February 2013 - Pharo-dev - lists.pharo.org

[Pharo-project] Problems with SmalltalkHub

by Serge Stinckwich

Hi all, I have some annoying problems with SmalltalkHub. I have made a project inside a team here: http://smalltalkhub.com/#!/~UMMISCO/Kendrick/ Everytime I try to browse on Pharo 1.4 this repository, I have the following errors: ZnHttpSuccessful: 500 Internal Server Error but not for other projects on SmalltalkHub ... Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Feb. 21, 2013

[Pharo-project] [update 2.0] #20561

by Marcus Denker

20561 ----- Issue 7557: Nautilus: halt in a test http://code.google.com/p/pharo/issues/detail?id=7557 Diff information: http://ss3.gemstone.com/ss/Pharo20/Nautilus-MarcusDenker.432.diff

Feb. 21, 2013

Re: [Pharo-project] projects to migrate/test on 2.0

by stephane ducasse

Ok I will add that to my todo. Stef On Feb 21, 2013, at 10:02 AM, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > Hi stef > > here is a list of the project we should validate for 2.0 > > Gofer > spec > project: 'Gofer Core' > with: [ > spec > className: 'ConfigurationOfGofer'; > versionString: '1.0-baseline'; > loads: #('Core'); > file: 'ConfigurationOfGofer'; > repository: 'http://www.squeaksource.com/MetacelloRepository'; > repository: 'http://seaside.gemstone.com/ss/metacello' ]; > > > Prof Stef > spec > className: 'ConfigurationOfProfStef'; > versionString: '1.0-baseline'; > file: 'ConfigurationOfProfStef'; > repository: 'http://www.squeaksource.com/MetacelloRepository'

Feb. 21, 2013

Re: [Pharo-project] spec className?

by stephane ducasse

Feb. 21, 2013

Re: [Pharo-project] A matter with Delays

by Igor Stasenko

On 21 February 2013 12:59, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Nice to know about this Smalltalk session. Didn't knew about that. > > BTW, did a debug it and it froze my image in a BlockClosure>>newProcess > wait for 1 hour and come back :) > Phil > > 2013/2/21 Igor Stasenko <siguctua(a)gmail.com>: >> On 21 February 2013 12:36, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> Yes, I think you are right: the ambiguity is plain wrong, and even then not saving and continuing them sounds reasonable. >>> >>> But what about the inverse: you schedule something that should happen every hour or every day, you save/restart the image and with the new approach these would all run immediately, right ? >>> >> >> well, but in this case, once you will know that all delays is released >> on image restart, you can always check for session change before doing >> any action.. >> for example: >> >> [ >> | session | >> session := Smalltalk session. >> >> 1 hour asDelay wait. >> >> "is session changed?" >> session == Smalltalk session ifFalse: [ "perhaps we should abandon >> the loop here and reload/reinitialize stuff in some higher layers of >> code" ]. >> >> self doSomething. >> >> ] repeat. >> >> >> Why this "perhaps we should abandon the loop here and >> reload/reinitialize stuff in some higher layers of code".. >> because any resident code (like forked process with infinite loop) is >> a common source of nasty problems, >> unreliable behavior and usually hard to debug (especially over >> multiple sessions or when you changing the code which it should run).. >> >> And to my thinking, writing a proper session-aware code is a way to >> go, instead of relying on ambiguous things. >> >>> So not only would you kill delays that are too short (reasonable), but collapse the longer ones. >>> >>> In terms of design: I think the different behaviors should be implemented with different objects. >>> >>> On 21 Feb 2013, at 12:28, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>>> Hi. >>>> >>>> There is one thing which is IMO an over-engineering artifact: >>>> - when system goes down (image shutdown), all currently scheduled >>>> delays are "saved" >>>> and then when image starting up they are rescheduled again to keep >>>> waiting what time is left for delay.. >>>> >>>> But the problem is that it does not takes into account the total time >>>> an image was frozen, and the requirement is quite ambiguous: >>>> >>>> - if you put a process on a delay for 5 minutes, then immediately >>>> save image, and then restart it 10 minutes (or 1 year) after, >>>> should this delay keep waiting for 4 +x seconds which is left? Or >>>> should we consider this delay as utterly expired? >>>> (and as you can see, the answer is different, if we counting time >>>> using real, physical time, or just image uptime). >>>> >>>> And why counting image uptime? Consider use cases, like connection >>>> timeout.. it is all about >>>> real time , right here , right now.. will it matter to get socket >>>> connection timeout error when you restart some image 1 year after? >>>> Please, give me a scenario, which will illustrate that we cannot live >>>> without it and should count image uptime for delays, because i can't >>>> find one. >>>> >>>> If not, then to my opinion, and to simplify all logic inside delay >>>> code, i would go straight and declare following: >>>> - when new image session starts, all delays, no matter for how long >>>> they are scheduled to wait are considered expired (and therefore all >>>> waiting processes >>>> is automatically resumed). >>>> >>>> Because as tried to demonstrate, the meaning of delay which spans over >>>> multiple image sessions is really fuzzy and i would be really >>>> surprised to find a code >>>> which relies on such behavior. >>>> >>>> This change will also can be helpful with terminating all processes >>>> which were put on wait for too long (6304550344559763 milliseconds) by >>>> mistake or such. >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

Feb. 21, 2013

Re: [Pharo-project] A matter with Delays

by Igor Stasenko

On 21 February 2013 12:49, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > I'd second that. > > There are two responsibilities mixed into one, which both currently > use one tool: Delay. > > BTW, Delay could have: > >>>elapsedImageTime >>>elapsedRealWorldTime >>>elapsedSinceImageStartTime > > which are three different things. > do you mean: delay waitImageTime delay waitRealTime delay waitInCurrentSession ? and delay wait is synonym for "delay waitInCurrentSession " > Now, the user of a Delay should be able to specify the intent. > > Is this for managing a timeout? > Is this for managing a repeating task? > ... other use cases ... > > One thing is sure, there are a tad too many Delay instances in the process list. > > Phil > > 2013/2/21 Sven Van Caekenberghe <sven(a)stfx.eu>: >> Yes, I think you are right: the ambiguity is plain wrong, and even then not saving and continuing them sounds reasonable. >> >> But what about the inverse: you schedule something that should happen every hour or every day, you save/restart the image and with the new approach these would all run immediately, right ? >> >> So not only would you kill delays that are too short (reasonable), but collapse the longer ones. >> >> In terms of design: I think the different behaviors should be implemented with different objects. >> >> On 21 Feb 2013, at 12:28, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> Hi. >>> >>> There is one thing which is IMO an over-engineering artifact: >>> - when system goes down (image shutdown), all currently scheduled >>> delays are "saved" >>> and then when image starting up they are rescheduled again to keep >>> waiting what time is left for delay.. >>> >>> But the problem is that it does not takes into account the total time >>> an image was frozen, and the requirement is quite ambiguous: >>> >>> - if you put a process on a delay for 5 minutes, then immediately >>> save image, and then restart it 10 minutes (or 1 year) after, >>> should this delay keep waiting for 4 +x seconds which is left? Or >>> should we consider this delay as utterly expired? >>> (and as you can see, the answer is different, if we counting time >>> using real, physical time, or just image uptime). >>> >>> And why counting image uptime? Consider use cases, like connection >>> timeout.. it is all about >>> real time , right here , right now.. will it matter to get socket >>> connection timeout error when you restart some image 1 year after? >>> Please, give me a scenario, which will illustrate that we cannot live >>> without it and should count image uptime for delays, because i can't >>> find one. >>> >>> If not, then to my opinion, and to simplify all logic inside delay >>> code, i would go straight and declare following: >>> - when new image session starts, all delays, no matter for how long >>> they are scheduled to wait are considered expired (and therefore all >>> waiting processes >>> is automatically resumed). >>> >>> Because as tried to demonstrate, the meaning of delay which spans over >>> multiple image sessions is really fuzzy and i would be really >>> surprised to find a code >>> which relies on such behavior. >>> >>> This change will also can be helpful with terminating all processes >>> which were put on wait for too long (6304550344559763 milliseconds) by >>> mistake or such. >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > -- Best regards, Igor Stasenko.

Feb. 21, 2013

Re: [Pharo-project] A matter with Delays

by phil＠highoctane.be

Nice to know about this Smalltalk session. Didn't knew about that. BTW, did a debug it and it froze my image in a BlockClosure>>newProcess Phil 2013/2/21 Igor Stasenko <siguctua(a)gmail.com>: > On 21 February 2013 12:36, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Yes, I think you are right: the ambiguity is plain wrong, and even then not saving and continuing them sounds reasonable. >> >> But what about the inverse: you schedule something that should happen every hour or every day, you save/restart the image and with the new approach these would all run immediately, right ? >> > > well, but in this case, once you will know that all delays is released > on image restart, you can always check for session change before doing > any action.. > for example: > > [ > | session | > session := Smalltalk session. > > 1 hour asDelay wait. > > "is session changed?" > session == Smalltalk session ifFalse: [ "perhaps we should abandon > the loop here and reload/reinitialize stuff in some higher layers of > code" ]. > > self doSomething. > > ] repeat. > > > Why this "perhaps we should abandon the loop here and > reload/reinitialize stuff in some higher layers of code".. > because any resident code (like forked process with infinite loop) is > a common source of nasty problems, > unreliable behavior and usually hard to debug (especially over > multiple sessions or when you changing the code which it should run).. > > And to my thinking, writing a proper session-aware code is a way to > go, instead of relying on ambiguous things. > >> So not only would you kill delays that are too short (reasonable), but collapse the longer ones. >> >> In terms of design: I think the different behaviors should be implemented with different objects. >> >> On 21 Feb 2013, at 12:28, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> Hi. >>> >>> There is one thing which is IMO an over-engineering artifact: >>> - when system goes down (image shutdown), all currently scheduled >>> delays are "saved" >>> and then when image starting up they are rescheduled again to keep >>> waiting what time is left for delay.. >>> >>> But the problem is that it does not takes into account the total time >>> an image was frozen, and the requirement is quite ambiguous: >>> >>> - if you put a process on a delay for 5 minutes, then immediately >>> save image, and then restart it 10 minutes (or 1 year) after, >>> should this delay keep waiting for 4 +x seconds which is left? Or >>> should we consider this delay as utterly expired? >>> (and as you can see, the answer is different, if we counting time >>> using real, physical time, or just image uptime). >>> >>> And why counting image uptime? Consider use cases, like connection >>> timeout.. it is all about >>> real time , right here , right now.. will it matter to get socket >>> connection timeout error when you restart some image 1 year after? >>> Please, give me a scenario, which will illustrate that we cannot live >>> without it and should count image uptime for delays, because i can't >>> find one. >>> >>> If not, then to my opinion, and to simplify all logic inside delay >>> code, i would go straight and declare following: >>> - when new image session starts, all delays, no matter for how long >>> they are scheduled to wait are considered expired (and therefore all >>> waiting processes >>> is automatically resumed). >>> >>> Because as tried to demonstrate, the meaning of delay which spans over >>> multiple image sessions is really fuzzy and i would be really >>> surprised to find a code >>> which relies on such behavior. >>> >>> This change will also can be helpful with terminating all processes >>> which were put on wait for too long (6304550344559763 milliseconds) by >>> mistake or such. >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > > -- > Best regards, > Igor Stasenko. >

Feb. 21, 2013

Re: [Pharo-project] A matter with Delays

by Igor Stasenko

On 21 February 2013 12:36, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Yes, I think you are right: the ambiguity is plain wrong, and even then not saving and continuing them sounds reasonable. > > But what about the inverse: you schedule something that should happen every hour or every day, you save/restart the image and with the new approach these would all run immediately, right ? > well, but in this case, once you will know that all delays is released on image restart, you can always check for session change before doing any action.. for example: [ | session | session := Smalltalk session. 1 hour asDelay wait. "is session changed?" session == Smalltalk session ifFalse: [ "perhaps we should abandon the loop here and reload/reinitialize stuff in some higher layers of code" ]. self doSomething. ] repeat. Why this "perhaps we should abandon the loop here and reload/reinitialize stuff in some higher layers of code".. because any resident code (like forked process with infinite loop) is a common source of nasty problems, unreliable behavior and usually hard to debug (especially over multiple sessions or when you changing the code which it should run).. And to my thinking, writing a proper session-aware code is a way to go, instead of relying on ambiguous things. > So not only would you kill delays that are too short (reasonable), but collapse the longer ones. > > In terms of design: I think the different behaviors should be implemented with different objects. > > On 21 Feb 2013, at 12:28, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> Hi. >> >> There is one thing which is IMO an over-engineering artifact: >> - when system goes down (image shutdown), all currently scheduled >> delays are "saved" >> and then when image starting up they are rescheduled again to keep >> waiting what time is left for delay.. >> >> But the problem is that it does not takes into account the total time >> an image was frozen, and the requirement is quite ambiguous: >> >> - if you put a process on a delay for 5 minutes, then immediately >> save image, and then restart it 10 minutes (or 1 year) after, >> should this delay keep waiting for 4 +x seconds which is left? Or >> should we consider this delay as utterly expired? >> (and as you can see, the answer is different, if we counting time >> using real, physical time, or just image uptime). >> >> And why counting image uptime? Consider use cases, like connection >> timeout.. it is all about >> real time , right here , right now.. will it matter to get socket >> connection timeout error when you restart some image 1 year after? >> Please, give me a scenario, which will illustrate that we cannot live >> without it and should count image uptime for delays, because i can't >> find one. >> >> If not, then to my opinion, and to simplify all logic inside delay >> code, i would go straight and declare following: >> - when new image session starts, all delays, no matter for how long >> they are scheduled to wait are considered expired (and therefore all >> waiting processes >> is automatically resumed). >> >> Because as tried to demonstrate, the meaning of delay which spans over >> multiple image sessions is really fuzzy and i would be really >> surprised to find a code >> which relies on such behavior. >> >> This change will also can be helpful with terminating all processes >> which were put on wait for too long (6304550344559763 milliseconds) by >> mistake or such. >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Feb. 21, 2013

Re: [Pharo-project] A matter with Delays

by phil＠highoctane.be

I'd second that. There are two responsibilities mixed into one, which both currently use one tool: Delay. BTW, Delay could have: >>elapsedImageTime >>elapsedRealWorldTime >>elapsedSinceImageStartTime which are three different things. Now, the user of a Delay should be able to specify the intent. Is this for managing a timeout? Is this for managing a repeating task? ... other use cases ... One thing is sure, there are a tad too many Delay instances in the process list. Phil 2013/2/21 Sven Van Caekenberghe <sven(a)stfx.eu>: > Yes, I think you are right: the ambiguity is plain wrong, and even then not saving and continuing them sounds reasonable. > > But what about the inverse: you schedule something that should happen every hour or every day, you save/restart the image and with the new approach these would all run immediately, right ? > > So not only would you kill delays that are too short (reasonable), but collapse the longer ones. > > In terms of design: I think the different behaviors should be implemented with different objects. > > On 21 Feb 2013, at 12:28, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> Hi. >> >> There is one thing which is IMO an over-engineering artifact: >> - when system goes down (image shutdown), all currently scheduled >> delays are "saved" >> and then when image starting up they are rescheduled again to keep >> waiting what time is left for delay.. >> >> But the problem is that it does not takes into account the total time >> an image was frozen, and the requirement is quite ambiguous: >> >> - if you put a process on a delay for 5 minutes, then immediately >> save image, and then restart it 10 minutes (or 1 year) after, >> should this delay keep waiting for 4 +x seconds which is left? Or >> should we consider this delay as utterly expired? >> (and as you can see, the answer is different, if we counting time >> using real, physical time, or just image uptime). >> >> And why counting image uptime? Consider use cases, like connection >> timeout.. it is all about >> real time , right here , right now.. will it matter to get socket >> connection timeout error when you restart some image 1 year after? >> Please, give me a scenario, which will illustrate that we cannot live >> without it and should count image uptime for delays, because i can't >> find one. >> >> If not, then to my opinion, and to simplify all logic inside delay >> code, i would go straight and declare following: >> - when new image session starts, all delays, no matter for how long >> they are scheduled to wait are considered expired (and therefore all >> waiting processes >> is automatically resumed). >> >> Because as tried to demonstrate, the meaning of delay which spans over >> multiple image sessions is really fuzzy and i would be really >> surprised to find a code >> which relies on such behavior. >> >> This change will also can be helpful with terminating all processes >> which were put on wait for too long (6304550344559763 milliseconds) by >> mistake or such. >> >> >> -- >> Best regards, >> Igor Stasenko. >> > >

Feb. 21, 2013

[Pharo-project] Fwd: CouchDB and Pharo

by StÃ©phane Ducasse

Begin forwarded message: > From: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: [Pharo-project] CouchDB and Pharo > Date: February 21, 2013 12:41:12 PM GMT+01:00 > To: Jesus Mari Aguirre <jmariaguirre(a)gmail.com> > > > On Feb 21, 2013, at 10:58 AM, Jesus Mari Aguirre <jmariaguirre(a)gmail.com> wrote: > >> Hi Stef! >> I have been working a lot in the CouchDB Jquery plugin and a ConfigurationOfSCouchDB and now I'm working on "Smalltalkize" Mustache templates. My idea is to have the new version for next week and start writing the doc just the day after. > > excellent > You should post that to the list > >> I developed a new "Albums" application with a nice approach. All its code is written in Smalltalk although the whole application runs in client side, it's made using jquery couchdb driver and jquery mobile and covers authentication, open/update/create/delete documents , uploading file attachments and its renderization. It could be nice to guide the text. > > Sweet :) > >> ConfigurationOfSCouchDB has several groups that will allow us to install only what we need, for instance we have: >> "default" "viewserver" "mustache" "jquerycouchdbplugin"... I will detail it in the document we are plaining to write. >> I've learn on ConfigurationOf... with the Metachello Paro 2.0 draft chapter, very good job! Ah! the project is available in smalltalkhub, I pushed an hour agoâ¦ > > Superbe > Let me know when I can read something. > >> >> Thanks for your suggestions >> keep contact >> >> >> 2013/2/1 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >> On Jan 30, 2013, at 6:55 AM, Jesus Mari Aguirre wrote: >> >> > Hi Stef! >> > There are many kind of scenarios between Seaside and CouchDB, Although I'm not a professional developer (This is not my job and it has never been) CouchDBServer was my first serious incursion in Smalltalk since one year ago). >> >> Cool :) >> >> > First of all I would write some clarifications. >> > -CouchDB is not only a NoSQL database, it is also an application server and there are several API for this purpose (evently,mustacheâ¦). >> > -SCouchDBViewServer project has just few thinks in common with Seaside(templates integration and jquery experimental plugin), >> >> When I meant seaside, I wanted to refer to something less javascript or plain html. >> >> > -SCouchDBViewServer cooperates with CouchDB to create Views, Shows and Lists with your data stored in CouchDB. Views are read by any client that has a CouchDB Driver. >> > -Shows and Lists are pure and STATIC HTML and Js rendered by the function(BlockClosure) List using data(determined by the view in its url) passed by couchDB. All of three are cached and won't be refreshed until there were a modification in the related data and a client asked for this data again. >> > -Main goal of the SCouchDDB.application category is creating a âCouchAppâ âlike environment. >> > -Mustache templates are useful in show and lists and this was the main goal when I ported from javascript. >> > -Mustache.seaside contains the WAMustacheTag class allowing Mustache and Seaside interaction. >> > -SCouchDB.jquery is an attempt to integrate the js jquery couchdb driver in seaside-jquery. But I have had no time enough to depurate and learn how seaside tags and jquery work on seaside. >> >> >> Probably that we should explain that in the chapter >> > >> > After all of this very long clarification listâ¦.I would suggest some scenarios: >> > >> > Deployment scenario >> > -SEASIDE DEPLOYMENT WITH COUCHDB. >> > - CouchDB Installation >> > - CouchDB configuration to redirect calls to Seaside. The most difficult is seaside configuration side (paths to access libs,CCSâ¦) >> > - Serving Files with CouchDB.(That could be the hardest workâ¦we can use an app with all files attachedâ¦could be interesting ) >> > -loading SCouchDBViewServer project >> > Persistence scenario >> > -SEASIDE PERSISTENCE WITH COUCHDB >> > -Create a new database.(easyâ¦itâs in my tutorial) >> > - Store/load a data model in CouchDB. (easyâ¦itâs in my tutorial) >> > >> > -SEASIDE USING JQUERY-MOBILE and COUCHDB >> > -If we have the application model in seasideâ¦.it will be a jquery mobile tutorial. >> > - >> > -USING MUSTACHE TEMPLATES ON SEASIDE >> > Very polemicalâ¦There are a lot of discussions about/against this topic. >> > -Loading Mustache project >> > -Using Templates (easy, I have examples) >> > -passing data to the templates. >> > >> > >> > â jesus I think that it would be good to have some configurationOf for Mustache and SCouchâ >> > Yes,itâs true, StÃ©phane, but first of all I have to lean how a configurationOf itâs doneâ¦ I will try to do it >> >> I can help if you want. >> I wrote also a (too) long chapter on it and we are working on tools to help peoplem >> >> > What scenario do you think is more important for you? To me all of them are interesting! >> >> The text does not have to be long but show some key points and kind of hand-ons >> I would say one where we do not have the tutorial of the other guy and minimizing javascript and html >> (I prefer to generate them :). >> >> Now what we can do is you sketch something and send it to the community and we collect feedback and iterate. >> >> We are working on a book that is called Pharo for the entreprise and this would fit perfectly there. >> >> >> > I think I can help you to make an initial version. >> > >> > PS.Sorry for my long long postâ¦ >> >> >> No I love such mails :) >> > >> > JesÃºs. >> > >> > >> > >> > 2013/1/28 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> > Hi guys >> > >> > I would love to have a chapter on couchDB/Mustache/Seaside. I learned also Mustache :) >> > So I contacted jesus and he sent me the source of the tutorial. >> > Now I read it and there is a bit too much js and html to my taste :) >> > >> > So I have several questions: >> > - could we get a chapter on couchDB with less js. >> > >> > - Is there somebody wanted to pair write with me? >> > Because I have time to read and fix and rewrite but not the write the first version. >> > >> > - any other suggestion? >> > >> > - may be get it up to date with the latest JQueryMobile and Pharo >> > >> > jesus I think that it would be good to have some configurationOf for Mustache and SCouch >> > because it will help loading them. >> > >> > Stef >> > >> > > Hi! >> > > >> > > Just noticed your stuff: >> > > >> > > http://vinsicaves.seasidehosting.st/resources/Developing%20Applications%20w… >> > > >> > > http://www.smalltalkhub.com/#!/~jmari/SCouchDBViewServer >> > > >> > > Looks very nice! >> > > >> > > I also wrote a view server implementation a while ago - I remember I did some tricks to make Compiler deal with it properly etc. Can dig it out an email it to you, in that way I am at least sure it didn't go to waste. >> > > >> > > regards, GÃ¶ran >> > > >> > > PS. I moved on to Riak after CouchDB and now I am heavily intrigued by HyperDex and have a binding brewing using NB FFI :) >> > > >> > >> > >> >> >

Feb. 21, 2013