Squeak-dev March 1999

squeak-dev@lists.squeakfoundation.org

153 participants
338 discussions

released: new streams framework 1g1
by Craig Latta 26 Mar '99

26 Mar '99

Hi-- I've made a release of my new streams framework. It eliminates a lot of redundant and twisty code, and does better buffering. The correspondents framework uses it. It's at http://www.netjam.org/self/projects/smalltalk/sources/streaming1g1.zip. thanks, -C -- Craig Latta composer and computer scientist craig.latta(a)netjam.org www.netjam.org latta(a)interval.com Smalltalkers do: [:it | All with: Class, (And love: it)]

1 0

released: exception-handling framework 1g2
by Craig Latta 26 Mar '99

26 Mar '99

Hi-- I've made a new release of my exception-handling framework. It incorporates a couple of bug fixes (thanks to Vassili Bykov and Andreas Raab), printing support (thanks to Stephen Pope) and ANSI support (thanks to Vassili). One of the bug fixes is of general interest: the Squeak 2.3 VM didn't properly handle returning from a context with a nil sender between it and the home context. That broke >>valueEnsuring: with deferred non-local returns. It's at http://www.netjam.org/self/projects/smalltalk/exceptionHandling.html. thanks, -C -- Craig Latta composer and computer scientist craig.latta(a)netjam.org www.netjam.org latta(a)interval.com Smalltalkers do: [:it | All with: Class, (And love: it)]

1 0

Re: Multilingual Squeak
by ohshima＠is.titech.ac.jp 26 Mar '99

26 Mar '99

Thank you for summarising. > It has been suggested that, as well as providing facilities to display and > handle strings in differing languages and scripts, a programmer should be > able to program in those langagues and scripts, ie a Chinese programmer > should not be forced to program in English, but should be able to program > in Chinese. I think 'programming in English (or Chinese)' is somewhat misleading. We write programs in Smalltalk, which is defined in English terminology. > Some objections have been raised: > > (1) This will lead to either (a) a mixed language image, which will be hard > to read and maintain, or (b) several, incompatible, single-language > versions of Squeak. By observing what have been happening on mule-lisp programming, I don't worry this so much. When a person wanted to distribute his/her program world-wide, he/she wrote the program in ASCII. Some very private or domestic program uses other 'scripts'. A good design is to relieve the obstacles for doing this as possible. But any kind of systematic keyword-to-keyword translation doesn't make sense. OHSHIMA Yoshiki Dept. of Mathematical and Computing Sciences Tokyo Institute of Technology

1 0

Re: Multilingual Squeak
by Joachim Durchholz 25 Mar '99

25 Mar '99

Mark Wai wrote: > > At 07:43 PM 3/23/99 +0100, Joachim wrote: > > >However, there are serious problems. > > > >First of all, it isn't much use to translate the standard classes. If > >Collection were translated to Ansammlung, then I won't be able to use > >any code that uses Collection objects, and you won't be able to use > >my code that says Ansammlung. > > I disagreed. Not if your entire Smalltalk base classes are written in > a *single* language. What use is it to allow writing German code if the base classes are still in English? How do you reuse my (German) classes in your (Chinese) systems? These are the questions that must be addressed. > I don't see why you would want to create a class (say > OrderedCollection) in English, then create a >>add: method in Dutch, > create another method >>addLast: in Chinese and create another method > >>removeFirst: in Russian. Nor do I. I'm talking about mixed languages at the system level, not mixed languages within a class (which is easy to avoid). > >This could be overcome by giving each class several names, one for > >each language. But such a list would never be complete, and you'll > >get into real trouble once several people start translating stuff > >independently of each other. > > I don't know how I could best answer (I have too much to say for this > one) you this but I don't see this as problem at all. Now you're being unfair. I have no chance to answer here. > >Third, there are characters that are different but look the same. > >This is particularly true for stuff in cyrillic scripts, such as > >Russian. A cyrillic a looks exactly as its latin equivalent, yet it > >has a different code. I just imagine Russians writing English code > >and accidentally dropping a cyrillic A in an otherwise latin > >identifier - the compiler will complain and nobody will be able to > >*see* the problem. > > No problem. This could be resolved if the VM, compiler and various > system classes support 2 bytes character encoding. This does *not* resolve the problem. In fact Unicode (which *is* a 2-byte encoding if I'm not totally mistaken) creates the problem in the first place. It's like having the same A glyph both for code 65 and for 165; you'll never know whether the A you're looking at is the same as the code-165 A somewhere else. > >In all, I think it's best to draw a distinction between source code > >(which has always been English, and should remain so) and display > >text (which should be translateable, so Unicode is an excellent idea > >*there*). > > I respect your opinion but I think the total opposite. English has > been, and will be the dominant force in programming level for any > forseeable future, I have no problem with that. I just think that > non-English programmers deserve a chance to express their programming > ideas natively in a beautiful environment like Smalltalk. I agree that they should be able to have that chance. But life isn't fair. > Pre-mature conclusion and always follow the given can only lead to > missed opportunities to make this a better world. I don't think my conclusions are premature. I have seen several tries at this one. Apple Computer translated the keywords of a scripting language, as did Microsoft. Both failed miserably; the experiment was cancelled almost instantly once it hit the street (i.e. within a year's notice). The problems were the same in both cases: 1) The effort required to translate any new code to all the languages in the world proved too great. (How far has your Chinese translation come? Are you prepared to keep translating for the rest of your life? Do you have a chance to keep up with the speed at which new software is appearing? Do you see all the volunteers required to translate Squeak into all the other languages? Translation requires an organized effort, to ensure at least a little consistency; it's drudgery to keep the terminology consistent; do you see the capable project leaders for each language? I don't. I have been a technical translator for three years, leading and doing several translation projects of various sizes. Believe me, there is nothing more boring (and thus error-prone) than translating heaps of technical stuff, be it source code or manuals. And in a community of volunteers, Boring = Will Not Be Done.) 2) Interoperability problems. Code written in the German dialect didn't run in the US, and vice versa. I foresee the same problem for Squeak. Regards, Joachim -- Please don't send unsolicited ads.

2 2

Limitations on C code generation?
by Jerome.Garcia＠wj.com 25 Mar '99

25 Mar '99

A while back someone described some limitations in the generation of C code from Squeak code using CCodeGenerator. Could someone please point me at a description of those limitations or provide one. Thanks in advance. Jerome E. Garcia

1 0

Refactoring for options (Was: Messaging vs. Methoding)
by agree＠carltonfields.com 25 Mar '99

25 Mar '99

I substantially agree (after all, I am agree(a)carltonfields.com!) with Doug's remarks. I think that a purely mechanical means of implementing optional keywords so that from the programmer's point of view, it would be fully functional without any change whatsoever being necessary with regard the VM/messaging semantics. I particularly like Doug's suggestion that the class of extended messages be displayed with a single line in the browser. It seems like a minimal impact solution would be a fun task. After steve pair's remarks, I have been thinking about the general case for refactoring in the absence of the modification, and there is at least one straightforward pattern solution: Given "extended" message pattern for message A in class Foo req1: rp1 req2: rp2 opt1: [op1 := d1] opt2: [op2 := d2] Refactor as follows: In Foo, put the messages: req1: rp1 req2: rp2 opt1: op1 opt2: op2 "central code for the process" and optWithReq1: rp1 req2: rp2 ^FooOpt obj: self req1: rp1 req2: rp2 Then create Class FooOpt with instance variables: obj rp1 rp2 op1 op2 with setters for op1 and op2, of the form: FooOpt>>op1: aValue op1 := value ^self "important -- see doit!" FooOpt class will have a instance creation method FooOpt>>obj: obj req1: rp1 req2: rp2 which sets obj, rp1 and rp2, returning a fooOpt, and also setting op1 and op2 to d1 and d2, respectively. Then, add message "doit" or the like to FooOpt, along the lines of: FooOpt>>doit ^obj req1: rp1 req2: rp2 opt1: op1 opt2: op2 Of course, this can be aesthetically tuned to suit, and works well when there are a multiplicity of "ultimate" operations for the required object combination. The syntax: (foo optWithReq1: rp1 req2: rp2) opt1: nondefault1 doit Seems to me more workable than the approach taken by Steve, where the express creation of the option object with a "yourself" at the end seemed to me awkward. This works particularly nicely where there are a hunk of "doit" operations, as in the RePlugin materials. Thus, we could have: aString reMatch: pattern for the simple case, and (aString reWithPattern: pattern) opt: 'imsl'; from: 10; to: 20; collect: [:m | m match ] for the more complex cases. I still prefer the "simpler" optional parm syntax of Python, but that ain't Smalltalk Squeak (yet!). Andy (werdna(a)gate.net, when not at work). -----Original Message----- From: MIME :dway@mat.net Sent: Thursday, March 25, 1999 1:05 AM To: squeak(a)cs.uiuc.edu Subject: Re: Messaging vs. Methoding On Tue, 23 Mar 1999, Allen Wirfs-Brock wrote: > Brian Wilkerson once developed an interesting proposal for extending the > message pattern with optional keywords and a variable numbers of > repeated keywords. You can find his proposal at > http://www.smalltalksystems.com/publications/varargs.pdf A year or so ago I thought about what adding optional keyword messages to Smalltalk would be like and how it would work... Brian's proposal is pretty much in line with what I was thinking.

1 0

[Q] Why is JPG reading is so SLOW ?
by Ninja 25 Mar '99

25 Mar '99

I'm newbie in squeak and just learned how to use file list. And I tried to open JPEG file with open image in window(?) like menu command, but it takes much time to display image. That file is open less than 0.1sec in xv or gimp like program. Why so slow ? And can I make it faster ? I'm newbie in both smalltalk and squeak. but knows some programming issues. Thanks in advance.

2 1

Re: sf2 reader
by johnm＠wdi.disney.com 25 Mar '99

25 Mar '99

Luciano Notarfrancesco <luciano(a)core-sdi.com> wrote: > Is there a SoundFont 2.0 reader for Squeak? Or is anybody working on it? Not that I know of. There is an AIFF file reader that can read some loop point information, so if you had a shareware SoundFont to AIFF converter, you might be be able to use that to get sound data into Squeak. Is the SoundFont file spec documented somewhere? Are you planning to implement a reader? -- John

2 1

Re: [VM] NCM performance report
by Dan Ingalls 25 Mar '99

25 Mar '99

Tim - >This costs one extra word/oop over the old design, >plus the compactheader for the bytecode object; total 8 bytes extra per >CM, or <36k for Dan's mini image example. My apologies for saying 73k. I was remembering another scheme. 36k isn't bad for a significant cleanup. I think it's just a matter of when we want to bring this baby in to dry dock (ie major version change) to clean off some of these barnacles. Besides NCM and possibly compact classes, there is also the split instance-size format field, and declaring a format code proper to contexts. I hope we could manage all of these some time in the summer. We're pretty much wedged for the next couple of months, though. - Dan

1 0

bad URL (was: Multilingual Squeak)
by jecel＠lsi.usp.br 25 Mar '99

25 Mar '99

I typed in the URL in my last message wrong. It should have been: http://www.lsi.usp.br/~jecel/tech.html Sorry, -- Jecel

1 0

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

Jump to page: