- Pharo-dev - lists.pharo.org

[Pharo-project] Compression question

by Bill Schwab

I am working on adapting some basic tools of mine to Pharo, and ran into a trick that use often: specifically, I use ZLib and Dolphin's ability to package globals to store compressed text for scripts, "empty" document files, etc. Then a small wrapper method uses ZLib to uncompress the content of the global w/o having to store all of data in the method source. There are other solutions, but I do this frequently and need to pick a way to handle it. At the most basic level, I found the compression stream and archives categories, but am unclear on where to look. If I want to have a byte array of data and "zip" or "unzip" it memory, is there a good entry point? Would I use a stream or an archive? Please do not feel pressed to do my browsing for me, but if somebody knows the answer, a class or method name would be appreciated. BTW, as further evidence of the accumulated effort, to check the jargon above, I just fired up an early 3.9 image that was handy, and the differences are striking! Maybe I do want to lean on Damien for an updated web image :) Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029

Sept. 27, 2008

Re: [Pharo-project] possible TODOs...

by Norbert Hartl

On Sat, 2008-09-27 at 16:35 +0100, Michael Roberts wrote: > I would keep them in the tracker too. the question in my mind is if > dumping a large list into a single issue scales? Perhaps by > convention if an issue contains a list, it is considered a bucket and > people break issues out on their own as they go? A single issue with > 100s of comments is going to get a mess. but then you have comments > on issues in two places. that would be where the wiki would help as a > dumping ground for lists, where you could delete items on insertion > into the tracker. I'm just thinking out loud... I implemented the > full screen but marcus beat me to it. i'll start at the bottom next > time ;) > > just my 0.02 GBP / EUR I'm not for a wiki page beside one that explains how to deal with tickets. This page is already there. As long as you cannot group tickets with assigned dependencies a ticket with 100 issues is not a good idea. Just create 100 issues where discussion takes place in every single issue. I don't see a single reason not to do so. Everything else is too complicated. Keeping information in two different places is a no no. If there is something more complex that has to go this way it is milestone planning. So you create a wiki page with all the issue numbers that have to be solved before the milestone is reached. Usually you would expect this from the tracker, too. But google code is not capable of doing this. In this case the wiki page does no harm as it is easy to sync. Just have a look at the tickets and you know what to do. I want to avoid new categories or types in the tracker as well as it just complicates things. If you need a strong filter for dealing with the tickets it is ok. that's another 2 cents (euro type) Norbert

Sept. 27, 2008

Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Bill Schwab

Damien, Stef, I _think_ what I would want for a starting point is something like Damien's web image, followed by a script that gets the latest of a few things, specific versions of others, and then loads a bunch of .cs or other files for my code. Damien, I suspect you put a lot of work into preparing your images, so please do not view this as anything other than gratitude driving some suggestions. With proper selection of browser and (sorry<g>) deactivating eCompletion, I very much enjoy your web image as a starting point. Whether I continue using it will depend on how hard it is to install Polymorph and the RB vs. Seaside and friends. Call me demanding, I want it all :) Installer can probably (either now or with some refinement) reduce Polymorph (which appears to be on its way into the Pharo base anyway???) and Seaside to one-liners in a script. Ditto cryptography. Add some lines to load .cs or whatever files I create on my own, and I should be able to download an image, and then run one script that builds the new image. I will stop short of asking you to manually keep up with the small releases, as I probably would end up waiting for the October release before building a new image. It would however be great to either reduce what you do to a simple script, or have it aggressively track updates once Pharo is officially released. >From a gradually decreasing distance at least, Installer looks like it is trying to fill a gap. As always, I would like to see Pharo sprout an ability to apply multiple categories per method; Dolphin has done that from (almost?) the beginning, and it is quite addictive. My point being that however clever, systems that take the one available category to package methods make the restriction all the more obvious. I hope that makes some sense. Thanks to all for what is shaping up to be a nice system! Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> damien.cassou(a)gmail.com 09/26/08 11:03 AM >>> On Fri, Sep 26, 2008 at 8:26 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > - For example I would like to have a real look at MC1.6 but the > message around it is blurry MC1.6 is not the topic here. > I tried LFP and it broke on me. It worked fine for me. You may want to try again and send bug report to Keith who answered all my emails. > - I like installer but when I look at the code I would like to refactor it. The code may not be perfect but it works fine. I don't think Keith would ignore our enhancements to his code. > - There is no document in a nice format that explain why and how (i'm > fixing that for installer and I was waiting because I will refactor it else I do not publish the chapter but I did not want to insult keith since this is not the point since I like installer). This is not fair. There is "no document in a nice format that explains" most of the tools you use everyday. But you still use them. The more people use a tool, the best chance you have to get documentation. Moreover, Keith and Matthew wrote a lot of things in pbwiki, squeak wiki and mailing lists. > - unknown is strange :) Should not be for us Squeakers and Pharoers. > - So if you want to help me I would love to have a > - Installer code refactored > - Installer chapter > - Sake (have a look at the code) > - Sake Chapter for the book I would love that too -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 27, 2008

Re: [Pharo-project] possible TODOs...

by Michael Roberts

I would keep them in the tracker too. the question in my mind is if dumping a large list into a single issue scales? Perhaps by convention if an issue contains a list, it is considered a bucket and people break issues out on their own as they go? A single issue with 100s of comments is going to get a mess. but then you have comments on issues in two places. that would be where the wiki would help as a dumping ground for lists, where you could delete items on insertion into the tracker. I'm just thinking out loud... I implemented the full screen but marcus beat me to it. i'll start at the bottom next time ;) just my 0.02 GBP / EUR Mike

Sept. 27, 2008

Re: [Pharo-project] About Flap

by Bill Schwab

Hello all, Flaps will be easier to remove than to replace, and toolbars and menus come to mind, of course. "The" world menu is a concept that always bothers me a little: while I like having the ability to run Pharo with what amounts to MDI (child shells in a single main window), it would be nice to have each shell/SystemWindow be a host window. In the latter situation, flaps and world menu are (correct me if I am wrong) largely homeless. Ok, a flap could be a host window of sorts (perhaps hidden when Pharo does not have focus), but Pharo no longer owns the desktop, so the world menu is gone, right?? Maybe it simply _should_ be gone in that case. In terms of flaps, they no doubt add to drawing overhead. Would that not improve if the polling were converted to handling events? Another helpful change would be to either replace "tearing off" a new tool to clicking/releasing a command button that simply opens it at default location and size, or changing the dragging to respect the fast window drag setting. I invariably set that even on new machines (not that I am quick to replace old ones). Bottom line: faster GUI code never hurts. A pop or a fast drag off of a flap should help. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> stephane.ducasse(a)inria.fr 09/27/08 1:59 AM >>> OK we will go slowly there. One of the problem is that flaps are taking also a cpu On Sep 27, 2008, at 12:27 AM, Gary Chambers wrote: > I quite like the tools flap, when configured for auto-popout and > with "solid" style... > Just my 2c > > Gary. > > > ----- Original Message ----- From: "Igor Stasenko" > <siguctua(a)gmail.com> > To: "An open mailing list to discuss any topics related to an open- > sourceSmalltalk" <pharo-project(a)lists.gforge.inria.fr> > Sent: Wednesday, September 24, 2008 8:46 PM > Subject: Re: [Pharo-project] About Flap > > >> 2008/9/24 Marcus Denker <denker(a)iam.unibe.ch>: >>> >>> On 24.09.2008, at 20:14, Bill Schwab wrote: >>> >>>> Lukas, >>>> >>>> That's fine if my hands are on the keyboard, but if I have one on >>>> the >>>> mouse (common when browsing), then (in Dolphin at least), I end up >>>> either right clicking on a class in an open browser, or hitting a >>>> toolbar button. For the more obscure tools, the shell menus >>>> (Tools) do >>>> the trick. Shortcuts are great, but we should also provide mouse- >>>> based >>>> options. >>>> >>> >>> remember: there will be a menu, with a "tools" entry. And there will >>> always be the world-menu (click on the backround). >>> >>> the flap is not faster in the number of clicks than a pulldown >>> menu... >>> >> >> well, with flaps is more convenient because you can drag a tool >> window >> and place it where you want to. >> While from menu - first, it placing a window automatically, and then >> often you need to arrange it again. >> How about putting a window in hand, when you opening it from menu? >> I find it very convenient and useful feature - it gives you chance to >> arrange window with no extra clicks. >> >> >>> Marcus >>> >>> -- >>> Marcus Denker -- denker(a)iam.unibe.ch >>> http://www.iam.unibe.ch/~denker >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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

