Camera sig fault on 64 bits machines.
Locked
123
123
Re: Camera sig fault on 64 bits machines.
 
|
Just one word: please don't forget the work from Pharo team on CMakeVMMaker, it might be a decent starting point. 2014-04-10 22:20 GMT+02:00 Andreas Wacknitz <[hidden email]>:
|
|
|
>>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. thx. tty |
Re: Camera sig fault on 64 bits machines.
|
|
On Thu, Apr 10, 2014 at 3:35 PM, gettimothy <[hidden email]> wrote:
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.
|
Re: Camera sig fault on 64 bits machines.
|
|
In reply to this post by tty
On 10-04-2014, at 1:35 PM, gettimothy <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: MFC: Mangle Following Command |
|
|
>>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. Sounds good. Cordially, t ---- On Thu, 10 Apr 2014 15:36:53 -0700 tim Rowledge<[hidden email]> wrote ----
|
VM CMake Project (was: Camera sig fault on 64 bits machines.)
|
|
In reply to this post by timrowledge
On Thu, Apr 10, 2014 at 12:53:28PM -0700, tim Rowledge wrote: > > 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. > This is a perfect summary, and all involved will be very happy if it can be achieved. I will only add that if you can make Tim happy with respect to a pi + stackvm + trunk Cmake , then in my view the remaining problems become very managable. So go forth and make Tim happy, and make sure he pays up if you manage to make him smile :-) Dave |
|
|
In reply to this post by tty
On 04/10/14 16:02, gettimothy wrote: > > > > > Tim, > > Thank you. > > I have changed the subject line to reflect the project. > Hi, I think you can get pretty far by simply copying over all the existing cmake stuff. For some things, like vm-* that may be all there is to do. Probably the cmake dir contents will require the most reconciling. This is mostly optimistic somewhat-informed guessing. :) Stu |
|
|
In reply to this post by tty
tty, On 10.04.2014, at 22:02, gettimothy <[hidden email]> 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 |
signature.asc (1K) |
|
Tobias, Thanks. cheers tty tty, |
Re: Camera sig fault on 64 bits machines.
|
|
In reply to this post by tty
Am 10.04.2014 um 22:35 schrieb gettimothy <[hidden email]>: 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 |
Re: Camera sig fault on 64 bits machines.
|
|
In reply to this post by Colin Putney-3
Am 10.04.2014 um 22:49 schrieb Colin Putney <[hidden email]>:
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, I found OpenIndiana last night and messed around with the installer this early a.m. (did not find my usb mouse, so I could not use it immediatly). I too have an interest in niche machines like Solaris and BSD, so I will return to this as I find it interesting. That said, I am turning my attention to CMAKE and the existing infrastructure. Cordially, tty
|
Re: Camera sig fault on 64 bits machines.
|
|
In reply to this post by Andreas Wacknitz
Hi Andreas, Hi Tty,
On Fri, Apr 11, 2014 at 7:54 AM, Andreas Wacknitz <[hidden email]> 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.
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
|
Re: Camera sig fault on 64 bits machines.
|
|
Am 11.04.2014 um 18:02 schrieb Eliot Miranda <[hidden email]>:
I will have a look at it. Best regards, Andreas |
|
|
In reply to this post by Gustavo Duarte-2
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 |
Re: Camera sig fault on 64 bits machines.
|
|
In reply to this post by Eliot Miranda-2
On 11-04-2014, at 9:02 AM, Eliot Miranda <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim A hacker does for love what others would not do for money. |
Re: Camera sig fault on 64 bits machines.
|
|
On Sat, Apr 12, 2014 at 10:20 AM, tim Rowledge <[hidden email]> wrote:
Could be. A hacker does for love what others would not do for money. best, Eliot
|
Re: Camera sig fault on 64 bits machines.
|
|
On Sun, Apr 13, 2014 at 9:12 PM, Eliot Miranda <[hidden email]> wrote:
Could be. But at Qwaq/Teleplace I had the ALSA plugin in the Cog branch working on linux using the itimer heartbeat.
best, Eliot
|
Re: Camera sig fault on 64 bits machines.
|
|
In reply to this post by Eliot Miranda-2
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. The only place I found a nanosleep() call was in block() in sqUnixMain.c. BTW what does with ticker and without ticker mean in respect to the heartbeat? Best regards, Andreas Am 11.04.2014 um 18:02 schrieb Eliot Miranda <[hidden email]>:
|
Re: Camera sig fault on 64 bits machines.
|
|
Hi Andreas,
On Sat, Apr 19, 2014 at 2:52 PM, Andreas Wacknitz <[hidden email]> wrote:
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.
See the nanosleep in sqUnixHeartbeat.c::beatStateMachine.
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, Eliot
|
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |