April 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Closure compiler

by StÃ©phane Ducasse

lukas do you want that we produce a backward compatibility layer so that old seaside code loads in pharo? Stef On Apr 8, 2009, at 12:20 PM, Lukas Renggli wrote: > I fixed it, try again. > > It was a bug in the loader of the builder. There is an exception > handler that tries to work around the variable capitalization errors > the Pharo compiler is (or was) throwing. I should work with the old > old-compiler, the old new-compiler, and the new old-compiler (closure > compiler) now. > > However keep in mind that a Seaside installed like this won't work > just like that for various reasons. For example #renderOn:, > #fixCallbackTemps and various other required methods are not > implemented in BlockClosure. > > Lukas > > On Wed, Apr 8, 2009 at 11:21 AM, Torsten Bergmann <astares(a)gmx.de> > wrote: >> FYI: loading seaside 2.9 alpha3 crashes in latest pharo #10269 in >> Parser/EncoderForV3PlusClosures with NonBooleanReceiver. >> >> To easily reproduce evaluate: >> >> (HTTPSocket httpGet: 'http://builder.seaside.st/?distribution=Seaside%202.9.0-alpha3&packages=all…') >> fileIn. >> >> Bye >> T. >> >> >> >> -- >> Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + >> Telefonanschluss fÃ¼r nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 8, 2009

Re: [Pharo-project] Fwd: Re: FFI in closure image/modifying block arguments

by StÃ©phane Ducasse

good! I should continue to recompile everything. stef On Apr 8, 2009, at 10:23 AM, Torsten Bergmann wrote: > Stephane wrote: >> we already fixed a lot of occurrences of arg assignments and >> we should be soon able to recompile the entire pharo image. > > Nice - and it looks like Andreas also fixed FFI in "FFI-Kernel-ar. > 9.mcz". > > Thanks! > > Bye > T. > -- > Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit > allen: http://www.gmx.net/de/go/multimessenger01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 8, 2009

Re: [Pharo-project] Fwd: Re: FFI in closure image/modifying block arguments

by StÃ©phane Ducasse

Yes this is why elliot added the preference so that you can load code doing assignment. On Apr 8, 2009, at 9:14 AM, Andreas Raab wrote: > StÃ©phane Ducasse wrote: >> block args in smalltalk are read-only > > For sure. But my point is that there is a lot more code out there > using block arg assignment than you might think. And it's one issue > to keep your own code clean, and a completely different one to force > other people to change theirs to your standards. Most of what you'll > get is complaints that "your system does't work, it doesn't even > load code that works fine in x, y, or z". Been there, done that > (underscore assignment in Croquet). It's a difficult road since you > loose potential users (people try, fail, and go away). But do > whatever you feel like. > > Cheers, > - Andreas > > >> On Apr 7, 2009, at 10:01 PM, Torsten Bergmann wrote: >>> I forwarded the mail from Andreas, since I think he is not >>> subscribed >>> to pharo list and his answer didnt appear on the the list archive. >>> >>> Many places - I agree. I had the problem while loading OB alpha >>> before >>> FFI since OB also had block arg assignment. But it was very easy to >>> fix. FFI could/should also be fixed. That's at least a start. >>> >>> However - the question left is if block arg assignment should be >>> allowed ... >>> >>> Bye >>> T. >>> >>> BTW: Andreas: would be good if you could subscribe to pharo list. If >>> you fear the traffic then just disable mail forwarding and use >>> the web archive to read. That's how I do it on all squeak related >>> lists and it works fine. >>> >>> >>> -------- Original-Nachricht -------- >>> Datum: Tue, 07 Apr 2009 07:06:41 -0700 >>> Von: Andreas Raab <XYZ(a)XYZ.de> >>> An: Torsten Bergmann <XYZ(a)XYZ.de> >>> CC: pharo-project(a)lists.gforge.inria.fr >>> Betreff: Re: FFI in closure image/modifying block arguments >>> >>> I think it is advisable to allow block arg assignment for the time >>> being. There is *lots* of code which uses it knowingly or >>> unknowingly >>> and unless you've fixed every single case you'll have these troubles >>> every step of the way. For laughs, just try to recompile all the >>> classes >>> in your image to see how far you get. >>> >>> Cheers, >>> - Andreas >>> >>> Torsten Bergmann wrote: >>>> FYI: with the new closure changes/image (Pharo0.1Core-10268cl.zip >>>> from [1]) >>>> it is not possible to store into block arguments: >>>> >>>> 1 to: 10 do: [:i | i := i + 1. Transcript show: i printString ] >>>> >>>> That makes the current version of FFI unloadable, due to >>>> the code in ExternalTypeClass>>initializeAtomicTypes >>>> >>>> Bye >>>> T. >>>> >>>> >>>> [1] https://gforge.inria.fr/frs/?group_id=1299 >>> >>> -- >>> Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit >>> allen: http://www.gmx.net/de/go/multimessenger01 >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >

April 8, 2009

Re: [Pharo-project] FontTest depends on curent styles

by Andrey Larionov

Thanks, Adrian. On Wed, Apr 8, 2009 at 10:58, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi Andrey, > > #DefaultTextStyle is a key in TextConstants. > You can find all usages of DefaultTextStyle if you search for its > senders (select it and ctrl-n). > > HTH, > Adrian > > On Apr 8, 2009, at 03:56 , Mariano Martinez Peck wrote: > >> On Tue, Apr 7, 2009 at 10:47 PM, Andrey Larionov >> <anlarionov(a)gmail.com>wrote: >> >>> Is symbol may contain a value? >>> >> >> As I understand it, the symbol is the value itself. Suppose you use >> #something. Everywhere in the image you use #something, you will be >> talking >> about the same symbol. They don't have a dynamic value as String. I >> mean, in >> String you set it a value. In symbols, they already are the value. >> They are >> literal. >> >> I don't know If I am being clear enough. >> >> Greetings, >> >> Mariano >> >> >>> >>> 2009/4/8 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>>> >>>> >>>> On Tue, Apr 7, 2009 at 9:21 PM, Andrey Larionov <anlarionov(a)gmail.com >>>> > >>>> wrote: >>>>> >>>>> Two test in FontTest assumes what TextStyle>>default will answer a >>>>> some Accuny font with some size. But if we override default font - >>>>> test will fail. I'll try to find solution and fix, but new vm and >>>>> image crashed during debuging. >>>>> I think solution will be to create corresponding TextStyle for >>>>> test. >>>>> >>>>> Also i'm a newbie and can some clarify what is DefaultTextStyle? It >>>>> not declared as instance or class variable. >>>> >>>> I am also a but newbie but I think that's a symbol Is it actually >>>> #DefaultTextStyle ? >>>> >>>> If true, yes, it would probably be a symbol. A symbol, as Squeak By >>> Example >>>> says is: >>>> >>>> " >>>> Symbols are like Strings, in that they contain a sequence of >>>> characters. >>>> Â Â However, unlike a string, a literal symbol is guaranteed to be >>> globally >>>> Â Â unique. There is only one Symbol object #Hello but there may be >>>> Â Â multiple String objects with the value 'Hello'. >>>> " >>>> >>>> See SBE for more documentation. >>>> >>>> However, if there is something that it is not a class neither a >>>> class >>>> variable, it can be a global variable. For example, do a expect it >>>> of >>>> Smalltalk. You may think Smalltalk is a class, but it doesn't. It is >>> global >>>> variable. Indeed it is an object of SystemDirectory. >>>> >>>> Cheers, >>>> >>>> Mariano >>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 8, 2009

Re: [Pharo-project] Closure compiler

by Lukas Renggli

I fixed it, try again. It was a bug in the loader of the builder. There is an exception handler that tries to work around the variable capitalization errors the Pharo compiler is (or was) throwing. I should work with the old old-compiler, the old new-compiler, and the new old-compiler (closure compiler) now. However keep in mind that a Seaside installed like this won't work just like that for various reasons. For example #renderOn:, #fixCallbackTemps and various other required methods are not implemented in BlockClosure. Lukas On Wed, Apr 8, 2009 at 11:21 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > FYI: loading seaside 2.9 alpha3 crashes in latest pharo #10269 in > Parser/EncoderForV3PlusClosures with NonBooleanReceiver. > > To easily reproduce evaluate: > > (HTTPSocket httpGet: 'http://builder.seaside.st/?distribution=Seaside%202.9.0-alpha3&packages=all…') > Â Â Â Â Â Â Â Â fileIn. > > Bye > T. > > > > -- > Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss fÃ¼r nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

April 8, 2009

[Pharo-project] Closure compiler

by Torsten Bergmann

FYI: loading seaside 2.9 alpha3 crashes in latest pharo #10269 in Parser/EncoderForV3PlusClosures with NonBooleanReceiver. To easily reproduce evaluate: (HTTPSocket httpGet: 'http://builder.seaside.st/?distribution=Seaside%202.9.0-alpha3&packages=all…') fileIn. Bye T. -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss fÃ¼r nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a

April 8, 2009

[Pharo-project] Fwd: Re: FFI in closure image/modifying block arguments

by Torsten Bergmann

Stephane wrote: >we already fixed a lot of occurrences of arg assignments and >we should be soon able to recompile the entire pharo image. Nice - and it looks like Andreas also fixed FFI in "FFI-Kernel-ar.9.mcz". Thanks! Bye T. -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

April 8, 2009

Re: [Pharo-project] FontTest depends on curent styles

by Adrian Lienhard

Hi Andrey, #DefaultTextStyle is a key in TextConstants. You can find all usages of DefaultTextStyle if you search for its senders (select it and ctrl-n). HTH, Adrian On Apr 8, 2009, at 03:56 , Mariano Martinez Peck wrote: > On Tue, Apr 7, 2009 at 10:47 PM, Andrey Larionov > <anlarionov(a)gmail.com>wrote: > >> Is symbol may contain a value? >> > > As I understand it, the symbol is the value itself. Suppose you use > #something. Everywhere in the image you use #something, you will be > talking > about the same symbol. They don't have a dynamic value as String. I > mean, in > String you set it a value. In symbols, they already are the value. > They are > literal. > > I don't know If I am being clear enough. > > Greetings, > > Mariano > > >> >> 2009/4/8 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>> >>> >>> On Tue, Apr 7, 2009 at 9:21 PM, Andrey Larionov <anlarionov(a)gmail.com >>> > >>> wrote: >>>> >>>> Two test in FontTest assumes what TextStyle>>default will answer a >>>> some Accuny font with some size. But if we override default font - >>>> test will fail. I'll try to find solution and fix, but new vm and >>>> image crashed during debuging. >>>> I think solution will be to create corresponding TextStyle for >>>> test. >>>> >>>> Also i'm a newbie and can some clarify what is DefaultTextStyle? It >>>> not declared as instance or class variable. >>> >>> I am also a but newbie but I think that's a symbol Is it actually >>> #DefaultTextStyle ? >>> >>> If true, yes, it would probably be a symbol. A symbol, as Squeak By >> Example >>> says is: >>> >>> " >>> Symbols are like Strings, in that they contain a sequence of >>> characters. >>> However, unlike a string, a literal symbol is guaranteed to be >> globally >>> unique. There is only one Symbol object #Hello but there may be >>> multiple String objects with the value 'Hello'. >>> " >>> >>> See SBE for more documentation. >>> >>> However, if there is something that it is not a class neither a >>> class >>> variable, it can be a global variable. For example, do a expect it >>> of >>> Smalltalk. You may think Smalltalk is a class, but it doesn't. It is >> global >>> variable. Indeed it is an object of SystemDirectory. >>> >>> Cheers, >>> >>> Mariano >>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 8, 2009

Re: [Pharo-project] FontTest depends on curent styles

by StÃ©phane Ducasse

A symbol is a unique string. Its value is itself. A symbol is not a variable which has a value. But a variable may contain a value. Have fun learning and do not hesitate asking questions. Stef On Apr 8, 2009, at 3:56 AM, Mariano Martinez Peck wrote: > > > On Tue, Apr 7, 2009 at 10:47 PM, Andrey Larionov > <anlarionov(a)gmail.com> wrote: > Is symbol may contain a value? > > As I understand it, the symbol is the value itself. Suppose you use > #something. Everywhere in the image you use #something, you will be > talking about the same symbol. They don't have a dynamic value as > String. I mean, in String you set it a value. In symbols, they > already are the value. They are literal. > > I don't know If I am being clear enough. > > Greetings, > > Mariano > > > 2009/4/8 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > > > > On Tue, Apr 7, 2009 at 9:21 PM, Andrey Larionov <anlarionov(a)gmail.com > > > > wrote: > >> > >> Two test in FontTest assumes what TextStyle>>default will answer a > >> some Accuny font with some size. But if we override default font - > >> test will fail. I'll try to find solution and fix, but new vm and > >> image crashed during debuging. > >> I think solution will be to create corresponding TextStyle for > test. > >> > >> Also i'm a newbie and can some clarify what is DefaultTextStyle? It > >> not declared as instance or class variable. > > > > I am also a but newbie but I think that's a symbol Is it actually > > #DefaultTextStyle ? > > > > If true, yes, it would probably be a symbol. A symbol, as Squeak > By Example > > says is: > > > > " > > Symbols are like Strings, in that they contain a sequence of > characters. > > However, unlike a string, a literal symbol is guaranteed to be > globally > > unique. There is only one Symbol object #Hello but there may be > > multiple String objects with the value 'Hello'. > > " > > > > See SBE for more documentation. > > > > However, if there is something that it is not a class neither a > class > > variable, it can be a global variable. For example, do a expect it > of > > Smalltalk. You may think Smalltalk is a class, but it doesn't. It > is global > > variable. Indeed it is an object of SystemDirectory. > > > > Cheers, > > > > Mariano > > > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 8, 2009

Re: [Pharo-project] Fwd: Re: FFI in closure image/modifying block arguments

by StÃ©phane Ducasse

Torsten just for the record, we already fixed a lot of occurrences of arg assignments and we should be soon able to recompile the entire pharo image. Stef On Apr 7, 2009, at 10:01 PM, Torsten Bergmann wrote: > I forwarded the mail from Andreas, since I think he is not subscribed > to pharo list and his answer didnt appear on the the list archive. > > Many places - I agree. I had the problem while loading OB alpha before > FFI since OB also had block arg assignment. But it was very easy to > fix. FFI could/should also be fixed. That's at least a start. > > However - the question left is if block arg assignment should be > allowed ... > > Bye > T. > > BTW: Andreas: would be good if you could subscribe to pharo list. If > you fear the traffic then just disable mail forwarding and use > the web archive to read. That's how I do it on all squeak related > lists and it works fine. > > > -------- Original-Nachricht -------- > Datum: Tue, 07 Apr 2009 07:06:41 -0700 > Von: Andreas Raab <XYZ(a)XYZ.de> > An: Torsten Bergmann <XYZ(a)XYZ.de> > CC: pharo-project(a)lists.gforge.inria.fr > Betreff: Re: FFI in closure image/modifying block arguments > > I think it is advisable to allow block arg assignment for the time > being. There is *lots* of code which uses it knowingly or unknowingly > and unless you've fixed every single case you'll have these troubles > every step of the way. For laughs, just try to recompile all the > classes > in your image to see how far you get. > > Cheers, > - Andreas > > Torsten Bergmann wrote: >> FYI: with the new closure changes/image (Pharo0.1Core-10268cl.zip >> from [1]) >> it is not possible to store into block arguments: >> >> 1 to: 10 do: [:i | i := i + 1. Transcript show: i printString ] >> >> That makes the current version of FFI unloadable, due to >> the code in ExternalTypeClass>>initializeAtomicTypes >> >> Bye >> T. >> >> >> [1] https://gforge.inria.fr/frs/?group_id=1299 > > -- > Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit > allen: http://www.gmx.net/de/go/multimessenger01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 8, 2009