[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

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

[Damien Doligez]

>From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>

>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"

This does not work.  You are printing the address of the custom block
that contains the handle, but this address can change during program
execution.

-- Damien
-------------------
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: Damien Doligez <damien.doligez@inria.fr>
> >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"
> 
> This does not work.  You are printing the address of the custom block
> that contains the handle, but this address can change during program
> execution.

Indeed, this is buggy. But you could have given the right answer :-)

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.field obj 1))
  else invalid_arg "dump_handle"

Jacques Garrigue
-------------------
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: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
> From: Damien Doligez <damien.doligez@inria.fr>
> > >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"
> > 
> > This does not work.  You are printing the address of the custom block
> > that contains the handle, but this address can change during program
> > execution.
> 
> Indeed, this is buggy. But you could have given the right answer :-)

What are you making me write!
This code was correct. I have been using it for months in ocamlbrowser
for windows.
nativeint itself is a boxed custom datatype, so outputing it will
correctly output the handle, not the pointer to it. I'm just using the
fact they share the same representation. Actually file_descr has
another field, but we don't need it.

Jacques Garrigue
-------------------
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 ???

[Alessandro Baretta]

I just realize I sent the following message only to 
Jean-Marc Eber, when it was meant to be for the mailing list.

Please excuse me.

Alex
-------- Original Message --------
Subject: Re: [Caml-list] Unix.file_descr -> int ???
Date: Thu, 13 Jun 2002 17:56:42 +0200
From: Alessandro Baretta <alex@baretta.com>
Organization: Baretta srl -- www.baretta.com
To: Jean-Marc Eber <jeanmarc.eber@lexifi.com>

Jean-Marc Eber wrote:
 > 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've heard the CEO of a 170 people  software company
declare: "Our clients don't want no Ocaml stuff! They don't
want no technology. They want *real_world* products on
*real_world* platforms: COBOL and .NET, that's what they want."

No comment. But if Ocaml could somehow "run on .NET", people
like the above CEO (an ex-mathematician and IBM researcher,
by the way) would be a whole lot more interested in Ocaml.

Alex


-------------------
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 ???

[Alessandro Baretta]

Jean-Marc Eber wrote:
> happy that you posted it on the list.
> I didn't want to propose it to you, because I thank you wanted it to
> stay non public.
> JM


Oh, it was definitely meant to be public. It was astonishing 
for me to hear an ex-IBM researcher, a man on science, one 
would imagine, say that his customers are not interested in 
any new or advanced stuff. And I'm pretty sure he knows what 
he's talking about.

How can customers not realize that improvements in the 
production technology necessarily translate to reduced costs 
and improved quality? I'd be willing to pay more for a piece 
of software, if I had a compiler-generated proof that no 
segmentation fault can occur. There is a dose of absurdity 
in all this--although there is some sense, as well.

Xavier, let me ask a dumb question, if you don't mind: how 
do you choose which processor architectures to port ocamlopt 
to? Could .NET simply be regarded as a new "architecture" 
for ocamlopt?

At any rate, I am writing and deploying O'Caml programs. My 
customer has no internal EDP resources, so they are relying 
entirely on me. Of course, they did not ask what language I 
would write the code in. They only care to see it work, and 
they are not disappointed. Long live the Caml!

Alex

-------------------
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]

Alessandro Baretta wrote:

> How can customers not realize that improvements in the production 
> technology necessarily translate to reduced costs and improved quality? 

They don't realise it, because it isn't the case. They're right, in 
general -- meaning,
most of the time. Ocaml is high risk. It is unstable, there are few 
programmers
around, and you can't sue the Ocaml team if something doesn't work.
You can't *demand* a fix by saying 'I paid heaps of money for this
product, you better fix it or I'll sue'.

Of course, the reality is that Ocaml team is more likely
to be responsive. But as a counter-example, I found a bug months
ago that was only recently fixed: I couldn't force the ocaml team
to believe me that there really was a bug in the compiler.
I didn't have an expensive maintenance contract either.
So I have had to use Ocaml 3.01 for ages now. (I'm using
the CVS version now the bug is fixed).

I'm currently working on a project using Python.
The 'boss' is a programmer. We're opting for 1.5.2,
a well recognized, widely installed, stable version.
Yet Python 2.2.1 has major improvements, including
lexical scoping (Heh! functional programming in Python).

Why? Because when it comes to small productivity
improvement (maybe) against risk, management --
even technically aware management -- will chose
to minimise risk every time.

It makes sense. They just need the programs to make
their business run. A small increase in costs is less important
than risking a catastrophy.

To see what it takes to overcome this kind of barrier,
just look at how much money Sun has spent to promote
Java. (Oh dear, what a terrible setback for computing).

BTW: I used Ocaml in a heavy industrial setting ..
but it was for writing a compiler -- something Ocaml is
so very good at.  In this case, the timeframe for, say, a C++
solution would have meant they missed the boat entirely.
So sometimes, superior technology does win --
when the risk seems justified or low.

-- 
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

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

[Xavier Leroy]

> Oh, it was definitely meant to be public. It was astonishing 
> for me to hear an ex-IBM researcher, a man on science, one 
> would imagine, say that his customers are not interested in 
> any new or advanced stuff. And I'm pretty sure he knows what 
> he's talking about.

What's so surprising about this?  This man chose a particular line of
business where customers are not interested in new or advanced stuff.
Just like you could choose to manage a McDonald's and have no
professional interest in gourmet food or fine wines.

I'm not disturbed in the least by the fact that many computer
professionals couldn't care less about what we do.  (And conversely :-)
What I am concerned about is the well-meaning suggestions that we
should move towards "their" technologies in the vague hope that they
will pay more attention then.  They won't.

> They want *real_world* products on
> *real_world* platforms: COBOL and .NET, that's what they want."
> No comment. But if Ocaml could somehow "run on .NET", people
> like the above CEO (an ex-mathematician and IBM researcher,
> by the way) would be a whole lot more interested in Ocaml.

Again, I think this is a fallacy.  By the same logic:

"if OCaml could somehow 'look like COBOL', people like the above CEO 
 would be a lot more interested in OCaml".

"if Bordeaux red wines were carbonated, McDonald's would be a lot more
 interested in selling them".

You can make your own parallels: it's fun :-)

> Xavier, let me ask a dumb question, if you don't mind: how 
> do you choose which processor architectures to port ocamlopt 
> to?

By a combination of demand and availability (of a machine running said
architecture).

> Could .NET simply be regarded as a new "architecture" for ocamlopt?

Not at all.  .NET isn't just a (virtual) machine instruction set: it's
a whole infrastructure, including memory management, data
representation formats, systems services, libraries, etc.  All these
replace (and conflict with) those we have in the OCaml implementation.

Our past experiments in retargeting the OCaml implementation to .Net
failed because of this.  For more details, and an explanation of why
.Net is a real straight-jacket for innovative programming languages,
see a previous post of mine:
        http://caml.inria.fr/archives/200102/msg00190.html

- 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 ???

[Markus Mottl]

On Thu, 20 Jun 2002, Xavier Leroy wrote:
> I'm not disturbed in the least by the fact that many computer
> professionals couldn't care less about what we do.  (And conversely :-)
> What I am concerned about is the well-meaning suggestions that we
> should move towards "their" technologies in the vague hope that they
> will pay more attention then.  They won't.

I don't think that the problem is about moving towards "their"
technologies but moving OCaml and its tools towards "their" problem
domain. It's definitely not the job of INRIA to do this, though some
help might make this task easier for the commercial programmers among us
(not me).

This usually boils down to adhering to or defining somewhat accepted
standards. E.g., I suppose that many programmers would be happy about
locale support or libraries in the distribution that handle some
high-level standard internet protocols, etc.

It might be a good idea to define some set of rules that allows people
external to INRIA to write libraries in such a way that they could be
accepted in the standard distribution. Or even better, to define and
implement standard packaging schemes that make seamless integration of 3rd
party libraries easy. Then the community could much more effectively take
over the burden of providing OCaml-libraries and tools for commercial use.

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
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 ???

[Alessandro Baretta]

Xavier Leroy wrote:
> What's so surprising about this?  This man chose a particular line of
> business where customers are not interested in new or advanced stuff.
> Just like you could choose to manage a McDonald's and have no
> professional interest in gourmet food or fine wines.

It is not so much his choice as the choice of his customers, 
which, of course, he must adhere to. If his customers ask 
for MS-SQLserver he gives them that, although he openly 
declares to have a preference for DB2.  The same is with 
PLs. He mentioned a "fantastic" programming languange by the 
name of APL which he used to use when he was a researcher at 
IBM. (I'm sure you know about APL much better than I.) It is 
not without melancholy, he said, that has had to move 
towards more commercial systems, mainly Java, and more 
recently, given the massive marketing effort from Microsoft, 
towards .NET.

What I'm talking about is the scarce interest customers have 
for quality software development processes, which 
necessarily include quality programming languages, as 
opposed to caring about the marketing hype behind one 
platform or another. Have you seen the MS commercial where a 
robot begins to paint a car frame as soon as the customer 
declares his preference for that color, stops when the 
customer shows some indecision, and immediately resumes as 
the client confirms his first choice? Has this got anything 
at all to do with .NET?

It's just the same thing with teenagers and MacDonalds: is 
it good for their health to eat there? Definitely not. An 
education effort must be carried out with teenagers to teach 
them to eat pizza, which is good for them ;-) as opposed to 
hamburgers. (And, BTW, yes, I am Italian.) A similar 
education effort might make corporate customers aware of the 
fact that O'Caml is good for them, while MS is not. (And, 
yes, I'm also a Caml rider and Penguin breeder.)

> I'm not disturbed in the least by the fact that many computer
> professionals couldn't care less about what we do.  (And conversely :-)
> What I am concerned about is the well-meaning suggestions that we
> should move towards "their" technologies in the vague hope that they
> will pay more attention then.  They won't.

I don't mean to say that "we" (the Ocaml team at INRIA, 
really) should bow to the omnipotence of Big Bill, 
especially when the language needs special features in its 
VM in order to work, as you mention later on. Yet, it would 
be easier for me to market O'Caml applications if I could 
mention some commercial trademarks my customers have already 
heard. "O'Caml" is not a winner for a trademark, especially 
when you are confronted by the inevitable question: "What 
does it stand for?"

>>They want *real_world* products on
>>*real_world* platforms: COBOL and .NET, that's what they want."
>>No comment. But if Ocaml could somehow "run on .NET", people
>>like the above CEO (an ex-mathematician and IBM researcher,
>>by the way) would be a whole lot more interested in Ocaml.
> 
> 
> Again, I think this is a fallacy.  By the same logic:
> 
> "if OCaml could somehow 'look like COBOL', people like the above CEO 
>  would be a lot more interested in OCaml".
> 
> "if Bordeaux red wines were carbonated, McDonald's would be a lot more
>  interested in selling them".
> 
> You can make your own parallels: it's fun :-)

I don't think O'Caml should like like anything other than 
O'Caml, with the sole exception of DdR's CamlP4 and its 
revised syntax. The customers has no visibility of the 
language itself, but of the entire platform on which the 
software runs: VM, API and libraries. I don't know a lot 
about VMs, but I can definitely say the Caml VM is a whole 
lot faster and more efficient that Sun's JVM. I had to buy a 
new PC one year ago just to write--and run--a few thousand 
lines of Java. O'Caml work, on the other hand, requires no 
costly hardware. I really like the VM. But all this does not 
make it terribly attractive to my customers. As I already 
mentioned, it is mainly a marketing problem.

>>Xavier, let me ask a dumb question, if you don't mind: how 
>>do you choose which processor architectures to port ocamlopt 
>>to?
> 
> 
> By a combination of demand and availability (of a machine running said
> architecture).
> 
> 
>>Could .NET simply be regarded as a new "architecture" for ocamlopt?
> 
> 
> Not at all.  .NET isn't just a (virtual) machine instruction set: it's
> a whole infrastructure, including memory management, data
> representation formats, systems services, libraries, etc.  All these
> replace (and conflict with) those we have in the OCaml implementation.
> 
> Our past experiments in retargeting the OCaml implementation to .Net
> failed because of this.  For more details, and an explanation of why
> .Net is a real straight-jacket for innovative programming languages,
> see a previous post of mine:
>         http://caml.inria.fr/archives/200102/msg00190.html

Dumb question. Alright, forget it.

Thank you very much for your time and interest. I hope I am 
making some sense.

Alex

-------------------
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 ???

[Stefano Lanzavecchia]

> PLs. He mentioned a "fantastic" programming languange by the name of 
> APL which he used to use when he was a researcher at IBM. (I'm sure 
> you know about APL much better than I.) It is

I happen to be an APL programmer... And, yes, it is an amazing
programming language. With almost nothing in common with OCaml, except,
possibly, the not being a mainstream language.

> not without melancholy, he said, that has had to move
> towards more commercial systems, mainly Java, and more
> recently, given the massive marketing effort from Microsoft, 
> towards .NET.

http://www.dyadic.com/whatsnew/msnet.htm


> It's just the same thing with teenagers and MacDonalds: is
> it good for their health to eat there? Definitely not. An
> education effort must be carried out with teenagers to teach 
> them to eat pizza, which is good for them ;-) as opposed to 
> hamburgers. (And, BTW, yes, I am Italian.) A similar 

So am I. Italian, although quite original to be an Italian.

> education effort might make corporate customers aware of the fact that

> O'Caml is good for them, while MS is not. (And,

Please. Microsoft is not the evil incarnated. I believe that Microsoft
is good for a lot of corporate customers. The thing you must educate
people is that there are other good alternatives, if they work for them.
Make them aware and make the choose. Starting from the point of view
that Microsoft is bad is as bad not being educated. In case you wonder,
I am not affiliated in any way to Microsoft or Dyadic Software. I am a
free thinker. And yes, was also a Penguin breeder, back in the days when
a 486 50MHz was the Ferrari of Personal Computing.
-- 
WildHeart'2k2 - mailto:stf@apl.it
Homepage: currently offline

<<<All I Ever Learned, I Learned From Anime: ---
   There are always multiple light sources.>>>

-------------------
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 ???

[Alessandro Baretta]

Stefano Lanzavecchia wrote:
> 
> http://www.dyadic.com/whatsnew/msnet.htm
> 

I will certainly mention this to the aforementioned 
entrepreneur, who will certainly be interested in this.

>>education effort might make corporate customers aware of the fact that
>>O'Caml is good for them, while MS is not. (And,
> 
> 
> Please. Microsoft is not the evil incarnated. I believe that Microsoft
> is good for a lot of corporate customers. The thing you must educate
> people is that there are other good alternatives, if they work for them.
> Make them aware and make the choose. Starting from the point of view
> that Microsoft is bad is as bad not being educated. In case you wonder,
> I am not affiliated in any way to Microsoft or Dyadic Software. I am a
> free thinker. And yes, was also a Penguin breeder, back in the days when
> a 486 50MHz was the Ferrari of Personal Computing.

There is a fair amount of joke in what I wrote. I am a caml 
rider and penguin breeder, not a plane hijacker or suicide 
bomber. I advocate the technology I like best, and, from a 
professional standpoint, I integrate it in the projects I am 
assigned by my clients. I am professionally uninterested in 
MS products, albeit primarily for aesthetic reasons and 
personal taste.

Even you were affiliated with Microsoft or Dyadic software, 
you would still be entitled to free thought. I actually wish 
to thank you for sharing an interesting bit of information 
with me about APL and .NET.

Alex

-------------------
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 ???

[YAMAGATA yoriyuki]

From: Markus Mottl <markus@oefai.at>
Subject: Re: [Caml-list] Unix.file_descr -> int ???
Date: Thu, 20 Jun 2002 13:52:37 +0200

> It might be a good idea to define some set of rules that allows people
> external to INRIA to write libraries in such a way that they could be
> accepted in the standard distribution.

and some degree of disclosure of the future development plan, or at
least, what INRIA team is working now, would help.  This would reduce
danger of duplicated works.

--
Yamagata Yoriyuki
http://www.mars.sphere.ne.jp/yoriyuki/
-------------------
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 ???

[Ohad Rodeh]

Regarding industry problems that Caml may be able to solve. Well, here's
one.

As part of research, I'm building a file-system, where the user-space parts
are written in my favorite programming language :-)  (you guessed correctly
...)
Communication between C and ML components in mostly restricted to sockets.
Here lies the problem: I need to marshal to and from network order
integers (16byte,32byte,64bytes).

I would be helpful if Caml supported marshaling to/from these types
directly.

for example:
                type ofs = int
      get_int16 : string -> ofs -> int
                get_int32 : string -> ofs -> int32
      get_int64 : string -> ofs -> int64

      Ohad.

-----------------------------------------------------------------------------------

Ohad Rodeh
tel: +972-9-9527641
IBM Haifa, storage research


                                                                                                                         
                      Markus Mottl                                                                                       
                      <markus@oefai.at>             To:       Xavier Leroy <xavier.leroy@inria.fr>                       
                      Sent by:                      cc:       Alessandro Baretta <alex@baretta.com>, Ocaml               
                      owner-caml-list@pauill         <caml-list@inria.fr>                                                
                      ac.inria.fr                   Subject:  Re: [Caml-list] Unix.file_descr -> int ???                 
                                                                                                                         
                                                                                                                         
                      20/06/2002 14:52                                                                                   
                      Please respond to                                                                                  
                      Markus Mottl                                                                                       
                                                                                                                         
                                                                                                                         



On Thu, 20 Jun 2002, Xavier Leroy wrote:
> I'm not disturbed in the least by the fact that many computer
> professionals couldn't care less about what we do.  (And conversely :-)
> What I am concerned about is the well-meaning suggestions that we
> should move towards "their" technologies in the vague hope that they
> will pay more attention then.  They won't.

I don't think that the problem is about moving towards "their"
technologies but moving OCaml and its tools towards "their" problem
domain. It's definitely not the job of INRIA to do this, though some
help might make this task easier for the commercial programmers among us
(not me).

This usually boils down to adhering to or defining somewhat accepted
standards. E.g., I suppose that many programmers would be happy about
locale support or libraries in the distribution that handle some
high-level standard internet protocols, etc.

It might be a good idea to define some set of rules that allows people
external to INRIA to write libraries in such a way that they could be
accepted in the standard distribution. Or even better, to define and
implement standard packaging schemes that make seamless integration of 3rd
party libraries easy. Then the community could much more effectively take
over the burden of providing OCaml-libraries and tools for commercial use.

Regards,
Markus Mottl

--
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
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




-------------------
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