March 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] in 11233 merging is broken?

by StÃ©phane Ducasse

thanks for investigating that. It seems to me that MC has some dark corners full of gremlins Stef On Mar 9, 2010, at 4:30 PM, Gary Chambers wrote: > Rather than ScriptLoader it appears to be a Monticello bug/feature... > > In PharoCore-1.1-11254 merging Polymorph-Widgets-gvc.109 from SqueakSource doesn't pull in > PasteUpMorph>>restoreMorphicDisplay. > > In fact, after merge it will say "no changes" upon attempted remerge, despite the obvious difference. > Something to do with MC doing snapshots relative to (common) ancestors rather then the wroking copy it seems... > > Regards, Gary > > ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Friday, February 26, 2010 9:36 AM > Subject: Re: [Pharo-project] in 11233 merging is broken? > > > I will have a look. > > Stef > > On Feb 25, 2010, at 10:38 PM, Marcus Denker wrote: > >> >> On Feb 25, 2010, at 5:35 PM, GARY CHAMBERS wrote: >> >>> Something must be wrong with the script load somehow... >>> >>> Note that there are changes between working copy after load and Polymorph-Tools-Diff-StephaneDucasse.23.mcz. >>> >>> To fix for yourself at the moment, reload Polymorph-Tools-Diff-StephaneDucasse.23.mcz. >>> >> >> >> The Scriptloader seems to never loas from the repository? Ther is a >> >> Name: Polymorph-Tools-Diff-StephaneDucasse.46 >> Author: StephaneDucasse >> Time: 10 February 2010, 7:16:13 pm >> >> >> Marcus >> >>> Not an answer to why though... >>> >>> Regards, Gary. >>> >>> From: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> To: Pharo-project Development <Pharo-project(a)lists.gforge.inria.fr> >>> Sent: Thursday, 25 February, 2010 15:50:40 >>> Subject: [Pharo-project] in 11233 merging is broken? >>> >>> Hi all >>> >>> I'm trying to integrate changes and apparently I cannot merge anymore nothing show up :). >>> two questions: >>> - do you get the behavior with 11233 or it is only me. >>> - any idea of the potential problem >>> >>> - Issue 2071: subclasses and withAllSubclasses should return a array. >>> - Issue 2076: Clean Exceptions. >>> - Issue 2072: clean RealEstateAgent. >>> >>> >>> Stef >>> _______________________________________________ >>> 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 >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> _______________________________________________ >> 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

March 9, 2010

Re: [Pharo-project] CrLfFileStream class>>new?!

by StÃ©phane Ducasse

It would be good to add that to the method and class comment. Henrik? Stef On Mar 9, 2010, at 3:11 PM, Henrik Johansen wrote: > Den 09.03.2010 14:38, skrev Adrian Lienhard: >> I was just puzzled why "CrLfFileStream defaultToLF" does not work until I figured that CrLfFileStream new returns an instance of a different class: >> >> CrLfFileStream class>>new >> ^ (MultiByteFileStream new) wantsLineEndConversion: true; yourself. >> >> >> Does somebody know what the point is? I really sometimes wonder why good coders write such code, and not even care to add a comment... >> >> Cheers, >> Adrian >> ___________________ >> http://www.adrian-lienhard.ch/ >> > CrLfFileStream does not handle any encodings other than latin1. > > My guess is: > - MultiByteFileStream probably didn't exist when it was created. > - Using a MultiByteFileStream with no encoding, but a lineEndConvention > is now the preferred method, but CrLfFileStream was kept for > backwards-compatability. > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 9, 2010

Re: [Pharo-project] [squeak-dev] Alien on Win32 - Test and Integration into VM Sources

by StÃ©phane Ducasse

Excellent! Thanks! Stef On Mar 9, 2010, at 1:16 PM, David T. Lewis wrote: > Thanks, > > I opened a Mantis report to track this for the VM developers > http://bugs.squeak.org/view.php?id=7475 > > You can attach patches to the Mantis report (or I'll try to collect > them from the previous posts, but I'm short of time this week). > > Andreas can reply WRT the Windows patches. FYI, Ian (Unix VM) has > been busy elsewhere but will probably be back shortly (next week > I think). Ian prefers to receive platform files (whole files, not > diffs) by email if possible (but I will try to coordinate if I > can get pointers to the right patches). > > IIUC no changes are required to the VMMaker package itself, as > the Alien changes are maintained in separate repository. Please > correct me if that is not right. > > Follow up discussion should go to the vm-dev list unless of > general interest. > > Thanks! > > Dave > > On Tue, Mar 09, 2010 at 12:53:17PM +0100, Torsten Bergmann wrote: >> Cool! With Alien working on Win32 we now have it on all >> major platforms (windows, linux, mac) >> >> I send this mail CC to the squeak-dev/pharo-dev list so >> others are able to try the plugin on Win32 and give feedback. >> >> This mail also goes to vm-dev list and I hope one of the >> vm-maintainers (Andreas, Elliot, David? - also in CC:) are >> able to respond to you directly on how to integrate your changes >> into the offical win32 vm sources. >> >> Thx >> Torsten >> >> -------- Original-Nachricht -------- >> Datum: Tue, 9 Mar 2010 09:47:45 +0100 >> Von: "Schmidt, Marco" <Marco.Schmidt AT eads.com> >> An: "Torsten Bergmann" <astares AT gmx.de> >> CC: ml-node+104410-17186360-21457(a)n4.nabble.com >> Betreff: AW: Test Alien on Win32... >> >> I added a zip file with the exe and the needed dlls to the bug 1360 (http://code.google.com/p/pharo/issues/detail?id=1360) >> >> I tested in the last days CairoGraphics and my own CurlLibrary binding - success! I have working callbacks for Curl too. >> >> I cloned the svn repo into a git repo. What is the correct format to submit patches to the developers? >> >> Marco >> >> >> -- >> Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - >> jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 9, 2010

Re: [Pharo-project] 11254 Image available

by StÃ©phane Ducasse

thanks! I should write a filter to scan for these characters in the package name http://code.google.com/p/pharo/issues/detail?id=2124 Stef On Mar 9, 2010, at 12:23 PM, Gary Chambers wrote: > For reference, Vista reports that the following are invalid characters: > > \ / : * ? " < > | > > Regards, Gary > > ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, March 08, 2010 8:38 PM > Subject: [Pharo-project] 11254 Image available > > >> Hi guys >> >> sorry for the fact that some of you could not update anymore due to a stupid name for package (we should check >> that : space ; / cannot be put in the package name. >> >> https://gforge.inria.fr/frs/download.php/26637/PharoCore-1.1-11254-UNSTABLE… >> >> Stef >> _______________________________________________ >> 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

March 9, 2010

Re: [Pharo-project] FieldNode

by StÃ©phane Ducasse

Thanks. Do you have a snippet to remove it cleanly? Stef On Mar 9, 2010, at 10:02 AM, Pavel Krivanek wrote: > Hi, > > I suppose that the class FieldNode should be removed. It is a Tweak hack: > > "FieldNode handles field access in Tweak, e.g. self fieldName := foo > => self fieldName: foo." > > it is used only in Encoder >> #init:context:notifying: where it > supposes nil offset. There's no such case in Pharo. > > Cheers > -- Pavel > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 9, 2010

Re: [Pharo-project] Fwd: Pharo by Example vol 2: new chapter available

by StÃ©phane Ducasse

For me there are much more important things to fix or make better :) Stef > I haven't read the chapter yet, but there is something that bothers me a little about the Exception hierarchy... what I've seen lately is that Exceptions are not used only as exceptions but as a why to get context information (for example Seaside with WACurrentRequestContext), notify about an event (for example the Notification class and subclasses), etc. > Despite if it is a good idea to solve this issues with exceptions, calling Exception to the root of the hierarchy makes a lot of noise (at least to me... I mean, a Notification is not an Exception, something you were not expecting... getting the current context has nothing to do with an exception...)... So, have you think about changing the name to that class and making the protocol simpler (at least for the root of the hierarchy) so all these types of uses fit better than they do today? (for example, retrying a notification looks like no sense, the same for wacurrentrequestcontext) > I think that the idea of "crawling" on the execution stack or the execution flow have more sense as metaphor to look for another name... > Anyway, just a thought. > Bye, > Hernan. > > 2010/3/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Thanks laurent > > Stef > > > Begin forwarded message: > >> From: laurent laffont <laurent.laffont(a)gmail.com> >> Date: March 3, 2010 10:09:32 PM GMT+01:00 >> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> Subject: Re: [Pharo-project] Pharo by Example vol 2: new chapter available >> >> Some notes: >> >> Page 1: The basic idea behing exception .... I would expect a schema to show the workflow. >> >> Page 8: When an exception is signaled, the exception handling mechanism ....I've read it 3 times (for something finally quite simple), maybe it needs a sequence diagram or reformulation. >> >> Section 1.15: How exceptions are implemented. I had to read several times to understand, lot of informations to handle at once. >> >> Page 27 (bottom): For example, in method 1.1 ... specify "on page 19" or put the snippet again so we can easily compare with method 1.2. >> >> I like the "real code" examples. The "How..." sections too. >> >> When not to use Exceptions: not to "hide errors". I have too many times seen try ... catch ... to hide errors to the users. >> >> Maybe add a "When to use Exceptions" section, reminding the "Crash early" principle. >> >> Laurent Laffont >> >> >> On Tue, Mar 2, 2010 at 2:26 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Hi guys >> >> We just released a new chapter for Pharo by Example Vol.2 on Exceptions >> http://pharobyexample.org/ >> >> Let us know what you think. >> >> Stef >> >> _______________________________________________ >> 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

March 9, 2010

Re: [Pharo-project] [Moose-dev] Re: XML Parser / Pastell

by Alexandre Bergel

NB: I switch to Pharo > Normally when you want to deprecate a method and discourage people > from using it you need only insert a "self deprecated: description" > line into it. When someone invokes such a method, they receive a > warning of its deprecation listing specifically its name and class. Yep, I understand this. Apparently, SAXDriver>>handleStartTag:attributes:namespaces: (indirectly) calls #startElement:attributes:, a deprecated method. Do you think we should update handleStartTag:attributes:namespaces: ? Also, the method SAXHandler>>startElement:prefix:uri:attributes: is not covered by the test. I think it is important that this method is covered. Cheers, Alexandre > I wanted to rename some of the handler messages in SAXHandler so > they would be more consistent with each other (note, for example, > the different argument order between > #startElement:namespaceURI:namesapce- and > #endElement:namespace:namespaceURI-) and also with other parts of > the API (-attributeList: vs. -atttributes:). Unfortunately, there is > no easy way to deprecate such messages. Users do not send them; > instead they override them in subclasses and expect the overridden > versions to be invoked by SAXDriver. Another problem is that the > handlers must degrade in a specific order, with each form invoking > the one taking the most arguments after it until the one taking the > fewest arguments (e.g., #startElement:attributes:) is reached. > > That unusual #forwardToDeprecatedHandler:withArgumentOrder:orTo: > message you discovered is the ad hoc solution. In renamed handlers > it checks to see if the old, deprecated version is implemented in > the class of the receiver and if it is, warns that it has been > deprecated and suggests using the new form--the caller--prior to > invoking the old form with the caller's arguments (reordered if > needed). If the deprecated version is not present, then it either > degrades in the normal fashion, invoking the version taking next- > most arguments after itself (which may also check for a deprecated > version of itself) or do nothing if no other handler needs to be > invoked. > >>> >>> The most recent version is completely string-based. The performance >>> of the symbol-based predecessors was erratic; it would be terribly >>> slow at first in a clean image and improve only after saving the >>> image at least once. Even then my tests indicated that a purely >>> string-based version would be faster. This is likely due to the >>> initial overhead of interning symbols and then the subsequent >>> overhead of looking them up. I did honestly prefer the #symbol >>> syntax for naming things, but considering that the things so-named >>> and the names themselves all begin life (from the tokenizer) as >>> strings, it makes more sense (and requires less code) to keep them >>> that way. It is also more portable, as we no longer need assume that >>> Symbol is a subclass of String. I don't think this will cause issues >>> in Squeak/Pharo code, as both systems (for now) assume #name = >>> 'name'. Hopefully it will not cause too much trouble for Norbert. >>> >>> Alexandre, you should see an improvement in your benchmarks now. >> >> Indeed! >> Cool! >> >> Alexandre >> >>> >>>>>>> anElement attributes class (I wrote species but that will fail >>>>>>> in >>>>>>> gemstone too I guess. Hell!) >>>>>> >>>>>> I just committed with species. Let me know. This is easy to >>>>>> adjust. >>>>>> >>>>> Ok. >>>>> >>>>>>>>> The gemstone XML Parser decides somehow to use >>>>>>>>> IdentityDictionary internally. I think this should be >>>>>>>>> allowed. I >>>>>>>>> just changed Dictionary to IdentityDictionary so the = test >>>>>>>>> reflects the right type. If you change it it is clear that it >>>>>>>>> fails. Because pharo uses Dictionary internally. So you might >>>>>>>>> see that it is not a question of using Dictionary or >>>>>>>>> IdentityDictionary but a question of the wrongness of using = >>>>>>>> >>>>>>>> How the XMLNodeTest should look like to accommodate your >>>>>>>> situation? >>>>>>>> >>>>>>> I need to recheck this. The problem is really that the XML >>>>>>> Parser >>>>>>> creatios instances of class Association but { #key->'value' } >>>>>>> creates an instance of class SymbolAssociation. That means I >>>>>>> would >>>>>>> know how to fix the test but I want to understand the >>>>>>> implications >>>>>>> of all of this. I'll get to you if I know anything new. >>>>>> >>>>>> Ok. >>>>>> >>>>> My mail to the gemstone list led to a ticket about removing class >>>>> checks from Association. That would be easing the handling a lot. >>>>> >>>>> Norbert >>>>>>> >>>>>>> >>>>>>>> Alexandre >>>>>>>> >>>>>>>>> >>>>>>>>>>> Here there is an assumption about the allAttributes >>>>>>>>>>> collection >>>>>>>>>>> while using = as comparsion. But there is also an assumption >>>>>>>>>>> about the order of the content. I changed this to >>>>>>>>>>> >>>>>>>>>>> self assert: (firstPerson allAttributes includesAllOf: >>>>>>>>>>> #(#'first-name' #'employee-number' #'family-name')). >>>>>>>>>>> self assert: (firstPerson allAttributeAssociations asArray >>>>>>>>>>> includesAllOf: {(#'first-name'->'Bob'). (#'employee-number'- >>>>>>>>>>>> 'A0000'). (#'family-name'->'Gates')}). >>>>>>>>>> >>>>>>>>>> Very right. My mistake. But wouldn't an asSortedCollection do >>>>>>>>>> the thing? Do you not test the size of the array. >>>>>>>>>> >>>>>>>>>>> This is not the best way to do because the check is only in >>>>>>>>>>> one direction but for this test it is ok. Somehow the second >>>>>>>>>>> assert fails and I have to check what is going on here. >>>>>>>>>> >>>>>>>>>> Yeah, my mistake. Sorry. The elements may be differently >>>>>>>>>> ordered. Would a asSortedCollection help? >>>>>>>>>> >>>>>>>>>> I have now granted you an access to the repository. You >>>>>>>>>> should >>>>>>>>>> be able to directly commit in it. >>>>>>>>>> >>>>>>>>>> Jaayer, what is your Squeaksource account? >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Alexandre >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 28.02.2010, at 02:01, Alexandre Bergel wrote: >>>>>>>>>>> >>>>>>>>>>>>> thanks for now. I did a first merge attempt. It will be >>>>>>>>>>>>> quite a bit of work. For me the xml parser is an important >>>>>>>>>>>>> component. With the newest changes it became biased >>>>>>>>>>>>> towards >>>>>>>>>>>>> pharo. There are things like ClassTestCase, Unicode >>>>>>>>>>>>> CharacterSet. These are for sure improvements/changes in >>>>>>>>>>>>> pharo you like to use. But they make porting a lot more >>>>>>>>>>>>> difficult. I would be glad if we could find some way to >>>>>>>>>>>>> lower the porting barrier. The necessary class I could put >>>>>>>>>>>>> in the squeak compat package in gemstone. But then the xml >>>>>>>>>>>>> parser will depend on the squeak package which I don't >>>>>>>>>>>>> like. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi Norbert, >>>>>>>>>>>> >>>>>>>>>>>> XMLParser effectively depends on Squeak specific classes. I >>>>>>>>>>>> wrote a small script that identify the squeak classes >>>>>>>>>>>> used in >>>>>>>>>>>> XML-Support. Here is the list: LanguageEnvironment, >>>>>>>>>>>> Unicode, >>>>>>>>>>>> LocaleID, CharacterSet >>>>>>>>>>>> >>>>>>>>>>>> I guess that porting the whole multilingual support may not >>>>>>>>>>>> be that easy. The tag xml:lang is used to select the proper >>>>>>>>>>>> support. It should be easy for you to ignore it I guess. >>>>>>>>>>>> >>>>>>>>>>>> CharacterSet seems to be one that has to be ported. It is >>>>>>>>>>>> not >>>>>>>>>>>> a big class. It depends on WideCharacterSet. I am not sure >>>>>>>>>>>> whether this is useful in your case however. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Alexandre >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 9, 2010

