- Pharo-dev - lists.pharo.org

[Pharo-project] Squeaksource is...

by Bernat Romagosa

...down :) Can someone take a look, please? -- Bernat Romagosa.

June 11, 2012

Re: [Pharo-project] recompiling class

by Igor Stasenko

On 11 June 2012 09:26, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > The whole point about improving the system is to then use the improvements. > Else what's the point in improving anything? > Hi, from Capt. Obvious :) > Â Â Â Â Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > -- Best regards, Igor Stasenko.

June 11, 2012

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

by Igor Stasenko

Some extra ideas. 1. Avoiding extra header for big sized objects. I not sure about this, but still .. according to Eliot's design: 8: slot size (255 => extra header word with large size) What if we extend size to 16 bits (so in total it will be 65536 slots) and we have a single flag, pointing how to calculate object size: flag(0) object size = (size field) * 8 flag(1) object size = 2^ (slot field) which means that past 2^16 (or how many bits we dedicate to size field in header) all object sizes will be power of two. Since most of the objects will fit under 2^16, we don't lose much. For big arrays, we could have a special collection/array, which will store exact size in it's inst var (and we even don't need to care in cases of Sets/Dicts/OrderedCollections). Also we can actually make it transparent: Array class>>new: size size > (max exact size ) ifTrue: [ ^ ArrayWithBigSizeWhatever new: size ] of course, care must be taken for those variable classes which potentially can hold large amounts of bytes (like Bitmap). But i think code can be quickly adopted to this feature of VM, which will simply fail a #new: primitive if size is not power of two for sizes greater than max "exact size" which can fit into size field of header. ---- 2. Slot for arbitrary properties. If you read carefully, Eliot said that for making lazy become it is necessary to always have some extra space per object, even if object don't have any fields: <<We shall probably keep the minimum object size at 16 bytes so that there is always room for a forwarding pointer. >> So, this fits quite well with idea of having slot for dynamic properties per object. What if instead of "extending object" when it requires extra properties slot, we just reserve the slot for properties at the very beginning: [ header ] [ properties slot] ... rest of data .. so, any object will have that slot. And in case of lazy-become. we can use that slot for holding forwarding pointer. Voila. 3. From 2. we going straight back to hash.. VM don't needs to know such a thing as object's hash, it has no semantic load inside VM, it just answers those bits by a single primitive. So, why it is kind of enforced inherent property of all objects in system? And why nobody asks, if we have that one, why we could not have more than one or as many as we want? This is my central question around idea of having per-object properties. Once VM will guarantee that any object can have at least one slot for storing object reference (property slot), then it is no longer needed for VM to care about identity hash. Because it can be implemented completely at language size. But most of all, we are NO longer limited how big/small hash values , which directly converts into bonuses: less hash collisions > more performance. Want 64-bit hash? 128-bit? Whatever you desire: Object>>identityHash ^ self propertiesAt: #hash ifAbsentPut: [ HashGenerator newHashValue ] and once we could have per-object properties.. and lazy become, things like Magma will get a HUGE benefits straightly out of the box. Because look, lazy become, immutability - those two addressing many problems related to OODB implementation (i barely see other use cases, where immutability would be as useful as in cases of OODB).. so for me it is logical to have this last step: by adding arbitrary properties, OODB now can store the ID there. -- Best regards, Igor Stasenko.

June 11, 2012

Re: [Pharo-project] Look and font competition

by Olivier Auverlot

Anonymous Pro is a cool font for editing code (http://www.ms-studio.com/FontSales/anonymouspro.html) Olivier ;-) > > On Sun, Jun 10, 2012 at 10:27 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Hi guys >> >> this morning Igor shows me all his work around dynlib loading of third party plugins. >> And yes now we get all the third party plugins downloaded and compiled (yes with only one copy of FT2)â¦.Great stuff! >> >> Now we would like to organize a little competition for the official look of Pharo 2.0. So if you feel that you are a little >> bit designer inside, please send us proposals. >> We propose this one :) based on Curlz MT (welcome to the world of the pink little ponies) :) >> >> > <PharoScreenshot.3.png>

June 11, 2012

Re: [Pharo-project] recompiling class

by Tudor Girba

+1. It is in your interest to get us to move to the latest version, and the best way to do it is to keep offering irresistible reasons :) Cheers, Doru On Mon, Jun 11, 2012 at 9:31 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Jun 11, 2012, at 7:17 AM, S Krish wrote: > >> "decompile to an Intermediate Representation" >> >> This will be nice to have backported if possible to 1.4. >> > IR: you can do it. Whole compiler: no way, as it changes APIs > and honestly, life is too short. > > Â Â Â Â Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > -- www.tudorgirba.com "Every thing has its own flow"

June 11, 2012

Re: [Pharo-project] recompiling class

