Hello,
As some people aware, we have a problem with Japanese text input into Squeak on X11, especially with NuScratch.
I've been punting to work on this but now Manabu Sugiura volunteered and I decided to just do what it takes to help him.
I wrote some code to support Japanese text input works on X11 when OLPC XO time, but things diverged since then. My understanding is that porting the code from that branch into the later branch(es), most notably the VM that NuScratch uses; But I am pretty sure there are more differences I am not aware of. Please let us know if there are some foreseeable issues. And please consider incorporating patches Manabu (and I) will produce when it is ready.
Thanks!
Hi Yoshiki,
On May 5, 2016, at 8:49 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Hello,
As some people aware, we have a problem with Japanese text input into Squeak on X11, especially with NuScratch.
I've been punting to work on this but now Manabu Sugiura volunteered and I decided to just do what it takes to help him.
I wrote some code to support Japanese text input works on X11 when OLPC XO time, but things diverged since then. My understanding is that porting the code from that branch into the later branch(es), most notably the VM that NuScratch uses; But I am pretty sure there are more differences I am not aware of.
Are you targeting the interpreter trunk or the cig JIT branch?
Please let us know if there are some foreseeable issues. And please consider incorporating patches Manabu (and I) will produce when it is ready.
We are about to move the Cig branch from svn on squeakvm.org to git on github. But I'm very happy to integrate patches into the svn tree before we've finished the move. Let me know if I can help in any way. Thanks for this!
Thanks!
-- -- Yoshiki
_,,,^..^,,,_ (phone)
On Thu, May 5, 2016 at 9:51 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On May 5, 2016, at 8:49 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Hello,
As some people aware, we have a problem with Japanese text input into Squeak on X11, especially with NuScratch.
I've been punting to work on this but now Manabu Sugiura volunteered and I decided to just do what it takes to help him.
I wrote some code to support Japanese text input works on X11 when OLPC XO time, but things diverged since then. My understanding is that porting the code from that branch into the later branch(es), most notably the VM that NuScratch uses; But I am pretty sure there are more differences I am not aware of.
Are you targeting the interpreter trunk or the cig JIT branch?
It actually is not clear yet which branches are the right one for current Scratch on raspi and also future proof. Perhaps doing for multiple branches is necessary? (What are the relationship of those?)
Please let us know if there are some foreseeable issues. And please consider incorporating patches Manabu (and I) will produce when it is ready.
We are about to move the Cig branch from svn on squeakvm.org to git on github. But I'm very happy to integrate patches into the svn tree before we've finished the move. Let me know if I can help in any way. Thanks for this!
Thank you!
On 05-05-2016, at 10:36 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
It actually is not clear yet which branches are the right one for current Scratch on raspi and also future proof. Perhaps doing for multiple branches is necessary? (What are the relationship of those?)
Oh, it’s absolutely clear for the Pi; Cog/Spur. The ancient original MIT image and an elderly interpreter are kept around for emergency use but will not be updated.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: FR: Flip Record
On 05-05-2016, at 10:36 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
It actually is not clear yet which branches are the right one for current Scratch on raspi and also future proof. Perhaps doing for multiple branches is necessary? (What are the relationship of those?)
Oh, itâs absolutely clear for the Pi; Cog/Spur. The ancient original MIT image and an elderly interpreter are kept around for emergency use but will not be updated.
We might need to harvest some older patches out of trunk and get them applied in our oscog branch.
Whatever it is that needs to be done, we'll all be happy to help :-)
Dave
On Thu, May 5, 2016 at 11:11 AM, tim Rowledge tim@rowledge.org wrote:
On 05-05-2016, at 10:36 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
It actually is not clear yet which branches are the right one for current Scratch on raspi and also future proof. Perhaps doing for multiple branches is necessary? (What are the relationship of those?)
Oh, it’s absolutely clear for the Pi; Cog/Spur. The ancient original MIT image and an elderly interpreter are kept around for emergency use but will not be updated.
Okay!
By any chance, can you tell me how you test things? for Raspberry Pi?
On 05-05-2016, at 1:02 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Thu, May 5, 2016 at 11:11 AM, tim Rowledge tim@rowledge.org wrote:
On 05-05-2016, at 10:36 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
It actually is not clear yet which branches are the right one for current Scratch on raspi and also future proof. Perhaps doing for multiple branches is necessary? (What are the relationship of those?)
Oh, it’s absolutely clear for the Pi; Cog/Spur. The ancient original MIT image and an elderly interpreter are kept around for emergency use but will not be updated.
Okay!
By any chance, can you tell me how you test things? for Raspberry Pi?
For Japanese input? I don’t, because I can’t and wouldn’t have the faintest idea if it were correct anyway. I leave it to Kazuhiro Abee to let me know when he notices something wrong.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A clear conscience is usually the sign of a bad memory.
On Thu, May 5, 2016 at 1:43 PM, tim Rowledge tim@rowledge.org wrote:
On 05-05-2016, at 1:02 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Thu, May 5, 2016 at 11:11 AM, tim Rowledge tim@rowledge.org wrote:
On 05-05-2016, at 10:36 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
It actually is not clear yet which branches are the right one for current Scratch on raspi and also future proof. Perhaps doing for multiple branches is necessary? (What are the relationship of those?)
Oh, it’s absolutely clear for the Pi; Cog/Spur. The ancient original MIT image and an elderly interpreter are kept around for emergency use but will not be updated.
Okay!
By any chance, can you tell me how you test things? for Raspberry Pi?
For Japanese input? I don’t, because I can’t and wouldn’t have the faintest idea if it were correct anyway. I leave it to Kazuhiro Abee to let me know when he notices something wrong.
Ah, no. I meant to ask how you test your things. Is there a dev image of some sort you are using (presumably .changes is there), and compiling VM and transferring it to a Pi, etc.
(I have done my own little share of compiling and testing things on Pi, which in the end involved compling C with some asm code on Pi on an SSH terminal and run it. But I am just curious how you've been doing it.)
Hi Yoshiki,
_,,,^..^,,,_ (phone)
On May 5, 2016, at 2:10 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Thu, May 5, 2016 at 1:43 PM, tim Rowledge tim@rowledge.org wrote:
On 05-05-2016, at 1:02 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Thu, May 5, 2016 at 11:11 AM, tim Rowledge tim@rowledge.org wrote:
On 05-05-2016, at 10:36 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
It actually is not clear yet which branches are the right one for current Scratch on raspi and also future proof. Perhaps doing for multiple branches is necessary? (What are the relationship of those?)
Oh, it’s absolutely clear for the Pi; Cog/Spur. The ancient original MIT image and an elderly interpreter are kept around for emergency use but will not be updated.
Okay!
By any chance, can you tell me how you test things? for Raspberry Pi?
For Japanese input? I don’t, because I can’t and wouldn’t have the faintest idea if it were correct anyway. I leave it to Kazuhiro Abee to let me know when he notices something wrong.
Ah, no. I meant to ask how you test your things. Is there a dev image of some sort you are using (presumably .changes is there), and compiling VM and transferring it to a Pi, etc.
(I have done my own little share of compiling and testing things on Pi, which in the end involved compling C with some asm code on Pi on an SSH terminal and run it. But I am just curious how you've been doing it.)
You'll find an updated squeak 5.0 trunk image on squeak.org/downloads, up-to-date VMs at http://www.mirandabanda.org/files/Cog/VM/ and instructions on building your own VM at http://www.mirandabanda.org/cogblog/compiling-the-vm/
-- -- Yoshiki
Hi Yoshiki,
On May 5, 2016, at 1:02 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Thu, May 5, 2016 at 11:11 AM, tim Rowledge tim@rowledge.org wrote:
On 05-05-2016, at 10:36 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
It actually is not clear yet which branches are the right one for current Scratch on raspi and also future proof. Perhaps doing for multiple branches is necessary? (What are the relationship of those?)
Oh, it’s absolutely clear for the Pi; Cog/Spur. The ancient original MIT image and an elderly interpreter are kept around for emergency use but will not be updated.
Okay!
By any chance, can you tell me how you test things? for Raspberry Pi?
A Pi is cheap enough that one can simply buy one. The new 64-bit one runs 32-bit binaries and is significantly faster than a pi2. As far as testing, one can either connect a display via hdmi and a mouse & keyboard via usb, or use VNC. There's a guide to setup of raspbian and of the VNC server on raspberrypi.org.
HTH
-- -- Yoshiki
_,,,^..^,,,_ (phone)
On Thu, May 5, 2016 at 2:06 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On May 5, 2016, at 1:02 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Thu, May 5, 2016 at 11:11 AM, tim Rowledge tim@rowledge.org wrote:
On 05-05-2016, at 10:36 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
It actually is not clear yet which branches are the right one for current Scratch on raspi and also future proof. Perhaps doing for multiple branches is necessary? (What are the relationship of those?)
Oh, it’s absolutely clear for the Pi; Cog/Spur. The ancient original MIT image and an elderly interpreter are kept around for emergency use but will not be updated.
Okay!
By any chance, can you tell me how you test things? for Raspberry Pi?
A Pi is cheap enough that one can simply buy one. The new 64-bit one runs 32-bit binaries and is significantly faster than a pi2. As far as testing, one can either connect a display via hdmi and a mouse & keyboard via usb, or use VNC. There's a guide to setup of raspbian and of the VNC server on raspberrypi.org.
Sorry for posing a vague question... I do have a couple of Pis (Pi and Pi2, but not Pi3), and have done some graphics stuff in C over SSH. So I invoke my program from a shell running emacs on an SSH session and things appear on a display connected to a Pi. But I have not tried VNC there. I haven't done any real Squeak stuff on Pi and for Pi; if running Squeak on Pi and interacting with it over VNC is reasonably fast, I'd go with that path. But this one involves some C programs and if people does some cross compiling more on a host computer, that is also an interesting option.
Hi Yoshiki,
On May 5, 2016, at 2:34 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Thu, May 5, 2016 at 2:06 PM, Eliot Miranda eliot.miranda@gmail.com wrote: Hi Yoshiki,
On May 5, 2016, at 1:02 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Thu, May 5, 2016 at 11:11 AM, tim Rowledge tim@rowledge.org wrote:
On 05-05-2016, at 10:36 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
It actually is not clear yet which branches are the right one for current Scratch on raspi and also future proof. Perhaps doing for multiple branches is necessary? (What are the relationship of those?)
Oh, it’s absolutely clear for the Pi; Cog/Spur. The ancient original MIT image and an elderly interpreter are kept around for emergency use but will not be updated.
Okay!
By any chance, can you tell me how you test things? for Raspberry Pi?
A Pi is cheap enough that one can simply buy one. The new 64-bit one runs 32-bit binaries and is significantly faster than a pi2. As far as testing, one can either connect a display via hdmi and a mouse & keyboard via usb, or use VNC. There's a guide to setup of raspbian and of the VNC server on raspberrypi.org.
Sorry for posing a vague question... I do have a couple of Pis (Pi and Pi2, but not Pi3), and have done some graphics stuff in C over SSH. So I invoke my program from a shell running emacs on an SSH session and things appear on a display connected to a Pi. But I have not tried VNC there. I haven't done any real Squeak stuff on Pi and for Pi; if running Squeak on Pi and interacting with it over VNC is reasonably fast, I'd go with that path. But this one involves some C programs and if people does some cross compiling more on a host computer, that is also an interesting option.
VNC feels pretty fast. IIRC there was some issue about running X11 apps directly. I'm not sure I could find a package. Anyway, Tim and u have been using VNC and it feels fine.
-- -- Yoshiki
A classic problem we have is that people devise UI stuff and other widgetry on a fast computer. Because, of course they do, why not? The issue is then using that stuff on more mundane machines - or even embedded devices. Whereupon we discover to our horror that not having a 750THz intel 256bit gigacore with 42Pb of RAM means that our nice clever button takes 45 years to handle a mouse click.
So to combat this, it really would be smart for everyone doing development to at least occasionally run on a less frenetic machine such as a Pi. A Pi (especially a 3) is fast enough to be pretty nice for running current Squeak, even with Shout operational. But it is slow enough to show up places where your algorithm really isn’t doing a good job, or where your UI doohickey is really spending a terrible number of cycles to animate that cute little effect.
For extra effect, run on a non-cog vm too. That might be too much masochism for everyday development but it will *really* show you were performance is being wasted.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CPM: Change Programmer's Mind
On 05-05-2016, at 2:34 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Sorry for posing a vague question... I do have a couple of Pis (Pi and Pi2, but not Pi3), and have done some graphics stuff in C over SSH. So I invoke my program from a shell running emacs on an SSH session and things appear on a display connected to a Pi. But I have not tried VNC there. I haven't done any real Squeak stuff on Pi and for Pi; if running Squeak on Pi and interacting with it over VNC is reasonably fast, I'd go with that path. But this one involves some C programs and if people does some cross compiling more on a host computer, that is also an interesting option.
Ah, I see.
When the first Pi came out and I started on improving Scratch, things were sufficiently slow in Scratch that I did much of my work on my iMac and just test-ran the system on the Pi. Compiling the VM etc has always been on the Pi, since a) it’s fast enough to be no problem even on a Pi B b) I’m not about to start messing around setting up a cross-compiling system. Gcc is enough of a nuisance as it is without that extra layer of madness.
The first improvements to Scratch were to make its image run on a more recent VM, which didn’t take a lot and on the circa 2012 interpreter it was ok to do some Squeak work on the Pi. Morphic was still a bit painful in a development image. That combination sufficed to get Scratch running around 4-8X faster as measured by an assortment of example projects; it wasn’t difficult to find and fix a rather large collection of poor code.
After that I moved all the source to a modern image (4.4? 4.5?) and rewrote almost everything to use layout properly, events, etc etc. That meant we could jump to a stack vm as well - and then the Pi 2 arrived. A Pi 2 running Squeak 4.5 on a stack vm is a decent development machine and by that stage I was doing all my work on the Pi. Then Eliot & I got the Cog vm working as well, and Squeak 5/Cog/spur on a Pi 2 is pretty damn fast.
I got my first Pi 3 last august, just as we got Cog going, which is why the PICs had to be rewritten - it turned out the the first version had a curious bug that didn’t cause a fatal error on a ‘real’ ARM v7 but does on an ARM v8 running v7 emulation. A production Pi 3 with cog/spur/5 benchmarks at around 100 dorado, 10% or so of my i7 3GHz iMac (using the shootout bmarks) and 280m bc/sec & 12m sends/s. Running my latest Scratch version you can run power hungry projects like PacMan around twice as fast as the original Scratch on my 2011 era macbook, which I suspect is around twice as fast as one fro m’07 when Scratch was initially released.
So, don’t waste time on cross-compiling or treating a Pi as some sort of arduino/toy; it’s a real computer. I see that kind of assumption everywhere; people asking what IDE to use to make programs for a Pi and how to download it and make it run. Argh! It’s a quad-core 1.2GHz unix supercomputer!
I recommend installing sudo apt-get install netatalk libnss-mdns xrdp i2c-tools then for dev work sudo apt-get install libX11-dev uuid-dev libcairo2-dev libpango1.0-dev autoconf libasound2-dev libssl-dev then save some space sudo apt-get remove wolfram-engine
set up nfs On Pi- `sudo aptitude install nfs-common portmap` (in jessie, no need to install) On the current version of Raspbian, rpcbind (part of the portmap package) does not start by default. . To enable it manually, so we can mount our directory immediately: sudo service rpcbind start sudo update-rc.d rpcbind enable mkdir /home/pi/DizietFS <- obviously change to suit sudo mount -t nfs 192.168.1.65:/Users/tim /home/pi/DizietFS <- obviously, your ip & path
Now, to make it permanent, you need to edit /etc/fstab to make the directory mount at boot. I added a line to the end of /etc/fstab:
`192.168.1.65:/Users/tim /home/pi/DizietFS nfs rsize=8192,wsize=8192,timeo=14,intr,noauto,x-systemd.automount 0 0`
On iMac- in a terminal `sudo nano /etc/exports` (which won’t normally exist until you save it) and add the line `/Users/tim -mapall=tim -alldirs -network 192.168.1.0 -mask 255.255.255.0` `sudo nfsd restart` should restart the daemon.
After all that, reboot the Pi and DizietFS ought to be visible and accessible.
On windows - no idea. Don’t do windows.
Make the LXDE GUI less irritating
edit .xsessionrc (creating if required) add xsetroot -cursor_name left_ptr&
chmod a+x .xsessionrc reboot to get proper cursor in X instead of a big ugly X
Use an rdp client on your mac/windows machine - I use the msoft one on my iMac and it’s fine. If you expect to use xrdp most of the time, use raspi-config to set the Pi to boot to command line rather than desktop.
Pi 3 has wifi & bt built in. Sound output is via a typically lousy ( and lossy) headphone socket or the hdmi, or add a nice HAT. Sound input is only via usb sound dongle or HAT.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Never do card tricks for the group you play poker with.
Great. Thanks.
I'll give it a try... I might not do NFS but seems good. So the VM would be the one I would produce by checking out the svn repository on squeakvm.org, go to the branches/Cog directory and compile? Is there a dev image you use?
On Thu, May 5, 2016 at 3:33 PM, tim Rowledge tim@rowledge.org wrote:
On 05-05-2016, at 2:34 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Sorry for posing a vague question... I do have a couple of Pis (Pi and Pi2, but not Pi3), and have done some graphics stuff in C over SSH. So I invoke my program from a shell running emacs on an SSH session and things appear on a display connected to a Pi. But I have not tried VNC there. I haven't done any real Squeak stuff on Pi and for Pi; if running Squeak on Pi and interacting with it over VNC is reasonably fast, I'd go with that path. But this one involves some C programs and if people does some cross compiling more on a host computer, that is also an interesting option.
Ah, I see.
When the first Pi came out and I started on improving Scratch, things were sufficiently slow in Scratch that I did much of my work on my iMac and just test-ran the system on the Pi. Compiling the VM etc has always been on the Pi, since a) it’s fast enough to be no problem even on a Pi B b) I’m not about to start messing around setting up a cross-compiling system. Gcc is enough of a nuisance as it is without that extra layer of madness.
The first improvements to Scratch were to make its image run on a more recent VM, which didn’t take a lot and on the circa 2012 interpreter it was ok to do some Squeak work on the Pi. Morphic was still a bit painful in a development image. That combination sufficed to get Scratch running around 4-8X faster as measured by an assortment of example projects; it wasn’t difficult to find and fix a rather large collection of poor code.
After that I moved all the source to a modern image (4.4? 4.5?) and rewrote almost everything to use layout properly, events, etc etc. That meant we could jump to a stack vm as well - and then the Pi 2 arrived. A Pi 2 running Squeak 4.5 on a stack vm is a decent development machine and by that stage I was doing all my work on the Pi. Then Eliot & I got the Cog vm working as well, and Squeak 5/Cog/spur on a Pi 2 is pretty damn fast.
I got my first Pi 3 last august, just as we got Cog going, which is why the PICs had to be rewritten - it turned out the the first version had a curious bug that didn’t cause a fatal error on a ‘real’ ARM v7 but does on an ARM v8 running v7 emulation. A production Pi 3 with cog/spur/5 benchmarks at around 100 dorado, 10% or so of my i7 3GHz iMac (using the shootout bmarks) and 280m bc/sec & 12m sends/s. Running my latest Scratch version you can run power hungry projects like PacMan around twice as fast as the original Scratch on my 2011 era macbook, which I suspect is around twice as fast as one fro m’07 when Scratch was initially released.
So, don’t waste time on cross-compiling or treating a Pi as some sort of arduino/toy; it’s a real computer. I see that kind of assumption everywhere; people asking what IDE to use to make programs for a Pi and how to download it and make it run. Argh! It’s a quad-core 1.2GHz unix supercomputer!
I recommend installing sudo apt-get install netatalk libnss-mdns xrdp i2c-tools then for dev work sudo apt-get install libX11-dev uuid-dev libcairo2-dev libpango1.0-dev autoconf libasound2-dev libssl-dev then save some space sudo apt-get remove wolfram-engine
set up nfs On Pi- `sudo aptitude install nfs-common portmap` (in jessie, no need to install) On the current version of Raspbian, rpcbind (part of the portmap package) does not start by default. . To enable it manually, so we can mount our directory immediately: sudo service rpcbind start sudo update-rc.d rpcbind enable mkdir /home/pi/DizietFS <- obviously change to suit sudo mount -t nfs 192.168.1.65:/Users/tim /home/pi/DizietFS <- obviously, your ip & path
Now, to make it permanent, you need to edit /etc/fstab to make the directory mount at boot. I added a line to the end of /etc/fstab:
`192.168.1.65:/Users/tim /home/pi/DizietFS nfs rsize=8192,wsize=8192,timeo=14,intr,noauto,x-systemd.automount 0 0`
On iMac- in a terminal `sudo nano /etc/exports` (which won’t normally exist until you save it) and add the line `/Users/tim -mapall=tim -alldirs -network 192.168.1.0 -mask 255.255.255.0` `sudo nfsd restart` should restart the daemon.
After all that, reboot the Pi and DizietFS ought to be visible and accessible.
On windows - no idea. Don’t do windows.
Make the LXDE GUI less irritating
edit .xsessionrc (creating if required) add xsetroot -cursor_name left_ptr&
chmod a+x .xsessionrc reboot to get proper cursor in X instead of a big ugly X
Use an rdp client on your mac/windows machine - I use the msoft one on my iMac and it’s fine. If you expect to use xrdp most of the time, use raspi-config to set the Pi to boot to command line rather than desktop.
Pi 3 has wifi & bt built in. Sound output is via a typically lousy ( and lossy) headphone socket or the hdmi, or add a nice HAT. Sound input is only via usb sound dongle or HAT.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Never do card tricks for the group you play poker with.
On Thu, May 05, 2016 at 04:01:29PM -0700, Yoshiki Ohshima wrote:
Great. Thanks.
I'll give it a try... I might not do NFS but seems good. So the VM would be the one I would produce by checking out the svn repository on squeakvm.org, go to the branches/Cog directory and compile? Is there a dev image you use?
To check out the entire repository for Cog/Spur:
$ svn co http://squeakvm.org/svn/squeak/branches/Cog
There is an ./images directory that contains development images, and a README to explain. There are also ./build.* directories for building various configurations.
Dave
On Thu, May 5, 2016 at 4:34 PM, David T. Lewis lewis@mail.msen.com wrote:
There is an ./images directory that contains development images, and a README to explain. There are also ./build.* directories for building various configurations.
Thanks!
First, I can run Squeak-5.0-All-in-One.zip. on Pi.
I managed to compile squeak.cog.spur VM on ARM (raspberry pi). However, when I tried to open the image in the All in One, it creates a window but inside of it is just blank and does not do any interaction. I downloaded http://www.mirandabanda.org/files/Cog/VM/VM.r3692/cogspurlinuxhtARM-16.18.36... and tried it, but it has the same problem.
I looked into the chain of shell scripts and tried a command line like:
env LD_LIBRARY_PATH=/home/pi/tmp/cogspurlinuxhtARM/lib/squeak/5.0-3692:/lib/arm-linux-gnueabihf:/lib:/usr/lib/arm-linux-gnueabihf:/usr/lib /home/pi/tmp/cogspurlinuxhtARM/lib/squeak/5.0-3692/squeak ~/Squeak5.0-15113.image
but no avail.
Does anybody know why the all in one vm and image works but the VM I downloaded from Eliot's site (nor the one I compiled)?
Hi Yoshiki,
it's probably just the absence of a sources file. I don't include it in the VMs on my site to save space. Simply link the sources into the lib dir in the directory tree, or include the sources in the directory containing the image.
On Fri, May 6, 2016 at 3:53 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Thu, May 5, 2016 at 4:34 PM, David T. Lewis lewis@mail.msen.com wrote:
There is an ./images directory that contains development images, and a README to explain. There are also ./build.* directories for building various configurations.
Thanks!
First, I can run Squeak-5.0-All-in-One.zip. on Pi.
I managed to compile squeak.cog.spur VM on ARM (raspberry pi). However, when I tried to open the image in the All in One, it creates a window but inside of it is just blank and does not do any interaction. I downloaded
http://www.mirandabanda.org/files/Cog/VM/VM.r3692/cogspurlinuxhtARM-16.18.36... and tried it, but it has the same problem.
I looked into the chain of shell scripts and tried a command line like:
env LD_LIBRARY_PATH=/home/pi/tmp/cogspurlinuxhtARM/lib/squeak/5.0-3692:/lib/arm-linux-gnueabihf:/lib:/usr/lib/arm-linux-gnueabihf:/usr/lib /home/pi/tmp/cogspurlinuxhtARM/lib/squeak/5.0-3692/squeak ~/Squeak5.0-15113.image
but no avail.
Does anybody know why the all in one vm and image works but the VM I downloaded from Eliot's site (nor the one I compiled)?
-- -- Yoshiki
On Fri, May 6, 2016 at 4:21 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
it's probably just the absence of a sources file. I don't include itin the VMs on my site to save space. Simply link the sources into the lib dir in the directory tree, or include the sources in the directory containing the image.
Oops, it needs to go I'm the same directory as the VM, so e.g. add cogspurlinux/lib/squeak/4.5-3692/ ]SqueakV50.sources
On Fri, May 6, 2016 at 3:53 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Thu, May 5, 2016 at 4:34 PM, David T. Lewis lewis@mail.msen.com wrote:
There is an ./images directory that contains development images, and a README to explain. There are also ./build.* directories for building various configurations.
Thanks!
First, I can run Squeak-5.0-All-in-One.zip. on Pi.
I managed to compile squeak.cog.spur VM on ARM (raspberry pi). However, when I tried to open the image in the All in One, it creates a window but inside of it is just blank and does not do any interaction. I downloaded
http://www.mirandabanda.org/files/Cog/VM/VM.r3692/cogspurlinuxhtARM-16.18.36... and tried it, but it has the same problem.
I looked into the chain of shell scripts and tried a command line like:
env LD_LIBRARY_PATH=/home/pi/tmp/cogspurlinuxhtARM/lib/squeak/5.0-3692:/lib/arm-linux-gnueabihf:/lib:/usr/lib/arm-linux-gnueabihf:/usr/lib /home/pi/tmp/cogspurlinuxhtARM/lib/squeak/5.0-3692/squeak ~/Squeak5.0-15113.image
but no avail.
Does anybody know why the all in one vm and image works but the VM I downloaded from Eliot's site (nor the one I compiled)?
-- -- Yoshiki
-- _,,,^..^,,,_ best, Eliot
On 06-05-2016, at 4:27 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
it's probably just the absence of a sources file. I don't include it in the VMs on my site to save space. Simply link the sources into the lib dir in the directory tree, or include the sources in the directory containing the image.Oops, it needs to go I'm the same directory as the VM, so e.g. add cogspurlinux/lib/squeak/4.5-3692/ ]SqueakV50.sources
Not on any of my Pi’s it doesn’t; I normally run with the sources in the same directory as the image while developing - and of course , a deployed Scratch image doesn’t need them at all. I’m fairly sure the sources ought to be able to live in the local dir, the image dir, the vm dir and obviously somewhere there will be a place to specify any other location you like.
Another possibility is Yoshiki has an old version of Raspbian; old kernel from early last year (?) wouldn’t let us futz wit the timer thread priority without pain. It’s been a while since that was fixed but if you have an old Raspbian… except that ought to prevent the all-in-one system running. But this is unix, which is carefully designed to drive one to the edge of madness, so maybe you just had the wrong kind of egg for your breakfast last time there was a blue moon.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Asking whether machines can think is like asking whether submarines can swim.
On Fri, May 6, 2016 at 5:58 PM, tim Rowledge tim@rowledge.org wrote:
Another possibility is Yoshiki has an old version of Raspbian; old kernel from early last year (?) wouldn’t let us futz wit the timer thread priority without pain. It’s been a while since that was fixed but if you have an old Raspbian… except that ought to prevent the all-in-one system running. But this is unix, which is carefully designed to drive one to the edge of madness, so maybe you just had the wrong kind of egg for your breakfast last time there was a blue moon.
That sounds plausible. I did "apt-get update" to get some packages loadable but did not go on to update the entire system. I'll try that.
The VM still does not display anything in the white window after I did apt-get dist-upgrade, and copy the .sources file to the same directly. (But I did not have an egg this morning). I'll try some display options. But also, it appears that the source code for the Cog seems to have the part I wrote for the composition input. The goal may be nearer than I originally thought.
On Fri, May 6, 2016 at 6:23 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Fri, May 6, 2016 at 5:58 PM, tim Rowledge tim@rowledge.org wrote:
Another possibility is Yoshiki has an old version of Raspbian; old kernel from early last year (?) wouldn’t let us futz wit the timer thread priority without pain. It’s been a while since that was fixed but if you have an old Raspbian… except that ought to prevent the all-in-one system running. But this is unix, which is carefully designed to drive one to the edge of madness, so maybe you just had the wrong kind of egg for your breakfast last time there was a blue moon.
That sounds plausible. I did "apt-get update" to get some packages loadable but did not go on to update the entire system. I'll try that.
-- -- Yoshiki
On 09-05-2016, at 10:35 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
The VM still does not display anything in the white window after I did apt-get dist-upgrade, and copy the .sources file to the same directly. (But I did not have an egg this morning). I'll try some display options. But also, it appears that the source code for the Cog seems to have the part I wrote for the composition input. The goal may be nearer than I originally thought.
That’s really disturbing. I mean, no egg for breakfast?
No, seriously, there’s no way you ought to be getting strange display problems. So far I’ve never had them on dozens of Pi’s over dozens of release mixes of Raspbian and VM and image. And even many actual displays both real and virtual.
My suggestion for any serious Raspbian update is do fresh load fro mPi central. I’ve read many people’s problem with inconsistent results of dist-upgrade and update and mixed up apt-gets and so on. Quicker to download/burn/reboot.
Aaand…. of course; built the new vm with hostwindowplugin included to respond to Levente and what do I get? blank white screen. Sigh.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim USER ERROR: replace user and press any key to continue.
On Mon, May 9, 2016 at 10:43 AM, tim Rowledge tim@rowledge.org wrote:
On 09-05-2016, at 10:35 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
The VM still does not display anything in the white window after I did apt-get dist-upgrade, and copy the .sources file to the same directly. (But I did not have an egg this morning). I'll try some display options. But also, it appears that the source code for the Cog seems to have the part I wrote for the composition input. The goal may be nearer than I originally thought.
Aaand…. of course; built the new vm with hostwindowplugin included to respond to Levente and what do I get? blank white screen. Sigh.
Oh, so you do get blank white screen? So, I guess I'd checkout an older revision of the svn repo just for now. What would a good revision to go back to?
On 09-05-2016, at 10:47 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote: Oh, so you do get blank white screen? So, I guess I'd checkout an older revision of the svn repo just for now. What would a good revision to go back to?
The last one I have built for Pi and running ok is 3663 and it just went bad in 3692. So I guess we start binary dividing...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "How many Motie Mediators does it take to chage a lightbulb?” "Are you insane? Only Crazy Eddie would want to change *anything*!"
An svn diff -r 3663:3692 in platforms/unix shows only some (to me) innocuous changes in vm/aio.c
More unixy expertise required to say if that has anything to do with it.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: BA: Branch Approximate
On 09-05-2016, at 11:05 AM, tim Rowledge tim@rowledge.org wrote:
An svn diff -r 3663:3692 in platforms/unix shows only some (to me) innocuous changes in vm/aio.c
More unixy expertise required to say if that has anything to do with it.
Building with the older version makes no difference for me. Let’s try an older tree.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim 42.7 percent of all statistics are made up on the spot.
On 09-05-2016, at 11:16 AM, tim Rowledge tim@rowledge.org wrote:
On 09-05-2016, at 11:05 AM, tim Rowledge tim@rowledge.org wrote:
An svn diff -r 3663:3692 in platforms/unix shows only some (to me) innocuous changes in vm/aio.c
More unixy expertise required to say if that has anything to do with it.
Building with the older version makes no difference for me. Let’s try an older tree.
3680 fails, let’s try 3670
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Death to all fanatics!
On 09-05-2016, at 11:24 AM, tim Rowledge tim@rowledge.org wrote:
On 09-05-2016, at 11:16 AM, tim Rowledge tim@rowledge.org wrote:
On 09-05-2016, at 11:05 AM, tim Rowledge tim@rowledge.org wrote:
An svn diff -r 3663:3692 in platforms/unix shows only some (to me) innocuous changes in vm/aio.c
More unixy expertise required to say if that has anything to do with it.
Building with the older version makes no difference for me. Let’s try an older tree.
3680 fails, let’s try 3670
Per the X11 input thread for those not paying attention to everything, 3671 is the last one I can get a display displaying on a Pi.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Klingon Code Warrior:- 6) "Our competitors are without honor!"
I confirm that r3663 does work on my Pi2 for Squeak5.0-15113.image. I'll try to make some progress from there for now.
On Mon, May 9, 2016 at 10:54 AM, tim Rowledge tim@rowledge.org wrote:
On 09-05-2016, at 10:47 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote: Oh, so you do get blank white screen? So, I guess I'd checkout an older revision of the svn repo just for now. What would a good revision to go back to?
The last one I have built for Pi and running ok is 3663 and it just went bad in 3692. So I guess we start binary dividing...
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "How many Motie Mediators does it take to chage a lightbulb?” "Are you insane? Only Crazy Eddie would want to change *anything*!"
On 09-05-2016, at 11:37 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
I confirm that r3663 does work on my Pi2 for Squeak5.0-15113.image. I'll try to make some progress from there for now.
3680 fails, 3670 work; 3675 fail; 3673 won’t build
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim When all else fails, let a = 7. If that doesn't help, then read the manual.
On 09-05-2016, at 11:40 AM, tim Rowledge tim@rowledge.org wrote:
On 09-05-2016, at 11:37 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
I confirm that r3663 does work on my Pi2 for Squeak5.0-15113.image. I'll try to make some progress from there for now.
3680 fails, 3670 work; 3675 fail; 3673 won’t build
3672 fails. At this rate my Pi will wear out its SD card by the end of the day…
3671 works.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A conclusion is the place where you got tired of thinking.
The pi3 has 1 gb of memory, it'd have to be a small disk. Never tried it.
On May 9, 2016, at 21:34, Stephan Eggermont stephan@stack.nl wrote:
On 09-05-16 20:52, tim Rowledge wrote: At this rate my Pi will wear out its SD card by the end of the day…
Does a Pi3 have enough memory to build on a ram disk?
Stephan
On Mon, May 9, 2016 at 10:35 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
The VM still does not display anything in the white window after I did apt-get dist-upgrade, and copy the .sources file to the same directly. (But I did not have an egg this morning). I'll try some display options. But also, it appears that the source code for the Cog seems to have the part I wrote for the composition input. The goal may be nearer than I originally thought.
It may not as closer than I thought, however. The world evolved to use ibus; we'd need to add some more stuff, such as DBus... I'll report more tomorrow.
On 10.05.2016, at 02:23, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Mon, May 9, 2016 at 10:35 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
The VM still does not display anything in the white window after I did apt-get dist-upgrade, and copy the .sources file to the same directly. (But I did not have an egg this morning). I'll try some display options. But also, it appears that the source code for the Cog seems to have the part I wrote for the composition input. The goal may be nearer than I originally thought.
It may not as closer than I thought, however. The world evolved to use ibus; we'd need to add some more stuff, such as DBus... I'll report more tomorrow.
Doesn’t ibus generate “old” X events, too? The README suggests this should work:
XMODIFIERS="@im=ibus" squeak
... which we could put in the startup script.
- Bert -
On Tue, May 10, 2016 at 7:37 AM, Bert Freudenberg bert@freudenbergs.de wrote:
On 10.05.2016, at 02:23, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Mon, May 9, 2016 at 10:35 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
The VM still does not display anything in the white window after I did apt-get dist-upgrade, and copy the .sources file to the same directly. (But I did not have an egg this morning). I'll try some display options. But also, it appears that the source code for the Cog seems to have the part I wrote for the composition input. The goal may be nearer than I originally thought.
It may not as closer than I thought, however. The world evolved to use ibus; we'd need to add some more stuff, such as DBus... I'll report more tomorrow.
Doesn’t ibus generate “old” X events, too? The README suggests this should work:
XMODIFIERS="@im=ibus" squeak... which we could put in the startup script.
This does not quite work. And also Abe-san says that I'd better make it work with scim first so I am taking that path now.
BTW, I have a long standing question of the development process. I create a VM by doing ./mvm, which creates display drivers and VM in one way or another, and installs them to products directory somewhere upthere. I have trouble seeing my changes to code gets reflected sometimes. (Say, I change a printf message somehwere in sqUnixX11.c, run mvm and invoke the squeak shell script in products/cogspurlinuxhtARM/ but it seems to pick up a different binary from somewhere else.
What do people do to make the debug cycle go faster on Linux?
Hi Yoshiki,
On May 11, 2016, at 11:52 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Tue, May 10, 2016 at 7:37 AM, Bert Freudenberg bert@freudenbergs.de wrote:
On 10.05.2016, at 02:23, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Mon, May 9, 2016 at 10:35 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
The VM still does not display anything in the white window after I did apt-get dist-upgrade, and copy the .sources file to the same directly. (But I did not have an egg this morning). I'll try some display options. But also, it appears that the source code for the Cog seems to have the part I wrote for the composition input. The goal may be nearer than I originally thought.
It may not as closer than I thought, however. The world evolved to use ibus; we'd need to add some more stuff, such as DBus... I'll report more tomorrow.
Doesn’t ibus generate “old” X events, too? The README suggests this should work:
XMODIFIERS="@im=ibus" squeak... which we could put in the startup script.
This does not quite work. And also Abe-san says that I'd better make it work with scim first so I am taking that path now.
BTW, I have a long standing question of the development process. I create a VM by doing ./mvm, which creates display drivers and VM in one way or another, and installs them to products directory somewhere upthere. I have trouble seeing my changes to code gets reflected sometimes. (Say, I change a printf message somehwere in sqUnixX11.c, run mvm and invoke the squeak shell script in products/cogspurlinuxhtARM/ but it seems to pick up a different binary from somewhere else.
It shouldn't. That's where the resulting binary gets installed (or a debug build in products/debug/cogspurlinuxhtARM etc).
What do people do to make the debug cycle go faster on Linux?
That's what I've been using, and I find it unsatisfactory too. I don't like the automake system and want to replace the whole thing with Gnu make makefiles (as is used in the win32 and MacOS builds) which would result in more sharing between the production, assert and debug builds plus accurate dependency information for reliable compilation, and the possibility of making a valid cogspurlinuxhtARM directory tree in the build directory and hence (again as I do in the win32 and MacOS builds) running the executable in the build directory instead of from products.
-- Yoshiki
_,,,^..^,,,_ (phone)
Hi Yoshiki,
On May 11, 2016, at 1:20 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On May 11, 2016, at 11:52 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Tue, May 10, 2016 at 7:37 AM, Bert Freudenberg bert@freudenbergs.de wrote: On 10.05.2016, at 02:23, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Mon, May 9, 2016 at 10:35 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
The VM still does not display anything in the white window after I did apt-get dist-upgrade, and copy the .sources file to the same directly. (But I did not have an egg this morning). I'll try some display options. But also, it appears that the source code for the Cog seems to have the part I wrote for the composition input. The goal may be nearer than I originally thought.
It may not as closer than I thought, however. The world evolved to use ibus; we'd need to add some more stuff, such as DBus... I'll report more tomorrow.
Doesn’t ibus generate “old” X events, too? The README suggests this should work:
XMODIFIERS="@im=ibus" squeak... which we could put in the startup script.
This does not quite work. And also Abe-san says that I'd better make it work with scim first so I am taking that path now.
BTW, I have a long standing question of the development process. I create a VM by doing ./mvm, which creates display drivers and VM in one way or another, and installs them to products directory somewhere upthere. I have trouble seeing my changes to code gets reflected sometimes. (Say, I change a printf message somehwere in sqUnixX11.c, run mvm and invoke the squeak shell script in products/cogspurlinuxhtARM/ but it seems to pick up a different binary from somewhere else.
It shouldn't. That's where the resulting binary gets installed (or a debug build in products/debug/cogspurlinuxhtARM etc).
What do people do to make the debug cycle go faster on Linux?
That's what I've been using, and I find it unsatisfactory too. I don't like the automake system and want to replace the whole thing with Gnu make makefiles (as is used in the win32 and MacOS builds) which would result in more sharing between the production, assert and debug builds plus accurate dependency information for reliable compilation, and the possibility of making a valid cogspurlinuxhtARM directory tree in the build directory and hence (again as I do in the win32 and MacOS builds) running the executable in the build directory instead of from products.
And I forgot to say that indeed sqUnixX11.c is one of the files that suffers from inaccurate dependency info because it includes sqUnixEvent.c and sqUnixXdnd.c but the dependency isn't reflected in the makefiles :-(
-- Yoshiki
_,,,^..^,,,_ (phone)
I am slowly working my way up. Most of the problems was about getting the right environment variables for right processes, including the X Server and Squeak. I now get vanilla UTF32 values for characters I type into the scim preedit window on Squeak.
The big question now is on the image side. We used to have StrikeFontSet as the default font and it was tad easier to just load language specific fonts into the image.
At the same time, the clients' need here for me this time around (i.e., make Squeak on raspi support Japanese input, I'd side step all regular Squeak stuff and minimum changes. I am inclined to take this path now.
Tim, is there a repo of the NuScratch that is used in the NuScratch image?
On Wed, May 11, 2016 at 1:24 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On May 11, 2016, at 1:20 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On May 11, 2016, at 11:52 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Tue, May 10, 2016 at 7:37 AM, Bert Freudenberg bert@freudenbergs.de wrote: On 10.05.2016, at 02:23, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Mon, May 9, 2016 at 10:35 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
The VM still does not display anything in the white window after I did apt-get dist-upgrade, and copy the .sources file to the same directly. (But I did not have an egg this morning). I'll try some display options. But also, it appears that the source code for the Cog seems to have the part I wrote for the composition input. The goal may be nearer than I originally thought.
It may not as closer than I thought, however. The world evolved to use ibus; we'd need to add some more stuff, such as DBus... I'll report more tomorrow.
Doesn’t ibus generate “old” X events, too? The README suggests this should work:
XMODIFIERS="@im=ibus" squeak... which we could put in the startup script.
This does not quite work. And also Abe-san says that I'd better make it work with scim first so I am taking that path now.
BTW, I have a long standing question of the development process. I create a VM by doing ./mvm, which creates display drivers and VM in one way or another, and installs them to products directory somewhere upthere. I have trouble seeing my changes to code gets reflected sometimes. (Say, I change a printf message somehwere in sqUnixX11.c, run mvm and invoke the squeak shell script in products/cogspurlinuxhtARM/ but it seems to pick up a different binary from somewhere else.
It shouldn't. That's where the resulting binary gets installed (or a debug build in products/debug/cogspurlinuxhtARM etc).
What do people do to make the debug cycle go faster on Linux?
That's what I've been using, and I find it unsatisfactory too. I don't like the automake system and want to replace the whole thing with Gnu make makefiles (as is used in the win32 and MacOS builds) which would result in more sharing between the production, assert and debug builds plus accurate dependency information for reliable compilation, and the possibility of making a valid cogspurlinuxhtARM directory tree in the build directory and hence (again as I do in the win32 and MacOS builds) running the executable in the build directory instead of from products.
And I forgot to say that indeed sqUnixX11.c is one of the files that suffers from inaccurate dependency info because it includes sqUnixEvent.c and sqUnixXdnd.c but the dependency isn't reflected in the makefiles :-(
-- Yoshiki
_,,,^..^,,,_ (phone)
Iit appears that most bits and pieces are there. For example, sqUnixX11.c does have two functions setCompositionFocus() and setCompositionWIndowPosition(), which used to be in a separated loadable VM plugin but now sitting in there without any caller (if I'm not mistaken). And the NuSqueak image has calls to Hand>>compositionWindowManager, and miraculously, returns an instance of ImmX11.
In ImmX11, setCompositionWindowPositionX:y: has a primitive call into ImmX11Plugin; but it appears that all I have to do is to change it to call the above-mentioned function in sqUnixX11.c.
To make it right, I'd propose to add two more functions to the display module interface. I see the implementation of those for X11 is there, and I remember writing something for Windows; but it can be an empty function.
So, if there is no opposition to add these to the display interface, I'd write a patch for it. But one thing I don't know much about is the HostWindowPlugin. If people think it makes sense to have them there for some reason, we can make that work, too.
On Fri, May 13, 2016 at 3:57 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
I am slowly working my way up. Most of the problems was about getting the right environment variables for right processes, including the X Server and Squeak. I now get vanilla UTF32 values for characters I type into the scim preedit window on Squeak.
The big question now is on the image side. We used to have StrikeFontSet as the default font and it was tad easier to just load language specific fonts into the image.
At the same time, the clients' need here for me this time around (i.e., make Squeak on raspi support Japanese input, I'd side step all regular Squeak stuff and minimum changes. I am inclined to take this path now.
Tim, is there a repo of the NuScratch that is used in the NuScratch image?
On Wed, May 11, 2016 at 1:24 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On May 11, 2016, at 1:20 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On May 11, 2016, at 11:52 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Tue, May 10, 2016 at 7:37 AM, Bert Freudenberg bert@freudenbergs.de wrote: On 10.05.2016, at 02:23, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Mon, May 9, 2016 at 10:35 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote: > The VM still does not display anything in the white window after I did > apt-get dist-upgrade, and copy the .sources file to the same directly. > (But I did not have an egg this morning). I'll try some display > options. But also, it appears that the source code for the Cog seems > to have the part I wrote for the composition input. The goal may be > nearer than I originally thought.
It may not as closer than I thought, however. The world evolved to use ibus; we'd need to add some more stuff, such as DBus... I'll report more tomorrow.
Doesn’t ibus generate “old” X events, too? The README suggests this should work:
XMODIFIERS="@im=ibus" squeak... which we could put in the startup script.
This does not quite work. And also Abe-san says that I'd better make it work with scim first so I am taking that path now.
BTW, I have a long standing question of the development process. I create a VM by doing ./mvm, which creates display drivers and VM in one way or another, and installs them to products directory somewhere upthere. I have trouble seeing my changes to code gets reflected sometimes. (Say, I change a printf message somehwere in sqUnixX11.c, run mvm and invoke the squeak shell script in products/cogspurlinuxhtARM/ but it seems to pick up a different binary from somewhere else.
It shouldn't. That's where the resulting binary gets installed (or a debug build in products/debug/cogspurlinuxhtARM etc).
What do people do to make the debug cycle go faster on Linux?
That's what I've been using, and I find it unsatisfactory too. I don't like the automake system and want to replace the whole thing with Gnu make makefiles (as is used in the win32 and MacOS builds) which would result in more sharing between the production, assert and debug builds plus accurate dependency information for reliable compilation, and the possibility of making a valid cogspurlinuxhtARM directory tree in the build directory and hence (again as I do in the win32 and MacOS builds) running the executable in the build directory instead of from products.
And I forgot to say that indeed sqUnixX11.c is one of the files that suffers from inaccurate dependency info because it includes sqUnixEvent.c and sqUnixXdnd.c but the dependency isn't reflected in the makefiles :-(
-- Yoshiki
_,,,^..^,,,_ (phone)
-- -- Yoshiki
On Fri, May 13, 2016 at 4:48 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Iit appears that most bits and pieces are there. For example, sqUnixX11.c does have two functions setCompositionFocus() and setCompositionWIndowPosition(), which used to be in a separated loadable VM plugin but now sitting in there without any caller (if I'm not mistaken). And the NuSqueak image has calls to Hand>>compositionWindowManager, and miraculously, returns an instance of ImmX11.
In ImmX11, setCompositionWindowPositionX:y: has a primitive call into ImmX11Plugin; but it appears that all I have to do is to change it to call the above-mentioned function in sqUnixX11.c.
To make it right, I'd propose to add two more functions to the display module interface. I see the implementation of those for X11 is there, and I remember writing something for Windows; but it can be an empty function.
So, if there is no opposition to add these to the display interface, I'd write a patch for it. But one thing I don't know much about is the HostWindowPlugin. If people think it makes sense to have them there for some reason, we can make that work, too.
This is in struct SqDisplay in platforms/unix/vm/SqDisplay.h? Go for it :-)
On Fri, May 13, 2016 at 3:57 PM, Yoshiki Ohshima
Yoshiki.Ohshima@acm.org wrote:
I am slowly working my way up. Most of the problems was about getting the right environment variables for right processes, including the X Server and Squeak. I now get vanilla UTF32 values for characters I type into the scim preedit window on Squeak.
The big question now is on the image side. We used to have StrikeFontSet as the default font and it was tad easier to just load language specific fonts into the image.
At the same time, the clients' need here for me this time around (i.e., make Squeak on raspi support Japanese input, I'd side step all regular Squeak stuff and minimum changes. I am inclined to take this path now.
Tim, is there a repo of the NuScratch that is used in the NuScratch
image?
On Wed, May 11, 2016 at 1:24 PM, Eliot Miranda eliot.miranda@gmail.com
wrote:
Hi Yoshiki,
On May 11, 2016, at 1:20 PM, Eliot Miranda eliot.miranda@gmail.com
wrote:
Hi Yoshiki,
On May 11, 2016, at 11:52 AM, Yoshiki Ohshima <
Yoshiki.Ohshima@acm.org> wrote:
> On Tue, May 10, 2016 at 7:37 AM, Bert Freudenberg <
bert@freudenbergs.de> wrote:
> On 10.05.2016, at 02:23, Yoshiki Ohshima Yoshiki.Ohshima@acm.org
wrote:
> > On Mon, May 9, 2016 at 10:35 AM, Yoshiki Ohshima > Yoshiki.Ohshima@acm.org wrote: >> The VM still does not display anything in the white window after I
did
>> apt-get dist-upgrade, and copy the .sources file to the same
directly.
>> (But I did not have an egg this morning). I'll try some display >> options. But also, it appears that the source code for the Cog
seems
>> to have the part I wrote for the composition input. The goal may
be
>> nearer than I originally thought. > > It may not as closer than I thought, however. The world evolved to > use ibus; we'd need to add some more stuff, such as DBus... I'll > report more tomorrow.
Doesn’t ibus generate “old” X events, too? The README suggests this
should work:
XMODIFIERS="@im=ibus" squeak... which we could put in the startup script.
This does not quite work. And also Abe-san says that I'd better make it work with scim first so I am taking that path now.
BTW, I have a long standing question of the development process. I create a VM by doing ./mvm, which creates display drivers and VM in one way or another, and installs them to products directory somewhere upthere. I have trouble seeing my changes to code gets reflected sometimes. (Say, I change a printf message somehwere in sqUnixX11.c, run mvm and invoke the squeak shell script in products/cogspurlinuxhtARM/ but it seems to pick up a different binary from somewhere else.
It shouldn't. That's where the resulting binary gets installed (or a
debug build in products/debug/cogspurlinuxhtARM etc).
What do people do to make the debug cycle go faster on Linux?
That's what I've been using, and I find it unsatisfactory too. I
don't like the automake system and want to replace the whole thing with Gnu make makefiles (as is used in the win32 and MacOS builds) which would result in more sharing between the production, assert and debug builds plus accurate dependency information for reliable compilation, and the possibility of making a valid cogspurlinuxhtARM directory tree in the build directory and hence (again as I do in the win32 and MacOS builds) running the executable in the build directory instead of from products.
And I forgot to say that indeed sqUnixX11.c is one of the files that
suffers from inaccurate dependency info because it includes sqUnixEvent.c and sqUnixXdnd.c but the dependency isn't reflected in the makefiles :-(
-- Yoshiki
_,,,^..^,,,_ (phone)
-- -- Yoshiki
-- -- Yoshiki
On Fri, May 13, 2016 at 5:22 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Fri, May 13, 2016 at 4:48 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Iit appears that most bits and pieces are there. For example, sqUnixX11.c does have two functions setCompositionFocus() and setCompositionWIndowPosition(), which used to be in a separated loadable VM plugin but now sitting in there without any caller (if I'm not mistaken). And the NuSqueak image has calls to Hand>>compositionWindowManager, and miraculously, returns an instance of ImmX11.
In ImmX11, setCompositionWindowPositionX:y: has a primitive call into ImmX11Plugin; but it appears that all I have to do is to change it to call the above-mentioned function in sqUnixX11.c.
To make it right, I'd propose to add two more functions to the display module interface. I see the implementation of those for X11 is there, and I remember writing something for Windows; but it can be an empty function.
So, if there is no opposition to add these to the display interface, I'd write a patch for it. But one thing I don't know much about is the HostWindowPlugin. If people think it makes sense to have them there for some reason, we can make that work, too.
This is in struct SqDisplay in platforms/unix/vm/SqDisplay.h? Go for it :-)
Yes, SqDisplay.h is what would be changed.
What I wrote above has some confusion, and I am indeed confused by this:
- the display vm plugin mechanism has primitives that are numbered as well as primitives that are in plugins like HostWindowPlugin. Is it possible to make then setCompositionFocus() and setCompositionWindowPosition() to be non-numbered yet make them be looked up from a plugin? Wasn't there a way to say to load a primitive from the core VM itself?
In any case, what to be edited seems to be minimal on the image side and isolated in the ImmX11 class; so it looks like it is close.
On Fri, May 13, 2016 at 07:31:07PM -0700, Yoshiki Ohshima wrote:
On Fri, May 13, 2016 at 5:22 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Fri, May 13, 2016 at 4:48 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Iit appears that most bits and pieces are there. For example, sqUnixX11.c does have two functions setCompositionFocus() and setCompositionWIndowPosition(), which used to be in a separated loadable VM plugin but now sitting in there without any caller (if I'm not mistaken). And the NuSqueak image has calls to Hand>>compositionWindowManager, and miraculously, returns an instance of ImmX11.
In ImmX11, setCompositionWindowPositionX:y: has a primitive call into ImmX11Plugin; but it appears that all I have to do is to change it to call the above-mentioned function in sqUnixX11.c.
To make it right, I'd propose to add two more functions to the display module interface. I see the implementation of those for X11 is there, and I remember writing something for Windows; but it can be an empty function.
So, if there is no opposition to add these to the display interface, I'd write a patch for it. But one thing I don't know much about is the HostWindowPlugin. If people think it makes sense to have them there for some reason, we can make that work, too.
This is in struct SqDisplay in platforms/unix/vm/SqDisplay.h? Go for it :-)
Yes, SqDisplay.h is what would be changed.
What I wrote above has some confusion, and I am indeed confused by this:
- the display vm plugin mechanism has primitives that are numbered as
well as primitives that are in plugins like HostWindowPlugin. Is it possible to make then setCompositionFocus() and setCompositionWindowPosition() to be non-numbered yet make them be looked up from a plugin? Wasn't there a way to say to load a primitive from the core VM itself?
Yes they can be non-numbered, and it is better for them to be named primitives. And yes, a named primitive in the VM can be called directly, but here is is better if you let them be named primitives in either ImmX11Plugin or HostWindowPlugin.
To summarize with an example, #primitiveHostWindowPosition is called as a named primitive:
HostWindowProxy>>primitiveWindowPosition: id "Find the topleft corner of the window" <primitive: 'primitiveHostWindowPosition' module: 'HostWindowPlugin'> ^self windowProxyError: 'get position'
The primitive calls ioPositionOfWindow(windowIndex() in the unix support code, declared in platforms/Cross/plugins/HostWindowPlugin.h, implemented in platforms/unix/plugins/sqHostWindowPlugin.c.
The plugin implementation calls a function in whatever VM module has been loaded for the display: dpy->hostWindowGetSize(windowIndex)
For unix/X11, the display module is implemented in sqUnixX11.c, and the function in that loaded module is display_hostWindowGetSize().
You can follow exactly the same pattern for the two new methods that you are adding. Your new primitives can be named primitives in either ImmX11Plugin or HostWindowPlugin.
I do not know which plugin would be better to use, but either one will work.
Dave
In any case, what to be edited seems to be minimal on the image side and isolated in the ImmX11 class; so it looks like it is close.
-- -- Yoshiki
Thanks! I don't have the environment right now, but I'll follow this. But adding ImmX11Plugin (back again) seems to be right thing to do. If I'm not mistaken, this does not actually involve the VMMaker?
On Fri, May 13, 2016 at 8:05 PM, David T. Lewis lewis@mail.msen.com wrote:
On Fri, May 13, 2016 at 07:31:07PM -0700, Yoshiki Ohshima wrote:
On Fri, May 13, 2016 at 5:22 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Fri, May 13, 2016 at 4:48 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Iit appears that most bits and pieces are there. For example, sqUnixX11.c does have two functions setCompositionFocus() and setCompositionWIndowPosition(), which used to be in a separated loadable VM plugin but now sitting in there without any caller (if I'm not mistaken). And the NuSqueak image has calls to Hand>>compositionWindowManager, and miraculously, returns an instance of ImmX11.
In ImmX11, setCompositionWindowPositionX:y: has a primitive call into ImmX11Plugin; but it appears that all I have to do is to change it to call the above-mentioned function in sqUnixX11.c.
To make it right, I'd propose to add two more functions to the display module interface. I see the implementation of those for X11 is there, and I remember writing something for Windows; but it can be an empty function.
So, if there is no opposition to add these to the display interface, I'd write a patch for it. But one thing I don't know much about is the HostWindowPlugin. If people think it makes sense to have them there for some reason, we can make that work, too.
This is in struct SqDisplay in platforms/unix/vm/SqDisplay.h? Go for it :-)
Yes, SqDisplay.h is what would be changed.
What I wrote above has some confusion, and I am indeed confused by this:
- the display vm plugin mechanism has primitives that are numbered as
well as primitives that are in plugins like HostWindowPlugin. Is it possible to make then setCompositionFocus() and setCompositionWindowPosition() to be non-numbered yet make them be looked up from a plugin? Wasn't there a way to say to load a primitive from the core VM itself?
Yes they can be non-numbered, and it is better for them to be named primitives. And yes, a named primitive in the VM can be called directly, but here is is better if you let them be named primitives in either ImmX11Plugin or HostWindowPlugin.
To summarize with an example, #primitiveHostWindowPosition is called as a named primitive:
HostWindowProxy>>primitiveWindowPosition: id "Find the topleft corner of the window" <primitive: 'primitiveHostWindowPosition' module: 'HostWindowPlugin'> ^self windowProxyError: 'get position'
The primitive calls ioPositionOfWindow(windowIndex() in the unix support code, declared in platforms/Cross/plugins/HostWindowPlugin.h, implemented in platforms/unix/plugins/sqHostWindowPlugin.c.
The plugin implementation calls a function in whatever VM module has been loaded for the display: dpy->hostWindowGetSize(windowIndex)
For unix/X11, the display module is implemented in sqUnixX11.c, and the function in that loaded module is display_hostWindowGetSize().
You can follow exactly the same pattern for the two new methods that you are adding. Your new primitives can be named primitives in either ImmX11Plugin or HostWindowPlugin.
I do not know which plugin would be better to use, but either one will work.
Dave
In any case, what to be edited seems to be minimal on the image side and isolated in the ImmX11 class; so it looks like it is close.
-- -- Yoshiki
On Fri, May 13, 2016 at 09:04:08PM -0700, Yoshiki Ohshima wrote:
Thanks! I don't have the environment right now, but I'll follow this. But adding ImmX11Plugin (back again) seems to be right thing to do. If I'm not mistaken, this does not actually involve the VMMaker?
I think that is right. I just tried generating source for ImmX11Plugin from my VMMaker. It seems to compile without problems (but probably it would have unresolved references). The generated ImmX11Plugin.c calls the function declared as extern int setCompositionWindowPosition(int, int).
So I think that what may be needed is to create a new source file platforms/unix/plugins/ImmX11Plugin/sqUnixImmX11Plugin.c and this source file would call the function in the VM display module.
I see now that I do not know enough about the ImmX11Plugin, so I am not sure if I fully understand what needs to be done.
But it works for HostWindowPlugin, so I think that we can make it work for ImmX11Plugin in a similar way.
Dave
On Fri, May 13, 2016 at 8:05 PM, David T. Lewis lewis@mail.msen.com wrote:
On Fri, May 13, 2016 at 07:31:07PM -0700, Yoshiki Ohshima wrote:
On Fri, May 13, 2016 at 5:22 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Fri, May 13, 2016 at 4:48 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Iit appears that most bits and pieces are there. For example, sqUnixX11.c does have two functions setCompositionFocus() and setCompositionWIndowPosition(), which used to be in a separated loadable VM plugin but now sitting in there without any caller (if I'm not mistaken). And the NuSqueak image has calls to Hand>>compositionWindowManager, and miraculously, returns an instance of ImmX11.
In ImmX11, setCompositionWindowPositionX:y: has a primitive call into ImmX11Plugin; but it appears that all I have to do is to change it to call the above-mentioned function in sqUnixX11.c.
To make it right, I'd propose to add two more functions to the display module interface. I see the implementation of those for X11 is there, and I remember writing something for Windows; but it can be an empty function.
So, if there is no opposition to add these to the display interface, I'd write a patch for it. But one thing I don't know much about is the HostWindowPlugin. If people think it makes sense to have them there for some reason, we can make that work, too.
This is in struct SqDisplay in platforms/unix/vm/SqDisplay.h? Go for it :-)
Yes, SqDisplay.h is what would be changed.
What I wrote above has some confusion, and I am indeed confused by this:
- the display vm plugin mechanism has primitives that are numbered as
well as primitives that are in plugins like HostWindowPlugin. Is it possible to make then setCompositionFocus() and setCompositionWindowPosition() to be non-numbered yet make them be looked up from a plugin? Wasn't there a way to say to load a primitive from the core VM itself?
Yes they can be non-numbered, and it is better for them to be named primitives. And yes, a named primitive in the VM can be called directly, but here is is better if you let them be named primitives in either ImmX11Plugin or HostWindowPlugin.
To summarize with an example, #primitiveHostWindowPosition is called as a named primitive:
HostWindowProxy>>primitiveWindowPosition: id "Find the topleft corner of the window" <primitive: 'primitiveHostWindowPosition' module: 'HostWindowPlugin'> ^self windowProxyError: 'get position'
The primitive calls ioPositionOfWindow(windowIndex() in the unix support code, declared in platforms/Cross/plugins/HostWindowPlugin.h, implemented in platforms/unix/plugins/sqHostWindowPlugin.c.
The plugin implementation calls a function in whatever VM module has been loaded for the display: dpy->hostWindowGetSize(windowIndex)
For unix/X11, the display module is implemented in sqUnixX11.c, and the function in that loaded module is display_hostWindowGetSize().
You can follow exactly the same pattern for the two new methods that you are adding. Your new primitives can be named primitives in either ImmX11Plugin or HostWindowPlugin.
I do not know which plugin would be better to use, but either one will work.
Dave
In any case, what to be edited seems to be minimal on the image side and isolated in the ImmX11 class; so it looks like it is close.
-- -- Yoshiki
-- -- Yoshiki
Hi Yoshiki,
On May 13, 2016, at 9:04 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Thanks! I don't have the environment right now, but I'll follow this. But adding ImmX11Plugin (back again) seems to be right thing to do. If I'm not mistaken, this does not actually involve the VMMaker?
Hopefully :-). The Cog build tree is designed to put control on the set of plugins to compile into the hands of a particular build. Plugins are generated to src/plugins, and the idea is for VMMaker to generate as many of them as can be generated. Then to specify what set of plugins to compile into a VM simply edit the plugins.int & plugins.ext in buildOSNNProc/flavour, eg build.linuxARM/squeak.cog.spur/{plugins.int,plugins.ext}.
So provided src/plugins/ImmX11Plugin/ImmX11Plugin.c exists (on my phone right now, will check soon) all you need to do is edit the relevant plugins.int & plugins.ext.
On Fri, May 13, 2016 at 8:05 PM, David T. Lewis lewis@mail.msen.com wrote:
On Fri, May 13, 2016 at 07:31:07PM -0700, Yoshiki Ohshima wrote:
On Fri, May 13, 2016 at 5:22 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Fri, May 13, 2016 at 4:48 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Iit appears that most bits and pieces are there. For example, sqUnixX11.c does have two functions setCompositionFocus() and setCompositionWIndowPosition(), which used to be in a separated loadable VM plugin but now sitting in there without any caller (if I'm not mistaken). And the NuSqueak image has calls to Hand>>compositionWindowManager, and miraculously, returns an instance of ImmX11.
In ImmX11, setCompositionWindowPositionX:y: has a primitive call into ImmX11Plugin; but it appears that all I have to do is to change it to call the above-mentioned function in sqUnixX11.c.
To make it right, I'd propose to add two more functions to the display module interface. I see the implementation of those for X11 is there, and I remember writing something for Windows; but it can be an empty function.
So, if there is no opposition to add these to the display interface, I'd write a patch for it. But one thing I don't know much about is the HostWindowPlugin. If people think it makes sense to have them there for some reason, we can make that work, too.
This is in struct SqDisplay in platforms/unix/vm/SqDisplay.h? Go for it :-)
Yes, SqDisplay.h is what would be changed.
What I wrote above has some confusion, and I am indeed confused by this:
- the display vm plugin mechanism has primitives that are numbered as
well as primitives that are in plugins like HostWindowPlugin. Is it possible to make then setCompositionFocus() and setCompositionWindowPosition() to be non-numbered yet make them be looked up from a plugin? Wasn't there a way to say to load a primitive from the core VM itself?
Yes they can be non-numbered, and it is better for them to be named primitives. And yes, a named primitive in the VM can be called directly, but here is is better if you let them be named primitives in either ImmX11Plugin or HostWindowPlugin.
To summarize with an example, #primitiveHostWindowPosition is called as a named primitive:
HostWindowProxy>>primitiveWindowPosition: id "Find the topleft corner of the window" <primitive: 'primitiveHostWindowPosition' module: 'HostWindowPlugin'> ^self windowProxyError: 'get position'
The primitive calls ioPositionOfWindow(windowIndex() in the unix support code, declared in platforms/Cross/plugins/HostWindowPlugin.h, implemented in platforms/unix/plugins/sqHostWindowPlugin.c.
The plugin implementation calls a function in whatever VM module has been loaded for the display: dpy->hostWindowGetSize(windowIndex)
For unix/X11, the display module is implemented in sqUnixX11.c, and the function in that loaded module is display_hostWindowGetSize().
You can follow exactly the same pattern for the two new methods that you are adding. Your new primitives can be named primitives in either ImmX11Plugin or HostWindowPlugin.
I do not know which plugin would be better to use, but either one will work.
Dave
In any case, what to be edited seems to be minimal on the image side and isolated in the ImmX11 class; so it looks like it is close.
-- Yoshiki
-- Yoshiki
_,,,^..^,,,_ (phone)
On Sat, May 14, 2016 at 07:44:29AM -0700, Eliot Miranda wrote:
Hi Yoshiki,
On May 13, 2016, at 9:04 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Thanks! I don't have the environment right now, but I'll follow this. But adding ImmX11Plugin (back again) seems to be right thing to do. If I'm not mistaken, this does not actually involve the VMMaker?
Hopefully :-). The Cog build tree is designed to put control on the set of plugins to compile into the hands of a particular build. Plugins are generated to src/plugins, and the idea is for VMMaker to generate as many of them as can be generated. Then to specify what set of plugins to compile into a VM simply edit the plugins.int & plugins.ext in buildOSNNProc/flavour, eg build.linuxARM/squeak.cog.spur/{plugins.int,plugins.ext}.
So provided src/plugins/ImmX11Plugin/ImmX11Plugin.c exists (on my phone right now, will check soon) all you need to do is edit the relevant plugins.int & plugins.ext.
Yoshiki,
I have done some additional testing, and I think that on Linux the ImmX11Plugin will work without any code changes at all :-)
I was expecting that some code changes would be needed to enable the primSetCompositionWindowPosition() function in ImmX11Plugin to call setCompositionWindowPosition() in the vm-display-X11 VM module. But I tried compiling ImmX11Plugin as an external module, and running under a gdb debugger. I can confirm that the ImmX11Plugin is calling the external setCompositionWindowPosition() function successfully.
I cannot test this with Cog due to issues with gcc/autotools on the Ubuntu system I am using now, but there should be no differences in doing this on Cog. So I think that if you add ImmX11Plugin to plugins.ext as Eliot describes, then the plugin probably will work for Raspbian without any other changes.
Dave
On Fri, May 13, 2016 at 8:05 PM, David T. Lewis lewis@mail.msen.com wrote:
On Fri, May 13, 2016 at 07:31:07PM -0700, Yoshiki Ohshima wrote:
On Fri, May 13, 2016 at 5:22 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Fri, May 13, 2016 at 4:48 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Iit appears that most bits and pieces are there. For example, sqUnixX11.c does have two functions setCompositionFocus() and setCompositionWIndowPosition(), which used to be in a separated loadable VM plugin but now sitting in there without any caller (if I'm not mistaken). And the NuSqueak image has calls to Hand>>compositionWindowManager, and miraculously, returns an instance of ImmX11.
In ImmX11, setCompositionWindowPositionX:y: has a primitive call into ImmX11Plugin; but it appears that all I have to do is to change it to call the above-mentioned function in sqUnixX11.c.
To make it right, I'd propose to add two more functions to the display module interface. I see the implementation of those for X11 is there, and I remember writing something for Windows; but it can be an empty function.
So, if there is no opposition to add these to the display interface, I'd write a patch for it. But one thing I don't know much about is the HostWindowPlugin. If people think it makes sense to have them there for some reason, we can make that work, too.
This is in struct SqDisplay in platforms/unix/vm/SqDisplay.h? Go for it :-)
Yes, SqDisplay.h is what would be changed.
What I wrote above has some confusion, and I am indeed confused by this:
- the display vm plugin mechanism has primitives that are numbered as
well as primitives that are in plugins like HostWindowPlugin. Is it possible to make then setCompositionFocus() and setCompositionWindowPosition() to be non-numbered yet make them be looked up from a plugin? Wasn't there a way to say to load a primitive from the core VM itself?
Yes they can be non-numbered, and it is better for them to be named primitives. And yes, a named primitive in the VM can be called directly, but here is is better if you let them be named primitives in either ImmX11Plugin or HostWindowPlugin.
To summarize with an example, #primitiveHostWindowPosition is called as a named primitive:
HostWindowProxy>>primitiveWindowPosition: id "Find the topleft corner of the window" <primitive: 'primitiveHostWindowPosition' module: 'HostWindowPlugin'> ^self windowProxyError: 'get position'
The primitive calls ioPositionOfWindow(windowIndex() in the unix support code, declared in platforms/Cross/plugins/HostWindowPlugin.h, implemented in platforms/unix/plugins/sqHostWindowPlugin.c.
The plugin implementation calls a function in whatever VM module has been loaded for the display: dpy->hostWindowGetSize(windowIndex)
For unix/X11, the display module is implemented in sqUnixX11.c, and the function in that loaded module is display_hostWindowGetSize().
You can follow exactly the same pattern for the two new methods that you are adding. Your new primitives can be named primitives in either ImmX11Plugin or HostWindowPlugin.
I do not know which plugin would be better to use, but either one will work.
Dave
In any case, what to be edited seems to be minimal on the image side and isolated in the ImmX11 class; so it looks like it is close.
-- Yoshiki
-- Yoshiki
_,,,^..^,,,_ (phone)
(if you see this twice but with a difference, I'm sorry.)
Hi, David,
At Sun, 15 May 2016 00:58:34 -0400, David T. Lewis wrote:
On Sat, May 14, 2016 at 07:44:29AM -0700, Eliot Miranda wrote:
Hi Yoshiki,
On May 13, 2016, at 9:04 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Thanks! I don't have the environment right now, but I'll follow this. But adding ImmX11Plugin (back again) seems to be right thing to do. If I'm not mistaken, this does not actually involve the VMMaker?
Hopefully :-). The Cog build tree is designed to put control on the set of plugins to compile into the hands of a particular build. Plugins are generated to src/plugins, and the idea is for VMMaker to generate as many of them as can be generated. Then to specify what set of plugins to compile into a VM simply edit the plugins.int & plugins.ext in buildOSNNProc/flavour, eg build.linuxARM/squeak.cog.spur/{plugins.int,plugins.ext}.
So provided src/plugins/ImmX11Plugin/ImmX11Plugin.c exists (on my phone right now, will check soon) all you need to do is edit the relevant plugins.int & plugins.ext.
Yoshiki,
I have done some additional testing, and I think that on Linux the ImmX11Plugin will work without any code changes at all :-)
I was expecting that some code changes would be needed to enable the primSetCompositionWindowPosition() function in ImmX11Plugin to call setCompositionWindowPosition() in the vm-display-X11 VM module. But I tried compiling ImmX11Plugin as an external module, and running under a gdb debugger. I can confirm that the ImmX11Plugin is calling the external setCompositionWindowPosition() function successfully.
I cannot test this with Cog due to issues with gcc/autotools on the Ubuntu system I am using now, but there should be no differences in doing this on Cog. So I think that if you add ImmX11Plugin to plugins.ext as Eliot describes, then the plugin probably will work for Raspbian without any other changes.
It indeed was to my surprise to find out that ImmX11Plugin was in the distribution! It even has more than two primitives I wrote while ago.
I can confirm that many things are working; but it still does require some code change in the VM and in the image.
Mr Hachisuka worked on a similar change and mentioned this:
http://www2.asu.ac.jp/hachi/v3/scratch14ime.html
Effectively, his change to recordPendingKeys() takes UTF8 string but cook them into UTF32 in there. Without this change, the image receives those octets separately, and the way things are set up currently, they are interpreted as individual characters.
We used to have a theory that this might be a job on the image side, but I'd be willing to go along with the idea that the VM does it in recordPendingKeys(). (Attached patch for now has an ifdef, but once it is accepted as a main stream patch, it'd not have to be there.)
Then on the image side, we need to fix ImmX11>>keyboardFocusForMorph: to support non-TextMorphs. My feeble attempt involves to test whether the given morph understand #paragraph and make it read:
------------------- keyboardFocusForAMorph: aMorph
aMorph ifNil: [^ self]. [ | left bottom pos height | pos := aMorph preferredKeyboardPosition. left := (pos x min: Display width max: 0) asInteger. (aMorph respondsTo: #paragraph) ifTrue: [ height := (aMorph paragraph characterBlockForIndex: aMorph editor selectionInterval first) height ] ifFalse: [ height := 0]. bottom := (pos y min: Display height max: 0) asInteger + height. self setCompositionWindowPositionX: left y: bottom asInteger ] on: Error do: [:ex |].
------------------- (#asInteger is sent so that the primitive does not get floats.)
and then to use it StringFieldMorph (and possible a few other classes) need its #keyboardFocusChange: to read:
------------------- keyboardFocusChange: t1 (t1 and: [isKeyboardFocus not]) ifTrue: [lastContents := stringMorph contents]. (isKeyboardFocus and: [t1 not]) ifTrue: [lastContents := nil. isNumeric ifTrue: [self contents: stringMorph contents asNumberNoError printStringNoExponent]. acceptWhenFocusLost ifTrue: [self acceptEdits]]. isKeyboardFocus := t1. isKeyboardFocus ifTrue: [selectionStart := 0. selectionEnd := stringMorph contents size]. "This line below" isKeyboardFocus ifTrue: [ActiveHand compositionWindowManager keyboardFocusForAMorph: self]. self changed -------------------
The result is that when the input method is enabled, and the user tries to type into a field, the preedit window shows up right there where you are typing in.
The prerequite for this is to have all the right environment variables for the X Server and Squeak VM and then the good old -vm-display-X11 -compositioninput is passed in to invoke the VM.
Thank you everybody for all the help! We'll need to fold these changes and I'll test a few more configurations so that a novice user invoking Scratch on Raspbian sees everything al right, but it is getting there!
-- Yoshiki
On 15-05-2016, at 1:29 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Thank you everybody for all the help! We'll need to fold these changes and I'll test a few more configurations so that a novice user invoking Scratch on Raspbian sees everything al right, but it is getting there!
I wish I could have offered something but unix non-anglo character input is so far outside my area I probably can’t even spell it correctly… but once you’ve got it working to your satisfaction I can certainly make sure it gets into the next available Pi release.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Always responds to "Make Money Fast" postings on the Net.
On Sun, May 15, 2016 at 1:32 PM, tim Rowledge tim@rowledge.org wrote:
On 15-05-2016, at 1:29 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Thank you everybody for all the help! We'll need to fold these changes and I'll test a few more configurations so that a novice user invoking Scratch on Raspbian sees everything al right, but it is getting there!
I wish I could have offered something but unix non-anglo character input is so far outside my area I probably can’t even spell it correctly… but once you’ve got it working to your satisfaction I can certainly make sure it gets into the next available Pi release.
Great. One thing I just started poking around was how Scratch actually gets executed when you choose it from the menu. What would have to happen is that the script executed from there (I presume /usr/bin/scratch) checks the LANG environment variable (or call the locale command, and when the result is either ja, ko, or cn (or actually the value of XMODIFIERS has @im), it invokes the VM with "-vm-display-X11 -compositioninput".
Then to the image, two changes to ImmX11>> keyboardFocusForMorph and StringFieldMorph>> keyboardFocusChange. There are some others that implement #keyboardFocusChange: but I have not all understood which ones are relevant to Scratch, and keyboard text input.
With those, and the change to recordPendingKeys(), it will be in good shape.
On Sun, May 15, 2016 at 02:16:17PM -0700, Yoshiki Ohshima wrote:
On Sun, May 15, 2016 at 1:32 PM, tim Rowledge tim@rowledge.org wrote:
On 15-05-2016, at 1:29 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Thank you everybody for all the help! We'll need to fold these changes and I'll test a few more configurations so that a novice user invoking Scratch on Raspbian sees everything al right, but it is getting there!
I wish I could have offered something but unix non-anglo character input is so far outside my area I probably can???t even spell it correctly??? but once you???ve got it working to your satisfaction I can certainly make sure it gets into the next available Pi release.
Great. One thing I just started poking around was how Scratch actually gets executed when you choose it from the menu. What would have to happen is that the script executed from there (I presume /usr/bin/scratch) checks the LANG environment variable (or call the locale command, and when the result is either ja, ko, or cn (or actually the value of XMODIFIERS has @im), it invokes the VM with "-vm-display-X11 -compositioninput".
Then to the image, two changes to ImmX11>> keyboardFocusForMorph and StringFieldMorph>> keyboardFocusChange. There are some others that implement #keyboardFocusChange: but I have not all understood which ones are relevant to Scratch, and keyboard text input.
With those, and the change to recordPendingKeys(), it will be in good shape.
-- -- Yoshiki
If I understand correctly, here is what we need to do:
1) Apply the changes of Mr Hachisuka to the VM. - The diff is in the earlier email from Yoshiki: http://lists.squeakfoundation.org/pipermail/squeak-dev/2016-May/189599.html http://www2.asu.ac.jp/hachi/v3/scratch14ime.html - Test updated VM to make sure the changes do not cause problems. Make sure it works without problems for Squeak trunk and for Scratch. - Apply the update in SVN for both oscog and trunk. I can help here. - Test the VM. Tim, I need help on this. I do not currently have a working Cog build environment (Unbuntu/autotools/gcc version issues). Can you apply the patch from Yoshiki's email and see if your resulting Cog VM continues to work for you as expected on Pi with Scratch? - Yoshiki, we should give credit to Mr Hachisuka for his contribution. Can you please give his full name for the commit notice? I assume the patch is MIT licensed.
2) Make updates to the image. - Start with Yoshiki's recommendations. - Make sure that it works in Scratch, and that all updates are also in Squeak trunk.
3) Make updates to the scripts that call Scratch from the menu (see above, this email).
4) Confirm that Scratch users around the world are happy :-)
Dave
At Sun, 15 May 2016 22:27:13 -0400, David T. Lewis wrote:
On Sun, May 15, 2016 at 02:16:17PM -0700, Yoshiki Ohshima wrote:
On Sun, May 15, 2016 at 1:32 PM, tim Rowledge tim@rowledge.org wrote:
On 15-05-2016, at 1:29 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Thank you everybody for all the help! We'll need to fold these changes and I'll test a few more configurations so that a novice user invoking Scratch on Raspbian sees everything al right, but it is getting there!
I wish I could have offered something but unix non-anglo character input is so far outside my area I probably can???t even spell it correctly??? but once you???ve got it working to your satisfaction I can certainly make sure it gets into the next available Pi release.
Great. One thing I just started poking around was how Scratch actually gets executed when you choose it from the menu. What would have to happen is that the script executed from there (I presume /usr/bin/scratch) checks the LANG environment variable (or call the locale command, and when the result is either ja, ko, or cn (or actually the value of XMODIFIERS has @im), it invokes the VM with "-vm-display-X11 -compositioninput".
Then to the image, two changes to ImmX11>> keyboardFocusForMorph and StringFieldMorph>> keyboardFocusChange. There are some others that implement #keyboardFocusChange: but I have not all understood which ones are relevant to Scratch, and keyboard text input.
With those, and the change to recordPendingKeys(), it will be in good shape.
-- -- Yoshiki
If I understand correctly, here is what we need to do:
- Apply the changes of Mr Hachisuka to the VM.
- The diff is in the earlier email from Yoshiki: http://lists.squeakfoundation.org/pipermail/squeak-dev/2016-May/189599.html
Yes, the attachment to my email is basically a reformatted version of Mr. Hachisuka's patch (with an ifdef)
http://www2.asu.ac.jp/hachi/v3/scratch14ime.html
- Test updated VM to make sure the changes do not cause problems. Make sure it works without problems for Squeak trunk and for Scratch.
Yes. One potential problem I think is that there is an assumption that the code delivered to the pendingKeys is UTF-8. On a platform this assumption is not correct, we would need an additional mechanism.
- Apply the update in SVN for both oscog and trunk. I can help
- here.
Thanks!
- Test the VM. Tim, I need help on this. I do not currently have a working Cog build environment (Unbuntu/autotools/gcc version issues). Can you apply the patch from Yoshiki's email and see if your resulting Cog VM continues to work for you as expected on Pi with Scratch?
And more testing would be nice.
- Yoshiki, we should give credit to Mr Hachisuka for his contribution. Can you please give his full name for the commit notice? I assume the patch is MIT licensed.
I'll ask him about the license.
- Make updates to the image.
- Start with Yoshiki's recommendations.
- Make sure that it works in Scratch, and that all updates are also in Squeak trunk.
- Make updates to the scripts that call Scratch from the menu (see above, this email).
I'll work on the script (I think) today.
- Confirm that Scratch users around the world are happy :-)
Thank you!
-- Yoshiki
Forgive me if I’m being hopelessly naive here, but does this text input mechanism work for other languages too? Would it, for example, be usable as an on-screen keyboard for theRaspberry Pi lcd touchscreen?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Sona si Latine loqueris = Honk if you speak Latin.
On Mon, May 16, 2016 at 10:04 AM, tim Rowledge tim@rowledge.org wrote:
Forgive me if I’m being hopelessly naive here, but does this text input mechanism work for other languages too? Would it, for example, be usable as an on-screen keyboard for theRaspberry Pi lcd touchscreen?
It should work for any other languages that ibus or scim can handle. Yes, it will be usable with the on-screen keyboard.
On Mon, May 16, 2016 at 10:06 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Mon, May 16, 2016 at 10:04 AM, tim Rowledge tim@rowledge.org wrote:
Forgive me if I’m being hopelessly naive here, but does this text input mechanism work for other languages too? Would it, for example, be usable as an on-screen keyboard for theRaspberry Pi lcd touchscreen?
It should work for any other languages that ibus or scim can handle. Yes, it will be usable with the on-screen keyboard.
So I wrote about two possible options on changes to /usr/bin/scratch; I think that the option that uses the XMODIFIERS environment variable, or some other ways to tell that there is an input method running, is more suitable for this purpose.
The relationship between /usr/bin/scratch and /usr/bin/squeak is somewhat confused. /usr/bin/scratch has some code to handle VMOPTIONS but it is not actually passed to /usr/bin/squeak. But then if /usr/bin/scratch was passing those to /usr/bin/squeak, that shell script does not handle them. I'd think it might be good to copy the LD_LIBRARY_PATH part of /usr/bin/squeak to /usr/bin/scratch, and the latter does not deal with the former.
What do you guys think?
On Mon, May 16, 2016 at 10:14 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Mon, May 16, 2016 at 10:06 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Mon, May 16, 2016 at 10:04 AM, tim Rowledge tim@rowledge.org wrote:
Forgive me if I’m being hopelessly naive here, but does this text input mechanism work for other languages too? Would it, for example, be usable as an on-screen keyboard for theRaspberry Pi lcd touchscreen?
It should work for any other languages that ibus or scim can handle. Yes, it will be usable with the on-screen keyboard.
So I wrote about two possible options on changes to /usr/bin/scratch; I think that the option that uses the XMODIFIERS environment variable, or some other ways to tell that there is an input method running, is more suitable for this purpose.
-- -- Yoshiki
I have not actually looked at the /usr/bin/scratch script, but I do know that the use of /usr/bin/squeak (or /usr/local/bin/squeak) is already overloaded depending on what flavor of VM was installed most recently. I suspect that it would be better to have a /usr/bin/scratch script that does exactly what you want it to do, possibly not relying at all on the /usr/bin/squeak script.
Tim, when someone installs Scratch on their Pi, does that installation include the VM? Or does it expect a VM to be installed separately? I am assuming that the Scratch installation would include a VM and with the Scratch plugins, and that you would not want other installations of VMs to affect the Scratch application. Is that right?
Dave
The relationship between /usr/bin/scratch and /usr/bin/squeak is somewhat confused. /usr/bin/scratch has some code to handle VMOPTIONS but it is not actually passed to /usr/bin/squeak. But then if /usr/bin/scratch was passing those to /usr/bin/squeak, that shell script does not handle them. I'd think it might be good to copy the LD_LIBRARY_PATH part of /usr/bin/squeak to /usr/bin/scratch, and the latter does not deal with the former.
What do you guys think?
On Mon, May 16, 2016 at 10:14 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Mon, May 16, 2016 at 10:06 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Mon, May 16, 2016 at 10:04 AM, tim Rowledge tim@rowledge.org wrote:
Forgive me if Iâm being hopelessly naive here, but does this text input mechanism work for other languages too? Would it, for example, be usable as an on-screen keyboard for theRaspberry Pi lcd touchscreen?
It should work for any other languages that ibus or scim can handle. Yes, it will be usable with the on-screen keyboard.
So I wrote about two possible options on changes to /usr/bin/scratch; I think that the option that uses the XMODIFIERS environment variable, or some other ways to tell that there is an input method running, is more suitable for this purpose.
-- -- Yoshiki
-- -- Yoshiki
On Mon, May 16, 2016 at 1:23 PM, David T. Lewis lewis@mail.msen.com wrote:
I have not actually looked at the /usr/bin/scratch script, but I do know that the use of /usr/bin/squeak (or /usr/local/bin/squeak) is already overloaded depending on what flavor of VM was installed most recently. I suspect that it would be better to have a /usr/bin/scratch script that does exactly what you want it to do, possibly not relying at all on the /usr/bin/squeak script.
Tim, when someone installs Scratch on their Pi, does that installation include the VM? Or does it expect a VM to be installed separately? I am assuming that the Scratch installation would include a VM and with the Scratch plugins, and that you would not want other installations of VMs to affect the Scratch application. Is that right?
The "nuscratch" package comes with the following files (besides some other files). The thing is that the package seems to have dependency on the scratch package, which in turn has dependency on squeak-vm. Note that both /usr/bin/squeak and /usr/bin/scratch are replaced with the ones that come in the nuscratch package and old ones are renamed to /usr/bin/squeak.old and /usr/bin/scratch.old.
Yes, I think it is good that the nuscratch package only replaces /usr/bin/scratch, and not depend on the squeak-vm package.
nuscratch: /usr/bin/scratch nuscratch: /usr/bin/squeak nuscratch: /usr/lib/squeak/5.0-3663/LocalePlugin nuscratch: /usr/lib/squeak/5.0-3663/Squeak3D nuscratch: /usr/lib/squeak/5.0-3663/SqueakFFIPrims nuscratch: /usr/lib/squeak/5.0-3663/SqueakSSL nuscratch: /usr/lib/squeak/5.0-3663/UUIDPlugin nuscratch: /usr/lib/squeak/5.0-3663/UnicodePlugin nuscratch: /usr/lib/squeak/5.0-3663/UnixOSProcessPlugin nuscratch: /usr/lib/squeak/5.0-3663/WeDoPlugin nuscratch: /usr/lib/squeak/5.0-3663/XDisplayControlPlugin nuscratch: /usr/lib/squeak/5.0-3663/squeak nuscratch: /usr/lib/squeak/5.0-3663/vm-display-X11 nuscratch: /usr/lib/squeak/5.0-3663/vm-display-null nuscratch: /usr/lib/squeak/5.0-3663/vm-sound-ALSA nuscratch: /usr/lib/squeak/5.0-3663/vm-sound-OSS nuscratch: /usr/lib/squeak/5.0-3663/vm-sound-null nuscratch: /usr/share/scratch/NuScratch02052016.image ...
My suggested change to /usr/bin/scratch would look like attached diff. Basically, it brings in the part to figure out the right LD_LIBRARY_PATH based on the VM's architecture, add a way to specify the display vm module, add a way to specify display module options, and finally figures out the need for -compositioninput based on the XMODIFIERS environment variable.
On Mon, May 16, 2016 at 3:28 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Mon, May 16, 2016 at 1:23 PM, David T. Lewis lewis@mail.msen.com wrote:
I have not actually looked at the /usr/bin/scratch script, but I do know that the use of /usr/bin/squeak (or /usr/local/bin/squeak) is already overloaded depending on what flavor of VM was installed most recently. I suspect that it would be better to have a /usr/bin/scratch script that does exactly what you want it to do, possibly not relying at all on the /usr/bin/squeak script.
Tim, when someone installs Scratch on their Pi, does that installation include the VM? Or does it expect a VM to be installed separately? I am assuming that the Scratch installation would include a VM and with the Scratch plugins, and that you would not want other installations of VMs to affect the Scratch application. Is that right?
The "nuscratch" package comes with the following files (besides some other files). The thing is that the package seems to have dependency on the scratch package, which in turn has dependency on squeak-vm. Note that both /usr/bin/squeak and /usr/bin/scratch are replaced with the ones that come in the nuscratch package and old ones are renamed to /usr/bin/squeak.old and /usr/bin/scratch.old.
Yes, I think it is good that the nuscratch package only replaces /usr/bin/scratch, and not depend on the squeak-vm package.
nuscratch: /usr/bin/scratch nuscratch: /usr/bin/squeak nuscratch: /usr/lib/squeak/5.0-3663/LocalePlugin nuscratch: /usr/lib/squeak/5.0-3663/Squeak3D nuscratch: /usr/lib/squeak/5.0-3663/SqueakFFIPrims nuscratch: /usr/lib/squeak/5.0-3663/SqueakSSL nuscratch: /usr/lib/squeak/5.0-3663/UUIDPlugin nuscratch: /usr/lib/squeak/5.0-3663/UnicodePlugin nuscratch: /usr/lib/squeak/5.0-3663/UnixOSProcessPlugin nuscratch: /usr/lib/squeak/5.0-3663/WeDoPlugin nuscratch: /usr/lib/squeak/5.0-3663/XDisplayControlPlugin nuscratch: /usr/lib/squeak/5.0-3663/squeak nuscratch: /usr/lib/squeak/5.0-3663/vm-display-X11 nuscratch: /usr/lib/squeak/5.0-3663/vm-display-null nuscratch: /usr/lib/squeak/5.0-3663/vm-sound-ALSA nuscratch: /usr/lib/squeak/5.0-3663/vm-sound-OSS nuscratch: /usr/lib/squeak/5.0-3663/vm-sound-null nuscratch: /usr/share/scratch/NuScratch02052016.image ...
-- -- Yoshiki
NuScratch is not at all properly packaged so far as I’m aware. I simply zip up all the relevant files and dump them on the Pi people, they install them in the Raspbian releases and there you are. So, no dependencies on packages, no users installing it, no complications of multiple VMs. It’s all there ready to run as soon as you boot.
As for the two shell scripts… they’re hacked up versions of the mess I inherited. In my view the /usr/bin/scratch script should gather up all the scratch specific settings, variable, paths and pass them onto the /usr/bin/squeak script which should run the appropriate vm under the appropriate settings with the given image and possible extra options. If someone has a better way to do it I’m very happy to learn.
There are no faffing arounds with working out cpu architecture etc since we just don’t care about anyone not smart enough to run on a Pi :-) And if anyone is worrying about licenses etc (I know they’re out there; just like Zombies in the movies, they’re *always out there*) please don’t ask me. Not my issue; my views on license stuff are well scatted across the net and are probably not safe for the faint of heart. Email the Raspberry Pi Foundation and talk to them.
Oh, and Yoshiki, you have an out of date version. Fetch a new copy of Raspbian...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Four wheels move the body. Two wheels move the soul
On Mon, May 16, 2016 at 4:55 PM, tim Rowledge tim@rowledge.org wrote:
NuScratch is not at all properly packaged so far as I’m aware. I simply zip up all the relevant files and dump them on the Pi people, they install them in the Raspbian releases and there you are. So, no dependencies on packages, no users installing it, no complications of multiple VMs. It’s all there ready to run as soon as you boot.
As for the two shell scripts… they’re hacked up versions of the mess I inherited. In my view the /usr/bin/scratch script should gather up all the scratch specific settings, variable, paths and pass them onto the /usr/bin/squeak script which should run the appropriate vm under the appropriate settings with the given image and possible extra options. If someone has a better way to do it I’m very happy to learn.
There are no faffing arounds with working out cpu architecture etc since we just don’t care about anyone not smart enough to run on a Pi :-) And if anyone is worrying about licenses etc (I know they’re out there; just like Zombies in the movies, they’re *always out there*) please don’t ask me. Not my issue; my views on license stuff are well scatted across the net and are probably not safe for the faint of heart. Email the Raspberry Pi Foundation and talk to them.
Oh, and Yoshiki, you have an out of date version. Fetch a new copy of Raspbian...
Oh, shoot. Are you talking about "May-10" version? I am just now trying apt-get dist-upgrade but would it update /usr/bin/scratch?
In any case, at least the patch attached to my last email captures the change that is needed and get rid of the need to call /usr/bin/squeak. So adapting this should not be hard.
On 16-05-2016, at 5:01 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Oh, shoot. Are you talking about "May-10" version? I am just now trying apt-get dist-upgrade but would it update /usr/bin/scratch?
Yup. upgrade etc *ought* to work but I too often read of problems, so I just fetch a full release and so on. I guess you might try specifically updating nuscratch (can you do that? I dunno, probably too logical for unix), though you ought to get the pigpio libraries/daemon as well or the gpio server will not work.
In any case, at least the patch attached to my last email captures the change that is needed and get rid of the need to call /usr/bin/squeak. So adapting this should not be hard.
-- -- Yoshiki
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Both.." said Pooh, as the guillotine came down
Okay. I think dist-upgrade did it and here is a new patch that is against the latest /usr/bin/scratch:
On Mon, May 16, 2016 at 5:07 PM, tim Rowledge tim@rowledge.org wrote:
On 16-05-2016, at 5:01 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Oh, shoot. Are you talking about "May-10" version? I am just now trying apt-get dist-upgrade but would it update /usr/bin/scratch?
Yup. upgrade etc *ought* to work but I too often read of problems, so I just fetch a full release and so on. I guess you might try specifically updating nuscratch (can you do that? I dunno, probably too logical for unix), though you ought to get the pigpio libraries/daemon as well or the gpio server will not work.
In any case, at least the patch attached to my last email captures the change that is needed and get rid of the need to call /usr/bin/squeak. So adapting this should not be hard.
-- -- Yoshiki
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Both.." said Pooh, as the guillotine came down
On 16.05.2016, at 19:06, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Mon, May 16, 2016 at 10:04 AM, tim Rowledge tim@rowledge.org wrote:
Forgive me if I’m being hopelessly naive here, but does this text input mechanism work for other languages too? Would it, for example, be usable as an on-screen keyboard for theRaspberry Pi lcd touchscreen?
It should work for any other languages that ibus or scim can handle. Yes, it will be usable with the on-screen keyboard.
Would it be feasible to make the VM primitives generic? That is, do not call it “ImmX11Plugin” but e.g. “KeyboardPlugin” and the “focus” primitive would be called whenever a text field is focused, and the image would pass the cursor position as arguments (plus possibly the text field bounds).
Then we could implement the same primitives in e.g. the iOS or Android VMs to support the on-screen keyboard.
- Bert -
On Tue, May 17, 2016 at 7:29 AM, Bert Freudenberg bert@freudenbergs.de wrote:
On 16.05.2016, at 19:06, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Mon, May 16, 2016 at 10:04 AM, tim Rowledge tim@rowledge.org wrote:
Forgive me if I’m being hopelessly naive here, but does this text input mechanism work for other languages too? Would it, for example, be usable as an on-screen keyboard for theRaspberry Pi lcd touchscreen?
It should work for any other languages that ibus or scim can handle. Yes, it will be usable with the on-screen keyboard.
Would it be feasible to make the VM primitives generic? That is, do not call it “ImmX11Plugin” but e.g. “KeyboardPlugin” and the “focus” primitive would be called whenever a text field is focused, and the image would pass the cursor position as arguments (plus possibly the text field bounds).
Then we could implement the same primitives in e.g. the iOS or Android VMs to support the on-screen keyboard.
I think it's feasible in theory. Originally, we had separated primitives for different platforms and the dispatch was done in the image. But standard primitive sounds reasonable.
On the practice side, The current ImmX11Plugin somehow got some Unix Locale features, which must have been added by for some reasons; it is is a bit overloaded and may require to disentangle them.
On Mon, May 16, 2016 at 9:30 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
At Sun, 15 May 2016 22:27:13 -0400, David T. Lewis wrote:
- Yoshiki, we should give credit to Mr Hachisuka for his contribution. Can you please give his full name for the commit notice? I assume the patch is MIT licensed.
I'll ask him about the license.
Mr. Hachisuka stated that it is fine to use the MIT license for that code.
On Tue, May 17, 2016 at 06:29:59PM -0700, Yoshiki Ohshima wrote:
On Mon, May 16, 2016 at 9:30 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
At Sun, 15 May 2016 22:27:13 -0400, David T. Lewis wrote:
- Yoshiki, we should give credit to Mr Hachisuka for his contribution. Can you please give his full name for the commit notice? I assume the patch is MIT licensed.
I'll ask him about the license.
Mr. Hachisuka stated that it is fine to use the MIT license for that code.
Yoshiki,
Thank you for confirming this.
Dave
On Mon, May 16, 2016 at 09:30:02AM -0700, Yoshiki Ohshima wrote:
At Sun, 15 May 2016 22:27:13 -0400, David T. Lewis wrote:
- Test the VM. Tim, I need help on this. I do not currently have a working Cog build environment (Unbuntu/autotools/gcc version issues). Can you apply the patch from Yoshiki's email and see if your resulting Cog VM continues to work for you as expected on Pi with Scratch?
And more testing would be nice.
Tim,
The attached sqUnixX11.c should get the HostWindowPlugin functions working on Cog/Spur. If that is confirmed, I will commit to SVN oscog branch and then we can follow up with the ImmX11 updates.
When you get a chance, can you please compile a VM with the attached sqUnixX11.c and let me know if the following works on Squeak trunk and Raspberry Pi:
saveExtent := Display width @ Display height. DisplayScreen hostWindowExtent: 500@100. (Delay forSeconds: 4) wait. DisplayScreen hostWindowExtent: saveExtent.
Thanks, Dave
On Sun, May 15, 2016 at 10:27:13PM -0400, David T. Lewis wrote:
If I understand correctly, here is what we need to do:
- Apply the changes of Mr Hachisuka to the VM.
- The diff is in the earlier email from Yoshiki: http://lists.squeakfoundation.org/pipermail/squeak-dev/2016-May/189599.html http://www2.asu.ac.jp/hachi/v3/scratch14ime.html
- Test updated VM to make sure the changes do not cause problems. Make sure it works without problems for Squeak trunk and for Scratch.
- Apply the update in SVN for both oscog and trunk. I can help here.
- Test the VM. Tim, I need help on this. I do not currently have a working Cog build environment (Unbuntu/autotools/gcc version issues). Can you apply the patch from Yoshiki's email and see if your resulting Cog VM continues to work for you as expected on Pi with Scratch?
- Yoshiki, we should give credit to Mr Hachisuka for his contribution. Can you please give his full name for the commit notice? I assume the patch is MIT licensed.
Hi Yoshiki,
I think that I now understand the VM changes for sqUnixX11.c, and I have applied the changes of Mr Hachisuka and committed them to the SVN trunk for interpreter VM. If these changes are correct, then I will also make a patch and commit them to the oscog branch for Cog/Spur VMs.
I arranged the code such that the multibyte recordPendingKeys() logic is used if and only if the -compositioninput option is set on the command line or the equivalent SQUEAK_COMPOSITIONINPUT environment variable is set. I believe that this is the intended usage, but please let me know if I did not understand.
If you are able to compile an interpreter VM (http://wiki.squeak.org/squeak/6354), then please let me know if these changes work as you expect. If you cannot easily make an interpreter VM, then I can commit the changes to the Cog/Spur branch, but I would prefer to test them first if possible.
I also found that many of the module command line options are not being passed correctly from the VM to the modules. The -compositionsinput option was one of these, so I fixed it in this update (and I will check if for Cog/Spur when we apply the patch there). But there are others that do not work, so if you find other VM options for multilingual support that do not work as expected, this may be the reason.
Dave
I'll try to do that. I haven't looked at the code but do you handle the case where the locale encoding is not UTF8 (e.g., ja_JP.EUC-JP) etc?
On Sun, May 22, 2016 at 5:03 PM, David T. Lewis lewis@mail.msen.com wrote:
On Sun, May 15, 2016 at 10:27:13PM -0400, David T. Lewis wrote:
If I understand correctly, here is what we need to do:
- Apply the changes of Mr Hachisuka to the VM.
- The diff is in the earlier email from Yoshiki: http://lists.squeakfoundation.org/pipermail/squeak-dev/2016-May/189599.html http://www2.asu.ac.jp/hachi/v3/scratch14ime.html
- Test updated VM to make sure the changes do not cause problems. Make sure it works without problems for Squeak trunk and for Scratch.
- Apply the update in SVN for both oscog and trunk. I can help here.
- Test the VM. Tim, I need help on this. I do not currently have a working Cog build environment (Unbuntu/autotools/gcc version issues). Can you apply the patch from Yoshiki's email and see if your resulting Cog VM continues to work for you as expected on Pi with Scratch?
- Yoshiki, we should give credit to Mr Hachisuka for his contribution. Can you please give his full name for the commit notice? I assume the patch is MIT licensed.
Hi Yoshiki,
I think that I now understand the VM changes for sqUnixX11.c, and I have applied the changes of Mr Hachisuka and committed them to the SVN trunk for interpreter VM. If these changes are correct, then I will also make a patch and commit them to the oscog branch for Cog/Spur VMs.
I arranged the code such that the multibyte recordPendingKeys() logic is used if and only if the -compositioninput option is set on the command line or the equivalent SQUEAK_COMPOSITIONINPUT environment variable is set. I believe that this is the intended usage, but please let me know if I did not understand.
If you are able to compile an interpreter VM (http://wiki.squeak.org/squeak/6354), then please let me know if these changes work as you expect. If you cannot easily make an interpreter VM, then I can commit the changes to the Cog/Spur branch, but I would prefer to test them first if possible.
I also found that many of the module command line options are not being passed correctly from the VM to the modules. The -compositionsinput option was one of these, so I fixed it in this update (and I will check if for Cog/Spur when we apply the patch there). But there are others that do not work, so if you find other VM options for multilingual support that do not work as expected, this may be the reason.
Dave
On Mon, May 23, 2016 at 03:29:53PM -0700, Yoshiki Ohshima wrote:
I'll try to do that. I haven't looked at the code but do you handle the case where the locale encoding is not UTF8 (e.g., ja_JP.EUC-JP) etc?
No, I made no changes to the logic except that it is conditional based on the value of the compositionInput variable. I do not know if this is the correct approach. I also found that the -compositioninput flag was not working (it is supposed to set the compositionInput variable), so I fixed that in sqUnixMain.c.
I am attaching a copy of the updated function so you can see it more easily.
Dave
On Sun, May 22, 2016 at 5:03 PM, David T. Lewis lewis@mail.msen.com wrote:
On Sun, May 15, 2016 at 10:27:13PM -0400, David T. Lewis wrote:
If I understand correctly, here is what we need to do:
- Apply the changes of Mr Hachisuka to the VM.
- The diff is in the earlier email from Yoshiki: http://lists.squeakfoundation.org/pipermail/squeak-dev/2016-May/189599.html http://www2.asu.ac.jp/hachi/v3/scratch14ime.html
- Test updated VM to make sure the changes do not cause problems. Make sure it works without problems for Squeak trunk and for Scratch.
- Apply the update in SVN for both oscog and trunk. I can help here.
- Test the VM. Tim, I need help on this. I do not currently have a working Cog build environment (Unbuntu/autotools/gcc version issues). Can you apply the patch from Yoshiki's email and see if your resulting Cog VM continues to work for you as expected on Pi with Scratch?
- Yoshiki, we should give credit to Mr Hachisuka for his contribution. Can you please give his full name for the commit notice? I assume the patch is MIT licensed.
Hi Yoshiki,
I think that I now understand the VM changes for sqUnixX11.c, and I have applied the changes of Mr Hachisuka and committed them to the SVN trunk for interpreter VM. If these changes are correct, then I will also make a patch and commit them to the oscog branch for Cog/Spur VMs.
I arranged the code such that the multibyte recordPendingKeys() logic is used if and only if the -compositioninput option is set on the command line or the equivalent SQUEAK_COMPOSITIONINPUT environment variable is set. I believe that this is the intended usage, but please let me know if I did not understand.
If you are able to compile an interpreter VM (http://wiki.squeak.org/squeak/6354), then please let me know if these changes work as you expect. If you cannot easily make an interpreter VM, then I can commit the changes to the Cog/Spur branch, but I would prefer to test them first if possible.
I also found that many of the module command line options are not being passed correctly from the VM to the modules. The -compositionsinput option was one of these, so I fixed it in this update (and I will check if for Cog/Spur when we apply the patch there). But there are others that do not work, so if you find other VM options for multilingual support that do not work as expected, this may be the reason.
Dave
-- -- Yoshiki
Ok. (Still have not looked into it yet) but in regards to handling different encodings, I think handling UTF-8 is at least an improvement over the current status so that is fine. The compositioninput was an option to the vm module but if the main module handles that, that is fine, too.
On Mon, May 23, 2016 at 4:09 PM, David T. Lewis lewis@mail.msen.com wrote:
On Mon, May 23, 2016 at 03:29:53PM -0700, Yoshiki Ohshima wrote:
I'll try to do that. I haven't looked at the code but do you handle the case where the locale encoding is not UTF8 (e.g., ja_JP.EUC-JP) etc?
No, I made no changes to the logic except that it is conditional based on the value of the compositionInput variable. I do not know if this is the correct approach. I also found that the -compositioninput flag was not working (it is supposed to set the compositionInput variable), so I fixed that in sqUnixMain.c.
I am attaching a copy of the updated function so you can see it more easily.
Dave
On Sun, May 22, 2016 at 5:03 PM, David T. Lewis lewis@mail.msen.com wrote:
On Sun, May 15, 2016 at 10:27:13PM -0400, David T. Lewis wrote:
If I understand correctly, here is what we need to do:
- Apply the changes of Mr Hachisuka to the VM.
- The diff is in the earlier email from Yoshiki: http://lists.squeakfoundation.org/pipermail/squeak-dev/2016-May/189599.html http://www2.asu.ac.jp/hachi/v3/scratch14ime.html
- Test updated VM to make sure the changes do not cause problems. Make sure it works without problems for Squeak trunk and for Scratch.
- Apply the update in SVN for both oscog and trunk. I can help here.
- Test the VM. Tim, I need help on this. I do not currently have a working Cog build environment (Unbuntu/autotools/gcc version issues). Can you apply the patch from Yoshiki's email and see if your resulting Cog VM continues to work for you as expected on Pi with Scratch?
- Yoshiki, we should give credit to Mr Hachisuka for his contribution. Can you please give his full name for the commit notice? I assume the patch is MIT licensed.
Hi Yoshiki,
I think that I now understand the VM changes for sqUnixX11.c, and I have applied the changes of Mr Hachisuka and committed them to the SVN trunk for interpreter VM. If these changes are correct, then I will also make a patch and commit them to the oscog branch for Cog/Spur VMs.
I arranged the code such that the multibyte recordPendingKeys() logic is used if and only if the -compositioninput option is set on the command line or the equivalent SQUEAK_COMPOSITIONINPUT environment variable is set. I believe that this is the intended usage, but please let me know if I did not understand.
If you are able to compile an interpreter VM (http://wiki.squeak.org/squeak/6354), then please let me know if these changes work as you expect. If you cannot easily make an interpreter VM, then I can commit the changes to the Cog/Spur branch, but I would prefer to test them first if possible.
I also found that many of the module command line options are not being passed correctly from the VM to the modules. The -compositionsinput option was one of these, so I fixed it in this update (and I will check if for Cog/Spur when we apply the patch there). But there are others that do not work, so if you find other VM options for multilingual support that do not work as expected, this may be the reason.
Dave
-- -- Yoshiki
It
On Sun, May 22, 2016 at 5:03 PM, David T. Lewis lewis@mail.msen.com wrote:
On Sun, May 15, 2016 at 10:27:13PM -0400, David T. Lewis wrote:
If I understand correctly, here is what we need to do:
- Apply the changes of Mr Hachisuka to the VM.
- The diff is in the earlier email from Yoshiki: http://lists.squeakfoundation.org/pipermail/squeak-dev/2016-May/189599.html http://www2.asu.ac.jp/hachi/v3/scratch14ime.html
- Test updated VM to make sure the changes do not cause problems. Make sure it works without problems for Squeak trunk and for Scratch.
- Apply the update in SVN for both oscog and trunk. I can help here.
- Test the VM. Tim, I need help on this. I do not currently have a working Cog build environment (Unbuntu/autotools/gcc version issues). Can you apply the patch from Yoshiki's email and see if your resulting Cog VM continues to work for you as expected on Pi with Scratch?
- Yoshiki, we should give credit to Mr Hachisuka for his contribution. Can you please give his full name for the commit notice? I assume the patch is MIT licensed.
Hi Yoshiki,
I think that I now understand the VM changes for sqUnixX11.c, and I have applied the changes of Mr Hachisuka and committed them to the SVN trunk for interpreter VM. If these changes are correct, then I will also make a patch and commit them to the oscog branch for Cog/Spur VMs.
I arranged the code such that the multibyte recordPendingKeys() logic is used if and only if the -compositioninput option is set on the command line or the equivalent SQUEAK_COMPOSITIONINPUT environment variable is set. I believe that this is the intended usage, but please let me know if I did not understand.
If you are able to compile an interpreter VM (http://wiki.squeak.org/squeak/6354), then please let me know if these changes work as you expect. If you cannot easily make an interpreter VM, then I can commit the changes to the Cog/Spur branch, but I would prefer to test them first if possible.
It does buiid. Yay. The build directory structure seems to be different from Cog, though. How do I test a VM that is just generated? Do people set different install directory someways?
On Tue, May 24, 2016 at 09:50:45AM -0700, Yoshiki Ohshima wrote:
On Sun, May 22, 2016 at 5:03 PM, David T. Lewis lewis@mail.msen.com wrote:
On Sun, May 15, 2016 at 10:27:13PM -0400, David T. Lewis wrote:
If I understand correctly, here is what we need to do:
- Apply the changes of Mr Hachisuka to the VM.
- The diff is in the earlier email from Yoshiki: http://lists.squeakfoundation.org/pipermail/squeak-dev/2016-May/189599.html http://www2.asu.ac.jp/hachi/v3/scratch14ime.html
- Test updated VM to make sure the changes do not cause problems. Make sure it works without problems for Squeak trunk and for Scratch.
- Apply the update in SVN for both oscog and trunk. I can help here.
- Test the VM. Tim, I need help on this. I do not currently have a working Cog build environment (Unbuntu/autotools/gcc version issues). Can you apply the patch from Yoshiki's email and see if your resulting Cog VM continues to work for you as expected on Pi with Scratch?
- Yoshiki, we should give credit to Mr Hachisuka for his contribution. Can you please give his full name for the commit notice? I assume the patch is MIT licensed.
Hi Yoshiki,
I think that I now understand the VM changes for sqUnixX11.c, and I have applied the changes of Mr Hachisuka and committed them to the SVN trunk for interpreter VM. If these changes are correct, then I will also make a patch and commit them to the oscog branch for Cog/Spur VMs.
I arranged the code such that the multibyte recordPendingKeys() logic is used if and only if the -compositioninput option is set on the command line or the equivalent SQUEAK_COMPOSITIONINPUT environment variable is set. I believe that this is the intended usage, but please let me know if I did not understand.
If you are able to compile an interpreter VM (http://wiki.squeak.org/squeak/6354), then please let me know if these changes work as you expect. If you cannot easily make an interpreter VM, then I can commit the changes to the Cog/Spur branch, but I would prefer to test them first if possible.
It does buiid. Yay. The build directory structure seems to be different from Cog, though. How do I test a VM that is just generated? Do people set different install directory someways?
I do not think that there is any standard approach for this, but here is what I do for my own use:
- Install a Cog VM. Rename the /usr/local/bin/squeak file to /usr/local/bin/cog. This is the 32-bit JIT VM for Squeak V3 images.
- Install a Spur VM. Rename /usr/local/bin/squeak file to /usr/local/bin/spur. This is the 32-bit JIT Spur VM for Spur images.
- Install Spur 64 bit VM. Rename the /usr/local/bin/squeak file to /usr/local/bin/spur64. This is the 64-bit JIT Spur VM for 64 bit Spur images.
- Compile and install trunk interpreter VM. Do not rename the /usr/local/bin/squeak file. These are the 64-bit VMs for both 32-bit V3 image and 64-bit V3 image.
With this arrangement, I type "cog" when I want to run a Cog VM, "spur" when I want to run a Spur VM, and "spur64" when I want to run a 64-bit Spur. For either 32-bit or 64-bit V3 images, I type "squeak".
I also have a script of my own making installed as /usr/local/bin/vmrun that selects an appropriate VM based on the image format, but I no longer use it because I usually know which VM I want anyway, so it is better for me to just use "cog", "spur", "spur64", or "squeak" directly.
Yoshiki, I should mention that since my last email, I have also updated the SVN oscog branch so that the -compositionInput option will work on Cog and Spur. This means that we can apply the sqUnixX11.c patch for Cog and Spur also, and it should now work the same as for the interpreter VM. But I appreciate very much if you can first confirm that the patch works as you expect on interpreter VM. Then we can apply the update for Cog/Spur so that it can be used for Scratch on Raspberry Pi.
I am sorry if I am moving too slowly here, but I do not understand how multibyte character composition should work, so I am trying to be careful with the changes.
Dave
I'd rather avoid touching existing files. But once I figure out how to pass --prefix for configure under the cmake regime, I am happy to go forward from there. (No, Dave, you are moving very fast and prompt! Thank you!)
But then I'll try the oscog branch and makes a cleaner now.
On Tue, May 24, 2016 at 8:20 PM, David T. Lewis lewis@mail.msen.com wrote:
On Tue, May 24, 2016 at 09:50:45AM -0700, Yoshiki Ohshima wrote:
On Sun, May 22, 2016 at 5:03 PM, David T. Lewis lewis@mail.msen.com wrote:
On Sun, May 15, 2016 at 10:27:13PM -0400, David T. Lewis wrote:
If I understand correctly, here is what we need to do:
- Apply the changes of Mr Hachisuka to the VM.
- The diff is in the earlier email from Yoshiki: http://lists.squeakfoundation.org/pipermail/squeak-dev/2016-May/189599.html http://www2.asu.ac.jp/hachi/v3/scratch14ime.html
- Test updated VM to make sure the changes do not cause problems. Make sure it works without problems for Squeak trunk and for Scratch.
- Apply the update in SVN for both oscog and trunk. I can help here.
- Test the VM. Tim, I need help on this. I do not currently have a working Cog build environment (Unbuntu/autotools/gcc version issues). Can you apply the patch from Yoshiki's email and see if your resulting Cog VM continues to work for you as expected on Pi with Scratch?
- Yoshiki, we should give credit to Mr Hachisuka for his contribution. Can you please give his full name for the commit notice? I assume the patch is MIT licensed.
Hi Yoshiki,
I think that I now understand the VM changes for sqUnixX11.c, and I have applied the changes of Mr Hachisuka and committed them to the SVN trunk for interpreter VM. If these changes are correct, then I will also make a patch and commit them to the oscog branch for Cog/Spur VMs.
I arranged the code such that the multibyte recordPendingKeys() logic is used if and only if the -compositioninput option is set on the command line or the equivalent SQUEAK_COMPOSITIONINPUT environment variable is set. I believe that this is the intended usage, but please let me know if I did not understand.
If you are able to compile an interpreter VM (http://wiki.squeak.org/squeak/6354), then please let me know if these changes work as you expect. If you cannot easily make an interpreter VM, then I can commit the changes to the Cog/Spur branch, but I would prefer to test them first if possible.
It does buiid. Yay. The build directory structure seems to be different from Cog, though. How do I test a VM that is just generated? Do people set different install directory someways?
I do not think that there is any standard approach for this, but here is what I do for my own use:
- Install a Cog VM. Rename the /usr/local/bin/squeak file to /usr/local/bin/cog.
This is the 32-bit JIT VM for Squeak V3 images.
- Install a Spur VM. Rename /usr/local/bin/squeak file to /usr/local/bin/spur.
This is the 32-bit JIT Spur VM for Spur images.
- Install Spur 64 bit VM. Rename the /usr/local/bin/squeak file to /usr/local/bin/spur64.
This is the 64-bit JIT Spur VM for 64 bit Spur images.
- Compile and install trunk interpreter VM. Do not rename the /usr/local/bin/squeak
file. These are the 64-bit VMs for both 32-bit V3 image and 64-bit V3 image.
With this arrangement, I type "cog" when I want to run a Cog VM, "spur" when I want to run a Spur VM, and "spur64" when I want to run a 64-bit Spur. For either 32-bit or 64-bit V3 images, I type "squeak".
I also have a script of my own making installed as /usr/local/bin/vmrun that selects an appropriate VM based on the image format, but I no longer use it because I usually know which VM I want anyway, so it is better for me to just use "cog", "spur", "spur64", or "squeak" directly.
Yoshiki, I should mention that since my last email, I have also updated the SVN oscog branch so that the -compositionInput option will work on Cog and Spur. This means that we can apply the sqUnixX11.c patch for Cog and Spur also, and it should now work the same as for the interpreter VM. But I appreciate very much if you can first confirm that the patch works as you expect on interpreter VM. Then we can apply the update for Cog/Spur so that it can be used for Scratch on Raspberry Pi.
I am sorry if I am moving too slowly here, but I do not understand how multibyte character composition should work, so I am trying to be careful with the changes.
Dave
It may have already been mentioned but just in case - on the unix builds (at least for Cog) the built vm is moved to the ‘products’ directory. For example on a Pi you build in ………./Cog/build.linux32ARM/squeak.cog.spur and find the completed (hopefully!) vm in ………../Cog/products/cogspurlinuxhtARM which you then copy to your Pi working directory (say, /home/pi/Scratch) and run with ./cogspurlinuxhtARM/squeak -vm-sound-demented my.image or similar.
So far as I can work out the Mac vms don’t get moved to products. And I have no idea about Windows vms.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Not an idiot, but plays one in his life.
On Wed, May 25, 2016 at 10:02 AM, tim Rowledge tim@rowledge.org wrote:
It may have already been mentioned but just in case - on the unix builds (at least for Cog) the built vm is moved to the ‘products’ directory. For example on a Pi you build in ………./Cog/build.linux32ARM/squeak.cog.spur and find the completed (hopefully!) vm in ………../Cog/products/cogspurlinuxhtARM which you then copy to your Pi working directory (say, /home/pi/Scratch) and run with ./cogspurlinuxhtARM/squeak -vm-sound-demented my.image or similar.
Right. The modified version of scratch script I made can take the --vm option that works so I can run the one in the products directory.
For the interpreter VM, I just edited Makefile and pass --prefix=/home/pi/usr to configure.
On Wed, May 25, 2016 at 11:52 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Wed, May 25, 2016 at 10:02 AM, tim Rowledge tim@rowledge.org wrote:
It may have already been mentioned but just in case - on the unix builds (at least for Cog) the built vm is moved to the ‘products’ directory. For example on a Pi you build in ………./Cog/build.linux32ARM/squeak.cog.spur and find the completed (hopefully!) vm in ………../Cog/products/cogspurlinuxhtARM which you then copy to your Pi working directory (say, /home/pi/Scratch) and run with ./cogspurlinuxhtARM/squeak -vm-sound-demented my.image or similar.
Right. The modified version of scratch script I made can take the --vm option that works so I can run the one in the products directory.
In any case, this is the current scratch script that works with the new scheme of passing -compositioninput flag without needing the display module spec.
On Wed, May 25, 2016 at 9:51 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
I'd rather avoid touching existing files. But once I figure out how to pass --prefix for configure under the cmake regime, I am happy to go forward from there. (No, Dave, you are moving very fast and prompt! Thank you!)
But then I'll try the oscog branch and makes a cleaner now.
I've been assuming that the "oscog" branch is "svn/branches/Cog", and I can confirm that the -compositioninput flag provided to the main VM binary is passed to the X11 driver, and other things seem to work. (The recordPendingKeys() in r3730 is not updated and ImmX11Plugin has not been added to plugins.ext so the actual Japanese input still does not work, but it seems close.)
In any case, I just copy and pasted the implementation of recordPendingKeys() from trunk to the Cog branch and it works as expected in an UTF8 environment.
On Wed, May 25, 2016 at 12:13 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Wed, May 25, 2016 at 9:51 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
I'd rather avoid touching existing files. But once I figure out how to pass --prefix for configure under the cmake regime, I am happy to go forward from there. (No, Dave, you are moving very fast and prompt! Thank you!)
But then I'll try the oscog branch and makes a cleaner now.
I've been assuming that the "oscog" branch is "svn/branches/Cog", and I can confirm that the -compositioninput flag provided to the main VM binary is passed to the X11 driver, and other things seem to work. (The recordPendingKeys() in r3730 is not updated and ImmX11Plugin has not been added to plugins.ext so the actual Japanese input still does not work, but it seems close.) -- -- Yoshiki
On Wed, May 25, 2016 at 03:42:45PM -0700, Yoshiki Ohshima wrote:
On Wed, May 25, 2016 at 12:13 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Wed, May 25, 2016 at 9:51 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
I'd rather avoid touching existing files. But once I figure out how to pass --prefix for configure under the cmake regime, I am happy to go forward from there. (No, Dave, you are moving very fast and prompt! Thank you!)
But then I'll try the oscog branch and makes a cleaner now.
I've been assuming that the "oscog" branch is "svn/branches/Cog", and I can confirm that the -compositioninput flag provided to the main VM binary is passed to the X11 driver, and other things seem to work. (The recordPendingKeys() in r3730 is not updated and ImmX11Plugin has not been added to plugins.ext so the actual Japanese input still does not work, but it seems close.)
In any case, I just copy and pasted the implementation of recordPendingKeys() from trunk to the Cog branch and it works as expected in an UTF8 environment.
Excellent, thank you for confirming.
Yes when I said "oscog branch" I should have said "svn/branches/Cog", sorry.
I just committed the update to SVN branches/Cog so that all of the Cog, Spur, and interpreter VMs will have the new recordPendingKeys() function, and command line parameters will be passed correctly to the X11 display module.
Dave
I see r3732, which has the working recordPendingKeys(). Once ImmX11Plugin is automatically added to plugins.ext, I think the VM change is all set.
Thank you!
On Wed, May 25, 2016 at 5:09 PM, David T. Lewis lewis@mail.msen.com wrote:
On Wed, May 25, 2016 at 03:42:45PM -0700, Yoshiki Ohshima wrote:
On Wed, May 25, 2016 at 12:13 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Wed, May 25, 2016 at 9:51 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
I'd rather avoid touching existing files. But once I figure out how to pass --prefix for configure under the cmake regime, I am happy to go forward from there. (No, Dave, you are moving very fast and prompt! Thank you!)
But then I'll try the oscog branch and makes a cleaner now.
I've been assuming that the "oscog" branch is "svn/branches/Cog", and I can confirm that the -compositioninput flag provided to the main VM binary is passed to the X11 driver, and other things seem to work. (The recordPendingKeys() in r3730 is not updated and ImmX11Plugin has not been added to plugins.ext so the actual Japanese input still does not work, but it seems close.)
In any case, I just copy and pasted the implementation of recordPendingKeys() from trunk to the Cog branch and it works as expected in an UTF8 environment.
Excellent, thank you for confirming.
Yes when I said "oscog branch" I should have said "svn/branches/Cog", sorry.
I just committed the update to SVN branches/Cog so that all of the Cog, Spur, and interpreter VMs will have the new recordPendingKeys() function, and command line parameters will be passed correctly to the X11 display module.
Dave
On Tue, May 24, 2016 at 8:20 PM, David T. Lewis lewis@mail.msen.com wrote:
On Tue, May 24, 2016 at 09:50:45AM -0700, Yoshiki Ohshima wrote:
On Sun, May 22, 2016 at 5:03 PM, David T. Lewis lewis@mail.msen.com wrote:
On Sun, May 15, 2016 at 10:27:13PM -0400, David T. Lewis wrote:
If I understand correctly, here is what we need to do:
- Apply the changes of Mr Hachisuka to the VM.
- The diff is in the earlier email from Yoshiki: http://lists.squeakfoundation.org/pipermail/squeak-dev/2016-May/189599.html http://www2.asu.ac.jp/hachi/v3/scratch14ime.html
- Test updated VM to make sure the changes do not cause problems. Make sure it works without problems for Squeak trunk and for Scratch.
- Apply the update in SVN for both oscog and trunk. I can help here.
- Test the VM. Tim, I need help on this. I do not currently have a working Cog build environment (Unbuntu/autotools/gcc version issues). Can you apply the patch from Yoshiki's email and see if your resulting Cog VM continues to work for you as expected on Pi with Scratch?
- Yoshiki, we should give credit to Mr Hachisuka for his contribution. Can you please give his full name for the commit notice? I assume the patch is MIT licensed.
Hi Yoshiki,
I think that I now understand the VM changes for sqUnixX11.c, and I have applied the changes of Mr Hachisuka and committed them to the SVN trunk for interpreter VM. If these changes are correct, then I will also make a patch and commit them to the oscog branch for Cog/Spur VMs.
I arranged the code such that the multibyte recordPendingKeys() logic is used if and only if the -compositioninput option is set on the command line or the equivalent SQUEAK_COMPOSITIONINPUT environment variable is set. I believe that this is the intended usage, but please let me know if I did not understand.
If you are able to compile an interpreter VM (http://wiki.squeak.org/squeak/6354), then please let me know if these changes work as you expect. If you cannot easily make an interpreter VM, then I can commit the changes to the Cog/Spur branch, but I would prefer to test them first if possible.
It does buiid. Yay. The build directory structure seems to be different from Cog, though. How do I test a VM that is just generated? Do people set different install directory someways?
I do not think that there is any standard approach for this, but here is what I do for my own use:
- Install a Cog VM. Rename the /usr/local/bin/squeak file to /usr/local/bin/cog.
This is the 32-bit JIT VM for Squeak V3 images.
- Install a Spur VM. Rename /usr/local/bin/squeak file to /usr/local/bin/spur.
This is the 32-bit JIT Spur VM for Spur images.
- Install Spur 64 bit VM. Rename the /usr/local/bin/squeak file to /usr/local/bin/spur64.
This is the 64-bit JIT Spur VM for 64 bit Spur images.
- Compile and install trunk interpreter VM. Do not rename the /usr/local/bin/squeak
file. These are the 64-bit VMs for both 32-bit V3 image and 64-bit V3 image.
With this arrangement, I type "cog" when I want to run a Cog VM, "spur" when I want to run a Spur VM, and "spur64" when I want to run a 64-bit Spur. For either 32-bit or 64-bit V3 images, I type "squeak".
I also have a script of my own making installed as /usr/local/bin/vmrun that selects an appropriate VM based on the image format, but I no longer use it because I usually know which VM I want anyway, so it is better for me to just use "cog", "spur", "spur64", or "squeak" directly.
Yoshiki, I should mention that since my last email, I have also updated the SVN oscog branch so that the -compositionInput option will work on Cog and Spur. This means that we can apply the sqUnixX11.c patch for Cog and Spur also, and it should now work the same as for the interpreter VM. But I appreciate very much if you can first confirm that the patch works as you expect on interpreter VM. Then we can apply the update for Cog/Spur so that it can be used for Scratch on Raspberry Pi.
In any case, I built an interpreter VM (of trunk, rev. 3730). But I get an error:
This interpreter (vers. 0) cannot read image file (vers. 6521)
Any thoughts?
On Wed, May 25, 2016 at 11:31:02AM -0700, Yoshiki Ohshima wrote:
On Tue, May 24, 2016 at 8:20 PM, David T. Lewis lewis@mail.msen.com wrote:
Yoshiki, I should mention that since my last email, I have also updated the SVN oscog branch so that the -compositionInput option will work on Cog and Spur. This means that we can apply the sqUnixX11.c patch for Cog and Spur also, and it should now work the same as for the interpreter VM. But I appreciate very much if you can first confirm that the patch works as you expect on interpreter VM. Then we can apply the update for Cog/Spur so that it can be used for Scratch on Raspberry Pi.
In any case, I built an interpreter VM (of trunk, rev. 3730). But I get an error:
This interpreter (vers. 0) cannot read image file (vers. 6521)
Any thoughts?
Image format 6521 is the 32-bit Spur image format used in Squeak 5.0. A Spur VM is required to run this image. Tim's latest Scratch work is updated to the 6521 Spur image format, so an interpreter VM can no longer be used to run these images.
Squeak 4.6 and earlier will work with the interpreter VM, and I expect that an older Scratch image should work also, although I do not know exactly when Scratch moved to Spur 6521.
Dave
On 25-05-2016, at 5:48 PM, David T. Lewis lewis@mail.msen.com wrote:
Squeak 4.6 and earlier will work with the interpreter VM, and I expect that an older Scratch image should work also, although I do not know exactly when Scratch moved to Spur 6521.
Around last August? Basically as soon as we had Cog working. We didn’t really put any effort into making an V3 Cog and in fact so far as I recall it may not be doable without some hassles because we couldn’t make a method entry block that would conform to the alignment parameters Eliot uses to discriminate between something and something else.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CEQ: Corrupt and Erase Queue
On Wed, May 25, 2016 at 06:22:49PM -0700, tim Rowledge wrote:
On 25-05-2016, at 5:48 PM, David T. Lewis lewis@mail.msen.com wrote:
Squeak 4.6 and earlier will work with the interpreter VM, and I expect that an older Scratch image should work also, although I do not know exactly when Scratch moved to Spur 6521.
Around last August? Basically as soon as we had Cog working. We didn???t really put any effort into making an V3 Cog and in fact so far as I recall it may not be doable without some hassles because we couldn???t make a method entry block that would conform to the alignment parameters Eliot uses to discriminate between something and something else.
Cog VMs for V3 images built from the latest sources work fine, yes? The pre-built VMs have been updated quite recently at http://www.mirandabanda.org/files/Cog/VM/VM.r3692/
So for an image in Spur 6521 format, you need a Spur VM. For images in the earlier V3 format, any Cog or interpreter VM should work. The Scratch image was moved to Spur 6521 format approximately last August, so these recent Scratch images require a Spur VM.
The necessary platforms source updates (Cog/Spur/Interpreter) are now in sync for the X11 display. We do still need to make sure that ImmX11Plugin is included in the VM for Scratch on Raspbian (and maybe we need to do some updates to the plugin, I am not sure), but otherwise we should now be close to having Scratch character input working for Japanese users.
Dave
Thanks for clarification. I wasn't quite sure that the image in the All in One was a Spur image, and also the error message (vers. 0) made me think that the VM was properly built.
On Wed, May 25, 2016 at 5:48 PM, David T. Lewis lewis@mail.msen.com wrote:
On Wed, May 25, 2016 at 11:31:02AM -0700, Yoshiki Ohshima wrote:
On Tue, May 24, 2016 at 8:20 PM, David T. Lewis lewis@mail.msen.com wrote:
Yoshiki, I should mention that since my last email, I have also updated the SVN oscog branch so that the -compositionInput option will work on Cog and Spur. This means that we can apply the sqUnixX11.c patch for Cog and Spur also, and it should now work the same as for the interpreter VM. But I appreciate very much if you can first confirm that the patch works as you expect on interpreter VM. Then we can apply the update for Cog/Spur so that it can be used for Scratch on Raspberry Pi.
In any case, I built an interpreter VM (of trunk, rev. 3730). But I get an error:
This interpreter (vers. 0) cannot read image file (vers. 6521)
Any thoughts?
Image format 6521 is the 32-bit Spur image format used in Squeak 5.0. A Spur VM is required to run this image. Tim's latest Scratch work is updated to the 6521 Spur image format, so an interpreter VM can no longer be used to run these images.
Squeak 4.6 and earlier will work with the interpreter VM, and I expect that an older Scratch image should work also, although I do not know exactly when Scratch moved to Spur 6521.
Dave
The error message "vers. 0" is a bug. It is supposed to give a meaningful version number for the VM. Funny but I never noticed this before.
Maybe the message should be revised anyway, because one version of the interpreter can read more than one image format. An interpreter for 32-bit object memory can support image formats 6502, 6504, and 6505. An interpreter for 64-bit V3 images supports image formats 68000, 68002, and 68003.
Dave
On Wed, May 25, 2016 at 08:10:25PM -0700, Yoshiki Ohshima wrote:
Thanks for clarification. I wasn't quite sure that the image in the All in One was a Spur image, and also the error message (vers. 0) made me think that the VM was properly built.
On Wed, May 25, 2016 at 5:48 PM, David T. Lewis lewis@mail.msen.com wrote:
On Wed, May 25, 2016 at 11:31:02AM -0700, Yoshiki Ohshima wrote:
On Tue, May 24, 2016 at 8:20 PM, David T. Lewis lewis@mail.msen.com wrote:
Yoshiki, I should mention that since my last email, I have also updated the SVN oscog branch so that the -compositionInput option will work on Cog and Spur. This means that we can apply the sqUnixX11.c patch for Cog and Spur also, and it should now work the same as for the interpreter VM. But I appreciate very much if you can first confirm that the patch works as you expect on interpreter VM. Then we can apply the update for Cog/Spur so that it can be used for Scratch on Raspberry Pi.
In any case, I built an interpreter VM (of trunk, rev. 3730). But I get an error:
This interpreter (vers. 0) cannot read image file (vers. 6521)
Any thoughts?
Image format 6521 is the 32-bit Spur image format used in Squeak 5.0. A Spur VM is required to run this image. Tim's latest Scratch work is updated to the 6521 Spur image format, so an interpreter VM can no longer be used to run these images.
Squeak 4.6 and earlier will work with the interpreter VM, and I expect that an older Scratch image should work also, although I do not know exactly when Scratch moved to Spur 6521.
Dave
-- -- Yoshiki
On Fri, May 13, 2016 at 05:22:59PM -0700, Eliot Miranda wrote:
On Fri, May 13, 2016 at 4:48 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Iit appears that most bits and pieces are there. For example, sqUnixX11.c does have two functions setCompositionFocus() and setCompositionWIndowPosition(), which used to be in a separated loadable VM plugin but now sitting in there without any caller (if I'm not mistaken). And the NuSqueak image has calls to Hand>>compositionWindowManager, and miraculously, returns an instance of ImmX11.
In ImmX11, setCompositionWindowPositionX:y: has a primitive call into ImmX11Plugin; but it appears that all I have to do is to change it to call the above-mentioned function in sqUnixX11.c.
To make it right, I'd propose to add two more functions to the display module interface. I see the implementation of those for X11 is there, and I remember writing something for Windows; but it can be an empty function.
So, if there is no opposition to add these to the display interface, I'd write a patch for it. But one thing I don't know much about is the HostWindowPlugin. If people think it makes sense to have them there for some reason, we can make that work, too.
This is in struct SqDisplay in platforms/unix/vm/SqDisplay.h? Go for it :-)
That sounds right to me also.
Yoshiki,
I have some changes to HostWindowPlugin that makes it work for the latest Squeak trunk. I do not think that this will conflict with any of your changes, and I will post the updates as soon as I can (but maybe not for a couple of days).
I do not know if primSetCompositionWindowPosition should better be in ImmX11Plugin or in HostWindowPlugin, but I see no reason to worry about it now. If someone finds a reason to change it, they can do that later.
Eliot,
The SqDisplayVersionMinor in oscog is 5, and in trunk it is 2. Adding the Qwaq enhancements needed for HostWindowPlugin would make trunk go from 2 -> 3, and the actual implementations in oscog seem to imply we should be at 3 there also. Maybe there were other Qwaq enhancements (that are not relevant here?) that moved the version number to 5.
Yoshiki's interface enhancement should probably bump the minor version up by one, making it either 3 -> 4 or 5 -> 6.
I'm inclined to think that we should just declare the current minor version to be 5 (as in oscog now) and chalk up the difference to missing Qwaq features, and then let Yoshiki's enhancement be SqDisplayVersionMinor be 6.
Does that sound right?
Dave
Hi Dave,
On May 13, 2016, at 7:31 PM, David T. Lewis lewis@mail.msen.com wrote:
On Fri, May 13, 2016 at 05:22:59PM -0700, Eliot Miranda wrote: On Fri, May 13, 2016 at 4:48 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Iit appears that most bits and pieces are there. For example, sqUnixX11.c does have two functions setCompositionFocus() and setCompositionWIndowPosition(), which used to be in a separated loadable VM plugin but now sitting in there without any caller (if I'm not mistaken). And the NuSqueak image has calls to Hand>>compositionWindowManager, and miraculously, returns an instance of ImmX11.
In ImmX11, setCompositionWindowPositionX:y: has a primitive call into ImmX11Plugin; but it appears that all I have to do is to change it to call the above-mentioned function in sqUnixX11.c.
To make it right, I'd propose to add two more functions to the display module interface. I see the implementation of those for X11 is there, and I remember writing something for Windows; but it can be an empty function.
So, if there is no opposition to add these to the display interface, I'd write a patch for it. But one thing I don't know much about is the HostWindowPlugin. If people think it makes sense to have them there for some reason, we can make that work, too.
This is in struct SqDisplay in platforms/unix/vm/SqDisplay.h? Go for it :-)
That sounds right to me also.
Yoshiki,
I have some changes to HostWindowPlugin that makes it work for the latest Squeak trunk. I do not think that this will conflict with any of your changes, and I will post the updates as soon as I can (but maybe not for a couple of days).
I do not know if primSetCompositionWindowPosition should better be in ImmX11Plugin or in HostWindowPlugin, but I see no reason to worry about it now. If someone finds a reason to change it, they can do that later.
Eliot,
The SqDisplayVersionMinor in oscog is 5, and in trunk it is 2. Adding the Qwaq enhancements needed for HostWindowPlugin would make trunk go from 2 -> 3, and the actual implementations in oscog seem to imply we should be at 3 there also. Maybe there were other Qwaq enhancements (that are not relevant here?) that moved the version number to 5.
I made at least two changes after Qwaq. I can check, but they fixed deficiencies, perhaps with sound, perhaps with dnd. I'll figure it out and post. But 5 is meaningful, not arbitrary :-).
Yoshiki's interface enhancement should probably bump the minor version up by one, making it either 3 -> 4 or 5 -> 6.
I'm inclined to think that we should just declare the current minor version to be 5 (as in oscog now) and chalk up the difference to missing Qwaq features, and then let Yoshiki's enhancement be SqDisplayVersionMinor be 6.
Does that sound right?
Yes, spot on.
Dave
Cheers, both!
oh, ok. I'll give it a try.
On Fri, May 6, 2016 at 4:27 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Fri, May 6, 2016 at 4:21 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
it's probably just the absence of a sources file. I don't include itin the VMs on my site to save space. Simply link the sources into the lib dir in the directory tree, or include the sources in the directory containing the image.
Oops, it needs to go I'm the same directory as the VM, so e.g. add cogspurlinux/lib/squeak/4.5-3692/ ]SqueakV50.sources
On Fri, May 6, 2016 at 3:53 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Thu, May 5, 2016 at 4:34 PM, David T. Lewis lewis@mail.msen.com wrote:
There is an ./images directory that contains development images, and a README to explain. There are also ./build.* directories for building various configurations.
Thanks!
First, I can run Squeak-5.0-All-in-One.zip. on Pi.
I managed to compile squeak.cog.spur VM on ARM (raspberry pi). However, when I tried to open the image in the All in One, it creates a window but inside of it is just blank and does not do any interaction. I downloaded
http://www.mirandabanda.org/files/Cog/VM/VM.r3692/cogspurlinuxhtARM-16.18.36... and tried it, but it has the same problem.
I looked into the chain of shell scripts and tried a command line like:
env LD_LIBRARY_PATH=/home/pi/tmp/cogspurlinuxhtARM/lib/squeak/5.0-3692:/lib/arm-linux-gnueabihf:/lib:/usr/lib/arm-linux-gnueabihf:/usr/lib /home/pi/tmp/cogspurlinuxhtARM/lib/squeak/5.0-3692/squeak ~/Squeak5.0-15113.image
but no avail.
Does anybody know why the all in one vm and image works but the VM I downloaded from Eliot's site (nor the one I compiled)?
-- -- Yoshiki
-- _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
On 05-05-2016, at 4:01 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Great. Thanks.
I'll give it a try... I might not do NFS but seems good. So the VM would be the one I would produce by checking out the svn repository on squeakvm.org, go to the branches/Cog directory and compile? Is there a dev image you use?
Just grab the Squeak 5.0 all-in-one bundle. It has a cog/spur vm ready to go on the Pi. And the image, of course. Just update it as usual. If you want the latest vm, then yes, you can build it in the normal manner as described in the Eliot’s readme. I’d guess that one could get from opening a fresh Pi box to running Sq5 on a new built vm in less than an hour, including all the apt-get and compile time etc. I did most of it a few weeks ago without problem just before a demo.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim To define recursion, we must first define recursion.
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
David T. Lewis -
Eliot Miranda -
John Pfersich -
Stephan Eggermont -
tim Rowledge -
Yoshiki Ohshima