- Pharo-dev - lists.pharo.org

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

by Andreas Wacknitz

> Am 04.12.2014 um 23:59 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: > > Hi Thierry, > > On Tue, Dec 2, 2014 at 10:25 PM, Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > > 2014-12-03 4:16 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>>: > > Yes, but *I* care about the Monticello metadata. IMO its *better* than the git metadata. > > Eliot, you'll have to do better than just IMO on that one. > > Quite right. One benefit is that Monticello metadata, at least per-method time stamps, are available for introspection inside the image. Just today I was alerted of some bad code by a particular author and it was very convenient to read all the methods by that particular author, which helped me find another problem. I also like the free frorm of the middle of method timestamps; I can and do annotate with labels for specific refactorings. > > Another benefit is that Monticello is amenable for scripting much more easily than git. I've been working on the SPur bootstrap fro a while now. It is essentially complete. What the bootstrap does in Monticello is construct patched versions of four packages, substituting specific methods with replacements. Each patched package inherits both from its patched ancestor and the package that was patched (a ladder like structure). This allows Spur to keep up-to-date automatically w.r.t. Squeak trunk. > > 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. > > > Some of us work with *both*, and have code for going back and forth, so the *better*; bah. > > I also happens to know how long it takes to parse hundreds of monticello metadata files... and I wasn't impressed with the result. > > Yes, but this can be reengineered. Most things can be optimized. This could be with a little effort. What's needed is to generate and maintain momentum. That's what worries me about git integration. It's a slippery slope towards giving up Monticello and just using git. And git itself will one day be viewed as old-hat. Monticello should be easy to keep evolving. It's in Smalltalk few chrissake. > +1 Plus: Introducing libgit2 will put additional burden for VM ports. Also there is a constant trial to get functionality out of the VM and into the image. This would be the opposite: new responsibility for the VM. Regards Andreas

Dec. 5, 2014

Re: [Pharo-dev] [squeak-dev] Re: [Vm-dev] [ANN] ARM Stack VMs available

by J. Vuletich (mail lists)

(inline) Quoting Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Juan, > > > On Dec 5, 2014, at 4:56 AM, "J. Vuletich (mail lists)" > <juanlists(a)jvuletich.org> wrote: > >> Hi Folks, >> >> The Squeak process scheduler usually preempts a process only by >> another one of higher priority. And when the scheduler is ready to >> go back at the lower priority, it will always resume the same >> process that was last suspended. The only way for two or more >> processes of the same priority to share the processor is when the >> running process calls #wait or #yield. > > No. According to the blue book preempting sends the preempted process > to the back if its run queue so preempting forces a yield. Obviously > this is wrong, but that's the way it was defined. The ObjectWorks & > VisualWorks VMs changed this to work as you describe. Oh, apologies. Thanks for correcting me. But this means that understanding the problems Ken and Tim found on the PI is not that easy, because in other platforms the problem don't occur, even with olders VMs and (I guess) on slower machines. I don't have a PI myself, so I can't do much testing. Maybe something in the VM timer(s), event fetching, or semaphore signaling is different in the PI from others VMs? Or maybe the possible interrupt points are different? Maybe something like this could make a higher priority process wake up at usual times, or under less restricted conditions? > When I implemented Cog I wanted to fix this but not break old code so > I made it optional. The behavior is controlled by a flag in the > image. You can see the flags via Smalltalk vmParameterAt: 48. Bit 2 > (value 4) is set if preempting puts the preempted process at the head > of its list, and hence does not yield. > > Here's the part of the comment from vmParameterAt: > > 48 various properties of the Cog VM as an integer encoding an > array of bit flags. > Bit 0: implies the image's Process class has threadId as its > 3rd inst var (zero relative) > Bit 1: on Cog VMs asks the VM to set the flag bit in > interpreted methods > Bit 2: if set, preempting a process puts it to the head of its > run queue, not the back, > i.e. preempting a process by a higher one will not > cause the process to yield > to others at the same priority. > > >> This means that using shared state from several processes at the >> same priority (without using any locking mechanism, such as >> Semaphores, Monitors or critical sections) is safe, as long as the >> processes do #wait or #yield only when that shared state is in a >> consistent state. > > Right. > >> >> It looks like this ARM VM is somehow not following this convention. >> If this was the case, the problems Ken sees are to be expected. > > Can you check the bit is set in the image? > > > Thanks for raising this. It looks like the Spur images have the bit > cleared. Ouch. Ah, it's not a problem of the bootstrap, its at least > a problem in trunk. The bit is not set in trunk. I need to a) write > some tests to test the bit and b) make sure its set in the relevant > places. Glad to be of help! Cheers, Juan Vuletich >> >> HTH, >> Juan Vuletich > > Eliot (phone) > >> Quoting Douglas McPherson <djm1329(a)san.rr.com>: >> >>> Hi Ken, >>> >>>> On Nov 11, 2014, at 16:28, Ken Dickey <Ken.Dickey(a)whidbey.com> wrote: >>>> >>>> >>>> On Sun, 9 Nov 2014 20:56:47 -0800 >>>> Douglas McPherson <djm1329(a)san.rr.com> wrote: >>>> >>>> KenD>> >>>>>> The stkspurlinuxhtARM VM, however, complains: >>>>>> This interpreter (vers. 6521) cannot read image file (vers. 6505). >>>>>> >>>>>> I presume some conversion is required to get the image into SPUR format? >>>>> Yes, the Spur VMs require a new image format. There are recent >>>>> Squeak trunk images in the spur format on Eliotâs site. Iâll let >>>>> Eliot and others comment about how a Cuis image might be >>>>> converted. >>>> >>>> I tried out the Squeak SPUR image from the Cog site and >>>> everything Squeak seems fine. >>>> >>>> >>>> There is a timing bug with Cuis redraw that shows up on both the >>>> stklinuxhtARM vm and the one you sent me earlier. >>>> >>>> Basically, I am using DisplayObject>>slideFrom:to:nSteps:delay: >>>> to do some animation. When multiple timer events fire during an >>>> animation it sometimes appears that the x,y redraw origin is used >>>> from the currently drawing morph's position, not 0,0. I.e. part >>>> of the redisplay is offset. [Display redraw via menu corrects >>>> the display]. >>>> >>>> This _only_ happens on the Samsung ARM Chromebook, never on Intel CPUs. >>> >>> Thanks for reporting this. Iâll try to look into it. There are >>> definitely ARM-specific changes to support certain atomic >>> operations, so there may be something not quite right with these. >>> >>> Can you suggest a method for reproducing this in Squeak? I >>> repeatedly sent morphs to the trash (with appropriate preference >>> set to enable the animation) but didnât see an issue. I suspect >>> Iâm not driving it hard enough. >>> >>>> My life is really, really busy right now, so I have never had >>>> time to dig into this. I can redraw the display, so a workaround >>>> exists. >>>> >>>> [One possible resource. The Apache Portable Runtime, >>>> http://apr.apache.org/ , implements compareAndSwap and various >>>> other atomic operations across various OSs.] >>> >>> Thanks for the reference. It may be useful. I also found a library >>> called Mintomic >>> (http://preshing.com/20130505/introducing-mintomic-a-small-portable-lock-fre…) which may >>> help. >>> >>>> I am happy to do quick tests, but must apologize for lack of time >>>> to dig into this. >>> >>> No problems, and thanks again for reporting it. >>> >>> >>>> FYI, >>>> -KenD

Dec. 5, 2014

Re: [Pharo-dev] RBSmalllintContext>>primitiveComputerLiterals

by Yuriy Tymchuk

Hi, maybe it is wrong, but the long term goal is to remove contexts completely, as it introduces one more custom environment implementation. Uko > On 05 Dec 2014, at 17:40, Ben Coman <btc(a)openinworld.com> wrote: > > > I just noticed RBSmalllintContext>>primitiveComputerLiterals > doesn't seem to follow the typical pattern for that naming convention. > > Without digging to really understand it, I just wondered if it maybe should be called #computeLiteralsForPrimitive, > or #basicComputerLiterals, or something else... > > cheers -ben >

Dec. 5, 2014

Re: [Pharo-dev] [Vm-dev] [ANN] ARM Stack VMs available

by Eliot Miranda

Hi Juan, On Dec 5, 2014, at 4:56 AM, "J. Vuletich (mail lists)" <juanlists(a)jvuletich.org> wrote: > Hi Folks, > > The Squeak process scheduler usually preempts a process only by another one of higher priority. And when the scheduler is ready to go back at the lower priority, it will always resume the same process that was last suspended. The only way for two or more processes of the same priority to share the processor is when the running process calls #wait or #yield. No. According to the blue book preempting sends the preempted process to the back if its run queue so preempting forces a yield. Obviously this is wrong, but that's the way it was defined. The ObjectWorks & VisualWorks VMs changed this to work as you describe. When I implemented Cog I wanted to fix this but not break old code so I made it optional. The behavior is controlled by a flag in the image. You can see the flags via Smalltalk vmParameterAt: 48. Bit 2 (value 4) is set if preempting puts the preempted process at the head of its list, and hence does not yield. Here's the part of the comment from vmParameterAt: 48 various properties of the Cog VM as an integer encoding an array of bit flags. Bit 0: implies the image's Process class has threadId as its 3rd inst var (zero relative) Bit 1: on Cog VMs asks the VM to set the flag bit in interpreted methods Bit 2: if set, preempting a process puts it to the head of its run queue, not the back, i.e. preempting a process by a higher one will not cause the process to yield to others at the same priority. > This means that using shared state from several processes at the same priority (without using any locking mechanism, such as Semaphores, Monitors or critical sections) is safe, as long as the processes do #wait or #yield only when that shared state is in a consistent state. Right. > > It looks like this ARM VM is somehow not following this convention. If this was the case, the problems Ken sees are to be expected. Can you check the bit is set in the image? Thanks for raising this. It looks like the Spur images have the bit cleared. Ouch. Ah, it's not a problem of the bootstrap, its at least a problem in trunk. The bit is not set in trunk. I need to a) write some tests to test the bit and b) make sure its set in the relevant places. > > HTH, > Juan Vuletich Eliot (phone) > Quoting Douglas McPherson <djm1329(a)san.rr.com>: > >> Hi Ken, >> >>> On Nov 11, 2014, at 16:28, Ken Dickey <Ken.Dickey(a)whidbey.com> wrote: >>> >>> >>> On Sun, 9 Nov 2014 20:56:47 -0800 >>> Douglas McPherson <djm1329(a)san.rr.com> wrote: >>> >>> KenD>> >>>>> The stkspurlinuxhtARM VM, however, complains: >>>>> This interpreter (vers. 6521) cannot read image file (vers. 6505). >>>>> >>>>> I presume some conversion is required to get the image into SPUR format? >>>> Yes, the Spur VMs require a new image format. There are recent Squeak trunk images in the spur format on Eliotâs site. Iâll let Eliot and others comment about how a Cuis image might be converted. >>> >>> I tried out the Squeak SPUR image from the Cog site and everything Squeak seems fine. >>> >>> >>> There is a timing bug with Cuis redraw that shows up on both the stklinuxhtARM vm and the one you sent me earlier. >>> >>> Basically, I am using DisplayObject>>slideFrom:to:nSteps:delay: to do some animation. When multiple timer events fire during an animation it sometimes appears that the x,y redraw origin is used from the currently drawing morph's position, not 0,0. I.e. part of the redisplay is offset. [Display redraw via menu corrects the display]. >>> >>> This _only_ happens on the Samsung ARM Chromebook, never on Intel CPUs. >> >> Thanks for reporting this. Iâll try to look into it. There are definitely ARM-specific changes to support certain atomic operations, so there may be something not quite right with these. >> >> Can you suggest a method for reproducing this in Squeak? I repeatedly sent morphs to the trash (with appropriate preference set to enable the animation) but didnât see an issue. I suspect Iâm not driving it hard enough. >> >>> My life is really, really busy right now, so I have never had time to dig into this. I can redraw the display, so a workaround exists. >>> >>> [One possible resource. The Apache Portable Runtime, http://apr.apache.org/ , implements compareAndSwap and various other atomic operations across various OSs.] >> >> Thanks for the reference. It may be useful. I also found a library called Mintomic (http://preshing.com/20130505/introducing-mintomic-a-small-portable-lock-fre…) which may help. >> >>> I am happy to do quick tests, but must apologize for lack of time to dig into this. >> >> No problems, and thanks again for reporting it. >> >> >>> FYI, >>> -KenD

Dec. 5, 2014

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

by Jan Vrany

On Fri, 2014-12-05 at 20:52 +0800, Ben Coman wrote: > 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 > Yeah, likely. I don't have enough knowledge of Pharo internal workings to tell for sure, but like the Delay, it does work fine on Windows. Best, Jan > 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] GetOpt

by stepharo

I liked that you propose yourself also to edit the zeroConf chapter. Thanks. I must admit that I'M FED UP to feel the only one with Sven that seems to be able to write a documentation in our wonderful community. So at least changes should be retrofitted in the available doc. Do not worry LaTex is easy and we will probably convert Deep into Pharo into Pillar. Stef Le 2/12/14 09:37, Esteban Lorenzano a Ã©crit : > is cool. > I would like to explore the possibility to replace our command line > parser with getopt. You knowâ¦ is more compatible at the end :) > > thanks phil. > > Esteban > >> On 02 Dec 2014, at 08:45, phil(a)highoctane.be >> <mailto:phil@highoctane.be> wrote: >> >> I have made Ian Piumarta's GST GetOpt work in Pharo 3.0 >> >> See: >> >> http://www.smalltalkhub.com/#!/~philippeback/GetOpt >> <http://www.smalltalkhub.com/#%21/%7Ephilippeback/GetOpt> >> >> Nice tool even if we have some other support in CommandLineHandlers. >> But for a quick parameters setting in your own CommandLineHandler, it >> is fast to use and easy to debug. >> >> Phil >> >> >> >

Dec. 5, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40400 Home: https://github.com/pharo-project/pharo-core

Dec. 5, 2014

[pharo-project/pharo-core] d5c6eb: 40400

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: d5c6eb2010fdff8d389e4a67eaa9cd586142c93c https://github.com/pharo-project/pharo-core/commit/d5c6eb2010fdff8d389e4a67… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-12-05 (Fri, 05 Dec 2014) Changed paths: A Collections-Strings.package/String.class/class/instance creation/loremIpsum.st A Collections-Strings.package/String.class/class/instance creation/loremIpsum_.st A CollectionsTests.package/StringTest.class/instance/testing - instance creation/testLoremIpsum.st A CollectionsTests.package/StringTest.class/instance/testing - instance creation/testLoremIpsum2048.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script400.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40400.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Examples.package/ScrollSyncExample.class/instance/private/loremIpsum.st Log Message: ----------- 40400 14571 Add String class>>#loremIpsum constant and dynamically sized filler text feature https://pharo.fogbugz.com/f/cases/14571 http://files.pharo.org/image/40/40400.zip

Dec. 5, 2014

RBSmalllintContext>>primitiveComputerLiterals

by Ben Coman

I just noticed RBSmalllintContext>>primitiveComputerLiterals doesn't seem to follow the typical pattern for that naming convention. Without digging to really understand it, I just wondered if it maybe should be called #computeLiteralsForPrimitive, or #basicComputerLiterals, or something else... cheers -ben

Dec. 5, 2014

Re: [Pharo-dev] Monticello and Fuel

by Thierry Goubier

2014-12-05 14:07 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Fri, Dec 5, 2014 at 6:55 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> 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 >> > > This one is the one I explain below. > > >> - mixing tanker/fuel with monticello. >> >> > I think here you mean an experiment where we serialized the little thing > MC serializes currently in the data file... > We found that that serialization/materialization is INSIGNIFICANT in the > export/import process. > Ok. > > > Ok... so.. > > Indeed: Tanker. > Fuel is able to serialize methods, classes etc... (but not by default). So > what Tanker does it kind of serialize a whole package (with internal > classes, extension methods, etc) as a fuel file. And then, at the import, > it materializes and then runs a lot of stuff besides the materialization > itself. The idea was NOT to use the Compiler at all at import time, because > that is/was one of the bottleneck when importing packages with Metacello. > The compiler was not needed most of the times, so performance was much > better. However, there were cases (like instVars changed in superclasses > where we are importing) etc.. that causes that we needed to RE-Compile or > stored methods because otherwise the instVar offsets were wrong. This, > COULD be solved this the intermediate representation of Opal and to avoid a > normal compilation. However, I don't remember us doing that. I think we > ended up using the compiler for that scenario. But I am not sure. > What is the state of that for, say, Pharo 4? > > >> 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). >> > > Exactly. The ones we found that took most of the time was: > > 1) Compiling (could be solved with Fuel and even more if we can fix some > scenarios with Opal) > 2) Notification of created methods/classes. One way to solve this is by > having bulk notifications where we notify a list rather than a single > object. But we should also adapt the observers. > They can be adapted. You can also pile up notifications (well, you can't at the moment, but it would be nice) and have a way to merge them. Such optimisations are also usefull for heavy code generators such as SmaCC. > > 3) #become: when updating/migrating existing instances. > > But...just to see that there is a light in the tunnel, I showed at... mmm > ESUG or PharoConf or.. how to load WHOLE seaside in 10 seconds...which in > my machine takes like 20 minutes. > Which is what I wanted to know :) > > Tanker was originally called "FuelPackageLoader" and was then renamed. > Some useful links with details: > > > http://marianopeck.wordpress.com/2012/08/11/tanker-transporting-packages-wi… > http://marianopeck.wordpress.com/2012/09/28/new-tanker-current-status/ > > http://marianopeck.wordpress.com/2012/04/28/building-pharo-from-pharokernel… > http://marianopeck.wordpress.com/tag/tanker/ > Thanks for the links! > > http://vimeo.com/63122424 > > > >> >> Just try the following: load a monticello package with (a) no Nautilus >> opened, and with (a) 10 Nautilus opened. >> >> > Exactly!!! Sometimes the slowdown of the notifications is not in the > observable but on the observers ;) > When, in the profile, the observers appear and you can optimize that. One of the way is to have a single central point (i.e. whatever the number of Nautilus instances opened, you send to a singleton), then memoize all queries you do on RPackage and friends before firing again notifications for the views (relevant package, class, etc..). In short, you have the thing. Thierry

Dec. 5, 2014