Squeak-dev January 1998

squeak-dev@lists.squeakfoundation.org

81 participants
196 discussions

Re: multithreading support
by James McCartney 29 Jan '98

29 Jan '98

At 4:52 PM -0700 1/28/98, Sehyo Chang wrote: > I am starting prototyping effort of add native multi-threading >support to Squeak. Any suggestions, hints, advice would be appreciated. > -- sehyo chang What choice are you going to make about multithreaded GC? --- james mccartney james(a)clyde.as.utexas.edu james(a)lcsaudio.com If you have a PowerMac check out SuperCollider, a real time synth program: http://www.audiosynth.com

1 0

Re: printing blocks
by FixPoint 29 Jan '98

29 Jan '98

Content-ID: <0_886030267(a)inet_out.mail.aol.com.1> Content-type: text/plain; charset=US-ASCII Here is a method useful for printing blocks. --Sheldon Nicholl Content-ID: <0_886030267(a)inet_out.mail.aol.com.2> Content-type: text/plain; name="DECOMP~1.ST" Content-disposition: inline 'From Squeak 1.23 of October 4, 1997 on 26 January 1998 at 6:32:39 pm'! !Decompiler methodsFor: 'public access' stamp: 'sn 1/26/98 18:27'! decompileBlock: aBlock "Decompile aBlock, returning the result as a BlockNode. Show temp names from source if available." "Decompiler new decompileBlock: [3 + 4]" | startpc end homeClass blockNode tempNames home | (home _ aBlock home) isNil ifTrue: [^nil]. method _ home method. (homeClass _ method who first) == #unknown ifTrue: [^nil]. constructor _ DecompilerConstructor new. method fileIndex ~~ 0 "got any source code?" ifTrue: [tempNames _ (homeClass compilerClass new parse: method getSourceFromFile in: homeClass notifying: nil) tempNames. self withTempNames: tempNames]. self initSymbols: homeClass. startpc _ aBlock startpc. end _ (method at: startpc-2)\\16-4*256 + (method at: startpc-1) + startpc - 1. stack _ OrderedCollection new: method frameSize. statements _ OrderedCollection new: 20. super method: method pc: startpc - 5. blockNode _ self blockTo: end. stack isEmpty ifFalse: [self error: 'stack not empty']. ^blockNode statements first! !

1 0

Re:Case-insensitive selectors
by Jon M. DeLaurier 28 Jan '98

28 Jan '98

I would rather be a PersonWhoTypesSelectorsLikeThis: than a PERSONWHOTYPESSELECTORSLIKETHIS: Jon ------------------------------------------ >Subject: Case-insensitive selectors >Sent: 27/01/1998 15:52 >Received: 28/01/1998 11:07 >From: Patrick Logan, patrickl(a)servio.gemstone.com >Reply-To: squeak(a)cs.uiuc.edu >To: squeak(a)cs.uiuc.edu > > > From my point of view (I am _not_ one of the "original" smalltalk > designers) it's just the other way around. In a static language > you have all the time you need for compiling and linking and doing > case insensitive comparisons. Smalltalk, however, does lots of > things with its selectors. You can "perform:" them which is in > basically a lookup of the signature. In principle, this happens > every time a message is sent. I'd say if the method lookup takes > longer for case-insensitive comparisons this a very good reason to > stay case insensitive. > >I am not advocating for case-insensitity but in response to the >message above, if one were to adopt this policy: > >(1) It would seem to me selectors could be replaced by all upper- or >lower-case selectors at compile (i.e. "accept") time. Then all lookups >would be canonical. > >(2) Common Lisp and other Lisps are case-insensitive and work fine in >an interactive environment. Its syntax is more suited though since it >can easily use - as a separator rather than _ which requires a <shift> >key. > >(3) WithoutASeparatorLike_or-IdGuessMostPeopleWouldStillTypeLikeThis > >-- >Patrick Logan mailto:patrickl@gemstone.com >Voice 503-533-3365 Fax 503-629-8556 >Gemstone Systems, Inc http://www.gemstone.com > ------------------------------------------------------------------------- | Jon M. DeLaurier | vox : 250.656.6176 | | 2209 Bradford Av | | | Sidney, B.C. V8L2C8 | | | Canada | email: jdelaurier(a)vanisle.net | ------------------------------------------------------------------------- | It is always darkest just before it gets black. (Dave Broadfoot 1996) | -------------------------------------------------------------------------

1 0

Re: Smalltalk Design Question
by Ken Dickey 28 Jan '98

28 Jan '98

> I'd say if the >method lookup takes longer for case-insensitive comparisons this a very >good reason to stay case insensitive. There is no performance penalty for this. The case gets 'squashed' once and lookup comparisons which have to be done dynamically run in the same time. Cheers, -Ken

1 0

Smalltalk Design Question
by Mark Wai 28 Jan '98

28 Jan '98

Hi, I have a question that I think the "original" Smalltalk designers could help me understand: I always wondering why Smalltalk method signature (not keywords like self, super etc.,) are CaSe SENSITIVE. Was this by design or due to implementation constraints? I can understand why static languages are case sensitive(e.g. more efficient compiling) but for dynamic languages like Smalltallk, I can think of more advantages of being non-case sensitive rather than case sensitive. Some obvious advantages of having Smalltalk non-case sensitive that I can think of are: - reduce typo runtime errors - polymorphism is easier due to lesser constraint (especially when the method signature is long) - reduce ambigous methods that have same name but different cases etc, Of course, the Smalltalk compiler must not allow the same method define if the names are the same but the case is different. Implementation wise, I think it should not be that hard (I have prototyped that in IBM Smalltalk a while ago, e.g. changing >>doesNotUnderstand: for quick hack). Therefore, I think I must have missed something. I sure hate seeing different Smalltalk dialects implements the same method with the same name but different case. I think one of those classic example is >>asUppercase versus >>asUpperCase. This creates portablitiy problem between multi-vendor dialects. Maybe this should consider to be part of ANSI standard too. I appreciate any comments. Thanks. -- Mark Wai Frontier Systems Architecture Inc. mailto: mwai(a)ibm.net or:[ mwai(a)frontiersa.com] __

5 4

Re: Case-insensitive selectors
by Mark Wai 28 Jan '98

28 Jan '98

Vassili Bykov writes: >Note however, that case does play a semantic role in variable names: >capitalization determines a variable scope. In a language with >case-sensitive variable names, it is quite natural to expect >case-sensitive func... oops, selectors -- if only for the sake of >consistency. I agreed. However, in Smalltalk, one can define an instance (or class) method with capital letter which can be very confusing and certainly not "consistent" from the point of semantic role in variable names. Smalltalk method's case tell you nothing about its scope. >Finally, case sensitivity might simply be a matter of someone's >personal concept of The Right Thing (tm). Yes or no. The reason I brought this thing up is because I don't just use a language. I also want to understand why a particular "feature" was implemented. This can help me to more effectively use a language if I understand the design and the philosophy behind it. It is a pity if the existence of a lanaguge's feature is due to the fact that traditionally that particular feature is implemented the same way in other languages without considering the language's own unique capabilities and nature. In order to improve a language, it needs to be evolved to a better one. In this case, I just don't understand why Smalltalk method has to be case sensitive while I can think of a stronger case for it being case-insensitive. That's why I ask for design rationale behind it. This is probably a tiny little issue for 99.9% of people that is not worth discussing but in my work the case sensitive and its ambiguity affect some of my design decisions. Thanks for your comment. -- Mark Wai Frontier Systems Architecture Inc. mailto: mwai(a)ibm.net or:[ mwai(a)frontiersa.com] __

2 1

Re: Case-insensitive selectors
by Vassili Bykov 28 Jan '98

28 Jan '98

Bill Kohl <billk(a)hypercon.com> wrote: >If Smalltalk were case insensitive, then I assume the method >'howIsThisForReadability', could be sent as HOWISTHISFORREADIBILITY or >howisthisforreadability (plus all other combinations). For me, this would make >readability an issue. Well, this does look like a really sound argument for case sensitivity. Symbols representing selectors do come back to us as items in browser method lists, or in "messages" selection dialogs. All technicalities and personal preferences aside, this is an actually important reason to preserve their original shape. <jarvisb(a)timken.com> wrote: >I personally prefer case-sensitive languages to case-insensitive >languages. If I want to have selectors or procedures named abc, Abc, >ABC, and aBc in a program I darn well expect the language to allow it >and not try to limit what can be done. I also *HATE* underscores and >dashes in identifier, selector, or procedure names. If I wanted to >PROGRAM-IN-COBOL or PROGRAM_IN_PL_1 <gag!> I'd do so. I don't. Keep >Smalltalk case-sensitive!!!! :-) Hey, dashes are just fine to separate words! But underscores -- *those* are really ugly, I'm with you on that. Seriously, as long as there are several approaches to achieving the same result, there are that many camps religiously defending the ergonomical, historical, or moral merits of their favourite one. In a well-known primitive case, the only problem was choosing the proper end of an egg, while in our advanced world opportunities are definitely much richer. I believe, Minsky described something similar in his _Society of Mind_: the closer two alternatives are to each other, the harder it is to choose -- the paradox being that the closer they are, the less significant is the choice. -- Vassili Bykov vassili(a)objectpeople.com The Object People http://www.objectpeople.com +1(613)225-8812

1 0

Case-insensitive selectors
by jarvisb＠timken.com 28 Jan '98

28 Jan '98

I personally prefer case-sensitive languages to case-insensitive languages. If I want to have selectors or procedures named abc, Abc, ABC, and aBc in a program I darn well expect the language to allow it and not try to limit what can be done. I also *HATE* underscores and dashes in identifier, selector, or procedure names. If I wanted to PROGRAM-IN-COBOL or PROGRAM_IN_PL_1 <gag!> I'd do so. I don't. Keep Smalltalk case-sensitive!!!! :-) *************************** Attachment *********************************** Date: 27 January 1998, 18:55:59 EST >From Patrick Logan patrickl at INTERNET patrickl(a)servio.gemstone.com squeak at INTERNET squeak(a)cs.uiuc.edu To: squeak at INTERNET squeak(a)cs.uiuc.edu cc: recipien at INTERNET recipient.list.not.shown:@ In-Reply-To: <199801272332.AAA11356(a)monet.cs.uni-magdeburg.de> Reply-To squeak at INTERNET squeak(a)cs.uiuc.edu Subject: Case-insensitive selectors Resent-Date: 27 Jan 1998 23:56:03 -0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: VM 6.22 under 19.15 XEmacs Lucid X-Mailing-List: <squeak(a)cs.uiuc.edu> archive/latest/400 X-Loop: squeak(a)cs.uiuc.edu Resent-Sender: squeak-request(a)cs.uiuc.edu From my point of view (I am _not_ one of the "original" smalltalk designers) it's just the other way around. In a static language you have all the time you need for compiling and linking and doing case insensitive comparisons. Smalltalk, however, does lots of things with its selectors. You can "perform:" them which is in basically a lookup of the signature. In principle, this happens every time a message is sent. I'd say if the method lookup takes longer for case-insensitive comparisons this a very good reason to stay case insensitive. I am not advocating for case-insensitity but in response to the message above, if one were to adopt this policy: (1) It would seem to me selectors could be replaced by all upper- or lower-case selectors at compile (i.e. "accept") time. Then all lookups would be canonical. (2) Common Lisp and other Lisps are case-insensitive and work fine in an interactive environment. Its syntax is more suited though since it can easily use - as a separator rather than _ which requires a <shift> key. (3) WithoutASeparatorLike_or-IdGuessMostPeopleWouldStillTypeLikeThis -- Patrick Logan mailto:patrickl@gemstone.com Voice 503-533-3365 Fax 503-629-8556 Gemstone Systems, Inc http://www.gemstone.com

1 0

RE: Portability of the Squeak shell (was Re: interpreter questions regarding memory model.)
by Serg Koren 28 Jan '98

28 Jan '98

How about Mouse? ;-) Or Cheese? S On Monday, January 26, 1998 11:34 AM, Paul Fernhout [SMTP:kfsoft@netins.net] wrote: > Tim Rowledge wrote: > > Actually, I'd suggest it might be useful to indirect ALL calls to 'outside' apis, so that the platform specific code can cleanly intercept any that might not be suitable; there aren't many so it wouldn't be too onerous. Let's see, malloc, > > fread, frite, fseek, fopen, fclose, math stuff.... that's about it. The easy way would be to have the SQ code refer to some munged name and to use macro definitions to make use of the 'normal' calls where acceptable. > > Thus we could easily intercept all the file handling but leave macros for exp, floor, sin etc. > > I second this. > > When dealing with code for the Newton, which doesn't support files, this > is a source of complexity. For the most part, it isn't that bad. But > there is one place in the VM when it starts up where the shell creates a > file handle and passes it to the VM (for reading the image) which > created the worst difficulty. That is one place that Squeak does not use > its own file primitives and the workaround is ugly. > > It would help if there was a test program written in C that exercised > the Squeak shell code. The test program woudl be much smaller than > Squeak itself - like one hundred lines of code or so. That way a port > could focus on getting a shell to work first. > > That test case could be as simple as: > Draw a diagonal line, respond to a mouse down or key by drawing another > line, play a sound, and maybe read a file. These could be individual > tests or run together based on compiler flags. One could progress in > some arbitrary order - like first get the bitmap to work, then get > keyboard, then the mouse, then files, then TCPIP, then sounds. There > could be feedback provided at each stage by the test program. > > On a related issue, there is much value in having a machine independent > GUI shell that collects keystrokes, tracks the mouse, interacts with > file like streams, displays bitmaps, does TCP/IP, and plays and records > sounds. With a little restructuring, the Squeak shell could turn into a > beautiful machine independent framework on top of which *anything* could > be placed. This might entail a slight performance hit depending on how > nternal Squeak data structures like strings were passed to the shell. > > For example, if a group wanted to make a portable version of Python with > TK widgets, they could just put it on top of the Squeak shell platform. > > This would potentially bring a lot more people into the machine > independent Squeak shell API fold. Even though they wouldn't have much > to say about Squeak, they might have an interest in porting the Squeak > shell to new platforms for their own reasons, and then Squeak could > follow. It might also multiply the number of people interested in > sharing the work of maintaining and debugging existing Squeak shell > ports. > > Maybe if the Squeak low level API had a name it would be treated more > like a thing on its own. Anyone with a catchy name for the Squeak shell > and related API? > Conch? > Squeak API? Squeak Happy? > The Nest? > Squeal? > Low Squeak? Rumble? > > -Paul Fernhout > Kurtz-Fernhout Software > =========================================================== > Developers of custom software and educational simulations > Download our Garden Simulator for Windows & source from: > http://www.gardenwithinsight.com >

1 0

MIDI File Reader Patch
by Andreas Raab 28 Jan '98

28 Jan '98

John, enclosed is a patch for the MIDIFileReader to handle RMID files correctly. If you don't know, RMID is M$ way of packing MIDI files in their own chunk structure. If you haven't seen any of these yet, look into your Windows\Media directory. There should be a couple of those (extension is ".rmi") . Have fun, Andreas ----------------------------------------------------------------------------- 'From Squeak 1.3 of Jan 16, 1998 on 27 January 1998 at 5:27:45 pm'! !MIDIFileReader methodsFor: 'chunk reading' stamp: 'ar 1/27/98 17:25'! readHeaderChunk | chunkType chunkSize division | chunkType _ self readChunkType. "AR hack - support RMID files" chunkType = 'RIFF' ifTrue:[chunkType _ self riffSkipToMidiChunk]. "AR endOfHack" chunkType = 'MThd' ifFalse: [^ self error: 'missing MIDI file header chunk']. chunkSize _ self readChunkSize. fileType _ self next16BitWord. trackCount _ self next16BitWord. division _ self next16BitWord. (division anyMask: 16r8000) ifTrue: [self error: 'SMPTE time formats are not yet supported'] ifFalse: [ticksPerQuarter _ division]. "sanity checks" chunkSize = 6 ifFalse: [self report: 'unusual MIDI header size ', chunkSize printString]. (#(0 1 2) includes: fileType) ifFalse: [self report: 'unusual MIDI file type ', fileType printString]. Transcript show: 'Reading Type ', fileType printString, ' MIDI File ('; show: trackCount printString, ' tracks, '; show: ticksPerQuarter printString, ' ticks per quarter note)'; cr. ! ! !MIDIFileReader methodsFor: 'private' stamp: 'ar 1/27/98 17:27'! next32BitWord: msbFirst "Read a 32-bit positive integer from the input stream." "Assume: Stream has at least four bytes left." | n | n _ stream next: 4. ^msbFirst ifTrue:[((n at: 1) bitShift: 24) + ((n at: 2) bitShift: 16) + ((n at: 3) bitShift: 8) + (n at: 4)] ifFalse:[((n at: 4) bitShift: 24) + ((n at: 3) bitShift: 16) + ((n at: 2) bitShift: 8) + (n at: 1)] ! ! !MIDIFileReader methodsFor: 'private' stamp: 'ar 1/27/98 17:27'! riffSkipToMidiChunk "The file is a RIFF file which may (or may not) contain a MIDI chunk" | dwLength fourcc | "Read length of all data" dwLength := self next32BitWord: false. "Get RIFF contents type " fourcc := self readChunkType. fourcc = 'RMID' ifFalse:[^fourcc]. "We can only read RMID files here" "Search for data" [[fourcc := self readChunkType. dwLength := self next32BitWord: false. fourcc = 'data'] whileFalse:[ "Skip chunk - rounded to word boundary" stream skip: (dwLength + 1 bitAnd: 16rFFFFFFFE). stream atEnd ifTrue:[^'']]. "Data chunk is raw - look into if it contains MIDI data and skip if not" fourcc := self readChunkType. fourcc = 'MThd'] whileFalse:[ "Skip data (chunk - 4bytes) rounded to word boundary" stream skip: (dwLength - 3 bitAnd: 16rFFFFFFFE)]. ^fourcc! ! ----------------------------------------------------------------------------- -- Linear algebra is your friend - Trigonometry is your enemy. +===== Andreas Raab ============= (raab(a)isg.cs.uni-magdeburg.de) =====+ I Department of Simulation and Graphics Phone: +49 391 671 8065 I I University of Magdeburg, Germany Fax: +49 391 671 1164 I +=============< http://isgwww.cs.uni-magdeburg.de/~raab >=============+

1 1

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

Jump to page: