trapping floating-point exceptions on Windows

Hi, I'm learning Limbo by writing toy programs.  I'd like to trap FP exceptions,
which would seem to be possible according to Section 9.16 in _The Limbo
Programming Language_.  But they aren't being trapped.  Here's the source:

implement Traptest;

include "sys.m";
        sys: Sys;
include "draw.m";
        draw: Draw;

Traptest: module
{
        init: fn(ctxt: ref Draw->Context, argv: list of string);
};

init(nil: ref Draw->Context, nil: list of string)
{
        sys = load Sys Sys->PATH;

        num := 1.0;
        while (num > 0.0) {
                { num *= 1E50; }
                exception {
                * =>
                        sys->print("exception!\n");
                        num = 0.0;
                }
                sys->print("%g\n", num);
        }

Re: trapping floating-point exceptions on Windows

it looks as though inferno.zip predates a change (to emu/Nt/os.c)
that might be needed in your case. i'll remake inferno.zip.

Linux framebuffer support patch on bitbucket.org

Hello!

Now, after almost seven years, I have found a time to make a public  
repository for linux framebuffer support sources.

bitbucket.org/santucco/inferno-fb

I have checked it on latest inferno-os sources, it works for me.

--

-- 
Best regards,
   santucco

Re: Linux framebuffer support patch on bitbucket.org

Oh ! Thanks ! :) Someone uses it in android version of inferno.

2011/10/10 Alexander Sychev <santucco@...>:
> Hello!
>
> Now, after almost seven years, I have found a time to make a public
> repository for linux framebuffer support sources.
>
> bitbucket.org/santucco/inferno-fb
>
> I have checked it on latest inferno-os sources, it works for me.
>
>
> --
> Best regards,
>  santucco
>

--

-- 
С наилучшими пожеланиями
Жилкин Сергей
With best regards
Zhilkin Sergey

Re: Linux framebuffer support patch on bitbucket.org

Well, at least someone uses it 

On Wed, 12 Oct 2011 15:37:47 +0400, Sergey Zhilkin
<szhilkin@...>  
wrote:

> Oh ! Thanks ! :) Someone uses it in android version of inferno.
>
> 2011/10/10 Alexander Sychev <santucco@...>:
>> Hello!
>>
>> Now, after almost seven years, I have found a time to make a public
>> repository for linux framebuffer support sources.
>>
>> bitbucket.org/santucco/inferno-fb
>>
>> I have checked it on latest inferno-os sources, it works for me.
>>
>>
>> --
>> Best regards,
>>  santucco
>>
>
>
>

--

-- 
Best regards,
   santucco

Re: Linux framebuffer support patch on bitbucket.org

Is there a chance to have it merged into main inferno-os repository?

On 10/10/11 9:58 AM, Alexander Sychev wrote:
> Hello!
> 
> Now, after almost seven years, I have found a time to make a public
> repository for linux framebuffer support sources.
> 
> bitbucket.org/santucco/inferno-fb
> 
> I have checked it on latest inferno-os sources, it works for me.
> 
> 

Re: Linux framebuffer support patch on bitbucket.org

yes

From: Oleksandr Iakovliev <yshurik@...>
Subject: Re: [inferno-list] Linux framebuffer support patch on bitbucket.org
Date: 2011-10-12 18:07:33 GMT

Is there a chance to have it merged into main inferno-os repository?

On 10/10/11 9:58 AM, Alexander Sychev wrote:
> Hello!
> 
> Now, after almost seven years, I have found a time to make a public
> repository for linux framebuffer support sources.
> 
> bitbucket.org/santucco/inferno-fb
> 
> I have checked it on latest inferno-os sources, it works for me.
> 
> 

launchd / Windows NT Services analogue in Inferno

Hello!

I'm estimating Inferno for application server suitability. It looks like a cross between Erlang and Node.js.

I haven't found built-in service facilities. There is Windows Services in Windows NT+ and there is launchd
in Mac OS X (and some Linux distroes).

The service is more than mere autorun. Service should be restarted on fail. Events should be logged.
Stop/restart shouldn't be just kill and re-run. Some entity should process these events as it happens
with launchd.

There seem to be another unresolved questions.

My host OS is currently Mac OS X. I have created two launchd entries for authenticating server and aux server
(running rstyx and httpd). So I can now run emu and communicate with aux server via cpu command. I can run ps,
I can kill a specific process and I can launch it again on an aux server. However, a namespace is clear for
every new cpu invokation. This is a problem since a complicated project would involve several mounted
namespaces (e. g. ircfs) and I might need to remount them without restarting other processes. I need my
commands to be invoked from a single namespace group.

--

-- 
If you want to get to the top, you have to start at the bottom 

Re: Linux framebuffer support patch on bitbucket.org

It is good 

Can I help to integrate the Linux framebuffer code from my side?

On Thu, 13 Oct 2011 01:05:17 +0400, Charles Forsyth  
<forsyth@...> wrote:

> yes

--

-- 
Best regards,
   santucco

Re: launchd / Windows NT Services analogue in Inferno

Hi!

On Fri, Oct 14, 2011 at 02:13:32PM +0700, Левашев Иван wrote:
> The service is more than mere autorun. Service should be restarted on
> fail. Events should be logged. Stop/restart shouldn't be just kill and
> re-run. Some entity should process these events as it happens with
> launchd.

There are two ways to monitor/restart Inferno services - inside Inferno
or outside Inferno. Implementing service monitoring tool similar to
launchd/daemontools/runit in Limbo to monitor services inside Inferno
sounds like native way to go, but in my experience Limbo services work
reliable enough, and both standard Inferno apps and my own apps don't fail
often enough. Most failures crash not just one service but overall Inferno
VM - usually because of out of memory error, or some bug in Inferno itself.
Which makes "native way to go" wrong, and makes better way to go is to use
existing service monitoring tools in host OS. I'm starting all my Inferno
services under `runsvdir/runsv` (from runit) supervision. This gives me
autorun, restart on fail, and ability to add custom hooks on fail/restart.

For logging I use `socklog` (syslog-compatible daemon on custom UNIX
socket) started under same `runsv` supervision together with Inferno
service (while it's possible to log to system's syslog, I prefer to keep
logs of my services separate).

For logging from Inferno services I use syslog-compatible logger
http://code.google.com/p/inferno-contrib-logger/ to write to UNIX socket
provided by `socklog`.

Just in case, to make sure crash of any critical Inferno apps within