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

Re: [Pharo-dev] 64-bit Pharo

by Markus Fritsche

On 2015-01-04 18:42, horrido wrote: > I understand that Pharo is currently 32-bit. I was wondering whether > this was > a significant impediment to Smalltalk adoption, esp. in the enterprise. > I'm > always hearing developers wanting 64-bits in their applications. The only place I have found it to be a showstopper is with trying to interface libraries that are closed source and only distributed as a 64bit version. Doesn't happen very often though.

Jan. 8, 2015

Re: [Pharo-dev] [ OT ] Je suis Charlie

by phil＠highoctane.be

Same here. I have been reading these guys since I was a child and they shaped a lot of my thinking. #jesuischarlie indeed! Phil Le 8 janv. 2015 09:46, "Sven Van Caekenberghe" <sven(a)stfx.eu> a Ã©crit : > I am shocked by yesterday's events in Paris. > > http://en.wikipedia.org/wiki/Charlie_Hebdo_shooting > > Freedom of speech, including satire, is a fundamental right. > > > I am sure that LibertÃ©, Ã©galitÃ©, fraternitÃ© will prevail. > > > The way we work together in our little community, building and supporting > free & open source software as a way to contribute to society, with diverse > people from all over the world respecting each other, is one example of > what humans can do. I am proud of that. > > > Sven > >

Jan. 8, 2015

Re: [Pharo-dev] Dark side of variables

by Roberto Minelli

Thanks a lot Marcus! Indeed I used it also like that once. Cheers, Roberto > On 07 Jan 2015, at 18:13, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> 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. 8, 2015

[ OT ] Je suis Charlie

by Sven Van Caekenberghe

I am shocked by yesterday's events in Paris. http://en.wikipedia.org/wiki/Charlie_Hebdo_shooting Freedom of speech, including satire, is a fundamental right. I am sure that LibertÃ©, Ã©galitÃ©, fraternitÃ© will prevail. The way we work together in our little community, building and supporting free & open source software as a way to contribute to society, with diverse people from all over the world respecting each other, is one example of what humans can do. I am proud of that. Sven

Jan. 8, 2015

Re: [Pharo-dev] Dark side of variables

by stepharo

may be you can read pharo by example... Le 7/1/15 17:40, Roberto Minelli a Ã©crit : > 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. 8, 2015

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

by stepharo

superb! Le 6/1/15 22:18, Torsten Bergmann a Ã©crit : >> The idea is that authors, maintainers, supporters or even users create a single poster style A4 page highlighting one >framework or library. Describe what it is, what the main features, advantages and applications are, give some links so where >those interested can find out more, a bit like a datasheet. > You mean something like the attached pages? > > Have fun > Torsten

Jan. 8, 2015

Pharo CI down?

by Max Leske

ci.inria.fr/pharo seems to be down...

Jan. 8, 2015

Are there lazy quantifiers in Pharo's Regex implementation ?

by Paul DeBruicker

I can see and use the "{1,3}" quantifiers but are there lazy quantifiers too? e.g. http://msdn.microsoft.com/en-us/library/3206d374(v=vs.110).aspx It seems like the "?" is parsed as a lookahead or as an optional element. Attempting to use it as a lazy quantifier gives an error.

Jan. 8, 2015

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

by Max Leske

Issue: https://pharo.fogbugz.com/f/cases/14688/Change-CompiledMethod-header-serial… Name: SLICE-Issue-14688-Change-CompiledMethod-header-serialization-to-use-signed-integer-MaxLeske.1 Author: MaxLeske Time: 8 January 2015, 7:22:34.50291 am UUID: a61fa3a2-c7c6-439f-8abf-39806a1411fa Ancestors: Dependencies: Fuel-MaxLeske.799 empty log message > On 08 Jan 2015, at 08:13, Max Leske <maxleske(a)gmail.com> wrote: > > >> On 08 Jan 2015, at 07:02, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >> >> Hi Max, >> >> >> On Jan 7, 2015, at 1:42 PM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@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. > > I see. So Iâll use a 32 bit signed int representation. > > Thanks > >> >>> >>> Cheers, >>> Max >> >> Eliot (phone) >> >>> >>>> On 07 Jan 2015, at 22:27, Max Leske <maxleske(a)gmail.com <mailto:maxleske@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 >>> >> _______________________________________________ >> Pharo-fuel mailing list >> Pharo-fuel(a)lists.gforge.inria.fr <mailto:Pharo-fuel@lists.gforge.inria.fr> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel <http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel>

Jan. 8, 2015

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

by Max Leske

> On 08 Jan 2015, at 07:02, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Max, > > > On Jan 7, 2015, at 1:42 PM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@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. I see. So Iâll use a 32 bit signed int representation. Thanks > >> >> Cheers, >> Max > > Eliot (phone) > >> >>> On 07 Jan 2015, at 22:27, Max Leske <maxleske(a)gmail.com <mailto:maxleske@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 >> > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr <mailto:Pharo-fuel@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel <http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel>

Jan. 8, 2015