[9fans] /dev/draw and c, rc, ruby, python, go

[9fans] /dev/draw and c, rc, ruby, python, go

[Sergey Kish]

Ruby is my language of choice. It was natural to use it for Plan 9
application development which involves working with dictiories, stacks
and some metaprogramming.

I took fgb/ruby, localized changes, wrote mkfile
https://gist.github.com/912507 And it was ok until I've started
GUI part. It appears that Ruby C extensions are dynamic libraries.
So I can't access libdraw, but why not access /dev/draw directly?

libdraw is a simple wrapper around /dev/draw. It can be implemented
in any language. Unexpected problem appeard rapidly.
I can't reread /dev/draw/ctl

    named-image.rb:26:in `read': Invalid argument - /dev/draw/new
    (Errno::EINVAL) from named-image.rb:26

To check algorithm named imaged retrieval on several
languages was written . All attempts storred on github
https://gist.github.com/912377

C looks clear and works fine. Python and Ruby falls with exception.
Their message construction checked in rc, which works fine. Also
works when opened from rc and accessed in application through /fd/4

	<[4] /dev/draw/new { ruby application.rb }

Today I've implemented same on go. It also falls but it may be my
fault

    error: read /dev/draw/new: unknown id for draw image

What's special about Plan 9 files? Which languages handle them?
How to fix Python and Ruby?
Any help appreciated

Re: [9fans] /dev/draw and c, rc, ruby, python, go

[ron minnich]

Hi, it's me, the repeating person (I almost said "broken record" but
I'm not sure how many people know what that means any more :-)

Suggest you run your command with ratrace

ratrace - whatevercommandyouarerunning

It can be very revealing.

ron

Re: [9fans] /dev/draw and c, rc, ruby, python, go

[Akshat Kumar]

Even on Plan 9 proper (that is, bare hardware?
how about virtualized on qemu or VMWare, etc.)?


ak

On Sun, Apr 10, 2011 at 1:49 PM, ron minnich <rminnich@gmail.com> wrote:
> Hi, it's me, the repeating person (I almost said "broken record" but
> I'm not sure how many people know what that means any more :-)
>
> Suggest you run your command with ratrace
>
> ratrace - whatevercommandyouarerunning
>
> It can be very revealing.
>
> ron
>
>

Re: [9fans] /dev/draw and c, rc, ruby, python, go

[erik quanstrom]

On Tue Apr 12 00:43:59 EDT 2011, akumar@mail.nanosouffle.net wrote:
> Even on Plan 9 proper (that is, bare hardware?
> how about virtualized on qemu or VMWare, etc.)?

ratrace works anywhere plan 9 runs.

- erik

Re: [9fans] /dev/draw and c, rc, ruby, python, go

[Anthony Martin]

Sergey Kish <sergey.kish@gmail.com> once said:
> Today I've implemented same on go. It also falls but it may be my
> fault
>
>     error: read /dev/draw/new: unknown id for draw image

You're giving bad data to devdraw.  The Go code on the gist
is sending

	long(id) 'n' long(id) byte(namelen) string(name)

but that first long will cause the write to fail.  Also,
you should really check the errors from any system call
instead of discarding them.  The error from the read is
a red herring in this case (but still expected because
the named image allocation failed).

Now for the Python and Ruby code, I really have no idea.
I would check to see if their standard library requires
that you flush after writes.

Hope that helps.

  Anthony

Re: [9fans] /dev/draw and c, rc, ruby, python, go

[Anthony Martin]

Another thing to check would be any encoding of the data
passed to a write, i.e., try opening the data file in
binary mode.

  Anthony

Re: [9fans] /dev/draw and c, rc, ruby, python, go

[Sergey Kish]

[-- Attachment #1: Type: text/plain, Size: 563 bytes --]

Thanks! All implementations works now.

A typo fix in Go implementation was not enough.  You can't write
message by parts, have to form it in buffer before writing.

ratrace helped to find problem with Ruby/Python implementations.
https://gist.github.com/912377#file_ratrace.log shows that both
writes to data after reading ctl. Fixed with a flush call.

> Also, you should really check the errors from any system call
> instead of discarding them.
It may be good in production, but in development I want program crash
as loud and quick as possible.

[-- Attachment #2: Type: text/html, Size: 810 bytes --]