On a side note, I plan on soon embarking on a journey to get "JPEGReadWriter2Plugin.so" compiled and running for my RedHat Linux 7.1 box, as well as my FreeBSD 4.5 box.

Unless, of course, somebody already has "JPEGReadWriter2Plugin.so" for those two platforms-- in which case, please let me know.

Thanks,

Nevin

Yisrael Lowenstein wrote:

The win32 JPEGReadWriter2Plugin seems to still be non functional.

I tried it out with a fresh, updated image (updated 3.2gamma-4827), the 3.1-win vm, and with both the mailing list copy from April 25th and the copy on the ftp site (dated April 26th). I put the plugin dll in the same directory as al the other files.

I loaded an mpeg, and tried to save it as a JPEGMovie...it told me that the JPEGReadWriter2Plugin primitive had failed.

Anyone know what could be causing this?

I tried this same proces on 2 machines, and NT and a 2000...

is it just me? or is this affecting others as well? Lushi

o |Yisrael Lowenstein: Computer Science Master's Student & Squeaker () o|lushi@bigfoot.com; gte356h@prism.gatech.edu; lushi@cc.gatech.edu o_/||/ |"Before you criticize a man, walk a mile in his shoes. That way || | when you do criticize him, you'll be a mile away and have his _/_ | shoes." - Unknown AIM: YisraelL ICQ: 1037061 Class Schedule: http://www.prism.gatech.edu/~gte356h/schedule/

Tim Rowledge wrote:

I have no problems at all in compiling it under RH7.1/x86 with VMMaker and the SF sources. Can't actually test it since I have no suitable files; send me a pointer to one and I'll try it for you.

tim

Now *I'm* confused. Won't the following test it?

Form fromUser writeJPEGfileNamed: 'test.jpg' progressive: false.

This will invoke the JPEGReadWriter2 class to create a JPEG image called 'test.jpg' in the current directory, and the JPEGReadWriter2 class will attempt to do it via the JPEGReadWriter2Plugin.so.

In other words, what do you mean by "I have no suitable files; send me a pointer to one"?

Nevin

Nevin Pratt nevin@smalltalkpro.com is claimed by the authorities to have written:

In other words, what do you mean by "I have no suitable files; send me a pointer to one"?

Sigh. I mean "I'm going senile and thought you meant mpeg fiels...".

Anyway, reading a jpg from my Olympus camera works fine, writing it out with the snippet you proved works and it reads in again. (Both in Squeak and on my Acorn)

So the plugin at least basically works on my x86 RH7.1 machine.

I also tried the IceAge mpeg clip Yisrael pointed out and it seems to run just fine, ok even as full screen( a few glitches and sound artifacts).

tim

Yisrael Lowenstein gte356h@prism.gatech.edu is claimed by the authorities to have written:

...

I also tried the IceAge mpeg clip Yisrael pointed out and it seems to run just fine, ok even as full screen( a few glitches and sound artifacts).

When you ran this, you just played it? or you saved it out to a JPEGMovie and then played it from that? If so, what system and vm and image are you using...I can't get the JPEGReadWriter2Plugin to work on anything but my mac...

Play the mpg, no problem. Use the MPegMoviePlayer (any chance we can get rid of some of the obsolete stuff guys? All it does is add confusion) menu to save as jpeg movie - it plays direct to the Display (not really the proper thing to do in my view) and saves ok, then playing the created .jmv files works perfectly.

Again, RH7.1/x86 using recently built VM from SF/VMMaker.

tim

Nevin Pratt nevin@smalltalkpro.com is claimed by the authorities to have written:

There are 36 different, distinct VM plugins! What do all those plugins actually do?

Make a real man/woman/primate of you.

Well, FilePlugin handles all the file stuff. SocketPlugin handles sockets. ZipPlugin handles (de)compressing BitBltPlugin handles (ta-da!) BitBlt. etc etc.

The simple option is to choose 'make all internal' from the menu in the bottom left list. This will move any/all plugins that can be made on your platform into the 'Internal plugin' list.

WARNING WARNING If you are on Windows, I have no idea what works and what doesn't. I don't have a windows machine so I have no way to check anything relating to it. Several people have been using VMMaker on windows so I hope they can offer more focussed help.

tim

I've been able to successfully build several VM's on my FreeBSD box.

Unfortunately, *every* VM I build exhibits extremely slow performance for answering web requests when using Comanche. The browser on the other end of the network link just waits and waits, then gets a little data, then waits and waits some more, then gets a little more data, etc. It's extremely painful.

This forces me to remove the freshly built VM and use my old one (which, if I remember, I downloaded from somewhere, but I've forgotten exactly where I got it).

Unfortunately, my old one wasn't compiled with the JPEGReadWriter2Plugin active. And I need that plugin.

Anybody know what's going on?

Nevin

Nevin Pratt nevin@smalltalkpro.com is claimed by the authorities to have written:

...

I've been able to successfully build several VM's on my FreeBSD box.

Unfortunately, *every* VM I build exhibits extremely slow performance for answering web requests when using Comanche. The browser on the other end of the network link just waits and waits, then gets a little data, then waits and waits some more, then gets a little more data, etc. It's extremely painful.

There's been some recent discussion about sockets, semaphores etc and I think I noticed that Comanche suffered from the latest attempt. You could try retreiving a week or so old copy of platforms/unix/plugins/SocketPlugin/sqUnixSockets.c which would almost surely have the bugs that were being attacked but at least seems to do Comanche ok.

Yes this issue is being fixed, I"m peering at a broken freebsd VM right now.... Certainly the issue of dribbles of data has been fixed, so wait a day or so

I guess this has only ever been tried with gnu make; using "gmake" instead of "make" on the SF compile farm works for me.

My Makefile looks like this (all plugins internal) " ... PLUGINS_O:=$(PLUGINS_O) Mpeg3Plugin.o $(LIBMPEG_BUILD_DIR)/libmpeg3.a ... PLUGINS_O:=$(PLUGINS_O) ADPCMCodecPlugin/ADPCMCodecPlugin.o ... {this is probably your line 453, note the Mpeg3Plugin is not in the list } ... VM_O= $(CORE_O) $(PLUGINS_O) $(INTERP).o ... "

So deleting the $(PLUGINS_O) would probably lose me the internally built Mpeg3Plugin.

Instead, I *think* it might be a little bit more portable to change PLUGINS_O:=$(PLUGINS_O) ... into PLUGINS_O += ...

in

platforms/unix/misc/util/mkMake platforms/unix/plugins/Mpeg3Plugin/mkMakeRules

I'll try this tomorrow. I have some other tweaks pending from trying to build under Solaris, I hope to wrap this up over the weekend and post everything I have.

Joern

Nevin Pratt wrote:

I'm playing around with VMMaker.

Any attempt to build the resultant source code on a FreeBSD system results in the error:

Variable PLUGINS_O is recursive

Line 453 of the resultant Makefile has the following:

PLUGINS_O:=$(PLUGINS_O) {and then all of the plugins are listed}

I remove the $(PLUGINS_O) from the line, and all seems to work.

Nevin

I'm playing around with VM building on Linux now, but I've run into multiple errors. I've got a RedHat 7.1 system that I long ago upgraded the compiler to gcc 3.0.3. The standard RedHat 7.1 compiler is broken and wouldn't run Ingres for a contract I had awhile back, but the 3.0.3 version ran all the Ingres stuff for that contract just fine. So, I think my compiler's OK.

But anyway, here's what I did:

1. I googled "Squeak VMMaker". It gave me Lex's page: "http://minnow.cc.gatech.edu/squeak/2173 "

2. Following the instructions on Lex's page, I downloaded and installed VMMaker into my existing Linux image (a 3.2g-4843 image). I get the VMMaker filein by clicking the VMMaker link in Lex's page, and then on the next page scrolling to the bottom and clicking on the link that says "The changesets are at: ...". Immediately below this changesets link, it suggests also using a "ClassBuilderFix.cs" filein, which I try and it crashes the image complaining about a serious meta inconsistency, so I redo everything again without using ClassBuilderFix.cs this time. I move on without the ClassBuilderFix.cs.

PROBLEM #1: THE "ClassBulderFix.cs" FILEIN CRASHES MY IMAGE

3. Back on Lex's page, I click on "Getting source using the CVS repository". I create a 'src' directory within the directory I am currently running squeak in, and then follow the cvs login instructions in Lex's page.

4. The cvs instructions say to either 'co squeak', or to 'co unix'. Since I am only interested in unix, I issue the cvs instructions to 'co unix'. It creates and populates a 'src/platforms' directory, and within the 'platforms' directory, I have 'CVS', 'Cross', and 'unix' directories.

5. I issue the cvs 'co CVSROOT' command, per Lex's instructions, from the same directory I did the 'co unix' in (within the 'src' directory). Now, within the 'src' directory, I have both a 'CVSROOT' directory, and a 'platforms' directory. And, of course, my 'src' directory is inside of my current working directory that I launched Squeak from.

6. I go back to Lex's page. He says to "Run VMMaker and generate source code including the plugins you want". So, in my existing Squeak image, I do 'VMMakerTool openInWorld'. In that UI, I click "Find Path", and it finds my platforms directory OK. I then click on "Find platform", and it shows me the choices "CVS" and "unix". I select "unix".

7. What is this "Path to generated sources" thing on the VMMaker UI? It has defaulted to the 'src' directory, which is the parent directory to the 'platforms' directory. I leave it with this default.

PROBLEM #2: THE "Path to generated sources" STUFF IS NOT CLEAR.

8. In the "Plugins not built" pane, I right mouse click and select "Make all internal". Then I click the "Generate All" button and wait for a little while.

9. I go back to Lex's web page to see what to do next. He says to "Make a 'build' directory", but he doesn't say where. However, he next says to 'cd build', and then '../platforms/unix/misc/configure'. Aha, this reveals where the 'build' directory should be-- it should be on the same directory level as the 'platforms' directory (i.e., inside of the 'src' directory). Otherwise you couldn't do a '../platforms/unix/misc/configure' command.

Hmm, the configure generated an error. It says:

find: ../platforms/unix/misc/../../../src/vm: No such file or directory

If you follow all of those '..' paths, you will see that it is looking for a 'src' directory at the same level as the 'platforms' and 'build' directories are at. That's not the level that the 'src' directory is at. It is instead one directory higher.

So, within my 'src' directory, I issue the following:

ln -s . src

This gives me a soft link 'src' which just links back to the same directory, within which the 'vm' directory can now be found. This makes it so that the 'find' path shown in the configure error should now work.

10. I rerun '../platforms/unix/misc/configure', and this time it seems to work.

PROBLEM #3: WHERE SHOULD YOU PUT THE 'build' DIRECTORY? WHY DID I NEED TO CREATE THIS 'src' LINK? ARE THESE TWO ISSUES RELATED?

11. I type 'make', and cross my fingers (on my Linux 7.1 box, 'gmake' is a link to 'make', which is the standard make on the box). It builds me a 'squeak' VM.

12. I quit my existing Squeak image, and replace the old 'squeak' VM with the new one, and try to restart my image. I get a walkback. The relevant part of the stack walkback is the following:

Error: Cannot truncate this number (... a few other stack frames, then...) Float(Object)>>error: Float>>truncated Float>>rounded Color>>setRed:green:blue: Color class>>r:g:b: Color class>>r:g:b:alpha: Color>>alphaMixed:with: Color>>veryMuchLighter PreDebugWindow(SystemWindow)>>paneColor: PreDebugWindow(SystemWindow)>>paneColor PreDebugWindow(SystemWindow)>>paneColorToUse PreDebugWindow(SystemWindow)>>extent: PreDebugWindow>>extent: PreDebugWindow(SystemWindow)>>initialize PreDebugWindow>>initialize

I switched back to the old VM and launched the image. I poked a little at the code shown in the walkback, and on a hunch turned off the alternativeWindowLook (which should stop the Color>>veryMuchLighter call from happening). Then I saved the image and switched back to the new VM. I got the same kind of error, but from the ScrollBar>>thumbColor, then some more ScrollBar methods, then Color methods, then the Float rounded thing, then Float truncated, then bam, "Cannot truncate this number" error.

PROBLEM #4: THE NEW VM DOESN'T WORK, AND I DON'T KNOW WHY

At Sat, 04 May 2002 00:11:32 -0600, Nevin Pratt wrote:

But anyway, here's what I did:

1. I googled "Squeak VMMaker". It gave me Lex's page:

"http://minnow.cc.gatech.edu/squeak/2173 "

2. Following the instructions on Lex's page, I downloaded and installed

VMMaker into my existing Linux image (a 3.2g-4843 image). I get the VMMaker filein by clicking the VMMaker link in Lex's page, and then on the next page scrolling to the bottom and clicking on the link that says "The changesets are at: ...". Immediately below this changesets link, it suggests also using a "ClassBuilderFix.cs" filein, which I try and it crashes the image complaining about a serious meta inconsistency, so I redo everything again without using ClassBuilderFix.cs this time. I move on without the ClassBuilderFix.cs.

       PROBLEM #1: THE "ClassBulderFix.cs" FILEIN CRASHES MY IMAGE

Just click on proceed.

3. Back on Lex's page, I click on "Getting source using the CVS

repository". I create a 'src' directory within the directory I am currently running squeak in, and then follow the cvs login instructions in Lex's page.

4. The cvs instructions say to either 'co squeak', or to 'co unix'.

Since I am only interested in unix, I issue the cvs instructions to 'co unix'. It creates and populates a 'src/platforms' directory, and within the 'platforms' directory, I have 'CVS', 'Cross', and 'unix' directories.

5. I issue the cvs 'co CVSROOT' command, per Lex's instructions, from

the same directory I did the 'co unix' in (within the 'src' directory). Now, within the 'src' directory, I have both a 'CVSROOT' directory, and a 'platforms' directory. And, of course, my 'src' directory is inside of my current working directory that I launched Squeak from.

6. I go back to Lex's page. He says to "Run VMMaker and generate source

code including the plugins you want". So, in my existing Squeak image, I do 'VMMakerTool openInWorld'. In that UI, I click "Find Path", and it finds my platforms directory OK. I then click on "Find platform", and it shows me the choices "CVS" and "unix". I select "unix".

7. What is this "Path to generated sources" thing on the VMMaker UI? It

has defaulted to the 'src' directory, which is the parent directory to the 'platforms' directory. I leave it with this default.

      PROBLEM #2: THE "Path to generated sources" STUFF IS NOT CLEAR.

8. In the "Plugins not built" pane, I right mouse click and select "Make

all internal". Then I click the "Generate All" button and wait for a little while.

9. I go back to Lex's web page to see what to do next. He says to

"Make a 'build' directory", but he doesn't say where. However, he next says to 'cd build', and then '../platforms/unix/misc/configure'. Aha, this reveals where the 'build' directory should be-- it should be on the same directory level as the 'platforms' directory (i.e., inside of the 'src' directory). Otherwise you couldn't do a '../platforms/unix/misc/configure' command.

Hmm, the configure generated an error. It says:

find: ../platforms/unix/misc/../../../src/vm: No such file or directory

If you follow all of those '..' paths, you will see that it is looking for a 'src' directory at the same level as the 'platforms' and 'build' directories are at. That's not the level that the 'src' directory is at. It is instead one directory higher.

So, within my 'src' directory, I issue the following:

ln -s . src

This gives me a soft link 'src' which just links back to the same directory, within which the 'vm' directory can now be found. This makes it so that the 'find' path shown in the configure error should now work.

10. I rerun '../platforms/unix/misc/configure', and this time it seems

to work.

     PROBLEM #3: WHERE SHOULD YOU PUT THE 'build' DIRECTORY?  WHY 

DID I NEED TO CREATE THIS 'src' LINK? ARE THESE TWO ISSUES RELATED?

src, build and platforms should be at the same level just under the top-level directory squeak.

11. I type 'make', and cross my fingers (on my Linux 7.1 box, 'gmake' is

a link to 'make', which is the standard make on the box). It builds me a 'squeak' VM.

12. I quit my existing Squeak image, and replace the old 'squeak' VM

with the new one, and try to restart my image. I get a walkback. The relevant part of the stack walkback is the following:

Error: Cannot truncate this number
(... a few other stack frames, then...)

Float(Object)>>error: Float>>truncated Float>>rounded Color>>setRed:green:blue: Color class>>r:g:b: Color class>>r:g:b:alpha: Color>>alphaMixed:with: Color>>veryMuchLighter PreDebugWindow(SystemWindow)>>paneColor: PreDebugWindow(SystemWindow)>>paneColor PreDebugWindow(SystemWindow)>>paneColorToUse PreDebugWindow(SystemWindow)>>extent: PreDebugWindow>>extent: PreDebugWindow(SystemWindow)>>initialize PreDebugWindow>>initialize

I switched back to the old VM and launched the image. I poked a little at the code shown in the walkback, and on a hunch turned off the alternativeWindowLook (which should stop the Color>>veryMuchLighter call from happening). Then I saved the image and switched back to the new VM. I got the same kind of error, but from the ScrollBar>>thumbColor, then some more ScrollBar methods, then Color methods, then the Float rounded thing, then Float truncated, then bam, "Cannot truncate this number" error.

       PROBLEM #4: THE NEW VM DOESN'T WORK, AND I DON'T KNOW WHY

I've got the same error with gcc 3.0, works without problems with gcc 2.95.

stuff for that contract just fine. So, I think my compiler's OK.

3.0.3 has a problem building Squeak, more on that in a bit.

      PROBLEM #1: THE "ClassBulderFix.cs" FILEIN CRASHES MY IMAGE

4855ClassBuilderFix3-2 -- Nathanael Schärli & Andreas Raab -- 23 April 2002 Fixes various problems in both ClassBuilder and the handling of obsolete subclasses"

Just sent out in the update stream. so update an image to the current level first.

     PROBLEM #2: THE "Path to generated sources" STUFF IS NOT CLEAR.

Tim????

    PROBLEM #3: WHERE SHOULD YOU PUT THE 'build' DIRECTORY?  WHY 

DID I NEED TO CREATE THIS 'src' LINK? ARE THESE TWO ISSUES RELATED?

Tim??? again...

12. I quit my existing Squeak image, and replace the old 'squeak' VM

with the new one, and try to restart my image. I get a walkback. The relevant part of the stack walkback is the following:

I think this is the 3.0.3 gcc issue

See Ned Konz notes in the archives At 3:55 PM -0800 3/7/02, Ned Konz wrote:

Looking further, it may be a config issue; the sqUnixConfig.h file generated for the two differed as follows:

$ diff -c ../sqUnix* *** ../sqUnixConfig.h.2.95.3 Thu Mar 7 15:34:11 2002 --- ../sqUnixConfig.h.3.03 Thu Mar 7 15:33:25 2002

---

*** 111,117 ****

/* #undef WORDS_BIGENDIAN */ /* #undef DOUBLE_WORD_ALIGNMENT */ ! #define DOUBLE_WORD_ORDER 1

/* damage containment */

--- 111,117 ----

/* #undef WORDS_BIGENDIAN */ /* #undef DOUBLE_WORD_ALIGNMENT */ ! /* #undef DOUBLE_WORD_ORDER */

/* damage containment */

So I tried doing the config for GCC 3.0.3 and then edited the sqUnixConfig.h file, defining DOUBLE_WORD_ORDER.

And guess what? It ran!

So I decided to run the tinyBenchmarks:

With 2.95.3: 0 tinyBenchmarks '42553191 bytecodes/sec; 1283021 sends/sec'

With 3.0.3: '38811400 bytecodes/sec; 1253071 sends/sec'

So then I changed the -O2 in the Makefile to -O3 and tried compiling again. It got a bit faster in the sends/sec but slower in the bytecodes/sec...

With 3.0.3, -O3: '36802760 bytecodes/sec; 1285996 sends/sec' '37383177 bytecodes/sec; 1285003 sends/sec'

Anyway, thought you might be amused.

At 4:36 PM -0800 3/7/02, Ned Konz wrote:

Oh come on now; it probably just needs someone to tweak the knobs on the back of the set... (twiddle twiddle)..

How's this 3.03 result:

0 tinyBenchmarks '47442550 bytecodes/sec; 1434550 sends/sec' '47761194 bytecodes/sec; 1415033 sends/sec'

For reference, 2.95.3 was: '42553191 bytecodes/sec; 1283021 sends/sec' '42356055 bytecodes/sec; 1282033 sends/sec'

I used CFLAGS= -I/usr/X11R6/include -g -O3 -DLSB_FIRST=1 -funroll-loops -fno-gcse

Adding the -fno-gcse made quite a bit of difference (27% more bytecodes/second, 11% more sends/sec).

So now it's about 12% faster than the 2.95.3 was. Of course, I don't know what'll happen if you use "-fno-gcse" with the 2.95.3 ...

Nevin Pratt nevin@smalltalkpro.com is claimed by the authorities to have written:

1. I googled "Squeak VMMaker". It gave me Lex's page:

"http://minnow.cc.gatech.edu/squeak/2173 "

2. Following the instructions on Lex's page, I downloaded and installed

VMMaker into my existing Linux image (a 3.2g-4843 image). I get the VMMaker filein by clicking the VMMaker link in Lex's page, and then on the next page scrolling to the bottom and clicking on the link that says "The changesets are at: ...". Immediately below this changesets link, it suggests also using a "ClassBuilderFix.cs" filein, which I try and it crashes the image complaining about a serious meta inconsistency, so I redo everything again without using ClassBuilderFix.cs this time. I move on without the ClassBuilderFix.cs.

       PROBLEM #1: THE "ClassBulderFix.cs" FILEIN CRASHES MY IMAGE

Does simply proceeding work ok? It files (takes a very long time) into images on my Mac, Acorn and RH7.1 machines ok. Obviously if you have an image with the ClassBuilder fix aready installed, don't bother to add it again.

3. Back on Lex's page, I click on "Getting source using the CVS

repository". I create a 'src' directory within the directory I am currently running squeak in, and then follow the cvs login instructions in Lex's page.

Hmm, some explanations needed here. Although VMMaker can cope with any old path to the place where you put the downloaded sources and any old path to where the generated ones go, the makefiles for various machines have assorted restrictions. On my Acorn for example, the two paths are utterly hardcoded because there is np scripting in RiscOS. On Mac you have to do approriate projectpath magic to change anything and under linux you can apparently use assorted commandline dooberries. The defaults provided by VMMaker are workable with all the makefiles I've been able try. That is to say (and the builtin Help stuff and VMMaker class comment it refers to does explain some of this but perhaps needs to explain more) by default we expect:-

{working directory} /platforms /Cross (required for all cases) /Mac OS /RiscOS /unix /win32

I always download everything from SF, it hardly takes any more time than fetching just mac or unix or whatever. It also provides useful comparison code for when debugging one platform.

Then when you run VMMaker with all the defaults left alone (it assumes ./platforms for the 'path to platforms code' and the bubble help explains this, it assumes the platform name is that returned by Smalltalk platformName, and finally it assumes it can write newly generated files into ./src) it creates the sources in the ./src tree and (depending on platform) copies files from ./platforms to ./scr ready to go.

Then depending on platform (again, and it would be really nice to simplify this but you try getting agreement on this sort of thing) you have to do different things to actually build the vm.

On Mac you have to unpack an archived resources file, open codeworrier and import an xml version of the project file, do other Macish things and press the go button.

On windows you have to do things I don't know about.

On Acorn you d-click on ./src/ MakePlug, wait then d-click on MakePlugins and wait some more.

On unix you make a 'build' dir in your working directory, cd to it and run ../platforms/unix/misc/configure which does lots of stuff. Then you 'make'. If you changed any of the directories in VMMaker you need to read the help info in the generated makefile or the autoconf scripts or wherever. Personally I'm too lazy to bother changing them. It works without messing, so why bother? Once all the compiling is done you can either 'make install' or d what I do which is 'cp squeak ..' and 'cp .libs/*.so ..' to get a working vm & plugins in your working directory.

So, I think you made life difficult for yourself by - creating the src directory and trying to work within it. It happens to clash with the name chosen by VMMaker. - downloading only part of the CVS tree. If you get the whole lot I don't think you need to mess with getting the CVSROOT stuff. - touching the find * buttons. You don't need to. You're right about the CVS being included in the platform choices though - needs removing from the list. - using gcc 3.* which seems to have utterly screwed up some important things.

The big question is what we can do to improve the documentation to avoid this confusion.

At some point, it is intended to provide ready-assembled source trees for people that simply want to compile for some platform rather than those that are intending to experiment with or develop for the vm. That hasn't been done yet. We need some actual agreement before that can happen.

tim

Hi Folks,

Try this one.

Cheers,

Yisrael Lowenstein wrote:

The win32 JPEGReadWriter2Plugin seems to still be non functional.

I tried it out with a fresh, updated image (updated 3.2gamma-4827), the 3.1-win vm, and with both the mailing list copy from April 25th and the copy on the ftp site (dated April 26th). I put the plugin dll in the same directory as al the other files.

I loaded an mpeg, and tried to save it as a JPEGMovie...it told me that the JPEGReadWriter2Plugin primitive had failed.

Anyone know what could be causing this?

I tried this same proces on 2 machines, and NT and a 2000...

is it just me? or is this affecting others as well? Lushi

o |Yisrael Lowenstein: Computer Science Master's Student & Squeaker () o|lushi@bigfoot.com; gte356h@prism.gatech.edu; lushi@cc.gatech.edu o_/||/ |"Before you criticize a man, walk a mile in his shoes. That way || | when you do criticize him, you'll be a mile away and have his _/_ | shoes." - Unknown AIM: YisraelL ICQ: 1037061 Class Schedule: http://www.prism.gatech.edu/~gte356h/schedule/

Yisrael Lowenstein wrote:

...

Try this one.

THANK YOU! You are a life saver! I am giving a presentation about Digital Video Special Effects at SqueakEnd tommorow and I couldn't save or view my JPEG movies that I had made on my mac...Now they can be incorperated into the presentation...I don't need to go utside to AVIs!

Are there any reports witten about the SqueakEnd for the rest of us?

Karl

Karl Ramberg wrote:

Are there any reports witten about the SqueakEnd for the rest of us?

Doug Way wrote: Well, John McIntosh wasn't there to give his usual in-depth report, so I'm

afraid there won't be a good hour-by-hour synopsis available. :-)

I write:

I missed Johns writeup also. I am I going to find out what was *really* going on there?

I'll tell you what I got out of the weekend . I arrived in Atlanta on Thursday night, and spent Friday morning taking a hike through the Atlanta Botantical Garden. Atlanta seemed like a nice place, and it was interesting to be walking through a hardwood forest in the middle of the downtown area.

When the conference started, Alan Kay gave a speech. I had never seen Alan give his talk, and I got a much better feeling for the initial impetus of the Squeak implementation. Overall, Squeak *should* be a system that an individual can understand in its entirety, and an adopter should be able to maintain a relatively complex application with only a couple of folks. It seems to me that the system has grown since its inception and is a little beyond this goal right now, hopefully when we redo the image with modules we can get back to that ideal. Squeak has always struck me as a computer science degree in a box.

The thing that I got out of the talk was the difference of concept versus implentation. There are a lot of concepts in computer science that are difficult to realize from their implementation. This difference is one of the points that Smalltalk tries to address, so that you can just describe your concepts and "see" how the resulting code solution implements the concept, and not get bogged down in the inevitable programming minutuae a lot of other programming languages bring with them to the table.

For example, a finite state machine is usually represented conceptually on the chalk board as several circles representing state with transition arrows inbetween. However, when you see a "C" implementation of that concept, it is usually some hacked up bit table. In and of itself, that's OK (for either efficiency or as an output from some other formalized process) but it's a big leap from what's really going on conceptually to the actual code itself. You can also make the case that it is difficult to maintain due to this difference, because when you come back a few months later you have to unravel the code to "understand" it again and implement your changes. My own experience has told me that it is much better just to code up the simplest thing; it just gets confusing over time if I try to do anything really clever.

Lex gave a good introduction to how to use Squeak after dinner. I don't really think of this gathering as a Squeakend, it was more a gathering a people who were interested in Squeak for a variety of reasons. This happened to include some of what we think of as "Squeakers" like the people on this list. In that sense, it was nice to meet other list mates and put names to faces. However, the agenda was pretty packed with interesting talks, so we didn't have a chance to really sit down as a group and talk and/or code.

There were a lot of presentations Saturday and Sunday. Most of the talks were on the advanced introduction level. The ones that I attended included 3D Graphics, Sound, Swiki, and Nebraska. In general, it was material that you probably covered if you have tried to use any of those facilities in Squeak on your own. The one thing that made those talks interesting though was that the initial implementors of those ideas in Squeak gave the talks. By "reading between the lines" you could pick up a whole lot more than what was presented, and made it more than worth the time. Also, Bijan gave a talk on the game of life, and it was interesting because this was his first attempt at an Active Essay. I thought he did a good job.

Oh, and we ate a lot. I like to think I did particularly well in that department. I tend to not care about what I eat when on the road to begin with (something about when the cat is away, the mice will play), and when you add that to having a lot of food around ... ;-)

One thing out of the ordinary was Dan Ingalls talk on the new modules system. It sounded to me like most of the architecture has been pretty well layed out, but that there is still quite a bit of work ahead before it can really be pushed out the door. This is a talk that you needed to be there to appreciate all of the subtle implications and tradeoffs that have to be made in order for this thing to work right.

Saturday night was demo night, and some interesting things were presented by the Squeak developers.

Talking to the other Squeak users there, I was surprised by one of the problems that a lot of new users are having. Craig Latta mentioned that his students were having problems finding the correct versions of Squeak to download for all of the different platforms. When 3.2 gets shipped, we'll have to make a concentrated effort to eliminate this silly problem. We really need to work on funneling the users to one place for all of their downloading needs.

I stayed over an extra night and left Monday morning. I was in the airport near the ticket gates, when all of the sudden I saw a tall looking man traveling very fast coming down the corridor through a swarm of people. It turned out to be a policeman on a Segway Human Transport machine!!! http://www.segway.com/ It almost seemed to make sense in that environment (I laughed for a long time after seeing the promotional video on the Segway site). I was going to try to stop the policeman and ask him questions, but thought better when I noticed the gun strapped to his waist. The policeman might have thought that having some madman chasing him at a full run would seem suspicious, so I thought better to err on the side of caution. I think they sensed my lingering excitement at the gate, as they did the full "take off your shoes and hold out your arms" search before I boarded the aircraft. When the woman opened my laptop up to examine it, I offered to do a Squeak demo, but she didn't seem very interested.

This just tells you, you need to go to these things. They're a lot more fun to attend than to read about.

Jim

Bijan Parsia wrote:

On Tue, 7 May 2002, Jim Benson wrote:

...

Karl Ramberg wrote:

...

Are there any reports witten about the SqueakEnd for the rest of us?

...

Doug Way wrote: Well, John McIntosh wasn't there to give his usual in-depth report, so I'm

afraid there won't be a good hour-by-hour synopsis available. :-)

I write:

I missed Johns writeup also. I am I going to find out what was *really* going on there?

Indeed, it's all like a dream, a glimpse of some otherworldly paradise...

...

I'll tell you what I got out of the weekend.

Me too, inspired by My Hero(tm)...JIM!

Jim and Bijan,

Thanks

Karl

On Wed, 8 May 2002, Craig Latta wrote:

heya--

...

Craig tried, and failed, to get an InterpreterSimulator going for me...is anyone running this on a regular basis or can point to a known good version? I'd really like to just *see* this.

Of course I couldn't just let this one go. :)

You just needed the right incentive. What *else* have you got to show me? :)

And, of course, I got it running after about another fifteen minutes at home. :)

Suuuuuuuuuuuuuuuuuuure.

[snip working instructions]

It worked. I am satisfied and happy. We should put this on the Swiki.

Yay!

Craig Rules.

Interpreter>>arrayValueOf: answered self, instead of the class name we were trying to confirm. And to get that far I had to fix InterpreterSimulator>>ioLoadExternalFunction:OfLength:FromModule:OfLength: (the block that populates functionString was trying to write to pluginString again). I moved on/back to 2.7 at that point. I assume that debugging the simulator is even hairier in post-2.8 releases. :)

Oh, dear. It would be nice for this to work with current releases.

The last time I ran the simulator was in Summer 1999, when I was debugging a scanned-sound-synthesis plugin I wrote. It was very handy!

And cool! What a *sexy demo*!

Cheers, Bijan Parsia.