September 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Compiling the VM for MacOSX

by Alexandre Bergel

> which is a bit sad. Because we cannot run an hudson srever to automatically build vms. > I do not really understand why this would not be possible. Indeed, it would be nice to have that Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 13, 2010

Re: [Pharo-project] Squeak VM on iPad/IPhone gets open/GL rendering

by John M McIntosh

Spent a few more hours today reading and then decided the test case I had from Bert spent 90% of it's time in the interpreter's copyLoop logic. Toss that for the fall back of using bouncing atoms so I could get a better feel of the performance differences. So after some optimization, on the iPad, the CALayer pushes about 38 fps, the OpenGL code pushes 49 fps (which is limited by Morphic loop). In checking Instruments the 10% of the time taken in CALayer for memcpy of data out of the UIImages is gone when I do open/GL However if the drawing area becomes too big then the Open/GL drawing is slower, trade offs, trade offs. Also the byte alignment plays a part, that I have to explore more. Still this is significant progress and we'll see what happens this week. A quick check on an iPhone 3GS shows CALayer pushes about 27fps, OpenGL does 43 fps. So much bigger win, I think we'll keep it. Sadly it doesn't fly on an iPod Gen 1 device (3.1.3) Zero clues.. It's possible of course there isn't isn't enough memory to go around, but given I've two different implementation classes I can choose the viable one at run time... On 2010-09-11, at 3:37 PM, John M McIntosh wrote: > On friday night I created an open/GL renderer to work with Squeak screen updates on the iPhone/iPad. > > Unfortunately it runs slows than the tiled Core Animation render that I had work out earlier in the year > with help from the Apple graphics engineers. > > So if anyone has a fair amount of knowledge about Open/GL ES maybe they could contact me and > we'll see if we can improve things? -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Sept. 13, 2010

[Pharo-project] i know esug just started...but some kind soul can please revive squeaksource

by Fernando olivero

thanks, Fernando

Sept. 13, 2010

Re: [Pharo-project] Pharo-project Digest, Vol 29, Issue 84

by Eliot Miranda

2010/9/12 Michael Roberts <mike(a)mjr104.co.uk> > > Sort of like > > Progressor progressDuring:[:bar | > ... > Progressor progressDuring:[:bar | > ... > Progressor progressDuring:[:bar | > > at different levels in the stack rather than letting the exception find the > notifier each time you would do it explicitly. Perhaps there is a reason > why that wouldn't work. > Simply because the progress indications occur in unrelated methods, not in a single method, so they can't be written this way. The issue is, when wanting to show a progress bar for some activity, whether there already exists an open progress bar in some outer activation. Essentially a signal is the most convenient way to do this if one wants to search the stack (a signal is an abstraction over stack searching). The other approach is to use a per-process variable (thread-local variable). Squeak uses the former style. But there's no reason why one can't cache the lookup of the first signal. I don't see any need for sending the signal on each increment of the progress indicator or each activation of the action block. cheers Eliot > > Cheers mike > > On 13 Sep 2010, at 00:26, Michael Roberts <mike(a)mjr104.co.uk> wrote: > > When I looked through the code I imagined one could implement the nesting > by just maintaining a stack on the progress initiator sort of like > > ... > > > On 11 Sep 2010, at 16:45, Eliot Miranda < <eliot.miranda(a)gmail.com> > eliot.miranda(a)gmail.com> wrote: > > Hi Ralph, > > On Sat, Sep 11, 2010 at 1:05 AM, Ralph Boland < <rpboland(a)gmail.com><rpboland(a)gmail.com> > rpboland(a)gmail.com> wrote: > >> > Hi, i don't know why things are done the way they are... >> > Is your question how the exception mechanism works, or why it is >> > needed to be done with an exception? as opposed to say doing it >> > some other way? >> >> > The direct answer to your question is that given it is implemented in >> > terms of exceptions, the signal is needed to trigger the >> > defaultAction, or to allow someone higher up in the stack to trap it >> > and redirect the notification. >> >> > cheers, >> > Mike >> >> >> I am no expert on Exceptions but I do understand this. >> What I don't understand is WHY ProgressInitiationException >> is used and why a signal is sent to its instance to get the ball rolling. >> >> Could not SystemProgressMorph be modified to handle this? >> >> Alternatively, could not some other new (non-exception) class handle >> the logic where an instance of that class is created and gets the ball >> rolling without sending a signal to itself? For me, currently, this >> is the more intuitive way to do things. Why use signals when they >> are not needed? (Or are they needed for some reason unknown to me?) >> >> The modifications I am planning to make to the ProgressDisplay >> package look easier if I get rid of the signal handling. >> But I don't know what I will be breaking or what functionality will >> be lost if I get rid of the signal handling. >> So I need to know WHY? >> > > I tried to answer your question the first time round but as I looked at the > code I found that I didn't understand it, and so gave up on my explanation > :). It seemed to me that the reason for using a signal was to handle > nesting. One raises the progress initiation signal in the wrapper to the > action block to get progress to display in the right progress bar. If the > signal is uncaught then its defaultAction would open up a new progress bar > with one progress strip and initiate processing of the progress block, > providing a handler for the progress initiation signal. If the signal is > caught (by the handler provided at the first level) then the existing > progress bar is extended with a new progress strip for the nested progress. > At least that's how I thought it worked but I couldn't work out how the > handler worked. > > If I were writing it I would still use the signal to find if the progress > was nested but I /would not/ put the code in the defaultAction. Instead the > signal would answer if it was nested and all the code would be at the point > where the signal is raised. For this one can use a simple Notification, > using its tag to disambiguate it e.g. > > [Notification new tag: #progressBar; signal] > on: Notification > do: [:ex| > ex tag == #progressBar ifTrue: [ex resume: true]. > ex pass] true > > So e.g. > > outerBarOrNil := Notification new tag: #progressBar; signal. > ... if nested add to the existing bar otherwise create a new bar ... > [actionBlock value: bar] > on: Notification > do: [:ex| > ex tag == #progressBar ifTrue: [ex resume: bar]. > ex pass] > > my 2Â¢ > > If you can make the tests pass with simpler code then go for it! > > best > Eliot > > > >> Regards, >> >> Ralph Boland >> >> > On Fri, Sep 10, 2010 at 4:37 AM, Ralph Boland < <rpboland(a)gmail.com><rpboland(a)gmail.com> >> rpboland(a)gmail.com> wrote: >> > > I posted the following earlier to the Squeak list but didn't get a >> responce. >> > > Hopefully someone on the Pharo list can help me. ?I need this >> information >> > > so I can make some planned changes to the ProgressDisplay package I >> released >> > > a while back. >> > > >> > > >> ----------------------------------------------------------------------------------------------------------------- >> > > >> > > A SystemProgressMorph is used to display progress while some >> computation >> > > is being done. ?Furthermore the progress bars can be stacked to show >> progress >> > > of component computations within a computation. >> > > This I understand and understand most of the code. >> > > But not All. >> > > What I have trouble with is understanding why a >> ProgressInitiationException >> > > is needed. ?In particular, String>>displayProgressAt:from:to:during: >> > > does: >> > > >> > > ProgressInitiationException >> > > >> display: self >> > > at: aPoint >> > > from: minVal >> > > to: maxVal >> > > during: workBlock. >> > > >> > > >> > > This method sets a few variables and then does: >> > > >> > > ^self signal >> > > >> > > This signal is caught where upon a SystemProgressMorph is started or >> > > extended with >> > > an additional progress bar. >> > > >> > > But I don't understand why sending a signal to a >> ProgressInitiationException >> > > is needed to get the ball rolling, >> > > >> > > Can someone please explain why things are done the way they are? >> > > >> > > >> > > Regards, >> > > >> > > Ralph Boland >> >> _______________________________________________ >> Pharo-project mailing list >> <Pharo-project(a)lists.gforge.inria.fr><Pharo-project(a)lists.gforge.inria.fr> >> Pharo-project(a)lists.gforge.inria.fr >> <http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project><http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > <Pharo-project(a)lists.gforge.inria.fr>Pharo-project(a)lists.gforge.inria.fr > <http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 13, 2010

Re: [Pharo-project] Pharo-project Digest, Vol 29, Issue 84

by Michael Roberts

Sort of like Progressor progressDuring:[:bar | ... Progressor progressDuring:[:bar | ... Progressor progressDuring:[:bar | at different levels in the stack rather than letting the exception find the notifier each time you would do it explicitly. Perhaps there is a reason why that wouldn't work. Cheers mike On 13 Sep 2010, at 00:26, Michael Roberts <mike(a)mjr104.co.uk> wrote: > When I looked through the code I imagined one could implement the > nesting by just maintaining a stack on the progress initiator sort > of like > > ... > > > On 11 Sep 2010, at 16:45, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> Hi Ralph, >> >> On Sat, Sep 11, 2010 at 1:05 AM, Ralph Boland <rpboland(a)gmail.com> >> wrote: >> > Hi, i don't know why things are done the way they are... >> > Is your question how the exception mechanism works, or why it is >> > needed to be done with an exception? as opposed to say doing it >> > some other way? >> >> > The direct answer to your question is that given it is >> implemented in >> > terms of exceptions, the signal is needed to trigger the >> > defaultAction, or to allow someone higher up in the stack to trap >> it >> > and redirect the notification. >> >> > cheers, >> > Mike >> >> >> I am no expert on Exceptions but I do understand this. >> What I don't understand is WHY ProgressInitiationException >> is used and why a signal is sent to its instance to get the ball >> rolling. >> >> Could not SystemProgressMorph be modified to handle this? >> >> Alternatively, could not some other new (non-exception) class handle >> the logic where an instance of that class is created and gets the >> ball >> rolling without sending a signal to itself? For me, currently, this >> is the more intuitive way to do things. Why use signals when they >> are not needed? (Or are they needed for some reason unknown to me?) >> >> The modifications I am planning to make to the ProgressDisplay >> package look easier if I get rid of the signal handling. >> But I don't know what I will be breaking or what functionality will >> be lost if I get rid of the signal handling. >> So I need to know WHY? >> >> I tried to answer your question the first time round but as I >> looked at the code I found that I didn't understand it, and so gave >> up on my explanation :). It seemed to me that the reason for using >> a signal was to handle nesting. One raises the progress initiation >> signal in the wrapper to the action block to get progress to >> display in the right progress bar. If the signal is uncaught then >> its defaultAction would open up a new progress bar with one >> progress strip and initiate processing of the progress block, >> providing a handler for the progress initiation signal. If the >> signal is caught (by the handler provided at the first level) then >> the existing progress bar is extended with a new progress strip for >> the nested progress. At least that's how I thought it worked but I >> couldn't work out how the handler worked. >> >> If I were writing it I would still use the signal to find if the >> progress was nested but I /would not/ put the code in the >> defaultAction. Instead the signal would answer if it was nested >> and all the code would be at the point where the signal is raised. >> For this one can use a simple Notification, using its tag to >> disambiguate it e.g. >> >> [Notification new tag: #progressBar; signal] >> on: Notification >> do: [:ex| >> ex tag == #progressBar ifTrue: [ex resume: true]. >> ex pass] true >> >> So e.g. >> >> outerBarOrNil := Notification new tag: #progressBar; signal. >> ... if nested add to the existing bar otherwise create a new bar ... >> [actionBlock value: bar] >> on: Notification >> do: [:ex| >> ex tag == #progressBar ifTrue: [ex resume: bar]. >> ex pass] >> >> my 2Â¢ >> >> If you can make the tests pass with simpler code then go for it! >> >> best >> Eliot >> >> >> >> Regards, >> >> Ralph Boland >> >> > On Fri, Sep 10, 2010 at 4:37 AM, Ralph Boland >> <rpboland(a)gmail.com> wrote: >> > > I posted the following earlier to the Squeak list but didn't >> get a responce. >> > > Hopefully someone on the Pharo list can help me. ?I need this >> information >> > > so I can make some planned changes to the ProgressDisplay >> package I released >> > > a while back. >> > > >> > > >> --- >> --- >> --- >> --- >> --- >> --- >> --- >> --- >> --- >> --- >> --- >> --- >> --- >> --- >> --- >> -------------------------------------------------------------------- >> > > >> > > A SystemProgressMorph is used to display progress while some >> computation >> > > is being done. ?Furthermore the progress bars can be stacked to >> show progress >> > > of component computations within a computation. >> > > This I understand and understand most of the code. >> > > But not All. >> > > What I have trouble with is understanding why a >> ProgressInitiationException >> > > is needed. ?In particular, >> String>>displayProgressAt:from:to:during: >> > > does: >> > > >> > > ProgressInitiationException >> > > >> display: self >> > > at: aPoint >> > > from: minVal >> > > to: maxVal >> > > during: workBlock. >> > > >> > > >> > > This method sets a few variables and then does: >> > > >> > > ^self signal >> > > >> > > This signal is caught where upon a SystemProgressMorph is >> started or >> > > extended with >> > > an additional progress bar. >> > > >> > > But I don't understand why sending a signal to a >> ProgressInitiationException >> > > is needed to get the ball rolling, >> > > >> > > Can someone please explain why things are done the way they are? >> > > >> > > >> > > Regards, >> > > >> > > Ralph Boland >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 12, 2010

Re: [Pharo-project] Pharo-project Digest, Vol 29, Issue 84

by Michael Roberts

When I looked through the code I imagined one could implement the nesting by just maintaining a stack on the progress initiator sort of like ... On 11 Sep 2010, at 16:45, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Ralph, > > On Sat, Sep 11, 2010 at 1:05 AM, Ralph Boland <rpboland(a)gmail.com> > wrote: > > Hi, i don't know why things are done the way they are... > > Is your question how the exception mechanism works, or why it is > > needed to be done with an exception? as opposed to say doing it > > some other way? > > > The direct answer to your question is that given it is implemented > in > > terms of exceptions, the signal is needed to trigger the > > defaultAction, or to allow someone higher up in the stack to trap it > > and redirect the notification. > > > cheers, > > Mike > > > I am no expert on Exceptions but I do understand this. > What I don't understand is WHY ProgressInitiationException > is used and why a signal is sent to its instance to get the ball > rolling. > > Could not SystemProgressMorph be modified to handle this? > > Alternatively, could not some other new (non-exception) class handle > the logic where an instance of that class is created and gets the ball > rolling without sending a signal to itself? For me, currently, this > is the more intuitive way to do things. Why use signals when they > are not needed? (Or are they needed for some reason unknown to me?) > > The modifications I am planning to make to the ProgressDisplay > package look easier if I get rid of the signal handling. > But I don't know what I will be breaking or what functionality will > be lost if I get rid of the signal handling. > So I need to know WHY? > > I tried to answer your question the first time round but as I looked > at the code I found that I didn't understand it, and so gave up on > my explanation :). It seemed to me that the reason for using a > signal was to handle nesting. One raises the progress initiation > signal in the wrapper to the action block to get progress to display > in the right progress bar. If the signal is uncaught then its > defaultAction would open up a new progress bar with one progress > strip and initiate processing of the progress block, providing a > handler for the progress initiation signal. If the signal is caught > (by the handler provided at the first level) then the existing > progress bar is extended with a new progress strip for the nested > progress. At least that's how I thought it worked but I couldn't > work out how the handler worked. > > If I were writing it I would still use the signal to find if the > progress was nested but I /would not/ put the code in the > defaultAction. Instead the signal would answer if it was nested and > all the code would be at the point where the signal is raised. For > this one can use a simple Notification, using its tag to > disambiguate it e.g. > > [Notification new tag: #progressBar; signal] > on: Notification > do: [:ex| > ex tag == #progressBar ifTrue: [ex resume: true]. > ex pass] true > > So e.g. > > outerBarOrNil := Notification new tag: #progressBar; signal. > ... if nested add to the existing bar otherwise create a new bar ... > [actionBlock value: bar] > on: Notification > do: [:ex| > ex tag == #progressBar ifTrue: [ex resume: bar]. > ex pass] > > my 2Â¢ > > If you can make the tests pass with simpler code then go for it! > > best > Eliot > > > > Regards, > > Ralph Boland > > > On Fri, Sep 10, 2010 at 4:37 AM, Ralph Boland <rpboland(a)gmail.com> > wrote: > > > I posted the following earlier to the Squeak list but didn't get > a responce. > > > Hopefully someone on the Pharo list can help me. ?I need this > information > > > so I can make some planned changes to the ProgressDisplay > package I released > > > a while back. > > > > > > > --- > --- > --- > --- > --- > --- > --- > --- > --- > --- > --- > --- > --- > --- > --- > -------------------------------------------------------------------- > > > > > > A SystemProgressMorph is used to display progress while some > computation > > > is being done. ?Furthermore the progress bars can be stacked to > show progress > > > of component computations within a computation. > > > This I understand and understand most of the code. > > > But not All. > > > What I have trouble with is understanding why a > ProgressInitiationException > > > is needed. ?In particular, > String>>displayProgressAt:from:to:during: > > > does: > > > > > > ProgressInitiationException > > > > display: self > > > at: aPoint > > > from: minVal > > > to: maxVal > > > during: workBlock. > > > > > > > > > This method sets a few variables and then does: > > > > > > ^self signal > > > > > > This signal is caught where upon a SystemProgressMorph is > started or > > > extended with > > > an additional progress bar. > > > > > > But I don't understand why sending a signal to a > ProgressInitiationException > > > is needed to get the ball rolling, > > > > > > Can someone please explain why things are done the way they are? > > > > > > > > > Regards, > > > > > > Ralph Boland > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 12, 2010

[Pharo-project] Updated http://isqueak.org/PlatformVMAPI

by John M McIntosh

I spent a few hours this morning and updated the VM Platform API documentation at http://isqueak.org/PlatformVMAPI To capture the details of the OS-X Cocoa work. (Squeak macintosh VM 5.x) For the most part the iPhone & OS-X implementation share a common Objective-C code base because Apple uses OSX as the foundation for both devices which shares most of the functionality except for the UI components. Thus for the most part I could say see iPhone implementation details. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Sept. 12, 2010

Re: [Pharo-project] update to OCompletion

by Francisco Ortiz PeÃ±aloza

On Sun, Sep 12, 2010 at 5:08 AM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: >> This is because when you have a line split into multiple lines, I want Enter to mean new line, not complete. This is particularly the case when you have pseudo-domain specific languages like in Glamour or Mondrian. > > A bit hard to get used to it, but I agree. Ok, you've got a good point. Thanks to point me out. > >> Nevertheless, I would say that once I pressed the down arrow, my focus is to the completion, and thus enter should mean selection of the completion. > > +1 I totally agree on this one. Francisco > > Alexandre > >> >> >> >> On 12 Sep 2010, at 01:30, Francisco Ortiz PeÃ±aloza wrote: >> >>> Hi, i'm trying the latest version cause i's tired of waiting for the >>> switch to the longer list of suggestions. But i don't understand the >>> following change >>> >>> -removed enter to insert a completion >>> >>> am i missing something? why do u ppl make this change? >>> >>> Cheers, >>> Francisco Ortiz PeÃ±aloza >>> >>> On Wed, Aug 4, 2010 at 8:20 PM, Tim Mackinnon <tamackinnon(a)gmail.com> wrote: >>>> I shall definitely give that a read - especially now i have an example to >>>> think back on. >>>> >>>> By the way - these chapters that people keep writing, are a great help (the >>>> monticello one certainly took away a huge load of frustrations I was having) >>>> - so thanks to everyone that keeps chipping away at them! >>>> >>>> tim >>>> >>>> On 4 Aug 2010, at 18:44, Mariano Martinez Peck wrote: >>>> >>>>> I am glad I helped. You can also take a look to the Metacello draft we >>>>> wrote for Pharo By Example 2. I attach it. >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow." >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 12, 2010

[Pharo-project] Improving generate accessors for refactoring browser

by Bart Gauquie

Dear list, I've noticed that when I'm using the generate accessors refactoring, I'm always adapting the generated code for the mutator: number: anObject number := anObject to: number: aNumber number := aNumber So I've adapted the refactoring code a bit so that it automatically generates this correctly. Anybody also thinks this is useful? If so, I will create a bug/improvement and a slice for it. Kind regards, Bart

Sept. 12, 2010

Re: [Pharo-project] Compiling the VM for MacOSX

by StÃ©phane Ducasse

> > > The instructions seems to target building a VM from April of 2009. Lots has changed since then to make the > process of building a Cocoa OS-X VM to match a distributed pre-built VM version more of a one-step process. > > Otherwise it's just too hard to mesh the pieces together between an arbitrary squeak image, vmmaker, and > the source from squeakvm.org which is a bit sad. Because we cannot run an hudson srever to automatically build vms. I do not really understand why this would not be possible. Stef > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 12, 2010