January 2014 - Pharo-dev - lists.pharo.org

unload all

by Pavel Krivanek

Hi, I finally successfully created a script that is able to unload everything *by Monticello* except kernel packages, network, Monticello, Gofer and related packages. I will setup a job when Jenkins will be healthy again. It uses several temporary patches that we need to solve properly: - make NativeBoost optional - make UserManager optional - small super-easy issue https://pharo.fogbugz .com/f/cases/12679/change-package-of-ClassTrait-soleInstance The size of resultant image is about 6.6 MB, 4.9 MB without MC data and caches. BTW in the full image Monticello data have about 5MB. The image has no Undeclared nor obsolete classes and is really able to load something using Gofer. With some care we can make it usable base for the next remodularizationeffort. Cheers, -- Pavel

Jan. 18, 2014

Re: [Pharo-dev] Making Platform Installers

by HernÃ¡n Morales Durand

If I understood your question correctly, you can steal my NSIS script at https://code.google.com/p/biosmalltalk/wiki/NSISInstallerScript and execute: makensis.exe myscript.nsi (see http://nsis.sourceforge.net/Docs/Chapter3.html for details) to generate an installer. Cheers, HernÃ¡n 2014/1/18 Sean P. DeNigris <sean(a)clipperadams.com> > Are there up-to-date instructions - or better yet CI scripts - or even > better > Smalltalk CI scripts :) - to make installers for Mac/Windows/Unix? > > How about if one can not install anything? Mac is easy enough, as a bundle > has everything hidden in one, but what about Windows? Can one do better > than > a batch file + Pharo.ini specifying the image? Or an sh file + > folder-with-everything-else for unix? > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Making-Platform-Installers-tp4737775.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Jan. 18, 2014

Re: [Pharo-dev] Making Platform Installers

by Benjamin

You can right a small C program calling the Vm :) Ben On 18 Jan 2014, at 14:47, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Are there up-to-date instructions - or better yet CI scripts - or even better > Smalltalk CI scripts :) - to make installers for Mac/Windows/Unix? > > How about if one can not install anything? Mac is easy enough, as a bundle > has everything hidden in one, but what about Windows? Can one do better than > a batch file + Pharo.ini specifying the image? Or an sh file + > folder-with-everything-else for unix? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Making-Platform-Installers-tp4737775.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Jan. 18, 2014

Making Platform Installers

by Sean P. DeNigris

Are there up-to-date instructions - or better yet CI scripts - or even better Smalltalk CI scripts :) - to make installers for Mac/Windows/Unix? How about if one can not install anything? Mac is easy enough, as a bundle has everything hidden in one, but what about Windows? Can one do better than a batch file + Pharo.ini specifying the image? Or an sh file + folder-with-everything-else for unix? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Making-Platform-Installers-tp4737775.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 18, 2014

Re: [Pharo-dev] Static File Server for Pharo Contribution

by Sean P. DeNigris

Marcus Denker-4 wrote > What do you want to store? An image? Documentation? Well I was recommending Phratch to a non-programmer (teacher) using Scratch. We went to the download page and found Metacello instructions, which baffled them. There is a CI build but IIRC we weren't linking to those artifacts as not to overload the CI server, so I was thinking it would be good to mirror them on a static server like we do with core. Then we could link to them on the project websites... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Static-File-Server-for-Pharo-Contribution-tp4737732p4… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 18, 2014

Re: [Pharo-dev] [Seaside] Re: ConfigurationOfGetText broken?

by Paul DeBruicker

Sounds fine to me. Thanks for sorting it out. Paul Johan Brichau-2 wrote > Fyi I am already adding gettext for seaside to the > ConfigurationOfSeaside3. > > So, it's good to clean ConfigurationOfGettext > > Johan (sent from my mobile) > >> On 18 Jan 2014, at 13:52, Usman Bhatti < > usman.bhatti@ > > wrote: >> >> We've already discussed it and I am in the favor of removing non-gettext >> dependancies from its config. >> http://lists.squeakfoundation.org/pipermail/seaside/2013-October/030221.html >> >> Now, I'll wait for Paul's response to cleanup. Because debugging >> ConfigurationOfGetText or for that matter any configuration with such >> complexities takes a lot of time. So, as an ad-hoc solution I am loading >> the only package in Gettext directly. >> >> >> Usman >> >> >>> On Sat, Jan 18, 2014 at 6:24 AM, Johan Brichau < > johan@ > > wrote: >>> I agree. >>> The Seaside packages should be moved to the Seaside configuration and >>> make that one dependent on ConfigurationOfGettext. >>> Also, the Seaside30Addons repository was moved to smalltalkhub. >>> >>> Johan >>> >>> On 17 Jan 2014, at 17:17, Hilaire Fernandes < > hilaire.fernandes@ > > wrote: >>> >>> > Le 17/01/2014 11:42, Usman Bhatti a Ã©crit : >>> >> >>> >> It seems that some recent changes in the ConfigurationOfText have >>> broken >>> >> the loading in the Pharo 3.0. >>> >> >>> > >>> > >>> > I only know basic of ConfigurationOf..., but it looks odd to me to see >>> > Seaside dependencies in the Gettext configuration. Should it not >>> belong >>> > to this configuration? Imagine if each package depending on Gettext to >>> > add itself in the gettext configuration? >>> > >>> > Hilaire >>> > >>> > -- >>> > Dr. Geo http://drgeo.eu >>> > >>> > >> >> _______________________________________________ >> seaside mailing list >> > seaside@.squeakfoundation >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -- View this message in context: http://forum.world.st/ConfigurationOfGetText-broken-tp4737466p4737765.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 18, 2014

Re: [Pharo-dev] #windowIsClosing not sent to model of WindowModel

by btc＠openinworld.com

Jan. 18, 2014

Re: [Pharo-dev] #windowIsClosing not sent to model of WindowModel

by Benjamin

I think i would be more elegant that the model register to the isClosedHolder changes :) Ben On 18 Jan 2014, at 12:09, btc(a)openinworld.com wrote: > PharoLauncher is currently leaking AnnouncementSubscriptions when its window closes. I'm not sure with Spec how to ensure actions are performed when the window is closed, but I have been able to achieve this with the following modification [1] which is... > ----- > WindowModel>>windowIsClosing > isClosedHolder value: true > self model windowIsClosing "<----proposed modification" > ----- > > I investigated with a halt in SpecWindow>>close to trace through and discover that it calls... > SpecWindow(StandardWindow)>>delete, which in my non-fullscreen-case calls... > SpecWindow(SystemWindow)>>delete, which "model windowIsClosing" calls... > MorphicWindowAdaptor>>windowIsClosing, which "self model windowIsClosing" calls... > WindowModel>>windowIsClosing, which does only "isClosedHolder value: true" > > That last line happens to hold aPharoLauncher in its 'model' instance variable, so with the above proposal I can implement PharoLauncher>>windowIsClosing to unregister the announcer. > Any problem expected with that modification? > > [1] https://pharo.fogbugz.com/f/cases/12677 > > cheers -ben > > >

Jan. 18, 2014

#windowIsClosing not sent to model of WindowModel

by btc＠openinworld.com

PharoLauncher is currently leaking AnnouncementSubscriptions when its window closes. I'm not sure with Spec how to ensure actions are performed when the window is closed, but I have been able to achieve this with the following modification [1] which is... ----- WindowModel>>windowIsClosing isClosedHolder value: true self model windowIsClosing "<----proposed modification" ----- I investigated with a halt in SpecWindow>>close to trace through and discover that it calls... SpecWindow(StandardWindow)>>delete, which in my non-fullscreen-case calls... SpecWindow(SystemWindow)>>delete, which "model windowIsClosing" calls... MorphicWindowAdaptor>>windowIsClosing, which "self model windowIsClosing" calls... WindowModel>>windowIsClosing, which does only "isClosedHolder value: true" That last line happens to hold aPharoLauncher in its 'model' instance variable, so with the above proposal I can implement PharoLauncher>>windowIsClosing to unregister the announcer. Any problem expected with that modification? [1] https://pharo.fogbugz.com/f/cases/12677 cheers -ben

Jan. 18, 2014

Re: [Pharo-dev] Static File Server for Pharo Contribution

by Marcus Denker

On 18 Jan 2014, at 15:32, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Is there one (or a section on the existing server)? Could there be? > > good questionâ¦ this is an interesting idea, it would be a good infrastructure to have. What do you want to store? An image? Documentation? Marcus

Jan. 18, 2014