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

Re: [Pharo-project] Announcement real problems - please read and comment.

by StÃ©phane Ducasse

Ok guys so I want a solution :). So how can we improve Announcement to cover different cases? Stef >>>> collection do: [:each | each doSomeAction ] >>>> >>>> but the problem here is that if one action triggers an error, then >>>> your loop are interrupted and no other actions performed >>>> for the remaining elements of collection. >>>> >>>> So, we need such behavior , that guarantees that: >>>> a) all elements , except errorneous get processed >>>> b) if an error is unhandled by action , then show a debugger window >>>> >>>> in terms of implementation this means that we should run each action >>>> in separate forked process (and Eliot described a clever scheme how to >>>> avoid most overhead of forking). >>>> >>>> So then, even if some action will trigger an error, it won't interrupt >>>> the loop and error could be handled in debugger >>> >>> Or instead of forking each action, simply: >>> (changed to make OC copy) >>> deliver: anAnnouncement >>> | cls copy | >>> cls := anAnnouncement class. >>> >>> "using a copy, so subscribers can unsubscribe from announcer " >>> "Use OrderedCollection , so unwind protection is easier" >>> self protected: [ copy := subscriptions as: OrderedCollection ]. >>> self deliver: anAnnouncement to: copy >>> >>> (private category) >>> deliver: anAnnouncement to: subs >>> >>> subs do: >>> [:each | >>> [each deliver: anAnnouncement] >>> ifCurtailed: [self deliver: anAnnouncement to: (subs after: each)]] >>> >> >> then probably you can do it in right place - in subscription>>deliver: >> put ifCurtailed: handler. > > You don't have access to the remaining subscriptions in the subscription instances. > ifCurtailed: sort of means "I'm about to terminate you (well, or do a non-local return, but that's never the case here), wanna do anything first?", so in my mind, the correct answer is the Registry saying "Hold on a bit, let me deliver to the remaining subscribers as well" > >> >>> >>> This has the added benefits of: >>> - No thread creation overhead (Not sure if how it's written avoids creating a block for argument to each ifCurtailed call though) >>> - Reproducibility. >>> Especially in the case Stephane gave, if you forking in separate threads, his code would appear to work when stepping in debugger. >>> There'd be mucho frustration and grumbling over announcements failing one second, but working the next. :) >>> >>> Downside is ofc that rest of subscribers won't be notified until you proceed/exit the debugger, but compared to reproducibility, that's a small price to pay imho. >>> >> >> Its really depends on use case, what is preferable behavior. For >> instance if you stall in debugger when delivering UI events, then no >> new events could be handled and you dead, >> so in cases like this you cannot afford to stop handler from >> processing events and wait for user intervention. > > Oh I agree. > I'd argue that is the exceptional exception case (:D) where you'd want a specialized announcer rather than the other way around though. :) > Prolly just me, but even in this case I'd favor a stacktrace which makes sense over a system which kinda sorta keeps on working when I do something horribly wrong. > >> Also, i think it would be nice to disable a subscription, so it won't >> receive any new announcements if it stopped under debugger, because if >> you don't do that, and new announcements are flowing at some constant >> rate, then you will have a tons of debugger >> windows popping out and no way to stop that :) > > You'd definitely need an Error handler for that, yeah. It not mutually exclusive with using ifCurtailed: protection though. > > Cheers, > Henry > > >

April 4, 2011

Re: [Pharo-project] [SPAM] Re: [ANN 1.2] 1.2.1 Full Release Image

by StÃ©phane Ducasse

I can go over the scriptloader log and complement what is at http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotTwo Stef

April 4, 2011

Re: [Pharo-project] [SPAM] Re: [ANN 1.2] 1.2.1 Full Release Image

by StÃ©phane Ducasse

>> >>> Please help because we have not the steam for the splash organization. >> >> So we poor users have to do all the work ?? >> >> Seriously, what is the easiest/fastest way to get to a rough list of the changes between 1.1.1 and 1.2.1 ? >> >> From that list we could try to make a readable list for release notes and then we could try to make a list of bullet points / highlights. >> > > Mariano started a list: I started it :) > > http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotTwo > > All things done should have a tracker entry: > > http://code.google.com/p/pharo/issues/list?can=1&q=milestone=1.2 > http://code.google.com/p/pharo/issues/list?can=1&q=Milestone%3D1.2-DevImage > > > > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

April 4, 2011

Re: [Pharo-project] [ANN 1.2] 1.2.1 Full Release Image

by Marcus Denker

On Apr 4, 2011, at 4:58 PM, Mariano Martinez Peck wrote: > I started to try to release 1.2. Not only I did the list of changes but also: > > 1) I asked if people still wanted the background: http://forum.world.st/Do-you-want-to-add-the-background-picture-to-the-imag… > results: negative. So, no backgrund. White as it is now. > > 2) I asked what people wanted that used to be in 1.1: http://forum.world.st/Do-we-want-this-for-Pharo-1-2-and-futures-td3350721.h… > guess how many replies? TWO. > results: I would only nclude the installScript. I guess that Hudson could do that very easy, doesn't it ? marcus ? > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/lastSuccessfulBuild/… Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 4, 2011

Re: [Pharo-project] IPAddressCountry & Iso3166CountryLongitudeLatitude

by Miguel CobÃ¡

Amazing app, you have there. Looks very professional. And the interface is very attractive. Good job! El lun, 04-04-2011 a las 15:21 +0200, Sven Van Caekenberghe escribiÃ³: > I want to share a couple of classes. > > Did you ever want to add this trick to your website where you do something based on the country your visitors are from ? Now you can do so in Smalltalk ! > > T3EasyUtils getIpAddressCountry atAddress: '81.83.7.35' > > #BE > > T3EasyUtils getIso3166CountryLongitudeLatitude at: #BE > > 4.0(a)50.8333 > > #('www.beta9.be' 'www.inria.fr' 'nic.st' 'www.world.st' 'www.pharo-project.org') > collect: [ :each | T3EasyUtils getIpAddressCountry atAddress: (NetNameResolver addressForName: each) ] > > #(#BE #FR #SE #US #CH) > > (T3EasyUtils is holding unique, loaded instances of IPAddressCountry & Iso3166CountryLongitudeLatitude). > > As this is part of one of our commercial applications, you can even access it over the internet as a JSON REST call: > > $ curl http://easy.t3-platform.net/rest/geo-ip?address=81.83.7.35 > > {"latitude":50.8333,"address":"81.83.7.35","country":"BE","longitude":4.0} > > (Please note that this is not a public service as such, you can try it, but you are not supposed to call this from your own applications.) > > BTW, T3 Easy is our new entry level track & trace product, an HTML5 web app (using client side HTML+Javascript+CSS) on top of a REST server written in Pharo Smalltalk. It consists of 4 stateless Pharo Cog VM's running behind an Apache load balancer. The server uses Zinc HTTP Components, both for its server part, as well as for clients talking to other systems behind the scenes. Even the Open Street Map tile serving, which is pushing out many megabytes, is currently going through this server. > > Here is a live demo URL in case your are curious: > > http://easy.t3-platform.net?t=livedemo > > (You need a fast web browser like Google Chrome, Safari, Opera 10 or Firefox 4.) > > The code for IPAddressCountry & Iso3166CountryLongitudeLatitude is on SqueakSource: > > http://www.squeaksource.com/ADayAtTheBeach.html > > These are the class comments: > > --- > > IPAddressCountry maps IP addresses to their country code. > I hold a collection of IPAddressRangeCountry objects that I do a binary search on. > > I am constructed based on a CSV data file using my class' #readFrom: > which expects lines like 3651886848,3651887103,BE or start,stop,code > > You can download a version of this file from http://homepage.mac.com/svc/data/GeoIPCountry.csv.gz > > ((IPAddressCountry readFrom: 'GeoIPCountry.csv') atAddress: '81.83.7.35') = #BE > > Addresses can also be specified as #(81 83 7 35) for #atAddress: or as 1364395811 for #at: > > You should cache one instance of me. > > Based on data from http://www.maxmind.com/app/geolitecountry > > --- > > Iso3166CountryLongitudeLatitude maps country codes to their average or central longtiude/latitude. > > My keys are two letter Iso3166 Symbols representing a country, such as #BE > My values are Points holding coordinates as longtiude@latitude > > I am constructed based on a CSV data file using my class' #readFrom: > which expects lines like BE,50.8333,4.0000 or code,latitude,longitude > > You can download a version of this file from http://homepage.mac.com/svc/data/CountryLatLong.csv.gz > > ((Iso3166CountryLongitudeLatitude readFrom: 'CountryLatLong.csv') at: #BE) = 4.0(a)50.8333 > > You should cache one instance of me. > > --- > > Sven > > > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

April 4, 2011

Re: [Pharo-project] Transcript rant

by StÃ©phane Ducasse

> Yes. Consider and API of well established unix logging facility such as syslog. > From application's point of view there is only one direction in > communication: it writes to syslog, and syslog then directs content > somewhere else (and where exactly is doesn't matters and not a concern > of application). > And its also thread safe, of course (but not at cost of having only > single way to do things). And apparently there is no API to read what > is just written (like #ensureCr, which implies reading the last > character from stream to check if it is cr). > > In this respect an old implementation was much nicer in a sense that > it could be replaced by different stream which responds to same > protocol.. > But now, Transcript is a class, and its much harder to replace it and > as to me it is too hardwired. > Maybe this is good for Cuis, but as to me, i consider Transcript as a > generic/default logging facility in smalltalk system. > I was planning to redirect Transcript to write to stdout when in > headless mode (and when VMs will provide stdio communication out of > the box). Yes we are in sync on that. > But how i suppose to do it now? Hacking existing class? And then > again, what if someone wants to redirect transcript to socket (and its > easy to imagine where we may need that - suppose you working with > remote image and want to see its transcript). > So, hacking the same class again? Ok so how do we make progress? > P.S. i know that maybe a preferable way to do logging is through 'self > log:' protocol etc.. > but lets face reality: there are a tons of code in system which using > Transcript. And i don't think that we will abandon it in nearest > future. > So, lets just keep it and make it more nicer, but lets separate concerns.

April 4, 2011

Re: [Pharo-project] Announcement real problems - please read and comment.

by Henrik Johansen

On Apr 4, 2011, at 5:06 16PM, Igor Stasenko wrote: > On 4 April 2011 16:38, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >> On Apr 4, 2011, at 1:16 29PM, Igor Stasenko wrote: >> >>> On 4 April 2011 12:55, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> >>>>>>>> Henrik what is your answer to problem 1 >>>>>>>> >>>>>>>> Problem 1 >>>>>>>> - the second announcement was never sent, because the first one broke the second was blocked. >>>>>>>> >> we should make sure that if an announcement leads to an error, other annoucements on the same emit should pass >>>>>>>> >>>>>>>> Because we can get the system down just because one guy can register a bug. >>>>>>> http://forum.world.st/Another-finalization-concern-error-handling-td2989615… >>>>>>> >>>>>>> It's basically the same. >>>>>> ?? >>>>> Same basic problem, same solutions apply. >>>>> I'd rather not repeat the exact same discussion. >>>>> Just exchange "finalization" with "announcement delivery" when reading the thread >>>> >>>> Igor what was exactly the summary? >>>> >>> >>> Summary, in short, is following: >>> >>> we want to iterate over some arbitrary collection and perform an >>> action per each element, like: >>> >>> collection do: [:each | each doSomeAction ] >>> >>> but the problem here is that if one action triggers an error, then >>> your loop are interrupted and no other actions performed >>> for the remaining elements of collection. >>> >>> So, we need such behavior , that guarantees that: >>> a) all elements , except errorneous get processed >>> b) if an error is unhandled by action , then show a debugger window >>> >>> in terms of implementation this means that we should run each action >>> in separate forked process (and Eliot described a clever scheme how to >>> avoid most overhead of forking). >>> >>> So then, even if some action will trigger an error, it won't interrupt >>> the loop and error could be handled in debugger >> >> Or instead of forking each action, simply: >> (changed to make OC copy) >> deliver: anAnnouncement >> | cls copy | >> cls := anAnnouncement class. >> >> "using a copy, so subscribers can unsubscribe from announcer " >> "Use OrderedCollection , so unwind protection is easier" >> self protected: [ copy := subscriptions as: OrderedCollection ]. >> self deliver: anAnnouncement to: copy >> >> (private category) >> deliver: anAnnouncement to: subs >> >> subs do: >> [:each | >> [each deliver: anAnnouncement] >> ifCurtailed: [self deliver: anAnnouncement to: (subs after: each)]] >> > > then probably you can do it in right place - in subscription>>deliver: > put ifCurtailed: handler. You don't have access to the remaining subscriptions in the subscription instances. ifCurtailed: sort of means "I'm about to terminate you (well, or do a non-local return, but that's never the case here), wanna do anything first?", so in my mind, the correct answer is the Registry saying "Hold on a bit, let me deliver to the remaining subscribers as well" > >> >> This has the added benefits of: >> - No thread creation overhead (Not sure if how it's written avoids creating a block for argument to each ifCurtailed call though) >> - Reproducibility. >> Especially in the case Stephane gave, if you forking in separate threads, his code would appear to work when stepping in debugger. >> There'd be mucho frustration and grumbling over announcements failing one second, but working the next. :) >> >> Downside is ofc that rest of subscribers won't be notified until you proceed/exit the debugger, but compared to reproducibility, that's a small price to pay imho. >> > > Its really depends on use case, what is preferable behavior. For > instance if you stall in debugger when delivering UI events, then no > new events could be handled and you dead, > so in cases like this you cannot afford to stop handler from > processing events and wait for user intervention. Oh I agree. I'd argue that is the exceptional exception case (:D) where you'd want a specialized announcer rather than the other way around though. :) Prolly just me, but even in this case I'd favor a stacktrace which makes sense over a system which kinda sorta keeps on working when I do something horribly wrong. > Also, i think it would be nice to disable a subscription, so it won't > receive any new announcements if it stopped under debugger, because if > you don't do that, and new announcements are flowing at some constant > rate, then you will have a tons of debugger > windows popping out and no way to stop that :) You'd definitely need an Error handler for that, yeah. It not mutually exclusive with using ifCurtailed: protection though. Cheers, Henry

April 4, 2011

Re: [Pharo-project] [Pharo-users] Last pending things for Pharo 1.2

by Marcus Denker

On Apr 4, 2011, at 5:05 PM, Mariano Martinez Peck wrote: > > > On Sat, Mar 12, 2011 at 8:19 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > So....here is the list of things I guess are pending: > In general, for all pending things adding entries in the bug tracker is the only way ti make sure they are not forgotten. > 1) "Release" all configurations included in Pharo (this is, ConfigurationOfPharo and all it dependencies). I mean, we should NOT use or depend on #development versions. > > so...can someone check this is done? GUillermo and me did it once...but it seems a lot of stuff was updated once again I just gave up and took the image yesterday. Like you did for 1.1: Just build it once, don't care that it is repeatable. > > 2) Update the one click image to use latest cog images and "pharo prepared vms". There are some issues regarding this... > > Marcus, which is the status of this one ? I updated the one-click image with the last cog VM. For the one-click, it is identical to 1.1 with the only change that I put the windows VM I got from Torsten. > > 3) Write down all the things/summary done in Pharo 1.2 > > consider as done in nobody else comes with something better, > > 5) Update SystemVersion current -->> Pharo1.2rc2 of 27 January 2011 update 12340 > > > SystemVersion current ->> Pharo1.2.1 of 2 April 2011 update 12345 > > so..it is ok, isn't it ? can we forget this item ? > > 6) Condense sources? condense changes? #cleanUpForRelease > > Marcus, is that necessary ? > > DEVImageCreator >> cleanUps > > ScriptLoader new cleanUpForRelease. > "In Pharo 1.1 condenseChanges is VERY slow because of the new method trailers. So condensingChanges each time even when it is not needed is not a good idea anymore. So in case a condenseChanges is needed it should be done explicitly. > Smalltalk condenseChanges." > Smalltalk garbageCollect. > > I did that and I put that comment. Now that they are faster and that we have Hudson, should I put back the Smalltalk condenseChanges ? is there anything else needed? do we need a condenseSources ? > CondenseChange and CondenseSource is broken right now. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 4, 2011

Re: [Pharo-project] [ANN 1.2] 1.2.1 Full Release Image

by laurent laffont

On Mon, Apr 4, 2011 at 4:58 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > I started to try to release 1.2. Not only I did the list of changes but > also: > > 1) I asked if people still wanted the background: > http://forum.world.st/Do-you-want-to-add-the-background-picture-to-the-imag… > results: negative. So, no backgrund. White as it is now. > > 2) I asked what people wanted that used to be in 1.1: > http://forum.world.st/Do-we-want-this-for-Pharo-1-2-and-futures-td3350721.h… > guess how many replies? TWO. > results: I would only nclude the installScript. I guess that Hudson could > do that very easy, doesn't it ? marcus ? > > 3) I wrote down the pending lists: > http://forum.world.st/Last-pending-things-for-Pharo-1-2-tp3350731p3350731.h… > > Sorry, I cannot do more. > Thanks Mariano. More and more I think we should do the agile way: timeboxing, let's define a fixed planning for Pharo 1.3 beta, rc, and release dates and release whatever happen - even bugs we know - if the bug is still here it means it's not really annoying. And it could always be fixed in 1.3.1 (which should be planned too). Laurent. > > Cheers > > Mariano > > > On Mon, Apr 4, 2011 at 4:33 PM, laurent laffont <laurent.laffont(a)gmail.com > > wrote: > >> >> On Mon, Apr 4, 2011 at 4:31 PM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: >> >>> >>> On 04 Apr 2011, at 16:19, Marcus Denker wrote: >>> >>> > On Apr 4, 2011, at 4:09 PM, Sven Van Caekenberghe wrote: >>> > >>> >> >>> >> On 04 Apr 2011, at 15:40, StÃ©phane Ducasse wrote: >>> >> >>> >>> Please help because we have not the steam for the splash >>> organization. >>> >> >>> >> So we poor users have to do all the work ?? >>> >> >>> >> Seriously, what is the easiest/fastest way to get to a rough list of >>> the changes between 1.1.1 and 1.2.1 ? >>> >> >>> >> From that list we could try to make a readable list for release notes >>> and then we could try to make a list of bullet points / highlights. >>> >> >>> > >>> > Mariano started a list: >>> > >>> > http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotTwo >>> > >>> > All things done should have a tracker entry: >>> > >>> > http://code.google.com/p/pharo/issues/list?can=1&q=milestone=1.2 >>> > >>> http://code.google.com/p/pharo/issues/list?can=1&q=Milestone%3D1.2-DevImage >>> >>> OK, I will start reading through these lists and compare with what was >>> written about the previous releases and see if I can come up with something >>> by tomorrow. >>> >> >> I will translate for the French announcement. >> >> Laurent. >> >> >> >> >>> >>> Sven >>> >>> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com > >

April 4, 2011

Re: [Pharo-project] Regarding SimpleMorphic

by Henrik Johansen

On Apr 4, 2011, at 1:44 09PM, Benjamin wrote: > > On Apr 1, 2011, at 8:29 PM, csrabak(a)bol.com.br wrote: > >> Em 31/03/2011 18:10, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> escreveu: >> >>> On Mar 31, 2011, at 8:08 PM, csrabak(a)bol.com.br wrote: >>> >>>> Benjamin, >>>> Testing the understanding of the diagram of yours: >>>> Model, Pluggable TextMorph, Pluggable CodeMorph, Browser, Browser >>>> Model, Debugger and Debugger Model all inherit from Object? >>>> the representation of "based on" means that it changes states in >>>> the model counterpart, and "use" means that has some similarity >>>> but not enough to inherit from the other classes? >>> >>> based on means, that the view (on right) is based on the model (on >>> left) >> >> This still tautological: does "based on" means the structure is one-to-one correspondent? >> >> Or are we re-introducing the MVC paradigm and the "based on" means that the View has to know the inners of the Model in order to be built? > > Yes it's MVC, the problem is there is no proper controllers ... > > > Ben "Problem" is a bit harsh of a word. Controllers are great for when you want modal behaviour for an object (like, a canvas in a drawing program responding to mouseclicks differently based on current brush). For typical widgets where behaviour is non--modal, they are mostly, if not entirely, an unnecessary level of indirection. My 2c at least :) Cheers, Henry

April 4, 2011