Squeak-dev October 2006

squeak-dev@lists.squeakfoundation.org

175 participants
305 discussions

[ENH] MorphMessageFix
by rhawley＠plymouth.ac.uk 05 Oct '06

05 Oct '06

from preamble: "Change Set: MorphMessageFix Date: 5 October 2006 Author: rhawley First Matter ---------__-- Morphic scripts can send messages like forward: to Morphs, but currently, if this is done as Smalltalk code it does not always work because the morph needs to relay the command to its costume, but if the costume does not yet exist it will need to be explicitely created. The separation of 'player' and 'costume' means that a morph cannot currently directly respond to player messages; as the trick of trapping the doesNotUnderstand: is already being used for morphic's tile based scripts, it seems reasonable to use the same type of technique so that we can write code that properly treats morphs as first class objects (as they were intended to be). So, with this fix we can straight forwardly do things like: X := EllipseMorph new. X openInWorld. X lowerPen; turn: 135; forward: 500 Second Matter ---------------- The naming of Morphs is currently not fully developed or very convenient to use. The fix to the SimpleButtonMorph makes it possible to reference a morph by using: (World morphNamed: #Jim) forward: 99 assuming that you have bought up the halos and edited a morph's name to be Jim. (This also makes use of the first fix to relay the forward: message.) " !

1 0

Re: Re: [Q] [Q] StrikeFontSet display problem for separators in 3.8
by "S.J.Chun" 05 Oct '06

05 Oct '06

First, I've already fixed my problem with resetting minascii value of original fonts. Second, for my image, asa my previous mail said, that's all I did for producing problem. I think original accufont package in SqueakMap does have this problem, which I'm not sure on this. I've downloaded Squeak 3.8 and updated to 3.8.1(?) and installed accufont package from SqueakMap. Hope this can help you. ----- Original Message ----- From: Yoshiki Ohshima <yoshiki(a)squeakland.org> To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Sent: 06-10-02 18:46:15 Subject: Re: Re: [Q] [Q] StrikeFontSet display problem for separators in 3.8 > I've found the source of the problem. When glyph of a character is > requested and the character's ascii value is less than font's minimum > ascii value, then ? is returned. This is why ? is displayed for tab or > other special characters. Hmm. while it is true, the Accujen fonts in 3.8-6665 are tweaked so that they have 0 as their minAscii. ((StrikeFont allInstances) select: [:e | e familyName beginsWith: 'Accujen']) collect: [:f | f minAscii] => #(0 0 0 0 0 0) Now I can't point exactly, but the installation script of m17n system has expression to change the minAscii value of fonts. (and also...) ((StrikeFont allInstances) select: [:e | e familyName beginsWith: 'Accujen']) collect: [:f | f maxAscii] => #(255 255 255 255 255 255) Can you tell me a bit more to reproduce the problem? -- Yoshiki

1 0

Re: Re: [Q] [Q] StrikeFontSet display problem for separators in 3.8
by "S.J.Chun" 05 Oct '06

05 Oct '06

1 0

Image Freeze on startup
by Keith Hodges 05 Oct '06

05 Oct '06

I am getting a regular problem (3.8-6665) when I load a chunk of new code into an image, I figure I will save that image before testing it out. Then on startup, a walkback occurs because some of the loaded code #startUp has broken. This leaves me with a saved image, which when started appears to be ok, but I have no UI. It does not respond to mouse keyboard or keyboard interrupts. I thought of starting the image with a script on the command line to restart the UI process or something similar. any ideas? Keith ___________________________________________________________ All New Yahoo! Mail Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html

1 0

Shared Variables in Monticello Package
by Chad Nantais 05 Oct '06

05 Oct '06

Is there a way that a Monticello package can automatically initialize a class or a set of shared system variables when it gets loaded into an image? I have build a package that relies on setting shared variables. I've got it so they can be set by initializing the class that depends on them. I just don't want to have to initialize the class manually whenever I load the package into another image if I don't really have to. Thanks in advance. Chad

