May 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Problem with Pharo 1.3 in Windows

by Torsten Bergmann

>And for 1.3, we should not release it until Hudson/Jenkinds can build the >complete thing *with version numbers*. +1 Bye T. -- NEU: FreePhone - kostenlos mobil telefonieren! Jetzt informieren: http://www.gmx.net/de/go/freephone

May 19, 2011

Re: [Pharo-project] Problem with Pharo 1.3 in Windows

by Marcus Denker

On May 19, 2011, at 8:05 AM, Marcus Denker wrote: > > On May 18, 2011, at 10:24 PM, StÃ©phane Ducasse wrote: > >> Hi Santiago >> >> which VM are you using. > > I used a new VM to build 1.2.2. I did the same mistake when building 1.2.1 > I made a new one: https://gforge.inria.fr/frs/download.php/28553/PharoCore-1.2.2-12353.zip And for 1.3, we should not release it until Hudson/Jenkinds can build the complete thing *with version numbers*. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 19, 2011

Re: [Pharo-project] Problem with Pharo 1.3 in Windows

by Igor Stasenko

On 19 May 2011 09:39, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 19.05.2011 09:16, Igor Stasenko wrote: >> >> On 19 May 2011 08:43, Torsten Bergmann<astares(a)gmx.de> Â wrote: >>> >>> Marcus wrote >>>> >>>> This situation with the thousands of different VMs is *impossible*. We >>>> need>to fix that. >>> >>> If on Windows you should really use the installer for Pharo 1.2.2. >>> from the download page. This will give you the two VM's: standard and Cog >>> and you can use them to start all images from your HD. >>> >>> Since both have a different icon (also for the Pharo window) >>> you always know which one you start/running on. >>> >>> Just give it a try, its simple. >>> >>> Since the Pharo.exe and PharoCog.exe also have the version number >>> in the resource section you can right click on it in explorer >>> and check which code version/revision they have (see attached >>> screenshot). >>> >> Torsten, can you please document somewhere, how you chaging the version >> info? > > Here's how we do it for our application: > > rc myApp.rc > ResHacker.exe -addoverwrite myApp.exe, Â myApp.exe, Â myApp.res, > versioninfo,1, > > where myApp.rc is the attached, actual values defined in config.h. > So it's not much magic needed :) > even less magic. Because we don't need to hack existing .exe files since we can reliably build them from scratch. > rc can be found as part of Visual Studio, and reshacker is freeware, there's > a beta with 64bit exe support. > > Cheers, > Henry > > -- Best regards, Igor Stasenko AKA sig.

May 19, 2011

Re: [Pharo-project] SIXX problem for ScaledDecimal

by Serge Stinckwich

You need to talk with umezawa-sensei about your problem with SIXX On Thu, May 19, 2011 at 3:42 PM, Dario Trussardi <dario.trussardi(a)tiscali.it> wrote: > Hi, > > Â Â Â Â i found some problem into Gemstone relative to Â SIXX support for manage ScaledDecimal instances. > > > Â Â Â Â I do some test into Pharo and i found error when i read the sixx declaration relative to ScaledDecimal : > > Â Â Â Â Â Â Â Â <sixx.object sixx.id="0" sixx.type="ScaledDecimal" >123.456s3</sixx.object> > > > Â Â Â Â For solve this error i define the ScaledDecimal : > > Â Â Â Â Â Â Â Â readSixxContentStringFrom: aStream > > > Â Â Â Â Â Â Â Â Â Â Â Â | numerator scale | > > Â Â Â Â Â Â Â Â Â Â Â Â numerator := aStream upTo: $s . > > Â Â Â Â Â Â Â Â Â Â Â Â scale := aStream upToEnd. > > > Â Â Â Â Â Â Â Â Â Â Â Â ^ self newFromNumber: Â numerator asNumber scale: scale asNumber > > > Now my doubt is relative to string size and performance. > > A) Â Â Â If i write > > Â Â Â Â Â Â Â Â <sixx.object sixx.id="0" sixx.type="ScaledDecimal" >123.456s3</sixx.object> > > > Â Â Â Â i have small string in sixx declartion but when create a ScaledDecimal from sixx the system execute the: > > Â Â Â Â Â Â Â Â newFromNumber: aNumber scale: anInteger > Â Â Â Â Â Â Â Â Â Â Â Â | aFraction | > Â Â Â Â Â Â Â Â Â Â Â Â aFraction := aNumber asFraction. > Â Â Â Â Â Â Â Â Â Â Â Â ^aFraction isFraction > Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [self new setNumerator: aFraction numerator denominator: aFraction denominator scale: anInteger] > Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [self new setNumerator: aFraction denominator: 1 scale: anInteger] > > > Â Â Â Â What is the performance relative to : Â Â Â Â Â Â Â Â Â aFraction := aFloat asFraction. Â Â ???? > > > > > B) Â Â Â The alternative is to write a sixx declaration with: > > Â Â Â Â Â Â Â Â <sixx.object sixx.id="0" sixx.type="ScaledDecimal" >(8687443681197687/70368744177664s3)</sixx.object> > > > Â Â Â Â in this case the sixx string is big but the ScaledDecimal instance creation is direct: > > > Â Â Â Â Â Â Â Â readSixxContentStringFromA: aStream > > Â Â Â Â Â Â Â Â Â Â Â Â " with numerator and denominator " > Â Â Â Â Â Â Â Â | numerator denominator scale | > Â Â Â Â Â Â Â Â aStream next. "skip $(" > Â Â Â Â Â Â Â Â numerator := aStream upTo: $/ . > Â Â Â Â Â Â Â Â denominator := aStream upTo: $s. > Â Â Â Â Â Â Â Â scale := aStream upTo: $). > > Â Â Â Â Â Â Â Â ^ self new setNumerator: Â numerator asNumber denominator: denominator asNumber scale: Â scale asNumber > > > > Any pointers would be greatly appreciated ! > > Â Â Â Â Thanks, > > Â Â Â Â Â Â Â Â Dario > > > > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

May 19, 2011

[Pharo-project] SIXX problem for ScaledDecimal

by Dario Trussardi

Hi, i found some problem into Gemstone relative to SIXX support for manage ScaledDecimal instances. I do some test into Pharo and i found error when i read the sixx declaration relative to ScaledDecimal : <sixx.object sixx.id="0" sixx.type="ScaledDecimal" >123.456s3</sixx.object> For solve this error i define the ScaledDecimal : readSixxContentStringFrom: aStream | numerator scale | numerator := aStream upTo: $s . scale := aStream upToEnd. ^ self newFromNumber: numerator asNumber scale: scale asNumber Now my doubt is relative to string size and performance. A) If i write <sixx.object sixx.id="0" sixx.type="ScaledDecimal" >123.456s3</sixx.object> i have small string in sixx declartion but when create a ScaledDecimal from sixx the system execute the: newFromNumber: aNumber scale: anInteger | aFraction | aFraction := aNumber asFraction. ^aFraction isFraction ifTrue: [self new setNumerator: aFraction numerator denominator: aFraction denominator scale: anInteger] ifFalse: [self new setNumerator: aFraction denominator: 1 scale: anInteger] What is the performance relative to : aFraction := aFloat asFraction. ???? B) The alternative is to write a sixx declaration with: <sixx.object sixx.id="0" sixx.type="ScaledDecimal" >(8687443681197687/70368744177664s3)</sixx.object> in this case the sixx string is big but the ScaledDecimal instance creation is direct: readSixxContentStringFromA: aStream " with numerator and denominator " | numerator denominator scale | aStream next. "skip $(" numerator := aStream upTo: $/ . denominator := aStream upTo: $s. scale := aStream upTo: $). ^ self new setNumerator: numerator asNumber denominator: denominator asNumber scale: scale asNumber Any pointers would be greatly appreciated ! Thanks, Dario

May 19, 2011

[Pharo-project] Problem with Pharo 1.3 in Windows

by Torsten Bergmann

Marcus >We have system that builds VMs from the latest soures automatically. >No need to wait for anyone. Does this "build system" magically write new code for the platform, fix bugs or implement the platform specific code for new plugins? There has to be at least one maintainer of the (win32)VM otherwise "latest soures" always points to the same version and no build system is required at all !!! The platform specific VM code needs maintenance ... either we continue to use the code base/versions from Andreas for regular VM and the code base/version from Eliot for the Cog VM or we fork ... Dont know if we have the resources to fork and maintain own VM's. On the other side Squeak Win32 VM is outdated anyway (SqueakVM-Win32-4.1.1-src.zip if from July 2010). I know many of you dont care about/hate Windows but if Pharo wants to be accepted in the larger commercial market then there is no way around a well maintained Win32 port. >I unsubscribed from all Squeak lists after 3.9. And that was final. "vm-dev" is for the VM which is currently for Squeak, Cuis, Pharo, ... You dont have to subscribe again, just check the archive: http://lists.squeakfoundation.org/pipermail/vm-dev/ Bye T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

May 19, 2011

Re: [Pharo-project] Problem with Pharo 1.3 in Windows

by Henrik Sperre Johansen

On 19.05.2011 10:26, Torsten Bergmann wrote: > Henrik Sperre Johansen >> Here's how we do it for our application: > PLEASE NO. Why use Reshacker? Its just a hacker tool > to manipulate the resource section in an EXISTING EXE file. Yes, my mind slipped and forgot we are actually able to build the VM from scratch :) Nevermind what I said about reshacker, include it directly in the build process like Torsten described. Cheers, Henry

May 19, 2011

[Pharo-project] Problem with Pharo 1.3 in Windows

by Torsten Bergmann

Henrik Sperre Johansen >Here's how we do it for our application: PLEASE NO. Why use Reshacker? Its just a hacker tool to manipulate the resource section in an EXISTING EXE file. I remember that this was the recommended way of a well known commercial smalltalk vendor to customize the VM icon. But this is just a workaround since the VM source code was not available there. Maybe it is OK for Henrik too since he dont want to look into VM building. But for Pharo WE HAVE the VM sources and now also a win build slave for hudson therefore should just use a custom *.rc for the build. I once suggested this to Andreas, he integrated it and his standard Win32 VM includes a versioninfo in the Squeak.rc file. I also suggested it to Eliot but he didnt included it (yet). I dont really care if he integrates into Cog since for a customized Pharo VM we use a custom "PharoCog.rc" file anyway (instead of Squeak.rc) during the build step. Read my post here, including the correct files for Cog: http://lists.gforge.inria.fr/pipermail/pharo-project/2011-May/049093.html If you copy them into the dir where Makefile lives you just have to change the name of the VM to build in the Makefile See also "Customization" at http://squeakvm.org/win32/compiling.html So if you switch to VM = MyKillerApp in the Makefile the build includes MyKillerApp.def.in MyKillerApp.rc instead of Squeak.def.in/Squeak.rc And in MyKillerApp.rc you can set the version info and point to a custom MyKillerApp.ico. And in the end you get a branded MyKillerApp.exe Simple! Bye T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

May 19, 2011

Re: [Pharo-project] Problem with Pharo 1.3 in Windows

by Marcus Denker

On May 19, 2011, at 10:08 AM, Torsten Bergmann wrote: > > Marcus wrote: >> We *neeeeeeed* for every version of Pharo a VM that has *just* the same >version number. > > I think the problem was and (maybe still is) that there > were no aligned VM releases. It's dependent on the VM maintainer > time and what he included (fixes, new plugins). > > So on each platform there was an own custom versioning scheme > (one for mac, one for windows, ...). > > On windows: for standard vm Andreas aligned with Squeak releases: > http://squeakvm.org/win32/release/?C=M;O=D > and Eliot is oriented towards his SVN revision number > http://www.mirandabanda.org/files/Cog/VM/ > We have system that builds VMs from the latest soures automatically. No need to wait for anyone. > But there was a discussion on VM versioning on vm-dev list. > Maybe you should discuss it there. > I unsubscribed from all Squeak lists after 3.9. And that was final. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 19, 2011

