Strange unix (Pi) vm event bug for july 2016 era vm build

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Strange unix (Pi) vm event bug for july 2016 era vm build

timrowledge

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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DMZ: Divide Memory by Zero


Reply | Threaded
Open this post in threaded view
|

Re: Strange unix (Pi) vm event bug for july 2016 era vm build

fniephaus
 
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 <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DMZ: Divide Memory by Zero


Reply | Threaded
Open this post in threaded view
|

{Q] Pluggins for Spur

Edgar De Cleene
 
{Q] Pluggins for Spur
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


Reply | Threaded
Open this post in threaded view
|

Re: Strange unix (Pi) vm event bug for july 2016 era vm build

timrowledge
In reply to this post by fniephaus


> On 06-10-2016, at 11:49 PM, Fabio Niephaus <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Hid behind the door when they passed out brains.


Reply | Threaded
Open this post in threaded view
|

Re: Strange unix (Pi) vm event bug for july 2016 era vm build

fniephaus
 

On Fri, Oct 7, 2016 at 9:13 PM tim Rowledge <[hidden email]> wrote:


> On 06-10-2016, at 11:49 PM, Fabio Niephaus <[hidden email]> 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

 


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Hid behind the door when they passed out brains.


Reply | Threaded
Open this post in threaded view
|

Re: Strange unix (Pi) vm event bug for july 2016 era vm build

timrowledge

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; [hidden email]; 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

Reply | Threaded
Open this post in threaded view
|

Re: Strange unix (Pi) vm event bug for july 2016 era vm build

Ben Coman
 
> 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

oh! nice haiku...

protected abstract
virtual base purely virtual
private destructor

cheers -ben
Reply | Threaded
Open this post in threaded view
|

Re: Strange unix (Pi) vm event bug for july 2016 era vm build

David T. Lewis
In reply to this post by timrowledge
 
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

Reply | Threaded
Open this post in threaded view
|

Re: Strange unix (Pi) vm event bug for july 2016 era vm build

timrowledge


> On 08-10-2016, at 6:19 AM, David T. Lewis <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
"Bother!" said Pooh, searching for the $10m winning lottery ticket.


Reply | Threaded
Open this post in threaded view
|

Re: Strange unix (Pi) vm event bug for july 2016 era vm build

timrowledge


> On 08-10-2016, at 10:01 AM, tim Rowledge <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Several nuts over fruitcake minimum.


Reply | Threaded
Open this post in threaded view
|

Re: Strange unix (Pi) vm event bug for july 2016 era vm build

Tobias Pape


On 08.10.2016, at 19:13, tim Rowledge <[hidden email]> wrote:

>
>
>> On 08-10-2016, at 10:01 AM, tim Rowledge <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
> Useful random insult:- Several nuts over fruitcake minimum.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Strange unix (Pi) vm event bug for july 2016 era vm build

David T. Lewis
In reply to this post by timrowledge
 
On Sat, Oct 08, 2016 at 10:01:35AM -0700, tim Rowledge wrote:

>
>
> > On 08-10-2016, at 6:19 AM, David T. Lewis <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Strange unix (Pi) vm event bug for july 2016 era vm build

David T. Lewis
In reply to this post by Tobias Pape
 
On Sat, Oct 08, 2016 at 07:47:49PM +0200, Tobias Pape wrote:

>
>
> On 08.10.2016, at 19:13, tim Rowledge <[hidden email]> wrote:
>
> >
> >
> >> On 08-10-2016, at 10:01 AM, tim Rowledge <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Strange unix (Pi) vm event bug for july 2016 era vm build

Henrik Sperre Johansen
In reply to this post by timrowledge
 

> On 08 Oct 2016, at 5:43 , tim Rowledge <[hidden email]> 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?"

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Strange unix (Pi) vm event bug for july 2016 era vm build

timrowledge
In reply to this post by timrowledge

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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: ETO: Emulate Toaster Oven


Reply | Threaded
Open this post in threaded view
|

Re: Strange unix (Pi) vm event bug for july 2016 era vm build

timrowledge
In reply to this post by Henrik Sperre Johansen


> On 10-10-2016, at 5:15 AM, Henrik Johansen <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Has a one-way ticket on the Disoriented Express.


Reply | Threaded
Open this post in threaded view
|

Re: Strange unix (Pi) vm event bug for july 2016 era vm build

David T. Lewis
 
On Mon, Oct 10, 2016 at 11:03:16AM -0700, tim Rowledge wrote:
>
>
> > On 10-10-2016, at 5:15 AM, Henrik Johansen <[hidden email]> 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

 
Reply | Threaded
Open this post in threaded view
|

Re: Strange unix (Pi) vm event bug for july 2016 era vm build

timrowledge
In reply to this post by timrowledge

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; [hidden email]; http://www.rowledge.org/tim
Computing Dictionary: Recursive: (see Recursive)


Reply | Threaded
Open this post in threaded view
|

Re: Strange unix (Pi) vm event bug for july 2016 era vm build

timrowledge
In reply to this post by David T. Lewis


> On 10-10-2016, at 4:52 PM, David T. Lewis <[hidden email]> wrote:
>
>
> On Mon, Oct 10, 2016 at 11:03:16AM -0700, tim Rowledge wrote:
>>
>>
>>> On 10-10-2016, at 5:15 AM, Henrik Johansen <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: PFM: Pray For Miracle


Reply | Threaded
Open this post in threaded view
|

Re: Strange unix (Pi) vm event bug for july 2016 era vm build

David T. Lewis
 
On Mon, Oct 10, 2016 at 09:54:33PM -0700, tim Rowledge wrote:

>
>
> > On 10-10-2016, at 4:52 PM, David T. Lewis <[hidden email]> wrote:
> >
> >
> > On Mon, Oct 10, 2016 at 11:03:16AM -0700, tim Rowledge wrote:
> >>
> >>
> >>> On 10-10-2016, at 5:15 AM, Henrik Johansen <[hidden email]> 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

12