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

[Pharo-project] Mouse wheel

by Alexandre Bergel

Hi! -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 19, 2011

[Pharo-project] bug in Nautilus/RPackage?

by Alexandre Bergel

Hi ! I think I bumped into a bug when using Nautilus. I am not sure whether this is due to RPackage or not. I loaded Spy, and apparently there is no class in the package within Nautilus. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 19, 2011

[Pharo-project] Strange SmalltalkImage>>startUp

by Igor Stasenko

Can someone explain me, why it does: startUp SystemChangeNotifier uniqueInstance notify: Smalltalk ofAllSystemChangesUsing: #event: why not doing it once in #initialize (on instance side, since Smalltalk is instance of SmalltalkImage)? -- Best regards, Igor Stasenko AKA sig.

May 19, 2011

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

by Igor Stasenko

On 19 May 2011 13:25, Torsten Bergmann <astares(a)gmx.de> wrote: > 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? > I could help a lot with Win32, because i know it well. And i want to help. The only problem is time. Because if you have too many hats, it is hard to decide how long you should wear one, before switching to another, and hard to decide which one should be worn next. :) > 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? > Branding VM is not a fork. It just putting a label on already manufactured product. And i think the right answer is to do it together. Eliot cannot do everything, neither do i, or anyone else. But if we merge our efforts, then we can do everything. > 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"... > yes. > But maybe I'm just too impatient... > For the impatient: register on gitorious and clone blessed repository and then put your modifications, which you described in another thread into your clone. A little, simple step. But then i will not be forced to search mailing list in order to harvest these bits. > 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 > -- Best regards, Igor Stasenko AKA sig.

May 19, 2011

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