Re: [Pharo-project] Wishes for new ClassBuilder (toon?)

by StÃ©phane Ducasse

excellent! Stef On May 19, 2011, at 9:51 AM, Toon Verwaest wrote: > I'll be at tools as well, so if we have time we can already do some stuff there. > > On 05/18/2011 11:01 PM, StÃ©phane Ducasse wrote: >> I'm planning to be at bern the friday 30 of june after tools so I would be happy to do that. >> >> Stef >> >> On May 18, 2011, at 10:31 PM, Toon Verwaest wrote: >> >>> Nope. That needs to be added. Sorry. If you have tests for the old classbuilder we can port them. Otherwise I can take the time at the next print I attend to do it; maybe together with somebody else. >>> >>> Toon >>> >>> On 05/18/2011 09:38 PM, StÃ©phane Ducasse wrote: >>>> toon I looked at the code but do you have tests for the new class builder? >>>> I could not find them. >>>> >>>> Stef >>>> On May 18, 2011, at 6:17 PM, Toon Verwaest wrote: >>>> >>>>> The PlayOut classbuilder indeed separates this nicely. We have the distinction between the "installer" and the "builder". The builder uses an "installer" as a client and notifies it about stuff that happens. >>>>> >>>>> For example we have an "anonymous subclass builder" that's implemented like that. It basically just ignores most of the notifications of the builder since it doesn't really do anything. >>>>> >>>>> ... but of course this means that you need PlayOut ;) You can get an image at http://pinocchio.unibe.ch/~tverwaes/PlayOut.tar.gz >>>>> >>>>> caveats: >>>>> - At the moment that system doesn't validate everything yet like the old classbuilder (since I wanted to freely change classes with any name) >>>>> - it doesn't handle obsolete subclasses yet. Oh well ;) >>>>> - it's still intertwined with our slots implementation, so it relies on Helvetia. But that can/should/will be fixed without changing the API. >>>>> >>>>> cheers, >>>>> Toon >>>>> >>>>> On 05/18/2011 03:18 PM, Mariano Martinez Peck wrote: >>>>>> Hi guys. As part of the Fuel project, one of the things we want to do (in fact, it is done) is to serialize classes. There want to have 3 possibilities: >>>>>> 1) Do something like DiskProxy where you only save its global name and some selector to run when deserialing it >>>>>> 2) Really searialize the whole class (following method dictionary, compiled methods, class pools and friend, etc) so that you can deserialize it in another image where such class is not present. >>>>>> 3) Do the same as 2 but validating and installing the class in the system. >>>>>> >>>>>> For 2) what we want to do is just to serialize the class as any other object. As a result, we get a Class instance. Nothing is validated, nothing is added in Smalltalk globals, nothing is compiled. We do not use ClassBuilder at all. >>>>>> >>>>>> For 3) we want to do 2) plus validating and installing the class in the system. For validating I mean ALL the validations that the class builder does when creating or modifying a class. And for "installing in the system" I mean notify, put in Smalltalk globals, re compile what is needed, etc... >>>>>> >>>>>> ClassBuilder seems to do 2) and 3) together. So, what I would love to have in a new class builder is to have those two things separated. So that I can say to an object ClassManager validate: aClass or ClassManager installClassOnSystem: aClass. >>>>>> >>>>>> Do you think such thing is possible? Right now going through ClassBuilder and understand all the validations it does is really complicated :( >>>>>> >>>>>> Thanks in advance, >>>>>> >>>>>> -- >>>>>> Mariano >>>>>> http://marianopeck.wordpress.com >>>>>> >>> >> > >

May 19, 2011