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

Re: [Pharo-project] Meanwhile, at another vm

by StÃ©phane Ducasse

On Apr 13, 2011, at 3:40 PM, Philippe Marschall wrote: > On 04/13/2011 02:57 PM, StÃ©phane Ducasse wrote: >> still this can always be interesting to learn your limit and dependencies. > > Sure, didn't make any judgments in any way. Just said I see some > problems on the road. That I'm convinced :) > > Cheers > Philippe > >

April 14, 2011

Re: [Pharo-project] Pharo Open Source Smalltalk â Contributors

by StÃ©phane Ducasse

Yes we need more faces under the mail addresses :) Stef On Apr 13, 2011, at 8:18 PM, laurent laffont wrote: > Added ! > > Laurent. > > On Wed, Apr 13, 2011 at 6:45 PM, Juan Vuletich <juan(a)jvuletich.org> wrote: > Hi Laurent, > > I'd like to be added to http://www.pharo-project.org/community/contributors . My picture is attached. Description text could be "Contributed the default anti-aliased fonts and the SimpleMorphic UI framework. Web page at www.jvuletich.org". > > Thank you. > > Cheers, > Juan Vuletich >

April 14, 2011

Re: [Pharo-project] Document on UIBuilder Tool

by StÃ©phane Ducasse

On Apr 13, 2011, at 8:02 PM, sourav roy wrote: > Hi all, > > Can any suggest me some documents on- > 1.UIBuilder Tool there is the one of nullPointer > 2.UI/Morph Class UITheme allExamples > 3.Database Connection Programming using Pharo. look at SqueakDBX BDXTalk > > Thanks&Regards, > Sourav Roy > Bangalore-India > > > > Get Yourself a cool, short @in.com Email ID now!

April 14, 2011

Re: [Pharo-project] new transcript :(

by StÃ©phane Ducasse

On Apr 14, 2011, at 9:31 AM, Fernando Olivero wrote: > Read only form, that's displayed surrounded by a system window. > Evaluate: Transcript clear. > I worked on some of the complaints, mainly by Igor on the previous email. > Maybe i should also make the TranscriptMorph to use a standard text > widget again. yes because this one looks like a regression. This is not clear that this is a readonly text that we cannot even select. > pd: please take a look at this issue: > ISSUE 3948: > I've replaced the Transcript class with an equal TranscriptModel > instance, reverting to the use of a global Transcript, according to > Igors suggestion. > I also modified a bit the TranscriptMorph, to denote the read-only > nature of the text. (Igor suggested to be able to select the text as > well, not yet there); and changed all the uses ( in Core) to go > through StandardToolSet openTranscript. ok I will Stef > > > On Wed, Apr 13, 2011 at 5:18 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> hi guys >> >> why there is no scrollbar on the widgets? >> why I cannot select text there? >> why I cannot delete text there? >> >> Stef >> >> >

April 14, 2011

Re: [Pharo-project] new transcript :(

by Fernando Olivero

Read only form, that's displayed surrounded by a system window. Evaluate: Transcript clear. I worked on some of the complaints, mainly by Igor on the previous email. Maybe i should also make the TranscriptMorph to use a standard text widget again. pd: please take a look at this issue: ISSUE 3948: I've replaced the Transcript class with an equal TranscriptModel instance, reverting to the use of a global Transcript, according to Igors suggestion. I also modified a bit the TranscriptMorph, to denote the read-only nature of the text. (Igor suggested to be able to select the text as well, not yet there); and changed all the uses ( in Core) to go through StandardToolSet openTranscript. On Wed, Apr 13, 2011 at 5:18 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > hi guys > > why there is no scrollbar on the widgets? > why I cannot select text there? > why I cannot delete text there? > > Stef > >

April 14, 2011

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

by Daniel Lyons

On Apr 13, 2011, at 5:00 PM, Dale Henrichs wrote: > To say that "if one were to handle the KeyNotFoundException, they will need the complete context", I prefer to say "Until one needs the complete context of the KeyNotFoundException, don't bother creating class" I hope (as an outsider) that this advice is taken seriously during this important refactoring effort. Designing the hierarchy is very much a what-color-should-the-bike-shed-be question. Usually the way it plays out on in day-to-day use is not gratitude towards the benevolent API designer for having provided such precise and helpful exception classes or rage towards the careless API designer for making them so unhelpful. No, In my experience it is much more likely to be, swearing at the API designer for having made exception handling an important (but substantially less discoverable) part of the API that must be mastered alongside the ordinary message protocol. A lesson from Java is that if you provide a rich, complex exception hierarchy with lots of specific exceptions, people will feel like they should be using them, even if they're never used in the system, poorly defined, or represent too broad a category (I'm looking at you, IllegalStateException!) â Daniel Lyons

April 14, 2011

Re: [Pharo-project] PostgresSQL - ODBC

by Schwab,Wilhelm K

You didn't miss anything that I can see - just passing along something I wish I had found in writing a few hours ago =:0 I was motivated to get ODBC working specifically because it has worked well for me too. At least in the version of ODBCLibrary that I am using, there is some room to grow with respect to discarding old objects on session start, and I continue to think we need (perhaps optional) logging to failures to load, failures to open ports, etc. Any time the vm translates something that we pass to it (name into path to library, port name into number or vice versa), there should be a way to log it w/o having to recompile the vm. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Benoit St-Jean [bstjean(a)yahoo.com] Sent: Wednesday, April 13, 2011 7:07 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] PostgresSQL - ODBC I missed the start of the thread but I've been using PostgreSQL and Pharo for quite a while on Windows XP (both PostgreSQL & Pharo). So far, Pharo is rock-solid with ODBC, at least on WinXP ! ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) ________________________________ From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: "Pharo-project(a)lists.gforge.inria.fr" <Pharo-project(a)lists.gforge.inria.fr> Sent: Wed, April 13, 2011 7:00:13 PM Subject: [Pharo-project] PostgresSQL - ODBC Hello all, I have been successful in using unixODBC and a Postgres driver to communicate with what I believe is an encrypting server (at least according to pgadmin). I did lots of things, such as building the driver from source, that might have been critical, but I strongly suspect that the key to success was simply using ServerName in place of Server in .odbc.ini. FWIW. Bill

April 13, 2011

Re: [Pharo-project] PostgresSQL - ODBC

by Benoit St-Jean

I missed the start of the thread but I've been using PostgreSQL and Pharo for quite a while on Windows XP (both PostgreSQL & Pharo). So far, Pharo is rock-solid with ODBC, at least on WinXP ! ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) ________________________________ From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: "Pharo-project(a)lists.gforge.inria.fr" <Pharo-project(a)lists.gforge.inria.fr> Sent: Wed, April 13, 2011 7:00:13 PM Subject: [Pharo-project] PostgresSQL - ODBC Hello all, I have been successful in using unixODBC and a Postgres driver to communicate with what I believe is an encrypting server (at least according to pgadmin). I did lots of things, such as building the driver from source, that might have been critical, but I strongly suspect that the key to success was simply using ServerName in place of Server in .odbc.ini. FWIW. Bill

April 13, 2011

[Pharo-project] PostgresSQL - ODBC

by Schwab,Wilhelm K

Hello all, I have been successful in using unixODBC and a Postgres driver to communicate with what I believe is an encrypting server (at least according to pgadmin). I did lots of things, such as building the driver from source, that might have been critical, but I strongly suspect that the key to success was simply using ServerName in place of Server in .odbc.ini. FWIW. Bill

April 13, 2011

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

by Dale Henrichs

On 04/13/2011 02:58 PM, Toon Verwaest wrote: > Is it such a problem if you duplicate a certain exception class? At the > moment you'll do the same anyway by not completely writing the exact > same symbol. It's a simple matter of namespaces and volume of names ... with a large open ended namespace you are more likely to have a number of redundant names with slight differences in spelling showing up in different spots in the hierarchy...with a logically segmented namespace each segment will have a manageable number of names and the risk of duplication is reduced ... end of discussion ... 10,000 names vs 30 names ... I can easily recognize duplicates in a list of 30 names ... not so easy in 10,000 ... that is all ... to attempt to map every possible error condition onto a class will lead you to 10,000 much quicker than using reasonCodes ... that is all ... I don't hate classes, it is a _practical_ matter ... if _you_ would rather manage 10,000 names then I will say that it isn't practical ... I'm _not_ saying it is _wrong_, just not _practical_. > > And if the problem is not finding classes anymore, maybe we need a > better way of organizing the exception classes away from the standard > classes so that they are as non-intrusive as symbols, but convey more > information? And now you've hit the nail on the head ... in order to handle the extra complexity you need additional tools ... before creating more tools, ask your self the simple question: "Do I _need_ the additional complexity?" ... if the answer is yes, then create the tool, if the answer is no, then you don't need to create a new tool .. Again, this is a _practical_ matter... > > self error: #keyNotFound > does not really give much information; and isn't much more difficult to > write than: > KeyNotFoundException new in: self; key: key; signal From a practical perspective how many exception handlers will be written to handle KeyNotFoundException ... I use at:ifAbsent: when I'm doing a look up that I think might fail ... better than writing an exception handler ... If there is a real need to write a handler for KeyNotFoundException, then by all means create the class, but until you actually NEED KeyNotFoundException, `self error: #keyNotFound` or `NotFoundException signal: #keyNotFound` will work just fine... > > although the second one gives you all the contextual information that > the first one misses. _If_ you NEED the additional contextual information. It's just like writing a framework that no uses ... there's nothing wrong with the idea or the implementation, it's just that the framework didn't solve a problem that anyone had... If you are going to create a class, I think the least it should do is address an real problem, not an imaginary one. To say that "if one were to handle the KeyNotFoundException, they will need the complete context", I prefer to say "Until one needs the complete context of the KeyNotFoundException, don't bother creating class" > > What I mean mostly: what about trying to figure out why you want to > avoid decent exception classes and tackling that problem? Depends upon what your definition of a decent exception classes is? My argument is simply that it is not _necessary_ to create a unique class for every unique error condition ... I think that folks should answer the question: "Will anyone every write an exception handler for this exception" before creating the class ... if the answer is yes (or better yet, I am writing code right now and need that exception) then by all means create the class. > Maybe we don't want classes but exception objects that can pool data > together? Maybe a very silly idea: what about just exception "classes" > that have dictionaries to store enough information? That would be another way of doing things ... although using exception classes and reasonCodes is pretty close to all that is needed... I agree with the notion that it isn't that useful to have a single Error class and have all errors mapped to it ... on the other hand I don't think it is particularly useful to have an exception class for every possible error condition ... the compromise is to provide a smallish hierarchy of excpetion classes with fairly general structure, provide a means for uniquely identifying every possible error condition (I think that is important) and then add new classes to the hierarchy when a demand for the class is found ...

April 13, 2011