Squeak-dev April 2000

squeak-dev@lists.squeakfoundation.org

141 participants
506 discussions

Re: Toward version 2.8
by Conrad Taylor 03 Apr '00

03 Apr '00

How are you doing? I was wondering, would it best to download 2.8b and the below changesets to it? Could I receive the below changesets? Finally, is their a build that includes all of the workable changesets thus far? Thanks in advance, -Conrad --- "R. A. Harmon" <harmonra(a)webname.com> wrote: > At 10:10 AM 4/2/00 -0700, Dan Ingalls wrote: > >We're converging on a plan for Squeak 2.8, so I > thought I would let you > know how it looks. > [snip] > > I suggest also adding my implementation of the ANSI > methods missing from > Squeak. I can send you a change set of it. > > It currently includes the Fundamental, Valuable, > Exception, Numeric, and > Date And Time Protocols. > > The missing Collection, Stream, and FileStream > Protocols can be added when > finished. I am updating the Collection > implementation for a previous > version and will finish the Stream, and FileStream > Protocols. > > -- > Richard A. Harmon "The only good zombie is > a dead zombie" > harmonra(a)webname.com E. G. McCarthy > Spencer, Iowa > > __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com

1 0

Re: [BUG] [FIX] Semaphore hash
by Tim Rowledge 03 Apr '00

03 Apr '00

Wim Boot wrote: > > I think Semaphore comparison (including #hash) should be identity > based, not content based. I agree with Wim; I hit this problem when cloning the image a while ago. There seems to me to be a problem with making a hash values depend on content of a mutable object - change the content and any collection holding the object is now messed up (from the point of view of using the hash to access it). Semaphores are pretty dynamic and so the first and last (or any other) element will likely not stay the same for long, and the hash would not match for long. We did have a short thread on this subject when I hit the problem last year, but no real resolution. tim

1 0

REMOVE FROM LIST
by 93CRAIGJ＠poolegram.dorset.sch.uk 03 Apr '00

03 Apr '00

REMOVE THIS ADDRESS FROM LIST IT IS UNKNOWN 93meineckd(a)poolegram.dorset.sch.uk Carol Cox Network Administrator Poole Grammar School chc(a)poolegram.dorset.sch.uk

1 0

[ENH][Pref] acceptWithPrettyPrint
by Stephan Rudlof 03 Apr '00

03 Apr '00

Dear Squeakers, now it also supplies 'prettyPrint' for selections of code... Stephan "Change Set: acceptWithPrettyPrint Date: 3 April 2000 Author: Stephan Rudlof, Torge Husfeldt This changeset introduces preferences #acceptWithPrettyPrint and #prettyPrintForSelections. If #acceptWithPrettyPrint is set to true, browsers will automatically format their contents before accepting it (without color). This works both in Morphic and MVC projects. If #prettyPrintForSelections is set, prettyPrint'ing *selections* of text is allowed. This avoids unformatted sources. Often you type in a method on the fly and leave the formatting to the Browser by setting the preference #acceptWithPrettyPrint to true. But the sources remain ugly. Using this preference is simpler as using the menu methods 'pretty print' or 'pretty print with color'. In addition to the 'pretty print' menu methods formatting works also for new methods. Note: - Includes changeset acceptPrettyPrint from Torge. - Browser>>defineMessageFrom:notifying: just overwrites wrong changes from first version of this changeset. " -- Stephan Rudlof (sr(a)evolgo.de) "Genius doesn't work on an assembly line basis. You can't simply say, 'Today I will be brilliant.'" -- Kirk, "The Ultimate Computer", stardate 4731.3

1 1

[ENH][Pref] acceptWithPrettyPrint
by Stephan Rudlof 03 Apr '00

03 Apr '00

Dear Squeakers, now there is a - hopefully - correct 'acceptWithPrettyPrint' changeset... Special thanks to Torge! Stephan "Change Set: acceptWithPrettyPrint Date: 3 April 2000 Author: Stephan Rudlof, Torge Husfeldt This changeset introduces preference #acceptWithPrettyPrint. If set to true, browsers will automatically format their contents before accepting it (without color). It works both in Morphic and MVC projects. This avoids unformatted sources. Often you type in a method on the fly and leave the formatting to the Browser by setting the preference #acceptWithPrettyPrint to true. But the sources remain ugly. Using this preference is simpler as using the menu methods 'pretty print' or 'pretty print with color'. In addition to the 'pretty print' menu methods formatting works also for new methods. Note: - Includes changeset acceptPrettyPrint from Torge. - Browser>>defineMessageFrom:notifying: just overwrites wrong changes from previous versions of this changesets. " -- Stephan Rudlof (sr(a)evolgo.de) "Genius doesn't work on an assembly line basis. You can't simply say, 'Today I will be brilliant.'" -- Kirk, "The Ultimate Computer", stardate 4731.3

1 0

Re: [ENH][Pref] acceptWithPrettyPrint
by Stephan Rudlof 03 Apr '00

03 Apr '00

Hello Torge, your changeset has led me to the right idea. After some trial&error now I have a working solution! See my posting without 'Re:' (to get it into the update stream...). Greetings, Stephan Torge Husfeldt wrote: > > Hello Stephan. > O.K. there are still problems with automaticly formatting a new method on > accept. > But as a first step we might allow the programmer to prettyPrint any > not-yet-accepted > text in the browser. Right now the menu-items prettyPrint and > prettyPrintWithColor > try to fetch the sourceCode first which is IMHO a Bad Idea(tm). > > Gruss, > Torge > P.S.: maybe we can put this on the first page of the menu (and maybe even > assign a hotKey)? > ----- Original Message ----- > From: Stephan Rudlof <sr(a)evolgo.de> > To: ML Squeak <squeak(a)cs.uiuc.edu> > Sent: Sunday, April 02, 2000 7:04 AM > Subject: [ENH][Pref] acceptWithPrettyPrint > > > Dear Squeakers, > > > > please don't use the previously posted 'acceptWithPrettyPrint' changeset > > (see below)! > > > > It doesn't work as it should, if there are temps missing in the method > > which has to be accepted. Possibly there are more errors. > > > > There doesn't seem to be an easy way to solve the problems: > > Compiler>>format:in:notifying:decorated: > > doesn't return the argument string fully formatted to give it so to > > ClassDescription>>compile:classified:notifying: > > then. > > If using > > Compiler>>format:in:notifying:decorated: > > like in the changeset, then after formatting the correct, but > > unformatted code is in the Browser and the formatted, but incorrect code > > transfered to > > ClassDescription>>compile:classified:notifying: > > . That's bad! > > > > Some guys seem to work at Parser/prettyPrint tools - and now I think I > > know, why! -, so I don't want to invest more time to solve these > > problems. > > > > Stephan > > > > I wrote: > > > > > > "Change Set: acceptWithPrettyPrint > > > Date: 1 April 2000 > > > Author: Stephan Rudlof > > > > > > This changeset introduces preference #acceptWithPrettyPrint. > > > If set to true, browsers will automatically format their contents before > > > accepting it (without color). > > > > > > This avoids unformatted sources. > > > > > > Often you type in a method on the fly and leave the formatting to the > > > Browser by setting the preference #acceptWithPrettyPrint to true. But > > > the sources remain ugly. > > > > > > Using this preference is simpler as using the menu methods 'pretty > > > print' or 'pretty print with color'. > > > > > > In addition to the 'pretty print' menu methods formatting works also for > > > new methods. > > > " > > > > > > -- > > > Stephan Rudlof (sr(a)evolgo.de) > > > "Genius doesn't work on an assembly line basis. > > > You can't simply say, 'Today I will be brilliant.'" > > > -- Kirk, "The Ultimate Computer", stardate 4731.3 > > > > > > ------------------------------------------------------------------------ > > > Name: acceptWithPrettyPrint.1.cs > > > acceptWithPrettyPrint.1.cs Type: unspecified type > (application/octet-stream) > > > Encoding: base64 > > > > -- > > Stephan Rudlof (sr(a)evolgo.de) > > "Genius doesn't work on an assembly line basis. > > You can't simply say, 'Today I will be brilliant.'" > > -- Kirk, "The Ultimate Computer", stardate 4731.3 > > > -- > Der Mensch kann wohl tun was er will, > aber er kann nicht wollen was er will. > > ------------------------------------------------------------------------ > Name: acceptPrettyPrint.1.cs > acceptPrettyPrint.1.cs Type: unspecified type (application/octet-stream) > Encoding: quoted-printable -- Stephan Rudlof (sr(a)evolgo.de) "Genius doesn't work on an assembly line basis. You can't simply say, 'Today I will be brilliant.'" -- Kirk, "The Ultimate Computer", stardate 4731.3

1 0

Re: Morphic Doc -- Eye Candy II
by Martin B. Pomije 03 Apr '00

03 Apr '00

Tim Rowledge wrote: > > On an auspicious day called Thu 30 Mar, Jim Benson wrote: > > http://minnow.cc.gatech.edu/squeak/1311 . > > Jim, you're my kind of curmudgeon. To paraphrase a friend of mine "I like you, > You're _funny_". > Somebody give this man a column in Wired, now, right now! > > tim > Yes, please put this sort of hate filled ranting in WiReD, where I won't be exposed to it and nobody will be able to read it. http://www.salon.com/12nov1995/comix/comix3.html Stallman, for all of his personality faults, doesn't engage in these sort of cheap personal attacks. I do think that the essay had a point about the counter productive chrome that is in Linux GUI's.

1 0

RE: [BUG][FIX][UNIX] VM bugs and make problems
by dpennell＠quallaby.com 02 Apr '00

02 Apr '00

Has anybody looked at how hard it would be to update the Unix VM to run headless via a command line switch like the Windows VM does? -david > -----Original Message----- > From: Bert Freudenberg [mailto:bert@isgnw.CS.Uni-Magdeburg.De] > Sent: Friday, March 31, 2000 4:47 AM > To: squeak(a)cs.uiuc.edu > Subject: Re: [BUG][FIX][UNIX] VM bugs and make problems > > > On Thu, 30 Mar 2000, Michael Rueger wrote: > > > 2) The target headless in the make file is missing > > You have to run "../conf/configure --without-x" manually from > the build > directory ... But you're right, that's not obvious, and there are some > minor (known) bugs - like HEADLESS not getting defined with certain > autoconf versions. A workaround is to put this on top of sqXWindow.c: > > #ifndef HAVE_LIBX11 > #define HEADLESS > #endif > > > Andreas hacked a workaround, but maybe one of the countless ;-) > > config/make wizards can fix this? > > You could automate this by inserting the following in the toplevel > Makefile: > > reconfigheadless@: > @$(MAKE) CONFARGS=--without-x reconfig > @-/bin/rm -f $(TARGET)/sqXWindow.o > > Then you just have to type "make reconfigheadless squeak" to build a > headless vm. > > -Bert- >

4 3

Re: [ENH][Pref] acceptWithPrettyPrint
by Henrik Gedenryd 02 Apr '00

02 Apr '00

Torge Husfeldt wrote: > But as a first step we might allow the programmer to prettyPrint any > not-yet-accepted > text in the browser. Right now the menu-items prettyPrint and > prettyPrintWithColor > try to fetch the sourceCode first which is IMHO a Bad Idea(tm). Wouldn't it be a good idea if the pretty printing were applied to the selected text only?. Often you just want its help with that nasty multi-argument message, and not the rest. If no selection, then pp it all. Henrik

1 0

RE: BitmapFillStyles
by Raab, Andreas 02 Apr '00

02 Apr '00

Jim [Sorry for not responding earlier - this message just dropped down the list too fast and I found it again when actually looking for a different message] In theory, the origin of a BitmapFillStyle (or any OrientedFillStyle) should be relative to the origin of the shape it fills. However, in an attempt to make these fill styles work in Morphic and be compatible with the already existing InfiniteForms (stored, of course, in the instVar #color - ouch!) this definition was screwed up so that there is a significant difference in how the origin is interpreted in other-than-flash-morphs. For the common morph (Morphus ordinarius?!), the origin is really the global origin, so that a BitmapFillStyle starting at the filled morph's upper left corner has an origin equal to the morph's boundingBox origin. Note that the above also requires to fix up a Morph's fill style if it is moved since the origin of the fill style has to move as well to stay in sync with the origin. This happens in Morph>>privateMoveBy: and is a pretty ugly hack (but the only way to keep the InfiniteForms working, since they are always relative to 0@0). It's likely that your problem is coming from this - assuming that you have two fill styles it's possible that one gets actually adjusted (if it was installed using #fillStyle:) and the other one not (only the #fillStyle is adjusted). To check this out you could just assign the origin in the #drawOn: method to make sure both fill styles are positioned accordingly, e.g., MyMorph>>drawOn: aCanvas self fillStyle1 origin: (self origin). self fillStyle2 origin: (self origin + (1@1)). aCanvas fillRectangle: self bounds fillStyle: self fillStyle1. aCanvas fillRectangle: self bounds fillStyle: self fillStyle2. If the above doesn't help, feel free to send the code around that you're actually working on - the solution is probably simple. - Andreas > -----Original Message----- > From: Jim Benson [mailto:jb@speed.net] > Sent: Wednesday, March 29, 2000 8:50 PM > To: Squeak > Cc: recipient list not shown > Subject: BitmapFillStyles > > > Hi, > > My question is how does the #origin: in a BitmapFillStyle > work? Let's say that I have two identical patterned bitmaps > that I way to keep registered in relationship to each other. > In other words, when I lay one on top of the other, I want > the pattern to appear seemless. From what I've seen in the > code, people seem to put the origin at the bounding box > origin. However, the only way that I've been able to get > it to work is to set the origin to 1@1. And I have to reset > the origin to 1@1 to get it to line up correctly after I > move it. > > I guess I don't understand how to use #origin: > > Jim Benson >

1 0

Jump to page: