I'm not the praying type, but first, let me offer a prayer that God may deliver me from all C code for the rest of eternity. Yeah, I can do it. I'd even go so far as to say the hacks I've done are relatively elegant. But, jeez, it's like pulling teeth sometimes after having done Smalltalk for a year now.
Anyway, in a case of missing the forest for the trees, I spent the last couple of *weeks* trying to figure out why the changes I made to mpeg3io.c and mpeg3io.h were simply not working. After litteriing the *entire* source tree with fprintfs, unsuccessfully trying to run gdb on the entire VM and countless hours of virtual debugging in the shower, I finally figured out that, somehow, my freshly compiled VM (in ~/dev/3.2.1) was referencing the Mpeg3Plugin.dll lying around somewhere under my image dir (in /mnt/c/Program Files/squeak). I deleted the plugin DLL and whoopeee! I can now hear the song I've been longing to hear for about a month in Squeak. One baby step closer to the Squeak uber-media box (which I'm thinking of calling STORMS - Smalltalk Object Remote-controlled Media System).
(If the mpeg stuff is compiled into the image now anyway, why *would* it be referencing the dll?)
So the question is - where do I send the patch? Is it too soon to ask for CVS access (since VorbisPlugin is next)? Either way, please let me know. This patch should be OS-agnostic, btw.
Jason,
Wednesday, May 22, 2002, 9:10:16 PM, you wrote:
I'm not the praying type, but first, let me offer a prayer that God may deliver me from all C code for the rest of eternity. Yeah, I can do it. I'd even go so far as to say the hacks I've done are relatively elegant. But, jeez, it's like pulling teeth sometimes after having done Smalltalk for a year now.
hear, hear!
it's like pulling your -own- teeth.
Jason Dufair jase@dufair.org is claimed by the authorities to have written:
First of all, congratulations on finally finding the solution!
(If the mpeg stuff is compiled into the image now anyway, why *would* it be referencing the dll?)
Not into the _image_. Plugins can be linked into the vm as internal plugins BUT any external one sitting in the search path will override an internal. This is purposely done to allow updates of a single plugin without having to replace the entire vm. Note that we can, in fact, replace the wheels whilst racing down the track by using 'Smalltalk unloadModule: modname' and then allowing the system to reload the new plugin at need. It works as long as the plugin writer doesn't do something evil to prevent that working - things like state that can't be restored, stuff like that.
So the question is - where do I send the patch? Is it too soon to ask for CVS access (since VorbisPlugin is next)? Either way, please let me know. This patch should be OS-agnostic, btw.
You could send it to me, or Andreas, or John McIntosh etc, or even post it so that the bug trapper picks it up and adds it to the list to be considered. We're not keen on adding more people to the CVS access list, people are worried about confusion etc.
tim
I'm not the praying type, but first, let me offer a prayer that God may deliver me from all C code for the rest of eternity. Yeah, I can do it. I'd even go so far as to say the hacks I've done are relatively elegant. But, jeez, it's like pulling teeth sometimes after having done Smalltalk for a year now.
Anyway, in a case of missing the forest for the trees, I spent the last couple of *weeks* trying to figure out why the changes I made to mpeg3io.c and mpeg3io.h were simply not working. After litteriing the *entire* source tree with fprintfs, unsuccessfully trying to run gdb on the entire VM and countless hours of virtual debugging in the shower, I finally figured out that, somehow, my freshly compiled VM (in ~/dev/3.2.1) was referencing the Mpeg3Plugin.dll lying around somewhere under my image dir (in /mnt/c/Program Files/squeak). I deleted the plugin DLL and whoopeee! I can now hear the song I've been longing to hear for about a month in Squeak. One baby step closer to the Squeak uber-media box (which I'm thinking of calling STORMS - Smalltalk Object Remote-controlled Media System).
(If the mpeg stuff is compiled into the image now anyway, why *would* it be referencing the dll?)
So the question is - where do I send the patch? Is it too soon to ask for CVS access (since VorbisPlugin is next)? Either way, please let me know. This patch should be OS-agnostic, btw.
-- Jason Dufair - jase@dufair.org http://www.dufair.org/ "Ad in classifieds: Pandora's Box (no box) $5"
Well you could submit them to the libmpeg3 people on source forge, and to me and I'll drop them into our source tree for squeak and build a mac vm.
PS you've a sunit for this so I can confirm it works?
John M McIntosh wrote:
Well you could submit them to the libmpeg3 people on source forge, and to me and I'll drop them into our source tree for squeak and build a mac vm.
Heh. I think they are all dead. No response on the SF message boards and no response via email. This is after nearly a month of trying to contact them.
Additionally, libmpeg3 has been pretty heavily refactored since it was incorporated into Squeak and this patch wouldn't apply at all. Either way, I'll send it to the list.
PS you've a sunit for this so I can confirm it works?
Yikes! This is starting to sound like my day job! :-) I can try to come up with an sUnit, but it would be dependent on the mp3 file itself. I suppose I could somehow create a simple ID3v2 tagged mp3 file of non-copyrighted material. Doesn't doing C code relieve one of the responsibility of having to create unit tests? :-)
Yikes! This is starting to sound like my day job! :-) I can try to come up with an sUnit, but it would be dependent on the mp3 file itself. I suppose I could somehow create a simple ID3v2 tagged mp3 file of non-copyrighted material. Doesn't doing C code relieve one of the responsibility of having to create unit tests? :-)
Yes, it's your night job that follows the same or better rules that your day job. The sunit and mp3 file are needed to confirm all is well when I recompile on the macintosh. Otherwise it's hard to know...
Yikes! This is starting to sound like my day job! :-) I can try to come up with an sUnit, but it would be dependent on the mp3 file itself. I suppose I could somehow create a simple ID3v2 tagged mp3 file of non-copyrighted material. Doesn't doing C code relieve one of the responsibility of having to create unit tests? :-)
Ok, I've made the update and posted the new macintosh plugins to the update stream. So look for them soon.
John M McIntosh wrote:
Yikes! This is starting to sound like my day job! :-) I can try to come up with an sUnit, but it would be dependent on the mp3 file itself. I suppose I could somehow create a simple ID3v2 tagged mp3 file of non-copyrighted material. Doesn't doing C code relieve one of the responsibility of having to create unit tests? :-)
Ok, I've made the update and posted the new macintosh plugins to the update stream. So look for them soon.
Thanks, John. For the Windows and Unix (and other platform) maintainers - attached is the sUnit test class, a test mp3 file (freely distributable, with ID3v2 tag including binary data) and the patch for the win32 3.2.1 source tree. The patch should apply without a hitch to any port using libmpeg3. Thanks for everyone's help.
Now I'm off to the more daunting task of writing the libvorbis plugin. Does anyone have any pointers to docs on writing plugins (ideally against an existing c lib)? TIA.
Jason Dufair
Jason Dufair wrote:
Now I'm off to the more daunting task of writing the libvorbis plugin. Does anyone have any pointers to docs on writing plugins (ideally against an existing c lib)? TIA.
Take a look at http://coweb.cc.gatech.edu:8888/squeakbook/
and the plugin chapter
http://coweb.cc.gatech.edu:8888/squeakbook/uploads/greenberg.pdf
Karl
Now I'm off to the more daunting task of writing the libvorbis plugin. Does anyone have any pointers to docs on writing plugins (ideally against an existing c lib)? TIA.
Jason Dufair
Take a look on my site for the TIFF plugin work. That was written against an existing c lib. The MPEG3 one is too of course.
squeak-dev@lists.squeakfoundation.org