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

Re: [Pharo-dev] Option for as-in-moose debugger layout

by Denis Kudriashov

2016-07-29 13:28 GMT+02:00 Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com>: > Hi, > > At the integration it was the default but it was changed since more > people found the old way more convenient. > > But I agree it should be a setting :) > I was think that problem was related to Mooc videos which was made with classic debugger look

July 29, 2016

Re: [Pharo-dev] Option for as-in-moose debugger layout

by Cyril Ferlicot D.

Le 27/07/2016 Ã 15:04, Denis Kudriashov a Ã©crit : > I want it too (but I never try it). > > And maybe it is good time to force people taste it as default? (with > setting to return classic one) > Hi, At the integration it was the default but it was changed since more people found the old way more convenient. But I agree it should be a setting :) > -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

July 29, 2016

Re: [Pharo-dev] Option for as-in-moose debugger layout

by webwarrior

I second this. Have been using GTDebugger since Pharo3 and always found its layout more convenient. -- View this message in context: http://forum.world.st/Option-for-as-in-moose-debugger-layout-tp4908132p4908… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 29, 2016

Re: [Pharo-dev] [Ann] Remote debugging tools

by Denis Kudriashov

2016-07-29 10:45 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > That sounds wonderful! Thank you very much! Is the new code online? Not yet. Probably I will finish it next week.

July 29, 2016

Re: [Pharo-dev] [Ann] Remote debugging tools

by Norbert Hartl

> Am 29.07.2016 um 10:20 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: > > Hi Norbert. > > 2016-07-19 16:11 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: > > I see big room for optimizations here. > Look at very small unit of communication: delivering integer result (from [1+2] evaluation). Following object is responsible for this: > > request := SeamlessDeliverResultRequest result: (SeamlessReturnValueResult with: 3) to: (SeamlessRequestContextReference id: 4 peerId: UUID new) . > stream := ByteArray new writeStream. > FLSerializer newDefault serialize: request on: stream. > bytes := stream contents. > bytes size. "==> 412" > (ObjectTraveler on: request ) countReferences "==>10" > > Last line shows that only 10 objects consists full object graph of request. And Fuel serialization takes for it 412 bytes. > It definitely could be improved with specialized serialization protocol. Also it could allow object traversal once which will lead to another performance improvements. > > I start implement optimized protocol and I got really nice results. I reduce size of packet in my example to 16 bytes. I not measure performance yet but it should be better too. Also new protocol will allow application specific optimisations. > So soon we will have really usable tools for your case with slow network. That sounds wonderful! Thank you very much! Is the new code online? Norbert

July 29, 2016

Re: [Pharo-dev] [Ann] Remote debugging tools

by Pavel Krivanek

2016-07-29 10:20 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi Norbert. > > 2016-07-19 16:11 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> >> I see big room for optimizations here. >> Look at very small unit of communication: delivering integer result (from >> [1+2] evaluation). Following object is responsible for this: >> >> request := SeamlessDeliverResultRequest result: >> (SeamlessReturnValueResult with: 3) to: (SeamlessRequestContextReference >> id: 4 peerId: UUID new) . >> stream := ByteArray new writeStream. >> FLSerializer newDefault serialize: request on: stream. >> bytes := stream contents. >> bytes size. "==> 412" >> (ObjectTraveler on: request ) countReferences "==>10" >> >> >> Last line shows that only 10 objects consists full object graph of >> request. And Fuel serialization takes for it 412 bytes. >> It definitely could be improved with specialized serialization protocol. >> Also it could allow object traversal once which will lead to another >> performance improvements. >> > > I start implement optimized protocol and I got really nice results. I > reduce size of packet in my example to 16 bytes. I not measure performance > yet but it should be better too. Also new protocol will allow application > specific optimisations. > So soon we will have really usable tools for your case with slow network. > Nice!

July 29, 2016

Re: [Pharo-dev] [Ann] Remote debugging tools

by Denis Kudriashov

Hi Norbert. 2016-07-19 16:11 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > I see big room for optimizations here. > Look at very small unit of communication: delivering integer result (from > [1+2] evaluation). Following object is responsible for this: > > request := SeamlessDeliverResultRequest result: (SeamlessReturnValueResult > with: 3) to: (SeamlessRequestContextReference id: 4 peerId: UUID new) . > stream := ByteArray new writeStream. > FLSerializer newDefault serialize: request on: stream. > bytes := stream contents. > bytes size. "==> 412" > (ObjectTraveler on: request ) countReferences "==>10" > > > Last line shows that only 10 objects consists full object graph of > request. And Fuel serialization takes for it 412 bytes. > It definitely could be improved with specialized serialization protocol. > Also it could allow object traversal once which will lead to another > performance improvements. > I start implement optimized protocol and I got really nice results. I reduce size of packet in my example to 16 bytes. I not measure performance yet but it should be better too. Also new protocol will allow application specific optimisations. So soon we will have really usable tools for your case with slow network.

July 29, 2016

Re: [Pharo-dev] newly introduced problem in Pharo5.0 running headless vm (Ubuntu 14.04)

by stepharo

Yes I saw it too. Stef Le 28/7/16 Ã 23:30, Dale Henrichs a Ã©crit : > Thanks Nicolai ... that looks exactly like my problem ... I see that > this report is from earlier in July, so it presumably will crop up > randomly .. > > Dale > > On 07/28/2016 02:24 PM, Nicolai Hess wrote: >> Hi Dale, >> >> I think this problem already exists in Pharo 5.0, see bug report >> 18706 >> <https://pharo.fogbugz.com/f/cases/18706/Build-of-Pharo5-is-broken> >> Build of Pharo5 is broken >> >> >> >> 2016-07-28 22:58 GMT+02:00 Dale Henrichs >> <dale.henrichs(a)gemtalksystems.com >> <mailto:dale.henrichs@gemtalksystems.com>>: >> >> Three additional pieces of info ... >> >> 1. 'canvas' is an instance variable in the WorldState instance >> and is probably a stale instance along with a stale process >> 2. If I bring up the image headful, I get no errors and then if I >> save it, the load works properly ... >> 3. If I run the load on Pharo.image directly without the initial >> ` ./pharo Pharo.image save xxx`, it loads properly >> >> This sequence is in a script that I ship to end users, so if >> `./pharo Pharo.image save xxx` is intended to work, I will wait >> patiently for a bugfix (and submit a bug if necessary -- I >> originally thought that this might have been recently introduced, >> but now I think that this is a bug that is possibly just recently >> exposed) otherwise, I'll have to rewrite the scripts to not rely >> on `./pharo Pharo.image save xxx`. >> >> Dale >> >> On 07/28/2016 01:49 PM, Dale Henrichs wrote: >> >> This sequence of commands was working yesterday and is broken >> today: >> >> ./pharo Pharo.image save xxx; ./pharo xxx.image --quit >> --save ./boom.st <http://boom.st> >> >> The contents of boom.st <http://boom.st> is the following: >> >> Metacello new >> baseline: 'Metacello'; >> repository: >> 'github://dalehenrich/metacello-work:master/repository'; >> onConflict: [:ex | ex allow]; >> load: #( 'batch' ). >> >> I've attached to PharoDebug.log ... The Pharo.image is >> freshly downloaded along with the vm. Needless to say, the >> expression above works when run with a GUI. Oddly enough the >> receiver of #finish looks to be a temp named 'canvas' in the >> middle of the WorkState>>displayWorld:submorphs: method ... >> two lines earlier the' canvas' temp had to have a valid >> value, so this has the look of a zombie process of some sort >> that is being brought to life at the wrong moment ... >> >> stdout for the run follows. >> >> Dale >> >> foos:voyage>./pharo Pharo.image save xxx; ./pharo xxx.image >> --quit --save ./boom.st <http://boom.st> >> Error: MessageNotUnderstood: receiver of "finish" is nil >> UndefinedObject(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.... >> >> >> >> >

July 29, 2016

Re: [Pharo-dev] Bizarre Text Selection in Pharo 5.0

by Max Leske

> On 29 Jul 2016, at 03:01, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Max Leske wrote >> Yes, regularly :) > > Arghh. This is a big-time workflow killer. Is there an issue or should I > create one? I found this case [1], but itâs old and doesnât describe our specific problem I think. Please open a new issue (you can add me to the notification list). Cheers, Max 1: https://pharo.fogbugz.com/f/cases/4579/check-cursor-movement-selection-prov… > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Bizarre-Text-Selection-in-Pharo-5-0-tp4908498p4908572… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

July 29, 2016

copyAllTo:

by Hilaire

copyAllTo: does not do what its comment says: '/tmp/toto/titi' asFileReference ensureCreateDirectory. '/tmp/dest' asFileReference ensureCreateDirectory. '/tmp/toto' asFileReference copyAllTo: '/tmp/dest' asFileReference 'toto' directory is not copied contrary to what wrote the method comment. What is wrong, the comment or the method? Hilaire copyAllTo: aResolvable "Performs a deep copy of the receiver, to a location specified by the argument. If the receiver is a file, the file will be copied; if a directory, the directory and its contents will be copied recursively. The argument must be a reference that doesn't exist; it will be created by the copy." -- Dr. Geo http://drgeo.eu

July 29, 2016