- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] My solution to handling errors in system-critical processes

by Igor Stasenko

Here the revised version, which more optimal. Initially i was capturing thisContext into temporary variable, which when running on Stack-based VMs leads to reifying context on heap. This can be avoided, since we can simply find this context from closure's home. So if your code runs without errors you will pay usual price of #on:do: handler. -- Best regards, Igor Stasenko AKA sig.

May 21, 2011

Re: [Pharo-project] VW's ObjectRegistry similar in Pharo?

by Andres Valloud

I think you want the add: that returns true/false depending on whether the object was there or not. In that way, you can just say add: and forget about includes:. On 5/19/11 15:34 , Mariano Martinez Peck wrote: > Hi guys. We are doing graph traversal (for Fuel) and we would love a > collection to be really fast and only support two simple operations: > #add: and #includes: > The idea is that each object we process of the graph we put it in the > collection and then for each object we have to ask whether it is > included or not (to avoid cycles and putting the same object more than > once). > > VW seems to have ObjectRegistry (subclass of IdentitySet) which is more > or less that. It is used by ObjectTracer, which in fact is what we want > to do. And even more, Parcels uses that ;) (or an extension of that). > > So...I wonder, is there a special collection implementation ideal for > this case? is something similar to ObjectRegistry available for pharo ? > > Thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com >

May 21, 2011

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

by Andres Valloud

Statements like "just pretend you know what you're doing" should raise red flags because it leads to "doing anything at all, even it is bad, is good". One might as well forget trying to know in favor of pretending to know, because doing something (anything) makes you right. But of course, no amount of pretense will make software work when it's critical for it to work at a customer's site, or when doing a demo of your research work while defending your thesis. Not only that, but doing something any which way has the hidden cost of incurring into software debt. Exactly how much cleanup homework are we still dealing with because of that kind of attitude? Are we happy with the results? Things that Work(TM) don't happen by accident, they are the product of significant amounts of effort. Shoddy code that appears to work some of the time is Just Bad(TM), and sooner or later you pay for it ***with interest***. On 5/18/11 4: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. > > > . >

May 21, 2011

Re: [Pharo-project] Name spaces

by Igor Stasenko

On 20 May 2011 23:34, Casimiro de Almeida Barreto <casimiro.barreto(a)gmail.com> wrote: > Em 20-05-2011 14:18, StÃ©phane Ducasse escreveu: > > ah tradition are so good. > May be we should have a cron job for these topics :) > > Stef > > (...) > Yeah. Let's assume something like that: > > #/bin/bash > > if [ $# -lt 2 ] > then > Â echo $0 "Wrong number of parameters. Plz, specify rant/bragging" > else > Â /usr/local/bin/restartOldDiscussion -topic $1 & > Â PID=$! > Â if [ $PID != "" ] > Â then > Â Â sleep `expr 3600 \* 24 \* 5` > Â Â Â kill -KILL $PID > Â fi > fi > > That would limit "periodic discussions" to 5 days (top)... > (sorry, couldn't resist) > No..We don't need that. We could ask someone to lead Endless Topic Of The Day, in same manner as Class Comment Of The Day and Bug Fix of The Day :) -- Best regards, Igor Stasenko AKA sig.

May 21, 2011

Re: [Pharo-project] [squeak-dev] My solution to handling errors in system-critical processes

by Igor Stasenko

Another application to elegantly solve well known problem: - spawning debugger windows in the loop, which effectively kills your image, because you cannot close those windows at the same rate they appear. So, consider a following : 100 timesRepeat: [ [ 1/0 ] on: Error fork: [:ex | ex pass ] ] this is what you usually get, if you are not careful or not doing self haltOnce etc.. Which actually makes debugging UI a hellishly tedious and hard task. Now what we can do instead? | sema | sema := Semaphore forMutualExclusion. 100 timesRepeat: [ [ 1/0 ] on: Error fork: [:ex | sema critical: [ ex pass ] ] ] now, you will see only a single window opened at one point of time. And once you deal with error, if there's another one, it will open second one and so on.. But not all of them at once. And later, if we are not happy with this, we could add a feature to 'Abandon same class of errors' , i.e. terminate forks with all errors which originated from same method. In that way, you can deal with error once, and kill the rest which otherwise will annoy you to death. -- Best regards, Igor Stasenko AKA sig.

May 21, 2011

Re: [Pharo-project] [squeak-dev] My solution to handling errors in system-critical processes

by Igor Stasenko

On 20 May 2011 19:33, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Igor, > Â Â Â I get the idea but I does one really need on:fork: ? Â Why not add > Exception>fork, a la Exception>pass? Â So one writes > [ self doSomething Â ] on: Error do: [:ex | ex fork ]. > and if you want to specify a handler function you pass in a block: > > [ self doSomething Â ] on: Error do: [:ex | ex fork: [block to handle error > in another process here] ]. Good question. You can implement it anywhere. Except then how to correctly determine stack slicing point? Exception>>fork: aBlock contextToSlice := thisContext sender home ? see, the above is too fragile. Where the guarantees that you sending #fork: inside a block, but not like: Error new fork: [ .... ] ? If you looked at implementation, i capturing the context of a method before sending #on:do: in this way, i know the stack slicing point beforehand. But if i place it into exception, then correct behavior will have to rely on developer's sanity that he using it as intended by design. So, why putting pitfalls when we can avoid them? My choice for stack slicing point was to let user to see the closure context with on:do: while debugging, otherwise it will be harder to determine the origin of code, which led to error. Right now, if you evaluate [ 1/0 ] on: Error fork:[ :ex | ex pass ] in debugger, you will see the 2nd bottom context will be an on:do: method, and next one will contain the context for closure that is receiver of #on:do: so in this way you can clearly see the method with exception handler, who wanted to handle errors in forked process. > ? > Further, re the finalization issue why are you so resistant to the > tried-and-tested VW solution that's been in use for about a decade? i am not resistant at all. I had no time to do that. Actually, i came to this idea when looking at Henrik's code for Announcements.. and then i found that it can serve for both finalization and Announcements (and lot of other critical places, where you don't want to be killed by errors). For instance , today i shown to Stef, that by placing it at single point in WorldState>>doOneCycleNowFor: aWorld we could avoid respawning UI process each time you open debugger. You slicing the stack with error, putting it into forked process, where you can do anything with it, while UI process continues to run from known safe point. So it solves more problems than just in finalization. Also i think that it is more efficient: you pay the high price only when it is necessary - when exception happens, but if things go as expected , the overhead is minimal. While in solution which you describing, the price was higher, since you have to pass the finalizer to forked process and signal semaphore, and then wait till it finish or fork another process. And synchronization is not cheap, and moreover, you will have 1 extra process hanging around all the time. While now i can simply do: executors do: [:executor | [ executor finalize ] on: Exception fork: [ :ex | ex pass ] ] > best, > Eliot -- Best regards, Igor Stasenko AKA sig.

May 20, 2011

Re: [Pharo-project] Can't load OSProcess in last Pharo Core 1.3

by David T. Lewis

This is fixed in both OSProcess and CommandShell on SqueakSource. I found an old comment in my code that says this: "Some images may have a bug in startup list processing. Add this class to a known place in the middle of the list to avoid getting bitten by the bug." So I knew that it was safe now to just use #addToStartUpList: instead of #addToStartUpList:after: This is the reason that people like me with bad memories need to write good comments ;-) Dave On Fri, May 20, 2011 at 03:18:53PM -0400, David T. Lewis wrote: > I don't remember why I put that dependency on the startup list for > OSProcess, but I'll take a look at it this weekend and see if there > is a better way. Probably it was just to ensure that file related > things were initialized prior to starting OSProcess initialization. > > Dave > > On Fri, May 20, 2011 at 08:26:59PM +0200, St?phane Ducasse wrote: > > Adrien > > > > people do not realize that you are not maintaining OSProcess :) > > So we should check and publish a new version of OSProcess with a difference startUpDependency. > > > > On May 20, 2011, at 5:07 PM, Adrien BARREAU wrote: > > > > > 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. > >

May 20, 2011

Re: [Pharo-project] SIXX problem for ScaledDecimal

by Chris Cunningham

On Fri, May 20, 2011 at 7:57 AM, Ralph Boland <rpboland(a)gmail.com> wrote: > Dealing with ScaledDecimal is a complicated matter and I have probably failed > to appreciate many of the complications but whoever is implementing > ScaledDecimal > (and Smalltalk needs ScaledDecimal) needs to appreciate those complications. > Anybody here a financial expert? > I am not a financial expert, but this is how ScaledDecimal works, in both Squeak/Pharo and I believe other implementations, too. I did run into this previously and it bugged me enough that I created FixedDecimal (at http://www.squeaksource.com/FixedDecimal.html ). It does not keep an internal more precise number - it keeps exactly what it shows you. (Although the implementation is somewhat odd - it does do what it is supposed to do.) -Chris

May 20, 2011

Re: [Pharo-project] Name spaces

by Igor Stasenko

On 20 May 2011 16:59, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On May 20, 2011, at 4:31 PM, Toon Verwaest wrote: >>>> >>> Maybe we can establish a new tradition and have a 100+ discussion about namespaces >>> every year. It worked well for Squeak... >> Wasn't the whole idea of Pharo to turn every "discussion in Squeak" into a "do in pharo"? > > Yes. We want namespaces. But we don't want to discuss about them now if we don't have > the manpower to *do* anything. Let's finish the stuff already started... we really can't open > yet another things now. (At least I can't. I can't even read a discussion. I am full) > +1 I dreaming about namespaces. after we got a new compiler, environments, object spaces.. then we can see new horizons opening for us. > Â Â Â Â Marcus > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > -- Best regards, Igor Stasenko AKA sig.

May 20, 2011

Re: [Pharo-project] bug in Nautilus/RPackage?

by Benjamin

Can you inspect the RPackageOrganizer to see if it comes from RPackage or from Nautilus please ? Thanks in advance, Ben On May 20, 2011, at 10:26 PM, Alexandre Bergel wrote: >> I don't know how to reproduce the situation in the screenshot, but I have a small idea of what the problem is: >> Your package Spy is composed of several subcategories. All the classes are defined in the subcategories but none is defined in the one called 'Spy'. > > All Spy classes are defined in a category Spy-XXX > >> In Rpackage, the classes are put inside the RPackage matching the category in which the class is defined > > What does it mean? How comes that the package Spy was created? Where does it come from? > > I just took a fresh 1.3 one click, downloaded Nautilus then Spy. Spy appear as one single package called 'Spy'. No idea where it comes from. > > Alexandre > >> >> 2011/5/19 Alexandre Bergel <alexandre.bergel(a)me.com> >> Thanks for making it happen :-) >> >> Alexandre >> >> >> On 19 May 2011, at 15:39, StÃ©phane Ducasse wrote: >> >>> thanks for reporting it. >>> >>> do you have a reproducable way of arriving to this state? >>> >>>> 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 >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> <Screen shot 2011-05-19 at 11.21.23.png> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

May 20, 2011