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

[Pharo-project] Citezen vs. Google Scholar bug??

by Schwab,Wilhelm K

Stef, I *think* Google Scholar is in the wrong here, but I'll mention it just in case. I've tried to paste the controversial entry below, but in case it gets corrupted in transfer, it is the third hit on Google Scholar with surface tension inclined tube stability Dumitrescu @article{couÃ«t1987effects, title={{The effects of surface tension and tube inclination on a two-dimensional rising bubble}}, author={Cou{\\"e}t, B. and Strumolo, G.S.}, journal={Journal of Fluid Mechanics}, volume={184}, pages={1--14}, issn={0022-1120}, year={1987}, publisher={Cambridge Univ Press} } The BibTeX source above is from GS' "Import into BibTeX" feature. Citezen didn't like it. I am assuming that the problem is that accented e in the key. Changing it to a "plain" e allowed my code to proceed. The real question is whether extended characters are legal in the key? If not, then Citezen is correct to complain. Bill

Dec. 21, 2010

Re: [Pharo-project] a way to ignore warnings?

by Dale Henrichs

HernÃ¡n I agree with you, because practicality outweighs correctness... However I mainly wanted to point out that handling Notifications in the general case is not a good idea ... For development and personal scripts, where you can fix the problems on the fly just about anything goes ... Dale On 12/21/2010 10:41 AM, HernÃ¡n Morales Durand wrote: > Hi Dale, > > Thanks for your comments, some notes between lines... > > 2010/12/21 Dale Henrichs<dhenrich(a)vmware.com>: >> On 12/20/2010 09:27 PM, HernÃ¡n Morales Durand wrote: >>> >>> 2010/12/20 Esteban Lorenzano<estebanlm(a)gmail.com>: >>>> >>>> duh... >>>> [ ... ] on: Warning do: [ :w | w resume ]. >>>> forget my question... :( >>> >>> That wouldn't make it for Notifications such as: >>> >>> self inform: 'test' >>> >>> so you might want to write: >>> >>> [ self inform: 'test' ] >>> on: Warning, Notification >>> do: [: ex | ex return: 'Ignored: ' , ex class name , ' ' , ex messageText >>> ]. >>> >> >> I would be careful about handling all Notifications. Unlike Error, there is >> no "correct" pattern for handling Notifications, just take a look at all >> implementors of #defaultAction for subclasses of Notification and you will >> see that in most cases, the default action returns an application specific >> object, so returning a String instead will break them all .. >> >> Notifications are meant to be ignored unless you know what you are doing. >> > > Agree. Although I think you're focusing on handling properly the > answer but Esteban just wanted to bypass modal dialogs so a time > consuming operation could finish without human intervention. In that > case we can assume he isn't going to provide a "dangerous" default for > a confirm operation and he'd like to log warnings and informations. > Esteban may you comment is that your case? > >> It turns out that even handling Warning can be dangerous. For Warning it is >> correct to use #resume to ignore the Warning (which ends up doing a `ex >> resume: nil`). However, UndeclaredVariableWarning (a subclass of Warning) >> expects a Boolean result, so if the code you are wrapping does any compiles >> you'll have to special case UndeclaredVariableWarning to do `ex resume: >> true`. >> > > Yes, I've seen the UndeclaredVariableWarning (from > Encoder>>undeclared: ) dialog many times when compiling > programatically, and one of things is that I have to handle every > compilation to avoid this dialog like this: > > [ self targetClass > compile: aString > classified: aCategoryClassification ] > on: UndeclaredVariableWarning > do: [: ex | self log: 'Warning UndeclaredVariableWarning in ' , self > targetClass asString , '>>' , aString asString ] > > I didn't found a preference to ignore this dialog, although I've found > > Parser warningAllowed -> false "That would be the More Warnings preference " > > I wonder is there a setting I've missed? > >> To ignore #inform: in Pharo, handling ProvideAnswerNotification is a better >> choice than Notification, but you need to be aware of the implications of >> ignoring inform: as ProvideAnswerNotification is used for dealing with: >> >> inform: - return value is ignored >> confirm:: - return values is expected to be a Boolean >> request: - is expected to be a String >> >> As Adrian mentions, if you are want to automate the handling of >> inform:/confirm:/request: you are better off using valueSupplyingAnswers:. >> >> Finally, in the above example using 'ex return:'a string` is not the correct >> way to ignore a Warning or Notification. The #return: messages returns the >> arg as the result of the block (unwinding the stack). #resume: returns the >> arg as the result of the #signal: and continues execution from that point. >> Take a look at the different results for the following two expressions: >> >> | w x y z | >> w := x:= y:= z:= nil. >> x:= [ w := #before. >> y:= self confirm: 'test'. >> z := #after ] >> on: ProvideAnswerNotification >> do: [:ex | ex return: false ]. >> {w. x. y. z.}. >> >> | w x y z | >> w := x:= y:= z:= nil. >> x:= [ w := #before. >> y:= self confirm: 'test'. >> z := #after ] >> on: ProvideAnswerNotification >> do: [:ex | ex resume: false ]. >> {w. x. y. z.}. >> > > I don't know if assuming always that "correct" means continue > execution in that scope. It may depend on the warning or notification > and the block task, but of course #resume: is a more common sense > choice for most cases. > >> HernÃ¡n this is common mistake when putting together simple examples and if I >> hadn't just finished writing a series of automatic Warning handlers, I >> wouldn't have picked up on it:) >> > > I know :) it could be as complex as hell, that's why I say you have to > automate exceptions with a specific goal in mind, for example logging > or finish an unattended loading. > Cheers, >

Dec. 21, 2010

Re: [Pharo-project] [OT] Re: Why Smalltalk ? Which Smalltalk ?

by Casimiro de Almeida Barreto

Em 21-12-2010 16:31, Sven Van Caekenberghe escreveu: > On 21 Dec 2010, at 19:16, Levente Uzonyi wrote: > >> a) removing unessential code from Squeak (Squeak, having started as a children.s education project, has accumulated a fair amount of cruft over the years), >> b) clearer licensing (MIT license), >> c) more frequent updates (think Ubuntu versus Debian), and >> d) being a reference implementation for the Seaside platform (perfect, exactly what I need it for)." >> >> b) and c) are clearly false. a) ignores the fact that you can unload quite a lot of "cruft" from Squeak making it comparable to Pharo-Core. > I might be wrong, and I known that Squeak has been changing lately, but Pharo seems to have been the driver here, putting these issues on the map. Following blogs, forums & e-mail lists you'll find these issues have been discussed since 2008 (at least). Split had little to do with technical issues (unfortunately). I agree with (b) & (c) false, (a) half-true & (d) true. I guess that both communities must learn from successes & errors from each other. Currently neither squeak nor pharo have enough technical differences to claim significant superiority over the other. One thing I like in squeak is that's possible to update it without having to backup & reinstall. On the other hand, pharo has a nicer way of installing stuff. > Sven > > > CdAB

