- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fwd: Issue 513 in pharo: UTF8 and file names

by John M McIntosh

I've updated http://code.google.com/p/pharo/issues/detail?id=513 I think you can close it as fixed. There is however still a problem with the clipboard logic, but that is issue http://code.google.com/p/pharo/issues/detail?id=823 ? On 4-Jul-09, at 4:01 AM, StÃ©phane Ducasse wrote: > John or mike can you tell us your point of view on this issue? > > Stef > > Begin forwarded message: > >> From: codesite-noreply(a)google.com >> Date: July 4, 2009 12:22:14 PM CEDT >> To: stephane.ducasse(a)gmail.com >> Subject: Issue 513 in pharo: UTF8 and file names >> >> >> Comment #13 on issue 513 by damien.pollet: UTF8 and file names >> http://code.google.com/p/pharo/issues/detail?id=513 >> >> more info : >> http://developer.apple.com/qa/qa2001/qa1235.html >> http://developer.apple.com/qa/qa2001/qa1173.html >> >> (ps in my tests, sometimes I'd see blank characters at the end of >> the name, sometimes in the middle after an >> accented char, etc) >> >> -- >> You received this message because you are listed in the owner >> or CC fields of this issue, or because you starred this issue. >> You may adjust your issue notification preferences at: >> http://code.google.com/hosting/settings > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

July 5, 2009

Re: [Pharo-project] Loads of Pharo development process questions

by Reinout Heeck

Hi Stef! Thanks for the in-depth answers, some remarks/further questions: > the update is only working for the core because OB is not part of > pharo but an add-on. > And the add-on are not managed by the pharo stream of changes but by > an update of > the projects in the pharo Universe (yes this is complex but we do not > want that people can > say that we are hijacking squeak tools). The motivation is fair, but the current solution seems untenable... I think we should consider cribbing from the model that Linux distros use: Load (more precisely: use -- we might not be able to load it) a / specific/ version of the Squeak tool, and then apply a separate (Pharo- maintained) set of patches to make it Pharo compliant. Define a process to specify how bug fixes are to be pushed upstream, and how enhancements are pulled downstream -- reassessing the Pharo patches each time a new version is pulled downstream. This way the tool is never hijacked but Pharo has a clear story on how it remains stable/unbreakable. If pushing bug fixes upstream is supported directly by tools we might even be able to make the argument that Pharo is helping the tool builders make better Squeak tools ;-) >> Pharo wants to be agile and be free to change at will (IMO a good >> decision) but if it is to be viable at my job there need to be >> versions that receive long-term support (the 'professional' aspect of >> Pharo). > > Yes > Normally with Squeak, severe bugs and selected one where retrofitted > in old versions. This way seaside 3.8 users got important fixes when > we did 3.9. It depends on how often Pharo wants to do a 'stable' release, if that is once every two years I don't see a problem with this model. But if that happens more often we will need to maintain a lot of older releases to make them viable for commercial use, thus spreading our resources thin. Hence my desire to pick only select releases that are designated to receive 'long term support' so bugfix back-porting efforts are concentrated on only one or two older releases to keep those alive for say 3+ years. [...for version management] > The vision is bytecode loader Pleas don't go there. Byte-code loading is a very nice-to-have in deployment scenarios (lazy plugin loading, live update delivery to deployed apps etc) but if there is one thing that using VW's Store has taught me it is that it definitely should not be part of a code repository that is used for development code version management. In the case of VW+Store standardizing on using only source-loading has served us well, it is definitely fast enough. Building our 'refactoring' image that holds all our projects (almost 100 MB image -- just code) takes less than an hour which is quite alright in a scenario where one uses nightly builds and updates the resulting image during the day-time development cycle. I suggest to get source-loading/diffing et al up to speed first. Cheers! Reinout -------

July 5, 2009

Re: [Pharo-project] Pharo Sprint in Berne, Switzerland

by Alexandre Bergel

Thanks for having had the idea. I had a wonderful time there. Cheers, Alexandre On 5 Jul 2009, at 12:30, Adrian Lienhard wrote: > Hi all, > > The sprint of yesterday was a success and great fun. Thanks to all > participants! For some details and pictures, see http://www.adrian-lienhard.ch/blog?dialog=pharo-sprint-in-bern-july-4-2009 > > Cheers, > Adrian > ___________________ > http://www.adrian-lienhard.ch/ > > On Jun 25, 2009, at 22:48 , Adrian Lienhard wrote: > >> Hi all, >> >> We are going to do a Pharo sprint in Bern on Saturday, July 4. >> >> http://code.google.com/p/pharo/wiki/PharoSprints >> >> Please add yourself to the list if you plan to attend (or send me a >> mail so I can add you). >> >> The main goal is to get closer to a first beta release. If you wish >> to >> work on other stuff, e.g., OmniBrowser, please propose this here so >> we >> can organize a bit in advance. >> >> Cheers, >> Adrian >> ___________________ >> http://www.adrian-lienhard.ch/ >> >> >> _______________________________________________ >> 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 5, 2009

Re: [Pharo-project] What will be the standard browser in Pharo?

by Alexandre Bergel

> David and Alex made couple of speed improvements in OmniBrowser during > yesterday's sprint. I will let them detail on what they achieved so > far. We did some benchmark and apparently there was some redundancy when updating. We also reduced the button at the top of the browser, apparently few people actually used them, and they consumed time to refresh. One of the result of this experiment, is that profiling tools in Squeak/Pharo are of a poor quality. There is definitely rooms for improvements, but this is getting complex. Cheers, Alexandre > > On Jul 4, 2009, at 21:08 , Schwab,Wilhelm K wrote: > >> Adrian, >> >> I share Stef's enthusiasm for your suggested process. Thanks for >> taking my prods about speed in the constructive spirit in which they >> are intended. >> >> One concern though: is the benchmark of opening and closing browsers >> able to give a realistic comparison of performance? Time to open a >> debugger is probably worth noting, but the things that concern me >> most with the browsers are poor response to keyboard input, time >> delays selecting a new class or method, and (most notably) time >> required to recompile a class; changing the category can take >> several seconds in my experience. >> >> Re keyboard input, I suspect characters are being lost; in fairness, >> that is difficult to test, because it requires typing quickly and >> accurately. Still, Pharo strikes me as just not being able to keep >> up, and it's worse with the package browser. You are of course >> correct to keep free type and Shout on the list of suspects, though >> I must say that Shout has always struck me as eerily fast. >> >> In short, I do not dispute that the difference is speed is small, >> especially for the open/close that is benchmarked. However, there >> is simply no "extra speed" to waste. Ideally, benchmarks should >> compare the different browsers with and without shout and free type, >> rounded corners, etc., and should separate selecting a new class and >> method. >> >> Some of my trouble might stem from using Linux for much of my work. >> I cannot describe the extent of my frustration with Windows - I've >> had it and then some. I'll stop the rant there (yes, I could go on >> for a while yet<g>). However, I cannot in good conscience join the >> "Linux is faster than Windows" crowd, and I am willing to consider >> the possibility that the display handling in the linux vm (no >> accusations, just in the interest of intellectual honesty) might >> have room for improvement, and/or the design of X-windows might not >> help. >> >> Bill >> >> >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr >> ] On Behalf Of StÃ©phane Ducasse >> Sent: Friday, July 03, 2009 4:48 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] What will be the standard browser in >> Pharo? >> >> yes yes yes! >> >> Stef >> On Jul 3, 2009, at 10:15 AM, Adrian Lienhard wrote: >> >>> Hi Bill, >>> >>> Performance is certainly important. Please don't stop bugging us to >>> make progress at this front too ;) >>> >>> What we should start with is to identify which features makes it >>> slow. >>> >>> I recently posted basic benchmarks [1], but we need to identify >>> single >>> features so that we know where to optimize or which features should >>> better be disabled. >>> >>> What would help is if you could tell us what exactly is slow (at the >>> moment I'm mainly working in the core image without freetype fonts >>> and >>> speed feels ok on my MacBook Pro). >>> >> Cheers, >>> Adrian >>> >>> [1] >>> http://lists.gforge.inria.fr/pipermail/pharo-project/2009-June/ >>> 009905. >>> html >>> >>> >>> On Jul 3, 2009, at 00:29 , Schwab,Wilhelm K wrote: >>> >>>> Stef, >>>> >>>> Understood, but since you appear to be leaving open things that I >>>> consider to be drastic (removing traits), it only seems reasonable >>>> to >>>> try the faster browser on some slower machines to see what impact >>>> it >>>> makes. It would not take too much prodding for me to be able to >>>> give >>>> some guidance along the lines of "not enough impact to be of help" >>>> or >>>> "well worth adopting." _Something_ is eating up a lot of clock >>>> cycles at present. >>>> >>>> Bill >>>> >>>> >>>> ________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>>> [mailto:pharo-project-bounces@lists.gforge.inria.fr >>>> ] On Behalf Of Mariano Martinez Peck >>>> Sent: Thursday, July 02, 2009 4:25 PM >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] What will be the standard browser in >>>> Pharo? >>>> >>>> "Ideally we would love to have a fast browser with package >>>> support:..." >>>> >>>> Notice the "ideally" and the "would" haha >>>> >>>> On Thu, Jul 2, 2009 at 8:22 PM, Schwab,Wilhelm K >>>> <bschwab(a)anest.ufl.edu <mailto:bschwab@anest.ufl.edu>> wrote: >>>> Stef, >>>> >>>> Is there a way to get the fast browser, or an image with it loaded? >>>> >>>> Bill >>>> >>>> >>>> -----Original Message----- >>>> From: >>>> pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project- >>>> boun >>>> ces(a)lists.gforge.inria.fr >>>>> [mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo- >>>>> pro >>>>> ject-bounces(a)lists.gforge.inria.fr >>>>> ] On Behalf Of StÃ©phane Ducasse >>>> Sent: Thursday, July 02, 2009 3:30 PM >>>> To: >>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo- >>>> project(a)lists.gforge >>>> .inria.fr >>>>> >>>> Subject: Re: [Pharo-project] What will be the standard browser in >>>> Pharo? >>>> >>>> Hi oscar >>>> >>>> Ideally we would love to have a fast browser with package support: >>>> - dual browser >>>> - class extensions >>>> - traits >>>> - refactoring >>>> - icons >>>> >>>> Now apparently OBEnhancements was a bit dirty and this is not clear >>>> what colin will integrate or not. >>>> Lukas has a OB version which is fast but it does not have >>>> - dual browser >>>> - class extensions >>>> - traits >>>> - icons >>>> So david and lukas should talk a bit more and we could get the best >>>> of the worlds. >>>> Saturday we should have a discussion. Having a fast but powerful >>>> browser is important and right now if the browser does not support >>>> trait then we should remove traits from the image. >>>> Similarly we cannot work well without class extension support and >>>> other package related functionality. >>>> Stef >>>> >>>> >>>> >>>> On Jul 2, 2009, at 9:07 PM, Oscar Nierstrasz wrote: >>>> >>>>> >>>>> Hi Folks, >>>>> >>>>> I am trying to port Squeak by Example to Pharo by Example. I am a >>>>> bit confused about what is suppose dto be the standard browser >>>>> now. >>>>> I thought it was the OB Package Browser, but Damien Cassou just >>>>> gave >>>>> me a new image where the browser is an OB System Browser >>>>> (Categories, not packages). I cannot even see any more how to >>>>> switch between the two. >>>>> >>>>> Can someone enlighten me? (Then I can explain it in the book.) >>>>> >>>>> - on >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo- >>>>> project(a)lists.gforg >>>>> e.inria.fr >>>>>> >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr<mailto: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<mailto: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 > > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 5, 2009

Re: [Pharo-project] Loads of Pharo development process questions

by Reinout Heeck

> Please note that Pharo is not even yet in beta, so some of the snags > you mention will no doubt get fixed as the feature list finalizes. > As an open source project, there will be a certain amount of bias > toward what is important to the heavy contributors. I hope those > will include organizations such as yours to push Pharo in the > direction of a stable performance-oriented environment on top of > which a mix of commercial and academic projects will flourish. Yes, yes, yes :-) This is why I showed up here, at the moment it is just me probing around in my private time but the motivation is to lobby for considering its use at my work. I assume there will be loads of additions required before we can even use it in the small there and clearly such additions won't just appear unless we contribute heavily towards them ourselves. (Off the cuff I'm thinking of requirements like full SOAP(all versions!) with support tools, multiple windows, COM interfacing etc, etc, but I need to cut my teeth on the basics first before I want to start discussing such things here). Baby steps will do just fine ;-) Thanks! Reinout -------

July 5, 2009

Re: [Pharo-project] FFI problem

by Mariano Martinez Peck

Andreas: can you see new comments here: http://code.google.com/p/pharo/issues/detail?id=908 What do you think? Thanks! Mariano On Tue, Jun 30, 2009 at 12:26 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > I crated the issue so that no to forget about it: > > http://code.google.com/p/pharo/issues/detail?id=908 > > Best, > > Mariano > > > On Sun, Jun 28, 2009 at 3:56 AM, Andreas Raab <andreas.raab(a)gmx.de> wrote: > >> Mariano Martinez Peck wrote: >> >>> Ok. Pharo people is in this mail. Let's wait if someone can help us. >>> >> >> Please cc vm-dev on any responses. I'm not subscribed to the Pharo list. >> >> I don't know why in mi Windows machine the dump file is not generated :( >>> >> >> It looks like the crash has two different ways of showing. In the first >> situation, it crashes with a recursive DNU. In the second, it actually does >> generate a crash dump (attached). The latter seems to happen when you try to >> step through the code. >> >> Benoit St-Jean can you attach the complete dump file? >>> >>> I tried this in Linux and it doesn't crash my image. So, only windows :( >>> >> >> Difficult to say. There is a good possibility that the problem is >> unrelated to the FFI since I have been completely unable to reproduce the >> problem elsewhere. >> >> Cheers, >> - Andreas >> > >

July 5, 2009

Re: [Pharo-project] Loads of Pharo development process questions

by Mariano Martinez Peck

> > > > The process of updating the dev image is excruciatingly slow, is this > > normal? > Yes, this proccess is slow. However, I noticed sometimes is VERY low. Are you using Nod32? If you do, please exclude the directory where squeak is and you will see the difference :) This is because .changes is being modified all the time and NOD32 checks that file for virus or something like that. I noticed this problem at work, where I have windows :( Cheers and welcome! Mariano > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 5, 2009

Re: [Pharo-project] Call: identifying issues relevant for 1.0

by Adrian Lienhard

I second that. Added the tag 1.0 to #709. Adrian On Jul 5, 2009, at 20:11 , StÃ©phane Ducasse wrote: > the core debugger is important and it will continue to be important. > > stef > > On Jul 5, 2009, at 1:06 PM, Michael Roberts wrote: > >> I know it is quite a job, but I would like to see the core debugger >> fixed and maintained - or removed. #709 is a serious issue unless >> someone has recently fixed it. I have not used the OB one too much, >> so I guess it comes down to a discussion of what the official tool- >> set >> actually is for Pharo. I don't think we really have the bandwidth to >> maintain two toolsets, but we are currently keeping them around. >> >> thanks, >> Mike >> >> _______________________________________________ >> 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

July 5, 2009

Re: [Pharo-project] Failing closures tests

by StÃ©phane Ducasse

Please mark them as expected failures but do not remove them because they show the real semantics of closure. Stef On Jul 5, 2009, at 2:11 PM, Lukas Renggli wrote: > ClosureTests>>#testToDoOutsideTemp and > ClosureTests>>#testWhileModificationBefore demonstrate two minor > problems with the closure implementation. Many Smalltalk > implementations (including the expensive industrial strength ones) get > these two and some of the other tests in ClosureTests wrong. > > If these two tests cannot be easily fixed I don't think they are a > show stopper and should be marked as expected failures. I don't know > about the other closure tests. > > Cheers, > Lukas > > > 2009/7/5 Adrian Lienhard <adi(a)netstyle.ch>: >> Hi Eliot and Lukas >> >> There are 9 failing tests in the two classes ClosureCompilerTests and >> ClosureTests that you wrote. >> >> Do they document bugs in the implementation, and if yes, what needs >> to >> be done? >> >> Thanks, >> Adrian >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 5, 2009

Re: [Pharo-project] Loads of Pharo development process questions

by StÃ©phane Ducasse

Hi reinout > Please bear in mind that I'm a newbie to Squeak, so some of these > questions may be rather naive. We welcome newbie like you :) > One of my motivations is to evaluate the future viability of Pharo as > a vehicle for commercial applications and whether it warrants to lobby > for resources being allocated to its development. > > So here goes: > > The wiki mentions 'kernel' and 'MiniImage' as not being in scope of > Pharo. > What does that entail, does this mean that discussions about allowing > nil in Sets are out of scope? ok this is old. this was by reference to the effort of pavel to create a minimal kernel. We did not want to stress that the only effort of pharo was to have a small kernel. Our effort is to have a modular, clean, tested smalltalk (which will probably have a small kernel). > What is the status of the dev-image? As delivered the tools are broken > (because context menus on the source pane raise an UHE that is induced > by OB-Enhancements, issue 904), is it actively used by the main > committers or is the core image the place to be? The dev image is alpha like pharo. Some of the OB code changes under the feet of david. He promised us to fix that. > Even more confusingly the above issue has been marked as fixed this > night but if I do a World->System->Software Update the bug persists in > my image. the update is only working for the core because OB is not part of pharo but an add-on. And the add-on are not managed by the pharo stream of changes but by an update of the projects in the pharo Universe (yes this is complex but we do not want that people can say that we are hijacking squeak tools). > When I looked into fixing it myself I got confused (because I looked > at InstallScript.st), it seems the code comes from various > repositories -- not a single Pharo respository/branch. Are these > various repositories Pharo-specific and maintained over Pharo-Inbox or > do I need to submit fixes to different places? ok for pharo code we have Pharo (our components) PharoInbox (for people to post) PharoTaskForces (for effort related to pharo but not ready yet) PharoTreatedInbox (once we clean the inbox we do not delete but move to an archive). > I guess as a Squeak newbie I need a high-level overview on the wiki on > how code and fixes flow within Pharo, towards Squeak and towards the > various tool maintainers (and back to Pharo of course, the upstream/ > downstream story). What is the story when such tools and Pharo become > incompatible and need to fork (or are they already forked)? Ok here it is: - when a fix for pharo arrives via the inbox - we treat it -> reject with reason -> integrate it in the pharo core stream - when a fix arrives for a tool we cannot do too much besides asking that the maintainer push it into his code -> this implies that some tools may fork. > Is there a vision on long-term support? You mean are they pharoers that you can pay to maintain and provide support? Yes I imagine that you can pay john mcintosh, mike rueger and some others to offer support. > Pharo wants to be agile and be free to change at will (IMO a good > decision) but if it is to be viable at my job there need to be > versions that receive long-term support (the 'professional' aspect of > Pharo). Yes Normally with Squeak, severe bugs and selected one where retrofitted in old versions. This way seaside 3.8 users got important fixes when we did 3.9. > At least bug fixes (and hopefully speed enhancements) need to be > ported back to an 'LTS' release for quite a while (I'm thinking three > to four years here) and on a consistent/reliable basis if Pharo is to > be viable for the kind of projects I work on. Since all the code is and will be available either people will have to do it or they should pay for it. We will be able to do the critical ones only. > Porting our projects (and project specific tool enhancements) > forwards turns out to be very > expensive (even in a 'conservative' environment like VisualWorks) so a > mechanism needs to be in place to avoid needing too many porting > moments over the lifetime of our projects (think 10+ years). > The process of updating the dev image is excruciatingly slow, is this > normal? Yes the complete code of the package is sent, parsed, compared..... We do not have bytecode and the packageInfo used by Monticello is really slow since it simulates packages by scanning the complete systemOrganisation all the time. I started to write a real package class with pointers to replace that. But I do that on my spare time. > The process seems to be CPU bound and takes ages for what I consider a > small amount of changes - in its current state it would be unusable > for the process we use at work, it will need to be brought back to > well under a minute as opposed to the twenty (or so) minutes it took > me yesterday. What is the background and vision for the future on > this issue? The vision is bytecode loader + real package + probably using monticello 2 when it will be ready. > Let me finish with a quick and easy newbie question: > where do I find the profiler tools for Pharo? I like this question. We need more of profiler and fixes. MessageTally SpaceTally bench millisecondsToRun: Reinout. We know that the road will be long and we do not have engineers but we will do it small steps at a time and see if we succeed. stef

July 5, 2009