Squeak-dev March 2002

squeak-dev@lists.squeakfoundation.org

169 participants
610 discussions

[ENH] ScamperPanesMod-sbw
by swessels＠one.net 29 Mar '02

29 Mar '02

from preamble: "Change Set: ScamperPanesMod-sbw Date: 29 March 2002 Author: Stephan B. Wessels Updates the Scamper window building code so that it uses fixed height panes for the button bar, status line and URL line. No attempt is made with this change set to modify the buttons to agree with the new preferences option. This is a very simple change that keeps the resizing of these panes from being proportional."!

1 0

universalTiles and self references
by Ned Konz 29 Mar '02

29 Mar '02

Ordinarily, when you do the scripting, references to a Player from within that Player's scripts become self references (i.e. if I have a Player named "Car" then when I drag a phrase Car doSomething into a script the code becomes self doSomething I've noticed that when you set the Preference "universalTiles", this doesn't happen properly; the reference remains to Car rather than to self. Is this intentional? -- Ned Konz currently: Stanwood, WA email: ned(a)bike-nomad.com homepage: http://bike-nomad.com

2 1

Squeak on new Zaurus?
by Michael Rueger 29 Mar '02

29 Mar '02

Hi all, a friend of mine just got one of these neat little machines and would like to try Squeak on it. Is there a pre-packaged version he could download and install? Thanks Michael

2 1

Re: Lego Mindstorm and Squeak
by Bob Arning 29 Mar '02

29 Mar '02

On Fri, 29 Mar 2002 10:10:39 -0800 Ned Konz <ned(a)bike-nomad.com> wrote: >On Friday 29 March 2002 10:02 am, Ned Konz wrote: > >> "Foreground process" >> >> [ >> queue size > 0 ifTrue: [ Transcript show: queue next ]. >> World doOneCycle. >> ] repeat. > >er, make that > > queue size > 0 whileTrue: [ Transcript show: queue next ]. er, make that [queue size > 0] whileTrue: [ Transcript show: queue next ]. Cheers, Bob

1 0

Re: Real printing plugin?
by Richard A. O'Keefe 29 Mar '02

29 Mar '02

I replied to Marcel Weiher, noting FOR CONTEXT that > I complained, nearly 2 weeks ago, about dramatic differences > between what I see on screen and what I get with "save PS". Marcel Weiher <marcel(a)metaobject.com> continues his attack. I must have overlooked the part of our support contract the specifies the guaranteed response times. I do not expect any support from Marcel Weiher. In fact, I don't expect any practical help from him at all. The point is that it is relevant to a discussion to note a two week gap. In particular, I had to reconstruct some of my examples. > Marcel Weiher <marcel(a)metaobject.com> replied: > > I don't think 'screen inches' are a very useful measurement. > > In the name of sanity, whyever not? If you don't know why it is not a good measurement, then I am not sure if there is any point in continuing this. What _is_ the point of this ad hominem attack? My problem is PRECISELY that there is a dramatic size discrepancy between what I see on the screen and what I get on the paper, and there seems to be no direct way to control this. The fact that N screen inches turn into KN paper inches (K > 1) is precisely my problem. I am *not* attempting a diagnosis. Well, on the Mac, the screen resolution is defined as exactly 72 dpi. This means that if your screen resolution is 96 dpi, you have a scaled-down view and cannot expect things to match 1:1 anyhow. This isn't exactly true. *Parts* of MacOS assume exactly 72 dpi, but parts do *NOT*. This is quite clear in Apple's documentation. The physical reality is that the resolution is 96 dpi. The computational reality is that SQUEAK CAN EASILY FIND THIS OUT. > Does "approximately 192 pixels on a > side" make it any better? No. The actual number of pixels would make it better. This is because Squeak has no idea about inches, its only measurement for screen objects is PIXELS. Squeak does not have a device independent imaging model. Yes, but I am not TALKING about Squeak's imaging model. I am talking about observable physical phenomena. I make no pretence of understanding what the heck is "really" goin on inside the box. I went to some pains to show that on each of the three main platforms Squeak *COULD* know what the physical dimensions are. Many people have complained in the past about the tiny, hard-to-read, nature of Squeak's default fonts, which assume 72 dpi. That's another area where Squeak SHOULD take physical dimensions into account, and select font sizes appropriately. By the way, I note that Ghostscript comes with commercial-quality versions of the 35 "standard" Postscript Level 2 fonts. It should be possible to automatically derive StrikeFonts from these, no? > It's quite a precise description. No it is not. Do you want help or do you just want to bitch? Is every request for help to be attacked? Is every self-defence to be constructed as bitching? > The effect is not sensitive to details. Yes it is. You may not be aware of the fact, but it is. I have tried it repeatedly, and for me, it is NOT sensitive to details. I think the burden of proof is on someone who says it is sensitive to details. In what way is this effect sensitive to details? > 1. Create a BookMorph. > 2. Drop a TextMorph in it. > 3. Make the font of the TextMorph New York 12. > 4. Stretch the thing so that it's about 2 inches (5 centimetres) > on a side. Once again, 2 inches on a monitor is not a useful description, because a monitor is not a calibrated device. It IS a useful description, because it is a measurement to be applied BY A PERSON, not by Squeak. It simply doesn't matter whether Squeak knows what the size is or not. If you set your screen resolution to 96 dpi, then follow the steps I listed, you will end up quite reproducibly with the situation I described. Squeak has no way at all of knowing how large (in inches) something it draws will be on your monitor. None at all. As I went to some trouble to point out, this isn't even close to true. Squeak may not *ASK*, but the information is *THERE* to be had. (OK, not to micron accuracy, but close enough to be useful.) Not that it's relevant here, because the measurement is a measurement to be made by a person, not by Squeak. > 5. Type some text. OK, the steps are easy to reproduce (apart from the "inches" part). > > Save PS in file, drop file onto MacGS. The result is > > nearly 4 inches on a side. > > So you're seeing a factor of 2? > > Yes. Well, I checked, and found this: "Define initialScale so that the morph will fit the page rotated or not" savedMorphExtent _ morphExtent _ rotateFlag ifTrue: [psBounds extent transposed] ifFalse: [psBounds extent]. in DSCPostscriptCanvas>>writePSIdentifierRotated:: So the effect is, in fact, due to a scale-to-fit option. Great. The important thing is that this is a scaling THAT I DID NOT REQUEST. When you choose "Print PS to file" you are prompted - for file name (sans suffix) - for orientation but not for scaling. A bit below that, you can see how to turn this off: initialScale _ (printSpecs isNil or: [printSpecs scaleToFitPage]) ifTrue: [ pageExtent x/morphExtent x min: pageExtent y/morphExtent y ] ifFalse: [ 1.0 ]. So it seems there is some kind of print-spec that can turn scale-to-fit on or off, with the default being on. Not in 3.0.1 there isn't. However, printSpecs is actually never written, so it looks like some functionality was intended here but not completed. Ah. So I'm not the only one to want this feature, and I'm not the only one to spend half a day getting lost trying to plug it in. > I would point out that my screen SIZE is not at issue, my screen > RESOLUTION is. Yup. And Squeak has no way of knowing your screen resolution. It can do a lot better than it does do. EXACTLY. It seems you DO understand why "screen inches" is not a useful measurement. Not at all. Screen inches is not only a useful measurement, it is the MOST useful measurement in this context. Because that's what I care about. Pixels are only a means to an end. I have no way of counting pixels for myself, but I _can_ put a ruler up against the screen. > The X11 system has, since its introduction, made it easy for any > application > that cares to discover the actual resolution of a display. This is also just a guess, since there is no feedback channel back from the screen to the computer. (a) Are you really sure about that? What law of physics says that NO screen can have a feedback channel to ANY computer? (b) xdpyinfo seems to come up with the right number. Call it a guess if you like, but it's a *heck* of a lot better than guessing 72 all the time. (c) I note that the screen resolution is electronically controllable. Whether there is a feedBACK path or not, there is a feedFORWARD path, and the computer can know what resolution it last told the screen to use. On the Mac, a pixel is defined to be precisely 1/72 of an inch. If you have different dpi, you are, technically, out of spec. and will get images that are proportionally shrunk. Not true. Some MacOS components use 1/72" *as their logical unit*. The desk accessory that sets the screen resolution is one provided by Apple, and it is quite explicit in the Apple Developer web pages that users are _intended_ to use that desk accessory and applications are _intended_ to respond to it. It is also irrelevant, since Squeak does not use a device-independent imaging model. Meaning that when you specify dimensions in Squeak, they are in PIXELS, and will come out whatever the size of pixels are on your current display device. That's the problem. Someone may kvetch that the methods I described for finding physical resolution are "only guesses", but they are BETTER guesses than 72dpi-all-the-time. [more bitching removed] > I have shown above how easy it is to come up with a mapping that > preserves > more (but still not enough) of the appearance that one wishes to > preserve. This is what I suggested you do. Why did you have to bitch about it instead of just doing it? FOR HEAVEN'S SAKE! He tells me how to do something. I *do* it, showing that I paid attention, and offer the result for general use, and he calls such a response "bitching"! It looks very much as though anything I say will be interpreted by Marcel Weiher as "bitching". I could praise Squeak to the sky, and it would be "bitching". I wish this MUA understood kill-files. I have a better idea: publish your improved mapping as an [ENH] to the list. Well, then maybe Squeak just isn't for you... In short, only test pilots are allowed to use Squeak. Nobody is allowed to ask for help. Gosh, this character has made me angry. Look, I am not a Squeak expert. I don't pretend to be. I like Squeak very much. I tell people how wonderful it is. But sometimes I need help, and I really don't appreciate being stomped all over when I do that.

5 6

[BUG] Problem with FileDirectory>assureExistence (etc)
by Tim Rowledge 29 Mar '02

29 Mar '02

In 3.2#4743 (the latest so far as I can tell) there is an infinite recursion in FileDirectory>assureExistence. I've been able to recreate this on Acorn, Mac & unix - can't try windows. To see the problem try the logical equivalent of:- FileDirectory on: '/wibbly/foo' {unix - make sure you don't actually have /wibbly!} FileDirectory on: '<name of disk you dont have>:fooble' {Mac} FileDirectory on: 'adfsbang::$/fooble/wiz' {Acorn - yeah right, like you have one} The problem is that we get to the root of the faulty path and then keep repeating it; either with '' or '/' depending on the OS. I guess there needs to be some extra check for the top of the possible tree (unix) and/or faulty root names (Acorn, Mac). I'm not sure what a really clean answer is right now and I'm a bit busy right now so I'll leave it as an entertaining exercise for some reader :-) tim -- Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: DUL: Delete Utility Library

4 7

RE: [ENH] vt100Telnet
by Norton, Chris 29 Mar '02

29 Mar '02

Hi Felix. This is *very* cool. Using your telnet machine, I was able to do some basic Unix admin stuff on a Solaris machine from my Windows NT box via Squeak. I could 'ls', 'more' files, 'cd' to different directories and even use 'vi'. Thank you! :-) Cheers, ---==> Chris PS> Though I was able to file this into 3.2 gamma, it would not load into the latest 3.3 alpha image. I suppose that's due to modules. PPS> The telnet session was quite a bit slower through your morph than it is from the Windows NT telnet client. I didn't take the time to debug this... perhaps another night. One thing I did want to do, was to make the font bigger (my eyesight isn't what it used to be). If you end up extending this feature, I would request that you add some font size stuff to your telnet client menu. Thanks!

3 2

Squeak - Combining Media and Technology in Education by Andreas Raab
by ducasse 29 Mar '02

29 Mar '02

Hi, Just to let you know that Dr Raab (previously Disney Engineering) will give a talk in the context of the University of Berne Kolloquium the 16th of April 2002 at 17h15 at the IAM room 002 http://www.iam.unibe.ch/ Title: Squeak - Combining Media and Technology in Education Dr. Raab: www.impara.de Andreas.Raab(a)gmx.de Summary: Squeak www.squeak.org is a multi-media authoring system for "children of all ages". Aimed at designing media-spaces in an educational context, Squeak provides a rich learning experience reaching from fourth-graders up to professional software engineers. The talk will consist of two parts. In the first part, a demonstration of the capabilities of Squeak, its use for designing media-rich environments and its use "in the classroom" is given. No specific CS knowledge is required in order to understand the presentation. In the second part, architectural implications of media-rich software environments are discussed, including aspects of object-oriented design, shared collaborative spaces, and support of widely varying hardware architectures. Participants should have working knowledge of component-architectures, object-oriented languages and their applications. Bio: Dr. Raab enjoys combining technology, media, and education in order to support live-long learning for children and adults, groups and organisations. He is a specialist in computer graphics, software architecture and their application to media-rich environments. In 1998, Dr. Raab received a PhD in Computer Science from the University of Magdeburg, Germany, where his research was focused on novel interaction and visualisation techniques for virtual environments. He also received a diploma (Msc) from the Univ. of Magdeburg in 1994. Dr. Raab joined Disney in 1998 where he worked with computer visionary Alan Kay building "Squeak", a media authoring environment for children of all ages. Working with an inspired group of collegues (including Dan Ingalls and Ted Kaehler, two of the original inventors of the Smalltalk programming language) he made major contributions in the areas of media integration, system architecture and interaction techniques. After leaving Disney, Dr. Raab returned to Europe and founded Impara, a company devoted to bringing educational technology to children in Europe. His current work is focused on making creative media environments available in schools and exploring the possibilities of shared virtual environments for education.

1 0

Interesting Locking Problem
by Ross Boylan 29 Mar '02

29 Mar '02

I have two smalltalk processes that sometimes write the same data. Further, each process may write recursively; in the course of handling one write, it will attempt other writes. I need to permit the recursive writes within a process while blocking activity between the processes. I would appreciate advice about how best to do this. My current approach has a small vulnerability, and it's not clear to me how to correct it. Further, it already seems a bit elaborate. I implement locking on the class side of one of my classes: lock "Acquire a Lock for the invoking Process, waiting as necessary" [ProcessLock notNil and: [ProcessLock ~~ Processor activeProcess]] whileTrue: [ (Delay forMilliseconds: 300) wait. ]. ProcessLock _ Processor activeProcess. UpdateLocks _ UpdateLocks ifNil: [1] ifNotNil:[UpdateLocks+1]. The ProcessLock class variable permits the original process to get recursive locks, and the UpdateLocks variable keeps track of when we're really done. unlock "Permit activity in the update process" self assert: [UpdateLocks > 0]. "and it should not be nil" self assert: [ProcessLock == Processor activeProcess]. UpdateLocks _ UpdateLocks-1. UpdateLocks = 0 ifTrue: [ ProcessLock _ nil. ] The problem is that these operations need to be atomic and they aren't. For example, in lock ProcessLock might test as nil, but then the other process might reset it before the first process does. For the truly paranoid, even UpdateLocks _ UpdateLocks-1 is not safe (maybe it is, given the VM, but I don't know that). I thought of adding a Semaphore and using critical: to protect the entire method, but this could lead to deadlock: Process A sets the ProcessLock (waiting and then signalling the semaphore). Process B enters the critical section, but does not exit it since it is in the loop waiting for ProcessLock to be nil) Process A attempts a recursive write operation. It begins by invoking the lock method, which waits on the semaphore. Since B has not finished its critical section, there are no spare signals, so A is blocked. For one of the processes there is a natural place to use a top-level lock, but for the other there is not; hence the need to deal with recursion. I suppose if I could restructure it to get a top level for the other process I could use a conventional mutex and be done. Any other ideas?

3 3

The bare minimum??
by Mayuresh Kathe 29 Mar '02

29 Mar '02

Hi, Which are the bare minimum (most required) files to run Squeak? I guess, other than the image, VM and changes nothing else would be really required, isn't it? There is a file called NPSqueak, its around 733Kb, what is that used for? (after I moved it out of the Squeak folder, Squeak continued to work) Is there any way to have an ultra fast yet shrunk wrapped VM? (current one is around 1Mb in size :) Eagerly awaiting your replies. ~Mayuresh

4 5

← Newer
1
...
5
6
7
8
9
10
11
...
61
Older →

Jump to page: