Dear David,
I have *very* good news!
CommandShellV3-0 works now!
If I type in an unknown command: $ ll ll: No such file or directory
I have come to this result by incident: I was wondering why the *.image files are made executable and tried to execute one directly. And wonder: it works!
It uses the same VM, but without some flags of my personal start script:
sr@karl:~/Squeak/work$ cat `which mySqueak` #!/bin/bash SqueakProg=/usr/local/lib/squeak/3.2-4743/squeak SqueakDir=~/Squeak/work if [ $# = 0 ]; then SqueakImage=blocks.image else SqueakImage=$1 fi
cd $SqueakDir exec $SqueakProg -memory 64m -xshm -nojit $SqueakImage
OK, let's try the same script, but without '-xshm':
Voila: this works! Reason for bug found! (Don't know what it is though...)
Greetings,
Stephan
Stephan Rudlof wrote:
<snipped>
But CommandShellV3-0 *crashes* for me for *unknown* Unix commands as stated before for CommandShellV1-6:
sr@karl:~/Squeak/work$ mySqueak standardVM ioLoadModule(UnixOSProcessPlugin): UnixOSProcessPlugin: cannot open shared objec t file: No such file or directory
Segmentation fault
1095321844 DisplayScreen>forceToScreen: 1095321752 [] in DisplayScreen>forceDamageToScreen: 1095321292 OrderedCollection>do: 1095321168 DisplayScreen>forceDamageToScreen: 1095321076 WorldState>forceDamageToScreen: 1095173560 WorldState>displayWorld:submorphs: 1095173468 PasteUpMorph>privateOuterDisplayWorld 1095173376 PasteUpMorph>displayWorld 1095172916 [] in WorldState>displayWorldSafely: 1095173100 BlockContext>on:do: 1095172824 BlockContext>ifError: 1095172732 WorldState>displayWorldSafely: 1095172640 PasteUpMorph>displayWorldSafely 1095172548 Morph>refreshWorld 1095160668 PluggableTextMorph>update: 1095160576 ShellWindowMorph>update: 1095160760 [] in Object>changed: 1095160484 DependentsArray>do: 1095160392 Object>changed: 1095160300 CommandShell>endEntry 1095160172 CommandShell>show: 1095159896 [] in CommandShell>processError:count: 1095159988 [] in Semaphore>critical: 1095159804 BlockContext>ensure: 1095159712 Semaphore>critical: 1095159620 CommandShell>processError:count: 1095158408 CommandShell>runProxy:signaling: 1095158316 CommandShell>foreground:signaling: 1095062568 CommandShell>doCommandsInString:ifTrue: 1095062172 [] in CommandShell>doCommandsInString: 1095062448 [] in BlockContext>newProcess
Just to notify you: for me currently it is important that OSProcess works..., and this works well!
Thanks for your work,
Greetings,
Stephan
Stephan Rudlof wrote:
Needed for me to get UnixOSProcessPlugin compiled by postscript... Should work as it is and incrementally to OSProcessFix-sr v1.1.
"Change Set: OSProcessFix-sr v2.0 Date: 12 March 2002 Author: Stephan Rudlof Preconditions: Squeak3.2gamma#4743, VMMaker-3-2-version5.5, OSProcessV3-0-dtl
History: v2.0 upgraded for OSProcessV3-0-dtl; added: >>translateDoInlining:, removed: >>sandboxSecurity v1.1 UnixOSProcessPlugin>>sandboxSecurity always returns 0 for no security to be compatible with actual VMSources (don't know where exactly the incompatibility has arosen). v1.0 To work with VMMaker-3-2-version5.5, OSProcessV2-7 needs this fix. Otherwise the postscript doesn't work. " -- Stephan Rudlof (sr@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: OSProcessFix-sr.3.cs.gzOSProcessFix-sr.3.cs.gz Type: application/x-gunzip Encoding: base64
-- Stephan Rudlof (sr@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
mmm I realize there is a lack of progress on the font issue, however let's present a real world problem.
Raymond Asselin raymondasselin@sympatico.ca was kind enough to email me with concerns about character display using non-english keyboards (ie the rest of the world). I welcome feedback, it makes the VM a better place. Assistance in managing the mac VM support code is even more welcome.
Although this was a bug that I created in 3.2.5 Mac VM, further checking and feedback by Raymond pointed out that he could *NOT* display a capital accented E typed via his nifty french Canadian keyboard.
Why, well the default font which many have a licensing issue with, is actually flawed, and doesn't display the character for that ascii value.
So enter AccuFonts (again). I checked, due to the work of Duane Maxwell and other he went to the effort to ensure foreign characters actually *are* mapped correctly in the AccuFonts that he licenced for the Squeak community to use.
Therefore could I suggest we install AccuFonts into the 3.3. image to correct this support issue and kill that licensing issue. I belive we are now approaching a year since this solution offered, actually July 1st 2000 is when I asked my former business partner for assistance in this matter and got Duane to start the porting.
However many of you might not be aware that the existing solution is not only flawed from a license viewpoint (*who cares*) but is also flawed in execution (*perhaps a more serious issue*).
Mmm I'm sure this will kick off another discussion about free truetype fonts, or usage of *free* MS fonts etc, before one does that you should review the archives for many year(s) of discussion on the matter, and the non-solutions.
PS not that a license issue isn't a serious matter, but some really don't care, but if you can't ever type capital accent E then you might have a real barrier to Squeak usage.
John M McIntosh wrote:
So enter AccuFonts (again). I checked, due to the work of Duane Maxwell and other he went to the effort to ensure foreign characters actually *are* mapped correctly in the AccuFonts that he licenced for the Squeak community to use.
Therefore could I suggest we install AccuFonts into the 3.3. image to correct this support issue and kill that licensing issue.
I agree. Are there obstacles in doing this?
Hannes Hirzel
On Wed, 13 Mar 2002, John M McIntosh wrote:
Although this was a bug that I created in 3.2.5 Mac VM, further checking and feedback by Raymond pointed out that he could *NOT* display a capital accented E typed via his nifty french Canadian keyboard.
Why, well the default font which many have a licensing issue with, is actually flawed, and doesn't display the character for that ascii value.
Therefore could I suggest we install AccuFonts into the 3.3. image to correct this support issue and kill that licensing issue.
PS not that a license issue isn't a serious matter, but some really don't care, but if you can't ever type capital accent E then you might have a real barrier to Squeak usage.
Absolutely! Go for it.
Of all of the solutions, this is probably the best overall route for all architectures.
È una bella idea!
Cheers
John
Should have been done ages ago; let's work to get it done Real Soon Now.
tim
Tim Rowledge wrote:
Should have been done ages ago; let's work to get it done Real Soon Now.
Agreed.
As far as I can tell, there are no obstacles to adding these fonts now. The original author has apparently agreed to license them under Squeak-L, which is all that matters.
It's been argued that bitmap fonts are unprotectible by law (see the end of http://minnow.cc.gatech.edu/squeak/1849), so in that sense adding these license-clean accufonts may be overkill. But I think there may be some value in being able to state that "Yes, the original Apple fonts were removed, and they were replaced with these hand-crafted fonts created by so-and-so, so we *know* that they're not just copies of the old Apple fonts." Plus, there's no harm in adding these fonts even if it is overkill license-wise.
- Doug Way dway@riskmetrics.com
On Tuesday 12 March 2002 06:41 pm, John M McIntosh wrote:
mmm I realize there is a lack of progress on the font issue, however let's present a real world problem.
So where can I download the Accufonts?
On Wednesday 03 April 2002 08:22 am, Ned Konz wrote:
On Tuesday 12 March 2002 06:41 pm, John M McIntosh wrote:
mmm I realize there is a lack of progress on the font issue, however let's present a real world problem.
So where can I download the Accufonts?
Never mind, I found them.
I extracted them from the Stable Squeak image and put them on http://minnow.cc.gatech.edu/squeak/696
Ned Konz wrote:
On Tuesday 12 March 2002 06:41 pm, John M McIntosh wrote:
mmm I realize there is a lack of progress on the font issue, however let's present a real world problem.
So where can I download the Accufonts?
-- Ned Konz currently: Stanwood, WA email: ned@bike-nomad.com homepage: http://bike-nomad.com
I realize the mac VM for 3.2.5 is broken for users that require characters over ascii 127. All the accented characters I believe.
Note some bright Squeaker might have a Smalltalk fix for this issue which could be applied to EventSensor (hint the character 16rCD is coming up from the VM as 16rFFFFFCD a negative 32bit integer). I'll leave the code as an exercise to the reader.
I was awaiting confirmation about my code fix for the problem, and this also which the font issue mentioned in my other note. Also I'd really like to kill the issue with time that jean-marie.zajac@laposte.net raised.
So bare with me for another day.
jean-marie.zajac In the mac menu bar he has 17:52pm he execute this code | totalSeconds now secondsForToday | totalSeconds _ Time totalSeconds. now _ Time now. secondsForToday _ Time fromSeconds: totalSeconds \ 86400. Transcript space;show: totalSeconds printString;space; show: now printString;space; show: secondsForToday printString;space; show: secondsForToday asSeconds
and we get in the transcript
3193405337 5:02:17 pm 5:02:17 pm 61337
Mmm if some bright unix hacker (old or young) can understand why this piece of ancient squeak platform code doesn't work as expected, please chip in
int ioSeconds(void) { struct tm timeRec; time_t time1904, timeNow;
/* start of ANSI epoch is midnight of Jan 1, 1904 */ timeRec.tm_sec = 0; timeRec.tm_min = 0; timeRec.tm_hour = 0; timeRec.tm_mday = 1; timeRec.tm_mon = 0; timeRec.tm_year = 4; timeRec.tm_wday = 0; timeRec.tm_yday = 0; timeRec.tm_isdst = 0; time1904 = mktime(&timeRec);
timeNow = time(NULL);
/* Squeak epoch is Jan 1, 1901, 3 non-leap years earlier than ANSI one */ return (timeNow - time1904) + (3 * 365 * 24 * 60 * 60); }
mmm Bet I could get rid of that mktime call everytime we do this call eh? Yes the Unix code is different, but won't compile on the mac, and where does my 50 minutes go (3000 seconds, an interesting number to be sure).
Ok, we nailed the time issue that jean-marie.zajac was having.
It's morning in France and we've been trading email and snippets of C code. So what I found was the mktime & time(0) code is broken. Using time(0)&gmt offset & constant from the Unix code base is fine.
So why.
1) The time server apple suggests you use for os-x in Europe is broken. ntpq -p time.euro.apple.com remote refid st t when poll reach delay offset jitter ============================================================================== *LOCAL(0) .GPS. 0 - 32 64 377 0.000 0.000 0.000 194.151.19.93 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00 17.254.0.49 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00 17.108.100.13 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00 time.apple.com. 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00
(mmm some of the mac os-x squeak users over there should confirm that).
2) I don't think jean had NTP services turned on, but see (1) to understand why that didn't work when we turned it on.
3) I have my suspicions that someone/thing was grabbing time from a cmos clock, but the BSD kernel clock has drifted away, and not been managed by having ntp run. Mac Hardware as documented by the NetBSD folks a few years back keeps lousy time! That's why os-x runs an NTP daemon. This might be bogus but sure sounds good.
4) Maybe mktime is just plain broken. I guess I'll check the raw number coming out of mktime and see if it gels with expectations.
On Wed, Mar 13, 2002 at 02:42:51AM +0100, Stephan Rudlof wrote:
Dear David,
I have *very* good news!
CommandShellV3-0 works now!
[snip]
OK, let's try the same script, but without '-xshm':
Voila: this works! Reason for bug found! (Don't know what it is though...)
That's amazing, I never would have figured this out! I get exactly the same result on my system: Run Squeak with the -xshm command line option, open a "Squeak shell", run a command that generates output on stderr, and <BOOM>, stack dump.
I think that this is going to be some obscure problem in sqXWindow.c, but it will be a hard bug to find. Whatever the problem is, at least it is repeatable now.
Thanks for the feedback, and I'm glad that CommandShell is finally working.
- Dave
p.s. I think that anyone who can find the root cause of this bug deserves a free Squeak T-shirt.
On Tue, 12 Mar 2002, David T. Lewis wrote:
That's amazing, I never would have figured this out! I get exactly the same result on my system: Run Squeak with the -xshm command line option, open a "Squeak shell", run a command that generates output on stderr, and <BOOM>, stack dump.
This also is discovered by running "UnixProcess runTests". Which also points at a problem with PipeableOSProcess: it is undeclared?
Actually, CommandShell and IOHandle are undeclared, too. You shouldn't just use the class names in the code but something like "Smalltalk classNamed: 'CommandShell'".
OIC. These come from the CommandShell changeset. It would be nice to decouple both (as, I guess, you intended).
I think that this is going to be some obscure problem in sqXWindow.c, but it will be a hard bug to find. Whatever the problem is, at least it is repeatable now.
It is just not a good idea to call shmExit() in the child.
Also, you should be using _exit() instead of exit() when exec() failed, because the latter calls the atexit functions which harm the running image.
I'll attach a changeset. Do I get a T-Shirt now? :-)
-- Bert
PS: David: I don't think it is a great idea to start plugin translation in the postscript of a changeset. Also, if there was no OSProcessPlugin before, inspecting the current process makes little sense.
Stefan: And removing the security check is not a good idea, either. Why did you do this?
Bert,
Bert Freudenberg wrote:
On Tue, 12 Mar 2002, David T. Lewis wrote:
That's amazing, I never would have figured this out! I get exactly the same result on my system: Run Squeak with the -xshm command line option, open a "Squeak shell", run a command that generates output on stderr, and <BOOM>, stack dump.
This also is discovered by running "UnixProcess runTests". Which also points at a problem with PipeableOSProcess: it is undeclared?
Actually, CommandShell and IOHandle are undeclared, too. You shouldn't just use the class names in the code but something like "Smalltalk classNamed: 'CommandShell'".
OIC. These come from the CommandShell changeset. It would be nice to decouple both (as, I guess, you intended).
I think that this is going to be some obscure problem in sqXWindow.c, but it will be a hard bug to find. Whatever the problem is, at least it is repeatable now.
It is just not a good idea to call shmExit() in the child.
Also, you should be using _exit() instead of exit() when exec() failed, because the latter calls the atexit functions which harm the running image.
I'll attach a changeset. Do I get a T-Shirt now? :-)
-- Bert
PS: David: I don't think it is a great idea to start plugin translation in the postscript of a changeset. Also, if there was no OSProcessPlugin before, inspecting the current process makes little sense.
Stefan: And removing the security check is not a good idea, either. Why did you do this?
Do you mean me (Stephan)? I have added UnixOSProcessPlugin>>sandboxSecurity as workaround for the previous version of the plugin, (I think it was) to get it compiled. Now this method is supplied by the current version in OSProcessPlugin. To be as incremental as not incremental to my previous fix cs, I have left the removal in it, though it is not necessary for the current plugin (since there is no UnixOSProcessPlugin>>sandboxSecurity).
Greetings,
Stephan
PS: Without looking deeper: Thank you for the bug fixing!
Name: OSProcessShmFix-bf.1.cs.gzOSProcessShmFix-bf.1.cs.gz Type: application/x-gunzip Encoding: BASE64
In case anyone emailed me from Europe (let alone Asia) and didn't get a response from me, you should be aware that my ISP invoked a spam rule last week to deflect eastern Asia spam that relied on blocking any mail containing any unicode values. -> Content rejected.
This as some folks let me know blocks people in Europe who have mail systems that are unicode aware who might have sent me mail and have say embedded accented characters in their names.
My ISP was kind enough to remove the block this morning. So if you email me about a Mac VM 3.2.x issue or the list looking for a response from me and didn't get it, you'll need to resent it.
On Wed, Mar 13, 2002 at 02:48:26PM +0100, Bert Freudenberg wrote:
On Tue, 12 Mar 2002, David T. Lewis wrote:
This also is discovered by running "UnixProcess runTests". Which also points at a problem with PipeableOSProcess: it is undeclared?
Actually, CommandShell and IOHandle are undeclared, too. You shouldn't just use the class names in the code but something like "Smalltalk classNamed: 'CommandShell'".
OIC. These come from the CommandShell changeset. It would be nice to decouple both (as, I guess, you intended).
Yes, this is some cleanup that I still need to do. I did quite a bit of reorganizing and refactoring this time, and the undeclared references are left over debris that I did not get around to cleaning up. Sorry about that. I should have labeled this a "test pilot" release.
I think that this is going to be some obscure problem in sqXWindow.c, but it will be a hard bug to find. Whatever the problem is, at least it is repeatable now.
It is just not a good idea to call shmExit() in the child.
Also, you should be using _exit() instead of exit() when exec() failed, because the latter calls the atexit functions which harm the running image.
Great, thank you! Help me understand, though: Was the call to shmExit() destroying the shared memory segment when running with -xshm? I would have thought that the shared memory segment would stay in place until the last reference to it went away (in the parent). My intention was to make sure the child processes disconnected themselves from the shared memory before the exec(), but as you can see I never really tested this much with the -xshm option enabled ;)
I'll attach a changeset. Do I get a T-Shirt now? :-)
You definitely deserve a T-Shirt for this. Let's see, wasn't Tim making Squeak T-Shirts a while back? I'll have to go check his web site.
PS: David: I don't think it is a great idea to start plugin translation in the postscript of a changeset. Also, if there was no OSProcessPlugin before, inspecting the current process makes little sense.
Yes, you're right. I meant to get rid of that mis-feature. I do like putting up the inspector on the current process though. It gives an idea of what to look at, and it will start working correctly as soon as the plugin is installed. But perhaps it's confusing for a first time installation?
Dave
"David T. Lewis" lewis@mail.msen.com wrote:
PS: David: I don't think it is a great idea to start plugin translation in the postscript of a changeset. Also, if there was no OSProcessPlugin before, inspecting the current process makes little sense.
Yes, you're right. I meant to get rid of that mis-feature. I do like putting up the inspector on the current process though. It gives an idea of what to look at, and it will start working correctly as soon as the plugin is installed. But perhaps it's confusing for a first time installation?
You could pop up a window with some active text in it. alt-6 has "Do It" as an option. Storing the text in your fileout is an exercise for the implementor. :)
-Lex
On Wed, 13 Mar 2002, David T. Lewis wrote:
On Wed, Mar 13, 2002 at 02:48:26PM +0100, Bert Freudenberg wrote:
It is just not a good idea to call shmExit() in the child.
Also, you should be using _exit() instead of exit() when exec() failed, because the latter calls the atexit functions which harm the running image.
Great, thank you! Help me understand, though: Was the call to shmExit() destroying the shared memory segment when running with -xshm?
Yes, because stFree(), called by shmExit(), calls shmctl(IPC_RMID) which destroys the segment. Which might have been okay if shmExit() had reset stDisplayBitmap to 0 so the segment gets recreated on the next ioShowDisplay().
Thinking about this, shmExit() probably even got called twice: once from your call, once via AT_EXIT by exec(). So to prevent future errors in here, shmExit() really should reset stDisplayBitmap.
I would have thought that the shared memory segment would stay in place until the last reference to it went away (in the parent). My intention was to make sure the child processes disconnected themselves from the shared memory before the exec()
After both, exec() and exit(), all attached shared memory segments are detached automatically. So it's at least superfluous to do this.
Although we'll have to think again if using _exit() per my suggestion doesn't circumvent this automatism - there might be a dangling segment now. I cannot recall the tool name that lists shared segments ... anyone?
-- Bert
Bert Freudenberg bert@isg.cs.uni-magdeburg.de wrote:
Although we'll have to think again if using _exit() per my suggestion doesn't circumvent this automatism - there might be a dangling segment now. I cannot recall the tool name that lists shared segments ... anyone?
Err, uh, ipcs I believe. I have a bunch of shared memory segments with no one attached; it looks like they aren't always getting deallocated properly.
-Lex
Lex Spoon wrote:
Bert Freudenberg bert@isg.cs.uni-magdeburg.de wrote:
Although we'll have to think again if using _exit() per my suggestion doesn't circumvent this automatism - there might be a dangling segment now. I cannot recall the tool name that lists shared segments ... anyone?
Err, uh, ipcs I believe.
Correct. After starting Squeak with -xshm:
sr@karl:~$ ipcs
------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 98305 sr 777 3027680 2
------ Semaphore Arrays -------- key semid owner perms nsems status
------ Message Queues -------- key msqid owner perms used-bytes messages
Greetings,
Stephan
PS: Great to learn something new about Linux here!
I have a bunch of shared memory segments with no one attached; it looks like they aren't always getting deallocated properly.
-Lex--
On Wed, Mar 13, 2002 at 02:48:26PM +0100, Bert Freudenberg wrote:
On Tue, 12 Mar 2002, David T. Lewis wrote:
I think that this is going to be some obscure problem in sqXWindow.c, but it will be a hard bug to find. Whatever the problem is, at least it is repeatable now.
It is just not a good idea to call shmExit() in the child.
Also, you should be using _exit() instead of exit() when exec() failed, because the latter calls the atexit functions which harm the running image.
I'll attach a changeset. Do I get a T-Shirt now? :-)
OK, the t-shirt is in the mail. You should receive it at the university in about a week.
It's a particularly nauseating shade of lime green with Tim's world famous, universally acclaimed Squeak logo on the front. My girlfriend took one look at it, gasped in horror, and exclaimed "Oh! I'ts *awful*!!!" I think you're going to like it a lot.
Prospective T-shirt builders who would like to carry on the long standing tradition of sending t-shirts to worthy Squeakers can obtain the logo from http://sumeru.stanford.edu/tim/pooters/squeak.html. I used a Gildan brand t-shirt in a remarkable shade of lime green, and the deed was done by a small shop in Ferndale, Michigan called, appropriately enough, "Dramatic Graphics."
Dave
In message 20020323135024.A3555@conch.msen.com "David T. Lewis" lewis@mail.msen.com wrote:
OK, the t-shirt is in the mail. You should receive it at the university in about a week.
It's a particularly nauseating shade of lime green with Tim's world famous, universally acclaimed Squeak logo on the front. My girlfriend took one look at it, gasped in horror, and exclaimed "Oh! I'ts *awful*!!!" I think you're going to like it a lot.
David, you are obviously a man of taste, style and that essential je ne sais quoi.
tim
On Sat, Mar 23, 2002 at 11:09:27AM -0800, Tim Rowledge wrote:
In message 20020323135024.A3555@conch.msen.com "David T. Lewis" lewis@mail.msen.com wrote:
OK, the t-shirt is in the mail. You should receive it at the university in about a week.
It's a particularly nauseating shade of lime green with Tim's world famous, universally acclaimed Squeak logo on the front. My girlfriend took one look at it, gasped in horror, and exclaimed "Oh! I'ts *awful*!!!" I think you're going to like it a lot.
David, you are obviously a man of taste, style and that essential je ne sais quoi.
Perhaps the latter. Colleen (the aforementioned girfriend) is convinced that I haven't a shred of taste or style, although I do recall her saying something about what I'm full of. Must have been the je ne sais quoi ;)
Dave
On Sat, 23 Mar 2002, David T. Lewis wrote:
On Wed, Mar 13, 2002 at 02:48:26PM +0100, Bert Freudenberg wrote:
On Tue, 12 Mar 2002, David T. Lewis wrote:
I think that this is going to be some obscure problem in sqXWindow.c, but it will be a hard bug to find. Whatever the problem is, at least it is repeatable now.
It is just not a good idea to call shmExit() in the child.
Also, you should be using _exit() instead of exit() when exec() failed, because the latter calls the atexit functions which harm the running image.
I'll attach a changeset. Do I get a T-Shirt now? :-)
OK, the t-shirt is in the mail. You should receive it at the university in about a week.
Great! Anybody else some bugs to squash? ;-)
Strangely, this reminds me of a fairy tale of my childhood ... I feel like "Das Tapfere Schneiderlein" (an English version is here: http://www.dsingley.com/GrimmFairyTales/TheValiantLittleTailor.html)
It's a particularly nauseating shade of lime green with Tim's world famous, universally acclaimed Squeak logo on the front. My girlfriend took one look at it, gasped in horror, and exclaimed "Oh! I'ts *awful*!!!" I think you're going to like it a lot.
Oh, I'm sure. I'll report back when my wife has seen it ...
-- Bert
On Sat, 23 Mar 2002, Bert Freudenberg wrote:
On Sat, 23 Mar 2002, David T. Lewis wrote:
On Wed, Mar 13, 2002 at 02:48:26PM +0100, Bert Freudenberg wrote:
On Tue, 12 Mar 2002, David T. Lewis wrote:
I think that this is going to be some obscure problem in sqXWindow.c, but it will be a hard bug to find. Whatever the problem is, at least it is repeatable now.
It is just not a good idea to call shmExit() in the child.
Also, you should be using _exit() instead of exit() when exec() failed, because the latter calls the atexit functions which harm the running image.
I'll attach a changeset. Do I get a T-Shirt now? :-)
OK, the t-shirt is in the mail. You should receive it at the university in about a week.
Great! Anybody else some bugs to squash? ;-)
Strangely, this reminds me of a fairy tale of my childhood ... I feel like "Das Tapfere Schneiderlein" (an English version is here: http://www.dsingley.com/GrimmFairyTales/TheValiantLittleTailor.html)
It's a particularly nauseating shade of lime green with Tim's world famous, universally acclaimed Squeak logo on the front. My girlfriend took one look at it, gasped in horror, and exclaimed "Oh! I'ts *awful*!!!" I think you're going to like it a lot.
Oh, I'm sure. I'll report back when my wife has seen it ...
Got it! It's incredibly ... green (see attached image). Thanks!!! At least my daughter likes it. Hear her comment: http://isgwww.cs.uni-magdeburg.de/~bert/squeak/PapaHatEineMaus.avi
My wife laughed and said it's well suited for our annual "Frühlingsfest" (spring party) were the computer science dept staff and students ... oh, it's hard to describe what we actually do. See here, the images speak for themselves I guess: http://isgwww.cs.uni-magdeburg.de/culture/ff97/final/
I'm really proud of being awarded the first Squeak Bug Fixing T-Shirt! :-))
-- Bert
On Sat, Mar 30, 2002 at 02:29:01PM +0100, Bert Freudenberg wrote:
Got it! It's incredibly ... green (see attached image). Thanks!!! At least my daughter likes it. Hear her comment: http://isgwww.cs.uni-magdeburg.de/~bert/squeak/PapaHatEineMaus.avi
My wife laughed and said it's well suited for our annual "Frühlingsfest" (spring party) were the computer science dept staff and students ... oh, it's hard to describe what we actually do. See here, the images speak for themselves I guess: http://isgwww.cs.uni-magdeburg.de/culture/ff97/final/
I'm really proud of being awarded the first Squeak Bug Fixing T-Shirt! :-))
Great! It looks like there is going to be a big demand for child size Squeak t-shirts too. And I'll bet that about half way through the Fruhlingsfest, people will start thinking that the green color looks pretty good.
Dave
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
David T. Lewis -
Doug Way -
Hannes Hirzel -
Joern Eyrich -
John Hinsley -
John M McIntosh -
Lex Spoon -
Ned Konz -
Stephan Rudlof -
Tim Rowledge