[Caml-list] Graphics frustration

[Caml-list] Graphics frustration

[Matt Gushee]

Hello, all--

I have been working on an application which will generate on-the-fly
graphics for the Web, but I have become very frustrated by the
limitations of the available graphics libraries for OCaml. If anyone
reading this thinks there are solutions I have overlooked, I would be
happy to discuss details. Right now, though, my purpose is to find out
whether others share my concerns, and how much interest there is in
developing better graphics libraries.

What I would like to see is a single library with at least the
following capabilities:

  * drawing primitives: line, rectangle, ellipse and/or arc, perhaps
    bezier curves

  * rendering text with arbitrary Type 1 and/or TrueType fonts

  * antialiasing

  * basic image manipulation functions such as transformations,
    contrast adjustment, cropping, etc.

  * saving to common bitmap formats such as JPEG and PNG

  * cross-platform

taking the various graphics packages together, all these capabilities
exist, but as far as I can tell there is no single package that combines
them all. So, in developing my application, I started out with
OCamlPlot, but discovered that it

  - doesn't do antialiasing

  - uses only 2 or 3 built-in fonts for PNG output

  - has a rather rigid and idiosyncratic API

  - doesn't run on Windows

Then I decided to try MLgraph + Camlimages, which is an improvement, but
still falls short: MLgraph is excellent for drawing, but saves only to
PostScript--and I find the final result, converted to PNG with
CamlImages, rather unsatisfactory (the main problem is that antialiasing
doesn't work very well, which may actually be a Ghostscript issue).
Performance with this combination is also markedly poorer than with
OCamlPlot.

Then there's OCamlGD, which seems quite promising. When complete, it
will probably satisfy all my requirements; but there hasn't been a
relesase in quite a while.

So that's a quick summary of my situation. Do others agree with me that
this is a significant problem? Are there any good solutions in the
works?

I am happy, by the way, to put some effort into developing something
better. My contribution would be limited, though (I'm not a C
programmer, for example, so I wouldn't be able to create a wrapper for
an existing C library.).

Comments?

-- 
Matt Gushee                 When a nation follows the Way,
Englewood, Colorado, USA    Horses bear manure through
mgushee@havenrock.com           its fields;
http://www.havenrock.com/   When a nation ignores the Way,
                            Horses bear soldiers through
                                its streets.
                                
                            --Lao Tzu (Peter Merel, trans.)

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

[Richard Jones]

I did something like this in C++ an eon ago. The program generated
Postscript directly and piped it into Ghostscript to render it into
the appropriate format. Postscript is a very powerful language for
this sort of thing once you get used to it.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - all your business data are belong to you.
 All new technology is irrelevant until it is taken up by the public.

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

[SooHyoung Oh]

What do you think about SVG (Selective Vector Graphics)?
It uses only text for graphics as postscript so it's not difficult to use
OCaml for SVG.
If you interested about that, I'll send you a few examples.

---
SooHyoung Oh
----- Original Message -----
From: "Matt Gushee" <mgushee@havenrock.com>
To: <caml-list@pauillac.inria.fr>
Sent: Thursday, July 24, 2003 1:20 PM
Subject: [Caml-list] Graphics frustration


> Hello, all--
>
> I have been working on an application which will generate on-the-fly
> graphics for the Web, but I have become very frustrated by the
> limitations of the available graphics libraries for OCaml. If anyone
> reading this thinks there are solutions I have overlooked, I would be
> happy to discuss details. Right now, though, my purpose is to find out
> whether others share my concerns, and how much interest there is in
> developing better graphics libraries.
>
> What I would like to see is a single library with at least the
> following capabilities:
>
>   * drawing primitives: line, rectangle, ellipse and/or arc, perhaps
>     bezier curves
>
>   * rendering text with arbitrary Type 1 and/or TrueType fonts
>
>   * antialiasing
>
>   * basic image manipulation functions such as transformations,
>     contrast adjustment, cropping, etc.
>
>   * saving to common bitmap formats such as JPEG and PNG
>
>   * cross-platform
>
> taking the various graphics packages together, all these capabilities
> exist, but as far as I can tell there is no single package that combines
> them all. So, in developing my application, I started out with
> OCamlPlot, but discovered that it
>
>   - doesn't do antialiasing
>
>   - uses only 2 or 3 built-in fonts for PNG output
>
>   - has a rather rigid and idiosyncratic API
>
>   - doesn't run on Windows
>
> Then I decided to try MLgraph + Camlimages, which is an improvement, but
> still falls short: MLgraph is excellent for drawing, but saves only to
> PostScript--and I find the final result, converted to PNG with
> CamlImages, rather unsatisfactory (the main problem is that antialiasing
> doesn't work very well, which may actually be a Ghostscript issue).
> Performance with this combination is also markedly poorer than with
> OCamlPlot.
>
> Then there's OCamlGD, which seems quite promising. When complete, it
> will probably satisfy all my requirements; but there hasn't been a
> relesase in quite a while.
>
> So that's a quick summary of my situation. Do others agree with me that
> this is a significant problem? Are there any good solutions in the
> works?
>
> I am happy, by the way, to put some effort into developing something
> better. My contribution would be limited, though (I'm not a C
> programmer, for example, so I wouldn't be able to create a wrapper for
> an existing C library.).
>
> Comments?
>
> --
> Matt Gushee                 When a nation follows the Way,
> Englewood, Colorado, USA    Horses bear manure through
> mgushee@havenrock.com           its fields;
> http://www.havenrock.com/   When a nation ignores the Way,
>                             Horses bear soldiers through
>                                 its streets.
>
>                             --Lao Tzu (Peter Merel, trans.)
>
> -------------------
> 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

Re: [Caml-list] Graphics frustration

[SooHyoung Oh]

SVG (Scalable Vector Graphics)

sorry...

---
SooHyoung Oh
----- Original Message -----
From: "SooHyoung Oh" <shoh@duonix.com>
To: "Matt Gushee" <mgushee@havenrock.com>; <caml-list@pauillac.inria.fr>
Sent: Saturday, July 26, 2003 10:37 AM
Subject: Re: [Caml-list] Graphics frustration


>
> What do you think about SVG (Selective Vector Graphics)?
> It uses only text for graphics as postscript so it's not difficult to use
> OCaml for SVG.
> If you interested about that, I'll send you a few examples.
>
> ---
> SooHyoung Oh
> ----- Original Message -----
> From: "Matt Gushee" <mgushee@havenrock.com>
> To: <caml-list@pauillac.inria.fr>
> Sent: Thursday, July 24, 2003 1:20 PM
> Subject: [Caml-list] Graphics frustration
>
>
> > Hello, all--
> >
> > I have been working on an application which will generate on-the-fly
> > graphics for the Web, but I have become very frustrated by the
> > limitations of the available graphics libraries for OCaml. If anyone
> > reading this thinks there are solutions I have overlooked, I would be
> > happy to discuss details. Right now, though, my purpose is to find out
> > whether others share my concerns, and how much interest there is in
> > developing better graphics libraries.
> >
> > What I would like to see is a single library with at least the
> > following capabilities:
> >
> >   * drawing primitives: line, rectangle, ellipse and/or arc, perhaps
> >     bezier curves
> >
> >   * rendering text with arbitrary Type 1 and/or TrueType fonts
> >
> >   * antialiasing
> >
> >   * basic image manipulation functions such as transformations,
> >     contrast adjustment, cropping, etc.
> >
> >   * saving to common bitmap formats such as JPEG and PNG
> >
> >   * cross-platform
> >
> > taking the various graphics packages together, all these capabilities
> > exist, but as far as I can tell there is no single package that combines
> > them all. So, in developing my application, I started out with
> > OCamlPlot, but discovered that it
> >
> >   - doesn't do antialiasing
> >
> >   - uses only 2 or 3 built-in fonts for PNG output
> >
> >   - has a rather rigid and idiosyncratic API
> >
> >   - doesn't run on Windows
> >
> > Then I decided to try MLgraph + Camlimages, which is an improvement, but
> > still falls short: MLgraph is excellent for drawing, but saves only to
> > PostScript--and I find the final result, converted to PNG with
> > CamlImages, rather unsatisfactory (the main problem is that antialiasing
> > doesn't work very well, which may actually be a Ghostscript issue).
> > Performance with this combination is also markedly poorer than with
> > OCamlPlot.
> >
> > Then there's OCamlGD, which seems quite promising. When complete, it
> > will probably satisfy all my requirements; but there hasn't been a
> > relesase in quite a while.
> >
> > So that's a quick summary of my situation. Do others agree with me that
> > this is a significant problem? Are there any good solutions in the
> > works?
> >
> > I am happy, by the way, to put some effort into developing something
> > better. My contribution would be limited, though (I'm not a C
> > programmer, for example, so I wouldn't be able to create a wrapper for
> > an existing C library.).
> >
> > Comments?
> >
> > --
> > Matt Gushee                 When a nation follows the Way,
> > Englewood, Colorado, USA    Horses bear manure through
> > mgushee@havenrock.com           its fields;
> > http://www.havenrock.com/   When a nation ignores the Way,
> >                             Horses bear soldiers through
> >                                 its streets.
> >
> >                             --Lao Tzu (Peter Merel, trans.)
> >
> > -------------------
> > 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
>

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

[Matt Gushee]

First of all, thanks to all who responded. And I have a few responses
for the respondents. First, though, one general remark: although I am
certainly interested in practical solutions to my current problem, in
this instance I was trying to draw attention to what I see as a weak
point in the selection of available libraries. Graphics are a common
need, and I think better graphics libraries would help the popularity of
OCaml.


On Thu, Jul 24, 2003 at 11:22:03AM +0200, Olivier Andrieu wrote:
>  Matt Gushee [Wednesday 23 July 2003] :
>  > So that's a quick summary of my situation. Do others agree with me that
>  > this is a significant problem? Are there any good solutions in the
>  > works?
> 
> I agree with you that libplot isn't fully satisfactory. I haven't much
> to suggest, though. GD seems to have all the features you need 

I agree. However ...

> (but I
> don't know the state of the ocaml wrapper).

That's the problem. It's far from being a complete GD interface. And
I've contacted its author, and he doesn't expect to continue developing
it. I may see if I can hack in the remaining functionality myself, but
with my minimal C knowledge I'm not optimistic about that.

> One solution I've been
> thinking about is using libart together with Camlimages. Libart is a
> library for rendering vector graphics (e.g. bezier paths) in
> anti-aliased pixel buffers. It's written by the Ghostscipt maintainer
> I think. It seems very good but it doesn't handle text rendering nor
> saving pixel buffers to file. But I think it should be possible to
> interface it with Camlimages : libart would do the primitives
> rendering and camlimages the text rendering and saving.

Interesting idea. I'd like to know if you do that. By the way, what in
particular do you like about libart?

> Writing a C wrapper seems the easiest and quicker way to do what you
> want though ...

I agree, and I actually would like to learn C. But there is so much to
learn, and so little time to learn it ...


On Thu, Jul 24, 2003 at 01:03:01PM +0100, Richard Jones wrote:
> I did something like this in C++ an eon ago. The program generated
> Postscript directly and piped it into Ghostscript to render it into
> the appropriate format. Postscript is a very powerful language for
> this sort of thing once you get used to it.

Well, I'm reasonably comfortable with PS, and that's pretty much the
approach I'm taking already: as I explained, draw with MLgraph, convert
with Camlimages (which uses Ghostscript to load PS). But the problem I'm
having there is that the antialiasing in the output is unsatisfactory.
If I use Camlimages out-of-the-box, there is no antialiasing, and curves
come out looking horribly jagged. On the other hand, if I hack the
Camlimages source such that Ghostscript is called with
-dGraphicsAlphaBits=4, curves look fine, but vertical and horizontal
lines look blurred and semi-transparent. I've also tried converting the
Postscript with ImageMagick, with results very similar to the latter. So
I'm afraid the root cause may be a limitation of Ghostscript, though I
haven't thoroughly investigated yet.


On Thu, Jul 24, 2003 at 02:25:38PM +0200, Daniel Bünzli wrote:
> Dear Matt,
> 
> Did you consider using OpenGL ?

What an appalling thought!

:-)

Seriously, though, I might end up doing this--when push comes to shove I
care more about making things work than about doing them 'correctly.'
Still, as a general solution to the problem of generating 2D raster
graphics, OpenGL strikes me as being an ugly (and perhaps inefficient?)
approach. But I don't understand OpenGL very well, and perhaps I'd
change my mind if I did.

> But it seems that the FreeType library can give you antialiased pixmaps 
> of given fonts and that CamlImages provides an inteface to the FreeType 
> library (never used that however). So maybe you can make both of them 
> interact smoothly. So I suggest you (though I'm completly misinformed) 
> CamlImages+lablGL.

May be worth trying. How mature and stable is lablGL? I would have to
learn OpenGL, and since I don't have much interest in OpenGL per se,
before I take the time to learn it, I'd like to have some assurance that
it is in fact a reliable means for producing high-quality 2D bitmaps.


On Sat, Jul 26, 2003 at 10:37:20AM +0900, SooHyoung Oh wrote:
> 
> What do you think about SVG (Selective Vector Graphics)?

I'm very interested in SVG, but it's not an appropriate solution in this
case. This is a front-end Web application, and I specifically intend it
to render graphics in a form that is viewable with any mainstream
browser--i.e., PNG, JPEG, and/or GIF. I think it will be several years
before we can reasonably expect clients to have built-in SVG support.

> It uses only text for graphics as postscript so it's not difficult to use
> OCaml for SVG.
> If you interested about that, I'll send you a few examples.

If you mean examples of SVG images, I probably have enough already. But
if you have written code for generating or processing SVG, I would be
interested in seeing what you've done.


On Sat, Jul 26, 2003 at 10:55:19AM +0900, SooHyoung Oh wrote:
> 
> SVG (Scalable Vector Graphics)
> 
> sorry...

No worries. There are so many acronyms floating around these days, I
would be a little scared of someone who could remember them all
correctly.

-- 
Matt Gushee                 When a nation follows the Way,
Englewood, Colorado, USA    Horses bear manure through
mgushee@havenrock.com           its fields;
http://www.havenrock.com/   When a nation ignores the Way,
                            Horses bear soldiers through
                                its streets.
                                
                            --Lao Tzu (Peter Merel, trans.)

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

[Alexander V. Voinov]

Hi Matt,

I don't see ploticus in the list. But it is a good plot maker. However I use it 
from Python, not from OCaml, and the reflection capability of the former makes 
the interface tiny. But in all other respects there should not be any difference.

Alexander

Matt Gushee wrote:

> First of all, thanks to all who responded. And I have a few responses
> for the respondents. First, though, one general remark: although I am
> certainly interested in practical solutions to my current problem, in
> this instance I was trying to draw attention to what I see as a weak
> point in the selection of available libraries. Graphics are a common
> need, and I think better graphics libraries would help the popularity of
> OCaml.
> 
> 
> On Thu, Jul 24, 2003 at 11:22:03AM +0200, Olivier Andrieu wrote:
> 
>> Matt Gushee [Wednesday 23 July 2003] :
>> > So that's a quick summary of my situation. Do others agree with me that
>> > this is a significant problem? Are there any good solutions in the
>> > works?
>>
>>I agree with you that libplot isn't fully satisfactory. I haven't much
>>to suggest, though. GD seems to have all the features you need 
> 
> 
> I agree. However ...
> 
> 
>>(but I
>>don't know the state of the ocaml wrapper).
> 
> 
> That's the problem. It's far from being a complete GD interface. And
> I've contacted its author, and he doesn't expect to continue developing
> it. I may see if I can hack in the remaining functionality myself, but
> with my minimal C knowledge I'm not optimistic about that.
> 
> 
>>One solution I've been
>>thinking about is using libart together with Camlimages. Libart is a
>>library for rendering vector graphics (e.g. bezier paths) in
>>anti-aliased pixel buffers. It's written by the Ghostscipt maintainer
>>I think. It seems very good but it doesn't handle text rendering nor
>>saving pixel buffers to file. But I think it should be possible to
>>interface it with Camlimages : libart would do the primitives
>>rendering and camlimages the text rendering and saving.
> 
> 
> Interesting idea. I'd like to know if you do that. By the way, what in
> particular do you like about libart?
> 
> 
>>Writing a C wrapper seems the easiest and quicker way to do what you
>>want though ...
> 
> 
> I agree, and I actually would like to learn C. But there is so much to
> learn, and so little time to learn it ...
> 
> 
> On Thu, Jul 24, 2003 at 01:03:01PM +0100, Richard Jones wrote:
> 
>>I did something like this in C++ an eon ago. The program generated
>>Postscript directly and piped it into Ghostscript to render it into
>>the appropriate format. Postscript is a very powerful language for
>>this sort of thing once you get used to it.
> 
> 
> Well, I'm reasonably comfortable with PS, and that's pretty much the
> approach I'm taking already: as I explained, draw with MLgraph, convert
> with Camlimages (which uses Ghostscript to load PS). But the problem I'm
> having there is that the antialiasing in the output is unsatisfactory.
> If I use Camlimages out-of-the-box, there is no antialiasing, and curves
> come out looking horribly jagged. On the other hand, if I hack the
> Camlimages source such that Ghostscript is called with
> -dGraphicsAlphaBits=4, curves look fine, but vertical and horizontal
> lines look blurred and semi-transparent. I've also tried converting the
> Postscript with ImageMagick, with results very similar to the latter. So
> I'm afraid the root cause may be a limitation of Ghostscript, though I
> haven't thoroughly investigated yet.
> 
> 
> On Thu, Jul 24, 2003 at 02:25:38PM +0200, Daniel Bünzli wrote:
> 
>>Dear Matt,
>>
>>Did you consider using OpenGL ?
> 
> 
> What an appalling thought!
> 
> :-)
> 
> Seriously, though, I might end up doing this--when push comes to shove I
> care more about making things work than about doing them 'correctly.'
> Still, as a general solution to the problem of generating 2D raster
> graphics, OpenGL strikes me as being an ugly (and perhaps inefficient?)
> approach. But I don't understand OpenGL very well, and perhaps I'd
> change my mind if I did.
> 
> 
>>But it seems that the FreeType library can give you antialiased pixmaps 
>>of given fonts and that CamlImages provides an inteface to the FreeType 
>>library (never used that however). So maybe you can make both of them 
>>interact smoothly. So I suggest you (though I'm completly misinformed) 
>>CamlImages+lablGL.
> 
> 
> May be worth trying. How mature and stable is lablGL? I would have to
> learn OpenGL, and since I don't have much interest in OpenGL per se,
> before I take the time to learn it, I'd like to have some assurance that
> it is in fact a reliable means for producing high-quality 2D bitmaps.
> 
> 
> On Sat, Jul 26, 2003 at 10:37:20AM +0900, SooHyoung Oh wrote:
> 
>>What do you think about SVG (Selective Vector Graphics)?
> 
> 
> I'm very interested in SVG, but it's not an appropriate solution in this
> case. This is a front-end Web application, and I specifically intend it
> to render graphics in a form that is viewable with any mainstream
> browser--i.e., PNG, JPEG, and/or GIF. I think it will be several years
> before we can reasonably expect clients to have built-in SVG support.
> 
> 
>>It uses only text for graphics as postscript so it's not difficult to use
>>OCaml for SVG.
>>If you interested about that, I'll send you a few examples.
> 
> 
> If you mean examples of SVG images, I probably have enough already. But
> if you have written code for generating or processing SVG, I would be
> interested in seeing what you've done.
> 
> 
> On Sat, Jul 26, 2003 at 10:55:19AM +0900, SooHyoung Oh wrote:
> 
>>SVG (Scalable Vector Graphics)
>>
>>sorry...
> 
> 
> No worries. There are so many acronyms floating around these days, I
> would be a little scared of someone who could remember them all
> correctly.
> 



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

[Caml-list] Re: Graphic frustration

[Nicolas Janin]

I think what  Matt Gushee's concern is, and  it is clear he isn't alone in
this case (see for example the thread "Roadplan for world domination"
07/25/2003), that now that Ocaml is a mature language, its major drawback
lies in the display and drawing area. There exists several bindings for
different usages in the graphical area but they are all developed in a
different manner, without any integration with existing components. Using
the libraries that exist currently here and there can only be short term
solutions for the serious user.
My feeling is that they are inadequate for corporate users and most
individuals, who don't want to spend twice as much time reading the
documentation (or the code itself !) of each and every library they need for
their projects. Also, since these are small projects by single individuals,
one doesn't know whether they are still maintained or not, so one may have
concerns using them.

Since Ocaml is a powerful language, it needs to show it can handle an
ambitious project :

1. Ocaml needs a comprehensive graphic library that encompasses all the
users needs, so that they won't have to reinvent the wheel each time they
need to do graphics : there exists bindings for SDL and Open GL, but it's a
pain to have to learn each and every library, and have to write again and
again all the code that lacks between the two. This is not practical at all.

What the serious user really wants is a SINGLE large, modular, fast &
extensible library that allows in a consistent manner  to do just about
everything graphical :

 - real time vizualisation for 3D games and 3D softwares with accelerated
Open GL,

 - raster image display (JPEG, PNG formats) in bitmap, B&W and true color,
and some basic image treatments algorithms,

 - 2D vectorized drawing primitives and vectorized text (Display Postscript
or Scalable Vector Graphics support, whichever),

 - a system for displaying and manipulating objects of all the predefined
graphical types on screen (a system of layers, for example),

 - output to the screen (anti-aliasing), Postscript and PDF formats for
printing (and optionnally XML for portable description).

 - an architecture that allows to extend the library fairly easily (with,
optionnally, an embedded interpreted language like Lua or Guile that would
allow applications written with the library, to add some graphical
fuctionalities for their specific uses),

 - a complete ocamldoc documentation.

2. Ocaml lacks a multiplatform native code GUI system, GTK is ok and a
wxwindows should help making GUIs multiplatform, but ideally, a modern
native Ocaml GUI based on the above library would be much better.
Of course, the better and more comprehensive the graphic library is, the
easier to develop and more powerful the GUI. The GUI could also be piloted
or extended in some ways by the scripting language of the graphic library.

Hopefully, by its sheer size and ambitious, provided that it eventually
exists, such a project would attract many volunteers, and a consistent
support throughout the years. Eventually, it could become the centerpiece of
a whole lot of software libraries.

Nicolas

----- Original Message -----
From: "SooHyoung Oh" <shoh@duonix.com>
To: "Matt Gushee" <mgushee@havenrock.com>; <caml-list@pauillac.inria.fr>
Sent: Saturday, July 26, 2003 3:41 AM


> Subject: Re: [Caml-list] Graphics frustration
> Date: Sat, 26 Jul 2003 10:37:20 +0900
> MIME-Version: 1.0
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: 7bit
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-Mailer: Microsoft Outlook Express 6.00.2600.0000
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
> X-Loop: caml-list@inria.fr
> X-Spam: no; 0.00; caml-list:01 gushee:01 mgushee:01 havenrock:01 all--:01
arc:99 ocamlplot:01 api:01 camlimages:01 englewood:01 manure:01
ignores:01 --lao:01 merel:01 bug:01
> Sender: owner-caml-list@pauillac.inria.fr
> Precedence: bulk
>
>
> What do you think about SVG (Selective Vector Graphics)?
> It uses only text for graphics as postscript so it's not difficult to use
> OCaml for SVG.
> If you interested about that, I'll send you a few examples.
>
> ---
> SooHyoung Oh
> ----- Original Message -----
> From: "Matt Gushee" <mgushee@havenrock.com>
> To: <caml-list@pauillac.inria.fr>
> Sent: Thursday, July 24, 2003 1:20 PM
> Subject: [Caml-list] Graphics frustration
>
>
> > Hello, all--
> >
> > I have been working on an application which will generate on-the-fly
> > graphics for the Web, but I have become very frustrated by the
> > limitations of the available graphics libraries for OCaml. If anyone
> > reading this thinks there are solutions I have overlooked, I would be
> > happy to discuss details. Right now, though, my purpose is to find out
> > whether others share my concerns, and how much interest there is in
> > developing better graphics libraries.
> >
> > What I would like to see is a single library with at least the
> > following capabilities:
> >
> >   * drawing primitives: line, rectangle, ellipse and/or arc, perhaps
> >     bezier curves
> >
> >   * rendering text with arbitrary Type 1 and/or TrueType fonts
> >
> >   * antialiasing
> >
> >   * basic image manipulation functions such as transformations,
> >     contrast adjustment, cropping, etc.
> >
> >   * saving to common bitmap formats such as JPEG and PNG
> >
> >   * cross-platform
> >
> > taking the various graphics packages together, all these capabilities
> > exist, but as far as I can tell there is no single package that combines
> > them all. So, in developing my application, I started out with
> > OCamlPlot, but discovered that it
> >
> >   - doesn't do antialiasing
> >
> >   - uses only 2 or 3 built-in fonts for PNG output
> >
> >   - has a rather rigid and idiosyncratic API
> >
> >   - doesn't run on Windows
> >
> > Then I decided to try MLgraph + Camlimages, which is an improvement, but
> > still falls short: MLgraph is excellent for drawing, but saves only to
> > PostScript--and I find the final result, converted to PNG with
> > CamlImages, rather unsatisfactory (the main problem is that antialiasing
> > doesn't work very well, which may actually be a Ghostscript issue).
> > Performance with this combination is also markedly poorer than with
> > OCamlPlot.
> >
> > Then there's OCamlGD, which seems quite promising. When complete, it
> > will probably satisfy all my requirements; but there hasn't been a
> > relesase in quite a while.
> >
> > So that's a quick summary of my situation. Do others agree with me that
> > this is a significant problem? Are there any good solutions in the
> > works?
> >
> > I am happy, by the way, to put some effort into developing something
> > better. My contribution would be limited, though (I'm not a C
> > programmer, for example, so I wouldn't be able to create a wrapper for
> > an existing C library.).
> >
> > Comments?
> >
> > --
> > Matt Gushee                 When a nation follows the Way,
> > Englewood, Colorado, USA    Horses bear manure through
> > mgushee@havenrock.com           its fields;
> > http://www.havenrock.com/   When a nation ignores the Way,
> >                             Horses bear soldiers through
> >                                 its streets.
> >
> >                             --Lao Tzu (Peter Merel, trans.)
> >
> > -------------------
> > 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
> _____________________________________________________________________
> Envie de discuter en "live" avec vos amis ? Télécharger MSN Messenger
> http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de France

_____________________________________________________________________
Envie de discuter en "live" avec vos amis ? Télécharger MSN Messenger
http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de France

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

[Caml-list] Re:

[Nicolas Janin]

It would be interesting to know how many people are directly interested by
such a project (provided that many people won't say they are interested, but
will eventually use such a library when it is in a mature state).

----- Original Message -----
From: "SooHyoung Oh" <shoh@duonix.com>
To: "Matt Gushee" <mgushee@havenrock.com>; <caml-list@pauillac.inria.fr>
Sent: Saturday, July 26, 2003 3:41 AM


> Subject: Re: [Caml-list] Graphics frustration
> Date: Sat, 26 Jul 2003 10:37:20 +0900
> MIME-Version: 1.0
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: 7bit
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-Mailer: Microsoft Outlook Express 6.00.2600.0000
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
> X-Loop: caml-list@inria.fr
> X-Spam: no; 0.00; caml-list:01 gushee:01 mgushee:01 havenrock:01 all--:01
arc:99 ocamlplot:01 api:01 camlimages:01 englewood:01 manure:01
ignores:01 --lao:01 merel:01 bug:01
> Sender: owner-caml-list@pauillac.inria.fr
> Precedence: bulk
>
>
> What do you think about SVG (Selective Vector Graphics)?
> It uses only text for graphics as postscript so it's not difficult to use
> OCaml for SVG.
> If you interested about that, I'll send you a few examples.
>
> ---
> SooHyoung Oh
> ----- Original Message -----
> From: "Matt Gushee" <mgushee@havenrock.com>
> To: <caml-list@pauillac.inria.fr>
> Sent: Thursday, July 24, 2003 1:20 PM
> Subject: [Caml-list] Graphics frustration
>
>
> > Hello, all--
> >
> > I have been working on an application which will generate on-the-fly
> > graphics for the Web, but I have become very frustrated by the
> > limitations of the available graphics libraries for OCaml. If anyone
> > reading this thinks there are solutions I have overlooked, I would be
> > happy to discuss details. Right now, though, my purpose is to find out
> > whether others share my concerns, and how much interest there is in
> > developing better graphics libraries.
> >
> > What I would like to see is a single library with at least the
> > following capabilities:
> >
> >   * drawing primitives: line, rectangle, ellipse and/or arc, perhaps
> >     bezier curves
> >
> >   * rendering text with arbitrary Type 1 and/or TrueType fonts
> >
> >   * antialiasing
> >
> >   * basic image manipulation functions such as transformations,
> >     contrast adjustment, cropping, etc.
> >
> >   * saving to common bitmap formats such as JPEG and PNG
> >
> >   * cross-platform
> >
> > taking the various graphics packages together, all these capabilities
> > exist, but as far as I can tell there is no single package that combines
> > them all. So, in developing my application, I started out with
> > OCamlPlot, but discovered that it
> >
> >   - doesn't do antialiasing
> >
> >   - uses only 2 or 3 built-in fonts for PNG output
> >
> >   - has a rather rigid and idiosyncratic API
> >
> >   - doesn't run on Windows
> >
> > Then I decided to try MLgraph + Camlimages, which is an improvement, but
> > still falls short: MLgraph is excellent for drawing, but saves only to
> > PostScript--and I find the final result, converted to PNG with
> > CamlImages, rather unsatisfactory (the main problem is that antialiasing
> > doesn't work very well, which may actually be a Ghostscript issue).
> > Performance with this combination is also markedly poorer than with
> > OCamlPlot.
> >
> > Then there's OCamlGD, which seems quite promising. When complete, it
> > will probably satisfy all my requirements; but there hasn't been a
> > relesase in quite a while.
> >
> > So that's a quick summary of my situation. Do others agree with me that
> > this is a significant problem? Are there any good solutions in the
> > works?
> >
> > I am happy, by the way, to put some effort into developing something
> > better. My contribution would be limited, though (I'm not a C
> > programmer, for example, so I wouldn't be able to create a wrapper for
> > an existing C library.).
> >
> > Comments?
> >
> > --
> > Matt Gushee                 When a nation follows the Way,
> > Englewood, Colorado, USA    Horses bear manure through
> > mgushee@havenrock.com           its fields;
> > http://www.havenrock.com/   When a nation ignores the Way,
> >                             Horses bear soldiers through
> >                                 its streets.
> >
> >                             --Lao Tzu (Peter Merel, trans.)
> >
> > -------------------
> > 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
> _____________________________________________________________________
> Envie de discuter en "live" avec vos amis ? Télécharger MSN Messenger
> http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de France

_____________________________________________________________________
Envie de discuter en "live" avec vos amis ? Télécharger MSN Messenger
http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de France

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

[Caml-list] RE :

[Jean-Denis EIDEN]

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

unsubscribe



--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus

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

[Caml-list] Re:

[nathalielibertine]

[-- Attachment #1: Type: text/html, Size: 5315 bytes --]

[Caml-list] Re:

[Damien Doligez]

On Aug 23, 2004, at 22:27, briand@aracnet.com wrote:

> ~/src/ocaml/math $ ocaml
>         Objective Caml version 3.08.0
>
> # #load "const.cmo";;
> # Const.pi
>   ;;
> - : float = 3.14159265358979312
> #
>
>
> ~/src/ocaml/math $ cd ..
> ~/src/ocaml $ cd pll
> ~/src/ocaml/pll $ ocaml
>         Objective Caml version 3.08.0
>
> # #load "../math/const.cmo";;
> # Const.pi;;
> Unbound value Const.pi
>
> Huh ??

What is the type of Const.pi?  In order to answer this question, you 
have
to know the interface of module Const.  This interface lives in 
const.mli,
which is compiled to const.cmi.  It is automatically looked up in the
current directory, but not in ../math (unless you use option -I).

In other words, a module is composed of two things: its interface and
its implementation.  The interface is all you need to know at compile
time, while the implementation is all you need at execution time.  But
the toplevel does both compilation and execution, so it needs both.
The #load directive only provides the implementation.  You should also
add "../math" to the interface search path with the #directory 
directive:

# #load "../math/const.cmo";;
# #directory "../math";;
# Const.pi;;

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

[Caml-list] Re:

[alex]

This is an autoresponder. I'll never see your message.

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

[Brian Hurt]

They're teaching C++ as a first language these days.  You simply don't 
touch on the more complicated aspects of the language.  Or don't teach 
them until you're good and ready to teach them.

Brian

On Sat, 8 Mar 2003, Seth Kurtzberg wrote:

> My inclination is that this is perhaps not the best approach.  As OCaml is 
> using concepts and methods from a wide variety of languages, jumping straight 
> into OCaml might make it difficult for the student to understand and absorb 
> the different paradigms.
> 
> On Saturday 08 March 2003 01:53 am, Vee Satayamas wrote:
> > Hello,
> >
> > I 'm interested in using Caml as the
> > first language to teach student.
> > What is your opinion? Is there any
> > place use Caml as the first language
> > in programming course.
> >
> > Thank you,
> > Vee Satayamas
> >
> > =====
> > Please feel free to talk to me.
> > My homepage : http://www.geocities.com/liberalvee
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Everything you'll ever need on one web page
> > from News and Sport to Email and Music Charts
> > http://uk.my.yahoo.com
> >
> > -------------------
> > 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

[Caml-list] Re:

[Seth Kurtzberg]

My inclination is that this is perhaps not the best approach.  As OCaml is 
using concepts and methods from a wide variety of languages, jumping straight 
into OCaml might make it difficult for the student to understand and absorb 
the different paradigms.

On Saturday 08 March 2003 01:53 am, Vee Satayamas wrote:
> Hello,
>
> I 'm interested in using Caml as the
> first language to teach student.
> What is your opinion? Is there any
> place use Caml as the first language
> in programming course.
>
> Thank you,
> Vee Satayamas
>
> =====
> Please feel free to talk to me.
> My homepage : http://www.geocities.com/liberalvee
>
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com
>
> -------------------
> 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

-- 
Seth Kurtzberg
M. I. S. Corp.
480-661-1849
seth@cql.com

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

[Caml-list] Re:

[Alessandro Baretta]

I must advise you to download the O'Reilly caml-book, and
read through it. The answers to all your questions are in there.

http://caml.inria.fr/oreilly-book/

Alex


climb wrote:
>  i am quite confused about the orgnization of source files.
> i have programmed with java . java has a simple rule to orgnize files: one file contains one class(public) or interface, and name of the file and the class  must be identical.
> 
> As to Ocaml.
> Does the file name of *.ml or mli has some similar relation ship with the content ?
>   for example , in the on-line manul
>   it says :
>   if complie like this
>   ocaml -c aux.mli
>   ocaml -c aux.ml
>   behaves exactly as if 
>   module Aux: sig (* contents of aux.mli*) end = struct (*contents of aux.ml*) end;;
>   in the toplevel
>   that seems to imply the exsiting fo some relationship , but i still has these questions:
> 1) can many modules be write in just one file ? 
>    maybe not , then how does classes?

Yes. Modules can contain modules. Every compilation unit
automatically defines a module. An ".mli" defines the
signature of the module defined ecapsulating the
corresponding ".ml".

> 2) Is the multi sigs with one struct  or multi structs  with one sig  compiled at a prper dependency can get the same result that like as in the toplevel?   should i write anther file to tell them how to assigning?

I don't understand what you mean.

> 3) take set.ml and set.mli for example which defined one functor: Make and two sigs : S and OrderedType.  But when we use , we use this command    Set.Make(..).       "Set" here seem can only get from the name of the file. So it seems the file name determined the library name .  Then how about the noraml module (not functor) case that if i define a module A with a funtion a(), in file b.ml and b.mli, how can i refer to a() in module A.  A.a() or B.A.a() or B.a()? 
> 

As I already pointed out, the compiler encapsulates every
".ml" in its own module declaration, where the name of the
module is equal to the name of file, with the first letter
capitalized. Therefore, if you can write

> (* File x.ml *)
>
> module Abc = struct
>   let function_of_abc () = ...
> end


> (* File y.ml *)
>
> let _ = X.Abc.function_of_abc ()



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

[Caml-list] Re:

[Nicolas FRANCOIS]

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

Le Mon, 17 Jun 2002 15:23:09 +0200 (CEST) "Jun P.FURUSE"
<Jun.Furuse@inria.fr> a écrit :

> Hello,
> 
> > if (point_color ma_fourmi.x ma_fourmi.y) = white
> > is allways false under Ocaml.
> 
> If the following code says "BUG" in your environment, I am afraid that
> there is a bug inside the graphics library. In such case, could you
> send me the result of the command xdpyinfo in your environment ? 
> 
> (* ocamlc -o testgraphics graphics.cma testgraphics.ml *)
> open Graphics
> let _ = 
>     open_graph "";
>     if point_color 0 0 = white then 
>       prerr_endline "OK"
>     else prerr_endline "BUG"
> ;;

I received the bad answer :-(

You'll find the xdpyinfo output in attachment.

What can I do, boss ? Please !!!!!

\bye

-- 

                   Nicolas FRANCOIS
            http://nicolas.francois.free.fr
 A TRUE Klingon programmer does NOT comment his code

[-- Attachment #2: xdpyinfo.out --]
[-- Type: application/octet-stream, Size: 9720 bytes --]

name of display:    :0.0
version number:    11.0
vendor string:    The XFree86 Project, Inc
vendor release number:    40100000
XFree86 version: 4.1.0
maximum request size:  4194300 bytes
motion buffer size:  256
bitmap unit, bit order, padding:    32, LSBFirst, 32
image byte order:    LSBFirst
number of supported pixmap formats:    7
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 4, bits_per_pixel 8, scanline_pad 32
    depth 8, bits_per_pixel 8, scanline_pad 32
    depth 15, bits_per_pixel 16, scanline_pad 32
    depth 16, bits_per_pixel 16, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
    depth 32, bits_per_pixel 32, scanline_pad 32
keycode range:    minimum 8, maximum 255
focus:  window 0x180000e, revert to Parent
number of extensions:    26
    BIG-REQUESTS
    DOUBLE-BUFFER
    DPMS
    Extended-Visual-Information
    FontCache
    GLX
    LBX
    MIT-SCREEN-SAVER
    MIT-SHM
    MIT-SUNDRY-NONSTANDARD
    RENDER
    SECURITY
    SGI-GLX
    SHAPE
    SYNC
    TOG-CUP
    XC-APPGROUP
    XC-MISC
    XFree86-Bigfont
    XFree86-DRI
    XFree86-Misc
    XFree86-VidModeExtension
    XInputExtension
    XKEYBOARD
    XTEST
    XVideo
default screen number:    0
number of screens:    1

screen #0:
  dimensions:    1280x1024 pixels (433x347 millimeters)
  resolution:    75x75 dots per inch
  depths (7):    16, 1, 4, 8, 15, 24, 32
  root window id:    0x4d
  depth of root window:    16 planes
  number of colormaps:    minimum 1, maximum 1
  default colormap:    0x20
  default number of colormap cells:    64
  preallocated pixels:    black 0, white 65535
  options:    backing-store NO, save-unders NO
  largest cursor:    64x64
  current input event mask:    0x58007f
    KeyPressMask             KeyReleaseMask           ButtonPressMask          
    ButtonReleaseMask        EnterWindowMask          LeaveWindowMask          
    PointerMotionMask        SubstructureNotifyMask   SubstructureRedirectMask 
    PropertyChangeMask       
  number of visuals:    32
  default visual id:  0x23
  visual:
    visual id:    0x23
    class:    TrueColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x24
    class:    TrueColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x25
    class:    TrueColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x26
    class:    TrueColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x27
    class:    TrueColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x28
    class:    TrueColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x29
    class:    TrueColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x2a
    class:    TrueColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x2b
    class:    TrueColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x2c
    class:    TrueColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x2d
    class:    TrueColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x2e
    class:    TrueColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x2f
    class:    TrueColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x30
    class:    TrueColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x31
    class:    TrueColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x32
    class:    TrueColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x33
    class:    DirectColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x34
    class:    DirectColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x35
    class:    DirectColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x36
    class:    DirectColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x37
    class:    DirectColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x38
    class:    DirectColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x39
    class:    DirectColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x3a
    class:    DirectColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x3b
    class:    DirectColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x3c
    class:    DirectColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x3d
    class:    DirectColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x3e
    class:    DirectColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x3f
    class:    DirectColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x40
    class:    DirectColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x41
    class:    DirectColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
  visual:
    visual id:    0x42
    class:    DirectColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits

Re: [Caml-list] Re:

[stalkern2]

Alle ore 15:56, sabato 23 febbraio 2002, Nicolas FRANCOIS (AKA El Bofo) ha 
scritto:
> Si tu es sous Linux, tu ne PEUX PAS faire autrement qu'utiliser emacs et
> le mode tuareg. La, c'est presque parfait (il faut bien laisser du travail
> aux developpeurs ;-) Si vraiment tu ne peux pas faire autrement, il existe
> aussi un mode specialise pour Vi.

Sous Linux il y a aussi le très bon et très simple éditeur de ocamlbrowser. 
Ocamlbrowser est le candidat outil de développement de ocaml, il est fourni 
avec la distribution standard, il permet à la fois de feuilleter la 
documentation, d'avoir un éditeur multi-pages et d'ouvrir des toplevels 
interactifs doués de mémoire des commandes exécutés.

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

[Caml-list] Re:

[Nicolas FRANCOIS]

On Sun, 17 Feb 2002 17:05:02 +0100 (MET)
francois.hugel@free.fr wrote:

> Monsieur,
> j'ai le CD-ROM de l'INRIA avec le logiciel Caml Light, mais je ne sais
> pas comment accéder à un éditeur approprié pour taper des
> programmes.Pourriez-vous me renseigner,SVP, à l'adresse ci-dessous:
> francois.hugel@free.fr

Si tu es sous Window$, il suffit de lancer camlwin. Ca fait editeur (mal)
interactif, ca permet de se lancer. Assez rapidement, tu auras besoin d'un
editeur, si possible specialise. Tu trouveras cela sur le site de Caml
(pauillac.inria.fr/caml/), dans les ressources disponibles.

Si tu es sous Linux, tu ne PEUX PAS faire autrement qu'utiliser emacs et
le mode tuareg. La, c'est presque parfait (il faut bien laisser du travail
aux developpeurs ;-) Si vraiment tu ne peux pas faire autrement, il existe
aussi un mode specialise pour Vi.

Si tu es sos Mac... Heu, je ne sais pas.

\bye

-- 

                   Nicolas FRANCOIS
            http://nicolas.francois.free.fr
 A TRUE Klingon programmer does NOT comment his code
-------------------
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