In a 3.9a-Packages image, I installed VMMaker, installed OSProcess, tried to generate the plugin, and got an error in MessageNode>>asTranslatorNode. This worked after I changed
sel _ (selector isSymbol) ifTrue: [selector] ifFalse: [selector key].
into:
sel _ (selector isMemberOf: Symbol) ifTrue: [selector] ifFalse: [selector key].
I would guess that selector was a ByteSymbol, instead of the expected Symbol, because of the internationalization changes.
BTW, VMMaker does not have a category in Mantis. BTW, I'd send a patch, but OSProcessPlugin inconveniently installs itself in a VMMaker category.
Daniel Vainsencher
Thank you for your report. I have transferred your report to Squeak's Mantis Database and you can followup on the issue if desired by going to http://bugs.impara.de/view.php?id=1389 .
In the future please report new issues on Squeak's Mantis Database at http://bugs.impara.de/ .
Since the non-platform specific code is distributed along with VMMaker just use the VM category for anything related to the VM, VMMaker, etc.
Thanks!
Ken
On Tue, 2005-06-28 at 22:26 +0300, Daniel Vainsencher wrote:
In a 3.9a-Packages image, I installed VMMaker, installed OSProcess, tried to generate the plugin, and got an error in MessageNode>>asTranslatorNode. This worked after I changed
sel _ (selector isSymbol) ifTrue: [selector] ifFalse:[selector key].
into:
sel _ (selector isMemberOf: Symbol) ifTrue: [selector]ifFalse: [selector key].
I would guess that selector was a ByteSymbol, instead of the expected Symbol, because of the internationalization changes.
BTW, VMMaker does not have a category in Mantis. BTW, I'd send a patch, but OSProcessPlugin inconveniently installs itself in a VMMaker category.
Daniel Vainsencher danielv@techunix.technion.ac.il wrote:
In a 3.9a-Packages image, I installed VMMaker, installed OSProcess, tried to generate the plugin, and got an error in MessageNode>>asTranslatorNode. This worked after I changed
See mantis #1389 for future commentary.
This change was made for mantis #1078 in the 3.8-66605 image. It works perfectly well there, so any problem in a 3.9 image means someone screwed up symbol in some way
BTW, VMMaker does not have a category in Mantis.
Just use VM. I look at all of them eventually.
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim Strange OpCodes: RSC: Rewind System Clock
On Tue, Jun 28, 2005 at 10:26:06PM +0300, Daniel Vainsencher wrote:
In a 3.9a-Packages image, I installed VMMaker, installed OSProcess, tried to generate the plugin, and got an error in MessageNode>>asTranslatorNode. This worked after I changed
sel _ (selector isSymbol) ifTrue: [selector] ifFalse: [selector key].
into:
sel _ (selector isMemberOf: Symbol) ifTrue: [selector] ifFalse: [selector key].
I would guess that selector was a ByteSymbol, instead of the expected Symbol, because of the internationalization changes.
I think there are a few little glitches related to ByteSymbol in the latest VMM/SVN sources etc (I'm trying to figure the same thing out myself as soon as I get a bit of free time).
BTW, VMMaker does not have a category in Mantis. BTW, I'd send a patch, but OSProcessPlugin inconveniently installs itself in a VMMaker category.
This was a seriously dumb move on my part. In the last OSPP release (3.1.1) I moved it into the VMMaker category, not thinking of the consequences related to loading MCZ files. Mea culpa, I'll change it back next time I update OSPP.
More seriously though, there are some changes in the current VMM sources that impact OSPP, and I need to get this sorted out before you can get a reliable build. Most notably, OSPP is currently relying on knowledge of the structure of struct SQFile in FilePlugin, which has recently changed. Another enhancement to VMM (ability to access the session ID from the interpreter) makes this dependency unnecessary, but OSPP is not yet in sync with the new sources.
Bottom line: For now, use one of Ian's distributions if you are running OSPP. Sorry for the inconvenience.
Dave
p.s. I'm having trouble building the latest VMM and SVN sources on Linux. The resulting VM does not see the X11-display plugin. Probably I'm doing something dumb, but is anyone else seeing this problem?
First, I botched that report, should have been #isMemberOf:->isSymbol, instead of the opposite. Just in case anyone else is following this here, instead of on Mantis.
David T. Lewis wrote:
I think there are a few little glitches related to ByteSymbol in the latest VMM/SVN sources etc (I'm trying to figure the same thing out myself as soon as I get a bit of free time).
Note that Tim has apparently already fixed this particular instance that I know about in his versions, but this change has not yet made it to SqueakMap.
[current state of OSPP/VMM] I thought I'd mention that after fixing that small thing, and reading some documentation, I did manage to build OSPP, and then run OSP, to the extent that GraphViz works, so I'm pretty satisfied. CommandShell also works pretty nicely.
From the 121 (!) UnixProcess* tests, 66 pass, 10 fail, 45 errors. Many of the errors give me an annoying OK box, saying that the process access module is not available (which I would prefer to have appear only when/if I investigate the bug).
Bottom line: For now, use one of Ian's distributions if you are running OSPP. Sorry for the inconvenience.
I am using the Debian packaged Squeak, which seems to be version 3.8a-1 (don't know from who). When compiling the sources, I got Ian's code (latest tar ball, not SVN), in which I didn't actually find the UnixProcess plugin. Are you sure its there?
I think OSProcess is great, and I think it should be available out of the box or very close to it. Not that I have really good ideas how to achieve that, just a wish.
p.s. I'm having trouble building the latest VMM and SVN sources on Linux. The resulting VM does not see the X11-display plugin. Probably I'm doing something dumb, but is anyone else seeing this problem?
Sorry, I built only that plugin, and placed it where my existing VM can see it, so I have no idea.
Daniel
On Wed, Jun 29, 2005 at 01:07:06AM +0300, Daniel Vainsencher wrote:
[current state of OSPP/VMM] I thought I'd mention that after fixing that small thing, and reading some documentation, I did manage to build OSPP, and then run OSP, to the extent that GraphViz works, so I'm pretty satisfied. CommandShell also works pretty nicely.
From the 121 (!) UnixProcess* tests, 66 pass, 10 fail, 45 errors. Many of the errors give me an annoying OK box, saying that the process access module is not available (which I would prefer to have appear only when/if I investigate the bug).
Hmmm, that's not quite where I would like to be. If you have a chance, would you mind running "OSProcess allTestResults" and mailing me a copy of the resulting OSProcessTestResults-<platform>.txt file? I'm looking to get zero errors and failures on a generic [Li|U]nux box, and some indeterminate number of problems on an OS X box with Unix VM.
I am using the Debian packaged Squeak, which seems to be version 3.8a-1 (don't know from who). When compiling the sources, I got Ian's code (latest tar ball, not SVN), in which I didn't actually find the UnixProcess plugin. Are you sure its there?
I think OSProcess is great, and I think it should be available out of the box or very close to it. Not that I have really good ideas how to achieve that, just a wish.
Thanks, much appreciated.
Nowadays, Ian packages OSPP with all of his binary distributions, so it's just a matter of loading OSProcess and CommandShell from SqueakMap. That seems reasonably "out of the box" for a package that is still quite platform dependent. I'm not sure about the Debian packages. I think that Lex puts these together (?) but I don't know what is included.
As far as the sources go, you need to load VMM, XDisplayControlPlugin, and OSPP from SqueakMap separately. But that's just because I'm still maintaining OSPP and XDisplayControlPlugin separately from VMM. It would be easy enough to move them over to VMM some time after I get run over by a truck, or if Tim happens to be looking for more aggrivation than he already has with the rest of the plugins.
[hmmm, come to think of it, I'll bet that you did not build an XDisplayControlPlugin, and that's probably where those SUnit errors are coming from]
Dave
David T. Lewis wrote:
Hmmm, that's not quite where I would like to be. If you have a chance, would you mind running "OSProcess allTestResults" and mailing me a copy of the resulting OSProcessTestResults-<platform>.txt file? I'm looking to get zero errors and failures on a generic [Li|U]nux box, and some indeterminate number of problems on an OS X box with Unix VM.
Ok, attached.
Nowadays, Ian packages OSPP with all of his binary distributions, so it's just a matter of loading OSProcess and CommandShell from SqueakMap. That seems reasonably "out of the box" for a package that is still quite platform dependent.
Yup.
I'm not sure about the Debian packages. I think that Lex puts these together (?) but I don't know what is included.
Now that I looked, I'm using the one by Lex. According to dpkg -L squeak-vm, it includes neither of OSPP and XDisplayControlPlugin.
[hmmm, come to think of it, I'll bet that you did not build an XDisplayControlPlugin, and that's probably where those SUnit errors are coming from]
I didn't - that's probably it. I think that having a note in the SM entry that says "requires SmalltalkImage current listLoadedModules to include X,Y" would probably help here.
Daniel
On Wed, Jun 29, 2005 at 10:21:06AM +0300, Daniel Vainsencher wrote:
David T. Lewis wrote:
Hmmm, that's not quite where I would like to be. If you have a chance, would you mind running "OSProcess allTestResults" and mailing me a copy of the resulting OSProcessTestResults-<platform>.txt file? I'm looking to get zero errors and failures on a generic [Li|U]nux box, and some indeterminate number of problems on an OS X box with Unix VM.
Ok, attached.
Nowadays, Ian packages OSPP with all of his binary distributions, so it's just a matter of loading OSProcess and CommandShell from SqueakMap. That seems reasonably "out of the box" for a package that is still quite platform dependent.
Yup.
I'm not sure about the Debian packages. I think that Lex puts these together (?) but I don't know what is included.
Now that I looked, I'm using the one by Lex. According to dpkg -L squeak-vm, it includes neither of OSPP and XDisplayControlPlugin.
[hmmm, come to think of it, I'll bet that you did not build an XDisplayControlPlugin, and that's probably where those SUnit errors are coming from]
I didn't - that's probably it. I think that having a note in the SM entry that says "requires SmalltalkImage current listLoadedModules to include X,Y" would probably help here.
Thanks for sending the test results. I tried removing XDisplayControlPlugin on my system, and I get the same results. So it looks like I have failed to handle this dependency properly, and I definitely need to document it as you suggest.
Thanks for pointing this out. It's amazing the things you can overlook when you are trying to check your own work ;)
Dave
Some funny things and questions: 1. I've now managed to build XDCP, put it in the plugin directory. Test still fail. Stop Squeak and restart, tests pass. Aren't plugins supposed to be loaded on demand? why did I have to stop and restart? 2. Now I get 100 tests, all green. Before I got 121, 66 green. So I suspect before I ran some extraneous tests. How many tests should be run for the UnixProcess*TestCase? I get 102 green, when I run add OSPipeTestCase. That's everything under Tests-OSProcess. Is there any other test I should run? 3. XDCP code is under yet another class category, VMConstruction. 4. I wanted to build only new external plugins (to add to an existing VM). So in VMMaker, I said, "generate external plugins". When I ran configure, I got an error that the file plugin.int is missing. This was corrected when in VMM, I generated everything, and tried again. Why is this needed?
Daniel
David T. Lewis wrote:
On Wed, Jun 29, 2005 at 10:21:06AM +0300, Daniel Vainsencher wrote:
David T. Lewis wrote:
Hmmm, that's not quite where I would like to be. If you have a chance, would you mind running "OSProcess allTestResults" and mailing me a copy of the resulting OSProcessTestResults-<platform>.txt file? I'm looking to get zero errors and failures on a generic [Li|U]nux box, and some indeterminate number of problems on an OS X box with Unix VM.
Ok, attached.
Nowadays, Ian packages OSPP with all of his binary distributions, so it's just a matter of loading OSProcess and CommandShell from SqueakMap. That seems reasonably "out of the box" for a package that is still quite platform dependent.
Yup.
I'm not sure about the Debian packages. I think that Lex puts these together (?) but I don't know what is included.
Now that I looked, I'm using the one by Lex. According to dpkg -L squeak-vm, it includes neither of OSPP and XDisplayControlPlugin.
[hmmm, come to think of it, I'll bet that you did not build an XDisplayControlPlugin, and that's probably where those SUnit errors are coming from]
I didn't - that's probably it. I think that having a note in the SM entry that says "requires SmalltalkImage current listLoadedModules to include X,Y" would probably help here.
Thanks for sending the test results. I tried removing XDisplayControlPlugin on my system, and I get the same results. So it looks like I have failed to handle this dependency properly, and I definitely need to document it as you suggest.
Thanks for pointing this out. It's amazing the things you can overlook when you are trying to check your own work ;)
Dave
On Wed, Jun 29, 2005 at 02:06:33PM +0300, Daniel Vainsencher wrote:
Some funny things and questions:
- I've now managed to build XDCP, put it in the plugin directory. Test
still fail. Stop Squeak and restart, tests pass. Aren't plugins supposed to be loaded on demand? why did I have to stop and restart?
I'm not certain, but I believe that if the lookup fails once, it will continue to fail. This would be for performance reasons; you would not want do time consuming dynamic library lookups every time you call a primitive when you already know that the plugin does not exit.
- Now I get 100 tests, all green. Before I got 121, 66 green. So I
suspect before I ran some extraneous tests. How many tests should be run for the UnixProcess*TestCase? I get 102 green, when I run add OSPipeTestCase. That's everything under Tests-OSProcess. Is there any other test I should run?
I'm away from my Squeak box now, so I can't check. Have a look at the OSProcess and CommandShell change sets that you loaded. I think there is a total of seven SUnit classes. OSProcess class>>allTestResults runs some or all of them, I don't quite recall.
- XDCP code is under yet another class category, VMConstruction.
- I wanted to build only new external plugins (to add to an existing
VM). So in VMMaker, I said, "generate external plugins". When I ran configure, I got an error that the file plugin.int is missing. This was corrected when in VMM, I generated everything, and tried again. Why is this needed?
OSPP should be in the same category as XDCP, but I mistakenly moved it to VMMaker-* in the most recent release. This was a botch on my part.
I think that you do need to "generate all" if you add or remove plugins in VMMaker. There are some source files generated that specify what plugins are internal and external, most likely VMM does this only when you generate all the sources.
Dave
"David T. Lewis" lewis@mail.msen.com wrote:
[snip]
I think that you do need to "generate all" if you add or remove plugins in VMMaker. There are some source files generated that specify what plugins are internal and external, most likely VMM does this only when you generate all the sources.
There's certainly bound to be a number of cases where some sort of interlock is needed between various files. I know I can't have handled all of them. Moving plugins around from internal to external is something that gets very little exercise because pretty much nobody changes the setups from one build to another. Andreas builds everything internal (I think), John makes almost everything internal, I do everything external and Ian probably does most internal. Moving a plugin to external and then generating externals only will likely leave the generated 'plugin.int' out of the picture - which seems reasonable since you haven't generated any of the core and internal plugins yet. If you had previously (ie in the same run ofVMMaker) generated the core+internal, it would probably work. If you _then_ moved the plugin from internal to external I imagine it might blow up interestingly.
In this case I think that configure is getting it wrong since an absent plugin.int ought to tell it that there are no internal plugins to deal with.
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim Useful random insult:- Parents beat him with an ugly stick.
David T. Lewis wrote:
- I've now managed to build XDCP, put it in the plugin directory. Test
still fails. Stop Squeak and restart, tests pass. Aren't plugins supposed to be loaded on demand? why did I have to stop and restart?
I'm not certain, but I believe that if the lookup fails once, it will continue to fail. This would be for performance reasons; you would not want do time consuming dynamic library lookups every time you call a primitive when you already know that the plugin does not exit.
So, how do I tell the VM to forgive and forget, and do the look up again?
Daniel
This seems underdocumented in the image. How about
forgetModule: aString "Primitive. If the module named aString is loaded, unloaded. If not, and it is marked as unloadable, unmark it so the VM will try to load it again next time. See comment for #unloadModule:." <primitive: 571> ^self primitiveFailed
in addition to or instead of unloadModule:?
Daniel
Andreas Raab wrote:
Smalltalk unloadModule: #MyPlugin
Sigh. SmalltalkImage current unloadModule: #MyPlugin. Sigh.
- A.
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Daniel Vainsencher -
David T. Lewis -
Ken Causey -
Tim Rowledge