July 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 2635 - methods recategorization

by StÃ©phane Ducasse

Hi Pavel where should I start? Because the changes you sent by emails are not in the same order than on the list? I was planning to start with the mail where you just uppercase the category? Stef On Jul 6, 2010, at 4:43 PM, Pavel Krivanek wrote: > Hi, > > I finished the list of changes for the issue > http://code.google.com/p/pharo/issues/detail?id=2635. > > This issue is the next step after already integrated packages > reorganization and the goal is to have compact package base a the > small headless PharoKernel image. > > Most changes are simple naming unification and some classes I skipped > because they need deeper refactorings. > > I will now check the list once more. > > -- Pavel > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 7, 2010

[Pharo-project] Monticello & proxy with security.

by Diogenes Moreira

hi folks. right now, i'm behind a squid proxy with security (user & pass).. in the preferences, I find the proxy configuration, but only have ip and port. Exists a way to set user and password in that connection??? Thanks in advance.

July 7, 2010

Re: [Pharo-project] should we move pharo to use webclient?

by StÃ©phane Ducasse

- Does it load? - what is teh package structure? - do the test work? - Check the interface - start to see how we can redirect the image code to be based on web - iterate on the last point. - remove/deprecate old code. Stef On Jul 7, 2010, at 1:02 PM, GermÃ¡n Arduino wrote: > If you (Stef/Sven) cand give some guidelines about what do you expect and how to integrate, I can help here also. > > Cheers. > GermÃ¡n. > > > 2010/7/7 Sven Van Caekenberghe <sven(a)beta9.be> > StÃ©f, > > I guess you mean integrating WebClient in 1.2, not 1.1 ? > I am willing to help here, but I am having a vacation starting tomorrow, I'll be back from June 19th. > I deliberately don't touch any computers during that time ;-) > > Sven > > On 06 Jul 2010, at 21:22, StÃ©phane Ducasse wrote: > > > I agree and this is why I asked. > > I'm not good in network but the code of network always made me nearly faint because it was clearly not designed. > > Now why interested people would not do a little task forces to bullet proof the integration and we prepare together > > its integration... > > remember pharo is also your smalltalk :) > > > > On Jul 6, 2010, at 3:04 PM, Sven Van Caekenberghe wrote: > > > >> Yes!! > >> > >> It now loads without patches into Pharo 1.1 rc2 > >> I used its client and server part, seaside adaptor, it all works. > >> > >> The code is quite readable/understandable/malleable. > >> > >> I did not yet test the WebClient-HTTP package which patches HTTPSocket to replace the old code, > >> which is obviously important (it then gets used by MC and the rest of Smalltalk). > >> > >> The unit tests also have to be double checked. > >> > >> What do others, like Lukas and other Seaside people think of it ? > >> > >> The basic point it: it can only be better than the older code. > >> But on the other hand, maybe the leap could be even bigger still ? > >> Having a facade for a pluggable http client is one step. > >> > >> Having a good basic HTTP client and server is very important. > >> > >> Sven > >> > >> On 06 Jul 2010, at 09:30, StÃ©phane Ducasse wrote: > >> > >>> to replace the old code? > >>> > >>> Stef > >>> > >>> _______________________________________________ > >>> 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 > > > > -- > ================================================= > GermÃ¡n S. Arduino <gsa @ arsol.net> Twitter: garduino > Arduino Software & Web Hosting http://www.arduinosoftware.com > PasswordsPro http://www.passwordspro.com > ================================================= > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 7, 2010

Re: [Pharo-project] should we move pharo to use webclient?

by StÃ©phane Ducasse

> StÃ©f, > > I guess you mean integrating WebClient in 1.2, not 1.1 ? Yes I'm always in the future :) > I am willing to help here, but I am having a vacation starting tomorrow, I'll be back from June 19th. > I deliberately don't touch any computers during that time ;-) Excellent! Stef > > Sven > > On 06 Jul 2010, at 21:22, StÃ©phane Ducasse wrote: > >> I agree and this is why I asked. >> I'm not good in network but the code of network always made me nearly faint because it was clearly not designed. >> Now why interested people would not do a little task forces to bullet proof the integration and we prepare together >> its integration... >> remember pharo is also your smalltalk :) >> >> On Jul 6, 2010, at 3:04 PM, Sven Van Caekenberghe wrote: >> >>> Yes!! >>> >>> It now loads without patches into Pharo 1.1 rc2 >>> I used its client and server part, seaside adaptor, it all works. >>> >>> The code is quite readable/understandable/malleable. >>> >>> I did not yet test the WebClient-HTTP package which patches HTTPSocket to replace the old code, >>> which is obviously important (it then gets used by MC and the rest of Smalltalk). >>> >>> The unit tests also have to be double checked. >>> >>> What do others, like Lukas and other Seaside people think of it ? >>> >>> The basic point it: it can only be better than the older code. >>> But on the other hand, maybe the leap could be even bigger still ? >>> Having a facade for a pluggable http client is one step. >>> >>> Having a good basic HTTP client and server is very important. >>> >>> Sven >>> >>> On 06 Jul 2010, at 09:30, StÃ©phane Ducasse wrote: >>> >>>> to replace the old code? >>>> >>>> Stef >>>> >>>> _______________________________________________ >>>> 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

July 7, 2010

[Pharo-project] why "maximize" does not fills all the window in 1.1?

by Esteban Lorenzano

Hi, I wonder why we rollback this change... maybe is stupid, but I liked the 1.0 behavior: when you hit maximize you fills the full world screen. Cheers, Esteban

July 7, 2010

Re: [Pharo-project] Fix the other dependencies of asContextWithSender:

by Juan Vuletich

Hi Eliot, There are several other changes in that package that could generate different behavior. Are they correct? They are: BlockClosure >> value used to call primitive 201, now calls 205 used to check for zero args, now checks for one (!?) BlockClosure >> value: used to call primitive 202, now calls 205 BlockClosure >> value:value: used to call primitive 203, now calls 205 BlockClosure >> value:value:value: used to call primitive 204, now calls 205 Primitive 205 was previously only used for #value:value:value:value:, so I wonder if this might be a mistake. Thanks, Juan Vuletich Eliot Miranda wrote: > > > On Tue, Jul 6, 2010 at 12:51 PM, stephane ducasse > <stephane.ducasse(a)free.fr <mailto:stephane.ducasse@free.fr>> wrote: > > Eliot > > should this fix be applied to pharo? > http://code.google.com/p/pharo/issues/detail?id=2655 > > > Yes please. Almost everything I'm likely to put in Compiler, Kernel > or System on Squeak 4.1 belongs in all dialects using the closure > compiler. > > > > Is there a dependency? > > > What's happing here is that very old primitive failure code that > allowed the closure system to run on old VMs without closure support > depended on BlockClosure>>asContext, which had a bug in it. So the > changes reflect the bug fix but are enclosed in false ifTrue: [] > because they really are obsolete, but the code is retained because its > useful documentation of how the closure primitives should work. I > hope this makes sense! > > best > Eliot > > > > Stef >

July 7, 2010

Re: [Pharo-project] Updating VM links for Pharo 1.1

by Adrian Lienhard

I'm a bit confused. Do we want to have a separate set of VMs or not? Furthermore, the link to the Unix VM just goes to http://squeakvm.org/unix/, but not to a particular version. Cheers, Adrian On Jul 7, 2010, at 14:09 , Mariano Martinez Peck wrote: > On Wed, Jul 7, 2010 at 11:33 AM, Serge Stinckwich < > serge.stinckwich(a)gmail.com> wrote: > >> 2010/7/7 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>> Hi. Henry made me remember that we need to update the VMs links for Pharo >>> 1.1. We are in RC4 and very very near of the stable release. Thus, I >> suggest >>> to fix this problem. >>> >>> You can see in http://code.google.com/p/pharo/issues/detail?id=2646 >>> >>> Mac: >>> 4.2.5 >>> Windows: >>> 4.0.2 >>> Linux: >>> 4.0.3.2202 >>> >>> What I am not sure if we should put these links in a particular section >> of >>> Pharo 1.1 or just update the current VMs links. The problem of doing the >>> last one is that these VMs will be downloaded for both images: 1.0 and >> 1.1. >>> Are there problems with it ? The only thing I can image is if the vm >> has >>> FreeType compiled. >> >> Hi Mariano, >> >> maybe it's better to avoid problems by providing two distincts VMs. >> And if some people reports problem from 1.0, maybe you will not know >> wich VMs they used. >> > > +1. I completly agree. > > Adrian, could you do this please? > > Thanks > > Mariano > > >> Regards, >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >> Every DSL ends up being Smalltalk >> http://doesnotunderstand.org/ >> >> _______________________________________________ >> 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

July 7, 2010

Re: [Pharo-project] Updating VM links for Pharo 1.1

by Mariano Martinez Peck

On Wed, Jul 7, 2010 at 11:33 AM, Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > 2010/7/7 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Hi. Henry made me remember that we need to update the VMs links for Pharo > > 1.1. We are in RC4 and very very near of the stable release. Thus, I > suggest > > to fix this problem. > > > > You can see in http://code.google.com/p/pharo/issues/detail?id=2646 > > > > Mac: > > 4.2.5 > > Windows: > > 4.0.2 > > Linux: > > 4.0.3.2202 > > > > What I am not sure if we should put these links in a particular section > of > > Pharo 1.1 or just update the current VMs links. The problem of doing the > > last one is that these VMs will be downloaded for both images: 1.0 and > 1.1. > > Are there problems with it ? The only thing I can image is if the vm > has > > FreeType compiled. > > Hi Mariano, > > maybe it's better to avoid problems by providing two distincts VMs. > And if some people reports problem from 1.0, maybe you will not know > wich VMs they used. > +1. I completly agree. Adrian, could you do this please? Thanks Mariano > Regards, > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 7, 2010

Re: [Pharo-project] should we move pharo to use webclient?

by Mariano Martinez Peck

2010/7/7 GermÃ¡n Arduino <garduino(a)gmail.com> > If you (Stef/Sven) cand give some guidelines about what do you expect and > how to integrate, I can help here also. > > Open a ticket, send email, publish in the repository PharoTaskForces so that people can start to commit there. Once you have something that works, someone just integrates it. Cheers mariano > Cheers. > GermÃ¡n. > > > 2010/7/7 Sven Van Caekenberghe <sven(a)beta9.be> > > StÃ©f, >> >> I guess you mean integrating WebClient in 1.2, not 1.1 ? >> I am willing to help here, but I am having a vacation starting tomorrow, >> I'll be back from June 19th. >> I deliberately don't touch any computers during that time ;-) >> >> Sven >> >> On 06 Jul 2010, at 21:22, StÃ©phane Ducasse wrote: >> >> > I agree and this is why I asked. >> > I'm not good in network but the code of network always made me nearly >> faint because it was clearly not designed. >> > Now why interested people would not do a little task forces to bullet >> proof the integration and we prepare together >> > its integration... >> > remember pharo is also your smalltalk :) >> > >> > On Jul 6, 2010, at 3:04 PM, Sven Van Caekenberghe wrote: >> > >> >> Yes!! >> >> >> >> It now loads without patches into Pharo 1.1 rc2 >> >> I used its client and server part, seaside adaptor, it all works. >> >> >> >> The code is quite readable/understandable/malleable. >> >> >> >> I did not yet test the WebClient-HTTP package which patches HTTPSocket >> to replace the old code, >> >> which is obviously important (it then gets used by MC and the rest of >> Smalltalk). >> >> >> >> The unit tests also have to be double checked. >> >> >> >> What do others, like Lukas and other Seaside people think of it ? >> >> >> >> The basic point it: it can only be better than the older code. >> >> But on the other hand, maybe the leap could be even bigger still ? >> >> Having a facade for a pluggable http client is one step. >> >> >> >> Having a good basic HTTP client and server is very important. >> >> >> >> Sven >> >> >> >> On 06 Jul 2010, at 09:30, StÃ©phane Ducasse wrote: >> >> >> >>> to replace the old code? >> >>> >> >>> Stef >> >>> >> >>> _______________________________________________ >> >>> 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 >> > > > > -- > ================================================= > GermÃ¡n S. Arduino <gsa @ arsol.net> Twitter: garduino > Arduino Software & Web Hosting http://www.arduinosoftware.com > PasswordsPro http://www.passwordspro.com > ================================================= > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 7, 2010

Re: [Pharo-project] should we move pharo to use webclient?

by Mariano Martinez Peck

On Wed, Jul 7, 2010 at 12:59 PM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > StÃ©f, > > I guess you mean integrating WebClient in 1.2, not 1.1 ? > Yes, 1.2, not 1.1. > I am willing to help here, but I am having a vacation starting tomorrow, > I'll be back from June 19th. > I deliberately don't touch any computers during that time ;-) > > Sven > > On 06 Jul 2010, at 21:22, StÃ©phane Ducasse wrote: > > > I agree and this is why I asked. > > I'm not good in network but the code of network always made me nearly > faint because it was clearly not designed. > > Now why interested people would not do a little task forces to bullet > proof the integration and we prepare together > > its integration... > > remember pharo is also your smalltalk :) > > > > On Jul 6, 2010, at 3:04 PM, Sven Van Caekenberghe wrote: > > > >> Yes!! > >> > >> It now loads without patches into Pharo 1.1 rc2 > >> I used its client and server part, seaside adaptor, it all works. > >> > >> The code is quite readable/understandable/malleable. > >> > >> I did not yet test the WebClient-HTTP package which patches HTTPSocket > to replace the old code, > >> which is obviously important (it then gets used by MC and the rest of > Smalltalk). > >> > >> The unit tests also have to be double checked. > >> > >> What do others, like Lukas and other Seaside people think of it ? > >> > >> The basic point it: it can only be better than the older code. > >> But on the other hand, maybe the leap could be even bigger still ? > >> Having a facade for a pluggable http client is one step. > >> > >> Having a good basic HTTP client and server is very important. > >> > >> Sven > >> > >> On 06 Jul 2010, at 09:30, StÃ©phane Ducasse wrote: > >> > >>> to replace the old code? > >>> > >>> Stef > >>> > >>> _______________________________________________ > >>> 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 >

July 7, 2010

Re: [Pharo-project] Pharo on OLPC XO kid notebook

by Hilaire Fernandes

Le 07/07/2010 12:53, Serge Stinckwich a Ã©crit : > Yes i was quite surprised the first time i used Squeak on XO-1. > COG could definitively help here, but i have no competences in VM. May be Laurent will be interested to sharp his knowledge in this department... >> - When Pharo is used to deploy application, what we should think about is >> how to load fast Smalltalk code in an existing Pharo installation in the XO >> notebook. > > You mean binary packages ? like parcel, sadly the project was not selected in GSoC. So we are a bit stuck there. > At the beginning, we should hide Pharo environment and just use it to > develop applications. We could have both, and the XO may be the primary plateform of development for some people, who knows... Hilaire

July 7, 2010

Re: [Pharo-project] should we move pharo to use webclient?

by GermÃ¡n Arduino

If you (Stef/Sven) cand give some guidelines about what do you expect and how to integrate, I can help here also. Cheers. GermÃ¡n. 2010/7/7 Sven Van Caekenberghe <sven(a)beta9.be> > StÃ©f, > > I guess you mean integrating WebClient in 1.2, not 1.1 ? > I am willing to help here, but I am having a vacation starting tomorrow, > I'll be back from June 19th. > I deliberately don't touch any computers during that time ;-) > > Sven > > On 06 Jul 2010, at 21:22, StÃ©phane Ducasse wrote: > > > I agree and this is why I asked. > > I'm not good in network but the code of network always made me nearly > faint because it was clearly not designed. > > Now why interested people would not do a little task forces to bullet > proof the integration and we prepare together > > its integration... > > remember pharo is also your smalltalk :) > > > > On Jul 6, 2010, at 3:04 PM, Sven Van Caekenberghe wrote: > > > >> Yes!! > >> > >> It now loads without patches into Pharo 1.1 rc2 > >> I used its client and server part, seaside adaptor, it all works. > >> > >> The code is quite readable/understandable/malleable. > >> > >> I did not yet test the WebClient-HTTP package which patches HTTPSocket > to replace the old code, > >> which is obviously important (it then gets used by MC and the rest of > Smalltalk). > >> > >> The unit tests also have to be double checked. > >> > >> What do others, like Lukas and other Seaside people think of it ? > >> > >> The basic point it: it can only be better than the older code. > >> But on the other hand, maybe the leap could be even bigger still ? > >> Having a facade for a pluggable http client is one step. > >> > >> Having a good basic HTTP client and server is very important. > >> > >> Sven > >> > >> On 06 Jul 2010, at 09:30, StÃ©phane Ducasse wrote: > >> > >>> to replace the old code? > >>> > >>> Stef > >>> > >>> _______________________________________________ > >>> 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 > -- ================================================= GermÃ¡n S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software & Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com =================================================

July 7, 2010

Re: [Pharo-project] should we move pharo to use webclient?

by Sven Van Caekenberghe

StÃ©f, I guess you mean integrating WebClient in 1.2, not 1.1 ? I am willing to help here, but I am having a vacation starting tomorrow, I'll be back from June 19th. I deliberately don't touch any computers during that time ;-) Sven On 06 Jul 2010, at 21:22, StÃ©phane Ducasse wrote: > I agree and this is why I asked. > I'm not good in network but the code of network always made me nearly faint because it was clearly not designed. > Now why interested people would not do a little task forces to bullet proof the integration and we prepare together > its integration... > remember pharo is also your smalltalk :) > > On Jul 6, 2010, at 3:04 PM, Sven Van Caekenberghe wrote: > >> Yes!! >> >> It now loads without patches into Pharo 1.1 rc2 >> I used its client and server part, seaside adaptor, it all works. >> >> The code is quite readable/understandable/malleable. >> >> I did not yet test the WebClient-HTTP package which patches HTTPSocket to replace the old code, >> which is obviously important (it then gets used by MC and the rest of Smalltalk). >> >> The unit tests also have to be double checked. >> >> What do others, like Lukas and other Seaside people think of it ? >> >> The basic point it: it can only be better than the older code. >> But on the other hand, maybe the leap could be even bigger still ? >> Having a facade for a pluggable http client is one step. >> >> Having a good basic HTTP client and server is very important. >> >> Sven >> >> On 06 Jul 2010, at 09:30, StÃ©phane Ducasse wrote: >> >>> to replace the old code? >>> >>> Stef >>> >>> _______________________________________________ >>> 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

July 7, 2010

Re: [Pharo-project] Pharo on OLPC XO kid notebook

by Serge Stinckwich

On Wed, Jul 7, 2010 at 5:43 PM, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > Hello Serge, > > Also we may want: > > - provide VM based on COG, the XO-1 are pretty slow, although XO 1.5 are > better. Yes i was quite surprised the first time i used Squeak on XO-1. COG could definitively help here, but i have no competences in VM. > - propose a sugar theme for Pharo (it is about 70% complete with some issues > depending on Gary help) Great ! > - When Pharo is used to deploy application, what we should think about is > how to load fast Smalltalk code in an existing Pharo installation in the XO > notebook. You mean binary packages ? > I am pretty sure we can have quite visible and important impact! > > Nonetheless, an important argument we want to sell with such a set up: > "Develop there, deploy anywhere" > > > Geert, yes browser may not the easiest. We should iterate on how to improve > the IDE if we want kids to write in some way Smalltalk code. May be the > Workspace is more importante at the first place. At the beginning, we should hide Pharo environment and just use it to develop applications. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

July 7, 2010

Re: [Pharo-project] Issue 2635 - methods recategorization

by Pavel Krivanek

Well, all parts are described and sent here and to the issue trackar (http://code.google.com/p/pharo/issues/detail?id=2635, comments 10 and next). Cheers, -- Pavel On Tue, Jul 6, 2010 at 10:27 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jul 6, 2010, at 10:20 PM, Pavel Krivanek wrote: > >> Hi Stef, >> >> of course, I will do that. For faster processing I filtered the >> commands that only change caps in the package names. > > good idea > >> Added as a >> comment 10 to this issue. It needs only a patch from comment 5 that >> adds a method that enables categories merging. >> >> !Categorizer methodsFor: 'accessing' stamp: 'pavel.krivanek 7/4/2010 11:54'! >> moveCategory: sourceCategory to: destinationCategory >> >> Â Â Â self classifyAll: (self listAtCategoryNamed: sourceCategory) under: >> destinationCategory. >> Â Â Â self removeCategory: sourceCategory. >> Â Â Â ! ! > > Ok I will have a look. > >> >> MethodReference organization renameCategory: '*fixunderscores' toBe: >> '*FixUnderscores'. >> MethodReference organization renameCategory: '*monticello' toBe: '*Monticello'. >> MethodReference organization renameCategory: '*packageinfo-base' toBe: >> '*PackageInfo-Base'. >> FileStream organization renameCategory: '*compression' toBe: '*Compression'. >> FileStream organization renameCategory: '*network-uri' toBe: '*Network-URI'. >> FileStream organization renameCategory: '*network-url' toBe: '*Network-URL'. >> FileStream organization renameCategory: '*tools' toBe: '*Tools'. >> FileStream class organization renameCategory: '*network-uri' toBe: >> '*Network-URI'. >> PositionableStream organization renameCategory: '*compression' toBe: >> '*Compression'. >> TranscriptStream organization renameCategory: '*morphic' toBe: '*Morphic'. >> Boolean class organization renameCategory: '*system-settings-browser' >> toBe: '*System-Settings-Browser'. >> SmartRefStream organization renameCategory: '*compression' toBe: '*compression'. >> StandardFileStream class organization renameCategory: '*network-uri' >> toBe: '*Network-URI'. >> Magnitude organization renameCategory: '*kernel-extensions-streaming' >> toBe: '*Kernel-Extensions-Streaming'. >> MacFileDirectory class organization renameCategory: '*network-uri' >> toBe: '*Network-URI'. >> Object organization renameCategory: '*system-settings-browser' toBe: >> '*System-Settings-Browser'. >> Object organization renameCategory: '*system-support' toBe: '*System-Support'. >> Object organization renameCategory: '*tools-browser' toBe: '*Tools-Browser'. >> Object organization renameCategory: '*tools-explorer' toBe: '*Tools-Explorer'. >> Behavior organization moveCategory: '*system-support' to: '*System-Support'. >> Integer organization moveCategory: '*files' to: '*Files'. >> Integer organization moveCategory: '*system-hashing-core' to: >> '*System-Hashing-Core'. >> Integer organization moveCategory: '*tools-explorer' to: '*Tools-Explorer'. >> OrderedCollection organization moveCategory: '*tools-inspector' to: >> '*Tools-Inspector'. >> SystemOrganizer organization moveCategory: '*gofer-core-accessing' to: >> '*Gofer-Core-Accessing'. >> Trait organization moveCategory: '*monticello' to: '*Monticello'. >> TraitBehavior organization moveCategory: '*tools-browser' to: '*Tools-Browser'. >> String organization moveCategory: '*compression' to: '*Compression'. >> String organization moveCategory: '*files' to: '*Files'. >> String organization moveCategory: '*monticello' to: '*Monticello'. >> String organization moveCategory: '*morphic' to: '*Morphic'. >> String organization moveCategory: '*network-mime' to: '*Network-MIME'. >> String organization moveCategory: '*network-protocols' to: '*Network-Protocols'. >> String organization moveCategory: '*network-uri' to: '*Network-URI'. >> String organization moveCategory: '*network-url' to: '*Network-Url'. >> String organization moveCategory: '*st80' to: '*ST80'. >> String organization moveCategory: '*system-settings-browser' to: >> '*System-Settings-Browser'. >> Text organization moveCategory: '*morphic-converting' to: '*Morphic-Converting'. >> Announcer organization moveCategory: '*announcements-view' to: >> '*Announcements-View'. >> Announcement organization moveCategory: '*announcements-view' to: >> '*Announcements-View'. >> ClassDescription organization moveCategory: '*system-support' to: >> '*System-Support'. >> WeakSet organization moveCategory: '*tools-inspector' to: '*Tools-Inspector'. >> Class organization moveCategory: '*monticello' to: '*Monticello'. >> FloatArray organization moveCategory: '*tools-inspector' to: '*Tools-Inspector'. >> Collection organization moveCategory: '*tools-explorer' to: '*Tools-Explorer'. >> Stream organization moveCategory: '*monticello' to: '*Monticello'. >> BitBlt organization moveCategory: '*FreeType-addition' to: '*FreeType-Addition'. >> ReadWriteStream organization moveCategory: '*compression' to: '*Compression'. >> RunArray class organization moveCategory: '*system-changes' to: >> '*System-Changes'. >> Color organization moveCategory: '*morphic' to: '*Morphic'. >> Color class organization moveCategory: '*system-settings-browser' to: >> '*System-Settings-Browser'. >> AcornFileDirectory class organization moveCategory: '*network-uri' to: >> '*Network-URI'. >> ImageSegment organization moveCategory: '*tests-system' to: '*Tests-System'. >> ChangeRecord organization moveCategory: '*monticello' to: '*Monticello'. >> Form organization moveCategory: '*morphic' to: '*Morphic'. >> Number class organization moveCategory: '*system-settings-browser' to: >> '*System-Settings-Browser'. >> DosFileDirectory class organization moveCategory: '*network-uri' to: >> '*Network-URI'. >> Dictionary organization moveCategory: '*compiler' to: '*Compiler'. >> Dictionary organization moveCategory: '*tools-inspector' to: '*Tools-Inspector'. >> Association organization moveCategory: '*system-settings-browser' to: >> '*System-Settings-Browser'. >> SequenceableCollection organization moveCategory: '*kernel-extensions' >> to: '*Kernel-Extensions'. >> SequenceableCollection organization moveCategory: >> '*morphic-newcurves-cubic support' to: '*Morphic-Newcurves-Cubic >> support'. >> SequenceableCollection organization moveCategory: '*traits' to: '*Traits'. >> Array organization moveCategory: '*system-settings-browser' to: >> '*System-Settings-Browser'. >> CrLfFileStream organization moveCategory: '*monticello' to: '*Monticello'. >> Point class organization moveCategory: '*system-settings-browser' to: >> '*System-Settings-Browser'. >> SystemNavigation organization moveCategory: '*multilingual-editor' to: >> '*Multilingual-Editor'. >> SystemNavigation organization moveCategory: '*tools-browser' to: >> '*Tools-Browser'. >> FileDirectory organization moveCategory: '*network-uri' to: '*network-URI'. >> FileDirectory class organization moveCategory: '*network-uri' to: >> '*Network-URI'. >> Set organization moveCategory: '*tools-inspector' to: '*Tools-Inspector'. >> StringHolder organization moveCategory: '*tools' to: '*Tools'. >> StringHolder organization moveCategory: '*tools-traits' to: '*Tools-Traits'. >> ByteArray organization moveCategory: '*compression' to: '*Compression'. >> ByteArray organization moveCategory: '*system-hashing-core' to: >> '*System-Hashing-Core'. >> >> -- Pavel >> >> >> >> On Tue, Jul 6, 2010 at 9:15 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> pavel >>> >>> could you chop it and send it piece by piece to the list so that everybody can get a feel about it >>> and discuss if necessary? >>> I'm sorry but I like that we act a group and not a bunch of cool individual and building a mind-share is important >>> for me. >>> >>> Stef >>> On Jul 6, 2010, at 4:43 PM, Pavel Krivanek wrote: >>> >>>> Hi, >>>> >>>> I finished the list of changes for the issue >>>> http://code.google.com/p/pharo/issues/detail?id=2635. >>>> >>>> This issue is the next step after already integrated packages >>>> reorganization and the goal is to have compact package base a the >>>> small headless PharoKernel image. >>>> >>>> Most changes are simple naming unification and some classes I skipped >>>> because they need deeper refactorings. >>>> >>>> I will now check the list once more. >>>> >>>> -- Pavel >>>> >>>> _______________________________________________ >>>> 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 >

July 7, 2010

Re: [Pharo-project] Pharo on OLPC XO kid notebook

by Hilaire Fernandes

Hello Serge, Also we may want: - provide VM based on COG, the XO-1 are pretty slow, although XO 1.5 are better. - propose a sugar theme for Pharo (it is about 70% complete with some issues depending on Gary help) - When Pharo is used to deploy application, what we should think about is how to load fast Smalltalk code in an existing Pharo installation in the XO notebook. I am pretty sure we can have quite visible and important impact! Nonetheless, an important argument we want to sell with such a set up: "Develop there, deploy anywhere" Geert, yes browser may not the easiest. We should iterate on how to improve the IDE if we want kids to write in some way Smalltalk code. May be the Workspace is more importante at the first place. Hilaire Le 07/07/2010 05:54, Serge Stinckwich a Ã©crit : > What should be done: > - build a specific VM (reuse EToys work), > - port D-BUS to Pharo : http://wiki.laptop.org/go/D-BUS This is mostly > used to communicate with OLPC-services. There is already an EToys > version: http://www.squeaksource.com/dbus.html > - package Pharo as an xo package, > - adapt PBE to have a PBE-Sugar edition. >> PS: I have a couple of XO machines for testing purpose.

July 7, 2010

Re: [Pharo-project] Issue 2635 - methods recategorization

by Pavel Krivanek

code: Point organization moveCategory: '*morphic-extent functions' to: 'extent functions'. Point organization moveCategory: '*morphic-truncation and roundoff' to: 'truncation and roundoff'. SystemNavigation organization moveCategory: 'browse' to: '*Tools-Browser'. SystemNavigation organization moveCategory: 'message sends UI' to: '*Tools'. ByteArray organization moveCategory: '*Network-Mime' to: '*MimeConverter'. TextAttribute organization classify: #actOnClickFor: under: '*ST80'. TextAttribute organization classify: #actOnClickFor:in: under: '*ST80'. TextAttribute organization classify: #actOnClickFor:in:at: under: '*ST80'. TextAttribute organization classify: #actOnClickFor:in:at:editor: under: '*ST80'. SequenceableCollection organization classify: #customizeExplorerContents under: '*Tools-Explorer'. Locale class organization classify: #migrateSystem under: '*Morphic'. TextPrintIt organization classify: #actOnClickFor:in:at:editor: under: '*ST80'. ProgressInitiationException organization classify: #defaultMorphicAction under: '*Morphic'. SystemNavigation organization classify: #allMethodsInCategory: under: 'accessing'. Model organization classify: #containingWindow under: '*Tools-Base'. Model organization classify: #topView under: '*Tools-Base'. Model class organization classify: #buildWith: under: '*ToolBuilder-Kernel'. description: Point organization moveCategory: '*morphic-extent functions' to: 'extent functions'. Point organization moveCategory: '*morphic-truncation and roundoff' to: 'truncation and roundoff'. - useful general methods SystemNavigation organization moveCategory: 'browse' to: '*Tools-Browser'. SystemNavigation organization moveCategory: 'message sends UI' to: '*Tools-Browser'. - tools dependent messages ByteArray organization moveCategory: '*Network-Mime' to: '*MimeConverter'. - base64 moved to MimeConverter TextAttribute organization classify: #actOnClickFor: under: '*ST80'. TextAttribute organization classify: #actOnClickFor:in: under: '*ST80'. TextAttribute organization classify: #actOnClickFor:in:at: under: '*ST80'. TextAttribute organization classify: #actOnClickFor:in:at:editor: under: '*ST80'. - Paragraph support SequenceableCollection organization classify: #customizeExplorerContents under: '*Tools-Explorer'. - explorer support Locale class organization classify: #migrateSystem under: '*Morphic'. - not used, adds morphic listeners to locale TextPrintIt organization classify: #actOnClickFor:in:at:editor: under: '*ST80'. - paragraph support ProgressInitiationException organization classify: #defaultMorphicAction under: '*Morphic'. - no discussion ;-) SystemNavigation organization classify: #allMethodsInCategory: under: 'accessing'. - the rest of the category movet to Tools Model organization classify: #containingWindow under: '*Tools-Base'. Model organization classify: #topView under: '*Tools-Base'. Model class organization classify: #buildWith: under: '*ToolBuilder-Kernel'. - tools and toolbuilder support

July 7, 2010

Re: [Pharo-project] Issue 2635 - methods recategorization

by Pavel Krivanek

"code:" ChangeSet organization moveCategory: '*mailOut' to: '*Tools-Changes'. ChangeSet class organization moveCategory: 'file list services' to: '*Tools-FileList'. Color organization moveCategory: 'morphic menu' to: '*Morphic'. Color class organization moveCategory: 'color from user' to: '*Graphics-Display Object'. Color class organization moveCategory: 'examples' to: '*Graphics-Display Object-Examples'. UIManager organization moveCategory: 'paragraph' to: '*ST80'. Form class organization moveCategory: 'bmp file reading' to: '*Graphics-Files'. Form class organization moveCategory: 'file list services' to: '*Tools-FileList'. Form class organization moveCategory: 'filein/out' to: '*Graphics-Files'. ChangeSet organization classify: '*buildMessageForMailOutWithUser' under: '*Tools-Changes'. ChangeSet class organization classify: #browseChangedMessages under: '*Tools-Changes'. KoreanEnvironment organization classify: #fontDownloadUrls under: '*Multilingual-Display'. Form organization classify: #defaultCanvasClass under: '*Morphic'. Form organization classify: #getCanvas under: '*Morphic'. Form organization classify: #asMorph under: '*Morphic'. Form organization classify: #writeBMPfileNamed: under: '*Graphics-Files'. Form organization classify: #writeJPEGfileNamed: under: '*Graphics-Files'. Form organization classify: #writeJPEGfileNamed:progressive: under: '*Graphics-Files'. Form organization classify: #writeOnMovie: under: '*Graphics-Files'. Form organization classify: #setAsBackground under: '*Morphic'. Number organization classify: #defaultLabelForInspector under: '*Tools-Inspector'. Dictionary organization classify: #customizeExplorerContents under: '*Tools-Explorer'. Dictionary organization classify: #explorerContentsWithIndexCollect: under: '*Tools-Explorer'. "description:" ChangeSet organization moveCategory: '*mailOut' to: '*Tools-Changes'. - ChangeSorter support ChangeSet class organization moveCategory: 'file list services' to: '*Tools-FileList'. - ...as in similar cases Color organization moveCategory: 'morphic menu' to: '*Morphic'. - methods called only from morphic Color class organization moveCategory: 'color from user' to: '*Graphics-Display Objects'. - simple color picker. Still part of the PharoKernel Color class organization moveCategory: 'examples' to: '*Graphics-Display Object-Examples'. - simple examples UIManager organization moveCategory: 'paragraph' to: '*ST80'. - paragraph support (composeFormFor: ) Form class organization moveCategory: 'bmp file reading' to: '*Graphics-Files'. Form class organization moveCategory: 'file list services' to: '*Tools-FileList'. Form class organization moveCategory: 'filein/out' to: '*Graphics-Files'. - file list and image readers/writers support ChangeSet organization classify: 'buildMessageForMailOutWithUser:' under: '*Tools-Changes'. ChangeSet class organization classify: #browseChangedMessages under: '*Tools-Changes'. change sorter support KoreanEnvironment organization classify: #fontDownloadUrls under: '*Multilingual-Display'. - multilingual fonts support Form organization classify: #defaultCanvasClass under: '*Morphic'. Form organization classify: #getCanvas under: '*Morphic'. Form organization classify: #asMorph under: '*Morphic'. - Morphic support Form organization classify: #writeBMPfileNamed: under: '*Graphics-Files'. Form organization classify: #writeJPEGfileNamed: under: '*Graphics-Files'. Form organization classify: #writeJPEGfileNamed:progressive: under: '*Graphics-Files'. Form organization classify: #writeOnMovie: under: '*Graphics-Files'. - image readers/writers Form organization classify: #setAsBackground under: '*Morphic'. - morphic support Number organization classify: #defaultLabelForInspector under: '*Tools-Inspector'. - inspector support Dictionary organization classify: #customizeExplorerContents under: '*Tools-Explorer'. Dictionary organization classify: #explorerContentsWithIndexCollect: under: '*Tools-Explorer'. - explorer support

July 7, 2010

Re: [Pharo-project] Issue 2635 - methods recategorization

by Pavel Krivanek

code: ClassTrait organization moveCategory: '*monticello' to: '*Monticello'. BitBlt organization moveCategory: 'text display' to: '*Graphics-Fonts'. DisplayScreen organization classify: #defaultCanvasClass under: '*Morphic'. SmalltalkImage organization classify: #aboutThisSystem under: '*Morphic'. TextURL organization classify: #actOnClickFor: under: '*ST80'. PluggableTextAttribute organization classify: #actOnClickFor: under: '*ST80'. Bitmap organization classify: #compressGZip under: '*Compression'. BitBlt organization classify: #cachedFontColormapFrom:to: under: '*Graphics-Fonts'. BitBlt organization classify: #installStrikeFont:foregroundColor:backgroundColor: under: '*Graphics-Fonts'. BitBlt organization classify: #installTTCFont:foregroundColor:backgroundColor: under: '*Graphics-Fonts'. BitBlt class organization classify: #asGrafPort under: '*Morphic'. TextLink organization classify: #actOnClickFor: under: '*ST80'. ImmWin32 organization classify: #keyboardFocusForAMorph: under: '*Morphic'. description: ClassTrait organization moveCategory: '*monticello' to: '*Monticello'. - simple renaming BitBlt organization moveCategory: 'text display' to: '*Graphics-Fonts'. - all methods are font support DisplayScreen organization classify: #defaultCanvasClass under: '*Morphic'. - morphic canvas support SmalltalkImage organization classify: #aboutThisSystem under: '*Morphic'. - morphic dependent, others can use systemInformationString TextURL organization classify: #actOnClickFor: under: '*ST80'. PluggableTextAttribute organization classify: #actOnClickFor: under: '*ST80'. - Paragraph support Bitmap organization classify: #compressGZip under: '*Compression'. - not used BitBlt organization classify: #cachedFontColormapFrom:to: under: '*Graphics-Fonts'. BitBlt organization classify: #installStrikeFont:foregroundColor:backgroundColor: under: '*Graphics-Fonts'. BitBlt organization classify: #installTTCFont:foregroundColor:backgroundColor: under: '*Graphics-Fonts'. - fonts support BitBlt class organization classify: #asGrafPort under: '*Morphic'. - GraphPort is part of Morphic, others use BitBlt TextLink organization classify: #actOnClickFor: under: '*ST80'. - Paragraph support ImmWin32 organization classify: #keyboardFocusForAMorph: under: '*Morphic'. - morphic support

July 7, 2010

Re: [Pharo-project] Updating VM links for Pharo 1.1

by Serge Stinckwich

2010/7/7 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi. Henry made me remember that we need to update the VMs links for Pharo > 1.1. We are in RC4 and very very near of the stable release. Thus, I suggest > to fix this problem. > > You can see in http://code.google.com/p/pharo/issues/detail?id=2646 > > Mac: > 4.2.5 > Windows: > 4.0.2 > Linux: > 4.0.3.2202 > > What I am not sure if we should put these links in a particular section of > Pharo 1.1 or just update the current VMs links. The problem of doing the > last one is that these VMs will be downloaded for both images: 1.0 and 1.1. > Are there problems with it ? Â The only thing I can image is if the vm has > FreeType compiled. Hi Mariano, maybe it's better to avoid problems by providing two distincts VMs. And if some people reports problem from 1.0, maybe you will not know wich VMs they used. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

July 7, 2010

Re: [Pharo-project] Issue 2635 - methods recategorization

by Pavel Krivanek

On Wed, Jul 7, 2010 at 10:44 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > On Tue, Jul 6, 2010 at 11:13 PM, Pavel Krivanek > <pavel.krivanek(a)gmail.com> wrote: >> On Tue, Jul 6, 2010 at 11:05 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: >>>>> 2) e.g you move somethings to *Tools and some things to *Tools-Explorer >>>>> is that not going to create the same problem that happened to System, >>>>> with both parent and child packages defined in the same image? >>>> >>>> There's only one MC package named Tools and this package is not >>>> splitted. But we may make future split of this package easier if we >>>> will use a category name Tools-Base (or more fitting one) instead of >>>> Tools. >>>> >>> >>> ok fair enough. but if i look in #12038 there appear a few cases: >>> Graphics-Stef.256 >>> Graphics-* >>> >>> Multilingual-Markus.2 >>> Multilingual-* >> >> At least the Multilingual package is automatically registered because >> of one method in the Character class and the fix is already mentioned >> in this thread. However I have no idea why MC registers automatically >> the Graphics package > > maybe the empty *Graphics category in the String. > > -- Pavel > I suggest to remove all empty method categories in the whole system. -- Pavel > >> >> Cheers, >> -- Pavel >> >>> >>> this needs fixing before applying more recategorisation? >>> >>> >>> thanks, >>> Mike >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >

July 7, 2010

Re: [Pharo-project] Issue 2635 - methods recategorization

by Pavel Krivanek

code: Behavior organization classify: #inspectAllInstances under: '*Tools-Inspector'. Behavior organization classify: #inspectSubInstances under: '*Tools-Inspector'. String organization classify: #displayProgressAt:from:to:during: under: '*UIManager-Support'. String organization classify: #base64Encoded under: '*MimeConverter'. String organization classify: #asDisplayText under: '*Graphics-Support'. DataStream class organization classify: #exampleWithPictures under: '*Graphics-Display Objects'. Text organization classify: #embeddedMorphs under: '*Morphic'. Text organization classify: #embeddedMorphsFrom:to: under: '*Morphic'. Text organization classify: #asDisplayText under: '*Graphics-Support'. Text organization classify: #asParagraph under: '*ST80'. Text organization classify: #asUrl under: '*Network-Url'. Rectangle class organization classify: #fromUser under: '*Graphics-Display Objects'. Rectangle class organization classify: #fromUser: under: '*Graphics-Display Objects'. Rectangle class organization classify: #originFromUser: under: '*Graphics-Display Objects'. Rectangle class organization classify: #originFromUser:grid: under: '*Graphics-Display Objects'. ArrayedCollection organization classify: #writeOnGZIPByteStream: under: '*Compression'. description: Behavior organization classify: #inspectAllInstances under: '*Tools-Inspector'. Behavior organization classify: #inspectSubInstances under: '*Tools-Inspector'. - inspector support String organization classify: #displayProgressAt:from:to:during: under: '*UIManager-Support'. - it will not remove it from the PharoKernel String organization classify: #base64Encoded under: '*MimeConverter'. - Base64MimeConverter moved to MimeConverter package (part of the PharoKernel) String organization classify: #asDisplayText under: '*Graphics-Support'. - DisplayText support DataStream class organization classify: #exampleWithPictures under: '*Graphics-Display Objects'. - an example with a Form from display Text organization classify: #embeddedMorphs under: '*Morphic'. Text organization classify: #embeddedMorphsFrom:to: under: '*Morphic'. - TextMorph support Text organization classify: #asDisplayText under: '*Graphics-Support'. - DisplayText support Text organization classify: #asParagraph under: '*ST80'. - Paragraph support Text organization classify: #asUrl under: '*Network-Url'. - Network Url support Rectangle class organization classify: #fromUser under: '*Graphics-Display Objects'. Rectangle class organization classify: #fromUser: under: '*Graphics-Display Objects'. Rectangle class organization classify: #originFromUser: under: '*Graphics-Display Objects'. Rectangle class organization classify: #originFromUser:grid: under: '*Graphics-Display Objects'. - still part of the PharoKernel, works with Display ArrayedCollection organization classify: #writeOnGZIPByteStream: under: '*Compression'. - compression support

July 7, 2010

Re: [Pharo-project] Updating VM links for Pharo 1.1

by StÃ©phane Ducasse

We should move to Mac 5.0 for 1.2 Stef On Jul 7, 2010, at 10:39 AM, Mariano Martinez Peck wrote: > Hi. Henry made me remember that we need to update the VMs links for Pharo 1.1. We are in RC4 and very very near of the stable release. Thus, I suggest to fix this problem. > > You can see in http://code.google.com/p/pharo/issues/detail?id=2646 > > Mac: > 4.2.5 > Windows: > 4.0.2 > Linux: > 4.0.3.2202 > > What I am not sure if we should put these links in a particular section of Pharo 1.1 or just update the current VMs links. The problem of doing the last one is that these VMs will be downloaded for both images: 1.0 and 1.1. Are there problems with it ? The only thing I can image is if the vm has FreeType compiled. > > Cheers > > Mariano _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 7, 2010

Re: [Pharo-project] I updated the how to contribute web page

by StÃ©phane Ducasse

laurent I did a pass on the wiki and I suggest that we removed it from the wiki and put it on the book and ideally in the help :) Stef On Jul 6, 2010, at 9:48 AM, laurent laffont wrote: > Hi, > > I've seen http://book.pharo-project.org/book/Contribute > > Should we Cut / Paste from google project's wiki ? (So we have only one source of documentation, that can be later integrated to HelpSystem). > > Cheers, > > Laurent Laffont > > http://pharocasts.blogspot.com/ > http://magaloma.blogspot.com/ > > > On Tue, Jul 6, 2010 at 12:21 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > thanks hernan. > I will not have the time to edit the changes but this is important that we keep this information upto date and that > people can understand it. > > Stef > > On Jul 5, 2010, at 4:34 PM, HernÃ¡n Morales Durand wrote: > > > Ok, > > > > ================ > > Here: "First and foremost, you must be aware that the Pharo project > > only accepts code published under the MIT license. By publishing your > > code in the SqueakSource Pharo or PharoInbox repositories, you are > > agreeing to this condition. With that out of the way, here are the > > steps to submit your contributions. " > > > > Please provide a link which explain the implications of code published > > under the MIT license. Or better, a little comparison table between > > different licensing schemes. > > > > ================ > > Here: "If your change is directly related to a Mantis report, add the > > label "Type-Mantis" and add the Mantis ticket number in front of the > > subject. Else choose another appropriate label " > > > > Please clarify or link to. Manits is the bugs.squeak.org right? It > > should be named by what it is, and not by the tool which is used for > > bug tracking (if they change their tool 10 times, you must update the > > page 10 times) > > > > ================ > > Here: "Announce your contribution by sending a mail to the mailing > > list and herewith ask to have somebody review your change. This person > > should change the state of the issue to "Verified". " > > > > Provide a link to the mailing list. Note "herewith" is most used and > > understood as a legal term. > > > > ================ > > Here: "For complex changes use a slice since there is a much better > > merging support. " > > > > What is a complex change? (please include this information in the page too) > > > > ================ > > "Prepare a changeset with your changes. File it out. Important: Put > > your Full name instead of your initials, it will help up to contact > > you as it is often necessary. Do not use space and only alphabetical > > characters. " > > > > 1) This is killing more than 50% of the habitants of the world :) What > > happens with contributors without latin alphabet? how they setup their > > system? (that should be included) > > > > 2) What is the problem with using space? If it is a limitation imposed > > by a tool then the tool should be responsible of trimming all blanks, > > not the users. > > > > 3) How do you distinguish between two John Smith? And how do you > > contact contributors? (I've never wrote my e-mail or gmail user name > > in a Pharo image). > > > > 4) Some brief explanation on how to create a changeset would be nice. > > > > ================ > > Finally, this information should be in all images. Better, provide a > > wizard to guide this process, it sounds like a nice excercise to do a > > standard window flow with Morphic. > > > > Cheers, > > > > HernÃ¡n > > > > 2010/7/5 stephane ducasse <stephane.ducasse(a)free.fr>: > >> please comment :) > >> http://code.google.com/p/pharo/wiki/HowToContribute > >> > >> Stef > >> > >> _______________________________________________ > >> 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

July 7, 2010

Re: [Pharo-project] Markup Builder in Smalltalk

by StÃ©phane Ducasse

looks more readable :) On Jul 7, 2010, at 7:49 AM, Sudhakar Krishnamachari wrote: > Accepted and committed as alpha: 1.13 in http://squeaksource.com/PharoGoodies/ > > modified api is: > newBldr := XMLBuilder new. > newBldr xmlPreprocessor; attributes: #(âa=â6â³â âb=â7â³â); > > test: âwelcome to buildersâ > > with: [ newBldr attributes: #('a="1"' 'b="2"'); trial: ''; > attributes: #('a="3"' 'b="4"'); trial: 'testing..' ; > > trial ]. > > to get: > > '<?xml version="1.0" ?><test a="6" b="7" >welcome to builders<trial a="1" b="2" ></trial><trial a="3" b="4" >testing..</trial><trial></trial></test>' > > > hope this aligns.. lots more stil to be cleaned for plugins, will do so by the next commit.. > > -Skrish > ***** > There is an interest! Please submit/publish it... > > Now What is the exact API I found cNode: a bit a bad name. What does it mesn childrenNode: > > > > newBldr := XMLBuilder new xmlPreprocessor. > newBldr mbAttr: #(âa=â6â³â âb=â7â³â); test: âwelcome to buildersâ > > why new and xmlPreprocessor > > > mbAttr: sucks also! > > Could you shine a bit the API to be reader friendly? > > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 7, 2010

Re: [Pharo-project] Mysql Port of Josh Mcdonald Driver

by StÃ©phane Ducasse

this is not in squeaksource? Stef On Jul 7, 2010, at 6:49 AM, Sudhakar Krishnamachari wrote: > Hi, > > Can anyone forward the latest version of Alan Reider's fixes of the Mysql driver. I cant access the squeak map I get link of.. > > -Skrish > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 7, 2010

Re: [Pharo-project] Issue 2635 - methods recategorization

by Pavel Krivanek

On Tue, Jul 6, 2010 at 11:13 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > On Tue, Jul 6, 2010 at 11:05 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: >>>> 2) e.g you move somethings to *Tools and some things to *Tools-Explorer >>>> is that not going to create the same problem that happened to System, >>>> with both parent and child packages defined in the same image? >>> >>> There's only one MC package named Tools and this package is not >>> splitted. But we may make future split of this package easier if we >>> will use a category name Tools-Base (or more fitting one) instead of >>> Tools. >>> >> >> ok fair enough. but if i look in #12038 there appear a few cases: >> Graphics-Stef.256 >> Graphics-* >> >> Multilingual-Markus.2 >> Multilingual-* > > At least the Multilingual package is automatically registered because > of one method in the Character class and the fix is already mentioned > in this thread. However I have no idea why MC registers automatically > the Graphics package maybe the empty *Graphics category in the String. -- Pavel > > Cheers, > -- Pavel > >> >> this needs fixing before applying more recategorisation? >> >> >> thanks, >> Mike >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

July 7, 2010

[Pharo-project] Updating VM links for Pharo 1.1

by Mariano Martinez Peck

Hi. Henry made me remember that we need to update the VMs links for Pharo 1.1. We are in RC4 and very very near of the stable release. Thus, I suggest to fix this problem. You can see in http://code.google.com/p/pharo/issues/detail?id=2646 Mac: 4.2.5 Windows: 4.0.2 Linux: 4.0.3.2202 What I am not sure if we should put these links in a particular section of Pharo 1.1 or just update the current VMs links. The problem of doing the last one is that these VMs will be downloaded for both images: 1.0 and 1.1. Are there problems with it ? The only thing I can image is if the vm has FreeType compiled. Cheers Mariano

July 7, 2010

Re: [Pharo-project] Issue 2635 - methods recategorization

by Pavel Krivanek

code: SystemDictionary organization moveCategory: 'ui' to: '*Tools-Inspector'. Quadrangle organization moveCategory: 'displaying-display' to: '*Graphics-Display Objects'. Quadrangle organization moveCategory: 'displaying-generic' to: '*Graphics-Display Objects'. DefaultExternalDropHandler organization moveCategory: 'event handling' to: '*Morphic'. Rectangle organization moveCategory: '*morphic-truncation and roundoff' to: 'truncation and roundoff'. description: SystemDictionary organization moveCategory: 'ui' to: '*Tools-Inspector'. - single method inspectGlobals, not used Quadrangle organization moveCategory: 'displaying-display' to: '*Graphics-Display Objects'. Quadrangle organization moveCategory: 'displaying-generic' to: '*Graphics-Display Objects'. - graphics dependent, not used DefaultExternalDropHandler organization moveCategory: 'event handling' to: '*Morphic'. - single morphic support method Rectangle organization moveCategory: '*morphic-truncation and roundoff' to: 'truncation and roundoff'. - morphic independent useful methods

July 7, 2010

Re: [Pharo-project] Issue 2635 - methods recategorization

by Pavel Krivanek

code: StandardFileStream organization classify: #directoryUrl under: '*Network-RemoteDirectory'. Object organization classify: #customizeExplorerContents under: '*Tools-Explorer'. Object organization classify: #asDraggableMorph under: '*Morphic'. Object organization classify: #printDirectlyToDisplay under: '*Graphics-Display Objects'. Object organization classify: #doExpiredInspectCount under: '*Tools-Inspector'. Object organization classify: #inspectOnCount: under: '*Tools-Inspector'. Object organization classify: #inspectOnce under: '*Tools-Inspector'. Object organization classify: #inspectUntilCount: under: '*Tools-Inspector'.. Object organization classify: #fullDrawPostscriptOn: under: '*Morphic'. Object organization classify: #currentEvent under: '*Morphic'. Object organization classify: #currentHand under: '*Morphic'. Object organization classify: #currentWorld under: '*Morphic'. Object organization classify: #saveOnFile under: '*Morphic'. Object organization classify: #showDiffs under: '*Tools-Base'. Object organization classify: #commandHistory under: '*Morphic'. Object organization classify: #purgeAllCommands under: '*Morphic'. Object organization classify: #rememberCommand: under: '*Morphic'. Object organization classify: #updateListsAndCodeIn: under: '*Tools-Base'. Object organization classify: #asExplorerString under: '*Tools-Explorer'. Object organization classify: #defaultBackgroundColor under: '*Tools-Base'. Object organization classify: #defaultLabelForInspector under: '*Tools-Inspector'. Object organization classify: #explore under: '*Tools-Explorer'. Object organization classify: #hasContentsInExplorer under: '*Tools-Explorer'. Object organization classify: #inspectWithLabel: under: '*Tools-Inspector'. Object class organization classify: #services under: '*Tools'. description: StandardFileStream organization classify: #directoryUrl under: '*Network-RemoteDirectory'. - a method dependent on network package. Called only from RemoteDirectory class Object organization classify: #customizeExplorerContents under: '*Tools-Explorer'. - support for the explorer Object organization classify: #asDraggableMorph under: '*Morphic'. - morphic specific method called only from morphic Object organization classify: #printDirectlyToDisplay under: '*Graphics-Display Objects'. - show text representation of an object on the display, not used. Object organization classify: #doExpiredInspectCount under: '*Tools-Inspector'. Object organization classify: #inspectOnCount: under: '*Tools-Inspector'. Object organization classify: #inspectOnce under: '*Tools-Inspector'. Object organization classify: #inspectUntilCount: under: '*Tools-Inspector'. - inspector support Object organization classify: #fullDrawPostscriptOn: under: '*Morphic'. - PostScript support, not used Object organization classify: #currentEvent under: '*Morphic'. Object organization classify: #currentHand under: '*Morphic'. Object organization classify: #currentWorld under: '*Morphic'. - morphic support Object organization classify: #saveOnFile under: '*Morphic'. - morphic support Object organization classify: #showDiffs under: '*Tools-Base'. - CodeHolder support Object organization classify: #commandHistory under: '*Morphic'. Object organization classify: #purgeAllCommands under: '*Morphic'. Object organization classify: #rememberCommand: under: '*Morphic'. - CommandHistory support Object organization classify: #updateListsAndCodeIn: under: '*Tools-Base'. - CodeHolder support Object organization classify: #asExplorerString under: '*Tools-Explorer'. - explorer support Object organization classify: #defaultBackgroundColor under: '*Tools-Base'. - tools support Object organization classify: #defaultLabelForInspector under: '*Tools-Inspector'. - inspector support Object organization classify: #explore under: '*Tools-Explorer'. Object organization classify: #hasContentsInExplorer under: '*Tools-Explorer'. - explorer support Object organization classify: #inspectWithLabel: under: '*Tools-Inspector'. - inspector support Object class organization classify: #services under: '*Tools-FileList''. - file list associations StandardFileStream class >> #privateCheckForBrowserPrimitives should be in the same package as the rest of browser plugin supporting methods (see previous comment) We should open an issue for Object >> #notifyWithLabel: senders. It should be more UI independent

July 7, 2010

Re: [Pharo-project] Issue 2635 - methods recategorization

by Pavel Krivanek

code: SmartRefStream organization moveCategory: 'conversion' to: '*Morphic'. TextIndent class organization moveCategory: '*example' to: '*ST80'. Object organization moveCategory: '*monticello' to: '*Traits'. Object organization moveCategory: 'creation' to: '*Morphic'. Object organization moveCategory: 'inspecting' to: '*Tools-Inspector'. Object organization moveCategory: 'graph model' to: '*Morphic'. Object organization moveCategory: 'thumbnail' to: '*Morphic'. Object organization moveCategory: 'viewer' to: '*Morphic'. description: SmartRefStream organization moveCategory: 'conversion' to: '*Morphic'. - defines conversions for old Morphic class names TextIndent class organization moveCategory: '*example' to: '*ST80'. - dependent on a paragraph Object organization moveCategory: '*monticello' to: '*Traits'. - real senders of the single method isConfilct only from traits (included in the PharoKernel) Object organization moveCategory: 'creation' to: '*Morphic'. - asMorph and similar conversions to morphs Object organization moveCategory: 'inspecting' to: '*Tools-Inspector'. - inspect and similar methods Object organization moveCategory: 'graph model' to: '*Morphic'. - two morphic dependent classes called only from morphic Object organization moveCategory: 'thumbnail' to: '*Morphic'. - single method iconOrThumbnailOfSize:, called only from morphic and dependent packages Object organization moveCategory: 'viewer' to: '*Morphic'. - single method externalName, called only from morphic and dependent packages I removed renaming of the category StandardFileStream >> 'browser requests' because it will be better if we will open an issue for separate package for the browser plugin support.

July 7, 2010

Re: [Pharo-project] Pharo on OLPC XO kid notebook

by Serge Stinckwich

On Wed, Jul 7, 2010 at 2:13 PM, Geert Claes <geert.wl.claes(a)gmail.com> wrote: > > > Serge Stinckwich-2 wrote: >> >> The idea is not to have Pharo as an IDE for kids but to use Pharo to >> develop XO software for kids. >> > > Ok, and in which environment will these kids develop XO software then? Kids will not develop software, they will use pedagogical activities developed in Pharo like Dr Geo 2 for example. -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

July 7, 2010

Re: [Pharo-project] Pharo on OLPC XO kid notebook

by Geert Claes

Serge Stinckwich-2 wrote: > > The idea is not to have Pharo as an IDE for kids but to use Pharo to > develop XO software for kids. > Ok, and in which environment will these kids develop XO software then? -- View this message in context: http://forum.world.st/Pharo-on-OLPC-XO-kid-notebook-tp2279811p2280559.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 7, 2010

Re: [Pharo-project] Pharo on OLPC XO kid notebook

by Serge Stinckwich

On Wed, Jul 7, 2010 at 1:28 PM, Geert Claes <geert.wl.claes(a)gmail.com> wrote: > > > Hilaire Fernandes-6 wrote: >> >> ... >> Now that Pharo 1.1 is in good sigh and as we are not ashame any more to >> show how Smalltalk looks like we could also produce a release of Pharo for >> OLPC XO Sugar environment >> ... >> > > My 2 cents is that the IDE - as it is stands now - is probably not intuitive > enough for kids. The idea is not to have Pharo as an IDE for kids but to use Pharo to develop XO software for kids. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

July 7, 2010

Re: [Pharo-project] Pharo on OLPC XO kid notebook

by Geert Claes

Hilaire Fernandes-6 wrote: > > ... > Now that Pharo 1.1 is in good sigh and as we are not ashame any more to > show how Smalltalk looks like we could also produce a release of Pharo for > OLPC XO Sugar environment > ... > My 2 cents is that the IDE - as it is stands now - is probably not intuitive enough for kids. -- View this message in context: http://forum.world.st/Pharo-on-OLPC-XO-kid-notebook-tp2279811p2280527.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 7, 2010

[Pharo-project] Markup Builder in Smalltalk

by Sudhakar Krishnamachari

Accepted and committed as alpha: 1.13 in http://squeaksource.com/PharoGoodies/ modified api is: newBldr := XMLBuilder new. newBldr xmlPreprocessor; attributes: #(âa=â6â³â âb=â7â³â); test: âwelcome to buildersâ with: [ newBldr attributes: #('a="1"' 'b="2"'); trial: ''; attributes: #('a="3"' 'b="4"'); trial: 'testing..' ; trial ]. to get: '<?xml version="1.0" ?><test a="6" b="7" >welcome to builders<trial a="1" b="2" ></trial><trial a="3" b="4" >testing..</trial><trial></trial></test>' hope this aligns.. lots more stil to be cleaned for plugins, will do so by the next commit.. -Skrish ***** There is an interest! Please submit/publish it... Now What is the exact API I found cNode: a bit a bad name. What does it mesn childrenNode: newBldr := XMLBuilder new xmlPreprocessor. newBldr mbAttr: #(âa=â6â³â âb=â7â³â); test: âwelcome to buildersâ why new and xmlPreprocessor mbAttr: sucks also! Could you shine a bit the API to be reader friendly? Stef

July 7, 2010

Re: [Pharo-project] feedup of selecting doit or typing " above and below expressions in comments?

by Lukas Renggli

> Again: when I have a method > > Â Â Â foo > Â Â Â Â self sendMessage: myMessage with: text. > Â Â Â Â self sendSecondMessage: myMessage. > > B) In Pharo (with OB): I can only check the senders/implementors > Â Â Â Â Â Â Â of #foo which is limiting and makes it hard to search > Â Â Â Â Â Â Â for s/i of the other messages sent from within the > Â Â Â Â Â Â Â method body. > > => So I'm limited with Pharo(OB) compared to Standard browser in Core. In OB you select (in the list or in the source code) whatever you want to browse/references/implementors/senders of. There are no additional pop-ups or questions. And please Torsten could you *finally* fix your e-mail client/account? You are the only one in the whole Smalltalk world that constantly messes up the mail threading. Lukas -- Lukas Renggli www.lukas-renggli.ch

July 7, 2010

[Pharo-project] Mysql Port of Josh Mcdonald Driver

by Sudhakar Krishnamachari

Hi, Can anyone forward the latest version of Alan Reider's fixes of the Mysql driver. I cant access the squeak map I get link of.. -Skrish

July 7, 2010

Re: [Pharo-project] Pharo on OLPC XO kid notebook

by Serge Stinckwich

On Tue, Jul 6, 2010 at 11:24 PM, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > OLPC moto is based from day one on the use of dynamic language to design the > content coming with their notebook. > > It is to write content but also to allow kids to examine source code, edit > it and test it ; as we are doing continuously in Smalltalk. > They even think about a source-code key in the keyboard to instantaneously > open a source code browser exposing the code of a running application. > > Now that Pharo 1.1 is in good sigh and as we are not ashame any more to show > how Smalltalk looks like we could also produce a release of Pharo for OLPC > XO Sugar environment. It is definitely a good opportunity to bring an > interesting tool to neutral mind (kids). In the other hand, it will > definitely help to bring awareness about Pharo. Â For example, without any > action of my part, DrGeoII was downloaded about 180'000 times in one year > for XO. > > Any takers? I'm interested ! I'm involved in OLPC Vietnam and we would like to develop more contents in Vietnamese. Our website is here: http://olpc.vn/ Some vietnamese students (one of them is in CC on this message) are working to port Magic Words (http://comikit.se/page_magicwords.html ) to the XO and we are looking for an Smalltalk image for deployment (at the moment we are considering using the EToys image). What should be done: - build a specific VM (reuse EToys work), - port D-BUS to Pharo : http://wiki.laptop.org/go/D-BUS This is mostly used to communicate with OLPC-services. There is already an EToys version: http://www.squeaksource.com/dbus.html - package Pharo as an xo package, - adapt PBE to have a PBE-Sugar edition. > Hilaire > > PS: I have a couple of XO machines for testing purpose. I've got one. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

July 7, 2010

[Pharo-project] feedup of selecting doit or typing " above and below expressions in comments?

by Torsten Bergmann

>This was removed on request of Stef and I completely agree on this: >for me it is time consuming to be forced to search for the selector in >a sorted list when the selector is written/selected right in front of >me. Maybe I dont understand what you wrote - but if I understand you correctly OB had the same behavior as in Core and this was removed from OB on request of Stef? Again: when I have a method foo self sendMessage: myMessage with: text. self sendSecondMessage: myMessage. A) In Core: I'm able to browse the senders/implementors of all three selectors using the sorted list provided by the "Senders of..."/"Implementors of..." menu: #(foo, sendMessage:with:, sendSecondMessage:) where the methods selector (#foo) of the selected method is explicitly at the top. B) In Pharo (with OB): I can only check the senders/implementors of #foo which is limiting and makes it hard to search for s/i of the other messages sent from within the method body. => So I'm limited with Pharo(OB) compared to Standard browser in Core. Bye T. -- GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl

July 6, 2010

Re: [Pharo-project] feedup of selecting doit or typing " above and below expressions in comments?

by StÃ©phane Ducasse

cool On Jul 6, 2010, at 10:54 PM, Lukas Renggli wrote: >>> Another thing that is related to the above and to the different browsers: >>> >>> In Core: When I select a method I can choose "Senders of..." >>> and "Implementors of..." to either search for senders/implementors >>> of the selected method AND the messages sent into the selected >>> method. >>> >>> In Pharo: with OB I can just do "senders" and "implementors" >>> which looks for the senders/implementors of the selected method >>> One is NOT able to search for senders/implementors of >>> the messages sent within the selected method. >>> Here I have to select the entire selector which is >>> time consuming as described above. >> >> enter a bug entry. > > This was removed on request of Stef and I completely agree on this: > for me it is time consuming to be forced to search for the selector in > a sorted list when the selector is written/selected right in front of > me. > >>> So Pharo with OB is (compared to core) really a step backwards here. >> >> I imagine that the enh I did also to get Cmd-M on class name browsing the class and Cmd-B on >> selectors do an implementors should also be pushed in OB. > > The Cmd-B was always part of OB, I've done the same for Cmd-M. Also I > updated the edit pane menu to match the one of the standard browser. > > Lukas > > -- > Lukas Renggli > 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

July 6, 2010

Re: [Pharo-project] Markup Builder in Smalltalk

by Lukas Renggli

>>I may perhaps be unaware of the XML/SGML builder generation from Seaside, love to be pointed out to.., The Html generation of >>Seaside uses explicit construct of classes ( WA**Tags) to do so.. Builders in dynamic manner >> use doesNotUnderstand: construct to generate the stream.. > > While it may seem desirable to have an API that uses #doesNotUnderstand: (or its equivalent in other languages) to facilitate markup generation by accepting arbitrary messages and taking them to be the names of tags, this approach is not a good idea for at least two reasons: 1) namespace prefixes cannot be specified in this way, as ":" is not a legal character within identifiers in Smalltalk (or in most other languages, for that matter), and 2) unary messages intended to be treated as tag names can collide with already-defined unary messages in the writer class or its superclasses. 3) The approach with #doesNotUnderstand: absolutely doesn't scale. Tools break in subtle ways (editors, debuggers, program checkers). Debugging is a pain. And it is slow. We've had that in Seaside up to version 2.6. Lukas -- Lukas Renggli www.lukas-renggli.ch

July 6, 2010

Re: [Pharo-project] Issue 2635 - methods recategorization

by Pavel Krivanek

code: SystemNavigation organization renameCategory: '*multilingual-editor' toBe: '*Multilingual-Encodings'. Project class organization classify: #spawnNewProcessIfThisIsUI: under: '*Morphic'. Project class organization removeCategory:'squeaklet on server'. ImmX11 organization classify: #keyboardFocusForAMorph: under: '*Morphic'. FileStream class organization classify: #fileReaderServicesForFile:suffix: under: '*Tools-FileList'. FileStream class organization classify: #serviceFileIn under: '*Tools-FileList'. FileStream class organization classify: #serviceRemoveLineFeeds under: '*Tools-FileList'. FileStream class organization classify: #services under: '*Tools-FileList'. Character organization classify: #macRomanToUnicode under: '*Multilingual-TextConversion'. Character organization classify: #unicodeToMacRoman under: '*Multilingual-TextConversion'. TranscriptStream organization classify: #codePaneMenu:shifted: under: '*Tools-Base'. TranscriptStream class organization classify: #openMorphicTranscript under: '*Morphic'. description: SystemNavigation organization renameCategory: '*multilingual-editor' toBe: '*Multilingual-Encodings'. - move the single method allSelect: to a base Multilingual package Project class organization classify: #spawnNewProcessIfThisIsUI: under: '*Morphic'. Project class organization removeCategory:'squeaklet on server'. - UI specific and sent only from Morphic dependent methods ImmX11 organization classify: #keyboardFocusForAMorph: under: '*Morphic'. - used only for Morphic FileStream class organization classify: #fileReaderServicesForFile:suffix: under: '*Tools-FileList'. FileStream class organization classify: #serviceFileIn under: '*Tools-FileList'. FileStream class organization classify: #serviceRemoveLineFeeds under: '*Tools-FileList'. FileStream class organization classify: #services under: '*Tools-FileList'. - FileList files associations. However a deeper refactoring is welcome. Character organization classify: #macRomanToUnicode under: '*Multilingual-TextConversion'. Character organization classify: #unicodeToMacRoman under: '*Multilingual-TextConversion'. - both packages in the PharoKernel. Move to a more fitting package. TranscriptStream organization classify: #codePaneMenu:shifted: under: '*Tools-Base'. TranscriptStream class organization classify: #openMorphicTranscript under: '*Morphic'.

July 6, 2010

Re: [Pharo-project] Markup Builder in Smalltalk

by jaayer

---- On Tue, 06 Jul 2010 02:37:38 -0700 Sudhakar Krishnamachari wrote ---- >I may perhaps be unaware of the XML/SGML builder generation from Seaside, love to be pointed out to.., The Html generation of >Seaside uses explicit construct of classes ( WA**Tags) to do so.. Builders in dynamic manner > use doesNotUnderstand: construct to generate the stream.. While it may seem desirable to have an API that uses #doesNotUnderstand: (or its equivalent in other languages) to facilitate markup generation by accepting arbitrary messages and taking them to be the names of tags, this approach is not a good idea for at least two reasons: 1) namespace prefixes cannot be specified in this way, as ":" is not a legal character within identifiers in Smalltalk (or in most other languages, for that matter), and 2) unary messages intended to be treated as tag names can collide with already-defined unary messages in the writer class or its superclasses.

July 6, 2010

Re: [Pharo-project] Issue 2635 - methods recategorization

by Pavel Krivanek

On Tue, Jul 6, 2010 at 11:05 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: >>> 2) e.g you move somethings to *Tools and some things to *Tools-Explorer >>> is that not going to create the same problem that happened to System, >>> with both parent and child packages defined in the same image? >> >> There's only one MC package named Tools and this package is not >> splitted. But we may make future split of this package easier if we >> will use a category name Tools-Base (or more fitting one) instead of >> Tools. >> > > ok fair enough. but if i look in #12038 there appear a few cases: > Graphics-Stef.256 > Graphics-* > > Multilingual-Markus.2 > Multilingual-* At least the Multilingual package is automatically registered because of one method in the Character class and the fix is already mentioned in this thread. However I have no idea why MC registers automatically the Graphics package Cheers, -- Pavel > > this needs fixing before applying more recategorisation? > > > thanks, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 6, 2010

Re: [Pharo-project] Issue 2635 - methods recategorization

by Michael Roberts

>> 2) e.g you move somethings to *Tools and some things to *Tools-Explorer >> is that not going to create the same problem that happened to System, >> with both parent and child packages defined in the same image? > > There's only one MC package named Tools and this package is not > splitted. But we may make future split of this package easier if we > will use a category name Tools-Base (or more fitting one) instead of > Tools. > ok fair enough. but if i look in #12038 there appear a few cases: Graphics-Stef.256 Graphics-* Multilingual-Markus.2 Multilingual-* this needs fixing before applying more recategorisation? thanks, Mike

July 6, 2010

Re: [Pharo-project] Markup Builder in Smalltalk (XMLWriter)

by jaayer

---- On Tue, 06 Jul 2010 03:19:48 -0700 Torsten Bergmann wrote ---- >Just check "XMLWriter-tbn.5" which can be found in "http://squeaksource.com/PharoGoodies/" > >------------------------------------------------------ >|writer| >writer := XMLTagWriter xml. >writer comment: 'A new xml file'. >writer tag: 'package' with: [ >Â Â Â Â writer cData: 'name' with: 'XMLWriter'. >]. >writer contents > >returns > > > > > > >------------------------------------------------------ > >You can also access the stream (writer stream). >Indenting is not yet working fully but at least >it should give you idea. Check out the test cases for >more. > >I once saw such an XMLWriter written by Ernest Micklei >in VAST (credits for the idea) and rebuilt it in Pharo. > >Bye >T. >-- >GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. >Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl > >_______________________________________________ >Pharo-project mailing list >Pharo-project(a)lists.gforge.inria.fr >http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > The next version of XMLSupport will feature an XMLWriter with an API similar to XMLTagWriter. I had decided a few weeks that any API using explicit start/end methods was unsmalltalk-like and should be replaced with one based on execute-around methods, though I was unaware of XMLTagWriter and instead modeled the API loosely on Seaside's HTML generation. You now send XMLWriter messages that create markup-writing objects for the parts of a document. These objects can then be configured using messages like #attributeAt:put: and written to the document explicitly with a serialization message (which typically accepts content) or implicitly by creating another markup writer after it. The new API looks like this: | writer | ((writer := XMLWriter new) enablePrettyPrinting; xmlDeclaration; tag: 'foo') xmlnsAt: 'foo' put: 'http://foo'; attributeAt: 'a' put: 'one'; attributeAt: 'b' put: 'two'; content: [ writer tag: 'bar' content: [ (writer string: 'test'; tag: 'baz'; tag: 'foobar') content: 'test']] which produces: <?xml version="1.0" encoding="UTF-8"?> <foo xmlns:foo="http://foo" a="one" b="two"> <bar>test<baz /> <foobar>test</foobar> </bar> </foo>

July 6, 2010

Re: [Pharo-project] Morph rendering with antialiasing

by Henrik Sperre Johansen

On 06.07.2010 22:28, Denis Kudriashov wrote: > Hello. > > Is somebody implement morphs rendering with antialiasing? > Maybe it is already possible? > > In practice I need circle button. But without antialiasing it seems > really ugly. > > If there is no existed solution. How do you think It can be implemented? > > I know that fonts rendered with antialiasing. How its approach can be > applyed for morphs? > > I notice browser buttons (senders, implementors..) has rounded > corners. And its nice rendered. What secrete? Can it be done for any > morph corner rounding Using shape rendering primitives, no. Balloon does AA, though you'll have problems with small thin lines (which is why smaller sized TTFonts doesn't exactly look stellar). The "secret" method used by both fonts and browser buttons is to instead display AA'd bitmaps (ie. you use the alpha channel), instead of rendering shapes. Cheers, Henry

July 6, 2010

Re: [Pharo-project] feedup of selecting doit or typing " above and below expressions in comments?

by Lukas Renggli

>> Another thing that is related to the above and to the different browsers: >> >> In Core: When I select a method I can choose "Senders of..." >> Â Â Â Â and "Implementors of..." to either search for senders/implementors >> Â Â Â Â of the selected method AND the messages sent into the selected >> Â Â Â Â method. >> >> In Pharo: with OB I can just do "senders" and "implementors" >> Â Â Â Â Â which looks for the senders/implementors of the selected method >> Â Â Â Â Â One is NOT able to search for senders/implementors of >> Â Â Â Â Â the messages sent within the selected method. >> Â Â Â Â Â Here I have to select the entire selector which is >> Â Â Â Â Â time consuming as described above. > > enter a bug entry. This was removed on request of Stef and I completely agree on this: for me it is time consuming to be forced to search for the selector in a sorted list when the selector is written/selected right in front of me. >> So Pharo with OB is (compared to core) really a step backwards here. > > I imagine that the enh I did also to get Cmd-M on class name browsing the class and Cmd-B on > selectors do an implementors should also be pushed in OB. The Cmd-B was always part of OB, I've done the same for Cmd-M. Also I updated the edit pane menu to match the one of the standard browser. Lukas -- Lukas Renggli www.lukas-renggli.ch

July 6, 2010

Re: [Pharo-project] Issue 2635 - methods recategorization

by Pavel Krivanek

code: MethodReference organization moveCategory: '*Kernel-Traits' to: '*Traits-Kernel'. LRUCache organization moveCategory: '*Polymorph-Widgets-override' to: 'accessing'. Project class organization moveCategory: 'utilities' to: '*Morphic'. Character organization moveCategory: '*Multilingual' to: '*Multilingual-Encodings'. TranscriptStream organization moveCategory: 'toolbuilder' to: '*ToolBuilder-Kernel'. TranscriptStream class organization moveCategory: 'toolbuilder' to: '*ToolBuilder-Kernel'. description: MethodReference organization moveCategory: '*Kernel-Traits' to: '*Traits-Kernel'. - swap package name parts to a more logical ownership. It contains only a method actualClass that has no other kernel implementation. Both packages will be in the kernel image. LRUCache organization moveCategory: '*Polymorph-Widgets-override' to: 'accessing'. - only one method. Declared as override but has no old version in the history and has general functionality Project class organization moveCategory: 'utilities' to: '*Morphic'. - all methods have no real senders or are called only from Morphic Character organization moveCategory: '*Multilingual' to: '*Multilingual-Encodings'. - only fix MC package name TranscriptStream organization moveCategory: 'toolbuilder' to: '*ToolBuilder-Kernel'. - single method buildWith:, used only for the Toolbuilder TranscriptStream class organization moveCategory: 'toolbuilder' to: '*ToolBuilder-Kernel'. - the same

July 6, 2010