- Pharo-users - lists.pharo.org

Re: [Pharo-users] the mystery of dirty package

by Usman Bhatti

On Fri, May 30, 2014 at 1:16 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I do not quite understand. > > If it is an overriden method, the dirtyness should not go away when > looking for changes, no? > +1 > In our case, there are no changes found. > > @Usman: what is the problematic method? > Doru, I didn't try it in moose yet. I'll give it a try later in the afternoon and inform you. > > Doru > > > On Fri, May 30, 2014 at 1:11 PM, Usman Bhatti <usman.bhatti(a)gmail.com> > wrote: > >> Tx for the pointer Thierry. >> >> So, I did a small script (because there were 314 methods) to see number >> of non-class-extension methods with and without loading the dirty marker >> package and I could spot the culprit. >> >> Running this script before and after loading the second package and doing >> a difference on the two sets shows determining the overridden method. >> >> methods := (RPackage organizer packageNamed: packageName) definedClasses >> flatCollect: [:class | class methodDict values]. >> methods := methods select: [:aMethod | aMethod category asString >> includesSubstring: '*']. >> >> >> regards, >> usman >> >> >> >> On Wed, May 28, 2014 at 4:30 PM, Goubier Thierry <thierry.goubier(a)cea.fr> >> wrote: >> >>> Hi Usman, >>> >>> look if the loaded package has overrides on other packages. If yes, it >>> will dirty them, and looking for changes will clean them. >>> >>> Thierry >>> >>> Le 28/05/2014 15:59, Usman Bhatti a Ã©crit : >>> >>> Hi, >>>> >>>> It is second time in a week that I have to analyze a problem related to >>>> a package getting dirty because of loading another package. But when >>>> looking for changes, the first package becomes clean again. >>>> >>>> >>>> One occurrence of the problem can be seen in the latest moose image: >>>> - download the latest image here:https://ci.inria.fr/ >>>> moose/job/moose-5.0/ >>>> - monticello browser -> Collections-Abstract -> changes and the package >>>> becomes clean. >>>> >>>> Any idea how to determine which method(s) from the incoming package >>>> might be causing changes in the loaded package? Or generally, how to go >>>> about correcting this problem? >>>> >>>> usman >>>> >>>> >>> -- >>> Thierry Goubier >>> CEA list >>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>> 91191 Gif sur Yvette Cedex >>> France >>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>> >>> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

May 30, 2014

Re: [Pharo-users] the mystery of dirty package

by Tudor Girba

I do not quite understand. If it is an overriden method, the dirtyness should not go away when looking for changes, no? In our case, there are no changes found. @Usman: what is the problematic method? Doru On Fri, May 30, 2014 at 1:11 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > Tx for the pointer Thierry. > > So, I did a small script (because there were 314 methods) to see number of > non-class-extension methods with and without loading the dirty marker > package and I could spot the culprit. > > Running this script before and after loading the second package and doing > a difference on the two sets shows determining the overridden method. > > methods := (RPackage organizer packageNamed: packageName) definedClasses > flatCollect: [:class | class methodDict values]. > methods := methods select: [:aMethod | aMethod category asString > includesSubstring: '*']. > > > regards, > usman > > > > On Wed, May 28, 2014 at 4:30 PM, Goubier Thierry <thierry.goubier(a)cea.fr> > wrote: > >> Hi Usman, >> >> look if the loaded package has overrides on other packages. If yes, it >> will dirty them, and looking for changes will clean them. >> >> Thierry >> >> Le 28/05/2014 15:59, Usman Bhatti a Ã©crit : >> >> Hi, >>> >>> It is second time in a week that I have to analyze a problem related to >>> a package getting dirty because of loading another package. But when >>> looking for changes, the first package becomes clean again. >>> >>> >>> One occurrence of the problem can be seen in the latest moose image: >>> - download the latest image here:https://ci.inria.fr/ >>> moose/job/moose-5.0/ >>> - monticello browser -> Collections-Abstract -> changes and the package >>> becomes clean. >>> >>> Any idea how to determine which method(s) from the incoming package >>> might be causing changes in the loaded package? Or generally, how to go >>> about correcting this problem? >>> >>> usman >>> >>> >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> >> > -- www.tudorgirba.com "Every thing has its own flow"

May 30, 2014

Re: [Pharo-users] the mystery of dirty package

by Usman Bhatti

Tx for the pointer Thierry. So, I did a small script (because there were 314 methods) to see number of non-class-extension methods with and without loading the dirty marker package and I could spot the culprit. Running this script before and after loading the second package and doing a difference on the two sets shows determining the overridden method. methods := (RPackage organizer packageNamed: packageName) definedClasses flatCollect: [:class | class methodDict values]. methods := methods select: [:aMethod | aMethod category asString includesSubstring: '*']. regards, usman On Wed, May 28, 2014 at 4:30 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Hi Usman, > > look if the loaded package has overrides on other packages. If yes, it > will dirty them, and looking for changes will clean them. > > Thierry > > Le 28/05/2014 15:59, Usman Bhatti a Ã©crit : > > Hi, >> >> It is second time in a week that I have to analyze a problem related to >> a package getting dirty because of loading another package. But when >> looking for changes, the first package becomes clean again. >> >> >> One occurrence of the problem can be seen in the latest moose image: >> - download the latest image here:https://ci.inria.fr/moose/job/moose-5.0/ >> - monticello browser -> Collections-Abstract -> changes and the package >> becomes clean. >> >> Any idea how to determine which method(s) from the incoming package >> might be causing changes in the loaded package? Or generally, how to go >> about correcting this problem? >> >> usman >> >> > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > >

May 30, 2014

Re: [Pharo-users] Accessing DLLs in Smalltalk/V

by kilon alios

"just to make sure that my message isnât misunderstood: I am not blaming Igor for not having written a book about NativeBoost (yet), and I am very thankful that he wrote NativeBoost in the first place. I know how hard it is to maintain a piece of software over an extended period of time. You have to work on a full-time job, earn money, have some remainders of a life etc. Itâs sometimes easier for academics as they may have some more freedom what they work on (but not necessarily so). If Chris Uppal had not written the excellent documentation of JNIPort for Dolphin before I took over maintenance, the JNIPort documentation would be in the same state as the NativeBoost docs. I simply donât have enough spare time for it. " good but I was not replying to you, I was replying to Stephan. "Excellent, thanks in advance! I can help in proof reading, but donât expect too much - see above." I never expect anything from anyone, even when I complain about it ;). I am already porting PBE to Pharo 3 and doing video tutorials on Pharo 3 so my hands are full too. "If it were so easyâ¦ To write NativeBoost docs, you have to understand what you are writing about in the first place, and you have to have a plan - chapter structure, consistent examples, ideally everything explained in the context of a typical problem. The current tutorial in already very good in this respect. But thatâs hard and takes time, and it canât be split up easily among more than three people - which accidentally seems to be the approximate number of knowledgeable NativeBoost experts on this planet who actually could actually do it." yeah its not that easy, that's true, its easier, write a line a day, Your philosophy about well structured documentation is of course ideal but this comes down to Well Structure but little documentation vs loads but messy documentation. Which in that case I pick the second option with my eyes closed. Which you think most people will pick ? Plus most documentation is very messy anyway. I am a lawyer as professional and I deal with messy documentation from day to day basis, its not that I don't hate i, I do, but the alternative of no documentation is simply not an option to me. And if you think about it messy documentation still beats google search hands down. So never underestimate the immense value of messy documentation. The idea that Nativeboost itself is a tricky subject, well sure you need to understand how C works and be able to tolerate all the manual management mess, but I can't say beyond that is that hard. I suspect however that the problem is that not that many people use Nativeboost in the first place. On Fri, May 30, 2014 at 12:40 PM, Joachim Geidel < joachim.geidel(a)onlinehome.de> wrote: > Hi all, > > Am 30.05.2014 um 10:30 schrieb kilon alios <kilon.alios(a)gmail.com>: > > he has not provided documentation for Nativeboost that's true, but he > never left a question unanswered either ;) > > > just to make sure that my message isnât misunderstood: I am not blaming > Igor for not having written a book about NativeBoost (yet), and I am very > thankful that he wrote NativeBoost in the first place. I know how hard it > is to maintain a piece of software over an extended period of time. You > have to work on a full-time job, earn money, have some remainders of a life > etc. Itâs sometimes easier for academics as they may have some more freedom > what they work on (but not necessarily so). If Chris Uppal had not written > the excellent documentation of JNIPort for Dolphin before I took over > maintenance, the JNIPort documentation would be in the same state as the > NativeBoost docs. I simply donât have enough spare time for it. > > > I think I will come around eventually to adding documentation to > Nativeboost. > > > Excellent, thanks in advance! I can help in proof reading, but donât > expect too much - see above. > > Imagine every Pharoer adding 10 lines of documentation every day. Say 100 > people . That's 33 pages per day , 12167 pages per year. Thats 30 books of > the size of PBE per year. An insane amount of documentation. > > > If it were so easyâ¦ To write NativeBoost docs, you have to understand what > you are writing about in the first place, and you have to have a plan - > chapter structure, consistent examples, ideally everything explained in the > context of a typical problem. The current tutorial in already very good in > this respect. But thatâs hard and takes time, and it canât be split up > easily among more than three people - which accidentally seems to be the > approximate number of knowledgeable NativeBoost experts on this planet who > actually could actually do it. > > On Fri, May 30, 2014 at 10:57 AM, stepharo <stepharo(a)free.fr> wrote: > >> Hi joachim >> >> could you spend some time and helping us to write a documentation on >> nativeboost? >> Else it will always stay the same. I cannot systematically try to write >> documentation on things I do not have expertise >> because it is killing me. >> > > Same for me, I am just a NativeBoost amateur, and unfortunately my time > budget is severely limited. I would prefer spending my time on enhancing > JNIPort (callbacks are currently too complicated). But I can help in > proofreading. > > Joachim > >

May 30, 2014

Re: [Pharo-users] MacOS headless but showing up in dock?

by Bernat Romagosa

Installing Alien proved to be quite a challenge... but I managed! Now I got an instance of ObjectiveCAlien that (I think) represents some kind of dock object, but I don't really know what to do with it... Here's what I have: #NSApplication inObjectiveC sharedApplication dockTile What kind of methods does this take? I see ObjectiveCAlien is a proxy, so I can't really browse what messages can I send it. Any hints? Thanks!!! Bernat. 2014-05-27 15:44 GMT+02:00 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com>: > OK! I'll try that! > > You sure deserve some credit in the Snap4Arduino MacOSX version... ;) > > Thanks a lot! > Bernat. > > > 2014-05-27 15:32 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > >> On 27 May 2014, at 10:13, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> >> wrote: >> >> Hi Mariano, >> >> Thanks, I used this method, but my problem is I do need an icon in the >> dock :) >> >> I'm using Pharo as a server, and I'd need the user to be able to stop it >> without any command-line knowledge. >> >> Esteban, I'll try with Alien. I'm curious though, doesn't NativeBoost >> replace Alien now? >> >> >> yes, but the ObjC bridge for NB is not working (yet, and until I found >> time to do it :( ) >> better to use the Alien FFI until then, so you can do something like: >> >> #NSApplication asObjectiveC sharedApplication dockTile â¦ (and etc.) >> >> :) >> >> >> >> Esteban >> >> >> Thanks! >> >> Bernat. >> >> >> 2014-05-27 14:35 GMT+02:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >>> Hi Bernat, >>> >>> About a year ago I did implement that on the Pharo VM (the Pharo's >>> branch of Cog). It was integrated as far as I remember. >>> I copied pasted here the ANN I sent to the mailing list: >>> >>> >>> Hello there, >>> >>> For a long time, Pharaoers and Squakers have been asking for headless support >>> in the Cocoa VMs just as we have with Carbon VMs. Carbon is becoming a >>> legacy framework so people needed this. >>> >>> I wanted to thanks Square [i] International <http://www.square-i.net/> for >>> sponsoring me to implement such a support. Not only have they sponsored the >>> development but they have also agreed to release it under MIT license for >>> the community. This headless support will be included in the official >>> Pharo VM and will be, therefore, accessible to everybody. >>> >>> The project is not yet finished but I do have a demo/prototype that I >>> wanted to share with you so that you can test it and give me feedback. This >>> VM should only work starting at OSX 10.6. >>> >>> *How to use it?* Basically it works this way: to have headless, just >>> edit the Info.plist and set the flag LSBackgroundOnly to 1 (add the key if >>> it is not present): >>> >>> <key>LSBackgroundOnly</key> >>> <true/> >>> >>> When doing this, you don't even need the -headless anymore since, >>> setting LSBackgroundOnly to 1, will cause the same effect (being the flag >>> almost mandatory). If you don't want headless, put it to false or don't >>> even put the key. If you don't set LSBackgroundOnly to 1 but send - >>> headless, the VM will still be headless but you will see a little >>> flash. If this flash bothers you, then set the flag. I am trying to get a >>> way to avoid the "flash" while also avoiding to set LSBackgroundOnly to 1, >>> but I still couldn't find it. Anyway, I think we can live with the current >>> situation. >>> >>> *How to test it?* You should run the image with something like RFB or >>> Seaside or whatever you can and then confirm if it is working even if you >>> areheadless. As a matter of testing, I saved an image with seaside >>> running in the port 5555. You can get both, this Seaside image and the VM >>> withheadless from: https://www.dropbox.com/sh/r7qk49bxywk2xce/6N7-fdyx6V >>> So if you run the VM headless with that image and go to localhost:5555, >>> you should see that Seaside is running. >>> >>> I would appreciate if you can test it. And please let me know in which >>> version of OSX you tried. Of course, the more of you who can test it, the >>> better. Notice that this VM was compiled with LLVM GCC 4.2 and it may have >>> some problems in older OSX versions (but I think it shouldn't). I still >>> couldn't compile a VM with GNU GCC 4.2 as I get a crash :( >>> >>> *Expected results?* In headless mode, anything should be displayed (no >>> window, no menu, no item in the dock and nothing appear when switching >>> apps). When running headfull, everything should be normal. >>> >>> *Where is the code? *The code I have modified to the VM is committed to >>> my own fork of the VM: >>> https://gitorious.org/~marianopeck/cogvm/marianopecks-blessed >>> Once the code is ready, I will do a pull request so that it can be >>> integrated. >>> >>> >>> >>> On Tue, May 27, 2014 at 7:02 AM, Bernat Romagosa < >>> tibabenfortlapalanca(a)gmail.com> wrote: >>> >>>> Hi list, >>>> >>>> is it possible to have Pharo run headless while still showing up in the >>>> dock? >>>> >>>> In the same direction, is it possible to add contextual menu items to >>>> the dock menu? Or for what matters, to the top system menu? >>>> >>>> Thanks! >>>> >>>> -- >>>> Bernat Romagosa. >>>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> >> >> -- >> Bernat Romagosa. >> >> >> > > > -- > Bernat Romagosa. > -- Bernat Romagosa.

May 30, 2014

Re: [Pharo-users] Sending transactional emails from Pharo

by Norbert Hartl

Am 30.05.2014 um 05:19 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com>: > As promised... I tested it, and worked. Thank you again Norbert! > Iâm glad to hear that. > I chose Mandrill over Postmark by two main reasons (other than better > looking UI): > * It doesn't require me to authenticate the from address (which is > unexistant, because it is a no-reply address, and the domain doesn't > even have a MX server). > * It's pretty much free (though this is not a relevant factor ) > Well, it is 12000 emails free per month. > Now about the strategy when sending emails from Pharo... > > Assuming you flag the transactions as "mailSent" or similar. > Mariano is referring to a piece of code Iâve sent him. This one post | mailResponse | participant := self participantWithId: request uri pathSegments second. participant hasEmail ifTrue: [ mailResponse := (MandrillMessage new addRecipient: (MandrillRecipient new email: participant email); html: self emailBody; subject: self subjectLine; fromEmail: ProjectConfiguration fromEmail; fromName: ProjectConfiguration fromName ) send. ]. ((mailResponse first at: 'status') = 'sent') ifTrue: [ self persistence changeStateOf: participant to: #emailSent ] ifFalse: [ self persistence changeStateOf: participant to: #emailFailed ]. self emptyOkResponse > How do you send the emails? > > 1.a. Right after the "transaction" (or other trigger/status) was performed? > 1.b. Right after the transaction, but forking (#fork) the submission > and returning immediately (to avoid waits on the client side) > 2.a With a worker image with a loop and running indefinitely (checking > mails in the database every n minutes) > 2.b. Running a cron job that starts a Pharo image, does his jobs, and quits > > 3. Some real architecture involving some kind of live communication > (sockets, MQ, etc.) between the image where the event was triggered > and the worker image. > > 4. ? > > I was thinking in doing 2. > > Comments suggerences? There are a lot of ways you can do that. From your description I assume you have quite some incoming requests that should return quickly. Furthermore you want to keep exact track of the sent email and react to unexpected cases, right? In my case I donât have these requirements. The request rate is pretty low and there is no effect to the user if a request to my handler takes longer. So I decided to use the synchronous API from Mandrill. So I get back the status immediately and can flag the action as OK or failed. I donât need more because if a message is not delivered from time to time it is no problem. So I guess Iâm in case #1 If your requirements are different Iâd probably wouldnât take the effort to do #2. It gets complicated really quick. If we have another view on the Mandrill API webhooks come to the rescue [1]. In your request handler you send the message asynchronously. The status in the message is âqueuedâ then. If you have the webhooks registered you get called from mandrill whenever the status of a mail send changes. That is probably the best option because no need to poll anything.There is no support for that in the Mandrill API at the moment. But Iâm interested in this as well and could collaborate on that. I think #3 would be really heavy weight for the task. My advize is not to do these kind of things until you really know that you need it. Complexity kills! Norbert P.S.: The code is on smalltalkhub now [2] [1] http://help.mandrill.com/entries/21738186-Introduction-to-Webhooks [2] http://smalltalkhub.com/#!/~NorbertHartl/Mandrill

May 30, 2014

Re: [Pharo-users] Accessing DLLs in Smalltalk/V

by Joachim Geidel

Hi all, Am 30.05.2014 um 10:30 schrieb kilon alios <kilon.alios(a)gmail.com>: > he has not provided documentation for Nativeboost that's true, but he never left a question unanswered either ;) just to make sure that my message isnât misunderstood: I am not blaming Igor for not having written a book about NativeBoost (yet), and I am very thankful that he wrote NativeBoost in the first place. I know how hard it is to maintain a piece of software over an extended period of time. You have to work on a full-time job, earn money, have some remainders of a life etc. Itâs sometimes easier for academics as they may have some more freedom what they work on (but not necessarily so). If Chris Uppal had not written the excellent documentation of JNIPort for Dolphin before I took over maintenance, the JNIPort documentation would be in the same state as the NativeBoost docs. I simply donât have enough spare time for it. > I think I will come around eventually to adding documentation to Nativeboost. Excellent, thanks in advance! I can help in proof reading, but donât expect too much - see above. > Imagine every Pharoer adding 10 lines of documentation every day. Say 100 people . That's 33 pages per day , 12167 pages per year. Thats 30 books of the size of PBE per year. An insane amount of documentation. If it were so easyâ¦ To write NativeBoost docs, you have to understand what you are writing about in the first place, and you have to have a plan - chapter structure, consistent examples, ideally everything explained in the context of a typical problem. The current tutorial in already very good in this respect. But thatâs hard and takes time, and it canât be split up easily among more than three people - which accidentally seems to be the approximate number of knowledgeable NativeBoost experts on this planet who actually could actually do it. > On Fri, May 30, 2014 at 10:57 AM, stepharo <stepharo(a)free.fr> wrote: > Hi joachim > > could you spend some time and helping us to write a documentation on nativeboost? > Else it will always stay the same. I cannot systematically try to write documentation on things I do not have expertise > because it is killing me. Same for me, I am just a NativeBoost amateur, and unfortunately my time budget is severely limited. I would prefer spending my time on enhancing JNIPort (callbacks are currently too complicated). But I can help in proofreading. Joachim

May 30, 2014

Re: [Pharo-users] Accessing DLLs in Smalltalk/V

by kilon alios

he has not provided documentation for Nativeboost that's true, but he never left a question unanswered either ;) I think I will come around eventually to adding documentation to Nativeboost. Imagine every Pharoer adding 10 lines of documentation every day. Say 100 people . That's 33 pages per day , 12167 pages per year. Thats 30 books of the size of PBE per year. An insane amount of documentation. On Fri, May 30, 2014 at 10:57 AM, stepharo <stepharo(a)free.fr> wrote: > Hi joachim > > could you spend some time and helping us to write a documentation on > nativeboost? > Else it will always stay the same. I cannot systematically try to write > documentation on things I do not have expertise > because it is killing me. > > For igor everything is obvious :) but we spent some afternoons improving > the x11 tutorial. > > Stef > > > > On 30/5/14 08:50, Joachim Geidel wrote: > > Hello ClÃ©ment, > > Am 29.05.2014 um 17:23 schrieb ClÃ©ment Bera <bera.clement(a)gmail.com>: > > NativeBoost is clearly the best option because it is the fastest, it is > mostly implemented in the image so you can look at the code and it is by > default in the image. > > FFI from the VM typically manages much better callbacks, so if you plan > to extensively use callbacks you should look at it, by loading the package > of Aliens (It does not rely any more on the old implementation of aliens > but still have the same image side API and library). Alternatively you can > improve NativeBoost so it manages better call back, this is "easy" as it is > mostly implemented in the image. > > > Could you explain why FFI is better at managing callbacks? I have used > NativeBoost or implementing JNIPort, and callbacks were one of the easier > parts of the work I had to do. As far as I know, both FFI and NativeBoost > donât support callbacks from threads other than the thread in which the > Smalltalk code is executed, but thatâs a limitation of both of them. > > As to improving NativeBoost: Thatâs not âeasyâ at all. Some parts of it > are quite cryptic if you are not familiar with x86 assembler code, the > documentation is still sparse, and I am under the impression that there are > some unfinished parts. It is practically impossible to add something to > NativeBoost if you are not Igor, and just want to use it for your own > project as opposed to spending many hours trying to figure out how > NativeBoost works. I was somewhat lucky that I found everything I needed in > the archives of the pharo-dev and pharo-users mailing list., but i wouldnât > call this documentation. > > I explained how to compile and bind a dll with NativeBoost here > (subsection Implementing the FFI calls) : > > http://clementbera.wordpress.com/2013/06/19/optimizing-pharo-to-c-speed-wit… > It is a very basic but very simple example. > > > Yes, this page helped, but as you wrote: basic and simple example - the > more involved stuff remains undocumented. When working on JNIPort, I > struggled with simple things like de-referencing a pointer to a pointer to > a struct etc. - I didnât find documentation for this, and this is a basic > feature in my opinion. > > Best regards, > Joachim Geidel > > Additional examples can be found in the class NBBasicExamples in the > package NativeBoost-Examples. > There are also tests (For example NBFFICallbackTests>>#benchQSort) that > you can look at, they work and show how to use NativeBoost. > > Else there is the chapter in Pharo for the entrerprise. Other people > will give you a link. > > > >

May 30, 2014

Re: [Pharo-users] [ANN] iStoa 14.06

by Tudor Girba

I just tried it this morning, and it works on Mac just fine. It looks quite interesting! Doru On Fri, May 30, 2014 at 9:59 AM, stepharo <stepharo(a)free.fr> wrote: > I have a son of 7 but on mac I will try to ee what I can do. > > > On 29/5/14 10:49, Hilaire Fernandes wrote: > >> Hi, >> >> If you have young kids (around 5-6 years old) and a linux workstation, >> you may want ot give a try to latest iStoa. >> https://launchpad.net/istoa/trunk/14.06 >> >> I translated it in French as well ;) >> >> If interest to translate in other languages (including asian ones) let >> me know. >> >> Hilaire >> >> > > -- www.tudorgirba.com "Every thing has its own flow"

May 30, 2014

Re: [Pharo-users] [ANN] iStoa 14.06

by stepharo

I have a son of 7 but on mac I will try to ee what I can do. On 29/5/14 10:49, Hilaire Fernandes wrote: > Hi, > > If you have young kids (around 5-6 years old) and a linux workstation, > you may want ot give a try to latest iStoa. > https://launchpad.net/istoa/trunk/14.06 > > I translated it in French as well ;) > > If interest to translate in other languages (including asian ones) let > me know. > > Hilaire >

May 30, 2014