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

Re: [Pharo-project] suppressing the ob ast navigation

by Lukas Renggli

In the latest version I changed it to Alt/Option+[Shift+]Left/Right arrow. That combination doesn't seem to be used. As a side note: to figure out if the alt/option key is pressed in Pharo one has to do bit-fiddeling ... buttons anyMask: 32 All other accessors have test methods. Lukas On 18 May 2011 13:04, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi again, > > Furthermore, ctrl+(left/right)arrow does not navigate through text words anymore. Instead, it seems to do the AST navigation :(. > > Cheers, > Doru > > > On 18 May 2011, at 12:40, Tudor Girba wrote: > >> 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." >> > > -- > www.tudorgirba.com > > "Reasonable is what we are accustomed with." > > > -- Lukas Renggli www.lukas-renggli.ch

May 20, 2011

Re: [Pharo-project] Name spaces

by Nicolas Cellier

With something like IBM supercomputer Watson (re-programmed in Smalltalk of course) it should be possible to extract argumentation from previous posts and let bots compose nice threads. Nicolas 2011/5/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > ah tradition are so good. > May be we should have a cron job for these topics :) > > Stef > > >> >> 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) >> >> Â Â Â Marcus >> >> >> -- >> Marcus Denker Â -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> > > >

May 20, 2011

Re: [Pharo-project] Name spaces

by StÃ©phane Ducasse

ah tradition are so good. May be we should have a cron job for these topics :) Stef > > 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) > > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

May 20, 2011

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

by StÃ©phane Ducasse

Lovely :) I want more - I want some tests :) For example that the running process is still running. Stef On May 19, 2011, at 12:56 PM, Igor Stasenko wrote: > 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. > <BlockClosure-onfork.st>

May 20, 2011

Re: [Pharo-project] SIXX problem for ScaledDecimal

by Dario Trussardi

But: > >>> From: Chris Cunningham <cunningham.cb(a)gmail.com> >>> Subject: Re: [Pharo-project] SIXX problem for ScaledDecimal >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Message-ID: <BANLkTinP7E_oh2Fi2=axmra6JsoXVJYWkg(a)mail.gmail.com> >>> Content-Type: text/plain; charset=ISO-8859-1 >> >>> For ScaledDecimal, SIXX should definite store it as the underlying >>> fraction. Storing it in the printed fashion does change the value of >>> the ScaledDecimal. >> >>> (1/3) asScaledDecimal: 2 gives 0.33s2 >>> and >>> (33/100) asScaledDecimal: 2 gives 0.33s2 >>> yet >>> 0.33s2 ~= ( (1/3) asScaledDecimal: 2 ) >>> and >>> ( (1/3) asScaledDecimal: 2 ) ~= ( (33/100) asScaledDecimal: 2 ) >> >>> In other words, the ScaledDecimal is about the precise internal number >>> and the scale to display it - which is NOT the scale that it is stored >>> as. >> >>> -Chris >> >> I don't agree. ScaledDecimal would be used where consistency is often >> more important than accuracy, e.g. in Financial calculations where being off by >> a few pennies doesn't matter but always getting the same answer matters a LOT. >> Once a number is converted to a ScaledDecimal computations must always >> produce the same result assuming enough digits. To ensure this asScaledDecimal >> must produce a scaled decimal for use in computations and, as such, storing >> a fraction internally is unacceptable. >> From a financial point of view 1/3 * 3 is not 1! >> From a programmers point of view asScaledDecimal changes the value >> in much the same way asInteger does for a float. >> >> Having said all of this allow me to contradict myself. It seems to me that >> a scaled decimal should in general store more digits than are displayed. >> For example money might be stored with a large (possibly arbitrary) number >> of digits after the decimal point but only display two digits beyond the decimal >> point. >> I don't know how ScaledDecimal is implemented but I would be inclined to >> use arbitrary or large size integers and store the location of the decimal point >> internally recomputing the position of the decimal point after each calculation. >> This is an expensive way of doing computations but I expect users of >> ScaledDecimal can live with that. When converting non decimal results to >> ScaledDecimal then how many digits of precision to maintain must be specified >> somehow. >> 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? >> >> Ralph Boland >> > > I think ScaledDecimal for financial data. > > Where rounded is do only for the last of the operations. ( the total of the document for example or when i command it ) > > I do : > > ( ((1/3 asScaledDecimal:5 ) + (1/3 asScaledDecimal:5 )) * (6 asScaledDecimal:5) ) > > > The result 4 is not right . > > > 2/3 * 6 when management 5 decimal are : > > 0,66666 * 6,00000 = 3,99996 > > and not fraction 2/3 * 6/1 -> 12 / 3 - > 4 > > BUT : (( 0.33333 asScaledDecimal: 5 )+ (0.33333 asScaledDecimal: 5 ) ) *6 3.99996s5 is right. Dario

May 20, 2011

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

by Mariano Martinez Peck

On Fri, May 20, 2011 at 5:07 PM, Adrien BARREAU <abarreau.dev(a)live.fr>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. > I think that is incorrect. Why would OSProcess requires to be before ImageSegment? OSProcess should be before what it really needs. And if it doesn't need anything then just use #addToStartupList: > in ThisOSProcess class>>initialize. > > > It seems that ImageSegment is not in the StartUpList anymore. > Is that normal? > > Adrien. > -- Mariano http://marianopeck.wordpress.com

May 20, 2011

Re: [Pharo-project] SIXX problem for ScaledDecimal

by Dario Trussardi

>> From: Chris Cunningham <cunningham.cb(a)gmail.com> >> Subject: Re: [Pharo-project] SIXX problem for ScaledDecimal >> To: Pharo-project(a)lists.gforge.inria.fr >> Message-ID: <BANLkTinP7E_oh2Fi2=axmra6JsoXVJYWkg(a)mail.gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1 > >> For ScaledDecimal, SIXX should definite store it as the underlying >> fraction. Storing it in the printed fashion does change the value of >> the ScaledDecimal. > >> (1/3) asScaledDecimal: 2 gives 0.33s2 >> and >> (33/100) asScaledDecimal: 2 gives 0.33s2 >> yet >> 0.33s2 ~= ( (1/3) asScaledDecimal: 2 ) >> and >> ( (1/3) asScaledDecimal: 2 ) ~= ( (33/100) asScaledDecimal: 2 ) > >> In other words, the ScaledDecimal is about the precise internal number >> and the scale to display it - which is NOT the scale that it is stored >> as. > >> -Chris > > I don't agree. ScaledDecimal would be used where consistency is often > more important than accuracy, e.g. in Financial calculations where being off by > a few pennies doesn't matter but always getting the same answer matters a LOT. > Once a number is converted to a ScaledDecimal computations must always > produce the same result assuming enough digits. To ensure this asScaledDecimal > must produce a scaled decimal for use in computations and, as such, storing > a fraction internally is unacceptable. > From a financial point of view 1/3 * 3 is not 1! > From a programmers point of view asScaledDecimal changes the value > in much the same way asInteger does for a float. > > Having said all of this allow me to contradict myself. It seems to me that > a scaled decimal should in general store more digits than are displayed. > For example money might be stored with a large (possibly arbitrary) number > of digits after the decimal point but only display two digits beyond the decimal > point. > I don't know how ScaledDecimal is implemented but I would be inclined to > use arbitrary or large size integers and store the location of the decimal point > internally recomputing the position of the decimal point after each calculation. > This is an expensive way of doing computations but I expect users of > ScaledDecimal can live with that. When converting non decimal results to > ScaledDecimal then how many digits of precision to maintain must be specified > somehow. > 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? > > Ralph Boland > I think ScaledDecimal for financial data. Where rounded is do only for the last of the operations. ( the total of the document for example or when i command it ) I do : ( ((1/3 asScaledDecimal:5 ) + (1/3 asScaledDecimal:5 )) * (6 asScaledDecimal:5) ) The result 4 is not right . 2/3 * 6 when management 5 decimal are : 0,66666 * 6,00000 = 3,99996 and not fraction 2/3 * 6/1 -> 12 / 3 - > 4 I'm surprised about it. Any idea ? Dario

May 20, 2011

Re: [Pharo-project] SIXX problem for ScaledDecimal

by Dario Trussardi

Il giorno 20/mag/2011, alle ore 16.57, Ralph Boland ha scritto: >> From: Chris Cunningham <cunningham.cb(a)gmail.com> >> Subject: Re: [Pharo-project] SIXX problem for ScaledDecimal >> To: Pharo-project(a)lists.gforge.inria.fr >> Message-ID: <BANLkTinP7E_oh2Fi2=axmra6JsoXVJYWkg(a)mail.gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1 > >> For ScaledDecimal, SIXX should definite store it as the underlying >> fraction. Storing it in the printed fashion does change the value of >> the ScaledDecimal. > >> (1/3) asScaledDecimal: 2 gives 0.33s2 >> and >> (33/100) asScaledDecimal: 2 gives 0.33s2 >> yet >> 0.33s2 ~= ( (1/3) asScaledDecimal: 2 ) >> and >> ( (1/3) asScaledDecimal: 2 ) ~= ( (33/100) asScaledDecimal: 2 ) > >> In other words, the ScaledDecimal is about the precise internal number >> and the scale to display it - which is NOT the scale that it is stored >> as. > >> -Chris > > I don't agree. ScaledDecimal would be used where consistency is often > more important than accuracy, e.g. in Financial calculations where being off by > a few pennies doesn't matter but always getting the same answer matters a LOT. > Once a number is converted to a ScaledDecimal computations must always > produce the same result assuming enough digits. To ensure this asScaledDecimal > must produce a scaled decimal for use in computations and, as such, storing > a fraction internally is unacceptable. > From a financial point of view 1/3 * 3 is not 1! > From a programmers point of view asScaledDecimal changes the value > in much the same way asInteger does for a float. > > Having said all of this allow me to contradict myself. It seems to me that > a scaled decimal should in general store more digits than are displayed. > For example money might be stored with a large (possibly arbitrary) number > of digits after the decimal point but only display two digits beyond the decimal > point. > I don't know how ScaledDecimal is implemented but I would be inclined to > use arbitrary or large size integers and store the location of the decimal point > internally recomputing the position of the decimal point after each calculation. > This is an expensive way of doing computations but I expect users of > ScaledDecimal can live with that. When converting non decimal results to > ScaledDecimal then how many digits of precision to maintain must be specified > somehow. > 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? > > Ralph Boland > I think ScaledDecimal for financial data. Where rounded is do only for the last of the operations. ( the total of the document for example or when i command it ) I do : ( ((1/3 asScaledDecimal:5 ) + (1/3 asScaledDecimal:5 )) * (6 asScaledDecimal:5) ) The result 4 is not right . 2/3 * 6 when management 5 decimal are : 0,66666 * 6,00000 = 3,99996 and not fraction 2/3 * 6/1 -> 12 / 3 - > 4 I'm surprised about it. Any idea ? Dario

May 20, 2011

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

by Miguel CobÃ¡

Yes that is a workaround but not a final fix, because it depends on a specific class in the system. In squeak, IIRC, it was a discussion about changing ordering of startup items using numbers instead of names of classes in the image, something similiar to the Linux startup infrastructure. But for now it is ok to change it as you said. Cheers El vie, 20-05-2011 a las 17:29 +0200, Adrien BARREAU escribiÃ³: > 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). > > Adrien. > > > > ______________________________________________________________________ > From: abarreau.dev(a)live.fr > To: pharo-project(a)lists.gforge.inria.fr > Date: Fri, 20 May 2011 17:07:04 +0200 > Subject: [Pharo-project] Can't load OSProcess in last Pharo Core 1.3 > > 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. -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

May 20, 2011

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

by Marcus Denker

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.

May 20, 2011