Hi Dave,

I followed your suggestion and could resolve this issue, thanks a lot.

Here the steps followed:

1) Uninstall, squeak-vm 64 bits comes with Ubuntu distribution, without its depends.

1) dpkg -r --force-no-depends squeak-vm

2) Download squeak-vm 32 bits.

wget http://www.squeakvm.org/unix/release/Squeak-4.10.2.2614-linux_i386.sh

sudo sh Squeak-4.10.2.2614-linux_i386.sh

Choice as path prefix /usr instead default: /usr/local

3) Install 32 bits compatibility library:

sudo apt-get install ia32-libs

I know that is a workaround, the finally solution as you said, is update the plugins to working properly on 64 bit architectures.

Thank you very much !

Gustavo.

On 04/05/2014 12:44 PM, David T. Lewis wrote:

On Sat, Apr 05, 2014 at 11:25:54AM -0300, Gustavo Duarte wrote:

...

Hi folks,

Imagen capture using web camera produces a a segmentation fault.

I'm using:

Squeak: 4.4.7 Scratch: 1.4.06 Plugins squeak-plugins-scratch: 1.4.0.2~svn.r83-1

My laptop is running Ubuntu 12.04 64 bits.

Here the output stack trace.

---

gustavo@gusHP ~ $ scratch Executing: padsp /usr/lib/squeak/4.4.7-2357/squeakvm -encoding UTF-8 -vm-display-x11 -fullscreen -plugins /usr/lib/scratch/plugins/:/usr/lib/squeak/4.4.7-2357/ -vm-sound-oss /usr/share/scratch/Scratch.image

Segmentation fault

11283804 BitBlt>setDestForm: 11283712 BitBlt class>toForm: 11283464 WarpBlt class>toForm: 11283372 ScratchCameraDialog>step 11283256 Morph>stepAt: 11280616 [] in PasteUpMorph>runStepMethods 11280120 OrderedCollection>do: 11280340 [] in PasteUpMorph>runStepMethods 11279452 BlockContext>ifError: 11279360 PasteUpMorph>runStepMethods 11271628 PasteUpMorph>doOneCycleNow 11271536 PasteUpMorph>doOneCycle 4967012 [] in Project>spawnNewProcess 4967104 [] in BlockContext>newProcess Aborted

---

Where do you think could be the bug, on Squeak, Scratch or Plugin ?

Hi Gustavo,

This is probably a bug in the camera plugin. This plugin has not been updated to work properly in 64-bit mode, and it might well cause a crash like this.

I think that you are probably using a VM that was compiled in 64-bit mode for an Ubuntu distribution. A 64-bit VM works fine for most Squeak users (I use one every day without problems). However, there are some plugins that do not yet work in 64-bit mode, and this causes problems if those plugins are used. For this reason, the VMs that are distributed from the squeakvm.org or squeak.org sites are compiled in 32-bit mode.

If you can, please try installing a VM from http://squeakvm.org/unix/ and using that with Scratch. Because it is a 32-bit application, you may also need to install 32-bit compatibility libraries for Ubuntu. I think that this will probably resolve the camera plugin problem.

I have also added a bug report on our Mantis bug tracker to follow up on this issue at http://bugs.squeak.org/view.php?id=7816

Dave

Hi David.

I have added this thread to my "keepers" folder. I will try to get to it after the SqueakSSL.

cordially,

tty

Hi All,

Just to clarify, the CameraPlugin is for WebCams correct?

Yes, that's right.

r.e. SqueakSSL: The plugin should currently be identical (I hope) in all branches of the VM. Both the interpreter VM (trunk) and the Pharo VM use CMake for the unix build, so you should not experience the libtool difficulties when working with either of them. IIRC, Ian Piumarta originally created the CMake build for Squeak VM back in 2009 largely because of problems with libtool, particularly related mixed 32 and 64 bit libraries. CMake seems to take care of the problem nicely.

Thx.

Also, for a heads up on the SqueakSSL, I am going to switch gears for a bit and then approach the problem from the Pharo side--if the pharo works out of the box on my 64 bit machine with 32 bit libs, then it will help me in identifying the issue on the Squeak side. If not, then I will start digging deeper on what I have.

thx for your help.

tty.

---- On Thu, 10 Apr 2014 07:39:47 -0700 David T. Lewis<lewis@mail.msen.com> wrote ----

> Hi All, > > > > Just to clarify, the CameraPlugin is for WebCams correct? >

Yes, that's right.

On 10-04-2014, at 9:51 AM, gettimothy gettimothy@zoho.com wrote:

1. Regarding CMake Isn't Eliot migrating more towards a Gnu style build tree from CMake (that is what I have inferred from emails he has addressed to Tim R)?

Eliot has stated that he would be happy to see the cog stuff made properly compatible with everything else and moved to using CMake - but that he has no interest in doing nor time to do the work. I offered a $1000 bounty for anyone (or several) making Cog work with CMake, but nobody appears to have any need for a spare $1000 so far.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Religious tolerance

Hi Tty,

On Thu, Apr 10, 2014 at 10:26 AM, gettimothy gettimothy@zoho.com wrote:

As it just so happens, I am unemployed and broke!

Please define the project scope and deliverables and I will get it done!

I'm not paying so I don't get to state the deliverables. But what I want is for the Cog linux build to use CMake. That is, make the build directories under http://www.squeakvm.org/svn/squeak/branches/Cog/unixbuildand http://www.squeakvm.org/svn/squeak/branches/Cog/nscogbuild/unixbuild to work, but to use CMake. My current build enbvironment is a CentOS 5.3 VM running under Parallels. The most convenient thing for me would be that the builds continue to work on this now rather old CentOS.

Thanks!!

---- On Thu, 10 Apr 2014 10:07:58 -0700 *tim Rowledge<tim@rowledge.org tim@rowledge.org>* wrote ----

On 10-04-2014, at 9:51 AM, gettimothy gettimothy@zoho.com wrote:

...

1. Regarding CMake Isn't Eliot migrating more towards a Gnu style build

tree from CMake (that is what I have inferred from emails he has addressed to Tim R)?

Eliot has stated that he would be happy to see the cog stuff made properly compatible with everything else and moved to using CMake - but that he has no interest in doing nor time to do the work. I offered a $1000 bounty for anyone (or several) making Cog work with CMake, but nobody appears to have any need for a spare $1000 so far.

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Religious tolerance

On Thu, Apr 10, 2014 at 11:45 AM, gettimothy gettimothy@zoho.com wrote:

Hi Eliot.

...

...

But what I want is for the Cog linux build to use CMake. That is, make

the build directories under http://www.squeakvm.org/svn/squeak/branches/Cog/unixbuild and http://www.squeakvm.org/svn/squeak/branches/Cog/nscogbuild/unixbuild to work, but to use CMake. My current >>build enbvironment is a CentOS 5.3 VM running under Parallels. The most convenient thing for me would be that the builds continue to work on this now rather old CentOS.

I am not familiar with Parallels, but a quick search showed its some sort of virtualization product. Centos is linux for paranoid sys-admins, so I should be good to go there (I have a spare partition where my windows7 blew itself up, so I can install it there if need be)

I have a static ip so I can make my work available for review and comment as it progresses.

sounds good!

cordially,

tty

David.

I am taking Tim up on his bounty offer. Gotta love a chance to contribute, learn something new and interesting and pay the rent.

I want to get get my webcam working today and I will turn my attention to CMake tomorrow.

cheers

tty.

---- On Thu, 10 Apr 2014 11:14:00 -0700 David T. Lewis&lt;lewis@mail.msen.com&gt; wrote ----

&gt; &gt; A couple of questions... &gt; &gt; &gt; 1. Regarding CMake Isn't Eliot migrating more towards a Gnu style build &gt; tree from CMake (that is what I have inferred from emails he has addressed &gt; to Tim R)? &gt;

See Tim's answer. I would love to see someone get the $1000 prize :-)

&gt; &gt; 2. If it is going to be Gnu-ified (which I do prefer) would separate build &gt; trees for 64 bit, 32 bit and 64/32 hybrid build trees make sense for &gt; simplifying and isolating problematic build issues?

Yes, you will want to use different build directories for this.

&gt; (If I may add, for the SqueakSSL, I reduced the source to the &gt; minimum to get the unixbuild to compile and run--AsynchFilePlugin \ &gt; B2DPlugin \ BitBltPlugin \FilePlugin \SocketPlugin &gt; \MiscPrimitivePlugin &gt; and a very slimmed down source tree that is actually easy to &gt; understand--see my blog post: &gt; http://timmydosmalltalk.wordpress.com/2014/04/08/first-take-on-the-minimum-p...) &gt;

If you are working in VMM trunk, try this:

VMMakerTool minimal

Also, the VMMakerTool makes it easy to regenerate just a specific plugin, after which you can just run make again in your build directory.

Dave

Tim,

Thank you.

I have changed the subject line to reflect the project.

I will start reviewing the archives tomorrow and come up with a roadmap. I don't have any projects besides this right now so I can give it my full attention and hopefully get something intuitive, functional and documented in place by end of next week-ish.

Cordially,

tty.

---- On Thu, 10 Apr 2014 12:53:28 -0700 tim Rowledge&lt;tim@rowledge.org&gt; wrote ----

On 10-04-2014, at 11:17 AM, gettimothy &lt;gettimothy@zoho.com&gt; wrote:

&gt; David. &gt; &gt; I am taking Tim up on his bounty offer. Gotta love a chance to contribute, learn something new and interesting and pay the rent.

OK. I’ll be very pleased if something can actually come of this. I’ve had several people claim they were going to solve the problem Real Soon Now but so far nothing. Forgive me if I seem world-weary and cynical but that’s because… I am.

The aim is to get Cog on *nix being built via a mechanism as near as possible to that used for the plain interp in the squeakvm.org trunk tree. Windows &amp; Mac may or may not ever be targets and I don’t care right now.

If you read the archives of the main squeak list and the vm-dev list after searching for all messages with ‘cmake’ in the subject and dating back to last june you’ll find at least 60-some hits. After a quick scan of my local archive I see a variety of suggestions to think about. I note that Ron Teitelbaum wrote that Goran was working on the issue at 3DICC, for example.

The grand aim would be to unify things so well that Eliot throws off the chains of keeping a virtual fork and starts using the main trunk since it is so easy to do. I suspect that might be more work than can be done in a few weeks even. What *I* would be happy with would be a checkout that works on my Pi, produces a working stackvm, matches the trunk cmake setup as closely as possible and is clearly documented so it can be further developed towards the Grand Aim.

tim

tty,

On 10.04.2014, at 22:02, gettimothy gettimothy@zoho.com wrote:

Tim,

Thank you.

I have changed the subject line to reflect the project.

I will start reviewing the archives tomorrow and come up with a roadmap. I don't have any projects besides this right now so I can give it my full attention and hopefully get something intuitive, functional and documented in place by end of next week-ish.

Cordially,

Steal what you want from https://github.com/krono/self/tree/master/vm/cmake

;)

best -Tobias

While we are at it: Linux is not a UNIX. Even if we are putting it under the UNIX umbrella, it is not the only UNIX.

I am trying to get Squeak/Pharo to run under Solaris (OpenSolaris) with some trouble. But also BSD folks have difficulties because UNIX == Linux in the view of the Squeak VM. While my first try with recent SqueakVM sources wasn’t successful (I got "DosFileDirectory(Object)>>doesNotUnderstand: #pathFromURI:“ from the provided image), I was able to build a recent pharovm after I manipulated the image in order to get the vm-sound-Sun module instead of the hard coded vm-sound-ALSA for the UNIX platform. I got everything compiled but the resulting binary stuck after showing the complete graphics with no reactions to mouse or keyboard events. I found out that inside the aioPoll function the call to select() always returns 0. Because of my limited spare time I didn’t get further yet.

So, please consider not only the 3 major platforms (Windows, Mac OS, Linux) when doing the great work on the VM.

Best regards Andreas

Am 10.04.2014 um 21:53 schrieb tim Rowledge tim@rowledge.org:

On 10-04-2014, at 11:17 AM, gettimothy gettimothy@zoho.com wrote:

...

David.

I am taking Tim up on his bounty offer. Gotta love a chance to contribute, learn something new and interesting and pay the rent.

OK. I’ll be very pleased if something can actually come of this. I’ve had several people claim they were going to solve the problem Real Soon Now but so far nothing. Forgive me if I seem world-weary and cynical but that’s because… I am.

The aim is to get Cog on *nix being built via a mechanism as near as possible to that used for the plain interp in the squeakvm.org trunk tree. Windows & Mac may or may not ever be targets and I don’t care right now.

If you read the archives of the main squeak list and the vm-dev list after searching for all messages with ‘cmake’ in the subject and dating back to last june you’ll find at least 60-some hits. After a quick scan of my local archive I see a variety of suggestions to think about. I note that Ron Teitelbaum wrote that Goran was working on the issue at 3DICC, for example.

The grand aim would be to unify things so well that Eliot throws off the chains of keeping a virtual fork and starts using the main trunk since it is so easy to do. I suspect that might be more work than can be done in a few weeks even. What *I* would be happy with would be a checkout that works on my Pi, produces a working stackvm, matches the trunk cmake setup as closely as possible and is clearly documented so it can be further developed towards the Grand Aim.

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RSC: Rewind System Clock

&gt;&gt;Nicolas &gt;&gt;Just one word: please don't forget the work from Pharo team on CMakeVMMaker, it might be a decent starting point.

Absolutely--never underestimate how lazy I can be (: I also have the existing standard interpreter CMake as a model as well. I am going to take the time to study CMake first instead of just modifying and hacking on other's work.

&gt;&gt;Andreas.. &gt;&gt;I am trying to get Squeak/Pharo to run under Solaris (OpenSolaris) with some trouble. But also BSD folks have difficulties because UNIX == Linux in the view of the Squeak VM.

I have considered Open Solaris and FreeBSD for my former dos partition--I don't know if CMake will work on them, but I will investigate. Do you have a link for open solaris? When I checked a few days ago Oracle had branded everything and I prefer to not deal with Ellison if I can.

thx.

tty

Am 10.04.2014 um 22:49 schrieb Colin Putney colin@wiresong.com:

On Thu, Apr 10, 2014 at 3:35 PM, gettimothy gettimothy@zoho.com wrote:

I have considered Open Solaris and FreeBSD for my former dos partition--I don't know if CMake will work on them, but I will investigate. Do you have a link for open solaris? When I checked a few days ago Oracle had branded everything and I prefer to not deal with Ellison if I can.

I did some work a while back to build Cog on SmartOS and OpenIndiana. I got it to compile and run, but the image couldn't do IO or respond to UI events. I've found VirtualBox handy for this sort of thing—you can get ready-made images for many operating systems, which saves installing and configuring a bare-metal installation.

So you got as far as I did. After some thoughts I guess the heart beat Eliot introduced for Cog might be a possible cause of the problem. When I did my first Solaris compilations of the Squeak VM a couple of years ago I had to adjust the signal handler installation. Solaris needs re-registration after a signal has been caught. I will take a look asap.

Regards, Andreas

Hi Andreas, Hi Tty,

On Fri, Apr 11, 2014 at 7:54 AM, Andreas Wacknitz a.wacknitz@gmx.de wrote:

Am 10.04.2014 um 22:49 schrieb Colin Putney colin@wiresong.com:

On Thu, Apr 10, 2014 at 3:35 PM, gettimothy gettimothy@zoho.com wrote:

...

I have considered Open Solaris and FreeBSD for my former dos partition--I don't know if CMake will work on them, but I will investigate. Do you have a link for open solaris? When I checked a few days ago Oracle had branded everything and I prefer to not deal with Ellison if I can.

I did some work a while back to build Cog on SmartOS and OpenIndiana. I got it to compile and run, but the image couldn't do IO or respond to UI events. I've found VirtualBox handy for this sort of thing--you can get ready-made images for many operating systems, which saves installing and configuring a bare-metal installation.

So you got as far as I did. After some thoughts I guess the heart beat Eliot introduced for Cog might be a possible cause of the problem. When I did my first Solaris compilations of the Squeak VM a couple of years ago I had to adjust the signal handler installation. Solaris needs re-registration after a signal has been caught. I will take a look asap.

Noe that the itemer/signal based heartbeat should be viewed as the heartbeat of last resort :-). It has bad effects when integrating with external code, interrupting system calls etc. Unless this external code is written to cope with interrupted calls that can't be restarted such as poll or select, the heartbeat needs to be disabled around calls to the external code.

Instead, the pthread/nanosleep based heartbeat (in platforms/unix/vm/sqUnixHeartbeat.c) is benign but does require multiple thread priorities in pthreads so that the heartbeat thread can run at a higher priority than the VM thread and hence reliably interrupt it.

On 11-04-2014, at 9:02 AM, Eliot Miranda eliot.miranda@gmail.com wrote:

Noe that the itemer/signal based heartbeat should be viewed as the heartbeat of last resort :-). It has bad effects when integrating with external code, interrupting system calls etc. Unless this external code is written to cope with interrupted calls that can't be restarted such as poll or select, the heartbeat needs to be disabled around calls to the external code.

Err, so maybe this is the cause of ALSA sound problems on the Pi with the stackVM? Damn.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A hacker does for love what others would not do for money.

On Sun, Apr 13, 2014 at 9:12 PM, Eliot Miranda eliot.miranda@gmail.comwrote:

On Sat, Apr 12, 2014 at 10:20 AM, tim Rowledge tim@rowledge.org wrote:

...

On 11-04-2014, at 9:02 AM, Eliot Miranda eliot.miranda@gmail.com wrote:

...

Noe that the itemer/signal based heartbeat should be viewed as the

heartbeat of last resort :-). It has bad effects when integrating with external code, interrupting system calls etc. Unless this external code is written to cope with interrupted calls that can't be restarted such as poll or select, the heartbeat needs to be disabled around calls to the external code.

...

Err, so maybe this is the cause of ALSA sound problems on the Pi with the stackVM? Damn.

Could be. But at Qwaq/Teleplace I had the ALSA plugin in the Cog branch working on linux using the itimer heartbeat.

Could be.

...

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A hacker does for love what others would not do for money.

-- best, Eliot

Hi Andreas,

On Sat, Apr 19, 2014 at 2:52 PM, Andreas Wacknitz a.wacknitz@gmx.de wrote:

Hi Eliot,

Today I was able to work on this problem again. Alas heartbeat_handler() in sqUnixTimerHeartbeat.c is not called automatically as it should be. Only if I trigger an external ALRM signal (by means of signal -ALRM <pid>) it’s being called. I wasn’t able to find out how the trigger for it is being set.

Hmmm. In sqUnixTimerHeartbeat.c::ioInitHeartbeat() there's a sigaction call that establishes heartbeat_handle as the handler for SIGALRM. Perhaps on FreeBSD or OpenSolaris you need to rearm the signal handler on each delivery? But perhaps there's a flag you can set in the sigaction that avoids having to do this.

The only place I found a nanosleep() call was in block() in sqUnixMain.c.

See the nanosleep in sqUnixHeartbeat.c::beatStateMachine.

BTW what does with ticker and without ticker mean in respect to the heartbeat?

The Qwaq/Teleplace/Terf VM needs support for sound processing. The ticker is the thread or call that provides cycles for sound processing.

But look, if FreeBSD provides pthreads you should try and use sqUnixHeartbeat.c instead of sqUnixTimerHeartbeat.c.

HTH, Eliot

Best regards, Andreas

Am 11.04.2014 um 18:02 schrieb Eliot Miranda eliot.miranda@gmail.com:

Hi Andreas, Hi Tty,

On Fri, Apr 11, 2014 at 7:54 AM, Andreas Wacknitz a.wacknitz@gmx.dewrote:

...

Am 10.04.2014 um 22:49 schrieb Colin Putney colin@wiresong.com:

On Thu, Apr 10, 2014 at 3:35 PM, gettimothy gettimothy@zoho.com wrote:

...

I have considered Open Solaris and FreeBSD for my former dos partition--I don't know if CMake will work on them, but I will investigate. Do you have a link for open solaris? When I checked a few days ago Oracle had branded everything and I prefer to not deal with Ellison if I can.

I did some work a while back to build Cog on SmartOS and OpenIndiana. I got it to compile and run, but the image couldn't do IO or respond to UI events. I've found VirtualBox handy for this sort of thing—you can get ready-made images for many operating systems, which saves installing and configuring a bare-metal installation.

So you got as far as I did. After some thoughts I guess the heart beat Eliot introduced for Cog might be a possible cause of the problem. When I did my first Solaris compilations of the Squeak VM a couple of years ago I had to adjust the signal handler installation. Solaris needs re-registration after a signal has been caught. I will take a look asap.

Noe that the itemer/signal based heartbeat should be viewed as the heartbeat of last resort :-). It has bad effects when integrating with external code, interrupting system calls etc. Unless this external code is written to cope with interrupted calls that can't be restarted such as poll or select, the heartbeat needs to be disabled around calls to the external code.

Instead, the pthread/nanosleep based heartbeat (in platforms/unix/vm/sqUnixHeartbeat.c) is benign but does require multiple thread priorities in pthreads so that the heartbeat thread can run at a higher priority than the VM thread and hence reliably interrupt it.

-- best, Eliot

On Tue, Apr 22, 2014 at 8:09 AM, Andreas Wacknitz a.wacknitz@gmx.de wrote:

Hi Eliot,

Thanks again for your help.

Am 21.04.2014 um 22:56 schrieb Eliot Miranda eliot.miranda@gmail.com:

Hi Andreas,

On Sat, Apr 19, 2014 at 2:52 PM, Andreas Wacknitz a.wacknitz@gmx.dewrote:

...

Hi Eliot,

Today I was able to work on this problem again. Alas heartbeat_handler() in sqUnixTimerHeartbeat.c is not called automatically as it should be. Only if I trigger an external ALRM signal (by means of signal -ALRM <pid>) it’s being called. I wasn’t able to find out how the trigger for it is being set.

Hmmm. In sqUnixTimerHeartbeat.c::ioInitHeartbeat() there's a sigaction call that establishes heartbeat_handle as the handler for SIGALRM. Perhaps on FreeBSD or OpenSolaris you need to rearm the signal handler on each delivery? But perhaps there's a flag you can set in the sigaction that avoids having to do this.

No, when I trigger SIGALRM from the outside the image works (albeit very slow). First I emitted SIGALRM by means of kill -SIGALRM <pid> from the shell; later I wrote a simple C program to do that for me :)

...

The only place I found a nanosleep() call was in block() in sqUnixMain.c.

See the nanosleep in sqUnixHeartbeat.c::beatStateMachine.

Yeah, I don’t know how I could miss this. I will debug a little bit in order to find out why this doesn’t work as expected on OpenSolaris. After the initial step through heartbeat, there won’t be any heartbeat_handler calls triggered from within the vm…

...

BTW what does with ticker and without ticker mean in respect to the heartbeat?

The Qwaq/Teleplace/Terf VM needs support for sound processing. The ticker is the thread or call that provides cycles for sound processing.

But look, if FreeBSD provides pthreads you should try and use sqUnixHeartbeat.c instead of sqUnixTimerHeartbeat.c.

I already did that yesterday. Alas it’s only working with superuser rights, otherwise I’ll get "pthread_setschedparam failed; consider using ITIMER_HEARTBEAT: Not owner“.

Ah, ok. That was the situation on linux before the 2.6.16 kernel (IIRC). I guess you're stuck with the getitimer heartbeat. So the issue is how to rearm the signal handler. If necessary put a call to signal/sigaction in heartbeat_handler.

I will also investigate further here so maybe I will get this working.

HTH, Eliot

Regards, Andreas

On 10-04-2014, at 1:35 PM, gettimothy gettimothy@zoho.com wrote:

I also have the existing standard interpreter CMake as a model as well. I am going to take the time to study CMake first instead of just modifying and hacking on other's work.

The current plain interp build system must be the model in order to end up with a system that satisfies the need to be able to merge plain and Cog. There are three people that need to be satisfied here; me, Eliot, & Ian.

Learning about CMake is a very good thing to start with...

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: MFC: Mangle Following Command

Am 10.04.2014 um 22:35 schrieb gettimothy gettimothy@zoho.com:

...

...

Nicolas Just one word: please don't forget the work from Pharo team on CMakeVMMaker, it might be a decent starting point.

Absolutely--never underestimate how lazy I can be (: I also have the existing standard interpreter CMake as a model as well. I am going to take the time to study CMake first instead of just modifying and hacking on other's work.

...

...

Andreas.. I am trying to get Squeak/Pharo to run under Solaris (OpenSolaris) with some trouble. But also BSD folks have difficulties because UNIX == Linux in the view of the Squeak VM.

I have considered Open Solaris and FreeBSD for my former dos partition--I don't know if CMake will work on them, but I will investigate. Do you have a link for open solaris? When I checked a few days ago Oracle had branded everything and I prefer to not deal with Ellison if I can.

Yes, alas Solaris is closed-source again after the taker-over by Oracle. Nevertheless there are a couple of derivates from the OpenSolaris, some commercial (like NexentraStor and SmartOS), some free (like openindiana, OpenSXCE, and DilOS). Most of them share Illumos (http://wiki.illumos.org) as a common base. While the commercial derivates typically have specialist usages (e.g. NexentraStor as big, reliable storage solution and SmartOS as a virtualization solution), the free offerings are still more or less general purpose OS's. In my eyes the most promising is openindiana (http://wiki.openindiana.org and for ISO’s: http://dlc.openindiana.org/isos/).

Regards, Andreas

Hi Gustav,

I'm afraid I cannot debug this issue because I just found out that my webcam is not supported by linux. I thought it might work on Ubuntu, but after installing Ubuntu and scratch, no luck.

Cordially

tty