2 1

OOPSLA 2006 BoF!
by goran＠krampe.se 04 Oct '06

04 Oct '06

Hi folks! Since I am attending OOPSLA :) I want to make sure we get a GREAT BOF this year! So I just edited the Swiki page on OOPSLA: http://minnow.cc.gatech.edu/squeak/2390 ...and created the page for this years OOPSLA: http://minnow.cc.gatech.edu/squeak/5864 So... when exactly do we hold it? I quote Dan: "I think we have a tradition of doing it just after supper (ie 7:30-ish) the night before the "social event", unless it conflicts with something else we like." AFAICT that would mean tuesday 7.30. The "special event" is on wednesday evening. And is there anyone willing to act as "conferencier" (or whatever it is called to present the speakers and then harass them so that they quit in time) for the BOF from the board? I could do it otherwise but will gladly accept help in finding a room and a projector etc. And finally of course - sign up on that page if you want to show us something cool! regards, Göran

6 9

re: Spoon development process
by Craig Latta 04 Oct '06

04 Oct '06

Hi Tony-- > I'd love to follow your ongoing work on Spoon more closely. How are > you structuring it? It's structured as in the latest release[1], as a master image with development tools and a slave image which is minimal. > Could your intermediate "snapshot" work-in-progress builds be made > available to the public somehow? It's difficult because of the very problem I'm trying to solve (modularity). My master image has several other of my projects in it, not all of which are appropriate for public consumption. Creating an appropriate snapshot is currently time-consuming. Once I have bootstrapped Spoon's module system, I plan to keep all snapshots publicly available all the time. As I mentioned in my most recent progress report, I plan to make a release soon, despite the burden. thanks, -C [1] http://ftp.squeak.org/Spoon/spoon1a12.zip -- Craig Latta http://netjam.org/resume

1 0

Squackers, Tenth-Birthday-of-Squeak edition
by Craig Latta 04 Oct '06

04 Oct '06

Hi all-- For October, Squackers[1] will celebrate Squeak's tenth birthday at Dan Ingalls's place near Santa Cruz, CA, USA, on Saturday the seventh[2]. We'll start by hanging out at the beach in the afternoon, then head up to Dan's for a barbeque and further merriment (and we might be found on the Squeak IRC channel around 7pm GMT-7, see [3]). If you think you'll be able to make it, please let me know! And please forward this message to others you think might be interested. take care, -C [1] Squackers is a group of Squeak hackers in the San Francisco bay area who get together once a month to have a good time and show off what they're up to with Squeak (including learning it). [2] ...the October Saturday nearest the traditional birthday of 1 October, the date Dan announced Squeak to comp.lang.smalltalk (see http://tinyurl.com/gqdhv for the original message). [3] http://users.squeak.org/irc -- Craig Latta http://netjam.org/resume

16 32

Bug ? (source same but rev changed) in Monticello
by Cédrick Béler 04 Oct '06

04 Oct '06

Hi I get this when I see the changes of a seaside package on monticello. For instances, after installing the last seaside (2.7a1-lr88)... and scriptaculous. If I modify nothing and then look at the changes in the same package (ie. 2.7a1-lr88), instead of havind empty, changes, I got a long list (maybe all seaside code) with the mention (source same but rev changed). Shouldn't it be nul ? Thanks Cédrick

1 0

Re: Collecting actions for RC2
by stephane ducasse 04 Oct '06

04 Oct '06

On 4 oct. 06, at 09:31, Roel Wuyts wrote: > Hello Chris, hello Stephane > > Two things for Chris, one thing for Stephane (or for Chris): > > 1- I am investigating your fix, and it looks ok. One question > though: did you have a deliberate reason to add a new method > SystemDictionary>>#renameClass:from: instead of updating the method > SystemDictionary>>#renameClass:as: ? (probably the method -but > not your fix of course- got renamed) > > 2- I am a bit worried about your remark about the obsolete class > and the bad event handler, but I cannot reproduce it. It would > interest me to have a look at it, since this is indeed something > which should not occur. Do you still have an image with this > problem ? A way to reproduce it (I tried running tests several > times in different orders but to no avail). > > 3- Stephane, yesterday I opened the 7061 image, opened the > TestRunner, did select all and ran all tests : they all passed. Yet > when I ran the test manually, as mentioned in Chris' mail, it > indeed fails. Does this mean that not all tests are included in > this TestRunner (intentionally, as a feature), or is there some > problem with the TestRunner ? this is strange and I do not know. > > > Kind Regards, > > Roel > > On 04 Oct 2006, at 05:30, Chris Muller wrote: > >> Thanks Stef for the quick response. >> >> Roel, how can I help? The test that is failing is >> ClassRenameFixTest. The test demonstrates a problem with the >> SystemChangeNotifier, that it signals the rename event while the >> system in in an inconsistent state. For a detailed explanation: >> >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2004- >> June/079418.html >> >> If you run the test in a stock 3.9-7061 image >> >> ClassRenameFixTest run: #testRenameClassUsingClass. >> >> it fails because the actual fix code did not get included in the >> image. >> >> All you need to do is file-in the latest file associated with the >> Mantis bug, ClassRenameFix6#2004.3.cs.gz. >> >> This fixes the bug, except... (...whew! after 2 hours of >> investigation...) - for the test case to pass, a "bad event >> handler" (apparently) from a prior run of this test must be >> removed from the SystemChangeNotifier in the 3.9-7061 image (it >> references an Obsolete class, not good). The #tearDown removes it >> so I don't know how this got stuck in there. >> >> It doesn't really matter, the easiest way to get rid of it: >> >> SystemChangeNotifier uniqueInstance noMoreNotificationsFor: >> (((((SystemChangeNotifier uniqueInstance instVarNamed: >> 'eventSource') instVarNamed: 'actionMap') at: #classRenamedEvent:) >> at: 8) at: 1) >> >> Now the test passes, demonstrating that the rename event is now >> called when the system is consistent. >> >> To summarize: >> >> 1) file in ClassRenameFix6#2004.3.cs.gz from the Mantis bug >> (http://bugs.impara.de/view.php?id=1621) >> 2) execute the above SystemChangeNotifier noMoreNotificationsFor... >> 3) see that the test passes >> >> I have been interested in getting this fix into standard Squeak >> since June, 2004. It will allow Magma users to develop code, >> including now renaming (persistent) classes, while connected to >> the database. >> >> If there is anything else I can do to help, please let me know. >> >> Thanks.. >> >> >> >> ----- Original Message ---- >> From: stephane ducasse <stephane.ducasse(a)gmail.com> >> To: Chris Muller <chris(a)funkyobjects.org> >> Cc: squeak dev <squeak-dev(a)lists.squeakfoundation.org> >> Sent: Tuesday, October 3, 2006 1:48:28 PM >> Subject: Re: Collecting actions for RC2 >> >> hi chris >> >> here is what roel told me about your mail: >> >> "Stef, I am trying to understand the problem by looking at the URL >> mentioned in the mail. I downloaded the RC1 image for 3.9 (7061), and >> ran all the tests, but they seem to work (and there is a test for the >> class renames). So I do not really know what I can do ? >> >> On 03 Oct 2006, at 14:38, stephane ducasse wrote: >> " >> >> On 3 oct. 06, at 04:01, Chris Muller wrote: >> >>> Yeeooww! Somehow this slipped through the cracks. >>> >>> http://bugs.impara.de/view.php?id=1621 >>> >>> Somehow only part of the above code, the new SUnit test, got >>> included in 7061. The test fails because the actual fix code did >>> not get included. Would you mind file in the all the code attached >>> to the above and include this in the next RC? >>> >>> Thanks.. >>> >>> >>> >> >> >> >> >> >> >

1 0

Jump to page: