On 8 May 2015 at 20:21, Eliot Miranda <eliot.mira...@gmail.com> wrote:
> > > On Fri, May 8, 2015 at 11:10 AM, Igor Stasenko <siguc...@gmail.com> wrote: > >> >> >> On 8 May 2015 at 19:42, Eliot Miranda <eliot.mira...@gmail.com> wrote: >> >>> >>> >>> On Fri, May 8, 2015 at 10:38 AM, Igor Stasenko <siguc...@gmail.com> >>> wrote: >>> >>>> >>>> >>>> On 8 May 2015 at 19:31, Ben Coman <b...@openinworld.com> wrote: >>>> >>>>> >>>>> >>>>> On Sat, May 9, 2015 at 1:22 AM, Eliot Miranda <eliot.mira...@gmail.com >>>>> > wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, May 8, 2015 at 9:21 AM, Alain Rastoul <alf.mmm....@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.
