September 2008 - Pharo-dev - lists.pharo.org

[Pharo-project] Throwing out the windowing support from core VM features

by Igor Stasenko

Hello, i'd like to discuss with you this quite radical idea. I , in particular, not happy that windowing in squeak VM is mandatory. Sure, you can run VM with -headless (or whatever), but this actually not solving anything, since VM still in much of control, how to deal with squeak window and how to manage messages etc. What i would like to see, is to completely detach windowing functionality into a separate VM plugin, making sure that: a) VM can be built w/o this plugin b) a language side is in total control to decide whether create and use window & display or not. This would require to deprecate some of 'blue book' primitives, which coming as built-in VM features , such as: - displayBits & friends - fullDisplayUpdate - keyboard & mouse event handling The point is, that squeak grew out on many platforms and embedded devices. Some of them don't have a usual input devices, like keyboard & mouse, so it is completely pointless to require VM to support I/O with these devices as mandatory option. Same for display. I would be happy to have full control at language side whether i need display or not , instead of having it 'for free' from a start and then using workarounds to not show/use it using command line (while language side still thinks its present). -- Best regards, Igor Stasenko AKA sig.

Sept. 13, 2008

Re: [Pharo-project] Re: Building VM Freetype

by StÃ©phane Ducasse

Sorry that you refer to just instruction. Then I would suggest that you register to the fgorge.inria.fr use team ADAM when creating yur account once you have done that I will add you to the pharo project then we will be able to use the svn and the uploads Stef On Sep 13, 2008, at 8:36 AM, Igor Stasenko wrote: > 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >>> Okay, who wants the VM? And where i can put the stuff + >>> instructions + >>> blablabla? >> >> You can use the code google page for that. > > Can you be more specific? > After reading through http://code.google.com/p/pharo/ > can't find any directions, where i can put a pre-built VM, or do any > upload. I doubt that pharo inbox at squeaksource is appropriate place > for VM binaries. > >> >> Stef > > > -- > Best regards, > Igor Stasenko AKA sig. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 13, 2008

Re: [Pharo-project] Re: Building VM Freetype

by Igor Stasenko

2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Okay, who wants the VM? And where i can put the stuff + instructions + >> blablabla? > > You can use the code google page for that. Can you be more specific? After reading through http://code.google.com/p/pharo/ can't find any directions, where i can put a pre-built VM, or do any upload. I doubt that pharo inbox at squeaksource is appropriate place for VM binaries. > > Stef -- Best regards, Igor Stasenko AKA sig.

Sept. 13, 2008

Re: [Pharo-project] Re: Building VM Freetype

by Igor Stasenko

2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > I hope other will answer but I thought that we could have a pluggin > and bundle in the deployed packages. > The idea for pharo is to have a similar setup than seaside a one click app > so the > vm and its plugin would be there (but may be the plugin should not be in the > image). Plugin is built-in in the VM. But freetype library is coming as separate dynamic library. Is this ok? There can be another option, but it would require to change the plugin code - to not link VM with import lib, but to load freetype.dll on demand. The plugin can simply check if this .dll available and start using it, or if not - fail to initialize, telling the system that plugin functionality is not available. > > Mike or john? On sophie how did you manage that the freetype bundle could > not be present? > Actually, to build a plugin, you need just headers + freetype.def file which then can be used to create the imports library from it. Building a freetype.dll can be completely separate process. I can remove dependency from freetype.lib, and leave only a freetype.def and create import lib by own, when making VM. But this is not safe, because now you must guarantee that you using correct .dll. (well, you need to guarantee it in either case). > If I remember correctly some people on squeak have been recompiling it for > 64 bits > >> I done with it. >> The resulting VM will not start without freetype.dll. >> Should i link it statically? But then you should hone their license >> stuff... >> >> Also, building freetype on windoze impossible using gnutools which >> used for building VM. >> It's make simply can't understand some things, which i assume appear >> in later make versions. >> So, i building freetype using my msys/mingw environment, and then >> simply producing >> - freetype.lib (imports library) >> - freetype.dll >> >> or maybe, i wrong, maybe it can be built using gnutools, but this >> would require too much voodoo dancing. >> it would be cool to make it cleanly build w/o manual work, but i'm not >> high expert in makefiles black voodoo. >> >> Okay, who wants the VM? And where i can put the stuff + instructions + >> blablabla? > > You can use the code google page for that. > > Stef >> >> >> 2008/9/12 Igor Stasenko <siguctua(a)gmail.com>: >>> >>> 2008/9/12 Igor Stasenko <siguctua(a)gmail.com>: >>>> >>>> As always, things not working out of the box. >>>> >>>> - VM builds from unzipped VM sources OK >>>> - but for building with VMMaker generated sources, had to fix 'gnuify' >>>> file to make a clean build >>>> >>>> i dreaming to build vm straight from squeak, without horrid makefiles. >>>> I heard that Keith did a 'Bob' tool which can be used as a kind of >>>> make utility. >>>> But i think, to fully replace makefiles, it needs an OSProcessPlugin >>>> to be able to interact with OS/shell. >>>> >>> >>> Next step, tried to load freetype plugin.... >>> http://source.impara.de/freetype/Freetype-Plugin-JMM.53.mcz >>> http://source.impara.de/freetype/Freetype-Plugin-tween.51.mcz >>> >>> and guess what? YES! It can't be loaded! :) >>> >>> MC complains about following: >>> >>> This package depends on the following classes: >>> FT2Constants >>> >>> The FT2Constants is the pool dictionary used by plugin. But not >>> defined within package. >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> <fonts.jpg>_______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Sept. 13, 2008

[Pharo-project] Re: Building VM Freetype

by StÃ©phane Ducasse

I hope other will answer but I thought that we could have a pluggin and bundle in the deployed packages. The idea for pharo is to have a similar setup than seaside a one click app so the vm and its plugin would be there (but may be the plugin should not be in the image). Mike or john? On sophie how did you manage that the freetype bundle could not be present? If I remember correctly some people on squeak have been recompiling it for 64 bits > I done with it. > The resulting VM will not start without freetype.dll. > Should i link it statically? But then you should hone their license > stuff... > > Also, building freetype on windoze impossible using gnutools which > used for building VM. > It's make simply can't understand some things, which i assume appear > in later make versions. > So, i building freetype using my msys/mingw environment, and then > simply producing > - freetype.lib (imports library) > - freetype.dll > > or maybe, i wrong, maybe it can be built using gnutools, but this > would require too much voodoo dancing. > it would be cool to make it cleanly build w/o manual work, but i'm not > high expert in makefiles black voodoo. > > Okay, who wants the VM? And where i can put the stuff + instructions + > blablabla? You can use the code google page for that. Stef > > > 2008/9/12 Igor Stasenko <siguctua(a)gmail.com>: >> 2008/9/12 Igor Stasenko <siguctua(a)gmail.com>: >>> As always, things not working out of the box. >>> >>> - VM builds from unzipped VM sources OK >>> - but for building with VMMaker generated sources, had to fix >>> 'gnuify' >>> file to make a clean build >>> >>> i dreaming to build vm straight from squeak, without horrid >>> makefiles. >>> I heard that Keith did a 'Bob' tool which can be used as a kind of >>> make utility. >>> But i think, to fully replace makefiles, it needs an OSProcessPlugin >>> to be able to interact with OS/shell. >>> >> >> Next step, tried to load freetype plugin.... >> http://source.impara.de/freetype/Freetype-Plugin-JMM.53.mcz >> http://source.impara.de/freetype/Freetype-Plugin-tween.51.mcz >> >> and guess what? YES! It can't be loaded! :) >> >> MC complains about following: >> >> This package depends on the following classes: >> FT2Constants >> >> The FT2Constants is the pool dictionary used by plugin. But not >> defined within package. >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > <fonts.jpg>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 13, 2008

Re: [Pharo-project] how to improve the menus

by StÃ©phane Ducasse

Lukas sorry my question was not clearly stated: how can we get some important menus in OB such as look for code containing string and a couple of others. Stef On Sep 12, 2008, at 11:55 PM, Lukas Renggli wrote: >> So who is responsible for the menus in OB? > > The menus in the columns come from OB. > > The menu in the edit pane comes from Squeak though and certain > commands are intercepted by OB. I think it would make sense if OB > changed that and provided the whole menu by itself. > > 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 >

Sept. 13, 2008

Re: [Pharo-project] Re: how to load sophie

by StÃ©phane Ducasse

txxxx :) On Sep 12, 2008, at 9:14 PM, Andrew Tween wrote: > > "StÃ©phane Ducasse" <Stephane.Ducasse(a)inria.fr> wrote in message news:7916FF5C-0CA0-4562-A69F-65B4B54C8067@inria.fr > ... >> Hi mike >> >> I would like to browse the code but not only from MC but in a real >> image. >> How do I get sophie loaded (even in 3.8 or others). >> In particular I would like to see how URI are used in the code. > > If you don't want to install it all from scratch then... > > If you download Sophie from www.sophieproject.org (http://www.sophieproject.org/download > ) > and run it, then the File>>Exit menu item will close the Sophie > application but leave the Squeak image running so you can open > browsers etc. > > Cheers, > Andy > >> >> Setf > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 13, 2008

Building VM (Was: Re: [Pharo-project] Re: Hello everyone!)

by Igor Stasenko

in original message i attached the screenshot, showing fonts rendered by squeak.. but image is a bit too big for mailing list (150k) ------ I done with it. The resulting VM will not start without freetype.dll. Should i link it statically? But then you should hone their license stuff... Also, building freetype on windoze impossible using gnutools which used for building VM. It's make simply can't understand some things, which i assume appear in later make versions. So, i building freetype using my msys/mingw environment, and then simply producing - freetype.lib (imports library) - freetype.dll or maybe, i wrong, maybe it can be built using gnutools, but this would require too much voodoo dancing. it would be cool to make it cleanly build w/o manual work, but i'm not high expert in makefiles black voodoo. Okay, who wants the VM? And where i can put the stuff + instructions + blablabla? 2008/9/12 Igor Stasenko <siguctua(a)gmail.com>: > 2008/9/12 Igor Stasenko <siguctua(a)gmail.com>: >> As always, things not working out of the box. >> >> - VM builds from unzipped VM sources OK >> - but for building with VMMaker generated sources, had to fix 'gnuify' >> file to make a clean build >> >> i dreaming to build vm straight from squeak, without horrid makefiles. >> I heard that Keith did a 'Bob' tool which can be used as a kind of >> make utility. >> But i think, to fully replace makefiles, it needs an OSProcessPlugin >> to be able to interact with OS/shell. >> > > Next step, tried to load freetype plugin.... > http://source.impara.de/freetype/Freetype-Plugin-JMM.53.mcz > http://source.impara.de/freetype/Freetype-Plugin-tween.51.mcz > > and guess what? YES! It can't be loaded! :) > > MC complains about following: > > This package depends on the following classes: > FT2Constants > > The FT2Constants is the pool dictionary used by plugin. But not > defined within package. > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Sept. 13, 2008

Re: Building VM (Was: Re: [Pharo-project] Re: Hello everyone!)

by Igor Stasenko

btw, after changing the title font of system window, corner grips AGAIN positioned badly. I thought it was fixed long ago... 2008/9/13 Igor Stasenko <siguctua(a)gmail.com>: > I done with it. > The resulting VM will not start without freetype.dll. > Should i link it statically? But then you should hone their license stuff... > > Also, building freetype on windoze impossible using gnutools which > used for building VM. > It's make simply can't understand some things, which i assume appear > in later make versions. > So, i building freetype using my msys/mingw environment, and then > simply producing > - freetype.lib (imports library) > - freetype.dll > > or maybe, i wrong, maybe it can be built using gnutools, but this > would require too much voodoo dancing. > it would be cool to make it cleanly build w/o manual work, but i'm not > high expert in makefiles black voodoo. > > Okay, who wants the VM? And where i can put the stuff + instructions + > blablabla? > > 2008/9/12 Igor Stasenko <siguctua(a)gmail.com>: >> 2008/9/12 Igor Stasenko <siguctua(a)gmail.com>: >>> As always, things not working out of the box. >>> >>> - VM builds from unzipped VM sources OK >>> - but for building with VMMaker generated sources, had to fix 'gnuify' >>> file to make a clean build >>> >>> i dreaming to build vm straight from squeak, without horrid makefiles. >>> I heard that Keith did a 'Bob' tool which can be used as a kind of >>> make utility. >>> But i think, to fully replace makefiles, it needs an OSProcessPlugin >>> to be able to interact with OS/shell. >>> >> >> Next step, tried to load freetype plugin.... >> http://source.impara.de/freetype/Freetype-Plugin-JMM.53.mcz >> http://source.impara.de/freetype/Freetype-Plugin-tween.51.mcz >> >> and guess what? YES! It can't be loaded! :) >> >> MC complains about following: >> >> This package depends on the following classes: >> FT2Constants >> >> The FT2Constants is the pool dictionary used by plugin. But not >> defined within package. >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Sept. 13, 2008

Re: Building VM (Was: Re: [Pharo-project] Re: Hello everyone!)

by Igor Stasenko

I done with it. The resulting VM will not start without freetype.dll. Should i link it statically? But then you should hone their license stuff... Also, building freetype on windoze impossible using gnutools which used for building VM. It's make simply can't understand some things, which i assume appear in later make versions. So, i building freetype using my msys/mingw environment, and then simply producing - freetype.lib (imports library) - freetype.dll or maybe, i wrong, maybe it can be built using gnutools, but this would require too much voodoo dancing. it would be cool to make it cleanly build w/o manual work, but i'm not high expert in makefiles black voodoo. Okay, who wants the VM? And where i can put the stuff + instructions + blablabla? 2008/9/12 Igor Stasenko <siguctua(a)gmail.com>: > 2008/9/12 Igor Stasenko <siguctua(a)gmail.com>: >> As always, things not working out of the box. >> >> - VM builds from unzipped VM sources OK >> - but for building with VMMaker generated sources, had to fix 'gnuify' >> file to make a clean build >> >> i dreaming to build vm straight from squeak, without horrid makefiles. >> I heard that Keith did a 'Bob' tool which can be used as a kind of >> make utility. >> But i think, to fully replace makefiles, it needs an OSProcessPlugin >> to be able to interact with OS/shell. >> > > Next step, tried to load freetype plugin.... > http://source.impara.de/freetype/Freetype-Plugin-JMM.53.mcz > http://source.impara.de/freetype/Freetype-Plugin-tween.51.mcz > > and guess what? YES! It can't be loaded! :) > > MC complains about following: > > This package depends on the following classes: > FT2Constants > > The FT2Constants is the pool dictionary used by plugin. But not > defined within package. > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Sept. 13, 2008

Re: [Pharo-project] how to improve the menus

by Lukas Renggli

> So who is responsible for the menus in OB? The menus in the columns come from OB. The menu in the edit pane comes from Squeak though and certain commands are intercepted by OB. I think it would make sense if OB changed that and provided the whole menu by itself. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 12, 2008

Re: [Pharo-project] Re: how to load sophie

by Michael Rueger

Andrew Tween wrote: > If you don't want to install it all from scratch then... which takes a patched 3.8/Tweak image and about 90 minutes... > If you download Sophie from www.sophieproject.org > (http://www.sophieproject.org/download) > and run it, then the File>>Exit menu item will close the Sophie > application but leave the Squeak image running so you can open browsers You beat me to it :-) Michael

Sept. 12, 2008

[Pharo-project] Re: how to load sophie

by Andrew Tween

"StÃ©phane Ducasse" <Stephane.Ducasse(a)inria.fr> wrote in message news:7916FF5C-0CA0-4562-A69F-65B4B54C8067@inria.fr... > Hi mike > > I would like to browse the code but not only from MC but in a real image. > How do I get sophie loaded (even in 3.8 or others). > In particular I would like to see how URI are used in the code. If you don't want to install it all from scratch then... If you download Sophie from www.sophieproject.org (http://www.sophieproject.org/download) and run it, then the File>>Exit menu item will close the Sophie application but leave the Squeak image running so you can open browsers etc. Cheers, Andy > > Setf

Sept. 12, 2008

[Pharo-project] how to load sophie

by StÃ©phane Ducasse

Hi mike I would like to browse the code but not only from MC but in a real image. How do I get sophie loaded (even in 3.8 or others). In particular I would like to see how URI are used in the code. Setf

Sept. 12, 2008

[Pharo-project] show bytecode menu -> DNU

by StÃ©phane Ducasse

Hi if one of you could have a look at the menu item show bytecode. Stef

Sept. 12, 2008

Re: [Pharo-project] About fixes for noury and other

by StÃ©phane Ducasse

Noury I harvested your classBuilder fixes. For the MC related ones, could you package them separately and in a way that merge is working well Then post them in the bugtracking and that we can ask lukas or adrian to have a look? Tx > StÃ©f, > > On 11 sept. 08, at 21:32, Noury Bouraqadi wrote: > >> On 11 sept. 08, at 09:44, StÃ©phane Ducasse wrote: >> >>> Hi noury >>> >>> I started to harvest your fixes and I learned something :) >>> when most of your fixes are about extending or changing a package >>> just publish a new version of that package. This way I can use the >>> merge tool >>> and be much more efficient, do not create a specific package with >>> specific class extension >>> for it else I have to modify everything by hand. >>> >> This sounds like a cleaner way indeed. >> If you didn't finish harvesting it, I can split different changes >> as you suggest. >> > Did you harvested my previous fixes ? > Cause I added an extra bug fix (attached) to the class builder to > avoid the creation of "zombie" classes (classes not in the > SystemDictionary => Memory leak) when class variable names are > lowercase. The test > > BTW, where one can check to see if a package has been harvested? > > Noury > ------------------------------------------------------------------ > Dr. Noury Bouraqadi - Enseignant/Chercheur > Responsable de l'enseignement de l'informatique > ARMINES - Ecole des Mines de Douai - Dept. I.A. > http://vst.ensm-douai.fr/noury > > European Smalltalk Users Group Board > http://www.esug.org > ------------------------------------------------------------------ > > <fixClassVarsVarlidation-Noury12sept2008.cs> > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 12, 2008

Re: [Pharo-project] About fixes for noury and other

by Noury Bouraqadi

I sent the wrong version of the changeset in my previous email. Attached the right one. Noury On 12 sept. 08, at 19:18, Noury Bouraqadi wrote: > StÃ©f, > > On 11 sept. 08, at 21:32, Noury Bouraqadi wrote: > >> On 11 sept. 08, at 09:44, StÃ©phane Ducasse wrote: >> >>> Hi noury >>> >>> I started to harvest your fixes and I learned something :) >>> when most of your fixes are about extending or changing a package >>> just publish a new version of that package. This way I can use the >>> merge tool >>> and be much more efficient, do not create a specific package with >>> specific class extension >>> for it else I have to modify everything by hand. >>> >> This sounds like a cleaner way indeed. >> If you didn't finish harvesting it, I can split different changes >> as you suggest. >> > Did you harvested my previous fixes ? > Cause I added an extra bug fix (attached) to the class builder to > avoid the creation of "zombie" classes (classes not in the > SystemDictionary => Memory leak) when class variable names are > lowercase. The test > > BTW, where one can check to see if a package has been harvested? > > Noury > ------------------------------------------------------------------ > Dr. Noury Bouraqadi - Enseignant/Chercheur > Responsable de l'enseignement de l'informatique > ARMINES - Ecole des Mines de Douai - Dept. I.A. > http://vst.ensm-douai.fr/noury > > European Smalltalk Users Group Board > http://www.esug.org > ------------------------------------------------------------------ > > <fixClassVarsVarlidation-Noury12sept2008.cs> Noury Bouraqadi ------------------------------------------------------------------ Dr. Noury Bouraqadi - Enseignant/Chercheur Responsable de l'enseignement de l'informatique ARMINES - Ecole des Mines de Douai - Dept. I.A. http://vst.ensm-douai.fr/noury European Smalltalk Users Group Board http://www.esug.org ------------------------------------------------------------------

Sept. 12, 2008

Re: [Pharo-project] About fixes for noury and other

by StÃ©phane Ducasse

Normally when you enter a bug fix in the issue I will close it when it is harvested/refused.... I will do the classbuilder related ones now. Stef On Sep 12, 2008, at 7:18 PM, Noury Bouraqadi wrote: > StÃ©f, > > On 11 sept. 08, at 21:32, Noury Bouraqadi wrote: > >> On 11 sept. 08, at 09:44, StÃ©phane Ducasse wrote: >> >>> Hi noury >>> >>> I started to harvest your fixes and I learned something :) >>> when most of your fixes are about extending or changing a package >>> just publish a new version of that package. This way I can use the >>> merge tool >>> and be much more efficient, do not create a specific package with >>> specific class extension >>> for it else I have to modify everything by hand. >>> >> This sounds like a cleaner way indeed. >> If you didn't finish harvesting it, I can split different changes >> as you suggest. >> > Did you harvested my previous fixes ? > Cause I added an extra bug fix (attached) to the class builder to > avoid the creation of "zombie" classes (classes not in the > SystemDictionary => Memory leak) when class variable names are > lowercase. The test > > BTW, where one can check to see if a package has been harvested? > > Noury > ------------------------------------------------------------------ > Dr. Noury Bouraqadi - Enseignant/Chercheur > Responsable de l'enseignement de l'informatique > ARMINES - Ecole des Mines de Douai - Dept. I.A. > http://vst.ensm-douai.fr/noury > > European Smalltalk Users Group Board > http://www.esug.org > ------------------------------------------------------------------ > > <fixClassVarsVarlidation-Noury12sept2008.cs> > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 12, 2008

Re: [Pharo-project] About fixes for noury and other

by Noury Bouraqadi

StÃ©f, On 11 sept. 08, at 21:32, Noury Bouraqadi wrote: > On 11 sept. 08, at 09:44, StÃ©phane Ducasse wrote: > >> Hi noury >> >> I started to harvest your fixes and I learned something :) >> when most of your fixes are about extending or changing a package >> just publish a new version of that package. This way I can use the >> merge tool >> and be much more efficient, do not create a specific package with >> specific class extension >> for it else I have to modify everything by hand. >> > This sounds like a cleaner way indeed. > If you didn't finish harvesting it, I can split different changes as > you suggest. > Did you harvested my previous fixes ? Cause I added an extra bug fix (attached) to the class builder to avoid the creation of "zombie" classes (classes not in the SystemDictionary => Memory leak) when class variable names are lowercase. The test BTW, where one can check to see if a package has been harvested? Noury ------------------------------------------------------------------ Dr. Noury Bouraqadi - Enseignant/Chercheur Responsable de l'enseignement de l'informatique ARMINES - Ecole des Mines de Douai - Dept. I.A. http://vst.ensm-douai.fr/noury European Smalltalk Users Group Board http://www.esug.org ------------------------------------------------------------------

Sept. 12, 2008

[Pharo-project] removing the DockingBar and TheWorldMainDockingBar

by StÃ©phane Ducasse

Hi all I was ready to remove the novice mode and I think that we should remove DockingBar and TheWorldMainDockingBar Now gary it may introduce conflicts with etoy removal. What do you think? When will you send us the etoy removal? Stef

Sept. 12, 2008

Re: [Pharo-project] how to improve the menus

by StÃ©phane Ducasse

an alternate solution is to gave up on browser and just use OB but do we get the look methods with source in it? Some of the menu items are really nice to have. So who is responsible for the menus in OB? Stef On Sep 12, 2008, at 5:43 PM, StÃ©phane Ducasse wrote: > Hi all > > I wanted to clean the code editing menu. > First I wanted to remove the novice mode preference > > Second the problem is that the workspace and the browser share the > same > menus. Do you have an idea how we can do that the browser has its > own menus? > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 12, 2008

Re: [Pharo-project] Using the new compiler...

by StÃ©phane Ducasse

>> >> > Poor guys. I was at the french border at that time (ventimiglia/ > menton) > and it was hot and there were no clouds. You must have been on the > other > site of the country :) menton is nice in february :) too much old people there: I know my grand-mother is living there and I lived there when I was a kid :) Stef

Sept. 12, 2008

[Pharo-project] how to improve the menus

by StÃ©phane Ducasse

Hi all I wanted to clean the code editing menu. First I wanted to remove the novice mode preference Second the problem is that the workspace and the browser share the same menus. Do you have an idea how we can do that the browser has its own menus? Stef

Sept. 12, 2008

Re: [Pharo-project] Re: Monticello 1.5

by StÃ©phane Ducasse

Hi matthew we wanted to see if MC1.6 (the one with actomic loader) could load the compiler fixes Compiler-md.67 available in pharoInbox We tried > HTTPSocket httpFileIn: 'installer.pbwiki.org/f/LPF.st' and it broke on us. so two requests: - could you give a try and tell us if you can load the package? - do you have a version of MC1.6 that does not really on LPF (whatever)? Stef

Sept. 12, 2008

Re: [Pharo-project] Using the new compiler...

by Alexandre Bergel

> Poor guys. I was at the french border at that time (ventimiglia/ > menton) > and it was hot and there were no clouds. You must have been on the > other > site of the country :) Arg! Do not tell me that... I was born exactly 20 km far from Menton, in Nice. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 12, 2008

Re: [Pharo-project] Using the new compiler...

by Norbert Hartl

On Sat, 2008-09-06 at 10:22 +0200, StÃ©phane Ducasse wrote: > On Sep 6, 2008, at 9:50 AM, Alexandre Bergel wrote: > > >>> AClass>>foo > >>> .... > >> > >> I do not get what you mean > >> with the old compiler you can use the name of the class in the > >> pattern? > > > > I mean having a sequence of dots in the method body. > > ah... > strange > > >>> Alexandre (who hasn't seen the sun for more than 3 weeks) > >> > >> come on it was really sunny last week-end and half of france is > >> under rain. > > > > I missed the only sunny day apparently, I was in Paris that very day. > > :) > > I pushed the kids in the garden that exact day :) > Poor guys. I was at the french border at that time (ventimiglia/menton) and it was hot and there were no clouds. You must have been on the other site of the country :) Norbert

Sept. 12, 2008

Re: [Pharo-project] Discussion summary and milestones

by Marcus Denker

On 12.09.2008, at 16:00, Norbert Hartl wrote: > On Mon, 2008-09-01 at 08:07 +0200, StÃ©phane Ducasse wrote: >> Michael >> This is not a question for us. Let us face it seriously we are not >> expert on VM building > > That is right. So this is a problem changing the code and maintaining > our own vm. It's too much work without the necessary expertise. But on > the other side the combination of vmmaker/slang/c does also not > attract > anyone to get into the vm stuff. So we would be bound to that a long > time. > > Wouldn't Spy (http://pypysqueak.blogspot.com/) be a benefit in the > long > run. I'm very interested in vm stuff (at the moment just reading). For > me it is much more attractive approach I would try to dive into. My > opinion is that it is more flexible and opens worlds like LLVM > (http://llvm.org/) and friends for us. What do you think? > The Squeak-in-python was an experiment. It it not really realistic to think that the result will be a replacement for the current vm anytime soon. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 12, 2008

Re: [Pharo-project] InstallerTest

by Damien Cassou

It's included in http://www.squeaksource.com/Testing/SUnit-kph.112.mcz On Fri, Sep 12, 2008 at 3:20 PM, Alexandre Bergel <Alexandre.Bergel(a)inria.fr> wrote: > Hi Keith, > > None of the test in InstallerTest pass. The class ClassClonerTestResource is > missing. > Any idea how to fix this? > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 12, 2008

Re: [Pharo-project] Discussion summary and milestones

by Norbert Hartl

On Mon, 2008-09-01 at 08:07 +0200, StÃ©phane Ducasse wrote: > Michael > This is not a question for us. Let us face it seriously we are not > expert on VM building That is right. So this is a problem changing the code and maintaining our own vm. It's too much work without the necessary expertise. But on the other side the combination of vmmaker/slang/c does also not attract anyone to get into the vm stuff. So we would be bound to that a long time. Wouldn't Spy (http://pypysqueak.blogspot.com/) be a benefit in the long run. I'm very interested in vm stuff (at the moment just reading). For me it is much more attractive approach I would try to dive into. My opinion is that it is more flexible and opens worlds like LLVM (http://llvm.org/) and friends for us. What do you think? > for the moment. Now we may start to build them. And yes using git > would be a good idea. > Stef > A lot of people are using git these days. So this must have something good. Norbert > > On Aug 31, 2008, at 10:54 PM, Michael Rueger wrote: > > > StÃ©phane Ducasse wrote: > > > >> It means that we should then produce our own VMs I imagine. So what > >> are the plans there? > > > > Knowing that I'm touching flame bait here, but how is the general > > consensus on continuing to use VMMaker and Slang for generating VMs? > > Alternatives could be pure C code and/or code management using Git. > > > > Michael > > > > > > _______________________________________________ > > 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

Sept. 12, 2008

[Pharo-project] Re: Building VM (Was: Re: Re: Hello everyone!)

by Andrew Tween

"Igor Stasenko" <siguctua(a)gmail.com> wrote in message news:4a5f5f320809120530j75fde46m173d7cd4297caef1@mail.gmail.com... > 2008/9/12 Igor Stasenko > <siguctua(a)gmail.com>: >> As always, things not working out of the box. >> >> - VM builds from unzipped VM sources OK >> - but for building with VMMaker generated sources, had to fix 'gnuify' >> file to make a clean build >> >> i dreaming to build vm straight from squeak, without horrid makefiles. >> I heard that Keith did a 'Bob' tool which can be used as a kind of >> make utility. >> But i think, to fully replace makefiles, it needs an OSProcessPlugin >> to be able to interact with OS/shell. >> > > Next step, tried to load freetype plugin.... > http://source.impara.de/freetype/Freetype-Plugin-JMM.53.mcz > http://source.impara.de/freetype/Freetype-Plugin-tween.51.mcz > > and guess what? YES! It can't be loaded! :) > > MC complains about following: > > This package depends on the following classes: > FT2Constants > > The FT2Constants is the pool dictionary used by plugin. But not > defined within package. Sorry. I forgot about that. The FT2Constants are in the main FreeTypePlus package - http://www.squeaksource.com/FreeTypePlus/FreeType-tween.435.mcz You should install that before installing Freetype-Plugin Cheers, Andy > > -- > Best regards, > Igor Stasenko AKA sig.

Sept. 12, 2008

[Pharo-project] InstallerTest

by Alexandre Bergel

Hi Keith, None of the test in InstallerTest pass. The class ClassClonerTestResource is missing. Any idea how to fix this? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 12, 2008

[Pharo-project] Coding session now...

by Alexandre Bergel

Dear List, Marcus, Stef and I are now doing a Pharo coding. - Stef is cleaning the list of issues in on the pharo website - I am working on making the test server. I am currently deprecating tests that popup windows Feel free to join Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 12, 2008

Re: Building VM (Was: Re: [Pharo-project] Re: Hello everyone!)

by Igor Stasenko

2008/9/12 Igor Stasenko <siguctua(a)gmail.com>: > As always, things not working out of the box. > > - VM builds from unzipped VM sources OK > - but for building with VMMaker generated sources, had to fix 'gnuify' > file to make a clean build > > i dreaming to build vm straight from squeak, without horrid makefiles. > I heard that Keith did a 'Bob' tool which can be used as a kind of > make utility. > But i think, to fully replace makefiles, it needs an OSProcessPlugin > to be able to interact with OS/shell. > Next step, tried to load freetype plugin.... http://source.impara.de/freetype/Freetype-Plugin-JMM.53.mcz http://source.impara.de/freetype/Freetype-Plugin-tween.51.mcz and guess what? YES! It can't be loaded! :) MC complains about following: This package depends on the following classes: FT2Constants The FT2Constants is the pool dictionary used by plugin. But not defined within package. -- Best regards, Igor Stasenko AKA sig.

Sept. 12, 2008

Building VM (Was: Re: [Pharo-project] Re: Hello everyone!)

by Igor Stasenko

As always, things not working out of the box. - VM builds from unzipped VM sources OK - but for building with VMMaker generated sources, had to fix 'gnuify' file to make a clean build i dreaming to build vm straight from squeak, without horrid makefiles. I heard that Keith did a 'Bob' tool which can be used as a kind of make utility. But i think, to fully replace makefiles, it needs an OSProcessPlugin to be able to interact with OS/shell. 2008/9/12 Igor Stasenko <siguctua(a)gmail.com>: > 2008/9/12 Andrew Tween <amtween(a)hotmail.com>: >> Hi, >> "Igor Stasenko" <siguctua(a)gmail.com> wrote in message >> news:4a5f5f320809111213v2eec6200te2dcab47f03f6a58@mail.gmail.com... >>> >>> 2008/9/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> >>>> I'm confused you do not use VMMaker for Hydra? >>>>> >>>>>> yes keep it there >>>>>> we have too much mailing-lists >>>>>> >>>>>> So can you do a unix/windows VM with the freeType pluging? >>>>>> >>>>> Sure i can, just give me details which/where i should take VMMaker & >>>>> platform sources & plugin. >>>> >>>> I thought that all this information was in the VM repository. >>>> >>> Can you point me to that VM repository? >>> >>> VMMaker are available on: >>> - squeakmap, >>> - http://www.squeaksource.com/VMMaker.html >>> - http://source.squeakfoundation.org (now is empty ,strange) >>> >>> The VM sources, are available on squeakvm.org SVN. >>> Is this places correct? >> >> For windows, you can use the source release from Squeak.org... >> http://www.squeakvm.org/win32/release/SqueakVM-Win32-3.10.7-src.zip >> >> Not sure about Linux. >> >>> >>> Also, where i can get freetype plugin and its platform sources? >> >> http://source.impara.de/freetype/Freetype-Plugin-JMM.53.mcz is the latest, >> but you might have to use an earlier version from the same repository - e.g. >> http://source.impara.de/freetype/Freetype-Plugin-tween.51.mcz >> >> For a long time, I have used the FT2Plugins that ship with Sophie. >> I think that we will need to get platform sources, makefiles etc. from the >> Sophie developers. >> >> The Windows ft2plugin.dll dynamically links to freetype6.dll . >> Once again we may need the Sophie developers help if we want to rebuild >> freetype6.dll (to move to a later version of Freetype, for example). >> >> You can find the freetype6.dll in >> http://dev.sophieproject.org/downloads/releases/Sophie1.0.3.zip , or >> alternatively in my plugins installer sar (zip) file >> http://map.squeak.org/accountbyid/46dcf6af-067d-43e3-9fc9-d7010e067153/file… >> >> The source for FreeType itself is on sourceforge - >> http://sourceforge.net/project/showfiles.php?group_id=3157&package_id=3121 >> The freetype6.dll was built from version 2.2.1 of FreeType. >> >> The Linux FT2Plugin dynamically links to the libfreetype.so.6 library that >> ships with most (all?) linux distributions. >> >> The bitblt modifications are currently in a changeset that should be >> installed after installing vmmaker - you can get it here... >> http://www.zen61439.zen.co.uk/bak/bitBlt_plugin_enhancements/FreeTypeBitBlt… >> (In a few days time this url will no longer work as I am changing ISP - so I >> have also attached it to this post) >> >> I know that this is all quite complicated and confusing, and it may take >> some time to get all the pieces of the puzzle in place. >> Thank you for your interest and help. >> > > No, it is not complicated. You described the picture quite understandable. > So, we have everything, except F2P plugin platform sources. > Any idea, who i should contact with, to get them? > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Sept. 12, 2008

Re: [Pharo-project] Re: Hello everyone!

by StÃ©phane Ducasse

>> > > No, it is not complicated. You described the picture quite > understandable. > So, we have everything, except F2P plugin platform sources. > Any idea, who i should contact with, to get them? For sophie contact mike and john m.rueger(a)acm.org and johnmci(a)smalltalkconsulting.com

Sept. 12, 2008

Re: [Pharo-project] Re: Hello everyone!

by Igor Stasenko

2008/9/12 Andrew Tween <amtween(a)hotmail.com>: > Hi, > "Igor Stasenko" <siguctua(a)gmail.com> wrote in message > news:4a5f5f320809111213v2eec6200te2dcab47f03f6a58@mail.gmail.com... >> >> 2008/9/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>> I'm confused you do not use VMMaker for Hydra? >>>> >>>>> yes keep it there >>>>> we have too much mailing-lists >>>>> >>>>> So can you do a unix/windows VM with the freeType pluging? >>>>> >>>> Sure i can, just give me details which/where i should take VMMaker & >>>> platform sources & plugin. >>> >>> I thought that all this information was in the VM repository. >>> >> Can you point me to that VM repository? >> >> VMMaker are available on: >> - squeakmap, >> - http://www.squeaksource.com/VMMaker.html >> - http://source.squeakfoundation.org (now is empty ,strange) >> >> The VM sources, are available on squeakvm.org SVN. >> Is this places correct? > > For windows, you can use the source release from Squeak.org... > http://www.squeakvm.org/win32/release/SqueakVM-Win32-3.10.7-src.zip > > Not sure about Linux. > >> >> Also, where i can get freetype plugin and its platform sources? > > http://source.impara.de/freetype/Freetype-Plugin-JMM.53.mcz is the latest, > but you might have to use an earlier version from the same repository - e.g. > http://source.impara.de/freetype/Freetype-Plugin-tween.51.mcz > > For a long time, I have used the FT2Plugins that ship with Sophie. > I think that we will need to get platform sources, makefiles etc. from the > Sophie developers. > > The Windows ft2plugin.dll dynamically links to freetype6.dll . > Once again we may need the Sophie developers help if we want to rebuild > freetype6.dll (to move to a later version of Freetype, for example). > > You can find the freetype6.dll in > http://dev.sophieproject.org/downloads/releases/Sophie1.0.3.zip , or > alternatively in my plugins installer sar (zip) file > http://map.squeak.org/accountbyid/46dcf6af-067d-43e3-9fc9-d7010e067153/file… > > The source for FreeType itself is on sourceforge - > http://sourceforge.net/project/showfiles.php?group_id=3157&package_id=3121 > The freetype6.dll was built from version 2.2.1 of FreeType. > > The Linux FT2Plugin dynamically links to the libfreetype.so.6 library that > ships with most (all?) linux distributions. > > The bitblt modifications are currently in a changeset that should be > installed after installing vmmaker - you can get it here... > http://www.zen61439.zen.co.uk/bak/bitBlt_plugin_enhancements/FreeTypeBitBlt… > (In a few days time this url will no longer work as I am changing ISP - so I > have also attached it to this post) > > I know that this is all quite complicated and confusing, and it may take > some time to get all the pieces of the puzzle in place. > Thank you for your interest and help. > No, it is not complicated. You described the picture quite understandable. So, we have everything, except F2P plugin platform sources. Any idea, who i should contact with, to get them? -- Best regards, Igor Stasenko AKA sig.

Sept. 12, 2008

[Pharo-project] Re: Hello everyone!

by Andrew Tween

Hi, "Igor Stasenko" <siguctua(a)gmail.com> wrote in message news:4a5f5f320809111213v2eec6200te2dcab47f03f6a58@mail.gmail.com... > 2008/9/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> I'm confused you do not use VMMaker for Hydra? >>> >>>> yes keep it there >>>> we have too much mailing-lists >>>> >>>> So can you do a unix/windows VM with the freeType pluging? >>>> >>> Sure i can, just give me details which/where i should take VMMaker & >>> platform sources & plugin. >> >> I thought that all this information was in the VM repository. >> > Can you point me to that VM repository? > > VMMaker are available on: > - squeakmap, > - http://www.squeaksource.com/VMMaker.html > - http://source.squeakfoundation.org (now is empty ,strange) > > The VM sources, are available on squeakvm.org SVN. > Is this places correct? For windows, you can use the source release from Squeak.org... http://www.squeakvm.org/win32/release/SqueakVM-Win32-3.10.7-src.zip Not sure about Linux. > > Also, where i can get freetype plugin and its platform sources? http://source.impara.de/freetype/Freetype-Plugin-JMM.53.mcz is the latest, but you might have to use an earlier version from the same repository - e.g. http://source.impara.de/freetype/Freetype-Plugin-tween.51.mcz For a long time, I have used the FT2Plugins that ship with Sophie. I think that we will need to get platform sources, makefiles etc. from the Sophie developers. The Windows ft2plugin.dll dynamically links to freetype6.dll . Once again we may need the Sophie developers help if we want to rebuild freetype6.dll (to move to a later version of Freetype, for example). You can find the freetype6.dll in http://dev.sophieproject.org/downloads/releases/Sophie1.0.3.zip , or alternatively in my plugins installer sar (zip) file http://map.squeak.org/accountbyid/46dcf6af-067d-43e3-9fc9-d7010e067153/file… The source for FreeType itself is on sourceforge - http://sourceforge.net/project/showfiles.php?group_id=3157&package_id=3121 The freetype6.dll was built from version 2.2.1 of FreeType. The Linux FT2Plugin dynamically links to the libfreetype.so.6 library that ships with most (all?) linux distributions. The bitblt modifications are currently in a changeset that should be installed after installing vmmaker - you can get it here... http://www.zen61439.zen.co.uk/bak/bitBlt_plugin_enhancements/FreeTypeBitBlt… (In a few days time this url will no longer work as I am changing ISP - so I have also attached it to this post) I know that this is all quite complicated and confusing, and it may take some time to get all the pieces of the puzzle in place. Thank you for your interest and help. Cheers, Andy > > >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -------------------------------------------------------------------------------- > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 12, 2008

Re: [Pharo-project] FileMan

by StÃ©phane Ducasse

what I would like is - take the best ideas of both and use that to replace the ugly in pharo. - there are some aspects of rio I do not like like the cascading .... (see the meial I sent this summer) - fileman wrap the ugly and we should replace the ugly. Stef On Sep 12, 2008, at 8:43 AM, Alexandre Bergel wrote: > Thanks Damien > > Alexandre > > > On 12 Sep 2008, at 07:30, Damien Cassou wrote: > >> Comparaison between FileMan and Rio : http://wiki.squeak.org/squeak/3800 >> >> On Thu, Sep 11, 2008 at 4:00 PM, Alexandre Bergel >> <Alexandre.Bergel(a)inria.fr> wrote: >>> Dear List, >>> >>> On SqueakMap there is a package called FileMan. Here is an example: >>> >>> Squeak's file libraries (Directory, DirectoryEntry, FileStream, >>> etc.) are >>> sometimes very confusing to use. FileMan provides a simple, >>> refactored >>> interfaces for manipulating files and directories by wrapping >>> those classes. >>> >>> "Before" >>> subDir := FileDirectory default directoryNamed: 'subDir'. >>> subDir assureExistence. >>> [str := subDir newFileNamed: 'file1'. >>> str nextPutAll: 'Hello!'] >>> ensure: [str close]. >>> >>> "After installation of FileMan" >>> './subDir' asDirectoryEntry at: 'file2' put: 'Hello!' >>> >>> Maybe it worth having a look at it? >>> >>> Cheers, >>> Alexandre >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Damien Cassou >> Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good >> luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 12, 2008

Re: [Pharo-project] FileMan

by Alexandre Bergel

Thanks Damien Alexandre On 12 Sep 2008, at 07:30, Damien Cassou wrote: > Comparaison between FileMan and Rio : http://wiki.squeak.org/squeak/3800 > > On Thu, Sep 11, 2008 at 4:00 PM, Alexandre Bergel > <Alexandre.Bergel(a)inria.fr> wrote: >> Dear List, >> >> On SqueakMap there is a package called FileMan. Here is an example: >> >> Squeak's file libraries (Directory, DirectoryEntry, FileStream, >> etc.) are >> sometimes very confusing to use. FileMan provides a simple, >> refactored >> interfaces for manipulating files and directories by wrapping those >> classes. >> >> "Before" >> subDir := FileDirectory default directoryNamed: 'subDir'. >> subDir assureExistence. >> [str := subDir newFileNamed: 'file1'. >> str nextPutAll: 'Hello!'] >> ensure: [str close]. >> >> "After installation of FileMan" >> './subDir' asDirectoryEntry at: 'file2' put: 'Hello!' >> >> Maybe it worth having a look at it? >> >> Cheers, >> Alexandre >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Damien Cassou > Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good > luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 12, 2008

Re: [Pharo-project] FileMan

by Damien Cassou

Comparaison between FileMan and Rio : http://wiki.squeak.org/squeak/3800 On Thu, Sep 11, 2008 at 4:00 PM, Alexandre Bergel <Alexandre.Bergel(a)inria.fr> wrote: > Dear List, > > On SqueakMap there is a package called FileMan. Here is an example: > > Squeak's file libraries (Directory, DirectoryEntry, FileStream, etc.) are > sometimes very confusing to use. FileMan provides a simple, refactored > interfaces for manipulating files and directories by wrapping those classes. > > "Before" > subDir := FileDirectory default directoryNamed: 'subDir'. > subDir assureExistence. > [str := subDir newFileNamed: 'file1'. > str nextPutAll: 'Hello!'] > ensure: [str close]. > > "After installation of FileMan" > './subDir' asDirectoryEntry at: 'file2' put: 'Hello!' > > Maybe it worth having a look at it? > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 12, 2008

[Pharo-project] Learning how to use Polymorph

by Hilaire Fernandes

Gary, I am looking at Polymorph examples, to start learning it. >From your example, I see you have this ExampleBuilderMorph class Is it a class I can use to build my application interface, or do I need to subclass another MorphicModel (this last class is pretty large) ? I see you are using trait for this class also. Hilaire -- http://blog.ofset.org/hilaire

Sept. 11, 2008

Re: [Pharo-project] About fixes for noury and other

by Noury Bouraqadi

StÃ©f, On 11 sept. 08, at 09:44, StÃ©phane Ducasse wrote: > Hi noury > > I started to harvest your fixes and I learned something :) > when most of your fixes are about extending or changing a package > just publish a new version of that package. This way I can use the > merge tool > and be much more efficient, do not create a specific package with > specific class extension > for it else I have to modify everything by hand. > This sounds like a cleaner way indeed. If you didn't finish harvesting it, I can split different changes as you suggest. Noury ------------------------------------------------------------------ Dr. Noury Bouraqadi - Enseignant/Chercheur Responsable de l'enseignement de l'informatique ARMINES - Ecole des Mines de Douai - Dept. I.A. http://vst.ensm-douai.fr/noury European Smalltalk Users Group Board http://www.esug.org ------------------------------------------------------------------

Sept. 11, 2008

Re: [Pharo-project] How to submit changes when SqueakSource is down ?

by Noury Bouraqadi

On 10 sept. 08, at 11:01, StÃ©phane Ducasse wrote: > About package renaming > > Noury lukas told me that it was quite difficult to rename a package > in MC. > Last week I got a huge problem because I used the rename > functionality of the browser of david and it > crew up my system > So did you tried your reanme behavior with dependency and the rest. > I developped it few years ago. I'm using it often. I wrote tests also :-) > Stef > > > >> Hi, >> >> SqueakSource is down again :-( >> Attached a monticello package with a serie of bugfixes and >> enhancements tested on pharo-dev of sept: >> >> *Bug Fixes >> -Transcript printing and self evaluating >> -Smalltalk printing and self evaluating >> -Instance Variable should never start by a capital >> >> *Enhancemnts >> -Monticello Package renaming >> -Prefix replacement for classes in a Monticello package >> >> Regards, >> Noury >> ------------------------------------------------------------------ >> Dr. Noury Bouraqadi - Enseignant/Chercheur >> Responsable de l'enseignement de l'informatique >> ARMINES - Ecole des Mines de Douai - Dept. I.A. >> http://vst.ensm-douai.fr/noury >> >> European Smalltalk Users Group Board >> http://www.esug.org >> ------------------------------------------------------------------ >> >> >> <FixesAndEnh-Noury. >> 1.mcz>_______________________________________________ >> 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 > Noury Bouraqadi ------------------------------------------------------------------ Dr. Noury Bouraqadi - Enseignant/Chercheur Responsable de l'enseignement de l'informatique ARMINES - Ecole des Mines de Douai - Dept. I.A. http://vst.ensm-douai.fr/noury European Smalltalk Users Group Board http://www.esug.org ------------------------------------------------------------------

Sept. 11, 2008

Re: [Pharo-project] Hello everyone!

by Igor Stasenko

2008/9/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > I'm confused you do not use VMMaker for Hydra? >> >>> yes keep it there >>> we have too much mailing-lists >>> >>> So can you do a unix/windows VM with the freeType pluging? >>> >> Sure i can, just give me details which/where i should take VMMaker & >> platform sources & plugin. > > I thought that all this information was in the VM repository. > Can you point me to that VM repository? VMMaker are available on: - squeakmap, - http://www.squeaksource.com/VMMaker.html - http://source.squeakfoundation.org (now is empty ,strange) The VM sources, are available on squeakvm.org SVN. Is this places correct? Also, where i can get freetype plugin and its platform sources? > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 11, 2008

Re: [Pharo-project] InterfaceDiscoverer

by Alexandre Bergel

Oh! did not know that! Thanks for this! Alexandre On 11 Sep 2008, at 16:38, Lukas Renggli wrote: > On 9/11/08, Alexandre Bergel <alexandre(a)bergel.eu> wrote: >> No debugger shows up. I just have this little windows saying there >> is a >> syntax error. > > You can edit source code in that gray little window and proceed from > there ;-) > > 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 11, 2008

Re: [Pharo-project] InterfaceDiscoverer

by Lukas Renggli

On 9/11/08, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > No debugger shows up. I just have this little windows saying there is a > syntax error. You can edit source code in that gray little window and proceed from there ;-) Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 11, 2008

Re: [Pharo-project] InterfaceDiscoverer

by Alexandre Bergel

No debugger shows up. I just have this little windows saying there is a syntax error. However, I was able to load GraphViz with having loaded FFI from SqueakMap. Thanks, Alexandre On 11 Sep 2008, at 15:51, Lukas Renggli wrote: >> The only way I see to load GraphViz, is to download the .mcz file, >> uncompress it, remove the improperly written method from the .st >> file, and >> then to load it from Squeak. Is there something better to load it? > > Fix it in the debugger that pops up while loading. Or load FFI from > SqueakMap. > > 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 11, 2008

[Pharo-project] FileMan

by Alexandre Bergel

Dear List, On SqueakMap there is a package called FileMan. Here is an example: Squeak's file libraries (Directory, DirectoryEntry, FileStream, etc.) are sometimes very confusing to use. FileMan provides a simple, refactored interfaces for manipulating files and directories by wrapping those classes. "Before" subDir := FileDirectory default directoryNamed: 'subDir'. subDir assureExistence. [str := subDir newFileNamed: 'file1'. str nextPutAll: 'Hello!'] ensure: [str close]. "After installation of FileMan" './subDir' asDirectoryEntry at: 'file2' put: 'Hello!' Maybe it worth having a look at it? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 11, 2008

Re: [Pharo-project] InterfaceDiscoverer

by Lukas Renggli

> The only way I see to load GraphViz, is to download the .mcz file, > uncompress it, remove the improperly written method from the .st file, and > then to load it from Squeak. Is there something better to load it? Fix it in the debugger that pops up while loading. Or load FFI from SqueakMap. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 11, 2008

Re: [Pharo-project] Your take on that: CollectionsTests-Ordered vs Collections-Ordered-Tests

by Bill Schwab

I agree that packages should be promoted to real objects vs. the result of clever (ab)use of category names. That said, I frequently use a general-to-specific naming scheme for related classes on the grounds that it seems to help me when I get an alphabetical view of names. With that same logic, I suppose one could argue for just about any of the options described here :) Sorry. In addition to reified packages, I would like to float the idea of allowing multiple method categories to apply to any given method. That has been very useful in Dolphin. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> luc.fabresse(a)gmail.com 9/11/2008 3:09 AM >>> I understand the problem and I did not explain well but the solution of the Graphics package seems great : Graphics-Text Graphics-Files and GraphicsTests-Text GraphicsTests-Files Other packages like Graphics : CollectionTests-*, KernelTests-*, ... Packages with other naming conventions that do not seem great : File-Tests, Tests-*, Monticello-Tests Sure, a system that does not rely on string maching would be better. #Luc 2008/9/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Sep 11, 2008, at 9:35 AM, Luc Fabresse wrote: > > the convention <category>Tests[<-subcategory>] seems great IMO. >> e.g. Graphics-Text -> GraphicsTests-Text >> >> With this naming pattern it is possible to have 2 monticello packages : >> <category> and <category>Tests >> And it is possible to not load Tests packages in a deployed image. >> > > Yes it does not work if Graphics is composed of several subpackages > > With this I cannot have > > Collections-OrderedCollection > and > Collections-OrderedCollection-Tests > > separated from > > Collections-Set > and > Collections-Set-Tests > > For me I want to have packages that I can load independently and the tests > should be attached to the package (to be eventually not load with it). > >> >> > I really hate the fact that we feel everywhere category and string > matching. > > Stef > > > >> Luc >> >> 2008/9/11 Alexandre Bergel <alexandre(a)bergel.eu> >> Having a package name without any - will prevent Monticello from being >> confuse on some point. >> Stef and I already experienced that... >> >> I was never happy in inserting a - in a package name. >> >> Alexandre >> >> >> >> On 11 Sep 2008, at 07:23, Damien Cassou wrote: >> >> On Wed, Sep 10, 2008 at 9:32 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >> Hi >> >> I noticed that we have CollectionsTests-Ordered >> kind of package name and I would prefer to get Collections-Ordered-Tests >> What do you think. I bit of regularity would help. >> >> Collections-Test-* categories belong to the Collections-Test package >> on monticello. If you rename it to Collections-Ordered-Tests, you will >> put everything in the Collections package (because there is no >> Collections-Ordered monticello package). >> >> >> -- >> Damien Cassou >> Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good >> luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> >> _______________________________________________ >> 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 >

Sept. 11, 2008

Re: [Pharo-project] InterfaceDiscoverer

by Alexandre Bergel

> Did you try the GraphViz from the same repository? Yes. > It seems to depend on FFI, but that functionality is not needed > anyway. You can safely ignore that warning. The dependency package of > mine will simply create an object model of the dependencies and > optionally a GraphViz file that you have to convert to a png/svg/pdf > from the command line yourself. The only way I see to load GraphViz, is to download the .mcz file, uncompress it, remove the improperly written method from the .st file, and then to load it from Squeak. Is there something better to load it? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 11, 2008

Re: [Pharo-project] InterfaceDiscoverer

by Lukas Renggli

> Sorry to answer so late. I tried to load GraphViz, but a syntax error pops > up. Did you try the GraphViz from the same repository? > MacOSGraphVizGenerator>>runWithSystemFramework: string > <> expected ->apicall: short 'system' (char*) module: > 'System.framework'> > > ^ self externalCallFailed > > I used the last Pharo image with loadOB installed. It seems to depend on FFI, but that functionality is not needed anyway. You can safely ignore that warning. The dependency package of mine will simply create an object model of the dependencies and optionally a GraphViz file that you have to convert to a png/svg/pdf from the command line yourself. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 11, 2008

Re: [Pharo-project] InterfaceDiscoverer

by Alexandre Bergel

Hi Lukas, Sorry to answer so late. I tried to load GraphViz, but a syntax error pops up. MacOSGraphVizGenerator>>runWithSystemFramework: string <> expected ->apicall: short 'system' (char*) module: 'System.framework'> ^ self externalCallFailed I used the last Pharo image with loadOB installed. Cheers, Alexandre On 6 Sep 2008, at 09:45, Lukas Renggli wrote: >> I built a small extension to OB that display dependencies between >> class >> categories. Just load InterfaceDiscoverer from squeaksource, and >> click on a >> class category in an OB browser. > > What kind of dependencies? > > For Seaside we use Package-Dependencies from > http://source.lukas-renggli.ch/unsorted/ to calculate static > dependencies between packages and visualize them using GraphViz. The > code takes some ideas from MudPie and Moose, but otherwise is a new > completely implementation. > > 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 11, 2008

Re: [Pharo-project] Your take on that: CollectionsTests-Ordered vs Collections-Ordered-Tests

by Luc Fabresse

I understand the problem and I did not explain well but the solution of the Graphics package seems great : Graphics-Text Graphics-Files and GraphicsTests-Text GraphicsTests-Files Other packages like Graphics : CollectionTests-*, KernelTests-*, ... Packages with other naming conventions that do not seem great : File-Tests, Tests-*, Monticello-Tests Sure, a system that does not rely on string maching would be better. #Luc 2008/9/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Sep 11, 2008, at 9:35 AM, Luc Fabresse wrote: > > the convention <category>Tests[<-subcategory>] seems great IMO. >> e.g. Graphics-Text -> GraphicsTests-Text >> >> With this naming pattern it is possible to have 2 monticello packages : >> <category> and <category>Tests >> And it is possible to not load Tests packages in a deployed image. >> > > Yes it does not work if Graphics is composed of several subpackages > > With this I cannot have > > Collections-OrderedCollection > and > Collections-OrderedCollection-Tests > > separated from > > Collections-Set > and > Collections-Set-Tests > > For me I want to have packages that I can load independently and the tests > should be attached to the package (to be eventually not load with it). > >> >> > I really hate the fact that we feel everywhere category and string > matching. > > Stef > > > >> Luc >> >> 2008/9/11 Alexandre Bergel <alexandre(a)bergel.eu> >> Having a package name without any - will prevent Monticello from being >> confuse on some point. >> Stef and I already experienced that... >> >> I was never happy in inserting a - in a package name. >> >> Alexandre >> >> >> >> On 11 Sep 2008, at 07:23, Damien Cassou wrote: >> >> On Wed, Sep 10, 2008 at 9:32 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >> Hi >> >> I noticed that we have CollectionsTests-Ordered >> kind of package name and I would prefer to get Collections-Ordered-Tests >> What do you think. I bit of regularity would help. >> >> Collections-Test-* categories belong to the Collections-Test package >> on monticello. If you rename it to Collections-Ordered-Tests, you will >> put everything in the Collections package (because there is no >> Collections-Ordered monticello package). >> >> >> -- >> Damien Cassou >> Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good >> luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> >> _______________________________________________ >> 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 >

Sept. 11, 2008

Re: [Pharo-project] Hello everyone!

by StÃ©phane Ducasse

I'm confused you do not use VMMaker for Hydra? > >> yes keep it there >> we have too much mailing-lists >> >> So can you do a unix/windows VM with the freeType pluging? >> > Sure i can, just give me details which/where i should take VMMaker & > platform sources & plugin. I thought that all this information was in the VM repository. Stef

Sept. 11, 2008

Re: [Pharo-project] Your take on that: CollectionsTests-Ordered vs Collections-Ordered-Tests

by StÃ©phane Ducasse

On Sep 11, 2008, at 9:35 AM, Luc Fabresse wrote: > the convention <category>Tests[<-subcategory>] seems great IMO. > e.g. Graphics-Text -> GraphicsTests-Text > > With this naming pattern it is possible to have 2 monticello > packages : <category> and <category>Tests > And it is possible to not load Tests packages in a deployed image. Yes it does not work if Graphics is composed of several subpackages With this I cannot have Collections-OrderedCollection and Collections-OrderedCollection-Tests separated from Collections-Set and Collections-Set-Tests For me I want to have packages that I can load independently and the tests should be attached to the package (to be eventually not load with it). > I really hate the fact that we feel everywhere category and string matching. Stef > > Luc > > 2008/9/11 Alexandre Bergel <alexandre(a)bergel.eu> > Having a package name without any - will prevent Monticello from > being confuse on some point. > Stef and I already experienced that... > > I was never happy in inserting a - in a package name. > > Alexandre > > > > On 11 Sep 2008, at 07:23, Damien Cassou wrote: > > On Wed, Sep 10, 2008 at 9:32 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > Hi > > I noticed that we have CollectionsTests-Ordered > kind of package name and I would prefer to get Collections-Ordered- > Tests > What do you think. I bit of regularity would help. > > Collections-Test-* categories belong to the Collections-Test package > on monticello. If you rename it to Collections-Ordered-Tests, you will > put everything in the Collections package (because there is no > Collections-Ordered monticello package). > > > -- > Damien Cassou > Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good > luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > _______________________________________________ > 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

Sept. 11, 2008

[Pharo-project] About fixes for noury and other

by StÃ©phane Ducasse

Hi noury I started to harvest your fixes and I learned something :) when most of your fixes are about extending or changing a package just publish a new version of that package. This way I can use the merge tool and be much more efficient, do not create a specific package with specific class extension for it else I have to modify everything by hand. Stef

Sept. 11, 2008

Re: [Pharo-project] Your take on that: CollectionsTests-Ordered vs Collections-Ordered-Tests

by Luc Fabresse

the convention <category>Tests[<-subcategory>] seems great IMO.e.g. Graphics-Text -> GraphicsTests-Text With this naming pattern it is possible to have 2 monticello packages : <category> and <category>Tests And it is possible to not load Tests packages in a deployed image. Luc 2008/9/11 Alexandre Bergel <alexandre(a)bergel.eu> > Having a package name without any - will prevent Monticello from being > confuse on some point. > Stef and I already experienced that... > > I was never happy in inserting a - in a package name. > > Alexandre > > > > On 11 Sep 2008, at 07:23, Damien Cassou wrote: > > On Wed, Sep 10, 2008 at 9:32 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >> >>> Hi >>> >>> I noticed that we have CollectionsTests-Ordered >>> kind of package name and I would prefer to get Collections-Ordered-Tests >>> What do you think. I bit of regularity would help. >>> >> >> Collections-Test-* categories belong to the Collections-Test package >> on monticello. If you rename it to Collections-Ordered-Tests, you will >> put everything in the Collections package (because there is no >> Collections-Ordered monticello package). >> >> >> -- >> Damien Cassou >> Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good >> luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 11, 2008

Re: [Pharo-project] Your take on that: CollectionsTests-Ordered vs Collections-Ordered-Tests

by Alexandre Bergel

Having a package name without any - will prevent Monticello from being confuse on some point. Stef and I already experienced that... I was never happy in inserting a - in a package name. Alexandre On 11 Sep 2008, at 07:23, Damien Cassou wrote: > On Wed, Sep 10, 2008 at 9:32 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Hi >> >> I noticed that we have CollectionsTests-Ordered >> kind of package name and I would prefer to get Collections-Ordered- >> Tests >> What do you think. I bit of regularity would help. > > Collections-Test-* categories belong to the Collections-Test package > on monticello. If you rename it to Collections-Ordered-Tests, you will > put everything in the Collections package (because there is no > Collections-Ordered monticello package). > > > -- > Damien Cassou > Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good > luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 11, 2008

Re: [Pharo-project] Hello everyone!

by Igor Stasenko

2008/9/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > yes keep it there > we have too much mailing-lists > > So can you do a unix/windows VM with the freeType pluging? > Sure i can, just give me details which/where i should take VMMaker & platform sources & plugin. > Stef > > On Sep 11, 2008, at 12:03 AM, Igor Stasenko wrote: > >> 2008/9/10 Alexandre Bergel <alexandre(a)bergel.eu>: >>> >>> Igor, >>> >>> Do you have a mailing list on Hydra? >>> I think it is important to initiate the creation of a community around >>> this >>> idea. >>> You may use googlecode for that. >>> >> >> there is not much activity in this area, worth creating new mailing list. >> Currently, i using squeak-dev or vm-dev mailing list for news & >> announcements. >> I asked community, maybe it is OT, but nobody complained about it, >> instead they want it there. :) >> >>> Cheers, >>> Alexandre >>> >>> >>> On 10 Sep 2008, at 10:44, Igor Stasenko wrote: >>> >>>> 2008/9/10 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>>> >>>>>> >>>>>> Well, as i said, putting FreeType into VM is simple thing. >>>>>> But maintaining a code base or regular basis is completely different >>>>>> thing. I'm not sure i have enough spare time to do this now. >>>>>> First, because i'm busy with Hydra VM. >>>>>> Second , I think you are aware, that Cog & Hydra will merge in future. >>>>>> Before this happens, i have little interest in supporting >>>>>> old-fashioned VMs :) >>>>>> >>>>>> I planning to do a major refactoring in Hydra, after which , an >>>>>> Interpreter/ObjectMemory can be simulated in image. But this will have >>>>>> a major impact on backward compatibility. >>>>>> >>>>>> But for minor changes, like in some plugins, it not hurts a lot. I >>>>>> think that, if you planning to maintain own VM, then i'll advice to >>>>>> split VMMaker package on two separate parts: >>>>>> - VM core >>>>>> - all plugins >>>>>> >>>>>> Because VM is a big code bloat , which is hard to manipulate with. >>>>>> >>>>>> Also, it would be good to have a common code repository, and separate >>>>>> tracker of bugs and fixes for VM/plugins, so it will make an >>>>>> integration easier for all interesting parties. >>>>> >>>>> could you push this idea to the VM maintainers or start to do it? >>>> >>>> yes i could, but do you think that i have a chance to be heard and my >>>> point to be accepted? :) >>>> >>>>> We are talking abut that since years. >>>>> I still do not understand I thought that the svn of the vm code was >>>>> such >>>>> common >>>>> code repository? >>>> >>>> I tried to raise this topic on board meeting, concerning status of >>>> VM-dev group and the answer was like: >>>> - we already have things set up, and each maintainer know/doing things >>>> well. >>>> I'm not sure about current status, but i keep feeling that VM >>>> maintainers efforts dissipating due to lack of >>>> communication/collaboration. >>>> Maybe it is because i'm relatively new, and missing info about how >>>> things was set up long ago, before i came in, maybe people really >>>> collaborate behind the scenes, i don't know. >>>> What i really sure about, is that , it will not hurt to call for a >>>> status (re)clarification to know who doing what and how things >>>> working. >>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Sept. 11, 2008

Re: [Pharo-project] Hello everyone!

by StÃ©phane Ducasse

yes keep it there we have too much mailing-lists So can you do a unix/windows VM with the freeType pluging? Stef On Sep 11, 2008, at 12:03 AM, Igor Stasenko wrote: > 2008/9/10 Alexandre Bergel <alexandre(a)bergel.eu>: >> Igor, >> >> Do you have a mailing list on Hydra? >> I think it is important to initiate the creation of a community >> around this >> idea. >> You may use googlecode for that. >> > > there is not much activity in this area, worth creating new mailing > list. > Currently, i using squeak-dev or vm-dev mailing list for news & > announcements. > I asked community, maybe it is OT, but nobody complained about it, > instead they want it there. :) > >> Cheers, >> Alexandre >> >> >> On 10 Sep 2008, at 10:44, Igor Stasenko wrote: >> >>> 2008/9/10 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>> >>>>> >>>>> Well, as i said, putting FreeType into VM is simple thing. >>>>> But maintaining a code base or regular basis is completely >>>>> different >>>>> thing. I'm not sure i have enough spare time to do this now. >>>>> First, because i'm busy with Hydra VM. >>>>> Second , I think you are aware, that Cog & Hydra will merge in >>>>> future. >>>>> Before this happens, i have little interest in supporting >>>>> old-fashioned VMs :) >>>>> >>>>> I planning to do a major refactoring in Hydra, after which , an >>>>> Interpreter/ObjectMemory can be simulated in image. But this >>>>> will have >>>>> a major impact on backward compatibility. >>>>> >>>>> But for minor changes, like in some plugins, it not hurts a lot. I >>>>> think that, if you planning to maintain own VM, then i'll advice >>>>> to >>>>> split VMMaker package on two separate parts: >>>>> - VM core >>>>> - all plugins >>>>> >>>>> Because VM is a big code bloat , which is hard to manipulate with. >>>>> >>>>> Also, it would be good to have a common code repository, and >>>>> separate >>>>> tracker of bugs and fixes for VM/plugins, so it will make an >>>>> integration easier for all interesting parties. >>>> >>>> could you push this idea to the VM maintainers or start to do it? >>> >>> yes i could, but do you think that i have a chance to be heard and >>> my >>> point to be accepted? :) >>> >>>> We are talking abut that since years. >>>> I still do not understand I thought that the svn of the vm code >>>> was such >>>> common >>>> code repository? >>> >>> I tried to raise this topic on board meeting, concerning status of >>> VM-dev group and the answer was like: >>> - we already have things set up, and each maintainer know/doing >>> things >>> well. >>> I'm not sure about current status, but i keep feeling that VM >>> maintainers efforts dissipating due to lack of >>> communication/collaboration. >>> Maybe it is because i'm relatively new, and missing info about how >>> things was set up long ago, before i came in, maybe people really >>> collaborate behind the scenes, i don't know. >>> What i really sure about, is that , it will not hurt to call for a >>> status (re)clarification to know who doing what and how things >>> working. >>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 11, 2008

Re: [Pharo-project] Your take on that: CollectionsTests-Ordered vs Collections-Ordered-Tests

by Damien Cassou

On Wed, Sep 10, 2008 at 9:49 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Or better > Collections-Tests That one would be ok -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 11, 2008

Re: [Pharo-project] Your take on that: CollectionsTests-Ordered vs Collections-Ordered-Tests

by Damien Cassou

On Wed, Sep 10, 2008 at 9:32 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi > > I noticed that we have CollectionsTests-Ordered > kind of package name and I would prefer to get Collections-Ordered-Tests > What do you think. I bit of regularity would help. Collections-Test-* categories belong to the Collections-Test package on monticello. If you rename it to Collections-Ordered-Tests, you will put everything in the Collections package (because there is no Collections-Ordered monticello package). -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 11, 2008

Re: [Pharo-project] Hello everyone!

by Igor Stasenko

2008/9/10 Alexandre Bergel <alexandre(a)bergel.eu>: > Igor, > > Do you have a mailing list on Hydra? > I think it is important to initiate the creation of a community around this > idea. > You may use googlecode for that. > there is not much activity in this area, worth creating new mailing list. Currently, i using squeak-dev or vm-dev mailing list for news & announcements. I asked community, maybe it is OT, but nobody complained about it, instead they want it there. :) > Cheers, > Alexandre > > > On 10 Sep 2008, at 10:44, Igor Stasenko wrote: > >> 2008/9/10 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>> >>>> >>>> Well, as i said, putting FreeType into VM is simple thing. >>>> But maintaining a code base or regular basis is completely different >>>> thing. I'm not sure i have enough spare time to do this now. >>>> First, because i'm busy with Hydra VM. >>>> Second , I think you are aware, that Cog & Hydra will merge in future. >>>> Before this happens, i have little interest in supporting >>>> old-fashioned VMs :) >>>> >>>> I planning to do a major refactoring in Hydra, after which , an >>>> Interpreter/ObjectMemory can be simulated in image. But this will have >>>> a major impact on backward compatibility. >>>> >>>> But for minor changes, like in some plugins, it not hurts a lot. I >>>> think that, if you planning to maintain own VM, then i'll advice to >>>> split VMMaker package on two separate parts: >>>> - VM core >>>> - all plugins >>>> >>>> Because VM is a big code bloat , which is hard to manipulate with. >>>> >>>> Also, it would be good to have a common code repository, and separate >>>> tracker of bugs and fixes for VM/plugins, so it will make an >>>> integration easier for all interesting parties. >>> >>> could you push this idea to the VM maintainers or start to do it? >> >> yes i could, but do you think that i have a chance to be heard and my >> point to be accepted? :) >> >>> We are talking abut that since years. >>> I still do not understand I thought that the svn of the vm code was such >>> common >>> code repository? >> >> I tried to raise this topic on board meeting, concerning status of >> VM-dev group and the answer was like: >> - we already have things set up, and each maintainer know/doing things >> well. >> I'm not sure about current status, but i keep feeling that VM >> maintainers efforts dissipating due to lack of >> communication/collaboration. >> Maybe it is because i'm relatively new, and missing info about how >> things was set up long ago, before i came in, maybe people really >> collaborate behind the scenes, i don't know. >> What i really sure about, is that , it will not hurt to call for a >> status (re)clarification to know who doing what and how things >> working. >> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 10, 2008

Re: [Pharo-project] Your take on that: CollectionsTests-Ordered vs Collections-Ordered-Tests

by StÃ©phane Ducasse

Or better Collections-Tests stef On Sep 10, 2008, at 9:32 PM, StÃ©phane Ducasse wrote: > Hi > > I noticed that we have CollectionsTests-Ordered > kind of package name and I would prefer to get Collections-Ordered- > Tests > What do you think. I bit of regularity would help. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 10, 2008

[Pharo-project] Your take on that: CollectionsTests-Ordered vs Collections-Ordered-Tests

by StÃ©phane Ducasse

Hi I noticed that we have CollectionsTests-Ordered kind of package name and I would prefer to get Collections-Ordered-Tests What do you think. I bit of regularity would help. Stef

Sept. 10, 2008

Re: [Pharo-project] Re: [squeak-dev] Re: FFI and FreeTypePlus problem?

by StÃ©phane Ducasse

Thanks andy We got already a lot of fun with your package and work. This was great to be able to use all our mac fonts in Squeak :) Stef On Sep 10, 2008, at 11:48 AM, Andrew Tween wrote: > Hi Stef, > > "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote in message news:DF04D962-8D70-41FD-AA9A-EC990E749A48@inria.fr > ... >> ================================================================ >> Hi there, >> >> I'm using Installer to make a custom 3dot10 7159. The first things >> I do >> in the script is to load from universe FreeTypePlus (wich brings >> FFI). Then I've >> load LPF. >> >> If I do that it never ends due to Squeak not being able of >> resolving a >> name. >> >> NetNameResolver addressForName: 'installer.pbwiki.com/f/LPF.st' >> >> Before loading the FreeTypePlus, evaluating the previous sentence >> has an >> instant response of the address. >> >> But if I do load the FreeTypePlus package it never ends. Maybe an FFI >> issue? >> >> I'm in Win32 using >> >> SqueakFFIPrims.dll from 8/30/2007 >> Squeak.exe from 6/5/2007 >> >> any clue? > > I think it is this bug... http://bugs.squeak.org/view.php?id=6980 > > I have been following the conversations re: FT2Plugin etc. , but > haven't had time to comment. > I hope to contribute to the discussion soon. > > The universe FreeTypePLus packages are quite old. > You may find the latest from squeaksource more appropriate. > I wrote before about how to install them - copied below... > ----- > Copy these files (included in > http://www.zen61439.zen.co.uk/ft_pharo/ft_pharo.zip ) to the default > directory... > > PinesoftEnhancementsForFreetype-tween.3.mcz > FreeType-tween.435.mcz > FreeType Plus Squeak Sans Font Pack.small.sar > FreeTypeSubPixelAntiAliasing-tween.13.mcz > > and then filein the attached script (contents shown below).. > > | repository | > repository := MCDirectoryRepository new. > MCVersionLoader new > addVersion: (repository loadVersionFromFileNamed: > 'PinesoftEnhancementsForFreetype-tween.3.mcz'); > load. > MCVersionLoader new > addVersion: (repository loadVersionFromFileNamed: > 'FreeType-tween.435.mcz'); > load. > SARInstaller installSAR: 'FreeType Plus Squeak Sans Font > Pack.small.sar'. > MCVersionLoader new > addVersion: (repository loadVersionFromFileNamed: > 'FreeTypeSubPixelAntiAliasing-tween.13.mcz'); > load. > ! > --- > > Omit the PinesoftEnhancementsForFreetype-tween.3.mcz if you are > loading into an image that already has UIEnhancements/Polymorph > loaded. > > Cheers, > Andy > > >> >> thanks >> >> Sebastian Sastre >> PD: here is the beginning of the script: >> >> Utilities >> informUser: 'Upgrading universe packages' >> during: [ UUniverse systemUniverse updatePackagesViaWWW ]. >> (UUniverse systemUniverse newestPackageNamed: 'FreeType Plus') >> ifNotNilDo: [ :package| |inst| >> inst := UGlobalInstaller universe: UUniverse >> systemUniverse. >> inst planToInstallPackage: package. >> inst doInstall ]. >> >> (HTTPSocket httpGet: 'installer.pbwiki.com/f/LPF.st') readStream >> fileIn. >> >> >> ================================================================ >> >> >> I already created a bug report for this, Andreas >> may be able to tell you more: >> >> http://bugs.squeak.org/view.php?id=6980 >> >> As a workaround you can can use FFI-Kernel-ar6.mcz >> instead of FFI-Kernel-ar-8.mcz. >> >> Bye >> Torsten >> >> >> ================================================================ >>> From: Andreas Raab <andreas.raab(a)gmx.de> >>> Date: March 27, 2008 10:00:21 PM CEST >>> To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org >>> > >>> Subject: [squeak-dev] Re: FFI and FreeTypePlus problem? >>> Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org >>> > >>> >>> Yeah, I had forgotten about the problem. The issue comes from a >>> call to Smalltalk>>recreateSpecialObjectsArray (which is required >>> for the FFI to work correctly) and which accidentally nukes the >>> external semaphore table. The fix is simple: Replace the >>> following line in SystemDictionary>>recreateSpecialObjectsArray >>> >>> newArray at: 39 put: Array new. >>> >>> by >>> "Preserve external semaphores when recreating splObjs" >>> newArray at: 39 put: (self specialObjectsArray at: 39). >>> >>> Also, saving and restarting the image after loading the FFI is >>> good temporary workaround for this problem. >>> >>> Cheers, >>> - Andreas >>> >>> Torsten Bergmann wrote: >>>> I already created a bug report for this, Andreas may be able to >>>> tell you more: >>>> http://bugs.squeak.org/view.php?id=6980 >>>> As a workaround you can can use FFI-Kernel-ar6.mcz >>>> instead of FFI-Kernel-ar-8.mcz. >>>> Bye >>>> Torsten >>> >>> > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 10, 2008

[Pharo-project] Re: [squeak-dev] Re: FFI and FreeTypePlus problem?

by Andrew Tween

Hi Stef, "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote in message news:DF04D962-8D70-41FD-AA9A-EC990E749A48@inria.fr... > ================================================================ > Hi there, > > I'm using Installer to make a custom 3dot10 7159. The first things I do > in the script is to load from universe FreeTypePlus (wich brings FFI). > Then I've > load LPF. > > If I do that it never ends due to Squeak not being able of resolving a > name. > > NetNameResolver addressForName: 'installer.pbwiki.com/f/LPF.st' > > Before loading the FreeTypePlus, evaluating the previous sentence has an > instant response of the address. > > But if I do load the FreeTypePlus package it never ends. Maybe an FFI > issue? > > I'm in Win32 using > > SqueakFFIPrims.dll from 8/30/2007 > Squeak.exe from 6/5/2007 > > any clue? I think it is this bug... http://bugs.squeak.org/view.php?id=6980 I have been following the conversations re: FT2Plugin etc. , but haven't had time to comment. I hope to contribute to the discussion soon. The universe FreeTypePLus packages are quite old. You may find the latest from squeaksource more appropriate. I wrote before about how to install them - copied below... ----- Copy these files (included in http://www.zen61439.zen.co.uk/ft_pharo/ft_pharo.zip ) to the default directory... PinesoftEnhancementsForFreetype-tween.3.mcz FreeType-tween.435.mcz FreeType Plus Squeak Sans Font Pack.small.sar FreeTypeSubPixelAntiAliasing-tween.13.mcz and then filein the attached script (contents shown below).. | repository | repository := MCDirectoryRepository new. MCVersionLoader new addVersion: (repository loadVersionFromFileNamed: 'PinesoftEnhancementsForFreetype-tween.3.mcz'); load. MCVersionLoader new addVersion: (repository loadVersionFromFileNamed: 'FreeType-tween.435.mcz'); load. SARInstaller installSAR: 'FreeType Plus Squeak Sans Font Pack.small.sar'. MCVersionLoader new addVersion: (repository loadVersionFromFileNamed: 'FreeTypeSubPixelAntiAliasing-tween.13.mcz'); load. ! --- Omit the PinesoftEnhancementsForFreetype-tween.3.mcz if you are loading into an image that already has UIEnhancements/Polymorph loaded. Cheers, Andy > > thanks > > Sebastian Sastre > PD: here is the beginning of the script: > > Utilities > informUser: 'Upgrading universe packages' > during: [ UUniverse systemUniverse updatePackagesViaWWW ]. > (UUniverse systemUniverse newestPackageNamed: 'FreeType Plus') > ifNotNilDo: [ :package| |inst| > inst := UGlobalInstaller universe: UUniverse > systemUniverse. > inst planToInstallPackage: package. > inst doInstall ]. > > (HTTPSocket httpGet: 'installer.pbwiki.com/f/LPF.st') readStream fileIn. > > > ================================================================ > > > I already created a bug report for this, Andreas > may be able to tell you more: > > http://bugs.squeak.org/view.php?id=6980 > > As a workaround you can can use FFI-Kernel-ar6.mcz > instead of FFI-Kernel-ar-8.mcz. > > Bye > Torsten > > > ================================================================ >> From: Andreas Raab <andreas.raab(a)gmx.de> >> Date: March 27, 2008 10:00:21 PM CEST >> To: The general-purpose Squeak developers list >> <squeak-dev(a)lists.squeakfoundation.org >> > >> Subject: [squeak-dev] Re: FFI and FreeTypePlus problem? >> Reply-To: The general-purpose Squeak developers list >> <squeak-dev(a)lists.squeakfoundation.org >> > >> >> Yeah, I had forgotten about the problem. The issue comes from a call to >> Smalltalk>>recreateSpecialObjectsArray (which is required for the FFI to >> work correctly) and which accidentally nukes the external semaphore >> table. The fix is simple: Replace the following line in >> SystemDictionary>>recreateSpecialObjectsArray >> >> newArray at: 39 put: Array new. >> >> by >> "Preserve external semaphores when recreating splObjs" >> newArray at: 39 put: (self specialObjectsArray at: 39). >> >> Also, saving and restarting the image after loading the FFI is good >> temporary workaround for this problem. >> >> Cheers, >> - Andreas >> >> Torsten Bergmann wrote: >>> I already created a bug report for this, Andreas may be able to tell >>> you more: >>> http://bugs.squeak.org/view.php?id=6980 >>> As a workaround you can can use FFI-Kernel-ar6.mcz >>> instead of FFI-Kernel-ar-8.mcz. >>> Bye >>> Torsten >> >> >>

Sept. 10, 2008

Re: [Pharo-project] Hello everyone!

by Alexandre Bergel

Igor, Do you have a mailing list on Hydra? I think it is important to initiate the creation of a community around this idea. You may use googlecode for that. Cheers, Alexandre On 10 Sep 2008, at 10:44, Igor Stasenko wrote: > 2008/9/10 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> >>> >>> Well, as i said, putting FreeType into VM is simple thing. >>> But maintaining a code base or regular basis is completely different >>> thing. I'm not sure i have enough spare time to do this now. >>> First, because i'm busy with Hydra VM. >>> Second , I think you are aware, that Cog & Hydra will merge in >>> future. >>> Before this happens, i have little interest in supporting >>> old-fashioned VMs :) >>> >>> I planning to do a major refactoring in Hydra, after which , an >>> Interpreter/ObjectMemory can be simulated in image. But this will >>> have >>> a major impact on backward compatibility. >>> >>> But for minor changes, like in some plugins, it not hurts a lot. I >>> think that, if you planning to maintain own VM, then i'll advice to >>> split VMMaker package on two separate parts: >>> - VM core >>> - all plugins >>> >>> Because VM is a big code bloat , which is hard to manipulate with. >>> >>> Also, it would be good to have a common code repository, and >>> separate >>> tracker of bugs and fixes for VM/plugins, so it will make an >>> integration easier for all interesting parties. >> >> could you push this idea to the VM maintainers or start to do it? > > yes i could, but do you think that i have a chance to be heard and my > point to be accepted? :) > >> We are talking abut that since years. >> I still do not understand I thought that the svn of the vm code was >> such >> common >> code repository? > > I tried to raise this topic on board meeting, concerning status of > VM-dev group and the answer was like: > - we already have things set up, and each maintainer know/doing > things well. > I'm not sure about current status, but i keep feeling that VM > maintainers efforts dissipating due to lack of > communication/collaboration. > Maybe it is because i'm relatively new, and missing info about how > things was set up long ago, before i came in, maybe people really > collaborate behind the scenes, i don't know. > What i really sure about, is that , it will not hurt to call for a > status (re)clarification to know who doing what and how things > working. > >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > -- > Best regards, > Igor Stasenko AKA sig. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 10, 2008

[Pharo-project] Fwd: [squeak-dev] Re: FFI and FreeTypePlus problem?

by StÃ©phane Ducasse

================================================================ Hi there, I'm using Installer to make a custom 3dot10 7159. The first things I do in the script is to load from universe FreeTypePlus (wich brings FFI). Then I've load LPF. If I do that it never ends due to Squeak not being able of resolving a name. NetNameResolver addressForName: 'installer.pbwiki.com/f/LPF.st' Before loading the FreeTypePlus, evaluating the previous sentence has an instant response of the address. But if I do load the FreeTypePlus package it never ends. Maybe an FFI issue? I'm in Win32 using SqueakFFIPrims.dll from 8/30/2007 Squeak.exe from 6/5/2007 any clue? thanks Sebastian Sastre PD: here is the beginning of the script: Utilities informUser: 'Upgrading universe packages' during: [ UUniverse systemUniverse updatePackagesViaWWW ]. (UUniverse systemUniverse newestPackageNamed: 'FreeType Plus') ifNotNilDo: [ :package| |inst| inst := UGlobalInstaller universe: UUniverse systemUniverse. inst planToInstallPackage: package. inst doInstall ]. (HTTPSocket httpGet: 'installer.pbwiki.com/f/LPF.st') readStream fileIn. ================================================================ I already created a bug report for this, Andreas may be able to tell you more: http://bugs.squeak.org/view.php?id=6980 As a workaround you can can use FFI-Kernel-ar6.mcz instead of FFI-Kernel-ar-8.mcz. Bye Torsten ================================================================ > From: Andreas Raab <andreas.raab(a)gmx.de> > Date: March 27, 2008 10:00:21 PM CEST > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > Subject: [squeak-dev] Re: FFI and FreeTypePlus problem? > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > > Yeah, I had forgotten about the problem. The issue comes from a call > to Smalltalk>>recreateSpecialObjectsArray (which is required for the > FFI to work correctly) and which accidentally nukes the external > semaphore table. The fix is simple: Replace the following line in > SystemDictionary>>recreateSpecialObjectsArray > > newArray at: 39 put: Array new. > > by > "Preserve external semaphores when recreating splObjs" > newArray at: 39 put: (self specialObjectsArray at: 39). > > Also, saving and restarting the image after loading the FFI is good > temporary workaround for this problem. > > Cheers, > - Andreas > > Torsten Bergmann wrote: >> I already created a bug report for this, Andreas may be able to >> tell you more: >> http://bugs.squeak.org/view.php?id=6980 >> As a workaround you can can use FFI-Kernel-ar6.mcz >> instead of FFI-Kernel-ar-8.mcz. >> Bye >> Torsten > > >

Sept. 10, 2008

Re: [Pharo-project] How to submit changes when SqueakSource is down ?

by StÃ©phane Ducasse

About package renaming Noury lukas told me that it was quite difficult to rename a package in MC. Last week I got a huge problem because I used the rename functionality of the browser of david and it crew up my system So did you tried your reanme behavior with dependency and the rest. Stef > Hi, > > SqueakSource is down again :-( > Attached a monticello package with a serie of bugfixes and > enhancements tested on pharo-dev of sept: > > *Bug Fixes > -Transcript printing and self evaluating > -Smalltalk printing and self evaluating > -Instance Variable should never start by a capital > > *Enhancemnts > -Monticello Package renaming > -Prefix replacement for classes in a Monticello package > > Regards, > Noury > ------------------------------------------------------------------ > Dr. Noury Bouraqadi - Enseignant/Chercheur > Responsable de l'enseignement de l'informatique > ARMINES - Ecole des Mines de Douai - Dept. I.A. > http://vst.ensm-douai.fr/noury > > European Smalltalk Users Group Board > http://www.esug.org > ------------------------------------------------------------------ > > > <FixesAndEnh-Noury. > 1.mcz>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 10, 2008

Re: [Pharo-project] Hello everyone!

by StÃ©phane Ducasse

>> > yes i could, but do you think that i have a chance to be heard and my > point to be accepted? :) > >> We are talking abut that since years. >> I still do not understand I thought that the svn of the vm code was >> such >> common >> code repository? > > I tried to raise this topic on board meeting, concerning status of > VM-dev group and the answer was like: > - we already have things set up, and each maintainer know/doing > things well. > I'm not sure about current status, but i keep feeling that VM > maintainers efforts dissipating due to lack of > communication/collaboration. No this is a question of power.... :) > > Maybe it is because i'm relatively new, and missing info about how > things was set up long ago, before i came in, maybe people really > collaborate behind the scenes, i don't know. :) > What i really sure about, is that , it will not hurt to call for a > status (re)clarification to know who doing what and how things > working. Yes please do. I would suggest to really work with eliot and get such a structure started. for Cog and hydra first and agglomerate slowly the rest This is years that mike is suggesting to have a real repository for VMs Stef

Sept. 10, 2008

Re: [Pharo-project] Hello everyone!

by Igor Stasenko

2008/9/10 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >> >> Well, as i said, putting FreeType into VM is simple thing. >> But maintaining a code base or regular basis is completely different >> thing. I'm not sure i have enough spare time to do this now. >> First, because i'm busy with Hydra VM. >> Second , I think you are aware, that Cog & Hydra will merge in future. >> Before this happens, i have little interest in supporting >> old-fashioned VMs :) >> >> I planning to do a major refactoring in Hydra, after which , an >> Interpreter/ObjectMemory can be simulated in image. But this will have >> a major impact on backward compatibility. >> >> But for minor changes, like in some plugins, it not hurts a lot. I >> think that, if you planning to maintain own VM, then i'll advice to >> split VMMaker package on two separate parts: >> - VM core >> - all plugins >> >> Because VM is a big code bloat , which is hard to manipulate with. >> >> Also, it would be good to have a common code repository, and separate >> tracker of bugs and fixes for VM/plugins, so it will make an >> integration easier for all interesting parties. > > could you push this idea to the VM maintainers or start to do it? yes i could, but do you think that i have a chance to be heard and my point to be accepted? :) > We are talking abut that since years. > I still do not understand I thought that the svn of the vm code was such > common > code repository? I tried to raise this topic on board meeting, concerning status of VM-dev group and the answer was like: - we already have things set up, and each maintainer know/doing things well. I'm not sure about current status, but i keep feeling that VM maintainers efforts dissipating due to lack of communication/collaboration. Maybe it is because i'm relatively new, and missing info about how things was set up long ago, before i came in, maybe people really collaborate behind the scenes, i don't know. What i really sure about, is that , it will not hurt to call for a status (re)clarification to know who doing what and how things working. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 10, 2008

Re: [Pharo-project] Hello everyone!

by StÃ©phane Ducasse

>> > > Well, as i said, putting FreeType into VM is simple thing. > But maintaining a code base or regular basis is completely different > thing. I'm not sure i have enough spare time to do this now. > First, because i'm busy with Hydra VM. > Second , I think you are aware, that Cog & Hydra will merge in future. > Before this happens, i have little interest in supporting > old-fashioned VMs :) > > I planning to do a major refactoring in Hydra, after which , an > Interpreter/ObjectMemory can be simulated in image. But this will have > a major impact on backward compatibility. > > But for minor changes, like in some plugins, it not hurts a lot. I > think that, if you planning to maintain own VM, then i'll advice to > split VMMaker package on two separate parts: > - VM core > - all plugins > > Because VM is a big code bloat , which is hard to manipulate with. > > Also, it would be good to have a common code repository, and separate > tracker of bugs and fixes for VM/plugins, so it will make an > integration easier for all interesting parties. could you push this idea to the VM maintainers or start to do it? We are talking abut that since years. I still do not understand I thought that the svn of the vm code was such common code repository?

Sept. 10, 2008

Re: [Pharo-project] Hello everyone!

by Igor Stasenko

2008/9/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>> >> >> Well, BitBlt code is , thanks God, platform independent. So you can >> easily backport changes into any VMMaker package. >> As for FT2Plugin , as long as it works well and maintained by its >> developer , i don't see any problem with it. >> I can build VM for win32, and (maybe) for Linux. But i can't do this >> for Macs, since i don't have one :) >> For maintaining a healthy VM , one need to setup all 3 platforms to be >> able to build & test VM on it. Otherwise its not makes any sense, >> because once we have multiple maintainers, the process starts to be >> complicated and will require much more time investments & coordination >> to ensure that some fix or improvement will be delivered fast on all >> platforms well tested and polished. :) > > so how can we progress on this front. > Bryce proposed to build a vm for linux or windows. > I imagine that john could help for the mac one. > Else we can also try. Mathieu recompiles his vm regularly > Well, as i said, putting FreeType into VM is simple thing. But maintaining a code base or regular basis is completely different thing. I'm not sure i have enough spare time to do this now. First, because i'm busy with Hydra VM. Second , I think you are aware, that Cog & Hydra will merge in future. Before this happens, i have little interest in supporting old-fashioned VMs :) I planning to do a major refactoring in Hydra, after which , an Interpreter/ObjectMemory can be simulated in image. But this will have a major impact on backward compatibility. But for minor changes, like in some plugins, it not hurts a lot. I think that, if you planning to maintain own VM, then i'll advice to split VMMaker package on two separate parts: - VM core - all plugins Because VM is a big code bloat , which is hard to manipulate with. Also, it would be good to have a common code repository, and separate tracker of bugs and fixes for VM/plugins, so it will make an integration easier for all interesting parties. > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 10, 2008

Re: [Pharo-project] Hello everyone!

by Igor Stasenko

2008/9/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Igor > > for the concurrency may be something good would be to start writing another > library. > instead of fixing the current one. I know that when we rewrite with get a > lot of bugs > but at least prototyping something would be useful. I'm really nul in > concurrent programming > but I know it should be good. > Well, that's is really tough task, but quite interesting. If we're free to change VM to make better support of atomic operations, like task switching, semaphore signaling etc etc, then it is really worth to do. But first , i'd like to hear a request for features from people. I having own vision, but want to hear your opinion , also maybe i don't see the whole picture, so please provide any info or issues you want to be fixed or features you want to be added or replace old ones. > Stef > -- Best regards, Igor Stasenko AKA sig.

Sept. 10, 2008

Re: [Pharo-project] Hello everyone!

by StÃ©phane Ducasse

>> >> > > Well, BitBlt code is , thanks God, platform independent. So you can > easily backport changes into any VMMaker package. > As for FT2Plugin , as long as it works well and maintained by its > developer , i don't see any problem with it. > I can build VM for win32, and (maybe) for Linux. But i can't do this > for Macs, since i don't have one :) > For maintaining a healthy VM , one need to setup all 3 platforms to be > able to build & test VM on it. Otherwise its not makes any sense, > because once we have multiple maintainers, the process starts to be > complicated and will require much more time investments & coordination > to ensure that some fix or improvement will be delivered fast on all > platforms well tested and polished. :) so how can we progress on this front. Bryce proposed to build a vm for linux or windows. I imagine that john could help for the mac one. Else we can also try. Mathieu recompiles his vm regularly Stef

Sept. 9, 2008

Re: [Pharo-project] Hello everyone!

by StÃ©phane Ducasse

On Sep 9, 2008, at 6:49 PM, Adrian Lienhard wrote: > > On Sep 9, 2008, at 17:43 , Igor Stasenko wrote: > >> 2008/9/9 Adrian Lienhard <adi(a)netstyle.ch>: >>> Welcome, Igor! >>> >>> Would you also be interested to help maintain the VM? Recently on >>> this list >>> we've discussed whether it would make sense to have our own Pharo >>> VM. For >>> instance, to have the Freetype Plugin by default, but maybe also >>> for larger >>> improvements like the ones that come from Eliot. >>> >> >> Making a Freetype plugin to be compiled as internal one is not a good >> reason to start VM branch :) > > Can you elaborate on why not? The background is that we really want > to have better fonts. One possibility is the Freetype work of Andrew > Tween, which needs the FT2Plugin and the modified BitBlt plugin for > subpixel antialiasing to work well. And this solution makes only > sense if people can download a VM for their platform that includes > this support by default. Yes we need that. > > > Adrian > >> And Eliot's improvements and his work will sooner or later lead to >> new >> , better thing, which then could replace current VM. >> So, i think it would be better to help Eliot with this process by >> proposing/discussing changes instead of developing separate branch. >> Of course, making own branch will give you freedom in directions >> where >> to go, like dropping compatibility, removing unwanted things etc etc. >> But then, the farther you go with it, merging changes will be harder >> and harder (if possible at all). >>> From this point, i think that its better to keep one VM and work >>> together on it. >> >> It would be easier to maintain things, if VM were written completely >> in single language (smalltalk or C), but currently this is not so >> elegant. And putting groundbreaking changes in smalltalk part most >> probably will lead to changes in C part, which is very rigid part of >> VM and most hard maintain , because a single structural change can >> lead to multiple changes in code for separate platforms. And then you >> need to test them, on at least all major platforms, not speaking >> about >> different ports to minor ones. This is a really complicated and you >> can lost there forever :) >> >> >>> Cheers, >>> Adrian >>> >>> On Sep 9, 2008, at 05:05 , Igor Stasenko wrote: >>> >>>> I just subscribed and want to say hello to this list. :) >>>> >>>> At ESUG we discussed with Stephane and Markus some things in Squeak >>>> (and consequently in Pharo), which really need an overlook and >>>> better >>>> implementation. >>>> Stephane asked me, to think about overlooking Processes and >>>> concurrency in its current state. >>>> First, i must say that it is very fragile part of system because >>>> most >>>> things written w/o concurrency in mind. Last year i seen many >>>> issues >>>> related to concurrency: Semaphore , Delay, Process, Scheduler. >>>> Some of >>>> them resolved, some of them resolved in an ugly and hackish way - >>>> mostly as workarounds of lacking critical VM primitives which >>>> should >>>> guarantee atomicity for different purposes, and some of them is not >>>> resolved at all. >>>> >>>> Some things, which i noted and which i like/not like, can be >>>> found in >>>> squeak-dev list. But i will repeat them here, in single place: >>>> - Process should assume that it is running in ideal environment >>>> (e.g. >>>> in parallel to another processes w/o any preemption). Every bit of >>>> code, which requires synchronization should be based/take into >>>> account >>>> this assumption. >>>> >>>> a process should have three discrete states: >>>> - suspended - when initially created. >>>> - running - when you invoke resume. >>>> - terminated - when process no longer running and can't be resumed. >>>> >>>> It is wrong to consider a process which waiting on semaphore >>>> signal as >>>> suspended process. >>>> (see http://bugs.squeak.org/view.php?id=6822) >>>> Process which waits on semaphore is actually performing an action, >>>> while , by definition, a suspended process can't perform any >>>> action. >>>> >>>> Concerning process termination, it is also a can of worms to deal >>>> with: >>>> >>>> - process termination means stop doing anything in requested >>>> process, >>>> but this going into conflict with exception handling mechanism. >>>> The conflict comes from two things like #ensure: and >>>> #ifCurtailed: . >>>> Such mechanisms used to ensure that some code will have chance to >>>> run >>>> under any circumstances, regardless of the state of computation. >>>> It is >>>> interesting, where such code should run? In a process which >>>> initiated >>>> a terminate request, or in process which needs to be terminated by >>>> request. Most valid, of course - to run them in a terminating >>>> process. >>>> The problem, however, how to achieve that. >>>> >>>> Someone suggested to throw an exception, like >>>> ProcessTerminateException to indicate that the given process is >>>> going >>>> to be terminated. >>>> Such thing is also going into conflict with different points of >>>> view: >>>> a Process termination is usual functionality, provided for use, >>>> so why >>>> it should be considered as exceptional? >>>> >>>> Maybe, to solve the conflicts, and avoid using exceptions in an >>>> arguable way, it would be better to add support of process >>>> termination >>>> notification. So, each time process is going to terminate, it can >>>> notify all interesting parties of such event. >>>> Then, instead of using #ensure: to free critical system >>>> resources, one >>>> could use notification. >>>> >>>> As you can see, there is more questions than answers :) >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 >

Sept. 9, 2008

Re: [Pharo-project] Hello everyone!

by StÃ©phane Ducasse

On Sep 9, 2008, at 5:43 PM, Igor Stasenko wrote: > 2008/9/9 Adrian Lienhard <adi(a)netstyle.ch>: >> Welcome, Igor! >> >> Would you also be interested to help maintain the VM? Recently on >> this list >> we've discussed whether it would make sense to have our own Pharo >> VM. For >> instance, to have the Freetype Plugin by default, but maybe also >> for larger >> improvements like the ones that come from Eliot. >> > > Making a Freetype plugin to be compiled as internal one is not a good > reason to start VM branch :) > And Eliot's improvements and his work will sooner or later lead to new > , better thing, which then could replace current VM. > So, i think it would be better to help Eliot with this process by > proposing/discussing changes instead of developing separate branch. yes this is what marcus will do. > Of course, making own branch will give you freedom in directions where > to go, like dropping compatibility, removing unwanted things etc etc. > But then, the farther you go with it, merging changes will be harder > and harder (if possible at all). I think that what adrian wanted to say is that this is stupid not to integrate well freetype just because we cannot recompile the vm. >> From this point, i think that its better to keep one VM and work >> together on it. > > It would be easier to maintain things, if VM were written completely > in single language (smalltalk or C), but currently this is not so > elegant. And putting groundbreaking changes in smalltalk part most > probably will lead to changes in C part, which is very rigid part of > VM and most hard maintain , because a single structural change can > lead to multiple changes in code for separate platforms. And then you > need to test them, on at least all major platforms, not speaking about > different ports to minor ones. This is a really complicated and you > can lost there forever :) > > >> Cheers, >> Adrian >> >> On Sep 9, 2008, at 05:05 , Igor Stasenko wrote: >> >>> I just subscribed and want to say hello to this list. :) >>> >>> At ESUG we discussed with Stephane and Markus some things in Squeak >>> (and consequently in Pharo), which really need an overlook and >>> better >>> implementation. >>> Stephane asked me, to think about overlooking Processes and >>> concurrency in its current state. >>> First, i must say that it is very fragile part of system because >>> most >>> things written w/o concurrency in mind. Last year i seen many issues >>> related to concurrency: Semaphore , Delay, Process, Scheduler. >>> Some of >>> them resolved, some of them resolved in an ugly and hackish way - >>> mostly as workarounds of lacking critical VM primitives which should >>> guarantee atomicity for different purposes, and some of them is not >>> resolved at all. >>> >>> Some things, which i noted and which i like/not like, can be found >>> in >>> squeak-dev list. But i will repeat them here, in single place: >>> - Process should assume that it is running in ideal environment >>> (e.g. >>> in parallel to another processes w/o any preemption). Every bit of >>> code, which requires synchronization should be based/take into >>> account >>> this assumption. >>> >>> a process should have three discrete states: >>> - suspended - when initially created. >>> - running - when you invoke resume. >>> - terminated - when process no longer running and can't be resumed. >>> >>> It is wrong to consider a process which waiting on semaphore >>> signal as >>> suspended process. >>> (see http://bugs.squeak.org/view.php?id=6822) >>> Process which waits on semaphore is actually performing an action, >>> while , by definition, a suspended process can't perform any action. >>> >>> Concerning process termination, it is also a can of worms to deal >>> with: >>> >>> - process termination means stop doing anything in requested >>> process, >>> but this going into conflict with exception handling mechanism. >>> The conflict comes from two things like #ensure: and #ifCurtailed: . >>> Such mechanisms used to ensure that some code will have chance to >>> run >>> under any circumstances, regardless of the state of computation. >>> It is >>> interesting, where such code should run? In a process which >>> initiated >>> a terminate request, or in process which needs to be terminated by >>> request. Most valid, of course - to run them in a terminating >>> process. >>> The problem, however, how to achieve that. >>> >>> Someone suggested to throw an exception, like >>> ProcessTerminateException to indicate that the given process is >>> going >>> to be terminated. >>> Such thing is also going into conflict with different points of >>> view: >>> a Process termination is usual functionality, provided for use, so >>> why >>> it should be considered as exceptional? >>> >>> Maybe, to solve the conflicts, and avoid using exceptions in an >>> arguable way, it would be better to add support of process >>> termination >>> notification. So, each time process is going to terminate, it can >>> notify all interesting parties of such event. >>> Then, instead of using #ensure: to free critical system resources, >>> one >>> could use notification. >>> >>> As you can see, there is more questions than answers :) >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 9, 2008

Re: [Pharo-project] Hello everyone!

by StÃ©phane Ducasse

Igor for the concurrency may be something good would be to start writing another library. instead of fixing the current one. I know that when we rewrite with get a lot of bugs but at least prototyping something would be useful. I'm really nul in concurrent programming but I know it should be good. Stef On Sep 9, 2008, at 9:41 AM, Adrian Lienhard wrote: > Welcome, Igor! > > Would you also be interested to help maintain the VM? Recently on > this list we've discussed whether it would make sense to have our > own Pharo VM. For instance, to have the Freetype Plugin by default, > but maybe also for larger improvements like the ones that come from > Eliot. > > Cheers, > Adrian > > On Sep 9, 2008, at 05:05 , Igor Stasenko wrote: > >> I just subscribed and want to say hello to this list. :) >> >> At ESUG we discussed with Stephane and Markus some things in Squeak >> (and consequently in Pharo), which really need an overlook and better >> implementation. >> Stephane asked me, to think about overlooking Processes and >> concurrency in its current state. >> First, i must say that it is very fragile part of system because most >> things written w/o concurrency in mind. Last year i seen many issues >> related to concurrency: Semaphore , Delay, Process, Scheduler. Some >> of >> them resolved, some of them resolved in an ugly and hackish way - >> mostly as workarounds of lacking critical VM primitives which should >> guarantee atomicity for different purposes, and some of them is not >> resolved at all. >> >> Some things, which i noted and which i like/not like, can be found in >> squeak-dev list. But i will repeat them here, in single place: >> - Process should assume that it is running in ideal environment (e.g. >> in parallel to another processes w/o any preemption). Every bit of >> code, which requires synchronization should be based/take into >> account >> this assumption. >> >> a process should have three discrete states: >> - suspended - when initially created. >> - running - when you invoke resume. >> - terminated - when process no longer running and can't be resumed. >> >> It is wrong to consider a process which waiting on semaphore signal >> as >> suspended process. >> (see http://bugs.squeak.org/view.php?id=6822) >> Process which waits on semaphore is actually performing an action, >> while , by definition, a suspended process can't perform any action. >> >> Concerning process termination, it is also a can of worms to deal >> with: >> >> - process termination means stop doing anything in requested process, >> but this going into conflict with exception handling mechanism. >> The conflict comes from two things like #ensure: and #ifCurtailed: . >> Such mechanisms used to ensure that some code will have chance to run >> under any circumstances, regardless of the state of computation. It >> is >> interesting, where such code should run? In a process which initiated >> a terminate request, or in process which needs to be terminated by >> request. Most valid, of course - to run them in a terminating >> process. >> The problem, however, how to achieve that. >> >> Someone suggested to throw an exception, like >> ProcessTerminateException to indicate that the given process is going >> to be terminated. >> Such thing is also going into conflict with different points of view: >> a Process termination is usual functionality, provided for use, so >> why >> it should be considered as exceptional? >> >> Maybe, to solve the conflicts, and avoid using exceptions in an >> arguable way, it would be better to add support of process >> termination >> notification. So, each time process is going to terminate, it can >> notify all interesting parties of such event. >> Then, instead of using #ensure: to free critical system resources, >> one >> could use notification. >> >> As you can see, there is more questions than answers :) >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 >

Sept. 9, 2008

Re: [Pharo-project] How to submit changes when SqueakSource is down ?

by StÃ©phane Ducasse

to reply to your question: - if this is changeset with some coherent set of fixes, create an entry on the issue (else pslit the cs) - send an email here "saying guys please review" - when this is done, we can push changes via changeset really fast now in pharo we worked with marcus to minimize the time it can take us when **we** perform a changes or apply a change in the latest release (versus merging package published on an old versions) - we are missing an scp connection calls to get nearly a push one button to release a new version Stef On Sep 9, 2008, at 12:11 PM, Noury Bouraqadi wrote: > Hi, > > SqueakSource is down again :-( > Attached a monticello package with a serie of bugfixes and > enhancements tested on pharo-dev of sept: > > *Bug Fixes > -Transcript printing and self evaluating > -Smalltalk printing and self evaluating > -Instance Variable should never start by a capital > > *Enhancemnts > -Monticello Package renaming > -Prefix replacement for classes in a Monticello package > > Regards, > Noury > ------------------------------------------------------------------ > Dr. Noury Bouraqadi - Enseignant/Chercheur > Responsable de l'enseignement de l'informatique > ARMINES - Ecole des Mines de Douai - Dept. I.A. > http://vst.ensm-douai.fr/noury > > European Smalltalk Users Group Board > http://www.esug.org > ------------------------------------------------------------------ > > > <FixesAndEnh-Noury. > 1.mcz>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 9, 2008

Re: [Pharo-project] How to submit changes when SqueakSource is down ?

by StÃ©phane Ducasse

:) For me this was not http://downWhenWeReallyNeedItAndThisSunday :) Stef >>>> >> http://downforeveryoneorjustme.com/ >> > well the squeaksource is often > http://downforeveryoneincludingme.com/ > :)

Sept. 9, 2008

Re: [Pharo-project] Wiki page rename

by StÃ©phane Ducasse

>> > The only option I guess is to checkout svn and move the file to > the new name. > > Norbert > > P.S.: Back from vacation and trying to find time to do some pharo > stuff I know the feeling (3 kids * 3 schools * wife = teacher * new team * new secretary * new deadlines * house with roof with holes) But this is cool message to my hears. Thanks! We are reorganizing ourselves and we would like to have - etoy out - polymorph in - free type in for the first release and a lot of little fixes of course. Stef

Sept. 9, 2008

Re: [Pharo-project] Hello everyone!

by Igor Stasenko

2008/9/9 Adrian Lienhard <adi(a)netstyle.ch>: > > On Sep 9, 2008, at 17:43 , Igor Stasenko wrote: > >> 2008/9/9 Adrian Lienhard <adi(a)netstyle.ch>: >>> >>> Welcome, Igor! >>> >>> Would you also be interested to help maintain the VM? Recently on this >>> list >>> we've discussed whether it would make sense to have our own Pharo VM. For >>> instance, to have the Freetype Plugin by default, but maybe also for >>> larger >>> improvements like the ones that come from Eliot. >>> >> >> Making a Freetype plugin to be compiled as internal one is not a good >> reason to start VM branch :) > > Can you elaborate on why not? The background is that we really want to have > better fonts. One possibility is the Freetype work of Andrew Tween, which > needs the FT2Plugin and the modified BitBlt plugin for subpixel antialiasing > to work well. And this solution makes only sense if people can download a VM > for their platform that includes this support by default. > Well, BitBlt code is , thanks God, platform independent. So you can easily backport changes into any VMMaker package. As for FT2Plugin , as long as it works well and maintained by its developer , i don't see any problem with it. I can build VM for win32, and (maybe) for Linux. But i can't do this for Macs, since i don't have one :) For maintaining a healthy VM , one need to setup all 3 platforms to be able to build & test VM on it. Otherwise its not makes any sense, because once we have multiple maintainers, the process starts to be complicated and will require much more time investments & coordination to ensure that some fix or improvement will be delivered fast on all platforms well tested and polished. :) > Adrian > >> And Eliot's improvements and his work will sooner or later lead to new >> , better thing, which then could replace current VM. >> So, i think it would be better to help Eliot with this process by >> proposing/discussing changes instead of developing separate branch. >> Of course, making own branch will give you freedom in directions where >> to go, like dropping compatibility, removing unwanted things etc etc. >> But then, the farther you go with it, merging changes will be harder >> and harder (if possible at all). >>> >>> From this point, i think that its better to keep one VM and work together >>> on it. >> >> It would be easier to maintain things, if VM were written completely >> in single language (smalltalk or C), but currently this is not so >> elegant. And putting groundbreaking changes in smalltalk part most >> probably will lead to changes in C part, which is very rigid part of >> VM and most hard maintain , because a single structural change can >> lead to multiple changes in code for separate platforms. And then you >> need to test them, on at least all major platforms, not speaking about >> different ports to minor ones. This is a really complicated and you >> can lost there forever :) >> >> >>> Cheers, >>> Adrian >>> >>> On Sep 9, 2008, at 05:05 , Igor Stasenko wrote: >>> >>>> I just subscribed and want to say hello to this list. :) >>>> >>>> At ESUG we discussed with Stephane and Markus some things in Squeak >>>> (and consequently in Pharo), which really need an overlook and better >>>> implementation. >>>> Stephane asked me, to think about overlooking Processes and >>>> concurrency in its current state. >>>> First, i must say that it is very fragile part of system because most >>>> things written w/o concurrency in mind. Last year i seen many issues >>>> related to concurrency: Semaphore , Delay, Process, Scheduler. Some of >>>> them resolved, some of them resolved in an ugly and hackish way - >>>> mostly as workarounds of lacking critical VM primitives which should >>>> guarantee atomicity for different purposes, and some of them is not >>>> resolved at all. >>>> >>>> Some things, which i noted and which i like/not like, can be found in >>>> squeak-dev list. But i will repeat them here, in single place: >>>> - Process should assume that it is running in ideal environment (e.g. >>>> in parallel to another processes w/o any preemption). Every bit of >>>> code, which requires synchronization should be based/take into account >>>> this assumption. >>>> >>>> a process should have three discrete states: >>>> - suspended - when initially created. >>>> - running - when you invoke resume. >>>> - terminated - when process no longer running and can't be resumed. >>>> >>>> It is wrong to consider a process which waiting on semaphore signal as >>>> suspended process. >>>> (see http://bugs.squeak.org/view.php?id=6822) >>>> Process which waits on semaphore is actually performing an action, >>>> while , by definition, a suspended process can't perform any action. >>>> >>>> Concerning process termination, it is also a can of worms to deal with: >>>> >>>> - process termination means stop doing anything in requested process, >>>> but this going into conflict with exception handling mechanism. >>>> The conflict comes from two things like #ensure: and #ifCurtailed: . >>>> Such mechanisms used to ensure that some code will have chance to run >>>> under any circumstances, regardless of the state of computation. It is >>>> interesting, where such code should run? In a process which initiated >>>> a terminate request, or in process which needs to be terminated by >>>> request. Most valid, of course - to run them in a terminating process. >>>> The problem, however, how to achieve that. >>>> >>>> Someone suggested to throw an exception, like >>>> ProcessTerminateException to indicate that the given process is going >>>> to be terminated. >>>> Such thing is also going into conflict with different points of view: >>>> a Process termination is usual functionality, provided for use, so why >>>> it should be considered as exceptional? >>>> >>>> Maybe, to solve the conflicts, and avoid using exceptions in an >>>> arguable way, it would be better to add support of process termination >>>> notification. So, each time process is going to terminate, it can >>>> notify all interesting parties of such event. >>>> Then, instead of using #ensure: to free critical system resources, one >>>> could use notification. >>>> >>>> As you can see, there is more questions than answers :) >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Sept. 9, 2008

Re: [Pharo-project] Hello everyone!

by Adrian Lienhard

On Sep 9, 2008, at 17:43 , Igor Stasenko wrote: > 2008/9/9 Adrian Lienhard <adi(a)netstyle.ch>: >> Welcome, Igor! >> >> Would you also be interested to help maintain the VM? Recently on >> this list >> we've discussed whether it would make sense to have our own Pharo >> VM. For >> instance, to have the Freetype Plugin by default, but maybe also >> for larger >> improvements like the ones that come from Eliot. >> > > Making a Freetype plugin to be compiled as internal one is not a good > reason to start VM branch :) Can you elaborate on why not? The background is that we really want to have better fonts. One possibility is the Freetype work of Andrew Tween, which needs the FT2Plugin and the modified BitBlt plugin for subpixel antialiasing to work well. And this solution makes only sense if people can download a VM for their platform that includes this support by default. Adrian > And Eliot's improvements and his work will sooner or later lead to new > , better thing, which then could replace current VM. > So, i think it would be better to help Eliot with this process by > proposing/discussing changes instead of developing separate branch. > Of course, making own branch will give you freedom in directions where > to go, like dropping compatibility, removing unwanted things etc etc. > But then, the farther you go with it, merging changes will be harder > and harder (if possible at all). >> From this point, i think that its better to keep one VM and work >> together on it. > > It would be easier to maintain things, if VM were written completely > in single language (smalltalk or C), but currently this is not so > elegant. And putting groundbreaking changes in smalltalk part most > probably will lead to changes in C part, which is very rigid part of > VM and most hard maintain , because a single structural change can > lead to multiple changes in code for separate platforms. And then you > need to test them, on at least all major platforms, not speaking about > different ports to minor ones. This is a really complicated and you > can lost there forever :) > > >> Cheers, >> Adrian >> >> On Sep 9, 2008, at 05:05 , Igor Stasenko wrote: >> >>> I just subscribed and want to say hello to this list. :) >>> >>> At ESUG we discussed with Stephane and Markus some things in Squeak >>> (and consequently in Pharo), which really need an overlook and >>> better >>> implementation. >>> Stephane asked me, to think about overlooking Processes and >>> concurrency in its current state. >>> First, i must say that it is very fragile part of system because >>> most >>> things written w/o concurrency in mind. Last year i seen many issues >>> related to concurrency: Semaphore , Delay, Process, Scheduler. >>> Some of >>> them resolved, some of them resolved in an ugly and hackish way - >>> mostly as workarounds of lacking critical VM primitives which should >>> guarantee atomicity for different purposes, and some of them is not >>> resolved at all. >>> >>> Some things, which i noted and which i like/not like, can be found >>> in >>> squeak-dev list. But i will repeat them here, in single place: >>> - Process should assume that it is running in ideal environment >>> (e.g. >>> in parallel to another processes w/o any preemption). Every bit of >>> code, which requires synchronization should be based/take into >>> account >>> this assumption. >>> >>> a process should have three discrete states: >>> - suspended - when initially created. >>> - running - when you invoke resume. >>> - terminated - when process no longer running and can't be resumed. >>> >>> It is wrong to consider a process which waiting on semaphore >>> signal as >>> suspended process. >>> (see http://bugs.squeak.org/view.php?id=6822) >>> Process which waits on semaphore is actually performing an action, >>> while , by definition, a suspended process can't perform any action. >>> >>> Concerning process termination, it is also a can of worms to deal >>> with: >>> >>> - process termination means stop doing anything in requested >>> process, >>> but this going into conflict with exception handling mechanism. >>> The conflict comes from two things like #ensure: and #ifCurtailed: . >>> Such mechanisms used to ensure that some code will have chance to >>> run >>> under any circumstances, regardless of the state of computation. >>> It is >>> interesting, where such code should run? In a process which >>> initiated >>> a terminate request, or in process which needs to be terminated by >>> request. Most valid, of course - to run them in a terminating >>> process. >>> The problem, however, how to achieve that. >>> >>> Someone suggested to throw an exception, like >>> ProcessTerminateException to indicate that the given process is >>> going >>> to be terminated. >>> Such thing is also going into conflict with different points of >>> view: >>> a Process termination is usual functionality, provided for use, so >>> why >>> it should be considered as exceptional? >>> >>> Maybe, to solve the conflicts, and avoid using exceptions in an >>> arguable way, it would be better to add support of process >>> termination >>> notification. So, each time process is going to terminate, it can >>> notify all interesting parties of such event. >>> Then, instead of using #ensure: to free critical system resources, >>> one >>> could use notification. >>> >>> As you can see, there is more questions than answers :) >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 9, 2008

Re: [Pharo-project] How to submit changes when SqueakSource is down ?

by Igor Stasenko

2008/9/9 Serge Stinckwich <serge.stinckwich(a)doesnotunderstand.org>: > 2008/9/9 Adrian Lienhard <adi(a)netstyle.ch>: >> >> On Sep 9, 2008, at 12:11 , Noury Bouraqadi wrote: >> >>> Hi, >>> >>> SqueakSource is down again :-( > > > When a site seems to be down, you can check with : > http://downforeveryoneorjustme.com/ > well the squeaksource is often http://downforeveryoneincludingme.com/ :) > -- > Serge Stinckwich > Smalltalkers do: [:it | All with: Class, (And love: it)] > http://blog.doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 9, 2008

Re: [Pharo-project] Hello everyone!

by Igor Stasenko

2008/9/9 Adrian Lienhard <adi(a)netstyle.ch>: > Welcome, Igor! > > Would you also be interested to help maintain the VM? Recently on this list > we've discussed whether it would make sense to have our own Pharo VM. For > instance, to have the Freetype Plugin by default, but maybe also for larger > improvements like the ones that come from Eliot. > Making a Freetype plugin to be compiled as internal one is not a good reason to start VM branch :) And Eliot's improvements and his work will sooner or later lead to new , better thing, which then could replace current VM. So, i think it would be better to help Eliot with this process by proposing/discussing changes instead of developing separate branch. Of course, making own branch will give you freedom in directions where to go, like dropping compatibility, removing unwanted things etc etc. But then, the farther you go with it, merging changes will be harder and harder (if possible at all). >From this point, i think that its better to keep one VM and work together on it. It would be easier to maintain things, if VM were written completely in single language (smalltalk or C), but currently this is not so elegant. And putting groundbreaking changes in smalltalk part most probably will lead to changes in C part, which is very rigid part of VM and most hard maintain , because a single structural change can lead to multiple changes in code for separate platforms. And then you need to test them, on at least all major platforms, not speaking about different ports to minor ones. This is a really complicated and you can lost there forever :) > Cheers, > Adrian > > On Sep 9, 2008, at 05:05 , Igor Stasenko wrote: > >> I just subscribed and want to say hello to this list. :) >> >> At ESUG we discussed with Stephane and Markus some things in Squeak >> (and consequently in Pharo), which really need an overlook and better >> implementation. >> Stephane asked me, to think about overlooking Processes and >> concurrency in its current state. >> First, i must say that it is very fragile part of system because most >> things written w/o concurrency in mind. Last year i seen many issues >> related to concurrency: Semaphore , Delay, Process, Scheduler. Some of >> them resolved, some of them resolved in an ugly and hackish way - >> mostly as workarounds of lacking critical VM primitives which should >> guarantee atomicity for different purposes, and some of them is not >> resolved at all. >> >> Some things, which i noted and which i like/not like, can be found in >> squeak-dev list. But i will repeat them here, in single place: >> - Process should assume that it is running in ideal environment (e.g. >> in parallel to another processes w/o any preemption). Every bit of >> code, which requires synchronization should be based/take into account >> this assumption. >> >> a process should have three discrete states: >> - suspended - when initially created. >> - running - when you invoke resume. >> - terminated - when process no longer running and can't be resumed. >> >> It is wrong to consider a process which waiting on semaphore signal as >> suspended process. >> (see http://bugs.squeak.org/view.php?id=6822) >> Process which waits on semaphore is actually performing an action, >> while , by definition, a suspended process can't perform any action. >> >> Concerning process termination, it is also a can of worms to deal with: >> >> - process termination means stop doing anything in requested process, >> but this going into conflict with exception handling mechanism. >> The conflict comes from two things like #ensure: and #ifCurtailed: . >> Such mechanisms used to ensure that some code will have chance to run >> under any circumstances, regardless of the state of computation. It is >> interesting, where such code should run? In a process which initiated >> a terminate request, or in process which needs to be terminated by >> request. Most valid, of course - to run them in a terminating process. >> The problem, however, how to achieve that. >> >> Someone suggested to throw an exception, like >> ProcessTerminateException to indicate that the given process is going >> to be terminated. >> Such thing is also going into conflict with different points of view: >> a Process termination is usual functionality, provided for use, so why >> it should be considered as exceptional? >> >> Maybe, to solve the conflicts, and avoid using exceptions in an >> arguable way, it would be better to add support of process termination >> notification. So, each time process is going to terminate, it can >> notify all interesting parties of such event. >> Then, instead of using #ensure: to free critical system resources, one >> could use notification. >> >> As you can see, there is more questions than answers :) >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Sept. 9, 2008

Re: [Pharo-project] Hello everyone!

by Igor Stasenko

2008/9/9 Bill Schwab <BSchwab(a)anest.ufl.edu>: > Igor, > > THANKS for thinking about concurrency. Processes need to be sound. Re > #ensure:, we might consider "unsuspending/unterminating" the process > long enough to run the block. That way the block runs in the thread it > expects, after which, there would hopefully be nothing else to do?? > The problem with exceptions, that some exception handling code can simply ignore exception and continue to run - from same or from different point. This will lead to situation, that issued termination request will not guarantee that process will be terminated. This is what i think we don't want to see, because its very controversial. That's why i thinking that using exceptions is not the way to go. Maybe, we could use a trick by overriding #pass and #return methods in ProcessTerminateException class, to ensure that it will continue unwinding stack. But how to deal with following code: [ ..... ] ensure: [ ^self ]. [ .... ] on: Error do: [:ex | ^ self ]. > Re using exceptions to indicate impending termination, that sounds more > like an event (potentially many consumers). If it is simply a > system-level trick, then I suppose it's fine. > Yes, it can be pushed into process to indicate termination, so user code could use it to differentiate behavior on it. But actual termination and stack unwinding should be separate thing, which should guarantee that process will be terminated > Bill > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 273-6785 > FAX: (352) 392-7029 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 9, 2008

Re: [Pharo-project] Hello everyone!

by Bill Schwab

Igor, THANKS for thinking about concurrency. Processes need to be sound. Re #ensure:, we might consider "unsuspending/unterminating" the process long enough to run the block. That way the block runs in the thread it expects, after which, there would hopefully be nothing else to do?? Re using exceptions to indicate impending termination, that sounds more like an event (potentially many consumers). If it is simply a system-level trick, then I suppose it's fine. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029

Sept. 9, 2008

Re: [Pharo-project] How to submit changes when SqueakSource is down ?

by Noury Bouraqadi

On 9 sept. 08, at 13:49, Serge Stinckwich wrote: > 2008/9/9 Adrian Lienhard <adi(a)netstyle.ch>: >> >> On Sep 9, 2008, at 12:11 , Noury Bouraqadi wrote: >> >>> Hi, >>> >>> SqueakSource is down again :-( > > > When a site seems to be down, you can check with : > http://downforeveryoneorjustme.com/ > Thanks Serge for this useful site. Note that SqueakSource was really down. An apologize message was displayed (see attachement). Why is the server so frequently down. Is there a size limit in SqueakSource ? Noury ------------------------------------------------------------------ Dr. Noury Bouraqadi - Enseignant/Chercheur Responsable de l'enseignement de l'informatique ARMINES - Ecole des Mines de Douai - Dept. I.A. http://vst.ensm-douai.fr/noury European Smalltalk Users Group Board http://www.esug.org ------------------------------------------------------------------

Sept. 9, 2008

Re: [Pharo-project] How to submit changes when SqueakSource is down ?

by Serge Stinckwich

2008/9/9 Adrian Lienhard <adi(a)netstyle.ch>: > > On Sep 9, 2008, at 12:11 , Noury Bouraqadi wrote: > >> Hi, >> >> SqueakSource is down again :-( When a site seems to be down, you can check with : http://downforeveryoneorjustme.com/ -- Serge Stinckwich Smalltalkers do: [:it | All with: Class, (And love: it)] http://blog.doesnotunderstand.org/

Sept. 9, 2008

Re: [Pharo-project] How to submit changes when SqueakSource is down ?

by Adrian Lienhard

On Sep 9, 2008, at 12:11 , Noury Bouraqadi wrote: > Hi, > > SqueakSource is down again :-( Hi Noury, it works fine for me right now Adrian

Sept. 9, 2008

[Pharo-project] How to submit changes when SqueakSource is down ?

by Noury Bouraqadi

Hi, SqueakSource is down again :-( Attached a monticello package with a serie of bugfixes and enhancements tested on pharo-dev of sept: *Bug Fixes -Transcript printing and self evaluating -Smalltalk printing and self evaluating -Instance Variable should never start by a capital *Enhancemnts -Monticello Package renaming -Prefix replacement for classes in a Monticello package Regards, Noury ------------------------------------------------------------------ Dr. Noury Bouraqadi - Enseignant/Chercheur Responsable de l'enseignement de l'informatique ARMINES - Ecole des Mines de Douai - Dept. I.A. http://vst.ensm-douai.fr/noury European Smalltalk Users Group Board http://www.esug.org ------------------------------------------------------------------

Sept. 9, 2008

Re: [Pharo-project] Wiki page rename

by Norbert Hartl

On Sun, 2008-08-31 at 14:02 -0400, Bill Schwab wrote: > Hello, > > Anybody know how to rename a page on the Wiki? Is it as crude as > add/copy/delete? Hopefully there is a better way?? > The only option I guess is to checkout svn and move the file to the new name. Norbert P.S.: Back from vacation and trying to find time to do some pharo stuff > Bill > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 273-6785 > FAX: (352) 392-7029 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 9, 2008

Re: [Pharo-project] Hello everyone!

by Adrian Lienhard

Welcome, Igor! Would you also be interested to help maintain the VM? Recently on this list we've discussed whether it would make sense to have our own Pharo VM. For instance, to have the Freetype Plugin by default, but maybe also for larger improvements like the ones that come from Eliot. Cheers, Adrian On Sep 9, 2008, at 05:05 , Igor Stasenko wrote: > I just subscribed and want to say hello to this list. :) > > At ESUG we discussed with Stephane and Markus some things in Squeak > (and consequently in Pharo), which really need an overlook and better > implementation. > Stephane asked me, to think about overlooking Processes and > concurrency in its current state. > First, i must say that it is very fragile part of system because most > things written w/o concurrency in mind. Last year i seen many issues > related to concurrency: Semaphore , Delay, Process, Scheduler. Some of > them resolved, some of them resolved in an ugly and hackish way - > mostly as workarounds of lacking critical VM primitives which should > guarantee atomicity for different purposes, and some of them is not > resolved at all. > > Some things, which i noted and which i like/not like, can be found in > squeak-dev list. But i will repeat them here, in single place: > - Process should assume that it is running in ideal environment (e.g. > in parallel to another processes w/o any preemption). Every bit of > code, which requires synchronization should be based/take into account > this assumption. > > a process should have three discrete states: > - suspended - when initially created. > - running - when you invoke resume. > - terminated - when process no longer running and can't be resumed. > > It is wrong to consider a process which waiting on semaphore signal as > suspended process. > (see http://bugs.squeak.org/view.php?id=6822) > Process which waits on semaphore is actually performing an action, > while , by definition, a suspended process can't perform any action. > > Concerning process termination, it is also a can of worms to deal > with: > > - process termination means stop doing anything in requested process, > but this going into conflict with exception handling mechanism. > The conflict comes from two things like #ensure: and #ifCurtailed: . > Such mechanisms used to ensure that some code will have chance to run > under any circumstances, regardless of the state of computation. It is > interesting, where such code should run? In a process which initiated > a terminate request, or in process which needs to be terminated by > request. Most valid, of course - to run them in a terminating process. > The problem, however, how to achieve that. > > Someone suggested to throw an exception, like > ProcessTerminateException to indicate that the given process is going > to be terminated. > Such thing is also going into conflict with different points of view: > a Process termination is usual functionality, provided for use, so why > it should be considered as exceptional? > > Maybe, to solve the conflicts, and avoid using exceptions in an > arguable way, it would be better to add support of process termination > notification. So, each time process is going to terminate, it can > notify all interesting parties of such event. > Then, instead of using #ensure: to free critical system resources, one > could use notification. > > As you can see, there is more questions than answers :) > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 9, 2008

[Pharo-project] Hello everyone!

by Igor Stasenko

I just subscribed and want to say hello to this list. :) At ESUG we discussed with Stephane and Markus some things in Squeak (and consequently in Pharo), which really need an overlook and better implementation. Stephane asked me, to think about overlooking Processes and concurrency in its current state. First, i must say that it is very fragile part of system because most things written w/o concurrency in mind. Last year i seen many issues related to concurrency: Semaphore , Delay, Process, Scheduler. Some of them resolved, some of them resolved in an ugly and hackish way - mostly as workarounds of lacking critical VM primitives which should guarantee atomicity for different purposes, and some of them is not resolved at all. Some things, which i noted and which i like/not like, can be found in squeak-dev list. But i will repeat them here, in single place: - Process should assume that it is running in ideal environment (e.g. in parallel to another processes w/o any preemption). Every bit of code, which requires synchronization should be based/take into account this assumption. a process should have three discrete states: - suspended - when initially created. - running - when you invoke resume. - terminated - when process no longer running and can't be resumed. It is wrong to consider a process which waiting on semaphore signal as suspended process. (see http://bugs.squeak.org/view.php?id=6822) Process which waits on semaphore is actually performing an action, while , by definition, a suspended process can't perform any action. Concerning process termination, it is also a can of worms to deal with: - process termination means stop doing anything in requested process, but this going into conflict with exception handling mechanism. The conflict comes from two things like #ensure: and #ifCurtailed: . Such mechanisms used to ensure that some code will have chance to run under any circumstances, regardless of the state of computation. It is interesting, where such code should run? In a process which initiated a terminate request, or in process which needs to be terminated by request. Most valid, of course - to run them in a terminating process. The problem, however, how to achieve that. Someone suggested to throw an exception, like ProcessTerminateException to indicate that the given process is going to be terminated. Such thing is also going into conflict with different points of view: a Process termination is usual functionality, provided for use, so why it should be considered as exceptional? Maybe, to solve the conflicts, and avoid using exceptions in an arguable way, it would be better to add support of process termination notification. So, each time process is going to terminate, it can notify all interesting parties of such event. Then, instead of using #ensure: to free critical system resources, one could use notification. As you can see, there is more questions than answers :) -- Best regards, Igor Stasenko AKA sig.

Sept. 9, 2008

Re: [Pharo-project] SCriptLoader>>InstallingInstaller

by StÃ©phane Ducasse

Ok I see This was fixed in the latest scriptloader. stef On Sep 7, 2008, at 3:54 PM, Luc Fabresse wrote: > I think it should be 'InstallerAll-md.1' (http://www.squeaksource.com/Installer/InstallerAll-md.1.mcz > ) > There is one more '.' in the code. > > #Luc > > > 2008/9/7 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > why? > > stef > > On Sep 7, 2008, at 11:17 AM, Hilaire Fernandes wrote: > > With the lateset update. > > There is something uncorrect in the package name I guess ? > > SCriptLoader>>InstallingInstaller > [...] > fileToLoad := files > detect: [:aFile | aFile beginsWith: > 'InstallerAll.-md.1'] > ifNone: []. > > -- > http://blog.ofset.org/hilaire > > _______________________________________________ > 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

Sept. 7, 2008

Re: [Pharo-project] SCriptLoader>>InstallingInstaller

by Luc Fabresse

I think it should be 'InstallerAll-md.1' ( http://www.squeaksource.com/Installer/InstallerAll-md.1.mcz)There is one more '.' in the code. #Luc 2008/9/7 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > why? > > stef > > On Sep 7, 2008, at 11:17 AM, Hilaire Fernandes wrote: > > With the lateset update. >> >> There is something uncorrect in the package name I guess ? >> >> SCriptLoader>>InstallingInstaller >> [...] >> fileToLoad := files >> detect: [:aFile | aFile beginsWith: >> 'InstallerAll.-md.1'] >> ifNone: []. >> >> -- >> http://blog.ofset.org/hilaire >> >> _______________________________________________ >> 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 >

Sept. 7, 2008

Re: [Pharo-project] SCriptLoader>>InstallingInstaller

by StÃ©phane Ducasse

why? stef On Sep 7, 2008, at 11:17 AM, Hilaire Fernandes wrote: > With the lateset update. > > There is something uncorrect in the package name I guess ? > > SCriptLoader>>InstallingInstaller > [...] > fileToLoad := files > detect: [:aFile | aFile beginsWith: 'InstallerAll.-md.1'] > ifNone: []. > > -- > http://blog.ofset.org/hilaire > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 7, 2008

[Pharo-project] SCriptLoader>>InstallingInstaller

by Hilaire Fernandes

With the lateset update. There is something uncorrect in the package name I guess ? SCriptLoader>>InstallingInstaller [...] fileToLoad := files detect: [:aFile | aFile beginsWith: 'InstallerAll.-md.1'] ifNone: []. -- http://blog.ofset.org/hilaire

Sept. 7, 2008