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

Re: [Pharo-project] A .mcz of Pinesoft's accumulated fixes applicable to Pharo

by Simon Kirk

Hmm, OK, I've had a dig around. I tried with a Pharo0.1-10074-oneclick package, and I think I see what you mean: viewing changes via the MC browser on the package I attached simply shows the entire method in red - even though if I go and find the equivalent method in the image it exists and should be showing changes instead. I then tried with a Pharo0.1-PolymorphTT package, as I'm more familiar with the diff tool from Gary's work. Again, the same problem. However, if I load the MCZ into the package, then pick, say, BrowserCommentTextMorph>>#hidePane and view the versions of the method, I can then see both the original method (sd 11/20/2005 21:26) and Gary's new version, and the differences between the two. So, perhaps the problem is that the Monticello browser can't show you differences between methods when one method is in the image under one class category, while the one in the Monticello package to be loaded is under a different one (the method in this case is an extension, so the method category for #hidePane would change from "displaying" to "*Pinesoft-Fixes-Misc" I hope that makes sense. I would have thought you would want to keep the original method categories, just keeping the method source from the MCZ. Unfortunately my knowledge of managing such changes falls well short of knowing how to go about that :( Hope this has all made sense and is helpful Cheers, S On 27 Sep 2008, at 06:58, StÃ©phane Ducasse wrote: > > On Sep 26, 2008, at 10:07 PM, Simon Kirk wrote: > >> hi Stef. >> >> Hmm, strange. How are you viewing the diffs? If I browse the MCZ in >> a Monticello browser I see extensions to these classes: >> >> BrowserCommentTextMorph >> BrowserRequestor >> CanvasCharacterScanner >> Character >> ConnectionQueue >> GrafPort >> MultiCanvasCharacterScanner >> NaturalLanguageTranslator >> Random >> RemoteString >> TranscriptStream >> >> Is this the diffs you're talking about? If so, I think they're >> correct. It's possible my rough list below may have missed some >> changes. > > > I see the same but I cannot see the diff between the changes and > what is in the image (for example in the merge > tools I do not (changed) and the like. > > Stef > >> >> >> Cheers, >> Simon >> >> On 26 Sep 2008, at 20:20, StÃ©phane Ducasse wrote: >> >>> Simon >>> >>> with which machine did you create you mcz? >>> Because apparently I can see the diffs for other packages. >>> >>> Can somebody else check the pinesoft package I put in the >>> pharoInbox? >>> >>> Stef >>> >>> >>> >>>> Hi all. >>>> >>>> Gary and I decided we ought to give out an MCZ of our fixes that >>>> we've put together over the last two years. >>>> >>>> Obviously some of those we found have been pulled into Pharo >>>> already, but the attached MCZ represents those that we think are >>>> still relevant :) >>>> >>>> This is a rough list of the fixes: >>>> >>>> 1. Fixed flaky borwser comment text area sometime not showing. >>>> >>>> 2. Added getArgumentPermutation to support RefactoringEngine. >>>> >>>> 3. Fixes to CanvasCharacterScanner and >>>> MultiCanvasCharacterScanner to correctly align the first line of >>>> text when centered/justifed etc. >>>> >>>> 4. Added more constant names to Character class. >>>> >>>> 5. Modified ConnectionQueue to not accept connections when queue >>>> is full. >>>> >>>> 6. Changed GrafPort to answer a MultiDisplayScanner when >>>> appropriate (allows subclasses of MultiNewParagraph). >>>> >>>> 7. NaturalLanguageTranslator startup postion move to after >>>> PasteUpMorph since it will show a progress bar. >>>> >>>> 8. Fix to Random>>nextInt: to allow large numbers which would be >>>> out of range if using Floats (as mentioned recently on dev, use >>>> of Floats is dodgy anyway...) >>>> >>>> 9. Changed TranscriptStream>>clear to use a new buffer (was just >>>> reset which could leave a massive collection). >>>> >>>> 10. Changed RemoteString to handle concurrent processes safely. >>>> This one's particularly interesting: we were load-testing our >>>> Seaside app here and getting lots of syntax errors when hitting >>>> the image with around the 20 concurrent processes due to source >>>> file access. After this change we were hitting it with >>>> approximately 500 concurrent processes, and the failure was in >>>> the Java load tester (it timed out). >>>> >>>> Hope just submitting a .mcz is OK! :) >>>> >>>> Cheers, >>>> Simon and Gary >>>> >>>> >>>> >>>> ****************************************************************************************************************************************** >>>> This email is from Pinesoft Limited. Its contents are >>>> confidential to the intended recipient(s) at the email >>>> address(es) to which it has been addressed. It may not be >>>> disclosed to or used by anyone other than the addressee(s), nor >>>> may it be copied in anyway. If received in error, please contact >>>> the sender, then delete it from your system. Although this email >>>> and attachments are believed to be free of virus, or any other >>>> defect which might affect any computer or IT system into which >>>> they are received and opened, it is the responsibility of the >>>> recipient to ensure that they are virus free and no >>>> responsibility is accepted by Pinesoft for any loss or damage >>>> arising in any way from receipt or use thereof. >>>> ******************************************************************************************************************************************* >>>> >>>> >>>> Pinesoft Limited are registered in England, Registered number: >>>> 2914825. Registered office: 266-268 High Street, Waltham Cross, >>>> Herts, EN8 7EA >>>> <Pinesoft-Fixes-Misc-gvc.24.mcz> >>>> _______________________________________________ >>>> 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 >> >> >> >> ****************************************************************************************************************************************** >> This email is from Pinesoft Limited. Its contents are confidential >> to the intended recipient(s) at the email address(es) to which it >> has been addressed. It may not be disclosed to or used by anyone >> other than the addressee(s), nor may it be copied in anyway. If >> received in error, please contact the sender, then delete it from >> your system. Although this email and attachments are believed to be >> free of virus, or any other defect which might affect any computer >> or IT system into which they are received and opened, it is the >> responsibility of the recipient to ensure that they are virus free >> and no responsibility is accepted by Pinesoft for any loss or >> damage arising in any way from receipt or use thereof. >> ******************************************************************************************************************************************* >> >> >> Pinesoft Limited are registered in England, Registered number: >> 2914825. Registered office: 266-268 High Street, Waltham Cross, >> Herts, EN8 7EA >> >> _______________________________________________ >> 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 ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Sept. 27, 2008

Re: [Pharo-project] Compression question

by StÃ©phane Ducasse

On Sep 27, 2008, at 5:59 PM, Bill Schwab wrote: > 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? Probably a stream. But I'm not expert. > 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 > > > _______________________________________________ > 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

we should split the list into issues but we should tag them as todo. Stef On Sep 27, 2008, at 5:35 PM, 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 > > 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

[Pharo-project] Regex11 -> regex 13. in VW

by StÃ©phane Ducasse

Begin forwarded message: > From: "Steven Kelly" <stevek(a)metacase.com> > Date: September 17, 2008 1:24:16 PM CEDT > To: "Vassili Bykov" <smalltalkbigot(a)gmail.com>, Steffen MÃ¤rcker <merkste(a)web.de > > > Cc: vwnc mailing list <vwnc(a)cs.uiuc.edu> > Subject: Re: [vwnc] Fwd: Regex11 > > OK! I've updated the code, tests and documentation and published as > 1.3. > > I second the vote for a Character predicate for this in the base - > it would replace longer code in 7 places in a current standard > image. I think the name should be #isWordConstituent, since > "identifier" generally implies the first character is not numeric. > > Steve > >> -----Original Message----- >> From: vwnc-bounces(a)cs.uiuc.edu [mailto:vwnc-bounces@cs.uiuc.edu] On >> Behalf Of Vassili Bykov >> Sent: 17 September 2008 00:16 >> To: Steffen MÃ¤rcker >> Cc: vwnc mailing list >> Subject: Re: [vwnc] Fwd: Regex11 >> >> I think \w should include underscore to match what seems to be the >> expected behavior out there. Going a step further, perhaps a >> Character >> predicate named something like #isIdentifierConstituent to include $_ >> in addition to pure alphanumerics would be useful. >> >> Cheers, >> >> --Vassili >> _______________________________________________ >> vwnc mailing list >> vwnc(a)cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ > vwnc mailing list > vwnc(a)cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > ------- Weitergeleitete Nachricht ------- > An: "Vassili Bykov" <smalltalkbigot(a)gmail.com> > Kopie: > Betreff: Regex11 > Datum: Mon, 15 Sep 2008 09:33:13 +0200 > > Dear Vassili Bykov, > > as far as I can see you've written the Regex11 package and I think > I've > found a bug. The documentation states: > > \w any word constituent character (same as [a-zA-Z0-9_]) > > but the actual implementation fails with underscores: > > '_' matchesRegex: '\w' "evaluates to false" > '_' matchesRegex: '[a-zA-Z0-9_]' "evaluates to true" > > Should the bug be fixed because we rely on the definition of \w or > is it > the better way to adjust the documentation in order not to break > existing > applications? How can I help?

Sept. 27, 2008

Re: [Pharo-project] Linux VM building - Where's Eliots closure code?

by Nikolay Suslov

Here is the link to files: http://www.mirandabanda.org/cogblog/downloads/ Regards, Nikolay On Sat, Sep 27, 2008 at 7:14 PM, <bryce(a)kampjes.demon.co.uk> wrote: > > I've made decent progress with merging and building. Just got a > working TrueType image. There's still work to be done on automating > the build. Makefiles still require manual editing, and I haven't > automated the image build fully. > > Where's Eliot's closure bytecode code? Preferably as an > mcz. Hopefully, I'll be ready to look at that this weekend. > > Bryce > > _______________________________________________ > 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

[Pharo-project] Fwd: Published a fix for WideString fromPacked: 'TEXT' asPacked

by StÃ©phane Ducasse

Begin forwarded message: > From: pharo-project-owner(a)lists.gforge.inria.fr > Date: September 27, 2008 9:04:14 AM CEDT > To: stephane.ducasse(a)free.fr > Subject: Published a fix for WideString fromPacked: 'TEXT' asPacked > > You are not allowed to post to this mailing list, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > pharo-project-owner(a)lists.gforge.inria.fr. > > > From: stephane ducasse <stephane.ducasse(a)free.fr> > Date: September 27, 2008 9:04:12 AM CEDT > To: An open mailing list to discuss any topics related to an open- > source Smalltalk <Pharo-project(a)lists.gforge.inria.fr> > Subject: Published a fix for WideString fromPacked: 'TEXT' asPacked > > > in multilangual in inbox > > Stef > > >

Sept. 27, 2008

[Pharo-project] Linux VM building - Where's Eliots closure code?

by bryce＠kampjes.demon.co.uk

I've made decent progress with merging and building. Just got a working TrueType image. There's still work to be done on automating the build. Makefiles still require manual editing, and I haven't automated the image build fully. Where's Eliot's closure bytecode code? Preferably as an mcz. Hopefully, I'll be ready to look at that this weekend. Bryce

Sept. 27, 2008

[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

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

by StÃ©phane Ducasse

> > > Keith, please correct me if I'm wrong: > > - Sake is a domain specific language with all required tools to define > make-like rules. It allows people to describe tasks (as done in the > Ant/Java world) and execute these tasks when necessary > (http://wiki.squeak.org/squeak/5953) Yes we need that > > - Packages uses Sake to reimplement a universe-like tool with > dependencies. Then, it describes a lot of Squeak packages with their > dependencies. Ok >> What is PackagesSqueak310U....? > > > this is a class which has been generated automatically by a Sake task > from the Dev Universe. This means that each change I do in the > Universe system is reflected automatically in Sake just by running a > task. > > Moreover, the fact that each package is describe in a method using > only Smalltalk code makes creating new set of packages very easy. For > Pharo, we could just subclass PackagesSqueak310U and override the > methods we want to change. For Seaside, they could just provide yet > another class... I think it's much easier than with Universes. > Finally, the package descriptions are hosted on SqueakSource instead > of one's particular server. Good! So let us check that. Don't you want to write something for the next book Squeak by Example VOl 2 (err....Phar ....) Stef > > > -- > 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) > _______________________________________________ > 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] Fwd: [Seaside-dev] preliminary Seaside 2.9 alpha universe

by StÃ©phane Ducasse

Thanks I will. since like me you would like to see some of the ideas od keith to be put forward. If you have some time, read the code andgive feedback I would like to continue to cruve out etoy for now. On Sep 27, 2008, at 11:43 AM, Damien Cassou wrote: > On Fri, Sep 26, 2008 at 6:25 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> On Sep 26, 2008, at 5:03 PM, Damien Cassou wrote: >> Did you check what LFP is doing? >> I would like to know that. >> Because the point is not that it would not be working but what are >> the stuff >> it brings in. > > http://installer.pbwiki.org/LevelPlayingField > > LPF is a script which installs Monticello 1.5 and Installer in your > image. The aim here is to get an equivalent playing field in all > images. This script allowed me to install Universes, OmniBrowser and > Shout in a Croquet image in a few minutes. > > For Pharo, we could have a look at what the script does exactly and > integrate the interesting fixes. > > -- > 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) > _______________________________________________ > 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

I do not see how we can synchronise real texttual documentation other by care. For the tests I would like to have information such as: the last time (with a timestamp) the tests were run for this package these ones were ok and those ones not. This way we could have regression data. Same for SmallLint I would like that a package defines the list of rules that make sense to it and may be the expected results. Stef On Sep 27, 2008, at 10:23 AM, Alexandre Bergel wrote: > The idea is nice. But how will you ensure that your meta-data are > well synchronized with your code? > > Cheers, > Alexandre > > > On 27 Sep 2008, at 09:40, StÃ©phane Ducasse wrote: > >> Hi guys >> >> For Moose we started to add package manifesto using DrDoc. >> We will use the manifesto to document our package with license, >> documentation, class diagram... >> Now what I would really like to have is the results of SmallLint >> rules and the tests >> because when I run the tests if some of them were broken I do not >> know whether I made progress or not. >> >> I think that the manifesto could be a nice place to keep such >> information. >> After we could have a simple manisfesto dropping script >> Object allSubclasses do: .... >> >> what do you think about that, I would like to have a bit more self >> documentation and software engineering >> meta data within the system. >> >> Stef >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 27, 2008

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

by Damien Cassou

On Fri, Sep 26, 2008 at 6:50 PM, Ramon Leon <ramon.leon(a)allresnet.com> wrote: > My objection, the big ball of mud called Kernel-Extensions and the liberal > use of overrides, which I think are evil. I don't know about Kernel-Extensions but if I look at http://installer.pbwiki.com/311-KernelExtensions, I can see that Â«It should be safe to install on any 3.7 or later image, as it only adds methods.Â» If this sentence is wrong, you should contact Keith. > I like using packages that do > their best to only use extensions and don't just go around the system willy > nilly monkey patching everything. I don't trust packages with overrides not > to break my system and I absolutely don't like packages that once installed > can't be uninstalled, try removing Kernel-Extensions sometime. If you only install Kernel-Extensions, it should be safe and easy to uninstall. Now, if you install packages that depend on Kernel-Extensions, it is understandable that Kernel-Extensions becomes harder to remove :-). This is even more true, if MC1.5 depends on Kernel-Extensions (but I don't know). > Now, the code may work perfectly fine, and Keith's done a lot of work, but > it's just not community friendly code. A package should have a clear > responsibility, few dependencies, not too many extensions, no overrides if > at all possible, and must install and uninstall cleanly without hosing my > system. If it doesn't meet those criteria, I don't consider it safe to even > experiment with. -- 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] Fwd: [Seaside-dev] preliminary Seaside 2.9 alpha universe

by Damien Cassou

On Fri, Sep 26, 2008 at 6:33 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > can you post the code to load > Sake > Packages > MC1.6 http://installer.pbwiki.com/Packages: Installer install: '311-KernelExtensions'. Installer squeaksource project: 'Sake'; install: 'Sake'. Installer squeaksource project: 'Packages'; install: 'Sake-Packages'. And you will get Sake and Packages. Look at the class PackagesDevU which contains the description of all packages from the dev-universe (it seems it is the new name for PackagesSqueak310U). For MC1.6, I don't know because it does not seem to be released yet. Look at http://installer.pbwiki.com/Monticello16-Beta and ask Keith and Matthew if you are really interested. -- 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] Fwd: [Seaside-dev] preliminary Seaside 2.9 alpha universe

by Damien Cassou

On Fri, Sep 26, 2008 at 6:28 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > What is Packages? compared to Sake Keith, please correct me if I'm wrong: - Sake is a domain specific language with all required tools to define make-like rules. It allows people to describe tasks (as done in the Ant/Java world) and execute these tasks when necessary (http://wiki.squeak.org/squeak/5953) - Packages uses Sake to reimplement a universe-like tool with dependencies. Then, it describes a lot of Squeak packages with their dependencies. > What is PackagesSqueak310U....? this is a class which has been generated automatically by a Sake task from the Dev Universe. This means that each change I do in the Universe system is reflected automatically in Sake just by running a task. Moreover, the fact that each package is describe in a method using only Smalltalk code makes creating new set of packages very easy. For Pharo, we could just subclass PackagesSqueak310U and override the methods we want to change. For Seaside, they could just provide yet another class... I think it's much easier than with Universes. Finally, the package descriptions are hosted on SqueakSource instead of one's particular server. -- 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] Fwd: [Seaside-dev] preliminary Seaside 2.9 alpha universe

by Damien Cassou

On Fri, Sep 26, 2008 at 6:25 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > On Sep 26, 2008, at 5:03 PM, Damien Cassou wrote: > Did you check what LFP is doing? > I would like to know that. > Because the point is not that it would not be working but what are the stuff > it brings in. http://installer.pbwiki.org/LevelPlayingField LPF is a script which installs Monticello 1.5 and Installer in your image. The aim here is to get an equivalent playing field in all images. This script allowed me to install Universes, OmniBrowser and Shout in a Croquet image in a few minutes. For Pharo, we could have a look at what the script does exactly and integrate the interesting fixes. -- 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] Regression testing results within package manifesto

by Alexandre Bergel

The idea is nice. But how will you ensure that your meta-data are well synchronized with your code? Cheers, Alexandre On 27 Sep 2008, at 09:40, StÃ©phane Ducasse wrote: > Hi guys > > For Moose we started to add package manifesto using DrDoc. > We will use the manifesto to document our package with license, > documentation, class diagram... > Now what I would really like to have is the results of SmallLint > rules and the tests > because when I run the tests if some of them were broken I do not > know whether I made progress or not. > > I think that the manifesto could be a nice place to keep such > information. > After we could have a simple manisfesto dropping script > Object allSubclasses do: .... > > what do you think about that, I would like to have a bit more self > documentation and software engineering > meta data within the system. > > Stef > > > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 27, 2008

[Pharo-project] Regression testing results within package manifesto

by StÃ©phane Ducasse

Hi guys For Moose we started to add package manifesto using DrDoc. We will use the manifesto to document our package with license, documentation, class diagram... Now what I would really like to have is the results of SmallLint rules and the tests because when I run the tests if some of them were broken I do not know whether I made progress or not. I think that the manifesto could be a nice place to keep such information. After we could have a simple manisfesto dropping script Object allSubclasses do: .... what do you think about that, I would like to have a bit more self documentation and software engineering meta data within the system. Stef

Sept. 27, 2008

Re: [Pharo-project] About Flap

by StÃ©phane Ducasse

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 >

Sept. 27, 2008

Re: [Pharo-project] A .mcz of Pinesoft's accumulated fixes applicable to Pharo

by StÃ©phane Ducasse

On Sep 26, 2008, at 10:07 PM, Simon Kirk wrote: > hi Stef. > > Hmm, strange. How are you viewing the diffs? If I browse the MCZ in > a Monticello browser I see extensions to these classes: > > BrowserCommentTextMorph > BrowserRequestor > CanvasCharacterScanner > Character > ConnectionQueue > GrafPort > MultiCanvasCharacterScanner > NaturalLanguageTranslator > Random > RemoteString > TranscriptStream > > Is this the diffs you're talking about? If so, I think they're > correct. It's possible my rough list below may have missed some > changes. I see the same but I cannot see the diff between the changes and what is in the image (for example in the merge tools I do not (changed) and the like. Stef > > > Cheers, > Simon > > On 26 Sep 2008, at 20:20, StÃ©phane Ducasse wrote: > >> Simon >> >> with which machine did you create you mcz? >> Because apparently I can see the diffs for other packages. >> >> Can somebody else check the pinesoft package I put in the pharoInbox? >> >> Stef >> >> >> >>> Hi all. >>> >>> Gary and I decided we ought to give out an MCZ of our fixes that >>> we've put together over the last two years. >>> >>> Obviously some of those we found have been pulled into Pharo >>> already, but the attached MCZ represents those that we think are >>> still relevant :) >>> >>> This is a rough list of the fixes: >>> >>> 1. Fixed flaky borwser comment text area sometime not showing. >>> >>> 2. Added getArgumentPermutation to support RefactoringEngine. >>> >>> 3. Fixes to CanvasCharacterScanner and MultiCanvasCharacterScanner >>> to correctly align the first line of text when centered/justifed >>> etc. >>> >>> 4. Added more constant names to Character class. >>> >>> 5. Modified ConnectionQueue to not accept connections when queue >>> is full. >>> >>> 6. Changed GrafPort to answer a MultiDisplayScanner when >>> appropriate (allows subclasses of MultiNewParagraph). >>> >>> 7. NaturalLanguageTranslator startup postion move to after >>> PasteUpMorph since it will show a progress bar. >>> >>> 8. Fix to Random>>nextInt: to allow large numbers which would be >>> out of range if using Floats (as mentioned recently on dev, use of >>> Floats is dodgy anyway...) >>> >>> 9. Changed TranscriptStream>>clear to use a new buffer (was just >>> reset which could leave a massive collection). >>> >>> 10. Changed RemoteString to handle concurrent processes safely. >>> This one's particularly interesting: we were load-testing our >>> Seaside app here and getting lots of syntax errors when hitting >>> the image with around the 20 concurrent processes due to source >>> file access. After this change we were hitting it with >>> approximately 500 concurrent processes, and the failure was in the >>> Java load tester (it timed out). >>> >>> Hope just submitting a .mcz is OK! :) >>> >>> Cheers, >>> Simon and Gary >>> >>> >>> >>> ****************************************************************************************************************************************** >>> This email is from Pinesoft Limited. Its contents are confidential >>> to the intended recipient(s) at the email address(es) to which it >>> has been addressed. It may not be disclosed to or used by anyone >>> other than the addressee(s), nor may it be copied in anyway. If >>> received in error, please contact the sender, then delete it from >>> your system. Although this email and attachments are believed to >>> be free of virus, or any other defect which might affect any >>> computer or IT system into which they are received and opened, it >>> is the responsibility of the recipient to ensure that they are >>> virus free and no responsibility is accepted by Pinesoft for any >>> loss or damage arising in any way from receipt or use thereof. >>> ******************************************************************************************************************************************* >>> >>> >>> Pinesoft Limited are registered in England, Registered number: >>> 2914825. Registered office: 266-268 High Street, Waltham Cross, >>> Herts, EN8 7EA >>> <Pinesoft-Fixes-Misc-gvc.24.mcz> >>> _______________________________________________ >>> 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 > > > > ****************************************************************************************************************************************** > This email is from Pinesoft Limited. Its contents are confidential > to the intended recipient(s) at the email address(es) to which it > has been addressed. It may not be disclosed to or used by anyone > other than the addressee(s), nor may it be copied in anyway. If > received in error, please contact the sender, then delete it from > your system. Although this email and attachments are believed to be > free of virus, or any other defect which might affect any computer > or IT system into which they are received and opened, it is the > responsibility of the recipient to ensure that they are virus free > and no responsibility is accepted by Pinesoft for any loss or damage > arising in any way from receipt or use thereof. > ******************************************************************************************************************************************* > > > Pinesoft Limited are registered in England, Registered number: > 2914825. Registered office: 266-268 High Street, Waltham Cross, > Herts, EN8 7EA > > _______________________________________________ > 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] About Flap

by Gary Chambers

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

Sept. 26, 2008

Re: [Pharo-project] A .mcz of Pinesoft's accumulated fixes applicable to Pharo

by Simon Kirk

hi Stef. Hmm, strange. How are you viewing the diffs? If I browse the MCZ in a Monticello browser I see extensions to these classes: BrowserCommentTextMorph BrowserRequestor CanvasCharacterScanner Character ConnectionQueue GrafPort MultiCanvasCharacterScanner NaturalLanguageTranslator Random RemoteString TranscriptStream Is this the diffs you're talking about? If so, I think they're correct. It's possible my rough list below may have missed some changes. Cheers, Simon On 26 Sep 2008, at 20:20, StÃ©phane Ducasse wrote: > Simon > > with which machine did you create you mcz? > Because apparently I can see the diffs for other packages. > > Can somebody else check the pinesoft package I put in the pharoInbox? > > Stef > > > >> Hi all. >> >> Gary and I decided we ought to give out an MCZ of our fixes that >> we've put together over the last two years. >> >> Obviously some of those we found have been pulled into Pharo >> already, but the attached MCZ represents those that we think are >> still relevant :) >> >> This is a rough list of the fixes: >> >> 1. Fixed flaky borwser comment text area sometime not showing. >> >> 2. Added getArgumentPermutation to support RefactoringEngine. >> >> 3. Fixes to CanvasCharacterScanner and MultiCanvasCharacterScanner >> to correctly align the first line of text when centered/justifed etc. >> >> 4. Added more constant names to Character class. >> >> 5. Modified ConnectionQueue to not accept connections when queue is >> full. >> >> 6. Changed GrafPort to answer a MultiDisplayScanner when >> appropriate (allows subclasses of MultiNewParagraph). >> >> 7. NaturalLanguageTranslator startup postion move to after >> PasteUpMorph since it will show a progress bar. >> >> 8. Fix to Random>>nextInt: to allow large numbers which would be >> out of range if using Floats (as mentioned recently on dev, use of >> Floats is dodgy anyway...) >> >> 9. Changed TranscriptStream>>clear to use a new buffer (was just >> reset which could leave a massive collection). >> >> 10. Changed RemoteString to handle concurrent processes safely. >> This one's particularly interesting: we were load-testing our >> Seaside app here and getting lots of syntax errors when hitting the >> image with around the 20 concurrent processes due to source file >> access. After this change we were hitting it with approximately 500 >> concurrent processes, and the failure was in the Java load tester >> (it timed out). >> >> Hope just submitting a .mcz is OK! :) >> >> Cheers, >> Simon and Gary >> >> >> >> ****************************************************************************************************************************************** >> This email is from Pinesoft Limited. Its contents are confidential >> to the intended recipient(s) at the email address(es) to which it >> has been addressed. It may not be disclosed to or used by anyone >> other than the addressee(s), nor may it be copied in anyway. If >> received in error, please contact the sender, then delete it from >> your system. Although this email and attachments are believed to be >> free of virus, or any other defect which might affect any computer >> or IT system into which they are received and opened, it is the >> responsibility of the recipient to ensure that they are virus free >> and no responsibility is accepted by Pinesoft for any loss or >> damage arising in any way from receipt or use thereof. >> ******************************************************************************************************************************************* >> >> >> Pinesoft Limited are registered in England, Registered number: >> 2914825. Registered office: 266-268 High Street, Waltham Cross, >> Herts, EN8 7EA >> <Pinesoft-Fixes-Misc-gvc.24.mcz> >> _______________________________________________ >> 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 ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Sept. 26, 2008

Re: [Pharo-project] A .mcz of Pinesoft's accumulated fixes applicable to Pharo

by StÃ©phane Ducasse

I'm trying to understand the problem I have the hypothesis that this is linked with the class extension or the fact that the package does not exist in the image. Can you also check that you can see diff when the changes is in an class extension? Because this is strange with some packages I can see the diff and with the pinesoft-fixes-misc I cannot. Stef On Sep 26, 2008, at 9:20 PM, StÃ©phane Ducasse wrote: > Simon > > with which machine did you create you mcz? > Because apparently I can see the diffs for other packages. > > Can somebody else check the pinesoft package I put in the pharoInbox? > > Stef > > > >> Hi all. >> >> Gary and I decided we ought to give out an MCZ of our fixes that >> we've put together over the last two years. >> >> Obviously some of those we found have been pulled into Pharo >> already, but the attached MCZ represents those that we think are >> still relevant :) >> >> This is a rough list of the fixes: >> >> 1. Fixed flaky borwser comment text area sometime not showing. >> >> 2. Added getArgumentPermutation to support RefactoringEngine. >> >> 3. Fixes to CanvasCharacterScanner and MultiCanvasCharacterScanner >> to correctly align the first line of text when centered/justifed etc. >> >> 4. Added more constant names to Character class. >> >> 5. Modified ConnectionQueue to not accept connections when queue is >> full. >> >> 6. Changed GrafPort to answer a MultiDisplayScanner when >> appropriate (allows subclasses of MultiNewParagraph). >> >> 7. NaturalLanguageTranslator startup postion move to after >> PasteUpMorph since it will show a progress bar. >> >> 8. Fix to Random>>nextInt: to allow large numbers which would be >> out of range if using Floats (as mentioned recently on dev, use of >> Floats is dodgy anyway...) >> >> 9. Changed TranscriptStream>>clear to use a new buffer (was just >> reset which could leave a massive collection). >> >> 10. Changed RemoteString to handle concurrent processes safely. >> This one's particularly interesting: we were load-testing our >> Seaside app here and getting lots of syntax errors when hitting the >> image with around the 20 concurrent processes due to source file >> access. After this change we were hitting it with approximately 500 >> concurrent processes, and the failure was in the Java load tester >> (it timed out). >> >> Hope just submitting a .mcz is OK! :) >> >> Cheers, >> Simon and Gary >> >> >> >> ****************************************************************************************************************************************** >> This email is from Pinesoft Limited. Its contents are confidential >> to the intended recipient(s) at the email address(es) to which it >> has been addressed. It may not be disclosed to or used by anyone >> other than the addressee(s), nor may it be copied in anyway. If >> received in error, please contact the sender, then delete it from >> your system. Although this email and attachments are believed to be >> free of virus, or any other defect which might affect any computer >> or IT system into which they are received and opened, it is the >> responsibility of the recipient to ensure that they are virus free >> and no responsibility is accepted by Pinesoft for any loss or >> damage arising in any way from receipt or use thereof. >> ******************************************************************************************************************************************* >> >> >> Pinesoft Limited are registered in England, Registered number: >> 2914825. Registered office: 266-268 High Street, Waltham Cross, >> Herts, EN8 7EA >> <Pinesoft-Fixes-Misc-gvc.24.mcz> >> _______________________________________________ >> 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. 26, 2008

Re: [Pharo-project] A .mcz of Pinesoft's accumulated fixes applicable to Pharo

by StÃ©phane Ducasse

Simon with which machine did you create you mcz? Because apparently I can see the diffs for other packages. Can somebody else check the pinesoft package I put in the pharoInbox? Stef > Hi all. > > Gary and I decided we ought to give out an MCZ of our fixes that > we've put together over the last two years. > > Obviously some of those we found have been pulled into Pharo > already, but the attached MCZ represents those that we think are > still relevant :) > > This is a rough list of the fixes: > > 1. Fixed flaky borwser comment text area sometime not showing. > > 2. Added getArgumentPermutation to support RefactoringEngine. > > 3. Fixes to CanvasCharacterScanner and MultiCanvasCharacterScanner > to correctly align the first line of text when centered/justifed etc. > > 4. Added more constant names to Character class. > > 5. Modified ConnectionQueue to not accept connections when queue is > full. > > 6. Changed GrafPort to answer a MultiDisplayScanner when appropriate > (allows subclasses of MultiNewParagraph). > > 7. NaturalLanguageTranslator startup postion move to after > PasteUpMorph since it will show a progress bar. > > 8. Fix to Random>>nextInt: to allow large numbers which would be out > of range if using Floats (as mentioned recently on dev, use of > Floats is dodgy anyway...) > > 9. Changed TranscriptStream>>clear to use a new buffer (was just > reset which could leave a massive collection). > > 10. Changed RemoteString to handle concurrent processes safely. This > one's particularly interesting: we were load-testing our Seaside app > here and getting lots of syntax errors when hitting the image with > around the 20 concurrent processes due to source file access. After > this change we were hitting it with approximately 500 concurrent > processes, and the failure was in the Java load tester (it timed out). > > Hope just submitting a .mcz is OK! :) > > Cheers, > Simon and Gary > > > > ****************************************************************************************************************************************** > This email is from Pinesoft Limited. Its contents are confidential > to the intended recipient(s) at the email address(es) to which it > has been addressed. It may not be disclosed to or used by anyone > other than the addressee(s), nor may it be copied in anyway. If > received in error, please contact the sender, then delete it from > your system. Although this email and attachments are believed to be > free of virus, or any other defect which might affect any computer > or IT system into which they are received and opened, it is the > responsibility of the recipient to ensure that they are virus free > and no responsibility is accepted by Pinesoft for any loss or damage > arising in any way from receipt or use thereof. > ******************************************************************************************************************************************* > > > Pinesoft Limited are registered in England, Registered number: > 2914825. Registered office: 266-268 High Street, Waltham Cross, > Herts, EN8 7EA > <Pinesoft-Fixes-Misc-gvc.24.mcz> > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 26, 2008

[Pharo-project] who is YM

by StÃ©phane Ducasse

because there is a package Network YM 44 Please please avoid to use initials. Stef

Sept. 26, 2008

[Pharo-project] Bug? I cannot see the diff anymore doing merge or browse

by StÃ©phane Ducasse

Hi I'm tracking a problem I have and which is quite annoying I cannot see the diff when I do a merge or browse with MC. I'm with 10074 and I woudl like to know if you have the same behavior. Stef

Sept. 26, 2008

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

by StÃ©phane Ducasse

>>> > My objection, the big ball of mud called Kernel-Extensions and the > liberal > use of overrides, which I think are evil. I like using packages > that do > their best to only use extensions and don't just go around the > system willy > nilly monkey patching everything. I don't trust packages with > overrides not > to break my system and I absolutely don't like packages that once > installed > can't be uninstalled, try removing Kernel-Extensions sometime. Thanks! Seriously. This is the kind of feedback I like. Now we know what should be done. Cleaning, reviewing, integrating... > Now, the code may work perfectly fine, and Keith's done a lot of > work, but > it's just not community friendly code. A package should have a clear > responsibility, few dependencies, not too many extensions, no > overrides if > at all possible, and must install and uninstall cleanly without > hosing my > system. 100% agree. This is why I'm saying that we want to integrate extensions or reject them. > If it doesn't meet those criteria, I don't consider it safe to even > experiment with.

Sept. 26, 2008

Re: [Pharo-project] A .mcz of Pinesoft's accumulated fixes applicable to Pharo

by StÃ©phane Ducasse

This is GREAT! you checked with Pharo, so I will check to see and publish that. Stef On Sep 26, 2008, at 6:36 PM, Simon Kirk wrote: > Hi all. > > Gary and I decided we ought to give out an MCZ of our fixes that > we've put together over the last two years. > > Obviously some of those we found have been pulled into Pharo > already, but the attached MCZ represents those that we think are > still relevant :) > > This is a rough list of the fixes: > > 1. Fixed flaky borwser comment text area sometime not showing. > > 2. Added getArgumentPermutation to support RefactoringEngine. > > 3. Fixes to CanvasCharacterScanner and MultiCanvasCharacterScanner > to correctly align the first line of text when centered/justifed etc. > > 4. Added more constant names to Character class. > > 5. Modified ConnectionQueue to not accept connections when queue is > full. > > 6. Changed GrafPort to answer a MultiDisplayScanner when appropriate > (allows subclasses of MultiNewParagraph). > > 7. NaturalLanguageTranslator startup postion move to after > PasteUpMorph since it will show a progress bar. > > 8. Fix to Random>>nextInt: to allow large numbers which would be out > of range if using Floats (as mentioned recently on dev, use of > Floats is dodgy anyway...) > > 9. Changed TranscriptStream>>clear to use a new buffer (was just > reset which could leave a massive collection). > > 10. Changed RemoteString to handle concurrent processes safely. This > one's particularly interesting: we were load-testing our Seaside app > here and getting lots of syntax errors when hitting the image with > around the 20 concurrent processes due to source file access. After > this change we were hitting it with approximately 500 concurrent > processes, and the failure was in the Java load tester (it timed out). > > Hope just submitting a .mcz is OK! :) > > Cheers, > Simon and Gary > > > > ****************************************************************************************************************************************** > This email is from Pinesoft Limited. Its contents are confidential > to the intended recipient(s) at the email address(es) to which it > has been addressed. It may not be disclosed to or used by anyone > other than the addressee(s), nor may it be copied in anyway. If > received in error, please contact the sender, then delete it from > your system. Although this email and attachments are believed to be > free of virus, or any other defect which might affect any computer > or IT system into which they are received and opened, it is the > responsibility of the recipient to ensure that they are virus free > and no responsibility is accepted by Pinesoft for any loss or damage > arising in any way from receipt or use thereof. > ******************************************************************************************************************************************* > > > Pinesoft Limited are registered in England, Registered number: > 2914825. Registered office: 266-268 High Street, Waltham Cross, > Herts, EN8 7EA > <Pinesoft-Fixes-Misc-gvc.24.mcz> > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 26, 2008

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

by Ramon Leon

> On Fri, Sep 26, 2008 at 8:38 AM, Lukas Renggli > <renggli(a)gmail.com> wrote: > > One problem I see with Sake/Packages is that these tools depend on a > > lot of other packages, that I don't necessarily want to > have loaded in > > my images: Logging, Rio, Installer, Sake, Packages ... > > > > I guess one could argue the same with XML and Universe. > > > This is the only argument against Sake/Packages I guess. Keith, could > you please give us more information on that? > - what mcz do we need to load exactly to have universes features using > Sake/Packages? > - is LPF necessary? My objection, the big ball of mud called Kernel-Extensions and the liberal use of overrides, which I think are evil. I like using packages that do their best to only use extensions and don't just go around the system willy nilly monkey patching everything. I don't trust packages with overrides not to break my system and I absolutely don't like packages that once installed can't be uninstalled, try removing Kernel-Extensions sometime. Now, the code may work perfectly fine, and Keith's done a lot of work, but it's just not community friendly code. A package should have a clear responsibility, few dependencies, not too many extensions, no overrides if at all possible, and must install and uninstall cleanly without hosing my system. If it doesn't meet those criteria, I don't consider it safe to even experiment with. Ramon Leon http://onsmalltalk.com

Sept. 26, 2008

[Pharo-project] A .mcz of Pinesoft's accumulated fixes applicable to Pharo

by Simon Kirk

Hi all. Gary and I decided we ought to give out an MCZ of our fixes that we've put together over the last two years. Obviously some of those we found have been pulled into Pharo already, but the attached MCZ represents those that we think are still relevant :) This is a rough list of the fixes: 1. Fixed flaky borwser comment text area sometime not showing. 2. Added getArgumentPermutation to support RefactoringEngine. 3. Fixes to CanvasCharacterScanner and MultiCanvasCharacterScanner to correctly align the first line of text when centered/justifed etc. 4. Added more constant names to Character class. 5. Modified ConnectionQueue to not accept connections when queue is full. 6. Changed GrafPort to answer a MultiDisplayScanner when appropriate (allows subclasses of MultiNewParagraph). 7. NaturalLanguageTranslator startup postion move to after PasteUpMorph since it will show a progress bar. 8. Fix to Random>>nextInt: to allow large numbers which would be out of range if using Floats (as mentioned recently on dev, use of Floats is dodgy anyway...) 9. Changed TranscriptStream>>clear to use a new buffer (was just reset which could leave a massive collection). 10. Changed RemoteString to handle concurrent processes safely. This one's particularly interesting: we were load-testing our Seaside app here and getting lots of syntax errors when hitting the image with around the 20 concurrent processes due to source file access. After this change we were hitting it with approximately 500 concurrent processes, and the failure was in the Java load tester (it timed out). Hope just submitting a .mcz is OK! :) Cheers, Simon and Gary ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Sept. 26, 2008

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

by StÃ©phane Ducasse

Damien can you post the code to load Sake Packages MC1.6 For me I'm always lost. Stef

Sept. 26, 2008

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

by StÃ©phane Ducasse

>> What is Packages? compared to Sake I tried to understand some of the emails keith sent a while back to squeak-dev but I could not get it. Setf > Sake/Packages is just about that: a declarative way to specify > packages. Nothing more. And there is a script which converts a > Universe to a set of tasks. It works very well and Keith uses it often > to update Packages from Universes. > > An example for PierBlog: What is PackagesSqueak310U....? > > > PackagesSqueak310U>>PierBlog > self name: 'Pier-Blog'. > self version: '1.0.16.73'. > > info category: 'Web Development'. > info description: 'Pier blog plugin.'. > info maintainer: 'Lukas Renggli <renggli(a)gmail.com>'. > info homepage: 'http://www.lukas-renggli.ch/smalltalk/pier'. > info squeakMapID: ''. > info url: 'http://mc.lukas-renggli.ch/pier/Pier-Blog-lr.73.mcz'. > self provides: #(). > > self dependsOn: #('Pier-Seaside' 'RSRSS2'). > > self load: [ > Installer installUrl:'http://mc.lukas-renggli.ch/pier/Pier-Blog-lr.73.mcz' > . > ]. > > self unload: [ > Installer mc unload: 'Pier-Blog'. > ]. > > -- > 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) > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 26, 2008

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

by StÃ©phane Ducasse

On Sep 26, 2008, at 5:03 PM, Damien Cassou wrote: > 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. Still this is the same :). It is a communication problem and what people see from you. > > >> 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. Did you check what LFP is doing? I would like to know that. Because the point is not that it would not be working but what are the stuff it brings in. >> - 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. We decided to refactor it :) > > > >> - 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. Come on I said that I'm writing a chapter. I can't do more. >> - 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) > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 26, 2008

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

by Damien Cassou

On Fri, Sep 26, 2008 at 2:59 PM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: > I think you answered already: no GUI, no integration with tools. I see that > as the only obstacle to a broader acceptance of Keith's work. For a long time, debian linux systems did not have any GUI to manage their packages. Still, their packaging system was used by thousands of people from the command line. Sake/packages makes installing packages very easy from the command line. No doubt that if more people use it, a gui will appear. What do you mean by no integration with tools and how does it differ from universes? -- 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. 26, 2008

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

by Damien Cassou

On Fri, Sep 26, 2008 at 8:38 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > One problem I see with Sake/Packages is that these tools depend on a > lot of other packages, that I don't necessarily want to have loaded in > my images: Logging, Rio, Installer, Sake, Packages ... > > I guess one could argue the same with XML and Universe. This is the only argument against Sake/Packages I guess. Keith, could you please give us more information on that? - what mcz do we need to load exactly to have universes features using Sake/Packages? - is LPF necessary? >> You can define a package with non-specific versions, i.e. to load the >> latest seaside when keeping up with the bleeding edge. > > This sounds very suspicious. That can't reliably work with standard > Monticello, all projects I know use multiple branches at some point. Keith does not mean you *must* use it :-). This is a feature that can be useful for some small packages. > I agree that Universes is not the ultimate solution, but at least it > seems to work reasonably well. I like the declarative way to > specifying package dependencies. Sake/Packages is just about that: a declarative way to specify packages. Nothing more. And there is a script which converts a Universe to a set of tasks. It works very well and Keith uses it often to update Packages from Universes. An example for PierBlog: PackagesSqueak310U>>PierBlog self name: 'Pier-Blog'. self version: '1.0.16.73'. info category: 'Web Development'. info description: 'Pier blog plugin.'. info maintainer: 'Lukas Renggli <renggli(a)gmail.com>'. info homepage: 'http://www.lukas-renggli.ch/smalltalk/pier'. info squeakMapID: ''. info url: 'http://mc.lukas-renggli.ch/pier/Pier-Blog-lr.73.mcz'. self provides: #(). self dependsOn: #('Pier-Seaside' 'RSRSS2'). self load: [ Installer installUrl:'http://mc.lukas-renggli.ch/pier/Pier-Blog-lr.73.mcz'. ]. self unload: [ Installer mc unload: 'Pier-Blog'. ]. -- 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. 26, 2008

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

by Damien Cassou

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. 26, 2008

[Pharo-project] Interesting news

by Bill Schwab

Hello all, Have a look at: http://www.object-arts.com/content/news/excitingNews.html Object Arts and Lesser Software are collaborating on a new version of Dolphin. They are still sticking to the Windows-only angle, which I find disappointing. However, even if they hold to that, we are better off keeping and enhancing what I consider to be the best development environment I have ever used. 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. 26, 2008

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

by Janko MivÅ¡ek

Damien Cassou wrote: > On Fri, Sep 26, 2008 at 12:19 AM, Keith Hodges <keith_hodges(a)yahoo.co.uk> wrote: >> Do have a look at Sake/Packages equivalent to universes. > > I agree with Keith. Sake/Packages have all the features of universes > without a GUI but provide an easy way to define your own universe as > you did with Seaside and as you want to do with Pharo (just need to > create a new subclass IIUC). I don't understand why people don't want > to look at this solution (it's not about you Seaside developers, it's > about the whole community. Some told me they would stop using my > dev-images if I use Sake/Packages without giving any good reason). I > hope Keith won't give up. I think you answered already: no GUI, no integration with tools. I see that as the only obstacle to a broader acceptance of Keith's work. JAnko -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

Sept. 26, 2008

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

by Lukas Renggli

> about the whole community. Some told me they would stop using my > dev-images if I use Sake/Packages without giving any good reason). I > hope Keith won't give up. One problem I see with Sake/Packages is that these tools depend on a lot of other packages, that I don't necessarily want to have loaded in my images: Logging, Rio, Installer, Sake, Packages ... I guess one could argue the same with XML and Universe. > You can define a package with non-specific versions, i.e. to load the > latest seaside when keeping up with the bleeding edge. This sounds very suspicious. That can't reliably work with standard Monticello, all projects I know use multiple branches at some point. I agree that Universes is not the ultimate solution, but at least it seems to work reasonably well. I like the declarative way to specifying package dependencies. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 26, 2008

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

by StÃ©phane Ducasse

Hi Damien I can give you an explanation but keith will not like it. Note that I like the ideas that he is pushing and that I started to write a chapter for the next book on installer. - Keith idea that everybody can build its own distribution is not something that everybody like - For example I would like to have a real look at MC1.6 but the message around it is blurry I tried LFP and it broke on me. - I like installer but when I look at the code I would like to refactor it. - 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). - unknown is strnage :) - 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 Stef On Sep 26, 2008, at 8:10 AM, Damien Cassou wrote: > On Fri, Sep 26, 2008 at 12:19 AM, Keith Hodges <keith_hodges(a)yahoo.co.uk > > wrote: >> Do have a look at Sake/Packages equivalent to universes. > > I agree with Keith. Sake/Packages have all the features of universes > without a GUI but provide an easy way to define your own universe as > you did with Seaside and as you want to do with Pharo (just need to > create a new subclass IIUC). I don't understand why people don't want > to look at this solution (it's not about you Seaside developers, it's > about the whole community. Some told me they would stop using my > dev-images if I use Sake/Packages without giving any good reason). I > hope Keith won't give up. > > Bye > > -- > 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) > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 26, 2008

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

by Stefan Schmiedl

On Fri, 26 Sep 2008 08:10:53 +0200 "Damien Cassou" <damien.cassou(a)gmail.com> wrote: > On Fri, Sep 26, 2008 at 12:19 AM, Keith Hodges <keith_hodges(a)yahoo.co.uk> wrote: > > Do have a look at Sake/Packages equivalent to universes. > > Some told me they would stop using my > dev-images if I use Sake/Packages without giving any good reason). I wonder how much they are paying you for the right to make such statements... If they don't cross your palm with enough silver, he who does work decides on the tools. Just making smalltalk, s.

Sept. 26, 2008

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

by Damien Cassou

On Fri, Sep 26, 2008 at 12:19 AM, Keith Hodges <keith_hodges(a)yahoo.co.uk> wrote: > Do have a look at Sake/Packages equivalent to universes. I agree with Keith. Sake/Packages have all the features of universes without a GUI but provide an easy way to define your own universe as you did with Seaside and as you want to do with Pharo (just need to create a new subclass IIUC). I don't understand why people don't want to look at this solution (it's not about you Seaside developers, it's about the whole community. Some told me they would stop using my dev-images if I use Sake/Packages without giving any good reason). I hope Keith won't give up. Bye -- 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. 26, 2008

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

by StÃ©phane Ducasse

Ok I understand now and I agree. >>> An installer script or an mcm is not an option because that would >>> always load one fixed configuration. >> >> But this is not what you want when you do not use a Universe? > > Not not? I am confused ;-) > >>>> but this is not what we want when we do not use a universe. >>> >>> To be able to properly load Seaside a system that can handle >>> dependencies is a requirement. >> >> so I'm confused I thought that exactly mcm allow to specify exact >> version. > > mcm is a fixed, ordered set of exact package versions. If we wanted to > provide mcm files, we needed to create one for every combination of > swazoo/kom (2), tests yes/no (2), development tools yes/no (2), > scriptaculous yes/no (2), comet yes/no (2), rsrss yes/no (2), ... > Imagine, if we wanted to add Magritte and Pier to that. We would soon > end up with an infinite number of possible combinations, each encoded > in a different mcm file. > >> But Universe do not have the granularity for following all the small >> changes. I thought that for the people developing seaside daily >> you wanted either the latest or been able to go back to exactly one >> version >> of a set of components and there the exact version number is a must >> I do not see the numbering in dependency in Universe. > > Exactly, but Seaside users usually don't follow small changes. We > expect developers to know about the dependencies and be able to load > the packages manually. Furthermore, as soon as a version of the > packages is loaded, doing small updates through Monticello is usually > no big deal. > > There will be a universe for every release (including alpha and beta > releases). Seaside users have the possibility to update from one > release to the next. > >> So tell me because I do not understand. >> I also thought that Mcm was offering a fixed versions and could be >> used a >> fixed configmap >> We could extend it to support **load latest for this component** > > We tried to use mcm in the beginning. Unfortunately not even the > developers want a fixed set of packages, but have different focuses > and therefore different packages loaded. For example, I focus on > JavaScript, while Philippe on different encodings and server adapters, > ... > > So in Universe each package has a list of dependencies to other fixed > versions of packages (not strictly, but we use it like this). This > allows users to select the parts of Seaside they need (for example kom > server, no tests, development tools, scriptaculous support and pier). > And boom, Universe automatically builds an ordered list of package > versions to load. In this example the list would include the correct > versions of Magritte-Core and Magritte-Seaside, even if this was never > explicitly declared. > > Universes is easier for us, because we don't need to prepare all the > possible configurations a user wants. Users just select themselves > what they want and the system calculates the prerequisites. > > Now with MC2, the story is again completely different ... > > Cheers, > Lukas > > -- > 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 >

Sept. 26, 2008

Re: [Pharo-project] Move to package from sender and implementors list

by Damien Cassou

On Thu, Sep 25, 2008 at 1:29 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > it would be great to have the senders and implementors tools > offering move to package in their menus. If you were using pharo-dev, the senders and implementors tools would be the ones of OB and you would not have these problems... Now that pharo-dev only contains a very small set of packages, I don't understand why you don't use it. -- 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. 26, 2008

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

by Lukas Renggli

> > An installer script or an mcm is not an option because that would > > always load one fixed configuration. > > But this is not what you want when you do not use a Universe? Not not? I am confused ;-) > > > but this is not what we want when we do not use a universe. > > > > To be able to properly load Seaside a system that can handle > > dependencies is a requirement. > > so I'm confused I thought that exactly mcm allow to specify exact version. mcm is a fixed, ordered set of exact package versions. If we wanted to provide mcm files, we needed to create one for every combination of swazoo/kom (2), tests yes/no (2), development tools yes/no (2), scriptaculous yes/no (2), comet yes/no (2), rsrss yes/no (2), ... Imagine, if we wanted to add Magritte and Pier to that. We would soon end up with an infinite number of possible combinations, each encoded in a different mcm file. > But Universe do not have the granularity for following all the small > changes. I thought that for the people developing seaside daily > you wanted either the latest or been able to go back to exactly one version > of a set of components and there the exact version number is a must > I do not see the numbering in dependency in Universe. Exactly, but Seaside users usually don't follow small changes. We expect developers to know about the dependencies and be able to load the packages manually. Furthermore, as soon as a version of the packages is loaded, doing small updates through Monticello is usually no big deal. There will be a universe for every release (including alpha and beta releases). Seaside users have the possibility to update from one release to the next. > So tell me because I do not understand. > I also thought that Mcm was offering a fixed versions and could be used a > fixed configmap > We could extend it to support **load latest for this component** We tried to use mcm in the beginning. Unfortunately not even the developers want a fixed set of packages, but have different focuses and therefore different packages loaded. For example, I focus on JavaScript, while Philippe on different encodings and server adapters, ... So in Universe each package has a list of dependencies to other fixed versions of packages (not strictly, but we use it like this). This allows users to select the parts of Seaside they need (for example kom server, no tests, development tools, scriptaculous support and pier). And boom, Universe automatically builds an ordered list of package versions to load. In this example the list would include the correct versions of Magritte-Core and Magritte-Seaside, even if this was never explicitly declared. Universes is easier for us, because we don't need to prepare all the possible configurations a user wants. Users just select themselves what they want and the system calculates the prerequisites. Now with MC2, the story is again completely different ... Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 25, 2008

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

by Keith Hodges

> > For me Universe is good when a complex program is ok for public > consumption not incremental > daily changes. > Do have a look at Sake/Packages equivalent to universes. You can define a package with non-specific versions, i.e. to load the latest seaside when keeping up with the bleeding edge. Packages beta load: 'Seaside'. Or you can define a specific definition based upon specific versions. Packages current load: 'Seaside'. Keith > So tell me because I do not understand. > I also thought that Mcm was offering a fixed versions and could be > used a fixed configmap > We could extend it to support **load latest for this component** > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 25, 2008

Re: [Pharo-project] Do you still need a Linux VM with FreeType?

by bryce＠kampjes.demon.co.uk

Igor Stasenko writes: > Hi Bryce, i'm already added platform source for linux. You can see it on > https://gforge.inria.fr/frs/?group_id=1299 > page. > I would appreciate if you help how to add dependency in linker (to > link with -lfreetype) , if plugin is compiled in. > Otherwise it require to change a makefile to complete a build. > Btw, same for B3DAcceleratorPlugin - it needs adding -lgl If you're trying to do Linux builds frequently you might want to look at VirtualBox or other virtualisation software. I'm using VirtualBox here to run Windows from Linux, according to the website, it should run Linux from Windows as well. It's free. Rebooting between OSes gets tedious fast. Bryce

Sept. 25, 2008

[Pharo-project] On Icons

by Torsten Bergmann

Matthew suggested >Perhaps OB could use composable icons Eclipse uses a similar concept, see http://www.eclipse.org/articles/Article-Decorators/decorators.html Typical icon sizes are 16x16 and 32x32 (at least on Win32 and in most icon collections on the web). The ones in OB currently look smaller and may be too small for decorators... Bye Torsten -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

Sept. 25, 2008

Re: [Pharo-project] Do you still need a Linux VM with FreeType?

by bryce＠kampjes.demon.co.uk

Marcus Denker writes: > > On 24.09.2008, at 23:16, <bryce(a)kampjes.demon.co.uk> <bryce(a)kampjes.demon.co.uk > > wrote: > > > > > I've stabilised the changes I was working on so now's a reasonable > > time for me to look at this if it's still required. Is it? > > > > > > For now, I just used the vm from the seaside package and copied all th > dll's in > from the freetype package. This seems to work... > > The recompiling gets really more important as soon as we go for > example for > Eliot's closure implementation... that I would want to have in as soon > as possible. OK, then my plan is this: 1) Build a VM dev environment with the latest mainstream source 2) Merge in Exupery 3) Add TrueType support 4) Automate the image build using Universes. (Probably starting with one of Damien's pharo-dev images) 4.5) Look at the makefiles (Igor's post) 5) Document the C setup 6) Review where I'm at 7) Review Eliot's closure impementation 8) Merge them assuming no problems My aim here is to make sure that the image used to build the VM is automatically buildable. I'll leave automating the C sources for later. This is where Exupery VM building currently is. Eliot's changes shouldn't effect build automation as I'll merge them into the Exupery VMMaker if they're acceptable. Exupery's VMMaker source is on SqueakSource Bryce P.S. Marcus, if you don't have the bitblit extensions then you'll not be getting sub-pixel aliasing. So with a re-built VM the fonts should look slightly nicer.

Sept. 25, 2008

[Pharo-project] [ANN] some cleans

by StÃ©phane Ducasse

I remove isUniClass: and clean the inspector following gary's clean. plus some leftOver related to uniclass. Stef

Sept. 25, 2008

Re: [Pharo-project] On Icons

by Matthew Fulmer

On Tue, Sep 23, 2008 at 10:54:08AM +0200, Lukas Renggli wrote: > On 9/23/08, Stï¿½phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > Lukas another example: > > Here I was browsing some methods and suddenly there is cross: I said oops > > this method is an extension. > > And I did not have to click on *packageinfo-base because in the flow of my > > reading I was not looking > > for extensions per se. > > I agree, that's nice to see. However now the plus hides information > that is totally orthogonal to package extensions (inheritance). Perhaps OB could use composable icons, like MS Windows does with shortcuts: A little arrow icon representing "shortcut" superimposed on a big icon representing "content type" Many IDE's use an icon for every method or class. I think I don't like that, though. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

Sept. 25, 2008

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

by StÃ©phane Ducasse

> An installer script or an mcm is not an option because that would > always load one fixed configuration. But this is not what you want when you do not use a Universe? >> but this is not what we want when we do not use a universe. > > To be able to properly load Seaside a system that can handle > dependencies is a requirement. so I'm confused I thought that exactly mcm allow to specify exact version. > To our knowledge, Universe is the only > system in Squeak/Pharo that can handle this task. > > If you do not like Universes you can always load the Monticello > packages manually following this graph: > <http://www.lukas-renggli.ch/dropbox/seaside-2.9/seaside.png>. Good > luck ;-) But Universe do not have the granularity for following all the small changes. I thought that for the people developing seaside daily you wanted either the latest or been able to go back to exactly one version of a set of components and there the exact version number is a must I do not see the numbering in dependency in Universe. For me Universe is good when a complex program is ok for public consumption not incremental daily changes. So tell me because I do not understand. I also thought that Mcm was offering a fixed versions and could be used a fixed configmap We could extend it to support **load latest for this component** Stef

Sept. 25, 2008

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

by Lukas Renggli

> but this is not what we want when we do not use a universe. To be able to properly load Seaside a system that can handle dependencies is a requirement. To our knowledge, Universe is the only system in Squeak/Pharo that can handle this task. If you do not like Universes you can always load the Monticello packages manually following this graph: <http://www.lukas-renggli.ch/dropbox/seaside-2.9/seaside.png>. Good luck ;-) Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 25, 2008

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

by Norbert Hartl

On Thu, 2008-09-25 at 15:51 +0200, Lukas Renggli wrote: > On 9/25/08, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > why can we have an installer script or mcm ? > > We should be able to have one click install too. > > It will eventually become simpler. > > An installer script or an mcm is not an option because that would > always load one fixed configuration. Only with Universe we have the > possibility to load the set of packages the developer needs, and pull > in a minimal set of required dependencies automatically. > What will you do with current channels (beta,...) with seaside. Are you preparing an universe for each. The most important thing that is lacking in Universe is to assign a package version to a certain channel. This leads to something I've seen some times: A package the is called Seaside-beta-anything which is broken as soon as this beta becomes stable. For me universes capture the basic idea of an package distribution tree but it lacks essential stuff. Without that I don't know if it is worth it. Having a maintained universe only for seaside is a good thing. But you have to include KomHttpServer as well which will also be in the "official" universe. And AFAIK you can't merge universes, right? We could convert your universe into a Monticello configuration. It may sound stupid as first but I don't think it is hard to do and we wouldn't need to have universes and XML parser in the image. my 2 cents, Norbert

Sept. 25, 2008

Re: [Pharo-project] Removing class category

by StÃ©phane Ducasse

But the problem that we face is that we have dependency that could be already factored out. I will start to remove etoy and we will see Stef On Sep 25, 2008, at 4:08 PM, Marcus Denker wrote: > > On 25.09.2008, at 15:40, Alexandre Bergel wrote: > >> Hi! >> >> I just created a package MorphicBalloon that contains the 3 classes >> defined in Morphic-Balloon. >> Here is the comment: >> -=-=-=-=-=-=-=-=-=-=-=-= >> This package contains the 3 classes that define Balloon >> (BalloonCanvas, BalloonRectangleMorph, MatrixTranformMorph). >> These three classes, are only referenced by classes defined in the >> class category Morphic-Support. >> I am not sure whether this is a good change, but it is a first step >> to remove class category >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> This is an example that should raise the question about where we >> want to go. >> I feel that having class category as sub-monticellopackage is a >> bad thing. >> We should get rid of class category. >> > > I don't know if that is a good idea... Morphic is such a blob of > unmaintainability, we should not add more confusion by > packaging it into many tiny packages. > > I would first clean up. > > 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. 25, 2008

Re: [Pharo-project] Removing class category

by Marcus Denker

On 25.09.2008, at 15:40, Alexandre Bergel wrote: > Hi! > > I just created a package MorphicBalloon that contains the 3 classes > defined in Morphic-Balloon. > Here is the comment: > -=-=-=-=-=-=-=-=-=-=-=-= > This package contains the 3 classes that define Balloon > (BalloonCanvas, BalloonRectangleMorph, MatrixTranformMorph). > These three classes, are only referenced by classes defined in the > class category Morphic-Support. > I am not sure whether this is a good change, but it is a first step > to remove class category > -=-=-=-=-=-=-=-=-=-=-=-= > > This is an example that should raise the question about where we > want to go. > I feel that having class category as sub-monticellopackage is a bad > thing. > We should get rid of class category. > I don't know if that is a good idea... Morphic is such a blob of unmaintainability, we should not add more confusion by packaging it into many tiny packages. I would first clean up. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 25, 2008

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

by StÃ©phane Ducasse

On Sep 25, 2008, at 3:51 PM, Lukas Renggli wrote: > On 9/25/08, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> why can we have an installer script or mcm ? >> We should be able to have one click install too. > > It will eventually become simpler. > > An installer script or an mcm is not an option because that would > always load one fixed configuration. but this is not what we want when we do not use a universe. > Only with Universe we have the > possibility to load the set of packages the developer needs, and pull > in a minimal set of required dependencies automatically. > > Cheers, > Lukas > > -- > 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 >

Sept. 25, 2008

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

by Lukas Renggli

On 9/25/08, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > why can we have an installer script or mcm ? > We should be able to have one click install too. It will eventually become simpler. An installer script or an mcm is not an option because that would always load one fixed configuration. Only with Universe we have the possibility to load the set of packages the developer needs, and pull in a minimal set of required dependencies automatically. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 25, 2008

[Pharo-project] Removing class category

by Alexandre Bergel

Hi! I just created a package MorphicBalloon that contains the 3 classes defined in Morphic-Balloon. Here is the comment: -=-=-=-=-=-=-=-=-=-=-=-= This package contains the 3 classes that define Balloon (BalloonCanvas, BalloonRectangleMorph, MatrixTranformMorph). These three classes, are only referenced by classes defined in the class category Morphic-Support. I am not sure whether this is a good change, but it is a first step to remove class category -=-=-=-=-=-=-=-=-=-=-=-= This is an example that should raise the question about where we want to go. I feel that having class category as sub-monticellopackage is a bad thing. We should get rid of class category. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 25, 2008

Re: [Pharo-project] Move to package from sender and implementors list

by David RÃ¶thlisberger

> I added an issue on this. > Probably what I did with the 'move package' in OB can be adapted. I will > work on this. It's actually already there in the senders and implementors browser of OB. The command you wrote is available for method and message nodes. David > On 25 Sep 2008, at 13:29, StÃ©phane Ducasse wrote: > >> Hi guys >> >> it would be great to have the senders and implementors tools >> offering move to package in their menus. >> >> Stef

Sept. 25, 2008

Re: [Pharo-project] On Icons

by Igor Stasenko

2008/9/25 David RÃ¶thlisberger <squeak(a)webcitas.ch>: > Hi Igor, > >> I know, determining all senders could be a slow operation (especially >> when you need to scan a list of them), but maybe there can be used >> some kind of optimizations like lazy/background evaluation? > > I like this idea, but indeed, performance is a big issue here. I haven't > found a solution yet to make this efficient enough. > Lazy/background evaluation would require us to store this information > directly in the compiled method object, something that I would rather not > like to do. In particular updating the information when suddendly a method > gets or loses its sender(s) might get difficult. Not necessary in methods. OB can hold a set of selectors which have no senders and update it periodically (when system changed). > > > David > > _______________________________________________ > 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.

Sept. 25, 2008

[Pharo-project] Just for fun...

by StÃ©phane Ducasse

Hi guys guess what... The old preferencePanelWindow is defined and created within the class Preferences of course preferencesControlPanel I will kill it. Stef

Sept. 25, 2008

Re: [Pharo-project] Move to package from sender and implementors list

by Alexandre Bergel

I added an issue on this. Probably what I did with the 'move package' in OB can be adapted. I will work on this. Alexandre On 25 Sep 2008, at 13:29, StÃ©phane Ducasse wrote: > Hi guys > > it would be great to have the senders and implementors tools > offering move to package in their menus. > > Stef > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 25, 2008

[Pharo-project] Move to package from sender and implementors list

by StÃ©phane Ducasse

Hi guys it would be great to have the senders and implementors tools offering move to package in their menus. Stef

Sept. 25, 2008

Re: [Pharo-project] about preparing the first release

by Bill Schwab

Stability takes at least two forms: the system works AND is not going to experience violent change. Given that more of the latter is possible/expected, it might be better to start at 0.1. 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 >>> adi(a)netstyle.ch 09/25/08 5:21 AM >>> On Sep 25, 2008, at 11:12 , Damien Cassou wrote: > On Wed, Sep 24, 2008 at 10:49 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: >> I'd suggest the common major.minor[.maintenance] scheme starting >> with "1.0". > > I would not start with "1.0" because it means this is already stable > enough for anyone to rely upon. isn't this exactly the goal of the release?! Only if the shipped version is reasonably stable the people will use it... Adrian _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 25, 2008

Re: [Pharo-project] On Icons

by David RÃ¶thlisberger

Hi Igor, > I know, determining all senders could be a slow operation (especially > when you need to scan a list of them), but maybe there can be used > some kind of optimizations like lazy/background evaluation? I like this idea, but indeed, performance is a big issue here. I haven't found a solution yet to make this efficient enough. Lazy/background evaluation would require us to store this information directly in the compiled method object, something that I would rather not like to do. In particular updating the information when suddendly a method gets or loses its sender(s) might get difficult. David

Sept. 25, 2008

Re: [Pharo-project] About traits support in OB

by David RÃ¶thlisberger

>> What do you think, should I change it like this or not? > > Give a try. I think that this is worth. ok, good, I will. David

Sept. 25, 2008

Re: [Pharo-project] On Icons

by StÃ©phane Ducasse

Thanks.! Stef > >>> something I would love to have..... >>> is a means to know whether a method is defined in multiple class >>> or only >>> the one I'm browsing. >> There is the annotation panel (to enable in the preferences) that >> shows this and other similar information. It slows everything down >> though. > > The main reason for the annotation panel to be so slow is that it > accesses all change sets to find out from where the current methods > origins... Actually, we could disable this access to the change sets > in the Preferences: #defaultAnnotationRequests. > > If we just show whether there is one or more implementor of a > method, then this will be much faster. We could introduce yet > another icon for this. ;) > > David > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 25, 2008

Re: [Pharo-project] about preparing the first release

by Adrian Lienhard

On Sep 25, 2008, at 11:12 , Damien Cassou wrote: > On Wed, Sep 24, 2008 at 10:49 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: >> I'd suggest the common major.minor[.maintenance] scheme starting >> with "1.0". > > I would not start with "1.0" because it means this is already stable > enough for anyone to rely upon. isn't this exactly the goal of the release?! Only if the shipped version is reasonably stable the people will use it... Adrian

Sept. 25, 2008

Re: [Pharo-project] about preparing the first release

by Damien Cassou

On Wed, Sep 24, 2008 at 10:49 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > I'd suggest the common major.minor[.maintenance] scheme starting with "1.0". I would not start with "1.0" because it means this is already stable enough for anyone to rely upon. Maybe 0.1 would be more appropriate. I also like the versioning scheme of Ubuntu: 08.10 means a major release which happened in October 2008. If they want a new maintainance release, they will call it 08.10.1. -- 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. 25, 2008

Re: [Pharo-project] On Icons

by David RÃ¶thlisberger

>> something I would love to have..... >> is a means to know whether a method is defined in multiple class or only >> the one I'm browsing. > > There is the annotation panel (to enable in the preferences) that > shows this and other similar information. It slows everything down > though. The main reason for the annotation panel to be so slow is that it accesses all change sets to find out from where the current methods origins... Actually, we could disable this access to the change sets in the Preferences: #defaultAnnotationRequests. If we just show whether there is one or more implementor of a method, then this will be much faster. We could introduce yet another icon for this. ;) David

Sept. 25, 2008

Re: [Pharo-project] Re: Re: Re: Re: [ANN] Demo with both Truetype+Polymorph

by StÃ©phane Ducasse

Yes write that. No pharo image open and send me the text that I review it. Stef On Sep 25, 2008, at 9:06 AM, Marcus Denker wrote: > > On 24.09.2008, at 21:57, StÃ©phane Ducasse wrote: > >> thanks for the report. >> I guess that marcus will look into that. I do not know how he made >> the one click precisely. >> > > Can you put a report on the bugtracker? > > I will not have time to look at this for the next days. I really > need to work on the SNF proposal, > securing my funding for the next months is kind of important even > for pharo ;-) > > 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. 25, 2008

Re: [Pharo-project] Do you still need a Linux VM with FreeType?

by StÃ©phane Ducasse

> The recompiling gets really more important as soon as we go for > example for > Eliot's closure implementation... that I would want to have in as > soon as possible. So marcus focus on that and let us deal with crap removal. The list you gave is good. I think that this is important to turn the TODO into issue (may be you did that) so that people can focus on one task. Stef

Sept. 25, 2008

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

by StÃ©phane Ducasse

why can we have an installer script or mcm ? We should be able to have one click install too. Stef On Sep 24, 2008, at 10:55 PM, Adrian Lienhard wrote: > The new and easy way to load Seaside takes up to 10 steps (see > below). We should try to make this even less painful in Pharo. I > assume, having Universes pre-loaded will already reduce half of the > steps, but how can it be further simplified? > > Adrian > > Begin forwarded message: > >> From: "Philippe Marschall" <philippe.marschall(a)gmail.com> >> Date: September 24, 2008 10:21:16 PM GMT+02:00 >> To: "Seaside - developer list" <seaside-dev(a)lists.squeakfoundation.org >> > >> Subject: [Seaside-dev] preliminary Seaside 2.9 alpha universe >> Reply-To: Seaside - developer list <seaside-dev(a)lists.squeakfoundation.org >> > >> >> Hi >> >> Seaside 2.9 was always hard to load. We always said that we would fix >> this and this is a preview of what we expect the solution to look >> like. >> >> After some evaluation of what is available in Squeak we had only two >> options, either start from scratch or use universes [1]. We decided >> to >> give universes a shot. Universes is something like a debian >> distribution universe for squeak. >> >> So how do you load this stuff: >> 1. get Universes, if you don't already have it (3.10) >> 1.1 get an XML parser [2] >> 1.2 get universes [3] >> 1.3 optionally the the OB universe browser [4] >> 2. save the *.packages to your image directory >> 3. load the attached .mcz >> 4. evaluate UUniverse switchSystemToUniverse: UUniverse >> seasideAndServers >> 5. in the world menu open a "Universe Browser" either basic or >> enhanced >> 6. "update list from network" >> 7. choose a distribution >> 8. choose a server >> >> There are still some unsolved issues like the naming of alpha an beta >> versions. We probably want website integration as well. One possible >> change would be to move the tests to a separate tests category. >> >> [1] http://wiki.squeak.org/squeak/3785 >> [2] http://www.squeaksource.com/universes.html >> [3] http://www.squeaksource.com/XMLSupport.html >> [4] http://www.squeaksource.com/OBUniverse.html >> >> Cheers >> Philippe > <Seaside-Universe-pmm.18.mcz><seaside.packages><servers.packages> >> >> _______________________________________________ >> seaside-dev mailing list >> seaside-dev(a)lists.squeakfoundation.org >> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 25, 2008

Re: [Pharo-project] about preparing the first release

by StÃ©phane Ducasse

> >> Hi guys >> >> I will work using the pinesoft etoy removal package. >> But it can take time to do that carefully since etoy put its >> fingers everywhere. >> Now I would really like that we define a date for the first release. >> I would really like to have something for maximum end of october. >> What about you? > > Sounds good. > > We should also think about if we do a beta phase before releasing > and if we will maintain the most recent released version? I think if > we continue making radical changes, we need to maintain the most > recent stable release, that is, to apply critical bug fixes to it. Sure this is really important. > And, what numbering scheme do we use? > > I'd suggest the common major.minor[.maintenance] scheme starting > with "1.0". > The first maintenance release then would be 1.0.1 and the following > release would be 1.1 etc. An increase of the major digit would only > be justified when fundamental changes are introduced (like image > format change). > ok for me. Stef

Sept. 25, 2008

Re: [Pharo-project] Re: Re: Re: Re: [ANN] Demo with both Truetype+Polymorph

by Marcus Denker

On 24.09.2008, at 21:57, StÃ©phane Ducasse wrote: > thanks for the report. > I guess that marcus will look into that. I do not know how he made > the one click precisely. > Can you put a report on the bugtracker? I will not have time to look at this for the next days. I really need to work on the SNF proposal, securing my funding for the next months is kind of important even for pharo ;-) Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 25, 2008

Re: [Pharo-project] Do you still need a Linux VM with FreeType?

by Marcus Denker

On 24.09.2008, at 23:16, <bryce(a)kampjes.demon.co.uk> <bryce(a)kampjes.demon.co.uk > wrote: > > I've stabilised the changes I was working on so now's a reasonable > time for me to look at this if it's still required. Is it? > > For now, I just used the vm from the seaside package and copied all th dll's in from the freetype package. This seems to work... The recompiling gets really more important as soon as we go for example for Eliot's closure implementation... that I would want to have in as soon as possible. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 25, 2008

Re: [Pharo-project] Do you still need a Linux VM with FreeType?

by Igor Stasenko

2008/9/25 <bryce(a)kampjes.demon.co.uk>: > > I've stabilised the changes I was working on so now's a reasonable > time for me to look at this if it's still required. Is it? > > Exupery already needs VMs for all major platforms, so I'm thinking > about merging that requirement with what Pharo needs. I can build > Linux VMs easily as it's my main development platform. Other platforms > depend on time, so far development has been more important than > maintaining ports for me. > Hi Bryce, i'm already added platform source for linux. You can see it on https://gforge.inria.fr/frs/?group_id=1299 page. I would appreciate if you help how to add dependency in linker (to link with -lfreetype) , if plugin is compiled in. Otherwise it require to change a makefile to complete a build. Btw, same for B3DAcceleratorPlugin - it needs adding -lgl > Bryce > > _______________________________________________ > 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.

Sept. 24, 2008

[Pharo-project] Do you still need a Linux VM with FreeType?

by bryce＠kampjes.demon.co.uk

I've stabilised the changes I was working on so now's a reasonable time for me to look at this if it's still required. Is it? Exupery already needs VMs for all major platforms, so I'm thinking about merging that requirement with what Pharo needs. I can build Linux VMs easily as it's my main development platform. Other platforms depend on time, so far development has been more important than maintaining ports for me. Bryce

Sept. 24, 2008

[Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alpha universe

by Adrian Lienhard

The new and easy way to load Seaside takes up to 10 steps (see below). We should try to make this even less painful in Pharo. I assume, having Universes pre-loaded will already reduce half of the steps, but how can it be further simplified? Adrian Begin forwarded message: > From: "Philippe Marschall" <philippe.marschall(a)gmail.com> > Date: September 24, 2008 10:21:16 PM GMT+02:00 > To: "Seaside - developer list" <seaside- > dev(a)lists.squeakfoundation.org> > Subject: [Seaside-dev] preliminary Seaside 2.9 alpha universe > Reply-To: Seaside - developer list <seaside-dev(a)lists.squeakfoundation.org > > > > Hi > > Seaside 2.9 was always hard to load. We always said that we would fix > this and this is a preview of what we expect the solution to look > like. > > After some evaluation of what is available in Squeak we had only two > options, either start from scratch or use universes [1]. We decided to > give universes a shot. Universes is something like a debian > distribution universe for squeak. > > So how do you load this stuff: > 1. get Universes, if you don't already have it (3.10) > 1.1 get an XML parser [2] > 1.2 get universes [3] > 1.3 optionally the the OB universe browser [4] > 2. save the *.packages to your image directory > 3. load the attached .mcz > 4. evaluate UUniverse switchSystemToUniverse: UUniverse > seasideAndServers > 5. in the world menu open a "Universe Browser" either basic or > enhanced > 6. "update list from network" > 7. choose a distribution > 8. choose a server > > There are still some unsolved issues like the naming of alpha an beta > versions. We probably want website integration as well. One possible > change would be to move the tests to a separate tests category. > > [1] http://wiki.squeak.org/squeak/3785 > [2] http://www.squeaksource.com/universes.html > [3] http://www.squeaksource.com/XMLSupport.html > [4] http://www.squeaksource.com/OBUniverse.html > > Cheers > Philippe > _______________________________________________ > seaside-dev mailing list > seaside-dev(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Sept. 24, 2008

Re: [Pharo-project] about preparing the first release

by Bill Schwab

Stef, Given a willingness to slip (either date or feature list) if the system is unstable, a deadline is great. 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/24/08 4:08 PM >>> Hi guys I will work using the pinesoft etoy removal package. But it can take time to do that carefully since etoy put its fingers everywhere. Now I would really like that we define a date for the first release. I would really like to have something for maximum end of october. What about you? Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 24, 2008

Re: [Pharo-project] about preparing the first release

by Adrian Lienhard

On Sep 24, 2008, at 22:08 , StÃ©phane Ducasse wrote: > Hi guys > > I will work using the pinesoft etoy removal package. > But it can take time to do that carefully since etoy put its fingers > everywhere. > Now I would really like that we define a date for the first release. > I would really like to have something for maximum end of october. > What about you? Sounds good. We should also think about if we do a beta phase before releasing and if we will maintain the most recent released version? I think if we continue making radical changes, we need to maintain the most recent stable release, that is, to apply critical bug fixes to it. And, what numbering scheme do we use? I'd suggest the common major.minor[.maintenance] scheme starting with "1.0". The first maintenance release then would be 1.0.1 and the following release would be 1.1 etc. An increase of the major digit would only be justified when fundamental changes are introduced (like image format change). Adrian

Sept. 24, 2008

Re: [Pharo-project] On Icons

by Lukas Renggli

> something I would love to have..... > is a means to know whether a method is defined in multiple class or only > the one I'm browsing. There is the annotation panel (to enable in the preferences) that shows this and other similar information. It slows everything down though. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 24, 2008

Re: [Pharo-project] Re: Re: Re: Re: [ANN] Demo with both Truetype+Polymorph

by Bill Schwab

It includes a Linux VM with the shutdown prompt fix - MUCH appreciated, not to mention the packages that were the point of demo :) 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/24/08 3:57 PM >>> thanks for the report. I guess that marcus will look into that. I do not know how he made the one click precisely. Stef

Sept. 24, 2008

[Pharo-project] about preparing the first release

by StÃ©phane Ducasse

Hi guys I will work using the pinesoft etoy removal package. But it can take time to do that carefully since etoy put its fingers everywhere. Now I would really like that we define a date for the first release. I would really like to have something for maximum end of october. What about you? Stef

Sept. 24, 2008

Re: [Pharo-project] Re: Re: Re: Re: [ANN] Demo with both Truetype+Polymorph

by Simon Kirk

Further to what I said earlier: it's not pasting from OSX - it was the string I copied in the "bare" image that would paste happily into the Pharo image. Cheers, S On 24 Sep 2008, at 20:57, StÃ©phane Ducasse wrote: > thanks for the report. > I guess that marcus will look into that. I do not know how he made > the one click precisely. > > Stef > >>>> >> Well, I'm using the one-click image from this thread (from here: https://gforge.inria.fr/frs/download.php/7268/Pharo0.1-PolymorphTT.zip) >> , so I presume it's running a VM that gets packaged with it? >> Certainly when running an image "bare" I'm running it with the VM I >> have installed on the Mac, which is 3.8.18Beta3U, and copy and >> paste works fine there. >> >> However, I think when I'm running the one-click image, I'm running >> a VM packaged within? >> >> For comparison, here is the printit output from "SmalltalkImage >> current vmVersion" on an image run "standalone": 'Squeak3.8.1 of >> ''28 Aug 2006'' [latest update: #6747] Squeak VM 3.8.18b3' >> >> And here's the printit output from the Pharo one-click linked >> above: 'Squeak3.8.1 of ''28 Aug 2006'' [latest update: #6747] >> Pharo'. >> >> I don't know if that helps. >> >> Ah, now things get extra weird! Copy and paste has *literally just* >> started working. I have seen this before. Perhaps it's because I >> tried a copy and paste on the "bare" image, then on Pharo? I can't >> say for sure what the conditions are yet, but perhaps somebody else >> has seen it. >> >> Either way, Gary definitely saw the same behaviour earlier today >> over my shoulder so he can confirm I'm not going mad :) >> >> >>>> I'm not sure if I'm repeating an earlier bug report here, or >>>> something already known, sorry if I am. >>>> >>>> Other than that, the image is looking really good :) >>> >>> >>> :) >>> >>> I want more :) I want that when I open a class browser it looks >>> really cool :) >> >> Amen to that! :) >> >> S >> >> ****************************************************************************************************************************************** >> This email is from Pinesoft Limited. Its contents are confidential >> to the intended recipient(s) at the email address(es) to which it >> has been addressed. It may not be disclosed to or used by anyone >> other than the addressee(s), nor may it be copied in anyway. If >> received in error, please contact the sender, then delete it from >> your system. Although this email and attachments are believed to be >> free of virus, or any other defect which might affect any computer >> or IT system into which they are received and opened, it is the >> responsibility of the recipient to ensure that they are virus free >> and no responsibility is accepted by Pinesoft for any loss or >> damage arising in any way from receipt or use thereof. >> ******************************************************************************************************************************************* >> >> >> Pinesoft Limited are registered in England, Registered number: >> 2914825. Registered office: 266-268 High Street, Waltham Cross, >> Herts, EN8 7EA >> >> _______________________________________________ >> 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 ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Sept. 24, 2008

[Pharo-project] [ANN] 10075

by StÃ©phane Ducasse

I removed ComponentLikeModel. Tomorrow morning we will applied our tools on pharo and start to fix package cycles. Stef going to bed :)

Sept. 24, 2008

Re: [Pharo-project] Re: Re: Re: Re: [ANN] Demo with both Truetype+Polymorph

by StÃ©phane Ducasse

thanks for the report. I guess that marcus will look into that. I do not know how he made the one click precisely. Stef >>> > Well, I'm using the one-click image from this thread (from here: https://gforge.inria.fr/frs/download.php/7268/Pharo0.1-PolymorphTT.zip) > , so I presume it's running a VM that gets packaged with it? > Certainly when running an image "bare" I'm running it with the VM I > have installed on the Mac, which is 3.8.18Beta3U, and copy and paste > works fine there. > > However, I think when I'm running the one-click image, I'm running a > VM packaged within? > > For comparison, here is the printit output from "SmalltalkImage > current vmVersion" on an image run "standalone": 'Squeak3.8.1 of > ''28 Aug 2006'' [latest update: #6747] Squeak VM 3.8.18b3' > > And here's the printit output from the Pharo one-click linked > above: 'Squeak3.8.1 of ''28 Aug 2006'' [latest update: #6747] Pharo'. > > I don't know if that helps. > > Ah, now things get extra weird! Copy and paste has *literally just* > started working. I have seen this before. Perhaps it's because I > tried a copy and paste on the "bare" image, then on Pharo? I can't > say for sure what the conditions are yet, but perhaps somebody else > has seen it. > > Either way, Gary definitely saw the same behaviour earlier today > over my shoulder so he can confirm I'm not going mad :) > > >>> I'm not sure if I'm repeating an earlier bug report here, or >>> something already known, sorry if I am. >>> >>> Other than that, the image is looking really good :) >> >> >> :) >> >> I want more :) I want that when I open a class browser it looks >> really cool :) > > Amen to that! :) > > S > > ****************************************************************************************************************************************** > This email is from Pinesoft Limited. Its contents are confidential > to the intended recipient(s) at the email address(es) to which it > has been addressed. It may not be disclosed to or used by anyone > other than the addressee(s), nor may it be copied in anyway. If > received in error, please contact the sender, then delete it from > your system. Although this email and attachments are believed to be > free of virus, or any other defect which might affect any computer > or IT system into which they are received and opened, it is the > responsibility of the recipient to ensure that they are virus free > and no responsibility is accepted by Pinesoft for any loss or damage > arising in any way from receipt or use thereof. > ******************************************************************************************************************************************* > > > Pinesoft Limited are registered in England, Registered number: > 2914825. Registered office: 266-268 High Street, Waltham Cross, > Herts, EN8 7EA > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 24, 2008

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

by StÃ©phane Ducasse

Yes I saw Now I imagine that we want to get rid of Project too. I ask because I was looking at EmbeddedWorld.... Stef >> > no. I only purged the data, which means it does not load anymore. > (there is a fix for that on the bugtracker). > > 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. 24, 2008

Re: [Pharo-project] About Flap

by Igor Stasenko

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.

Sept. 24, 2008

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

by Marcus Denker

On 24.09.2008, at 21:31, StÃ©phane Ducasse wrote: > Hi marcus > > did you remove squeakmap already? > no. I only purged the data, which means it does not load anymore. (there is a fix for that on the bugtracker). Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 24, 2008

Re: [Pharo-project] Other Morphic question: allKnownNames

by Marcus Denker

On 24.09.2008, at 21:27, StÃ©phane Ducasse wrote: > We are in sync then > I think that morphic will be quite small once we will get done with > it. :) > I will release ComponentLikeModel removal > > BTW scriptEditorMoprh is not in etoy package but it smells like it. > I think that I will try to remove it too. > What do you think? > Yes, that's etoys. I think there was some work going on to make the tiles more general and use them for non-kids stuff, too. see senders of #universalTiles. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 24, 2008