November 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] problem using curl and wget in zero-conf

by stepharo

I'm bad with scripts :) but this is important to improve them. Can you open a bug entry so that this discussion is not lost? Le 24/11/15 00:25, Dale Henrichs a Ã©crit : > I've been using zero-conf scripts to download the pharo vm for a while > and occasionally the download fails to install the vm in the pharo-vm > directory .... silently ..... with no clue as to what happened. even > worse the exit status is zero so the failure isn't noticed until much > later on in my install when an attempt is made to actually use the vm > .... I do know that when I see these failures the pharo-vm does get > created but is empty ... > > I got another failure today and figured that I would dig into this on > my end to see if I could understand what might be going on .... > > The section of the zero-conf script that is suspect is the following: > > mkdir $VM_DIR > $DOWNLOAD_TO$VM_DIR/vm.zip $VM_URL > > > After the $VM_DIR is created (which I know happens), the $DOWNLOAD_TO > script is run. Recently, I learned that a side effect of using the > --silent option for curl is that error messages are also suppressed > and I see that for curl, the `--silent` option is being used: > > if [[ `which curl 2> /dev/null` ]]; then > DOWNLOAD="curl --silent --location --compressed "; > DOWNLOAD_TO="$DOWNLOAD --output "; > elif [[ `which wget 2> /dev/null` ]]; then > DOWNLOAD_TO="wget --quiet --output-document="; > DOWNLOAD="$DOWNLOAD_TO-"; > else > echo "Please install curl or wget on your machine"; > exit 1 > fi > > > For curl if you want to turn off the progress meter (a good thing) and > continue to report errors, you need to use --show-error in conjunction > with --silent (as described in the man page) > > I think the same thing applies to wget, --quiet turns off error > messages and progress .... you probably should be using --no-verbose > to continue to get error messages ... > > Dale > > >

Nov. 24, 2015

Install Pharo launcher on MAC

by Trussardi Dario Romano

Ciao, i have a macbook with Mac OS X 10.7.5 and some Pharo x.y applications. Now i begin a new development work and i think to started with the Pharo launcher to manage the last and the future pharo image. Into https://ci.inria.fr/pharo/view/Launcher/job/Launcher-Mac/ i found this link: latest.dmg It's the right dmg image to install ? I need to do something for the old pharo applications? After installed the new pharo launcher, the old Pharo application is load and works without problem? ( how they work now: open with specific VM ) In the Mac App Store i found this : https://itunes.apple.com/it/app/pharo-launcher/id503025789?mt=12 It has the same name: 'pharo-launcher' but it's another think or i wrong? It can interact with the above? Thanks for any considerations. Dario

Nov. 24, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50464 Home: https://github.com/pharo-project/pharo-core

Nov. 24, 2015

[pharo-project/pharo-core] b6096c: 50464

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: b6096c13153280900cf70f47d471e02d5b2b9e0a https://github.com/pharo-project/pharo-core/commit/b6096c13153280900cf70f47… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-24 (Tue, 24 Nov 2015) Changed paths: M Debugger-Tests.package/DebuggerModelTest.class/instance/running/setUp.st M Debugger-Tests.package/DebuggerModelTest.class/instance/tests/testCorrectlyCreateDebugSession.st M Debugger-Tests.package/DebuggerModelTest.class/instance/tests/testStepInto.st M Debugger-Tests.package/DebuggerModelTest.class/instance/tests/testStepOver.st M Debugger-Tests.package/FilterTest.class/instance/running/setUp.st R DebuggerModel.package/DebugSession.class/class/instance creation/process_context_.st R Morphic-Widgets-Tabs.package/Tab.class/instance/event handling/handlesMouseUp_.st M Morphic-Widgets-Tabs.package/TabManager.class/instance/private-contents/addTabContents_at_delta_.st A Morphic-Widgets-Tabs.package/TabWithNoContents.class/instance/accessing/tab.st M Morphic-Widgets-Tabs.package/extension/SequenceableCollection/instance/max_.st A NautilusCommon.package/AbstractNautilusPlugin.class/class/testing/isUsed.st M NautilusCommon.package/AnnotationPanePlugin.class/instance/private/buildString.st M NautilusCommon.package/AnnotationRequest.class/README.md M NautilusCommon.package/AnnotationRequest.class/definition.st M NautilusCommon.package/NautilusHistoryEntry.class/definition.st M NautilusCommon.package/NautilusPluginManager.class/instance/buttons behavior/addButtonState.st M NautilusCommon.package/NautilusPluginManager.class/instance/buttons behavior/removeButtonState.st A Polymorph-Widgets.package/MorphicUIManager.class/instance/debug/lowSpaceWarningMessage.st A Polymorph-Widgets.package/MorphicUIManager.class/instance/debug/lowSpaceWatcherDefaultAction_.st R Polymorph-Widgets.package/MorphicUIManager.class/instance/ui process/interruptName_preemptedProcess_.st R Polymorph-Widgets.package/MorphicUIManager.class/instance/ui requests/lowSpaceWatcherDefaultAction_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50463.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50464.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50463.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50464.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Settings-Polymorph.package/PolymorphSystemSettings.class/class/desktop/desktopBackgroundChanged.st A Settings-Polymorph.package/PolymorphSystemSettings.class/class/desktop/desktopImageLayout.st A Settings-Polymorph.package/PolymorphSystemSettings.class/class/desktop/desktopImageLayout_.st M Settings-Polymorph.package/PolymorphSystemSettings.class/class/desktop/desktopSettingsOn_.st M Settings-Polymorph.package/PolymorphSystemSettings.class/definition.st R Spec-Debugger.package/SpecDebugger.class/class/instance creation/context_.st R Spec-Debugger.package/SpecDebugger.class/class/instance creation/informExistingDebugger_label_.st R Spec-Debugger.package/SpecDebugger.class/class/instance creation/openOn_.st R Spec-Debugger.package/SpecDebugger.class/class/opening/openInterrupt_onProcess_.st R Spec-Debugger.package/SpecDebugger.class/class/private/spanNewSessionForContext_fromProcess_.st R Spec-Debugger.package/SpecDebugger.class/instance/api/openOn_.st R Spec-Debugger.package/SpecDebugger.class/instance/initialization/process_context_.st R Spec-Debugger.package/SpecDebugger.class/instance/old - public/errorWasInUIProcess_.st R Spec-Debugger.package/SpecDebugger.class/instance/old - public/proceed_.st R Spec-Debugger.package/SpecDebugger.class/instance/opening/openNotifierContents_label_.st R Spec-Debugger.package/SpecDebugger.class/instance/opening/openWithFullViewAndTitle_.st R Spec-Debugger.package/SpecDebugger.class/instance/private/lowSpaceChoices.st M Tools-Test.package/DebuggerTest.class/instance/testing/testBasic.st Log Message: ----------- 50464 17095 small code critique cleanup in NautilusCommon https://pharo.fogbugz.com/f/cases/17095 17094 Small code critique cleanup in Morphic-Widgets-Tabs https://pharo.fogbugz.com/f/cases/17094 17090 Opening debugger API cleanup. Part3 https://pharo.fogbugz.com/f/cases/17090 16936 Desktop Background Image changes aspect ratio whenever the Pharo World window does https://pharo.fogbugz.com/f/cases/16936 http://files.pharo.org/image/50/50464.zip

Nov. 24, 2015

Re: [Pharo-dev] Rules

by Ben Coman

On Tue, Nov 24, 2015 at 4:32 PM, Nicolas Anquetil <nicolas.anquetil(a)inria.fr> wrote: > > > On 23/11/2015 22:14, stepharo wrote: >> >> >> >> Le 22/11/15 22:11, Yuriy Tymchuk a Ã©crit : >>> >>> Hi. >>> >>> The rule is correct. Sending a different message to super may be >>> confusing. In this case you are in âprintOn:â method and you are sending >>> âprintOn:nextPutAll:â to super. The idea is that you have to send >>> âprintOn:nextPutAll:â to self and then either it will invoke the super one, >>> you there will be an overridden method in your current class. >> >> >> exactly but do you expect a newbie to understand anything with the current >> explanation? >> I do not. >> >> " >> >> Rewrite super messages to self messages when both refer to same method" > > What about : Sorry :) both of these make my head hurt. I think Stef's was clearer. The useful part there is that it reports the actual identifier causing the problem, which makes it more obvious this is not what was meant, from which even a newbie may infer the missing period. > "'super' should call the same selector. Send different selector to 'self' > then use 'super' in this one." > ? btw, is this just commonly how super is used, or is it really bad to call a different super method? I'm sure I've done that on occasion. cheers -ben > > or: > > "should not send a different message to super (send different message to > self and then call super from it)" > ? > > > > nicolas > >> >> Sucks >> >>> >>> Secondly, there is an issue with âsends unkown selectorâ. Iâve also >>> noticed it recently. I think that it happens because the rule has a special >>> cace, and I messed up something with refresh. This is the next thing on my >>> TODO list. >>> >>> Cheers. >>> Uko >>> >>> >>>> On 22 Nov 2015, at 16:33, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>>> >>>> >>>>> On 22 Nov 2015, at 12:20, stepharo <stepharo(a)free.fr> wrote: >>>>> >>>>> With the following (broken) definition >>>>> >>>>> >>>>> : aStream >>>>> super printOn: aStream >>>>> aStream nextPutAll: '(', faces printString , ')' >>>>> >>>>> I got this strange rule: >>>>> >>>>> Rewrite super messages to self messages when both refer to same >>>>> method >>>>> >>>>> I do not get it and it looks really suspicious to me. >>>>> Any suggestions? >>>> >>>> The rule is meant to catch the case when when âsuperâ can be âselfâ as >>>> there is no #printOn: >>>> defined in the class. >>>> >>>> But here it looks like it is wrong: it would be an infinite loop. >>>> >>>> I think it could be related to this other bug: I have seen that the >>>> rules are not correctly updated >>>> when you add methods. (I wanted to add an issue for that but did not >>>> yet). E.g. I often get >>>> a âsends unkown selectorâ for self sends and then I check â> method is >>>> there, I just added it! >>>> >>>> So here this means that you added a new printOn:, the rules do not >>>> update, and it thinks >>>> that there is no printOn:. >>>> >>>> So the real bug is that added methods need to be taken into account by >>>> QA. >>>> >>>> Marcus >>> >>> >>> >> >> > > -- > Nicolas Anquetil > RMod team -- Inria Lille > >

Nov. 24, 2015

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

by Andrei Chis

Hi Mario, I compiled a debug vm with #checkForLeaks answering 1 and I get the same error messages. However I get them in every version of Pharo 5 that I checked just by interacting with the system. When running clearLeakMapAndMapAccessibleObjects I get a failure: (lldb) call clearLeakMapAndMapAccessibleObjects() error: Execution was interrupted, reason: EXC_BAD_ACCESS (code=1, address=0x424a9434). The process has been returned to the state before expression evaluation. Cheers, Andrei On Tue, Nov 24, 2015 at 3:28 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > OK, I made it work by compiling a VM with #checkForLeaks answering 1. > I see plenty of leaks but they are all of the pattern "cache tag leak in > CM". > See a piece of the gdb output: > > ----------- > cache tag leak in CM 0x1f4a8b58 @ 0x1f4a8bfa > cache tag leak in CM 0x1f4a9800 @ 0x1f4a98a9 > cache tag leak in CM 0x1f4ad8a0 @ 0x1f4ad974 > cache tag leak in CM 0x1f4ae380 @ 0x1f4ae3ea > cache tag leak in CM 0x1f4ae510 @ 0x1f4ae577 > cache tag leak in CM 0x1f4af708 @ 0x1f4af94e > > checkCodeIntegrity(0) 11637 > > fwdBlockValid(fwdBlock2) 40450 > > Program received signal SIGSEGV, Segmentation fault. > 0x000ab672 in updatePointersInRangeFromto (memStart=525336576, > memEnd=555384320) at > /Users/mariano/Pharo/git/pharo-vm/src/vm/gcc3x-cointerp.c:40451 > 40451 targetObj = longAt(fwdBlock2); > ------------- > > > There is none other type of leak displayed. > > Any idea what does this mean? > > > > On Mon, Nov 23, 2015 at 11:15 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> On Mon, Nov 23, 2015 at 11:13 PM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> >>> >>> On Mon, Nov 23, 2015 at 9:57 PM, Andrei Chis <chisvasileandrei(a)gmail.com >>> > wrote: >>> >>>> Hi Eliot, >>>> >>>> Is an assert vm the same as a vm compiled with debugging support? >>>> Also can you point me to any documentation about the leak checker. >>>> >>>> >>> I was about to ask the same. I have the VM compiled with debug support >>> and gdb working. I can reproduce the crash. >>> After checking a bit in the VM about what Eliot says, I found out >>> methods like #clearLeakMapAndMapAccessibleObjects and #checkCodeIntegrity:. >>> >>> However, I tried, for example (clearLeakMapAndMapAccessibleObjects to >>> later call checkCodeIntegrity(0) ) from gdb: >>> >>> ------ >>> *fwdBlockValid(fwdBlock2) 40450* >>> >>> *Program received signal SIGSEGV, Segmentation fault.* >>> *0x000ab6d2 in ?? ()* >>> *(gdb) call clearLeakMapAndMapAccessibleObjects()* >>> ------- >>> >>> >>> And I get CPU at 100% never ending. >>> >> >> I forgot to said..I also compiled the VM with a hardcoded #checkForLeaks >> that answers 1 (to force the checker) but that did not work either. >> >> >> >>> >>> >>> 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 >>>> >>>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com >

Nov. 24, 2015

Re: [Pharo-dev] Debugging a failing test doesn't include the full stack

by Ben Coman

On Tue, Nov 24, 2015 at 7:32 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > I'm trying to debug a failing test case in Pharo 5, but for some reason in > certain tests I can't see the full stack, so basically I can't fix nor > diagnose the failing test within the debugger because I only get the assert > notification. > > > > This doesn't happen in Pharo 4, there seems to be a refactoring of the > TestCase hierarchy, but I don't know how it affects the exception handling, > which in the case of Glorp seems to not be very orthodox. > > Regards! > â > > Esteban A. Maringolo > Possible workaround hack is to remove some of the conditions from #on:do: so you get a debugger straight away on the original error rather than storing it for later. TestResult>>runCase: aTestCase [ aTestCase announce: TestCaseStarted withResult: self. aTestCase runCase. aTestCase announce: TestCaseEnded withResult: self. self addPass: aTestCase] on: self class failure , self class skip, self class warning, self class error do: [:ex | ex sunitAnnounce: aTestCase toResult: self] cheers -ben

Nov. 24, 2015

Re: [Pharo-dev] problem using curl and wget in zero-conf -- explained

by Ben Coman

On Tue, Nov 24, 2015 at 8:51 AM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > As I mentioned in the previous email, I sometimes have users report that > they get the following error in their log file when installing > pharo/GsDevKit-Home: > >> /home/travis/build/GsDevKit/GsDevKit_home/shared/pharo/pharo: line 11: >> /home/travis/build/GsDevKit/GsDevKit_home/shared/pharo > > > and I assumed that it was some sort of unreported error while downloading > the pharo-vm (--silent used without --show-error for curl) ... fortunately > I just started reliably getting this error on travis[1] and was able to > track down the root cause of the bogus "file does not exist message" to the > fact that the 32 bit libraries have not been installed[2]. > > It's true that the zero-conf script reports info that the 32-bit libraries > were not installed, but the linux error message in this case is completely > misleading ... it wasn't until I verified that the file did indeed exist[1] > that I was able to investigate this further --- in my case I was expecting > the 32-bit libraries to get installed in a later step and changes to the > script structure resulted in the 32 bit library install being skipped ... > > At the end of the day, I think that error messages should not be suppressed > by the zero-conf scripts, especially given the fact that the error message > you get when a download does fail is pretty much the same as you'd get when > you don't have the 32 bit libraries installed ... > > In my case, now that I understand that I cannot rely on a proper error error > when 32-libraries have not been installed, I will have to see if I can come > up with a way to provide a better error message for GsDevKit_home users .... > > Dale > > [1] https://travis-ci.org/GsDevKit/GsDevKit_home/jobs/92839591#L352 > [2] > http://askubuntu.com/questions/133389/no-such-file-or-directory-but-the-fil… > > > On 11/23/2015 04:05 PM, Dale Henrichs wrote: >> >> >> >> On 11/23/2015 03:39 PM, Esteban A. Maringolo wrote: >>> >>> 2015-11-23 20:25 GMT-03:00 Dale Henrichs >>> <dale.henrichs(a)gemtalksystems.com>: >>>> >>>> I've been using zero-conf scripts to download the pharo vm for a while >>>> and >>>> occasionally the download fails to install the vm in the pharo-vm >>>> directory >>>> .... silently ..... with no clue as to what happened. even worse the >>>> exit >>>> status is zero so the failure isn't noticed until much later on in my >>>> install when an attempt is made to actually use the vm .... I do know >>>> that >>>> when I see these failures the pharo-vm does get created but is empty >>>> ... >>> >>> +1. I've been bitten by this too. >>> >>> I would also like the option of seeing the progress of the download of >>> the sources AND vm, because sometimes I want to know how the download >>> is going on, speed, etc. >>> >>> Regards! >>> >>> -- >>> Esteban >>> >> I agree with the progress, but when running as a batch job, you end up >> with a ton of junk being dumped out into the log file ... getting rid of >> junk from a log file is how I learned about the problem with --silent:) >> >> With regards to the issue I am having --- I have hit a point in my testing >> (on travis) where I consistently get the: >> >>> /home/travis/build/GsDevKit/GsDevKit_home/shared/pharo/pharo: line 11: >>> /home/travis/build/GsDevKit/GsDevKit_home/shared/pharo/pharo-vm/pharo: No >>> such file or directory >> >> >> error message yet the following appears to work: >> >>> if [ "$OS" == "win" ]; then >>> PHARO_VM=`find $VM_DIR -name ${VM_BINARY_NAME}.exe` >>> elif [ "$OS" == "mac" ]; then >>> PHARO_VM=`find $VM_DIR -name ${VM_BINARY_NAME}` >>> elif [ "$OS" == "linux" ]; then >>> PHARO_VM=`find $VM_DIR -name ${VM_BINARY_NAME_LINUX}` >>> fi >>> >>> echo $PHARO_VM >> >> >> since `pharo-vm/pharo` is properly echoed even though the file does not >> appear to exist? I'm digging deeper .... I don't have a linux box to check this on, but how about something like... if [ `ldd $PHARO_VM 2>/dev/null | grep -c 'not found'` -ne 0 ]; then echo "Missing library dependencies..." ldd $PHARO_VM 2>/dev/null | grep 'not found' echo "Maybe you need to..." echo " $ sudo dpkg --add-architecture i386" echo " $ sudo apt-get update" echo "and for each $MISSING_LIBRARY..." echo " $ sudo apt-get install $MISSING_LIBRARY:386" exit 1 fi cheers -ben

Nov. 24, 2015

Re: [Pharo-dev] Unable to accept changes in SyntaxErrorDebugger -> DNU: receiver of asSymbol is nil

by Marcus Denker

On Tue, Nov 24, 2015 at 9:07 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2015-11-24 13:01 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> I will put it on the TODOâ¦. sadly I am a bit busy and canât postpone the >> other things now to work on this. >> > > No problem. > An idea how this should be solved. > > I think that SyntaxErrorDebugger should not care about the category. It's a very exceptional case and recatogorizing a method in that case is not too much to ask. The self flag: #hack. "Should use the new OPalWarnings directly instead of recreating a SyntaxErrorNotification" is not really good because OC falls back on calling #notify:at:... on the requestor in non-interactive mode. The whole error handling needs to be improved, but we can only do that *after* we remove the old Compiler. This is why I did not invest yet into cleaning and simplification... it is impossible if we have to stay compatible. > >> On 20 Nov 2015, at 18:19, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> Any idea how to solve this: >> >> 16961 >> <https://pharo.fogbugz.com/f/cases/16961/Unable-to-accept-changes-in-SyntaxE…> >> Unable to accept changes in SyntaxErrorDebugger -> DNU: receiver of >> asSymbol is nil >> and >> 16723 >> <https://pharo.fogbugz.com/f/cases/16723/File-in-a-file-with-an-error-does-n…> >> File in a file with an error does not set the doitFlag well >> >> If you file in some code that with syntactic errors, you can not fix the >> code from within SyntaxErrorDebugger because >> 1. the doitflag is nil, and If we would change this, init it with true... >> 2. ... the category is nil >> >> From where it is used and comments like: >> >> notify: message at: location in: code >> self flag: #hack. >> "Should use the new OPalWarnings directly instead of recreating a >> SyntaxErrorNotification" >> SyntaxErrorNotification >> inClass: STCommandLineHandler >> category: nil >> withCode: code >> doitFlag: nil >> errorMessage: message >> location: location. >> >> it looks like the usage for SyntaxErrorNotification should be cleaned >> reworked, >> any ideas what to do? >> I can not find a Opal OCSytaxEror or something like this. And I don't >> understand >> the workflow of raising and catching and reraising >> SyntaxErrorNotifications. >> >> >> >> >> >> > -- -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Nov. 24, 2015

Re: [Pharo-dev] Unable to accept changes in SyntaxErrorDebugger -> DNU: receiver of asSymbol is nil

by Nicolai Hess

2015-11-24 13:01 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > I will put it on the TODOâ¦. sadly I am a bit busy and canât postpone the > other things now to work on this. > No problem. An idea how this should be solved. > > On 20 Nov 2015, at 18:19, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > Any idea how to solve this: > > 16961 > <https://pharo.fogbugz.com/f/cases/16961/Unable-to-accept-changes-in-SyntaxE…> > Unable to accept changes in SyntaxErrorDebugger -> DNU: receiver of > asSymbol is nil > and > 16723 > <https://pharo.fogbugz.com/f/cases/16723/File-in-a-file-with-an-error-does-n…> > File in a file with an error does not set the doitFlag well > > If you file in some code that with syntactic errors, you can not fix the > code from within SyntaxErrorDebugger because > 1. the doitflag is nil, and If we would change this, init it with true... > 2. ... the category is nil > > From where it is used and comments like: > > notify: message at: location in: code > self flag: #hack. > "Should use the new OPalWarnings directly instead of recreating a > SyntaxErrorNotification" > SyntaxErrorNotification > inClass: STCommandLineHandler > category: nil > withCode: code > doitFlag: nil > errorMessage: message > location: location. > > it looks like the usage for SyntaxErrorNotification should be cleaned > reworked, > any ideas what to do? > I can not find a Opal OCSytaxEror or something like this. And I don't > understand > the workflow of raising and catching and reraising > SyntaxErrorNotifications. > > > > > >

Nov. 24, 2015