- Pharo-dev - lists.pharo.org

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

by Philippe Marschall

On 03.01.2011 16:42, David T. Lewis wrote: > On Mon, Jan 03, 2011 at 03:57:07PM +0100, Philippe Marschall wrote: >> 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. >> > > Huh ?!?!? What do you mean "nobody cares"? Nodby cares enough to get to the bottom of it and fix it once and for all. And yes, that includes me. It's just an observation. So if this is really critical for somebody then he'll have to fix it himself. Reporting the same bug again won't make a difference. That's just how open source is. Cheers Philippe

Jan. 3, 2011

Re: [Pharo-project] new Cog VMs

by Philippe Marschall

On 03.01.2011 00:15, Eliot Miranda wrote: > Hi Martin, Hi All, > > so find new VMs in VM.r2341/ > <http://www.mirandabanda.org/files/Cog/VM/VM.r2341/>. The linux crashes > (certainly the one you suffered from Martin) seem to be caused by an > optimization bug (but they could be caused by bad code generation, > creating something that assumes ordering constraints which C doesn't > guarantee). I suspect the former because I don't see the crash when > running exactly the same VM and image from a different directory; > provoking the crash requires a particular path (go figure; I haven't > pinned this down yet). > > So my "fix" is preventing a complex function being inlined into the main > interpreter loop, removing the sources of some warnings, and lowering > the optimization level of the gcc3x-cointerp.c file to -O1 from -O2 (my > build environment, CentOS Linux 5.3, uses gcc 4.1.2). I'm not proud of > this "fix". I've violated the Deutsch criterion by not diagnosing the > cause of the bug so I can't stand behind this fix; it's a hack that > appears to work and may have merely pushed the real bug further > underground. Alas I don't have time to do a better job. Hopefully it'll > get those of you on linux going again. That fixes my Linux crash issues. Cheers Philippe

Jan. 3, 2011

Re: [Pharo-project] new Cog VMs

by Eliot Miranda

The MethodContext>>numArgs is I guess to be expected because there's no implementation so far. Find attached. 'From Pharo-1.1.1-- of 12 September 2010 [Latest update: #11414] on 2 January 2011 at 2:23:32 pm'! !MethodContext methodsFor: 'accessing' stamp: 'eem 1/2/2011 14:23'! numArgs "Answer the number of arguments required to evaluate this method or block." ^closureOrNil ifNil: [method numArgs] ifNotNil: [closureOrNil numArgs]! ! On Sun, Jan 2, 2011 at 2:49 AM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > Hi Eliot. Running: > > - Mac OS > - VM r2340 > - PharoCore 1.2 12288 > > Running all tests I got this DNU. > It is reproducable running the test testClosureRestart which seems to > pass well in previous VMs. > > Cheers > > Mariano > > THERE_BE_DRAGONS_HERE > MessageNotUnderstood: MethodContext>>numArgs > 2 January 2011 11:38:31 am > > VM: Mac OS - intel - 1065 - Croquet Closure Cog VM [CoInterpreter > VMMaker-oscog.41] Croquet Cog 3.0.0 > Image: Pharo1.2beta [Latest update: #12288] > > SecurityManager state: > Restricted: false > FileAccess: true > SocketAccess: true > Working Dir /Users/mariano/Pharo/imagenes/PharoCore-1.2beta-12283 > Trusted Dir /foobar/tooBar/forSqueak/bogus/ > Untrusted Dir /Users/mariano/Library/Preferences/Croquet/Internet/Untrusted > > MethodContext(Object)>>doesNotUnderstand: #numArgs > Receiver: [| b | > self assert: 10 == a. > self assert: nil == b. > b := a + 20. > firstTimeThrough > ifT...etc... > Arguments and temporary variables: > t1: numArgs > t2: nil > t3: nil > Receiver's instance variables: > sender: nil > pc: nil > stackp: 3 > method: (MethodContextTest>>#privRestartBlockTest "a > CompiledMethod(700186624)"...etc... > closureOrNil: [| b | > self assert: 10 == a. > self assert: nil == b. > b := a + 20...etc... > receiver: MethodContextTest>>#testClosureRestart > > > > --- The full stack --- > MethodContext(Object)>>doesNotUnderstand: #numArgs > ------------------------------------------------------------ > > > > > On Sun, Jan 2, 2011 at 8:52 AM, Philippe Marschall <kustos(a)gmx.net> wrote: > >> On 01.01.2011 21:38, Eliot Miranda wrote: >> > Hi All, >> > >> > there are new versions of both the SimpleStackBasedCogit and the >> > StackToRegisterMappingCogit Cog VMs in VM.r2337/ >> > <http://www.mirandabanda.org/files/Cog/VM/VM.r2337/> & VM.r2338/ >> > <http://www.mirandabanda.org/files/Cog/VM/VM.r2338/> respectively. >> > These contain fixes for another bad pc mapping bug that could cause >> > hard crashes when jitting on a backward branch in a looping interpreted >> > method. If you're trying to reproduce Cog crashes please upgrade to one >> > of tthese two VMs. >> > >> > TIA >> > and happy new 2011, P.S. according to an FBF >> > RT @dpp RT @giuliodeluise 2011 is a prime number & the sum of 11 >> > consecutive prime numbers: >> 2011=157+163+167+173+179+181+191+193+197+199+211 >> >> Crashes right at start up: >> >> Segmentation fault >> >> >> >> Smalltalk stack dump: >> 0xff8aafb4 M Error class(Exception class)>handles: -1246542340: a(n) >> Error class >> 0xff8aafdc M MethodContext(ContextPart)>handleSignal: -1220670568: a(n) >> MethodContext >> 0xff8aaffc M MethodContext(ContextPart)>handleSignal: -1216945468: a(n) >> MethodContext >> 0xff8ab020 I UnhandledError(Exception)>signal -1216945236: a(n) >> UnhandledError >> 0xff8ab040 I UnhandledError class>signalForException: -1246541380: a(n) >> UnhandledError class >> 0xff8ab064 I MessageNotUnderstood(Error)>defaultAction -1216945688: a(n) >> MessageNotUnderstood >> 0xff8ab084 I MessageNotUnderstood>defaultAction -1216945688: a(n) >> MessageNotUnderstood >> 0xff8ab0a8 I UndefinedObject>handleSignal: -1247481852: a(n) >> UndefinedObject >> 0xff8ab0cc I MessageNotUnderstood(Exception)>pass -1216945688: a(n) >> MessageNotUnderstood >> 0xff8ab0f8 I [] in PasteUpMorph>becomeActiveDuring: -1245846436: a(n) >> PasteUpMorph >> 0xff8ab11c I BlockClosure>valueWithPossibleArgs: -1221000224: a(n) >> BlockClosure >> 0xff8ab13c M [] in MethodContext(ContextPart)>handleSignal: -1220670568: >> a(n) MethodContext >> 0xff8ab15c M BlockClosure>ensure: -1216945284: a(n) BlockClosure >> 0xff8ab17c M MethodContext(ContextPart)>handleSignal: -1220670568: a(n) >> MethodContext >> 0xff8ab1a4 I MethodContext(ContextPart)>handleSignal: -1216945468: a(n) >> MethodContext >> 0xff8ab1c8 I MessageNotUnderstood(Exception)>signal -1216945688: a(n) >> MessageNotUnderstood >> 0xff8ab1f0 I ProcessorScheduler(Object)>doesNotUnderstand: >= >> -1247476532: a(n) ProcessorScheduler >> 0xff8ab210 M Process>priority: -1216945752: a(n) Process >> 0xff8ab238 I BlockClosure>forkAt: -1216945972: a(n) BlockClosure >> 0xff8ab25c I >> InputEventPollingFetcher(InputEventFetcher)>installEventLoop >> -1246030580: a(n) InputEventPollingFetcher >> 0xff8ab280 I InputEventPollingFetcher(InputEventFetcher)>startUp >> -1246030580: a(n) InputEventPollingFetcher >> 0xff8ab2a0 I InputEventFetcher class>startUp -1246046280: a(n) >> InputEventFetcher class >> 0xff8ab2b8 M InputEventFetcher class(Behavior)>startUp: -1246046280: >> a(n) InputEventFetcher class >> 0xff8ab2e0 M [] in SmalltalkImage>send:toClassesNamedIn:with: >> -1242015264: a(n) SmalltalkImage >> 0xff8ab2fc M BlockClosure>on:do: -1216946688: a(n) BlockClosure >> 0xff8ab32c M [] in SmalltalkImage>send:toClassesNamedIn:with: >> -1242015264: a(n) SmalltalkImage >> 0xff8ab354 I OrderedCollection>do: -1241999736: a(n) OrderedCollection >> 0xff8ab37c I SmalltalkImage>send:toClassesNamedIn:with: -1242015264: >> a(n) SmalltalkImage >> 0xff8ab3a8 I SmalltalkImage>processStartUpList: -1242015264: a(n) >> SmalltalkImage >> 0xff8ab3d4 I SmalltalkImage>snapshot:andQuit:embedded: -1242015264: a(n) >> SmalltalkImage >> -1220672224 s SmalltalkImage>snapshot:andQuit: >> -1220672132 s WorldState class>saveAndQuit >> -1220672040 s [] in ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent: >> -1220671948 s BlockClosure>ensure: >> -1220999860 s CursorWithMask(Cursor)>showWhile: >> -1220999972 s ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent: >> -1220671856 s ToggleMenuItemMorph(MenuItemMorph)>mouseUp: >> -1220671764 s ToggleMenuItemMorph(MenuItemMorph)>handleMouseUp: >> -1220671672 s MouseButtonEvent>sentTo: >> -1220671580 s ToggleMenuItemMorph(Morph)>handleEvent: >> -1220671488 s MorphicEventDispatcher>dispatchDefault:with: >> -1220671396 s MorphicEventDispatcher>dispatchEvent:with: >> -1220671304 s ToggleMenuItemMorph(Morph)>processEvent:using: >> -1220671212 s MorphicEventDispatcher>dispatchDefault:with: >> -1220671120 s MorphicEventDispatcher>dispatchEvent:with: >> -1220671028 s MenuMorph(Morph)>processEvent:using: >> -1220670936 s MenuMorph(Morph)>processEvent: >> -1220670844 s MenuMorph>handleFocusEvent: >> -1220670752 s [] in HandMorph>sendFocusEvent:to:clear: >> -1220670660 s [] in PasteUpMorph>becomeActiveDuring: >> -1220670568 s BlockClosure>on:do: >> -1221000336 s PasteUpMorph>becomeActiveDuring: >> -1221000456 s HandMorph>sendFocusEvent:to:clear: >> -1220670476 s HandMorph>sendEvent:focus:clear: >> -1221000572 s HandMorph>sendMouseEvent: >> -1221000664 s HandMorph>handleEvent: >> -1220670384 s HandMorph>processEvents >> -1220670292 s [] in WorldState>doOneCycleNowFor: >> -1220670200 s Array(SequenceableCollection)>do: >> -1220670108 s WorldState>handsDo: >> -1221001008 s WorldState>doOneCycleNowFor: >> -1220670016 s WorldState>doOneCycleFor: >> -1220669924 s PasteUpMorph>doOneCycle >> -1221589100 s [] in Project class>spawnNewProcess >> -1221602884 s [] in BlockClosure>newProcess >> >> Most recent primitives >> basicNew >> size >> at: >> basicNew: >> decompress:fromByteArray:at: >> beCursorWithMask: >> vmParameterAt:put: >> vmParameterAt:put: >> setGCBiasToGrowGCLimit: >> setGCBiasToGrow: >> ensure: >> valueNoContextSwitch >> wait >> value >> specialObjectsArray >> new: >> at:put: >> value >> signal >> basicNew >> new: >> at: >> value: >> basicIdentityHash >> on:do: >> value >> perform:with: >> millisecondClockValue >> signal >> value: >> size >> size >> bitShift: >> \\ >> \\ >> \\ >> \\ >> \\ >> perform:with: >> shallowCopy >> subclasses >> new: >> new: >> new: >> // >> value: >> value: >> value: >> = >> = >> value: >> value: >> at:put: >> value: >> at:put: >> addAll: >> - >> + >> + >> + >> size >> at: >> do: >> do: >> value: >> getSystemAttribute: >> compare:with:collated: >> value: >> value: >> platformName >> = >> = >> value: >> value: >> getSystemAttribute: >> compare:with:collated: >> determineActivePlatformStartingAt: >> determineActivePlatformStartingAt: >> basicNew >> value: >> value: >> value: >> value: >> perform:with: >> actualScreenSize >> species >> species >> supportsDisplayDepth: >> new: >> basicNew >> beDisplay >> value: >> perform:with: >> isMemberOf: >> value: >> perform:with: >> basicNew >> critical: >> critical: >> wait >> wait >> specialObjectsArray >> species >> new: >> replaceFrom:to:with:startingAt: >> specialObjectsArray >> at:put: >> at:put: >> primSetInputSemaphore: >> suspend >> findNextUnwindContextUpTo: >> value: >> bottomContext >> objectAt: >> basicNew: >> basicNew >> basicNew >> findNextHandlerContextStarting >> tempAt: >> nextHandlerContext >> handleSignal: >> isKindOf: >> tempAt:put: >> tempAt:put: >> tempAt:put: >> valueWithArguments: >> findNextHandlerContextStarting >> basicNew >> findNextHandlerContextStarting >> tempAt: >> findNextHandlerContextStarting >> tempAt: >> Abgebrochen >> >> Cheers >> Philippe >> >> >> >

Jan. 3, 2011

[Pharo-project] next steps for pharo

by Torsten Bergmann

>The coolest programmer of the month ;) Take care, sometimes the "coolest programmer" is the one who is not interested in writing documentation. Sometimes people think they are cool when they win the IOCCC contest [1] or find neat coding tricks that other people do not understand. Following conformance rules, writing clean code or documenting is often seen as "boring task" but necessary to grow into professional shared development. So we have to find a way to turn "boring" into "simple & fun". Bye T. [1] http://de.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Jan. 3, 2011

Re: [Pharo-project] next steps for pharo

by StÃ©phane Ducasse

On Jan 3, 2011, at 7:57 PM, Torsten Bergmann wrote: > I think we can could/should not really force people to it > but at least work on this and add support for cleaning. > > For instance blocking the Monticello upload in 1.3 if a package > does not follow certain criterias would not be a good > idea! > > We want to continue accepting solutions even if they are not 100% > (since the definition of 100% sometimes depends on the POV and > we may end up with code Bureaucracy and maybe less developers). > > Pharo should continue to be fun but we want more discipline. > > IMHO we should: > > 1. do it step by step by more repacking and documenting > (see the already repackaged announcements and regex, > Sunit will follow with issue 3445) > > => we need cleaned exemplary packages so people > are able to follow the patterns yes!!! > 2. Define lint checks and make them instantly available via > browser tools. Maybe you know the VisualWorks browser where > you have the checks in a tab beside the code pane where > one could instantly check and see problems in code. > > Eclipse has that too with Checkstyle/"the Problem view". > > I would like to see that in standard browser. Yes now the standard browser code is bad so. > 3. Define minimum criterias a core/dev package must have > to be part of the system (unloadable, cleaned up dependency, > class comments, have tests, ...) > > 4. Give a visual feedback (icon) if the package is not "clean", > so people get a bad feeling when they see this on their > packages and work towards cleaning. > > We can also have a package ranking ("the most clean" or > "package of the month", ... ;) The coolest programmer of the month ;) > > Just $0.02 > > Bye > T. > > > > > > > > -- > GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > gratis Handy-Flat! http://portal.gmx.net/de/go/dsl >

Jan. 3, 2011

Re: [Pharo-project] next steps for pharo.

by StÃ©phane Ducasse

On Jan 3, 2011, at 7:28 PM, csrabak(a)bol.com.br wrote: > Em 03/01/2011 15:01, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: > >> Hi guys >> I'm brainstorming on what should be our next important actions. My >> gut feeling is that I would love >> - to get more class comments and documentation. > > I'm all for it. We need to increase the actual and perceived quality > of our work. > >> - get a list of working packages for development expanding the list > of packages available from: > http://book.pharo-project.org/book/PharoTools > >> - get metacello repositories up and running and start to get >> certified packages. > > I'm not keeping up with the overwhelming stream of messages in this > list and probably may be missing the kernel of it, but just in case: > do we have already a certification process for packages? no and now that hudson is working I would like to see what we can do especially with metacello - loading ok - % comment of - % of red tests >> How can we all make sure that this happens? > > All of it, it depends on the time frame ;-) IMHO I think priority zero > is class comments and documentation and second the certification > process. > > Attempting to answer the "how" part of the question, I surmise we will > keep the discussion on the comments and documentation in the next IRC > meeting? Yes > I see this as THE most important 'cultural' change we all need to undergo > because of all collaborations we can envisage, writing documentation (or > comments) for someone else code is the less efficient way of doing it. > > Perhaps some form of 'pair commenting' via Skype/IM or IRC _before_ the code > is uploaded? I do not know. Now I try to systematically write comments. I would like to take some example like the soup package and see how it goes. Stef > > > My 0.019999 > > -- > Cesar Rabak >

Jan. 3, 2011

[Pharo-project] next steps for pharo

by Torsten Bergmann

I think we can could/should not really force people to it but at least work on this and add support for cleaning. For instance blocking the Monticello upload in 1.3 if a package does not follow certain criterias would not be a good idea! We want to continue accepting solutions even if they are not 100% (since the definition of 100% sometimes depends on the POV and we may end up with code Bureaucracy and maybe less developers). Pharo should continue to be fun but we want more discipline. IMHO we should: 1. do it step by step by more repacking and documenting (see the already repackaged announcements and regex, Sunit will follow with issue 3445) => we need cleaned exemplary packages so people are able to follow the patterns 2. Define lint checks and make them instantly available via browser tools. Maybe you know the VisualWorks browser where you have the checks in a tab beside the code pane where one could instantly check and see problems in code. Eclipse has that too with Checkstyle/"the Problem view". I would like to see that in standard browser. 3. Define minimum criterias a core/dev package must have to be part of the system (unloadable, cleaned up dependency, class comments, have tests, ...) 4. Give a visual feedback (icon) if the package is not "clean", so people get a bad feeling when they see this on their packages and work towards cleaning. We can also have a package ranking ("the most clean" or "package of the month", ... ;) Just $0.02 Bye T. -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

Jan. 3, 2011

Re: [Pharo-project] next steps for pharo.

by csrabak＠bol.com.br

Em 03/01/2011 15:01, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: > Hi guys > I'm brainstorming on what should be our next important actions. My > gut feeling is that I would love > - to get more class comments and documentation. I'm all for it. We need to increase the actual and perceived quality of our work. > - get a list of working packages for development expanding the list of packages available from: http://book.pharo-project.org/book/PharoTools > - get metacello repositories up and running and start to get > certified packages. I'm not keeping up with the overwhelming stream of messages in this list and probably may be missing the kernel of it, but just in case: do we have already a certification process for packages? > How can we all make sure that this happens? All of it, it depends on the time frame ;-) IMHO I think priority zero is class comments and documentation and second the certification process. Attempting to answer the "how" part of the question, I surmise we will keep the discussion on the comments and documentation in the next IRC meeting? I see this as THE most important 'cultural' change we all need to undergo because of all collaborations we can envisage, writing documentation (or comments) for someone else code is the less efficient way of doing it. Perhaps some form of 'pair commenting' via Skype/IM or IRC _before_ the code is uploaded? My 0.019999 -- Cesar Rabak

Jan. 3, 2011

[Pharo-project] next steps for pharo.

by StÃ©phane Ducasse

Hi guys I'm brainstorming on what should be our next important actions. My gut feeling is that I would love - to get more class comments and documentation. - get a list of working packages for development expanding the list of packages available from: http://book.pharo-project.org/book/PharoTools - get metacello repositories up and running and start to get certified packages. How can we all make sure that this happens? Stef

Jan. 3, 2011

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

by David T. Lewis

On Mon, Jan 03, 2011 at 03:57:07PM +0100, Philippe Marschall wrote: > 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. > Huh ?!?!? What do you mean "nobody cares"? We are apparently now facing two *different* bugs in two different sets of Linux distributions. It's documented here: http://bugs.squeak.org/view.php?id=7358 The only solution I can suggest is to get rid of the UUIDPlugin on unix VMs until the various Linux distros get this fixed. If anyone has a better solution *please* speak up. If you don't know how to fix it, well join the club but don't say that nobody cares. Dave

Jan. 3, 2011