headers
Chad Dougherty | 7 Jan 2005 22:40

irritating bug

in the process of getting setup to try some of the things on caerwyn's
blog, I ran into a problem that's almost certainly a bug either in
mk, bufio, or even emu itself.

I grabbed caerwyn's src,
(http://home.comcast.net/~caerwyn/caerwyn.arch.gz), installed it,
and then followed his build instructions in doc/NOTES.

at a random point in the mk install, mk hangs and there's a
bufio thread from mk that appears to be wedged.  ps shows:

     524       30        crd    0:00.0    release   193K Mk[$Sys]
     545       30        crd    0:00.0    release   202K Bufio[$Sys]

I can debug the bufio thread, and the stack trace ends in

	readchunk	 bufio.b:79.5, 48

I can kill the bufio thread and restart mk, but it never finishes
all the way through no matter how many times I do this.  since it
happens at random points in the process, I thought it might be some
bad interaction between emu and the host os's filesystem.  this
first happened to me on the macosx platform, but I was able to
duplicate the problem on both a linux system and a freebsd system.
my plan9 system did not have the problem.  all the systems were
running the 20041217 release, but I recall having the same problem
with the 20040905 release (at least on macosx) as well.

has anyone else seen this?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Chad Dougherty | 8 Jan 2005 03:33

Re: irritating bug

On Fri, Jan 07, 2005 at 11:17:35PM +0000, C H Forsyth wrote:
> the full stack trace would be useful; stack -v mk_pid might do
> 

oh yeah, I forgot about stack(1).  I had been trying to figure out
a way to save the output of the wm/deb stack window to a file. duh.

% stack -v -p /dis /usr/crd/debug 49
unknown fn() Module $Sys PC 606421
wait() mk.b:588.5, 39
        status=[0] ""
        buf=[192]  <at> 79d6c8
        s=[0] ""
        n=40
waitfor(msg=[64]  <at> 77ce28) os.b:173.13, 19
        pid=7984824
        wm=nil
waitup(echildok=1, retstatus=nil) run.b:118.1, 19
        pid=-1
        buf=[64]  <at> 77ce28
        n=nil
        p=nil
        bp=nil
        j=nil
        slot=0
        w=nil
        uarg=0
        done=0
        e=nil
        s=nil
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alexander Sychev | 11 Jan 2005 14:22
Picon

Linux framebuffer support

Hi, all!

I implemented Linux framebuffer support for Inferno emu.
Now Inferno emu can be used on Linux without X Window.
I hope this will help to use Inferno emu on handheld devices such as  
HP/Compaq iPaq or Sharp Zaurus.

What was done:
  RGB16, RGB24 and XRGB32 color schemes support;
  ps2  and intelli-  mice support;
  generic keyboard support.

I tested a new version of emu on Gentoo Linux with kernel 2.6.9 kernel and  
glibc 2.3.4  on a test computer with  Intel Pentium III 667Mhz processor,  
128Mb of RAM, Matrox G400 videocard,  101-buttons keyboard and Logitech  
USB mouse with three buttons.

--

-- 
Best regards,
   santucco
Attachment (inferno.tar.bz2): application/bzip2, 19 KiB
Permalink | Reply | 0 comments |
headers
Ronald G. Minnich | 11 Jan 2005 18:33

Re: [9fans] Summer Internship Opportunity


On Tue, 11 Jan 2005, Eric Van Hensbergen wrote:

> I'm pitching several Plan 9 related ideas for summer internship projects
> at our lab.  Projects would definately involve working with 9P,
> hypervisors, v9fs, and doing operating systems work.  Internships here
> typically run for 3-4 months starting sometime in May and wrapping up by
> September (but this is somewhat flexible).  We'd be looking for graduate
> students with some Plan 9 or Inferno background to fill the positions.  
> If you are interested, send me a resume and/or feel free to ask any
> questions.
> 

hmm, eric, that's a great idea, and so I will pitch one internship too 
here at LANL. 

But: you gotta really know Plan 9, there is no time for on-the-job 
training. The work can be on Plan 9, or on implementing a Plan 9 idea on 
Linux (I would like to have 'cpu' for example, now that we have v9fs).

email to me.

ron
Permalink | Reply | 0 comments |
headers
Eric Van Hensbergen | 11 Jan 2005 18:28
Picon
Gravatar

Summer Internship Opportunity

I'm pitching several Plan 9 related ideas for summer internship
projects at our lab.  Projects would definately involve working with
9P, hypervisors, v9fs, and doing operating systems work.  Internships
here typically run for 3-4 months starting sometime in May and
wrapping up by September (but this is somewhat flexible).   We'd be
looking for graduate students with some Plan 9 or Inferno background
to fill the positions.  If you are interested, send me a resume and/or
feel free to ask any questions.

        Eric Van Hensbergen
         IBM Research: Austin
Permalink | Reply | 0 comments |
headers
Benjamin Huntsman | 12 Jan 2005 23:40

compilers

Just a quick question:
Does anyone know if it would be possible to implement a C compiler in Limbo?  (thought I doubt it would be easy)
 
-Ben
Attachment (winmail.dat): application/ms-tnef, 3162 bytes
Permalink | Reply | 2 comments |
headers
Vladimir Los | 13 Jan 2005 08:27

Re: compilers

As I know it is alredy in the system...
Or it is planned as programming exercise?  :o)

