- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Transcript needs your love

by ClÃ©ment Bera

2015-05-08 19:39 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Fri, May 8, 2015 at 10:32 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> On 8 May 2015 at 19:22, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >>> >>> >>> 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. >>> >>> >> True.. but this is only highlights how deeply broken the overall system >> around UI are. >> Why would MC postscripts need to run in UI thread? Aren't they should be >> completely independent of having UI process at all (unless we're talking >> about packages that actually providing these facilities) ? >> I know that running doits in separate process is 'bad idea' (tm). Only >> because of original bad idea in the past to not care about clearly separate >> things and rely on de-facto non-linear and intricate dependencies in >> system, that established over the years, because of lack of design and >> planning. >> >> I know it may sound like an arrogant moron blabbery, but it doesn't means >> i wrong :) >> > > I still don't hear any rationale for the transcript not updating itself > when it does flush/endEntry:. I still don't hear any rationale for the > morphic transcript behaving differently to a stdout transcript. In that > case, it only makes sense to fix the transcript, right? > That was my original point. I would like a tool, as used to be the Transcript, that has the same behavior than the stdout transcript but shows the stream in the image instead of the command line. In Pharo stdout is not broken. It works fine and I use it often. You can start Pharo from the command line and try the do-it: 1 to: 100 do: [ :i | 0.1 seconds asDelay wait. FileStream stdout << 'x'. ] x is displayed every 100 ms on the command line. Only the Transcript has a different behavior, which is not compatible with the use cases of VM development. > > >> >>> >>>> 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 >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > best, > Eliot >

May 8, 2015

Re: [Pharo-dev] Testers needed! Re: Athens BitBlt bug?

by Nicolai Hess

2015-05-08 11:06 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Thanks. > > I check your scenario on Windows7. > All work like you said. And with your fix artifacts are disappeared > Thank you for testing. > > 2015-05-08 11:25 GMT+03:00 Nicolai Hess <nicolaihess(a)web.de>: > >> >> >> 2015-05-08 10:05 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >>> Hi >>> >>> 2015-05-08 1:43 GMT+03:00 Nicolai Hess <nicolaihess(a)web.de>: >>> >>>> load bleeding edge from Bloc >>> >>> >>> Code for loading it can be very helpfull >>> >> >> :) >> >> Gofer new >> smalltalkhubUser: 'Pharo' project: 'Bloc'; >> load; >> configurationOf: 'Bloc'; >> loadBleedingEdge >> >> >> >

May 8, 2015

Re: [Pharo-dev] Windows version of 0-config scripts?

by Nicolai Hess

Works for me on windows 7 (in a msys console). 2015-05-08 19:40 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > > > On Sat, May 9, 2015 at 1:06 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> 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 >> >> > Works for me on OSX. > cheers -ben > >

May 8, 2015

Re: [Pharo-dev] Windows version of 0-config scripts?

by Igor Stasenko

On 8 May 2015 at 19:40, Ben Coman <btc(a)openinworld.com> wrote: > > > On Sat, May 9, 2015 at 1:06 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> 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 >> >> > Works for me on OSX. > Oh, dear.. i am happy for you :) But as i noticed the problem is that i want it to work on Windows (tm).. not on OS Ten. > cheers -ben > > -- Best regards, Igor Stasenko.

May 8, 2015

Re: [Pharo-dev] Transcript needs your love

by Igor Stasenko

