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

Re: [Pharo-dev] Transcript needs your love

by Ben Coman

On Sat, May 9, 2015 at 12:05 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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. > In troubleshooting a few system red-screen-of-deaths over time, it crossed my mind a few times that it might be safer if the #drawOn: methods were written in a functional paradigm, and be passed a kind of "RenderContext" object containing everything they need to render. > That means a lot of work revising the way how morphic delivers content to > the real estate.. > I guess Bloc is doing a lot of this work anyway. Maybe further discussion of a separate rendering loop would be worthwhile? cheers -ben > > 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). > >

May 9, 2015

Re: [Pharo-dev] Transcript needs your love

by Sven Van Caekenberghe

Stealing some code from SystemProgressMorph, which can show an update while the UI thread drives it, the following seems to work (using a Doit that block the UI thread): (textModel := TextModel new) text: ''; title: 'Pharo Transcript'; aboutText: 'An experimental Transcript View'; isCodeCompletionAllowed: false; menuHolder: [ ]; openWithSpec. 10 timesRepeat: [ textModel text: (textModel text), 'X'. UIManager default currentWorld displayWorld. 0.1 seconds wait ]. Needless to say, this would be a very inefficient implementation ;-) > On 09 May 2015, at 14:37, stepharo <stepharo(a)free.fr> wrote: > > Hi guys > > Eliot I do not understand why you are reacting like that. Our goal is not to make the live of people worse. All the efforts we > do in Pharo is to get better. > I changed the transcript because when I started to work on concurrent programming chapters then the transcript was simply useless. > Now I would like to know how we can improve the solution and this is why I sent this mail. > But apparently I should not have. :( > > I did not send it to receive your kind of emails. I'm convinced you can do better. I do not know what you mean about doctrine. > Pharo objectives is to bring money in Smalltalk and to build better tools and infrastructure. > > Stef

May 9, 2015

Re: [Pharo-dev] Pharo 4 & NeoCSV

by Sean P. DeNigris

Hannes Hirzel wrote > Thank you for adding this for 'normal' people! Adding it was smooth.... Oh, that is useful! +1 thanks :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-4-NeoCSV-tp4804307p4825430.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 9, 2015

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

by Glenn CavarlÃ©

Thanks Marcus ! I just updated my pharo image, I'll test it (with care) ! It will be really great when it will be fully integrated within Nautilus, i look forward. regards, Glenn. ----- Glenn CavarlÃ© -- View this message in context: http://forum.world.st/Reflectivity-Progress-for-Breakpoints-tp4825234p48254… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 9, 2015

Re: [Pharo-dev] Pharo 4 & NeoCSV

by H. Hirzel

Thank you for adding this for 'normal' people! Adding it was smooth.... On 2/8/15, stepharo <stepharo(a)free.fr> wrote: > > Le 7/2/15 18:48, Sven Van Caekenberghe a Ã©crit : >>> On 07 Feb 2015, at 17:21, stepharo <stepharo(a)free.fr> wrote: >>> >>> sven I'm adding a menu to the configuration browser to define the >>> corresponding repo in MC because I'm tired to add repo manually. >> OK. >> >> I always just load a random small thing to get the repo defined ;-) > > :) > I don't and imagine normal people do the same so now the UI is better > Stef >> >>> Stef >>> >>> Le 7/2/15 14:19, Sven Van Caekenberghe a Ã©crit : >>>> Hi Andreas, >>>> >>>> I added it. >>>> >>>> Sven >>>> >>>>> On 07 Feb 2015, at 13:59, Andreas Wacknitz <a.wacknitz(a)gmx.de> wrote: >>>>> >>>>> I miss the configuration of NeoCSV in the configuration browser of >>>>> Pharo 4. Is there any reason for the lack of it? >>>>> NeoJSON is available, thoughâ¦ >>>>> >>>>> Regards >>>>> Andreas >>>> >>> >> >> > > >

May 9, 2015

Re: [Pharo-dev] Transcript needs your love

by stepharo

Hi guys Eliot I do not understand why you are reacting like that. Our goal is not to make the live of people worse. All the efforts we do in Pharo is to get better. I changed the transcript because when I started to work on concurrent programming chapters then the transcript was simply useless. Now I would like to know how we can improve the solution and this is why I sent this mail. But apparently I should not have. :( I did not send it to receive your kind of emails. I'm convinced you can do better. I do not know what you mean about doctrine. Pharo objectives is to bring money in Smalltalk and to build better tools and infrastructure. Stef

May 9, 2015

Re: [Pharo-dev] Transcript needs your love

by stepharo

Eliot I changed the transcript because it is not thread safe so I could use it at all to explain concurrent programming output. It was terrible. Stef Le 8/5/15 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) > > 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 >> >> > >

May 9, 2015

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

by stepharo

Indeed I'm amazed. Freaky logic. Stef Le 8/5/15 22:28, Igor Stasenko a Ã©crit : > > > On 8 May 2015 at 22:20, Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>> wrote: > > > > 2015-05-08 21:42 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com > <mailto:siguctua@gmail.com>>: > > > > On 8 May 2015 at 21:32, Igor Stasenko <siguctua(a)gmail.com > <mailto:siguctua@gmail.com>> wrote: > > > > On 8 May 2015 at 00:43, Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@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. > > > This mean it can happen every time we read form data from a > surface plugin - it is not only an issue for athens/cairo. > > Right, this is not cairo-only issue.. It just manifested itself when i > was started using external surfaces allocated by cairo with bitblt. > Which was causing occasional, irregular crashes time to time and i was > quite lucky finding the cause of it. > > I will take a look at bitblt implementation. > > Thank you ! > > > > 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 > <mailto:stepharo@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 <mailto:nicolaihess@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. > > > > > > -- > Best regards, > Igor Stasenko.

May 9, 2015

Re: [Pharo-dev] [Ann] The Garage database driver API

by stepharo

Le 7/5/15 20:42, Esteban A. Maringolo a Ã©crit : > 2015-05-07 15:09 GMT-03:00 Guillermo Polito <guillermopolito(a)gmail.com>: >> Le 7 mai 2015 18:59, "Esteban A. Maringolo" <emaringolo(a)gmail.com> a Ã©crit : >>> Regarding the GlorpDBX in metarepo, I uploaded a few packages and >>> configs last week to Glorp & GlorpDBX, does the metarepo get updated >>> automatically? >> Nope, you/we have to copy them manually to the corresponding metaRepp. > Is there a script menu for that? just copy the configuration there: - in the configuration browser select "add as MC" - then in MC you click on your configuration and do copy > Do I need write access to the MetaRepo? If so, can it be granted to me? > > Thank you! > >

May 9, 2015

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

by Nicolai Hess

Thank you for testing. I am sorry but I missed one additional change. This change set issue_14183.cs did not revert all. The one thing I was missing is a change in AthensCairoSurface class>>createGetSurfaceFormatFn here, it tells the bitblt the size of the external form data, and igor made this height one line smaller to prevent the wrong memory access. please test again, with this cs: issue_14813_II.cs You need to save and restart the image to use the change in createGetSurfaceFormatFn (I don't know how to manually reinitialize this method). But even with this change, I can not reproduce a segfault. I will take a look at the bitblt implementation and try to find the place where the wrong memory access could happen. nicolai 2015-05-09 10:41 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > > > On Fri, May 8, 2015 at 6:43 AM, 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. >> >> 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 >>> >>> >>> >>> >>> > I am unable to produce the segfault on OSX Mavericks with neither old nor > new VMs... > > Image > ----- > /Users/ben/Library/Application Support/Pharo/images/Athens > BitBlt-50041/Athens BitBlt-50041.image > Pharo5.0 > Latest update: #50041 > Unnamed > > > Virtual Machine > --------------- > /Applications/Pharo.app/Contents/MacOS/Pharo > NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: > acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 > NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: > acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 > https://github.com/pharo-project/pharo-vm.git Commit: > ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200 > By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14826 > > Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< > VMMaker versionString https://github.com/pharo-project/pharo-vm.git > Commit: ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 > +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14826 > NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: > acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 > NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: > acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 > > > > Virtual Machine > --------------- > /Users/ben/Library/Application > Support/Pharo/vm/pharo-mac-stable-vm/Contents/MacOS/Pharo > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > https://github.com/pharo-project/pharo-vm.git Commit: > 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 > By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14904 > > Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< > VMMaker versionString https://github.com/pharo-project/pharo-vm.git > Commit: 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 > +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14904 > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > > cheers -ben > >

May 9, 2015