- Pharo-dev - lists.pharo.org

[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

Re: [Pharo-project] The Cult of Done Manifesto

by Noury Bouraqadi

Thanks marcus for pointing this. Noury On 18 mai 2011, at 13:17, Marcus Denker wrote: > The Cult of Done Manifesto > > - There are three states of being. Not knowing, action and completion. > > - Accept that everything is a draft. It helps to get it done. > > - There is no editing stage. > > - Pretending you know what you're doing is almost the same as knowing what you are doing, > so just accept that you know what you're doing even if you don't and do it. > > - Banish procrastination. If you wait more than a week to get an idea done, abandon it. > > - The point of being done is not to finish but to get other things done. > > - Once you're done you can throw it away. > > - Laugh at perfection. It's boring and keeps you from being done. > > - People without dirty hands are wrong. Doing something makes you right. > > - Failure counts as done. So do mistakes. > > - Destruction is a variant of done. > > - If you have an idea and publish it on the internet, that counts as a ghost of done. > > - Done is the engine of more. > > http://www.brepettis.com/blog/2009/3/3/the-cult-of-done-manifesto.html?v=1 > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > Noury Bouraqadi http://car.mines-douai.fr/noury -- -6th National Conference on âControl Architecture of Robotsâ 24-25 may 2011, Grenoble area, France http://car2011.inrialpes.fr/ -19th ESUG International Smalltalk Conference 22-26 August 2011, Edinburgh, UK http://www.esug.org/Conferences/2011 -19Ã¨mes JournÃ©es Francophones sur les SystÃ¨mes Multi-Agents (JFSMAâ11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France

May 19, 2011

[Pharo-project] Problem with Pharo 1.3 in Windows

by Torsten Bergmann

Igor wrote: > Torsten, can you please document somewhere, how you chaging the version info? > I really can't understand how today's VMs are versioned, and what > version we could use for Pharo-branded VMs. You change the version info in the *.rc file. This file is used during the build process, creates the ressource section in the windows portable executable (PE) file. This info is used by explorer to display the version info. This info is also used by setups to see if an installed component is newer and should not be overwritten. (see my post in "Branded Cog for Win32" from yesterday. Currently I use the versions that the Win32 maintainers "officially" released. Latest standard Squeak VM for Windows from Andreas is 4.1.1 (see http://squeakvm.org/win32/) - but very old. And latest tagged SVN revision from Eliot was VM.r2378/ (see http://www.mirandabanda.org/files/Cog/VM/) Cog now moved on and is as of today at VM.r2382 In general the standard Win32 VM doesnt look very well maintained (Andreas stepped back or has no time) and Eliots focus is on performance/bug fixing. Dont know if you are already maintain an offical Pharo VM fork for Win32... 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/ But there was a discussion on VM versioning on vm-dev list. Maybe you should discuss it there. Bye T. -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone

May 19, 2011

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

by Toon Verwaest

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

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

by Henrik Sperre Johansen

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 :) rc can be found as part of Visual Studio, and reshacker is freeware, there's a beta with 64bit exe support. Cheers, Henry

May 19, 2011