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

Re: [Pharo-dev] GanttChartMorph openOn: aCollectionOfActivities ?

by Chris Cunningham

On Fri, May 8, 2015 at 1:33 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi Hannes! > > Here is a first shoot paired-programmed with Juraj using Roassal: > Neat! I think I can use this.. question: <snip> > > b axisX numberOfLabels: 5. > b > -=-=-=-=-=-=-=-=-=-=-=-= > > > so, numberOfLabels means the origin label + that number of labels? You ask for 5,and it shows 6. Not an issue per se, but I do want to know that this is intentional and will stay. -cbc

May 8, 2015

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

by Igor Stasenko

On 8 May 2015 at 21:32, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 8 May 2015 at 00:43, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> Some testers needed! >> >> I can not reproduce the BitBlt bug and I would like to get this right, so >> that surface pattern >> paints use the correct form dimension. >> >> Be sure, my fried, the bug is there, sitting in VM. > Bitblt implementation prereads a pixel from bitmap *before* checking the > loop bounds, meaning that it reads at least a single byte beyond the actual > contents of the bitmap. > It is not harmful in cases when bitmap is allocated in object memory since > VM memory design actually guarantees, that there are at least certain > amount of bytes in form of breathing space always available, so reading > single word past any allocated object is not hurts.. > But not in case, when bitmap residing in external heap.. because reading > beyond allocated space might cause segmentation fault.. and it was, until i > figured what was causing it and where the bug is. > > The workaround, that i introduced was simply to tell Cairo to allocate surface 1 row taller and then use smaller height in bitblt operations, so it can never use the last row.. that, of course, going in conflict of using cairo for a patterns to fill things with bitmaps, which relying on surface's dimensions and using all its pixels.. :( hmm.. > > >> Prefered test setup: >> a (fresh) pharo image >> load bleeding edge from Bloc (because with bloc the whole (morphic) world >> is drawn with athens). >> change to watery theme ( because it makes some heavy use of form fills) >> verify that vertical scrollbars have this artifact (blank lines). >> load the attached code (this code reverts igors change for the 1 pixel >> extra height. >> >> please report back >> what platform windows/linux/mac 32/64 bit >> what pharo vm and image version. >> >> For me >> Windows 7 32 bit >> Win32 built on Apr 9 2015 21:05:04 Compiler: 4.6.2 >> Latest update: #50039 >> >> -> no segfault >> >> thanks in advance >> >> >> 2015-03-13 21:22 GMT+01:00 stepharo <stepharo(a)free.fr>: >> >>> I do not know. May be igor is reading this mailing-list but I doubt. >>> >>> >>> 2015-01-27 21:46 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: >>> >>> Anyone knows what this BitBlt bug is or was? >>>> 12818 <https://pharo.fogbugz.com/default.asp?12818> Last row missing >>>> 13236 <https://pharo.fogbugz.com/default.asp?13236> Fix 1 extra >>>> height for Cairo surface >>>> >>>> Because with the fix in 13236, it is not (easily) possible to make >>>> a repeating (vertical) pattern paint with 1 pixel height: >>>> 14813 <https://pharo.fogbugz.com/default.asp?14813> Wrong size for >>>> Athens surface pattern paint from a Form >>>> >>>> >>>> nicolai >>>> >>>> >>>> >>> BUMP >>> >>> >>> >>> >>> >>> >> > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

May 8, 2015

Re: [Pharo-dev] Athens BitBlt bug?

by Nicolai Hess

2015-03-13 10:26 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > 2015-01-27 21:46 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > >> Anyone knows what this BitBlt bug is or was? >> 12818 <https://pharo.fogbugz.com/default.asp?12818> Last row missing >> 13236 <https://pharo.fogbugz.com/default.asp?13236> Fix 1 extra height >> for Cairo surface >> >> Because with the fix in 13236, it is not (easily) possible to make >> a repeating (vertical) pattern paint with 1 pixel height: >> 14813 <https://pharo.fogbugz.com/default.asp?14813> Wrong size for >> Athens surface pattern paint from a Form >> >> >> nicolai >> >> >> > BUMP > > > Igor, do you remember what bitblt bug this was about? > > >

May 8, 2015

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

by Igor Stasenko

On 8 May 2015 at 00:43, Nicolai Hess <nicolaihess(a)web.de> wrote: > > Some testers needed! > > I can not reproduce the BitBlt bug and I would like to get this right, so > that surface pattern > paints use the correct form dimension. > > Be sure, my fried, the bug is there, sitting in VM. Bitblt implementation prereads a pixel from bitmap *before* checking the loop bounds, meaning that it reads at least a single byte beyond the actual contents of the bitmap. It is not harmful in cases when bitmap is allocated in object memory since VM memory design actually guarantees, that there are at least certain amount of bytes in form of breathing space always available, so reading single word past any allocated object is not hurts.. But not in case, when bitmap residing in external heap.. because reading beyond allocated space might cause segmentation fault.. and it was, until i figured what was causing it and where the bug is. > Prefered test setup: > a (fresh) pharo image > load bleeding edge from Bloc (because with bloc the whole (morphic) world > is drawn with athens). > change to watery theme ( because it makes some heavy use of form fills) > verify that vertical scrollbars have this artifact (blank lines). > load the attached code (this code reverts igors change for the 1 pixel > extra height. > > please report back > what platform windows/linux/mac 32/64 bit > what pharo vm and image version. > > For me > Windows 7 32 bit > Win32 built on Apr 9 2015 21:05:04 Compiler: 4.6.2 > Latest update: #50039 > > -> no segfault > > thanks in advance > > > 2015-03-13 21:22 GMT+01:00 stepharo <stepharo(a)free.fr>: > >> I do not know. May be igor is reading this mailing-list but I doubt. >> >> >> 2015-01-27 21:46 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: >> >> Anyone knows what this BitBlt bug is or was? >>> 12818 <https://pharo.fogbugz.com/default.asp?12818> Last row missing >>> 13236 <https://pharo.fogbugz.com/default.asp?13236> Fix 1 extra height >>> for Cairo surface >>> >>> Because with the fix in 13236, it is not (easily) possible to make >>> a repeating (vertical) pattern paint with 1 pixel height: >>> 14813 <https://pharo.fogbugz.com/default.asp?14813> Wrong size for >>> Athens surface pattern paint from a Form >>> >>> >>> nicolai >>> >>> >>> >> BUMP >> >> >> >> >> >> > -- Best regards, Igor Stasenko.

May 8, 2015

Re: [Pharo-dev] Transcript needs your love

by Sven Van Caekenberghe

> On 08 May 2015, at 21:00, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > > 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. We also have NonInteractiveTranscript which I use a lot ! > Only the Transcript has a different behavior, which is not compatible with the use cases of VM development. IMHO this is a discussion about efficiency, the price you are willing to pay: the old system was slow because it tries to update for each #endEntry, the new system is way faster, but does not update if you block the UI thread. (There are also correctness issues, the red screen of death). It would not be too hard to image this being an option/setting. The 'better' design would be to have a stream viewer thing that is clever enough to batch updates if they come fast and only draw them when needed. > 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] Transcript needs your love

by Igor Stasenko

On 8 May 2015 at 21:00, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > 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. > > > The rationale was to change things in a way that: - updates on the screen should not impact heavily the performance of the system and should not happen more often than actual physical screen can update itself, not speaking about that users's cannot read text that flies at the light speed before your eyes and therefore completely useless from the usability perspective. Another rationale is that the only facility that should know how 'immediately' of 'forcibly' update the screen should be the GUI framework, and should properly expose such functionality via its own API or whatever.. but not the strangely wired and single utility (albeit quite useful), that tries to force updates on the screen disregarding everything and stalling the system, burning cpu on redrawing the screen faster than anyone can read.. -- 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) > Interesting points Yes Eliot, I suspect some things could be broken But *breakage* ? to prevent this, I submitted the idea to add an *extra* option 'run async' and afterall may be not that much. when nobody tries who knows ? May be just very few breakages ? (may be none ... mmm well I don't think ... ;) ) And again this could be an *extra* menu option (...) Anyway, it is certainly possible in Pharo too to update the Transcript while in the UI process and find a non breaking solution here. (probably very different from squeak implementation but it doesn't matter) -- Regards, Alain

May 8, 2015

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

by Igor Stasenko

On 8 May 2015 at 20:40, Nicolai Hess <nicolaihess(a)web.de> wrote: > Works for me on windows 7 (in a msys console). > > hmm.. probably i got an outdated msys, that lacks mktemp utility, and need to update it (see ya couple hours later :) > 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 >> >> > -- Best regards, Igor Stasenko.

May 8, 2015

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