Squeak-dev January 2003

squeak-dev@lists.squeakfoundation.org

148 participants
312 discussions

[VI4] experimental vm for MacOS X
by Marcus Denker 03 Jan '03

03 Jan '03

Hi, I've build a MacOS X Version for Anthony Hannan's VI4 VM. It's available at http://minnow.cc.gatech.edu/squeak/2119 Seems to work, but there is a problem with AppleScript on startup (just close the debugger...). Marcus -- Marcus Denker marcus(a)ira.uka.de -- Squeak! http://squeak.de

1 0

[FIX] ClassCommentVersionsBrowser fix
by Magistrello Alejandro (SFA) 03 Jan '03

03 Jan '03

The ClassCommentVersionBrowser was not working for all classes (ProcessBrowser is one), it was looking for a commentStamp that get lost after a condenseChanges best Regards Alejandro Magistrello <<ccvb-fix-asm.1.cs>>

2 1

Re: Newbie question: ConstantShapeMorph?
by Bob Arning 02 Jan '03

02 Jan '03

Bill, Mostly right on in your interpretation. On Mon, 30 Dec 2002 15:40:05 -0800 Bill Spight <bspight(a)pacbell.net> wrote: >Let me see if I understand what is going on. > >> You could override the #extent: method to do something like: >> > >In resizing the morph is sent an #extent: message. We make sure the new >extent has the correct proportions. Yup. >> extent: aPoint >> >> x _ aPoint x. >> y _ aPoint y. >> (y * aspectRatio) > x ifTrue: [ >> x _ y * aspectRatio >> ] ifFalse: [ >> y _ x / aspectRatio >> ]. >Doing it this way makes for the greater extent, which is faster when >expanding. I could easily have picked smaller rather than greater. Since it wasn't specified, I flipped a coin. > >> ^super extent: (x@y) rounded >> > >x@y is rounded because drawing requires an integral number of pixels. I think the low-level stuff mostly handles non-integers, but there are at least a few places where fractional coordinates have caused problems for me before, so I tried to be sure the code would run without actually running it. >Sending this message to super avoids the extra processing if it were >sent to self. (And also avoids an infinite loop when rounding). Well, the infinite loop is "the" issue here. If the last line were ^self extent: (x@y) rounded you would be in for a long wait (as in "How long does it take a proton to decay?"). Cheers, Bob

2 2

RE: Programming in a Cloud of Images ( Was: RE: Subjective Squeak )
by Brent Vukmer 02 Jan '03

02 Jan '03

Oops. I presssed 'Send' too soon! What I *meant* to type was: ** Loading Projects ** I'm excited about this because I think that idea of Projects in Squeak is very cool but the experience of unsuccessful-Project-loads is not so cool. As I imagine it, Project windows would be built in the Project Explorer image as follows: (1) Get the URL for the Project image spec (2) Get the URL for the living objects that will be copied into the new Project image (3) Get the URL for the to-be-created Project image (4) Retrieve the Project image spec from URL in(1) (5) Build the Project image to spec, accessible from URL in(3) (6) Import the living objects from URL in (2) into the Project image (7) Create a ProjectWorldMorph in the Project Explorer image Steps (1) through (6) would be cool because the work of building a Project is separated out into nice clear simple steps. Dependencies and in general Project metadata become much more accessible. Also we could easily build Project-subscription tools with this mechanism. I'm still thinking about step (7). Would the cloud of Project images always be headless? I.e., would MVC/Morphic/SomeFutureUI always only be loaded into a Project Explorer image?

1 0

Programming in a Cloud of Images ( Was: RE: Subjective Squeak )
by Brent Vukmer 02 Jan '03

02 Jan '03

Daniel, very interesting -- the current singleton image would become a Project Explorer image communicating with a cloud of Project images, if I understand you correctly. I like this mechanism; it seems like it would be simple, easy-to-understand, robust, re-use alot of proven technology, etc. Also it seems like SqueakMap would dovetail nicely with this approach. Some thoughts: ** Loading Projects ** I'm excited about this because I think that idea of Projects in Squeak is very cool but the experience of unsuccessful-Project-loads is not so cool. As I imagine it, Project windows would be built in the Project Explorer image as follows: (1) Get the URL for the Project image spec (2) Get the URL for the living objects that will be copied into the new Project image (3) Get the URL for the to-be-created Project image (4) Retrieve the Project image spec from URL in(1) (5) Build the Project image to spec, accessible from URL in(3) (6) Import the living objects from URL in (2) into the Project image (7) Create a ProjectWorldMorph in the Project Explorer image Steps (1) through (5) would be cool because the work of building a Project is separated out into nice clear simple steps. Dependencies and in general Project metadata become much more accessible. Also we could easily build Project-subscription tools with this mechanism. I'm still thinking about step (6). Would the cloud of Project images always be headless? ** Programming In Layers ** What are the use cases for programming in switchable layers? I'm trying to think of use cases that this mechanism doesn't address well. ** Unfixably Stuck Images ** A Project Explorer image should be very stable, if it is smart about how it handles its connections to stuck images. One of various Project images in the cloud may freeze, but the rest should be fine. ** Hogging Memory With Big Fat Images ** Headless images built to spec should get Smaller All The Time. Also, I guess the cloud of Project images wouldn't necessarily have to live on the same physical resource; they could live all over the network/Internet, if they communicate in an Internet-friendly way ( and if network/Internet latency ain't a big deal ). -----Original Message----- From: Daniel Vainsencher [mailto:danielv@netvision.net.il] Sent: Saturday, December 21, 2002 4:00 PM To: squeak-dev(a)lists.squeakfoundation.org Subject: Re: Subjective Squeak [snip] ...switchable environments - now that's a Model issue. One PIE paper shows a good role for layers as a model of programming (layers as a programmers product - a unit of code modifications). [snip] ...I am very sorry we still don't have a model as developed as they did for programming. [snip] What our models are is the big question, and how do we start modifying the way we work, to realize them as quickly as possible. Mechanism vs Mechanism The more you talk about switchable layers, the more, I think why not get the same capabilities from richly communicating separate images, reusing the OS/separate VM's protection? About projects - the problem with projects precisely exemplifies the issues at stake. First, you need to have projects be dependent on a specific configuration, and be able to download that automatically (using SM). We're mostly agreed there. Second, you need to be able to activate it, while isolating it properly from your current image. So yes, right now, I know I'd load more projects if they were simply run in a separate, new process. In fact, when I start to think about it, a complete alternate Squeak universe unfolds. Imagine a GUI image, that has all the GUI tools you want, but doesn't generally run the models. The models run on one or more headless images. I have a mail image, and I have a completely separate development image, but their GUIs run on the same image. Most of the browsers and workspaces simply happen to be connected to the development machine. Communications between the image are kept mostly asynchronous, and on simple, standard protocols, and completely for free, you get a Squeak that runs very well on SMP machines. Or distributed across a network. And yet at any time, you can connect a browser and an object explorer to a specific image, and KNOW, that in front of you within this address space, is something as simple as a completely self consistent Smalltalk, separate from the rest of the world, except for the above communications. Daniel

1 0

[BUG] Mac-VM 3.4.0Beta2 crashes
by Marcus Denker 02 Jan '03

02 Jan '03

Hi, The newest Mac VM (Squeak 3.4.0Beta2) crashes when I try to turn "full screen" on. Does anyone else has the same problem? This does not happen with every image, but if it happens it is reproducable. (I have saved one of those images and I could upload it somewhere) The Crash-Reporter log is attached. Marcus -- Marcus Denker marcus(a)ira.uka.de -- Squeak! http://squeak.de

1 1

[BUG][FIX] macroBenchmark workaround
by Marcus Denker 02 Jan '03

02 Jan '03

Hi, Here's a quick fix to make the macroBenchmarks work again. The Benchmark tried to garantee exactly 10MB of free space by allocating "Smalltalk garbageCollect - 1e7" bytes. This does not work on newer VMs, because memory grows and shrinks as needed. This changeset simply removes all code related to this as a quick workaround. -- Marcus Denker marcus(a)ira.uka.de -- Squeak! http://squeak.de

1 0

Question about change set 5051u62, regarding #classComment:
by Nevin Pratt 02 Jan '03

02 Jan '03

In change set 5051u62, the implementation of ClassDescription>>classComment: was changed from: classComment: aString ^ self classComment: aString stamp: '<historical>' to classComment: aString aString isEmptyOrNil ifFalse: [self error: 'class comment set without stamp']. ^ self classComment: '' stamp: 'ignored' This change effectively breaks Squeak from being able to file in VisualWorks 3.0 chunk format fileins. I have found the interoperability for fileins between VW and Squeak to be very useful. In fact, my Squeak GLORP port just uses the VW GLORP filein directly. But, this change broke that ability. So, what was the rationale for making that change in Squeak? Is there any chance we can get it set back to what it was? Nevin

2 1

[ENH] QueueSoundComment-efc
by cottonsqueak＠earthlink.net 02 Jan '03

02 Jan '03

from preamble: "Change Set: QueueSoundComment-efc Date: 2 January 2003 Author: Eddie Cottongim A class comment for QueueSound."!

1 0

File closing annoyances
by Tim Rowledge 02 Jan '03

02 Jan '03

I've been trying to see if I can rid the image of the obscenity known as #readOnlyCopy with, unfortunately little luck so far. It's not so much a problem with excising #readOnlyCopy as such as the fairly pervasive assumption that files can be opened again and again and again. Unfortunately it is not always true that you can open a file already opened. However, one place that really caught my eye whilst digging around was the rather odd seeming close-and-reopen process whenever changes are flushed to the changelog. This is despite the use of an explicit flush method... (see SystemDictionary>forceChangesToDisk or similar) Does anyone know if this oddity is still required, or why it is used? Can it be dropped? tim -- Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: MW: Multiply Work

3 4

Jump to page: