- Pharo-dev - lists.pharo.org

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

by Schwab,Wilhelm K

Mike, The rebuttal position: someone not long ago reported having to disable the OB debugger in order to "be able to use Pharo." FWIW, I was having some problems myself, and changed debuggers based on that report. My problems might have been due to a corrupted image, so changing debuggers might have been irrelevant to my ultimate climb out of the hole by building a new image. Your point about not spreading ourselves too thin is well taken, but I also wonder whether we should expect to have high end tools and a set with more modest demands on the cpu. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael Roberts Sent: Sunday, July 05, 2009 6:06 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Call: identifying issues relevant for 1.0 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

July 5, 2009

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

by StÃ©phane Ducasse

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

July 5, 2009

Re: [Pharo-project] Failing closures tests

by Mariano Martinez Peck

I think Eliot is not in this mailing list, so, I cc him. Cheers, Mariano On Sun, Jul 5, 2009 at 9:11 AM, Lukas Renggli <renggli(a)gmail.com> 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 Schwab,Wilhelm K

Reinout, The profiling tools are exposed through MessageTally. http://onsmalltalk.com/com/profiling-smalltalk should get you started. 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. Re slow updates, I am not sure what to expect, but Pharo's response times in general are of concern to me, and there are efforts getting under way to find out what is wrong (PackageInfo has been marked as a suspect a couple of times), what is realistic, and what can be done about it. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Reinout Heeck Sent: Sunday, July 05, 2009 6:36 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Loads of Pharo development process questions I'm having trouble wrapping my head around how the Pharo development/ maintenance process is supposed to work. Most of these seem to be missing info on the wiki which merely need fleshing out there, I would update the wiki pages myself if only I knew what to write... Please bear in mind that I'm a newbie to Squeak, so some of these questions may be rather naive. 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? 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? 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. 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? 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)? Is there a vision on long-term 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). 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. 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? 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? Let me finish with a quick and easy newbie question: where do I find the profiler tools for Pharo? Thanks! Reinout ------- _______________________________________________ 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] What will be the standard browser in Pharo?

by Schwab,Wilhelm K

Adrian, That's a pretty good summary of the details I listed. Perhaps more important, I am suggesting that we create benchmarks of a typical number of open browsers' response to normal use. We should probably also parameterize the theme in use and the options (Shout, free type, rounded corners, etc.) that are enabled, to allow us to compare the effects of the "luxury" items. Ideally, the benchmark would run all of the combinations and leave behind a text file identifying the also the contributor and their description of the machine, allowing us to see what clobers us on which OS+hardware. The category change I had in mind was of a class, in particular, suppose I have packages SpellingErrors-Stupid and SpellingErrors-ReelyStupid, and want to change the second one<g>; OB really ground to a crawl on things like that. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Sunday, July 05, 2009 6:32 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] What will be the standard browser in Pharo? Hi Bill, 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. Summarizing your mail below, the following are the most important actions to optimize: - response to keyboard input - time delays selecting a new class or method - time required to recompile a class - changing the category (class or method?) Anybody interested to do benchmarks of these actions (e.g., comparing Pharo to Pharo-core)? Cheers, Adrian 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

July 5, 2009

Re: [Pharo-project] about halos

by Damien Cassou

On Sat, Jul 4, 2009 at 4:35 PM, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> wrote: > damien it worked. Can you add an enty in the bugtracker? > so that I can close it done: http://code.google.com/p/pharo/issues/detail?id=935 -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 5, 2009

Re: [Pharo-project] Failing closures tests

by Lukas Renggli

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

July 5, 2009

[Pharo-project] Loads of Pharo development process questions

by Reinout Heeck

I'm having trouble wrapping my head around how the Pharo development/ maintenance process is supposed to work. Most of these seem to be missing info on the wiki which merely need fleshing out there, I would update the wiki pages myself if only I knew what to write... Please bear in mind that I'm a newbie to Squeak, so some of these questions may be rather naive. 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? 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? 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. 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? 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)? Is there a vision on long-term 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). 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. 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? 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? Let me finish with a quick and easy newbie question: where do I find the profiler tools for Pharo? Thanks! Reinout -------

July 5, 2009

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

by Adrian Lienhard

Hi Bill, 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. Summarizing your mail below, the following are the most important actions to optimize: - response to keyboard input - time delays selecting a new class or method - time required to recompile a class - changing the category (class or method?) Anybody interested to do benchmarks of these actions (e.g., comparing Pharo to Pharo-core)? Cheers, Adrian 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

July 5, 2009

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

by Michael Roberts

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

July 5, 2009