Re: [Pharo-project] [update 1.1] #11243
Actually this is already fixed by the previous fix. Jorge and I are going to write some new tests. Lukas On 8 March 2010 14:50, Lukas Renggli reng...@gmail.com wrote: Erwann just noticed another kind of serious shadowing bug. The closure compiler allows to declare methods like the following: foo: self | super thisContext true false nil | ^ super := thisContext := true := false := nil := self These argument and temporary names should all be disallowed as all other Smalltalk compiler do (and also the pre closure one in Pharo did). Using the implicit variables as argument or temp names leads to absolutely unmaintainable code. Lukas On 5 March 2010 12:16, Lukas Renggli reng...@gmail.com wrote: The problem is that some ancestor versions disappeared, what makes it impossible to merge. We've manually integrated the delta into: Name: Tests-lr.79 Author: lr Time: 5 March 2010, 12:16:05 pm UUID: 99f8b58a-0923-4264-9ea6-58fec6cf4d18 Ancestors: Tests-MichaelRueger.78 - merged Jorges Code Lukas On 5 March 2010 11:25, Stéphane Ducasse stephane.duca...@inria.fr wrote: Jorge could you publish the tests for 1.1 because I could not find my way 11 conflicts for 1.1? Stef Hi Adrian, Sorry for the delay, too many things today. Ok, I added 17 test to Tests-Compiler which model the cases of shadowing, at least the ones I could come up with. I also modified the EncoderbindTemp: in order to make it a little bit more intention revealing. My changes are in: Compiler-JorgeRessia.144 Tests-JorgeRessia.46 Some comments: - In order to test the not interactive mode I had to mock the Transcript. I could not find a better solution, if anybody has a better one just let me know I'll change it. - There is a special case which is that when you are NOT in interactive mode if the shadowed variable is a temp then the syntax error is triggered as in interactive mode. This is the behavior implemented before I did the changes. Is that what we want? - I added this test to Tests-Compiler package, I would have preferred to add them to Compiler-Tests but there was nothing there. Cheers, Jorge On Thu, Mar 4, 2010 at 8:45 PM, Adrian Lienhard a...@netstyle.ch wrote: Hi Jorge, Just let me know when you think the code is ok for 1.0 or when you have something different that I should integrate. Thanks! Cheers, Adrian On Mar 4, 2010, at 09:37 , Jorge Ressia wrote: Hi Adrian, Yep, I have the same problem as you. My idea was to make it work as before without completely changing it. Basically because I did not have the test support to validate my changes. Anyhow, what I propose is to write a bunch of tests for every case that we know and then if new cases show up add them to the test suite. And then play with the code. I will work on that today, is that ok? For the explanation of what is going on is that now node can be an instance variable node, then the behavior that was there was not appropriate in the sense that instance variable nodes do not understand #scope. However, why this validation (node isTemp or: [requestor interactive]) was there in the first place is not that clear to me, but it's been there since 1999. I'll try to build the tests and come up with a better solution. Cheers, Jorge On Thu, Mar 4, 2010 at 9:14 AM, Adrian Lienhard a...@netstyle.ch wrote: Jorge, I looked at the code to integrate in 1.0. And I really have troubles understanding it (even after drawing a boolean table for the different combinations of or: ifTrue: and: ifFalse:). Is it correct that the warning is shown when node isTemp is false and requestor interactive is true? Is the comment still accurate? This is the code: When non-interactive raise the error only if its a duplicate (node isTemp or: [requestor interactive]) ifTrue:[ ((node isTemp) and: [node scope = 0] ) ifFalse: [^self notify:'Name is already defined' ]] Cheers, Adrian On Mar 3, 2010, at 20:47 , Stéphane Ducasse wrote: 11243 - - Issue 2102: Fix the fact that local temp can shadow silently instance var --- fixed Problem fixed: We cannot have twice the same block arg in a method [:each | each ...] [:each | each ...] THANKS jorge :) Do you like good bio beer? 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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.1] #11243
Here are 3 additional tests that verify that these reserved variables are not shadowed. Please integrate :-) Lukas On 8 March 2010 15:01, Lukas Renggli reng...@gmail.com wrote: Actually this is already fixed by the previous fix. Jorge and I are going to write some new tests. Lukas On 8 March 2010 14:50, Lukas Renggli reng...@gmail.com wrote: Erwann just noticed another kind of serious shadowing bug. The closure compiler allows to declare methods like the following: foo: self | super thisContext true false nil | ^ super := thisContext := true := false := nil := self These argument and temporary names should all be disallowed as all other Smalltalk compiler do (and also the pre closure one in Pharo did). Using the implicit variables as argument or temp names leads to absolutely unmaintainable code. Lukas On 5 March 2010 12:16, Lukas Renggli reng...@gmail.com wrote: The problem is that some ancestor versions disappeared, what makes it impossible to merge. We've manually integrated the delta into: Name: Tests-lr.79 Author: lr Time: 5 March 2010, 12:16:05 pm UUID: 99f8b58a-0923-4264-9ea6-58fec6cf4d18 Ancestors: Tests-MichaelRueger.78 - merged Jorges Code Lukas On 5 March 2010 11:25, Stéphane Ducasse stephane.duca...@inria.fr wrote: Jorge could you publish the tests for 1.1 because I could not find my way 11 conflicts for 1.1? Stef Hi Adrian, Sorry for the delay, too many things today. Ok, I added 17 test to Tests-Compiler which model the cases of shadowing, at least the ones I could come up with. I also modified the EncoderbindTemp: in order to make it a little bit more intention revealing. My changes are in: Compiler-JorgeRessia.144 Tests-JorgeRessia.46 Some comments: - In order to test the not interactive mode I had to mock the Transcript. I could not find a better solution, if anybody has a better one just let me know I'll change it. - There is a special case which is that when you are NOT in interactive mode if the shadowed variable is a temp then the syntax error is triggered as in interactive mode. This is the behavior implemented before I did the changes. Is that what we want? - I added this test to Tests-Compiler package, I would have preferred to add them to Compiler-Tests but there was nothing there. Cheers, Jorge On Thu, Mar 4, 2010 at 8:45 PM, Adrian Lienhard a...@netstyle.ch wrote: Hi Jorge, Just let me know when you think the code is ok for 1.0 or when you have something different that I should integrate. Thanks! Cheers, Adrian On Mar 4, 2010, at 09:37 , Jorge Ressia wrote: Hi Adrian, Yep, I have the same problem as you. My idea was to make it work as before without completely changing it. Basically because I did not have the test support to validate my changes. Anyhow, what I propose is to write a bunch of tests for every case that we know and then if new cases show up add them to the test suite. And then play with the code. I will work on that today, is that ok? For the explanation of what is going on is that now node can be an instance variable node, then the behavior that was there was not appropriate in the sense that instance variable nodes do not understand #scope. However, why this validation (node isTemp or: [requestor interactive]) was there in the first place is not that clear to me, but it's been there since 1999. I'll try to build the tests and come up with a better solution. Cheers, Jorge On Thu, Mar 4, 2010 at 9:14 AM, Adrian Lienhard a...@netstyle.ch wrote: Jorge, I looked at the code to integrate in 1.0. And I really have troubles understanding it (even after drawing a boolean table for the different combinations of or: ifTrue: and: ifFalse:). Is it correct that the warning is shown when node isTemp is false and requestor interactive is true? Is the comment still accurate? This is the code: When non-interactive raise the error only if its a duplicate (node isTemp or: [requestor interactive]) ifTrue:[ ((node isTemp) and: [node scope = 0] ) ifFalse: [^self notify:'Name is already defined' ]] Cheers, Adrian On Mar 3, 2010, at 20:47 , Stéphane Ducasse wrote: 11243 - - Issue 2102: Fix the fact that local temp can shadow silently instance var --- fixed Problem fixed: We cannot have twice the same block arg in a method [:each | each ...] [:each | each ...] THANKS jorge :) Do you like good bio beer? 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] [squeak-dev] Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
Yanni == Yanni Chiu ya...@rogers.com writes: Yanni GLORP is LGPL, with a subsequently added explanation of how the the Yanni license should be interpreted in a Smalltalk context. INAL, but this Yanni still seems muddy, since it's unclear whether or not the author's Yanni interpretation and intentions would override the actual license, which Yanni is LGPL. Or, is it the case that the actual license is LGPL + author Yanni addendums - gah, another license mess. And I believe some heavyweights (with actual lawyers they paid) have already weighed in that the LGPL is equivalent to the *GPL* in a Smalltalk context, so unless the code is explicitly dual-licensed with a more permissive license as well, it taints the entire distro. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 mer...@stonehenge.com URL: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
[Pharo-project] about the hudson server
Hi yanni I wanted to know if you can tell us what means (unstable) in the report summary http://hudson.jooshr.org/job/Pharo1.1/81/ is it because the tests cannot run? 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] [squeak-dev] Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
Randal == Randal L Schwartz mer...@stonehenge.com writes: Randal And I believe some heavyweights (with actual lawyers they paid) have Randal already weighed in that the LGPL is equivalent to the *GPL* in a Randal Smalltalk context, so unless the code is explicitly dual-licensed with Randal a more permissive license as well, it taints the entire distro. Here's the reference: http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-January/124027.html -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 mer...@stonehenge.com URL: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] [update 1.1] #11243
Erwann just noticed another kind of serious shadowing bug. The closure compiler allows to declare methods like the following: foo: self | super thisContext true false nil | ^ super := thisContext := true := false := nil := self These argument and temporary names should all be disallowed as all other Smalltalk compiler do (and also the pre closure one in Pharo did). Using the implicit variables as argument or temp names leads to absolutely unmaintainable code. Lukas On 5 March 2010 12:16, Lukas Renggli reng...@gmail.com wrote: The problem is that some ancestor versions disappeared, what makes it impossible to merge. We've manually integrated the delta into: Name: Tests-lr.79 Author: lr Time: 5 March 2010, 12:16:05 pm UUID: 99f8b58a-0923-4264-9ea6-58fec6cf4d18 Ancestors: Tests-MichaelRueger.78 - merged Jorges Code Lukas On 5 March 2010 11:25, Stéphane Ducasse stephane.duca...@inria.fr wrote: Jorge could you publish the tests for 1.1 because I could not find my way 11 conflicts for 1.1? Stef Hi Adrian, Sorry for the delay, too many things today. Ok, I added 17 test to Tests-Compiler which model the cases of shadowing, at least the ones I could come up with. I also modified the EncoderbindTemp: in order to make it a little bit more intention revealing. My changes are in: Compiler-JorgeRessia.144 Tests-JorgeRessia.46 Some comments: - In order to test the not interactive mode I had to mock the Transcript. I could not find a better solution, if anybody has a better one just let me know I'll change it. - There is a special case which is that when you are NOT in interactive mode if the shadowed variable is a temp then the syntax error is triggered as in interactive mode. This is the behavior implemented before I did the changes. Is that what we want? - I added this test to Tests-Compiler package, I would have preferred to add them to Compiler-Tests but there was nothing there. Cheers, Jorge On Thu, Mar 4, 2010 at 8:45 PM, Adrian Lienhard a...@netstyle.ch wrote: Hi Jorge, Just let me know when you think the code is ok for 1.0 or when you have something different that I should integrate. Thanks! Cheers, Adrian On Mar 4, 2010, at 09:37 , Jorge Ressia wrote: Hi Adrian, Yep, I have the same problem as you. My idea was to make it work as before without completely changing it. Basically because I did not have the test support to validate my changes. Anyhow, what I propose is to write a bunch of tests for every case that we know and then if new cases show up add them to the test suite. And then play with the code. I will work on that today, is that ok? For the explanation of what is going on is that now node can be an instance variable node, then the behavior that was there was not appropriate in the sense that instance variable nodes do not understand #scope. However, why this validation (node isTemp or: [requestor interactive]) was there in the first place is not that clear to me, but it's been there since 1999. I'll try to build the tests and come up with a better solution. Cheers, Jorge On Thu, Mar 4, 2010 at 9:14 AM, Adrian Lienhard a...@netstyle.ch wrote: Jorge, I looked at the code to integrate in 1.0. And I really have troubles understanding it (even after drawing a boolean table for the different combinations of or: ifTrue: and: ifFalse:). Is it correct that the warning is shown when node isTemp is false and requestor interactive is true? Is the comment still accurate? This is the code: When non-interactive raise the error only if its a duplicate (node isTemp or: [requestor interactive]) ifTrue:[ ((node isTemp) and: [node scope = 0] ) ifFalse: [^self notify:'Name is already defined' ]] Cheers, Adrian On Mar 3, 2010, at 20:47 , Stéphane Ducasse wrote: 11243 - - Issue 2102: Fix the fact that local temp can shadow silently instance var --- fixed Problem fixed: We cannot have twice the same block arg in a method [:each | each ...] [:each | each ...] THANKS jorge :) Do you like good bio beer? 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 ___ 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] [update 1.1] #11243
Naturally in the Pharo Inbox: Name: Tests-lr.122 Author: lr Time: 8 March 2010, 3:12:26 pm UUID: faa9eb31-f84e-4e49-916e-991115a6f2da Ancestors: Tests-StephaneDucasse.121 - added tests for the compiler to test shadowing of self, super, thisContext, true, false and nil On 8 March 2010 15:13, Lukas Renggli reng...@gmail.com wrote: Here are 3 additional tests that verify that these reserved variables are not shadowed. Please integrate :-) Lukas On 8 March 2010 15:01, Lukas Renggli reng...@gmail.com wrote: Actually this is already fixed by the previous fix. Jorge and I are going to write some new tests. Lukas On 8 March 2010 14:50, Lukas Renggli reng...@gmail.com wrote: Erwann just noticed another kind of serious shadowing bug. The closure compiler allows to declare methods like the following: foo: self | super thisContext true false nil | ^ super := thisContext := true := false := nil := self These argument and temporary names should all be disallowed as all other Smalltalk compiler do (and also the pre closure one in Pharo did). Using the implicit variables as argument or temp names leads to absolutely unmaintainable code. Lukas On 5 March 2010 12:16, Lukas Renggli reng...@gmail.com wrote: The problem is that some ancestor versions disappeared, what makes it impossible to merge. We've manually integrated the delta into: Name: Tests-lr.79 Author: lr Time: 5 March 2010, 12:16:05 pm UUID: 99f8b58a-0923-4264-9ea6-58fec6cf4d18 Ancestors: Tests-MichaelRueger.78 - merged Jorges Code Lukas On 5 March 2010 11:25, Stéphane Ducasse stephane.duca...@inria.fr wrote: Jorge could you publish the tests for 1.1 because I could not find my way 11 conflicts for 1.1? Stef Hi Adrian, Sorry for the delay, too many things today. Ok, I added 17 test to Tests-Compiler which model the cases of shadowing, at least the ones I could come up with. I also modified the EncoderbindTemp: in order to make it a little bit more intention revealing. My changes are in: Compiler-JorgeRessia.144 Tests-JorgeRessia.46 Some comments: - In order to test the not interactive mode I had to mock the Transcript. I could not find a better solution, if anybody has a better one just let me know I'll change it. - There is a special case which is that when you are NOT in interactive mode if the shadowed variable is a temp then the syntax error is triggered as in interactive mode. This is the behavior implemented before I did the changes. Is that what we want? - I added this test to Tests-Compiler package, I would have preferred to add them to Compiler-Tests but there was nothing there. Cheers, Jorge On Thu, Mar 4, 2010 at 8:45 PM, Adrian Lienhard a...@netstyle.ch wrote: Hi Jorge, Just let me know when you think the code is ok for 1.0 or when you have something different that I should integrate. Thanks! Cheers, Adrian On Mar 4, 2010, at 09:37 , Jorge Ressia wrote: Hi Adrian, Yep, I have the same problem as you. My idea was to make it work as before without completely changing it. Basically because I did not have the test support to validate my changes. Anyhow, what I propose is to write a bunch of tests for every case that we know and then if new cases show up add them to the test suite. And then play with the code. I will work on that today, is that ok? For the explanation of what is going on is that now node can be an instance variable node, then the behavior that was there was not appropriate in the sense that instance variable nodes do not understand #scope. However, why this validation (node isTemp or: [requestor interactive]) was there in the first place is not that clear to me, but it's been there since 1999. I'll try to build the tests and come up with a better solution. Cheers, Jorge On Thu, Mar 4, 2010 at 9:14 AM, Adrian Lienhard a...@netstyle.ch wrote: Jorge, I looked at the code to integrate in 1.0. And I really have troubles understanding it (even after drawing a boolean table for the different combinations of or: ifTrue: and: ifFalse:). Is it correct that the warning is shown when node isTemp is false and requestor interactive is true? Is the comment still accurate? This is the code: When non-interactive raise the error only if its a duplicate (node isTemp or: [requestor interactive]) ifTrue:[ ((node isTemp) and: [node scope = 0] ) ifFalse: [^self notify:'Name is already defined' ]] Cheers, Adrian On Mar 3, 2010, at 20:47 , Stéphane Ducasse wrote: 11243 - - Issue 2102: Fix the fact that local temp can shadow silently instance var --- fixed Problem fixed: We cannot have twice the same block arg in a method [:each | each ...] [:each | each ...] THANKS jorge :) Do you like good bio beer? Stef ___ Pharo-project mailing list
Re: [Pharo-project] XML Parser / Pastell
Note that this email is sent to the Pharo mailing list. It is actually
more appropriate since the moose mailing list members are also part of
Pharo.
I have an update I will push in a day or two that extends namespace
support to attributes and also preserves the order of attributes.
Additionally, the tokenizer has been sped up somewhat. I have also
renamed some of the SAX handlers, but if you have a subclass that
implements them, they will still be invoked but with a warning that
they have been deprecated.
Using deprecation is good
I am going back on using Symbols to identify elements and
attributes. The performance of such a Symbol-based system is quite
erratic; running benchmark1 several times (at a much higher
interval), I repeatedly got results in the ~5800 to ~6200 range in a
clean image with XML-Support loaded into it from Monticello. Saving
the image and running it again, I got results in the range of ~4400
to ~4700. There seems to be a performance hit associated with using
symbols in this fashion that does not abate until you save the image
at least once. Even then my tests seem to indicate that a String-
based system would be slightly faster. This is probably due to the
initial overhead of interning Symbols and the subsequent overhead of
looking them up.
Really strange. What make you think it is related to Symbol?
Cheers,
Alexandre
On Thu, 04 Mar 2010 12:35:39 -0800 Alexandre Bergel alexan...@bergel.eu
wrote
Hi,
I exchanged a number of emails with Jaayer and Norbert regarding some
improvements of XMLSupport and its port to Gemstone.
It may be a bit difficult for people to follow this, but I think it
is
important to not discuss privately.
I already changed
XMLTokenizernextName
^ self fastStreamStringContents: nameBuffer
to
XMLTokenizernextName
^ (self fastStreamStringContents: nameBuffer) asSymbol
in the gemstone parser to be more consistent.
Have you noticed any slow down for this?
No I didn't do any tests. But if internally all names are symbols
than I guess converting it while reading is the best way to do.
I added benchmark1 in XMLParserTest. Really simple way to measure
progress (or slowdown).
On my machine, I have:
XMLParserTest new benchmark1
= 2097
Adding (self fastStreamStringContents: nameBuffer) asSymbol
increase the bench to 2273
I don't believe this ;) you read them as string from the stream. If
they are managed as symbols somehow they need to be converted. If
not at this place then on some other. I would suspect that there are
doubled calls to asSymbol. Could you check the sources?
There is indeed a slowdown. I am not sure where it comes from
however.
Executing twice XMLParserTest new benchmark1 does not return the
same result. Actually, it increases at each execution! I thought that
a garbage collect before running the bench would help, does
apparently
it does not.
Calling asSymbol on a symbol should not be perceptible I believe.
Cheers,
Alexandre
anElement attributes class (I wrote species but that will fail in
gemstone too I guess. Hell!)
I just committed with species. Let me know. This is easy to adjust.
Ok.
The gemstone XML Parser decides somehow to use
IdentityDictionary internally. I think this should be allowed. I
just changed Dictionary to IdentityDictionary so the = test
reflects the right type. If you change it it is clear that it
fails. Because pharo uses Dictionary internally. So you might
see that it is not a question of using Dictionary or
IdentityDictionary but a question of the wrongness of using =
How the XMLNodeTest should look like to accommodate your
situation?
I need to recheck this. The problem is really that the XML Parser
creatios instances of class Association but { #key-'value' }
creates an instance of class SymbolAssociation. That means I would
know how to fix the test but I want to understand the implications
of all of this. I'll get to you if I know anything new.
Ok.
My mail to the gemstone list led to a ticket about removing class
checks from Association. That would be easing the handling a lot.
Norbert
Alexandre
Here there is an assumption about the allAttributes collection
while using = as comparsion. But there is also an assumption
about the order of the content. I changed this to
self assert: (firstPerson allAttributes includesAllOf:
#(#'first-name' #'employee-number' #'family-name')).
self assert: (firstPerson allAttributeAssociations asArray
includesAllOf: {(#'first-name'-'Bob'). (#'employee-number'-
'A'). (#'family-name'-'Gates')}).
Very right. My mistake. But wouldn't an asSortedCollection do
the thing? Do you not test the size of the array.
This is not the best way to do because the check is only in
one direction but for this test it is ok. Somehow the second
assert fails and I have to check what is going on here.
Yeah, my mistake. Sorry. The elements may be differently
ordered. Would a asSortedCollection
Re: [Pharo-project] [update 1.1] #11243
Thanks. Apparently the mailing-list is working again. Stef On Mar 8, 2010, at 3:13 PM, Lukas Renggli wrote: Here are 3 additional tests that verify that these reserved variables are not shadowed. Please integrate :-) Lukas On 8 March 2010 15:01, Lukas Renggli reng...@gmail.com wrote: Actually this is already fixed by the previous fix. Jorge and I are going to write some new tests. Lukas On 8 March 2010 14:50, Lukas Renggli reng...@gmail.com wrote: Erwann just noticed another kind of serious shadowing bug. The closure compiler allows to declare methods like the following: foo: self | super thisContext true false nil | ^ super := thisContext := true := false := nil := self These argument and temporary names should all be disallowed as all other Smalltalk compiler do (and also the pre closure one in Pharo did). Using the implicit variables as argument or temp names leads to absolutely unmaintainable code. Lukas On 5 March 2010 12:16, Lukas Renggli reng...@gmail.com wrote: The problem is that some ancestor versions disappeared, what makes it impossible to merge. We've manually integrated the delta into: Name: Tests-lr.79 Author: lr Time: 5 March 2010, 12:16:05 pm UUID: 99f8b58a-0923-4264-9ea6-58fec6cf4d18 Ancestors: Tests-MichaelRueger.78 - merged Jorges Code Lukas On 5 March 2010 11:25, Stéphane Ducasse stephane.duca...@inria.fr wrote: Jorge could you publish the tests for 1.1 because I could not find my way 11 conflicts for 1.1? Stef Hi Adrian, Sorry for the delay, too many things today. Ok, I added 17 test to Tests-Compiler which model the cases of shadowing, at least the ones I could come up with. I also modified the EncoderbindTemp: in order to make it a little bit more intention revealing. My changes are in: Compiler-JorgeRessia.144 Tests-JorgeRessia.46 Some comments: - In order to test the not interactive mode I had to mock the Transcript. I could not find a better solution, if anybody has a better one just let me know I'll change it. - There is a special case which is that when you are NOT in interactive mode if the shadowed variable is a temp then the syntax error is triggered as in interactive mode. This is the behavior implemented before I did the changes. Is that what we want? - I added this test to Tests-Compiler package, I would have preferred to add them to Compiler-Tests but there was nothing there. Cheers, Jorge On Thu, Mar 4, 2010 at 8:45 PM, Adrian Lienhard a...@netstyle.ch wrote: Hi Jorge, Just let me know when you think the code is ok for 1.0 or when you have something different that I should integrate. Thanks! Cheers, Adrian On Mar 4, 2010, at 09:37 , Jorge Ressia wrote: Hi Adrian, Yep, I have the same problem as you. My idea was to make it work as before without completely changing it. Basically because I did not have the test support to validate my changes. Anyhow, what I propose is to write a bunch of tests for every case that we know and then if new cases show up add them to the test suite. And then play with the code. I will work on that today, is that ok? For the explanation of what is going on is that now node can be an instance variable node, then the behavior that was there was not appropriate in the sense that instance variable nodes do not understand #scope. However, why this validation (node isTemp or: [requestor interactive]) was there in the first place is not that clear to me, but it's been there since 1999. I'll try to build the tests and come up with a better solution. Cheers, Jorge On Thu, Mar 4, 2010 at 9:14 AM, Adrian Lienhard a...@netstyle.ch wrote: Jorge, I looked at the code to integrate in 1.0. And I really have troubles understanding it (even after drawing a boolean table for the different combinations of or: ifTrue: and: ifFalse:). Is it correct that the warning is shown when node isTemp is false and requestor interactive is true? Is the comment still accurate? This is the code: When non-interactive raise the error only if its a duplicate (node isTemp or: [requestor interactive]) ifTrue:[ ((node isTemp) and: [node scope = 0] ) ifFalse: [^self notify:'Name is already defined' ]] Cheers, Adrian On Mar 3, 2010, at 20:47 , Stéphane Ducasse wrote: 11243 - - Issue 2102: Fix the fact that local temp can shadow silently instance var --- fixed Problem fixed: We cannot have twice the same block arg in a method [:each | each ...] [:each | each ...] THANKS jorge :) Do you like good bio beer? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project
[Pharo-project] Fwd: [squeak-dev] Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!
Thanks thanks thanks thanks for a refresh on that! Thanks! Stef On Mar 8, 2010, at 5:55 PM, Randal L. Schwartz wrote: Randal == Randal L Schwartz mer...@stonehenge.com writes: Randal And I believe some heavyweights (with actual lawyers they paid) have Randal already weighed in that the LGPL is equivalent to the *GPL* in a Randal Smalltalk context, so unless the code is explicitly dual-licensed with Randal a more permissive license as well, it taints the entire distro. Here's the reference: http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-January/124027.html -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 mer...@stonehenge.com URL: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
[Pharo-project] Fwd: [update 1.1] #11249
Begin forwarded message: From: stephane ducasse stephane.duca...@free.fr Date: March 6, 2010 11:30:09 PM GMT+01:00 To: Pharo Development Pharo-project@lists.gforge.inria.fr Subject: [update 1.1] #11249 11249 - - Issue 2114:Enhance SqNumberParser error handling inside Compiler. Tx nicolas - Issue 2116:Compiler sometimes return nil rather than diagnosing the problem. Tx nicolas - Issue 2118: 1) Let unicode leading Char be zero (only 2 methods). Arbitrarily solve the Russian/Nepalese environment conflict. -- SOMEONE HAS TO CHECK WHAT SHOULD THE POLICY BE... -- (I guess a non issue except for OLPC Etoys) 2) Prepare a TextStopConditions object for handling endOfRun/crossedX without breaking a macron. 3) After loading, you should execute: EncodedCharSets initialize. Thanks nicolas Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Fwd: [update 1.1] #11250
Begin forwarded message: From: Stéphane Ducasse stephane.duca...@inria.fr Date: March 7, 2010 1:34:57 PM GMT+01:00 To: Pharo Development Pharo-project@lists.gforge.inria.fr Subject: [update 1.1] #11250 11250 - - Issue 2121:Rewrite Binary Selectors Immeditely Followed By Negative Literal. rewrite all expressions of the form 1...@-2 to 1 @ -2, where @ is a binary selector and -2 an negative literal that will soon be parsed as 1 @- (2) (according to ANSI) Thanks lukas! Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Fwd: [update 1.1] #11251
Begin forwarded message: From: Stéphane Ducasse stephane.duca...@inria.fr Date: March 7, 2010 4:47:03 PM GMT+01:00 To: Pharo Development Pharo-project@lists.gforge.inria.fr Subject: [update 1.1] #11251 11251 - - Issue 2119: Complete ensure blocks. Tx Andreas - Issue 2118: Let Unicode leadingChar = 0 (part 2) Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Fwd: [update 1.1] #11244
Begin forwarded message: From: Stéphane Ducasse stephane.duca...@inria.fr Date: March 5, 2010 11:31:29 AM GMT+01:00 To: Pharo Development Pharo-project@lists.gforge.inria.fr Subject: [update 1.1] #11244 - remove the default password squeak in the MCHttpRepository creation template - Introduction of tests for validating the different use cases of Shadowing in CompilerTest. - Improvement in the EncoderbindTemp: method in order to make explicit the decisions Thanks Jorge and lukas :) ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Fwd: [update 1.1] #11252
Begin forwarded message: From: Stéphane Ducasse stephane.duca...@inria.fr Date: March 7, 2010 6:51:30 PM GMT+01:00 To: Pharo Development Pharo-project@lists.gforge.inria.fr Subject: [update 1.1] #11252 11252 - - Issue 2118: Let Unicode leadingChar = 0 Part 3: get rid of (stopConditions at: EndOfRun) (or CrossedX) Replace with a proper message (stopConditions endOfRun) (crossedX) Also: - Reduce the number of FreeType-overrides, move back to Graphics/Multilingual. I will republish FreeType later because I don t know if MC will not remove essential methods. - Do not test alignment == Justified ! Justified is a Number, alignment = Justified is just so cleaner. - Prepare TextStopConditions clean-up Soon final part ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Fwd: [update 1.1] #11253
Begin forwarded message: From: stephane ducasse stephane.duca...@free.fr Date: March 7, 2010 10:52:45 PM GMT+01:00 To: Pharo Development Pharo-project@lists.gforge.inria.fr Cc: nicolas cellier nicolas.cellier.aka.n...@gmail.com Subject: [update 1.1] #11253 11253 - - Issue 2118: Let Unicode leadingChar = 0 Part 4: + cleaning package. Please no space and funky characters in package name and no white space to start (JB) Stef ___ 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.1] #11254
11254 - - Issue 2115: Allow $- anywhere in binary selector ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Force the focus of a panel for start to listen keypress events.
Many many thanks; that has been very useful for me. Anyway I did decide change the mechanism for load and show data of my grid, on drawing place., and now works much much more fast. Really I have poor knowledge of different posibilities for do one thing, but I´m learning bit a bit. Now I will use that for my new grid widget. Regards -- View this message in context: http://n4.nabble.com/Conseils-for-develop-a-grid-tp1299737p1585128.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] Full time engineer position for Pharo looking for cool engineer :)
Hi guys Some good news :) INRIA-lille nord Europe ranked Pharo among the top 3 projects that will receive support for a full time confirmed engineer. We will know if the national level or the lab will carry the cost by mid april, but for now the position is allocated to Pharo. This is not the official job announce but just to give some hints and that you can prepare yourself to - move to France (one hour from paris, 1h30 from London, 35 min from Brussels) - try a lot of good beers (belgium :) - eat french food - have fun with us - yes we are even fun - ok with geeky humor :) - code all the day in Smalltalk and a bit of C Apparently from what the DHR services told me, the salary will depend on years of expertise and diplomas but we can think that 2700 Euros (before final taxes) should be a good working number -- In France the employer pays already taxes so the salary is not brutto but already includes deduction. The social insurance is included and you may want to pay an extra like me (100 Euros) to have a better health insurance. Lille is an active city but not expensive. To give an idea Marcus got a nice sunny close to everything flat with wooden floor for 650 Euros. The job will to continue making Pharo (core) better - better tools - better network support - helping with the new compiler - helping with alien and others - cleaning/shrinking Duration: 30 months Starting date: October 2010 Location: Lille (no remote job possible) Do not hesitate to contact us. Stef/Marcus Dr. Stéphane Ducasse -- Directeur de Recherche (Senior Researcher) INRIA - USTL - CNRS UMR 8022 stephane.duca...@inria.fr http://stephane.ducasse.free.fr http://rmod.lille.inria.fr/ **NEW ***Tel 00 33 (0)3 20 43 42 56 - Fax 33 3 59 57 78 50 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza, Villeneuve d'Ascq, FR-59650, France. if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth CalvinHobbes ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] 11254 Image available
Hi guys sorry for the fact that some of you could not update anymore due to a stupid name for package (we should check that : space ; / cannot be put in the package name. https://gforge.inria.fr/frs/download.php/26637/PharoCore-1.1-11254-UNSTABLE.1.zip Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Fwd: about Issue 2118: Let Unicode leadingChar = 0
Hi nicolas could you give us an executive summary of the reasoning behind this change? Does this implies that we get Unicode by default? and that Unicode is integrated in the table of language (replacing latin1), so this way we do not have to check all the time is it 255? Stef I like all these opportunities to learn things. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fwd: about Issue 2118: Let Unicode leadingChar = 0
Unicode Leading Char The default leading char is now 0 instead of 255 making Unicode - UTF conversions stable. See also discussion at http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-August/138915.html 2010/3/8 Stéphane Ducasse stephane.duca...@inria.fr: Hi nicolas could you give us an executive summary of the reasoning behind this change? Does this implies that we get Unicode by default? and that Unicode is integrated in the table of language (replacing latin1), so this way we do not have to check all the time is it 255? Stef I like all these opportunities to learn things. ___ 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 news about GSoC!!!
Hi folks. We have been working hard with Janko and we built a website for the GSoC 2010 and for future editions! The URL is http://gsoc2010.esug.org/ In 4 days, is the deadline to submit ESUG as mentoring organization. For that purpose, there are several questions that we need to answer, as you can read here: http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#org_app This is the most important step. If we get selected, then we have project, and we will have to vote which projects to select and finally select students...but all that is ONLY if we are selected as mentoring organization. Last year Squeak wasn't so this year will be hard. We really appreciate any feedback you can give us so that we can achieve this goal. Basically we should demonstrate that we have a big community, with several interesting projects and with mentors and students that are willing to do it. Our first version of those answer are here: http://gsoc2010.esug.org/application.html Please, send feedback. The ideas page is necessary. For this, it would be cool to have several projects. With this we can show that the community is big. Of course, we cannot put projects that has no sense. But don't be shy to submit. We are ALL smalltalk dialects and even Newspeak. Right now there are 13 projects but I think there can be much more. In squeak 2007 there were like 20, and now we are all dialects together. Note that a project doesn't need to be cross dialect. You can propose a project that apply only to one dialect. I cannot take the time to write each proposal...so, if you have a project, right the title, description, technical details, benefits to the student and benefits to the community. Otherwise will be probably ignored. It would be cool to have all mentors already selected for the 12th so that we can demonstrate that we are really willing to do it and that we already have mentors for all projects. Even more, it would be fantastic if there can be mentors or co-mentors. As you can see in the ideas link, there are ideas that are not even complete. No text. Again...if someone want to do it, excellent. Otherwise, they will have to be removed. Now...a personal question...do you think we have enough students to take care about the projects? what is your opinion ? That's all for the moment...please, if you have questions, just ASK!!! 4 days. 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] VM crash on Windows
Hello all, I am having a sudden problem with Pharo crashing on Windows - it's quitting on handling Seaside requests, and I'm getting **no** information. The VM pops up the output console, writes a lot of (probably useful) information to it, and then promptly exits. Is there any way to get it to log the output? So far, the things I have found online say that it will write a dump when it crashes, but it's not doing it. Bill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] VM crash on Windows
Hello all, Good news/bad news: I got it running again :) I have no idea what was wrong, nor what is right now :( A corrupt image file is not out of the question. I was having huge problems with Ubuntu (perhaps Linux in general??[*]) and cifs writing to windows shares. That problem suddenly went away some weeks ago, but maybe it is simply less frequent now?? Nearly the same image was running just fine on a sibling box, and copying the image from there to the offending machine got me going again. What bothers me here is not so much that Pharo crashed but that it did it so abruptly and without logging anything that I could find. Suggestions would be most welcome. I also wondered about the vm on the misbehaving box and tried to download a new one from the Pharo site - I have not been able to successfully download it but the alternate link appears to work. Bill [*] I was building up to trying Mandriva when I discovered things had radically improved on Ubuntu. Some writings on the net lead me to suspect that it might have been more than just Ubuntu users suffering, but I am simply not certain. -Original Message- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K Sent: Monday, March 08, 2010 7:27 PM To: Pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] VM crash on Windows Hello all, I am having a sudden problem with Pharo crashing on Windows - it's quitting on handling Seaside requests, and I'm getting **no** information. The VM pops up the output console, writes a lot of (probably useful) information to it, and then promptly exits. Is there any way to get it to log the output? So far, the things I have found online say that it will write a dump when it crashes, but it's not doing it. Bill ___ 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] VM crash on Windows
On Mon, Mar 08, 2010 at 07:47:16PM -0500, Schwab,Wilhelm K wrote: Hello all, Good news/bad news: I got it running again :) I have no idea what was wrong, nor what is right now :( A corrupt image file is not out of the question. I was having huge problems with Ubuntu (perhaps Linux in general??[*]) and cifs writing to windows shares. That problem suddenly went away some weeks ago, but maybe it is simply less frequent now?? Nearly the same image was running just fine on a sibling box, and copying the image from there to the offending machine got me going again. What bothers me here is not so much that Pharo crashed but that it did it so abruptly and without logging anything that I could find. Suggestions would be most welcome. Bill, Whatever is wrong, it is probably not the fault of the Pharo image. When the VM crashes abruptly with no log file generated, it is most likely because it encountered an access violation (segfault) error in some plugin or in an FFI call. If you get a hard failure like that, the image is not able to write the debug log file (because it is already dead - d'oh!). I think that various people have reported problems with virus scanners and that sort of thing on windows. And it is possible that running on network file systems (cifs etc) will expose bugs that do not show up when running on local file systems. I think you're going to be stuck doing some good old process of elimination work here :( Dave ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Full time engineer position for Pharo looking for cool engineer :)
Oh. Why i come in magic world of Smalltalk too late (have no necessary experience at the moment). It's job of my dream in very beautiful place with great colleagues :) Good luck with candidate searching. On Mon, Mar 8, 2010 at 23:36, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi guys Some good news :) INRIA-lille nord Europe ranked Pharo among the top 3 projects that will receive support for a full time confirmed engineer. We will know if the national level or the lab will carry the cost by mid april, but for now the position is allocated to Pharo. This is not the official job announce but just to give some hints and that you can prepare yourself to - move to France (one hour from paris, 1h30 from London, 35 min from Brussels) - try a lot of good beers (belgium :) - eat french food - have fun with us - yes we are even fun - ok with geeky humor :) - code all the day in Smalltalk and a bit of C Apparently from what the DHR services told me, the salary will depend on years of expertise and diplomas but we can think that 2700 Euros (before final taxes) should be a good working number -- In France the employer pays already taxes so the salary is not brutto but already includes deduction. The social insurance is included and you may want to pay an extra like me (100 Euros) to have a better health insurance. Lille is an active city but not expensive. To give an idea Marcus got a nice sunny close to everything flat with wooden floor for 650 Euros. The job will to continue making Pharo (core) better - better tools - better network support - helping with the new compiler - helping with alien and others - cleaning/shrinking Duration: 30 months Starting date: October 2010 Location: Lille (no remote job possible) Do not hesitate to contact us. Stef/Marcus Dr. Stéphane Ducasse -- Directeur de Recherche (Senior Researcher) INRIA - USTL - CNRS UMR 8022 stephane.duca...@inria.fr http://stephane.ducasse.free.fr http://rmod.lille.inria.fr/ **NEW ***Tel 00 33 (0)3 20 43 42 56 - Fax 33 3 59 57 78 50 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza, Villeneuve d'Ascq, FR-59650, France. if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth CalvinHobbes ___ 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] Fwd: about Issue 2118: Let Unicode leadingChar = 0
Thanks a lot I think that this is a good decision. Here is the mail of andreas mentioned by nicolas. Folks - I think it's time to do something about the leadingChar in Characters that has been on the TODO list for a while. I have been looking over this stuff for some time now, fixing things here and there and laying some of the ground work for the things to come. Here is the good news: Squeak doesn't need the leadingChar any longer. If you are running an updated trunk image you can run entirely without the leadingChar being used, and I've done this for about a week now with no ill side effects (disclaimer: I haven't been using very much of m17n support stuff so there may still be breakage but it means it won't explode in your face straightaway). If you would like to try yourself, all you need to do is to hack CharactersetValue: to say, e.g., value := newValue bitClear: 16r3FC0. and you're good (and won't ever see a leadingChar). However, the removal of the leading char could be used to do a couple of other things that I would like to discuss and solicit feedback in particular from the folks who care about the leadingChar. The main insight is that although we *can* run without the leadingChar, it doesn't mean we *have* to. As it stands, the leading char is used for two purposes: Character set selection (EncodedCharSet) and (parts of) language support. There is a significant amount of confusion between the two with Latin1/Latin2Environment subclasses of LanguageEnvironment (although these are character encodings not languagse). What I would propose to do here is to define that leadingChar = 0 which currently means Latin1 encoding, language neutral is being redefined to Unicode encoding, language neutral. What this does is that Character value: 353 and Unicode value: 353 become the same, if the environment is considered language neutral which by default it would be. All but the environment which care about the connotations of the language tag should be able to work with this definition without any change whatsovever. The only thing that changes is that the default LanguageEnvironment is Unicode based, using leadingChar=0, most of the subclasses go away (being replaced by the default LanguageEnvironment) and those that we care about, or need a transition plan (i.e., the CJK languages) we keep using the language tag for the time being. That means that *if* you set your language environment to be one of the CJK languages you get a language tag in your strings, but by default the language neutral environment will produce plain Unicode. Which should make the server/seaside/aida people a lot more happy when dealing with this stuff. For the CJK languages (or other languages requiring support that has been so far expressed via the languag tag) we can use this opportunity and phase the use of the language tag out in favor of using text attributes (which would have to be written first). The main advantage of the proposal is that the people who would like to use plain Unicode get to use it, and the people who care about the language tag and its consequences can still use that as well. How does that sound? Cheers, - Andreas On Mar 8, 2010, at 10:49 PM, Nicolas Cellier wrote: Unicode Leading Char The default leading char is now 0 instead of 255 making Unicode - UTF conversions stable. See also discussion at http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-August/138915.html 2010/3/8 Stéphane Ducasse stephane.duca...@inria.fr: Hi nicolas could you give us an executive summary of the reasoning behind this change? Does this implies that we get Unicode by default? and that Unicode is integrated in the table of language (replacing latin1), so this way we do not have to check all the time is it 255? Stef I like all these opportunities to learn things. ___ 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
