[Caml-list] Unix.file_descr -> int ???

[Caml-list] Unix.file_descr -> int ???

[Max Kirillov]

Hello.

Suddently, I'm unable to recover file descriptor from Unix's
file_descr. At least, Unix module does not contain any
function doing that and the type is abstract.

What was a reason for the limitaion?
Is there some way (apart from hacking ocaml) to do that?

Max.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unix.file_descr -> int ???

[Bruno.Verlyck]

   Date: Tue, 11 Jun 2002 21:31:59 +0700
   From: Max Kirillov <max630@mail.ru>

   Suddently, I'm unable to recover file descriptor from Unix's file_descr.  At
   least, Unix module does not contain any function doing that and the type is
   abstract.

   What was a reason for the limitation?
Xavier answered this some years ago; see
 http://caml.inria.fr/archives/199703/msg00009.html

   Is there some way (apart from hacking ocaml) to do that?
You can use Cash (http://pauillac.inria.fr/cash).  It has all the
machinery you may want to do that.  This machinery is not that light,
and this comforts Xavier's choice (IMO).

Bruno.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unix.file_descr -> int ???

[Xavier Leroy]

> Suddently, I'm unable to recover file descriptor from Unix's
> file_descr. At least, Unix module does not contain any
> function doing that and the type is abstract.
> What was a reason for the limitaion?

Well, because file descriptors are an abstract data type.  
What makes you think that they are integers?  None of the integer
operations make any sense on file descriptors, e.g. adding or
multiplying two file descriptors.

It is true that under Unix, file descriptors happen to be implemented
as integers, but that's purely accidental.  E.g. under Windows,
Unix.file_descr is not implemented by integers.

> Is there some way (apart from hacking ocaml) to do that?

Within well-typed code, no.  With typing hacks, yes.  But what would
you want to do this?

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unix.file_descr -> int ???

[Max Kirillov]

Hello.

I was trying to trace a code with some significant amount of
select'ed fds. At some point, I faced the fact that I just
have no way to "show" a descriptor value. That was a real
shock. At the moment, the bug is found and fixed
deductively, but the question remains.

I know almost nothing about win32, but I was very surprised
to discover that win32 has functions, isomorphic to
low-level unix calls. However, I suspect (I don't have win32
headers to look in just now) that HANDLE is again a
"typedef" of intteger.

The abstraction is good for a higher-level portable api,
which would use posix or win32 functions in background,
depending on platform. I thought it to be a function
"open_connection" and so on. Now I'm happy to see that usual
"unix" functions would work well in win32.

Anyway, any meaningful type barrier is good. Maybe the
discussed too. But, since we all know that file_descr and
dir_handle are integers, could it be worthwhile to have
functions *_of_int and int_of_*?

Max.

On Tue, Jun 11, 2002 at 05:45:27PM +0200, Xavier Leroy wrote:
<...>
> Well, because file descriptors are an abstract data type.  
> What makes you think that they are integers?  None of the integer
> operations make any sense on file descriptors, e.g. adding or
> multiplying two file descriptors.
> 
> It is true that under Unix, file descriptors happen to be implemented
> as integers, but that's purely accidental.  E.g. under Windows,
> Unix.file_descr is not implemented by integers.
<...>
> - Xavier Leroy
> -------------------
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unix.file_descr -> int ???

[Berke Durak]

On Wed, Jun 12, 2002 at 02:26:11AM +0700, Max Kirillov wrote:
> Hello.
> 
...
> Anyway, any meaningful type barrier is good. Maybe the
> discussed too. But, since we all know that file_descr and
> dir_handle are integers, could it be worthwhile to have
> functions *_of_int and int_of_*?
> 
> Max.

Hi

A file_descr_of_int function might seem meaningless at first, but with
inheritance of descriptors under Unix, some programs are intended to
be executed with a particular file descriptor configuration, eg. fd 3
is data stream, fd 4 is control, etc. OK, under Linux or BSD you can open
/proc/fd/xx or /fd/xx, but that's not really standard.

For the other direction, I'd suggest a "name_of_file_descr" function,
which, given a file descriptor, gives a platform-dependent string, for
debugging purposes. Under Unix, it could return the FD in decimal
format ; under other OSes, it could return a hexadecimal pointer
value.
--
Berke Durak
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unix.file_descr -> int ???

[Jacques Garrigue]

From: Max Kirillov <max630@mail.ru>

> I was trying to trace a code with some significant amount of
> select'ed fds. At some point, I faced the fact that I just
> have no way to "show" a descriptor value. That was a real
> shock. At the moment, the bug is found and fixed
> deductively, but the question remains.

If your goal is debugging, then you can dump the value in this way.
Note that this is safe (we check the data representation before
dumping), but system dependent.

Unix version:

let dump_fd (h : Unix.file_descr) =
  let obj = Obj.repr h in
  if Obj.is_int h then string_of_int (Obj.obj obj)
  else invalid_arg "dump_fd"

Windows version:

let dump_handle (h : Unix.file_descr) =
  let obj = Obj.repr h in
  if Obj.is_block obj && Obj.tag obj = Obj.custom_tag then
    Nativeint.format "%x" (Obj.obj obj)
  else invalid_arg "dump_handle"

> I know almost nothing about win32, but I was very surprised
> to discover that win32 has functions, isomorphic to
> low-level unix calls. However, I suspect (I don't have win32
> headers to look in just now) that HANDLE is again a
> "typedef" of intteger.

As you can see, win32 fd's have to be handled differently.
One reason is that caml fits both HANDLE and SOCKET in the same
abstract datatype.  But even HANDLE is not an int, it is a long, and
you cannot be sure it would fit in an ocaml int, so you would need a
nativeint anyway.

> Anyway, any meaningful type barrier is good. Maybe the
> discussed too. But, since we all know that file_descr and
> dir_handle are integers, could it be worthwhile to have
> functions *_of_int and int_of_*?

If it's okay to be unix specific, then something like that could do
the job.
let file_descr_of_int n =
  let fd : Unix.file_descr = Obj.magic (n : int) in
  try Unix.close (Unix.dup fd); fd
  with _ -> invalid_arg "file_descr_of_int"

However, I would not take any responsibility for problems with this
code.

On windows it's more painful. For this kind of use it might be more
reasonable to use a windows specific library, as not all notions can
be mapped to unix ones.

        Jacques Garrigue

P.S. The above uses of Obj.obj and Obj.magic are in some way legal, as
they are just breaking an abstraction barrier. But any error in the
code can still get you a segmentation fault...
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Ocaml debugging (Was [Caml-list] Unix.file_descr -> int ???)

[Mattias Waldau]

> I was trying to trace a code with some significant amount of 
> select'ed fds. At some point, I faced the fact that I just 
> have no way to "show" a descriptor value. That was a real 
> shock. At the moment, the bug is found and fixed deductively, 
> but the question remains.

This raises the issue with debugging in Ocaml and printing the
contents of variables.

ocamldebug is very good, and if you sprinkle your code with asserts, 
and use the backwards stepping function, you find almost all your
bugs within minutes.

However, this only works if you don't use signatures and objects.
Therefor, I do not use them! 

It would really be an improved to O'Caml if 
- Functions can be called in the debugger
- The signatures can be by-passed (so that you can see all
  elements in your Set)
- instance variables can be shown.

I know that you can define printers for the debugger, but currently
it is too clumsy. Why is this done by ocamlc (isn't it that what -g
means :-)?
(maybe is should be a camlp-filter, but it must be done automatically,
otherwise very few will use it.)

/mattias

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: Ocaml debugging (Was [Caml-list] Unix.file_descr -> int ???)

[Pixel]

"Mattias Waldau" <mattias.waldau@abc.se> writes:

> ocamldebug is very good, and if you sprinkle your code with asserts, 
> and use the backwards stepping function, you find almost all your
> bugs within minutes.
> 
> However, this only works if you don't use signatures and objects.
> Therefor, I do not use them! 
> 
> It would really be an improved to O'Caml if 
> - Functions can be called in the debugger
> - The signatures can be by-passed (so that you can see all
>   elements in your Set)
> - instance variables can be shown.
> 
> I know that you can define printers for the debugger, but currently
> it is too clumsy. Why is this done by ocamlc (isn't it that what -g
> means :-)?

i totally agree! 

i would also add:

- variables occuring only once are not available in debugger. which is
bad when you debug-develop (add a pattern, debug to see exactly what
is happening, add the body of the pattern)

- polymorphic values are not shown (eg: stepping through "map" only
gives you things like <poly>). I sometimes instantiate some parametric
polymorphism functions to get back debug-ability
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unix.file_descr -> int ???

[Xavier Leroy]

> I was trying to trace a code with some significant amount of
> select'ed fds. At some point, I faced the fact that I just
> have no way to "show" a descriptor value.

OK, if it's just for debugging, and only intended to run under Unix,
you could use the following:

     external int_of_filedesc: Unix.file_descr -> int = "%identity"

> I know almost nothing about win32, but I was very surprised
> to discover that win32 has functions, isomorphic to
> low-level unix calls. However, I suspect (I don't have win32
> headers to look in just now) that HANDLE is again a
> "typedef" of intteger.

Not really.  It's a typedef of void *.  Values of this type look like
small integers, but no guarantees of this kind are given in the Win32
specs.  Moreover, a Unix.file_descr under Windows is not a HANDLE, but
a pair of a HANDLE and a flag saying whether it's a socket or not.

See, we really need type abstraction to hide these details :-)  And
also to catch common errors like confusing the "fd" and "length"
parameters to the read() or write() functions (in C).

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unix.file_descr -> int ???

[Basile STARYNKEVITCH]

>>>>> "Xavier" == Xavier Leroy <xavier.leroy@inria.fr> writes:

 [[citing Max Kirillov <max630@mail.ru> cited by  Bruno.Verlyck@inria.fr]]

    >> Suddently, I'm unable to recover file descriptor from Unix's
    >> file_descr. At least, Unix module does not contain any function
    >> doing that and the type is abstract.  What was a reason for the
    >> limitaion?

    Xavier> Well, because file descriptors are an abstract data type.
    Xavier> What makes you think that they are integers?  None of the
    Xavier> integer operations make any sense on file descriptors,
    Xavier> e.g. adding or multiplying two file descriptors.

    Xavier> It is true that under Unix, file descriptors happen to be
    Xavier> implemented as integers, but that's purely accidental.
    Xavier> E.g. under Windows, Unix.file_descr is not implemented by
    Xavier> integers.

I agree with Xavier that file descriptors are [somehow] an abstract
type. However, in *Unix* (I am talking of Unix only, more precisely
Linux) it is legitimate to pass the file descriptor number to (e.g.) a
child process. Of course adding or substracting file descriptors has
generally no sense [but there are ugly exceptions: imagine a program
whose calling convention requires 2 fds which are guaranteed to be
consecutive numbers]

For example, I will very soon add in my program (opensource GPL-ed,
see www.poesia-filter.org and its CVS repository
PoesiaSoft/PoesiaMonIcap) some code which

1. Create three pipes (using the pipe(2) system call) I O and C

2. Fork(2) a child process

3. in the child process execve(2) a program passing it the file
   descriptors of I (read-end, i.e. the first file descriptor returned
   by pipe) O (write-end, i.e. the second file descriptor returned by
   pipe) and C (read-end). For instance, it may execve a program
   /usr/libexec/poesiafilter/nlp_italian and passes it as arguments
	 arg[0] = "nlp_italian"   
	 arg[1] = "-i"
	 arg[2] = "5"
	 arg[3] = "-o"
	 arg[4] = "7"
	 arg[5] = "-c"
	 arg[6] = "8"
	 arg[7] = "-C"
	 arg[8] = "/etc/poesia/nlp_italian_config"
	 arg[9] is the null pointer
and the 5, 7, and 8 are file descriptors number. This seems a
legitimate use of file descriptors (there are some Unix programs which
does that).

The program (which I call the Poesia monitor) which does this
Unix-pecular stuff is coded in Ocaml. Obviously it requires a
conversion from Unix.file_descr to either integer or strings. If the
child program where coded in Ocaml (and some might be), they will need
a mean to convert a numerical string arguments (like above arg[4] =
"7") to a Unix.file_descr

I think that Ocaml's Unix module should provide all the hooks to do
any Unix programming.

And yes, I know that Unix file descriptors are not really pure or
mathematically elegant. I will even add that the very idea of files
(at least viewed, as in Unix, as a stream of bytes) is debatable. In
an ideal word, we should have orthogonally persistent objects [Curious
readers might look e.g. inside http://www.tunes.org/ for that matter]
and should not deal with dirty things like files. Sadly, the real
world use Unix and Windows :-( sometimes, and use files, sockets,
etc...

We really need something like 
  val ugly_filedescr_of_int: int -> Unix.file_descr
  val ugly_int_of_filedescr: Unix.file_descr -> int

and I'll guess that in practice they both could be (in that very
precise case, for a Unix plateform) defined as Obj.magic suitably
"casted".

The most important debate is: should Ocaml give access to all Unix
ugliness (and dirty tricks)? I think that for pragmatic reasons the
answer should definitely be yes. Ocaml targets not only academia but
also the real world (otherwise, the Ocaml consortium has no sense).

regards


N.B. Any opinions expressed here are only mine, and not of my organization.
N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA.

---------------------------------------------------------------------
Basile STARYNKEVITCH   ----  Commissariat à l Energie Atomique * France
DRT/LIST/DTSI/SLA * CEA/Saclay b.528 (p111f) * 91191 GIF/YVETTE CEDEX 
phone:+33 1,6908.6055; fax: 1,6908.8395 home: 1,4665.4553; mobile: 6,8501.2359
work email: Basile point Starynkevitch at cea point fr 
home email: Basile at Starynkevitch point net

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unix.file_descr -> int ???

[Xavier Leroy]

> [Passing fd numbers as arguments to exec-ed programs]
> This seems a legitimate use of file descriptors (there are some Unix
> programs which does that).

I won't go into POSIX standards to see whether this is legitimate or
not.  Yes, some (very few) Unix programs do this.  I can't help
thinking that it's ugly.

At any rate, if you're into that kind of stuff, Cash is for you:
http://pauillac.inria.fr/cash/

> The most important debate is: should Ocaml give access to all Unix
> ugliness (and dirty tricks)? I think that for pragmatic reasons the
> answer should definitely be yes.

"Pragmatisme, que de crimes commis en ton nom"...  You mean, for
pragmatic reasons, you want ioctl() in Caml?  With its total lack of
typing and portability?

> Ocaml targets not only academia but also the real world 
> (otherwise, the Ocaml consortium has no sense).

WARNING!  Stereotype alert!  So, let's see, according to you, the
virtues of type abstraction should be reserved to academia, while the
"real world" (whatever the #$@%@ this means) is concerned about dirty hacks
and nothing else?  What are you going to tell us next?  Women can't
drive and men can't raise children? :-)

I can assure you that in an "industrial" programming setting,
guaranteeing (some amount of) Unix-Windows source-code portability is
a *lot* more important than the marginal Unix hacks you describe.

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unix.file_descr -> int ???

[Max Kirillov]

On Wed, Jun 12, 2002 at 10:21:02AM +0200, Xavier Leroy wrote:
<...>
> WARNING!  Stereotype alert!  So, let's see, according to you, the
> virtues of type abstraction should be reserved to academia, while the
> "real world" (whatever the #$@%@ this means) is concerned about dirty hacks
> and nothing else?  What are you going to tell us next?  Women can't
> drive and men can't raise children? :-)
> 
> I can assure you that in an "industrial" programming setting,
> guaranteeing (some amount of) Unix-Windows source-code portability is
> a *lot* more important than the marginal Unix hacks you describe.

Why so strong? Unix is Unix, Win32 is Win32. That's
different system, and they both have specific things. Nobody
calls ACL or multi-threaded file storage (or how they
called), or DDE, "marginal Windows hacks". So why do you
call some things "marginal hacks" just because MS didn't
bother to implement them? If you want throw away all of Unix
weirdness, you better should throw away Unix itself, or your
come into risk of turning it into DOS. That's not good to
use under-system just because it's "right way".

I think that there is a lot of things which are not
portable. And there are a lot of progs not intended to be
portable. Btw, Unix module contains tc* functions, with all
their non-potrability. Why did you included them?

If asked, I would say that there should be module IO,
presenting the higher abstraction level for interaction with
the system, and the lower-level modules Unix, Win32, and so
on... The first requires some design, but is better than be
sticked to castrated unix.

Max.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unix.file_descr -> int ???

[Jean-Marc Eber]

Dear Ocaml friends,

> > The most important debate is: should Ocaml give access to all Unix
> > ugliness (and dirty tricks)? I think that for pragmatic reasons the
> > answer should definitely be yes.
>
> "Pragmatisme, que de crimes commis en ton nom"...

Oh Yes !!! :-)

A library that gives access to all Unix tricks would clearly have its place
on the ocaml cdk, or the hump maybe, but...

>
> > Ocaml targets not only academia but also the real world
> > (otherwise, the Ocaml consortium has no sense).

Yes indeed. And as an "industrial user" (+consortium member), I can
only confirm that it does it well (or, more precisely, very well if one
looks
at the restricted resources available at inria on the ocaml project).

We should definitively distinguish clearly between what is _possible_ with
Ocaml (more or less anything, if you agree to use a little bit yourself the
C interface) and what should be included in the _standard_ libraries
(and, by the way, what must then be supported along all versions by the
ocaml team: that's the point) and is therefore provided as "good" ocaml
"practice".

I want to emphasize again here that we, as industrials, are using ocaml not
because of any hacking capacity, but because of the intrinsic quality of
the
language and its implementation _plus_ the _insurance_ that we could, if
necessary, do "dirty" tricks by ourselves (because of source code access).

Clearly, there _are_ "dirty tricks" we, as industrials, are interested in
and
cannot do ourselves, and where we depend on the ocaml team.

An example ?

Targeting the .NET platform with ocaml, as F# seems to show the technical
possibility (or look, at least, for some easy way to interface with this
platform).

No please, please,... no flameware.... :-)

To be clear: I think that the "industrial" users need isn't an endless
extension
of the standard libraries (they cover today many, many needs, I think), but
an easy
integration with the "rest of us" (ole automation, Java, .NET,...).
For us (or, more preciselly, our potential customers), thats really the
_only_
"bottleneck" with ocaml.

>
> I can assure you that in an "industrial" programming setting,
> guaranteeing (some amount of) Unix-Windows source-code portability is
> a *lot* more important than the marginal Unix hacks you describe.
>

Yes. And I insist: a *lot* !

Thanks to the ocaml team for making our industrial "programming experience"
(*)
easier and funny !

Jean-Marc Eber
LexiFi

(*) that's a typical industrial buzzword... which may or may not be
registered by some
company(ies).



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unix.file_descr -> int ???

[Bruno.Verlyck]

   Date: Wed, 12 Jun 2002 09:42:04 +0200
   From: Basile STARYNKEVITCH <basile.starynkevitch@cea.fr>

   For example, I will very soon add in my program (opensource GPL-ed, see
   www.poesia-filter.org and its CVS repository PoesiaSoft/PoesiaMonIcap) some
   code which
   1. Create three pipes (using the pipe(2) system call) I O and C
   2. Fork(2) a child process
   3. in the child process execve(2) a program passing it the file descriptors
      of I (read-end, i.e. the first file descriptor returned by pipe) O
      (write-end, i.e. the second file descriptor returned by pipe) and C
      (read-end). For instance, it may execve a program
      /usr/libexec/poesiafilter/nlp_italian and passes it as arguments
	    arg[0] = "nlp_italian"
	    arg[1] = "-i"
	    arg[2] = "5"
	    arg[3] = "-o"
	    arg[4] = "7"
	    arg[5] = "-c"
	    arg[6] = "8"
	    arg[7] = "-C"
	    arg[8] = "/etc/poesia/nlp_italian_config"
	    arg[9] is the null pointer
   and the 5, 7, and 8 are file descriptors number.  This seems a legitimate
   use of file descriptors (there are some Unix programs which does that).

   The program (which I call the Poesia monitor) which does this Unix-pecular
   stuff is coded in Ocaml.  Obviously it requires a conversion from
   Unix.file_descr to either integer or strings.  If the child program where
   coded in Ocaml (and some might be), they will need a mean to convert a
   numerical string arguments (like above arg[4] = "7") to a Unix.file_descr
Basile,

you should definitely have a look at Cash.  Your programs are exactly of the
kind Cash was made for.  You can easily do everything you told us above, and
more (e.g. here, you use any file_descr attached to your pipe, but don't try to
force it on file descriptor 3), ..

   We really need something like
     val ugly_filedescr_of_int: int -> Unix.file_descr
     val ugly_int_of_filedescr: Unix.file_descr -> int
   and I'll guess that in practice they both could be (in that very precise
   case, for a Unix plateform) defined as Obj.magic suitably "casted".
.. and with a much less ugly interface than this.  Check around `Channel
mapping machinery' in the documentation for detailed explanations.

   The most important debate is: should Ocaml give access to all Unix ugliness
   (and dirty tricks)?
I don't believe the interface has to be ugly.  But then, it can't be as simple
as the one you propose :-).  There's a real abstraction clash between those
little file descriptors and channels, and not only at the typing level.  Cash
brings you a clean bridge between both.

Bruno.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unix.file_descr -> int ???

[John Max Skaller]

Xavier Leroy wrote:

>>Suddently, I'm unable to recover file descriptor from Unix's
>>file_descr. At least, Unix module does not contain any
>>function doing that and the type is abstract.
>>What was a reason for the limitaion?
>>

>But what would
>you want to do this?
>
That has a simple answer: you have an external C function which requires it.

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners