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

Re: [Pharo-project] Fwd: About SPDF

by Sven Van Caekenberghe

On 25 Aug 2010, at 08:22, Torsten Bergmann wrote: > Similar to iText for Java, this allows you change the > license and block your government later ;), see the story > of Bruno Lowagie [1] Don't you just like Belgium and the Belgians ? We're definitively in one of the most absurd and surreal places imaginable. Sven

Aug. 25, 2010

Re: [Pharo-project] String to Number conversion

by Schwab,Wilhelm K

Squeak has a long tradition of silent failures of all types (in the image and the vm), and IMNSHO, it is a **really** bad idea with terrible consequences and needs to be fixed. Default actions that return nil merely push problems down stream to a point where there is no context to figure out what went wrong. I think much of this goes back to the late 70's and early 80's, before structured exception handling, and has never been modernized. Dolphin, which started life in the mid 90's, is built from the ground up to do these things correctly. Once one learns that the exceptions are indeed helping to make things work reliably, it is hard to imagine making something robust without them. Exceptions can be expensive, both to set up handlers, and even more so when exceptions are thrown. You have identified the answer, which is to provide #readFrom:ifFail: (or #readFrom:onError: - whatever you want to call it) that evaluates a block when things go wrong, which allows one to bypass the overhead, much like #at:ifAbsent:; if error and remedy are near by, it is easy to do and skips the overhead. For the lazy<g>, or simply for frameworks that can/should use exceptions to handle exceptional conditions (big separation between the problem and anything that knows how to cope with it), #readFrom: (without the block) does the robust/correct thing, and raises an exception. As you no doubt know, it can (often should) be written in terms of #readFrom:ifFail: with the block raising the exception. Things will break for a while, but I hesitate to think how much stuff is just plain broken and we never notice it because things answer nil and/or ignore error conditions. The industry tried to formalize such head-in-the-sand-hope-it-goes-away design under the fancy name "defensive programming." It remains a useful approach when used sparingly to keep critical systems running, but it generally failed under its own lack of merit. It was popularized as a way to cope with the dreaded UAEs of 16 bit Windows, which was in turn due to the lack of exception handling and ensured execution in the GUI, which lead to incomplete cleanup, memory leaks, and all kinds of crashes. YES. PLEASE DO THIS. **GREAT** IDEA. You might take a look at http://www.squeaksource.com/PharoInbox/DolphinCompatibility-Streams-BillSch… for what I consider to be very much related changes to stream I/O. Since it quickly became obvious to me that #next and #next: were not going to change any time soon, I simply stopped using them myself; instead I write code using #nextOne, #nextMany:, and #nextAvailable:. You will also find methods such as #nextDWORD to help with binary file formats, device interfacing, etc . It is a work in progress, but the idea is to have read streams bark when they run out of data, unless (#nextAvailable:) specifically authorized to truncate. I also have some text converters modeled after Dolphin's framework. I don't think I have released those yet, but plan to do so eventually. Because of the problem you have identified, I have added some tests (and throw exceptions when they fail) for whether the stream is or is not at the end or read an expected number of types, etc. Thanks for working on this! Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito(a)gmail.com] Sent: Tuesday, August 24, 2010 4:33 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] String to Number conversion http://code.google.com/p/pharo/issues/detail?id=2857 Which will be the impact in the system and other tools to throw an error when the conversion cannot take place? I think an error must be thrown, but should it be in Pharo 1.2 or in next version? On Tue, Aug 24, 2010 at 11:45 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com<mailto:nicolas.cellier.aka.nice@gmail.com>> wrote: In squeak, (Integer readFromString: 'foo') ->Error Use: - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, - (Integer readFrom: 'foo' ifFail: []), to get nil Though it is possible, I dislike anwsering nil, because it would mean a bunch of #readFrom: send should be protected by #ifNil: Blocks... 1) That's nonsense, readFrom:ifFail: already does the work. 2) you cripple the code with Error conditions and end up with unreadable C-looking like code (3 lines of Error condition crap for 1 line of underlying algorithm at every function call) 3) Exception handling can avoid long chains of ifFail: / ifNil: tests But that conversation already took place many times... I'd like the readFrom:ifFail: form to be generalized to other objects, with default behaviour raising an Error. What do you think ? Nicolas 2010/8/24 Johan Brichau <johan(a)inceptive.be<mailto:johan@inceptive.be>>: > > On 24 Aug 2010, at 15:19, StÃ©phane Ducasse wrote: > >> I thought that readFromString: was raising an error and that guessNumber* was returning zero > > I thought that too. I even have application code that shows that this used to return nil in some version of Pharo... > But: > > 'foo' asInteger = nil > Integer readFromString: 'foo' = 0 > 'foo' asNumber -> Error > > aargh :-( > > disclaimer: currently testing this in pharo1.1 > > Johan > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 25, 2010

Re: [Pharo-project] Why is readStream on SequenceableCollection and not on Collection?

by Henrik Johansen

Den 24.08.2010 17:58, skrev Nicolas Cellier: > 2010/8/24 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > >> This cropped up in Dolphin some years back. IIRC, OA's answer was that streams historically worked on only Array and maybe something else. Having said that, they relaxed a constraint because it was harmless and a good idea. >> >> I'm not sure about streaming over a set; lack of order means that it might be tricky to maintain a reasonable position?? >> >> > Exactly, the Stream would hardly be positionable, unless you use a > sort of OrderedSet... > A ReadWriteStream would be problematic for the same reasons. > > What would be the interest of such a Stream ? > (I mean something more than what just you can do with #do:or #add:) > > Nicolas +1. I don't quite see what use could would find in a stream of a non-sequenced source that is not better served by using a different abstraction, or the source itself.. Cheers, Henry

Aug. 25, 2010

[Pharo-project] #hasClassNamed

by Torsten Bergmann

Stef wrote: >well named: means that you expect a name no? When I type and write Object I write down the name of the class Object, dont I? Thats why I'm not sure. I think it is more a philosophical problem... Bye T. -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

Aug. 25, 2010

Re: [Pharo-project] cog vm

by StÃ©phane Ducasse

BTW levente what is your company? Atef On Aug 25, 2010, at 2:05 AM, Levente Uzonyi wrote: > On Tue, 24 Aug 2010, Sven Van Caekenberghe wrote: > >> >> On 24 Aug 2010, at 11:42, Levente Uzonyi wrote: >> >>> These apps use Squeak trunk images (updated regularly, but manually) with Seaside 3.0 (some with Comet), WebClient, SqueakSSL, OSProcess, PostgresV3. >> >> Is PostgresV3 production ready, last time I checked it seemed like it was not ready vs the older PostgresV2. I must have missed its progress (no pun intended). > > We're using it in production for a year now (instead of PostgresV2), so it's production ready from our POV. But it's not ready for others, because it's short on documentation (especially user documentation) and it mostly implements stuff we need(ed). That's why there was no announcement about it yet. > >> >> Is there some writeup about this package somewhere ? >> > > No, there's none, but in short: > The package consists of a 3 "APIs". The lowest level API is the PG3Connection. This works pretty much like PostgresV2, though some method names are different, but if you know how to use PostgresV2, then you will find out in 5 minutes how to use this. A higher level API is the PG3ConnectionPool which implements a simple connection pool. It's fairly easy to use the pool too. In 10 minutes one can set up a pool for a db without docs. The highest level API (in the public repository) is the PG3FunctionClient which allows you to call Postgres functions which return a refcursor. Most of our apps use this API to communicate with the DB. In our private repo we implemented a new high level API, which allows one to edit the Postgres functions in the Browser, fix bugs in the Debugger, version them with Monticello, etc. It also allows one to call "normal" functions which don't return a refcursor. Since the package is getting fat, we are at the point where we have to split it. When we're done with that, we'll push it to the public repo. > So feel free to experiment with it and if you need a feature or found a bug, let us know. > > > Levente > >> Thx, >> >> Sven >> >> >> _______________________________________________ >> 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

Aug. 25, 2010

Re: [Pharo-project] [Pharo-users] funny idea Symbol vs. Selector

by StÃ©phane Ducasse

lol :) I was more thinking that selector could be a subclass of symbol to avoid such problem On Aug 24, 2010, at 11:43 PM, Igor Stasenko wrote: > On 25 August 2010 00:14, Gabriel Brunstein <gaboto(a)gmail.com> wrote: >> Or something like: >> self perform: #myMessage asSelector. >> It would be just one message in Symbol and not all the selector related protocol >> > > Yeah, and then code things like: > > 'foo' asSymbol asSelector > > great idea (pun intended)! > >> you can also leave the current behavior for that message if your >> prefer, in my opinion is not so bad... >> >> >> On Tue, Aug 24, 2010 at 5:27 PM, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> Following this logic, an object should perform: aSelector rather than aSymbol. >>> Thus we should then write (self perform: (#myMessage as: Selector)) in >>> order to keep up with conceptual clarity. >>> Unless of course we alter the # syntax and let it answer a Selector >>> rather than a Symbol ;) >>> Then, we could write (#mySymbol as: Symbol), or just remove class Symbol ;) >>> >>> Seriously ? >>> >>> Nicolas >>> >>> 2010/8/24 Gabriel Brunstein <gaboto(a)gmail.com>: >>>> I like the idea to have a class Selector with all the protocol for >>>> selectors there, so any symbol doesnÂ´t have to understand selectors >>>> messages. >>>> Maybe you don't see short term advanteges of doing that, but I think >>>> that it will give conceptual clarity. >>>> >>>> On Tue, Aug 24, 2010 at 4:27 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>> 2010/8/24 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>>>> >>>>>> >>>>>> 2010/8/24 Mariano Martinez Peck <marianopeck(a)gmail.com> >>>>>>> >>>>>>> >>>>>>> On Tue, Aug 24, 2010 at 2:58 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>>>>> >>>>>>>> On 23 August 2010 23:26, stephane ducasse <stephane.ducasse(a)free.fr> >>>>>>>> wrote: >>>>>>>>> Hi guys >>>>>>>>> >>>>>>>>> I'm thinking aloud... >>>>>>>>> I was wondering if we could not take advantage of a new class: >>>>>>>>> Selector. >>>>>>>>> MethodDict would only contain selectors and not symbols. >>>>>>>>> >>>>>>>>> I remember that I talked about that with hernan. >>>>>>>>> >>>>>>>> >>>>>>>> Hmm.. i don't see obvious advantages. Do you? >>>>>>>> Most symbols (90% of cases), used as selectors, so it is likely that >>>>>>>> such refactoring will be nothing more, >>>>>>>> but just renaming the class :) >>>>>> >>>>>> Personally I find it slightly annoying. Symbols are only used as selectors >>>>>> by convention, and the VM has placed no restriction on what objects can be >>>>>> used as selectors so that, e.g. when aggressively shrinking one can replace >>>>>> Symbols with SmallIntegers. Introducing a Selector class would obscure this >>>>>> possibility even more. However I find use of the term "symbol" where >>>>>> "selector" is meant even more annoying. I *hate* methodSymbol in >>>>>> MethodReference. It should be selector. >>>>>> 2Â¢ >>>>> >>>>> You're right, any object could be used as a selector, placed into >>>>> corresponding method dictionary, >>>>> but in practice syntax and compiler implies, that only symbols could >>>>> be used as selectors. >>>>> >>>>> Selector is just a _role_ , and really, VM doesn't puts too much >>>>> restrictions on it (thanks to everyone's most liked deity). >>>>> In contrast, a Symbol, is a class, and instances of it can play >>>>> multiple roles, including being selector. >>>>> >>>>>> Eliot >>>>>> >>>>>>> >>>>>>> Maybe because there are things implemented in Symbol or similar that are >>>>>>> responsabilities of a Selector? >>>>>>> >>>>>>> I have no idea. But I did a quick search and methods like flushCache, >>>>>>> numArgs:,value:, isKeyword, cull:, etc, seems more from Selector >>>>>>> >>>>>>> Cheers >>>>>>> >>>>>>> mariano >>>>>>> >>>>>>>> >>>>>>>>> Stef >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Pharo-users mailing list >>>>>>>>> Pharo-users(a)lists.gforge.inria.fr >>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, >>>>>>>> Igor Stasenko AKA sig. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-users mailing list >>>>>>>> Pharo-users(a)lists.gforge.inria.fr >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 25, 2010

Re: [Pharo-project] #hasClassNamed

by StÃ©phane Ducasse

On Aug 25, 2010, at 9:43 AM, Torsten Bergmann wrote: > Dont know if this is something we should fix: > > Smalltalk hasClassNamed: 'Object' -> true > Smalltalk hasClassNamed: #Object -> true > > but > Smalltalk hasClassNamed: Object -> false > > Last one may be confusing and could be solved > by adding an additional #asString so it returns true too. well named: means that you expect a name no? Stef > > Bye > T. > -- > Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! > Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 25, 2010

[Pharo-project] Philippe's WebClient patches

by StÃ©phane Ducasse

Hi guys Philippe sent me these patches that apparently did not get into the webclient trunk. I will integrate them later with our fork since it does not seem possible otherwise. Stef > Anyway here are my patches. > > > Cheers > Philippe >

Aug. 25, 2010

[Pharo-project] #hasClassNamed

by Torsten Bergmann

Dont know if this is something we should fix: Smalltalk hasClassNamed: 'Object' -> true Smalltalk hasClassNamed: #Object -> true but Smalltalk hasClassNamed: Object -> false Last one may be confusing and could be solved by adding an additional #asString so it returns true too. Bye T. -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

Aug. 25, 2010

Re: [Pharo-project] Why String>>adaptToNumber: rcvr andSend: selector

by StÃ©phane Ducasse

:) I accept code. We are in unstable so this is the time to shake the system. On Aug 24, 2010, at 10:17 PM, Nicolas Cellier wrote: > Noooo, we dooon't want to. > > Nicolas > > 2010/8/24 Guillermo Polito <guillermopolito(a)gmail.com>: >> Do we reeeeeally want to do >> >> 5 + '4' >> >> 5 + 'hello' >> >> ? >> >> _______________________________________________ >> 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

Aug. 25, 2010