- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Full time engineer position for Pharo looking for cool engineer :)

by StÃ©phane Ducasse

Thanks! This is also a dream for us because in the life of a researcher having an engineer is rare. Stef On Mar 9, 2010, at 7:04 AM, Andrey Larionov wrote: > Oh. Why i come in magic world of Smalltalk too late (have no necessary > experience at the moment). It's job of my dream in very beautiful > place with great colleagues :) > Good luck with candidate searching. > > On Mon, Mar 8, 2010 at 23:36, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Hi guys >> >> Some good news :) >> INRIA-lille nord Europe ranked Pharo among the top 3 projects that will receive support for a full time confirmed engineer. >> We will know if the national level or the lab will carry the cost by mid april, but for now the position is allocated to Pharo. >> >> This is not the official job announce but just to give some hints and that you can prepare yourself to >> - move to France (one hour from paris, 1h30 from London, 35 min from Brussels) >> - try a lot of good beers (belgium :) >> - eat french food >> - have fun with us - yes we are even fun - ok with geeky humor :) >> - code all the day in Smalltalk and a bit of C >> >> Apparently from what the DHR services told me, the salary will depend on years of expertise and diplomas but >> we can think that 2700 Euros (before final taxes) should be a good working number -- In France the employer pays already taxes so the salary is not brutto but already includes deduction. The social insurance is included and you may want to pay an extra like me (100 Euros) to have a better health insurance. Lille is an active city but not expensive. To give an idea Marcus got a nice sunny close to everything flat with wooden floor for 650 Euros. >> >> The job will to continue making Pharo (core) better >> - better tools >> - better network support >> - helping with the new compiler >> - helping with alien and others >> - cleaning/shrinking >> >> Duration: 30 months >> Starting date: October 2010 >> Location: Lille (no remote job possible) >> >> Do not hesitate to contact us. >> >> Stef/Marcus >> >> >> >> >> ------------------------ >> Dr. StÃ©phane Ducasse -- Directeur de Recherche (Senior Researcher) >> INRIA - USTL - CNRS UMR 8022 >> stephane.ducasse(a)inria.fr >> http://stephane.ducasse.free.fr >> http://rmod.lille.inria.fr/ >> **NEW ***Tel 00 33 (0)3 20 43 42 56 - Fax 33 3 59 57 78 50 >> >> 40, avenue Halley, Parc Scientifique de la Haute Borne, >> BÃ¢t.A, Park Plaza, Villeneuve d'Ascq, FR-59650, France. >> >> "if you knew today was your last day on earth, what would you >> do different? ... especially if, by doing something different, >> today might not be your last day on earth" Calvin&Hobbes >> >> >> >> >> >> >> _______________________________________________ >> 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] Full time engineer position for Pharo looking for cool engineer :)

by StÃ©phane Ducasse

> Some questions? > > - Is french required (A1 DELF or something like that) or English is > enough? English is enough (to your own risk :). Marcus does not speak french, mariano neither. > - Is just for single persons or married ones with kids are allowed? We pay only the person working but you can have family with you. :) I imagine that as soon as you get married your wife and kids can get visa without problems (at least from countries without security problems). > - Do you have some profile you would prefer for the position? > -- Visible projects in Smalltalk > -- Long time of contributing to Pharo Technical achievement in general. Finishing the last 2% of your great achievement. We are not pharo specific, even smart squeakers can apply :) > - What kind of Visa is required? I'm not sure that you have to do anything since our administration should get the visa for you. The applicants should get a working permit visa. > - Is some specific technical hability needed (networking experience, vm > hacking experience) This would be a plus but not necessarily. Wanting to build a better world, good communication, friendly, open-minded, efficient, working fast, **understanding** what we are building are more important! At the end trust and commitment too :) Stef

March 9, 2010

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