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

Re: [Pharo-dev] Fuel and multiple bytecode set support

by Eliot Miranda

Hi Max, On Jan 7, 2015, at 1:42 PM, Max Leske <maxleske(a)gmail.com> wrote: > Just to be sure: is the size of the header stil 32 bits? Or is it now 64 bits? Or is it 32 bits for now and will then become 64 bits? If it will become 64 bits anyway, we might aswell store 64 bits right away. That way we wonât have to make another change later on. The method header is 32-bits;it's a SmallInteger. In the 64-bit VMs (standard and Spur) it is a 64-but integer but only 32-bits are used. If we were to use more bits then it would be very difficult to serialize and deserialize code between 64- & 32-bit images; it would require a recompile. Also the VMs would be a bit different and the image code for the compiler etc. so basically it's not going to happen. It breaks too many things. > > Cheers, > Max Eliot (phone) > >> On 07 Jan 2015, at 22:27, Max Leske <maxleske(a)gmail.com> wrote: >> >> Hi ClÃ©ment >> >>> On 30 Dec 2014, at 12:36, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >>> >>> Hello, >>> >>> As some of you may know, Pharo is being enhanced with support for multiple bytecode sets. This will allow to run at the same time compiled methods with 2 different bytecode sets for experimentation and to add easily the new bytecode set described in this ESUG paper. >>> >>> The virtual machine knows which bytecode set the compiled method uses for its encoding based on the sign of its header. This means that on the contrary to right now, a compiled method *can* have a negative header. >>> >>> The issue is that typically operations such as #bitAnd: or #+ to access bits of the smallinteger does not work the same way on negative integers (2 complement's implementation of integers), resulting in incorrect values. I am fixing the problematic cases in Pharo. >>> >>> One case is in Fuel and I can't fix it myself. It's in: >>> >>> FLCompiledMethodCluster>>#serializeInstance: aCompiledMethodToSerialize with: anEncoder >>> >>> "some code" >>> header := aCompiledMethod header. >>> "some code" >>> anEncoder encodeUint32: header >>> "some code" >>> >>> This looks problematic because now header is not a uint anymore but a sint. >>> In addition, #encodeUint32: uses #bitAnd: which may work differently on negative integers. >>> >>> What do you fuel experts think ? Is there anything to fix there ? >> >> Replacing the header serialization with #encodeInt32: should fix the problem. >> >> Every header will from now on be an sint, is that correct? >> >> Iâll make the change and integrate. >> >> Cheers, >> Max >> >>> >>> Best, >>> >>> Clement >

Jan. 8, 2015

Re: [Pharo-dev] FogBugsz issue assignment

by Marcus Denker

> On 06 Jan 2015, at 15:13, MartinW <wm(a)fastmail.fm> wrote: > > Whenever I reply to an issue or resolve an issue, everybody gets > automatically removed from "assigned to this issue" and I am set as the only > one the issue is assigned to. > > Is this intended? > > I just entered a new bug > (https://pharo.fogbugz.com/f/cases/14679/Fix-layout-glitch-in-FileDialogWind…) > then it is assigned to everybody. > After i resolved it as "fix review needed" it gets automatically only > assigned to me. But exactly now it should be assigned to everybody, so that > someone can review it? Or do i misunderstand the mechanism? > For me the whole âto whom the issue is asking toâ is confusing, too. I think that the issue is always assigned back to the âownerâ after every step. The solution seems to be to manually assign it. Marcus

Jan. 7, 2015

Re: [Pharo-dev] Fuel and multiple bytecode set support

by Max Leske

Just to be sure: is the size of the header stil 32 bits? Or is it now 64 bits? Or is it 32 bits for now and will then become 64 bits? If it will become 64 bits anyway, we might aswell store 64 bits right away. That way we wonât have to make another change later on. Cheers, Max > On 07 Jan 2015, at 22:27, Max Leske <maxleske(a)gmail.com> wrote: > > Hi ClÃ©ment > >> On 30 Dec 2014, at 12:36, ClÃ©ment Bera <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com>> wrote: >> >> Hello, >> >> As some of you may know, Pharo is being enhanced with support for multiple bytecode sets. This will allow to run at the same time compiled methods with 2 different bytecode sets for experimentation and to add easily the new bytecode set described in this ESUG paper <http://esug.org/data/ESUG2014/IWST/Papers/iwst2014_A%20bytecode%20set%20for…>. >> >> The virtual machine knows which bytecode set the compiled method uses for its encoding based on the sign of its header. This means that on the contrary to right now, a compiled method *can* have a negative header. >> >> The issue is that typically operations such as #bitAnd: or #+ to access bits of the smallinteger does not work the same way on negative integers (2 complement's implementation of integers), resulting in incorrect values. I am fixing the problematic cases in Pharo. >> >> One case is in Fuel and I can't fix it myself. It's in: >> >> FLCompiledMethodCluster>>#serializeInstance: aCompiledMethodToSerialize with: anEncoder >> >> "some code" >> header := aCompiledMethod header. >> "some code" >> anEncoder encodeUint32: header >> "some code" >> >> This looks problematic because now header is not a uint anymore but a sint. >> In addition, #encodeUint32: uses #bitAnd: which may work differently on negative integers. >> >> What do you fuel experts think ? Is there anything to fix there ? > > Replacing the header serialization with #encodeInt32: should fix the problem. > > Every header will from now on be an sint, is that correct? > > Iâll make the change and integrate. > > Cheers, > Max > >> >> Best, >> >> Clement

Jan. 7, 2015

Re: [Pharo-dev] Fuel and multiple bytecode set support

by Max Leske

Hi ClÃ©ment > On 30 Dec 2014, at 12:36, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hello, > > As some of you may know, Pharo is being enhanced with support for multiple bytecode sets. This will allow to run at the same time compiled methods with 2 different bytecode sets for experimentation and to add easily the new bytecode set described in this ESUG paper <http://esug.org/data/ESUG2014/IWST/Papers/iwst2014_A%20bytecode%20set%20for…>. > > The virtual machine knows which bytecode set the compiled method uses for its encoding based on the sign of its header. This means that on the contrary to right now, a compiled method *can* have a negative header. > > The issue is that typically operations such as #bitAnd: or #+ to access bits of the smallinteger does not work the same way on negative integers (2 complement's implementation of integers), resulting in incorrect values. I am fixing the problematic cases in Pharo. > > One case is in Fuel and I can't fix it myself. It's in: > > FLCompiledMethodCluster>>#serializeInstance: aCompiledMethodToSerialize with: anEncoder > > "some code" > header := aCompiledMethod header. > "some code" > anEncoder encodeUint32: header > "some code" > > This looks problematic because now header is not a uint anymore but a sint. > In addition, #encodeUint32: uses #bitAnd: which may work differently on negative integers. > > What do you fuel experts think ? Is there anything to fix there ? Replacing the header serialization with #encodeInt32: should fix the problem. Every header will from now on be an sint, is that correct? Iâll make the change and integrate. Cheers, Max > > Best, > > Clement

Jan. 7, 2015

Re: [Pharo-dev] [ Call for participation ] Pharo Days 2015 Project Expo

by horrido

Here is an important "project" to present at Pharo Days. SRP_at_Pharo_Days.pdf <http://forum.world.st/file/n4798256/SRP_at_Pharo_Days.pdf> -- View this message in context: http://forum.world.st/Call-for-participation-Pharo-Days-2015-Project-Expo-t… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 7, 2015

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by Marcus Denker

> On 07 Jan 2015, at 13:15, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > > >> On Dec 1, 2014, at 8:21 AM, Hilaire <hilaire(a)drgeo.eu <mailto:hilaire@drgeo.eu>> wrote: >> >> With git, don't you lost the capability to browse the history of changes >> in your code? >> >> Hilaire The history mechanism needs to be changed to query the git repo. Marcus

Jan. 7, 2015

Re: [Pharo-dev] Dark side of variables

by Marcus Denker

> On 07 Jan 2015, at 14:06, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > > Thank you, ClÃ©ment! > > We use instance var on class side is to implement singleton, for example. > Iâve never used a class var and I am wondering what is a the most common use of such a variable? Singletons where you have a hierarchy of classes and you want to have just one object for the whole hierarchy. e.g. ThemeIcons, there the singleton was until recently a class instance variable, leading to us having multiple instances of the singleton in the image, one per subclass. Marcus

Jan. 7, 2015

Re: [Pharo-dev] Dark side of variables

by Roberto Minelli

Thank you, ClÃ©ment! We use instance var on class side is to implement singleton, for example. Iâve never used a class var and I am wondering what is a the most common use of such a variable? Cheers, R > On 07 Jan 2015, at 17:57, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > A class variable is shared between the class, its subclasses, its instances and its subclasses instances. > > An instance variable of a class is a regular instance variable (can be accessed only by the object holding it, in this case, the class and its subclasses have all an instance variable with potentially different objects in it). > > > > 2015-01-07 17:40 GMT+01:00 Roberto Minelli <roberto.minelli(a)usi.ch>: > Hi guys, > > Can anyone please quickly explain to me the difference between (1) an instance variable defined on the class side and (2) a class variable defined on the instance side? > > Thanks a lot! > > Cheers, > Roberto >

Jan. 7, 2015

Re: [Pharo-dev] Dark side of variables

by ClÃ©ment Bera

A class variable is shared between the class, its subclasses, its instances and its subclasses instances. An instance variable of a class is a regular instance variable (can be accessed only by the object holding it, in this case, the class and its subclasses have all an instance variable with potentially different objects in it). 2015-01-07 17:40 GMT+01:00 Roberto Minelli <roberto.minelli(a)usi.ch>: > Hi guys, > > Can anyone please quickly explain to me the difference between (1) an > instance variable defined on the class side and (2) a class variable > defined on the instance side? > > Thanks a lot! > > Cheers, > Roberto >

Jan. 7, 2015

Dark side of variables

by Roberto Minelli

Hi guys, Can anyone please quickly explain to me the difference between (1) an instance variable defined on the class side and (2) a class variable defined on the instance side? Thanks a lot! Cheers, Roberto

Jan. 7, 2015