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

Re: [Pharo-project] Pharo 1.1.1 (CogVM) crashes when saving Monticello packages to any repository due to possible bug in primitive UUID generation

by jaayer

---- On Sun, 05 Dec 2010 12:55:17 -0800 Igor Stasenko wrote ---- >On 5 December 2010 20:53, jaayer wrote: >> >> >> I have found that I cannot save any package to any repository (local or Squeaksource) using Pharo 1.1.1 with the CogVM on 64-bit Ubuntu 10.10. After being prompted to describe the changes to the package and then accepting, the entire image just crashes with the stack dump below. I do have the proper IA32-libs installed (to run 32-bit applications on a 64-bit Linux), and everything else seems to work fine, including loading of Monticello packages. >> >> This code: "UUID new primMakeUUID" can produce the crash. Changing UUID>>primMakeUUID to use the non-primitive implementation: >> Â Â Â Â UUIDGenerator default generateBytes: self forVersion: 4. >> stops the crashing. >> > >UUID bug is well known for a long time. >It is plaguing us for 2 years i think. I see, my mistake. I assumed it was new because this is the first time I have ever encountered it on Linux after two years of using Pharo, and there were no recent posts here discussing it (though searching just now, I found a thread concerning Cog and UUID crashes from last October) or related issues in the tracker that I could find. But I feel compelled to stress that the current Pharo 1.1.1 OneClick distribution is shipping with this bug in it, and the previous 1.1 distribution did not. Perhaps this quarrelsome plug-in should be disabled by default, if only on Linux. I would hate for a budding Pharo user to encounter this while going through the exercises in Pharo By Example. >-- >Best regards, >Igor Stasenko AKA sig. > >

Dec. 5, 2010

Re: [Pharo-project] Comments or no integration: a simple choice for you

by Schwab,Wilhelm K

Stef, IMHO, before we take such a stance, we should have a package comment pane and encourage its use. A complex package is probably best documented with a good high-level description and some type of example(s), which can take the form of do-its in a package comment. A package comment could be expected to provide or point to appropriate examples/tests for the package. That solves the problem while allowing for contributors' styles and the "shape" of the code. Something with just a few classes is well-served by class comments; something with many classes presents the would-be reader with a treasure hunt to find the correct class comment. We might also create a #help mechanism so that something like CzAuthor help gathers class and package comments that might exist. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Sunday, December 05, 2010 3:52 PM To: Pharo-project(a)lists.gforge.inria.fr Development Subject: [Pharo-project] Comments or no integration: a simple choice for you Hi guys I decided that I will not integrate any code that is not documented in Pharo. I strongly suggest to remove from Pharo-dev packages whose classes are not commented. I'm not sure that I will look at code or answer question to code that is not commented. We should change our mindset and it seems that we do not care, so we should take radical decisions: less changes, less progress, more comments. And for once I will not bash the past. Smalltalk was always with methods fully documented. We are just plain lazy and this is a shame. Stef

Dec. 5, 2010

Re: [Pharo-project] Comments or no integration: a simple choice for you

by GermÃ¡n Arduino

Yes I agree. Documentation is a key part of any software, without doc, all is more hard and painful. I would add also proper naming of things, and not use criptics things as "el", "dr", etc that certainly don't help with the code understanding. Cheers. 2010/12/5 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi guys > > I decided that I will not integrate any code that is not documented in Pharo. > > I strongly suggest to remove from Pharo-dev packages whose classes are not commented. > I'm not sure that I will look at code or answer question to code that is not commented. > We should change our mindset and it seems that we do not care, so we should take radical decisions: > Â Â Â Â less changes, less progress, more comments. > > And for once I will not bash the past. Smalltalk was always with methods fully documented. > We are just plain lazy and this is a shame. > > Stef >

Dec. 5, 2010

Re: [Pharo-project] Pharo 1.1.1 (CogVM) crashes when saving Monticello packages to any repository due to possible bug in primitive UUID generation

by GermÃ¡n Arduino

Right. First thing I do when download a new version of Cog is rename the UUID plugin :P 2010/12/5 Igor Stasenko <siguctua(a)gmail.com>: > On 5 December 2010 20:53, jaayer <jaayer(a)zoho.com> wrote: >> >> >> I have found that I cannot save any package to any repository (local or Squeaksource) using Pharo 1.1.1 with the CogVM on 64-bit Ubuntu 10.10. After being prompted to describe the changes to the package and then accepting, the entire image just crashes with the stack dump below. I do have the proper IA32-libs installed (to run 32-bit applications on a 64-bit Linux), and everything else seems to work fine, including loading of Monticello packages. >> >> This code: "UUID new primMakeUUID" can produce the crash. Changing UUID>>primMakeUUID to use the non-primitive implementation: >> Â Â Â Â UUIDGenerator default generateBytes: self forVersion: 4. >> stops the crashing. >> > > UUID bug is well known for a long time. > It is plaguing us for 2 years i think. > > -- > Best regards, > Igor Stasenko AKA sig. > >

Dec. 5, 2010

Re: [Pharo-project] Pharo 1.1.1 (CogVM) crashes when saving Monticello packages to any repository due to possible bug in primitive UUID generation

by Igor Stasenko

On 5 December 2010 20:53, jaayer <jaayer(a)zoho.com> wrote: > > > I have found that I cannot save any package to any repository (local or Squeaksource) using Pharo 1.1.1 with the CogVM on 64-bit Ubuntu 10.10. After being prompted to describe the changes to the package and then accepting, the entire image just crashes with the stack dump below. I do have the proper IA32-libs installed (to run 32-bit applications on a 64-bit Linux), and everything else seems to work fine, including loading of Monticello packages. > > This code: "UUID new primMakeUUID" can produce the crash. Changing UUID>>primMakeUUID to use the non-primitive implementation: > Â Â Â Â UUIDGenerator default generateBytes: self forVersion: 4. > stops the crashing. > UUID bug is well known for a long time. It is plaguing us for 2 years i think. -- Best regards, Igor Stasenko AKA sig.

Dec. 5, 2010

[Pharo-project] Comments or no integration: a simple choice for you

by StÃ©phane Ducasse

Hi guys I decided that I will not integrate any code that is not documented in Pharo. I strongly suggest to remove from Pharo-dev packages whose classes are not commented. I'm not sure that I will look at code or answer question to code that is not commented. We should change our mindset and it seems that we do not care, so we should take radical decisions: less changes, less progress, more comments. And for once I will not bash the past. Smalltalk was always with methods fully documented. We are just plain lazy and this is a shame. Stef

Dec. 5, 2010

Re: [Pharo-project] Parsing and navigating Html

by StÃ©phane Ducasse

Hi paul There is not one single class comments :( Do you have an example? I got two tests red, it is normal? I'm sad because this is really not like that, that we will attract people to Smalltalk. Stef On Dec 5, 2010, at 5:19 PM, Paul DeBruicker wrote: > On 12/05/2010 06:02 AM, pharo-project-request(a)lists.gforge.inria.fr wrote: >> From: St?phane Ducasse<stephane.ducasse(a)inria.fr> >> Subject: [Pharo-project] Parsing and navigating Html >> To:"Pharo-project(a)lists.gforge.inria.fr Development" >> <Pharo-project(a)lists.gforge.inria.fr> >> Message-ID:<1C53DFD8-3021-4233-BC83-CE8C1EA8D103(a)inria.fr> >> Content-Type: text/plain; charset=us-ascii >> >> Hi >> >> I would like extract partial information from HTML pages. >> So I started to play and fix HTMLParser. >> >> Now does anybody know alternatives? >> >> Second, does anybody develop a lib to query HTML structure as with the XMLSupport package? >> >> Stef > > > The Soup package on SqueakSource.com works OK. >

Dec. 5, 2010

[Pharo-project] Dictionary responds to #add:, #addAll: but shouldNotImplement #remove: and #remove:ifAbsent

by jaayer

Is anyone else bother by this inconsistency?

Dec. 5, 2010

[Pharo-project] Pharo 1.1.1 (CogVM) crashes when saving Monticello packages to any repository due to possible bug in primitive UUID generation

by jaayer

I have found that I cannot save any package to any repository (local or Squeaksource) using Pharo 1.1.1 with the CogVM on 64-bit Ubuntu 10.10. After being prompted to describe the changes to the package and then accepting, the entire image just crashes with the stack dump below. I do have the proper IA32-libs installed (to run 32-bit applications on a 64-bit Linux), and everything else seems to work fine, including loading of Monticello packages. This code: "UUID new primMakeUUID" can produce the crash. Changing UUID>>primMakeUUID to use the non-primitive implementation: UUIDGenerator default generateBytes: self forVersion: 4. stops the crashing. 0xffdda054 M UUID>initialize -1222112984: a(n) UUID 0xffdda06c M UUID class(Behavior)>new: -1246280952: a(n) UUID class 0xffdda090 I UUID class>new -1246280952: a(n) UUID class 0xffdda0b8 I MCWorkingAncestry>infoWithName:message: -1237212252: a(n) MCWorkingAncestry 0xffdda0e8 I MCWorkingCopy>newVersionWithName:message: -1237214288: a(n) MCWorkingCopy 0xffdda114 I MCWorkingCopy>newVersion -1237214288: a(n) MCWorkingCopy 0xffdda13c I MCWorkingCopyBrowser>saveVersion -1224547984: a(n) MCWorkingCopyBrowser 0xffdda15c I PluggableButtonMorphPlus(PluggableButtonMorph)>performAction -1224524124: a(n) PluggableButtonMorphPlus 0xffdda17c I PluggableButtonMorphPlus>performAction -1224524124: a(n) PluggableButtonMorphPlus 0xffdda198 M [] in PluggableButtonMorphPlus(PluggableButtonMorph)>mouseUp: -1224524124: a(n) PluggableButtonMorphPlus 0xffdda1bc M Array(SequenceableCollection)>do: -1224322708: a(n) Array 0xffdda1e4 I PluggableButtonMorphPlus(PluggableButtonMorph)>mouseUp: -1224524124: a(n) PluggableButtonMorphPlus 0xffdda208 I PluggableButtonMorphPlus>mouseUp: -1224524124: a(n) PluggableButtonMorphPlus 0xffdda224 M PluggableButtonMorphPlus(Morph)>handleMouseUp: -1224524124: a(n) PluggableButtonMorphPlus 0xffdda240 M MouseButtonEvent>sentTo: -1224322748: a(n) MouseButtonEvent 0xffdda25c M PluggableButtonMorphPlus(Morph)>handleEvent: -1224524124: a(n) PluggableButtonMorphPlus 0xffdda278 M PluggableButtonMorphPlus(Morph)>handleFocusEvent: -1224524124: a(n) PluggableButtonMorphPlus 0xffdda2a0 M [] in HandMorph>sendFocusEvent:to:clear: -1245777988: a(n) HandMorph 0xffdda2bc M [] in PasteUpMorph>becomeActiveDuring: -1245489536: a(n) PasteUpMorph 0xffdda2d8 M BlockClosure>on:do: -1224322800: a(n) BlockClosure 0xffdda304 M PasteUpMorph>becomeActiveDuring: -1245489536: a(n) PasteUpMorph 0xffdda328 M HandMorph>sendFocusEvent:to:clear: -1245777988: a(n) HandMorph 0xffdda350 M HandMorph>sendEvent:focus:clear: -1245777988: a(n) HandMorph 0xffdda374 M HandMorph>sendMouseEvent: -1245777988: a(n) HandMorph 0xffdda398 M HandMorph>handleEvent: -1245777988: a(n) HandMorph 0xffdda3c4 M HandMorph>processEvents -1245777988: a(n) HandMorph 0xffdda3dc M [] in WorldState>doOneCycleNowFor: -1244859188: a(n) WorldState 0xffdda400 M Array(SequenceableCollection)>do: -1247208360: a(n) Array 0xffdda41c M WorldState>handsDo: -1244859188: a(n) WorldState 0xffdda438 M WorldState>doOneCycleNowFor: -1244859188: a(n) WorldState 0xffdda454 M WorldState>doOneCycleFor: -1244859188: a(n) WorldState 0xffdda470 M PasteUpMorph>doOneCycle -1245489536: a(n) PasteUpMorph 0xffdda490 I [] in Project class>? -1244779680: a(n) Project class -1245658620 s [] in BlockClosure>? Most recent primitives basicNew basicNew @ @ basicNew @ @ @ basicNew basicNew truncated fractionPart fractionPart truncated fractionPart truncated fractionPart truncated basicNew truncated basicNew truncated fractionPart fractionPart truncated fractionPart truncated fractionPart truncated basicNew truncated perform:with: perform:with: basicNew truncated @ @ @ basicNew @ @ basicNew @ @ primDisplayString:from:to:map:xTable:kern: @ primDisplayString:from:to:map:xTable:kern: @ @ @ @ basicNew @ @ basicNew @ @ primDisplayString:from:to:map:xTable:kern: @ primDisplayString:from:to:map:xTable:kern: @ @ @ @ basicNew @ @ basicNew @ @ primDisplayString:from:to:map:xTable:kern: @ primDisplayString:from:to:map:xTable:kern: @ @ @ @ basicNew @ @ basicNew @ @ primDisplayString:from:to:map:xTable:kern: @ primDisplayString:from:to:map:xTable:kern: @ @ @ @ basicNew @ @ basicNew @ @ primDisplayString:from:to:map:xTable:kern: @ primDisplayString:from:to:map:xTable:kern: @ basicNew @ @ @ basicNew @ perform:with: @ @ perform:with: @ basicNew @ @ basicNew @ copyBits @ @ basicNew at:put: basicNew new: at:put: species basicNew new: species basicNew new: species basicNew new: at:put: at:put: species basicNew new: @ @ basicNew at:put: @ @ basicNew at:put: species species species species species species replaceFrom:to:with:startingAt: at:put: new: at:put: at:put: @ @ basicNew shallowCopy shallowCopy basicNew new: at:put: shallowCopy new: replaceFrom:to:with:startingAt: at:put: shallowCopy basicNew basicNew @ @ basicNew @ perform:with: @ @ perform:with: @ basicNew @ @ basicNew @ perform:with: @ @ perform:with: @ basicNew copyBits @ @ basicNew at:put: @ @ basicNew shallowCopy shallowCopy basicNew new: at:put: shallowCopy new: replaceFrom:to:with:startingAt: at:put: shallowCopy basicNew basicNew @ @ basicNew at:put: @ @ @ basicNew @ perform:with: @ @ perform:with: @ basicNew @ @ basicNew @ copyBits @ @ basicNew at:put: basicNew new: species basicNew new: species basicNew new: at:put: at:put: at:put: primShowRectLeft:right:top:bottom: primShowRectLeft:right:top:bottom: primShowRectLeft:right:top:bottom: primitiveDeferUpdates: forceDisplayUpdate findNextUnwindContextUpTo: terminateTo: basicNew: primMakeUUID Aborted

Dec. 5, 2010

[Pharo-project] Issue 3384 in pharo: include static files in Monticello package

by pharo＠googlecode.com

Status: Accepted Owner: laurent.laffont Labels: Type-RequestForEnhancement New issue 3384 by laurent.laffont: include static files in Monticello package http://code.google.com/p/pharo/issues/detail?id=3384 See: http://forum.world.st/static-files-in-a-MC-package-td3072246.html and: http://lists.squeakfoundation.org/pipermail/beginners/2010-December/007398.… MC 1.5 / 1.6 seems to handle the inclusion of static files in a package, but Pharo uses an older version so it should be upgraded but: The problem is not that we simply ignore what keith did. This is that the implications were not clear and that the code was not simple. So cleaning MC progressively is the only way to be able to later improve it.

Dec. 5, 2010