- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo+Git cons?

by Ben Coman

Thierry Goubier wrote: > > 2014-12-04 23:59 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com > <mailto:eliot.miranda@gmail.com>>: > > I'm also delighted that work like Chris Muller's version server is > out there. This is very nicely integrated to allow me to find out > which package versions contain versions of a particular method or > class definition. > > > I know that this version server exists, and I hoped that you would point > it out, because I believe it is significant. Even if it is not usable in > many professional settings, such as mine. My google fu didn't turn up anything on this in the first few pages. Could you provide a pointer? cheers -ben

Dec. 5, 2014

Re: [Pharo-dev] Semaphore seems to timeout prematurely

by Ben Coman

Jan Vrany wrote: > Hi there, > > I have encountered a situation where semaphore timeouts > prematurely when run in "non-interactive" mode (eval cmdline handler). > > Setup (script prepare.sh) > > 1) Fresh Pharo image (3.0 / 4.0, both exhibits the same behaviour) > 2) Evaluate: > == > Smalltalk at: #WaitBlock put: [:sema :tout | (sema waitTimeoutSeconds: > tout) ifTrue:[ Halt now ] ]. > == > 3. Save image > > Run 1: > 1) Run the image, open workspace > 2) Evaluate: > == > | sema | > sema := Semaphore new. > [ 100 factorial. sema signal ] fork. > (Smalltalk at: #WaitBlock) value: sema value: 60*60. > 'OK' > == > Returns 'OK' as expected (100 factorial should not take more than > hour :-) > > > Run 2 (script test.sh) > 1) The same, but evaluate using command line handler: > ./pharo Test.image eval "\ > | sema |\ > \ > sema := Semaphore new.\ > [ 100 factorial. sema signal ] fork.\ > (Smalltalk at: #WaitBlock) value: sema value: 60*60.\ > 'OK'\ > " > Halt triggers, which is what I would not expect. > > Why is that? Bug? Or Am I missing something obvious? > > Best, Jan Is it like the thread on "Super fast delay" ? http://forum.world.st/Super-fast-delay-td4787257.html I have a fix for Pharo 4 ready to be reviewed... https://pharo.fogbugz.com/default.asp?14353 cheers -ben

Dec. 5, 2014

Re: [Pharo-dev] Monticello and Fuel

by Thierry Goubier

2014-12-05 10:55 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: > I will summon Martin and Mariano here :). > > Introducing fuel in the loading infrastructure had so far AFAIK two > different experimental setups: > - tanker: a package completely written in fuel > Oh, I missed that one, yes. I remember the name. > - mixing tanker/fuel with monticello. > > Sort of what I'm thinking about. > However, the results were not so promising I remember. Apparently when > loading a package, most of the time is spent not in the > deserialization/recompilation but in the update of the system (system > dictionary, categories, rpackages, update the corresponding subclass > relationships). > > Just try the following: load a monticello package with (a) no Nautilus > opened, and with (a) 10 Nautilus opened. > I profiled AltBrowser for that use case... It's a bit more vulnerable to that than Nautilus because you may see more of the structure at a given time than Nautilus (such as having a single browser watching the methods of two classes). Still, once a bit optimised, MC loading time dominates. But I haven't looked too closely on exactly what; I was focused on getting the browser bit as small as possible. If anybody has things about the various costs, I'd be interested. Thierry

Dec. 5, 2014

Re: [Pharo-dev] Monticello and Fuel

by Guillermo Polito

I will summon Martin and Mariano here :). Introducing fuel in the loading infrastructure had so far AFAIK two different experimental setups: - tanker: a package completely written in fuel - mixing tanker/fuel with monticello. However, the results were not so promising I remember. Apparently when loading a package, most of the time is spent not in the deserialization/recompilation but in the update of the system (system dictionary, categories, rpackages, update the corresponding subclass relationships). Just try the following: load a monticello package with (a) no Nautilus opened, and with (a) 10 Nautilus opened. I let Martin and Mariano give the details :). On Fri, Dec 5, 2014 at 9:28 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2014-12-05 8:35 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > >> >> > On 05 Dec 2014, at 08:02, Norbert Hartl <norbert(a)hartl.name> wrote: >> > >> > >> > >> > >> >> Am 04.12.2014 um 23:31 schrieb Thierry Goubier < >> thierry.goubier(a)gmail.com>: >> >> >> >> Hi all, >> >> >> >> I'm just wondering. >> >> >> >> Would it work to have a package format based on Fuel? >> >> >> > I doubt it would work cross platform. I don't know how fuel serializes >> WideString, LargePositiveInteger, BoxedFloat64. These differ between >> smalltalk platforms. The source as string solves that. Strings are written >> as unicode string and numbers as certain number format etc. >> >> True. Cross dialect loading isnât something we encourage to do with Fuel. >> >> @Thierry >> You said something about partial loading: that will never be possible >> with Fuel because of its pickle format. To select any partial graph you >> have to first read the entire file and rebuild the graph first (ok, you >> donât strictly have to build the graph but you still need to read the >> entire file). >> > > Hum. I was thinking of partial loading at the application level, not at > the marshalling level. > > The process of cutting out Monticello packages versions ancestry in Pharo > releases come to mind as a ... how should I say that ... We can/should do > better (additionally, because if the mcz isn't available somewhere, having > its ref its useless). > > Thierry > > >> >> > >> > Norbert >> > >> >> Would that make loading faster? >> >> >> >> Does it already exist? >> >> >> >> Thanks, >> >> >> >> Thierry >> > >> >> >> >

Dec. 5, 2014

Re: [Pharo-dev] Monticello and Fuel

by Thierry Goubier

2014-12-05 8:35 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > > > On 05 Dec 2014, at 08:02, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > > > > > > >> Am 04.12.2014 um 23:31 schrieb Thierry Goubier < > thierry.goubier(a)gmail.com>: > >> > >> Hi all, > >> > >> I'm just wondering. > >> > >> Would it work to have a package format based on Fuel? > >> > > I doubt it would work cross platform. I don't know how fuel serializes > WideString, LargePositiveInteger, BoxedFloat64. These differ between > smalltalk platforms. The source as string solves that. Strings are written > as unicode string and numbers as certain number format etc. > > True. Cross dialect loading isn't something we encourage to do with Fuel. > > @Thierry > You said something about partial loading: that will never be possible with > Fuel because of its pickle format. To select any partial graph you have to > first read the entire file and rebuild the graph first (ok, you don't > strictly have to build the graph but you still need to read the entire > file). > Hum. I was thinking of partial loading at the application level, not at the marshalling level. The process of cutting out Monticello packages versions ancestry in Pharo releases come to mind as a ... how should I say that ... We can/should do better (additionally, because if the mcz isn't available somewhere, having its ref its useless). Thierry > > > > > Norbert > > > >> Would that make loading faster? > >> > >> Does it already exist? > >> > >> Thanks, > >> > >> Thierry > > > > >

Dec. 5, 2014

Re: [Pharo-dev] [ANN] Transition of Ubuntu PPA maintenance

by Luc Fabresse

yes Thank you very much! #Luc 2014-12-04 23:40 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > Markus Fritsche wrote: > >> Hello, >> >> The maintenance of the Ubuntu Pharo VM and .source Packages is being >> transferred from Damien Cassou to myself, Markus Fritsche. By trade, I >> am a Business Intelligence consultant, but always following what's going >> on with smalltalk/ pharo. >> >> If you experience any problems with the ubuntu packages, please feel >> free to contact me. I might not be able to help right away, but I'll try >> my best! >> >> Best regards, >> Markus >> >> >> > Thanks for this Markus. > cheers -ben > >

Dec. 5, 2014

Re: [Pharo-dev] Twittering Smalltalk

by phil＠highoctane.be

And a #pharo hastag. Le 5 dÃ©c. 2014 08:35, "Marcus Denker" <marcus.denker(a)inria.fr> a Ã©crit : > > > On Thu, Dec 4, 2014 at 10:32 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> >Do you have the links of all those tweets? I'd like to Storify some of >> them. >> >> All of them were from the ESUG twitter account. >> >> > The account is @esugsmalltalk: > https://twitter.com/esugsmalltalk > (603 followers) > > There is a pharo twitter account, too: > https://twitter.com/pharoproject > (1063 followers) > > Marcus > >

Dec. 5, 2014

Re: [Pharo-dev] Monticello and Fuel

by Max Leske

> On 05 Dec 2014, at 08:02, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > >> Am 04.12.2014 um 23:31 schrieb Thierry Goubier <thierry.goubier(a)gmail.com>: >> >> Hi all, >> >> I'm just wondering. >> >> Would it work to have a package format based on Fuel? >> > I doubt it would work cross platform. I don't know how fuel serializes WideString, LargePositiveInteger, BoxedFloat64. These differ between smalltalk platforms. The source as string solves that. Strings are written as unicode string and numbers as certain number format etc. True. Cross dialect loading isnât something we encourage to do with Fuel. @Thierry You said something about partial loading: that will never be possible with Fuel because of its pickle format. To select any partial graph you have to first read the entire file and rebuild the graph first (ok, you donât strictly have to build the graph but you still need to read the entire file). > > Norbert > >> Would that make loading faster? >> >> Does it already exist? >> >> Thanks, >> >> Thierry >

Dec. 5, 2014

Re: [Pharo-dev] Twittering Smalltalk

by Marcus Denker

On Thu, Dec 4, 2014 at 10:32 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > >Do you have the links of all those tweets? I'd like to Storify some of > them. > > All of them were from the ESUG twitter account. > > The account is @esugsmalltalk: https://twitter.com/esugsmalltalk (603 followers) There is a pharo twitter account, too: https://twitter.com/pharoproject (1063 followers) Marcus

Dec. 5, 2014

Re: [Pharo-dev] Monticello and Fuel

by Norbert Hartl

> Am 04.12.2014 um 23:31 schrieb Thierry Goubier <thierry.goubier(a)gmail.com>: > > Hi all, > > I'm just wondering. > > Would it work to have a package format based on Fuel? > I doubt it would work cross platform. I don't know how fuel serializes WideString, LargePositiveInteger, BoxedFloat64. These differ between smalltalk platforms. The source as string solves that. Strings are written as unicode string and numbers as certain number format etc. Norbert > Would that make loading faster? > > Does it already exist? > > Thanks, > > Thierry

Dec. 5, 2014