- Pharo-dev - lists.pharo.org

[Pharo-project] The Cult of Done Manifesto
by Marcus Denker May 21, 2011

May 21, 2011

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.

8 8

[Pharo-project] SerialPort Plugin Patches.
by Friedrich Dominicus May 21, 2011

May 21, 2011

I've downloaded the Cog sources and checked the SerialPlugin stuff. I'd like to use it with the patches that will make it work on Linux also but for that there should be a primite with printPortByName or the like, but it's not in the actual sources. So can anyone tell me where an actualiced SerialPlugin is, with which I then can use strings for accessing the serial lines? Thanks Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

1 0

[Pharo-project] Can't load OSProcess in last Pharo Core 1.3
by Adrien BARREAU May 20, 2011

May 20, 2011

Hi all, I just tried to load OSProcess in the last PharoCore 1.3 (I took it from hudson). It fails when it tries to add ThisOSProcess to the startup list with: Smalltalk addToStartUpList: ThisOSProcess after: ImageSegment. in ThisOSProcess class>>initialize. It seems that ImageSegment is not in the StartUpList anymore. Is that normal? Adrien.

5 7

[Pharo-project] suppressing the ob ast navigation
by Tudor Girba May 20, 2011

May 20, 2011

Hi, In the latest OB, pressing ctrl+shift+(left/right)arrow gets you to navigate through the AST. This is certainly cool, but I could not find a usage for it yet :). But, the problem is that it overloads the ctrl+shift which in any text editor selects the previous/next word. If this feature is indeed wanted, could we find another keybinding solution for it? If not, how can I disable it in my image? Cheers, Doru -- www.tudorgirba.com "Presenting is storytelling."

5 7

Re: [Pharo-project] Name spaces
by Marcus Denker May 20, 2011

May 20, 2011

On May 20, 2011, at 3:43 PM, Philippe Marschall wrote: > On 05/20/2011 02:52 PM, Janko MivÅ¡ek wrote: >> On 20. 05. 2011 14:15, StÃ©phane Ducasse wrote: >> >>>>>> I'm wondering what is the status of the name spaces project developed last summer as part of GSoC. >>>>> >>>>> nowhere and do not expect it to be in pharo. >>>> >>>> Why that? Is it because of the implementation or because you don't want >>>> namespaces in Pharo? >>> >>> sorry guy I do not have the time for discussing that. >> >> But it is certainly needed to be discussed and it would be nice if at >> least a timeframe for this discussion is announced. If not put in a plan >> for Pharo ... > > Yes, name spaces haven't yet been discussed enough. > Maybe we can establish a new tradition and have a 100+ discussion about namespaces every year. It worked well for Squeak... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

7 6

[Pharo-project] My solution to handling errors in system-critical processes
by Igor Stasenko May 20, 2011

May 20, 2011

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.

2 1

Re: [Pharo-project] Can't load OSProcess in last Pharo Core 1.3
by Marcus Denker May 20, 2011

May 20, 2011

On May 20, 2011, at 5:30 PM, Adrien BARREAU wrote: > I just saw that update 13205 removed ImageSegment from the StartUpList. > > Replacing > Smalltalk addToStartUpList: ThisOSProcess after: ImageSegment. > by > Smalltalk addToStartUpList: ThisOSProcess before: UUIDGenerator. > in ThisOSProcess>>initialize would be ok I think (and would have the same result). > > The problem is that there was no #addToStartUpList:before: So if you wanted to add yourself before something (because that thing depends on you), you had to add after something completely unrelated, leading to strange dependencies (like OSProcess depending on ImageSegment in the startup list..) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Re: [Pharo-project] [Vm-dev] Re: out of memory - cog on windows
by Tudor Girba May 20, 2011

May 20, 2011

Hi, I am not sure I understand where we are on this issue. I will say it again that I find it to be critical to be able to work with images that are not small :). Would it be possible to find some resolution on it? Cheers, Doru On 20 May 2011, at 17:08, Andreas Raab wrote: > On 5/20/2011 16:57, Igor Stasenko wrote: >> Here an excert from crash.dmp: >> >> Memory Information (upon launch): >> Physical Memory Size: 4194303 kbytes >> Physical Memory Free: 2507424 kbytes >> Page File Size: 4194303 kbytes >> Page File Free: 4194303 kbytes >> Virtual Memory Size: 2097024 kbytes >> Virtual Memory Free: 2030280 kbytes >> Memory Load: 59 percent >> >> this is strange. >> Of course, with sizes like above , it cannot fit into memory. > > Nothing strange about it. Standard 4GB Ram configuration with about 2GB available. > > Cheers, > - Andreas > > >> >>> Hi, >>> >>> On 18 May 2011, at 18:07, Levente Uzonyi wrote: >>> >>>> On Wed, 18 May 2011, Tudor Girba wrote: >>>> >>>> snip >>>> >>>>> I tried with several versions of Cog including the latest ones (on both platforms) and I got the same result. I did not try with an interpreter VM because I only have Cog images around (based on Pharo 1.2) and they are not compatible. >>>> You can use this interpreter vm to open cog images: http://leves.web.elte.hu/squeak/SqueakVM-Win32-4.4.9-2358-non-official-bin.… >>> I tried with this VM, but it crashes with the attached error. >>> >>> In any case, if someone wants to reproduce it, here is an image to play with: >>> http://dl.dropbox.com/u/18323746/Tmp/moose-case-study-windows-problem.zip >>> >>> Cheers, >>> Doru >>> >>> >>> >>> >>> >>>> Levente >>>> >>>> snip >>> -- >>> www.tudorgirba.com >>> >>> "Being happy is a matter of choice." >>> >>> >> >> -- www.tudorgirba.com "Every thing has its own flow."

1 0

Re: [Pharo-project] paragraph replacement?
by Marcus Denker May 20, 2011

May 20, 2011

On May 20, 2011, at 1:22 PM, Tudor Girba wrote: > Hi, > > Another class we used in EyeSee (besides Circle) is Paragraph. I see that this class is now deprecated and empty. What should we use instead of it? > NewParagraph It has a different API, though. And there is a subclass that is the one used by the system (MultiNewParaph)... this part of the system definitly needs more cleanup and simplification. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 2

[Pharo-project] [update 1.3] #13207
by Marcus Denker May 20, 2011

May 20, 2011

13207 ----- Issue 4173: If sources file is not present, something bad happens -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0