June 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] [ANN] Metacello 1.0-beta.27

by Dale Henrichs

With the recent rash of SqueakSource/GemSource server downtime, I've bitten the bullet and updated the bootstrap process for Metacello to automatically switch to a secondary repository if the primary repository is not available. I also recommend that if you are maintaining a Metacello configuration that you update the class-side #ensureMetacello method for your configuration to use the primary and secondary repositories for loading the ConfigurationOfMetacello. A new version of the #ensureMetacello method can be found here (I've also updated the config template): http://code.google.com/p/metacello/wiki/EnsureMetacello If you are interested in using redundant repositories in your own Metacello project then you should take a look at this post: http://gemstonesoup.wordpress.com/2010/06/15/metacello-1-0-beta-27-unfurled/ as it describes the steps that you should follow. Dale

June 15, 2010

Re: [Pharo-project] MC breakage in 1.1

by Julian Fitzell

The Copy button allows you to copy the version from your cache to whatever repository you want. I never used the debugger to fix the problem (agreed a debugger is not very nice) but simply went to the MC repository list, edited the repository, and then simply used Copy to put the version where I wanted. I'm not saying this is the greatest behaviour ever, but it at least allowed you to deal with the problem easily when it occurred. If people want to come up with a better behaviour that uses exceptions and so on, feel free; all I'm saying is that as far as I'm concerned the current behaviour is less helpful than the previous behaviour when this (common) error happens. Julian On Tue, Jun 15, 2010 at 2:12 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > Hi Julian, > > 2010/6/15 Julian Fitzell <jfitzell(a)gmail.com>: >> It seems that in Pharo 1.1 MC no longer displays the Version window >> after a failed commit attempt (due to missing authentication for >> example). As a result, cannot easily resubmit the version after fixing >> the credentials. >> > > This is the issue, http://code.google.com/p/pharo/issues/detail?id=2260 > > please reopen if necessary but in the old version the "Version window" > is a pluggable standard window with a MCVersionInspector as model and > > 1) I saw no button to resubmit the version in this Window. The buttons > are : Browse, History, Changes, Load, Merge, Adopt, Copy, Diff > 2) A Debugger window was opened and used as an information dialog even > when there's nothing to Debug (most failure cases are user errors like > missing credentials). The Proceed button was used as Resubmit/Retry > after the credentials were corrected. > > I think a version window should be displayed for a succesful save, not > for every failed save attempt (imagine a script or a UI test which > fails to save hundreds of packages). Actually #storeVersion: should > trigger specific exceptions for every kind of failure so appropiate > handlers could be implemented for different scenarios. > >> In fact, as I look further, it's worse than that. Let's say I had >> version 1 and changed two methods. After the failed commit the >> following seems to be the situation: >> >> - The ancestor of my working copy is 2 instead of 1 (confirmed with History) >> - The working copy is dirty >> - The Changes button shows the same two modified methods that I was >> trying to save into 2 >> - The diff between 1 and 2 shows the two modified methods >> - The diff between 2 and my image (as selected from the History >> window) shows no changes > > This is because "2" should not be created. If a copy cannot be saved > then there is no reason to increment the version number with the > failed attempt. May deserve another issue entry? > > Please comment I would like to read opinions on this. > > HernÃ¡n > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 15, 2010

Re: [Pharo-project] A couple of memory management related questions

by Eliot Miranda

On Tue, Jun 15, 2010 at 2:17 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi All, > > I've started working on a new GC for Cog and have a few questions. > > 1. does anyone have a copy of Joel Bartlett's J. F. Bartlett. A > generational, compacting collector for C++. In E. Jul and N.-C. Juul, > editors, OOPSLA/ECOOP â90 Workshop on Garbage Collection in Object-Oriented > Systems, Oct. 1990. ? > thanks to all 5 of you who've provided this. Ta! > > 2. what's the largest number of classes you've got in your most complex > image and/or what's the largest number of classes you're ever created in an > image? a.k.a. is 64k classes enough (16 bits), or is 1m classes enough (24 > bits)? > > 3. do you have any personal recommendations, or example code, of systems > that combine generation scavenging and/or compaction with object pinning? > > TIA, > Eliot >

June 15, 2010

Re: [Pharo-project] maintaining state during parsing

by Lukas Renggli

> During my parsing (with PetitParser) I'd like to retain some context as > I go. Â A simple example would be the current line number, which gets > incremented at line ends. Â A more complex example would be a current > list of variables. Tokens could easily provide line and column number. They currently don't, but I have done that for a separate project. I think I will merge that with the main code. > I can avoid the whole problem by only retaining state after the parse > tree is constructed, i.e., when I walk the tree. Â Is it just a bad idea > to do anything else? It depends what you want to use it for. > The methods I've thought of, and their drawbacks are > * use a global variable (ugly and requires only one active parse at a > time) Yeah, I wouldn't do that. > * keep the state in the stream I'm parsing with a special stream class > that holds a regular stream and the state (not sure all parsers would > have access to the stream; requires more hacks for parse: to work, as > opposed to parseOn:) That's what I would suggest. The stream is the parser context and you can subclass it to keep other state. The PetitParser GUI does that for example to profile and trace parsers while reading input. If you subclass PPStream you should not need to change #parseOn:. > * make special parser subclasses, each of which refers to the shared > state (lots of work and lots of extra classes; possibly I'd have one > special parser that held the state and an arbitrary real parser) That's another possibility. I wouldn't subclass though (that would lead to an explosion of parsers), but use wrappers instead (like method wrappers but for parsers). For example, you can wrap aParser like this: aParser >=> [ :stream :continuation | before. result := continuation value. after. result ] We've documented some of these (and other) tricks in the DYLA 2010 paper: http://bergel.eu/download/Dyla2010/dyla10_submission_4.pdf Lukas -- Lukas Renggli www.lukas-renggli.ch

June 15, 2010

[Pharo-project] A couple of memory management related questions

by Eliot Miranda

Hi All, I've started working on a new GC for Cog and have a few questions. 1. does anyone have a copy of Joel Bartlett's J. F. Bartlett. A generational, compacting collector for C++. In E. Jul and N.-C. Juul, editors, OOPSLA/ECOOP â90 Workshop on Garbage Collection in Object-Oriented Systems, Oct. 1990. ? 2. what's the largest number of classes you've got in your most complex image and/or what's the largest number of classes you're ever created in an image? a.k.a. is 64k classes enough (16 bits), or is 1m classes enough (24 bits)? 3. do you have any personal recommendations, or example code, of systems that combine generation scavenging and/or compaction with object pinning? TIA, Eliot

June 15, 2010

Re: [Pharo-project] maintaining state during parsing

by Igor Stasenko

On 16 June 2010 00:03, Ross Boylan <ross(a)biostat.ucsf.edu> wrote: > During my parsing (with PetitParser) I'd like to retain some context as > I go. Â A simple example would be the current line number, which gets > incremented at line ends. Â A more complex example would be a current > list of variables. > > I can avoid the whole problem by only retaining state after the parse > tree is constructed, i.e., when I walk the tree. Â Is it just a bad idea > to do anything else? > > The methods I've thought of, and their drawbacks are > * use a global variable (ugly and requires only one active parse at a > time) > * keep the state in the stream I'm parsing with a special stream class > that holds a regular stream and the state (not sure all parsers would > have access to the stream; requires more hacks for parse: to work, as > opposed to parseOn:) > * make special parser subclasses, each of which refers to the shared > state (lots of work and lots of extra classes; possibly I'd have one > special parser that held the state and an arbitrary real parser) > * black magic walking up the call stack (I think Seaside uses this, but > I'd rather avoid black magic). > Many of these approaches might also slow things down, particularly if I > did quick and dirty implementations that used doesNotUnderstand: to do > the delegation for the 2nd and 3rd options. > I am using a parse tokens in own parser, which capturing a token's source range. In similar manner, token could capture a line number(s) as well, or simply reconstruct the line number after tokenization. > Ross Boylan > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

June 15, 2010

[Pharo-project] maintaining state during parsing

by Ross Boylan

During my parsing (with PetitParser) I'd like to retain some context as I go. A simple example would be the current line number, which gets incremented at line ends. A more complex example would be a current list of variables. I can avoid the whole problem by only retaining state after the parse tree is constructed, i.e., when I walk the tree. Is it just a bad idea to do anything else? The methods I've thought of, and their drawbacks are * use a global variable (ugly and requires only one active parse at a time) * keep the state in the stream I'm parsing with a special stream class that holds a regular stream and the state (not sure all parsers would have access to the stream; requires more hacks for parse: to work, as opposed to parseOn:) * make special parser subclasses, each of which refers to the shared state (lots of work and lots of extra classes; possibly I'd have one special parser that held the state and an arbitrary real parser) * black magic walking up the call stack (I think Seaside uses this, but I'd rather avoid black magic). Many of these approaches might also slow things down, particularly if I did quick and dirty implementations that used doesNotUnderstand: to do the delegation for the 2nd and 3rd options. Ross Boylan

June 15, 2010

Re: [Pharo-project] Squeak on iPad (2)

by StÃ©phane Ducasse

What I would do - ask alain for the event hierarchy that he extracted from sophie (because they are better for handling a lot of situation and mike redesign them with mulitouch in mind. - check the new event system that was put in place by mike during the clean he did. Stef On Jun 15, 2010, at 8:14 PM, Fernando olivero wrote: > The model is still there, see for example PasteUpMorph>>addHand: aHandMorph. > > The challenge is creating and triggering the necessary events from the vm. > > This would be excellent to have in Pharo. > > Fernando > > > On Jun 15, 2010, at 5:57 PM, Torsten Bergmann wrote: > >> More here: >> >> http://croquetweak.blogspot.com/2010/06/squeak-etoys-on-ipad.html >> >> "Morphic was designed to handle multiple "hands" (pointing devices) >> from the beginning" >> >> I hope we didnt remove that while cleaning morphic, so Pharo >> could also be made multitouch-aware. >> >> Bye >> T. >> >> -- >> GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. >> Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 15, 2010

Re: [Pharo-project] Autotest, proof-of-concept [was: About TDD and Pharo]

by laurent laffont

Hi Alexandre, I've reorganized Autotest to write tests. The tests now run in a thread with lower priority. Thanks for feedback. Cheers, Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ On Mon, Jun 14, 2010 at 4:52 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > Hi Laurent, > > I tried to program while having AutoTest running. > More importantly than the interface, I experienced some problem with long > executing tests. Basically, these tests should not be executed while I am > programming. Or at least in a thread of a lesser priority. Am I the only one > to experience this? > > Cheers, > Alexandre > > > On 11 Jun 2010, at 09:02, laurent laffont wrote: > > > On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel <alexandre(a)bergel.eu> > wrote: > > Hi Laurent, > > > > I like Autotest. It is true that I always execute the test after > modifying it. > > There are three horizontal panes. Why so? Is it just to open a debugger > when necessary? > > > > I want to be able to open a debugger from autotest. I agree the GUI is > crap now. > > > > > > We could imagine one standalone button instead with a green color to say > the test I just edited is green, and yellow or red when it fails. In that > case, clicking on the button open a debugger. > > > > I just feel the window of autotest takes a lot of space in the screen, > without having a real benefit. > > > > Yes it's true. I'm still thinking on a good GUI. But I'm learning how to > make GUI now :) > > > > If you look at Autotest package, AutotestView is just the GUI, so we can > implement several GUI and see the best solution. I need to take the time to > do it, repository is read / write so feel free to commit :) > > > > What I want to have is a dashboard docked on one side of the screen which > acts like you're driving a car. It's always visible, you have to be able to > look quickly at it as when you check the speed of your car, adjust your > drive, .... > > > > Also another problem with the current version if that if a test fails, > change it and fails again, you don't see it has run (nothing moves in the > GUI). > > > > Finally, another problem is that you see that a test has failed, but you > don't know why (SUnit TestRunner has the same problem). I want to display > the exception message too. > > > > Thanks a lot for feedback. > > > > Laurent Laffont > > > > http://pharocasts.blogspot.com/ > > http://magaloma.blogspot.com/ > > > > > > > > Cheers, > > Alexandre > > > > > > On 3 Jun 2010, at 17:11, laurent laffont wrote: > > > > > Hi, > > > > > > I've written a proof-of-concept for Autotest. Draft/crappy code and no > tests (exploration mode :) but it loads on PharoCore-1.1-11383-beta image. > > > > > > Load it: > > > Gofer new > > > squeaksource: 'Autotest'; > > > package: 'Autotest'; > > > load > > > > > > Open it: > > > AutotestView open > > > (there's en entry in WorldMenu > Tools) > > > > > > And change a tested method to see the results. > > > > > > There's a bug I need to find, maybe someone knows: > > > - Change Bag>>occurrencesOf: > > > - Autotest gives: > > > > > > 284 run, 281 passes, 0 expected failures, 1 failures, 2 errors, 0 > unexpected passes > > > Failures: > > > CollectionRootTest>>#test0FixtureIterateTest > > > > > > Errors: > > > CollectionRootTest>>#testBasicCollect > > > CollectionRootTest>>#testDoWithout > > > > > > but in SUnit CollectionRootTest gives > > > 0 run, 0 passes, 0 expected failures, 0 failures, 0 errors, 0 > unexpected passes ?? > > > > > > > > > Cheers, > > > > > > Laurent Laffont > > > > > > http://pharocasts.blogspot.com/ > > > http://magaloma.blogspot.com/ > > > > > > > > > On Thu, Jun 3, 2010 at 6:09 PM, Alexandre Bergel <alexandre(a)bergel.eu> > wrote: > > > The idea is excellent. > > > > > > Cheers, > > > Alexandre > > > > > > > > > On 3 Jun 2010, at 10:22, laurent laffont wrote: > > > > > > > > > > > > > > > On Thu, Jun 3, 2010 at 3:42 PM, Alexandre Bergel < > alexandre(a)bergel.eu> wrote: > > > > > You may have a lot of noise. > > > > > > > > > > I guess that Ruby uses files as a unit of development/deployment. > The closest Smalltalk/Pharo has is the class and the package. > > > > > > > > > > I would suggest that TestCase which would use this feature use some > pragma/method to identify/declare which classes/packages this test depends > upon. Then the "autotest" framework would register such tests and listen for > changes in the given classes/packages, launching required tests whenever a > change happen. > > > > > > > > > > Additionally, one could declare such a pragma on a single test > method, when this test should be run for a specific class. > > > > > > > > > > Of course, you also to take care of long running tests, which you > probably want to exclude from auto-testing. > > > > > > > > I see autotest in Pharo in a slighly different way: When I press save > in the Monticello browser, I have a popup menu which asks me whether (i) I > want to run all the tests or (ii) only the tests that cover that I changed > from the last version. > > > > > > > > Does this make sense? > > > > > > > > Please no popup :) What I like in ruby autotest is that I can quickly > look at test results if I want (or not) without stop writing. Often you want > to see your tests failing, as you type / save code. I don't have to stop > writing, click a button, wait test results, go again.... testing is done in > background and I just see notifications whether it's OK or not. > > > > > > > > So test log in a Transcript is OK for me. > > > > > > > > > > > > For autotest unit of work is file: it runs the test file which has > the same name as the code file, but you can customize this behavior. For > autotest-rails: > > > > "A simplified version of Autotest heuristics in this mode would be: > > > > When changing a test file, only this file is run (e.g. > test/unit/foo_test.rb âtest/unit/foo_test.rb). > > > > When changing a model file, only associated unit test file is run > (e.g.app/models/foo.rb â test/unit/foo_test.rb). > > > > When changing a controller file, associated functional test file is > run (e.g.app/controllers/foo_controller.rb > âtest/functional/foo_controller_test.rb). > > > > When changing a fixture file, associated unit test and functional > test are run (e.g.app/fixtures/foos.yml â test/unit/foo_test.rb > +test/functional/foo_controller_test.rb). > > > > When changing a helper file, associated functional test file is run > (e.g.app/helpers/foo_helper.rb âtest/functional/foo_controller_test.rb). > > > > When changing application_helper.rb file all functional test files > are run (e.g.application_helper.rb â test/functional/*_test.rb). > > > > When changing a file under the config directory, all tests are run." > > > > > > > > Laurent > > > > > > > > > > > > > > > > Cheers, > > > > Alexandre > > > > -- > > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > > Alexandre Bergel http://www.bergel.eu > > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Pharo-project mailing list > > > > Pharo-project(a)lists.gforge.inria.fr > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > _______________________________________________ > > > > Pharo-project mailing list > > > > Pharo-project(a)lists.gforge.inria.fr > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > Alexandre Bergel http://www.bergel.eu > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 15, 2010

Re: [Pharo-project] Squeak on iPad (2)

by Fernando olivero

The model is still there, see for example PasteUpMorph>>addHand: aHandMorph. The challenge is creating and triggering the necessary events from the vm. This would be excellent to have in Pharo. Fernando On Jun 15, 2010, at 5:57 PM, Torsten Bergmann wrote: > More here: > > http://croquetweak.blogspot.com/2010/06/squeak-etoys-on-ipad.html > > "Morphic was designed to handle multiple "hands" (pointing devices) > from the beginning" > > I hope we didnt remove that while cleaning morphic, so Pharo > could also be made multitouch-aware. > > Bye > T. > > -- > GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. > Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 15, 2010