Re: [Caml-list] about OcamIL
On 05/05/2010 02:06 PM, ben kuin wrote: I'm waiting for the day that microsoft release f# under a "official" open source license. It has been promised several times, but its still only available under the "Microsoft Research Shared Source license agreement" and meanwhile I'm not sure if it ever really happens. I cannot answer you question about OCamIL, but if you are interested in combining OCaml and .Net programming, you might be interested in our CSML tool which allows you to define bindings between the two worlds in a high-level way. We use it to develop large OCaml applications with a Winforms GUI and other .Net components. http://www.lexifi.com/csml/ Regards, Alain ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
Or use the real ocaml on a real OS (^_^) -- Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
--- On Wed, 5/5/10, Eray Ozkural wrote: > Or use the real ocaml on a real OS > (^_^) > I do not understand UNIX bigotry. Yes, Unix is technically superior to Windows. But Plan 9 is technically superior to Unix. But I doubt Eray is running Plan 9. More computers run Windows than all other OS's combined. If you want a large user base you need to support Windows. If you do not care about the size of your user base, write for Plan 9. Personalty I try to support as many systems as practical. It bothers me that the Ocaml community seems to consider Windows developers as second class citizens. Until this changes Ocaml will never be a main stream language. F# may eat it's lunch. But F# is tied to Windows, Ocaml has the potential to be multi-platform. I just wish it would live up to this potential. -EdK Ed Keith e_...@yahoo.com Blog: edkeith.blogspot.com ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
http://caml.inria.fr/download.en.html Well, it is actually available on Windows. And mind you, there is some popular windows software written in ocaml. We were taking a look at haxe the other day. The F# makes use of the (pretty good designed) .net CLR. Which isn't a bad thing at all, but it's not my cup of tea. :) On the other hand, starting an ocaml interpreter on windows makes me feel a bit like a caveman touching a spaceship's gleaming surface. Cheers and take it easy, -- Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
> Or use the real ocaml on a real OS (^_^) my vision is a unix centric clr based vm: - no non-ecma parts - maybe a complete different base class library (like OcamIL) - the target is not to enable windows apps on unix, but the other way around - the vm is crossplattform, the bytecode is compatible to mono and ms-.net but the library is incopatible to the standard .net stack ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
Le 5 mai 10 à 21:16, Ed Keith a écrit : --- On Wed, 5/5/10, Eray Ozkural wrote: Or use the real ocaml on a real OS (^_^) I do not understand UNIX bigotry. Yes, Unix is technically superior to Windows. But Plan 9 is technically superior to Unix. But I doubt Eray is running Plan 9. More computers run Windows than all other OS's combined. If you want a large user base you need to support Windows. If you do not care about the size of your user base, write for Plan 9. Personalty I try to support as many systems as practical. It bothers me that the Ocaml community seems to consider Windows developers as second class citizens. Until this changes Ocaml will never be a main stream language. F# may eat it's lunch. But F# is tied to Windows, Ocaml has the potential to be multi-platform. I just wish it would live up to this potential. I guess you shouldn't take some stup** trollism as representing the whole community thinking though. I am not a Windows user but this kind of "Windows sucks" remark pisses me off. Still, it's a fact that it's hard to use ocaml on Windows but there are frequently some posts on this list showing that many ocamlers do care about Windows. The Ocaml Team explicitly requests some help of windows users to test the releases because they know it's a downside of ocaml. I think this shows that they really seem to care about it and try to improve. V. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
keith, a few thoughts, ... before I've worked with linux I was a windows guy. I remember the day (forgot the context though) when I installed the ocaml package on my dell/windows-xp/laptop (yuk) . Since the workflow on windows is very gui centric, you can't help to get very sensible how a particular app looks and feels. I can tell you those "weird" guis (tcl/tk?) scared the hell out of me and I hoped I could get rid of the stuff without breaking the registry :-). Anyway, I think in order to provide something that the next windows user would like to work with, all the ocaml gui apps should be feel very much more native. Maybe the time would be better invested by an effort to port Ocaml-Batteries to F#. I mean why not? On Wed, May 5, 2010 at 3:16 PM, Ed Keith wrote: > --- On Wed, 5/5/10, Eray Ozkural wrote: > >> Or use the real ocaml on a real OS >> (^_^) >> > > I do not understand UNIX bigotry. > > Yes, Unix is technically superior to Windows. But Plan 9 is technically > superior to Unix. But I doubt Eray is running Plan 9. > > More computers run Windows than all other OS's combined. If you want a large > user base you need to support Windows. If you do not care about the size of > your user base, write for Plan 9. > > Personalty I try to support as many systems as practical. > > It bothers me that the Ocaml community seems to consider Windows developers > as second class citizens. Until this changes Ocaml will never be a main > stream language. F# may eat it's lunch. But F# is tied to Windows, Ocaml has > the potential to be multi-platform. I just wish it would live up to this > potential. > > -EdK > > Ed Keith > e_...@yahoo.com > > Blog: edkeith.blogspot.com > > > > > > ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
I think the main problem is the lack of cross platform gui that looks good on windows. LablTk: ok only for simple gui LablGtk:fragile on linux, bad on windows qt: I once tried to create bindings for a newer qt release ( > 4.2), I didn't finished it, but I think it would be doable. The big problem though is the huge qt dependency with this blackboxy C++/moc thing . On Wed, May 5, 2010 at 6:13 PM, Vincent Aravantinos wrote: > > Le 5 mai 10 à 21:16, Ed Keith a écrit : > >> --- On Wed, 5/5/10, Eray Ozkural wrote: >> >>> Or use the real ocaml on a real OS >>> (^_^) >>> >> >> I do not understand UNIX bigotry. >> >> Yes, Unix is technically superior to Windows. But Plan 9 is technically >> superior to Unix. But I doubt Eray is running Plan 9. >> >> More computers run Windows than all other OS's combined. If you want a >> large user base you need to support Windows. If you do not care about the >> size of your user base, write for Plan 9. >> >> Personalty I try to support as many systems as practical. >> >> It bothers me that the Ocaml community seems to consider Windows >> developers as second class citizens. Until this changes Ocaml will never be >> a main stream language. F# may eat it's lunch. But F# is tied to Windows, >> Ocaml has the potential to be multi-platform. I just wish it would live up >> to this potential. > > I guess you shouldn't take some stup** trollism as representing the whole > community thinking though. > I am not a Windows user but this kind of "Windows sucks" remark pisses me > off. > > Still, it's a fact that it's hard to use ocaml on Windows but there are > frequently some posts on this list showing that many ocamlers do care about > Windows. > The Ocaml Team explicitly requests some help of windows users to test the > releases because they know it's a downside of ocaml. > I think this shows that they really seem to care about it and try to > improve. > > V. > ___ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
On Thu, May 6, 2010 at 1:36 AM, ben kuin wrote: > I think the main problem is the lack of cross platform gui that looks > good on windows. > > LablTk: ok only for simple gui > LablGtk: fragile on linux, bad on windows > qt: I once tried to create bindings for a newer qt release ( > > 4.2), I didn't finished it, but I think it would be doable. The big > problem though is the huge qt dependency with this blackboxy C++/moc > thing . yeah i tried my hand once too :/ i've been thinking about this. perhaps the best bet is to write a proper gui toolkit in ocaml. after all this is the most productive programming language, right? :D i remember a lot of interesting gui frameworks and approaches for functional languages. i bet we could create a much better api than any of those once we get rid of the low-level low-tech approach to gui programming. why don't we write a google summer of code proposal for that? perhaps some enthusiastic students would take up the challenge. it could be divided into some stages, for instance abstracting over x11/win32(horrors!) windowing systems first cheers, -- Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara http://groups.yahoo.com/group/ai-philosophy http://myspace.com/arizanesil http://myspace.com/malfunct ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
On Wed, May 5, 2010 at 11:16 PM, Ed Keith wrote: > It bothers me that the Ocaml community seems to consider Windows developers > as second class citizens. Until this changes > Ocaml will never be a main stream language. I think it's not really that bad. Ocaml developers support Windows as a first class platform. Many Ocaml libraries can be build under Windows without a problem. And now GODI supports Windows too. > F# may eat it's lunch. But F# is tied to Windows, Ironically it's also not entirely true. F# works well under Mono/Unix. Maybe it will even be faster than Ocaml for some applications due to threads running in parallel on multiple cores. But F# is very different from Ocaml. - Dmitry Bely ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
> for instance abstracting over > x11/win32(horrors!) windowing systems first you're an optimist :-) On Wed, May 5, 2010 at 7:13 PM, Eray Ozkural wrote: > On Thu, May 6, 2010 at 1:36 AM, ben kuin wrote: >> I think the main problem is the lack of cross platform gui that looks >> good on windows. >> >> LablTk: ok only for simple gui >> LablGtk: fragile on linux, bad on windows >> qt: I once tried to create bindings for a newer qt release ( > >> 4.2), I didn't finished it, but I think it would be doable. The big >> problem though is the huge qt dependency with this blackboxy C++/moc >> thing . > > yeah i tried my hand once too :/ i've been thinking about this. > perhaps the best bet is to write a proper gui toolkit in ocaml. after > all this is the most productive programming language, right? :D i > remember a lot of interesting gui frameworks and approaches for > functional languages. i bet we could create a much better api than any > of those once we get rid of the low-level low-tech approach to gui > programming. why don't we write a google summer of code proposal for > that? perhaps some enthusiastic students would take up the challenge. > it could be divided into some stages, for instance abstracting over > x11/win32(horrors!) windowing systems first > > cheers, > > -- > Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara > http://groups.yahoo.com/group/ai-philosophy > http://myspace.com/arizanesil http://myspace.com/malfunct > ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
> 1. [...] it would still require some time to rewrite a few parts. Release early, release often. Maybe you put it under your name on sourceforge, if you are afraid to put potentially non-buildable code under the flags of lexifi. > 2. Similarly, we rely on our "extended standard library" (a collection of > general purpose modules). That sounds interesting! > Again, it would take some time to extract the few > needed function to make a standalone distribution. Release early, release o... > 3. [...] At some point, we planned to sell a version of CSML as > an extra module to this platform If this is about biz vs. oss, then it could be a solution to go the path of PyQT: - offer of a GPL version - sell a version that can be used commercially On Thu, May 6, 2010 at 4:40 AM, Alain Frisch wrote: > On 05/05/2010 11:46 PM, ben kuin wrote: >> >> thats interesting indeed, is there a particular reason you wont >> release the csml compiler sources and provide only the binaries? > > Yes, there are several reasons: > > 1. The code uses some local extensions to the OCaml compiler that are not > available in the INRIA version; this is less true today because some of our > extensions have been integrated upstream, but it would still require some > time to rewrite a few parts. > > 2. Similarly, we rely on our "extended standard library" (a collection of > general purpose modules). Again, it would take some time to extract the few > needed function to make a standalone distribution. > > 3. We sell a development platform for financial applications, which includes > our modified version of OCaml and advanced libraries for the manipulation of > financial concepts. At some point, we planned to sell a version of CSML as > an extra module to this platform (the public version of CSML does not > support some extra features). It hasn't been formally decided yet, but we > might change our plans regarding this issue. > > > We did not get any feedback from the community regarding this tool, so we > haven't felt any motivation to address point 1 and 2 above, or to reconsider > our position in point 3. If you plan to use CSML, let us know about your > projects, and we might find some arrangement (either a custom license with > source code at no charge for you, or a real open-source license). > > Regards, > > Alain Frisch > > > ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
--- On Wed, 5/5/10, ben kuin wrote: > From: ben kuin > Subject: Re: [Caml-list] about OcamIL > To: "Ed Keith" , caml-list@yquem.inria.fr > Date: Wednesday, May 5, 2010, 6:18 PM > keith, a few thoughts, ... before > I've worked with linux I was a > windows guy. I remember the day (forgot the context though) > when I > installed the ocaml package on my dell/windows-xp/laptop > (yuk) . Since > the workflow on windows is very gui centric, you can't help > to get > very sensible how a particular app looks and feels. I can > tell you > those "weird" guis (tcl/tk?) scared the hell out of me and > I hoped I > could get rid of the stuff without breaking the registry > :-). > > Anyway, I think in order to provide something that the next > windows > user would like to work with, all the ocaml gui apps should > be feel > very much more native. > > Maybe the time would be better invested by an effort to > port > Ocaml-Batteries to F#. I mean why not? > > > On Wed, May 5, 2010 at 3:16 PM, Ed Keith > wrote: Actually I always have one or more command prompts open on my Windows box. A command line is so much more efficient than a GUI for many tasks. -EdK Ed Keith e_...@yahoo.com Blog: edkeith.blogspot.com ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
lablGTK2 on linux is not fragile! Its robust, well designed, and produces nice guis! (at least on debian. props to the packagers and developers, if you're listening) On Wed, May 5, 2010 at 6:36 PM, ben kuin wrote: > I think the main problem is the lack of cross platform gui that looks > good on windows. > > LablTk: ok only for simple gui > LablGtk: fragile on linux, bad on windows > qt: I once tried to create bindings for a newer qt release ( > > 4.2), I didn't finished it, but I think it would be doable. The big > problem though is the huge qt dependency with this blackboxy C++/moc > thing . ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 06 May 2010 06:43:21 am Dmitry Bely wrote: > Ironically it's also not entirely true. F# works well under Mono/Unix. > > - Dmitry Bely > A little off topic, but how is Mono/Unix these days? Last I checked (>2 years ago) it implemented the basic libraries and runtimes but had terrible performance. Is it now on par with Windows? Thanks, Peng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFL4u9DfIRcEFL/JewRAlvRAJ4t7waiAbNJL7zyo/baAOzZxjiM/QCfZkST dakL+vN3hqa/Tff2F+Qe20A= =pURF -END PGP SIGNATURE- ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
> On Thursday 06 May 2010 06:43:21 am Dmitry Bely wrote: >> Ironically it's also not entirely true. F# works well under Mono/Unix. >> > A little off topic, but how is Mono/Unix these days? Last I checked (>2 years > ago) it implemented the basic libraries and runtimes but had terrible > performance. Is it now on par with Windows? It's hard to say: personally I don't use Mono (neither Windows nor Linux) yet. But indeed I was overoptimistic. Mono still uses Boehm GC so it should be slow enough. Nevertheless things are changing: http://www.mono-project.com/Compacting_GC http://lists.ximian.com/pipermail/mono-devel-list/2009-November/033421.html Let's wait for mono 2.8 and see how the new generational GC works. - Dmitry Bely ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] about OcamIL
> A little off topic, but how is Mono/Unix these days? Last I checked > (>2 years ago) it implemented the basic libraries and runtimes but had terrible > performance. Is it now on par with Windows? Still leaks memory, has broken TCO and runs like a dog. Mono has also fallen even farther behind now that .NET 4 is out. However, they have at least stated that they intend to start trying to support F# on Mono. Then again, they stated about 6 years ago they were going to replace their crappy conservative GC with one that might actually work but they never managed to do that either... Cheers, Jon. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
> A little off topic, but how is Mono/Unix these days? >> Still leaks memory, you refer to your examinations? (http://flyingfrogblog.blogspot.com/2009/01/mono-22-still-leaks-memory.html?showComment=1233522107493#c7872630239059031867) where you say yes and the mono devs are say no to memory leaking? >> has broken TCO Again, I think other people do not have the same opion on this ( http://flyingfrogblog.blogspot.com/2009/01/mono-does-not-support-tail-calls.html) >> and runs like a dog I think this on the other hand is indeed a problem and has been documented seriously (also by you: http://flyingfrogblog.blogspot.com/2009/01/mono-22.html) I've introduced the post with some license related concerns, maybe I should take a step back and think about what I want: 1. - programming in a ML like language ( especially the caml family since I really like those lightweigt type definitions and the pattern matching that can be applied on those) 2. - high performance runtime, preferably a jit based vm, no problems with TCO 3. - a true open source license (approved by Open Source Initiative or by Free Software Foundation) I think this 3 point are REASONABLE but the combination of those 3 items is INEXISTENT. Ocaml: the vm is not very fast (no jit AFAIK) F#: No open source license so far. Bad runtime performance on mono. Ocaml on HLVM: I would appreciate if Jon could make a clear statement if this is something serious or just a little toy. Scala: Not really a ML language: I think it's kind of fun to try to emulate ocaml features or try to port ocaml apps to scala. The problem is the actual work is never going to be finished. I have some concerns the the runtime performance is unpredictable (no TCO, a lot of hacks into the JVM) Yeti: I like the language, but it is in a experimental stage Nekoml: Supercool project, but the vm is not the fastest and jit runs only on x86 platforms So I guess the best thing would be to use good ol Ocaml in native mode...? A last idea: What do you think about libjit? They claim that a jvm/clr like runtime could be built in weeks. Wouldn't it be nice to have a fast vm for Ocaml (ocamljit) ? Does someone has experience with this, I think writing a fast vm is hard, but a fast vm for a functional language is nearly impossible? Maybe OcamIL could then be used as a model for a jit backend, since its MSIL output already runs on libjit (DotGnu, alias pnet) On Mon, May 10, 2010 at 11:53 PM, Jon Harrop wrote: >> A little off topic, but how is Mono/Unix these days? Last I checked >> (>2 years ago) it implemented the basic libraries and runtimes but had > terrible >> performance. Is it now on par with Windows? > > Still leaks memory, has broken TCO and runs like a dog. Mono has also fallen > even farther behind now that .NET 4 is out. However, they have at least > stated that they intend to start trying to support F# on Mono. Then again, > they stated about 6 years ago they were going to replace their crappy > conservative GC with one that might actually work but they never managed to > do that either... > > Cheers, > Jon. > > > ___ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 11 May 2010 07:22:56 am ben kuin wrote: > I think this 3 point are REASONABLE but the combination of those 3 > items is INEXISTENT. > > Ocaml: the vm is not very fast (no jit AFAIK) > > > So I guess the best thing would be to use good ol Ocaml in native mode...? > What do you mean by vm? OCaml doesn't have a vm like the jvm. Although there's been some great work on compiling OCaml for the jvm. OCaml does have a toplevel interpreter. It even has a native mode toplevel now that's suppose to be fast (anyone have any experience with this?). So that's good. And of course as you pointed out you can always compile OCaml code to native machine code which has always had good performance. Peng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD4DBQFL6YhCfIRcEFL/JewRAuB7AJ9tDRHgDJGt3+VqmX4u/IxU+vRXyQCWL3NX SkKhph4GC7xGA85ilSspTw== =IxIG -END PGP SIGNATURE- ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
On Tue, May 11, 2010 at 9:39 AM, Peng Zang wrote: > And of course as you pointed out you can always compile OCaml code to native > machine code which has always had good performance. i was under the impression the main complaint is lack of top-notch support for concurrency? ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
> 1. - programming in a ML like language ( especially the caml family > since I really like those lightweigt type definitions and the pattern > matching that can be applied on those) > > 2. - high performance runtime, preferably a jit based vm, no problems with TCO > > 3. - a true open source license (approved by Open Source Initiative or > by Free Software Foundation) > > I think this 3 point are REASONABLE but the combination of those 3 > items is INEXISTENT. i, for one, am hoping Shen comes through for us. http://groups.google.com/group/qilang ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
> OCaml doesn't have a vm like the jvm. ocamlc compiles to bytecode ocamlrun interprets the bytecode bytecode interpreter == vm hence ocaml has a vm On Tue, May 11, 2010 at 6:39 PM, Peng Zang wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > On Tuesday 11 May 2010 07:22:56 am ben kuin wrote: >> I think this 3 point are REASONABLE but the combination of those 3 >> items is INEXISTENT. >> >> Ocaml: the vm is not very fast (no jit AFAIK) >> >> >> So I guess the best thing would be to use good ol Ocaml in native mode...? >> > > What do you mean by vm? OCaml doesn't have a vm like the jvm. Although > there's been some great work on compiling OCaml for the jvm. OCaml does have > a toplevel interpreter. It even has a native mode toplevel now that's > suppose to be fast (anyone have any experience with this?). So that's good. > And of course as you pointed out you can always compile OCaml code to native > machine code which has always had good performance. > > Peng > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.7 (GNU/Linux) > > iD4DBQFL6YhCfIRcEFL/JewRAuB7AJ9tDRHgDJGt3+VqmX4u/IxU+vRXyQCWL3NX > SkKhph4GC7xGA85ilSspTw== > =IxIG > -END PGP SIGNATURE- > ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ah, I guess I think of ocamlrun as just an interpreter. But you're right, that's also a vm. Peng On Tuesday 11 May 2010 07:47:25 pm ben kuin wrote: > > OCaml doesn't have a vm like the jvm. > > ocamlc compiles to bytecode > ocamlrun interprets the bytecode > bytecode interpreter == vm > hence ocaml has a vm > > On Tue, May 11, 2010 at 6:39 PM, Peng Zang wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On Tuesday 11 May 2010 07:22:56 am ben kuin wrote: > >> I think this 3 point are REASONABLE but the combination of those 3 > >> items is INEXISTENT. > >> > >> Ocaml: the vm is not very fast (no jit AFAIK) > >> > >> > >> So I guess the best thing would be to use good ol Ocaml in native > >> mode...? > > > > What do you mean by vm? OCaml doesn't have a vm like the jvm. Although > > there's been some great work on compiling OCaml for the jvm. OCaml does > > have a toplevel interpreter. It even has a native mode toplevel now > > that's suppose to be fast (anyone have any experience with this?). So > > that's good. And of course as you pointed out you can always compile > > OCaml code to native machine code which has always had good performance. > > > > Peng > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v2.0.7 (GNU/Linux) > > > > iD4DBQFL6YhCfIRcEFL/JewRAuB7AJ9tDRHgDJGt3+VqmX4u/IxU+vRXyQCWL3NX > > SkKhph4GC7xGA85ilSspTw== > > =IxIG > > -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFL6gscfIRcEFL/JewRAgWBAJ93Hee3UhXDbLdX+bCuQs3Vwx72mQCaA/e4 G5U5E2pOf5NY3QvcciaenuU= =W6jj -END PGP SIGNATURE- ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] about OcamIL
Peng Zang wrote: > It even has a native mode toplevel now that's > suppose to be fast (anyone have any experience with this?). You mean "ocamlnat"? The performance was great but it was buggy and I think it never made it into mainline OCaml. Cheers, Jon. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] about OcamIL
Ben Kuin wrote: > > A little off topic, but how is Mono/Unix these days? > >> Still leaks memory, > you refer to your examinations? > (http://flyingfrogblog.blogspot.com/2009/01/mono-22-still-leaks- > memory.html?showComment=1233522107493#c7872630239059031867) > where you say yes and the mono devs are say no to memory leaking? Yes. > >> has broken TCO > Again, I think other people do not have the same opion on this ( > http://flyingfrogblog.blogspot.com/2009/01/mono-does-not-support-tail- > calls.html) Yes. They are wrong. > I've introduced the post with some license related concerns, maybe I > should take a step back and think about what I want: > > 1. - programming in a ML like language ( especially the caml family > since I really like those lightweigt type definitions and the pattern > matching that can be applied on those) > > 2. - high performance runtime, preferably a jit based vm, no problems > with TCO > > 3. - a true open source license (approved by Open Source Initiative or > by Free Software Foundation) > > I think this 3 point are REASONABLE but the combination of those 3 > items is INEXISTENT. I'm afraid the situation is far worse. Even if you relax your conditions from "ML-like" to any functional language and even allow broken TCO, there are not only no language implementations satisfying those weaker conditions but nobody is even trying to create such a language implementation. > Ocaml on HLVM: I would appreciate if Jon could make a clear statement > if this is something serious or just a little toy. HLVM is not yet ready for serious use and it may well never compile OCaml but at least it is now compiling code like this: http://flyingfrogblog.blogspot.com/2010/04/variant-types-and-pattern-matchin g-in.html > A last idea: What do you think about libjit? They claim that a jvm/clr > like runtime could be built in weeks. Wouldn't it be nice to have a > fast vm for Ocaml (ocamljit) ? Does someone has experience with this, > I think writing a fast vm is hard, but a fast vm for a functional > language is nearly impossible? Maybe OcamIL could then be used as a > model for a jit backend, since its MSIL output already runs on libjit > (DotGnu, alias pnet) I think LLVM is a much better choice than libjit. Once you've got that kind of solid foundation to build upon and a decent language like OCaml to write in, you can write a decent FPL implementation in a few man-months. The problem is finding the time... Cheers, Jon. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] about OcamIL
Jon Harrop a écrit : Ben Kuin wrote: I've introduced the post with some license related concerns, maybe I should take a step back and think about what I want: 1. - programming in a ML like language ( especially the caml family since I really like those lightweigt type definitions and the pattern matching that can be applied on those) 2. - high performance runtime, preferably a jit based vm, no problems with TCO 3. - a true open source license (approved by Open Source Initiative or by Free Software Foundation) I think this 3 point are REASONABLE but the combination of those 3 items is INEXISTENT. I'm afraid the situation is far worse. Even if you relax your conditions from "ML-like" to any functional language and even allow broken TCO, there are not only no language implementations satisfying those weaker conditions but nobody is even trying to create such a language implementation. Putting aside an answer I posted this morning on a parallel thread, I will just present some counter examples to this claim. Limiting myself to the JVM, and not even trying to be exhaustive, I can find... ... in the LISP family : - Clojure - http://clojure.org/ - Eclipse Public License ... in the Scheme family : - Bigloo - http://www-sop.inria.fr/indes/fp/Bigloo/ - GPL / LGPL - Kawa - http://www.gnu.org/software/kawa/ - X11 / MIT license - SISC - http://sisc-scheme.org/ - GPL ... in the ML family: - Yeti - http://mth.github.com/yeti/ ... in the Haskell family: - CAL - http://openquark.org/Open_Quark/Welcome.html - BSD-like license ... in its own family: - Scala - http://www.scala-lang.org Moreover, at least Scala and Bigloo deliver excellent performances. Regards, Xavier Clerc ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] about OcamIL
Xavier Clerc wrote: > Limiting myself to the JVM... > Moreover, at least Scala and Bigloo deliver excellent performances. I have benchmarks where the JVM is well over 10x slower than .NET. So I do not regard any JVM-based language as "high performance". Cheers, Jon. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
On Fri, May 14, 2010 at 1:40 PM, Jon Harrop wrote: > Xavier Clerc wrote: >> Limiting myself to the JVM... >> Moreover, at least Scala and Bigloo deliver excellent performances. > > I have benchmarks where the JVM is well over 10x slower than .NET. So I do > not regard any JVM-based language as "high performance". You got a point there. JVM has a ridiculous performance, not fitting for any computationally expensive operation. At best it's some kind of mudware for data plumbing and simple network applications. The memory system, whatever it is doing, is absolutely terrible. I've implemented some semi-sophisticated information retrieval code on it (related to a search engine) and I've seen that it's not only much slower but horribly bloated memory-wise as well. You can only use it for toy problems. And there are even papers using Java/MPI for high performance computing! Using Java still turns any computer to a Commodore 64, so why are people using it? Cheers, -- Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara http://groups.yahoo.com/group/ai-philosophy http://myspace.com/arizanesil http://myspace.com/malfunct ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
Le 14 mai 2010 à 12:58, Eray Ozkural a écrit : > On Fri, May 14, 2010 at 1:40 PM, Jon Harrop > wrote: >> Xavier Clerc wrote: >>> Limiting myself to the JVM... >>> Moreover, at least Scala and Bigloo deliver excellent performances. >> >> I have benchmarks where the JVM is well over 10x slower than .NET. So I do >> not regard any JVM-based language as "high performance". > > You got a point there. > > JVM has a ridiculous performance, not fitting for any computationally > expensive > operation. At best it's some kind of mudware for data plumbing and > simple network > applications. The memory system, whatever it is doing, is absolutely > terrible. I've > implemented some semi-sophisticated information retrieval code on it > (related to a > search engine) and I've seen that it's not only much slower but > horribly bloated > memory-wise as well. You can only use it for toy problems. > > And there are even papers using Java/MPI for high performance computing! > Using Java still turns any computer to a Commodore 64, so why are > people using it? If it is not considered as too much off-topic for this mailing list, could one of you provide references to such benchmarks rather than just state that they exist. Regards, Xavier Clerc ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
Le 14 mai 2010 à 12:40, Jon Harrop a écrit : > Xavier Clerc wrote: >> Limiting myself to the JVM... >> Moreover, at least Scala and Bigloo deliver excellent performances. > > I have benchmarks where the JVM is well over 10x slower than .NET. So I do > not regard any JVM-based language as "high performance". Quite ironically, by scratching the surface, one would discover that both quoted projects can also target .NET (not tested that though). Regards, Xavier Clerc ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] about OcamIL
--- On Fri, 5/14/10, Jon Harrop wrote: > From: Jon Harrop > Subject: RE: [Caml-list] about OcamIL > To: caml-list@yquem.inria.fr > Date: Friday, May 14, 2010, 6:40 AM > Xavier Clerc wrote: > > Limiting myself to the JVM... > > Moreover, at least Scala and Bigloo deliver excellent > performances. > > I have benchmarks where the JVM is well over 10x slower > than .NET. So I do > not regard any JVM-based language as "high performance". I have never used it, but I believe Scala works with .NET. -EdK Ed Keith e_...@yahoo.com Blog: edkeith.blogspot.com ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
Jon Harrop writes: > Xavier Clerc wrote: >> Limiting myself to the JVM... >> Moreover, at least Scala and Bigloo deliver excellent performances. > > I have benchmarks where the JVM is well over 10x slower than .NET. So I do > not regard any JVM-based language as "high performance". > > Cheers, > Jon. You can pretty much write a benchmark for any 2 languages that specifically targets the weekness of one and the strength of the other showing that one is better than the other by a wide margin. You can usualy reverse the argument with a different benchmark. So your argument as such says nothing about JVM, just something about your benchmarks. MfG Goswin ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
> So your argument as such says nothing about JVM jon-bot: yes it does, look at those numbers here: ... goswin-bot: no it doesn't because: ... startup time ... hotspot ... server ... jon-bot: moron goswin-bot: liar So far the typical java-shootout pattern. Maybe another approach would be to compare the JVM and the CLR in the realworld. I think it's interesting that on the ms-windows platform .net is used for everything with great success: - desktop apps (mostly .net: windows forms, wpf / c++ is dying) - web apps (mostly .net: asp.net / asp and com are dead) - backend services (c++ and .net apis: sharepoint, ... / dcom is dying) Compared to that I think the jvm is only succesful when it comes to 'backend services', which often play an important role in big and often technically conservative companies. There are (great) desktop and web apps in java but they require much more expertise then the clr equivalent, they are fewer and often more expensive. That means on the linux platform we have the following situation: - desktop apps (highly fragmented/diversified) - web apps (highly fragmented/diversified) - backend services (c++ and jvm) I think it's safe to say that on the linux platform we have NOTHING COMPARABLE to .NET when it comes to DESKTOP and WEB apps. Why can't java doesn't fill this gap? My guess is that: For desktop and also web apps startup time, memory usage and ease of deployment are too important that most developers are happy with the compromises that the jvm offers. So they do : - use php, ruby, perl, python even for huge applications (without typechecking at compiletime) - write all sorts of extensions in c to speed up: XS, cython, ... (yuck) - write all sorts of bindings to c libraries: PyGtk, ... (yuck) With the result of fragile desktop apps and bad scaling web apps and the consequence that we use a lot of time of hack around those problems. I think something like the clr would be a huge progress first and foremost for the linux programmers. Maybe Ocaml could play an important role of providing a slick api, because of its strength when it comes to language implementation (compilers), so we would have: gil ( gnu intermediate language, a bytecode ) gilrt ( gnu intermediate language runtime, a jit based vm) - the gilrt written in c or c++ - an Ocaml binding to the gilrt - different language implementations gPython, gRuby, gC, gJava (Language to gil compilers written in Ocaml) Or maybe that's just crazy talk ... ben - On Fri, May 14, 2010 at 5:17 PM, Goswin von Brederlow wrote: > Jon Harrop writes: > >> Xavier Clerc wrote: >>> Limiting myself to the JVM... >>> Moreover, at least Scala and Bigloo deliver excellent performances. >> >> I have benchmarks where the JVM is well over 10x slower than .NET. So I do >> not regard any JVM-based language as "high performance". >> >> Cheers, >> Jon. > > You can pretty much write a benchmark for any 2 languages that > specifically targets the weekness of one and the strength of the other > showing that one is better than the other by a wide margin. You can > usualy reverse the argument with a different benchmark. > > So your argument as such says nothing about JVM, just something about > your benchmarks. > > MfG > Goswin > > ___ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
Le 14 mai 10 à 18:26, ben kuin a écrit : I think something like the clr would be a huge progress first and foremost for the linux programmers. Maybe Ocaml could play an important role of providing a slick api, because of its strength when it comes to language implementation (compilers), so we would have: gil ( gnu intermediate language, a bytecode ) gilrt ( gnu intermediate language runtime, a jit based vm) - the gilrt written in c or c++ - an Ocaml binding to the gilrt - different language implementations gPython, gRuby, gC, gJava (Language to gil compilers written in Ocaml) Or maybe that's just crazy talk ... ben Isn't this precisely the aim of Jon's hlvm (www.ffconsultancy.com/ocaml/hlvm/)? V.___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
On Fri, May 14, 2010 at 9:26 AM, ben kuin wrote: > realworld. I think it's interesting that on the ms-windows platform > .net is used for everything with great success: > Compared to that I think the jvm is only succesful when it comes to > 'backend services', which often play an important role in big and > often technically conservative companies. > I think it's safe to say that on the linux platform we have NOTHING > COMPARABLE to .NET when it comes to DESKTOP and WEB apps. Why can't > java doesn't fill this gap? ms windows is a more closed and constrained and well-defined ecosystem than linux is. i think that has impact on the situation. sincerely. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
but that would be the big benefit of a clr like vm: It doesn't matter how messed up, chaotic or just heterogen the environment is as long as you can count on a regular execution of your portable bytecode. On Fri, May 14, 2010 at 8:11 PM, Raoul Duke wrote: > On Fri, May 14, 2010 at 9:26 AM, ben kuin wrote: >> realworld. I think it's interesting that on the ms-windows platform >> .net is used for everything with great success: >> Compared to that I think the jvm is only succesful when it comes to >> 'backend services', which often play an important role in big and >> often technically conservative companies. >> I think it's safe to say that on the linux platform we have NOTHING >> COMPARABLE to .NET when it comes to DESKTOP and WEB apps. Why can't >> java doesn't fill this gap? > > ms windows is a more closed and constrained and well-defined ecosystem > than linux is. i think that has impact on the situation. > > sincerely. > > ___ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
> Isn't this precisely the aim of Jon's hlvm > (www.ffconsultancy.com/ocaml/hlvm/)? that's an interesting question, Here are a few thoughts: technical: - in .NET everything is easy (from the surface): you have your source file (hello.cs) you take your compiler (cs.exe) and compile it to a msil bytecode file (hello.dll). You can run reflection tools to hello.dll or link it to a exe or generate back to source. This bytecodefile is your friend. You can run it on a bunch of runtimes like .net clr, or on mono, or rotor, or dotgnu. You can register libraries in a container to prevent versioning problems with future releases. I couldn't figure out those equivalents int hlvm or llvm. - with HLVM things are complex (for me): What is the role of the big underlying llvm infrastructure. Why do even need hlvm if we have llvm plus ocaml bindings. Does hlvm has its own bytecode? If yes where is it specified? Is hlvm a ocaml library or is it a free standing vm? etc. Maybe for you these a trivial questions, but I still dont get it, while with .net I never had problem to get the idea. licensing: Hlvm is driven by a company and its landing page is on a companies website and one of its protagonists is smart *and* business savvy. What if hlvm would really take off, could they set it free and move the homepage to sourceforge ? Right now it's bsd licensed, maybe tomorow it's dual licenced like Qi? Or maybe the license some (future) killer features under a closed license? This is just guessing - I don't want to spread fud. But as a former .net developer I followed mono from the beginning and I'm very disappointed that mono is still not considered as a friendly linux citicen. All because of some half-clear license issues. But sure hlvm is impressive and could be the solution. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
Le 14 mai 10 à 23:42, Raoul Duke a écrit : -- Forwarded message -- From: Raoul Duke Date: Fri, May 14, 2010 at 2:42 PM Subject: Re: [Caml-list] about OcamIL To: ben kuin On Fri, May 14, 2010 at 11:59 AM, ben kuin wrote: but that would be the big benefit of a clr like vm: It doesn't matter how messed up, chaotic or just heterogen the environment is as long as you can count on a regular execution of your portable bytecode. of course it matters: there must be the resources to get the vm ported across all the fubar variations of the ecosystem. the combinatorics has to be dealt with somewhere. that kind of complexity is less in the hegemonic windows os world, i hypothesize. Please. You're not talking about the same thing. Ben talks about the benefits such a vm would have once it would be done, you talk about how hard it would be to do it. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
> Please. You're not talking about the same thing. Ben talks about the > benefits such a vm would have once it would be done, you talk about how hard > it would be to do it. i think several things are being intertwined here, i don't agree with you evaluation of the discussion. sincerely. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
> Please. You're not talking about the same thing. Ben talks about the > benefits such a vm would have once it would be done, you talk about how hard > it would be to do it. Exactly, thanks. I assume it's save to say that most today (business) critical applications have to be written in a vm supported language. What is with Ocamls vm then? I have the impression that only little development is going into Ocamls vm. Or is that wrong? If no - what is the reason for this? What if ocamlopt would be dropped for a faster ocaml vm? Would that be an option? ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
ben kuin wrote: > I assume it's save to say that most today (business) critical > applications have to be written in a vm supported language. Why do you assume that? The only evidence to support this is the widespead usage of Java and C#, but I think that is a language choice rather than a conscious decision to use a language that runs on a VM. People chose Java and C# because they are preferable to fundamentally unsafe langauges like C and C++. > What if ocamlopt would be dropped for a faster ocaml vm? Why? Even if the Ocaml was able to target a faster VM, there are still many people who would chose to generate native binaries. Erik (who uses Ocaml compiled to native binaries for mission critical code) -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] about OcamIL
Ben Kuin wrote: > technical: > - in .NET everything is easy (from the surface): you have your source > file (hello.cs) you take your compiler (cs.exe) and compile it to a > msil bytecode file (hello.dll). You can run reflection tools to > hello.dll or link it to a exe or generate back to source. This > bytecodefile is your friend. You can run it on a bunch of runtimes > like .net clr, or on mono, or rotor, or dotgnu. You can register > libraries in a container to prevent versioning problems with future > releases. I couldn't figure out those equivalents int hlvm or llvm. They haven't been written yet. :-) > - with HLVM things are complex (for me): What is the role of the big > underlying llvm infrastructure. LLVM provides the compilation to native code, both static and JIT. > Why do even need hlvm if we have llvm plus ocaml bindings. LLVM's intermediate representation is a low-level assembly language with no memory safety and no automatic memory management. HLVM is a layer on top of LLVM that provides a higher-level intermediate language that is memory safe and garbage collected. > Does hlvm has its own bytecode? If yes where is it specified? HLVM's IR is evolving much too quickly to be worth specifying yet. > Is hlvm a ocaml library or is it a free standing vm? Today, HLVM is an OCaml library. In the future, HLVM will be a free standing VM. > Maybe for you these a trivial questions, but I still dont get it, > while with .net I never had problem to get the idea. Ultimately, HLVM should be just as easy to understand. The only reason it appears complicated today is that HLVM is a set of evolving fragments that are gradually stabilizing and being pulled together to form a progressively more capable core VM. > What if hlvm would really take off, could they set it free and move the homepage to sourceforge? HLVM is free. I would always keep the core (VM and standard library) open source. I might write an "HLVM for Scientists" book, sell libraries or implement features for a fee but nothing evil. :-) In fact, one dream I have is to create a commerce-friendly platform for tools and libraries. I think Linux has really suffered from being anti-commerce rather than truly free. Cheers, Jon. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
Erik de Castro Lopo writes: > ben kuin wrote: > >> I assume it's save to say that most today (business) critical >> applications have to be written in a vm supported language. Hardly any business today has an inhomogene environment. And if the environment is homogene then the vm gives you 0 advantage. It just costs you overhead to emulate. MfG Goswin ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
hi erik, I highly appreciate your blog, so it hurts me a little but - I disagree: > The only evidence to support this is the widespead usage of > Java and C#, but I think that is a language choice rather than > a conscious decision to use a language that runs on a VM. > > People chose Java and C# because they are preferable to > fundamentally unsafe langauges like C and C++. English is not my first language, maybe I misunderstand, but what you're are saying here sound like a complete contradiction to me: Like you say C and C++ are considered as 'unsafe' languages. But thats because they offer features, that are not available when programming for a vm. This has nothing to do with languages, it's a conscious platform decision. >> What if ocamlopt would be dropped for a faster ocaml vm? > > Why? Even if the Ocaml was able to target a faster VM, there > are still many people who would chose to generate native > binaries. I'd call that a questionable decision. As far as I know, using native binaries means to open a whole range of potentially uncorrectionable problems with abi incomptabilities between libraries or with changes of the underlying os. As far as I know when you go native you always have to take abi incompatibility and therefore recompilation into account. For business apps, that's a showstopper. > Erik (who uses Ocaml compiled to native binaries for mission > critical code) Would you mind to share some infos about your experiences, maybe on your blog? ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
--- On Sat, 5/15/10, ben kuin wrote: > >> What if ocamlopt would be dropped for a faster > ocaml vm? > > > > Why? Even if the Ocaml was able to target a faster VM, > there > > are still many people who would chose to generate > native > > binaries. > > I'd call that a questionable decision. As far as I know, > using native > binaries means to open a whole range of potentially > uncorrectionable > problems with abi incomptabilities between libraries or > with changes > of the underlying os. > > As far as I know when you go native you always have to take > abi > incompatibility and therefore recompilation into account. > For business > apps, that's a showstopper. I have worked in many environments, most have been homogeneous, none have had more then four platforms. Supporting four platforms is not difficult if your tools support all four platforms (unfortunately Ocaml's support for Windows is a bit spotty). Running a VM, no matter how good, is always going to carry a performance hit. If your code is UI intensive, that may be acceptable (although I find the startup time for the JVM to be a problem), but if your code is memory or CPU intensive a VM may be unaceptable. -EdK Ed Keith e_...@yahoo.com Blog: edkeith.blogspot.com ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
Le 15 mai 10 à 11:45, ben kuin a écrit : What if ocamlopt would be dropped for a faster ocaml vm? Why? Even if the Ocaml was able to target a faster VM, there are still many people who would chose to generate native binaries. I'd call that a questionable decision. As far as I know, using native binaries means to open a whole range of potentially uncorrectionable problems with abi incomptabilities between libraries or with changes of the underlying os. As far as I know when you go native you always have to take abi incompatibility and therefore recompilation into account. For business apps, that's a showstopper. Aren't most Windows applications binary ones? Not all Windows apps are .Net based, or run on a whatever vm. Most others are binary, aren't they? If yes it seems this has not been a big showstopper to Windows apps developpers... Maybe I don't get the precise sense of "binary". V. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
> If yes it seems this has not been a big showstopper to Windows apps err what?? On what planet do you live? It must be a nice place :-) COM components ( to encapsulate the abi ) DLL hell ( never heard of that? com registration) STL ( taming the abi) CORBA ( to talk between incompatible libraries) VC6++, VC7++ incompatibilities If you really want to torture a developer, these is the best toolset you get. If you want to punish the user with crashing apps and beautiful error messages ( stuff like: "Error msxml.dll not registered by regsvr32" then go ahead. .NET was already a success before the dotnet-sdk was downloadable. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
ben kuin writes: > hi erik, > I highly appreciate your blog, so it hurts me a little but - I disagree: > >> The only evidence to support this is the widespead usage of >> Java and C#, but I think that is a language choice rather than >> a conscious decision to use a language that runs on a VM. >> >> People chose Java and C# because they are preferable to >> fundamentally unsafe langauges like C and C++. > > English is not my first language, maybe I misunderstand, but what > you're are saying here sound like a complete contradiction to me: > Like you say C and C++ are considered as 'unsafe' languages. But thats > because they offer features, that are not available when programming > for a vm. This has nothing to do with languages, it's a conscious > platform decision. Who says they are not available in a vm? There is nothing stopping you from compiling C code to run on a vm. It will be just as unsafe and crash in the vm as it is on a real cpu. Similary ocaml can be run in a vm or native. Why would the quality be improved by running it in a vm? Both bytecode and native use the same source (unless you mean things like --unsafe). >>> What if ocamlopt would be dropped for a faster ocaml vm? >> >> Why? Even if the Ocaml was able to target a faster VM, there >> are still many people who would chose to generate native >> binaries. > > I'd call that a questionable decision. As far as I know, using native > binaries means to open a whole range of potentially uncorrectionable > problems with abi incomptabilities between libraries or with changes > of the underlying os. > > As far as I know when you go native you always have to take abi > incompatibility and therefore recompilation into account. For business > apps, that's a showstopper. Has the native ABI ever changed in ocaml native code? I somewhat doubt that. That is just the C ABI. The compiled module interface though changes with every compiler version and every source change it seems. So every time you update the compiler or change a module you need to recompile everything. But that is a problem of the specific ocaml implementation and in no way a general problem. And correct me if I'm wrong but don't you have to recompile bytecode just as well every time you update the compiler? >> Erik (who uses Ocaml compiled to native binaries for mission >> critical code) > > Would you mind to share some infos about your experiences, maybe on your blog? MfG Goswin ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] about OcamIL
Goswin wrote: > Hardly any business today has an inhomogene environment. And if the > environment is homogene then the vm gives you 0 advantage. It just > costs you overhead to emulate. A Common Language Runtime (CLR) is an obvious counter example => the shared VM gives you safe and high-level interoperability between languages. For example, you can pass garbage collected data structures between languages by reference because they share a single GC. Without a CLR, you generally resort to painstakingly copying everything for no reason and give up for anything non-trivial (like closures) and often end up with segmentation faults and no working code. I was once asked how someone might interoperate between Standard ML and OCaml (two very closely related languages) and my answer was XMLRPC. Contrast that with F# development where almost every program in existence relies entirely upon seamless two-way interoperability with C# libraries like WPF. Cheers, Jon. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] about OcamIL
Raoul Duke wrote: > On Fri, May 14, 2010 at 11:59 AM, ben kuin wrote: > > but that would be the big benefit of a clr like vm: It doesn't matter > > how messed up, chaotic or just heterogen the environment is as long > > as you can count on a regular execution of your portable bytecode. > > of course it matters: there must be the resources to get the vm ported > across all the fubar variations of the ecosystem. the combinatorics > has to be dealt with somewhere. that kind of complexity is less in the > hegemonic windows os world, i hypothesize. Not really. Windows supports a far wider variety of hardware than Linux and Apple supports even less. Providing consistency was one of the major advantages of .NET that had people building on it originally. If you want robustly-deployable hardware-accelerated GUI apps then WPF and, therefore, .NET is your only choice on Windows and you have zero choices on Linux. If you wanted to build something comparable on Linux you would use OpenGL and must then test all software/hardware combinations to see which were unreliable (OpenGL drivers are often very unreliable on Linux). I saw this first hand when I productized OpenGL-based presentation software written in OCaml. It was a catastrophe: with segfaults on 80% of customers machines that we could not reproduce. We canned it and never tried to sell Linux-based software again. Cheers, Jon. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
ben kuin wrote: > English is not my first language, maybe I misunderstand, but what > you're are saying here sound like a complete contradiction to me: > Like you say C and C++ are considered as 'unsafe' languages. Yes. One can't really program in those languages without using pointers and manually allocating/deallocating memory. > But thats > because they offer features, that are not available when programming > for a vm. This has nothing to do with languages, it's a conscious > platform decision. Yes, many languages (native compiled Ocaml and Haskell are just two) have garbage collection and are fundamentally safe. > I'd call that a questionable decision. I call requiring a VM one more potential point of failure. > As far as I know, using native > binaries means to open a whole range of potentially uncorrectionable > problems with abi incomptabilities between libraries or with changes > of the underlying os. My experience says otherwise. My experience consists of having lots of small self contained programs, written in Ocaml and distributed using the Debian packaging system. Binary incompatibilities always get found during development and developer testing and QA. I find Ocaml native binaries far more reliable that those of C and C++ and that reliability is due to garbage collection, and the fact that Ocaml's type system helps prevent bugs. > As far as I know when you go native you always have to take abi > incompatibility and therefore recompilation into account. For business > apps, that's a showstopper. You have no idea just how much you are overstating the case. > Would you mind to share some infos about your experiences, maybe on your > blog? There's really not much to share. Its programs written in Ocaml and distributed to the client machines via the Debian packaging system. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
ben kuin wrote: > > If yes it seems this has not been a big showstopper to Windows apps > > err what?? On what planet do you live? It must be a nice place :-) I would say it hasn't been a big problem on Windows because people are still using windows. Furthermore, how many of the programs that Microsoft distrubutes with Windows 7 are written in C#/.NET and how many are written in C++? Furthermore, many of the problems suffered by Windows are not a problem on Unix systems. > COM components ( to encapsulate the abi ) They were always a mistake. COM never made it to Unix. > DLL hell ( never heard of that? com registration) This is a Microsoft specific problem. Unix systems have used versioned shared libraries since at least the mid 1980s. > STL ( taming the abi) The STL should only be problem and compile time. > CORBA ( to talk between incompatible libraries) Another mistake. Never common on Unix. > VC6++, VC7++ incompatibilities I've only ever come across one problem as a result of this, a problem with passing file descriptor across the application/DLL boundary when the application and the DLL were compiled with different versions of the compiler. Again, this is a problem with Microsoft's OS that I have never come across on any of the Unix systems I have used. > If you really want to torture a developer, these is the best toolset > you get. You have to be kidding me. I personally think the Microsoft development tools are completely horrible. > If you want to punish the user with crashing apps and > beautiful error messages ( stuff like: "Error msxml.dll not registered > by regsvr32" then go ahead. How does that have anything to do with using a VM or not. > .NET was already a success before the dotnet-sdk was downloadable. Microsoft was your saviour because Microsoft caused all your problems in the first place. Microsoft keeps calling Unix a legacy platform, but Unix has evolved over time and to people running modern versions of Unix, its Windows that looks like a legacy platform. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
Jon Harrop wrote: > Not really. Windows supports a far wider variety of hardware than Linux and Oh really? I have a three machine here: a) A Dual PowerPC G5 Apple Mac. b) A SUN ultra-sparc X1. c) One of the early Cobalt Qube machines with a MIPS CPU. All of these run Debian. Can windows run on these machines? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
> Microsoft was your saviour because Microsoft caused all your problems > in the first place. Ok, the topic here is personal and office computing. I mean cubical drones who are not allowed to used right mouse button? Consultants and their 20 MB powerpoints? Middle management assholes with the portable devices, always busy with syncing stuff from some weird Exchange source to another place. Grandpa who is trying to install his new scanner which also a tv receiver, because the isp told him he also watch tv over internet? It's one ugly amorphous quickly fluctuating mess that happens if you endow the average end user with a PC and throw them into a hit-and-run market environment. So far linux was spared by the end user and 'personal computing'. Would linux be really capable to enhance the personal computing experience not only for the enduser but also for the developer? I see two stumbling blocks: - X/X11/X org: I support a few members in my family and friends with linux installations and problems. X is a source for a lot of grieve. The complexity of X punches the end user to often. I dont see alternatives though. - Applications: I mean the way enduser application are developed deployed and installed. The best way would be mono, unfortunately a forbidden fruit because microsoft was too stupid to really set it free. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] about OcamIL
Erik wrote: > Jon Harrop wrote: > > Not really. Windows supports a far wider variety of hardware than > > Linux and > > Oh really? Yes, really. > I have a three machine here: > > a) A Dual PowerPC G5 Apple Mac. > b) A SUN ultra-sparc X1. > c) One of the early Cobalt Qube machines with a MIPS CPU. For every SUN Ultra-sparc or Cobalt Qube there are thousands of gadgets like cameras and printers that don't have Linux drivers or that have only partially-functioning Linux drivers. Cheers, Jon. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
Jon Harrop writes: > Goswin wrote: >> Hardly any business today has an inhomogene environment. And if the >> environment is homogene then the vm gives you 0 advantage. It just >> costs you overhead to emulate. > > A Common Language Runtime (CLR) is an obvious counter example => the shared > VM gives you safe and high-level interoperability between languages. For > example, you can pass garbage collected data structures between languages by > reference because they share a single GC. Without a CLR, you generally > resort to painstakingly copying everything for no reason and give up for > anything non-trivial (like closures) and often end up with segmentation > faults and no working code. And there we disagree. A VM does not give you savety or high-level anything in general. A VM can be as unsafe and low-level as you like. Most VMs won't stop you when you write an int to some (allocated) memory address and load a float from the same address. And BANG you have total garbage. Most VMs won't catch array/string over/underruns. And so on. The safety usualy comes from the high-level language used on top of the VM. As for interoperability you get the same if you define your CLR to be native mode with ONE specific GC. You still need to port every single languag you use to that CLR, native or VM. > I was once asked how someone might interoperate between Standard ML and > OCaml (two very closely related languages) and my answer was XMLRPC. > Contrast that with F# development where almost every program in existence > relies entirely upon seamless two-way interoperability with C# libraries > like WPF. And how do I get the F# code to use my haskell lib? The interoperability comes from F# and C# having common grounds. Not from them running in a VM. The common language runtime is the key there. > Cheers, > Jon. MfG Goswin PS: There is a java CPU so java bytecode can run native. I wonder when someone will build a F# cpu. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
Jon Harrop writes: > Erik wrote: >> Jon Harrop wrote: >> > Not really. Windows supports a far wider variety of hardware than >> > Linux and >> >> Oh really? > > Yes, really. > >> I have a three machine here: >> >> a) A Dual PowerPC G5 Apple Mac. >> b) A SUN ultra-sparc X1. >> c) One of the early Cobalt Qube machines with a MIPS CPU. > > For every SUN Ultra-sparc or Cobalt Qube there are thousands of gadgets like > cameras and printers that don't have Linux drivers or that have only > partially-functioning Linux drivers. > > Cheers, > Jon. Damn, my stupid proprietary webcam doesn't work. Hmpf, not .net for me then. :) MfG Goswin ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
Erik de Castro Lopo writes: > ben kuin wrote: >> If you really want to torture a developer, these is the best toolset >> you get. > > You have to be kidding me. I personally think the Microsoft development > tools are completely horrible. That is what he said. That toolset is the best to *torture* a developer. MfG Goswin ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
On Sun, May 16, 2010 at 5:04 AM, Jon Harrop wrote: > Erik wrote: >> Jon Harrop wrote: >> > Not really. Windows supports a far wider variety of hardware than >> > Linux and >> >> Oh really? > > Yes, really. Well, this does sound a little funny considering that Linux is free software and has been ported to almost every odd hardware platform, and how many platforms does Windows run on? In my opinion, the existence and market-domination of Windows is a little like the case with fossil fuel and internal combustion engines vs. whatever higher technology is being suppressed. However, I can confidently say that Windows would never be a decent operating system if there were not rivalry from free software (Linux and BSD kernels of course!) Cheers, -- Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara http://groups.yahoo.com/group/ai-philosophy http://myspace.com/arizanesil http://myspace.com/malfunct ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] about OcamIL
Erik wrote: >>> Jon Harrop wrote: >>> > Not really. Windows supports a far wider variety of hardware than >>> > Linux and > > Well, this does sound a little funny considering that Linux is free > software and has been ported to almost every odd hardware platform, > and how many platforms does Windows run on? I think he meant hardware support as support for devices/drivers. > In my opinion, the existence and market-domination of Windows is a > little like the case with fossil fuel and internal combustion engines > vs. whatever higher technology is being suppressed. > However, I can confidently say that Windows would never be a decent > operating system if there were not rivalry from free software (Linux > and BSD kernels of course!) I look foreward to the day when somebody explain me why even well educated people loose the ability to differentiate when it comes to Microsoft, while the fall into a state of extasy everytime Google drops a little comfort toy while they carry on with their business venture of 'monetizing' the worlds information. The frightening success of Googles IT Services (Postini, Google Apps) is unfortunately not only Microsofts fault, it also the consequence of the fact that it is impossible with linux to significantly lowering maintaining costs of a bigger it infrastructure. In other words: It's still too difficult to manage. That in turn is what I believe a consequence of the lack of modern language infrastructure. As a proof of concept, try to lower your it costs with a true open source alternative to Exchange. See? And this is the niche Google fills with completely aggressive pricing. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] about OcamIL
Xavier Clerc: > Le 14 mai 2010 à 12:40, Jon Harrop a écrit : > > Xavier Clerc wrote: > >> Limiting myself to the JVM... > >> Moreover, at least Scala and Bigloo deliver excellent performances. > > > > I have benchmarks where the JVM is well over 10x slower than .NET. So > > I do not regard any JVM-based language as "high performance". > > Quite ironically, by scratching the surface, one would discover that > both quoted projects can also target .NET (not tested that though). Does Bigloo.NET support value types? Does Scala.NET use .NET (2.0) generics? Not AFAICT. Name dropping them in the context of "high performance" language implementations is more than a little bit silly... Cheers, Jon. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] about OcamIL
Jon Harrop a écrit : Xavier Clerc: Le 14 mai 2010 à 12:40, Jon Harrop a écrit : > Xavier Clerc wrote: >> Limiting myself to the JVM... >> Moreover, at least Scala and Bigloo deliver excellent performances. > > I have benchmarks where the JVM is well over 10x slower than .NET. So > I do not regard any JVM-based language as "high performance". Quite ironically, by scratching the surface, one would discover that both quoted projects can also target .NET (not tested that though). Does Bigloo.NET support value types? Does Scala.NET use .NET (2.0) generics? Not AFAICT. Name dropping them in the context of "high performance" language implementations is more than a little bit silly... First off, public insult seems quite superfluous. We should be able to handle a heated debate without resorting to that. And I still wait for a clear statement of your level for "high performance", and references to benchmarks that back up your claims in this thread. As you seem to come from an academic background, I expect facts and references, and not ad hominem attacks and fuzzy unbacked claims. Unless you show that neither Bigloo nor Scala meet your (to be defined) criteria for "high performance", my counterexamples still stand. It may just end up that we have different perceptions of "high performance", and of the trade-offs we are going to make in our language / platform choices. Regards, Xavier Clerc ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] about OcamIL
Xavier Clerc wrote: > Jon Harrop a écrit : > > Xavier Clerc: > >> Le 14 mai 2010 à 12:40, Jon Harrop a écrit : > >> > Xavier Clerc wrote: > >> >> Limiting myself to the JVM... > >> >> Moreover, at least Scala and Bigloo deliver excellent > performances. > >> > > >> > I have benchmarks where the JVM is well over 10x slower than .NET. > So > >> > I do not regard any JVM-based language as "high performance". > >> > >> Quite ironically, by scratching the surface, one would discover that > >> both quoted projects can also target .NET (not tested that though). > > > > Does Bigloo.NET support value types? Does Scala.NET use .NET (2.0) > > generics? > > Not AFAICT. Name dropping them in the context of "high performance" > > language > > implementations is more than a little bit silly... > > First off, public insult seems quite superfluous. I was not trying to insult you. Your examples are silly because they are incomplete and untested. Do you even have either of them working right now? AFAICT, Scala.NET is known not to work and Bigloo.NET is still have dozens of core bugs fixed. > We should be able to handle a heated debate without resorting to that. I don't think this is heated at all. We were talking about "high performance" languages and you cited a bunch of languages that get whipped by Python on this benchmark: http://flyingfrogblog.blogspot.com/2009/04/f-vs-ocaml-vs-haskell-hash-table. html > And I still wait for a clear statement of your level for "high > performance", Within 2x of ANSI C compiled with gcc on all practically-relevant benchmarks without dropping to low-level code, e.g. GHC's FFI in Haskell. > and references to benchmarks that back up your claims in this thread. http://fsharpnews.blogspot.com/2010/05/java-vs-f.html > As you seem to come from an academic background, I expect facts > and references, and not ad hominem attacks and fuzzy unbacked claims. An ad-hominem attack is an attack against a person. I attacked your examples, not you. > Unless you show that neither Bigloo nor Scala meet your (to be defined) > criteria for "high performance", my counterexamples still stand. Are you talking about Bigloo.NET and Scala.NET or have you gone back to the original discussion about JVM-based languages? Scala on the JVM is 7x slower than C++ on this benchmark: http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=scala&lan g2=gpp The JVM's hash table is 17x slower than .NET's on this benchmark: http://fsharpnews.blogspot.com/2010/05/java-vs-f.html I think that is not "high performance" by any reasonable definition and this reflects fundamental deficiencies in the VM itself, so there is no hope of working around it in general. I have not been able to get Bigloo to run: it was deleted from Debian and Ubuntu (and the shootout) and the source distribution barfs during configuration with " ./install-gc-7.1: 39: patch: not found". > It may just end up that we have different perceptions of "high > performance", and of the trade-offs we are going to make in our > language / platform choices. Probably. What languages do not you not consider to be high performance? Cheers, Jon. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] about OcamIL
Jon Harrop a écrit : (...) I don't think this is heated at all. We were talking about "high performance" languages and you cited a bunch of languages that get whipped by Python on this benchmark: http://flyingfrogblog.blogspot.com/2009/04/f-vs-ocaml-vs-haskell-hash-table. html Acknowledged. "Whipped" is here 2 times slower on that particular benchmark, while Python is rarely within an order of magnitude of OCaml code (cf. the language shootout). Moreover, hashtables are ubiquitous in Python (and hence probably particularly optimized), while they are not so common in Haskell or Caml. And I still wait for a clear statement of your level for "high performance", Within 2x of ANSI C compiled with gcc on all practically-relevant benchmarks without dropping to low-level code, e.g. GHC's FFI in Haskell. and references to benchmarks that back up your claims in this thread. http://fsharpnews.blogspot.com/2010/05/java-vs-f.html Point taken. Just notice that the 17x factor is observed on the micro-benchmark, while on the larger one the two platforms seem on par. Here is a question about the micro-benchmark: do you know if F# do monomorphize the collection in this example ? If it turns out to be done, one may probably argue that the problem is more related to the language than to the platform (just recycling an objection made on the page you pointed out). As you seem to come from an academic background, I expect facts and references, and not ad hominem attacks and fuzzy unbacked claims. An ad-hominem attack is an attack against a person. I attacked your examples, not you. I do not understand how "name droping is more than silly" could be seen as targeted at the sentence rather than at the one pronouncing it. But, anyway, let's move to the point. Unless you show that neither Bigloo nor Scala meet your (to be defined) criteria for "high performance", my counterexamples still stand. Are you talking about Bigloo.NET and Scala.NET or have you gone back to the original discussion about JVM-based languages? Scala on the JVM is 7x slower than C++ on this benchmark: http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=scala&lan g2=gpp Agreed, but it seems that if you aggregate the results of the different benchmarks, Scala is on average only 1.5x from C++ (but far away in terms of memory consumption). The 7x factor is observed the worst result, the median being 2x. (...) It may just end up that we have different perceptions of "high performance", and of the trade-offs we are going to make in our language / platform choices. Probably. What languages do not you not consider to be high performance? I am not sure it is that easy to compare languages, but measuring compiler performances: any compiler that produces code that runs within -let's say- 5x of the fastest one around, on a bunch of wide-spectrum benchmarks (e. g. numerical code *plus* string matching *plus* tree walking, etc). Maybe it should also be mentioned that I am more versed into symbolic computations. Regarding trade-offs, I am also inclined to favor Open Source solutions and higher-level languages (the trade-off being here execution time vs programming/debugging time). Xavier Clerc PS: as an aside, I used the word "references" for academic publications that went through a reviewing process, not blog entries. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] about OcamIL
Xavier Clerc wrote: > Jon Harrop a écrit : > > I don't think this is heated at all. We were talking about "high > > performance" languages and you cited a bunch of languages that get > whipped > > by Python on this benchmark: > > > > > > http://flyingfrogblog.blogspot.com/2009/04/f-vs-ocaml-vs-haskell- > hash-table. > > html > > Acknowledged. > "Whipped" is here 2 times slower on that particular benchmark, > while Python is rarely within an order of magnitude of OCaml code > (cf. the language shootout). > Moreover, hashtables are ubiquitous in Python (and hence probably > particularly optimized), while they are not so common in Haskell > or Caml. I greatly value efficient generic collections. > >> and references to benchmarks that back up your claims in this > thread. > > > > http://fsharpnews.blogspot.com/2010/05/java-vs-f.html > > Point taken. > Just notice that the 17x factor is observed on the micro-benchmark, > while on the larger one the two platforms seem on par. Sure but those two benchmarks are testing completely different things. The shootout's knucleotide is a larger benchmark that still uses hash tables and Java is still 4x slower because the JVM cannot express a generic hash table efficiently. There are many such problems where the lack of value types on the JVM is a serious impediment to performance. > Here is a question about the micro-benchmark: do you know if F# do > monomorphize the collection in this example? > If it turns out to be done, one may probably argue that the problem > is more related to the language than to the platform (just recycling > an objection made on the page you pointed out). I'm not sure what you mean here. Both of the programs are just using the generic hash table implementation native to their platform. Neither language does anything of relevance to optimize the code. .NET is a lot faster and uses a lot less memory than the JVM because it stores keys and values unboxed in the spine of the hash table because they are value types whereas the JVM boxes them, and because the insertion function is monomorphized at JIT time. > > Scala on the JVM is 7x slower than C++ on this benchmark: > > > http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=scal > a&lan > > g2=gpp > > Agreed, but it seems that if you aggregate the results of the different > benchmarks, Scala is on average only 1.5x from C++ (but far away in > terms > of memory consumption). The 7x factor is observed the worst result, > the median being 2x. Sure. This seems to be a difference in our interpretation of "high performance". If a language or platform can be 17x slower than others then I would not call it "high performance" even if it is competitively performant elsewhere. Indeed, I would completely disregard averages on benchmark suites and focus on outliers because they convey more useful information. Granted that was a microbenchmark but the effect is severe enough to afflict many real programs. > >> It may just end up that we have different perceptions of "high > >> performance", and of the trade-offs we are going to make in our > >> language / platform choices. > > > > Probably. What languages do not you not consider to be high > > performance? > > I am not sure it is that easy to compare languages, but measuring > compiler > performances: any compiler that produces code that runs within -let's > say- 5x > of the fastest one around, on a bunch of wide-spectrum benchmarks (e. > g. > numerical code *plus* string matching *plus* tree walking, etc). > Maybe it should also be mentioned that I am more versed into symbolic > computations. Then you're probably more interested in OCaml's GC vs parallelism when performance is important. > Regarding trade-offs, I am also inclined to favor Open Source solutions > and > higher-level languages (the trade-off being here execution time vs > programming/debugging time). I agree in general, of course, but I'm not sure "higher-level languages" means much in this context. Is C# higher level than Java? Maybe, but I'm interested in the value types and approach to generics here. Monomorphization and unboxed tuples get you a long way towards decent performance without a top-notch GC tuned for functional languages. That makes it feasible to implement with a naïve multicore-capable GC, which is precisely the current direction of HLVM. > PS: as an aside, I used the word "references" for academic publications > that went through a reviewing process, not blog entries. I see. I value reproducible results far higher than peer reviewed academic papers, particularly in this context. Cheers, Jon. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs