With squeak-vm-4.10.2.2614 with the Scratch plugin that's included, the Help Screens function (which is supposed to launch a browser with HTML help) does not work. If I copy in the so.ScratchPlugin from the Scratch package, however, it works fine.
(Code is 'ScratchPlugin primOpenURL: helpDir pathName, FileDirectory slash, aFilename')
On Thu, Jan 31, 2013 at 11:29:00AM -0500, Matthew Miller wrote:
With squeak-vm-4.10.2.2614 with the Scratch plugin that's included, the Help Screens function (which is supposed to launch a browser with HTML help) does not work. If I copy in the so.ScratchPlugin from the Scratch package, however, it works fine.
(Code is 'ScratchPlugin primOpenURL: helpDir pathName, FileDirectory slash, aFilename')
Hi Matthew,
I'm checking back through these posts, and it sounds like we have two issues that require follow up. Both the CameraPlugin and ScratchPlugin have problems in the standard Squeak VM, and those problems are not present in the plugins distributed with Scratch. Is that correct?
Thanks, Dave
On 2013-02-13, at 12:54, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Jan 31, 2013 at 11:29:00AM -0500, Matthew Miller wrote:
With squeak-vm-4.10.2.2614 with the Scratch plugin that's included, the Help Screens function (which is supposed to launch a browser with HTML help) does not work. If I copy in the so.ScratchPlugin from the Scratch package, however, it works fine.
(Code is 'ScratchPlugin primOpenURL: helpDir pathName, FileDirectory slash, aFilename')
Hi Matthew,
I'm checking back through these posts, and it sounds like we have two issues that require follow up. Both the CameraPlugin and ScratchPlugin have problems in the standard Squeak VM, and those problems are not present in the plugins distributed with Scratch. Is that correct?
Thanks, Dave
Also, Matthew, which architecture are you running on? x86_64 by chance?
- Bert -
On Thu, Feb 14, 2013 at 03:22:02PM +0100, Bert Freudenberg wrote:
Also, Matthew, which architecture are you running on? x86_64 by chance?
Yes I am. I can test in a i386 VM if it helps. (Well, not the camera.)
On 2013-02-14, at 15:24, Matthew Miller mattdm@mattdm.org wrote:
On Thu, Feb 14, 2013 at 03:22:02PM +0100, Bert Freudenberg wrote:
Also, Matthew, which architecture are you running on? x86_64 by chance?
Yes I am.
That is vital information. Most likely these plugins are not yet 64-bit clean.
I can test in a i386 VM if it helps. (Well, not the camera.)
You could simply run the i386 version of Squeak in your 64 bit Linux. That should work perfectly fine.
This might do the job of installing it (untested):
sudo yum install squeak-vm.i686
- Bert -
On Thu, Feb 14, 2013 at 03:29:28PM +0100, Bert Freudenberg wrote:
Also, Matthew, which architecture are you running on? x86_64 by chance?
Yes I am.
That is vital information. Most likely these plugins are not yet 64-bit clean.
Huh. In 2013 I rarely consider that anymore. :) I'll test and see what I find.
I can test in a i386 VM if it helps. (Well, not the camera.)
You could simply run the i386 version of Squeak in your 64 bit Linux. That should work perfectly fine.
That's okay for me, but it's not okay for the Fedora Linux distribution I'm working on packaging it for.
This might do the job of installing it (untested): sudo yum install squeak-vm.i686
We generally only have 32-bit versions of packages in x86_64 when they're white-listed in for a specific reason.
On 2013-02-14, at 15:34, Matthew Miller mattdm@mattdm.org wrote:
On Thu, Feb 14, 2013 at 03:29:28PM +0100, Bert Freudenberg wrote:
Also, Matthew, which architecture are you running on? x86_64 by chance?
Yes I am.
That is vital information. Most likely these plugins are not yet 64-bit clean.
Huh. In 2013 I rarely consider that anymore. :) I'll test and see what I find.
There is zero benefit to Scratch (or any current Squeak app) from running on a 64 bit VM, since all Squeak images in use are 32 bits. It's only thanks to David's hard work recently (and Ian's/Dan's work initially) that it mostly works, for the convenience of Linux folks who insist on doing everything in 64 bits. (Windows and Mac users happily use the 32 bit VMs)
So yes, we are working on it (or rather, Dave is), but the reason it's not finished yet is that it has too little benefit currently.
This will change with a more widespread adoption of 64-bit images (there is an up-to-date 64 bit image, again thanks to David: http://build.squeak.org/job/Squeak%2064-bit%20image/ ) but then again, this will need yet another VM: http://squeakvm.org/squeak64/faq.html
(we hope Linux packagers will hide the VM selection details behind a common squeakvm script that launches the right binary for the image)
I can test in a i386 VM if it helps. (Well, not the camera.)
You could simply run the i386 version of Squeak in your 64 bit Linux. That should work perfectly fine.
That's okay for me, but it's not okay for the Fedora Linux distribution I'm working on packaging it for.
This might do the job of installing it (untested): sudo yum install squeak-vm.i686
We generally only have 32-bit versions of packages in x86_64 when they're white-listed in for a specific reason.
Having "working software" might be a good reason? ;)
- Bert -
Bert Freudenberg wrote:
(we hope Linux packagers will hide the VM selection details behind a common squeakvm script that launches the right binary for the image)
I can test in a i386 VM if it helps. (Well, not the camera.)
You could simply run the i386 version of Squeak in your 64 bit Linux. That should work perfectly fine.
That's okay for me, but it's not okay for the Fedora Linux distribution I'm working on packaging it for.
This might do the job of installing it (untested): sudo yum install squeak-vm.i686
We generally only have 32-bit versions of packages in x86_64 when they're white-listed in for a specific reason.
Having "working software" might be a good reason? ;)
I agree with Bert. Fedora allows us to install 32-bit packages. The user needs to install all the dynamically linked 32 bit shared object libraries too: which would be easier if the 32-bit dependencies were listed in an RPM. But once this is done, Squeak works perfectly, including the camera, as far as I know (I didn't try all the plugins yet.) The alternative would be for a team of x86_64 enthusiasts to discover and squash all the bugs introduced by selecting 64-bit architecture options for the C compiler.
Thanks to Jaroslav's great work incorporating David Lewis's recent x86_64 bug squashed code in the Fedora source RPM, Fedora 18 is in a much better shape than earlier releases ( https://bugzilla.redhat.com/show_bug.cgi?id=879974 )
Where is the right place to influence the Fedora decision-making process? I take it you (Matthew) and Jaroslav can't make the decision to go 32-bit on your own.
One thing we could keep an eye out for, to avoid it happening again, is when the Fedora buildbot reported x86_64 failed builds for F15(?) onwards, and the automatic build process fell back to distributing an old and broken 64-bit squeak vm in the six-monthly releases. The Sugar-on-a-Stick community then automatically published x86_64 spins of Fedora whose Etoys and Scratch didn't work! (In my own experience, Squeak was one of several Sugar packages completely broken in Fedora 16 x86_64.)
I may be wrong, but I wonder if these concerns are also relevant for the other 64-bit platforms that Fedora builds for. (Alpha, Sparc etc still around? 64-bit ARM?)
On the same topic, will 32-bit ARM Squeak (Linux, Android, iOS, Windows, or RiscOS) run on the new 64-bit ARM platforms?
Matthew wrote:
the Help Screens function (which is supposed to launch a browser with HTML help) does not work. If I copy in the so.ScratchPlugin from the Scratch package, however, it works fine. (Code is 'ScratchPlugin primOpenURL: helpDir pathName, FileDirectory slash,
aFilename')
In 2011 there was a Pharo Scratch community, 'Scat', (links below) that forked MIT's Smalltalk branch of Scratch, when MIT efforts refocused on Actionscript Scratch. Perhaps there is functionality in the current Squeak / Pharo that duplicates the functionality of the OpenURL primitive. If I recall correctly, modern Squeak can launch a browser on most common desktops without a special plugin. Anyway, it might be worth suggesting to the Scat community or looking into more deeply, if not for the short term gain of wroking around a bug, for the long term benefits of Don't Repeat Yourself :)
Have fun! David
Scat links: http://code.google.com/p/scat/ http://www.squeaksource.com/nscratch.html
On Wed, Feb 13, 2013 at 06:54:47AM -0500, David T. Lewis wrote:
I'm checking back through these posts, and it sounds like we have two issues that require follow up. Both the CameraPlugin and ScratchPlugin have problems in the standard Squeak VM, and those problems are not present in the plugins distributed with Scratch. Is that correct?
That's definitely the case with ScratchPlugin, but I need to go back to verify that CameraPlugin isn't also crashing in the version that comes with Scratch.
vm-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
David Corking -
David T. Lewis -
Matthew Miller