- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Semantic analysis doesn't compute RBArgumentNode instances

by Martin Dias

Done: https://pharo.fogbugz.com/f/cases/17179/Semantic-analysis-doesn-t-compute-R… On Thu, Dec 3, 2015 at 2:30 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > yes ! > > On 03 Dec 2015, at 14:16, Martin Dias <tinchodias(a)gmail.com> wrote: > > > > Hi, > > > > In Pharo 4, the RBExplicitVariableParser computed the argument variables > as RBArgumentNodes: > > > > (Integer >> #bitAnd:) parseTree arguments > > "--> an OrderedCollection(RBArgumentNode(n))" > > > > In Pharo 50191, such parser was removed (case 16026) because "semantic > analysis" does the same job. However, it does not exactly the same job: > argument variables are now parsed as generic variable nodes: > > > > (Integer >> #bitAnd:) parseTree doSemanticAnalysis arguments > > "an OrderedCollection(RBVariableNode(n))" > > > > Anyway, it works well with other variables, e.g. temporaries: > > > > (Integer >> #bitAnd:) parseTree doSemanticAnalysis temporaries > > "an OrderedCollection(RBTemporaryNode(norm))" > > > > Should I create a bug entry? > > > > Cheers, > > Martin > > >

Dec. 3, 2015

How to listen Monticello load start/end (and origin of changes)

by Martin Dias

Hi, Doru asked me how does Epicea listen this information, and I created a snippet to demo it *in a plain Pharo 5 image* (no need to load Epicea before). Maybe somebody else is interested, that's why I share it with everybody. You can open a Transcript and evaluate the following snippet. After evaluation, you can add new methods in Nautilus and see the log in the Transcript. (The code is not very nice). Cheers, Martin "Listen load start" Job jobAnnouncer when: JobStart do: [ :aJobStart | | owner | owner := aJobStart job owner. (owner isKindOf: MCVersionLoader) ifTrue: [ ('Starting to load ', owner versions asArray asString) logCr ] ]. "Listen load end" Job jobAnnouncer when: JobEnd do: [ :aJobEnd | | owner | owner := aJobEnd job owner. (owner isKindOf: MCVersionLoader) ifTrue: [ ('Ending to load ', owner versions asArray asString) logCr ] ]. "Listen changes in the middle" SystemAnnouncer uniqueInstance when: MethodAdded do: [ :aMethodAdded | | mcLoaderJobOrNil | mcLoaderJobOrNil := Job current ifNil: [ nil ] ifNotNil: [ :currentJob | currentJob lookup: [ :job | job owner isKindOf: MCVersionLoader ] ifNone: [ nil ] ]. (aMethodAdded methodAdded printString, ' --- ', (mcLoaderJobOrNil ifNil: [ 'no info' ] ifNotNil: [ 'while loading ', mcLoaderJobOrNil owner versions asArray asString ])) logCr ]. "Try it loading" Gofer it smalltalkhubUser: 'MartinDias' project: 'AlarmClock'; package: 'AlarmClock'; load.

Dec. 3, 2015

Re: [Pharo-dev] VoyageMongo and cache compaction

by Holger Freyther

> On 03 Dec 2015, at 09:58, Holger Freyther <holger(a)freyther.de> wrote: > > Hi guys, > This is a write "heavy" workload but at no point in time more than a couple of objects will > be in the cache. So somehow the VOMongoCache>>#compactIfNeeded check does not > trigger and/or given the difference in the sizes of the dictionary it is possible that some of > the dead objects are not removed from the timestamp cache. the keyword here is "delete" heavy. VOMongoCache>>#removeValue: is called by the VOMongoRepository>>#remove: but this leaves the timeStamp (pharo v3 version or versions in newer) to have an entry for a OID that was removed. And as >>#performCompact will only remove "dead" keys from timeStamp/versions it will leave many delete entries in the timeStamp. The other thing is that I wonder why the self mutex critical lock is not taken around the removal of the object? Is there anyone willing to resolve this, create a testcase and make a backport to Pharo3? holger

Dec. 3, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Ben Coman

On Wed, Dec 2, 2015 at 10:45 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> On 02 Dec 2015, at 15:21, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> >> >> 2015-12-02 15:03 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> On Wed, Dec 2, 2015 at 12:38 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> > Hi, >> > >> >> On Dec 1, 2015, at 5:13 PM, Max Leske <maxleske(a)gmail.com> wrote: >> >> >> >> @Doru >> >> Youâre missing the point: #anyOne *fails* for empty collections. >> > >> > I am not missing the point at all. I am saying that if you want sum: to be generic, it cannot assume a specific Zero object. >> > >> > And sum: should be generic because of its name. >> >> I am missing understanding the other use cases. Can you describe >> further the generic nature of #sum & #sum: ? I would have thought by >> default they only applied to numbers. >> >> sum can be applied to anything that supports #+, not only numbers >> sum: can be applied to any collection with a block that return some object that supports #+ To me this is a mis-application of polymorphism, that just because something responds to #+ it should be summable. We have overloaded the semantics of #+ to mean both numeric addition and concatenation/membership, but technically "summation" relates only to numeric addition. https://www.google.com.au/search?q=define+sum&oq=define+sum https://www.google.com.au/search?q=define+concatenate&oq=define+concatenate For example... * KMModifier implements #+ so what is the expected semantic of " { KMModifier shift . KMModifier meta} sum " ? To me this is more of a concatenation/join/union facility rather than numeric addition. (btw, that expression actually fails since KMModifier does not understand minus #- ) . * String implements #+ and " { '1' . '2' } sum " --> '3', so actually its doing numeric addition. However " { 'a' . 'b' } sum " produces an error. So actually there seem some existing problems with summing non-numerics. What examples work? * Trait classes implement both #+ and #- , but the semantic seems more to do with membership than numeric addition. I don't how how to produce an example of using #sum against traits. * Points are summable " { 2@2 . 3@3 } " --> 5@5. But then " 2@2 + 1 " --> 3@3 , so " {} sum " returning 0 would seem to not cause any error in this case. cheers -ben >> >> therefore you can not assume 0 (<- a number) is a proper initial value therefore you *need* to work with #anyOne >> and as you can not assume a proper initial value, you can not assume a default value for empty collections >> -> it should throw an error. If you (the caller of the function) knows what to do with an empty collection you have >> to check, or call inject:into: directly, with a proper initial value. > > I am sorry but I am getting really tired of this, you should read what is being said. > > I am not suggesting to stop using #anyOne because I like why it is there and what it can do. > > The change I want is what happens with an empty collection when using the simplest selector, #sum. > > I do not want to say to some collection of numbers #sumIfEmpty: [0], because summing numbers starting from zero is the most common case and everybody expects that, hence the unary selector fits. > > I want the less common cases to use the more complicated API, as in some collection of colors #sumIfEmpty: [ Color black ] > > In my book that is common sense API design. > > Doing that I do no take anything away, because today you already have to make sure the collection is not empty. > > The only change would be in the error behaviour. I think that is a reasonable price to pay. Instead of having #anyOne fail, it will say that #+ cannot add 0 to some object, and in a comment we can point to the alternative API. > > http://izquotes.com/quote/242740 right ? > >> cheers -ben >> >> > >> >>> On 01 Dec 2015, at 15:31, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> >>> >> >>> I don't want to be heretic (or too orthodox), but why not to delegate >> >>> this behavior to other class (an iterator maybe?). >> >>> >> >>> It's too tempting adding these convenience methods to Collection >> >>> and/or subclasses, but anything that requires an explicit protocol of >> >>> its elements is wrong, IMO. >> >>> >> >>> something like aCollection arithmetic sum: [...] or.... aCollection >> >>> arithmetic avg. >> >> >> >> >> >> Interesting thought! >> > >> > +100 >> > >> > Doru >> > >> >>> >> >>> My two cents for this. >> >>> >> >>> Regards! >> >>> >> >>> >> >>> Esteban A. Maringolo >> >>> >> >> >> >> >> > >> > -- >> > www.tudorgirba.com >> > >> > "Every thing has its own flow." >> > >> > >> > >> > >> > > >

Dec. 3, 2015

Re: [Pharo-dev] Semantic analysis doesn't compute RBArgumentNode instances

by Marcus Denker

yes ! > On 03 Dec 2015, at 14:16, Martin Dias <tinchodias(a)gmail.com> wrote: > > Hi, > > In Pharo 4, the RBExplicitVariableParser computed the argument variables as RBArgumentNodes: > > (Integer >> #bitAnd:) parseTree arguments > "--> an OrderedCollection(RBArgumentNode(n))" > > In Pharo 50191, such parser was removed (case 16026) because "semantic analysis" does the same job. However, it does not exactly the same job: argument variables are now parsed as generic variable nodes: > > (Integer >> #bitAnd:) parseTree doSemanticAnalysis arguments > "an OrderedCollection(RBVariableNode(n))" > > Anyway, it works well with other variables, e.g. temporaries: > > (Integer >> #bitAnd:) parseTree doSemanticAnalysis temporaries > "an OrderedCollection(RBTemporaryNode(norm))" > > Should I create a bug entry? > > Cheers, > Martin

Dec. 3, 2015

Semantic analysis doesn't compute RBArgumentNode instances

by Martin Dias

Hi, In Pharo 4, the RBExplicitVariableParser computed the argument variables as RBArgumentNodes: (Integer >> #bitAnd:) parseTree arguments "--> an OrderedCollection(RBArgumentNode(n))" In Pharo 50191, such parser was removed (case 16026) because "semantic analysis" does the same job. However, it does not exactly the same job: argument variables are now parsed as generic variable nodes: (Integer >> #bitAnd:) parseTree doSemanticAnalysis arguments "an OrderedCollection(RBVariableNode(n))" Anyway, it works well with other variables, e.g. temporaries: (Integer >> #bitAnd:) parseTree doSemanticAnalysis temporaries "an OrderedCollection(RBTemporaryNode(norm))" Should I create a bug entry? Cheers, Martin

Dec. 3, 2015

Re: [Pharo-dev] [Vm-dev] Re: vm crash in SmalltalkImage>garbageCollect

by Mariano Martinez Peck

Indeed it seems related. Unfortunately neither Andrei or me could find the reason. We did what Eliot suggested us with leaks but we found none. At least right now we have 2 different ways of reproducing the crash (if it is the same bug). On Thu, Dec 3, 2015 at 7:50 AM, Max Leske <maxleske(a)gmail.com> wrote: > > Hi, > > I discovered a similar issue described in this issue > https://pharo.fogbugz.com/f/cases/14165/ObsoleteTest-testFixObsoleteSharedP…. > Might be related. > > Cheers, > Max > > > On 24 Nov 2015, at 19:34, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Mon, Nov 23, 2015 at 4:57 PM, Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > >> Hi Eliot, >> >> Is an assert vm the same as a vm compiled with debugging support? >> > > VMMaker.oscog generates VM sources designed to be compiled in three > different ways, Debug, Assert and Production. Debug is designed to enable > asserts to check invariants and be compiled with no optimization for > maximum debuggability. Assert is designed to enable asserts to check > invariants and be compiled with limited optimization for faster assert > checking. Production has asserts disabled (actually compiled-out) and be > compiled with aggressive optimization, so it has limited debuggability (it > should still contain debugging symbols). > > So Assert and Debug are not quite the same and certainly if you're hunting > for storage leaks an Assert VM will run much faster than a Debug VM. If > you have a look at the Cog svn sources you'll find that the build scripts > build all three kinds of VMs for all platforms. > > > > Also can you point me to any documentation about the leak checker. >> > > It's not well documented because it may change over time, but the -help > flag on the VM should include this: > > -leakcheck num check for leaks in the heap > > and the meaning of num is a set of flags: > > setCheckForLeaks: integerFlags > " 0 = do nothing. > 1 = check for leaks on fullGC (GCModeFull). > 2 = check for leaks on scavenger (GCModeNewSpace). > 4 = check for leaks on incremental (GCModeIncremental) > 8 = check for leaks on become > 16 = check for leaks on image segments" > checkForLeaks := integerFlags > > So once you have your assert VM try running your test case using > > myvm -leakcheck 5 myimage.image > > on the command line. You'll want to use a debugger to put breakpoints in > the leak checker and you may need to learn about the VM's debug routines to > try and figure out the cause of the leak once the leak checker finds it. > >> Cheers, >> Andrei >> >> On Nov 24, 2015 1:45 AM, "Eliot Miranda" <eliot.miranda(a)gmail.com> wrote: >> > >> > Hi Andrei, >> > >> > On Mon, Nov 23, 2015 at 7:59 AM, Andrei Chis < >> chisvasileandrei(a)gmail.com> wrote: >> >> >> >> Hi, >> >> >> >> With both the latest and stable vm I have an use case in which the vm >> crashed in SmalltalkImage>>garbageCollect. >> >> >> >> To set up an image that exhibits the failure , execute this with the >> latest pharo version: >> >> >> >> /pharo Pharo.image eval --save "{ { 'ConfigurationOfRubric'. 'Pharo'. >> 'Rubric' }. { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. { >> 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. { >> 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. { >> 'ConfigurationOfGTEventRecorder'. 'Moose'. 'GToolkit' }. { >> 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. } do: [ :spec | Gofer >> new smalltalkhubUser: spec second project: spec third; package: spec first; >> load ]." >> >> >> >> ./pharo Pharo.image config >> http://www.smalltalkhub.com/mc/Pharo/Pharo50Inbox/main ConfigurationOfGToolkitCore >> --install=3.2 >> >> >> >> Then attempting to run the following code triggers the failure: >> >> >> >> ./pharo Pharo.image eval --save "TestRunner open model >> packageSearchUpdate: 'gt-tests-inspector'; classSearchUpdate: >> 'GTInspectorExamplesTest'; runAll" >> >> >> >> Based on the trace below the failure happens when the >> test GTInspectorExamplesTest calls 'Smalltalk>>garbageCollect' in the setUp >> method. >> >> >> >> That call can be removed, however, in other runs the failure happens >> in other methods calling Smalltalk>>garbageCollect. >> >> >> >> Is it possible that this is a bug with the image (some broken object) >> or is it a vm bug? >> > >> > >> > The way to test this is to build an assert VM and then use the leak >> checker. The leak checker will allow you to narrow down the cause. If the >> leak checker shows no corruption then its definitely a GC bug. If there >> leak checker does show corruption before GC then one still has to find out >> what caused the heap corruption, but you can use the leak checker to narrow >> the search. >> > >> > HTH >> > Eliot >> > >> >> Cheers, >> >> >> >> Andrei >> >> >> >> >> >> >> >> andrei$ ./pharo Pharo.image eval --save "{ { 'ConfigurationOfRubric'. >> 'Pharo'. 'Rubric' }. { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. >> { 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. { >> 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. { >> 'ConfigurationOfGTEventRecorder'. 'Moose'. 'GToolkit' }. { >> 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. } do: [ :spec | Gofer >> new smalltalkhubUser: spec second project: spec third; package: spec first; >> load ]." >> >> >> >> andrei$ ./pharo Pharo.image config >> http://www.smalltalkhub.com/mc/Pharo/Pharo50Inbox/main ConfigurationOfGToolkitCore >> --install=3.2 >> >> >> >> andrei$ ./pharo Pharo.image eval --save "TestRunner open model >> packageSearchUpdate: 'gt-tests-inspector'; classSearchUpdate: >> 'GTInspectorExamplesTest'; runAll" >> >> >> >> >> >> Segmentation fault Mon Nov 23 16:48:36 2015 >> >> >> >> >> >> >> >> https://github.com/pharo-project/pharo-vm.git Commit: >> 28d077d8df494ce050ca42c97c892471e8b8740c Date: 2015-10-16 12:02:43 +0200 >> By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #15016 >> >> >> >> >> >> C stack backtrace: >> >> >> >> 0 Pharo 0x0004cacf reportStackState + >> 159 >> >> >> >> >> >> >> >> Smalltalk stack dump: >> >> >> >> 0xbffbf1a0 M SmalltalkImage>garbageCollect 0x1fd49e30: a(n) >> SmalltalkImage >> >> >> >> 0xbffbf1c0 I GTInspectorExamplesTest>setUp 0x2126bc80: a(n) >> GTInspectorExamplesTest >> >> >> >> 0x2126cb90 is not a context >> >> >> >> >> >> Most recent primitives >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> basicNew >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> shallowCopy >> >> >> >> new >> >> >> >> new: >> >> >> >> new: >> >> >> >> basicNew >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> replaceFrom:to:with:startingAt: >> >> >> >> new: >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> replaceFrom:to:with:startingAt: >> >> >> >> new: >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> new: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> perform:with: >> >> >> >> perform:with: >> >> >> >> perform: >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> new: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> perform:with: >> >> >> >> perform:with: >> >> >> >> perform: >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> new >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> new: >> >> >> >> at:put: >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> new: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> new: >> >> >> >> @ >> >> >> >> at:put: >> >> >> >> @ >> >> >> >> at:put: >> >> >> >> @ >> >> >> >> at:put: >> >> >> >> @ >> >> >> >> at:put: >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> shallowCopy >> >> >> >> shallowCopy >> >> >> >> @ >> >> >> >> @ >> >> >> >> new: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> new: >> >> >> >> @ >> >> >> >> at:put: >> >> >> >> @ >> >> >> >> at:put: >> >> >> >> @ >> >> >> >> at:put: >> >> >> >> @ >> >> >> >> at:put: >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> perform: >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> shallowCopy >> >> >> >> shallowCopy >> >> >> >> primUTCMicrosecondsClock >> >> >> >> // >> >> >> >> basicNew >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> value >> >> >> >> valueNoContextSwitch >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> new: >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> replaceFrom:to:with:startingAt: >> >> >> >> primitiveGarbageCollect >> >> >> >> **IncrementalGC** >> >> >> >> **FullGC** >> >> >> >> garbageCollectMost >> >> >> >> **IncrementalGC** >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> someInstance >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> someInstance >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> someInstance >> >> >> >> new: >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> replaceFrom:to:with:startingAt: >> >> >> >> primitiveGarbageCollect >> >> >> >> **IncrementalGC** >> >> >> >> **FullGC** >> >> >> >> garbageCollectMost >> >> >> >> **IncrementalGC** >> >> >> >> wait >> >> >> >> shallowCopy >> >> >> >> shallowCopy >> >> >> >> signal >> >> >> >> wait >> >> >> >> shallowCopy >> >> >> >> shallowCopy >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> signal >> >> >> >> wait >> >> >> >> shallowCopy >> >> >> >> shallowCopy >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> signal >> >> >> >> new: >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> replaceFrom:to:with:startingAt: >> >> >> >> primitiveGarbageCollect >> >> >> >> **IncrementalGC** >> >> >> >> **FullGC** >> >> >> >> >> >> (Segmentation fault) >> >> >> >> ./pharo: line 11: 5224 Abort trap: 6 >> "$DIR"/"pharo-vm/Pharo.app/Contents/MacOS/Pharo" --headless "$@" >> > >> > >> > >> > >> > -- >> > _,,,^..^,,,_ >> > best, Eliot >> > > > > -- > _,,,^..^,,,_ > best, Eliot > > > > -- Mariano http://marianopeck.wordpress.com

Dec. 3, 2015

Re: [Pharo-dev] evolutions of squeakelib & crypto (Reed Solomon)

by Robert Withers

ReedSolomon updates: https://www.dropbox.com/s/f5unbbdetv4c5xs/Cryptography-rww.41.mcz?dl=0 more refactoring of the pipeline: https://www.dropbox.com/s/g45himklwa66zqb/SqueakElib-rww.205.mcz?dl=0 - Robert On 12/03/2015 06:00 AM, Robert Withers wrote: > Here is an update with some refactorings and extensions. I added > 'domain' to the IWant/IAm messages to support subdomains. > > https://www.dropbox.com/s/tvpxfuixzxrj3op/SqueakElib-rww.204.mcz?dl=0 > > thanks for trying it, > Robert > > On 12/01/2015 02:23 PM, Robert Withers wrote: >> Another version fixing empty payloads... >> >> https://www.dropbox.com/s/wjhbopwabbrszjn/SqueakElib-rww.202.mcz?dl=0 >> >> thank you, >> - Robert >> >> On 12/01/2015 11:44 AM, Robert Withers wrote: >>> Here is a newer version (201) with a protocol change to remove all >>> tcpIds from the rendezvous. >>> >>> https://www.dropbox.com/s/7mgfglwu3e4bf4j/SqueakElib-rww.201.mcz?dl=0 >>> >>> - Robert >>> >>> On 12/01/2015 07:37 AM, Robert Withers wrote: >>>> This version of the Cryptography package has beginnings of >>>> ReedSolomon encoding. >>>> >>>> The rendezvous is separated into an OperationProtocol and a >>>> StartupProtocol and the message pipeline of the session layer of >>>> SqueakElib has been completely rewritten and LayeredProtocols have >>>> been folded in. Please look at ElibVatTPDataTestCase for an example. >>>> >>>> Cryptography: >>>> https://www.dropbox.com/s/z9dux2goimej79e/Cryptography-rww.40.mcz?dl=0 >>>> SqueakElib: >>>> https://www.dropbox.com/s/5yvkl3df89uyjnh/SqueakElib-rww.200.mcz?dl=0 >>>> >>>> In the spirit of #GivingTuesday, >>>> Robert >>> >> >

Dec. 3, 2015

Re: [Pharo-dev] evolutions of squeakelib & crypto (Reed Solomon)

by Robert Withers

Here is an update with some refactorings and extensions. I added 'domain' to the IWant/IAm messages to support subdomains. https://www.dropbox.com/s/tvpxfuixzxrj3op/SqueakElib-rww.204.mcz?dl=0 thanks for trying it, Robert On 12/01/2015 02:23 PM, Robert Withers wrote: > Another version fixing empty payloads... > > https://www.dropbox.com/s/wjhbopwabbrszjn/SqueakElib-rww.202.mcz?dl=0 > > thank you, > - Robert > > On 12/01/2015 11:44 AM, Robert Withers wrote: >> Here is a newer version (201) with a protocol change to remove all >> tcpIds from the rendezvous. >> >> https://www.dropbox.com/s/7mgfglwu3e4bf4j/SqueakElib-rww.201.mcz?dl=0 >> >> - Robert >> >> On 12/01/2015 07:37 AM, Robert Withers wrote: >>> This version of the Cryptography package has beginnings of >>> ReedSolomon encoding. >>> >>> The rendezvous is separated into an OperationProtocol and a >>> StartupProtocol and the message pipeline of the session layer of >>> SqueakElib has been completely rewritten and LayeredProtocols have >>> been folded in. Please look at ElibVatTPDataTestCase for an example. >>> >>> Cryptography: >>> https://www.dropbox.com/s/z9dux2goimej79e/Cryptography-rww.40.mcz?dl=0 >>> SqueakElib: >>> https://www.dropbox.com/s/5yvkl3df89uyjnh/SqueakElib-rww.200.mcz?dl=0 >>> >>> In the spirit of #GivingTuesday, >>> Robert >> >

Dec. 3, 2015

Re: [Pharo-dev] vm crash in SmalltalkImage>garbageCollect

by Max Leske

Hi, I discovered a similar issue described in this issue https://pharo.fogbugz.com/f/cases/14165/ObsoleteTest-testFixObsoleteSharedP…. Might be related. Cheers, Max > On 24 Nov 2015, at 19:34, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Mon, Nov 23, 2015 at 4:57 PM, Andrei Chis <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com>> wrote: > Hi Eliot, > > Is an assert vm the same as a vm compiled with debugging support? > > > VMMaker.oscog generates VM sources designed to be compiled in three different ways, Debug, Assert and Production. Debug is designed to enable asserts to check invariants and be compiled with no optimization for maximum debuggability. Assert is designed to enable asserts to check invariants and be compiled with limited optimization for faster assert checking. Production has asserts disabled (actually compiled-out) and be compiled with aggressive optimization, so it has limited debuggability (it should still contain debugging symbols). > > So Assert and Debug are not quite the same and certainly if you're hunting for storage leaks an Assert VM will run much faster than a Debug VM. If you have a look at the Cog svn sources you'll find that the build scripts build all three kinds of VMs for all platforms. > > > > Also can you point me to any documentation about the leak checker. > > > It's not well documented because it may change over time, but the -help flag on the VM should include this: > > -leakcheck num check for leaks in the heap > > and the meaning of num is a set of flags: > > setCheckForLeaks: integerFlags > " 0 = do nothing. > 1 = check for leaks on fullGC (GCModeFull). > 2 = check for leaks on scavenger (GCModeNewSpace). > 4 = check for leaks on incremental (GCModeIncremental) > 8 = check for leaks on become > 16 = check for leaks on image segments" > checkForLeaks := integerFlags > > So once you have your assert VM try running your test case using > > myvm -leakcheck 5 myimage.image > > on the command line. You'll want to use a debugger to put breakpoints in the leak checker and you may need to learn about the VM's debug routines to try and figure out the cause of the leak once the leak checker finds it. > Cheers, > Andrei > > On Nov 24, 2015 1:45 AM, "Eliot Miranda" <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: > > > > Hi Andrei, > > > > On Mon, Nov 23, 2015 at 7:59 AM, Andrei Chis <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com>> wrote: > >> > >> Hi, > >> > >> With both the latest and stable vm I have an use case in which the vm crashed in SmalltalkImage>>garbageCollect. > >> > >> To set up an image that exhibits the failure , execute this with the latest pharo version: > >> > >> /pharo Pharo.image eval --save "{ { 'ConfigurationOfRubric'. 'Pharo'. 'Rubric' }. { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. { 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTEventRecorder'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. } do: [ :spec | Gofer new smalltalkhubUser: spec second project: spec third; package: spec first; load ]." > >> > >> ./pharo Pharo.image config http://www.smalltalkhub.com/mc/Pharo/Pharo50Inbox/main <http://www.smalltalkhub.com/mc/Pharo/Pharo50Inbox/main> ConfigurationOfGToolkitCore --install=3.2 > >> > >> Then attempting to run the following code triggers the failure: > >> > >> ./pharo Pharo.image eval --save "TestRunner open model packageSearchUpdate: 'gt-tests-inspector'; classSearchUpdate: 'GTInspectorExamplesTest'; runAll" > >> > >> Based on the trace below the failure happens when the test GTInspectorExamplesTest calls 'Smalltalk>>garbageCollect' in the setUp method. > >> > >> That call can be removed, however, in other runs the failure happens in other methods calling Smalltalk>>garbageCollect. > >> > >> Is it possible that this is a bug with the image (some broken object) or is it a vm bug? > > > > > > The way to test this is to build an assert VM and then use the leak checker. The leak checker will allow you to narrow down the cause. If the leak checker shows no corruption then its definitely a GC bug. If there leak checker does show corruption before GC then one still has to find out what caused the heap corruption, but you can use the leak checker to narrow the search. > > > > HTH > > Eliot > > > >> Cheers, > >> > >> Andrei > >> > >> > >> > >> andrei$ ./pharo Pharo.image eval --save "{ { 'ConfigurationOfRubric'. 'Pharo'. 'Rubric' }. { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. { 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTEventRecorder'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. } do: [ :spec | Gofer new smalltalkhubUser: spec second project: spec third; package: spec first; load ]." > >> > >> andrei$ ./pharo Pharo.image config http://www.smalltalkhub.com/mc/Pharo/Pharo50Inbox/main <http://www.smalltalkhub.com/mc/Pharo/Pharo50Inbox/main> ConfigurationOfGToolkitCore --install=3.2 > >> > >> andrei$ ./pharo Pharo.image eval --save "TestRunner open model packageSearchUpdate: 'gt-tests-inspector'; classSearchUpdate: 'GTInspectorExamplesTest'; runAll" > >> > >> > >> Segmentation fault Mon Nov 23 16:48:36 2015 > >> > >> > >> > >> https://github.com/pharo-project/pharo-vm.git <https://github.com/pharo-project/pharo-vm.git> Commit: 28d077d8df494ce050ca42c97c892471e8b8740c Date: 2015-10-16 12:02:43 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> Jenkins build #15016 > >> > >> > >> C stack backtrace: > >> > >> 0 Pharo 0x0004cacf reportStackState + 159 > >> > >> > >> > >> Smalltalk stack dump: > >> > >> 0xbffbf1a0 M SmalltalkImage>garbageCollect 0x1fd49e30: a(n) SmalltalkImage > >> > >> 0xbffbf1c0 I GTInspectorExamplesTest>setUp 0x2126bc80: a(n) GTInspectorExamplesTest > >> > >> 0x2126cb90 is not a context > >> > >> > >> Most recent primitives > >> > >> @ > >> > >> basicNew > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> basicNew > >> > >> basicNew > >> > >> basicNew > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> shallowCopy > >> > >> new > >> > >> new: > >> > >> new: > >> > >> basicNew > >> > >> basicNew > >> > >> new: > >> > >> basicNew > >> > >> new: > >> > >> replaceFrom:to:with:startingAt: > >> > >> new: > >> > >> basicNew > >> > >> new: > >> > >> replaceFrom:to:with:startingAt: > >> > >> new: > >> > >> basicNew > >> > >> @ > >> > >> new: > >> > >> at:put: > >> > >> at:put: > >> > >> perform:with: > >> > >> perform:with: > >> > >> perform: > >> > >> @ > >> > >> @ > >> > >> basicNew > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> basicNew > >> > >> @ > >> > >> new: > >> > >> at:put: > >> > >> at:put: > >> > >> perform:with: > >> > >> perform:with: > >> > >> perform: > >> > >> @ > >> > >> @ > >> > >> basicNew > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> new > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> basicNew > >> > >> @ > >> > >> @ > >> > >> new: > >> > >> at:put: > >> > >> @ > >> > >> @ > >> > >> basicNew > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> new: > >> > >> at:put: > >> > >> at:put: > >> > >> at:put: > >> > >> at:put: > >> > >> new: > >> > >> @ > >> > >> at:put: > >> > >> @ > >> > >> at:put: > >> > >> @ > >> > >> at:put: > >> > >> @ > >> > >> at:put: > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> basicNew > >> > >> @ > >> > >> @ > >> > >> basicNew > >> > >> @ > >> > >> @ > >> > >> basicNew > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> shallowCopy > >> > >> shallowCopy > >> > >> @ > >> > >> @ > >> > >> new: > >> > >> at:put: > >> > >> at:put: > >> > >> at:put: > >> > >> at:put: > >> > >> new: > >> > >> @ > >> > >> at:put: > >> > >> @ > >> > >> at:put: > >> > >> @ > >> > >> at:put: > >> > >> @ > >> > >> at:put: > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> basicNew > >> > >> @ > >> > >> @ > >> > >> basicNew > >> > >> @ > >> > >> @ > >> > >> basicNew > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> basicNew > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> basicNew > >> > >> @ > >> > >> @ > >> > >> basicNew > >> > >> @ > >> > >> @ > >> > >> basicNew > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> basicNew > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> @ > >> > >> basicNew > >> > >> @ > >> > >> @ > >> > >> perform: > >> > >> basicNew > >> > >> new: > >> > >> basicNew > >> > >> new: > >> > >> basicNew > >> > >> new: > >> > >> shallowCopy > >> > >> shallowCopy > >> > >> primUTCMicrosecondsClock > >> > >> // > >> > >> basicNew > >> > >> basicNew > >> > >> new: > >> > >> at:put: > >> > >> at:put: > >> > >> at:put: > >> > >> at:put: > >> > >> value > >> > >> valueNoContextSwitch > >> > >> basicNew > >> > >> new: > >> > >> basicNew > >> > >> new: > >> > >> new: > >> > >> basicNew > >> > >> new: > >> > >> replaceFrom:to:with:startingAt: > >> > >> primitiveGarbageCollect > >> > >> **IncrementalGC** > >> > >> **FullGC** > >> > >> garbageCollectMost > >> > >> **IncrementalGC** > >> > >> basicNew > >> > >> new: > >> > >> someInstance > >> > >> basicNew > >> > >> new: > >> > >> someInstance > >> > >> basicNew > >> > >> new: > >> > >> someInstance > >> > >> new: > >> > >> basicNew > >> > >> new: > >> > >> replaceFrom:to:with:startingAt: > >> > >> primitiveGarbageCollect > >> > >> **IncrementalGC** > >> > >> **FullGC** > >> > >> garbageCollectMost > >> > >> **IncrementalGC** > >> > >> wait > >> > >> shallowCopy > >> > >> shallowCopy > >> > >> signal > >> > >> wait > >> > >> shallowCopy > >> > >> shallowCopy > >> > >> at:put: > >> > >> at:put: > >> > >> at:put: > >> > >> at:put: > >> > >> at:put: > >> > >> at:put: > >> > >> signal > >> > >> wait > >> > >> shallowCopy > >> > >> shallowCopy > >> > >> at:put: > >> > >> at:put: > >> > >> signal > >> > >> new: > >> > >> basicNew > >> > >> new: > >> > >> replaceFrom:to:with:startingAt: > >> > >> primitiveGarbageCollect > >> > >> **IncrementalGC** > >> > >> **FullGC** > >> > >> > >> (Segmentation fault) > >> > >> ./pharo: line 11: 5224 Abort trap: 6 "$DIR"/"pharo-vm/Pharo.app/Contents/MacOS/Pharo" --headless "$@" > > > > > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > > > > > -- > _,,,^..^,,,_ > best, Eliot

Dec. 3, 2015