Hi,
When M. Ober say the official material is of poor quality. i am
French and really surprise.
I saw Xavier Leroy teach caml at the CNAM in france, and he know how
to teach.
The official document is not an ocaml curse, that's right. (The
inria is not pay for that )
I have given recently
On Apr 1, 2009, at 8:59 AM, Mihamina Rakotomandimby (R12y) wrote:
FALCON Gilles RD-RESA-LAN wrote:
I totally agree that it would be pleasant to have more
documentation on Ocaml, especially if you don't have ocaml lesson.
Yes and No.
The problem can be felt in PHP, where you see anyone
the following are the most visible ocaml tutorials, but are low
quality, blog like, full of misleading characterizations,
irrevelancies, misleading comparisons. The type that you'd spend
hours on and got more confused, regardless whether you are a expert
logician or expert industrial
For distributing binaries, I build my quartz variant of MacPorts
as a subdirectory of the installation path that I wish to use
(/usr/local/Frama-C/lib/macports), and include in the distributed
archive those libraries that are necessary for running Frama-C.
See the contents of one of the Mac OS
On Mar 21, 2009, at 5:28 PM, Michael Ekstrand wrote:
Joel Reymont joe...@gmail.com writes:
On Mar 21, 2009, at 1:38 PM, Jon Harrop wrote:
. You will succumb to ocamlopt's current run-time representation
which is
objectively inefficient (e.g. boxing floats, tuples, records) and
was only
I'm using the readline for toplevel from programmer-monk for a while
now:
http://pmonk.net/svn/ocaml-misc/readline
I can use the up-down arrows easily which is usually enough. Still
when I try to do C-r for incremental backward search, it doesn't
work. Anybody knows how to enable it?
Of course, you can always say that you can use the foreign function
interface, but then you lose inlining and speed.
The same is true of C/C++. You can get much better performance from
assembler
but calling assembler from C or C++ not only costs inlining and
speed but
even functionality
i'm just trying to get my head around what it might look like, and
if/how it might be useful. (it just bugs me that somebody can claim
that C++ is the /only/ language that could do it -- maybe the real
quote implied mainstream or something. apparently Ada wasn't up to
snuff
I've worked a little bit with C++ using unboxed objects, that
is without introducing pointers (similar to boxing) in templates,
like listfigure instead of listfigure*, and passing them
as value in parameters, or returning them,
and it was far less efficient because there was lots of copy,
and you
On Mar 4, 2009, at 11:17 AM, Mikkel Fahnøe Jørgensen wrote:
When looking at the benchmark game and other benchmarks I have seen, I
noticed that Haskell is almost as fast as OCaml and sometimes faster.
Some Lisp implementations are also pretty fast.
However, when you look at memory consumption
Jon Harrop a écrit :
There are really two major advantages over the current ocamlopt
design and both stem from the use of JIT compilation:
. Run-time types allow per-type functions like generic pretty
printers and comparison.
. Monomorphisation during JIT compilation completely removes
I am developing a high-level virtual machine built upon LLVM and
written in
OCaml that uses JIT compilation to execute OCaml-like code at break-
neck
speeds.
I just stumbled upon a weird performance result: compiling my VM
with ocamlc
and ocamlopt produces very different benchmark results
industrial control process, audio processing share a need for others
pattern of allocation, solved using pools
of memory range of various size.
I think that there is a big class of realtime signal processing where
dynamic memory allocation is not only uncalled for, but would be a
: and the winner is NOT: Ocaml.
:
http://www.linuxquestions.org/questions/2008-linuxquestions.org-members-choice-awards-83/programming-language-of-the-year-695662/
Yeah right. A thousand folks who ask about Linux on a web site and
like PHP and Java, and preferring C# to Haskell, are going
Le 9 févr. 09 à 15:04, Romain Bardou a écrit :
However, there ARE some examples in the part which talks about
flag, where we clearly see an usage (After_rules).
Which doesn't mean it cannot be used differently.
Anyway it seems useless arguing further: we just don't have the same
On Jan 16, 2009, at 10:14 PM, Sashan Govender wrote:
I basically still hold that Yaron's original objection is baseless
in face
of established good OO practice in C++/Java/C#/...
I do understand the limitations of the popular OO model, of course,
and
the benefits of Jane Street
On Jan 17, 2009, at 8:27 AM, Jon Harrop wrote:
On Friday 16 January 2009 15:18:50 Kuba Ober wrote:
So, when correctly applied, what's so disturbing about inheritance?
Inheritance is disturbing because, in general, it cannot be applied
correctly.
That is why there are so many workarounds
On Jan 17, 2009, at 11:59 AM, Jon Harrop wrote:
On Saturday 17 January 2009 14:35:22 Kuba Ober wrote:
I wonder how such a hierarchy would be implemented in a natural way
in OCaml?
Assuming you stick with accepted wisdom, you would mimic the same
effects
using OCaml's object system, just
Yaron Minsky wrote a while ago that When we first tried switching
over from VB to C#,
one of the most disturbing features of the language to the partners
who read the code
was inheritance. They found it difficult to figure out which
implementation
of a given method was being invoked from a
On Jan 16, 2009, at 1:27 PM, Raoul Duke wrote:
the Liskov's substitution principle was violated. I have violated
it myself
...
So, when correctly applied, what's so disturbing about inheritance?
You
i like these food-for-thought / throw-gasoline-on-the-fire articles
about the general
On Jan 16, 2009, at 11:19 AM, Hugo Ferreira wrote:
Peter Ilberg wrote:
On Friday 16 January 2009 08:42:52 Hugo Ferreira wrote:
I have implemented a simple Prolog like inference engine
to be used in machine learning algorithms (ILP). My first
basic test shows that inference is dismally slow
Happy New Year everyone!
I just wanted to ping with an update: I planned
to do a lot of Camelia work over the holidays. That
never happened, as I was enjoying doing nothing much
and just having good time without doing any programming ;)
Now that school has started, and I'm taking a yet
another
On Tuesday 18 November 2008, you wrote:
On Mon, 2008-11-17 at 22:43 -0500, Kuba Ober wrote:
Please note that this is an early version, in particular the DOM
interface module is neither pretty nor well typed.
However, it can already be used to create little applets or scripts
On Tuesday 18 November 2008, Jon Harrop wrote:
On Monday 17 November 2008 16:20:50 Benjamin Canou wrote:
Hi,
O'Browser is an implementation of the OCaml virtual machine in
JavaScript, designed to run in web browsers.
It features a runtime library compatible with OCaml's standard one
On Monday 17 November 2008, Benjamin Canou wrote:
O'Browser is an implementation of the OCaml virtual machine in
JavaScript, designed to run in web browsers.
It features a runtime library compatible with OCaml's standard one
(including OOP and concurrent threads) and bindings of some
On Friday 07 November 2008, Jon Harrop wrote:
I was just perusing SourceForge and stumbled upon a popular software
package classed as being written partly in OCaml called WideStudio:
http://www.widestudio.org
This is apparently a cross platform IDE with a GUI toolkit that supports
several
On Wednesday 05 November 2008, Jon Harrop wrote:
On Tuesday 04 November 2008 23:06:00 Kuba Ober wrote:
On Tuesday 04 November 2008, Jon Harrop wrote:
You'll just be invoking autogenerated Python code using OCaml so
OCaml's class system is only relevant if you want to do some fancy
However, Trolltechs own demos segfault on my machine regularly
and KDE is unreliable despite being written almost entirely in Qt's native
language. So I would not be so hasty to blame PyQt for Qt's reliability
problems.
As a longtime KDE user, I'm very much disappointed by the most recent
Have you ran recent Qt demos distributed with Qt? I'd say they look
pretty cool in my book.
They would not have impressed me a decade ago, let alone today. Many of
them don't even work on either of my Debian machines.
I have one question regarding OpenGL: maybe it's just me, but isn't
On Wednesday 05 November 2008, Paolo Donadeo wrote:
In contrast, you can implement a GUI toolkit in OCaml that far exceeds
the relevant limitations of Qt4 with quite easily.
Jon, did you ever used Qt in a big C++ or Python project? Qt is the
best GUI framework out there, GTK is a ridiculous
On Wednesday 05 November 2008, Jon Harrop wrote:
On Wednesday 05 November 2008 15:20:26 Kuba Ober wrote:
[snip]
So, please understand that I'm not oblivious to benefits of thinking in
higher levels of abstraction, but I'm also practical and know that Qt
provides me with a whole big lot
And neither QPainterPath nor QPicture are really hierarchical. About the
only way to think of a hierarchy for Qt's drawing system is at the level
of QPainter, which provides save() / restore() functionality for its
state. All of this structure is implemented by the QPainter(), so as soon
On Wednesday 05 November 2008, Jérémie Dimino wrote:
Jon Harrop [EMAIL PROTECTED] writes:
I'd forget about that and just focus on making the whole of Qt4 available
safely from OCaml in any form first. Even this is an unsolved problem in
the OCaml world!
I suggest an idea. I know that Qt4
On Monday 03 November 2008, Jon Harrop wrote:
On Monday 03 November 2008 14:15:38 Kuba Ober wrote:
On Friday 31 October 2008, Jon Harrop wrote:
. Written in OCaml using OCaml's own lexer and parser to save effort
and make it possible for others to help develop it without losing
On Tuesday 04 November 2008, Jon Harrop wrote:
On Tuesday 04 November 2008 18:35:45 Kuba Ober wrote:
On Monday 03 November 2008, Jon Harrop wrote:
On Monday 03 November 2008 14:15:38 Kuba Ober wrote:
I could port Camelia to OCaml if
someone would first develop Qt bindings for OCaml
On Friday 31 October 2008, Jon Harrop wrote:
On Monday 20 October 2008 14:19:40 Kuba Ober wrote:
what do you guys use for your development environment?
I use Emacs but I hate it.
:)
What would be the minimal set of functionality that would make you happy
for an IDE?
. Written in OCaml
I've finished the initial part of translating Camelia
to Qt4. It now uses no Qt3 classes/methods, and compiles cleanly
with Qt3 support disabled. Some minor Qt3-isms were refactored,
but it's just a tip of the iceberg. I now have to get it into a running shape.
I commit to SVN every day or two,
On Wednesday 22 October 2008, you wrote:
Thanks, I tried it and I love the simplicity vis-a-vis eclipse's
baroqueness. But am I missing something?
When I type in a line of caml followed by a CR the cursor lines up all
the way to the left rather than indenting
on the next line. Once I'm doing
What would make me switch: a way to highlight the error when compiling,
highlighting the line, a stronger highlight for the character range
reported by the compiler, taking in consideration the tab mode used
(real tab, n spaces) to interpret the value returned by the compiler.
the error
What would make me switch: a way to highlight the error when compiling,
highlighting the line, a stronger highlight for the character range
reported by the compiler, taking in consideration the tab mode used (real
tab, n spaces) to interpret the value returned by the compiler.
the error
I really like OcaIDE (http://ocaml.eclipse.ortsa.com:8480/ocaide/).
It's Eclipse plugin so Windows is fully supported (including graphical
debugging). IMHO it's (almost) ready for commercial development. Many
features are very convenient: hyperlink jumps, code outline, type
tooltip on
I'm not sure that parsing ocamlbuild file is the right thing to do. For
a simple OCaml project (which would probably mean most Camelia
projects), there are no OCamlBuild files at all.
Mmmhhh there's .itarget (i.e. a list of files you wish generated
after compilation), but that's about
I thought of reading through the code and maybe contributing, but the fact
that it's all in C++ is holding me back a bit. Still, I'm going to take a
look once I have time.
Actually, porting the code to pure OCaml might prove the most interesting
task to me. I wonder what is the state of QT4
On Monday 20 October 2008, Romain Bardou wrote:
Kuba Ober a écrit :
I'm not sure that parsing ocamlbuild file is the right thing to do. For
a simple OCaml project (which would probably mean most Camelia
projects), there are no OCamlBuild files at all.
Mmmhhh there's .itarget (i.e
I use 16 (4x4) virtual Fvwm desktops with free mouse movement between
them and a small map of the desktops in the lower-right corner (+
xosview). The majority of the population finds this disturbing, I'm not
really sure why. I hate clicking or typing to switch from a window to
another so I
On Monday 20 October 2008, you wrote:
What are killer features you dream of?
Clearly, the ability to click on a function to go to the place where it is
defined is the only reason why I switched from emacs to Eclipse
I think that Camelia can do that -- it already fetches type annotations from
It'd be interesting to hear[1] what exact features of elisp are
counterproductive for large-scale collaborative programming.
I've not looked very closely at elisp, but assumed the reason that
emacs remains unconfigurable for most users is because it's Lisp,
not because of the particular
Here's the update from the trenches: I'm about 75% done
porting Camelia code to Qt4, the editor-related parts took
longer than anticipated since a lot of code had to change due
to the arguably better way that Qt4 handles text editing. The
code shrinks quite a bit in the process (20% or so, per the
Why do we need fork? I need to look at the code...
http://caml.inria.fr/pub/ml-archives/caml-list/1999/03/f44178e212e78826bcbd
ee52ddf6fd91.en.html
Concerning bytecode debugging under Windows, the major issue is the
way our debugger performs periodic checkpointing of the running program
On Wednesday 15 October 2008, Seo Sanghyeon wrote:
2008/10/15 Kuba Ober [EMAIL PROTECTED]:
For ia64, I don't care much, and if DDK provides masm-x64 then that's
probably good enough.
x64 usually means x86_64, not ia64.
Even so, 64 bit is out of my scope at this moment.
Cheers, Kuba
On Wednesday 15 October 2008, Dmitry Bely wrote:
On Wed, Oct 15, 2008 at 4:35 PM, Kuba Ober [EMAIL PROTECTED] wrote:
For example, if you download and install OCaml MSVC from
http://caml.inria.fr and you open a MS Visual Studio 2005 MSDOS shell,
you can perfectly compile a native application
Here's the recap from the discussion so far. I'm only considering
win32 platform, nothing else. Please pitch in if I didn't get it
right this time:
1. OCaml 3.11 will have a non-replaying bytecode debugger that runs
on native ports (built with msvc or mingw).
2. OCaml requires an installed C
On Wednesday 15 October 2008, Kuba Ober wrote:
6. ocamlopt can use either ml or masm for assembler; ml comes with
recent Visual Studios. When ml is not present, it would be good
to have it use nasm instead.
Replying to myself: ml == masm, and ml is present in all VS 2008 SP1,
including
On Wednesday 15 October 2008, David Allsopp wrote:
Kuba Ober write:
On Monday 13 October 2008, Seo Sanghyeon wrote:
2008/10/14 Kuba Ober [EMAIL PROTECTED]:
2. I need to get OCaml to use nasm instead of masm. I would go as far
as completely pruning any masm references from OCaml
Also, I don't think cygwin is bad. I just think it is not the
appropriate answer for most of us.
Cygwin is an answer if you can't code natively. If you insist on
using Unix mindset, then sure Cygwin is easiest. I don't see a problem
with OCaml doing things the Windows way on Windows,
On Tuesday 14 October 2008, Elliott Oti wrote:
Ocaml works fine on windows with the mingw and msys toolchain. Cygwin is
not needed. What you are doing with (1) and (2) would be duplicating msys.
Well, maybe (1) is not needed, then, but (2) surely wouldn't hurt as OCaml
tries to use masm. Maybe
Side note: is there an Ocaml bytecode-compiler written in Ocaml
somewhere?
I'm pretty sure the vast majority of the standard Ocaml bytecode
compiler is written in Ocaml. The same is probably not true for
the bytecode VM.
Chicken-and-egg question: how was it bootstrapped, at the dawn of
On Friday 03 October 2008, Erik de Castro Lopo wrote:
axllaruse wrote:
I would like to convert all the MTASC open source project to
C/C++ or PHP.
Sorry, but you're crazy.
MTASC is a compiler and compilers are one of the tasks that
Ocaml does better that all of the languages you mention.
On Thursday 07 August 2008, Kuba Ober wrote:
With this strategy, OCaml programs at Red Hat are performing as well
as C code, and about an order of magnitude faster an order of
magnitude lower memory usage than programs written in Python, which is
the main language used around here.
What
On Tuesday 15 July 2008, you wrote:
Am Dienstag, den 15.07.2008, 11:57 -0400 schrieb Kuba Ober:
On Thursday 10 July 2008, Gerd Stolpmann wrote:
Am Donnerstag, den 10.07.2008, 21:02 + schrieb Sylvain Le Gall:
On 10-07-2008, Gerd Stolpmann [EMAIL PROTECTED] wrote:
Am Donnerstag
It is a stop-gap solution...
That is not true. Many-core machines will always be decomposed into
shared-memory clusters of as many cores as possible because shared memory
parallelism will always be orders of magnitude more efficient than
distributed parallelism.
The way shared memory on
On Thursday 10 July 2008, Gerd Stolpmann wrote:
Am Donnerstag, den 10.07.2008, 21:02 + schrieb Sylvain Le Gall:
On 10-07-2008, Gerd Stolpmann [EMAIL PROTECTED] wrote:
Am Donnerstag, den 10.07.2008, 20:07 + schrieb Sylvain Le Gall:
On 10-07-2008, Gerd Stolpmann [EMAIL PROTECTED]
On Friday 09 May 2008, Richard Jones wrote:
On Fri, May 09, 2008 at 07:09:57PM +0100, Jon Harrop wrote:
F# has long since overtaken all other functional languages in terms of
industrial uptake and I have not heard that complaint from anyone. Like
OCaml, it follows simple rules and is
On Monday 12 May 2008, you wrote:
Yet, if you look at things in the light of optimization is
depessimization,
you'd much rather have easier to read code, than code which is ugly
because
you preoptimized it by hand. This is why, for me, Ocaml has a long way to
go
to make it useful for
5. Strings: pushing unicode throughout a general purpose language is a
mistake, IMHO. This is why languages like Java and C# are so slow.
Unicode by itself, when wider-than-byte encodings are used, adds zero
runtime overhead; the only overhead is storage (2 or 4 bytes per character).
Given
9. Deforestation: Brian says Haskell has introduced a very interesting and
(to my knowledge) unique layer of optimization, called deforrestation.
True, of course, but useless theoretical piffle because we know that
Haskell is slow in practice and prohibitively difficult to optimize
to-boot.
1. Lack of Parallelism: Yes, this is already a complete show stopper.
Exploiting multicores requires a scalable concurrent GC and message
passing (like JoCaml) is not a substitute. Unfortunately, this is now
true of all functional languages available for Linux, which is why we
have now
On Friday 09 May 2008, Ulf Wiger (TN/EAB) wrote:
Jon Harrop skrev:
On Friday 09 May 2008 14:00:52 you wrote:
Jon Harrop skrev:
. Parallelism is for performance and performance
requires mutable data structures.
I disagree. SMP Erlang has no mutable data structures,
but achieves
68 matches
Mail list logo
