- Pharo-dev - lists.pharo.org

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

by Damien Cassou

Hi Bill, I'm not sure I understand your email completly. Please tell me if it is not the case. On Sat, Sep 27, 2008 at 5:44 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > 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. Polymorph is going to be included in all Pharo images so you don't have to worry. RB as been in all my images from the beginning and will continue to be. I think I will stop generating web images for Pharo because we want only one image for Pharo. I will try to find a way to make installing Seaside easy. > 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. I'm sorry but I do not understand this paragraph. > >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) > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- 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. 28, 2008

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

by StÃ©phane Ducasse

Hi simon This is what I meant. I wanted to understand the problem because when we merge this is important to see the diff. stef On Sep 27, 2008, at 10:07 PM, Simon Kirk wrote: > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 28, 2008

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

by bryce＠kampjes.demon.co.uk

Nikolay Suslov writes: > Here is the link to files: http://www.mirandabanda.org/cogblog/downloads/ Thanks, I'm looking into merging this in. It'll take a little work as Eliot built off an old VM. Just importing his change set breaks the build. Bryce P.S. I've got a makefile modification that works a little better. It doesn't require edits for each build, but I've hardcoded the path to the freetype include files into the makefile.

Sept. 27, 2008

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