I have a really annoying bug afflicting a few users. As in several million…
The latest release of Raspbian includes a cog vm tagged 5.0-201607181657 and suffers from a very annoying habit of not (seemingly) passing in key-up events if another key has gone down since the first did. In ordinary typing of course this isn’t often an issue but for Scratch scripts that test things like cursor key presses (say for example, AsteroidBlaster) it gets very annoying because you get completely screwed by what seems to be a jammed key.
Aside for explanatory purpose - Scratch wants to be able to query whether a certain key is up or down, rather than making use of events per se. To provide this I have a very simple and so far effective keyboard event listener class that merely keeps a big array of true/false for each ascii value. Scratch checks that table for the requested ascii value.
On previous release vms and indeed a september 28 build, there was/is no problem. The key events come in, the listener gets pinged, the state is updated. Asteroids are blasted. With the july vm (the one shipped to several million kids) the up events are not coming in in quite the same way; if I press left-cursor, then right cursor, then release right and finally left, that last left-cursor-up event seems not to arrive. The *same* image on the other vm(s) works.
So far I’m completely unable to find any difference in the code! I’ve checked sqUnixEvent.c & sqUnixX11.c for example - any other plausible places where key events might get mangled? I see some recent-ish changes for some squeak/pharo labelling differences but that’s it. Can anyone recall making changes around the june/july era that might have had some effect? Not to mention something that *fixed* the problem sometime in early September?
Obviously one could say it’s fixed and to hell with it but it would be nice to understand what on earth went wrong. I also have to work out how it didn’t get spotted during the release testing but that;s a different problem.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DMZ: Divide Memory by Zero
Who decided to ship that VM with Raspbian? Even though this is the first "stable" release tag (which is why we used it for Squeak-5.1), it is known to have a keyboard input related bug. And like you said, the bug has apparently been fixed already, but I have no idea what was actually going on.
Do we need to release a newer version asap for Raspbian?
Best, Fabio
On Fri, 7 Oct 2016 at 01:26, tim Rowledge tim@rowledge.org wrote:
I have a really annoying bug afflicting a few users. As in several million…
The latest release of Raspbian includes a cog vm tagged 5.0-201607181657 and suffers from a very annoying habit of not (seemingly) passing in key-up events if another key has gone down since the first did. In ordinary typing of course this isn’t often an issue but for Scratch scripts that test things like cursor key presses (say for example, AsteroidBlaster) it gets very annoying because you get completely screwed by what seems to be a jammed key.
Aside for explanatory purpose - Scratch wants to be able to query whether a certain key is up or down, rather than making use of events per se. To provide this I have a very simple and so far effective keyboard event listener class that merely keeps a big array of true/false for each ascii value. Scratch checks that table for the requested ascii value.
On previous release vms and indeed a september 28 build, there was/is no problem. The key events come in, the listener gets pinged, the state is updated. Asteroids are blasted. With the july vm (the one shipped to several million kids) the up events are not coming in in quite the same way; if I press left-cursor, then right cursor, then release right and finally left, that last left-cursor-up event seems not to arrive. The *same* image on the other vm(s) works.
So far I’m completely unable to find any difference in the code! I’ve checked sqUnixEvent.c & sqUnixX11.c for example - any other plausible places where key events might get mangled? I see some recent-ish changes for some squeak/pharo labelling differences but that’s it. Can anyone recall making changes around the june/july era that might have had some effect? Not to mention something that *fixed* the problem sometime in early September?
Obviously one could say it’s fixed and to hell with it but it would be nice to understand what on earth went wrong. I also have to work out how it didn’t get spotted during the release testing but that;s a different problem.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DMZ: Divide Memory by Zero
In Cog on Mac I could put the Pluggins for VM like
1. Select the icon in Dock 2. Press right button and select Options -> Show in Finder 3. You should be into Applicatios folder and with the app selected 4. Press right button and select Show Package Contens 5. Navigate to Resources 6. Here my list
1. BochsIA32Plugin.bundle 2. ClipboardExtendedPlugin.bundle 3. CroquetPlugin.bundle 4. CurlPlugin.bundle 5. FloatArrayPlugin.bundle 6. FloatMathPlugin.bundle 7. FT2Plugin.bundle 8. IA32ABI.bundle 9. KedamaPlugin.bundle 10. KedamaPlugin2.bundle 11. LocalePlugin.bundle 12. mpeg3Plugin.bundle 13. ObjectiveCPlugin.bundle 14. OggPlugin.bundle 15. PrintJobPlugin.bundle 16. QuicktimePlugin.bundle 17. RePlugin.bundle 18. RomePlugin.bundle 19. SerialExtendedUnixPlugin.bundle 20. ServicesPlugin.bundle 21. SpellingPlugin.bundle 22. SqueakFFIPrims.bundle 23. SqueakSSL.bundle 24. TestOSAPlugin.bundle 25. UnixOSProcessPlugin.bundle
I know not all of this work on Spur, sure no via putting all on Resources folder
My questions
Where I found the appropriate files for Linux and how is the step by step way on having all this working on Linux?
Thanks in advance
Edgar @morplenauta
On 06-10-2016, at 11:49 PM, Fabio Niephaus lists@fniephaus.com wrote:
Who decided to ship that VM with Raspbian?
Well obviously, I did - that’s my job. I don’t recall the exact sequence but evidently at some point I pulled the latest sources and built them, found it apparently ok and put it in place. Shortly later I repeated with later sources and built another release package for Pi and sent it off to Cambridge as a replacement. Sadly in the usual chaos surrounding a big release of hundreds of applications with a new UI and many other bits, something got lost and the older vm was left in the release. The image got updated again later after some RC testing by my small coterie of enthusiastic testers - but *they* were using the better vm and so nobody had any problems with key events.
Pi Towers are assembling an updated .deb as I type.
Even though this is the first "stable" release tag (which is why we used it for Squeak-5.1), it is known to have a keyboard input related bug. And like you said, the bug has apparently been fixed already, but I have no idea what was actually going on.
The interesting question here - as well as what was wrong and what fixed it - is how come I didn’t see any comments about key problems at the time. Clearly I wouldn’t have used the vm if I had any idea of such a problem. Not that that explains how it wasn’t completely obvious when I tried it out… all very odd.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Hid behind the door when they passed out brains.
On Fri, Oct 7, 2016 at 9:13 PM tim Rowledge tim@rowledge.org wrote:
On 06-10-2016, at 11:49 PM, Fabio Niephaus lists@fniephaus.com wrote:
Who decided to ship that VM with Raspbian?
Well obviously, I did - that’s my job. I don’t recall the exact sequence but evidently at some point I pulled the latest sources and built them, found it apparently ok and put it in place. Shortly later I repeated with later sources and built another release package for Pi and sent it off to Cambridge as a replacement. Sadly in the usual chaos surrounding a big release of hundreds of applications with a new UI and many other bits, something got lost and the older vm was left in the release. The image got updated again later after some RC testing by my small coterie of enthusiastic testers - but *they* were using the better vm and so nobody had any problems with key events.
Pi Towers are assembling an updated .deb as I type.
That's great!
Even though this is the first "stable" release tag (which is why we used
it for Squeak-5.1), it is known to have a keyboard input related bug. And like you said, the bug has apparently been fixed already, but I have no idea what was actually going on.
The interesting question here - as well as what was wrong and what fixed it - is how come I didn’t see any comments about key problems at the time. Clearly I wouldn’t have used the vm if I had any idea of such a problem. Not that that explains how it wasn’t completely obvious when I tried it out… all very odd.
I spent the last 30mins to do some research and I came to the conclusion that I might have mixed this up with [1]. Nonetheless, I went through the changes since 201608171728 [2] and all keyboard-related changes I was able to find were in [3], but those seem unrelated. Also checking the news until VMMaker.oscog-cb.1919 at [4] didn't bring up anything related. So I am afraid that's all I know. And I believe it could be tough to solve this mystery because many (good) things happened since that release (PharoVM changes are being merged back by Esteban, CB and Eliot are actively working on Sista, Nicolas is working on various things, ...).
Maybe someone else can help...
Fabio
[1] http://forum.world.st/Re-VM-Crash-on-Mac-with-Input-Method-Vm-dev-Re-squeak-... [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/201608171728...Cog [3] https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/e24f4da5a82e2b37a3e... [4] http://source.squeak.org/VMMaker.html
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Hid behind the door when they passed out brains.
Right, well I think I have a handle on this oddity. It’s both trickier and simpler than I expected.
We (as in Pi Towers) built a new package with the 20160818 0858 vm. Yippee!
Oh pooh; install it and the bug is still there. Damn. How is this possible?
Binary diff all the vm files (such fun) and they’re all identical. But when the vm is in my working directory it is fine - in the /usr/lib/blah end-user location, bug. How is it possible?
Actually I’m going to stop there and see if anyone else spots what is happening, just for fun.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one? -- Tom Cargin
On Fri, Oct 07, 2016 at 08:43:23PM -0700, tim Rowledge wrote:
Right, well I think I have a handle on this oddity. It???s both trickier and simpler than I expected.
We (as in Pi Towers) built a new package with the 20160818 0858 vm. Yippee!
Oh pooh; install it and the bug is still there. Damn. How is this possible?
Binary diff all the vm files (such fun) and they???re all identical. But when the vm is in my working directory it is fine - in the /usr/lib/blah end-user location, bug. How is it possible?
Actually I???m going to stop there and see if anyone else spots what is happening, just for fun.
Keyboard settings. Your personal account on the PI is configured for a different keyboard setting than whatever is delivered by default for Raspian.
Dave
On 08-10-2016, at 6:19 AM, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Oct 07, 2016 at 08:43:23PM -0700, tim Rowledge wrote:
Right, well I think I have a handle on this oddity. It???s both trickier and simpler than I expected.
We (as in Pi Towers) built a new package with the 20160818 0858 vm. Yippee!
Oh pooh; install it and the bug is still there. Damn. How is this possible?
Binary diff all the vm files (such fun) and they???re all identical. But when the vm is in my working directory it is fine - in the /usr/lib/blah end-user location, bug. How is it possible?
Actually I???m going to stop there and see if anyone else spots what is happening, just for fun.
Keyboard settings. Your personal account on the PI is configured for a different keyboard setting than whatever is delivered by default for Raspian.
That’s so close it’s worthy of applause.
The one key difference between running the ‘0818’ vm in my local dir and in the ‘production’ dir is the content of the ‘squeak’ shell script. The production version is (for various reasons I can’t work out really) the script that we worked out to run the composition input subsystem a while back. I’m not sure why the lines that test for the need for the -compositioninput flag aren’t in the dev version.
It’s not even the use of the flag, but a side-effect of exporting $LANG. Combined, I strongly suspect but can’t prove yet, with *not* having all the additional support libraries etc installed. My guess right now is that there is a bug in the relevant code in sqUnixEvent or vm-display-X11 that looks for $LANG when it should only do that if the flag is also set.
I guess I have to install all the extra stuff on one of my Pi to see if that stops the problem even with $LANG getting exported. And any help on spotting where the actual bug is would be nice. X stuff is pretty opaque.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother!" said Pooh, searching for the $10m winning lottery ticket.
On 08-10-2016, at 10:01 AM, tim Rowledge tim@rowledge.org wrote:
X stuff is pretty opaque.
I take that back. It’s $%&#$%#98!@#ing insane. Time ten to the google’th power. Cubed.
Oh, and take a look at vm-display-X11/sqUnixX11.c ll: 2473-7 ; why on earth is a mouse button event getting modified differently if the cpu is PPC?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Several nuts over fruitcake minimum.
On 08.10.2016, at 19:13, tim Rowledge tim@rowledge.org wrote:
On 08-10-2016, at 10:01 AM, tim Rowledge tim@rowledge.org wrote:
X stuff is pretty opaque.
I take that back. It’s $%&#$%#98!@#ing insane. Time ten to the google’th power. Cubed.
Oh, and take a look at vm-display-X11/sqUnixX11.c ll: 2473-7 ; why on earth is a mouse button event getting modified differently if the cpu is PPC?
Maybe because Unix X11 on PPC meant OSX-PPC for quite a while? Macs do things different. When they should at most do things differently…
Best regards -Tobias
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Several nuts over fruitcake minimum.
On Sat, Oct 08, 2016 at 07:47:49PM +0200, Tobias Pape wrote:
On 08.10.2016, at 19:13, tim Rowledge tim@rowledge.org wrote:
On 08-10-2016, at 10:01 AM, tim Rowledge tim@rowledge.org wrote:
X stuff is pretty opaque.
I take that back. It?s $%&#$%#98!@#ing insane. Time ten to the google?th power. Cubed.
Well maybe. But it was designed well enough to have lasted 30 years. The computers and operating systems and network protocols that X11 was designed for (VAX, DECnet, VMS, Ultrix, and whatever IBM was using back then) are all long gone. But X11 is still happily chugging along on our tiny cheap Raspberry Pi gadgets, and it is included free with our free operating systems. Somebody must have done something right.
More importantly, if you compare the X11 event model to the Squeak event model, I think that it is fair to say that we have some room for improvement in Squeak. And perhaps there are a few things that we might learn by taking a closer look at the X11 event design.
Oh, and take a look at vm-display-X11/sqUnixX11.c ll: 2473-7 ; why on earth is a mouse button event getting modified differently if the cpu is PPC?
Maybe because Unix X11 on PPC meant OSX-PPC for quite a while? Macs do things different. When they should at most do things differently?
Possibly it is something related to the different byte ordering on that platform. It has been that way since at least 2003, so it is not likely related to any recent bugs.
Dave
On Sat, Oct 08, 2016 at 10:01:35AM -0700, tim Rowledge wrote:
On 08-10-2016, at 6:19 AM, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Oct 07, 2016 at 08:43:23PM -0700, tim Rowledge wrote:
Right, well I think I have a handle on this oddity. It???s both trickier and simpler than I expected.
We (as in Pi Towers) built a new package with the 20160818 0858 vm. Yippee!
Oh pooh; install it and the bug is still there. Damn. How is this possible?
Binary diff all the vm files (such fun) and they???re all identical. But when the vm is in my working directory it is fine - in the /usr/lib/blah end-user location, bug. How is it possible?
Actually I???m going to stop there and see if anyone else spots what is happening, just for fun.
Keyboard settings. Your personal account on the PI is configured for a different keyboard setting than whatever is delivered by default for Raspian.
That???s so close it???s worthy of applause.
The one key difference between running the ???0818??? vm in my local dir and in the ???production??? dir is the content of the ???squeak??? shell script. The production version is (for various reasons I can???t work out really) the script that we worked out to run the composition input subsystem a while back. I???m not sure why the lines that test for the need for the -compositioninput flag aren???t in the dev version.
It???s not even the use of the flag, but a side-effect of exporting $LANG. Combined, I strongly suspect but can???t prove yet, with *not* having all the additional support libraries etc installed. My guess right now is that there is a bug in the relevant code in sqUnixEvent or vm-display-X11 that looks for $LANG when it should only do that if the flag is also set.
I guess I have to install all the extra stuff on one of my Pi to see if that stops the problem even with $LANG getting exported. And any help on spotting where the actual bug is would be nice. X stuff is pretty opaque.
Here is how to debug the X11 events that are delivered to the Squeak VM:
First start Squeak (Scratch) on your Raspberry Pi. The VM will open a new X11 window as a container, then open a second child X11 window inside the first. The child X11 window is used for the actual Squeak display. The vm-display-X11 VM module looks for events delivered to that child window, and turns the interesting ones into Squeak events that are delivered to the image.
Open a separate terminal window in the desktop on your Pi to use for event display.
In that window, use the xwininfo utlity to find the X11 window ID for the child window used for Squeak display. Run xwininfo -tree, then click anywhere on the Squeak display to get the information:
pi@raspberrypi:~/squeak/VM-Git/opensmalltalk-vm/image $ xwininfo -tree
xwininfo: Please select the window about which you would like information by clicking the mouse in that window.
xwininfo: Window id: 0x2c00001 "SpurVMMaker.image"
Root window id: 0x25 (the root window) (has no name) Parent window id: 0x1400c48 (has no name) 1 child: 0x2c00002 (has no name): () 1124x804+0+0 +11+100
The window we want is the child window, which in this example has X11 window ID 0x2c00002.
Use the xev utility to show X11 events delivered to this window from the X11 server. In this case we only want keyboard events (see the xev man page for other options):
pi@raspberrypi:~/squeak/VM-Git/opensmalltalk-vm/image $ xev -id 0x2c00002 -event keyboard
KeymapNotify event, serial 13, synthetic NO, window 0x0, keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
KeymapNotify event, serial 13, synthetic NO, window 0x0, keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
KeymapNotify event, serial 13, synthetic NO, window 0x0, keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
KeymapNotify event, serial 13, synthetic NO, window 0x0, keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
KeyPress event, serial 13, synthetic NO, window 0x2c00002, root 0x25, subw 0x0, time 2779572111, (283,270), root:(294,370), state 0x0, keycode 43 (keysym 0x66, f), same_screen YES, XLookupString gives 1 bytes: (66) "f" XmbLookupString gives 1 bytes: (66) "f" XFilterEvent returns: False
This will continuously display the X11 event information as it is delivered to vm-display-11. If it scrolls by too quickly to see what is happening, you can redirect the output of xev to a file, type a few keystrokes in Squeak, stop the xev program, and review the file to see what happened.
HTH, Dave
I can stop the errant key event problem by removing a single line from my /usr/bin/squeak script.
We have a small section that exports a couple of values if [ -z $LC_ALL ]; then export LC_ALL=$LANG export LANGUAGE=$LANG fi
If I comment out the first export there is no problem.
I *think* that means that the problem is in the x2sqKeyInput() function which seems to get substituted for x2sqKeyPlain() if getenv(“LC_ALL”) is true. I was pretty much expecting to see that it was the x2sqKeyCompositionInput() causing the problem since it is the newer bit of code directly associated with the changes.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ETO: Emulate Toaster Oven
On 08 Oct 2016, at 5:43 , tim Rowledge tim@rowledge.org wrote:
Right, well I think I have a handle on this oddity. It’s both trickier and simpler than I expected.
We (as in Pi Towers) built a new package with the 20160818 0858 vm. Yippee!
Oh pooh; install it and the bug is still there. Damn. How is this possible?
Binary diff all the vm files (such fun) and they’re all identical. But when the vm is in my working directory it is fine - in the /usr/lib/blah end-user location, bug. How is it possible?
Actually I’m going to stop there and see if anyone else spots what is happening, just for fun.
tim
20160915 had one redeeming feature from my PoV; it shipped with a working OSProcessPlugin (thanks!) 20160915+1 does not. (but stdout/stdin/stderr, which gave write errors in previous, seem fixed).
I can't do apt-get install nuscratch=20160915 to get the old version after a dist-upgrade, seemingly the package cache only maintains latest version?
The poor mans patch works though; downloading the old version manually from archive.raspberrypi.org/debian/pool/main/n/nuscratch, and replacing the installed version.
A minor thing; secondary users can't run squeak/scratch by default, getting "pthread_setschedparam not permitted" error (The pi user must have quite some super rights...) As the shipped vm is a ht variant, although the base case for scratch use rarely requires it*, it would be nice if /etc/security/limits.d/squeak.conf was added as part of the squeak package as described in README on f.ex. www.mirandabanda.org/files/Cog/VM/latest I've tested, and it works.
(Also, the error message referenced a README with url to a non-existent build on mirandabanda.org, not sure if it was built from same source as CI, or if that message should be updated to reference bintray?)
Cheers, Henry
* After all, there's no UI to change users, and though I guess some kid out there would find digging into unix cli authorization management** a blast, for the rest of us, it's something to endure when necessary.
** "Why can't I see any WiFi nets? What do you mean my useradd'ed user isn't in the proper (netdev) group? Who is wpa_supplicant, and why is he making my life harder on purpose?"
On 10-10-2016, at 5:15 AM, Henrik Johansen henrik.s.johansen@veloxit.no wrote:
20160915 had one redeeming feature from my PoV; it shipped with a working OSProcessPlugin (thanks!)
OK, that’s an interesting issue. I don’t recall adding it and I don’t recall removing it..
20160915+1 does not. (but stdout/stdin/stderr, which gave write errors in previous, seem fixed).
Slightly later vm, presumably post some fix.
I can't do apt-get install nuscratch=20160915 to get the old version after a dist-upgrade, seemingly the package cache only maintains latest version?
No idea on that. I’m not sure the package is fully and properly set up to be honest. I don’t have anything to do with that part.
A minor thing; secondary users can't run squeak/scratch by default, getting "pthread_setschedparam not permitted" error (The pi user must have quite some super rights...) As the shipped vm is a ht variant, although the base case for scratch use rarely requires it*, it would be nice if /etc/security/limits.d/squeak.conf was added as part of the squeak package as described in README on f.ex. www.mirandabanda.org/files/Cog/VM/latest I've tested, and it works.
You’re referring to not-pi user names yes? I’ve not tried using any such and I don’t think anyone recommends it because of issues like this. I’ve seen occasional messages on the subject on the Pi forums. To be honest I’d urge you to go there (raspberrypi.org, try the Raspbian forum) to ask about it. The sigline insult below applies to me in this area.
My experience with user privilege issues is using xrdp or vnc to remotely display stuff. We just got that sorted (I think!) in the latest Raspbian.
(Also, the error message referenced a README with url to a non-existent build on mirandabanda.org, not sure if it was built from same source as CI, or if that message should be updated to reference bintray?)
Guess that’s an issue for Eliot to handle since it is his website.
Cheers, Henry
- After all, there's no UI to change users, and though I guess some kid out there would find digging into unix cli authorization management** a blast, for the rest of us, it's something to endure when necessary.
** "Why can't I see any WiFi nets? What do you mean my useradd'ed user isn't in the proper (netdev) group? Who is wpa_supplicant, and why is he making my life harder on purpose?”
He is a close friend of General ProtectionError, who is forever reading my disk.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Has a one-way ticket on the Disoriented Express.
On Mon, Oct 10, 2016 at 11:03:16AM -0700, tim Rowledge wrote:
On 10-10-2016, at 5:15 AM, Henrik Johansen henrik.s.johansen@veloxit.no wrote:
20160915 had one redeeming feature from my PoV; it shipped with a working OSProcessPlugin (thanks!)
OK, that???s an interesting issue. I don???t recall adding it and I don???t recall removing it..
Use VMConstruction-Plugins-OSProcessPlugin-dtl.40. That is the latest version of my OSProcessPlugin, and it works correctly on Raspbian.
VMConstruction-Plugins-OSProcessPlugin.oscog-eem.53 does not work on Raspbian, and it fails UnixProcessAccessorTestCase>>testRedirectStdOutTo.
Dave
On 10-10-2016, at 4:52 PM, David T. Lewis lewis@mail.msen.com wrote:
On Mon, Oct 10, 2016 at 11:03:16AM -0700, tim Rowledge wrote:
On 10-10-2016, at 5:15 AM, Henrik Johansen henrik.s.johansen@veloxit.no wrote:
20160915 had one redeeming feature from my PoV; it shipped with a working OSProcessPlugin (thanks!)
OK, that???s an interesting issue. I don???t recall adding it and I don???t recall removing it..
Use VMConstruction-Plugins-OSProcessPlugin-dtl.40. That is the latest version of my OSProcessPlugin, and it works correctly on Raspbian.
VMConstruction-Plugins-OSProcessPlugin.oscog-eem.53 does not work on Raspbian, and it fails UnixProcessAccessorTestCase>>testRedirectStdOutTo.
Yah, a search of mail reveals we got this worked through about three months ago. Just copying over the generated sources, nothing clever. It really would be nice to get the whole thing sorted properly. Say, Dave, you’ve had to take a break from that thrill laden life of Blindfolded Naked High Altitude Para Cave Diving you normally enjoy; got time?
tim PS One of my younger (and stupider) brothers used to jump out of perfectly good aeroplanes with a parachute and scuba gear to go cave diving. I really hope he never did it nekkid. -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: PFM: Pray For Miracle
On Mon, Oct 10, 2016 at 09:54:33PM -0700, tim Rowledge wrote:
On 10-10-2016, at 4:52 PM, David T. Lewis lewis@mail.msen.com wrote:
On Mon, Oct 10, 2016 at 11:03:16AM -0700, tim Rowledge wrote:
On 10-10-2016, at 5:15 AM, Henrik Johansen henrik.s.johansen@veloxit.no wrote:
20160915 had one redeeming feature from my PoV; it shipped with a working OSProcessPlugin (thanks!)
OK, that???s an interesting issue. I don???t recall adding it and I don???t recall removing it..
Use VMConstruction-Plugins-OSProcessPlugin-dtl.40. That is the latest version of my OSProcessPlugin, and it works correctly on Raspbian.
VMConstruction-Plugins-OSProcessPlugin.oscog-eem.53 does not work on Raspbian, and it fails UnixProcessAccessorTestCase>>testRedirectStdOutTo.
Yah, a search of mail reveals we got this worked through about three months ago. Just copying over the generated sources, nothing clever. It really would be nice to get the whole thing sorted properly. Say, Dave, you???ve had to take a break from that thrill laden life of Blindfolded Naked High Altitude Para Cave Diving you normally enjoy; got time?
I'll try to double-check it this weekend, but we already know that the the version that I want people to use (i.e. mine) works fine. Granted we did not try regenerating the C source from an oscog image, but I can't think of any reason why that would not work.
I really would prefer if people would use the original version of OSPP that I maintain. After all, I tend to be the person who ends up answering questions like "why doesn't OSProcess work on my Raspberry Pi?"
Mind you, I'm not at all sorry that I bought that Raspberry Pi to figure out why OSProcess was not working. Very cool little gadget, and I'm glad you finally gave me an excuse to go get one :-)
tim PS One of my younger (and stupider) brothers used to jump out of perfectly good aeroplanes with a parachute and scuba gear to go cave diving. I really hope he never did it nekkid.
Remind me to find a picture of the crude ultralight airplane I used to fly back in the 1980's. It would make your brother look reasonably sane. Inexplicably, I survived that one too.
Dave
On 11-10-2016, at 5:47 PM, David T. Lewis lewis@mail.msen.com wrote: [snip]
I'll try to double-check it this weekend, but we already know that the the version that I want people to use (i.e. mine) works fine. Granted we did not try regenerating the C source from an oscog image, but I can't think of any reason why that would not work.
If we’re talking moving your slang code across then the only likely problems would be some places where slang meta-commands clash - IIRC #ifCpp:type stuff differs a bit.
I really would prefer if people would use the original version of OSPP that I maintain. After all, I tend to be the person who ends up answering questions like "why doesn't OSProcess work on my Raspberry Pi?”
I tend to agree. What do we need to do to make it so?
Mind you, I'm not at all sorry that I bought that Raspberry Pi to figure out why OSProcess was not working. Very cool little gadget, and I'm glad you finally gave me an excuse to go get one :-)
Much fun can be obtained for little money. Why, you can now get Flash under Chromium and run Scratch2 directly from MIT’s website. And … it’s…. sl….ow…. with odd dd… jum…ps. Seriously. Flash. <head-desk>
Remind me to find a picture of the crude ultralight airplane I used to fly back in the 1980's. It would make your brother look reasonably sane. Inexplicably, I survived that one too.
Just so long as the mudguard stays stayed in pace, eh?
I’ve just built a latest vm with the unixosprocess .c file replaced by your one (taken from the old squeakvm.org tree, dated 6th jun, 8:10pm, hope that is the latest?) and loaded the OSProcess head package via squeakmap. I get 80 run, 71 passes, 0 expected failures, 5 failures, 4 errors, 0 unexpected passes. All the problems appear to be related to locking stuff, which is about as far as my ability will take me. Err, mind you 3 failures and 2 errors look like win32 tests, so just maybe they don’t count.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- POSH MORTEM - Death styles of the rich and famous
On Wed, Oct 12, 2016 at 03:12:40PM -0700, tim Rowledge wrote:
I???ve just built a latest vm with the unixosprocess .c file replaced by your one (taken from the old squeakvm.org tree, dated 6th jun, 8:10pm, hope that is the latest?) and loaded the OSProcess head package via squeakmap. I get 80 run, 71 passes, 0 expected failures, 5 failures, 4 errors, 0 unexpected passes. All the problems appear to be related to locking stuff, which is about as far as my ability will take me. Err, mind you 3 failures and 2 errors look like win32 tests, so just maybe they don???t count.
That will have to be "good enough" for now, sorry about that. I also get failures when running on Ubuntu on a fast machine. The tests have timing issues related to cooperating Squeak images that run in the tests, and the formerly all-green tests are failing now on the faster machines. I also suspect some differences related to file I/O differences as the OS runtimes have changed, but I can't say that for sure.
In any case, your plugin is working, and OSProcess and CommandShell should work fine in normal day-to-day use.
Dave
Hi David, Hi Tim,
On Mon, Oct 10, 2016 at 4:52 PM, David T. Lewis lewis@mail.msen.com wrote:
On Mon, Oct 10, 2016 at 11:03:16AM -0700, tim Rowledge wrote:
On 10-10-2016, at 5:15 AM, Henrik Johansen <
henrik.s.johansen@veloxit.no> wrote:
20160915 had one redeeming feature from my PoV; it shipped with a
working OSProcessPlugin (thanks!)
OK, that???s an interesting issue. I don???t recall adding it and I
don???t recall removing it..
Use VMConstruction-Plugins-OSProcessPlugin-dtl.40. That is the latest version of my OSProcessPlugin, and it works correctly on Raspbian.
VMConstruction-Plugins-OSProcessPlugin.oscog-eem.53 does not work on Raspbian, and it fails UnixProcessAccessorTestCase>>testRedirectStdOutTo.
This is unsatisfactory. I forked from VMConstruction-Plugins-OSProcessPlugin-dtl.40 because the Slang support has evolved for VMMaker.oscog, and not sufficiently for VMMaker. For example, the VMMaker code assumes the source is generated for the current platform, whereas the VMMaker.oscog code assumes the plugin is generated irrespective of platform (because in opensmalltalk/vm we store the generated code, and hence we want code generated for all platforms, not just the "current" one).
In no way was I trying to undermine OSProcessPlugin or your authorship. i merely wanted to keep the code moving along with the rest of VMMaker.oscog so I could continue to generate the plugin source.
So, in the absence of our harmonising the source so there is again only one VMConstruction-Plugins-OSProcessPlugin, can we please fold back the bug fixes? If you point out what the bug fixes are I'll happily do the merge.
Dave
On Tue, Oct 18, 2016 at 03:46:13PM -0700, Eliot Miranda wrote:
Hi David, Hi Tim,
On Mon, Oct 10, 2016 at 4:52 PM, David T. Lewis lewis@mail.msen.com wrote:
On Mon, Oct 10, 2016 at 11:03:16AM -0700, tim Rowledge wrote:
On 10-10-2016, at 5:15 AM, Henrik Johansen <
henrik.s.johansen@veloxit.no> wrote:
20160915 had one redeeming feature from my PoV; it shipped with a
working OSProcessPlugin (thanks!)
OK, that???s an interesting issue. I don???t recall adding it and I
don???t recall removing it..
Use VMConstruction-Plugins-OSProcessPlugin-dtl.40. That is the latest version of my OSProcessPlugin, and it works correctly on Raspbian.
VMConstruction-Plugins-OSProcessPlugin.oscog-eem.53 does not work on Raspbian, and it fails UnixProcessAccessorTestCase>>testRedirectStdOutTo.
This is unsatisfactory. I forked from VMConstruction-Plugins-OSProcessPlugin-dtl.40 because the Slang support has evolved for VMMaker.oscog, and not sufficiently for VMMaker. For example, the VMMaker code assumes the source is generated for the current platform, whereas the VMMaker.oscog code assumes the plugin is generated irrespective of platform (because in opensmalltalk/vm we store the generated code, and hence we want code generated for all platforms, not just the "current" one).
In no way was I trying to undermine OSProcessPlugin or your authorship. i merely wanted to keep the code moving along with the rest of VMMaker.oscog so I could continue to generate the plugin source.
So, in the absence of our harmonising the source so there is again only one VMConstruction-Plugins-OSProcessPlugin, can we please fold back the bug fixes? If you point out what the bug fixes are I'll happily do the merge.
Hi Eliot,
Sorry, but I do not know why the oscog version is crashing on Raspbian.
Dave
I’ve spent a positively *delightful* day trying to debug this awful code and I’m pretty much out of sanity.
What I’ve been able to find out is -
the exporting of LC_ALL = $LANG causes usage of the x2sqKeyInput() function (via pointer x2sqKey) instead of x2sqKeyPlain().
with x2sqKeyPlain() in use there is no bug here.
with x2sqKeyInput() in use, something results in a -1 value being returned to handleEvent() case KeyRelease where `keyCode= x2sqKey…` is called. This means the next clause skips the key up event, which seems to be the problem. My best guess is that the problem must be something to do with the settings of the local static var lastKey.
The part that really puzzles me is that we appeared to not have a problem when the assorted iBus/anthy stuff loaded; I can only imagine that there is some affect relating to XmbLookupString() that is magic. I can’t recall any problem with the chording of keypresses between when I installed that (around july when working with Yoshiki on the composition input stuff) and moving to the new Raspbian release where the ibus etc is not installed. Right now I simply don’t have time or energy to push this any further and mess with installing and de-installing things.
Somebody that actually feels they understand it will have to jump in!
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Computing Dictionary: Recursive: (see Recursive)
vm-dev@lists.squeakfoundation.org
-
Ben Coman -
David T. Lewis -
Edgar J. De Cleene -
Eliot Miranda -
Fabio Niephaus -
Henrik Johansen -
tim Rowledge -
Tobias Pape