- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN 1.2.1Core] pre-build 1.2.1 Core image

by Marcus Denker

On Mar 29, 2011, at 10:14 PM, Lukas Renggli wrote: > Pharo 1.2.1 looks good so far, except for the GLMOrangeUITheme that is > still in a circular dependency. > There was no bug report filed. I nearly asked when you sent the mail if this was meant to be a bug report... but I thought you would do it if you would think that it's a show stopper. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 29, 2011

[Pharo-project] [update 1.3] #13118

by StÃ©phane Ducasse

13118 ----- - Issue 3429: Better Number performance. Thanks Levente and Nicolas Cellier. - Issue 3845: Polymorph extension shortSummary is not programmed the object way. Thanks Nicolas Cellier. - Issue 3902: Text field converter refactoring. Thanks Gary Chambers. - Issue 3713: Additional obsolete methods. Thanks Edmond - Issue 3878: #enableTextChange selector name is misleading, i propose changing the name to #canChangeText. Thanks Fernando Olivero. Thanks guys..... More tomorrow

March 29, 2011

Re: [Pharo-project] Issue 3429 in pharo: Better Number performance

by StÃ©phane Ducasse

Thanks. No stress :). even if the minus can make all the difference :) Stef > Sorry, it seems I let another bug, like -0.01s2 printString loosing its sign. > There might be some tests missing in KernelTests-Numbers > > I will open a new issue and give a new patch from trunk. > > Nicolas > > 2011/3/29 <pharo(a)googlecode.com>: >> >> Comment #4 on issue 3429 by stephane...(a)gmail.com: Better Number performance >> http://code.google.com/p/pharo/issues/detail?id=3429 >> >> in 13118 >> >> >> >

March 29, 2011

Re: [Pharo-project] [squeak-dev] Immutability, read-only objects

by Eliot Miranda

Hi Janko, 2011/3/27 Janko MivÅ¡ek <janko.mivsek(a)eranova.si> > Dear all, > > What is current status of immutable/read-only support in VM? Or more > broader, object instvar change catching support (for which I mostly need > immutability anyway)? > My understanding is that this exists only in the Newspeak VM sources. It is now reasonably easy to port to the standard and Cog VMs and the necessary primitive error code support is in the VMs and the image. I'm currently working in Newspeak at Cadence expect that this summer I will have the opportunity to port the Cog VM under Newspeak. At that point I'll be able to add the support to Cog and the standard VM. There are now mechanisms in the VM which would allow one to include the immutability support conditionally, in which case the source could be included in the base VMs, and not have to live in a fork, which would be my preference. e.g. Interpreter methods for stack bytecodes storeAndPopReceiverVariableBytecode "Note: This code uses storePointerUnchecked:ofObject:withValue: and does the store check explicitly in order to help the translator produce better code." | rcvr top | <expandInCase: 'currentBytecode'> "this bytecode will be expanded so that refs to currentBytecode below will be constant" rcvr := receiver. top := self internalStackTop. self cppIf: Immutability ifTrue: [(self internalIsImmutable: rcvr) ifTrue: [self internalPop: 1. self internalCannotAssign: top to: receiver withIndex: (currentBytecode bitAnd: 7)]. "cannot fetch next bytecode until after immutability check so pc is correct (set to following bytecode, not the bytecode after that) after attemptToAssign:withIndex:"]. self fetchNextBytecode. rcvr < youngStart ifTrue: [self possibleRootStoreInto: rcvr value: top]. self storePointerUnchecked: (currentBytecode bitAnd: 7) ofObject: rcvr withValue: top. self internalPop: 1 best, Eliot > > Best regards > Janko > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si > >

March 29, 2011

Re: [Pharo-project] Issue 3878 in pharo: #enableTextChange selector name is misleading, i propose changing the name to #canChangeText

by pharo＠googlecode.com

Updates: Status: Closed Comment #5 on issue 3878 by stephane...(a)gmail.com: #enableTextChange selector name is misleading, i propose changing the name to #canChangeText http://code.google.com/p/pharo/issues/detail?id=3878 in 13118 :)

March 29, 2011

Re: [Pharo-project] [ANN 1.2.1Core] pre-build 1.2.1 Core image

by Lukas Renggli

Pharo 1.2.1 looks good so far, except for the GLMOrangeUITheme that is still in a circular dependency. Lukas On 29 March 2011 22:07, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Mar 29, 2011, at 9:49 PM, Lukas Renggli wrote: > >> I don't care if we move to 6505, I will just have to update my build >> server to use the new VM as well. So far I built with the old VM to >> make sure that the images also work on older VMs. > > For the moment lukas this is the best solution. Because not all the plugins are not yeat available. > We can do the bleeding edge test with our hudson and this is good to have yours as a backup for olderVMs. > I use the old vm so far also for that (and because I'm slow :)). > >> >> Lukas >> >> On 29 March 2011 21:46, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> On Mar 29, 2011, at 9:38 PM, Lukas Renggli wrote: >>> >>>> Is this intentional that the image was saved with a newer VM than >>>> previous builds? >>>> >>>> Â Â This interpreter (vers. 6502) cannot read image file (vers. 6505). >>>> >>> >>> Oh, yes... I have a new VM on my system (one compiled by our build system). >>> >>> And on the build server use right now Ian's latest unix vm that can read these images, too. >>> >>> This shows that 1.2 should have been released weeks ago. The world is moving on and it >>> gets really difficult to go back to the past just to relase 1.2. >>> >>> So what do we do? The shity gforge means that we would need to generate a new link. >>> >>> Maybe named "1.2.1 this time really final?". >>> >>> I am getting tired of 1.2... >>> >>> Â Â Â Â Marcus >>> >>> >>> >>> -- >>> Marcus Denker Â -- http://www.marcusdenker.de >>> INRIA Lille -- Nord Europe. Team RMoD. >>> >>> >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > -- Lukas Renggli www.lukas-renggli.ch

March 29, 2011

Re: [Pharo-project] Migration morph objects from 1.1 to 1.2

by Denis Kudriashov

Ok, I load my morph. I just implement "TextConstants class>>at: aSymbol" with: "^classPool at: aSymbol". Now all work good. But I want to now what really changed in TextConstants stuff? 2011/3/29 Denis Kudriashov <dionisiydk(a)gmail.com> > Hello > > I have many morphs saved in files by smartReferenceStream. I doing it in > pharo1.1 image. > Now I want to load this objects to pharo1.2. > When I doing this I have exception about absent TextConstants stuff. My > saved Morph containes textMorph. > I know pharo1.2 has textMorph refactored and TextConstants was removed. > > How old object can be migrated to new stuff? Is some rules exists? > For example, when I import morph from file (created in pharo1.1) I see in > debugger "TextConstants class at: index" where "index=#DefaultTabsArray" > > Best regards, > Denis > >

March 29, 2011

Re: [Pharo-project] Migration morph objects from 1.1 to 1.2

by Marcus Denker

On Mar 29, 2011, at 9:58 PM, Denis Kudriashov wrote: > Hello > > I have many morphs saved in files by smartReferenceStream. I doing it in pharo1.1 image. > Now I want to load this objects to pharo1.2. > When I doing this I have exception about absent TextConstants stuff. My saved Morph containes textMorph. > I know pharo1.2 has textMorph refactored and TextConstants was removed. > > How old object can be migrated to new stuff? Is some rules exists? No, I don't think so... keeping the system compatibel at that level is *really* difficult... simple refactoring can be done (e.g. etoys did that for years), but complex changes in the image will be nearly impossible if you require serializability compatibility at that level. (especially when using image segment style low-level serialization). Being compatible on that level was religion for Squeak (and it's even today). I personally don't think that what we have is valuable enough to define compatibility on that level to be more impotant than being able to evolve the system. The system as it is now is just not good enough to have any form of future with it, so trading "improve it" vs. "be backward compatible on a binary level" is selection between having the past and having a future... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 29, 2011

Re: [Pharo-project] Issue 3713 in pharo: Additional obsolete methods in PharoCore-1.2.image (2/15/11 9:08am)

by pharo＠googlecode.com

Updates: Status: Closed Comment #5 on issue 3713 by stephane...(a)gmail.com: Additional obsolete methods in PharoCore-1.2.image (2/15/11 9:08am) http://code.google.com/p/pharo/issues/detail?id=3713 Edmond did you sign the license? If not could you send it to us. We accepted scans. Stef integrated in 13118

March 29, 2011

Re: [Pharo-project] Migration morph objects from 1.1 to 1.2

by StÃ©phane Ducasse

On Mar 29, 2011, at 9:57 PM, Denis Kudriashov wrote: > Hello > > I have many morphs saved in files by smartReferenceStream. I doing it in pharo1.1 image. > Now I want to load this objects to pharo1.2. > When I doing this I have exception about absent TextConstants stuff. My saved Morph containes textMorph. > I know pharo1.2 has textMorph refactored and TextConstants was removed. What you could check is the fix in 1.3 so that TextConstants accept at:. > How old object can be migrated to new stuff? Is some rules exists? > For example, when I import morph from file (created in pharo1.1) I see in debugger "TextConstants class at: index" where "index=#DefaultTabsArray" http://code.google.com/p/pharo/issues/detail?id=3820 Can you try and let us know? I still do not get why the search in the bug entry is so bad for a company that is specialized in search engines :) > > Best regards, > Denis >

March 29, 2011