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

[Pharo-project] Squeak on iPad

by Torsten Bergmann

Hey, nice to see Squeak running on the iPad: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-June/151285.html 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

June 15, 2010

Re: [Pharo-project] Help menu disappeared [WAS] [ANN] Pharo-1.1-11400-rc1dev10.06.1

by StÃ©phane Ducasse

On Jun 14, 2010, at 10:07 PM, Adrian Lienhard wrote: > OK, Torsten has some good points (like, why not doing it right now rather than later?)! I took the proposal of Torsten from an earlier mail and tweaked it a bit. This shows the complete world menu including sub menus: > > System Browser > Workspace > Test Runner > Monticello Browser > -------------------- > Tools > ... (<-as today) > Windows > Collapse all windows > Expand all windows > Close top window <<<< we could remove that since you can also press the button > Close all debuggers > Send top window to back > Move window onscreen > Delete unchanged windows > System > About... > Settings > -------------- > VM statistics > Start profiling all processes > Start profiling UI > -------------- > Start drawing again > Start stepping again > -------------- > Restore display > Enable halt inspect once > Help > Help Browser > ProfStef Tutorial > Welcome Workspace > ---------------- > Save > Save as... > Save and quit > Quit > > > Note, I inlined the debug menu into System. The reason is that I don't like multiply nested menus and the system menu does not get overly long. Also I deleted "Space left". Maybe other items like "Start stepping again" are also not really useful anymore? Furthermore I moved "Close all debuggers" into the Windows menu. I kept About... in system as I think it has not much to do with Help but more with System. I also changed the labels of some of the items (like Help Browser and ProfStef Tutorial). > > Does that look reasonable? > > Cheers, > Adrian > > On Jun 14, 2010, at 20:45 , StÃ©phane Ducasse wrote: > >> torsten >> >> propose a menu redistribution as laurent did so that we arrive to something better. >> I agree that debug could be in another place than in root. >> >> stef >> _______________________________________________ >> 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] MC breakage in 1.1

by StÃ©phane Ducasse

It would be nice to fix that in a better way. Hernan we integrated your change but now the package stays dirty and if you republish in the repository then you may break the ancestor chain so I do not know what to do. Stef On Jun 15, 2010, at 7:37 AM, Lukas Renggli wrote: >> 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. > > I noticed this problem too. The previous behavior was better, at least > if you knew how to fix you credentials in the debugger. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > 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

[Pharo-project] Help menu disappeared [WAS] [ANN] Pharo-1.1-11400-rc1dev10.06.1

by Torsten Bergmann

>Does that look reasonable? Yes, looks good. >I kept About... in system as I think it has not much to do with Help but >more with System. Tested with a non-Smalltalk person this morning and yes - she expected it under "System". Maybe because I asked "where to find informations about the system"... So +1 from me here too 100 timesRepeat: [ (Message named: 'Thx') sendTo: #Adrian ] Thx T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

June 15, 2010

Re: [Pharo-project] PPFlattenParser fix

by Lukas Renggli

Thank you for the bug fix. I think the problem is somewhere else, though. Directly parsing on a FileStream should normally not happen, parsing is supposed to happen on a PPStream. Actually PetitParser should automatically convert the FileStream to a PPStream using the #asPetitStream convertor prior to parsing. Doesn't that happen in your case? For example the following code works well in my image without your patch and it consumes the complete contents of the file: #any asParser star flatten parse: (FileStream oldFileNamed: 'README') In the method PPFlattenParser>>parseOn: I get an instance of PPStream. Lukas PS: Make sure to call the #parse: method to start the paring (with a stream or string as argument), do not call directly #parseOn: (see the method comment). On 15 June 2010 02:47, Ross Boylan <ross(a)biostat.ucsf.edu> wrote: > The original parseOn: code failed for me with a FileStream in the Pharo > 1.0 image. Â The last line gets the collection of the stream, and this is > nil (or something that didn't work in the invoked method). Â I've > attached a revision that works for me. > > Ross > -- Lukas Renggli www.lukas-renggli.ch

June 15, 2010

Re: [Pharo-project] MC breakage in 1.1

by Lukas Renggli

> 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. I noticed this problem too. The previous behavior was better, at least if you knew how to fix you credentials in the debugger. Lukas -- Lukas Renggli www.lukas-renggli.ch

June 15, 2010

Re: [Pharo-project] PetitParser

by Lukas Renggli

You are right, I recently changed that but forgot to adapt the documentation. Lukas On 15 June 2010 00:33, Ross Boylan <ross(a)biostat.ucsf.edu> wrote: > http://www.lukas-renggli.ch/blog/petitparser-1 says > > The class side of PPPredicateParser provides a lot of other factory > methods that can be used to build more complex terminal parsers. > > The class side is empty. Â Has the material perhaps moved to > PPPredicateObjectParser, which has lots of stuff? > > Ross > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

June 15, 2010

Re: [Pharo-project] Unwind errors: worse in 1.1?

by John Toohey

I'm using Seaside 3.0 and Pharo 1.0 stable. Each time I get a DNU or some such from my app, the debugger fires on a WAIllegaStateException. I then have to click on Full Stack and scroll to where the actual error is. After that (abandon or fix error and proceed), I then get the UnWindException, but I can always abandon that. Happens all the time, regardless of the error. This just appeared with latest Seaside and Pharo 1.0, previous versions always fired the debugger on the point of the error. On Mon, Jun 14, 2010 at 17:14, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > Ok, I'll give it a try. Fortunately, I am not seeing it with every > notifier like in the one image. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Chris Muller > Sent: Monday, June 14, 2010 4:08 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Unwind errors: worse in 1.1? > > I don't know what causees those either, but if you just want to dismiss the > debugger window, try Proceed. > > On Sat, Jun 12, 2010 at 5:11 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > wrote: > > I have long intermittently seen errors with walkbacks titled "Unwind > error during termination." They might be more common in 1.1, and worse, I > am now unable to close the offending notifiers/debuggers. I also tried > "close all debuggers" without success. > > > > Bill > > > > _______________________________________________ > > 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 > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- -JT

June 15, 2010

Re: [Pharo-project] MC breakage in 1.1

by HernÃ¡n Morales Durand

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

June 15, 2010

[Pharo-project] PPFlattenParser fix

by Ross Boylan

The original parseOn: code failed for me with a FileStream in the Pharo 1.0 image. The last line gets the collection of the stream, and this is nil (or something that didn't work in the invoked method). I've attached a revision that works for me. Ross

June 15, 2010