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 <[hidden email]> An: Torsten Bergmann <[hidden email]> CC: [hidden email] 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
> However - the question left is if block arg assignment should be
> allowed ... Eliot explained that it is a setting in the closure compiler. By default it shouldn't be allowed, as long as method arguments are also read-only. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Torsten Bergmann
block args in smalltalk are read-only
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 <[hidden email]> > An: Torsten Bergmann <[hidden email]> > CC: [hidden email] > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Torsten Bergmann
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 <[hidden email]> > An: Torsten Bergmann <[hidden email]> > CC: [hidden email] > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post 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 <[hidden email]> >>> An: Torsten Bergmann <[hidden email]> >>> CC: [hidden email] >>> 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |