August 2016 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 3c4689: 60174

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 3c46899a2ee045db8515d52e3e13ed1c340a7e56 https://github.com/pharo-project/pharo-core/commit/3c46899a2ee045db8515d52e… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-08-09 (Tue, 09 Aug 2016) Changed paths: M AST-Core.package/RBParser.class/instance/private-parsing/parseBlock.st A AST-Core.package/RBSequenceNode.class/instance/adding nodes/addFaultyNode_.st M AST-Tests-Core.package/RBParserTest.class/instance/tests parsing/testParseUnfinishedBlockWithFaultyBody.st M Monticello-Tests.package/MCStWriterTest.class/instance/data/expectedClassMethodDefinition.st M Monticello-Tests.package/MCStWriterTest.class/instance/data/expectedMethodDefinition.st M Monticello-Tests.package/MCStWriterTest.class/instance/testing/testClassMethodDefinition.st M Monticello-Tests.package/MCStWriterTest.class/instance/testing/testMethodDefinition.st M OpalCompiler-Core.package/extension/Context/instance/isBlockReturn_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60173.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60174.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60173.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60174.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60174 18890 Parser cant not parse faulty or unfinished blocks with return caret https://pharo.fogbugz.com/f/cases/18890 18893 MCStWriterTest>>#expectedClassMethodDefinition will always fail on bootstrapped image https://pharo.fogbugz.com/f/cases/18893 18892 simplify isBlockReturn: to use encoder https://pharo.fogbugz.com/f/cases/18892 http://files.pharo.org/image/60/60174.zip

Aug. 9, 2016

Re: [Pharo-dev] Iceberg in general

by Norbert Hartl

I've checked again on pharo6 and get the same error. - downloaded pharo6 - Metacello new baseline: 'Iceberg'; repository: 'github://npasserini/iceberg:stable'; load. - openend UI via tools/Iceberg - click "Clone new repository" Same error as in pharo5. Cannot parse URL I've created an issue Norbert > Am 09.08.2016 um 14:00 schrieb Nicolas Passerini <npasserini(a)gmail.com>: > > Hi Norbert, > > Up to date, Iceberg has only been developed/used/tested on Pharo 6.0, please look at the prerrequisites in https://github.com/npasserini/iceberg <https://github.com/npasserini/iceberg>. I can not tell if it would work on Pharo 5.0. > > Either way, if you could submit a bug report I will happily pay a look at it. > > On Tue, Aug 9, 2016 at 1:55 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: > > > On Tue, Aug 9, 2016 at 1:39 PM, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: > I'm using pharo5 and I wonder we is this version marked as stable > > The readme states: > > "This is still a prototype and is not yet ready for production, but you are invited to try it and provide feedback. " > > Note however that I've successfully started using it for smaller project(s) that are hosted on GitHub. Of course there's a lot of issues https://github.com/npasserini/iceberg/issues <https://github.com/npasserini/iceberg/issues> , but it can be forced to work if you are willing to live on the edge. :) > > Regarding your error, it would be best to submit a bug report. > > Peter >

Aug. 9, 2016

Re: [Pharo-dev] Bloc, Bloc 2 and Brick

by stepharo

Le 7/8/16 Ã 17:01, webwarrior a Ã©crit : > stepharo wrote >> ... >> >> In June we spent three days to understand if we should merge Bloc2 >> into Bloc and we decided the inverse because >> his implementation is based on SDL and a separate window) it does >> not suffer from the morphic plague. So for example >> the event bubbling is nice and clean. The idea is to be able to use >> one window (morphic) to develop >> all the widgets and displayed in the SDL window needed up to the >> point where we can remove morphic. >> >> ... > Does that mean that Bloc will only work in separate window until Morphic is > fully replaced and removed from the image? Yes. > That would take many years I guess. Not really. Once we have nice widgets we can go fast. Especially since we started to do it by using things like Spec. > And before that, all tools like debugger etc. will open themselves in host > (Morphic) window? Yes. I can tell you that it was not an easy solution when I see the pain that alain got to make Bloc worked within morphic but the pay load was too high. Stef > > > > > -- > View this message in context: http://forum.world.st/Bloc-Bloc-2-and-Brick-tp4909112p4909861.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Aug. 9, 2016

Pharo5 Jenkins build crash

by Yann Dubois

Hi, Since Sunday, all build launched for Pharo 5 crashed I have this log message : CollectionIsEmpty: a Set() is emptySet(Collection)>>errorEmptyCollection Set(Collection)>>emptyCheck Set(Collection)>>anyOne Set(Collection)>>sum: TestCommandLineHandler>>informResults: TestCommandLineHandler>>runPackages TestCommandLineHandler>>activate TestCommandLineHandler class(CommandLineHandler class)>>activateWith: [ aCommandLinehandler activateWith: commandLine ] in PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in Block: [ aCommandLinehandler activateWith: commandLine ] BlockClosure>>on:do: PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument: [ self handleArgument: (self arguments ifEmpty: [ '' ] ifNotEmpty: [ :arguments | arguments first ]) ] in PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [ self... BlockClosure>>on:do: PharoCommandLineHandler(BasicCommandLineHandler)>>activate PharoCommandLineHandler>>activate PharoCommandLineHandler class(CommandLineHandler class)>>activateWith: [ super activateWith: aCommandLine ] in PharoCommandLineHandler class>>activateWith: in Block: [ super activateWith: aCommandLine ] NonInteractiveUIManager(UIManager)>>defer: PharoCommandLineHandler class>>activateWith: [ aCommandLinehandler activateWith: commandLine ] in BasicCommandLineHandler>>activateSubCommand: in Block: [ aCommandLinehandler activateWith: commandLine ] BlockClosure>>on:do: BasicCommandLineHandler>>activateSubCommand: BasicCommandLineHandler>>handleSubcommand BasicCommandLineHandler>>handleArgument: [ self handleArgument: (self arguments ifEmpty: [ '' ] ifNotEmpty: [ :arguments | arguments first ]) ] in BasicCommandLineHandler>>activate in Block: [ self... BlockClosure>>on:do: BasicCommandLineHandler>>activate [ self new activate ] in BasicCommandLineHandler class>>startUp: in Block: [ self new activate ] ./pharo $JOB_NAME.image config http://smalltalkhub.com/mc/NorbertHartl/Mustache/main ConfigurationOfMustache --install=bleedingEdge + ./pharo Pillar.image config http://smalltalkhub.com/mc/NorbertHartl/Mustache/main ConfigurationOfMustache --install=bleedingEdge 'Installing ConfigurationOfMustache bleedingEdge'Error: MessageNotUnderstood: receiver of "finish" is nilUndefinedObject(Object)>>error: [ :err :rcvr | | errCtx errMorph | errCtx := thisContext. [ errCtx := errCtx sender. "Search the sender chain to find the morph causing the problem" [ errCtx notNil and: [ errCtx receiver isMorph not ] ] whileTrue: [ errCtx := errCtx sender ]. "If we're at the root of the context chain then we have a fatal drawing problem" errCtx ifNil: [ ^ self handleFatalDrawingError: err ]. errMorph := errCtx receiver. "If the morph causing the problem has already the #drawError flag set, then search for the next morph above in the caller chain." errMorph hasProperty: #errorOnDraw ] whileTrue. errMorph setProperty: #errorOnDraw toValue: true. "Install the old error handler, so we can re-raise the error" rcvr error: err ] in WorldState>>displayWorldSafely: in Block: [ :err :rcvr | ... BlockClosure>>cull:cull: [ :ex | errorHandlerBlock cull: ex description cull: ex receiver ] in BlockClosure>>ifError: in Block: [ :ex | errorHandlerBlock cull: ex description cul...etc... BlockClosure>>cull: Context>>evaluateSignal: Context>>handleSignal: MessageNotUnderstood(Exception)>>signal UndefinedObject(Object)>>doesNotUnderstand: #finish WorldState>>displayWorld:submorphs: WorldMorph>>displayWorld [ aWorld displayWorld ] in WorldState>>displayWorldSafely: in Block: [ aWorld displayWorld ] BlockClosure>>on:do: BlockClosure>>ifError: WorldState>>displayWorldSafely: WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: WorldMorph>>doOneCycle [ [ World doOneCycle. Processor yield. false ] whileFalse: [ ] ] in MorphicUIManager>>spawnNewProcess in Block: [ [ World doOneCycle.... [ self value. Processor terminateActive ] in BlockClosure>>newProcess in Block: [ self value.... I think that the problem is in command line handler but I'm not sure. You can see the complete log, for example, at https://ci.inria.fr/pharo-contribution/job/Pillar/1715/PHARO=50,VERSION=sta…

Aug. 9, 2016

Re: [Pharo-dev] Iceberg in general

by Nicolas Passerini

Hi Norbert, Up to date, Iceberg has only been developed/used/tested on Pharo 6.0, please look at the prerrequisites in https://github.com/npasserini/iceberg. I can not tell if it would work on Pharo 5.0. Either way, if you could submit a bug report I will happily pay a look at it. On Tue, Aug 9, 2016 at 1:55 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > On Tue, Aug 9, 2016 at 1:39 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> I'm using pharo5 and I wonder we is this version marked as stable > > > The readme states: > > "This is still a prototype and is not yet ready for production, but you > are invited to try it and provide feedback. " > > Note however that I've successfully started using it for smaller > project(s) that are hosted on GitHub. Of course there's a lot of issues > https://github.com/npasserini/iceberg/issues , but it can be forced to > work if you are willing to live on the edge. :) > > Regarding your error, it would be best to submit a bug report. > > Peter >

Aug. 9, 2016

Re: [Pharo-dev] DNU with GT Debugger

by stepharo

Hi doru I sent you a drop box where you just have to click to repeat the problem. Let me know if this is enough. Else I should send you more scripts and files. Stef Le 9/8/16 Ã 12:07, Tudor Girba a Ã©crit : > Hi, > > Thanks for the report. Do you happen to have an image around? > > Doru > > >> On Aug 9, 2016, at 11:47 AM, stepharo <stepharo(a)free.fr> wrote: >> >> While trying to debug pillar I got a DNU when clicking on the raw pane (when the items was selected) >> >> DNU: >> >> presentation rawSelection is aLinkedList and it does not understand key >> >> >> >> >> 'From Pharo 6.0 of 13 May 2016 [Latest update: #60173] on 9 August 2016 at 11:45:10.355092 am'! >> >> !GTRawObjectVariablesBrowser methodsFor: 'private building' stamp: 'AndreiChis 4/26/2016 10:37'! >> variablesIn: composite >> ^ composite table >> showOnly: 50; >> shouldValidate: false; >> allowsRecursiveSearch: false; >> children: [ :assoc | >> assoc key = 'self' >> ifTrue: [ #() ] >> ifFalse: [ self variableValuePairsFor: assoc value ] ]; >> icon: [ :assoc | self iconFor: assoc value ]; >> display: [ :anObject | >> self rebuildCacheFor: anObject. >> self variableValuePairsFor: anObject ]; >> column: 'Variable' >> evaluated: [:assoc | ' ', (GTObjectPrinter new asNonTruncatedTextFrom: assoc key) ]; >> column: 'Value' >> evaluated: [:assoc | GTObjectPrinter new asTruncatedTextFrom: assoc value ] >> modified: [:newValue :assoc :presentation | >> self updateInstanceVariable: assoc key from: presentation entity basedOn: newValue. >> presentation update ]; >> morphicSelectionAct: [:list | list selection value browse ] >> icon: GLMUIThemeExtraIcons glamorousBrowse >> on: $b >> entitled: 'Browse'; >> morphicSelectionAct: [:list | list selection value inspect ] >> icon: GLMUIThemeExtraIcons glamorousInspect >> on: $i >> entitled: 'Inspect'; >> selectionAct: [:list | >> ((list selection pointersToExcept: { list selection }) >> reject: [ :each | each pointsOnlyWeaklyTo: list selection ]) inspect ] >> on: $t >> entitled: 'Open pointers to'; >> dynamicActionsOnSelection: [ :presentation | >> (presentation entity class hasInstVarNamed: presentation rawSelection key) >> >> ^^^^^^^^ here >> >> >> >> ifTrue: [ >> { >> GLMGenericAction new >> action: [:list | self systemNavigation browseAllAccessesTo: list rawSelection key from: list entity class ]; >> title: 'List methods using this variable'. >> GLMGenericAction new >> action: [:list | self systemNavigation browseAllStoresInto: list rawSelection key from: list entity class ]; >> title: 'List methods storing into this variable'. >> } >> ] >> ifFalse: [ #() ] ]! ! >> >> <GTRawObjectVariablesBrowser-variablesIn.st> > -- > www.tudorgirba.com > www.feenk.com > > "Reasonable is what we are accustomed with." > > >

Aug. 9, 2016

Epicea redoVisitor does not handle protocol changes

by stepharo

Hi I just tried to replay a change today in Pharo60 and I got an error in epicea. EpRedoVisitor>>visitEvent: aChange ^ self error: 'Should not be reached'. EpRedoVisitor>>visitCodeChange: aChange "Default behavior for any change." ^ self visitEvent: aChange EpRedoVisitor>>visitBehaviorChange: aChange ^ self visitCodeChange: aChange EpRedoVisitor>>visitProtocolChange: aProtocolAddition ^ self visitBehaviorChange: aProtocolAddition. visitProtocolAddition: aProtocolAddition ^ self visitProtocolChange: aProtocolAddition Apparently it was a EpProtocolAddition And the RedoVisitor does not handle them. I do not have the time to check further - I just want to rescue my code for now. Stef

Aug. 9, 2016

Re: [Pharo-dev] Iceberg in general

by Peter UhnÃ¡k

On Tue, Aug 9, 2016 at 1:39 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > I'm using pharo5 and I wonder we is this version marked as stable The readme states: "This is still a prototype and is not yet ready for production, but you are invited to try it and provide feedback. " Note however that I've successfully started using it for smaller project(s) that are hosted on GitHub. Of course there's a lot of issues https://github.com/npasserini/iceberg/issues , but it can be forced to work if you are willing to live on the edge. :) Regarding your error, it would be best to submit a bug report. Peter

Aug. 9, 2016

Re: [Pharo-dev] Iceberg in general

by Guille Polito

I'm using it in Pharo6 without problems. No idea about Pharo5... -------- Original Message -------- > I played a little further with Iceberg and not even creating a local repository worked. I'm using pharo5 and I wonder we is this version marked as stable and if there is an ETA for a first stable version. > > Norbert > >

Aug. 9, 2016

about endless loop handling

by stepharo

Hi does it look like a taboo or we will never have decent endless loop handling? Stef

Aug. 9, 2016