Squeak-dev February 2001

squeak-dev@lists.squeakfoundation.org

144 participants
725 discussions

How to store projects on file with more than one change set?
by Ned Konz 28 Feb '01

28 Feb '01

I have a project that I'd like to share with the Squeak world (my latest Connector stuff, which is getting pretty useful). However, its code is right now in two change sets that I'd like to keep separate if I could (the Connectors CS is dependent on the FSM CS). How can I get the prerequisite change set stored in the project along with the project's own change set? -- Ned Konz currently: Stanwood, WA email: ned(a)bike-nomad.com homepage: http://bike-nomad.com

1 0

Re: Symbolic Math/Functions in Smalltalk
by Alan Kay 28 Feb '01

28 Feb '01

Yeah, going the other way would really be half VAST ... Cheers, Alan ------ At 5:15 PM -0500 2/27/01, JArchibald(a)aol.com wrote: >=> 2/27/01 5:06:52 PM Est, Alan.Kay(a)disney.com => ><< I'd like something just half VAST .... >> > >Alan, > >The direction is a positive one, though. It is translating VAST code to >Squeak, rather than Squeak to VAST. > >Cheers, >Jerry. >____________________________ > >Jerry L. Archibald >systemObjectivesIncorporated >____________________________

1 0

Re: Project layout
by Richard A. O'Keefe 28 Feb '01

28 Feb '01

Alan Kay <Alan.Kay(a)disney.com> wrote: But most paper notepads or xeroxed papers are 8.5*11 with not all the boundary pixels used, so my calculation covers this physical size. "Most"? I haven't seen any notepads that weren't in metric sizes since I left California >10 years ago. I could probably still lay my hands on a Quarto or Foolscap pad if I searched my parents' home, but it has been A4 here for lo! these many years, as it is almost everywhere. I am fed up to the back teeth with programs like Acrobat Reader that start up *every* time offering a paper size ("Letter") that is about as common in this country as unicorn feathers. (Nor will it accept "mm", "cm", "centimetres", or even "centimeters" in place of "inches" for *PageUnits in ~/.acrorc.) What I want in a screen is room for two A4 pages side by side with at least a 1cm gap between them and another 1.5cm strip around the edge. And if the screen is big enough to suit the paper sizes peculiar to the US as well, that'd be nice too.

1 0

Re: [BUG] Low Space problem in 3.0 (and 3.1.3696)
by Richard A. O'Keefe 27 Feb '01

27 Feb '01

There used to be quite a bit of interest in Prolog circles in automatic cycle detection. Of course the comparative absence of side effects in Prolog makes it a *lot* easier. The major surviving Prolog systems don't bother, in part because keeping accurate track of stack depth conflicts with tail recursion optimisation. The Clean and Haskell compilers I have access to basically let you set a limit on stack size (if you want to) and when the hardware/OS tell you it has run out, kill your program. Interlisp-D on the Xerox Dandelions and such (1108, 1109, 1185, 1186) had a hard limit of 64k cells in the stack. It wasn't that hard to run out, but somehow most Interlisp programmers never noticed that there was a limit. Preferences are entirely the wrong way to go because they have to be set by the wrong person, who lacks the knowledge about how the limit might be set. Something like aBlock valueWithStackLimit: aNumber would let the programmer override the limit at the point where s/he has some idea what limit will be needed. Even that's a bit dodgy. The main thing is that it's ok to blast away the thread that gets too big, but not to crash the entire Smalltalk system.

1 0

Re: Symbolic Math/Functions in Smalltalk
by Alan Kay 27 Feb '01

27 Feb '01

Hey Dave -- I'd like something just half VAST .... Cheers, Alan ------ At 3:46 PM -0500 2/27/01, David N. Smith $IBM$ wrote: >Jerry: > >Sure, and I even recall that they are on my web site and may have >been posted here some long time ago. > >Basically, I have a set of methods that process class and method and >application (but not subapplication) definitions from a fileout in >IBM Smalltalk format and converts them to the nearest Squeak >equivalent. > >I've used it several times to convert things to Squeak. > >Here is a longer description from the tools filein. > > >"VAST Filein Support allows IBM Smalltalk applications to be filed in. > >Follow this process: >* File out a VAST Application (not just a class). >* In Squeak, file in the application. > >The change set name of the filed in code is the application name; >application BigStuffApp is saved in change set BigStuffApp. The >change set is created, if needed, and each 'BigStuffApp >becomeDefault' in the filein switches back to this change set. > >The category of the filed in code is the application name; >application BigStuffApp is saved in category BigStuffApp. > > >Method categories are set to those from VAST; private methods in a >category are placed in a new category with the word 'private' >appended. Thus, a private method in category 'access' is placed in >category 'access private'. If there are no category for a method, >the category is set to either 'Public methods' or 'Private methods'. > >Class comments are filed in and can be seen by pressing the '?' >button in a browser. Class notes are not filed in. > > >Class Application is a simple version of the VAST class Application. >Class Subapplication is not supported at this time. Prereqs are >checked and errors are noted in the Transcript. The only system >prereq currently defined is Kernel. > >All class definition methods are supported, including >classInstanceVariables. However there is no equivalent to >variableWord (16-bit) so it is mapped to Squeak's variableWord >(32-bit). > >Methods of applications themselves are filed in. >#initializeAfterLoad can sent by the filein to the class and >application and will execute. In addition, #loaded is sent to the >application by the filein. If these methods do dangerous things, be >sure to remove them before the filein. > > >A pool dictionary named CldtConstants is defined and has the same >contents as in IBM Smalltalk; pools for CfsConstants, CgConstants, >and CwConstants are not defined.! " > >Dave > > > >At 10:37 -0500 2/27/01, JArchibald(a)aol.com wrote: >>=> 2/27/01 10:13:43 AM EST, dnsmith(a)watson.ibm.com => >><< ... I moved the code, written in IBM Smalltalk, to Squeak in January, >>using some tools I have for that, and identified 4-5 spots that needed minor >>changes due to differences in exception handling. ... >> _______________________________ >> Any opinions or recommendation herein are those of the author and not of his >>employer. >> >> >>Dave, >> >>Ahem. >> >>Ahhhh, these tools that you mention -- can you in your role as an author >>communicate to us any of their content -- without jeopardy to your role as an >>employee? >> >>Just hoping. :-) >> >>Good luck, >>Jerry. >> >>____________________________ >> >>Jerry L. Archibald >>systemObjectivesIncorporated >>____________________________ > >Attachment converted: Macintosh HD:IBM Smalltalk Fileins.13.cs >(TEXT/R*ch) (00012D45) >-- >_______________________________ >David N. Smith >IBM T J Watson Research Center >Hawthorne, NY >_______________________________ >Any opinions or recommendations >herein are those of the author >and not of his employer.

1 0

Re: JPEG problems
by Ned Konz 27 Feb '01

27 Feb '01

On Tuesday 27 February 2001 11:49, Bob Arning wrote: > Anyone out there interested in trying to extend the JPEGReadWriter to > handle some additional markers? I have gotten on numerous occasions: > > 'marker 16rC2 cannot be handled' > > from JPEGReadWriter>>parseNextMarker. Would be nice if we could deal with > this, whatever it is. It looks like this may indicate a progressive JPEG (that is, if it really means 'marker 16rFFC2'). -- Ned Konz currently: Stanwood, WA email: ned(a)bike-nomad.com homepage: http://bike-nomad.com

1 0

Lot's of pixels are nice to have -- was Re: Project layout
by JArchibald＠aol.com 27 Feb '01

27 Feb '01

All-- I thought I might just go check specs on that Apple 22" Cinema Display that brings out such a sweat in me. And once again, I get to experience the speed of technology change. The display has listed resolution of 1600 by 1024 pixels (and the price is now $2999 -- $1000 less than when released). If you haven't seen one, find one; it's worth the experience just to make a detour. Notheless, this is less than the Dell Inspiron (at 1600 x 1200 pixels) that Jon mentioned earlier (albeit on a much smaller screen). < ;-) > ... maybe when it's $1999, I'll buy it ... </ ;-) > Still dreaming, Jerry. ____________________________ Jerry L. Archibald systemObjectivesIncorporated ____________________________

3 2

RE: Project layout
by Norton, Chris 27 Feb '01

27 Feb '01

I haven't followed this thread very carefully, but I'd like to toss in my 2 bits about projects and their layout. I downloaded the Squeak 3.0 released version for Windows on Friday. It is *really* slick! However, when I went out to Bobs Super Swiki and loaded in some of the sample projects, I found that large portions of the projects were pushed off screen (bottom, right). I run with an 800 X 600. I have weak eyesight, so I prefer to have somewhat larger text and pictures. I think it is unacceptable for the sample projects to be pushed off screen like that. I understand that people with higher resolutions and bigger monitors like to use them to their fullest potential. So I propose that we (someone w/ the skills) should add scroll bars to the world (they would only appear if needed). There are many solutions to this problem, but short of redesigning morphs to be auto-scalable (a la layout frames), this would give us big bang for small bucks. What do y'all think? Cheers, ---==> Chris PS> Alternate ideas: * Grabbable world (like Adobe Acrobat documents -- a tiny gripping hand) * A mini locator window that shows the whole project -- you click in the window and it moves the center of your screen accordingly * Little Arrow buttons in the corners of a project. Clicking on the buttons moves your viewpoint over by some amount.

1 0

RE: Project layout
by G.J.Tielemans＠dinkel.utwente.nl 27 Feb '01

27 Feb '01

Can't you solve the problem by creating an overview window in a lower resolution and a zoom-window that can freely wander around on the big screen? -----Original Message----- From: Alan Kay [mailto:Alan.Kay@disney.com] Sent: Tuesday, February 27, 2001 1:16 PM To: squeak(a)cs.uiuc.edu Subject: Re: Project layout Right you are. Lot's of pixels are nice to have, and so is a phyically big display. Here we were talking about the minimal criterial to do scaling, pdf, readable fonts, etc., and here the pitch plus a few other things is what matters in order not to see artifacts. A display that would be the equivalent of two facing 10" high pages would indeed be about 4M pixels which is the count that Lex mentioned. But most paper notepads or xeroxed papers are 8.5*11 with not all the boundary pixels used, so my calculation covers this physical size. BTW, in the late sixties we were able to compute pretty accurately that the proposed Dynabook (which was about 9*12), which employed its lower quarter with a low travel keyboard and had a squarish display, needed about 1M pixels in order to simulate paper well enough for readability, drawing, and capacity. Cheers, Alan ------ At 5:31 AM -0500 2/27/01, JArchibald(a)aol.com wrote: >=> 2/26/01 10:51:03 PM EST, Alan.Kay(a)disney.com => ><< Actually, a pitch of about 150/inch and using some color selection >trickery will do the job pretty darn well. So a pretty nice display would be >about 1.9 million pixels (8" * 10.5"). >> > >According to my multiplier, this is a screen resolution of 1575x1200 pixels >-- a substantial information content. This is pretty good on all but the very >largest of screens available today (which needless to say, are quite a bit >bigger than 8" x 10.5"). > >Jerry. >____________________________ > >Jerry L. Archibald >systemObjectivesIncorporated >____________________________

2 1

Re: [ENH] BetterTouches
by Bob Arning 27 Feb '01

27 Feb '01

On Tue, 27 Feb 2001 11:22:39 -0500 Joshua Channing Gargus <schwa(a)cc.gatech.edu> wrote: >Fixes a problem with Player>>touchesA:, and also uses a better contact >algorithm than bounding box intersection. The new algorithm uses >BitBlt to determine whether any pixels overlap within the intersection >of two morph's bounding boxes. It also works with rotated morphs. > >Each call to Morph>>touchesMorph: takes approx. 10ms on my 300Mhz G3 >to find whether two ellipses (extent: 300@40) touch (assuming that >their bounding boxes intersect; otherwise it will be much faster) Joshua, I apologize for not giving a better indication of the purpose of #touchesA:. Calling the argument to the method "aPrototypicalPlayer" was meant to indicate that I wanted to know if I touched something that "looked like" the prototype. By removing the test (trueGoal appearsToBeSameCostumeAs: trueNeighbor), you seem to have defeated that intent. I ran a comparison of your code and mine in Osmosis2 (available on BSS). I counted each entry to #touchesA:, each time it answered true and the number of milliseconds to reach 10000 invocations: raa #(10001 807 17354) jcg #(10001 55 16978) As you can see, both versions took about the same time to do 10000 tests, but yours produced significantly fewer touches. While some of this can be attributed to a narrower criteria for "touch" in your code, I believe the greater part is due to ignoring valid hits. I would be interested in seeing how your code performs when returning all valid collisions. One of my goals was to make something fast at the expense of a little accuracy, if need be. Since the morphs in question were small and round, I felt it a reasonable sacrifice. Cheers, Bob

1 0

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

Jump to page: