SECOND CALL FOR PAPERS SECOND CALL FOR PAPERS
JFLA'2010 (http://jfla.inria.fr/2010/)
Journées Francophones des Langages Applicatifs
Organised by INRIA
from 30 January to 02 February 201
Hello,
In tried not getting into this discussion but I could not resist
commenting on the following:
Jacques Garrigue wrote:
>...
> ... There are applications for that (ray tracing is
> one), but this is not the kind of needs most people have.
>...
As with most technology people will or will no
Jon Harrop a écrit :
> If you want to draw aspirations based upon popularity, look at the most
> popular languages: Java and C#. [...]
I which world? Do you have references? These languages might be the most
commercially {backed,advertised,etc.}, so I guess you are refering to
the software indust
On Sep 25, 2009, at 6:07 AM, Jacques Garrigue wrote:
First, like everybody else, I'd like very much to try this out.
Is there any chance it could compile on Snow Leopard :-)
(I suppose it's near impossible, but still ask...)
I haven't tried that yet, mostly because I guess that it wouldn't wo
On Friday 25 September 2009 08:32:26 Hugo Ferreira wrote:
> Put it another way; if parallel/concurrent programming could be
> easily used with a minimum of effort then I believe "most people"
> would use it simply because it is available.
Once your run-time supports it, you just need a library tha
> On Friday 25 September 2009 08:32:26 Hugo Ferreira wrote:
>> Put it another way; if parallel/concurrent programming could be
>> easily used with a minimum of effort then I believe "most people"
>> would use it simply because it is available.
>
> Once your run-time supports it, you just need a lib
f my
> ray tracer benchmark is 10x slower with the new GC. However, this is
> anomalous with respect to complexity and the relative performance is much
> better for simpler renderings. For example, the new GC is only 1.7x slower
> with n=6 instead of n=9.
I just put a version with a bu
Dear Camlers,
Following a number of improvements in the repository, here is a new
release of LablGtk2, the ocaml interface to the Gtk+ GUI library and
friends (glade, rsvg, gnomecanvas, gnomedruid, panel, gtkspell,
gtksourceview2.)
This release is still based on the gtk+-2.12.x series, but the na
Jon Harrop wrote:
On Thursday 24 September 2009 13:39:40 Stefano Zacchiroli wrote:
On Thu, Sep 24, 2009 at 12:52:24PM +0100, Jon Harrop wrote:
The next steps are to get oc4mc into the apt repositories and build
Uhm, I'm curious: how do you plan to achieve that?
Good question. I have no idea,
Hello.
Sorry for reviving this short thread. I have the same error message, but
I really do not understand what "safety" means in this context.
If I specify the signature of the recursive module, shouldn't the type
checker work out right out of the box?
Sorry, but I'm a bit confused. You'll
On Friday 25 September 2009 05:07:21 Jacques Garrigue wrote:
> Your benchmark seems strange to me, as you are comparing apples with
> oranges.
In some sense, yes. I was interested in the performance of the
defacto-standard hash table implementations and not the performance that can
be obtained b
> Rethinking our application/algorithmic structure may not be a real
> deterrent. An application does not require parallel/concurrent
> processing everywhere. It is really a question of identifying where
> and when this is useful. Much like selecting the most "appropriate"
> data-structure for any
Hi everyone,
If there are anyone interested in it, please go to
http://github.com/ichernetsky/gentoo-overlay
It is a result of quick and dirty attempt, but it's usable anyway.
--
Yours sincerely,
Ivan Chernetsky.
___
Caml-list mailing list. Subscriptio
Hi everyone,
And let's have a little prayer for Philippe who is now in bed, suffering
from its head and hands because of his teammates letting him answer all
the mail.
Just (half) kidding.
So,
Xavier Leroy a wrote (and probably described the work quite well) :
what they did is an amazing h
> I will add that we did not made this experiment to beat F# or python's
> hashtables, so I will not comment on that here. The point about
> performance is that it should be *predictable*.
Perhaps an off-topic and naive question:
What does it take to beat F# and still
have predictable performance?
On Saturday 26 September 2009 01:45:50 kche...@math.carleton.ca wrote:
> Perhaps an off-topic and naive question: What does it take to beat F# and
> still have predictable performance?
Provided you're talking abouts today's machines and don't care about pause
times, HLVM with a parallel GC (not u
16 matches
Mail list logo
