Problem with Arch Linux and Cog

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

Problem with Arch Linux and Cog

Robert Sirois
I've been trying to work around this problem, but it can't be ignored now. I've also noticed that any exceptions thrown in the image cause a crash as well.

Was there any solution, or is the solution to not use Arch Linux?

Related to this thread:

http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033009.html
http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033361.html

Thanks,
RS
Reply | Threaded
Open this post in threaded view
|

Re: Problem with Arch Linux and Cog

Schwab,Wilhelm K
You've clearly done the first thing I was going to recommend, which was to run Pharo from a terminal to capture any diagnostic output.

The next step would be strace, which might reveal the vm's thoughts.  Use either the -o option or redirect standard error to a file; strace writes nothing to stdout - you've been warned :)   Once you get the output, it will be verbose, but grep is your friend in that case.  You probably know this, something like

   cat strace-log.txt | grep uuid

could be revealing.  It might show where Cog thinks the library lives.  It's ugly, but if you know where Cog insists on looking, then you can put symlink there and *maybe* get going.  I just hit the problem I am describing (and suspect could be ailing you) on Ubuntu and hacked around it that way. Thanks to Nick for the strace pointer.

If you are not sure if/where the UUID library lives, you can try the locate command, or otherwise scrounge around.  If the library is not on the machine, that might be the problem.

HTH.

Bill




From: [hidden email] [[hidden email]] on behalf of Robert Sirois [[hidden email]]
Sent: Tuesday, January 10, 2012 10:20 PM
To: [hidden email]
Subject: [Pharo-project] Problem with Arch Linux and Cog

I've been trying to work around this problem, but it can't be ignored now. I've also noticed that any exceptions thrown in the image cause a crash as well.

Was there any solution, or is the solution to not use Arch Linux?

Related to this thread:

http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033009.html
http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033361.html

Thanks,
RS
Reply | Threaded
Open this post in threaded view
|

Re: Problem with Arch Linux and Cog

mmimica
In reply to this post by Robert Sirois
This is what you get for trying to make a binary that just works on any x86 Linux distribution. It won't work. Vendors don't like it, Linus doesn't like it, RMS hates it :) The proper fix to all of this problems would be to provide distribution specific packages. I know that's a lot more of work and many more people should be involved into this, but how hard can it be? Any piece of software aimed to linux has packages for most popular distributions, so it is doable. And once you provide a decent package, vendors may take over it and make it official and maintain it for you.
I could do the Slackware package.

PS. I do love on-click paradigm. Too bad it doesn't work.


On 11 January 2012 04:20, Robert Sirois <[hidden email]> wrote:
I've been trying to work around this problem, but it can't be ignored now. I've also noticed that any exceptions thrown in the image cause a crash as well.

Was there any solution, or is the solution to not use Arch Linux?

Related to this thread:

http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033361.html

Thanks,
RS



--
Milan Mimica
http://sparklet.sf.net
Reply | Threaded
Open this post in threaded view
|

Re: Problem with Arch Linux and Cog

Stéphane Ducasse

On Jan 11, 2012, at 12:25 PM, Milan Mimica wrote:

> This is what you get for trying to make a binary that just works on any x86 Linux distribution. It won't work. Vendors don't like it, Linus doesn't like it, RMS hates it :) The proper fix to all of this problems would be to provide distribution specific packages. I know that's a lot more of work and many more people should be involved into this, but how hard can it be? Any piece of software aimed to linux has packages for most popular distributions, so it is doable. And once you provide a decent package, vendors may take over it and make it official and maintain it for you.
> I could do the Slackware package.


excellent
what we should do is that the package is automatically created using jenkins.

>
> PS. I do love on-click paradigm. Too bad it doesn't work.
>
>
> On 11 January 2012 04:20, Robert Sirois <[hidden email]> wrote:
> I've been trying to work around this problem, but it can't be ignored now. I've also noticed that any exceptions thrown in the image cause a crash as well.
>
> Was there any solution, or is the solution to not use Arch Linux?
>
> Related to this thread:
>
> http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033009.html
> http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033361.html
>
> Thanks,
> RS
>
>
>
> --
> Milan Mimica
> http://sparklet.sf.net


Reply | Threaded
Open this post in threaded view
|

Re: Problem with Arch Linux and Cog

laurent laffont
For ArchLinux  as a starting point I've seen there's a  squeakvm package in AUR https://aur.archlinux.org/packages.php?ID=44187 

Laurent

On Wed, Jan 11, 2012 at 1:25 PM, Stéphane Ducasse <[hidden email]> wrote:

On Jan 11, 2012, at 12:25 PM, Milan Mimica wrote:

> This is what you get for trying to make a binary that just works on any x86 Linux distribution. It won't work. Vendors don't like it, Linus doesn't like it, RMS hates it :) The proper fix to all of this problems would be to provide distribution specific packages. I know that's a lot more of work and many more people should be involved into this, but how hard can it be? Any piece of software aimed to linux has packages for most popular distributions, so it is doable. And once you provide a decent package, vendors may take over it and make it official and maintain it for you.
> I could do the Slackware package.


excellent
what we should do is that the package is automatically created using jenkins.

>
> PS. I do love on-click paradigm. Too bad it doesn't work.
>
>
> On 11 January 2012 04:20, Robert Sirois <[hidden email]> wrote:
> I've been trying to work around this problem, but it can't be ignored now. I've also noticed that any exceptions thrown in the image cause a crash as well.
>
> Was there any solution, or is the solution to not use Arch Linux?
>
> Related to this thread:
>
> http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033009.html
> http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033361.html
>
> Thanks,
> RS
>
>
>
> --
> Milan Mimica
> http://sparklet.sf.net



Reply | Threaded
Open this post in threaded view
|

Re: Problem with Arch Linux and Cog

laza
In reply to this post by mmimica
2012/1/11 Milan Mimica <[hidden email]>
>
> The proper fix to all of this problems would be to provide distribution specific packages. I know that's a lot more of work and many more people should be involved into this, but how hard can it be? Any piece of software aimed to linux has packages for most popular distributions, so it is doable.

Sure! Please note that Ian Piumarta, the maintainer of the original
(stack) VM for unix did provide packages for RedHat and Debian systems
early on. There are still packages for the latest VM for RedHat/Suse?
on [1].
I think Matej Kosik, José Luis Redrejo and others took the labor of
building a license clean squeak-vm packages, which got accepted by
Debian [3] and Ubuntu [4]. I'm not sure about their current status and
do not know about other distributions.

I don't think that projects like the linux kernel, gnome or whatever
all build packages for every linux distribution that's out there. It's
true that there is a different demand after the linux kernel than
after the squeak-vm. But we still have limited resources and can only
hope that squeak/pharo/cuis keeps attracting people, so that they get
included in some distributions.

The cog VM might be the standard VM inside the pharo/cuis/squeak
communities, but it's still experimental and only for x86. So there is
the question how to integrate the cog vm/stack vm both into eg. the
debian distribution that is also targeting amd64, mips, mipsel,
powerpc, s390, s390x, sh4. You can't just provide a new squeak-vm
package that contains the latest cog vm.

Alex

[1] http://www.squeakvm.org/unix/
[2] http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-March/126624.html
[3] http://packages.debian.org/de/sid/squeak-vm
[4] http://packages.ubuntu.com/hardy/squeak-vm

Reply | Threaded
Open this post in threaded view
|

Re: Problem with Arch Linux and Cog

Robert Sirois
In reply to this post by Schwab,Wilhelm K
Thanks for the response (everyone). Wilhelm, I appreciate your confidence in my skills as a programmer ;) but this type of debugging is a little beyond me. I may take this information and have someone locally help me out if possible.

In the meantime, I have two other questions:

1) Is Pharo still deployable on Squeak. I guess for some reason I assumed it was only deployable with a Cog vm now, perhaps I misled myself?
and 2) Are there any distributions of Linux that are true and tested, so to speak, with Pharo/Cog?

Thanks!
RS


From: [hidden email]
To: [hidden email]
Date: Wed, 11 Jan 2012 03:47:05 +0000
Subject: Re: [Pharo-project] Problem with Arch Linux and Cog

You've clearly done the first thing I was going to recommend, which was to run Pharo from a terminal to capture any diagnostic output.

The next step would be strace, which might reveal the vm's thoughts.  Use either the -o option or redirect standard error to a file; strace writes nothing to stdout - you've been warned :)   Once you get the output, it will be verbose, but grep is your friend in that case.  You probably know this, something like

   cat strace-log.txt | grep uuid

could be revealing.  It might show where Cog thinks the library lives.  It's ugly, but if you know where Cog insists on looking, then you can put symlink there and *maybe* get going.  I just hit the problem I am describing (and suspect could be ailing you) on Ubuntu and hacked around it that way. Thanks to Nick for the strace pointer.

If you are not sure if/where the UUID library lives, you can try the locate command, or otherwise scrounge around.  If the library is not on the machine, that might be the problem.

HTH.

Bill




From: [hidden email] [[hidden email]] on behalf of Robert Sirois [[hidden email]]
Sent: Tuesday, January 10, 2012 10:20 PM
To: [hidden email]
Subject: [Pharo-project] Problem with Arch Linux and Cog

I've been trying to work around this problem, but it can't be ignored now. I've also noticed that any exceptions thrown in the image cause a crash as well.

Was there any solution, or is the solution to not use Arch Linux?

Related to this thread:

http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033009.html
http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033361.html

Thanks,
RS
Reply | Threaded
Open this post in threaded view
|

Re: Problem with Arch Linux and Cog

Schwab,Wilhelm K
RS,

I didn't want to presume to tutor you on what might be basics to you.  With lots of "jumping in at the deep end" and no small amount of help from people like Nick, I've come a long way in my understanding of Linux, but I'm still not a master of the art.  If something I said is unclear, feel free to ask.

(1) Partial answer: I am still using 1.1.1 for most work; it runs happily on Ian's VM (http://squeakvm.org/unix/).  It's worth a try.

(2) that's a very good question.  The answer is probably no, but I'd be happy to be shown wrong.  I like Ubuntu, but they offer either chaos (six month releases) or near stagnation (the LTS releases).  Something in between would be nice.  A few years ago, I met some very enthusiastic Mandriva users.  On Ubuntu, a compromise is to use an LTS release and alternate repositories; I recently brought my R installation forward a couple of years using one.  I am not at all happy about Unity/Gnome-3 changes that are brewing, so I am looking for good alternatives.

Re your current situation, I do not argue with those saying that binaries on Linux can be a poor mix.  I do, however, think that library search paths are a VERY likely explanation for your troubles.  Certainly, it should be ruled out as a cause, and the complete absence of related diagnostic information is a red flag.  Silent failures have been a fact of life on Squeak from the early days, and I have never understood why it has been tolerated; we all suffer from it.  Sig's plan to move the search logic into the image would be a huge boost, because we could both adapt it as needed, and (more importantly) see what is happening w/o the need for external tools.

Give strace a try.  *IF* the UUID library is being sought in all the wrong places, a symlink **might** get you going.  I say that because I just went through the exercise on Ubuntu.  Let me know if I can help sort out how to use the tools in question.  Apologies in advance for any time you waste following my advice; but, at a minimum, exploring the failure would give you experience with tools that will be helpful "next time."

Bill




From: [hidden email] [[hidden email]] on behalf of Robert Sirois [[hidden email]]
Sent: Thursday, January 12, 2012 10:11 AM
To: [hidden email]
Subject: Re: [Pharo-project] Problem with Arch Linux and Cog

Thanks for the response (everyone). Wilhelm, I appreciate your confidence in my skills as a programmer ;) but this type of debugging is a little beyond me. I may take this information and have someone locally help me out if possible.

In the meantime, I have two other questions:

1) Is Pharo still deployable on Squeak. I guess for some reason I assumed it was only deployable with a Cog vm now, perhaps I misled myself?
and 2) Are there any distributions of Linux that are true and tested, so to speak, with Pharo/Cog?

Thanks!
RS


From: [hidden email]
To: [hidden email]
Date: Wed, 11 Jan 2012 03:47:05 +0000
Subject: Re: [Pharo-project] Problem with Arch Linux and Cog

You've clearly done the first thing I was going to recommend, which was to run Pharo from a terminal to capture any diagnostic output.

The next step would be strace, which might reveal the vm's thoughts.  Use either the -o option or redirect standard error to a file; strace writes nothing to stdout - you've been warned :)   Once you get the output, it will be verbose, but grep is your friend in that case.  You probably know this, something like

   cat strace-log.txt | grep uuid

could be revealing.  It might show where Cog thinks the library lives.  It's ugly, but if you know where Cog insists on looking, then you can put symlink there and *maybe* get going.  I just hit the problem I am describing (and suspect could be ailing you) on Ubuntu and hacked around it that way. Thanks to Nick for the strace pointer.

If you are not sure if/where the UUID library lives, you can try the locate command, or otherwise scrounge around.  If the library is not on the machine, that might be the problem.

HTH.

Bill




From: [hidden email] [[hidden email]] on behalf of Robert Sirois [[hidden email]]
Sent: Tuesday, January 10, 2012 10:20 PM
To: [hidden email]
Subject: [Pharo-project] Problem with Arch Linux and Cog

I've been trying to work around this problem, but it can't be ignored now. I've also noticed that any exceptions thrown in the image cause a crash as well.

Was there any solution, or is the solution to not use Arch Linux?

Related to this thread:

http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033009.html
http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033361.html

Thanks,
RS