- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Crash on saving with Monticello

by Alexandre Bergel

>> I found the class UUID and remove the call to the primitive. It works. Strange problem. Shall I report it in codegoogle? > > Has been known for two years, shouldn't happen, nobody cares. One student of mine works with Ubuntu and the last Pharo 1.2 one click image, and he does care. He couldn't do a save in Monticello before I remove the call to the primitive. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 3, 2011

Re: [Pharo-project] Crash on saving with Monticello

by Philippe Marschall

On 01/03/2011 03:25 PM, Alexandre Bergel wrote: > Hi! > > Sorry for the late answer. The student is now in my office and there is indeed a problem. > UUIDPlugin is not present on his harddisk. Maybe built in the VM. > > I found the class UUID and remove the call to the primitive. It works. Strange problem. Shall I report it in codegoogle? Has been known for two years, shouldn't happen, nobody cares. Cheers Philippe

Jan. 3, 2011

Re: [Pharo-project] Crash on saving with Monticello

by Alexandre Bergel

Hi! Sorry for the late answer. The student is now in my office and there is indeed a problem. UUIDPlugin is not present on his harddisk. Maybe built in the VM. I found the class UUID and remove the call to the primitive. It works. Strange problem. Shall I report it in codegoogle? Cheers, Alexandre On 28 Dec 2010, at 10:09, Mariano Martinez Peck wrote: > > > On Tue, Dec 28, 2010 at 2:00 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > Hi! > > Several of my students experience a crash of Pharo when saving with Monticello. They all use linux. I can ask for more detailed description. > Are we the only one to experience this? > > > yes, probably the UUID known problem. Just renaming / removing the plugin may work. > Are they in Ubuntu/debian? > > Please let us know if we should do this for the PharoOneClick image. > > cheers > > mariano > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 3, 2011

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken

by pharo＠googlecode.com

Comment #9 on issue 3436 by step...(a)stack.nl: #copyFrom: is broken http://code.google.com/p/pharo/issues/detail?id=3436 Then the real question is: why do we have copyFrom:to:? To be in collection protocol style, that could be from:to:. It is not reliably derivable from the protocol name if you get a copy or mutate the original.

Jan. 3, 2011

[Pharo-project] [update 1.2] #12292

by StÃ©phane Ducasse

12292 ----- - Issue 3414: CompilerEvaluationTest>>#testEvaluationOfSelfSend fails. Thanks Igor :) - Issue 3503: LongMessageDialogWindow should be resizeable. Thanks Alain Plantec Stef

Jan. 3, 2011

Re: [Pharo-project] fixing deprecation process once for all

by StÃ©phane Ducasse

On Jan 3, 2011, at 9:34 AM, Henrik Johansen wrote: > Sounds good to me, to me there's a missing when/why description though: > Which criterias do we use for when deprecating is warranted? > - # of callers in image required to deprecate planned for removal (0?) > - # of callers / age when considering renaming for clarity (low > number of callers and/or age < X years?) > - new/better API available (always, as long as new place documented?) > > As for the how, since we do have an integration process, would it not > also be desirable with some sort of integration lint tool working on slices? yes now I do not time for that... :( > For deprecations, it could do things like: > - Checking for method removals without corresponding method additions in > a slice aimed at recategorization (happened quite a few times...) YES! > - Deprecations rather than removals of non-private methods This is true that having something more automatic would be good. In fact I would like to have the rbengine available all the time. but even if I said that I did not make any progress on using metacello to manage core/dev.... Stef > > Cheers, > Henry > > Den 01.01.2011 12:35, skrev StÃ©phane Ducasse: >> I took 5 min and wrote down that >> http://code.google.com/p/pharo/wiki/DeprecationProcess >> >> comment if you want. >> >> >

Jan. 3, 2011

Re: [Pharo-project] Issue 3503 in pharo: LongMessageDialogWindow should be resizeable

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3503 by stephane.ducasse: LongMessageDialogWindow should be resizeable http://code.google.com/p/pharo/issues/detail?id=3503 (No comment was entered for this change.)

Jan. 3, 2011

Re: [Pharo-project] Issue 3414 in pharo: CompilerEvaluationTest>>#testEvaluationOfSelfSend fails

by pharo＠googlecode.com

Comment #8 on issue 3414 by stephane.ducasse: CompilerEvaluationTest>>#testEvaluationOfSelfSend fails http://code.google.com/p/pharo/issues/detail?id=3414 in 12292

Jan. 3, 2011

Re: [Pharo-project] fixing deprecation process once for all

by Henrik Johansen

Sounds good to me, to me there's a missing when/why description though: Which criterias do we use for when deprecating is warranted? - # of callers in image required to deprecate planned for removal (0?) - # of callers / age when considering renaming for clarity (low number of callers and/or age < X years?) - new/better API available (always, as long as new place documented?) As for the how, since we do have an integration process, would it not also be desirable with some sort of integration lint tool working on slices? For deprecations, it could do things like: - Checking for method removals without corresponding method additions in a slice aimed at recategorization (happened quite a few times...) - Deprecations rather than removals of non-private methods Cheers, Henry Den 01.01.2011 12:35, skrev StÃ©phane Ducasse: > I took 5 min and wrote down that > http://code.google.com/p/pharo/wiki/DeprecationProcess > > comment if you want. > >

Jan. 3, 2011

Re: [Pharo-project] IRC meeting next Tuesday, January 4, at ...?

by StÃ©phane Ducasse

Thanks for the call adrian. I will be travelling until 16h (it was not planned when I proposed that dat) but there is no problem, Stef On Jan 2, 2011, at 10:34 PM, Adrian Lienhard wrote: > Hi all, > > During the last meeting [1] we decided to do the next one on January 4 but we didn't decide when to start. > > The previous meeting started at 20:00 CET/UTC/GMT+1, which may not be optimal for people in other time zones. If somebody likes to suggest another time, please let us know soon! > > Cheers, > Adrian > > [1] http://pharo-project.org/news?article=irc-meeting-notes

Jan. 3, 2011