[Pharo-project] [ANN] DrGeo release 10.08

[Hilaire Fernandes]

Dear all,

I am please to announce the DrGeo release 10.08. This is an universal
application working identically for GNU/Linux, Windows and Mac OS X.

http://blog.ofset.org/hilaire/index.php?post/2010/07/30/DrGeo-release-10.08-for-workstation

Hilaire


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] Limitation of number os literals in a method?

[nullPointer]

I get that error when I try save a CLView builded with the UIBuilder

More than 256 literals referenced. 
You must split or otherwise simplify this method.
The 257th literal is: 128

Select Proceed to continue, or close this window to cancel the operation.



How I can solve that problem? The method than I try save is generated
programmatically...

Thanks
-- 
View this message in context: 
http://forum.world.st/Limitation-of-number-os-literals-in-a-method-tp2308740p2308740.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] running Magma tests in 1.1

[Mariano Martinez Peck]

On Sat, Jul 31, 2010 at 4:57 AM, Henrik Johansen <
henrik.s.johan...@veloxit.no> wrote:

> Yes, the implementation of fileExists: was changed, so it no longer
> iterates over entire directory contents, but tries to open the file. Sadly,
> the Unix vm contains a bug which means relative links will not be resolved
> correctly.
> A fix from Cog has been submitted, but no release has been made which
> obtains it yet.
>
>
Hi Henry, Thanks a lot. Do you know if we have a test in PharoCore that test
this? At least a failing/error one due to this? It would be great to have
it.

The other vms are ok ?

thanks

mariano



> Cheers,
> Henry
>
> Den 30. juli 2010 kl. 23:09 skrev Chris Muller :
>
> > To run the test-suite for Magma 1.1r2 in Pharo:
> >
> > - Proceed past two warnings about "FlapTab" when loading Magma.
> > - Revert FileDirectory>>#fileExists: to the prior version.
> > - Remove #testClassSchemaUpgrades.
> > - Load OSProcess.
> >
> > The second and third steps, above, I believe may be regressions in Pharo
> 1.1.
> >
> > In Pharo 1.1:
> >
> >FileDirectory default fileExists:  '/bin/sh'"---> false"
> >
> > but the file does, indeed, exist as a soft-link.  Squeak answers true
> > and, I'll bet, so does Pharo 1.0, so I'm not sure if there is a
> > problem here or not.
> >
> > #testClassSchemaUpgrades tests Magma's ability to keep up with
> > class-schema changes in the image.  Usually class-schemas change only
> > in development, not production systems so maybe it's not a big deal.
> > But still, it can be very convenient develop new class schemas while
> > connected to a persistent Magma store.  Magma makes use of the
> > SystemChangeNotifier to do this.  I don't know if Pharo cleaned
> > something with SystemChangeNotifier or a regression happened, but I
> > don't have time to debug it right now.  Certainly, if there is a
> > problem with Magma I will fix it, but I'm not convinced of that yet.
> >
> > - Chris
> >
> > ___
> > Pharo-project mailing list
> > Pharo-project@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] about ToolBuilder

[stephane ducasse]

Hi guys

during the sprint I discussed with Gary about ToolBuilder and we think that it 
would be better to remove it
since a lot of new widgets are not covered so this means that we will be 
constantly limiting ourselves.
Of course ToolBuilder is a nice idea (if we would have several UI framework). 
So far we got only one
and we would have several we would have to take the smallest common denominator.
Another idea would be to extend toolBuilder to support new widgets.
So what do you think?

Stef
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] About overlapping packages :(

[Stéphane Ducasse]

Hi 

I have worked on the integration of the new package implementation and its 
synchronisation with MC/PackageInfo. 
Now I have the following problem:

Scenario 1:
the user have created a package Foo which contains several classes, 
some like FooObject
in the category Foo-Core, others in category Foo-Others.
Now if he creates a package Foo-Core, Foo-Core should contain the 
classes
having Foo-Core as category.

I have a problem with PackageInfo semantics since here packages Foo and 
Foo-Core could contain
FooObject. 

Scenario 2:
the user have created a class in the category Foo-Core, and after 
created a package only named Foo. 
The classes in category Foo-Core should be added to Foo. But some other 
packages and categories starting with Foo may exist.


Now in the new implementation, classes cannot be two packages at the same time. 
So I will be forced
to implement a checker making sure that there is no such situation and also 
that we should remove
first the Foo package and then create two package Foo-Core and Foo-Others.
What do you think?

May be such a checker should be hooked into MC right now so we detect anyway 
such bad situations.

For the moment I'm fighting within events and announcements to make sure that I 
could potentially 
keep the new implementation of Package and PackageOrganizer in sync with 
PackageInfo but this is not that simple.

Stef
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Underscores in 1.1??

[Stéphane Ducasse]

Don't overuse that :)

We do not like print_on_ ( ...) 
;D
Stef

On Jul 25, 2010, at 3:05 PM, Schwab,Wilhelm K wrote:

> THANKS! to all involved in getting this done.
> 
> 
> 
> 
> 
> From: pharo-project-boun...@lists.gforge.inria.fr 
> [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Lukas Renggli 
> [reng...@gmail.com]
> Sent: Sunday, July 25, 2010 4:32 AM
> To: Pharo-project@lists.gforge.inria.fr
> Subject: Re: [Pharo-project] Underscores in 1.1??
> 
>> Is 1.1 able to handle underscores in method *and* class names?  Is this 
>> really behind us now?
> 
> Yes, all identifiers support underscore characters everywhere. Also
> temporary and instance variables. And also in the refactoring engine.
> 
> The only problem I just noticed in the editor is that double clicking
> on a variable with a underscore does not change the selection
> correctly.
> 
> Lukas
> 
> --
> Lukas Renggli
> www.lukas-renggli.ch
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] SqueakSSL fails...

[Levente Uzonyi]

On Fri, 30 Jul 2010, Andrei Stebakov wrote:


It fails at the following statement:
(decoded readInto: buffer startingAt: index count: count) = count
ifFalse:[self error: 'Unexpected read failure'].

In SecureSocketStream>>initialize it decoded defined as
decoded := ReadStream on: (ByteArray new: 2) from: 1 to: 0.

Maybe decoded is supposed to become a SocketStream later in the game,
but at this point it's still a ReadStream which doesn't understand
#readInto:startingAt:count:


Hm no. It just wasn't integrated: 
http://code.google.com/p/pharo/issues/detail?id=2177 .



Levente



Can anyone reproduce this in Pharo 1.1? Just evaluate "WebClient
httpGet: 'https://www.google.com/search?q=squeak'."

2010/7/30 Levente Uzonyi :

On Fri, 30 Jul 2010, Andrei Stebakov wrote:


Apparently #readInto:startingAt:count: is not supported by ReadStream
Pharo 1.1...


SecureSocketStream is a subclass of SocketStream which has a method named
#readInto:startingAt:count:.


Levente




On Fri, Jul 30, 2010 at 5:46 PM, Andrei Stebakov 
wrote:


Well, I put it there when Pharo was running. Now that I restarted
Pharo I got a different error:
When I execute "WebClient httpGet:
'https://www.google.com/search?q=squeak'." I got:

ReadStream(Object)>>doesNotUnderstand: #readInto:startingAt:count:
SecureSocketStream>>receiveDataInto:startingAt:
SecureSocketStream>>receiveAvailableData
SecureSocketStream(SocketStream)>>upToAll:
WebResponse>>readFrom:
WebClient>>sendRequest:content:size:
WebClient>>sendRequest:
WebClient>>httpGet:do:
WebClient>>httpGet:
WebClient class>>httpGet:
UndefinedObject>>DoIt
Compiler>>evaluate:in:to:notifying:ifFail:logged:
[] in TextMorphForShoutEditor(ParagraphEditor)>>evaluateSelection
BlockClosure>>on:do:
TextMorphForShoutEditor(ParagraphEditor)>>evaluateSelection
TextMorphForShoutEditor(ParagraphEditor)>>doIt
[] in TextMorphForShoutEditor(ParagraphEditor)>>doIt:
TextMorphForShoutEditor(ParagraphEditor)>>terminateAndInitializeAround:
TextMorphForShoutEditor(ParagraphEditor)>>doIt:
TextMorphForShoutEditor(ParagraphEditor)>>dispatchOnKeyEvent:with:




On Fri, Jul 30, 2010 at 4:47 PM, Andrei Stebakov 
wrote:


I've downloaded the SqueakSSL.dll plugin and put it in the root folder.
Also I've downloaded
SqueakSSL-Core
SqueakSSL-Plugin
SqueakSSL-Tests

All tests passed.
Now when I try to execute "SqueakSSL google: 'Squeak'."
It fails creating the module in

primitiveSSLCreate
       "Primitive. Creates and returns a new SSL handle"

       
       ^self primitiveFailed

How can I fix it?

Thank you,
Andrei





___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] More on autotest

[Alexandre Bergel]

Hi Laurent!

One thing with autotest. When I compile a method, even though it is not covered 
by the tests, the tests are run again. This does not always make sense I feel 
since it slow down the way I code...

For example, when I am defining a meta-model, then running the test each time I 
add some business method it makes sense. However, when I define a mondrian 
visualization, all #visualize have to be excluded by autotest.

Cheers,
Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Pharo 1.1 host menu os x

[Michael Roberts]

>
> Michael, it is working for me. Not only in the OneClick but also with the
> image and the Squeak 4.2.5beta1U
> what is exactly what it is NOT working for you?

like I said literally the host menu quit menu item does not do
anything. exactly the symptom described in the original issue. this is
with the one click 1.1.

I will have a look at the code.
cheers
Mike

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] how do I turn off "smart" quotes in Pharo Seaside one-click image

[Nick Ager]

