- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Canvas transform bug when rendering text?

by StÃ©phane Ducasse

we should release 1.1 much faster :) like that people will be able to get all the fixes.... Stef On Apr 18, 2010, at 2:42 AM, Henrik Sperre Johansen wrote: > Sorry for responding so late. but... > On 09.04.2010 11:14, Lukas Renggli wrote: >> Pay attention there is a #haltOnce in the code. Also there is >> something wrong with the line endings in the change-set. >> > :( Didn't have time to review it before submission at the time, so some debug code was left in. >> However it also breaks some window refreshing, see attached screenshot. >> >> Lukas > > Yes, for some reason, 1.0 does not contain > TransformMorph >> areasRemainingTofFill: aRectangle > > ^Array with: aRectangle > > Which is needed for a proper refresh. > As you noticed, at least it's quite visible when not present, so one is forced to determine what the proper return value should be, > Basically, areasRemaining...: should denote the non-opaque areas of the morph. > This is mostly used in the drawing algorithm, to determine coverage of a morph, and thus which areas remain to be drawn below it. > In the case of TransformMorph, the calculation for returning a decent estimate is probably more work than just telling it to draw everything below (ie. return the rectangle as the area that remains to be drawn), so that's what we do. If you have a better default, please suggest it! :D > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 18, 2010

Re: [Pharo-project] Fix 1938 - various changes

by StÃ©phane Ducasse

Laurent will be happy :) Because this was really the purpose of the screencast. Stef On Apr 17, 2010, at 11:49 PM, Sean P. DeNigris wrote: > > In inbox. http://code.google.com/p/pharo/issues/detail?id=1938 > > Sean DeNigris > > p.s. following the screencast > (http://pharocasts.blogspot.com/2010/03/how-to-contribute-to-pharo.html) > made it much easier to submit the code. > -- > View this message in context: http://n4.nabble.com/Fix-1938-various-changes-tp2014441p2014441.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 18, 2010

Re: [Pharo-project] Really Important message (tm)

by StÃ©phane Ducasse

Thanks a lot!!! On Apr 17, 2010, at 11:46 PM, Sean P. DeNigris wrote: > > > StÃ©phane Ducasse wrote: >> >> - We need you! >> > > I'm in! Just submitted my first bug fix :) > > Sean > -- > View this message in context: http://n4.nabble.com/Really-Important-message-tm-tp1860396p2014439.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 18, 2010

[Pharo-project] Fwd: [Vm-dev] InputSemaphore on Windows

by StÃ©phane Ducasse

Begin forwarded message: > From: Igor Stasenko <siguctua(a)gmail.com> > Date: April 18, 2010 3:00:02 AM GMT+02:00 > To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > Subject: Re: [Vm-dev] InputSemaphore on Windows > Reply-To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > > > On 16 April 2010 02:07, Andreas Raab <andreas.raab(a)gmx.de> wrote: >> >> On 4/15/2010 3:18 PM, Henrik Sperre Johansen wrote: >>> >>> Is there a reason why this isn't signalled when inputSemaphoreIndex > 0? >> >> None. It just doesn't bite me. If it did I would've fixed it already. Got >> patch? >> >>> In sqWin32Window.c, the comment for synchronizedSignalSemaphoreWithIndex >>> looks somewhat scary... >>> But looking at the svn logs, it seems it never was used in the >>> record...Event() functions at all, so I wondered if a problem was >>> encountered before svn was in use that lead to its removal, or if it's >>> just not done by default? >> >> The short answer is that there are so many potential issues with handling >> semaphore signals properly that at some point I just gave up. At this point, >> there is no reliable way to deliver semaphore signals, they can and they >> *do* get dropped (we've proven that). >> > Wait.. lets us separate the issues. > 1) synchronizedSignalSemaphoreWithIndex() & friends, for signaling an > arbitrary semaphore > 2) an input semaphore, which should be signaled if there are any > events pending for delivery into language side. > > For (2) , i remember you promised to fix that in no time (a fix is > quite trivial) , so then newer images could finally > stop using polling and use an input semaphore instead. > Usually, it is not a big problem with dropping an input semaphore > signals ( if that's ever possible), > because events tend to come at a regular basis, so even if image-side > missed a signal, it can catch up later, > when next event will come by. > >> Cheers, >> - Andreas >> > > -- > Best regards, > Igor Stasenko AKA sig.

April 18, 2010

[Pharo-project] Fwd: [Vm-dev] InputSemaphore on Windows

by StÃ©phane Ducasse

Begin forwarded message: > From: Igor Stasenko <siguctua(a)gmail.com> > Date: April 18, 2010 2:51:55 AM GMT+02:00 > To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > Subject: Re: [Vm-dev] InputSemaphore on Windows > Reply-To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > > > On 16 April 2010 01:18, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no> wrote: >> >> Is there a reason why this isn't signalled when inputSemaphoreIndex > 0? >> >> In sqWin32Window.c, the comment for synchronizedSignalSemaphoreWithIndex >> looks somewhat scary... >> But looking at the svn logs, it seems it never was used in the >> record...Event() functions at all, so I wondered if a problem was >> encountered before svn was in use that lead to its removal, or if it's just >> not done by default? >> > This function is not called, because recordXXXEvent() is already synchronous > because VM calls handleEvents(), and during that, no interpreter > activity is possible, > so it is safe to modify an input semaphore state directly. > The synchronizedSignalSemaphoreWithIndex() is used only for cases, > when you need to signal a > semaphore from other thread, than interpreter runs in. > >> Cheers, >> Henry >> > > > > -- > Best regards, > Igor Stasenko AKA sig.

April 18, 2010

[Pharo-project] Fwd: [Vm-dev] InputSemaphore on Windows

by StÃ©phane Ducasse

Begin forwarded message: > From: Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> > Date: April 18, 2010 2:24:45 AM GMT+02:00 > To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > Subject: Re: [Vm-dev] InputSemaphore on Windows > Reply-To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > > On 16.04.2010 01:07, Andreas Raab wrote: >> >> On 4/15/2010 3:18 PM, Henrik Sperre Johansen wrote: >>> Is there a reason why this isn't signalled when inputSemaphoreIndex > 0? >> >> None. It just doesn't bite me. If it did I would've fixed it already. Got patch? > Not yet, thought I'd ask the question if there was any good reason not to do so first :) > The reason I'd like it to be so, is that Pharo already includes a an EventSensor (InputEventFetcher) which relies on this, and abolishes the polling of EventSensor, but it's not used by default since InputSemaphore is not signaled on all VM's. The code should be easily* portable to Squeak as well. >> >>> In sqWin32Window.c, the comment for synchronizedSignalSemaphoreWithIndex >>> looks somewhat scary... >>> But looking at the svn logs, it seems it never was used in the >>> record...Event() functions at all, so I wondered if a problem was >>> encountered before svn was in use that lead to its removal, or if it's >>> just not done by default? >> >> The short answer is that there are so many potential issues with handling semaphore signals properly that at some point I just gave up. At this point, there is no reliable way to deliver semaphore signals, they can and they *do* get dropped (we've proven that). > As far as I could read from the latest thread about it on the Squeak list http://n4.nabble.com/More-Delay-Semaphore-fun-td67556.html#a67556, this is an issue mostly when the the waiting/signaling process is terminated, which would (probably... ) not be the case for an event fetcher. > > If I get the time to make any progress** I'll send you the modified file for review. > > Cheers, > Henry > > *As in, I haven't done it, but the code should run on both platforms. > ** Something buildable, which works as expected when InputEventSensor is active on Pharo

April 18, 2010

Re: [Pharo-project] Canvas transform bug when rendering text?

by Henrik Sperre Johansen

Sorry for responding so late. but... On 09.04.2010 11:14, Lukas Renggli wrote: > Pay attention there is a #haltOnce in the code. Also there is > something wrong with the line endings in the change-set. > :( Didn't have time to review it before submission at the time, so some debug code was left in. > However it also breaks some window refreshing, see attached screenshot. > > Lukas Yes, for some reason, 1.0 does not contain TransformMorph >> areasRemainingTofFill: aRectangle ^Array with: aRectangle Which is needed for a proper refresh. As you noticed, at least it's quite visible when not present, so one is forced to determine what the proper return value should be, Basically, areasRemaining...: should denote the non-opaque areas of the morph. This is mostly used in the drawing algorithm, to determine coverage of a morph, and thus which areas remain to be drawn below it. In the case of TransformMorph, the calculation for returning a decent estimate is probably more work than just telling it to draw everything below (ie. return the rectangle as the area that remains to be drawn), so that's what we do. If you have a better default, please suggest it! :D Cheers, Henry

April 18, 2010

Re: [Pharo-project] Text at an angle

by Henrik Sperre Johansen

On 17.04.2010 15:19, Schwab,Wilhelm K wrote: > Hello all, > > I am trying to reproduce something that I did in Dolphin. It is a grid of colored squares (got that part) with horizontal and vertial text labels on the rows and columns, respectively. How to create the vertical text is not clear to me. > > One approach would be to draw the text horizontally and then rotate the resulting form. Is there a better way? > > Bill http://n4.nabble.com/forum/Search.jtp?tpl=search-page&node=1294836&query=ro…

April 18, 2010

Re: [Pharo-project] Iliad 0.8 released!

by Henrik Sperre Johansen

On 18.04.2010 01:05, Julian Fitzell wrote: > Cool stuff, Nicolas. I'm happy to see Grease getting use in the > wild... I'm curious to what degree it met your needs? > > I just recorded a podcast with James Robertson this week talking about > cross-platform development. He asked what other projects were using > Grease and I'm afraid I didn't know to include yours. :) > > Julian From my limited experience, beyond the ANSI standard, Grease seems like a step forward towards more dialect compatibility, 2c: How about a "Greasifier" (Grease lubricate: ? ;) ), which would take as input a package/arbitrary unit of code, and emit an equivalent unit of code, in which methods whose bytecodes would be equivalent to the dialect-specific Grease method were rewritten to use the Grease equivalent? (The other way around would ofc also be possible) Or in smalltalk: ^Package copyWithAllMethods: [:aMethod | aMethod byteCodeSequenceDo: [:bcs | (Grease hasMethodEqivalentTo: bcs) ifNotNil: [:equivGreaseCodes | aMethod with: bcs replacedBy:equivGreaseCodes ] ] Cheers, Henry

April 18, 2010

Re: [Pharo-project] Iliad 0.8 released!

by Julian Fitzell

Cool stuff, Nicolas. I'm happy to see Grease getting use in the wild... I'm curious to what degree it met your needs? I just recorded a podcast with James Robertson this week talking about cross-platform development. He asked what other projects were using Grease and I'm afraid I didn't know to include yours. :) Julian 2010/4/17 Nicolas Petton <petton.nicolas(a)gmail.com> > We are happy to announce the release of Iliad version 0.8 for GNU > Smalltalk et Pharo. > > New features include: > > - Iliad is now using Grease and non portable code has been partially > replaced; > - The "mark dirty" mechanism has been rewritten to improve support for > tabs/windows sharing the same session; > - The new Formula package makes it easy to build validated forms; > - Control flow has been improved with new widgets (like confirmations, > sequences, etc) and widgets can append or prepend other widgets; > - In addition to static files served with ILDiskDirectory, they can also > be served from the image with ILMemoryDirectory; > - Smalltalk code can be evaluated on DOM events with #on<event>Do: ; > - Rewrite rules can be applied to the url builder; > > Last but not least, the release also includes an experimental > implementation of Comet using XmlHttpRequest long polling. > > > GNU Smalltalkers can download Iliad with gst-package (using GST 3.2): > gst-package -t ~/.st --download iliad > > Or clone it from github: > git clone git://github.com/NicolasPetton/iliad.git > > > Pharo users can download a preconfigured image: > > http://www.iliadproject.org/resources/lYk5F_GiApFb/ggAMT_HRzRph9Yxp/Iliad-0… > > Or download Iliad packages from the SqueakSource repository: > http://www.squeaksource.com/Iliad.html > > We would like to thank Steven Costiou for his work on the Pharo version > of Iliad. > > > Nicolas Petton & SÃ©bastien Audier > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 18, 2010