Re: [Pharo-project] Fwd: Pharo by Example vol 2: new chapter available

by Hernan Wilkinson

hey, you are right, I forgot about that in Java. On Tue, Mar 9, 2010 at 8:31 AM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > hi Hernan, > > You're very right saying that exception are often abused. In Java, you have > a class Throwable. > > Cheers, > Alexandre > > > > On 9 Mar 2010, at 08:10, Hernan Wilkinson wrote: > > I haven't read the chapter yet, but there is something that bothers me a >> little about the Exception hierarchy... what I've seen lately is that >> Exceptions are not used only as exceptions but as a why to get context >> information (for example Seaside with WACurrentRequestContext), notify about >> an event (for example the Notification class and subclasses), etc. >> Despite if it is a good idea to solve this issues with exceptions, calling >> Exception to the root of the hierarchy makes a lot of noise (at least to >> me... I mean, a Notification is not an Exception, something you were not >> expecting... getting the current context has nothing to do with an >> exception...)... So, have you think about changing the name to that class >> and making the protocol simpler (at least for the root of the hierarchy) so >> all these types of uses fit better than they do today? (for example, >> retrying a notification looks like no sense, the same for >> wacurrentrequestcontext) >> I think that the idea of "crawling" on the execution stack or the >> execution flow have more sense as metaphor to look for another name... >> Anyway, just a thought. >> Bye, >> Hernan. >> >> 2010/3/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> Thanks laurent >> >> Stef >> >> >> Begin forwarded message: >> >> From: laurent laffont <laurent.laffont(a)gmail.com> >>> Date: March 3, 2010 10:09:32 PM GMT+01:00 >>> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> Subject: Re: [Pharo-project] Pharo by Example vol 2: new chapter >>> available >>> >>> Some notes: >>> >>> Page 1: The basic idea behing exception .... I would expect a schema to >>> show the workflow. >>> >>> Page 8: When an exception is signaled, the exception handling mechanism >>> ....I've read it 3 times (for something finally quite simple), maybe it >>> needs a sequence diagram or reformulation. >>> >>> Section 1.15: How exceptions are implemented. I had to read several times >>> to understand, lot of informations to handle at once. >>> >>> Page 27 (bottom): For example, in method 1.1 ... specify "on page 19" or >>> put the snippet again so we can easily compare with method 1.2. >>> >>> I like the "real code" examples. The "How..." sections too. >>> >>> When not to use Exceptions: not to "hide errors". I have too many times >>> seen try ... catch ... to hide errors to the users. >>> >>> Maybe add a "When to use Exceptions" section, reminding the "Crash >>> early" principle. >>> >>> Laurent Laffont >>> >>> >>> On Tue, Mar 2, 2010 at 2:26 PM, StÃ©phane Ducasse < >>> stephane.ducasse(a)inria.fr> wrote: >>> Hi guys >>> >>> We just released a new chapter for Pharo by Example Vol.2 on Exceptions >>> http://pharobyexample.org/ >>> >>> Let us know what you think. >>> >>> Stef >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 9, 2010

Re: [Pharo-project] Please: less license blahblah, more actual progress on the issue

by Schwab,Wilhelm K

Paolo, Perhaps I'm getting this out of context, but you have done something *very* difficult to do: you've offended me (on Stef's behalf). Asking Stef to "do something constructive" is like asking asking a shark to swim. As for GPL in any variant, I have never trusted it, and see no justifiable advantage over something like MIT or BSD. Your (apparent) reaction to Stef is only deepening my preference for simplicity of licensing. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Paolo Bonzini Sent: Tuesday, March 09, 2010 11:05 AM To: GNU Smalltalk; Pharo Development; ESUG Mailing list Cc: stephane ducasse Subject: [Pharo-project] Please: less license blahblah, more actual progress on the issue On Mon, Mar 8, 2010 at 18:53, stephane ducasse <stephane.ducasse(a)gmail.com> wrote: > Thanks thanks thanks thanks for a refresh on that! > Thanks! Stef, instead of thanking five times, why don't you try to do something constructive? The GPLv3 includes a system of granting Additional Permissions. This system has already been used by GCC and Autoconf. Let's develop a set of additional permissions that we believe do not "taint" the whole image. I placed a starting point at http://smalltalk.gnu.org/blog/bonzinip/towards-permissive-copyleft-license-… [To those that followed the entire thread: this is totally independent of how any GSoC code related to GNU Smalltalk will be licensed]. Paolo _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 9, 2010

Re: [Pharo-project] More news about GSoC!!!

by Mariano Martinez Peck

On Tue, Mar 9, 2010 at 10:46 AM, Geert Claes <geert.wl.claes(a)gmail.com>wrote: > > > Mariano Martinez Peck wrote: > > > >> Is there a way to vote for ideas? > >> > > > > be a mentor ;) > > > > Seriously. This is a complicated subject that I am not sure what to do. > In > > previous Squeak GSoC (2007 and 2008) only the mentors vote for the > > project. > > Suppose there were 20 projects, and Google gave Squeak 5 slots...then > each > > mentor vote their most interesting 5 projects...The 5 projects with more > > votes, won. > > > > Letting only the mentors to vote have advantages and disadvantages. > > Advantages is that there is a lot of people in the community that only > > talk, > > only ask, only "I would like". But few do. We don't want to feed those > who > > only talk. > > On the other hand, there is a lot of people who works a lot, but they are > > not mentors...so, it is a pity for them. But you cannot make that > > difference. > > > > So, as you can see, it is not easy. > > > > If we get selected then we should review this. > > > > Mariano > > > > Fair enough, even though I would like to be more actively involved, I > simply > don't have the time at the moment ... voting could give all mentors an > indication of the popularity of their ideas though couldn't it? > Maybe that's a good idea. Let all the people vote, but just to show mentors and co-mentors what the community wants. Then...is up to them to vote whatever they want... Thanks for the idea!!! I hope we have to discuss this topic (because it would mean we were selected...) > -- > View this message in context: > http://n4.nabble.com/More-news-about-GSoC-tp1585307p1585737.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 9, 2010