>
>
>  but if the point is that it is useful if one selects and then types, could
>> it simply apply the smart characters only when there is a slection as the
>> character is typed?  In that case, typing [ would do just that, typing [
>> when there is a selection would wrap the selection in [].  Just a thought.
>>
>
> I like this idea -- smartCharacters might be useful if it only took effect
> with a non-null selection. As it is, trying to type 'foo' is just too
> annoying to leave it on.
>
>
+1

It's also a frustration for those new to Smalltalk as the editor doesn't
behave in the way they're used to from their current programming editors. We
noticed this when we ran the introduction to Smalltalk at the recent
CampSmalltalk London.

However having the "Smart Character" off when you type, but on for a
selection so they magically wrap around selected text would in my view, be a
perfect compromise.
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] About overlapping packages :(

[Michael Roberts]

sounds tricky. at the very least add a checker to a menu somewhere so
we can start to use it. You wouldn't need to that deeply integrate it
in the first instance...

do you need to match the existing semantics exactly? I don't think
it's good that we can get into these situations. Perhaps we should
prevent them being able to be created in the first place, rather than
deal with them once they overlap.

cheers

Mike

On Fri, Jul 30, 2010 at 11:36 AM, Stéphane Ducasse
 wrote:
> Hi
>
> I have worked on the integration of the new package implementation and its 
> synchronisation with MC/PackageInfo.
> Now I have the following problem:
>
> Scenario 1:
>        the user have created a package Foo which contains several classes, 
> some like FooObject
>        in the category Foo-Core, others in category Foo-Others.
>        Now if he creates a package Foo-Core, Foo-Core should contain the 
> classes
>        having Foo-Core as category.
>
>        I have a problem with PackageInfo semantics since here packages Foo 
> and Foo-Core could contain
>        FooObject.
>
> Scenario 2:
>        the user have created a class in the category Foo-Core, and after 
> created a package only named Foo.
>        The classes in category Foo-Core should be added to Foo. But some 
> other packages and categories starting with Foo may exist.
>
>
> Now in the new implementation, classes cannot be two packages at the same 
> time. So I will be forced
> to implement a checker making sure that there is no such situation and also 
> that we should remove
> first the Foo package and then create two package Foo-Core and Foo-Others.
> What do you think?
>
> May be such a checker should be hooked into MC right now so we detect anyway 
> such bad situations.
>
> For the moment I'm fighting within events and announcements to make sure that 
> I could potentially
> keep the new implementation of Package and PackageOrganizer in sync with 
> PackageInfo but this is not that simple.
>
> Stef
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] how do I turn off "smart" quotes in Pharo Seaside one-click image

[Lukas Renggli]

2010/7/31 Nick Ager :
>>
>>> but if the point is that it is useful if one selects and then types,
>>> could it simply apply the smart characters only when there is a slection as
>>> the character is typed?  In that case, typing [ would do just that, typing [
>>> when there is a selection would wrap the selection in [].  Just a thought.
>>
>> I like this idea -- smartCharacters might be useful if it only took effect
>> with a non-null selection. As it is, trying to type 'foo' is just too
>> annoying to leave it on.
>>
>
> +1
> It's also a frustration for those new to Smalltalk as the editor doesn't
> behave in the way they're used to from their current programming editors. We
> noticed this when we ran the introduction to Smalltalk at the recent
> CampSmalltalk London.
> However having the "Smart Character" off when you type, but on for a
> selection so they magically wrap around selected text would in my view, be a
> perfect compromise.

I don't know if we talk about the same thing, but smart characters
behave the same way in my Pharo images as they do in Eclipse and in
TextMate.

Lukas

-- 
Lukas Renggli
www.lukas-renggli.ch

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Pharo 1.1 host menu os x

[Michael Roberts]

I guess the problem is because the one click application menu name is
now 'Pharo Development' rather than 'Pharo'. the code in this method
#rebuildApplicationMenuHandlers: is looking for the former. Did
someone make this change?  is it done in the info.plist? I am not very
familiar but i have had a poke around. I prefer Pharo anyway. it is
less verbose.  I will see if i can change it and get it to work.

thanks,
Mike

On Sat, Jul 31, 2010 at 1:04 PM, Michael Roberts  wrote:
>>
>> Michael, it is working for me. Not only in the OneClick but also with the
>> image and the Squeak 4.2.5beta1U
>> what is exactly what it is NOT working for you?
>
> like I said literally the host menu quit menu item does not do
> anything. exactly the symptom described in the original issue. this is
> with the one click 1.1.
>
> I will have a look at the code.
> cheers
> Mike
>

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] how do I turn off "smart" quotes in Pharo Seaside one-click image

[Nick Ager]

>
> I don't know if we talk about the same thing, but smart characters
> behave the same way in my Pharo images as they do in Eclipse and in
> TextMate.


My apologies - I've just downloaded the latest Eclipse and you are correct
the smart-characters work in a similar manor. However one important
usability difference is that when entering a string, my brain won't stop my
fingers from closing the quote - even though my eyes see "Smart Characters"
have automatically inserted the closing quote. On Eclipse the editor infers
I'm typing the closing quote/bracket etc and skips over the already inserted
"Smart Character", in Pharo it inserts another set of quotes giving me three
quotes at the end of my string and leaving the insertion point between the
first the second quote.  I think this issue was shared by our CampSmalltalk
beginners.


I've noticed that the builds I download from
http://hudson.lukas-renggli.chhave a different autocomplete to the
ones I download from
http://pharo-project.org. The autocomplete on the builds from Lukas seem a
lot faster - I find scrolling down in an autocomplete in the standard pharo
build often unbearable slow. Another difference is the added useful feature
of being able to view method detail from the autocomplete with right arrow.
Is there a way to load the Lukas build autocomplete on-top of a standard
Pharo image? Why the difference?
 

Nick
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] how do I turn off "smart" quotes in Pharo Seaside one-click image

[Lukas Renggli]

>> I don't know if we talk about the same thing, but smart characters
>> behave the same way in my Pharo images as they do in Eclipse and in
>> TextMate.
>
> My apologies - I've just downloaded the latest Eclipse and you are correct
> the smart-characters work in a similar manor. However one important
> usability difference is that when entering a string, my brain won't stop my
> fingers from closing the quote - even though my eyes see "Smart Characters"
> have automatically inserted the closing quote. On Eclipse the editor infers
> I'm typing the closing quote/bracket etc and skips over the already inserted
> "Smart Character", in Pharo it inserts another set of quotes giving me three
> quotes at the end of my string and leaving the insertion point between the
> first the second quote.  I think this issue was shared by our CampSmalltalk
> beginners.

That's fairly easy to adapt, please try the following version from
:

  Name: ECompletion-lr.126
  Author: lr
  Time: 31 July 2010, 4:10:04 pm
  UUID: 777d55d6-95e9-4630-a5ac-b35347286646
  Ancestors: ECompletion-lr.125

  - try to be smarter with smart characters

> 
> I've noticed that the builds I download from http://hudson.lukas-renggli.ch
> have a different autocomplete to the ones I download
> from http://pharo-project.org. The autocomplete on the builds from Lukas
> seem a lot faster - I find scrolling down in an autocomplete in the standard
> pharo build often unbearable slow. Another difference is the added useful
> feature of being able to view method detail from the autocomplete with right
> arrow. Is there a way to load the Lukas build autocomplete on-top of a
> standard Pharo image? Why the difference?
>  

oCompletion is an "extended" version of eCompletion that I use in my images.

You and I are not the only ones that prefer eCompletion, I know of
quite a few other people that think so too.

Lukas

-- 
Lukas Renggli
www.lukas-renggli.ch

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] how do I turn off "smart" quotes in Pharo Seaside one-click image

[Nick Ager]

Hi Lukas,

> My apologies - I've just downloaded the latest Eclipse and you are correct
> > the smart-characters work in a similar manor. However one important
> > usability difference is that when entering a string, my brain won't stop
> my
> > fingers from closing the quote - even though my eyes see "Smart
> Characters"
> > have automatically inserted the closing quote. On Eclipse the editor
> infers
> > I'm typing the closing quote/bracket etc and skips over the already
> inserted
> > "Smart Character", in Pharo it inserts another set of quotes giving me
> three
> > quotes at the end of my string and leaving the insertion point between
> the
> > first the second quote.  I think this issue was shared by our
> CampSmalltalk
> > beginners.
>
> That's fairly easy to adapt, please try the following version from
> :
>
>  Name: ECompletion-lr.126
>  Author: lr
>  Time: 31 July 2010, 4:10:04 pm
>  UUID: 777d55d6-95e9-4630-a5ac-b35347286646
>  Ancestors: ECompletion-lr.125
>
>  - try to be smarter with smart characters


Thanks for the that - it's getting there. A couple of issues:

* The change appears to have introduced odd delete behaviour. When I delete
a character within smart quotes, a character *and* the ending smart quote is
deleted - different behaviour to prior to your change,

* If I enter:  ('   in Eclipse when I type:  ') it skips over both the
closing ' and the closing ).

Apologies for my pedantry.

Nick
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] SqueakSSL fails...

[Stéphane Ducasse]

Indeed, if somebody has time please help.

Stef

On Jul 31, 2010, at 1:52 PM, Levente Uzonyi wrote:

> On Fri, 30 Jul 2010, Andrei Stebakov wrote:
> 
>> It fails at the following statement:
>> (decoded readInto: buffer startingAt: index count: count) = count
>>  ifFalse:[self error: 'Unexpected read failure'].
>> 
>> In SecureSocketStream>>initialize it decoded defined as
>> decoded := ReadStream on: (ByteArray new: 2) from: 1 to: 0.
>> 
>> Maybe decoded is supposed to become a SocketStream later in the game,
>> but at this point it's still a ReadStream which doesn't understand
>> #readInto:startingAt:count:
> 
> Hm no. It just wasn't integrated: 
> http://code.google.com/p/pharo/issues/detail?id=2177 .
> 
> 
> Levente
> 
>> 
>> Can anyone reproduce this in Pharo 1.1? Just evaluate "WebClient
>> httpGet: 'https://www.google.com/search?q=squeak'."
>> 
>> 2010/7/30 Levente Uzonyi :
>>> On Fri, 30 Jul 2010, Andrei Stebakov wrote:
>>> 
 Apparently #readInto:startingAt:count: is not supported by ReadStream
 Pharo 1.1...
>>> 
>>> SecureSocketStream is a subclass of SocketStream which has a method named
>>> #readInto:startingAt:count:.
>>> 
>>> 
>>> Levente
>>> 
 
 
 On Fri, Jul 30, 2010 at 5:46 PM, Andrei Stebakov 
 wrote:
