- Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

On May 19, 2011, at 1:25 PM, Torsten Bergmann wrote: > Stef wrote >> Now my main questions are > > Hey ... dont take me wrong. I did not :) I just took your mail as a pretext to make us all think :) > I want the build server to > build the VMs too, I want a repeatable process and > a reliable VM. I appreciate that we change this!!! > > We all know that if VM development is dependent on a single > maintainer person then nobody would invest into Pharo, Squeak > or Cuis since the truck factor* is one. > > I support all this. Remember: I was the one who wrote the first > ConfigurationOfVMMaker so that it is easy to get all the bits > and pieces. I want to make it easier for people to dive into > VM building. I know :) > The windows build slave is a huge step forward ... we > can not only build the VM and installer ... we can also run > the tests on Windows too to see if there are platform specific > issues. Cool and hardly needed! > > But someone (person or team) has to wear the Win32 VM "hat" > to check contributions or help fixing a bug. So may question is what > is the direction we will take here? I have the impression that igor will have to have a look at it :) We did not tell him yet :) but there is a high chance that igor should do something :) > It looks like the standard SqueakWin32 VM is unmaintained since the > last release is from July 2010. We still have no Alien, we still > have no callbacks. Yes, there is Cog whose code base is newer > but I think Eliots focus is on speed rather than functionality. > > Will we fork from standard VM, will we participate in Eliots > work or will we fork an own using git and maintain it by picking pieces > from the other VMs? this is not the answer that we can give alone :) > Also: what can we do to reach the goal of feature complete VM's > with aligned version numbers. I think this means to participate on > lists like "vm-dev"... stef

May 19, 2011

[Pharo-project] Problem with Pharo 1.3 in Windows

by Torsten Bergmann

Stef wrote >Now my main questions are Hey ... dont take me wrong. I want the build server to build the VMs too, I want a repeatable process and a reliable VM. I appreciate that we change this!!! We all know that if VM development is dependent on a single maintainer person then nobody would invest into Pharo, Squeak or Cuis since the truck factor* is one. I support all this. Remember: I was the one who wrote the first ConfigurationOfVMMaker so that it is easy to get all the bits and pieces. I want to make it easier for people to dive into VM building. The windows build slave is a huge step forward ... we can not only build the VM and installer ... we can also run the tests on Windows too to see if there are platform specific issues. Cool and hardly needed! But someone (person or team) has to wear the Win32 VM "hat" to check contributions or help fixing a bug. So may question is what is the direction we will take here? It looks like the standard SqueakWin32 VM is unmaintained since the last release is from July 2010. We still have no Alien, we still have no callbacks. Yes, there is Cog whose code base is newer but I think Eliots focus is on speed rather than functionality. Will we fork from standard VM, will we participate in Eliots work or will we fork an own using git and maintain it by picking pieces from the other VMs? Also: what can we do to reach the goal of feature complete VM's with aligned version numbers. I think this means to participate on lists like "vm-dev"... But maybe I'm just too impatient... Bye T. *the truck factor = The number of people on your team who have to be hit with a truck before the project is in serious trouble" -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

May 19, 2011

[Pharo-project] My solution to handling errors in system-critical processes

by Igor Stasenko

Hello, if you remember , there was a discussion about how to solve efficiently a following problem: We have a critical processes running in system, which usually running an infinite loop and providing some service(s), which triggered periodically. A most common case is weak finalization. We need to ensure that finalization works, and if finalization of some object causing an error, it should not affect the finalization of the rest of object(s) nor affect the finalization process (like suspending it or terminating it). Also, in another discussion about Announcements, we found that same requirement actually should be fulfilled by Announcement framework: a delivery of a single announcement to some subscriber may fail, however regardless of such failure, other subscribers should be able to receive an announcement no matter what happen. There was a different solutions proposed, like finalizing a single object in separate, forked process, so even if it will fail with error, the rest of finalizers are not affected by this and finalization process continues to run normally. However its not very effective, because you paying the cost of forking process each time you need to finalize new object. There was an optimized solution, but nevertheless it doesn't changing the idea: perform a single item finalization in separate process. Another (a bit lame) approach is to simply swallow any errors, and while it provides guarantee that your critical process won't be terminated due to errors, at the same time, it makes impossible to detect and fix error(s), which of course should be taken care of to prevent them from appearing in future. So, my idea is to fork only if error happens. Add a new protocol to BlockClosure, which could allow us to handle errors in special manner: [ self doSomething ] on: Error fork: [:ex | handle error here ]. it is similar to #on:do: , except that in case of error, and error handler is invoked in separate forked process, while original process simply returns from closure activation with nil return value. But don't think that it is implemented as simple as: on: error fork: handleAction ^ self on: error do: [:ex | [handleAction cull: ex ] fork ]. it would be too easy and therefore useless. :) Because when you do it like that, a debugger window which opens an error, will not show you the stack contents which you wanna see. And then you will have to manually inspect the exception and then inspect an exception context and so on, in order to determine what caused error. What my implementation does, is actually splits the stack of current process and all contexts which are above #on:fork: method is going to forked process, while original process simply returns to sender of #on:fork: with nil return value. So, consider the original stack of a single process: a. <bottom> a. ... a. ... sender of #on:fork: b. <#on:fork:> b. #on:do: b. ... b. ... b. ... b. SomeError signal. b. ... b. ... b. error handler. then in case of exception, all contexts labeled by (a) are left in original process, and original process continues execution from sender of on:fork:, while contexts labeled by (b) is transferred to a newly forked process. In this way, if exception is unhandled (if you put 'ex pass' there), the debugger will show a usual stack trace, as you normally see when error occurs, except that you don't see stack below #on:do: method (which is a context next to #on:fork:), but that's already enough information to determine what causing an error and even fix it and complete the action! So, we can have a cake (a fault-tolerant critical services) and eat it too (conveniently debug errors which could happen there), and without extra overhead. Please review my implementation. I tried it with could different exceptions and it works fine. However there could be some caveats. I tried it on Cog and it works fine. If there everything ok, then we can start using this method in finalization and in announcements, which will improve our systems stability and make it much easier to deal with errors there :) -- Best regards, Igor Stasenko AKA sig.

May 19, 2011

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

by Marcus Denker

On May 19, 2011, at 11:07 AM, Marcus Denker wrote: > > 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 Full: https://gforge.inria.fr/frs/download.php/28554/Pharo-1.2.2-12353.zip Hudson build images are compatible to old vm, too. 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 StÃ©phane Ducasse

Torsten I have some real concerns about the implication behind your remarks :) And I would like to share them with the community. Now my main questions are - can we as a community in 2011 not use a build server and tests for VMs? Should we just look at pypy thinking that they are cool and not do anything? - what is the message that we send to the world? Oh yes this VM will be compiled somehow, sometimes, may be, if you have the right lib patched level 3 It may work. - how can we trace systematically potential problems and regressions at the VM level? - how can we control impact of changes? - how can we make sure that we can be more agile at the VM level? - how can we make sure that changed proposed can be tested by the community without having that somebody have to take care to integrate the changes and make a release. So a lot of these questions can simply be solved by using a nice versioning system and build server. It takes time and energy to build and maintain a compilation and test server. Now if the community does not see an interest in that we cannot do much. Personally I love to see all the tests get run automatically when I do something. I would love to see people proposing enhancements and being able to see tests running and checking their own VMs automatically. It would lower some stress on the VMs maintainers and also let us experiment more. Stef > 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 StÃ©phane Ducasse

>> > 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 who? Are you serious? > 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

[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