by Marcus Denker

On Jun 11, 2012, at 7:17 AM, S Krish wrote: > "decompile to an Intermediate Representation" > > This will be nice to have backported if possible to 1.4. > IR: you can do it. Whole compiler: no way, as it changes APIs and honestly, life is too short. Marcus -- Marcus Denker -- http://marcusdenker.de

June 11, 2012

Re: [Pharo-project] recompiling class

by Marcus Denker

On Jun 9, 2012, at 8:16 PM, Eliot Miranda wrote: > > For the backend of Opal, I did some crude benchmark for Martin this week: > Decompiling to IR and re-generating of all methods in Morph that access iVars takes 0.8 seconds... > > and how long does recompiling all Morph methods take? > on the same machine: 6.5 seconds. But of course that can be cut down by selecting for ivar access (to around half). More statistics: Bytecode to IR for the whole image: 4.5 seconds. BC->IR-BC: 12.7 seconds. (no install) Opal image (~57000 CompiledMethods) Not installing the methods yet... and of course nothing is profiled and optimized yet. > Marcus, I'm eager to port your code to Squeak. Would that be OK? > Yes! The first version will be (I think) portable. But future versions might use Pharo features. Compatibility is not the main goal. The whole point about improving the system is to then use the improvements. Else what's the point in improving anything? Marcus -- Marcus Denker -- http://marcusdenker.de

June 11, 2012

Re: [Pharo-project] zip bug [IMPORTANT] probably related to the recent Zip changes

by Ben Coman

Sean P. DeNigris wrote: > Sean P. DeNigris wrote > >> Where did you click on it? I need steps to reproduce... >> >> > > Okay, I tried to merge it and got the error when the package was being > read... > > I did some experiments... > * create a zip at Mac command line -> new Pharo code correctly parses > date/times > * unzip Balloon-CamilloBruni.85.mcz at Mac command line -> Mac reports > date/time as 1/23/2010... I'm assuming this is wrong because pre-fix, Pharo > reported 29 September 2011 > > So, I think the code is correct, but transitioning is a problem... let me > see write up a fallback defaulting to the old date format for invalid > dates... > > -- > View this message in context: http://forum.world.st/zip-bug-IMPORTANT-probably-related-to-the-recent-Zip-… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > What do you get if you unzip it outside Pharo? from the operating system?

June 11, 2012

Re: [Pharo-project] recompiling class

by S Krish

"decompile to an Intermediate Representation" This will be nice to have backported if possible to 1.4. On Sat, Jun 9, 2012 at 5:40 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Jun 9, 2012, at 8:26 AM, S Krish wrote: > > > > > > > Can we do this in Pharo: > > > > "in Java, the computation of numeric o ffsets for instance elds in > memory is done by > > the run-time system. This permits updating a class with new instance > elds or methods without > > aff ecting existing code. In other words, it is possible to run an > existing bytecode fi le for a subclass > > after updating and recompiling the class, but without recompiling the > subclass." > > Hello, > > In Smalltalk, not only *new* instances get the changed > class layout, but *all* existing ones are migrated. > > There is always just one version of a class in the system, all instances > are of that version. > > Thus, if you add a instvar in a superclass, the iVar offsets of the > subclasses have to be > fixed. Right now this is done by recompiling the all subclasses, but you > could be much > more intelligent: filter for those methods that actually reference ivars > and then don't recompile > but just change the offset. > > This "just" is more difficult than it seems: changing an offset can mean > that the bytecode > needed is larger (2 instead of 1), and that then means jump offsets need > to be changed. > Which in turn can mean that the larger jump needs more bytecode, too.. > > So in practice, the best is to decompile to an Intermediate Representation > that is at the > level of bytecode, yet abtracts away jumps and the decision of which > bytecode exactly it used. > > For the backend of Opal, I did some crude benchmark for Martin this week: > Decompiling to IR and re-generating of all methods in Morph that access > iVars takes 0.8 seconds... > > We will add the IR backend to 2.0 soon and the new ClassBuilder will use > it. > > But in general, it would be nice to late-bind the offsets and just use > names in the representation > that a method is saved in. > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > >

June 11, 2012

[Pharo-project] [CTI-KH] News

by Santiago Bragagnolo

Hi all! Here are the week news from TypeInference project :) Enjoy the week! . http://concretetypeinference.blogspot.com.ar/2012/06/news-cti.html Whats new in ConcreteTypeInference http://concretetypeinference.blogspot.com.ar/2012/06/news-kh.html Whats new in KwisatzHaderach http://concretetypeinference.blogspot.com.ar/2012/06/about-mechanisms-part-… Little explanation of type in our context. http://concretetypeinference.blogspot.com.ar/2012/06/kwisatz-haderach-about… Graph building 'concepts exposition

June 11, 2012