June 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 2.0] #20109

by StÃ©phane Ducasse

20109 ----- Issue 6021: less hardcoded RPackage and RPackageOrganizer http://code.google.com/p/pharo/issues/detail?id=6021 Normally does not change broken tests.

June 3, 2012

[Pharo-project] Apparently composed trait methods loses their categories...

by StÃ©phane Ducasse

Hi guys In 20, which T1>>m1 is defined under cat1 when we do T3 uses: T1 T3>>m1 is 'as yet unclassified' and this breaks several tests. Any idea of a change that could have modified the system? Stef

June 3, 2012

[Pharo-project] [PharoCasts] Athens + NativeBoost how to

by laurent laffont

Hi, I've published Igor's screencast of Athens and added instructions to make it work on Linux, OSX and Windows. http://www.pharocasts.com/2012/06/athens-and-native-boost-at-work.html Cheers, Laurent

June 3, 2012

Re: [Pharo-project] [update 2.0] #20108

by Pavel Krivanek

Tests Guard page updated: http://code.google.com/p/pharo/wiki/TestsGuard The new failures are green again. -- Pavel On Sun, Jun 3, 2012 at 10:32 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > 20108 > ----- > > Â Issue 6015: Â Â ClassBuilderFormatTests raises duplicated announcements. Thanks Guillermo Polito > Â Â Â Â Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=6015 > > > ***THANKS*** !!!!! > > Stef

June 3, 2012

[Pharo-project] [update 2.0] #20108

by StÃ©phane Ducasse

20108 ----- Issue 6015: ClassBuilderFormatTests raises duplicated announcements. Thanks Guillermo Polito http://code.google.com/p/pharo/issues/detail?id=6015 ***THANKS*** !!!!! Stef

June 3, 2012

Re: [Pharo-project] Tests Guard report 20111

by StÃ©phane Ducasse

yes probably because this tests have side effect on the events. Stef On Jun 3, 2012, at 7:58 PM, Pavel Krivanek wrote: > Tests Guard report for update 20111: > http://code.google.com/p/pharo/wiki/TestsGuard > > We have got 6 new tests failures: > KernelTests?.Classes.ClassBuilderFormatTests?.testByteVariableSubclass > KernelTests?.Classes.ClassBuilderFormatTests?.testSubclass > KernelTests?.Classes.ClassBuilderFormatTests?.testSubclassWithInstanceVariables > KernelTests?.Classes.ClassBuilderFormatTests?.testVariableSubclass > KernelTests?.Classes.ClassBuilderFormatTests?.testWeakSubclass > KernelTests?.Classes.ClassBuilderFormatTests?.testWordVariableSubclass > > Cheers, > -- Pavel >

June 3, 2012

Re: [Pharo-project] [Vm-dev] Re: Plan/discussion/communication around new object format

by Levente Uzonyi

On Wed, 30 May 2012, Igor Stasenko wrote: > > Here are couple (2) of mine, highly valuable cents :) > > 2^20 for classes? > might be fine (or even overkill) for smalltalk systems, but could be > quite limiting for one who would like experiment and implementing a > prototype-based frameworks, > where every object is a "class" by itself. I think it's more important to have a fast Smalltalk VM, than one that is slower, but might fit for a concrete experiment which might happen sometime and would get some performance boost from the implementation. > > --- > 8: slot size (255 => extra header word with large size) > 3: odd bytes/fixed fields (odd bytes for non-pointer, fixed fields for > pointer, 7 => # fixed fields is in the class) > 4 bits: format (pointers, indexable, bytes/shorts/longs/doubles > indexable, compiled method, ephemerons, weak, etc) > 1: immutability > 3: GC 2 mark bits. 1 forwarded bit > 20: identity hash > 20: class index > --- > what takes most of the space in object header? right - hash! > Now, since we will have lazy become i am back to my idea of having > extra & arbitrary properties > per object. > > In a nutshell, the idea is to not store hash in an object header, but > instead use just a single bit 'hash present'. > > When identity hash of object is requested (via corresponding primitive) > the implementation could check if 'hash present' is set, > then if it's not there , we do a 'lazy become' of existing object to same object > copied into another place, but with hash bit set, and with extra 64-bit field, > where hash value can be stored. > > So, when you requesting an identity hash for object which don't have it, > the object of from: > [header][...data.. ] > copied to new memory region with new layout: > [header][hash bits][...data..] > > and old object, is of course 'corpsed' to forwarding pointer to new location. The weak point of this idea is that you might run of out memory during the allocation of the new object if you ask the identity hash of a larger object or many smaller objects at once. > > Next step is going from holding just hash to having an arbitrary & > dynamic number of extra fields per object. > In same way, we use 1 extra bit, indicating that object having extra properties. > And when object don't have it, we lazy-become it from being > [header][...data.. ] > or > [header][hash bits][...data..] > to: > [header][hash bits][oop][...data..] > > where 'oop' can be anything - instance of Array/Dictionary (depends > how language-side will decide to store extra properties of object) > > This , for instance , would allow us to store extra properties for > special object formats like variable bytes or compiled methods, which > don't have the instance variables. > > Not need to mention, how useful being able to attach extra properties > per object, without changing the object's class. > And , of course the freed 18 bits (20 - 2) in header can be allocated > for other purposes. > (Stef, how many bits you need for experiments? ;) > > ------------ > > About immediates zoo. > > Keep in mind, that the more immediates we have, the more complex implementation > tends to be. > > I would just keep 2 data types: > - integers > - floats > > and third, special 'arbitrary' immediate , which seen by VM as a 60-bit value. > The interpretation of this value depends on lookup in range-table, > where developer specifying the correspondence between the value > interval and class: > [min .. max] -> class > > intervals, of course, cannot overlap. > Determining a class of such immediate might be slower - O(log2(n)) at > best (where n is size of range table), but from other side, > how many different kinds of immediates you can fit into 60-bit value? > Right, it is 2^60. Much more than proposed 8 isn't? :) > > And this extra cost can be mitigated completely by inline cache. > - in case of regular reference, you must fetch the object's class and > then compare it with one, stored in cache. > - in case of immediate reference, you compare immediate value with min > and max stored in cache fields. > And if value is in range, you got a cache hit, and free to proceed. > So, its just 1 extra comparison comparing to 'classic' inline cache. > > And, after thinking how inline cache is organized, now you can scratch > the first my paragraph related to immediates! > We really don't need to discriminate between small integers/floats/rest!! > They could also be nothing more than just one of a range(s) defined in > our zoo of 'special' immediates! > > So, at the end we will have just two kinds of references: > - zero bit == 0 -- an object pointer > - zero bit == 1 -- an immediate > > Voila!. > > We can have real zoo of immediates, and simple implementation to support them. > And not saying that range-table is provided by language-side, so we're > free to rearrange them at any moment. > > And of course, it doesn't means that VM could not reserve some of the > ranges for own 'contracted' > immediates, like Characters, and even class reference for example. > Think about it :) > I like the idea, but I'm not sure how useful it will be in practice. I'd also add characters as third data type. String/Character operations should be as fast as possible. Levente

June 3, 2012

Re: [Pharo-project] Some steps towards headless on OS X

by Mark Smith

On 3 Jun 2012, at 18:27, Sean P. DeNigris wrote: > > Mark Smith wrote >> >> Marking the process as background only will remove the icon, menu etc. but >> it will not stop us from creating that window. >> ... >> Anyway I'd like to keep working on this but I've hit a wall > Are your changes publicly available anywhere? I didn't make many changes yet. The machinery is already there but isn't functional. If you set the LSBackgroundOnly key in Info.plist to YES and run headless you will see that the icon and menu bar are goneâ¦ only the window remains :). With this change in place â When the VM is not run in headless mode it it brings itself into the foreground. Unfortunately this cannot work the other way around because foreground processes cannot become background processes (we'll have to ask Apple why that is exactly :). When the VM is run in headless mode it stays in the background, but our window will be visible. If we can change the VM such that no window is created in headless mode then everything should function as we expect. That's where I get lost. The obvious thing to try (which I tried ;) is to not create a window, but then the VM doesn't start and the application just exits [normally]. I have no idea why starting the VM would have anything to do with the creation of a window but this seem to be the case. That said Mac applications aren't exactly friendly to headless operation. That is that they're sort-of-intended to be graphical. The other solution would be to make a headless VM, similar in operation to perl/python/ruby... which is really what we want. I think ;). > -- > View this message in context: http://forum.world.st/Some-steps-towards-headless-on-OS-X-tp4633047p4633048… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

June 3, 2012

[Pharo-project] Tests Guard report 20111

by Pavel Krivanek

Tests Guard report for update 20111: http://code.google.com/p/pharo/wiki/TestsGuard We have got 6 new tests failures: KernelTests?.Classes.ClassBuilderFormatTests?.testByteVariableSubclass KernelTests?.Classes.ClassBuilderFormatTests?.testSubclass KernelTests?.Classes.ClassBuilderFormatTests?.testSubclassWithInstanceVariables KernelTests?.Classes.ClassBuilderFormatTests?.testVariableSubclass KernelTests?.Classes.ClassBuilderFormatTests?.testWeakSubclass KernelTests?.Classes.ClassBuilderFormatTests?.testWordVariableSubclass Cheers, -- Pavel

June 3, 2012

Re: [Pharo-project] Some steps towards headless on OS X

by Sean P. DeNigris

Mark Smith wrote > > Marking the process as background only will remove the icon, menu etc. but > it will not stop us from creating that window. > ... > Anyway I'd like to keep working on this but I've hit a wall Are your changes publicly available anywhere? -- View this message in context: http://forum.world.st/Some-steps-towards-headless-on-OS-X-tp4633047p4633048… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 3, 2012