* Re: [Caml-list] Unix.file_descr -> int ???
@ 2002-06-18 13:38 Alessandro Baretta
[not found] ` <000101c21705$d9f23640$0501a8c0@lexifi01>
0 siblings, 1 reply; 28+ messages in thread
From: Alessandro Baretta @ 2002-06-18 13:38 UTC (permalink / raw)
To: Ocaml
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Caml-list] Unix.file_descr -> int ???
[not found] ` <000101c21705$d9f23640$0501a8c0@lexifi01>
@ 2002-06-18 22:41 ` Alessandro Baretta
2002-06-19 16:22 ` John Max Skaller
2002-06-20 11:23 ` Xavier Leroy
0 siblings, 2 replies; 28+ messages in thread
From: Alessandro Baretta @ 2002-06-18 22:41 UTC (permalink / raw)
To: Ocaml
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Caml-list] Unix.file_descr -> int ???
2002-06-18 22:41 ` Alessandro Baretta
@ 2002-06-19 16:22 ` John Max Skaller
2002-06-20 11:23 ` Xavier Leroy
1 sibling, 0 replies; 28+ messages in thread
From: John Max Skaller @ 2002-06-19 16:22 UTC (permalink / raw)
To: Alessandro Baretta; +Cc: Ocaml
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Caml-list] Unix.file_descr -> int ???
2002-06-18 22:41 ` Alessandro Baretta
2002-06-19 16:22 ` John Max Skaller
@ 2002-06-20 11:23 ` Xavier Leroy
2002-06-20 11:52 ` Markus Mottl
2002-06-20 13:14 ` Alessandro Baretta
1 sibling, 2 replies; 28+ messages in thread
From: Xavier Leroy @ 2002-06-20 11:23 UTC (permalink / raw)
To: Alessandro Baretta; +Cc: Ocaml
> 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Caml-list] Unix.file_descr -> int ???
2002-06-20 11:23 ` Xavier Leroy
@ 2002-06-20 11:52 ` Markus Mottl
2002-06-20 13:14 ` Alessandro Baretta
1 sibling, 0 replies; 28+ messages in thread
From: Markus Mottl @ 2002-06-20 11:52 UTC (permalink / raw)
To: Xavier Leroy; +Cc: Alessandro Baretta, Ocaml
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Caml-list] Unix.file_descr -> int ???
2002-06-20 11:23 ` Xavier Leroy
2002-06-20 11:52 ` Markus Mottl
@ 2002-06-20 13:14 ` Alessandro Baretta
2002-06-20 13:23 ` Stefano Lanzavecchia
2002-06-20 14:42 ` YAMAGATA yoriyuki
1 sibling, 2 replies; 28+ messages in thread
From: Alessandro Baretta @ 2002-06-20 13:14 UTC (permalink / raw)
To: Xavier Leroy; +Cc: Ocaml
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* RE: [Caml-list] Unix.file_descr -> int ???
2002-06-20 13:14 ` Alessandro Baretta
@ 2002-06-20 13:23 ` Stefano Lanzavecchia
2002-06-20 16:22 ` Alessandro Baretta
2002-06-20 14:42 ` YAMAGATA yoriyuki
1 sibling, 1 reply; 28+ messages in thread
From: Stefano Lanzavecchia @ 2002-06-20 13:23 UTC (permalink / raw)
To: 'Ocaml'
> 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Caml-list] Unix.file_descr -> int ???
2002-06-20 13:14 ` Alessandro Baretta
2002-06-20 13:23 ` Stefano Lanzavecchia
@ 2002-06-20 14:42 ` YAMAGATA yoriyuki
2002-06-21 16:16 ` [Caml-list] proposal for library Christophe Raffalli
1 sibling, 1 reply; 28+ messages in thread
From: YAMAGATA yoriyuki @ 2002-06-20 14:42 UTC (permalink / raw)
To: markus; +Cc: xavier.leroy, alex, caml-list
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Caml-list] Unix.file_descr -> int ???
2002-06-20 13:23 ` Stefano Lanzavecchia
@ 2002-06-20 16:22 ` Alessandro Baretta
0 siblings, 0 replies; 28+ messages in thread
From: Alessandro Baretta @ 2002-06-20 16:22 UTC (permalink / raw)
To: Stefano Lanzavecchia, Ocaml
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Caml-list] proposal for library
2002-06-20 14:42 ` YAMAGATA yoriyuki
@ 2002-06-21 16:16 ` Christophe Raffalli
2002-06-22 11:56 ` Nicolas Cannasse
0 siblings, 1 reply; 28+ messages in thread
From: Christophe Raffalli @ 2002-06-21 16:16 UTC (permalink / raw)
To: caml-list
Le jeu 20/06/2002 à 16:42, YAMAGATA yoriyuki a écrit :
> 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.
Why not have a system of submission/referee for adding functions to
existing library (I am often mising for instance the usual List.flat_map
or List.rev_append in list.mli) or adding new library to the standard
OCaml ?
There should exist some clearly written rules to respect, and the
referees should check that these rules are respected. The referees could
also ask for modification and so on ..
I do not think the INRIA team spend a lot of time adapting the libraries
when they do incompatible change to OCaml. And moreover, some libraries
could be maintained outside of INRIA (by the guy who created the
library) ?
I think this is interesting, because we often write some small library
of function that could be useful to every body ... so it is a nice way
to share them.
among the useful missing library that I am sure many people have
allready written, there are: library for multiset (using Map or
something better), partial order, etc ...
Morever, people could also submit optimized replacement for existing
libraries (using a compatible interface ans semantics, this is hard to
check for the referre). So this way we could get nice, complete and
efficient libraries for OCaml !
--
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex
tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
-------------------
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Caml-list] proposal for library
2002-06-21 16:16 ` [Caml-list] proposal for library Christophe Raffalli
@ 2002-06-22 11:56 ` Nicolas Cannasse
0 siblings, 0 replies; 28+ messages in thread
From: Nicolas Cannasse @ 2002-06-22 11:56 UTC (permalink / raw)
To: Christophe Raffalli, caml-list
> I think this is interesting, because we often write some small library
> of function that could be useful to every body ... so it is a nice way
> to share them.
>
> among the useful missing library that I am sure many people have
> allready written, there are: library for multiset (using Map or
> something better), partial order, etc ...
>
> Morever, people could also submit optimized replacement for existing
> libraries (using a compatible interface ans semantics, this is hard to
> check for the referre). So this way we could get nice, complete and
> efficient libraries for OCaml !
I also think it would be nice to have one big polymorphic data-structures
library ( a la C++ Standard Template Library ) including both mutable and
non-mutable structures and most of the common algorithms - and perhaps some
"misc" functions for strings and others.... If some people are interested by
opening a SourceForge ( or other CVS ) account to enable such development,
that will enable the whole community to design and write such a library.
Once it'll be complete and safe, I don't think there will be any problem for
putting it into the official distribution.
Nicolas Cannasse
-------------------
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Caml-list] Unix.file_descr -> int ???
@ 2002-06-20 12:24 Ohad Rodeh
0 siblings, 0 replies; 28+ messages in thread
From: Ohad Rodeh @ 2002-06-20 12:24 UTC (permalink / raw)
To: caml-list
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Caml-list] Unix.file_descr -> int ???
2002-06-12 8:21 ` Xavier Leroy
2002-06-12 16:06 ` Max Kirillov
@ 2002-06-13 10:24 ` Jean-Marc Eber
1 sibling, 0 replies; 28+ messages in thread
From: Jean-Marc Eber @ 2002-06-13 10:24 UTC (permalink / raw)
To: Xavier Leroy, Basile STARYNKEVITCH; +Cc: caml-list
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Caml-list] Unix.file_descr -> int ???
2002-06-12 8:21 ` Xavier Leroy
@ 2002-06-12 16:06 ` Max Kirillov
2002-06-13 10:24 ` Jean-Marc Eber
1 sibling, 0 replies; 28+ messages in thread
From: Max Kirillov @ 2002-06-12 16:06 UTC (permalink / raw)
To: caml-list
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Caml-list] Unix.file_descr -> int ???
2002-06-11 15:45 ` Xavier Leroy
2002-06-11 19:26 ` Max Kirillov
2002-06-12 7:42 ` Basile STARYNKEVITCH
@ 2002-06-12 15:44 ` John Max Skaller
2 siblings, 0 replies; 28+ messages in thread
From: John Max Skaller @ 2002-06-12 15:44 UTC (permalink / raw)
To: Xavier Leroy; +Cc: Max Kirillov, caml-list
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Caml-list] Unix.file_descr -> int ???
2002-06-12 7:42 ` Basile STARYNKEVITCH
2002-06-12 8:21 ` Xavier Leroy
@ 2002-06-12 13:09 ` Bruno.Verlyck
1 sibling, 0 replies; 28+ messages in thread
From: Bruno.Verlyck @ 2002-06-12 13:09 UTC (permalink / raw)
To: basile.starynkevitch; +Cc: xavier.leroy, caml-list
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Caml-list] Unix.file_descr -> int ???
2002-06-12 9:57 ` Jacques Garrigue
@ 2002-06-12 11:04 ` Jacques Garrigue
0 siblings, 0 replies; 28+ messages in thread
From: Jacques Garrigue @ 2002-06-12 11:04 UTC (permalink / raw)
To: damien.doligez; +Cc: caml-list
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Caml-list] Unix.file_descr -> int ???
2002-06-12 9:53 Damien Doligez
@ 2002-06-12 9:57 ` Jacques Garrigue
2002-06-12 11:04 ` Jacques Garrigue
0 siblings, 1 reply; 28+ messages in thread
From: Jacques Garrigue @ 2002-06-12 9:57 UTC (permalink / raw)
To: damien.doligez; +Cc: caml-list
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Caml-list] Unix.file_descr -> int ???
@ 2002-06-12 9:53 Damien Doligez
2002-06-12 9:57 ` Jacques Garrigue
0 siblings, 1 reply; 28+ messages in thread
From: Damien Doligez @ 2002-06-12 9:53 UTC (permalink / raw)
To: garrigue, max630; +Cc: caml-list
>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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Caml-list] Unix.file_descr -> int ???
2002-06-12 7:42 ` Basile STARYNKEVITCH
@ 2002-06-12 8:21 ` Xavier Leroy
2002-06-12 16:06 ` Max Kirillov
2002-06-13 10:24 ` Jean-Marc Eber
2002-06-12 13:09 ` Bruno.Verlyck
1 sibling, 2 replies; 28+ messages in thread
From: Xavier Leroy @ 2002-06-12 8:21 UTC (permalink / raw)
To: Basile STARYNKEVITCH; +Cc: caml-list
> [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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Caml-list] Unix.file_descr -> int ???
2002-06-11 19:26 ` Max Kirillov
2002-06-11 23:12 ` Berke Durak
2002-06-12 0:10 ` Jacques Garrigue
@ 2002-06-12 8:08 ` Xavier Leroy
2 siblings, 0 replies; 28+ messages in thread
From: Xavier Leroy @ 2002-06-12 8:08 UTC (permalink / raw)
To: caml-list
> 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Caml-list] Unix.file_descr -> int ???
2002-06-11 15:45 ` Xavier Leroy
2002-06-11 19:26 ` Max Kirillov
@ 2002-06-12 7:42 ` Basile STARYNKEVITCH
2002-06-12 8:21 ` Xavier Leroy
2002-06-12 13:09 ` Bruno.Verlyck
2002-06-12 15:44 ` John Max Skaller
2 siblings, 2 replies; 28+ messages in thread
From: Basile STARYNKEVITCH @ 2002-06-12 7:42 UTC (permalink / raw)
To: Xavier Leroy; +Cc: caml-list
>>>>> "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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Caml-list] Unix.file_descr -> int ???
2002-06-11 19:26 ` Max Kirillov
2002-06-11 23:12 ` Berke Durak
@ 2002-06-12 0:10 ` Jacques Garrigue
2002-06-12 8:08 ` Xavier Leroy
2 siblings, 0 replies; 28+ messages in thread
From: Jacques Garrigue @ 2002-06-12 0:10 UTC (permalink / raw)
To: max630; +Cc: caml-list
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Caml-list] Unix.file_descr -> int ???
2002-06-11 19:26 ` Max Kirillov
@ 2002-06-11 23:12 ` Berke Durak
2002-06-12 0:10 ` Jacques Garrigue
2002-06-12 8:08 ` Xavier Leroy
2 siblings, 0 replies; 28+ messages in thread
From: Berke Durak @ 2002-06-11 23:12 UTC (permalink / raw)
To: Max Kirillov; +Cc: caml-list
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Caml-list] Unix.file_descr -> int ???
2002-06-11 15:45 ` Xavier Leroy
@ 2002-06-11 19:26 ` Max Kirillov
2002-06-11 23:12 ` Berke Durak
` (2 more replies)
2002-06-12 7:42 ` Basile STARYNKEVITCH
2002-06-12 15:44 ` John Max Skaller
2 siblings, 3 replies; 28+ messages in thread
From: Max Kirillov @ 2002-06-11 19:26 UTC (permalink / raw)
To: caml-list
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Caml-list] Unix.file_descr -> int ???
2002-06-11 14:31 Max Kirillov
2002-06-11 15:40 ` Bruno.Verlyck
@ 2002-06-11 15:45 ` Xavier Leroy
2002-06-11 19:26 ` Max Kirillov
` (2 more replies)
1 sibling, 3 replies; 28+ messages in thread
From: Xavier Leroy @ 2002-06-11 15:45 UTC (permalink / raw)
To: Max Kirillov; +Cc: caml-list
> 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Caml-list] Unix.file_descr -> int ???
2002-06-11 14:31 Max Kirillov
@ 2002-06-11 15:40 ` Bruno.Verlyck
2002-06-11 15:45 ` Xavier Leroy
1 sibling, 0 replies; 28+ messages in thread
From: Bruno.Verlyck @ 2002-06-11 15:40 UTC (permalink / raw)
To: max630; +Cc: caml-list
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Caml-list] Unix.file_descr -> int ???
@ 2002-06-11 14:31 Max Kirillov
2002-06-11 15:40 ` Bruno.Verlyck
2002-06-11 15:45 ` Xavier Leroy
0 siblings, 2 replies; 28+ messages in thread
From: Max Kirillov @ 2002-06-11 14:31 UTC (permalink / raw)
To: caml-list
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
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2002-06-22 11:59 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-06-18 13:38 [Caml-list] Unix.file_descr -> int ??? Alessandro Baretta
[not found] ` <000101c21705$d9f23640$0501a8c0@lexifi01>
2002-06-18 22:41 ` Alessandro Baretta
2002-06-19 16:22 ` John Max Skaller
2002-06-20 11:23 ` Xavier Leroy
2002-06-20 11:52 ` Markus Mottl
2002-06-20 13:14 ` Alessandro Baretta
2002-06-20 13:23 ` Stefano Lanzavecchia
2002-06-20 16:22 ` Alessandro Baretta
2002-06-20 14:42 ` YAMAGATA yoriyuki
2002-06-21 16:16 ` [Caml-list] proposal for library Christophe Raffalli
2002-06-22 11:56 ` Nicolas Cannasse
-- strict thread matches above, loose matches on Subject: below --
2002-06-20 12:24 [Caml-list] Unix.file_descr -> int ??? Ohad Rodeh
2002-06-12 9:53 Damien Doligez
2002-06-12 9:57 ` Jacques Garrigue
2002-06-12 11:04 ` Jacques Garrigue
2002-06-11 14:31 Max Kirillov
2002-06-11 15:40 ` Bruno.Verlyck
2002-06-11 15:45 ` Xavier Leroy
2002-06-11 19:26 ` Max Kirillov
2002-06-11 23:12 ` Berke Durak
2002-06-12 0:10 ` Jacques Garrigue
2002-06-12 8:08 ` Xavier Leroy
2002-06-12 7:42 ` Basile STARYNKEVITCH
2002-06-12 8:21 ` Xavier Leroy
2002-06-12 16:06 ` Max Kirillov
2002-06-13 10:24 ` Jean-Marc Eber
2002-06-12 13:09 ` Bruno.Verlyck
2002-06-12 15:44 ` John Max Skaller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).