Dec. 21, 2010

Re: [Pharo-project] Issue 3472 in pharo: Text selection problem in Pharo-dev 1.2

by pharo＠googlecode.com

Updates: Labels: Milestone-1.2-DevImage Comment #1 on issue 3472 by marcus.denker: Text selection problem in Pharo-dev 1.2 http://code.google.com/p/pharo/issues/detail?id=3472 (No comment was entered for this change.)

Dec. 21, 2010

Re: [Pharo-project] a way to ignore warnings?

by HernÃ¡n Morales Durand

Hi Dale, Thanks for your comments, some notes between lines... 2010/12/21 Dale Henrichs <dhenrich(a)vmware.com>: > On 12/20/2010 09:27 PM, HernÃ¡n Morales Durand wrote: >> >> 2010/12/20 Esteban Lorenzano<estebanlm(a)gmail.com>: >>> >>> duh... >>> [ ... ] on: Warning do: [ :w | w resume ]. >>> forget my question... :( >> >> That wouldn't make it for Notifications such as: >> >> self inform: 'test' >> >> so you might want to write: >> >> [ self inform: 'test' ] >> on: Warning, Notification >> do: [: ex | ex return: 'Ignored: ' , ex class name , ' ' , ex messageText >> ]. >> > > I would be careful about handling all Notifications. Unlike Error, there is > no "correct" pattern for handling Notifications, just take a look at all > implementors of #defaultAction for subclasses of Notification and you will > see that in most cases, the default action returns an application specific > object, so returning a String instead will break them all .. > > Notifications are meant to be ignored unless you know what you are doing. > Agree. Although I think you're focusing on handling properly the answer but Esteban just wanted to bypass modal dialogs so a time consuming operation could finish without human intervention. In that case we can assume he isn't going to provide a "dangerous" default for a confirm operation and he'd like to log warnings and informations. Esteban may you comment is that your case? > It turns out that even handling Warning can be dangerous. For Warning it is > correct to use #resume to ignore the Warning (which ends up doing a `ex > resume: nil`). However, UndeclaredVariableWarning (a subclass of Warning) > expects a Boolean result, so if the code you are wrapping does any compiles > you'll have to special case UndeclaredVariableWarning to do `ex resume: > true`. > Yes, I've seen the UndeclaredVariableWarning (from Encoder>>undeclared: ) dialog many times when compiling programatically, and one of things is that I have to handle every compilation to avoid this dialog like this: [ self targetClass compile: aString classified: aCategoryClassification ] on: UndeclaredVariableWarning do: [: ex | self log: 'Warning UndeclaredVariableWarning in ' , self targetClass asString , '>>' , aString asString ] I didn't found a preference to ignore this dialog, although I've found Parser warningAllowed -> false "That would be the More Warnings preference " I wonder is there a setting I've missed? > To ignore #inform: in Pharo, handling ProvideAnswerNotification is a better > choice than Notification, but you need to be aware of the implications of > ignoring inform: as ProvideAnswerNotification is used for dealing with: > > Â inform: Â Â Â Â Â - return value is ignored > Â confirm:: Â Â Â Â - return values is expected to be a Boolean > Â request: Â Â Â Â Â - is expected to be a String > > As Adrian mentions, if you are want to automate the handling of > inform:/confirm:/request: you are better off using valueSupplyingAnswers:. > > Finally, in the above example using 'ex return:'a string` is not the correct > way to ignore a Warning or Notification. The #return: messages returns the > arg as the result of the block (unwinding the stack). #resume: returns the > arg as the result of the #signal: and continues execution from that point. > Take a look at the different results for the following two expressions: > > | w x y z | > w := x:= y:= z:= nil. > x:= [ w := #before. > Â Â Â Â y:= self confirm: 'test'. > Â Â Â Â z := #after ] > Â Â Â Â Â Â Â Â on: ProvideAnswerNotification > Â Â Â Â Â Â Â Â do: [:ex | ex return: false ]. > {w. x. y. z.}. > > | w x y z | > w := x:= y:= z:= nil. > x:= [ w := #before. > Â Â Â Â y:= self confirm: 'test'. > Â Â Â Â z := #after ] > Â Â Â Â Â Â Â Â on: ProvideAnswerNotification > Â Â Â Â Â Â Â Â do: [:ex | ex resume: false ]. > {w. x. y. z.}. > I don't know if assuming always that "correct" means continue execution in that scope. It may depend on the warning or notification and the block task, but of course #resume: is a more common sense choice for most cases. > HernÃ¡n this is common mistake when putting together simple examples and if I > hadn't just finished writing a series of automatic Warning handlers, I > wouldn't have picked up on it:) > I know :) it could be as complex as hell, that's why I say you have to automate exceptions with a specific goal in mind, for example logging or finish an unattended loading. Cheers, -- HernÃ¡n Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.

Dec. 21, 2010

Re: [Pharo-project] [OT] Re: Why Smalltalk ? Which Smalltalk ?

by Sven Van Caekenberghe

On 21 Dec 2010, at 19:16, Levente Uzonyi wrote: > a) removing unessential code from Squeak (Squeak, having started as a children.s education project, has accumulated a fair amount of cruft over the years), > b) clearer licensing (MIT license), > c) more frequent updates (think Ubuntu versus Debian), and > d) being a reference implementation for the Seaside platform (perfect, exactly what I need it for)." > > b) and c) are clearly false. a) ignores the fact that you can unload quite a lot of "cruft" from Squeak making it comparable to Pharo-Core. I might be wrong, and I known that Squeak has been changing lately, but Pharo seems to have been the driver here, putting these issues on the map. Sven

Dec. 21, 2010

Re: [Pharo-project] Issue 3224 in pharo: Migrating MethodReference to MethodReferenceWithSource

by pharo＠googlecode.com

Comment #6 on issue 3224 by luc.fabresse: Migrating MethodReference to MethodReferenceWithSource http://code.google.com/p/pharo/issues/detail?id=3224 ok, so we must kill the senders.

Dec. 21, 2010

Re: [Pharo-project] Why Smalltalk ? Which Smalltalk ?

by Henrik Johansen

Den 21.12.2010 18:57, skrev Miguel CobÃ¡: > El mar, 21-12-2010 a las 18:51 +0100, Levente Uzonyi escribiÃ³: >> On Tue, 21 Dec 2010, Sven Van Caekenberghe wrote: >> >>> On 21 Dec 2010, at 00:14, Levente Uzonyi wrote: >>> >>>> Really? The third question has 3 wrong answers... >>> OK, I'll take the bait: I was looking for a high-quality, professional, well-maintained open-source Smalltalk supported by an active community with the right ideas, attitudes and ideals going forward, and I am happy I found it. And it seems I am not the only one. >> I guess you're missing my point, which is: the post has false statements. > Maybe you can show us the false statements and not let us guess what are > you refering to b) and c) definetely. The situation was rather different back around april, if his last exposure to Squeak was back then it could be called merely outdated. a) is debatable I guess, with the unloading work that's been done in Squeak, depending on how you define "removing". (I think Cuis would win this one hands down if it were included for consideration though) Cheers, Henry

Dec. 21, 2010

[Pharo-project] [OT] Re: Why Smalltalk ? Which Smalltalk ?

by Levente Uzonyi

On Tue, 21 Dec 2010, Miguel CobÃ¡ wrote: > El mar, 21-12-2010 a las 18:51 +0100, Levente Uzonyi escribiÃ³: >> On Tue, 21 Dec 2010, Sven Van Caekenberghe wrote: >> >>> >>> On 21 Dec 2010, at 00:14, Levente Uzonyi wrote: >>> >>>> Really? The third question has 3 wrong answers... >>> >>> OK, I'll take the bait: I was looking for a high-quality, professional, well-maintained open-source Smalltalk supported by an active community with the right ideas, attitudes and ideals going forward, and I am happy I found it. And it seems I am not the only one. >> >> I guess you're missing my point, which is: the post has false statements. > > Maybe you can show us the false statements and not let us guess what are > you refering to IMHO there's no need to guess and it's better to discuss it in the blog itself, but here you go: "Although I.ve worked with .plain Squeak. for a number of years, the Pharo fork was a fairly easy choice since it focuses on a) removing unessential code from Squeak (Squeak, having started as a children.s education project, has accumulated a fair amount of cruft over the years), b) clearer licensing (MIT license), c) more frequent updates (think Ubuntu versus Debian), and d) being a reference implementation for the Seaside platform (perfect, exactly what I need it for)." b) and c) are clearly false. a) ignores the fact that you can unload quite a lot of "cruft" from Squeak making it comparable to Pharo-Core. So I consider it false. d) is clearly true, but not a strong argument, because Seaside is cross-platform. Levente > > >> And a decision is based on these false statements. >> >> >> Levente >> >>> >>> Sven >>> >>> >>> >> > > -- > Miguel CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > > >

Dec. 21, 2010

Re: [Pharo-project] [SPAM] asUrl retrieveContents -> with POST vars

by Sven Van Caekenberghe

Or you could do this, which is a more explicit API, with more object oriented computing going on behind the scenes: ZnHttpClient new url: 'http://localhost:1701/echo/foo'; parameterAt: 'foo' put: 'bar'; parameterAt: 'baz' put: 'bang'; post. Sven PS: For this you need an extra install: Gofer it squeaksource: 'ZincHTTPComponents'; package: 'Zinc-HTTP'; package: 'Zinc-Tests'; load On 17 Dec 2010, at 21:53, sergio_101 wrote: > i know i have done this before, and it's totally escaping me.. > > i am also not sure if this is the place to ask generic smalltalk > questions, so if it's not, please someone let me know.. > > doing something like: > > url := 'http://domain/?var1=one&var2=two" > > url asUrl retrieveContents contents. > > BUT! > > i would like to send the vars as POST vars. can i do that with retrieveContents? > > thanks! > > -- > ---- > peace, > sergio > photographer, journalist, visionary > > http://www.ThoseOptimizeGuys.com > http://www.CodingForHire.com > http://www.coffee-black.com > http://www.painlessfrugality.com > http://www.twitter.com/sergio_101 > http://www.facebook.com/sergio101 >

Dec. 21, 2010