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

[Pharo-project] Issue 3247 breaks external packages

by Miguel CobÃ¡

I am trying to run Magma and uses TextConstants at: idiom. Before 3247 TextConstants was a Dictionary and the at: message works ok. But now that it is a SharedPool there is no way to use the external code without modify it before it works in Pharo 1.2. This change doesn't even tries to present the same interface to acces the Text constants as before. The TextConstants>>at: message in Pharo 1.2 is the Object>>at: method that obviously doesn't work. What is the reason of this change? Why is better than the dictionary (I suppose that reifying it is a reason)? What is the intended usage for code that uses TextConstants the dictionary access way? Specifically, code like this doesn't work anymore in Pharo1.2 self ~~ (TextConstants at: #DefaultTabsArray) and: [ self ~~ (TextConstants at: #DefaultMarginTabsArray) ] What should I do, I can't see a reopen status in the issue tracker. Should I open a new ticket? Cheers -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

March 15, 2011

Re: [Pharo-project] [COTDC] 31 - PreDebugWindow

by Guillermo Polito

I am the window that shows up when the debugger is launched. I show you the first lines of the stack trace that caused my apparition, and buttons to allow you to: - resume the execution - abandon the execution - debug this error - create the method if it is a DNU On Mon, Mar 14, 2011 at 7:13 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Today: PreDebugWindow > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment > will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > Laurent >

March 15, 2011

Re: [Pharo-project] Issue 3817 in pharo: make Object >> error: deprecated

by pharo＠googlecode.com

Comment #12 on issue 3817 by guillerm...(a)gmail.com: make Object >> error: deprecated http://code.google.com/p/pharo/issues/detail?id=3817 Lets convey that if you have an InvalidArgumentException, that's a bug in your code. There's no way that it can be handled. It is no useful. You can catch it? Yes, you can, but what can you do about it? I'm in favor of using specific errors, where it is useful. And there are errors you cannot (actually you shouldn't) handle, as the InvalidArgumentException. So, about deprecating Object>>error: I say -1.

March 15, 2011

Re: [Pharo-project] Issue 3817 in pharo: make Object >> error: deprecated

by pharo＠googlecode.com

Comment #11 on issue 3817 by cesar.ra...(a)gmail.com: make Object >> error: deprecated http://code.google.com/p/pharo/issues/detail?id=3817 Camillo, Regarding your comment in #6, I think replacing `Object >> error:` with something like..." is not an option, except if you're canvassing for reducing Pharo compatibility with ANSI Standard. We should find a way to arrive at the results you propose creating a tool and perhaps adding one or more methods to achieve the substitutions your deem necessary, but not change compatibility with standards. NOW, if you're calling for a different Standard, then we need to find the resources and the stamina for doing it ;-)

March 15, 2011

Re: [Pharo-project] Issue 3817 in pharo: make Object >> error: deprecated

by pharo＠googlecode.com

Comment #10 on issue 3817 by camillob...(a)gmail.com: make Object >> error: deprecated http://code.google.com/p/pharo/issues/detail?id=3817 http://www.springerlink.com/content/e7170h6104136721/ seems to be a thorough study on exception handling. One important claim is, that in order to increase software quality errors have to be handled. However, what I can see in Pharo is, that using a generic Error does not help to accomplish this goal.

March 15, 2011

Re: [Pharo-project] Issue 3817 in pharo: make Object >> error: deprecated

by pharo＠googlecode.com

Comment #9 on issue 3817 by camillob...(a)gmail.com: make Object >> error: deprecated http://code.google.com/p/pharo/issues/detail?id=3817 Just to give an example of what I mean. In Java the general error handling is mainly based on a set of specific classes, the generic Exception is almost never used. For instance InvalidArgumentException is a common use-case where in the existing Smalltalk code `self error` is used, whereas a specific would be appropriate. In many places like BlockContext >> valueError generic errors are thrown with only a user readable warning. So the main issue here is, that in may places a specific error could be used, but it isn't and hence a specific treatment of said error makes no sense at thus is not used (this is what I called a broken design). Of course the whole system has moved towards the usage of generic errors, but this is the same as starting to use generic dictionaries instead of proper objects, just because it is less effort to do so. Besides work on adapting all the senders of `Object >> error:` what would be other negative effects?

March 14, 2011

Re: [Pharo-project] Issue 3817 in pharo: make Object >> error: deprecated

by pharo＠googlecode.com

Comment #8 on issue 3817 by guillerm...(a)gmail.com: make Object >> error: deprecated http://code.google.com/p/pharo/issues/detail?id=3817 What's a broken design? Tell me how does a more specific subclass of Error help you if you don't give it an special treatment. If you don't do that, the semantics IN a class name are the same as the semantics in the string it contains if you just use the name for give information. So, if I have to show an error to the user, should I catch all exceptions and rethrow a new generic exception on the "view"? I don't catch up that part. Tell me WHY do this: "If your error should inform the "user" from within the model, then you should use an explicit class which gives additional semantics (besides the human readable string) to it." I think it doesn't make sense, as I said before why.

March 14, 2011

Re: [Pharo-project] from bash to Coral

by David T. Lewis

FYI, rudimentary scripting on top of OSProcess/CommandShell is in class CommandShell, method category "command scripting". Possibly the shell syntax parsing, file name globbing etc from CommandShell could be tied in with Coral, although I have not looked into this. Dave On Mon, Mar 14, 2011 at 03:20:06PM +0100, Adrien BARREAU wrote: > > Hi Laurent, > > I would say yes, because Coral can execute any piece of Smalltalk. > So if you can do what that script does with OSProcess, there is no reason you can't put it in a Coral script. > > At that time, there is no Coral API to make your life easier on top on things like OSProcess, but perhaps I should write some things like that. > If you have any ideas while trying, don't hesitate to tell me :). > > Adrien. > > From: laurent.laffont(a)gmail.com > Date: Mon, 14 Mar 2011 12:33:30 +0100 > To: pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] from bash to Coral > > Hi, > Is it possible today to write this using Coral ? > find application library -type f $ -name "*.php" -o -name "*.phtml" $ -exec /usr/local/bin/xgettext -j -L PHP --from-code=utf-8 --keyword=traduire --keyword=_ -o library/translation/fr.pot {} \; > > for i in `ls library/translation/*.po`do /usr/local/bin/msgmerge -s $i library/translation/fr.pot -o $i /usr/local/bin/msgfmt -o `echo $i|cut -d '.' -f1`.mo $i > > done > > > I need to write several scripts like this - would be cool to start with Coral. > > Laurent Laffont - @lolgzs > > > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Blog: http://magaloma.blogspot.com/ > Developer group: http://cara74.seasidehosting.st > > >

March 14, 2011

Re: [Pharo-project] Do you want to add the background picture to the image like we did with Pharo 1.1 ?

by GermÃ¡n Arduino

2011/3/13 Tudor Girba <tudor.girba(a)gmail.com>: > I vote against using a picture as a background. > > Doru > > +1 GermÃ¡n.

March 14, 2011

[Pharo-project] [COTDC] 31 - PreDebugWindow

by laurent laffont

Today: PreDebugWindow Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

March 14, 2011