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

Re: [Pharo-project] Symbol>>value:value:

by StÃ©phane Ducasse

I would be in favor of having value: value: on symbol and get rid of value on Object Because this is really cool to write #( 1 2 3) collect: #abs On May 20, 2009, at 4:01 PM, Tudor Girba wrote: > Hi, > > (I apologize for the length of this email, but I did not know how to > write it shorter) > > My reasons for Symbol>>value: and similar selectors are as follows. > > A Symbol is already used for several things, like a key in an identity > dictionary. But it is also used for parameterizing a mapping to a > piece of behavior via a #symbol stored in a selector instance > variable. Later on, this behavior is invoked as: > > receiver perform: selector. > > This is for example what happens in Morphic, and as a result I am > forced to create a Model class for a custom Morph, even if the > customization is minimal. This is a hurdle when you are in prototype > mode. Instead I would like to have the possibility to prototype faster > using blocks instead of creating a class. > > This is possible right now for unary methods when the framework does > not directly do a perform:, but instead it does: > > selector value: receiver. > > Ideally, we could have in the entire image only one place in which > perform: is called explicitly: in the Symbol>>value:. In this way, I > will be able to pass a block everywhere a unary method is now used. > This is something we do when we want to use Smalltalk for scripting > (Mondrian and Glamour do that) > > The same case goes for Symbol>>value:value: . These two methods would > already cover the large majority of performs, but I would argue for > adding all possibilities of evaluating blocks and of performing > messages. > > If you are asking what do Symbol have to do with blocks from a > conceptual point of view, I will answer that when the Symbol is used > as a selector, it does nothing else but point to a piece of behavior. > Given that a Block does a similar thing, you can as well treat them in > a polymorphic fashion. > > The only question that remains in my mind is: does a modification like > this has the possibility of harming? I am not aware of a case in which > it is harmful, but who knows. > > Cheers, > Doru > > > On 20 May 2009, at 15:27, StÃ©phane Ducasse wrote: > >> value from Object and value: from Symbol are different >> with value: on Symbol you can do >> >> self collect: #abs >> >> :) >> >> On May 20, 2009, at 2:48 PM, Gabriel Cotelli wrote: >> >>> +1 to the removal of value: from Symbol.... >>> >>> On Wed, May 20, 2009 at 3:18 AM, Lukas Renggli <renggli(a)gmail.com> >>> wrote: >>>> Given that in Pharo we have Symbol>>value:, are there any reasons >>> not >>>> to have also >>>> >>>> Symbol>>value: anObject value: anotherObject >>>> ^ anObject perform: self with: anotherObject >>> >>> While Symbol>>#value: is at the border of being readable, >>> Symbol>>#value:value: is even worse. It is not immediately obvious >>> what it does. The order of receiver and arguments is hardcoded and >>> thus the construct cannot be applied in most cases without rewriting >>> the code. Fixed arguments cannot be given. >>> >>> Instead of adding new #value: variants, we should rather try to >>> remove >>> Object>>#value which is a real nightmare ;-) >>> >>> Cheers, >>> Lukas >>> >>> -- >>> 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 >>> >>> _______________________________________________ >>> 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 > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of > problem understanding." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 21, 2009

Re: [Pharo-project] SGrid

by StÃ©phane Ducasse

what is SGrid? Porting from? Any effort in providing new cool widgets to pharo is really important. I can test but other than that my plate is full. Stef > Anyone willing to collaborate in porting and testing SGrid out there? > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 21, 2009

Re: [Pharo-project] PlotMorph

by StÃ©phane Ducasse

Thanks carlos Now the question: - did you sign the license agreement? Please do. - do you know if there is a project for PlotMorph? Stef On May 21, 2009, at 6:09 AM, Carlos Crosetti wrote: > Fixed to run from Pharo. Attached, regards, Carlos<Plot- > Morph.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 21, 2009

Re: [Pharo-project] ThirtyTwoBitRegister methods removed

by StÃ©phane Ducasse

If you need them for glorp copy them from Squeak and publish a new package version working for Glorp in PharoInbox I will push it in pharo On May 21, 2009, at 3:07 AM, Mariano Martinez Peck wrote: > I searched in Monticello for the package System-Digital Signatures > and in the Pharo repository I only see two commits and even in the > first one, these two methods are not there. But, they are in Squeak. > So, know I guess where this commit should be? where I can search ? > > Thanks! > > Mariano > > On Mon, May 18, 2009 at 9:27 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > > wrote: > Hi folks. I noticed that this two methods were removed from > ThirtyTwoBitRegister: > > asByteArray > ^ ByteArray with: (low bitAnd: 16rFF) with: (low bitShift: > -8) with: (hi bitAnd: 16rFF) with: (hi bitShift: -8) > > > > reverseLoadFrom: aByteArray at: index > "Load my 32-bit value from the four bytes of the given > ByteArraystarting at the given index. Consider the first byte to > contain the mostsignificant bits of the word (i.e., use big-endian > byte ordering)." > > hi := ((aByteArray at: index + 3) bitShift: 8) + > ( aByteArray at: index + 2). > low := ((aByteArray at: index + 1) bitShift: 8) + > ( aByteArray at: index). > > > > I need them for Glorp. I looked but I didn't found a similar message > for them. I don't think adding them as an extension is a good > solution here since this seems to be very "internal". is there a > reason of the removing? If not, could them be added again? If there > are reason, which should be the best approach to fix this in mi case? > > I have no problem in commit them if you want. > > Thanks! > > Mariano > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 21, 2009

Re: [Pharo-project] Error when trying to create a package

by StÃ©phane Ducasse

> > I added that ability to Installer ages ago. Installer cache > install: 'Morphic'. Ok I was not aware of that. > > > Or you want it to search the cache without changing the script? > hmm. good idea. I'll make that work Yeap :) something like Installer install: 'Morphic' and a default to not use the cache to do a real reload Installer ignoreCache install: .... Stef

May 21, 2009

Re: [Pharo-project] Win32Setup - custom VM and app tutorial

by Janko MivÅ¡ek

Hi Torsten, I just tried it and I'd really like to thank for moving Smalltalk much closer to usually spoiled Windows user, who won't even touch anything without such installation as you provided. Big step forward in usability terms, really! Now just Pharo needs to be less scary when first opened by such user. Because now it is scary. It was even for me - after such easy and normal installation you end up with some blank screen with just those cryptic references open. Hmm, what to do now? So, there is at least some short text needed to encourage user to explore further, at least a reference to Squeak by example book. And how to open a Class browser ... Best regards Janko Torsten Bergmann pravi: > there is now a ready made setup for installing pharo on windows. > > http://gforge.inria.fr/frs/download.php/22307/setup_pharo_0.0.0.1.exe > > It is available in the Win32 Setup section on > http://gforge.inria.fr/frs/?group_id=1299 > > Far from perfect, but working. Use at your own risk! -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

May 21, 2009

[Pharo-project] SGrid

by Carlos Crosetti

Anyone willing to collaborate in porting and testing SGrid out there?

May 21, 2009

[Pharo-project] PlotMorph

by Carlos Crosetti

Fixed to run from Pharo. Attached, regards, Carlos

May 21, 2009

[Pharo-project] FW: [OT] RIS vs. BibTeX

by Schwab,Wilhelm K

Damien, Any thoughts on this? Bibus is looking less and less like a short-term solution to my needs, so I'd like to get Citezen loaded and see what it can do. Thanks, Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K Sent: Saturday, May 16, 2009 9:55 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [OT] RIS vs. BibTeX Damien, It was running along fine and then hit a walkback in RioLocalExecutive class>>initialize. Does not like Current initializeDefault (DNU). Any ideas? That looks like missing steps to me, so it might not be something I can "just fix". Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Damien Pollet Sent: Saturday, May 16, 2009 8:48 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [OT] RIS vs. BibTeX On Sat, May 16, 2009 at 12:12, Damien Pollet <damien.pollet(a)gmail.com> wrote: >> After with enough pressure I'm sure that he can do a CitezenLoader >> class :) > > That could indeed be helpful :) Actually there is one already, and it seems to work. See the wiki tab of http://www.squeaksource.com/Citezen.html -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet _______________________________________________ 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

May 21, 2009

Re: [Pharo-project] ThirtyTwoBitRegister methods removed

by Mariano Martinez Peck

I searched in Monticello for the package System-Digital Signatures and in the Pharo repository I only see two commits and even in the first one, these two methods are not there. But, they are in Squeak. So, know I guess where this commit should be? where I can search ? Thanks! Mariano On Mon, May 18, 2009 at 9:27 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi folks. I noticed that this two methods were removed from > ThirtyTwoBitRegister: > > asByteArray > ^ ByteArray with: (low bitAnd: 16rFF) with: (low bitShift: -8) with: > (hi bitAnd: 16rFF) with: (hi bitShift: -8) > > > > reverseLoadFrom: aByteArray at: index > "Load my 32-bit value from the four bytes of the given > ByteArraystarting at the given index. Consider the first byte to contain the > mostsignificant bits of the word (i.e., use big-endian byte ordering)." > > hi := ((aByteArray at: index + 3) bitShift: 8) + ( aByteArray at: > index + 2). > low := ((aByteArray at: index + 1) bitShift: 8) + ( aByteArray at: > index). > > > > I need them for Glorp. I looked but I didn't found a similar message for > them. I don't think adding them as an extension is a good solution here > since this seems to be very "internal". is there a reason of the removing? > If not, could them be added again? If there are reason, which should be the > best approach to fix this in mi case? > > I have no problem in commit them if you want. > > Thanks! > > Mariano > > > > > >

May 21, 2009