> 
> Well, I put it there when Pharo was running. Now that I restarted
> Pharo I got a different error:
> When I execute "WebClient httpGet:
> 'https://www.google.com/search?q=squeak'." I got:
> 
> ReadStream(Object)>>doesNotUnderstand: #readInto:startingAt:count:
> SecureSocketStream>>receiveDataInto:startingAt:
> SecureSocketStream>>receiveAvailableData
> SecureSocketStream(SocketStream)>>upToAll:
> WebResponse>>readFrom:
> WebClient>>sendRequest:content:size:
> WebClient>>sendRequest:
> WebClient>>httpGet:do:
> WebClient>>httpGet:
> WebClient class>>httpGet:
> UndefinedObject>>DoIt
> Compiler>>evaluate:in:to:notifying:ifFail:logged:
> [] in TextMorphForShoutEditor(ParagraphEditor)>>evaluateSelection
> BlockClosure>>on:do:
> TextMorphForShoutEditor(ParagraphEditor)>>evaluateSelection
> TextMorphForShoutEditor(ParagraphEditor)>>doIt
> [] in TextMorphForShoutEditor(ParagraphEditor)>>doIt:
> TextMorphForShoutEditor(ParagraphEditor)>>terminateAndInitializeAround:
> TextMorphForShoutEditor(ParagraphEditor)>>doIt:
> TextMorphForShoutEditor(ParagraphEditor)>>dispatchOnKeyEvent:with:
> 
> 
> 
> 
> On Fri, Jul 30, 2010 at 4:47 PM, Andrei Stebakov 
> wrote:
>> 
>> I've downloaded the SqueakSSL.dll plugin and put it in the root folder.
>> Also I've downloaded
>> SqueakSSL-Core
>> SqueakSSL-Plugin
>> SqueakSSL-Tests
>> 
>> All tests passed.
>> Now when I try to execute "SqueakSSL google: 'Squeak'."
>> It fails creating the module in
>> 
>> primitiveSSLCreate
>>"Primitive. Creates and returns a new SSL handle"
>> 
>>
>>^self primitiveFailed
>> 
>> How can I fix it?
>> 
>> Thank you,
>> Andrei
>> 
> 
 
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>> 
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>> 
>> 
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] About overlapping packages :(

[Stéphane Ducasse]

> sounds tricky. at the very least add a checker to a menu somewhere so
> we can start to use it.

I will do that. 

> You wouldn't need to that deeply integrate it
> in the first instance...
> 
> do you need to match the existing semantics exactly? I don't think
> it's good that we can get into these situations. Perhaps we should
> prevent them being able to be created in the first place, rather than
> deal with them once they overlap.

It will change the flow: we will not be able to create a new subpackage 
Foo-Core (if Foo is already created)
, but will have to start delete the top package. 

Stef
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Aida/Web now loads and runs well on Pharo 1.1

[Stéphane Ducasse]

janko 
excellent news.
Did you create and publish configurationOfSwazoo Aida?
Because this is the way to go :)

Stef

On Jul 28, 2010, at 11:15 PM, Janko Mivšek wrote:

> Hi guys,
> 
> I just made Aida ready on new and wonderfull Pharo 1.1. and now Aida
> installs and run nicelly and even side by side with Seaside. You can
> even run both on the same Swazoo web server, which is also included.
> 
> Just evulate DEVImageWorkspaces openExternalProjectWorkspace then
> evaluate loads of both Seaside and Aida, then start both, for Aida evaluate:
> 
>   SwazooAida demoStart
>   "open http://localhost: in your web browser"
> 
> Best regards
> Janko 
> 
> 
> -- 
> Janko Mivšek
> AIDA/Web
> Smalltalk Web Application Server
> http://www.aidaweb.si
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] HTTP client library in Pharo?

[Stéphane Ducasse]

> Welcome to the wonderful world of squeak:
> 
> (Robin Williams genii voice on)
> 
> Vast, Cosmic Programming Powers
> 
> poorlymaintainedlibraries

Even if you are right, nothing prevents people to 
- load 
- fix
- enh 
libraries

We are working on books, chapters, ... and any help is welcomed.
People often mentions that Python has good documentations, but 
documentations/tests
do not get written magically. People do write them.

We will make sure with Metacello that libraries gets archived and loadable 
since metacello 
will help us to build distributions. 

Kent Beck told me recently that we often forget that everything done (even 
simple) is not to be done
anymore and that each time you do something you progress.
This is an important vision behind pharo. 
Do something small and do it a lot. Everybody can do something small. 

Stef
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Books for summer (was: Time Machine)

[Stéphane Ducasse]

C 90 ansi.
Socket chapters for the next books
Gentle introduction to semaphores (reread in fact).
Not sure that this is inspiring...

On Jul 26, 2010, at 7:39 AM, laurent laffont wrote:

> 
> 
> On Sat, Jul 24, 2010 at 10:59 AM, Patrick Barroca  
> wrote:
> I've ordered "Why programs fail" by Andreas Zeller.
> It will be my summer holidays book ;)
> 
> So I'll borrow it once read :)
> 
> I've ordered
> "Your Brain at Work: Strategies for Overcoming Distraction, Regaining Focus, 
> and Working Smarter All Day Long" - David Rock
>  
> "The 10-day MBA: A Step-by-Step Guide to Mastering the Skills Taught in Top 
> Business Schools" - Steven Silbiger (recommended in "Passionate Programmer" 
> by Chad Fowler).
> 
> And you dear Pharoers, what will you read this summer regarding your 
> computing/business activity ?
> 
> 
> Laurent
> 
> 
> 
> On Thu, Jul 22, 2010 at 11:52 PM, Stéphane Ducasse
>  wrote:
> > http://www.st.cs.uni-saarland.de/dd/
> > you can get some papers but also the slides that go with the book
> > Stef
> >
> > On Jul 22, 2010, at 11:36 PM, laurent laffont wrote:
> >
> >>
> >> On Thu, Jul 22, 2010 at 11:34 PM, Stéphane Ducasse 
> >>  wrote:
> >> did you read delta debugging from andreas Zeller?
> >>
> >> No. Where ?
> >>
> >> Laurent
> >>
> >>
> >>
> >> Stef
> >>
> >> On Jul 22, 2010, at 11:11 PM, laurent laffont wrote:
> >>
> >> > Hi,
> >> >
> >> > From a discussion I had with Kent Beck about Continuous Testing / 
> >> > Autotest (see 
> >> > http://pharocasts.blogspot.com/2010/07/live-testing-with-autotest.html 
> >> > ), I would like to add a kind of Time Machine for Smalltalk code in 
> >> > Autotest.
> >> >
> >> > When a test fails, what I really want to know is why. Sometimes a test 
> >> > fails and I don't know why. So I have to go through a debugging session 
> >> > which distracts me from what I've been coding.
> >> >
> >> > So an idea is to diff backtrace before and after the test fails:
> >> > - revert to last green
> >> > - replay the test and save the trace
> >> > - forward to current test and run (test fails)
> >> > - compare execution paths in order to see the consequence of last change
> >> >
> >> > How would you do this ? Where should I look for materials which can help 
> >> > me coding this ?
> >> >
> >> > Cheers,
> >> >
> >> > Laurent Laffont
> >> >
> >> > http://pharocasts.blogspot.com/
> >> > http://magaloma.blogspot.com/
> >> > ___
> >> > Pharo-project mailing list
> >> > Pharo-project@lists.gforge.inria.fr
> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >>
> >>
> >> ___
> >> Pharo-project mailing list
> >> Pharo-project@lists.gforge.inria.fr
> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >>
> >> ___
> >> Pharo-project mailing list
> >> Pharo-project@lists.gforge.inria.fr
> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
> >
> > ___
> > Pharo-project mailing list
> > Pharo-project@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
> 
> 
> 
> --
> Patrick Barroca
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] what about deprecating deprecated: ?

[Stéphane Ducasse]

Good idea. Now what I want and we will do it with veronica :)
is to have *ALL* the squeak/pharo code in a Gemstone db so that we can 
browse the complete history.

Stef

On Jul 29, 2010, at 8:24 PM, Mariano Martinez Peck wrote:

> Hi folks. Yes, I know it sounds weird...but just read
> 
> We said (don't remember when) that when we deprecate a method, we give a 
> whole release time so that eternal packages can fix they senders. And then in 
> the next release we remove it.
> 
> For example, in Pharo 1.1 we deprecate the methodX. Then, in Pharo 1.2, we 
> should remove it, together with the rest of methods depreacted in Pharo 1.1. 
> 
> How to detect the methods deprecated in Pharo 1.1? You need to take a 1.1 
> image and look there.
> 
> But to solve this, and other problems, we have not only deprecate: but also 
> deprecated: anExplanationString on: date in: version
> This is muuuch better and we can even then automate code so that it 
> automatically removes the deprecation of a previous image. You can browse and 
> see where each method was deprecated.
> 
> It would be cool if everybody uses that method instead of deprecated. And 
> thus, it would be cool to deprecate deprecated: hahahahaha
> 
> what do you think?
> 
> cheers
> 
> mariano
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Conflic between Shout and PluggableTextMorph in Pharo 1.2

[Stéphane Ducasse]

open a ticket :)

Stef

On Jul 29, 2010, at 8:49 PM, Mariano Martinez Peck wrote:

> Hi. If you try to load Shout, you will have the error: 'styler is already 
> defined in PluggableTextMorph'
> 
> The problem is that the Shut class PluggableShoutMorph subclass 
> PluggableTextMorph. 
> PluggableShoutMorph has its own instVar 'styler' which PluggableTextMorph 
> doesn't have in Pharo 1.1
> 
> But in Pharo 1.2 (I don't know why) PluggableTextMorph has its own instVar 
> 'styler'thus, the problem.
> 
> Of course, if I remove the instVar 'styler' from PluggableShoutMorph it shoud 
> load...but I am not sure if this is the correct action.
> 
> Thanks for the help in advance
> 
> Mariano
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] PluggableThemedOverflowPanelMorph(Object)>>doesNotUnderstand: #statusColor

[Stéphane Ducasse]

Thanks 
gary mentions that to me but I was off.
http://code.google.com/p/pharo/issues/detail?id=2732

On Jul 29, 2010, at 8:54 PM, Marcus Denker wrote:

> 
> On Jul 29, 2010, at 7:38 PM, Mariano Martinez Peck wrote:
> 
>> ok...as martin said, recompiling (change and save) 
>> PluggableButtonMorph>>#update:
>> did the trick...weird. Now we need to include this fix ASAP in the stream..
>> 
> I did:
> 
> -> fix all refrences to PluggableButtonPlus (and all other Undeclared)
> -> recompile the image.
> 
> Works.
> 
> 
>> cheers
>> 
>> mariano
>> 
>> On Thu, Jul 29, 2010 at 7:23 PM, Mariano Martinez Peck 
>>  wrote:
>> We need help to solve this problemI cannot do anything as I need the 
>> TestRunner.
>> 
>> WE have http://code.google.com/p/pharo/issues/detail?id=2717
>> 
>> and http://code.google.com/p/pharo/issues/detail?id=2700
>> 
>> I tried a Compiler recompileAll but still have the same problem. 
>> 
>> Cheers
>> 
>> Mariano
>> 
>> 
>> On Mon, Jul 26, 2010 at 11:02 PM, Mariano Martinez Peck 
>>  wrote:
>> Just try open a TestRunner. You will get a DNU and that won't let you even 
>> debug the error.  
>> 
>> Pharo core version: PharoCore-1.2-12061
>> 
>> I attach PharoDebug.log
>> PluggableThemedOverflowPanelMorph(Object)>>doesNotUnderstand: #statusColor
>> 
>> Issue:  http://code.google.com/p/pharo/issues/detail?id=2717
>> 
>> Cheers
>> 
>> Mariano
>> 
>> 
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> --
> Marcus Denker  -- http://www.marcusdenker.de
> INRIA Lille -- Nord Europe. Team RMoD.
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] there are still references to PluggableButtonMorphPlus

[Stéphane Ducasse]

marcus
can you update http://code.google.com/p/pharo/issues/detail?id=2732

Stef

On Jul 29, 2010, at 8:56 PM, Marcus Denker wrote:

> 
> On Jul 29, 2010, at 7:35 PM, Mariano Martinez Peck wrote:
> 
>> I am in PharoCore 12066 and there are still references to 
>> PluggableButtonMorphPlus, which doesn't exist anymore:
>> 
>> 
> 
> As much as I understand what Stef did with Gary is to start to merge all 
> those many many button classes into one.
> They removed all the *Plus ones, for example. The standard Pluggable one can 
> now do what the Plus did. 
> 
>> 1) MorphicToolBuilder >> buttonClass
>>^ PluggableButtonMorphPlus
>> 
>> is it ok to change it to
>> 
>> buttonClass
>>^ PluggableButtonMorph
>> 
>> ?
>> 
> yes, did that.
> 
>> 2) UITheme >> newButtonIn: aThemedMorph for: aModel getState: stateSel 
>> action: actionSel arguments: args getEnabled: enabledSel getLabel: labelSel 
>> help: helpText
>> 
>> 
>>|b|
>>b := PluggableButtonMorphPlus
>>on: aModel
>>getState: stateSel
>>action: actionSel
>>label: labelSel.
>> 
>> 
>> 
>> is it ok to change it to 
>> 
>>|b|
>>b := PluggableButtonMorph
>>on: aModel
>>getState: stateSel
>>action: actionSel
>>label: labelSel.
>> 
>> ?
>> 
> 
> I did that.
>> 
>> 3) MorphicToolBuilderTests >> expectedFailures
>>"Polymorph override of PluggableButtonMorphPlus>>update: makes color not 
>> being updated anymore in respond to sending #changed:. Was this an 
>> intentional change and this test is obsolete?"
>>^ #(testGetButtonColor)
>> 
>> 
>> I don't know how this one should be. But it should be updated, at least the 
>> class name. 
>> 
> 
> Yes, the classname should be fixed.
> 
> 
> --
> Marcus Denker  -- http://www.marcusdenker.de
> INRIA Lille -- Nord Europe. Team RMoD.
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] PharoCore 1.1 comments

[Stéphane Ducasse]

> Other than that, the new image is *very* fast!

We did a lot of cleans. Now it should be clear that we benefitted from the work 
done in Squeak by levente, nicolas and a couple of others.
Now this is not easy to follow what exactly can benefit to pharo and they were 
supportive. Now people can help at this level, comparing 
behavior, methods

Finally we do not want to give the impression that we are stealing from Squeak 
- I think that Squeak can also learn from Pharo. Our goal is to make a really 
cool Smalltalk system. There are still a lot of work to be done. 

Stef
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Pharo-users] Recent Messages Browser

[Stéphane Ducasse]

On Jul 30, 2010, at 10:47 AM, Mariano Martinez Peck wrote:

> 
> 
> On Fri, Jul 30, 2010 at 2:47 AM, Benjamin Van Ryseghem 
>  wrote:
> Hi everybody, 
> 
> 
> 
> I've rewrited a recent messages browser based on MorphTreeMorph.
> 
> 
> Hi, this is very good idea!
> 
>  
> If you can test it and tell me what's do you think about, it will be cool 
> (I'm a new Smalltalker ^^)
> 
> 
> welcome!
> 
>  
> You can download code here :
> 
> Gofer new
>   squeaksource: 'PharoTaskForces';
>   package: 'RecentSubmissions';
>   load.
> 
> 
> To launch it, just click on the World >> Tools >> Recent Messages.
> 
> You can set it up in the Setting Menu >> Code browsing >> Recent Message.
> 
> 
> 
> Ok...I did it. A few remarks:
> 
> 1) RecentMessageList >> initialize
> 
> you do
> 
> SmalltalkImage current addToStartUpList: self class.
> 
> but should be SmalltalkImage addToStartUpList: self class.

just Smalltalk addToStartUpList: self class.
> 
> 
> (at least in Pharo 1.1)
> 
> 2) What is the idea of the Recent Messages?   To see the recent MODIFIED 
> methods ? isn't it?   If true, maybe would be good to 
> 2.1) directly show the diff with the previous version
> 2.2) Have a button to see the versions of that method
> 
> 3) Once you press any button, like collapse all or similar, they become blue 
> and neve grey again
> 
> 4) When is the list of recen messages clean ?  how do you know the recen 
> messages? you store that information somewhere? when is that cleaned?
> 
> 
> Thank you very much and continue with the good work!  Maybe once we can 
> include it by defult in Pharo.

yes this is the point.

> 

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Limitation of number os literals in a method?

[Eliot Miranda]

On Sat, Jul 31, 2010 at 1:57 AM, nullPointer  wrote:

>
> I get that error when I try save a CLView builded with the UIBuilder
>
> More than 256 literals referenced.
> You must split or otherwise simplify this method.
> The 257th literal is: 128
>
> Select Proceed to continue, or close this window to cancel the operation.
>
>
>
> How I can solve that problem? The method than I try save is generated
> programmatically...
>

A proper fix requires new bytecodes, but if your method contains lots of
explicit literal references, not just lots of message selectors or global
varaiables, then there is a workaround.  The problem is due to encoding
ranges in message send and literal reference bytecodes which are limited to
a 0 to 255 single byte range.  There is no way around this limitation for
message selectors or global variables without defining as bytecode with an
extended range, but for explicit references if you put your literals in
multiple arrays and access them by index you can pool the indices.  This can
be done either at the compiler level or at the generation level, but you
should start working at the generation level.  e.g.

myMethod
| litPool0 litPool1 litPool2 litPool3 |
litPool0 := #( a literal array with up to 128 elements).
litPool1 := #( a literal array with up to 128 elements).
litPool2 := #( a literal array with up to 128 elements).
litPool3 := #( a literal array with up to 128 elements).

self doSomethingWith: (litPool2 at: 127)
...

Your method now uses 1 literal for each pool and 1 literal for each array
index other than 1 & 2 (1 & 2 have special bytecodes for them, as does the
selector #at:).  So, assuming every index is used, the above method uses 4 +
126 = 130 literals, leaving 126 literals for selectors and globals, while
providing access to 512 explicit literals in the pool literal arrays.  If
you were to make the literal pools 256 elements large you'd loose because
you'd need as many literals for the indices 3 to 256 as you saved from
making the literal pool indirect.  So using more smaller pools increases the
total number of  literals, e.g. with 8 64-element pools the above example
uses 8 + 62 = 70 literals.

When we can get to it we need to redefine the bytecode set to extend these
ranges.  Take a look at the VisualWorks bytecodes for a better encoding
scheme.

HTH
Eliot


>
> Thanks
> --
> View this message in context:
> http://forum.world.st/Limitation-of-number-os-literals-in-a-method-tp2308740p2308740.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [squeak-dev] [ANN] Magma 1.1r2

[Chris Muller]

> Two more package missing in Magma repo:
>
> Ma exception handling-cmm.36.mcz
> Ma object serialization tester-cmm.32.mcz

Fixed.  Thanks.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Limitation of number os literals in a method?

[nullPointer]

That is the method with the problems:

 http://paste.lisp.org/display/113020
-- 
View this message in context: 
http://forum.world.st/Limitation-of-number-os-literals-in-a-method-tp2308740p2308973.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Object>>doesNotUnderstand:

[Stéphane Ducasse]

Denis 

I would really like to see/have access to your code because I think that the 
behavior you want should be in any system so that you can run really headless. 

Stef
On Jul 27, 2010, at 10:58 PM, Denis Kudriashov wrote:

> In either case control should not return to the point of error.  If you want 
> to log errors and then continue you need to continue from some well-defined 
> point, not merely return control to the point of error.  So if your approach 
> is to catch and log errors, after logging you need to transfer control back 
> to some starting point, e.g. by throwing some ResumeExecution exception.
> 
> Thanks, It really work
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Limitation of number os literals in a method?

[Randal L. Schwartz]

> "nullPointer" == nullPointer   writes:

nullPointer> That is the method with the problems:

nullPointer>  http://paste.lisp.org/display/113020

Eww.  I hope that method was generated automatically, and that humans
can maintain something that *generates* that method.

Otherwise, it's a strong candidate for being broken up into sane smaller
methods. 

Lots of repetition too.  Could use a good refactoring, to invoke that
code driven from some sort of data structure.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
 http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Underscores in 1.1??

[Schwab,Wilhelm K]

Stef,

No worries there.  The value of underscores is for external interfacing: names 
map (more or less) directly and there are few if any concerns about whether 
removing the underscores resulted in two otherwise distinct names colliding.  
Like I said: THANKS!

Bill





From: pharo-project-boun...@lists.gforge.inria.fr 
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse 
[stephane.duca...@inria.fr]
Sent: Saturday, July 31, 2010 7:03 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Underscores in 1.1??

Don't overuse that :)

We do not like print_on_ ( ...)
;D
Stef

On Jul 25, 2010, at 3:05 PM, Schwab,Wilhelm K wrote:

> THANKS! to all involved in getting this done.
>
>
>
>
> 
> From: pharo-project-boun...@lists.gforge.inria.fr 
> [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Lukas Renggli 
> [reng...@gmail.com]
> Sent: Sunday, July 25, 2010 4:32 AM
> To: Pharo-project@lists.gforge.inria.fr
> Subject: Re: [Pharo-project] Underscores in 1.1??
>
>> Is 1.1 able to handle underscores in method *and* class names?  Is this 
>> really behind us now?
>
> Yes, all identifiers support underscore characters everywhere. Also
> temporary and instance variables. And also in the refactoring engine.
>
> The only problem I just noticed in the editor is that double clicking
> on a variable with a underscore does not change the selection
> correctly.
>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Limitation of number os literals in a method?

[nullPointer]

XD
-- 
View this message in context: 
http://forum.world.st/Limitation-of-number-os-literals-in-a-method-tp2308740p2308991.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] Fwd: [squeak-dev] [ANN] DnsClient: More protocol fun

[Stéphane Ducasse]

Looks interesting :)


> From: Andreas Raab 
> Date: July 27, 2010 9:24:16 AM GMT+02:00
> To: The general-purpose Squeak developers list 
> 
> Subject: [squeak-dev] [ANN] DnsClient: More protocol fun
> Reply-To: The general-purpose Squeak developers list 
> 
> 
> Folks -
> 
> I just finished another fun little protocol implementation. DnsClient is a 
> client for DNS lookups of all sorts. Why implement the DNS protocol you ask? 
> Well, because 1) it's fun, 2) it's educational, and 3) it's non-blocking. The 
> latter is actually interesting, we've found that occasionally we get very 
> long VM blocking due to synchronous name lookup performed in the Unix socket 
> code.
> 
> You can install DnsClient from Squeaksource:
> 
>   (Installer ss project: 'ar')
>   install: 'DnsClient-Core';  "all the code"
>   install: 'DnsClient-Tests'; "the tests"
>   install: 'DnsClient-Hacks'. "use DnsClient when present"
> 
> DnsClient should work well but beware that on Windows it will currently use 
> the deefault fallback name servers (Google DNS and OpenDNS) since I still 
> need to implement the primitive to return the proper resolv.conf content 
> (which is spread out in the Windows registry). Consequently, if you're trying 
> look up local names or if you are behind a firewall, these addresses will 
> fail until I've implemented the primitive proper.
> 
> Cheers,
> - Andreas
> 






___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] how do I turn off "smart" quotes in Pharo Seaside one-click image

[Lukas Renggli]

2010/7/31 Nick Ager :
> Hi Lukas,
>
>> > My apologies - I've just downloaded the latest Eclipse and you are
>> > correct
>> > the smart-characters work in a similar manor. However one important
>> > usability difference is that when entering a string, my brain won't stop
>> > my
>> > fingers from closing the quote - even though my eyes see "Smart
>> > Characters"
>> > have automatically inserted the closing quote. On Eclipse the editor
>> > infers
>> > I'm typing the closing quote/bracket etc and skips over the already
>> > inserted
>> > "Smart Character", in Pharo it inserts another set of quotes giving me
>> > three
>> > quotes at the end of my string and leaving the insertion point between
>> > the
>> > first the second quote.  I think this issue was shared by our
>> > CampSmalltalk
>> > beginners.
>>
>> That's fairly easy to adapt, please try the following version from
>> :
>>
>>  Name: ECompletion-lr.126
>>  Author: lr
>>  Time: 31 July 2010, 4:10:04 pm
>>  UUID: 777d55d6-95e9-4630-a5ac-b35347286646
>>  Ancestors: ECompletion-lr.125
>>
>>  - try to be smarter with smart characters
>
> Thanks for the that - it's getting there. A couple of issues:
> * The change appears to have introduced odd delete behaviour. When I delete
> a character within smart quotes, a character *and* the ending smart quote is
> deleted - different behaviour to prior to your change,
> * If I enter:  ('   in Eclipse when I type:  ') it skips over both the
> closing ' and the closing ).
> Apologies for my pedantry.

Well, I am sorry I said it is fairly easy to adapt. The implementation
was really bogus because it globally kept state. I rewrote the code
from scratch and committed it here:

  Name: ECompletion-lr.127
  Author: lr
  Time: 31 July 2010, 7:21:25 pm
  UUID: 42e3e807-2478-4dda-b207-acf162648cfe
  Ancestors: ECompletion-lr.126

  - rewrote the complete smart character logic (very ugly)

Now this is really ugly and long code and there are literally dozens
of cases to handle. Let me know if it works better for you? I kind of
like it. The behavior for smart characters and the backspace is now
entirely different if there is a selection or if you are just typing.

Lukas

-- 
Lukas Renggli
www.lukas-renggli.ch

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Conflic between Shout and PluggableTextMorph in Pharo 1.2

[Mariano Martinez Peck]

http://code.google.com/p/pharo/issues/detail?id=2734

It is easy to fix:

a) use the same instVar and I just remove it from Shout
b) rename the instVar in Shout

the problem is that I don't know the correct one

cheers

mariano


On Sat, Jul 31, 2010 at 5:47 PM, Stéphane Ducasse  wrote:

> open a ticket :)
>
> Stef
>
> On Jul 29, 2010, at 8:49 PM, Mariano Martinez Peck wrote:
>
> > Hi. If you try to load Shout, you will have the error: 'styler is already
> defined in PluggableTextMorph'
> >
> > The problem is that the Shut class PluggableShoutMorph subclass
> PluggableTextMorph.
> > PluggableShoutMorph has its own instVar 'styler' which PluggableTextMorph
> doesn't have in Pharo 1.1
> >
> > But in Pharo 1.2 (I don't know why) PluggableTextMorph has its own
> instVar 'styler'thus, the problem.
> >
> > Of course, if I remove the instVar 'styler' from PluggableShoutMorph it
> shoud load...but I am not sure if this is the correct action.
> >
> > Thanks for the help in advance
> >
> > Mariano
> > ___
> > Pharo-project mailing list
> > Pharo-project@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] copying always the .sources ??? [WAS] Re: PharoCore 1.1 comments

[Mariano Martinez Peck]

2010/7/30 Miguel Enrique Cobá Martínez 

> Hi all,
>
> some things I noticed in PharoCore 1.1 release:
>
>
> - This PharoCore-1.1.zip doesn't include a sources file. It was good to
> have it included in the zip as before. Can be included for every
> PharoCore release?
>
> - The page says that PharoV10.sources is for use with 1.0, 1.1 and 1.2.
> Shouldn't be better to have a different one for each release? (even if
> 1.1 is a copy of 1.0, the different name avoids doubts about numbering
> scheme):
>
> PharoCore-1.0.image
> PharoCore-1.0.changes
> PharoV10.sources
>
> PharoCore-1.1.image
> PharoCore-1.1.changes
> PharoV10.sources(???)
>
>

I also thought about this and that could be confusing with newcomers. But if
.sources didn't change in 1.1 and 1.2, is it necessary to have them?   or
the note saying that PharoV10.sources works for all is enought ?

Cheers

Mariano




> ...
>
> PharoCore-1.7.image
> PharoCore-1.7.changes
> PharoV10.sources(bigger ???)
>
> Just a suggestion. ;)
>
> - SystemVersion current majorMinorVersion prints:
>
> PharoCore 1.0: 'PharoCore1.0'
>
> PharoCore 1.1: 'Pharo1.1'
>
> Maybe this should be in the script preparing the image so that correctly
> set the version string for PharoCore images and for Pharo images (or
> maybe already is there but wasn't executed?)
>
> Other than that, the new image is *very* fast!
>
> Cheers
> --
> Miguel Cobá
> http://miguel.leugim.com.mx
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] PharoCore 1.1 comments

[Mariano Martinez Peck]

2010/7/30 Miguel Enrique Cobá Martínez 

> Hi all,
>
> some things I noticed in PharoCore 1.1 release:
>
>
> - This PharoCore-1.1.zip doesn't include a sources file. It was good to
> have it included in the zip as before. Can be included for every
> PharoCore release?
>
>
I agree. The release SHOULD include the .sources. Not every pharo core
release because it is too much...but official releases may have also the
.sources.

Maybe we can repackage and upload a newone?

marcus?



> - The page says that PharoV10.sources is for use with 1.0, 1.1 and 1.2.
> Shouldn't be better to have a different one for each release? (even if
> 1.1 is a copy of 1.0, the different name avoids doubts about numbering
> scheme):
>
> PharoCore-1.0.image
> PharoCore-1.0.changes
> PharoV10.sources
>
> PharoCore-1.1.image
> PharoCore-1.1.changes
> PharoV10.sources(???)
>
> ...
>
> PharoCore-1.7.image
> PharoCore-1.7.changes
> PharoV10.sources(bigger ???)
>
> Just a suggestion. ;)
>
> - SystemVersion current majorMinorVersion prints:
>
> PharoCore 1.0: 'PharoCore1.0'
>
> PharoCore 1.1: 'Pharo1.1'
>
> Maybe this should be in the script preparing the image so that correctly
> set the version string for PharoCore images and for Pharo images (or
> maybe already is there but wasn't executed?)
>
> Other than that, the new image is *very* fast!
>
> Cheers
> --
> Miguel Cobá
> http://miguel.leugim.com.mx
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] SqueakSSL fails...

[Mariano Martinez Peck]

I am in mac...do you have binaries for mac of such plugin?

On Sat, Jul 31, 2010 at 5:14 PM, Stéphane Ducasse  wrote:

> Indeed, if somebody has time please help.
>
> Stef
>
> On Jul 31, 2010, at 1:52 PM, Levente Uzonyi wrote:
>
> > On Fri, 30 Jul 2010, Andrei Stebakov wrote:
> >
> >> It fails at the following statement:
> >> (decoded readInto: buffer startingAt: index count: count) = count
> >>  ifFalse:[self error: 'Unexpected read failure'].
> >>
> >> In SecureSocketStream>>initialize it decoded defined as
> >> decoded := ReadStream on: (ByteArray new: 2) from: 1 to: 0.
> >>
> >> Maybe decoded is supposed to become a SocketStream later in the game,
> >> but at this point it's still a ReadStream which doesn't understand
> >> #readInto:startingAt:count:
> >
> > Hm no. It just wasn't integrated:
> http://code.google.com/p/pharo/issues/detail?id=2177 .
> >
> >
> > Levente
> >
> >>
> >> Can anyone reproduce this in Pharo 1.1? Just evaluate "WebClient
> >> httpGet: 
> >> 'https://www.google.com/search?q=squeak'
> ."
> >>
> >> 2010/7/30 Levente Uzonyi :
> >>> On Fri, 30 Jul 2010, Andrei Stebakov wrote:
> >>>
>  Apparently #readInto:startingAt:count: is not supported by ReadStream
>  Pharo 1.1...
> >>>
> >>> SecureSocketStream is a subclass of SocketStream which has a method
> named
> >>> #readInto:startingAt:count:.
> >>>
> >>>
> >>> Levente
> >>>
> 
> 
>  On Fri, Jul 30, 2010 at 5:46 PM, Andrei Stebakov  >
>  wrote:
> >
> > Well, I put it there when Pharo was running. Now that I restarted
> > Pharo I got a different error:
> > When I execute "WebClient httpGet:
> > 'https://www.google.com/search?q=squeak'."
> I got:
> >
> > ReadStream(Object)>>doesNotUnderstand: #readInto:startingAt:count:
> > SecureSocketStream>>receiveDataInto:startingAt:
> > SecureSocketStream>>receiveAvailableData
> > SecureSocketStream(SocketStream)>>upToAll:
> > WebResponse>>readFrom:
> > WebClient>>sendRequest:content:size:
> > WebClient>>sendRequest:
> > WebClient>>httpGet:do:
> > WebClient>>httpGet:
> > WebClient class>>httpGet:
> > UndefinedObject>>DoIt
> > Compiler>>evaluate:in:to:notifying:ifFail:logged:
> > [] in TextMorphForShoutEditor(ParagraphEditor)>>evaluateSelection
> > BlockClosure>>on:do:
> > TextMorphForShoutEditor(ParagraphEditor)>>evaluateSelection
> > TextMorphForShoutEditor(ParagraphEditor)>>doIt
> > [] in TextMorphForShoutEditor(ParagraphEditor)>>doIt:
> >
> TextMorphForShoutEditor(ParagraphEditor)>>terminateAndInitializeAround:
> > TextMorphForShoutEditor(ParagraphEditor)>>doIt:
> > TextMorphForShoutEditor(ParagraphEditor)>>dispatchOnKeyEvent:with:
> >
> >
> >
> >
> > On Fri, Jul 30, 2010 at 4:47 PM, Andrei Stebakov <
> lisper...@gmail.com>
> > wrote:
> >>
> >> I've downloaded the SqueakSSL.dll plugin and put it in the root
> folder.
> >> Also I've downloaded
> >> SqueakSSL-Core
> >> SqueakSSL-Plugin
> >> SqueakSSL-Tests
> >>
> >> All tests passed.
> >> Now when I try to execute "SqueakSSL google: 'Squeak'."
> >> It fails creating the module in
> >>
> >> primitiveSSLCreate
> >>"Primitive. Creates and returns a new SSL handle"
> >>
> >>
> >>^self primitiveFailed
> >>
> >> How can I fix it?
> >>
> >> Thank you,
> >> Andrei
> >>
> >
> 
>  ___
>  Pharo-project mailing list
>  Pharo-project@lists.gforge.inria.fr
>  http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >>>
> >>> ___
> >>> Pharo-project mailing list
> >>> Pharo-project@lists.gforge.inria.fr
> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >>>
> >>
> >> ___
> >> Pharo-project mailing list
> >> Pharo-project@lists.gforge.inria.fr
> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> > ___
> > Pharo-project mailing list
> > Pharo-project@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] [update 1.2] #12071

[Stéphane Ducasse]

12071
-

- Issue 2732:   Paste Up Clean up post actions required
- Issue 2731:   SystemNavigation cleaning
- Issue 2730:   Dialog cleaning
- Issue 2728:   MCSubDirectoryRepository should not use / but
- Issue 2709:   printStringHex for Character

Stef

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Limitation of number os literals in a method?

[Stéphane Ducasse]

eliot

in VW did windows spec faced such a limit and relied on such bytecodes?
I imagine that this is the case but...

Stef

On Jul 31, 2010, at 6:10 PM, Eliot Miranda wrote:

> 
> On Sat, Jul 31, 2010 at 1:57 AM, nullPointer  wrote:
> 
> I get that error when I try save a CLView builded with the UIBuilder
> 
> More than 256 literals referenced.
> You must split or otherwise simplify this method.
> The 257th literal is: 128
> 
> Select Proceed to continue, or close this window to cancel the operation.
> 
> 
> 
> How I can solve that problem? The method than I try save is generated
> programmatically...
> 
> A proper fix requires new bytecodes, but if your method contains lots of 
> explicit literal references, not just lots of message selectors or global 
> varaiables, then there is a workaround.  The problem is due to encoding 
> ranges in message send and literal reference bytecodes which are limited to a 
> 0 to 255 single byte range.  There is no way around this limitation for 
> message selectors or global variables without defining as bytecode with an 
> extended range, but for explicit references if you put your literals in 
> multiple arrays and access them by index you can pool the indices.  This can 
> be done either at the compiler level or at the generation level, but you 
> should start working at the generation level.  e.g.
> 
> myMethod
> | litPool0 litPool1 litPool2 litPool3 |
> litPool0 := #( a literal array with up to 128 elements).
> litPool1 := #( a literal array with up to 128 elements).
> litPool2 := #( a literal array with up to 128 elements).
> litPool3 := #( a literal array with up to 128 elements).
> 
> self doSomethingWith: (litPool2 at: 127)
> ...
> 
> Your method now uses 1 literal for each pool and 1 literal for each array 
> index other than 1 & 2 (1 & 2 have special bytecodes for them, as does the 
> selector #at:).  So, assuming every index is used, the above method uses 4 + 
> 126 = 130 literals, leaving 126 literals for selectors and globals, while 
> providing access to 512 explicit literals in the pool literal arrays.  If you 
> were to make the literal pools 256 elements large you'd loose because you'd 
> need as many literals for the indices 3 to 256 as you saved from making the 
> literal pool indirect.  So using more smaller pools increases the total 
> number of  literals, e.g. with 8 64-element pools the above example uses 8 + 
> 62 = 70 literals.
> 
> When we can get to it we need to redefine the bytecode set to extend these 
> ranges.  Take a look at the VisualWorks bytecodes for a better encoding 
> scheme.
> 
> HTH
> Eliot
>  
> 
> Thanks
> --
> View this message in context: 
> http://forum.world.st/Limitation-of-number-os-literals-in-a-method-tp2308740p2308740.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] how do I turn off "smart" quotes in Pharo Seaside one-click image

[Stéphane Ducasse]

>>> 
> 
> Well, I am sorry I said it is fairly easy to adapt. The implementation
> was really bogus because it globally kept state. I rewrote the code
> from scratch and committed it here:
> 
>  Name: ECompletion-lr.127
>  Author: lr
>  Time: 31 July 2010, 7:21:25 pm
>  UUID: 42e3e807-2478-4dda-b207-acf162648cfe
>  Ancestors: ECompletion-lr.126
> 
>  - rewrote the complete smart character logic (very ugly)
> 
> Now this is really ugly and long code and there are literally dozens
> of cases to handle. Let me know if it works better for you? I kind of
> like it. The behavior for smart characters and the backspace is now
> entirely different if there is a selection or if you are just typing

sound exciting


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Conflic between Shout and PluggableTextMorph in Pharo 1.2

[Stéphane Ducasse]

I see styler was only in the Plus variation

Now styler is used in PluggableTextMorph so may be a default null Styler would 
be better than all these okToStyle check
everywhere.

So I would remove styler from shout and tag the version for 1.2.

Stef


> http://code.google.com/p/pharo/issues/detail?id=2734
> 
> It is easy to fix: 
> 
> a) use the same instVar and I just remove it from Shout
> b) rename the instVar in Shout
> 
> the problem is that I don't know the correct one
> 
> cheers
> 
> mariano
> 
> 
> On Sat, Jul 31, 2010 at 5:47 PM, Stéphane Ducasse  
> wrote:
> open a ticket :)
> 
> Stef
> 
> On Jul 29, 2010, at 8:49 PM, Mariano Martinez Peck wrote:
> 
> > Hi. If you try to load Shout, you will have the error: 'styler is already 
> > defined in PluggableTextMorph'
> >
> > The problem is that the Shut class PluggableShoutMorph subclass 
> > PluggableTextMorph.
> > PluggableShoutMorph has its own instVar 'styler' which PluggableTextMorph 
> > doesn't have in Pharo 1.1
> >
> > But in Pharo 1.2 (I don't know why) PluggableTextMorph has its own instVar 
> > 'styler'thus, the problem.
> >
> > Of course, if I remove the instVar 'styler' from PluggableShoutMorph it 
> > shoud load...but I am not sure if this is the correct action.
> >
> > Thanks for the help in advance
> >
> > Mariano
> > ___
> > Pharo-project mailing list
> > Pharo-project@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] copying always the .sources ??? [WAS] Re: PharoCore 1.1 comments

[Stéphane Ducasse]

A self contained version would be good.
this way I download one file and I get everything.

Stef

> 
> 
> 2010/7/30 Miguel Enrique Cobá Martínez 
> Hi all,
> 
> some things I noticed in PharoCore 1.1 release:
> 
> 
> - This PharoCore-1.1.zip doesn't include a sources file. It was good to
> have it included in the zip as before. Can be included for every
> PharoCore release?
> 
> - The page says that PharoV10.sources is for use with 1.0, 1.1 and 1.2.
> Shouldn't be better to have a different one for each release? (even if
> 1.1 is a copy of 1.0, the different name avoids doubts about numbering
> scheme):
> 
> PharoCore-1.0.image
> PharoCore-1.0.changes
> PharoV10.sources
> 
> PharoCore-1.1.image
> PharoCore-1.1.changes
> PharoV10.sources(???)
> 
> 
> 
> I also thought about this and that could be confusing with newcomers. But if 
> .sources didn't change in 1.1 and 1.2, is it necessary to have them?   or the 
> note saying that PharoV10.sources works for all is enought ?
> 
> Cheers
> 
> Mariano
> 
> 
>  
> ...
> 
> PharoCore-1.7.image
> PharoCore-1.7.changes
> PharoV10.sources(bigger ???)
> 
> Just a suggestion. ;)
> 
> - SystemVersion current majorMinorVersion prints:
> 
> PharoCore 1.0: 'PharoCore1.0'
> 
> PharoCore 1.1: 'Pharo1.1'
> 
> Maybe this should be in the script preparing the image so that correctly
> set the version string for PharoCore images and for Pharo images (or
> maybe already is there but wasn't executed?)
> 
> Other than that, the new image is *very* fast!
> 
> Cheers
> --
> Miguel Cobá
> http://miguel.leugim.com.mx
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Limitation of number os literals in a method?

[Stéphane Ducasse]

did you try to generate a string (I know this is not the same)

container := CLPanel new.
container name: 'container'.
container text: ''.
container usePolymorphStyleMechanism: true.
container balloonText: nil.
container enabled: true.
container location: 8...@10.
container extent: 6...@460.
container anchors: {false .false .false .false .}.
container imageResource: nil.
container style: {
(BorderStyle width: 0 color: Color transparent) .(Color r: 0.972 g: 0.972 b: 
0.944) .(Color r: 0.972 g: 0.972 b: 0.944)
 .false .false .}.
container minWidth: 2.
container minHeight: 2.
container layout: {ProportionalLayout .#rigid .#rigid .0 .#center 
.#none .0 .#topLeft .#topToBottom .#none .false .#topLeft .#none .0 .1073741823 
.}.
container visible = false.
container openInWorld.

=>

'Panel
name: ''container''
usePolymorphStyleMechanism: true.
enabled: true.
location: 8...@10.
extent: 6...@460.
anchors: {false .false .false .false .}.
...
 minWidth: 2.
 minHeight: 2.
layout: #(ProportionalLayout .#rigid .#rigid .0 .#center .#none 
.0 .#topLeft .#topToBottom .#none .false .#topLeft .#none .0 .1073741823 ) .
visible: false.'

then you parse only subexpressions delimited by #( )
and do a big perform: loop


what you could do is also to decouple the description from its interpretation 
using a Builder Design Pattern.
This way you do not bind the spec to your specific widgets and you could 
customize your build with different 
widgets.

PS: Apparently you have a problem also 

container visible = false.
=>
container visible: false.

Stef

On Jul 31, 2010, at 10:57 AM, nullPointer wrote:

> 
> I get that error when I try save a CLView builded with the UIBuilder
> 
> More than 256 literals referenced. 
> You must split or otherwise simplify this method.
> The 257th literal is: 128
> 
> Select Proceed to continue, or close this window to cancel the operation.
> 
> 
> 
> How I can solve that problem? The method than I try save is generated
> programmatically...
> 
> Thanks
> -- 
> View this message in context: 
> http://forum.world.st/Limitation-of-number-os-literals-in-a-method-tp2308740p2308740.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Pharo 1.1/1.2 and class names in Chinese

[Stéphane Ducasse]

+ 2

Stef

On Jul 28, 2010, at 10:27 PM, Juan Vuletich wrote:

> Hi Folks,
> 
> I think that is a mistake. Having Spanish as my mother tongue, I used to code 
> with Spanish names before knowing Smalltalk. So when started using Smalltalk 
> I kept doing it. Later I realized it is a bad idea. In Smalltalk there is no 
> clear distinction between the "vendor libraries" and our own code. Our 
> application specific classes will many times implement methods akin to 
> existing ones in the system. Writing their names in English makes the whole 
> system more consistent. Following this a little bit, it is better if all the 
> code we write is in English too.
> 
> OTOH, I believe it is ok to write comments in languages other than English 
> (if the code will not be open sourced).
> 
> I'd even suggest the system to reject names and selectors not in ASCII.
> 
> Cheers,
> Juan Vuletich
> 
> Alexandre Bergel wrote:
>> I have no idea how to help you. But trying to have classes with chinese (or 
>> any other alphabet with accents) names is important.
>> Even though I personally write all my code in English, many like to write 
>> code in their favorite natural language. This is what I see with students 
>> for example.
>> 
>> Cheers,
>> Alexandre
>> 
>> 
>> On 28 Jul 2010, at 21:33, empty wrote:
>> 
>>  
>>> In 1.1 and 1.2, without setting a language environment for Chinese, I am 
>>> able
>>> to use Chinese by setting fonts. It seems to work except for accepting a
>>> class named in Chinese will end in a ClassBuilder error of 'Class names must
>>> be capitalized'. Well is it a feature(requires language environment being
>>> set correctly) or bug?
>>> 
>>> The code located being:
>>> 
>>> validateClassName: aString
>>> "Validate the new class name"
>>> 
>>> aString isSymbol
>>> ifFalse: [ ^ false ].
>>> aString first canBeGlobalVarInitial ifFalse:[
>>> self error: 'Class names must be capitalized'.
>>> ^false].
>>> environ at: aString ifPresent:[:old|
>>> (old isKindOf: Behavior) ifFalse:[
>>> self notify: aString asText allBold,
>>> ' already exists!\Proceed will store over it.' 
>>> withCRs]].
>>> ^ true
>>> 
>>> and following the code the problemic method is #canBeGlobalVarInitial: which
>>> is found in two classes:
>>> in EncodedCharSet class side:
>>> canBeGlobalVarInitial: char
>>> 
>>> | leadingChar |
>>> leadingChar := char leadingChar.
>>> 
>>> leadingChar = 0 ifTrue: [^ self isUppercase: char].
>>> ^ self isLetter: char.
>>> 
>>> and in LanguageEnvironment
>>> 
>>> canBeGlobalVarInitial: char
>>> 
>>> ^ Unicode canBeGlobalVarInitial: char.
>>> 
>>> I didn't set a Chinese environment and the exception is occured in in
>>> EncodedCharSet class since leadingChar is 0 and a Chinese char seems thought
>>> to be lowercased.
>>> 
>>> 
>>> 
>>> 
>>> -
>>> 南無佛 南無法 南無僧
>>> -- 
>>> View this message in context: 
>>> http://forum.world.st/Pharo-1-1-1-2-and-class-names-in-Chinese-tp2305496p2305496.html
>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>> 
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>> 
>>  
>> 
>> 
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3030 
>> - Release Date: 07/26/10 15:34:00
>> 
>>  
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Pharo 1.1/1.2 and class names in Chinese

[Stéphane Ducasse]

It would be nice to clean that situation in 1.3 
I think that we should get some tasks and tackle it together. Probably more 
pair programming would help.

Stef

On Jul 29, 2010, at 10:42 AM, Henrik Johansen wrote:

> 
> On Jul 29, 2010, at 9:23 54AM, Philippe Marschall wrote:
> 
>> On 07/28/2010 10:48 PM, Alexandre Bergel wrote:
 I'd even suggest the system to reject names and selectors not in ASCII.
>>> 
>>> I agree for what has to be put in PharoCore and Pharo. However, a user 
>>> lambda must be able to create a class called MaClassePréférée if he/she 
>>> wishes. Every beginner do this...
>> 
>> Are you sure all your subsystems (changesets, fileouts, changes file,
>> Monticello, ...) are Unicode aware? Do you use Unicode normalization? If
>> so which one?
>> 
>> Cheers
>> Philippe
> 
> +1.
> Venture outside the ascii-range, and you are asking for trouble when storing 
> code externally.
> AFAIK, only the .sources / .changes *supposedly* uses utf8 natively. 
> Heck, MultiByteFileStream>>setConverterForCode uses MacRoman unless you've 
> written the utf8 BOM-marker ... 
> Use MultiByteBinaryOrTextStream>>setEncoderForSourceCodeNamed: , and it WILL 
> use MacRoman for .cs or .st files no matter what the streams contents are 
> (thankfully, there are no senders in the core image, at least) 
> Which is weird to me, since ByteString encoding is assumed to be 8859-1, and 
> the default fonts displays 8859-15 characters :) 
> Change any of this however, and you will surely break some old filed-out code.
> 
> TLDR; 
> There is no overall strategy for ensuring that code will be saved externally 
> in a unicode-compatible encoding, and it's probably impossible to implement 
> one while maintaining backwards-compatability. 
> If you want to stay safe, use only ASCII. 
> If you plan to never export any code (say, use changesets or Monticello), 
> write in whatever language you want. (well, as long as you are able to input 
> the characters of course)
> 
> Cheers,
> Henry 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] how do I turn off "smart" quotes in Pharo Seaside one-click image

[Nick Ager]

>
> >  Name: ECompletion-lr.127
> >  Author: lr
> >  Time: 31 July 2010, 7:21:25 pm
> >  UUID: 42e3e807-2478-4dda-b207-acf162648cfe
> >  Ancestors: ECompletion-lr.126
> >
> >  - rewrote the complete smart character logic (very ugly)
> >
> > Now this is really ugly and long code and there are literally dozens
> > of cases to handle. Let me know if it works better for you? I kind of
> > like it. The behavior for smart characters and the backspace is now
> > entirely different if there is a selection or if you are just typing
>
> sound exciting


Hi Lukas,

I noticed you've just added  ECompletion-lr.128. I've briefly tried it.
Perhaps I'm missing something, as the functionality seem to be the
same as ECompletion-lr.125,
so if you type an extra ' at the end of a string, it inserts another two.
Is there something else I need to update?

Nick
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Autotest, proof-of-concept [was: About TDD and Pharo]

[Stéphane Ducasse]

yes!

On Jul 29, 2010, at 10:51 AM, Dennis Schetinin wrote:

> 
> 
> 2010/7/26 Alexandre Bergel 
> Ideally, we should not tag long tests. The system should be smart enough to 
> characterize a test as long. If it takes more than 200ms, then it is long. 
> Autotest should then offer me to include long test or not in the automatic 
> test execution.
> 
> Using tags means that I have to go over each method test and tag them. This 
> is a costly effort that is likely to not work in practice.
> 
> 
> Why not split the task: make SUnit support tags (which is obviously useful 
> for so many applications) and create some auto-tagging facilities?
> 
> 
> 
> -- 
> Dennis Schetinin
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Extending SUnit [was Re: Autotest, proof-of-concept [was: About TDD and Pharo]]

[Stéphane Ducasse]

This is a good convention.
I will apply to the SystemAnnouncement I enhanced slowly.

On Jul 29, 2010, at 7:42 PM, Henrik Sperre Johansen wrote:

> On 29.07.2010 17:45, Alexandre Bergel wrote:
>>> Wow ! Fast !.
>>> 
>>> That means it should be easy now to do a lot of exciting stuff. Show tests 
>>> progression, errors/failures as soon as they occur, log several things, 
>>> drink cocktails,  meet beautiful girls that's really cool.
>> I will be in winter time in 1 week time. We have to enjoy now
>> 
>> Alexandre
> Nice!
> Maybe it's just me, or could we not add Announcement to the end of every 
> Announcement subclass name though?
> Like with the window announcement, I like them better as verbs describing the 
> event, f.ex.
> someAnnouncer on: TestStarted do: []
> someAnnouncer on: TestEnded send: #x to: y
> 
> Cheers,
> Henry
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Pharo-users] Couple of newbie questions

[Mariano Martinez Peck]

G I know you were going to bother with that ;)   I couldn't scape
jahahaha

ok...here it is:  http://book.pharo-project.org/book/FAQ/

BUT I HATE MY STYLE. I cannot put a nice CSS or display of the page. If
someone can help me, pleaseit is ugly.

In addition, I didn't add it to
http://www.pharo-project.org/documentation/faq

because I think they are different kinds of FAQ.

what do you think?

I still hope someone has time to migrate the techincal stufff from SCG to
the new book. It would be awesome.

http://scg.unibe.ch/wiki/faq/pharo

Cheers

Mariano



On Sat, Jul 31, 2010 at 6:35 PM, Stéphane Ducasse  wrote:

> mariano
>
> we should turn that into an FAQ and add it to the collabactive book?
>
> Stef
>
> On Jul 24, 2010, at 8:09 PM, Mariano Martinez Peck wrote:
>
> >
> >
> > On Sat, Jul 24, 2010 at 2:29 PM, Thomas Worthington <
> tho...@2worthingtons.net> wrote:
> > Hi everyone,
> >
> >
> > Hi and welcome!
> >
> > Two questions:
> >
> > 1) How do I get my Pharo 1.0 to "upgrade" to the 1.1 image?
> >
> >
> > The system update is disabled in purpose. The Pharo image cannot be
> updated anymore. Only PharoCore images can be updated. So..what you have to
> do is to just download a Pharo 1.1 image :)
> >
> > If you are curious why updates were disable, read:
> http://forum.world.st/update-1-1-11371-tp2229126p2231195.html
> >
> > Just FYI the latest 1.1 release is here:
> https://gforge.inria.fr/frs/download.php/27254/Pharo-1.1-11409-rc4dev10.07.2.zip
> >
> > as you can see in http://www.pharo-project.org/pharo-download
> >
> > 2) How do I make a "one-click" image that will start my app when clicked?
> >
> >
> > Very easy. Two options:
> >
> > - Take your new image (both .image and .changes), put exactly the same
> file names, and override the original files that can be found in
> /Contents/Resources . I think they are named Pharo-1.0.image and
> Pharo-1.0.changes
> >
> > - This option is the proper one. It depends on the OS you are using. If
> you are in Linux, just edit the Pharo.sh file so that it points to your new
> image (where it says "$RES/Pharo-1.0.image"). If you are in Windows, edit
> the Pharo.ini file where it says
> "ImageFile=Contents\Resources\Pharo-1.0.image".
> >
> > Sorry if these are FAQs, but I couldn't find answers via Google.
> >
> >
> > We should add it to FAQ or book.
> >
> > Where you aware of http://book.pharo-project.org/  and
> http://pharobyexample.org/   ?
> >
> > Cheers
> >
> > Mariano
> >
> > TW
> >
> > ___
> > Pharo-users mailing list
> > pharo-us...@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
> >
> > ___
> > Pharo-users mailing list
> > pharo-us...@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>
>
> ___
> Pharo-users mailing list
> pharo-us...@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] how do I turn off "smart" quotes in Pharo Seaside one-click image

[Lukas Renggli]

Please try again ECompletion-lr.128. I further simplified the code.
Now it is exactly the behavior of TextMate. And almost the same as
Eclipse.

Lukas

2010/7/31 Nick Ager :
>> >  Name: ECompletion-lr.127
>> >  Author: lr
>> >  Time: 31 July 2010, 7:21:25 pm
>> >  UUID: 42e3e807-2478-4dda-b207-acf162648cfe
>> >  Ancestors: ECompletion-lr.126
>> >
>> >  - rewrote the complete smart character logic (very ugly)
>> >
>> > Now this is really ugly and long code and there are literally dozens
>> > of cases to handle. Let me know if it works better for you? I kind of
>> > like it. The behavior for smart characters and the backspace is now
>> > entirely different if there is a selection or if you are just typing
>>
>> sound exciting
>
> Hi Lukas,
> I noticed you've just added  ECompletion-lr.128. I've briefly tried it.
> Perhaps I'm missing something, as the functionality seem to be the same
> as ECompletion-lr.125, so if you type an extra ' at the end of a string, it
> inserts another two.
> Is there something else I need to update?
> Nick
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



-- 
Lukas Renggli
www.lukas-renggli.ch

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] how do I turn off "smart" quotes in Pharo Seaside one-click image

[Lukas Renggli]

Ehh ECompletion-lr.129.

On 31 July 2010 22:11, Lukas Renggli  wrote:
> Please try again ECompletion-lr.128. I further simplified the code.
> Now it is exactly the behavior of TextMate. And almost the same as
> Eclipse.
>
> Lukas
>
> 2010/7/31 Nick Ager :
>>> >  Name: ECompletion-lr.127
>>> >  Author: lr
>>> >  Time: 31 July 2010, 7:21:25 pm
>>> >  UUID: 42e3e807-2478-4dda-b207-acf162648cfe
>>> >  Ancestors: ECompletion-lr.126
>>> >
>>> >  - rewrote the complete smart character logic (very ugly)
>>> >
>>> > Now this is really ugly and long code and there are literally dozens
>>> > of cases to handle. Let me know if it works better for you? I kind of
>>> > like it. The behavior for smart characters and the backspace is now
>>> > entirely different if there is a selection or if you are just typing
>>>
>>> sound exciting
>>
>> Hi Lukas,
>> I noticed you've just added  ECompletion-lr.128. I've briefly tried it.
>> Perhaps I'm missing something, as the functionality seem to be the same
>> as ECompletion-lr.125, so if you type an extra ' at the end of a string, it
>> inserts another two.
>> Is there something else I need to update?
>> Nick
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>



-- 
Lukas Renggli
www.lukas-renggli.ch

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] how do I turn off "smart" quotes in Pharo Seaside one-click image

[Lukas Renggli]

The latest also highlights the matching character.

On 31 July 2010 22:12, Lukas Renggli  wrote:
> Ehh ECompletion-lr.129.
>
> On 31 July 2010 22:11, Lukas Renggli  wrote:
>> Please try again ECompletion-lr.128. I further simplified the code.
>> Now it is exactly the behavior of TextMate. And almost the same as
>> Eclipse.
>>
>> Lukas
>>
>> 2010/7/31 Nick Ager :
 >  Name: ECompletion-lr.127
 >  Author: lr
 >  Time: 31 July 2010, 7:21:25 pm
 >  UUID: 42e3e807-2478-4dda-b207-acf162648cfe
 >  Ancestors: ECompletion-lr.126
 >
 >  - rewrote the complete smart character logic (very ugly)
 >
 > Now this is really ugly and long code and there are literally dozens
 > of cases to handle. Let me know if it works better for you? I kind of
 > like it. The behavior for smart characters and the backspace is now
 > entirely different if there is a selection or if you are just typing

 sound exciting
>>>
>>> Hi Lukas,
>>> I noticed you've just added  ECompletion-lr.128. I've briefly tried it.
>>> Perhaps I'm missing something, as the functionality seem to be the same
>>> as ECompletion-lr.125, so if you type an extra ' at the end of a string, it
>>> inserts another two.
>>> Is there something else I need to update?
>>> Nick
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>



-- 
Lukas Renggli
www.lukas-renggli.ch

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Limitation of number os literals in a method?

[nullPointer]

I´m looking for use of strings. That could be a solution...


"container"
container := CLPanel new.
Compiler new evaluate: 'container name: ''container''. 
container text: .
container usePolymorphStyleMechanism: true.
container balloonText: nil.
container enabled: true.
container location: 8...@10.
container extent: 6...@460.
container anchors: {false .false .false .false .}.
container imageResource: nil.
container style: {(BorderStyle width: 0 color: Color transparent) 
.(Color
r: 0.972 g: 0.972 b: 0.944) .(Color r: 0.972 g: 0.972 b: 0.944) .false
.false .}.
container minWidth: 2.
container minHeight: 2.
container layout: {ProportionalLayout .#rigid .#rigid .0 .#center 
.#none .0
.#topLeft .#topToBottom .#none .false .#topLeft .#none .0 .1073741823 .}.
container visible = false.
container openInWorld.' in: thisContext to: nil.


I did the probe and works.
-- 
View this message in context: 
http://forum.world.st/Limitation-of-number-os-literals-in-a-method-tp2308740p2309111.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] String, ByteString and WideString

[Andrey Larionov]

Working with WebClient i found what it lacks of non latin languages
support (for example Russian). During investigation i found, what for
streaming there used ByteString, which is custructed by calling String
class>>new:. All subclases of String by calling of this method
produces only ByteString instances. Also WriteStream>>contents
indirectly calls String class>>new:. So even you construct WideString
with #basicNew: calling
(WideString basicNew: size) writeStrem contents
produce only ByteString

Is this a bug or there some workaround?

Thanks.

-- 
Andrey Larionov

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] HTTP client library in Pharo?

[Andrey Larionov]

I found WebClient resonably helpful. And in Pharo1.1 WebClient loaded
with Metacello passes all tests green on Linux. In more recent version
some test related to WebSockets are failed.
I found WebClient lack of multi-domain cookie support and response
encoding problems, but working on it right now.

On Thu, Jul 29, 2010 at 20:06, Andrei Stebakov  wrote:
> I've been trying to find a library for Pharo/Squeak which would handle
> GET/POST requests with the ability to manage cookies and deal with
> https servers.
> The HTTPSocket that's included in Pharo doesn't have cookies support.
> I tried to find any library that handles cookies and there came up
> CurlPlugin and SWHTTPClient.
> SWHTTPClient page has a broken link to the source code
> (http://map.squeak.org/package/15f42ec1-e93e-4bcf-ab2b-6746ae9d413f).
> CurlPlugin package for Win32 that I found on the main project page
> fails most of the tests and can't retrieve any http data.
> I also found WebClient/WebServer library at
> http://www.squeaksource.com/@QY3MLGU4hU3c8qcE/2xQek_iM which also
> fails most tests after installation.
>
> I wonder what people in smalltalk community are using when they need
> to do some web scraping when they need to keep some session in
> cookies?
> What would be the best library to invest time into (I am very new to 
> Smalltalk)?
>
> Thank you,
> Andrei
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] More on autotest

[laurent laffont]

On Sat, Jul 31, 2010 at 1:56 PM, Alexandre Bergel wrote:

> Hi Laurent!
>
> One thing with autotest. When I compile a method, even though it is not
> covered by the tests, the tests are run again. This does not always make
> sense I feel since it slow down the way I code...
>

See AutotestFinder>>methodsFor: . When no senders/test/setup/teardown found,
it searches for tests which reference the class of the modifed method. That
means it will run all tests related to the class, which may not cover the
changed method.

I've done this because you can have testMethod calls methodA calls methodB.
If you modify methodB, there's no senders in tests. But I want to know if
it's covered by tests actually. Or I don't want senders in tests because
it's a private method.

So when I modify methodB, Autotest run all tests which reference its class.
In this case the "Hit count" info is really useful because it tells if the
method is covered by tests or not.

Is there another way to know if methodB is covered by tests or not ?


> For example, when I am defining a meta-model, then running the test each
> time I add some business method it makes sense. However, when I define a
> mondrian visualization, all #visualize have to be excluded by autotest.
>


Is #visualize a slow method or there's too much senders of #visualize ?   Is
excluding long tests as we talked earlier can resolve it ?

Can you send me your image and tell me which methods you change bother you ?
So I can "feel" the problem too.

Laurent




>
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project