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

Re: [Pharo-project] Issue 2560 : Convenient methods from Grease for Strings

by StÃ©phane Ducasse

On Jun 17, 2010, at 3:14 PM, Julian Fitzell wrote: > 2010/6/17 Marcus Denker <marcus.denker(a)inria.fr>: >> >> On Jun 17, 2010, at 12:27 PM, Lukas Renggli wrote: >> >> - If included with Pharo I suggest to rename all the methods, >> otherwise we will run into big troubles with Seaside and other >> projects that depend on Grease. >> >> >> From a philosophical standpoint, I *hate* that. this means that as a >> plattform, we can not >> grow and improve our libraris anymore? >> Shouldn't be the goal that useful extensions gets adopted by the core? > > We will need to find a way to allow platforms to adopt Grease methods > - I do think this is the end goal. It's a bit of a nightmare from our > point of view because we end up having to have different Grease > versions for different versions of the platforms, but isn't that sort > of unavoidable in the long run anyway? because you were planning to have only one grease for all the platform. Ok this was not obvious. > Part of the reason that's so > awful is simply due to the lack of good branching and management tools > in our version control systems... But did you try metacello? Because I thought it was good for that kind of managament Stef >

June 18, 2010

Re: [Pharo-project] Issue 2560 : Convenient methods from Grease for Strings

by StÃ©phane Ducasse

Why you just adapt your package to the version of pharo that includes the changes. We do that all the time so I do not understand where is the problem? >> - If included with Pharo I suggest to rename all the methods, >> otherwise we will run into big troubles with Seaside and other >> projects that depend on Grease. >> >> >> From a philosophical standpoint, I *hate* that. this means that as a >> plattform, we can not >> grow and improve our libraris anymore? >> Shouldn't be the goal that useful extensions gets adopted by the core? > > I agree, from Pharo point of view. However, for any software built on > top of Pharo it means troubles if Pharo suddenly implements the same > methods. > > 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 18, 2010

Re: [Pharo-project] Issue 2560 : Convenient methods from Grease for Strings

by StÃ©phane Ducasse

On Jun 17, 2010, at 12:27 PM, Lukas Renggli wrote: > I've tried to post a message on the bug-tracker, but it seems to have > some troubles at the moment. So I post it here: > > - If included with Pharo I suggest to rename all the methods, > otherwise we will run into big troubles with Seaside and other > projects that depend on Grease. why? you cannot have a Pharo package for grease where these methods are not present? > - If included with Pharo I suggest to also include the tests from Grease-Tests. > > - The #trim protocol is just a subset of various related string > manipulation methods. It is kind of a pity to take that apart. Why not > keep Grease-Core as an externally loadable package? It has no other > dependencies. why not > > Lukas > > On 17 June 2010 11:57, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: >> Hi Adrien, >> >> i think it's much better if you include some tests also. >> >> Regards, >> >> 2010/6/17 Adrien BARREAU <abarreau.dev(a)live.fr>: >>> Hello all, >>> >>> The trim* messages defined in Grease are really useful. >>> I suggest to integrate them in the String class. >>> >>> Take a look: http://code.google.com/p/pharo/issues/detail?id=2560 >>> >>> Adrien. >>> >>> >>> ________________________________ >>> Vous voulez protÃ©ger votre vie privÃ©e ? La solution avec Internet Explorer 8 >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >> Every DSL ends up being Smalltalk >> http://doesnotunderstand.org/ >> >> _______________________________________________ >> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 18, 2010

Re: [Pharo-project] DummyUIManager

by StÃ©phane Ducasse

thanks! On Jun 17, 2010, at 11:36 AM, Pavel Krivanek wrote: > Hi, > > I updated issue http://code.google.com/p/pharo/issues/detail?id=2069 > that adds DummyUIManager and makes Pharo more UIManager independent. > > Please review it, it is an important patch for better modularization. > > For the method fileInSilentlyAnnouncing: it only changes the category. > > Cheers, > -- Pavel > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 18, 2010

[Pharo-project] status of the recreateSpecialArray?

by StÃ©phane Ducasse

so what is the status of this discussion? It would be good that we can load alien in 1.1. David what is the status from VMMaker and the latest VMs? http://code.google.com/p/pharo/issues/detail?id=1360 Stef

June 18, 2010

Re: [Pharo-project] Mac carbon VM goes to 4.2.5beta1U

by StÃ©phane Ducasse

mega neat :) Stef On Jun 16, 2010, at 7:44 PM, Sean P. DeNigris wrote: > > Cool, thanks! > > It took me a little figuring out the last two times I downloaded a new Mac > VM, so I wrote down the steps at http://seandenigris.com/blog/, which boil > down to (in Terminal): > $> ftp -a smalltalkconsulting.com > ftp> binary > ftp> get âSqueak 4.2.5beta1U.app.zipâ > > Sean > -- > View this message in context: http://forum.world.st/Mac-carbon-VM-goes-to-4-2-5beta1U-tp2256763p2257678.h… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 18, 2010

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

by StÃ©phane Ducasse

how did you get an ipad :) On Jun 16, 2010, at 11:33 AM, CÃ©drick BÃ©ler wrote: > I just tested etoys on the ipad (Bert version). For those interested, send me an email. I'll try to get a Pharo version on it too. > > That's already very cool but we need to think about a better way to handle the different events. > We need event like n-fingers, pinch in and out, etc... Also, we need to build specific tools. > > That would be cool to discuss that in Barcelona... > > My 2 cents, > > 2010/6/15 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > CÃ©drick > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 18, 2010

Re: [Pharo-project] ISSUE 2557 : NewTextMorph Refactorings and Tests

by StÃ©phane Ducasse

thanks we will integrate that in 1.2 On Jun 16, 2010, at 1:51 PM, Fernando olivero wrote: > SLICE-Issue-2557-NewTextMorphRefactorings-FernandoOlivero.11 > > > I've published to the inbox several major refactoring s to NewTextMorph and CodeMorph. Added a bunch of tests too. > > The basic idea behind CodeMorph is that an instance of codeMorph holds a target and displays a certain aspect of it. > > For example the first example displays the method source and the second, only the selectorWithArguments, of the same method. > > morph := CodeMorph new. > morph target: ( CodeMorph >> #styler: ). > > morph beCode. > self assert: morph text asString = 'styler: aStyler > styler := aStyler ' . > > morph beSelectorWithArguments. > self assert: morph text asString = 'styler: aStyler'. > > > Lukas, i think now we would be able to easily provide a single line editor for OB, when performing renaming or other selector/arguments or class name refactorings. If you are interested let me now and we can code them together. ( take a look at NewTextMorphTest>>testSelectorWithArguments ). > > > Fernando > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 18, 2010

Re: [Pharo-project] MC breakage in 1.1

by StÃ©phane Ducasse

yes this would be a good alternative. On Jun 16, 2010, at 8:38 AM, HernÃ¡n Morales Durand wrote: > Ok, I have a question, it is really necessary to create and save a > working copy in the default cache when the Save button is pressed and > there are no valid credentials for the selected repository? Why would > you need to save a new version in a cache even though you don't have > permission to save in the repository you have selected in the first > instance? it seems to me the Save button is saving user intentions to > save in the form of new versions in a cache. It isn't supposed MC > should to cache versions which are truly saved?. > > (I did a funny script to confirm, creating 2000 files for free in > local package-cache :) > | repo wc | > repo := MCHttpRepository location: > 'http://www.squeaksource.com/DependencyWalker' user: '' password: ''. > wc := MCWorkingCopy forPackage: (MCPackage named: 'TestSaveMC1'). > 1 to: 2000 do: [ : i | | v | > v := wc newVersionWithName: 'TestSaveMC1-hfm. ' , i asString message: > 'nothing'. > [ repo storeVersion: v ] on: Error do: [: ex | ] ] > > I think #canSave could answer <false> if credentials are invalid for > the selected repository, and then nothing is saved in the cache > presumably avoiding the ancestor/working copy mismatch that Julian has > described. > > Also exploring the MCRepositoryGroup I've noted the useCache instVar > is never disabled. This is another way to go. > > Opinions? > > HernÃ¡n > > 2010/6/15 Julian Fitzell <jfitzell(a)gmail.com>: >> 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 >> >> _______________________________________________ >> 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 18, 2010

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

by Adrian Lienhard

Just a meta remark... In this thread 8 people have sent a total of 30 mails. But in the end nobody volunteers to do the (not very hard) work to make what was discussed actually happen. Was this a bikeshed.com discussion? Maybe not since designing good menus is complex and important. But my point is that we should take care, as a community, to not only invest into discussions but at least as much into *doing*. Cheers, Adrian On Jun 16, 2010, at 08:42 , Adrian Lienhard wrote: > OK, since there seems no opposition lets change it as proposed. > > Any taker? > > Adrian > > On Jun 15, 2010, at 09:17 , StÃ©phane Ducasse wrote: > >> >> 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 >> >> >> _______________________________________________ >> 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 18, 2010