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

Re: [Pharo-dev] Transcript needs your love

by Igor Stasenko

On 8 May 2015 at 19:15, Ben Coman <btc(a)openinworld.com> wrote: > > > On Sat, May 9, 2015 at 12:21 AM, Alain Rastoul <alf.mmm.cat(a)gmail.com> > wrote: > >> Le 08/05/2015 16:16, Eliot Miranda a Ã©crit : >> >>> Hi, >>> >>> if one uses a at doit transcript then no special action is required >>> to get output to appear beyond sending flush to Transcript right? So any >>> solution that requires special action to get the moronic transcript to work >>> us broken. We should fix the transcript, not expect every application to >>> work around a bug. >>> >>> Eliot (phone) >>> >>> Yes using World dooneCycle is bad, but forking another process not bad >> IMHO: >> >> There is probably a solution to make the Transcript less moronic and >> refresh the world >> (it seems very different from Squeak transcript) but it would be an >> uncomplete specific-to-Transcript solution. >> >> The first thing I did when I tried Stef's example in Squeak was trying to >> move the window (it was >> a bit overlapped by my workspace) but I couldn't. >> >> If we do >> [ | m | >> [ m := BorderedMorph new borderColor: (Color yellow) . >> m position: 0@0. >> m openInWorld . >> 1 to: 500 do: [ :i | m position: i@i . >> 1 milliSeconds asDelay wait ] >> ] ensure: [ m delete ] . >> ] value >> we see nothing. >> if we replace value by fork, we can see a morph moving , because of the >> way Morphic world runs >> you know that of course, it's just that this example does not sound nice >> to me too. >> >> > >> Wouldn't it be better to execute do-it (s) systematically in another >> process ? >> > > This is an interesting idea. Actually if you DebugIt you already get a > separate process, so always forking a separate process for DoIts could be > considered more consistent. What would be the downside of doing this? > cheers -ben > > aside of numerous complaints 'now nothing is works the way it used to be'? i guess none. :) > and have a friendly way to control those processes, a bit similar to what >> happens when you launch your program in other IDEs like eclipse, visual >> studio, it starts another process ? >> >> And to start, with a simple right-click menu option : 'Do it async' to >> experiment >> > > I'd go the other way and make the forking 'DoIt' default, and while we > test it out, have a backup menu item 'DoIt within system UI loop'. > > >> (from a recent discussion, may be few problems with the inspector, >> but that's another point) >> > > The Pharo philosophy is to press forward. If it forces a few UI threading > issues into the light, that could be beneficial overall. > > > Now to the Squeak/Pharo difference. Squeak does this... > TranscriptStream>>show: > TranscriptStream>>endEntry > TranscriptStream>>changed: > DependentsArray>>do: > TranscriptStream>>changed: > PluggableTextMorphPlus>>update: > PluggableTextMorph>>update: > Morph>>refreshWorld > PasteUpMorph>>displayWorldSafely: > > First, Pharo's PluggableTextMorph>>update: does not call #refreshWorld. > Second, Pharo replaced TranscriptStream with ThreadSafeTranscript. This > behaviour has been present since at least build 20000 (I could not find an > earlier one). Further, the fix [1] for the "Transcript red screen of > death" occurring just before Pharo 3 release ensures the Transcript display > is updated only once each Morphic cycle (which has the side effect of > making calls to #show: faster.) > > [1] https://pharo.fogbugz.com/default.asp?13032 > > cheers -ben > > >> >> I don't know how it works under other smalltalks, does it blocks under >> VisualWorks when you execute some do-it ? >> >> >> >> -- >> Regards, >> >> Alain >> >> >> > -- Best regards, Igor Stasenko.

May 8, 2015

Re: [Pharo-dev] Transcript needs your love

by Eliot Miranda

On Fri, May 8, 2015 at 9:21 AM, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > Le 08/05/2015 16:16, Eliot Miranda a Ã©crit : > >> Hi, >> >> if one uses a at doit transcript then no special action is required >> to get output to appear beyond sending flush to Transcript right? So any >> solution that requires special action to get the moronic transcript to work >> us broken. We should fix the transcript, not expect every application to >> work around a bug. >> >> Eliot (phone) >> >> Yes using World dooneCycle is bad, but forking another process not bad > IMHO: > > There is probably a solution to make the Transcript less moronic and > refresh the world > (it seems very different from Squeak transcript) but it would be an > uncomplete specific-to-Transcript solution. > Why? Why wouldn't it e a general solution that was available to any morph that wanted to update its contents immediately? > > The first thing I did when I tried Stef's example in Squeak was trying to > move the window (it was > a bit overlapped by my workspace) but I couldn't. > > If we do > [ | m | > [ m := BorderedMorph new borderColor: (Color yellow) . > m position: 0@0. > m openInWorld . > 1 to: 500 do: [ :i | m position: i@i . > 1 milliSeconds asDelay wait ] > ] ensure: [ m delete ] . > ] value > we see nothing. > if we replace value by fork, we can see a morph moving , because of the > way Morphic world runs > you know that of course, it's just that this example does not sound nice > to me too. > > Wouldn't it be better to execute do-it (s) systematically in another > process ? > I find this faintly absurd. This is, in the English phrase, the tail wagging the dog. You don;t know how many issues executing doits in their own process will cause (it could break Monticello package update for example, when running package postscripts, it could prevent doits doing simple things, for example) all for want of the transcript updating itself. So instead of fixing the problem we're considering introducing huge unknowns in a core piece of the system? I think that's a little mad. > and have a friendly way to control those processes, a bit similar to what > happens when you launch your program in other IDEs like eclipse, visual > studio, it starts another process ? > > And to start, with a simple right-click menu option : 'Do it async' to > experiment > (from a recent discussion, may be few problems with the inspector, > but that's another point) > > I don't know how it works under other smalltalks, does it blocks under > VisualWorks when you execute some do-it ? > > > > -- > Regards, > > Alain > > > -- best, Eliot

May 8, 2015

Re: [Pharo-dev] Transcript needs your love

by Ben Coman

On Sat, May 9, 2015 at 12:21 AM, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > Le 08/05/2015 16:16, Eliot Miranda a Ã©crit : > >> Hi, >> >> if one uses a at doit transcript then no special action is required >> to get output to appear beyond sending flush to Transcript right? So any >> solution that requires special action to get the moronic transcript to work >> us broken. We should fix the transcript, not expect every application to >> work around a bug. >> >> Eliot (phone) >> >> Yes using World dooneCycle is bad, but forking another process not bad > IMHO: > > There is probably a solution to make the Transcript less moronic and > refresh the world > (it seems very different from Squeak transcript) but it would be an > uncomplete specific-to-Transcript solution. > > The first thing I did when I tried Stef's example in Squeak was trying to > move the window (it was > a bit overlapped by my workspace) but I couldn't. > > If we do > [ | m | > [ m := BorderedMorph new borderColor: (Color yellow) . > m position: 0@0. > m openInWorld . > 1 to: 500 do: [ :i | m position: i@i . > 1 milliSeconds asDelay wait ] > ] ensure: [ m delete ] . > ] value > we see nothing. > if we replace value by fork, we can see a morph moving , because of the > way Morphic world runs > you know that of course, it's just that this example does not sound nice > to me too. > > > Wouldn't it be better to execute do-it (s) systematically in another > process ? > This is an interesting idea. Actually if you DebugIt you already get a separate process, so always forking a separate process for DoIts could be considered more consistent. What would be the downside of doing this? cheers -ben > and have a friendly way to control those processes, a bit similar to what > happens when you launch your program in other IDEs like eclipse, visual > studio, it starts another process ? > > And to start, with a simple right-click menu option : 'Do it async' to > experiment > I'd go the other way and make the forking 'DoIt' default, and while we test it out, have a backup menu item 'DoIt within system UI loop'. > (from a recent discussion, may be few problems with the inspector, > but that's another point) > The Pharo philosophy is to press forward. If it forces a few UI threading issues into the light, that could be beneficial overall. Now to the Squeak/Pharo difference. Squeak does this... TranscriptStream>>show: TranscriptStream>>endEntry TranscriptStream>>changed: DependentsArray>>do: TranscriptStream>>changed: PluggableTextMorphPlus>>update: PluggableTextMorph>>update: Morph>>refreshWorld PasteUpMorph>>displayWorldSafely: First, Pharo's PluggableTextMorph>>update: does not call #refreshWorld. Second, Pharo replaced TranscriptStream with ThreadSafeTranscript. This behaviour has been present since at least build 20000 (I could not find an earlier one). Further, the fix [1] for the "Transcript red screen of death" occurring just before Pharo 3 release ensures the Transcript display is updated only once each Morphic cycle (which has the side effect of making calls to #show: faster.) [1] https://pharo.fogbugz.com/default.asp?13032 cheers -ben > > I don't know how it works under other smalltalks, does it blocks under > VisualWorks when you execute some do-it ? > > > > -- > Regards, > > Alain > > >

May 8, 2015

Re: [Pharo-dev] Genie plugin strikes back!

by Igor Stasenko

On 8 May 2015 at 19:09, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > Am Freitag, 8. Mai 2015 schrieb Igor Stasenko : > >> Just cloning pharo-vm repo on windows 7, got this: >> >> >> error: unable to create file >> mc/VMMaker.oscog.package/GeniePlugin.class/instance >> >> /primSameClassAbsoluteStrokeDistanceMyPoints.otherPoints.myVectors.otherVectors. >> >> mySquaredLengths.otherSquaredLengths.myAngles.otherAngles.maxSizeAndReferenceFla >> g.rowBase.rowInsertRemove.rowInsertRemoveCount..st (No such file or >> directory) >> >> :( >> >> i suspecting windows refuses to create a file because its name is too >> long? >> > > Yes, too long. You can ignore the error. > >> any ideas? >> > yeah, and i should be reading windows readme file, where it is already mentioned, before alerting mailing list :) > >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

May 8, 2015

Re: [Pharo-dev] Genie plugin strikes back!

by Nicolai Hess

Am Freitag, 8. Mai 2015 schrieb Igor Stasenko : > Just cloning pharo-vm repo on windows 7, got this: > > > error: unable to create file > mc/VMMaker.oscog.package/GeniePlugin.class/instance > > /primSameClassAbsoluteStrokeDistanceMyPoints.otherPoints.myVectors.otherVectors. > > mySquaredLengths.otherSquaredLengths.myAngles.otherAngles.maxSizeAndReferenceFla > g.rowBase.rowInsertRemove.rowInsertRemoveCount..st (No such file or > directory) > > :( > > i suspecting windows refuses to create a file because its name is too long? > Yes, too long. You can ignore the error. > any ideas? > > -- > Best regards, > Igor Stasenko. >

May 8, 2015

Windows version of 0-config scripts?

by Igor Stasenko

remind me please, is it broken, or never worked? trying: wget -O- get.pharo.org/30+vm |bash Downloading the latest 30 Image: http://files.pharo.org/get-files/30/pharo.zip bash: line 51: mktemp: command not found -- Best regards, Igor Stasenko.

May 8, 2015

Genie plugin strikes back!

by Igor Stasenko

Just cloning pharo-vm repo on windows 7, got this: error: unable to create file mc/VMMaker.oscog.package/GeniePlugin.class/instance /primSameClassAbsoluteStrokeDistanceMyPoints.otherPoints.myVectors.otherVectors. mySquaredLengths.otherSquaredLengths.myAngles.otherAngles.maxSizeAndReferenceFla g.rowBase.rowInsertRemove.rowInsertRemoveCount..st (No such file or directory) :( i suspecting windows refuses to create a file because its name is too long? any ideas? -- Best regards, Igor Stasenko.

May 8, 2015

Re: [Pharo-dev] Transcript needs your love

by Alain Rastoul

Le 08/05/2015 16:16, Eliot Miranda a Ã©crit : > Hi, > > if one uses a at doit transcript then no special action is required to get output to appear beyond sending flush to Transcript right? So any solution that requires special action to get the moronic transcript to work us broken. We should fix the transcript, not expect every application to work around a bug. > > Eliot (phone) > Yes using World dooneCycle is bad, but forking another process not bad IMHO: There is probably a solution to make the Transcript less moronic and refresh the world (it seems very different from Squeak transcript) but it would be an uncomplete specific-to-Transcript solution. The first thing I did when I tried Stef's example in Squeak was trying to move the window (it was a bit overlapped by my workspace) but I couldn't. If we do [ | m | [ m := BorderedMorph new borderColor: (Color yellow) . m position: 0@0. m openInWorld . 1 to: 500 do: [ :i | m position: i@i . 1 milliSeconds asDelay wait ] ] ensure: [ m delete ] . ] value we see nothing. if we replace value by fork, we can see a morph moving , because of the way Morphic world runs you know that of course, it's just that this example does not sound nice to me too. Wouldn't it be better to execute do-it (s) systematically in another process ? and have a friendly way to control those processes, a bit similar to what happens when you launch your program in other IDEs like eclipse, visual studio, it starts another process ? And to start, with a simple right-click menu option : 'Do it async' to experiment (from a recent discussion, may be few problems with the inspector, but that's another point) I don't know how it works under other smalltalks, does it blocks under VisualWorks when you execute some do-it ? -- Regards, Alain

May 8, 2015

Re: [Pharo-dev] Transcript needs your love

by Igor Stasenko

Either you run doits in separate process (as Sven demonstrated), or you run it in UI process, blocking the rest of UI. Stef, you complaining about not being able to see output of code that blocks a process from doing such output. I wonder how you going to fix that, and how much other complaints you will face, once you will fix that. The solution could be to change the whole UI paradigm and separate rendering from UI handling, which means that display no longer depends on what UI process are busy with. That means a lot of work revising the way how morphic delivers content to the real estate.. Only then Transcript could work as expected, scheduling screen updates into rendering/screen update schedule, as well as many other applications that can benefit from separating rendering pipeline from event handling. But alas, even then, you won't be fully satisfied, since VM is single threaded and it can be busy only with one thing at a time, either updating your screen, or advancing in progress of an action you instructed it to perform. And i remember many complaints of the past, where people was really annoyed that 'Transcript is tooooo damn slow' because often for VM it takes more cycles to update transcript than to do any progress with computation you run.. So, the choice is yours: you can run simulation that force updates of its progress every microsecond on screen (so fast, that human eye cannot notice) and as result your simulation takes hours rather than seconds, or you block the updates , or at least do not update that often (for human eyes updating more than 25 times per second is overkill). On 8 May 2015 at 16:16, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi, > > if one uses a at doit transcript then no special action is required to > get output to appear beyond sending flush to Transcript right? So any > solution that requires special action to get the moronic transcript to work > us broken. We should fix the transcript, not expect every application to > work around a bug. > > Eliot (phone) > > On May 8, 2015, at 6:15 AM, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > > > Le 08/05/2015 11:34, stepharo a Ã©crit : > >> Hi guys > >> > >> the Transcript in Pharo is that it's not asynchronous so I can't use it > >> in VM development to show the current progress of the simulation. For > >> example: > >> 1 to: 100 do: [ :i | > >> 0.1 seconds asDelay wait. > >> Transcript show: 'x'. ] > >> => on Squeak, this shows a x every 0.1 second in the Transcript > >> => on Pharo, nothing happens during 10 seconds then all the x are shown. > >> > >> https://pharo.fogbugz.com/default.asp?15515 > > Yes, as do it are evaluated in the World morphic process, running in a > forked process or sending World doOneCycle in the loop solve the problem. > > > > Probably in squeak, in Transcript this is done somewhere under the hood. > > > > via dependents ? > > > > TranscriptStream>>endEndtry > > "Display all the characters since the last endEntry, and reset the > stream" > > self semaphore critical:[ > > self changed: #appendEntry. > > self reset. > > ]. > > > > Object>>changed: aParameter > > self dependents do: [:aDependent | aDependent update: aParameter] > > > > And probably not doOnecycle since you cannot do anything else during > execution (clicking or moving windows). > > > > > > -- > > Regards, > > > > Alain > > > > > > -- Best regards, Igor Stasenko.

May 8, 2015

Re: [Pharo-dev] [Reflectivity] Progress for Breakpoints

by Marcus Denker

> On 08 May 2015, at 14:58, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 08 May 2015, at 11:52, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> Hi, >> >> 50040 now has these changes: >> >> - Smart Suggestions used to re-parse even when the editor window is not dirty. >> ==> now we work on the AST we get from the method in this case. >> - Reflectivity: FIX: when removing the last link, make sure to recompile the method. >> - Breakpoints: added (and simplified a bit) the class Breakpoint from Claraâs SmartBreakpoint >> project. >> >> Next: integrate enable setting/removing breakpoints using suggestions. >> > > https://pharo.fogbugz.com/f/cases/15516/add-suggestion-for-breakpoint <https://pharo.fogbugz.com/f/cases/15516/add-suggestion-for-breakpoint> > > this is of course completely untestedâ¦ it works only when there is no unaccepted > text in the editor and maybe only within Nautilus. > > And of course existing breakpoints are not yet in any form visualised in the editor. This is in 50041. Please use with careâ¦ still needs work to be really usable. Marcus

May 8, 2015