Squeak-dev January 2001

squeak-dev@lists.squeakfoundation.org

112 participants
318 discussions

Professor seeking sabbatical niche
by Andrew P. Black 02 Jan '01

02 Jan '01

I hope that this is not an inappropriate request to place on this list -- if it is, please flame me privately ;-) I'm a professor at the Oregon Graduate Institute, and my interest in Squeak has been growing steadily as I do more and more with it. But there is no Squeak "community" here at OGI. I have a sabbatical coming up next academic year (October 2001 onwards), and I would like to spend some part of it doing something that deepens my knowledge of Squeak, and hopefully contributes to the Squeak environment. Oh--and is fun! Most likely, this would be some not-for-profit activity, perhaps one that draws on my interests in distributed systems, and contributes to the Squeak source pool; for this I would expect to get at least partial salary support from my University. But I would also be interested in doing some commercial O-O development in Squeak, particularly as part of an XP team. See my web page at http://www.cse.ogi.edu/~black for more information about me. If you might be interested in talking further about my participation on your project, please contact me (off the list) mailto:black@cse.ogi.edu Although October seems like a long way off, I do need to make plans fairly quickly with the University. At this point I'm looking for expressions of interest rather than a firm commitment. Andrew

1 0

Re: 2.8 vm for unix, speed of 2.9a
by John Briggs 02 Jan '01

02 Jan '01

On Mon, Jan 01, 2001 at 10:40:50PM -0600, Mark A. Schwenk wrote: > Perhaps you meant, http://www-sor.inria.fr/~piumarta/squeak/Jitter-3.1/. > > -Mark Schwenk > WellThot Inc. > Hi Mark Sorry I shouldn,t post messages on New Year's Day. That is the correct URL, I just misquoted the original post. Regards John

1 0

Re: CharRecog & ALT-?? keys
by Alan Kay 01 Jan '01

01 Jan '01

Kevin -- Don't forget that Nathanial Schaerli did a fantastic recognizer that is much much better than the one in the download. He has promised to put it in 2.9 when it settles down enough. (Nathanial: has it?) Cheers and Happy New Year to All, Alan ----- At 3:03 PM -0500 1/1/01, Kevin Fisher wrote: >Happy new year, one and all! > >Well, I've successfully shrunken a -useful- Morphic image for use on an iPaq. >Success! It's only about 5megs in size, nice and cozy yet still useful. >Tetris & Same Game look pretty nifty on the iPaq. :) I'm putting a small >changeset together specifically for creating Morphic images on iPaqs that I'll >send out soon (it's just a variation on majorShrink). I've found that >unusedClasses and removeAllUnsentMessages tends to remove vital things needed >by Morphic so I had to comment that out. > >Anyway, I want to get the CharRecog stuff working in a convenient way for iPaq >use. Currently, it gets turned on when you do an alt-r in a TextMorph. I'm >trying to think of a convenient way to activate this mode on the iPaq...for >now I think the SystemWindow menu button would be a good place to put it for >starters (does anyone have any other good ideas?). > >However, I can't seem to track down the code that handles alt-whatever >keypresses! Can anyone give me a pointer to where this is handled?

1 0

["BUG"][FIX?]Incorrect Pseudo-Code for #whileTrue:/#whileFalse:?
by Andrew C. Greenberg 01 Jan '01

01 Jan '01

It's possible that I'm just not getting it, but it would appear that the pseudo-code for #whileTrue; and #whileFalse: is incorrect. Even if I were right, it is still the height of pedantry on my part to call this a bug, since the code is never executed due to compiler inlining. Nevertheless, perhaps it would be more aesthetically pleasing to have pseudo-code here that would work if the compiler did not inline loops? The present code in BlockContext is: >whileTrue: aBlock > "Ordinarily compiled in-line, and therefore not overridable. > This is in case the message is sent to other than a literal block. > Evaluate the argument, aBlock, as long as the value of the >receiver is true." > > ^ [self value] whileTrue: [aBlock value] But it would appear to me that this code would infinite loop for so long as these valuations do not result in a walkback. In either case the behavior appears both undefined and incorrect for most BlockContext instances and arguments. Perhaps something like the following would yield the desired result? ^ self value ifTrue: [aBlock value. self whileTrue: aBlock] (and in the case of #whileFalse, use #ifFalse instead).

2 1

Re: ["BUG"][FIX?]Incorrect Pseudo-Code for #whileTrue:/#whileFalse:?
by Bob Arning 01 Jan '01

01 Jan '01

Andrew, On Mon, 1 Jan 2001 13:29:44 -0500 "Andrew C. Greenberg" <werdna(a)mucow.com> wrote: >It's possible that I'm just not getting it, but it would appear that >the pseudo-code for #whileTrue; and #whileFalse: is incorrect. Even >if I were right, it is still the height of pedantry on my part to >call this a bug, since the code is never executed due to compiler >inlining. Actually, it is executed when the receiver is not a literal block. Code such as | b x | x _ 0. b _ [(x _ x + 1) < 10]. b whileTrue: [Transcript show: x printString; cr]. will cause the method in BlockContext to be executed. >Nevertheless, perhaps it would be more aesthetically >pleasing to have pseudo-code here that would work if the compiler did >not inline loops? With one exception, the current code does work. If you disable inlining of #whileTrue: by changing MessageMode>>transformWhile: to transformWhile: encoder ^false then | x | x _ 0. [(x _ x + 1) < 10] whileTrue: [Transcript show: x printString; cr]. will use the code in BlockContext and will run successfully, UNLESS you recompile BlockContext>>whileTrue:, at which point you do encounter the infinite loop. >The present code in BlockContext is: > >>whileTrue: aBlock >> "Ordinarily compiled in-line, and therefore not overridable. >> This is in case the message is sent to other than a literal block. >> Evaluate the argument, aBlock, as long as the value of the >>receiver is true." >> >> ^ [self value] whileTrue: [aBlock value] > >But it would appear to me that this code would infinite loop for so >long as these valuations do not result in a walkback. In either case >the behavior appears both undefined and incorrect for most >BlockContext instances and arguments. Perhaps something like the >following would yield the desired result? > > ^ self value ifTrue: [aBlock value. self whileTrue: aBlock] > >(and in the case of #whileFalse, use #ifFalse instead). Umm... this could eat up memory in a hurry. Add this to BlockContext whileTrueToo: aBlock ^ self value ifTrue: [aBlock value. self whileTrueToo: aBlock] and then evaluate | x | x _ 0. [x = 999 ifTrue: [self halt]. (x _ x + 1) < 1000] whileTrueToo: []. and look at the stack in the debugger. It would seem to me that, absent the optimization of #whileTrue: (at least in #whileTrue: itself), some sort of tail recursion handling would be required and I don't think that would be easy. Cheers, Bob

1 0

Re: String literal at:put: question
by Lex Spoon 01 Jan '01

01 Jan '01

Actually, it's not too hard to create a ReadOnlyString and ReadOnlyArray which have several methods overridden to produce errors. Overriding at: and basicAt: goes an awefully long way. Then, the Parser needs to be updated. I did this once, but it was in an image too divergent from the main Squeak image that it could really be useful. :| (I at least *tried* to make Float's and Characters read-only, too, though I don't remember how far I got!) -Lex Hans-Martin Mosner <hm.mosner(a)cityweb.de> wrote: > Avi Schwartz wrote: > > > Hi, > > > > I am new to Smalltalk and Squeak, so please bear with me... > > Welcome to The Club :-) > > > I am trying to figure out why the result of > > > > 'abcdef' at: 1 put: $x > > > > is $x and not 'xbcdef'. > > That has been the Smalltalk behavior since the dark ages... I presume > the intention is to make it semantically similar to assignment > expressions, whose value is equal to the assigned value. To achieve your > intention, you should evalutae > 'abcdef' > at: 1 put: $x; > yourself > which returns the receiver of the first message expression. > > > Now, to complicate matters even worse for me, according to the book > > 'Smalltalk, Objects, and Design' by Chamond Liu, the result I should > > expect is an exception since a string literal is immutable. > > Squeak does not currently have really immutable objects (with the > exception of SmallIntegers). This is also true for a number of other > Smalltalks. To make your code portable to Smalltalks with immutable > literals, you should write > 'abcdef' copy > at: 1 put: $x; > yourself > It would certainly be a great service to the Squeak community to > implement immutable objects, but I think that this requires quite some > in-depth knowledge of the VM and/or image to do, so this is certainly > not a beginner's project. > > Cheers and happy holidays, > Hans-Martin

3 2

Desired Windows/CE ports? What do you want?
by Ned Konz 01 Jan '01

01 Jan '01

I finally got around to working with the latest Windows/CE code that I could find. The latest source files I've been able to find were called Squeak-pre-2_8-src.zip and were on Andreas' FTP site. On Nov. 17, Yasuhiro KURAHARA <kurahara(a)kobe.hp.com> announced a Squeak 2.8 VM for Windows/CE. I used his diffs, and did some more work to fix problems like hanging at exit and screen damage from the taskbar (this last is not yet finished). I also updated the code to use the newer (>= WinCE OS 2.11) libraries, which include standard library functions that had previously been provided by the Squeak VM support code. I'd be glad to put the results of this work up on my web site, but need to know which platforms to port for. There are a number of supported chips (MIPS, SH3, ARM, Thumb, PPC, x86) and several OS choices (H/PC Pro 2.11, Pocket PC 3.0, Pocket PC 2.11, as I remember). I only have a MIPS device (a NEC MobilePro 770, which is a H/PC Pro 2.11), so can't test very well. If there are any other requests, I'll try (possibly not very soon) to compile for these as well. So what do you want ports for? Tell me CPU type and OS... -- Ned Konz currently: Stanwood, WA email: ned(a)bike-nomad.com homepage: http://bike-nomad.com

2 1

Re: 2.8 vm for unix, speed of 2.9a
by John Briggs 01 Jan '01

01 Jan '01

On Sun, Dec 31, 2000 at 01:24:50PM +0000, Lex Spoon wrote: > silence-squeak(a)nilpotent.org (Faried Nawaz) wrote: > > > > Hello, > > > > The INRIA site has 2.8pre3 -- is that the latest VM for Unix? I keep seeing > > references to 2.8p4 and 2.8p5 but they're neither at the INRIA ftp site nor > > at UIUC. > > > > I think I have 2.8pre5, though the only tar file I immediately find is > 2.8pre4. I remember it taking some hunting to find, and unfortunately I > don't remember the details now. Maybe it was on the ftp site, and not > the web site? Currently ftp.inria.fr seems to be down, so I can't > check. If you get in, look for "INRIA", "Projects", "SOR", "People", > and "Piumarta", though not necessarily in that order. > > Was 2.8 ever officially released? Maybe Ian thinks that 2.7 is the > current release, and that's why finding the 2.8 sources is so difficult. > If 2.8 has been released, someone should email Ian. If it hasn't... > how about we release it? > > > -Lex > Hi Lex For your info the URL for 2.8pre5 source file is: http://www-sor.inria.fr/squeak/Jitter-3.1/ When I compiled this code I had to comment out in the Makefile all the references to the MAC build, otherwise it compiled smoothly on my system. John

1 0

Jump to page: