- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Metacello issues on Pharo 2.0

by Dale Henrichs

Stef, I definitely intend to keep supporting Metacello on ALL platforms ... I have not made any public changes to Metacello since the summer (roughly) so in one sense I've been ignoring all platforms equally for a while now ... I am looking forward to porting the Metacello Scripting API work to Pharo2.0, but I have a number of balls in the air at them moment ... >From reading subsequent emails, it sounds as though the bar is a lot lower than it was before ... it sounds like it won't be as big a job to get things running on Pharo2.0 as I anticipated, but I still need to find some time just to get my development environment (FileTree, git/github, travisCI) operational on Pharo2.0 ... Dale ----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: Pharo-project(a)lists.gforge.inria.fr | Cc: metacello(a)googlegroups.com | Sent: Wednesday, February 20, 2013 10:14:33 AM | Subject: Re: [Pharo-project] Metacello issues on Pharo 2.0 | | Dale | | We are investing massively on metacello so now this is important for us to | know if you will continue | to maintain it or not. | Because if this is not the case then we will have to rethink our strategy. | | Stef | | | | > Christophe, | > | > I'm not exactly sure what your problem is ... | > | > I have to admit that I haven't kept up with Pharo2.0 since last summer when | > I couldn't use Pharo2.0 for development because of OsProcess issues. I | > know that recently those issues have been cleared up, but I haven't had | > the time to return to Pharo2.0 and check things out (I'm facing more | > issues with getting PHaro2.0 to work with travis-ci, etc. so it will be a | > big undertaking for me to fully support Pharo2.0). | > | > I've got a fairly recent Pharo2.0 image and it looks like there are | > pharo-specific versions for each of the packages loaded into Pharo2.0. I | > assume that the tests are all passing with those versions, although I | > can't say whether or not the tests had to be modified to pass in Pharo2.0 | > as well ... which is likely to be a source of one of the problems you are | > looking at ... | > | > I don't know where the configuration exists that is being used to manage | > the changes for Pharo2.0 and the tests, but that is probably a good | > starting point ... if you are not using the proper Pharo2.0 configuration, | > you won't be getting the proper packages loaded ... | > | > Dale | > ----- Original Message ----- | > | From: "Christophe Demarey" <Christophe.Demarey(a)inria.fr> | > | To: metacello(a)googlegroups.com | > | Cc: Pharo-project(a)lists.gforge.inria.fr | > | Sent: Friday, February 15, 2013 6:09:27 AM | > | Subject: [Pharo-project] Metacello issues on Pharo 2.0 | > | | > | Hi all, | > | | > | I have issues with Metacello on Pharo 2.0 | > | | > | If I load and run tests for the version used in Pharo1.4, it gives: | > | (ConfigurationOfMetacello project version: '1.0-beta.31.1.4') load: | > | 'Tests' | > | | > | | > | | > | Metacello packages shipped with Pharo 2.0 are all packages derived from | > | the | > | latest stable Metacello baseline (1.0-beta.31.1.5) except the | > | MetacelloToolBox. | > | If I load and run tests packages with version described in the latest | > | stable | > | Metacello baseline (1.0-beta.31.1.5), i.e. : | > | Metacello-TestsCore-DaleHenrichs.14 and | > | Metacello-TestsMC-dkh.351, | > | it gives (Pharo 2.0 #20547): | > | | > | | > | So, it seems there are some problems. Do we use the rigth versions of | > | Metacello packages? | > | | > | Regards, | > | Christophe. | > | | > | | > | | > Chr | > |

Feb. 20, 2013

[Pharo-project] Time Series in Smalltalk

by Serge Stinckwich

Hi all, I'm looking for a time series library available in Smalltalk. Something like Python Time Series Analysis : http://pytseries.sourceforge.net/ or Pandas: http://pandas.pydata.org/ Thank you. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Feb. 20, 2013

Re: [Pharo-project] please test 2.0

by Yanni Chiu

On 19/02/13 12:22 PM, Esteban Lorenzano wrote: > > We are almost there for the release, but we still need a little > effort more. Would be terrific if everyone of you took the latest 2.0 > image and test it with your usual workflows (we cannot imagine all, > they are infinite :) I usually keep a build tracking the upcoming Pharo release, but when I tried to do it during early Pharo-2.0 development, the code was not stable. Then I never got back to it. Here's what happened, when I tried to build with the newest version. First try: "Notice: Your VM is too old for this image. Please download the latest VM." Get latest coglinux, from http://www.mirandabanda.org/files/Cog/VM/ Second try: "Can't infer base LD_LIBRARY_PATH. Aborting. Try adding a line for /lib/i686/cmov/libc.so.6 ..." Patch squeak shell script with a case for "/lib/i686/cmov/libc*" Third try: No complaint about LD_LIBRARY_PATH, but still says "VM is too old ..." Switch to a CogVM (early version of PharoVM) that was lying around. More tries: Can't load Seaside. Update to newer seaside31.st script from https://github.com/renggli/builder/tree/master/scripts Magritte3/Pier3 has deprecations and undefined class. Revert to trying Seaside30. Get: *** Warning: Warning: This package depends on the following classes: BlockContext You must resolve these dependencies before you will be able to load these definitions: renderOn: Go back to trying Magritte3/Pier3 on Seaside31 again. Ignore the deprecations, find: FileSystem-Legacy, at: http://smalltalkhub.com/mc/dh83/fisleg/main Can now load Pier3 into Pharo-20558. Figure out where to get the latest Zinc-Seaside. (Found at http://www.squeaksource.com/ZincHTTPComponents) Start Seaside, go to Pier link, get deprecation warnings about #includesSubString:. Try to disable warnings in System Settings. Still get warnings in webpage. Change to #includesSubString: to not call #deprecated:on:. Now, can see default Pier page. Next step, try to load my custom code...

Feb. 20, 2013

Re: [Pharo-project] Weird behavior in Nautilus when doing a method rename

by phil＠highoctane.be

http://stackoverflow.com/questions/882885/how-do-i-change-a-methods-name-dy… is an interesting read. Phil, now more educated on the matter. 2013/2/20 stephane ducasse <stephane.ducasse(a)free.fr>: > > On Feb 20, 2013, at 1:07 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> > wrote: > > There is actually no simple way to simply rename a method. > We should maybe add one which keep track of the versions :) > > > sure there is: > click on the method > in the text pane change the selector of the method and compile. > > Historically (even if it sounds wrong today) you create a new method, > and delete the old one (and indeed this is disturbing for new comers ^^) > > I really think that both usage are valid even if I think that most of the > time, > you want to do a refactoring while renaming :) > > Let's release Pharo 2.0, and then we will have fun experimenting this ^^ > > Ben > >

Feb. 20, 2013

Re: [Pharo-project] Continuing weirdness with SS3.gemstone.com and Monticello in Pharo 2.0

by phil＠highoctane.be

No, I can't as 2013/2/20 Camillo Bruni <camillobruni(a)gmail.com>: > can you try on the StackVM? > > http://pharo.gforge.inria.fr/ci/vm/stack/ > > so I am convinced it is not a Pharo problem per se, but a nasty issue with > the VM > > > On 2013-02-20, at 22:01, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >> Freeze. I let the image open for more than 3 hours without any change. >> >> Phil >> >> 2013/2/20 stephane ducasse <stephane.ducasse(a)free.fr>: >>> are you sure that this is a freeze and not a timeout on the repository? >>> Because the timeout can take some time. >>> >>> Stef >>> On Feb 19, 2013, at 11:27 PM, phil(a)highoctane.be wrote: >>> >>>> Well, that's what you get from having people using some other kind of >>>> workflow that the usual one you gurus use since years; they do click >>>> on some unforseen button combinations. But frozen it was for sure. >>>> >>>> Anyway, cannot send you any image for testing... it was frozen. >>>> >>>> This makes me wonder: isn't there any way to put a kind of non >>>> maskable kind of interrupt key in the VM that would interrupt its >>>> execution for sure? >>>> >>>> I do encounter a tad too many freezes. Some of them my fault but quite >>>> some others not really. I now understand why one would have a process >>>> saving images with an incrementing number endlessly in the background >>>> to avoid just that now. >>>> >>>> I don't even want to think about life before Monticello ... Yikes! >>>> >>>> Phil >>>> >>>> 2013/2/19 Camillo Bruni <camillobruni(a)gmail.com>: >>>>> this is rather strange. >>>>> We're using gemstone for all pharo development and we haven't had any problems with it. >>>>> >>>>> I loaded all the stuff from your test-repository and it worked. >>>>> more details? ;) >>>>> >>>>> On 2013-02-19, at 22:06, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>>> >>>>>> So, I wanted to merge my stuff from the SS3 project. >>>>>> >>>>>> When loading it needed to have BitBltPen (which I had somewhere as in >>>>>> BitBltPen-MarianoMartinezPeck.4.mcz) >>>>>> >>>>>> I wanted to put that into my SS3 area and so, added the repository to >>>>>> the list of repos in monticello, then took the mcz and then added the >>>>>> repository to the package. >>>>>> >>>>>> Net result: Frozen image. >>>>>> >>>>>> No amount of Cmd-. could do anything. >>>>>> >>>>>> See screenshot. >>>>>> >>>>>> ... now restarting VM... >>>>>> >>>>>> Phil >>>>>> <Capture dâÃ©cran 2013-02-19 Ã 22.01.46.png> >>>>> >>>>> >>>> >>> >>> >> > >

Feb. 20, 2013

Re: [Pharo-project] New Issue Tracker

by phil＠highoctane.be

Fogbugz is cool and for sure more fully featured. But I do meet Jira more often in the field (about 80% of my clients use that thing for better or worse). But if we talk about such things, then let's have a look at Fossil. At least, it is FOSS software. Phil 2013/2/20 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com>: > On Feb 20, 2013, at 8:16 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> thanks christophe :) >> For me this would be ok. > > I still have a preference for fogbugz :) > >> Is there an API for scripting it? > > There is one but not yet implemented in Pharo :) (contrary to FogBugz ^^) > > We ask people from the mailing to express their opinion about it, but so far, so answers :S > > Ben > >> Stef >>> Hi all, >>> >>> I quickly developed a basic importer (Google code => Jira) so that everyone can play a bit with real data. >>> There is still a lot of missing stuff that we can import (ex: labels, author) but I will only do that once we agree on the new bugtracker to choose. >>> >>> So, we have a free Jira instance available at https://pharo-project.atlassian.net/browse/DEMO (there is already a Pharo project but I prefer to not pollute it with tests). >>> Direct acces to issues: https://pharo-project.atlassian.net/issues/?jql=project%20%3D%20DEMO >>> I configured the minimum. We can tune this portal if needed. >>> >>> If you want to play, first register and ask me to become a project member. >>> >>> Cheers, >>> Christophe. >>> >>> Le 12 fÃ©vr. 2013 Ã 14:16, Camillo Bruni a Ã©crit : >>> >>>> After a discussion with Christophe which is in favor of JIRA ;) we decided to put a >>>> wiki page online where we should list all the requirements (not just the ones I think >>>> are important :P) >>>> >>>> https://code.google.com/p/pharo/wiki/NewIssueTracker >>> >> >> > >

Feb. 20, 2013

Re: [Pharo-project] Continuing weirdness with SS3.gemstone.com and Monticello in Pharo 2.0

by Camillo Bruni

can you try on the StackVM? http://pharo.gforge.inria.fr/ci/vm/stack/ so I am convinced it is not a Pharo problem per se, but a nasty issue with the VM On 2013-02-20, at 22:01, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > Freeze. I let the image open for more than 3 hours without any change. > > Phil > > 2013/2/20 stephane ducasse <stephane.ducasse(a)free.fr>: >> are you sure that this is a freeze and not a timeout on the repository? >> Because the timeout can take some time. >> >> Stef >> On Feb 19, 2013, at 11:27 PM, phil(a)highoctane.be wrote: >> >>> Well, that's what you get from having people using some other kind of >>> workflow that the usual one you gurus use since years; they do click >>> on some unforseen button combinations. But frozen it was for sure. >>> >>> Anyway, cannot send you any image for testing... it was frozen. >>> >>> This makes me wonder: isn't there any way to put a kind of non >>> maskable kind of interrupt key in the VM that would interrupt its >>> execution for sure? >>> >>> I do encounter a tad too many freezes. Some of them my fault but quite >>> some others not really. I now understand why one would have a process >>> saving images with an incrementing number endlessly in the background >>> to avoid just that now. >>> >>> I don't even want to think about life before Monticello ... Yikes! >>> >>> Phil >>> >>> 2013/2/19 Camillo Bruni <camillobruni(a)gmail.com>: >>>> this is rather strange. >>>> We're using gemstone for all pharo development and we haven't had any problems with it. >>>> >>>> I loaded all the stuff from your test-repository and it worked. >>>> more details? ;) >>>> >>>> On 2013-02-19, at 22:06, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>> >>>>> So, I wanted to merge my stuff from the SS3 project. >>>>> >>>>> When loading it needed to have BitBltPen (which I had somewhere as in >>>>> BitBltPen-MarianoMartinezPeck.4.mcz) >>>>> >>>>> I wanted to put that into my SS3 area and so, added the repository to >>>>> the list of repos in monticello, then took the mcz and then added the >>>>> repository to the package. >>>>> >>>>> Net result: Frozen image. >>>>> >>>>> No amount of Cmd-. could do anything. >>>>> >>>>> See screenshot. >>>>> >>>>> ... now restarting VM... >>>>> >>>>> Phil >>>>> <Capture dâÃ©cran 2013-02-19 Ã 22.01.46.png> >>>> >>>> >>> >> >> >

Feb. 20, 2013

Re: [Pharo-project] Weird behavior in Nautilus when doing a method rename

by phil＠highoctane.be

This creates another method and leaves the first one in place. 2013/2/20 stephane ducasse <stephane.ducasse(a)free.fr>: > to rename a method without refactoring: just click on the method and in the method pan change its name and recompile > > Stef > > On Feb 20, 2013, at 11:25 AM, phil(a)highoctane.be wrote: > >> Yes, but the rename is *not* in the refactoring menu. It is *below* >> the refactoring menu. >> So, it is an unexpected refactoring in disguise... >> >> There was a simple rename in 1.4 I think. Maybe can we get that one >> back (in 3.0 of course...) >> >> Phil >> >> 2013/2/20 Fernando Olivero <fernando.olivero(a)usi.ch>: >>> Hi, i had the same misconception once, but i recall Lukas pointed out >>> that the refactoring engine is built on the original refactoring's >>> from Fowler's book, and implemented in Smalltalk by Roberts and >>> Johnson [1]. >>> >>> So the semantics of the refactoring are preserved in the implementation. >>> >>> If you just want a method rename, not a method refactoring rename, >>> maybe is best have an option for that in the menu [2]. >>> >>> >>> Fernando >>> >>> [1] http://st-www.cs.illinois.edu/users/droberts/tapos.pdf >>> [2] or use a better widget for editing methods, than a simple code >>> editor within the pane of the browser, as in Gaucho..which i'm working >>> on. >>> >>> On Wed, Feb 20, 2013 at 11:03 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> and you are right, scoped browsing is a very powerful feature that can be tricky to newcomers... but at least now with nautilus it is there, as first option (in OB it was there, but more or less hidden in a submenu)... >>>> It is a small step, but is something... and well... we can improve in next releases, one step at a time :) >>>> >>>> Esteban >>>> >>>> On Feb 20, 2013, at 10:52 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>> >>>>> Yes, thanks, I figured that out. A newcomer wouldn't... and renaming >>>>> is pretty common. >>>>> >>>>> What will happen is that people will remove the method and recreate a new one. >>>>> Version history will then go away. >>>>> >>>>> Or is the system smart enough to find out about these things? >>>>> >>>>> Phil >>>>> >>>>> 2013/2/20 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>>> hi, >>>>>> >>>>>> yes, you are right.. but that is a "nice to have", not a bug... so it will wait to 3.0 :) >>>>>> In the mean time, you can do a scoped rename: you select the packages you want, then right click and "browse scoped", then you apply you rename, and it will apply the refactor in the scoped selection, not all the image. >>>>>> >>>>>> cheers, >>>>>> Esteban >>>>>> >>>>>> On Feb 20, 2013, at 10:21 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>>>> >>>>>>> Well, look at the screenshot then tell me that this is what I want. >>>>>>> >>>>>>> It is definitively *not* what I want. Especially unchecking that >>>>>>> endless list of methods. >>>>>>> >>>>>>> Adding a "Uncheck all" "Check all" button to the Changes Browser list >>>>>>> would help... >>>>>>> >>>>>>> Regards >>>>>>> Phil >>>>>>> >>>>>>> 2013/2/20 Camillo Bruni <camillobruni(a)gmail.com>: >>>>>>>> there is 1 certain bug, that is that you cannot see the changes of the refactoring: >>>>>>>> >>>>>>>> https://code.google.com/p/pharo/issues/detail?id=7547 >>>>>>>> >>>>>>>> the rest I would consider a bug as well. But in the terms of refactoring it might >>>>>>>> be "valid". It does preserve behavior by renaming also all implementors. >>>>>>>> >>>>>>>> How about this reasoning: >>>>>>>> >>>>>>>> Rename method >>>>>>>> => rename all senders (since you refactor) >>>>>>>> => you have to rename all implementors as well since you renamed all send sites >>>>>>>> otherwise you'll run for sure into a DNU >>>>>>>> >>>>>>>> I think I just convinced myself :D >>>>>>>> >>>>>>>> On 2013-02-20, at 09:26, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>>>>>>> I was doing a Refactoring>rename of the initialize method in Nautilus >>>>>>>>> for the ClassMethodBrowser and then the changes browser proposed me to >>>>>>>>> change all classes with initialize. WTF? >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> <PharoScreenshot.3.png> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > >

Feb. 20, 2013

Re: [Pharo-project] Continuing weirdness with SS3.gemstone.com and Monticello in Pharo 2.0

by phil＠highoctane.be

Freeze. I let the image open for more than 3 hours without any change. Phil 2013/2/20 stephane ducasse <stephane.ducasse(a)free.fr>: > are you sure that this is a freeze and not a timeout on the repository? > Because the timeout can take some time. > > Stef > On Feb 19, 2013, at 11:27 PM, phil(a)highoctane.be wrote: > >> Well, that's what you get from having people using some other kind of >> workflow that the usual one you gurus use since years; they do click >> on some unforseen button combinations. But frozen it was for sure. >> >> Anyway, cannot send you any image for testing... it was frozen. >> >> This makes me wonder: isn't there any way to put a kind of non >> maskable kind of interrupt key in the VM that would interrupt its >> execution for sure? >> >> I do encounter a tad too many freezes. Some of them my fault but quite >> some others not really. I now understand why one would have a process >> saving images with an incrementing number endlessly in the background >> to avoid just that now. >> >> I don't even want to think about life before Monticello ... Yikes! >> >> Phil >> >> 2013/2/19 Camillo Bruni <camillobruni(a)gmail.com>: >>> this is rather strange. >>> We're using gemstone for all pharo development and we haven't had any problems with it. >>> >>> I loaded all the stuff from your test-repository and it worked. >>> more details? ;) >>> >>> On 2013-02-19, at 22:06, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>> >>>> So, I wanted to merge my stuff from the SS3 project. >>>> >>>> When loading it needed to have BitBltPen (which I had somewhere as in >>>> BitBltPen-MarianoMartinezPeck.4.mcz) >>>> >>>> I wanted to put that into my SS3 area and so, added the repository to >>>> the list of repos in monticello, then took the mcz and then added the >>>> repository to the package. >>>> >>>> Net result: Frozen image. >>>> >>>> No amount of Cmd-. could do anything. >>>> >>>> See screenshot. >>>> >>>> ... now restarting VM... >>>> >>>> Phil >>>> <Capture dâÃ©cran 2013-02-19 Ã 22.01.46.png> >>> >>> >> > >

Feb. 20, 2013

Re: [Pharo-project] New Issue Tracker

by Benjamin

On Feb 20, 2013, at 8:16 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > thanks christophe :) > For me this would be ok. I still have a preference for fogbugz :) > Is there an API for scripting it? There is one but not yet implemented in Pharo :) (contrary to FogBugz ^^) We ask people from the mailing to express their opinion about it, but so far, so answers :S Ben > Stef >> Hi all, >> >> I quickly developed a basic importer (Google code => Jira) so that everyone can play a bit with real data. >> There is still a lot of missing stuff that we can import (ex: labels, author) but I will only do that once we agree on the new bugtracker to choose. >> >> So, we have a free Jira instance available at https://pharo-project.atlassian.net/browse/DEMO (there is already a Pharo project but I prefer to not pollute it with tests). >> Direct acces to issues: https://pharo-project.atlassian.net/issues/?jql=project%20%3D%20DEMO >> I configured the minimum. We can tune this portal if needed. >> >> If you want to play, first register and ask me to become a project member. >> >> Cheers, >> Christophe. >> >> Le 12 fÃ©vr. 2013 Ã 14:16, Camillo Bruni a Ã©crit : >> >>> After a discussion with Christophe which is in favor of JIRA ;) we decided to put a >>> wiki page online where we should list all the requirements (not just the ones I think >>> are important :P) >>> >>> https://code.google.com/p/pharo/wiki/NewIssueTracker >> > >

Feb. 20, 2013