Benjamin Huntsman wrote:
> Just a quick question:
> Does anyone know if it would be possible to implement a C compiler in Limbo?  (thought I doubt it would be easy)
>  
> -Ben
Permalink | Reply | 1 comment |
headers
Alexander Sychev | 13 Jan 2005 12:36
Picon

Linux framebuffer support

I'm terrible sorry, I've just took a new Inferno distribution from the web  
site.
I post an archive with updated sources of Inferno emu with Linux  
framebuffer support.
--

-- 
Best regards,
   santucco
Attachment (inferno.tar.bz2): application/bzip2, 19 KiB
Permalink | Reply | 1 comment |
headers
Vladimir Los | 13 Jan 2005 12:37

Re: compilers

By the way Active Oberon in Blubottle is purely compiled language (with 
GC and original multytasking language support)...

C H Forsyth wrote:

> there was some discussion many years ago about doing a
> C compiler for Inferno.  i suppose it might have been bootstrapped,
> although at the time i'd assumed it would all have been in Limbo.
> ritchie discussed it briefly on an inferno list or 9fans.
> you can probably find a longer discussion about it through google.
> one observation was that C pointers become Dis arrays,
> another is that the result is a strict implementation of C,
> conforming to ANSI but not necessarily to hackers expectations.
> 
> i did once think of doing versions of the native os linkers (5l etc)
> in Limbo, because that would allow a native system to relink itself
> without having to have a hosted environment elsewhere.
> i poked at it a bit but didn't do it in the end.
> i always have far more things i can think of doing than time to do them.
> i only just got back to USB after a gap of nearly 7 years
> (to judge from copyright dates).
>
Permalink | Reply | 0 comments |
headers
Vladimir Los | 13 Jan 2005 12:36

Re: compilers

I think there is no sense to develop C for Inferno. There is one 
successful sample of creating whole system without even one assembler 
line. Only using a high level language similar to Limbo in paradigms and 
ideology. I mean Active Oberon (bluebottle.ethz.ch) and I haven't any 
problem to use it for low level tasks (and especially for multitasking)...

It was very interesting to see additionals into Limbo (exceptions and 
parametrization). I need these things in Active Oberon very much! Many 
approaches and decisions could be simplier to implement... and to 
undersatnd of course... :o)

C H Forsyth wrote:
> there was some discussion many years ago about doing a
> C compiler for Inferno.  i suppose it might have been bootstrapped,
> although at the time i'd assumed it would all have been in Limbo.
> ritchie discussed it briefly on an inferno list or 9fans.
> you can probably find a longer discussion about it through google.
> one observation was that C pointers become Dis arrays,
> another is that the result is a strict implementation of C,
> conforming to ANSI but not necessarily to hackers expectations.
> 
> i did once think of doing versions of the native os linkers (5l etc)
> in Limbo, because that would allow a native system to relink itself
> without having to have a hosted environment elsewhere.
> i poked at it a bit but didn't do it in the end.
> i always have far more things i can think of doing than time to do them.
> i only just got back to USB after a gap of nearly 7 years
> (to judge from copyright dates).
(Continue reading)

Permalink | Reply | 0 comments |

Gmane