Squeak-dev April 2006

squeak-dev@lists.squeakfoundation.org

177 participants
262 discussions

RE: Fun with Number readFrom: What should we do ?
by Ramon Leon 28 Apr '06

28 Apr '06

> > Just to say that squeak learners (we all, and that includes > newbies) can learn a lot from this kind of discussions. > > Nicolas > > Le Jeudi 27 Avril 2006 21:41, stéphane ducasse a écrit : > > Just to say that I really enjoy reading this discussion. > > Please continue and conclude with some enh, fix and tests. > Excellent! > > Yes, everyone can learn a lot, I like seeing these things hashed out publicly as well because you get a peek at the thought processes of various people and can learn quite a bit about style from such interchanges. -- Ramon Leon

1 0

Fw: Fun with Number readFrom: What should we do ?
by Chris Muller 27 Apr '06

27 Apr '06

> Maybe a new exception class is better than Error, but i do not take this responsability alone. [value1 := Number readfrom: aStream. value2 := Number readFrom: aStream] on: NumberReadError do: [:exc | global handler block] Hi Nicolas, I just wanted to say I think your reasoning is compelling and I see nothing wrong with creating a new Error subclass if its really needed. A lot better than resorting to looking at the messageText in the handler! You might consider a slightly more generic error, like ParseError or something.. Regards, Chris

1 0

[ANN] some news about the next exciting ESUG conference
by stéphane ducasse 27 Apr '06

27 Apr '06

Hi all I want to let you know some news about the future program of the next ESUG conference that will be held at Prague: http://www.esug.org/conferences/ 14thinternationalsmalltalkconference2006/ Joe Armstrong, the inventor of Erlang which is a Smalltalk fan will be an invited speaker! Here is a preliminary list of talks: - Scaling Smalltalk Web Application Server - Rethink Smalltalk - Gemstone 64 - Ajax and Seaside - Integration of Smalltalk Systems – E.g. ObjectStudio inside VisualWorks - UbiTalk - News From Squeak - Seaside for newbies - Packaging and deploying applications Stay tuned If you were planning to present something, please do not wait the last moment and follow instructions: http://www.esug.org/conferences/ 14thinternationalsmalltalkconference2006/callforpresentations/ Stef Prof. Stéphane DUCASSE [ | ] http://www.iam.unibe.ch/~ducasse/ "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 Open Source Smalltalks: http://www.squeak.org, http://www.gnu.org/ software/smalltalk/smalltalk.html Free books for Universities at http://www.esug.org/sponsoring/ promotionProgram.html Online Free Books at http://www.iam.unibe.ch/~ducasse/WebPages/ FreeBooks.html

3 3

Wiki Spam removal
by Serge Stinckwich 27 Apr '06

27 Apr '06

Hi all, i would like to remove some spam in the Squeak Wiki. I know the passowrd to edit, but some pages seems to be locked like this one : http://minnow.cc.gatech.edu/squeak/741 or http://minnow.cc.gatech.edu/squeak/1088 The last edit of these pages are July 2004 ! -- oooo Dr. Serge Stinckwich OOOOOOOO Université de Caen>CNRS UMR 6072>GREYC>MAD OOESUGOO http://purl.org/net/SergeStinckwich oooooo Smalltalkers do: [:it | All with: Class, (And love: it)] \ / ##

2 1

Socket ping: doesn't work
by Cédrick Béler 27 Apr '06

27 Apr '06

I can't manage to make: Socket ping: '127.0.0.1' or any other local machine... I've removed the proxy... I'm using squeak 3.8-6665 on linux (ubuntu) Do you have any idea ? The thing I find strange is that with any local connection, it even doesnt wait for 10 seconds... I immediatly receive the message 'continue to wait for connection to...' whereas for an extern site, it waits 10 seconds ... Have no idea :( I tried with OldSocket too and had the same problem... Thanks cédrick

2 2

Re: Fun with Number readFrom: What should we do ?
by ncellier＠ifrance.com 27 Apr '06

27 Apr '06

I agree with your example, but not with your words. You don't know whether you can read a double or not in advance. So what you do ? You don't test if you can read a number as a precondition, because that would be the same as duplicating a large part of Number readFrom: code. What you do instead is trial and error. You're trying to read a Number, if it fails you do another thing. Exception are well fitted for that case. What i proposed readFrom:ifFail: is exactly corresponding to trial and error approach Nicolas Martin Wirblat: Nicolas, you are arguing form the premise that some string that is not convertible to a float is a problem, an error or an exception. Consider a csv file. You would read it with upTo: $;. If you get an empty string it does not mean that an error occurred, it means that a piece of information is not applicable or available. That is valid information and not an error! There are csv files with more than 99% of such empty fields. The same holds true for an unformatted text from which information has to be extracted. It is expected that at many places a piece of information may or may not appear. And because it is expected it can't be an exception ;) I think if a string can't be converted to a float almost never an error should be raised. And if so, some very specific reason has to exist, some reason that makes this scenario a real - unforeseeable - error. For me the bottom line of the 'exception thread' was exactly this: an error or an exception is something which is unforeseeable. If you can predict that it may happen or if it regularly happens it should get handled directly. Perhaps even more straight: If *possible* it should be handled directly. Error handlers are reserved for cases where you don't know when or where exactly what may go wrong. Regards, Martin nicolas cellier wrote: > Le Jeudi 27 Avril 2006 12:14, vous avez écrit : > >>nicolas cellier wrote: >>... >> >> >>>What do you vote for ? exception, answering 0, any other idea ? >>>What to do with the stream in case of error ? rewind, keep in place ? >>>I'am waiting for your comments. >> >>Answering nil of course. To answer 0 is outright wrong and raising an >>exception is at least to cumbersome. One could rate it being wrong too, >>because unknown text that has to be converted is a valid input, and thus >>finding no correct float is a valid result - nil. >> >>Regards, >>Martin > > > Hi Martin > Of course, answering nil is an obvious possibility better than answering 0. > I longly used this construction before i discovered exceptions, and i will try > to explain why i have switched to this second preferable style. > > Answering nil is exactly the policy adopted in C programs. > It means that when you write a line of code, you will have 3 lines following > for handling problems. > If you omit this post-checking, your C programs can have weird behaviours like > dumping a core later when uninitialzed values will be used... > > The FORTRAN way was better (i think of the READ() instruction): > - default was to abort the program with an error message (brutal but clean) > - it was possible to pass a label to branch on in case of error (an early > exception handling mechanism). > > In Smalltalk, we have those nice soft aborption with debugger, better than a > core dumped, but that does not solve everything, and in fact we face the same > choice that C-FORTRAN explained above: > > Suppose we adopt the nil answer. > We will have to check for nil after each readFrom: instruction. > If we lazily omit those nil-checking lines, the problem can appear well later > in the code when we will try and use the value, and the debugger will not be > of much use, because it won't point directly at the place where the problem > come from (the C core dumped case)... > > If i have a method with 10 readFrom: , i will have 10 ifNil: blocks for > handling the exception. > Maybe the handling can consist simply in answering nil in our turn and reject > the problem to the sender method, wich will have to check ifNil: in its turn > und so weiter... > What i dislike in this C-style is that it makes code less readable because > main algorithm is scattered among exception handling code. > > Suppose now we adopt an exception mechanism. > I am lazy and do not put an exception handling block (working on a prototype). > Then the debugger will open exactly where the problem occured. > I am smarter with the users of my programs and provide an exception handling > block: then i can factor several exceptions in a single block (the case when > i do 10 readFrom:), and i can handle the problem several senders above > without adding noisy ifNil: at each level. > > The problem with exception is that if i trap Error, i will trap too many > errors, not only the readFrom: error. This is not selective enough. This has > already been discussed on the list, when to create a new exception class ? > but i do not have the feeling we got a clear answer... > Untill we address this problem, your ^nil proposition is a candidate though > not my favourite style. Maybe readFrom: can also call readFrom:ifFail: the > way Dictionary at: call at:ifAbsent:. > > Nicolas > > > ________________________________________________________________________ iFRANCE, exprimez-vous ! http://web.ifrance.com

1 0

Re: Fun with Number readFrom: What should we do ?
by ncellier＠ifrance.com 27 Apr '06

27 Apr '06

I agree, my prop was low level, yours is higher level (extensible) Nicolas Diego Fernandez: > My proposition is: > > Number>>readFrom: aStringOrStream > ^self readFrom: aStringOrStream ifFail: [^self error: 'cannot read a > number'] > > If nil is what you want, you will have to write: > value := Number readFrom: aStream ifFail: [nil]. > A little longer than your proposition: > value := Number readfrom: aStream. The mine is: Number>>readFrom: aStringOrStream ^NumberParser new parse: aStringOrStream NumberParser>>parse: aStringOrStream "on failure" NumberParsingException signal "or just ParseException" I think that #readFrom: must be an extension of Number. So if you want more control of the parsing you can configure an instance of NumberParser. (may be you can have a FortranNumberParser :)). ________________________________________________________________________ iFRANCE, exprimez-vous ! http://web.ifrance.com

1 0

Squeak Chat Monday May 1st 12:00 GMT
by Ken Causey 27 Apr '06

27 Apr '06

Just a reminder that the next Squeak Chat will take place between 12:00 (Noon) and 16:00 (4 PM) GMT Monday May 1st, 2006. As usual we will meet in #squeak on irc.freenode.net. More information about the #squeak IRC channel can be found at http://people.squeakfoundation.org/article/7.html This is a good time to contribute to the development of Squeak by participating in the Harvesting Process. One of the main ways to contribute is by Reviewing submitted fixes and enhancements. For information about the Harvesting Process see http://minnow.cc.gatech.edu/squeak/3152 If you have the time please attend and work toward the future of Squeak. The next seven chats are scheduled for 16:00 (04:00 PM) GMT Friday May 05, 2006 20:00 (08:00 PM) GMT Tuesday May 09, 2006 00:00 (12:00 AM) GMT Sunday May 14, 2006 04:00 (04:00 AM) GMT Thursday May 18, 2006 08:00 (08:00 AM) GMT Monday May 22, 2006 12:00 (12:00 PM) GMT Friday May 26, 2006 16:00 (04:00 PM) GMT Tuesday May 30, 2006

1 0

testing connection - ping
by Cédrick Béler 27 Apr '06

27 Apr '06

Hi I cannot connect to an external database so I tried to ping some hosts and nothing works.. I tried: I'm behind a firewall that I desactivated Socket ping: 'an External host'. returns after some time continue to wait for connection to... Socket ping: 'a local machine'. returns immediately continue to wait for connection to... with or without proxy :s do you where I can have a problem ?... It looks like I cannot connect whereas I have no problem with squeakmap or monticello... Can you help me ? maybe I should try other tests ? Thanks Cédrick

1 0

Google Summer of Code
by Selem Delul 27 Apr '06

27 Apr '06

Hi, Did Squeak Foundation apply for Google Summer of Code 2006 as a mentor organization?

3 2

← Newer
1
2
3
4
5
6
7
8
9
...
27
Older →

Jump to page: