Hi mark

On mac I got a fuzzy camera control and the floor is not uniform but we see tiles bordered of black. I know that this will not help you but I got other strange behavior.

Stef

On Friday, June 13, 2003, at 07:25 PM, Mark Guzdial wrote:

I can't open any models in Squeak Alice, in either 3.4 nor 3.5. Wonderland new works, and I can control the bunny in the Worlds of Squeak, but whenever I try to open a model (either "in editor" via the FileList or via "w makeActorFrom: 'pathname'"), I see the pieces showing up in the hierarchy of parts view, but then all of Squeak crashes -- the window just collapses. No log or debug file is generated. I've tried both the Objects.zip from UIUC and the SqueakObjects.zip on Jeff's account at CMU.

This is on a Dell Latitude running XP, even downloading a fresh 3.5 image. Jeff Pierce is trying this, too, and isn't having any problem, so it must be something weird about my setup. Anyone ever seen anything like this?

Mark

---

Mark Guzdial, Associate Professor, College of Computing/GVU http://www.cc.gatech.edu/~mark.guzdial/ Collaborative Software Lab http://coweb.cc.gatech.edu/csl

Certainly a possibility, but it must be a NEW anti-Python virus. I just checked -- Squeak 2.7 and 3.2 work fine. It's only 3.4 and 3.5 where Alice dies when I open a model.

Stephane, you might want to check your Mac bugs and see if they're new, too.

Mark

At 02:11 PM 6/13/2003 -0800, Alan Kay wrote:

It must be that Python stuff you've been fooling around with ....

Cheers,

Alan

---

At 1:25 PM -0400 6/13/03, Mark Guzdial wrote:

...

I can't open any models in Squeak Alice, in either 3.4 nor 3.5. Wonderland new works, and I can control the bunny in the Worlds of Squeak, but whenever I try to open a model (either "in editor" via the FileList or via "w makeActorFrom: 'pathname'"), I see the pieces showing up in the hierarchy of parts view, but then all of Squeak crashes -- the window just collapses. No log or debug file is generated. I've tried both the Objects.zip from UIUC and the SqueakObjects.zip on Jeff's account at CMU.

This is on a Dell Latitude running XP, even downloading a fresh 3.5 image. Jeff Pierce is trying this, too, and isn't having any problem, so it must be something weird about my setup. Anyone ever seen anything like this?

Mark

---

Mark Guzdial, Associate Professor, College of Computing/GVU http://www.cc.gatech.edu/~mark.guzdial/ Collaborative Software Lab http://coweb.cc.gatech.edu/csl

--

______ Mark Guzdial, Associate Professor, College of Computing/GVU http://www.cc.gatech.edu/~mark.guzdial/ Collaborative Software Lab http://coweb.cc.gatech.edu/csl

Hi Guys,

For preparing a demo I need some code which is capable of reading and writing animated GIFs. While this particular demo can work without the support it would make an incredible difference if someone would have some code for dealing with it. Doesn't have to be anything special, just the ability to encode and decode a few simple images from/to GIF. Since the basic support is already in Squeak it shouldn't be too hard to make this work.

BTW, if you have some half-baked (sometime started but never finished) code lying around I'd be willing to clean it up so that we can use it from GIFReadWriter along with the other stuff.

Thanks for any help you can provide.

Cheers, - Andreas

Hi

Working on a Genie demo I have just realized that the TransformationMorph does not seem to work properly with translucent colors. As an example, do the following:

- Create a EllipseMorph and open it - Change the color of the ellipse to a translucent color (e.g., "self color: (Color red alpha: 0.5)") - Open the halos on the EllipseMorph and rotate it.

You will see that the translucency goes away and the EllipseMorph suddenly appears in a weird color. Also if you change the color of the Ellipse again (e.g., to another translucent color), this does not work properly.

Is this problem known? If not, can someone try to fix it? (I'm extremely short on time right now and so it would be great if I didn't have to dive into this myself).

Nathanael

PS: I'm pretty sure that this problem is caused by the TransformationMorph the Ellipse is embedded into when rotated.

Here you'll find a gif writter:

http://groups.yahoo.com/group/squeak/message/62471

Cheers,

Diego

Hi Guys,

For preparing a demo I need some code which is capable of reading and writing animated GIFs. While this particular demo can work without the support it would make an incredible difference if someone would have some code for dealing with it. Doesn't have to be anything special, just the ability to encode and decode a few simple images from/to GIF. Since the basic support is already in Squeak it shouldn't be too hard to make this work.

BTW, if you have some half-baked (sometime started but never finished) code lying around I'd be willing to clean it up so that we can use it from GIFReadWriter along with the other stuff.

Thanks for any help you can provide.

Cheers,

• Andreas

Bert Freudenberg wrote:

Am Montag, 16.06.03 um 23:35 Uhr schrieb Andreas Raab:

...

Hi Guys,

For preparing a demo I need some code which is capable of reading and writing animated GIFs. ...

This should wind up in the update stream soon (it was [approved] already)

http://swiki.gsug.org/sqfixes/3341.html

Hmm, this should have gone in the update stream awhile ago. It seems that I missed a few items approved around June 4th for some reason... I'll add those in with the next batch. (My excuse is that the text filtering wasn't working in the BugFixArchiveViewer when I tried it a few days ago. :-) I'll do a more thorough check with the next batch.)

- Doug Way

I've tracked my Alice bug down to:

Form fromFileNamed: 'anything.bmp'

I can't read any BMP's with a 3.4 or 3.5 Windows VM on an XP box. The same BMP's open just fine in 3.2. It's a VM-level bug because I can read the BMP's in a 3.5 image running in a 3.2 VM. But in a 3.4 or 3.5 VM, trying to read the BMP crashes Squeak.

Who maintains the Windows VM these days? Is there anything that's changed between 3.2 and 3.4 that would effect reading BMP's?

Thanks! Mark

At 09:27 PM 6/16/2003 -0400, Mark Guzdial wrote:

Next clue: It's the 3.4 and 3.5 Windows VMs. If I open the latest 3.5 image in a 3.2 VM, Alice works just fine. But if I try to open any model in Alice with a 3.4 or 3.5 VM, Squeak crashes on XP.

Mark

At 12:05 PM 6/16/2003 -0400, you wrote:

...

Certainly a possibility, but it must be a NEW anti-Python virus. I just checked -- Squeak 2.7 and 3.2 work fine. It's only 3.4 and 3.5 where Alice dies when I open a model.

Stephane, you might want to check your Mac bugs and see if they're new, too.

Mark

At 02:11 PM 6/13/2003 -0800, Alan Kay wrote:

...

It must be that Python stuff you've been fooling around with ....

Cheers,

Alan

---

At 1:25 PM -0400 6/13/03, Mark Guzdial wrote:

...

I can't open any models in Squeak Alice, in either 3.4 nor 3.5. Wonderland new works, and I can control the bunny in the Worlds of Squeak, but whenever I try to open a model (either "in editor" via the FileList or via "w makeActorFrom: 'pathname'"), I see the pieces showing up in the hierarchy of parts view, but then all of Squeak crashes -- the window just collapses. No log or debug file is generated. I've tried both the Objects.zip from UIUC and the SqueakObjects.zip on Jeff's account at CMU.

This is on a Dell Latitude running XP, even downloading a fresh 3.5 image. Jeff Pierce is trying this, too, and isn't having any problem, so it must be something weird about my setup. Anyone ever seen anything like this?

Mark

---

Mark Guzdial, Associate Professor, College of Computing/GVU http://www.cc.gatech.edu/~mark.guzdial/ Collaborative Software Lab http://coweb.cc.gatech.edu/csl

--

---

Mark Guzdial, Associate Professor, College of Computing/GVU http://www.cc.gatech.edu/~mark.guzdial/ Collaborative Software Lab http://coweb.cc.gatech.edu/csl

---

Mark Guzdial, Associate Professor, College of Computing/GVU http://www.cc.gatech.edu/~mark.guzdial/ Collaborative Software Lab http://coweb.cc.gatech.edu/csl

______ Mark Guzdial, Associate Professor, College of Computing/GVU http://www.cc.gatech.edu/~mark.guzdial/ Collaborative Software Lab http://coweb.cc.gatech.edu/csl

I did try BMP reading for 3.5 on an XP machine, and it worked ok.

Eddie

---- Original Message ----- From: "Tim Rowledge" tim@sumeru.stanford.edu To: squeak-dev@lists.squeakfoundation.org Sent: Wednesday, June 18, 2003 5:48 PM Subject: Re: [BUG] Can't read BMPs in 3.4/3.5 Windows VM (was Re: [bug?] Problems with Alice -- can't open new models)

Mark Guzdial guzdial@cc.gatech.edu wrote:

...

I can't read any BMP's with a 3.4 or 3.5 Windows VM on an XP box. The

same

...

BMP's open just fine in 3.2. It's a VM-level bug because I can read the BMP's in a 3.5 image running in a 3.2 VM. But in a 3.4 or 3.5 VM,

trying

...

to read the BMP crashes Squeak.

Well it's done by the BMPReadWriterPlugin. Since it was in-image code until 3.6, I guess the evidence comes from the changes file. Hmm, the plugin was added in update 4891 from code by Andreas dated 16 june 2002. This was nominally for 3.3a and I can't spot any difference with the code in my latest VMMaker file. I _have_ tested this on my Acorn and it works fine. I guess using the 3.2 vm means you're relying on the back up code. Obvious quick check is to comment out the primitive call in !BMPReadWriter methodsFor: 'reading' stamp: 'ar 6/16/2002 18:47'! read24BmpLine: pixelLine into: formBits startingAt: formBitsIndex width:

width

| pixIndex rgb bitsIndex | <primitive: 'primitiveRead24BmpLine' module:'BMPReadWriterPlugin'> pixIndex _ 0. "pre-increment" and see if all seems well. After that it requires someone to debug the code on a wondows machine...

tim

Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim No single raindrop believes it is to blame for the flood

Mark Guzdial wrote

I've tracked my Alice bug down to:

Form fromFileNamed: 'anything.bmp'

I can't read any BMP's with a 3.4 or 3.5 Windows VM on an XP box. The

same

BMP's open just fine in 3.2. It's a VM-level bug because I can read the BMP's in a 3.5 image running in a 3.2 VM. But in a 3.4 or 3.5 VM, trying to read the BMP crashes Squeak.

MobVM MultiMedia release (tracking 3.4.4) and squeak 3.5, a PrintIt on:

Form fromFileNamed: 'F:\squeak\AliceObjects\Animals\cat.bmp'

gave 'ColorForm(256x256x8)'

Any bitmap file can be open (viewed) via FileList without problem.

However,

w makeActorFrom 'F:\squeak\AliceObjects\Animals\cat.mdl'

or 'Load actor' to 'scene' (from a Wonderland Visual Studio), crashed Squeak without a stack trace:

-------------------------- crash.dmp start ----------------------------------------- Wed Jun 18 22:13:36 2003

Exception code: C0000005 Exception addr: 01607A0F Access violation (read access) at 7A000000 EAX:BD000000 EBX:1AF5E408 ECX:1AF5AF4C EDX:00000030 ESI:00000014 EDI:00000038 EBP:1AF82228 ESP:0012FE70 EIP:01607A0F EFL:00010246 FP Control: FFFF027F FP Status: FFFF1963 FP Tag: FFFFFFFF VM Version: MobVM - RFC version - MultiMedia Release(Tracking 3.4.4) May 21 2003 Compiler: Microsoft Visual C++

Current byte code: 211 Primitive index: 130

Loaded plugins: JPEGReadWriter2Plugin 5 September 2002 (e) Squeak3D 9 March 2003 (e) LargeIntegers v1.2 5 September 2002 (e) B2DPlugin 5 September 2002 (e) FloatArrayPlugin 5 September 2002 (e) Matrix2x3Plugin 5 September 2002 (e) BitBltPlugin 9 November 2002 (e) MiscPrimitivePlugin 5 September 2002 (e) WindowPlugin September 2002 (e) DropPlugin 5 September 2002 (e) FilePlugin 5 September 2002 (e) SecurityPlugin 5 September 2002 (e) MegaInterpreterPlugin Halloween 2002 (e) ModManPlugin May 21 2003 (e) PlatformPlugin September 2002 (e) SqMOM September 2002 (e) PlugManPlugin September 2002 (e) MicroKernel February 2003 (i)

Stack dump: [EMPTY]

-------------------------- crash.dmp end -----------------------------------------

and Tim wrote:

... it requires someone to debug the code on a wondows machine...

Preliminary investigations indicated that this bug is nasty and dirty. It's in the garbage collector.

It always crashed in primitive 130:

primitiveFullGC >>> incrementalGC() >>> incCompBody() >>> mapPointersInObjectsFromtomapPointersInObjectsFromto()

It happened at different spots on different models, on different ways of tracing (debugging).

Sometimes it happened here:

newOop = longAt(fwdBlock4); // <<<< CRASH

Some other times, here:

newClassOop = longAt(fwdBlock3); // <<<< CRASH

Does it ring a bell ?

Cheers,

PhiHo.

It's very unlikely that this is a bug in the GC code. Crashing in prim 130 means nothing - much more plausible is that the BMP loading code is corrupting memory and the corruption causes GC to go mental.

tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: PUS: PUrge System

Hi John,

Ya, I think the last GC bug we had which was related to class changing and process switching where one forgot to remember to swap an instance variable was 2-3? years ago. This is not to say there couldn't be a bug, however in my experiences any GC crash is related to some primitive trashing memory.

I tend to agree with Tim and you about this. That's why it was categorised as 'nasty and dirty' ;-)

But Mark reported a crash when he evaluated:

Form fromFileNamed: 'anything.bmp'

I could never reproduce this. However I could randomly crashed Squeak when I tried to makeActorFrom cat.mdl. Sometimes I got a cat sometimes I got a crash before my first post.

After my first posting, I tried several times on two diffrent machines and could not reproduce it even when loading mutiple actors, one after another.

How can this behavior be explained ? What can cause Squeak to crash in a non-reproducible manner ?

If the loading of BMP is corrupting the memory, would the crash be reproducible every time ?

To me this bug seems to be dependent on environment. Maybe Mark can clarify this by trying to reproduce it under different environments.

I also noticed a few things that may be helpful for further investigations:

1/- primitiveFullGC (130) is never called during my game session (FreeCell, Tetris)

2/- primitiveFullGC is not called when I evaluated:

Form fromFileNamed: 'F:\squeak\AliceObjects\Animals\Chicken.bmp'

3/- primitiveFullGC is not call when I open/view same bitmap via FileList.

4/- primitiveFullGC is called many times when I open 'Chicken.mdl' once for every part of the chicken, namely:

left leg, left foot, right leg, right foot, neck, head, upperLip, lowerLip.

who, what are responsible for the GC call ?

5/- at this point sometimes it crashed, sometimes it didn't, but if it did not crash, it did not show me the chicken either (not even in the garbage bin ;-)

Where is my chicken ? Is this reproducible on other platforms.

Cheers,

PhiHo.

----- Original Message ----- From: "John M McIntosh" johnmci@smalltalkconsulting.com To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Friday, June 20, 2003 4:10 PM Subject: Re: [BUG] Can't read BMPs in 3.4/3.5 Windows VM (was Re: [bug?] Problems with Alice -- can't open new models)

Ya, I think the last GC bug we had which was related to class changing and process switching where one forgot to remember to swap an instance variable was 2-3? years ago. This is not to say there couldn't be a bug, however in my experiences any GC crash is related to some primitive trashing memory.

If you've seen the visualworks source code, why every step of the way in the debug vm, there are assert checks to confirm there are no buffer overflow conditions and everything in sight is confirmed as valid. We aren't as paranoid in Squeak.

I'd suspect one would need to look at the BMP code and start coding up asserts to confirm there are no memory overwrite conditions.

For example I just fixed a problem in the SerialPort Read Primitive were a size check is made, but on a failure just the success flag is set (prim failed), and the vm cheerfully executes the memory trashing. It never has been an issue because the primitive call is setting up the right values, still I was surprised to see it was defective.

On Friday, June 20, 2003, at 11:47 AM, Tim Rowledge wrote:

...

It's very unlikely that this is a bug in the GC code. Crashing in prim 130 means nothing - much more plausible is that the BMP loading code is corrupting memory and the corruption causes GC to go mental.

tim

Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: PUS: PUrge System

--

=== John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===