On 8 May 2015 at 20:23, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Fri, May 8, 2015 at 11:16 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> On 8 May 2015 at 20:00, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >>> >>> >>> On Fri, May 8, 2015 at 10:52 AM, Igor Stasenko <siguctua(a)gmail.com> >>> wrote: >>> >>>> >>>> >>>> On 8 May 2015 at 19:39, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>> >>>>> >>>>> >>>>> On Fri, May 8, 2015 at 10:32 AM, Igor Stasenko <siguctua(a)gmail.com> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 8 May 2015 at 19:22, Eliot Miranda <eliot.miranda(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>> >>>>>> True.. but this is only highlights how deeply broken the overall >>>>>> system around UI are. >>>>>> Why would MC postscripts need to run in UI thread? Aren't they should >>>>>> be completely independent of having UI process at all (unless we're talking >>>>>> about packages that actually providing these facilities) ? >>>>>> I know that running doits in separate process is 'bad idea' (tm). >>>>>> Only because of original bad idea in the past to not care about clearly >>>>>> separate things and rely on de-facto non-linear and intricate dependencies >>>>>> in system, that established over the years, because of lack of design and >>>>>> planning. >>>>>> >>>>>> I know it may sound like an arrogant moron blabbery, but it doesn't >>>>>> means i wrong :) >>>>>> >>>>> >>>>> I still don't hear any rationale for the transcript not updating >>>>> itself when it does flush/endEntry:. I still don't hear any rationale for >>>>> the morphic transcript behaving differently to a stdout transcript. In >>>>> that case, it only makes sense to fix the transcript, right? >>>>> >>>>> >>>> Transcript is not an UI element, it is a stream. Period. >>>> >>> >>> Ah, a write-only invisible transcript. Riiiight. Really useful to log >>> output to somewhere no one can see it. Riiight. >>> >> No, Igor, the Transcript is a UI element and a stream. It is a place to >>> log textual output where the programmer can see it. It is Smalltalk's >>> standard output console. If one ants a stream which will record output one >>> can use a file. If one wants to see it in real time, one uses a transcript. >>> >>> >> what if i want to log to stdout.. why i need morphic UI element? >> > > I've said my piece. You're making me laugh. Keep digging. > > What's so funny? Would you be against having a widget, called , for instance 'stream contents viewer', that can be connected to any writeable stream and which display contents of that stream? And then sure thing, once we got such widget, it wouldn't be a much of a hassle to hook it with transcript stream and everyone is happy and joyful. Again, what is so funny in redirecting transcript to stdout or file? What if i run things on a server and can only connect via console and need to be aware of what happening with my image? Does that sounds funny? > Look, understand me wrong not. ;) >> I am not against having a UI element that showing the contents of >> transcript (or any other stream, why not?) and updates it as soon as >> possible (or as often as users see fit). >> Such element is indeed quite useful and quite needed.. >> What i am against is putting equality sign between transcript and such UI >> element. >> It is two different things, two different concerns. That's it. >> >> >>> >>> >>>> From that perspective, is it *not* broken in Pharo and works well. >>>> You can write to transcript and everything you written to it is not >>>> lost and recorded.. >>>> to be later piped wherever used wants it to. >>>> I repeat again, Transcript is *not* an UI element simply because it >>>> works even if there's no any transcript window open. >>>> From that perspective the 'flush' command issued cannot be interpreted >>>> as a 'do whatever it takes and deliver immediately my contents to the >>>> screen', >>>> because obviously there may be no any screen nor window.. >>>> So, the 'flush' behavior is more like a soft hint, that can be >>>> completely ignored (making users mad :) ) rather than strict command. >>>> >>>> So, forcing updates to the screen (even if you not really neeed it), is >>>> a separate >>>> issue, and as to me, has little to do with transcript, because it is >>>> more general problem of being able to update screen at the moment you want, >>>> not at the moment, when a system designed to do that. >>>> >>>> >>>>> >>>>>> >>>>>>> >>>>>>>> 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 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> best, >>>>> Eliot >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >>> >>> -- >>> best, >>> Eliot >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > best, > Eliot > -- Best regards, Igor Stasenko.

May 8, 2015

Re: [Pharo-dev] Transcript needs your love

by Igor Stasenko

On 8 May 2015 at 20:21, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Fri, May 8, 2015 at 11:10 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> On 8 May 2015 at 19:42, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >>> >>> >>> On Fri, May 8, 2015 at 10:38 AM, Igor Stasenko <siguctua(a)gmail.com> >>> wrote: >>> >>>> >>>> >>>> On 8 May 2015 at 19:31, Ben Coman <btc(a)openinworld.com> wrote: >>>> >>>>> >>>>> >>>>> On Sat, May 9, 2015 at 1:22 AM, Eliot Miranda <eliot.miranda(a)gmail.com >>>>> > wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, May 8, 2015 at 9:21 AM, Alain Rastoul <alf.mmm.cat(a)gmail.com> >>>>>> wrote >>>>>>> >>>>>>> >>>>>>> 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. >>>>>> >>>>>> >>>>> ahh yes. Maybe we're not ready to be that adventurous yet. >>>>> cheers -ben >>>>> >>>>> >>>> Unlike other software environments, smalltalk(s) allow you to change >>>> virtually anything in the system. And i found this to be really great >>>> thing.. and was happy until the moment i realized that the real thing, that >>>> prevents changes is not the software but people who opposing the changes :) >>>> >>> >>> Nonsense. Changes are not the same as breakages. I've just changed the >>> entire VM and object representation. I implemented a JIT and then followed >>> up with a faster one, and ClÃ©ment and I are following up with an even >>> faster one. But I didn't break things; I made them better. SOmeone who >>> reimplements the transcript so that >>> - it doesn't have all the stream messages any more, and hence isn't a >>> stream as it was always, >>> - it doesn't update >>> has not made changes; they have broken things. And in a shared space we >>> rightly get to complain when that happens. >>> >>> >> <idioto> >> i truly believe that any changes to Transcript that being made in Pharo >> was with intent of making things better not to break them. As well as other >> 99.999% of changes. >> Of course, in shared space, there are potential risk of meeting a >> malicious person, who will break things intentionally forcing people to >> frustration and misery, but luckily, we have little or no such persons >> involved in developing pharo.. >> so... i am not sure what breakage you are talking about :) >> </idioto> >> >> i think there is a fundamental difference between 'stream' and 'update on >> the screen' . Choose one and stick to it. >> We shall separate such responsibilities and NEVER ever merge them again , >> even if it was cool, nice, soft and puffy in the past. >> Yes, sure, we can then build the facade on top of that providing similar >> behavior of what was in the past.. >> > > Then VM development will happen in Squeak where we ca log output from the > internals of the JIT as it runs as we do our soft and puffy work with > machine code adaptive optimization and garbage collection. It won't happen > in Pharo, because one can't see what's going on, because doctrine is more > important than workflow. Afterall why would one want to design computing > systems for people? What a strange idea. > > > >> But if not, then it will always be something that will forever be causing >> problem, since it is conceptually wrong and looks like attempt to cross >> breed two different species. >> > > Right. The terminal is an abomination. We should do all computing in > braille, and submit programs on punch cards, because systems that both > consume and display data are against God. I'm glad I got that straight. > > Nope.. you trying to put into my mouth things, that i never said. Nothing wrong in having terminal(s), nothing wrong in having displays and being able to make applications that puts data on displays so users can read it. I am only humbly proposing to change the point of view on transcript.. as a facility that not an UI element.. and separate responsibilities between UI and logging.. then build on top of that and eventually get the same functionality back again, but with much less chances of causing troubles and inconvenience to users in future. > >> >> >> -- >>> best, >>> Eliot >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > best, > Eliot > -- Best regards, Igor Stasenko.

May 8, 2015

Re: [Pharo-dev] Transcript needs your love

by Eliot Miranda

On Fri, May 8, 2015 at 11:16 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 8 May 2015 at 20:00, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > >> >> >> On Fri, May 8, 2015 at 10:52 AM, Igor Stasenko <siguctua(a)gmail.com> >> wrote: >> >>> >>> >>> On 8 May 2015 at 19:39, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> >>>> >>>> >>>> On Fri, May 8, 2015 at 10:32 AM, Igor Stasenko <siguctua(a)gmail.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On 8 May 2015 at 19:22, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> 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. >>>>>> >>>>>> >>>>> True.. but this is only highlights how deeply broken the overall >>>>> system around UI are. >>>>> Why would MC postscripts need to run in UI thread? Aren't they should >>>>> be completely independent of having UI process at all (unless we're talking >>>>> about packages that actually providing these facilities) ? >>>>> I know that running doits in separate process is 'bad idea' (tm). Only >>>>> because of original bad idea in the past to not care about clearly separate >>>>> things and rely on de-facto non-linear and intricate dependencies in >>>>> system, that established over the years, because of lack of design and >>>>> planning. >>>>> >>>>> I know it may sound like an arrogant moron blabbery, but it doesn't >>>>> means i wrong :) >>>>> >>>> >>>> I still don't hear any rationale for the transcript not updating itself >>>> when it does flush/endEntry:. I still don't hear any rationale for the >>>> morphic transcript behaving differently to a stdout transcript. In that >>>> case, it only makes sense to fix the transcript, right? >>>> >>>> >>> Transcript is not an UI element, it is a stream. Period. >>> >> >> Ah, a write-only invisible transcript. Riiiight. Really useful to log >> output to somewhere no one can see it. Riiight. >> > No, Igor, the Transcript is a UI element and a stream. It is a place to >> log textual output where the programmer can see it. It is Smalltalk's >> standard output console. If one ants a stream which will record output one >> can use a file. If one wants to see it in real time, one uses a transcript. >> >> > what if i want to log to stdout.. why i need morphic UI element? > I've said my piece. You're making me laugh. Keep digging. > Look, understand me wrong not. ;) > I am not against having a UI element that showing the contents of > transcript (or any other stream, why not?) and updates it as soon as > possible (or as often as users see fit). > Such element is indeed quite useful and quite needed.. > What i am against is putting equality sign between transcript and such UI > element. > It is two different things, two different concerns. That's it. > > >> >> >>> From that perspective, is it *not* broken in Pharo and works well. >>> You can write to transcript and everything you written to it is not lost >>> and recorded.. >>> to be later piped wherever used wants it to. >>> I repeat again, Transcript is *not* an UI element simply because it >>> works even if there's no any transcript window open. >>> From that perspective the 'flush' command issued cannot be interpreted >>> as a 'do whatever it takes and deliver immediately my contents to the >>> screen', >>> because obviously there may be no any screen nor window.. >>> So, the 'flush' behavior is more like a soft hint, that can be >>> completely ignored (making users mad :) ) rather than strict command. >>> >>> So, forcing updates to the screen (even if you not really neeed it), is >>> a separate >>> issue, and as to me, has little to do with transcript, because it is >>> more general problem of being able to update screen at the moment you want, >>> not at the moment, when a system designed to do that. >>> >>> >>>> >>>>> >>>>>> >>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>>> >>>> -- >>>> best, >>>> Eliot >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> >> -- >> best, >> Eliot >> > > > > -- > Best regards, > Igor Stasenko. > -- best, Eliot

May 8, 2015

Re: [Pharo-dev] Transcript needs your love

by Eliot Miranda

On Fri, May 8, 2015 at 11:10 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 8 May 2015 at 19:42, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > >> >> >> On Fri, May 8, 2015 at 10:38 AM, Igor Stasenko <siguctua(a)gmail.com> >> wrote: >> >>> >>> >>> On 8 May 2015 at 19:31, Ben Coman <btc(a)openinworld.com> wrote: >>> >>>> >>>> >>>> On Sat, May 9, 2015 at 1:22 AM, Eliot Miranda <eliot.miranda(a)gmail.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Fri, May 8, 2015 at 9:21 AM, Alain Rastoul <alf.mmm.cat(a)gmail.com> >>>>> wrote >>>>>> >>>>>> >>>>>> 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. >>>>> >>>>> >>>> ahh yes. Maybe we're not ready to be that adventurous yet. >>>> cheers -ben >>>> >>>> >>> Unlike other software environments, smalltalk(s) allow you to change >>> virtually anything in the system. And i found this to be really great >>> thing.. and was happy until the moment i realized that the real thing, that >>> prevents changes is not the software but people who opposing the changes :) >>> >> >> Nonsense. Changes are not the same as breakages. I've just changed the >> entire VM and object representation. I implemented a JIT and then followed >> up with a faster one, and ClÃ©ment and I are following up with an even >> faster one. But I didn't break things; I made them better. SOmeone who >> reimplements the transcript so that >> - it doesn't have all the stream messages any more, and hence isn't a >> stream as it was always, >> - it doesn't update >> has not made changes; they have broken things. And in a shared space we >> rightly get to complain when that happens. >> >> > <idioto> > i truly believe that any changes to Transcript that being made in Pharo > was with intent of making things better not to break them. As well as other > 99.999% of changes. > Of course, in shared space, there are potential risk of meeting a > malicious person, who will break things intentionally forcing people to > frustration and misery, but luckily, we have little or no such persons > involved in developing pharo.. > so... i am not sure what breakage you are talking about :) > </idioto> > > i think there is a fundamental difference between 'stream' and 'update on > the screen' . Choose one and stick to it. > We shall separate such responsibilities and NEVER ever merge them again , > even if it was cool, nice, soft and puffy in the past. > Yes, sure, we can then build the facade on top of that providing similar > behavior of what was in the past.. > Then VM development will happen in Squeak where we ca log output from the internals of the JIT as it runs as we do our soft and puffy work with machine code adaptive optimization and garbage collection. It won't happen in Pharo, because one can't see what's going on, because doctrine is more important than workflow. Afterall why would one want to design computing systems for people? What a strange idea. > But if not, then it will always be something that will forever be causing > problem, since it is conceptually wrong and looks like attempt to cross > breed two different species. > Right. The terminal is an abomination. We should do all computing in braille, and submit programs on punch cards, because systems that both consume and display data are against God. I'm glad I got that straight. > > > -- >> best, >> Eliot >> > > > > -- > Best regards, > Igor Stasenko. > -- best, Eliot

May 8, 2015

Re: [Pharo-dev] Transcript needs your love

by Igor Stasenko

On 8 May 2015 at 20:00, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Fri, May 8, 2015 at 10:52 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> On 8 May 2015 at 19:39, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >>> >>> >>> On Fri, May 8, 2015 at 10:32 AM, Igor Stasenko <siguctua(a)gmail.com> >>> wrote: >>> >>>> >>>> >>>> On 8 May 2015 at 19:22, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>> >>>>> >>>>> >>>>> 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. >>>>> >>>>> >>>> True.. but this is only highlights how deeply broken the overall system >>>> around UI are. >>>> Why would MC postscripts need to run in UI thread? Aren't they should >>>> be completely independent of having UI process at all (unless we're talking >>>> about packages that actually providing these facilities) ? >>>> I know that running doits in separate process is 'bad idea' (tm). Only >>>> because of original bad idea in the past to not care about clearly separate >>>> things and rely on de-facto non-linear and intricate dependencies in >>>> system, that established over the years, because of lack of design and >>>> planning. >>>> >>>> I know it may sound like an arrogant moron blabbery, but it doesn't >>>> means i wrong :) >>>> >>> >>> I still don't hear any rationale for the transcript not updating itself >>> when it does flush/endEntry:. I still don't hear any rationale for the >>> morphic transcript behaving differently to a stdout transcript. In that >>> case, it only makes sense to fix the transcript, right? >>> >>> >> Transcript is not an UI element, it is a stream. Period. >> > > Ah, a write-only invisible transcript. Riiiight. Really useful to log > output to somewhere no one can see it. Riiight. > No, Igor, the Transcript is a UI element and a stream. It is a place to > log textual output where the programmer can see it. It is Smalltalk's > standard output console. If one ants a stream which will record output one > can use a file. If one wants to see it in real time, one uses a transcript. > > what if i want to log to stdout.. why i need morphic UI element? Look, understand me wrong not. ;) I am not against having a UI element that showing the contents of transcript (or any other stream, why not?) and updates it as soon as possible (or as often as users see fit). Such element is indeed quite useful and quite needed.. What i am against is putting equality sign between transcript and such UI element. It is two different things, two different concerns. That's it. > > >> From that perspective, is it *not* broken in Pharo and works well. >> You can write to transcript and everything you written to it is not lost >> and recorded.. >> to be later piped wherever used wants it to. >> I repeat again, Transcript is *not* an UI element simply because it works >> even if there's no any transcript window open. >> From that perspective the 'flush' command issued cannot be interpreted as >> a 'do whatever it takes and deliver immediately my contents to the screen', >> because obviously there may be no any screen nor window.. >> So, the 'flush' behavior is more like a soft hint, that can be completely >> ignored (making users mad :) ) rather than strict command. >> >> So, forcing updates to the screen (even if you not really neeed it), is a >> separate >> issue, and as to me, has little to do with transcript, because it is more >> general problem of being able to update screen at the moment you want, >> not at the moment, when a system designed to do that. >> >> >>> >>>> >>>>> >>>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >>> >>> -- >>> best, >>> Eliot >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > best, > Eliot > -- Best regards, Igor Stasenko.

May 8, 2015

Re: [Pharo-dev] Transcript needs your love

by Igor Stasenko

On 8 May 2015 at 19:42, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Fri, May 8, 2015 at 10:38 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> On 8 May 2015 at 19:31, Ben Coman <btc(a)openinworld.com> wrote: >> >>> >>> >>> On Sat, May 9, 2015 at 1:22 AM, Eliot Miranda <eliot.miranda(a)gmail.com> >>> wrote: >>> >>>> >>>> >>>> On Fri, May 8, 2015 at 9:21 AM, Alain Rastoul <alf.mmm.cat(a)gmail.com> >>>> wrote >>>>> >>>>> >>>>> 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. >>>> >>>> >>> ahh yes. Maybe we're not ready to be that adventurous yet. >>> cheers -ben >>> >>> >> Unlike other software environments, smalltalk(s) allow you to change >> virtually anything in the system. And i found this to be really great >> thing.. and was happy until the moment i realized that the real thing, that >> prevents changes is not the software but people who opposing the changes :) >> > > Nonsense. Changes are not the same as breakages. I've just changed the > entire VM and object representation. I implemented a JIT and then followed > up with a faster one, and ClÃ©ment and I are following up with an even > faster one. But I didn't break things; I made them better. SOmeone who > reimplements the transcript so that > - it doesn't have all the stream messages any more, and hence isn't a > stream as it was always, > - it doesn't update > has not made changes; they have broken things. And in a shared space we > rightly get to complain when that happens. > > <idioto> i truly believe that any changes to Transcript that being made in Pharo was with intent of making things better not to break them. As well as other 99.999% of changes. Of course, in shared space, there are potential risk of meeting a malicious person, who will break things intentionally forcing people to frustration and misery, but luckily, we have little or no such persons involved in developing pharo.. so... i am not sure what breakage you are talking about :) </idioto> i think there is a fundamental difference between 'stream' and 'update on the screen' . Choose one and stick to it. We shall separate such responsibilities and NEVER ever merge them again , even if it was cool, nice, soft and puffy in the past. Yes, sure, we can then build the facade on top of that providing similar behavior of what was in the past.. But if not, then it will always be something that will forever be causing problem, since it is conceptually wrong and looks like attempt to cross breed two different species. -- > best, > Eliot > -- Best regards, Igor Stasenko.

May 8, 2015