Sept. 27, 2008

Re: [Pharo-project] possible TODOs...

by Norbert Hartl

On Sat, 2008-09-27 at 17:09 +0200, StÃ©phane Ducasse wrote: > I thought marcus was planning to create a wiki page with the todos. > So if you cannot find one, just create one. > I have the impression that we could use another tag for todo issue. > since wiki pages do not work well for trakcing. > I would opt for putting the todos in the tracker. IMHO it is impossible to keep a wiki page in sync. In tracker there is already something like a todo: an accepted enhancement! my 2 Norbert > On Sep 27, 2008, at 4:53 PM, Michael Roberts wrote: > > > folks, I was wondering (or I have missed the docs) if someone could > > update HowToContribute on the wiki to include the loose ideas for how > > to construct and manage wish lists & todos etc? Is the plan that the > > issue tracker is used as the master todo list? Say #186 contains a > > list of things to do. If I start working on one should I create a new > > entry so that I can show progress on it? I like the issue tracker, > > i'm just not entirely sure how to behave in this pre-coding / > > organisational phase. HowToContribute assumes pretty much you're > > ready with your mcz. > > > > cheers, > > Mike > > > > On Mon, Sep 22, 2008 at 9:12 AM, Marcus Denker <denker(a)iam.unibe.ch> > > wrote: > >> > >> On 21.09.2008, at 16:22, Janko MivÅ¡ek wrote: > >> > >>> Hi, > >>> > >>> Let me add few my wishes: > >>> > >>> - Inspect and Explore merging into just Inspect. By extending > >>> Explorer > >>> with remaining Inspector functionalities like editing objects? > >>> > >>> - Inspect always on the same place in menus, not once at the top, > >>> then on > >>> the middle, on the bottom... > >>> > >>> - same for senders/implementors > >>> > >>> - Integrating Monticello commands directly into code browser, in > >>> right-click menu over packages. This really helps with code > >>> management, I > >>> know that from VW. > >>> > >>> - switch off halos by default, > >>> > >>> - multi select by Ctrl-left click or Shift-left click (all other > >>> windowing > >>> systems have multi select, so it is a time to introduce it here > >>> too = a big > >>> plus for newcomers) > >>> > >> > >> Good ideas! I am collecting them for now in this bug-report: > >> > >> http://code.google.com/p/pharo/issues/detail?id=186 > >> > >> > >> Marcus > >> > >> > >> -- > >> Marcus Denker -- denker(a)iam.unibe.ch > >> http://www.iam.unibe.ch/~denker > >> > >> > >> _______________________________________________ > >> 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

Sept. 27, 2008

Re: [Pharo-project] possible TODOs...

by StÃ©phane Ducasse

I thought marcus was planning to create a wiki page with the todos. So if you cannot find one, just create one. I have the impression that we could use another tag for todo issue. since wiki pages do not work well for trakcing. On Sep 27, 2008, at 4:53 PM, Michael Roberts wrote: > folks, I was wondering (or I have missed the docs) if someone could > update HowToContribute on the wiki to include the loose ideas for how > to construct and manage wish lists & todos etc? Is the plan that the > issue tracker is used as the master todo list? Say #186 contains a > list of things to do. If I start working on one should I create a new > entry so that I can show progress on it? I like the issue tracker, > i'm just not entirely sure how to behave in this pre-coding / > organisational phase. HowToContribute assumes pretty much you're > ready with your mcz. > > cheers, > Mike > > On Mon, Sep 22, 2008 at 9:12 AM, Marcus Denker <denker(a)iam.unibe.ch> > wrote: >> >> On 21.09.2008, at 16:22, Janko MivÅ¡ek wrote: >> >>> Hi, >>> >>> Let me add few my wishes: >>> >>> - Inspect and Explore merging into just Inspect. By extending >>> Explorer >>> with remaining Inspector functionalities like editing objects? >>> >>> - Inspect always on the same place in menus, not once at the top, >>> then on >>> the middle, on the bottom... >>> >>> - same for senders/implementors >>> >>> - Integrating Monticello commands directly into code browser, in >>> right-click menu over packages. This really helps with code >>> management, I >>> know that from VW. >>> >>> - switch off halos by default, >>> >>> - multi select by Ctrl-left click or Shift-left click (all other >>> windowing >>> systems have multi select, so it is a time to introduce it here >>> too = a big >>> plus for newcomers) >>> >> >> Good ideas! I am collecting them for now in this bug-report: >> >> http://code.google.com/p/pharo/issues/detail?id=186 >> >> >> Marcus >> >> >> -- >> Marcus Denker -- denker(a)iam.unibe.ch >> http://www.iam.unibe.ch/~denker >> >> >> _______________________________________________ >> 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. 27, 2008

Re: [Pharo-project] Regression testing results within package manifesto

by StÃ©phane Ducasse

this is just for now a stupid package on squeaksource. the point is that I tried to make it independent of anything. May be the Manifesto should inherit from packageInfo. Stef On Sep 27, 2008, at 4:42 PM, Michael Roberts wrote: > Where can I read about DrDoc? > > thanks > > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 27, 2008

Re: [Pharo-project] possible TODOs...

by Michael Roberts

folks, I was wondering (or I have missed the docs) if someone could update HowToContribute on the wiki to include the loose ideas for how to construct and manage wish lists & todos etc? Is the plan that the issue tracker is used as the master todo list? Say #186 contains a list of things to do. If I start working on one should I create a new entry so that I can show progress on it? I like the issue tracker, i'm just not entirely sure how to behave in this pre-coding / organisational phase. HowToContribute assumes pretty much you're ready with your mcz. cheers, Mike On Mon, Sep 22, 2008 at 9:12 AM, Marcus Denker <denker(a)iam.unibe.ch> wrote: > > On 21.09.2008, at 16:22, Janko MivÅ¡ek wrote: > >> Hi, >> >> Let me add few my wishes: >> >> - Inspect and Explore merging into just Inspect. By extending Explorer >> with remaining Inspector functionalities like editing objects? >> >> - Inspect always on the same place in menus, not once at the top, then on >> the middle, on the bottom... >> >> - same for senders/implementors >> >> - Integrating Monticello commands directly into code browser, in >> right-click menu over packages. This really helps with code management, I >> know that from VW. >> >> - switch off halos by default, >> >> - multi select by Ctrl-left click or Shift-left click (all other windowing >> systems have multi select, so it is a time to introduce it here too = a big >> plus for newcomers) >> > > Good ideas! I am collecting them for now in this bug-report: > > http://code.google.com/p/pharo/issues/detail?id=186 > > > Marcus > > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 27, 2008

Re: [Pharo-project] Regression testing results within package manifesto

by Michael Roberts

Where can I read about DrDoc? thanks Mike

Sept. 27, 2008