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

Re: [Pharo-project] Why announcer subscriptions is dectionary?

by Denis Kudriashov

> > It is a dictionary for speed reasons. A user might trigger trigger > thousands of events per seconds and iterating through large flat lists > can be very slow if there are many handlers. > Where is speedup improvements? In code that I found in Pharo 1.1 there is simple iteration by all dictionary items. And I think there is no places for speed improvements because subscribers can subscribers for announcement hierarchy (not concrete class). Announcer>>announce: anAnnouncement | announcement | announcement := anAnnouncement asAnnouncement. subscriptions ifNil: [ ^ announcement ]. subscriptions keysAndValuesDo: [ :class :actions | (class handles: announcement) ifTrue: [ actions valueWithArguments: (Array with: announcement) ] ]. ^ announcement

June 22, 2010

Re: [Pharo-project] Cog - dumb question

by Yanni Chiu

Schwab,Wilhelm K wrote: > I am very excited about Cog, but also have to urge some caution: There was mention of Seaside not running on it, which is a show-stopper until fixed. Yes, that's what I meant by fix major bugs. But given the level of excitement and interest, I figured these would be fixed, long before a Pharo 1.2 would be released. >> Henrik Johansen wrote: > > - Platform availability (64bit is not supported, iPhone/iPad VM's can't run them) > - Still buggy (I've reported 2 so far) > - No process established yet how / if to synch with current VMMaker (which contains quite a lot of fixes not found in Cog) > - Plugin availability (f.ex. I tried building FT2Plugin using Cog structure on OSX, and failed miserably) > - No good reason to release a backwards-incompatible image by default, when Cog translates them by default, but not the other way around. Yes, these are all very good points. The last point is the best, there's no reason not to, since Cog can translate it. I just have a feeling that dragging out a transition like this would be more painful than a quick leap. I know that for me, as soon as Seaside runs on MacOSX and Linux, I'd make the move. I'd probably hold back if it was only 1.5 times speed-up, but likely 3 times or more, is hard to resist. It's not easy to always know which VM you're running, so there's almost certainly going to be image mis-matches, the longer the transition takes. Now that I think about it, for me, I can simply change the two VM's I use. It's just the image builders that need to pick up the right VM (if they happen to use Cog day-to-day), and keep everything straight.

June 22, 2010

Re: [Pharo-project] Cog - dumb question

by Eliot Miranda

Hi All, On Tue, Jun 22, 2010 at 8:09 AM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > > On Jun 22, 2010, at 4:58 36PM, Yanni Chiu wrote: > > > Henrik Johansen wrote: > >> The code works on both Cog and Closure VMs though, so development can > >> continue on whatever VM you desire without a split in package > >> versions. As Cog is able to read closure-images, but not the other > >> way around, I imagine we will want to keep releasing official images > >> saved by the closure VM. > > > > IMHO, we should move to Cog as soon as possible - once any major bugs, if > any, are dealt with. So, change direction: abandon 1.2 (which just started) > and go for 2.0, which requires an image format change (due to Cog VM). Is > there a reason to hang back - Teleplace has used Cog for about a year > already? > > > - Platform availability (64bit is not supported, iPhone/iPad VM's can't run > them) > - Still buggy (I've reported 2 so far) > - No process established yet how / if to synch with current VMMaker (which > contains quite a lot of fixes not found in Cog) > - Plugin availability (f.ex. I tried building FT2Plugin using Cog structure > on OSX, and failed miserably) > - No good reason to release a backwards-incompatible image by default, when > Cog translates them by default, but not the other way around. > I just want to endorse Henry's caution. Clearly Cog is not ready to replace the existing VMs. But do note that the Stack VM is included and that should be a portable VM. I know that John McIntosh is looking at the Stack VM for iPhone. The Stack VM is not a JIT and so is cross-platform; but it does use the same context-to-stack mapping scheme as the Cog VM. What I hope will happen is that the Stack VM will replace the standard VM pretty soon, and that, because the Stack VM and the Cog VM can read each other's images that once the VM maintainers have integrated the Stack VM into the VM sources then images will move forward to the Cog format. But for the present Henry is absolutely right. best Eliot > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 22, 2010

Re: [Pharo-project] Cog - dumb question

by Schwab,Wilhelm K

I am very excited about Cog, but also have to urge some caution: There was mention of Seaside not running on it, which is a show-stopper until fixed. -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Johansen Sent: Tuesday, June 22, 2010 10:10 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Cog - dumb question On Jun 22, 2010, at 4:58 36PM, Yanni Chiu wrote: > Henrik Johansen wrote: >> The code works on both Cog and Closure VMs though, so development can >> continue on whatever VM you desire without a split in package >> versions. As Cog is able to read closure-images, but not the other >> way around, I imagine we will want to keep releasing official images >> saved by the closure VM. > > IMHO, we should move to Cog as soon as possible - once any major bugs, if any, are dealt with. So, change direction: abandon 1.2 (which just started) and go for 2.0, which requires an image format change (due to Cog VM). Is there a reason to hang back - Teleplace has used Cog for about a year already? - Platform availability (64bit is not supported, iPhone/iPad VM's can't run them) - Still buggy (I've reported 2 so far) - No process established yet how / if to synch with current VMMaker (which contains quite a lot of fixes not found in Cog) - Plugin availability (f.ex. I tried building FT2Plugin using Cog structure on OSX, and failed miserably) - No good reason to release a backwards-incompatible image by default, when Cog translates them by default, but not the other way around. Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 22, 2010

[Pharo-project] [update 1.2] #12012

by StÃ©phane Ducasse

12012 ----- - Issue 2582: Rearrange World Menu - Issue 2069: Be able to load DummyUIManager in a Pharo image More to come A lot more... but busy Stef

June 22, 2010

Re: [Pharo-project] [update 1.1] #12012

by StÃ©phane Ducasse

my mistake I had to run and remove the updates from the updates. I will fix that after 19h30 Stef On Jun 22, 2010, at 2:17 PM, Torsten Bergmann wrote: >> any trouble? This update is still not available. >> http://pharo.gforge.inria.fr/updates/pharo1.2/updates.list > > Yes, I'm also not able to update from 12011 to 12012. > Is this related to Cog since 12011 included changes for that. > > And I think the topic of the mail should be "[update 1.2] #12012" > since it belongs to 1.2. > > Thx > Torsten > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 22, 2010

Re: [Pharo-project] DummyUIManager

by StÃ©phane Ducasse

I do not know :) did you try? Stef On Jun 22, 2010, at 12:37 PM, Pavel Krivanek wrote: > Hi Stef, > > I have a little idea about processing of package movements. What about > to move classes that will belong in the next update to another package > to the new temporary system category using the update script. That > temporary category will not have any corresponding package. Then the > update process will load new versions of the packages but because the > moved classes will not be in any package, the loading order will be > irrelevant and the right package will be assigned to the class during > the mergin. The temporary category will be empty in the end and can be > removed. The same way can be applicable for methods. > > Cheers > -- Pavel > > On Mon, Jun 21, 2010 at 5:51 PM, Pavel Krivanek > <pavel.krivanek(a)gmail.com> wrote: >> Hi Stef, >> >> 1) this UIManager patch >> 2a) there is a small count of minor kernel changes that should be >> harvested (SoundService and Browser dependency etc.) >> 2b) http://code.google.com/p/pharo/issues/detail?id=2105, I will have >> to check it again for the latest Pharo. >> >> In this stage it should be possible to shrink the image to about 3MB >> (very unclean) >> >> 3) reorganize methods to clean the kernel packages, >> 4) prepare network and monticello packages (quite easy) >> 5) modify the rest of packages to be loadable >> >> None of this steps is hard or extremely time consuming. However it >> requires at least two next eyes to audit the changes and a >> selfmurderer to integrate it into the update stream ;-) >> >> -- Pavel >> >> >> On Mon, Jun 21, 2010 at 3:57 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> On Jun 21, 2010, at 12:03 PM, Pavel Krivanek wrote: >>> >>>> Hi Mariano, >>>> >>>> it is not so straightforward. You simply cannot switch from Morphic to >>>> DummyUIManager (it requires several next steps and modifications). >>>> This patch is only a small step to better Pharo UI Independency and >>>> PharoKernel. >>> >>> It would be good to identify a roadmap of actions to step by step >>> arrive to this point. >>> Do you have a high level list? >>> >>> >>>> When Pharo will be PharoKernel ready, we may start to >>>> talk about benefits for the deployment. However you may add me as the >>>> book user ;-) >>>> >>>> -- Pavel >>>> >>>> 2010/6/21 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>>>> Hi pavel. This is excellent :) >>>>> >>>>> Now, it would be cool to document how to use it. And even more, the >>>>> scenarios where it can be useful. For example, suppose I deploy a headless >>>>> PharoCore image with seaside, should I replace the UIManager with the Dummy >>>>> ? what do I save? how can I do that? >>>>> >>>>> I think http://book.pharo-project.org/ is excellent for this. If you want >>>>> to write something please let me know and I make you an user. >>>>> >>>>> Thanks again >>>>> >>>>> mariano >>>>> >>>>> On Thu, Jun 17, 2010 at 11:36 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> >>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I updated issue http://code.google.com/p/pharo/issues/detail?id=2069 >>>>>> that adds DummyUIManager and makes Pharo more UIManager independent. >>>>>> >>>>>> Please review it, it is an important patch for better modularization. >>>>>> >>>>>> For the method fileInSilentlyAnnouncing: it only changes the category. >>>>>> >>>>>> Cheers, >>>>>> -- Pavel >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 22, 2010

Re: [Pharo-project] Cog - dumb question

by Henrik Johansen

On Jun 22, 2010, at 4:58 36PM, Yanni Chiu wrote: > Henrik Johansen wrote: >> The code works on both Cog and Closure VMs though, so development can >> continue on whatever VM you desire without a split in package >> versions. As Cog is able to read closure-images, but not the other >> way around, I imagine we will want to keep releasing official images >> saved by the closure VM. > > IMHO, we should move to Cog as soon as possible - once any major bugs, if any, are dealt with. So, change direction: abandon 1.2 (which just started) and go for 2.0, which requires an image format change (due to Cog VM). Is there a reason to hang back - Teleplace has used Cog for about a year already? - Platform availability (64bit is not supported, iPhone/iPad VM's can't run them) - Still buggy (I've reported 2 so far) - No process established yet how / if to synch with current VMMaker (which contains quite a lot of fixes not found in Cog) - Plugin availability (f.ex. I tried building FT2Plugin using Cog structure on OSX, and failed miserably) - No good reason to release a backwards-incompatible image by default, when Cog translates them by default, but not the other way around. Cheers, Henry

June 22, 2010

Re: [Pharo-project] Cog - dumb question

by Yanni Chiu

Henrik Johansen wrote: > The code works on both Cog and Closure VMs though, so development can > continue on whatever VM you desire without a split in package > versions. As Cog is able to read closure-images, but not the other > way around, I imagine we will want to keep releasing official images > saved by the closure VM. IMHO, we should move to Cog as soon as possible - once any major bugs, if any, are dealt with. So, change direction: abandon 1.2 (which just started) and go for 2.0, which requires an image format change (due to Cog VM). Is there a reason to hang back - Teleplace has used Cog for about a year already?

June 22, 2010

[Pharo-project] [update 1.1] #12012

by Torsten Bergmann

>any trouble? This update is still not available. >http://pharo.gforge.inria.fr/updates/pharo1.2/updates.list Yes, I'm also not able to update from 12011 to 12012. Is this related to Cog since 12011 included changes for that. And I think the topic of the mail should be "[update 1.2] #12012" since it belongs to 1.2. Thx Torsten -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

June 22, 2010