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

Re: [Pharo-project] AutoStart startUp:

by StÃ©phane Ducasse

Thanks pavel Do you have a cs? Stef On Jun 15, 2010, at 10:21 AM, Pavel Krivanek wrote: > Hi, > > I'm synchronizing changes of the PharoKernel with Pharo 1.2 and I see > that in the method AutoStart class>>startUp: the temp variable > startupParameters is not initialized. Lukas deleted the line > > startupParameters := AbstractLauncher extractParameters. > > it should placed back as: > > startupParameters := SmalltalkImage current extractParameters. > > 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 15, 2010

Re: [Pharo-project] MC breakage in 1.1

by StÃ©phane Ducasse

On Jun 15, 2010, at 9:42 AM, HernÃ¡n Morales Durand wrote: > Why the ancestor chain is broken if the save failed? > > Of course if the fix breaks other parts I agree to revert or reopen > the issue until we find a better solution. because (may be I'm wrong) your cache will contain v+1 and when you will republish v+2 its ancestor v+1 will not be saved on the server so on the server we will get v and v+2 > > What people think about triggering specific exceptions for different > failures? When I saw this issue it seemed to me no trivial to > implement it to my MC knowledge at least. If nobody take it I will > have a look tonight, sorry for the unwanted effects just trying to get > a better Pharo experience. would be nice to have better exception so that we can react adequately > > HernÃ¡n > > 2010/6/15 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> 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 >> >> >> _______________________________________________ >> 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 Lukas Renggli

> What people think about triggering specific exceptions for different > failures? When I saw this issue it seemed to me no trivial to > implement it to my MC knowledge at least. If nobody take it I will > have a look tonight, sorry for the unwanted effects just trying to get > a better Pharo experience. I think it is cool to improve that. The error message is nice, but it should leave Monticello in exactly the same state as it was before the commit. Right now it already commits a version to the cache and leaves the browser in an inconsistent state. To fix this situation it means more work than with the debugger before. Lukas -- Lukas Renggli www.lukas-renggli.ch

June 15, 2010

Re: [Pharo-project] AutoStart startUp:

by Pavel Krivanek

there's another issue in this method. If WorldState is not present, no launcher is called. It should be: (ws := Smalltalk at: #WorldState ifAbsent: [ nil ]) ifNotNil: [ launchers do: [:launcher | ws addDeferredUIMessage: [launcher startUp]] ] ifNil: [ launchers do: [:launcher | launcher startUp]]. -- Pavel On Tue, Jun 15, 2010 at 10:21 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > I'm synchronizing changes of the PharoKernel with Pharo 1.2 and I see > that in the method AutoStart class>>startUp: the temp variable > startupParameters is not initialized. Lukas deleted the line > > startupParameters := AbstractLauncher extractParameters. > > it should placed back as: > > startupParameters := SmalltalkImage current extractParameters. > > Cheers, > -- Pavel >

June 15, 2010

[Pharo-project] AutoStart startUp:

by Pavel Krivanek

Hi, I'm synchronizing changes of the PharoKernel with Pharo 1.2 and I see that in the method AutoStart class>>startUp: the temp variable startupParameters is not initialized. Lukas deleted the line startupParameters := AbstractLauncher extractParameters. it should placed back as: startupParameters := SmalltalkImage current extractParameters. Cheers, -- Pavel

June 15, 2010

Re: [Pharo-project] [SPAM] Fwd: [Pharo-users] [SPAM] Re: WebClient

by Sven Van Caekenberghe

On 14 Jun 2010, at 16:48, StÃ©phane Ducasse wrote: >> I will contact Andreas directly once I know your position on the last remaining item. > > Good I did contact Andreas Raab and he integrated both of my patch sets upstream so that WebClient-Core now load and works on Pharo 1.1rc2 without the need for any Pharo specific patches. Sven

June 15, 2010

[Pharo-project] Alien for 1.1

by Noury Bouraqadi

Hi, I failed to load Alien on 1.1. Then, I went to the googleCode rep and found that the issue was already reported. But, it's tagged for 1.2. Does it mean that we'll have to live without Alien in 1.1? see issues: 1360 ---- Accepted Add Alien in 1.2 Milestone=1.2 difficulty=Important 2452 ---- Accepted recreate special object array Milestone=1.2 difficulty=Important Noury

June 15, 2010

Re: [Pharo-project] MC breakage in 1.1

by HernÃ¡n Morales Durand

Why the ancestor chain is broken if the save failed? Of course if the fix breaks other parts I agree to revert or reopen the issue until we find a better solution. What people think about triggering specific exceptions for different failures? When I saw this issue it seemed to me no trivial to implement it to my MC knowledge at least. If nobody take it I will have a look tonight, sorry for the unwanted effects just trying to get a better Pharo experience. HernÃ¡n 2010/6/15 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > 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 > > > _______________________________________________ > 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

before reverting it could we not have another solution ;) Because indeed I never went inside the debugger to catch the credentials Stef On Jun 15, 2010, at 9:25 AM, HernÃ¡n Morales Durand wrote: > 2010/6/15 Lukas Renggli <renggli(a)gmail.com>: >>> 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. >> > > Ok then revert the change if you like, although the Debugger is > probably the most powerful tool we have I see it as a tool for editing > code, not configurations (I've never heard of anyone going though > Debugger to set credentials in MC) and newbies may perceive a problem > with MC instead of their settings or network problems. > > 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] MC breakage in 1.1

by HernÃ¡n Morales Durand

2010/6/15 Lukas Renggli <renggli(a)gmail.com>: >> 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. > Ok then revert the change if you like, although the Debugger is probably the most powerful tool we have I see it as a tool for editing code, not configurations (I've never heard of anyone going though Debugger to set credentials in MC) and newbies may perceive a problem with MC instead of their settings or network problems. HernÃ¡n

June 15, 2010