Squeak-dev October 2000

squeak-dev@lists.squeakfoundation.org

112 participants
424 discussions

Newbie
by Adam Bloom 03 Oct '00

03 Oct '00

Hello, I'm new to this list, and to Squeak, I'm thirteen and started programming in Scheme around four years ago, and now I've started learning Squeak. I've done the first twelve chapters of On to Smalltalk, (using Squeak, and a guide that tells the differences between the two) and I'm planning on doing the rest of them soon. I've also done the tutorials on Morphic that are on the Squeak website, so I know a little about how that works. I'm looking for advice, and even some simple projects that would help me learn more about how it works. Adam _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com.

1 0

Re: ConnectionQueue question???
by Lex Spoon 03 Oct '00

03 Oct '00

Rob Withers <rwithers(a)exobox.com> wrote: > > The code seems OK to me. I suspect you forgot to initialize the network. > > (NetNameResolver initializeNetworkIfFail: [self error: 'network > > initialization failed'].) > > > > Wouldn't it be nice if....this happened on startup. Perhaps there is a > good reason why it isn't, but I don't know what it is. Otherwise, we could > register a start up Class (Socket) and implement #startUp. > > Rob Best of all, IMHO, would be for the VM to do it internally as needed. For robustness, all VM network primitives already need a preamble anyway for checking whether the network has been initialized. All that would be required is modification of that preamble. -Lex

1 0

Re: ARM based Squeak, OSKit, EPOC
by Edward P Luwish 03 Oct '00

03 Oct '00

The problem with the .EXE is when you try to call out to the graphics and file syscalls. Symbian has (or "have" in the UK) provided a console interface and most of libc for quick porting of UNIX-ish code, but the .EXE route was intended specifically for "server engines" that do calculations and data manipulations on behalf of "real" apps constructed in the awful way EPOC expects. There is a way to do things more easily than that, but it still requires removing the static variables (i.e., I don't have to rewrite the interpreter as a C++ program except for a trivial "jacket") which may turn out to be useful for other platforms anyway. Even going directly to the hardware is a problem, if you were thinking that way - besides, I'd like it to work on Tim's Netbook in addition to my S5, so it should be constructed as a more-or-less well-behaved EPOC app. I won't have to worry about fonts, cut-and-paste, keyboard decoding and pen input, either. And, if Tim likes Squeak on the Netbook, it would be easier to convince my wife to let me buy one. Ed Dean_Swan(a)Mitel.COM wrote: > From: Dean Swan@MITEL on 10/03/2000 12:18 PM > > Tim, > > >That sounds pretty good; wish it had been in that state when we needed > >it for the Interval pad work! Note that they support ARM - which might > > > And maybe even the new ARM powered gamboy-thingy. > > I think the OSKit would be substantial overkill for the ARM based > gameboy. All the hardware is custom, so you won't exactly be able > to re-use device drivers, and probably won't want to "pay" for the > extra overhead either. I suspect the same would have been true for > the Interval Pad, unless you were using PC-ish hardware for your > peripherals. > > While on the topic of Squeak on ARMs, I was looking over the dreaded > EPOC32 SDK this weekend, and based on comments you and/or Ed have made, > I'm wondering, why wouldn't you just target the port for an EXE rather > than an APP? EXEs don't have any restrictions regarding writeable > statics, and they run in their own process, which is the case for > nearly every OS I can think of (except EPOC, of course). > > It just seems like EXEs are the most straight-forward way to port > existing code to EPOC. Am I missing something? I'm sure I could be > since the EPOC documentation is "a little" hard to follow. > > I also started looking through the generated code for 'interp.c' to > see if I could find where the static variables declared in it come > from. I'm guessing that class variables and anything in the System > Dictionary would be candidates? > > I was thinking that Squeak on an 18.432 MHz ARM 710 on the S5 would > give a very good idea of how it would perform on the 16.78 MHz > ARM 710T in the new Gameboy. > > -Dean > > Tim Rowledge <tim(a)sumeru.stanford.edu> on 10/02/2000 01:22:10 PM > > Please respond to squeak(a)cs.uiuc.edu > > To: squeak(a)cs.uiuc.edu > cc: (bcc: Dean Swan/Ogd/Mitel) > > Subject: Re: SqueakOnLinuxFramebuffer getStatus. > > Jecel Assumpcao Jr <jecel(a)mail.merlintec.com> is widely believed to have > written: > > > You can borrow drivers from Linux and BSD using the OSKit: > > > > http://www.cs.utah.edu/flux/oskit/index.html > > > That sounds pretty good; wish it had been in that state when we needed > it for the Interval pad work! Note that they support ARM - which might > just make it interesting for something on the compaq handheld. And maybe > even the new ARM powered gamboy-thingy. > > tim > -- > Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim > Strange OpCodes: SDL: Shift Disk Left

1 0

Squeak on MacOS X
by Karl Ramberg 03 Oct '00

03 Oct '00

Wouldn't this be a good time to spread the word to the emerging MacOS X community. Those poor people don't have too much to play with at the moment ( www.xappeal.org/apps/ ) and a free and fun thing as Squeak could live up their desktop... I emailed to the site abow to tell them Squeak is ported (cocoa and soon carbon) to MacOS X but what more can we do ? Karl

2 1

Re: ARM based Squeak, OSKit, EPOC
by Tim Rowledge 03 Oct '00

03 Oct '00

In message <8525696D.005995ED.00(a)kanmta01.software.mitel.com> Dean_Swan(a)Mitel.COM wrote: > I think the OSKit would be substantial overkill for the ARM based > gameboy. All the hardware is custom, so you won't exactly be able > to re-use device drivers, and probably won't want to "pay" for the > extra overhead either. I suspect the same would have been true for > the Interval Pad, unless you were using PC-ish hardware for your > peripherals. Could be, but I suspect that having a working system to examine would have saved a bundle of time. You wouldn't (well maybe you would) beleive how much time was lost to fixing the lowest levels of the monitor, debug comms channels, interrupt handling basics and so on. And as for the socket library we used... sheesh. > > While on the topic of Squeak on ARMs, I was looking over the dreaded > EPOC32 SDK this weekend, and based on comments you and/or Ed have made, > I'm wondering, why wouldn't you just target the port for an EXE rather > than an APP? EXEs don't have any restrictions regarding writeable > statics, and they run in their own process, which is the case for > nearly every OS I can think of (except EPOC, of course). I'm very happily deferring to Ed on this. He has been able to make sense of the EPOC doc and so on. IIRC (Ed, help!) there are problems with communicating to any other software or something like that if you use exe form. > > It just seems like EXEs are the most straight-forward way to port > existing code to EPOC. Am I missing something? I'm sure I could be > since the EPOC documentation is "a little" hard to follow. Tell me about it. Ever tried installing the SDK? The older ones required that you install a particular version of PERL (even if you already had PERL installed) in order to run an install program that was effectively 'cp -R blahblah' ! Oh, and only to particular directories on the c: drive. > > I also started looking through the generated code for 'interp.c' to > see if I could find where the static variables declared in it come > from. I'm guessing that class variables and anything in the System > Dictionary would be candidates? Class variables in ObjectMemory etc are generally constants and the instance variables are generally the statics you see at the top of interp.c. Others can be added via the assorted #declareCVarsIn: methods scattered around the place. I have a theory, never tested, that it would be possible to put them all in a structure of somesort and access them by globals->thingy type statements, which ought to be easy to do at translation time. If the address of 'globals' can be coerced into a register, it might even be faster (on an ARM, and who could possibly care about any other:-) than straight global access. I think it would also ease code sharing among mulitple VMs running at once, since each could have a separate globals struct. Of course, any decent OS should do that for you anyway. > > I was thinking that Squeak on an 18.432 MHz ARM 710 on the S5 would > give a very good idea of how it would perform on the 16.78 MHz > ARM 710T in the new Gameboy. Extremely good would be my suspicion. And as Jecel pointed out, a 33-ish 486 would be about the same. But I still want my quad processor SA-2 (whoops, XScale) running at 1+GHz... tim -- Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- One bird short of a flock.

1 0

Re: SqueakOnLinuxFramebuffer getStatus.
by Jecel Assumpcao Jr 03 Oct '00

03 Oct '00

On Tue, 03 Oct 2000, Aaron J Reichow wrote: > You'd still have to write a kernel, No - the Squeak virtual machine *is* the kernel. See Squeak on DOS for an example. You do need some interrupt handlers, but that is it. > TCP/IP stack, The OSKit includes this, though I have no idea how easy it is to use it. > and a file system. Squeak includes an abstract file system already. See the second Tektronix chapter in the green book ("Smalltalk-80: Bits of History, Words of Advice", Addison-Wesley, 1983, ISBN 0-201-11669-3, edited by Glenn Krasner) to see how much work is required to write the needed concrete classes. -- Jecel

1 0

Re: ARM based Squeak, OSKit, EPOC
by Jecel Assumpcao Jr 03 Oct '00

03 Oct '00

Dean, > I was thinking that Squeak on an 18.432 MHz ARM 710 on the S5 would > give a very good idea of how it would perform on the 16.78 MHz > ARM 710T in the new Gameboy. Running Squeak on a 33 MHz 486 should also give you a good feel for how it would perform on these machines. And you are right about the OSKit not being worth it for non-PC computers. -- Jecel

1 0

Re: ConnectionQueue question???
by Rob Withers 03 Oct '00

03 Oct '00

Johan Fabry wrote: > jchludzinski(a)worldkey.net wrote: > > > I create an instance of ConnectionQueue to listen on a specified > > portNumber (hardwiring the queueLength to be 4). When I try to > > connect to this instance > > > > (using an instance of Socket: > > > > socket _ Socket newTCP. > > socket connectTo: (NetNameResolver localHostAddress) port: 54321. > > socket waitForConnectionUntil: Socket standardDeadline.) > > > > nothing shows up in 'connection' (an instance of > > OrderedCollection). As a consequence, 'getConnectionOrNil' returns > > 'nil'. > > > > Obviously I'm doing something wrong, any suggestions??? > > The code seems OK to me. I suspect you forgot to initialize the network. > (NetNameResolver initializeNetworkIfFail: [self error: 'network > initialization failed'].) > Wouldn't it be nice if....this happened on startup. Perhaps there is a good reason why it isn't, but I don't know what it is. Otherwise, we could register a start up Class (Socket) and implement #startUp. Rob > > -- > "You are more than the sum Johan Fabry - Johan.Fabry(a)vub.ac.be > of what you consume. Vrije Universiteit Brussel > Desire is not an occupation." Programming Technology Lab, Room 10F709 > -- KMFDM Pleinlaan 2, 1050 Brussels, Belgium

2 1

[updates] 14 for 2.9alpha
by Dan Ingalls 03 Oct '00

03 Oct '00

Folks - Herewith another 14 updates. Many small fixes and enhancements. Included are 5 Celeste goodies from the summer, as approved by Daniel Vainsencher and Mike Rutenberg. Update #2756 is dedicated to Ned Konz and his AttachmentMorph project. Enjoy - Dan ----------------------------- 2749ColorPickerTrackColorAt 2750saveTheSource-raa -- Bob Arning -- 30 September 2000 - restore code that was lost for a while to preserve the source for CompiledMethods exported in an ImageSegment where the sourcePointer had been set. Otherwise, the receiving system may get real confused as to the source for that method." 2751fixUncovered-raa -- Bob Arning -- 1 October 2000 - a bit of a hack to squelch those 'Error: this collection is empty' that TextMorphs seem to produce from time to time when asked #uncoveredAt:" 2752projectGoof-raa -- Bob Arning -- 1 October 2000 - fix confusion in parsing project file name where version and suffix were interchanged - fix an overlooked direct enumerator of Projects" 2753DropShadowHeadingFix-di -- Dan Ingalls -- 1 October 2000 Repairs the control of heading and rotation center where dropShadows are involved, in a manner that is reasonably consistent with the new heading protocols. The main problem had been that renderedMorph, which is used by the halo to set heading, goes down through dropShadows as well as transformations, so we needed a new protocol (degreesOfFlex) to return heading back up through such a chain." 2754ftpDateFix-raa -- Bob Arning -- 30 September 2000 - correct parsing of dates received from an ftp server" 2755newScript3-raa -- Bob Arning -- 2 October 2000 - some fixes for positioning and sizing of flaps in pasteups that are not the world (i.e. that can be resized and positioned at other than 0@0)" 2756ArrowTweaks-di -- Dan Ingalls -- 2 October 2000 Adds a facility to control the appearance of arrowheads on morphic lines. Both length and width of the arrowheads can be controlled, and two styles of arrowhead are now supported. Also, arrowheads now end strictly at the end vertices of their line. This allows one to change line width or arrow size without having to reposition the line to meet an adjacent object. Finally a modicum of help is now provided during operation of the arrowhead control as well as the similar border width control. 2757psBold-raa -- Bob Arning -- 2 October 2000 - allow change of styles within one line of text as postscript. temporarily (or longer, perhaps) defeats test justification on such lines" 2758SubjectFiltering-dv -- Daniel Vainsencher -- 1 July 2000 cmd-s in the toc list turns on Subj. F. Entering an empty filter turns it off. Subject filter made tolerant of extra spaces. In short, it's now easier to read whole threads." 2759PluggableSetDict-dv -- Daniel Vainsencher -- 11 June 2000 The pluggable classes are now not initialized with blocks, and assume the regular =/hash definitions. This supports specializing precisely what part of the behavior you want without paying for the block invocations for both behaviors." 2760CelesteTweaksFixes-mdr -- Mike Rutenberg (mdr(a)scn.org) -- 16 August 2000 (1) emptyTrash will no longer remove messages from database if they are also in another category. This avoids surprises when you have filed a message in two categories, delete one, and then empty the trash. (2) Fixes a recently introduced bug in Celeste moveAgain where the message was removed from the current category but never added to the proper destination category. (3) Small cleanups Removes two unused methods (Celeste hasUsername: and MailDB delete:) Renames a recently included method (updateToc) that differed only in capitalization from an existing method (4) Clear the password when the POP username is changed 2761CelesteAddAttachment-mdr -- Mike Rutenberg -- 31 August 2000 This was the message whose attachment was unnamed because of another Celeste bug." 2762CelesteIndex-beo -- Bruce O'Neel -- 25 June 2000 On the mac the EMAIL.index.log file behaves a bit incorrectly. First it stays around after Celeste is closed, and second if you close Celeste and then open Celeste again quickly, before a GC, the file is still open and the mac gets indigestion when you try to open a file which is open. This change set just makes sure the indexlog is closed."

2 1

Re: [updates] 14 for 2.9alpha
by Bruce ONeel 03 Oct '00

03 Oct '00

Hi, These are up at: ftp://st.cs.uiuc.edu//Smalltalk/Squeak/2.9_alpha/Squeak2.9a-2762.zip cheers bruce Dan Ingalls <Dan.Ingalls(a)disney.com> wrote: > Folks - > > Herewith another 14 updates. Many small fixes and enhancements. Included are 5 Celeste goodies from the summer, as approved by Daniel Vainsencher and Mike Rutenberg. Update #2756 is dedicated to Ned Konz and his AttachmentMorph project. > > Enjoy > - Dan > ----------------------------- > 2749ColorPickerTrackColorAt > > 2750saveTheSource-raa -- Bob Arning -- 30 September 2000 > - restore code that was lost for a while to preserve the source for CompiledMethods exported in an ImageSegment where the sourcePointer had been set. Otherwise, the receiving system may get real confused as to the source for that method." > > 2751fixUncovered-raa -- Bob Arning -- 1 October 2000 > - a bit of a hack to squelch those 'Error: this collection is empty' that TextMorphs seem to produce from time to time when asked #uncoveredAt:" > > 2752projectGoof-raa -- Bob Arning -- 1 October 2000 > - fix confusion in parsing project file name where version and suffix were interchanged > - fix an overlooked direct enumerator of Projects" > > 2753DropShadowHeadingFix-di -- Dan Ingalls -- 1 October 2000 > Repairs the control of heading and rotation center where dropShadows are involved, in a manner that is reasonably consistent with the new heading protocols. The main problem had been that renderedMorph, which is used by the halo to set heading, goes down through dropShadows as well as transformations, so we needed a new protocol (degreesOfFlex) to return heading back up through such a chain." > > 2754ftpDateFix-raa -- Bob Arning -- 30 September 2000 > - correct parsing of dates received from an ftp server" > > 2755newScript3-raa -- Bob Arning -- 2 October 2000 > - some fixes for positioning and sizing of flaps in pasteups that are not the world (i.e. that can be resized and positioned at other than 0@0)" > > 2756ArrowTweaks-di -- Dan Ingalls -- 2 October 2000 > Adds a facility to control the appearance of arrowheads on morphic lines. Both length and width of the arrowheads can be controlled, and two styles of arrowhead are now supported. > Also, arrowheads now end strictly at the end vertices of their line. This allows one to change line width or arrow size without having to reposition the line to meet an adjacent object. > Finally a modicum of help is now provided during operation of the arrowhead control as well as the similar border width control. > > 2757psBold-raa -- Bob Arning -- 2 October 2000 > - allow change of styles within one line of text as postscript. temporarily (or longer, perhaps) defeats test justification on such lines" > > 2758SubjectFiltering-dv -- Daniel Vainsencher -- 1 July 2000 > cmd-s in the toc list turns on Subj. F. > Entering an empty filter turns it off. > Subject filter made tolerant of extra spaces. > In short, it's now easier to read whole threads." > > 2759PluggableSetDict-dv -- Daniel Vainsencher -- 11 June 2000 > The pluggable classes are now not initialized with blocks, and assume > the regular =/hash definitions. This supports specializing precisely > what part of the behavior you want without paying for the block > invocations for both behaviors." > > 2760CelesteTweaksFixes-mdr -- Mike Rutenberg (mdr(a)scn.org) -- 16 August 2000 > (1) emptyTrash will no longer remove messages from database if they are also in another category. This avoids surprises when you have filed a message in two categories, delete one, and then empty the trash. > (2) Fixes a recently introduced bug in Celeste moveAgain where the message was removed from the current category but never added to the proper destination category. > (3) Small cleanups > Removes two unused methods (Celeste hasUsername: and MailDB delete:) > Renames a recently included method (updateToc) that differed only in capitalization from an existing method > (4) Clear the password when the POP username is changed > > 2761CelesteAddAttachment-mdr -- Mike Rutenberg -- 31 August 2000 > This was the message whose attachment was unnamed because of > another Celeste bug." > > 2762CelesteIndex-beo -- Bruce O'Neel -- 25 June 2000 > On the mac the EMAIL.index.log file behaves a bit incorrectly. First > it stays around after Celeste is closed, and second if you close Celeste > and then open Celeste again quickly, before a GC, the file is still > open and the mac gets indigestion when you try to open a file which > is open. This change set just makes sure the indexlog is closed."

1 0

Jump to page: