Squeak-dev May 2000

squeak-dev@lists.squeakfoundation.org

137 participants
680 discussions

RE: Stepper
by Doug Way 02 May '00

02 May '00

(Responding to an old thread...) On Sun, 13 Feb 2000, Terry Raymond wrote: > Stefan Matthias Aust wrote: > > > > At 13:58 13.02.00 -0700, David Farber wrote: > > > > > >i agree. a "debug it" command on the pop-up menu would be > > really handy. > > > > I second this. This would save an "self halt" in the > > expression and also > > omit the click on "debug" in the notifier before the debugger opens. > > > > Does anybody know how far away this would be from real > > breakpoints (in the debugger and other code panes) > > No comparison. To do a "debug it" you would compile the expression > then open the debugger and do an automatic send into the expression. > A self halt would not appear in the expression because the debugger > was opened before the expression began execution. I was actually just looking into implementing a "debug it" menu item in Squeak, but I'm still not all that familiar with the Compiler/Debugger, so I think I need a few more hints... By tracing through Compiler>>evalute:in:to:notifying:ifFail:, I've figured out how to generate a CompiledMethod from a do-it string via the Compiler/MethodNode, but the Debugger seems to expect a MethodContext instead. (See Debugger>>openContext:label:contents:.) Is there a way to get the context from the CompiledMethod, to begin executing it, in other words? (or is there a different method I should be using when opening the Debugger?) Also, how do I do an "automatic send into the expression"? Thanks for any tips, - Doug Way EAI/Transom Technologies, Ann Arbor, MI http://www.transom.com dway(a)mat.net, @eai.com

1 0

Re: [ENH][ANN] 99% Of All ANSI Messages In Change Set
by Conrad Taylor 01 May '00

01 May '00

Hi, will this be available for Squeak 2.8a? Thanks, -Conrad --- "R. A. Harmon" <harmonra(a)webname.com> wrote: > This is a incomplete implementation. It adds > missing ANSI methods, or > changes existing methods to conforming ANSI > behavior, so that when installed > Squeak will contain 99% of all the messages > specified in the ANSI standard. > I am awaiting the release of the Camp Smalltalk ANSI > Tests to finish the > final 1%. > > Beware! There are subtle differences between the > behavior specified by the > ANSI standard for some methods already present in > Squeak. I did not check > if the differences broke existing code except for > obvious errors I > discovered using Squeak. > > The Fundamental, Valuable, Exception, Numeric, and > Date And Time protocols > are complete and tested. > > All but a few of the ANSI standard Collection > protocol messages have been > added or changed, and tested in an ad hoc fashion. > > I have not implemented the Stream, and FileStream > protocols as yet. > > I reformatted all my method's code using pretty > printing. > > The Squeak 2.7 change set is now available at my web > page: > > http://homepage2.rconnect.com/raharmon/ > > I hope it can be incorporated into the Squeak > Central release. > > -- > Richard A. Harmon "The only good zombie is > a dead zombie" > harmonra(a)webname.com E. G. McCarthy > Spencer, Iowa > > __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/

1 0

Re: [FIX][ENH] SortedCollection robustness & speedup
by Florin X Mateoc 01 May '00

01 May '00

Hi Andres, Have you tried the sample code ? For me it gives the correct result, as it should. The only thing that Georg did here was to add the "^aCollection" at the end, which makes it consistent with the way the "adding" protocol behaves. The addition part of the method was and still is correct (well, I don't know what image you are using). Maybe something else is broken in your image. Cheers, Florin avalloud(a)entrypoint.com on 04/28/2000 02:14:05 PM Please respond to squeak(a)cs.uiuc.edu To: squeak(a)cs.uiuc.edu cc: (bcc: Florin X Mateoc) Subject: Re: [FIX][ENH] SortedCollection robustness & speedup Hi Georg. > >> addAll: aCollection > >> "Optimize for large additions." > >> > >> aCollection size > (self size // 3) ifTrue: [ > >> aCollection do: [ :each | super addLast: each ]. > >> self reSort ] > >> ifFalse: [ aCollection do: [ :each | self add: each ]]. > >> ^aCollection! ! > > Sorry, I do not understand this one. Can you elaborate ? The message addAll: works by adding stuff to the receiver. Hence, x addAll: aCollection gets you x with all its elements plus the elements of aCollection, all of those in x. aCollection is not modified by this process. Now, with the method above, you may get an equivalent answer but the receiver may be left untouched by addAll:. This would happen when aCollection size <= (self size // 3). In that case, aCollection would have its elements and those of x, so the answer of this message would be equivalent. But aCollection is modified instead of x. So, you could have this happen: x _ (1 to: 10) asSortedCollection. y _ (11 to: 12) asSortedCollection. x addAll: y. x size <alt-p> 10 How come it's 10 when I added stuff to it? And surprisingly, y size <alt-p> 12 ?!??!... What I meant by merge sort is that when collections are large, the cost of resorting is huge. So, when addAll: is sent with a big collection to another big collection, you could do merge sort and create a third temp one whose contents would replace the receiver's when the process is finished. Alas, you can only do this if the sort blocks are both nil or are compatible. I do not think that the sort blocks can be determined to be compatible... it would take too much (even if they sent the same messages, you would also have to verify that they were supposed to send the same messages to the same kind of objects). That leaves the case when the sort blocks are both nil, in which you can safely do merge sort. Andres.

2 1

Re: Carrying preferences around
by Lex Spoon 01 May '00

01 May '00

Hrm, I would rather preferences be attached to an image, though. For instance, I have development images, server images, and an occasional screwball image where I'm playing with something really wierd. Each image is its own little world, with its own preference settings. Such a system is incompatible with global preferences stored in files. Let me propose another question to think about: How do you transmit an interesting collection of settings to one of your friends? For example, you've come up with a good color scheme, and you'd like to share it with your buddies. What is the mechanism that allows this to work? Whatever the answer is, we can use it to transfer settings from one image to another as well. -Lex

1 0

Re: Reading Video from Squeak
by Lex Spoon 01 May '00

01 May '00

mdr(a)scn.org (Mike Rutenberg) wrote: > Also, TWAIN might be the way to go (http://www.twain.org/). Not only is the Quickcam VC TWAIN compatable (according to http://www.ctdepot.com/store/cameras/quickcamvc.htm), but so are almost all scanners. And TWAIN seems to be a cross platform standard, at least with Macs and PCs supported (Linux too?). > AFAICT, TWAIN is a standard for drivers, not for devices themselves. For example, you can make a network card "TWAIN compliant" just by writing a new driver. TWAIN is probably not a good choice for Squeak, because: 1. TWAIN drivers are tied to specific OS's, because they open GUI windows. 2. Most devices only have a TWAIN driver for one or two OS's. Rare will be the scanner that has a Zaurus driver. On Linux, the standard of choice is SANE. So probably the best solution, is for the Windows VM to talk to TWAIN, and the Unix VM to talk to SANE, and for other VM's to do some other thing. Squeak then needs to have its *own* interface between the image and the VM. -Lex PS -- there are two sentences in this message without an acronym. :)

1 0

Re: [updates] 35 more for 2.8alpha
by R. A. Harmon 01 May '00

01 May '00

At 12:11 PM 4/30/00 -0400, Andrew C. Greenberg wrote: >>At 01:39 PM 4/29/00 +0200, Stefan Matthias Aust wrote: >>>At 15:56 27.04.00 -0500, R. A. Harmon wrote: >>> >>>>I would suspect not as MVC is slated to be removed from Squeak Central >>>>release. I'm not sure when. >>> >>>I'm not sure whether this statement is correct. Actually, I think, it's >>>wrong. AFAIK, the default desktop is probably changed from MVC to morphic >>>but there're no plans to remove MVC. >> >>The last time this question came up a couple of months ago I went back and >>found Dan Ingalls's original post on the future of Squeak and confirmed that >>he said MVC was being removed. I think I posted an excerpt of it. >> >>Unless I missed something since the last discussion, I guess that is still >>the plan. >> >> >>>I'm also pretty sure that this wouldn't be easy as it's deeply burried in >>>all parts of Squeak - including Morphic :-) >> >>If I remember correctly, during the last discussion Dan explained (something >>like) that the MVC event mechanism would remain but they still planned to >>remove the MVC GUI framework. Sorry, I can't give a better explanation. >> >>He said anyone could then add the MVC GUI framework to the Squeak Central >>release, if they wanted it. > >I see it as Stefan describes. I see no indication of an MVC extraction. > >While this rumor of an MVC extraction seems to continue unabated, >cycling roughly monthly in posts by Mr. Harmon, I don't see any >evidence of it. I certainly didn't see any of it in my e-mail >archives I reviewed. > >Dan certainly did state that Morphic was going to be the primary GUI >for SqC, and would be the default in the SqC release, probably >beginning with 2.8. Beyond that, Mr. Harmon's conclusion seems to be >wild extrapolation of other remarks. > >The comments found in recent changesets continue to indicate concern >about changes being properly supported in or backpatched to MVC, and >changesets with updates and upgrades continue to be posted. A fair >amount of third-party Smalltalk code relies on MVC (or is more easily >ported to MVC), and thus MVC is a useful tool for compatibility. As much Smalltalking as I've done, I still don't understand GUI stuff, including MVC, as well as I'd like. My paraphrasing of Squeak Central's plans for MVC was correspondingly lacking. Poor recall and writing skill didn't help either. Since I am apparently unable to give a short -- and especially an accurate -- description of Squeak Central's plan for MVC, I'll refrain from the attempt. Sorry, I'll try to better in the future. Dan Ingall's clarification at http://macos.tuwien.ac.at:9009/757366513.asHtml MVC is Dead? - Dan Ingalls Title MVC is Dead? Author Dan Ingalls Date: Wed, 2 Feb 2000 10:16:43 -0800 From: Dan Ingalls <Dan.Ingalls(a)disney.com> Subject: Re: MVC is Dead? [A clarification -- when we at Squeak Central (SqC) refer to "MVC", we are= usually referring to the "old ST-80 viewing structures" and their control= regime (View/Ctlr, SSView/Ctlr, and ControlManager). We consider the= model/dependents architecture and change/update protocols to be of enduring= value in Squeak as in MVC]. >At 09:34 PM 2/1/00 -0600, Les Tyrrell wrote: >>If the support is there to power Morphic, I'd think that the >>support will always be in place to resurrect MVC, should it >>be dropped from the baseline. >[snip] "R. A. Harmon" <harmonra(a)webname.com> replied... >I don't share your optimism on this point. I think it would slowly become = a >dead path. Less bugs would get fixed, less enhancements get added, less >people use it, so less bugs would get fixed, less enhancements get added, >less people use it, . . . . It appears to me that additional "widget?" are >added to morphic but not in a way that they can be used in MVC--I'm not >familiar enough with morphic to tell for sure. This is already the case -- MVC is currently maintained for backward= compatibility (with documentation, etc) -- it is not the site of most= enhancements and of Squeak's general forward motion (animation, 3D, music= and sound support, etc). >I think this is a route that will diminish Squeaks accessibility to folks >new to Smalltalk as most books on Smalltalk and code freely available (othe= r >dialects) don't use morphic. Trying to translate MVC to morphic adds a >level of complexity to learning from the books and code. This is enough to >dissuade someone from getting over the OOP-think hump. This is why we have kept MVC so far. That familiarity and compatibility= with other STs is a valuable component in the overall synergy. Regarding the OOP-think hump, we at SqC consider NEITHER Morphic nor MVC to= be adequate. We still feel that an entirely new approach is needed here --= along the lines of Morphic viewers somehow integrated with a real inspector= /browser/debugger, with maybe a few things borrowed from Fabrik and Morphic= Wrappers. Wish us luck (or beat us to it!). >I think the newbies and tools are both useful in getting to the next plane. Absolutely. We do not plan to decommission (excise from the release) MVC until the time= when nearly everyone who uses Squeak does so as an environment unto itself,= not as a free alternative to other similar Smalltalks where MVC= compatibility is important. We feel that this could happen within the= current year (but we had the same feeling a year ago ;-). Whenever the= time comes, we will produce a "Last Picture Show" image that is the= cleanest and most complete MVC-based image possible, so that it can be used= and maintained indefinitely by motivated MVC survivalists. >>Isn't Morphic about due for the long-awaited refactoring? Yes, indeed. This is another nice thing about retaining MVC for a while. = It gives us a place to stand when making major changes to Morphic. - Dan Created by the Squeak Mail Archiver on 1 May 2000 at 3:44:24 pm. -- Richard A. Harmon "The only good zombie is a dead zombie" harmonra(a)webname.com E. G. McCarthy Spencer, Iowa

1 0

Another Potential Squeak Handheld from Sharp?
by Dean_Swan＠Mitel.COM 01 May '00

01 May '00

John, I ran across this news blurb at smaller.com: Windows CE 5/1/00 Sharp Ships Telios WinCE HPC Pro While Microsoft itself has not shown much interest in its WinCE HPCs, intransigent supporter Sharp has announced and started shipping another CE device. Named Telios 7000, the new Sharp is by far the most impressive HPC to date with a built-in digital camera, a 7.1" 16-bit active matrix display, a USB port, and a Fast IR port. that led me to this URL: http://www.sharp.co.jp/sc/eihon/hcvj1c/text/index.html I'd like to know what you think of this machine, since Roxanne can translate for you. It's unclear to me whether this machine will be offered in the US, but being WinCE based, I imagine it's either MIPS or an SH processor, so the standard WinCE VM ought to work well. -Dean dean_swan(a)mitel.com

1 0

Preferences for applications?
by mdr＠scn.org 01 May '00

01 May '00

I was thinking of building a preferences panel for Celeste. If I look in the class Preferences, everything is hard coded in the class side for the standard system preferences. It seems like configuration and preferences will become more and more modular with the new segment/application architecture. Is there any strong reason preferences need to stay the way they are? Has anybody done a more modular scheme? Thanks! Mike

1 0

[ENH][FIX][Goodie] Various bug fixes, Exmh mail import, and a MailNotifier
by danielv＠netvision.net.il 01 May '00

01 May '00

Bugs fixed - * MailDB printOn: more robust * MailMessage timeFrom: can now handle timezone '+-200' (some mailers think I live there). * MIME fields made case insensitive (Case amnesiac, actually. Could this be a problem?). Second file is a crude but effective MailNotifier. Anyone feel like making it pretty and more convinient (UI experts, anyone)? Third file is a class I created to import my mail from Exmh, in case anyone else uses it or wants another example to help create his own. BTW, hacking up the import code is simpler than it seems.

2 1

ARM - Implications for Squeak?
by Dean_Swan＠Mitel.COM 01 May '00

01 May '00

From: Dean Swan@MITEL on 05/01/2000 10:48 AM John, I too have been seriously considering "upgrading" my E-105 to one of the new Compag PocketPCs. Can Andreas build an ARM version of the WinCE VM? On a related note, the ARM based version of Nintendo's Gameboy is apparently being delayed until 2001 because they don't want to cannibalize current strong sales of Gameboy Color. However, developers kits *are* shipping. If you/Disney is able to get a hold of a developer's kit, I'd be happy to do the port. Regarding Squeak on on lower performance processors, has anybody done any serious performance profiling on low end machines? I've run Squeak 2.7 acceptably on a 485DX2/50 Mhz, which is a fairly low end machine, and after my recent read of that 'history of PARC' book, I did a little digging on the Alto. >From what I gather, it was a user micro-codable NOVA clone with a 1.5 microsecond instruction cycle time, and 170 ns micro cycle. It must have run Smalltalk bytecode at something like only 10,000, to 20,000 bytecodes/second, and maybe 1000 to 2000 sends/second which is less than 1% of the speed of Squeak on "modern" hardware! This makes me wonder how Smalltalk never suffered from infant mortality. I suspect that Squeak in it's current incarnation is just squandering resources in a few isolated areas, since Smalltalk did, in fact, survive from it's origins on what would be considered *very* low-end hardware by today's standards. -Dean dean_swan(a)mitel.com John.Maloney(a)disney.com on 05/01/2000 09:37:55 AM Please respond to squeak(a)cs.uiuc.edu To: squeak(a)cs.uiuc.edu cc: (bcc: Dean Swan/Ogd/Mitel) Subject: Re: Palm drops 68K in Favor of ARM - Implications for Squeak? Thanks for passing along this news. The Palm has long been a natural Squeak target, but the low performance Dragonball processor made it unattractive. Worse, the Palm OS memory model made it difficult to get a single contiguous block of RAM in which to put Squeak's object heap. An ARM processor (StrongARM or otherwise) would address the first problem and I suspect that Palm would also address the second problem when they migrate to the new processor. Applications such as MP3 players and speech recognition would be difficult to write using the current Palm memory model, and I don't think ARM architecture offers any particular incentives to use small memory chunks the way the 68K architecture does. Meanwhile, the new Compaq Aero based on the StrongARM sounds like it might make an excellent Squeak platform. There are pdf files at: ftp://ftp.compaq.com/pub/products/handhelds/pocketpc.pdf ftp://ftp.compaq.com/pub/products/handhelds/famchart.pdf -- John At 12:58 PM -0700 4/28/00, John-Reed Maffeo wrote: >http://news.cnet.com/news/0-1006-200-1752075.html?dtn.head

1 0

Jump to page: