You can subscribe to this list here.
2003 |
Jan
|
Feb
(81) |
Mar
(97) |
Apr
(88) |
May
(80) |
Jun
(170) |
Jul
(9) |
Aug
|
Sep
(18) |
Oct
(58) |
Nov
(19) |
Dec
(7) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(22) |
Feb
(9) |
Mar
(28) |
Apr
(164) |
May
(186) |
Jun
(101) |
Jul
(143) |
Aug
(387) |
Sep
(69) |
Oct
(14) |
Nov
(8) |
Dec
(99) |
2005 |
Jan
(10) |
Feb
(34) |
Mar
(24) |
Apr
(7) |
May
(41) |
Jun
(20) |
Jul
(3) |
Aug
(23) |
Sep
(2) |
Oct
(26) |
Nov
(41) |
Dec
(7) |
2006 |
Jan
(6) |
Feb
(3) |
Mar
(11) |
Apr
|
May
|
Jun
(5) |
Jul
(8) |
Aug
(20) |
Sep
|
Oct
(6) |
Nov
(5) |
Dec
|
2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
(3) |
May
(2) |
Jun
|
Jul
|
Aug
(1) |
Sep
(7) |
Oct
(6) |
Nov
(19) |
Dec
(11) |
2008 |
Jan
|
Feb
(7) |
Mar
(9) |
Apr
(21) |
May
(42) |
Jun
(27) |
Jul
(28) |
Aug
(26) |
Sep
(16) |
Oct
(32) |
Nov
(49) |
Dec
(65) |
2009 |
Jan
(35) |
Feb
(20) |
Mar
(36) |
Apr
(42) |
May
(111) |
Jun
(99) |
Jul
(70) |
Aug
(25) |
Sep
(15) |
Oct
(29) |
Nov
(3) |
Dec
(18) |
2010 |
Jan
(10) |
Feb
(4) |
Mar
(57) |
Apr
(63) |
May
(71) |
Jun
(64) |
Jul
(30) |
Aug
(49) |
Sep
(11) |
Oct
(4) |
Nov
(2) |
Dec
(3) |
2011 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
2024 |
Jan
(1) |
Feb
(3) |
Mar
(6) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2025 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Bardur A. <oca...@sc...> - 2004-04-30 08:00:02
|
On Fri, Apr 30, 2004 at 09:16:44AM +0200, Nicolas Cannasse wrote: > > On Fri, Apr 30, 2004 at 12:54:36AM +0200, Bardur Arantsson wrote: > > > Sorry, if I come across as confrontational/annoyed, but I > > > am a _huge_ fan of ConfigParser (the python one that is), > > > I use it in all my Python-based projects where persistent > > > configuration is even slightly useful.. > > > > Stay tuned; my missinglib for OCaml will support Python-style > > interpolation very shortly.... This should render it fully compatible > > with Python's SafeConfigParser, and give it some extra features to boot. > > That is, OCaml's library can parse files generated by Python's save(), > > and vice-versa, and get the same results out of them. > > > > -- John > > Could you interface it with IO ? so one can read and write config files. > What is exactly "interpolation" ? > Interpolation is basically just variable susbstitution; as in the following Perl snippet: print "This is the variable value: $bla\n" where the value of the "bla" variable from the surrounding scope is inserted into the string. -- Bardur Arantsson <ba...@im...> <ba...@sc...> - Disco Stu doesn't advertise. Disco Stu | The Simpsons |
From: Nicolas C. <war...@fr...> - 2004-04-30 07:17:40
|
> On Fri, Apr 30, 2004 at 12:54:36AM +0200, Bardur Arantsson wrote: > > Sorry, if I come across as confrontational/annoyed, but I > > am a _huge_ fan of ConfigParser (the python one that is), > > I use it in all my Python-based projects where persistent > > configuration is even slightly useful.. > > Stay tuned; my missinglib for OCaml will support Python-style > interpolation very shortly.... This should render it fully compatible > with Python's SafeConfigParser, and give it some extra features to boot. > That is, OCaml's library can parse files generated by Python's save(), > and vice-versa, and get the same results out of them. > > -- John Could you interface it with IO ? so one can read and write config files. What is exactly "interpolation" ? Regards, Nicolas Cannasse |
From: John G. <jgo...@co...> - 2004-04-30 05:16:13
|
On Fri, Apr 30, 2004 at 12:54:36AM +0200, Bardur Arantsson wrote: > Sorry, if I come across as confrontational/annoyed, but I > am a _huge_ fan of ConfigParser (the python one that is), > I use it in all my Python-based projects where persistent > configuration is even slightly useful.. Stay tuned; my missinglib for OCaml will support Python-style interpolation very shortly.... This should render it fully compatible with Python's SafeConfigParser, and give it some extra features to boot. That is, OCaml's library can parse files generated by Python's save(), and vice-versa, and get the same results out of them. -- John |
From: Bardur A. <oca...@sc...> - 2004-04-29 22:54:42
|
On Thu, Apr 29, 2004 at 10:48:31PM +0200, Nicolas Cannasse wrote: [--snip stuff about enums--] Thank you, sir. You said it so much better than I ever could. :) > OCaml is not python : providing a port of a Python library is certainly nice for > interfacing, but as nothing to do in a general purpose library such as > ExtLib. /me thinks it does. :) To me it would be so useful that it absolutely deserves to be part of ExtLib. (To me, interoperability is not part of the reason I think it should be included... see below). > If you come up with a version of ConfigParser that can enforce the > config file structure and types using a kind of typed-DTD [...] > Having generators of caml type from the typed-DTD will be a killer. Say what? It seems to me you're over-complicating things to the point of absurdity. There is a very good reason that the ConfigParser module in Python is like it is (and it has nothing to do with Python as a language): It is simply _the_ most convenient and _simple_ way to parse user-editable configuration files! There is nothing that comes close! I mean, what could possibly be easier than: let my_server = ConfigParser.get_string ~section:"global" "server" and my_port = ConfigParser.get_int ~section:"global" "port" and my_bla = ConfigParser.get_float ~section:"some_section" "bla" [...] You could even add a bit more compile-time checking by using section tags, as in: let global_section = ConfigParser.get_section ... "global" in let my_server = ConfigParser.get_string global_section "server" .... You may objects that this is not all that general in that it doesn't allow parsing of arbitrarily-typed values from the config file. But why should that be a concern? People simply do not need configuration settings that are more complicated than those already available in the ConfigParser(py) module. If they did, people would be asking the python developers for them! (and the python developer would likely be happy to oblige, they usually are :)) Wrt. specifying various types of values (int,float,string) by using different formatting in the config file... My question is simply: Why? I can see absolutely no benefit to doing this. You can still just as easily get exceptions at parse time, and if the user doesn't already know that some setting should be an int, then they have no business editing that config file! Sorry, if I come across as confrontational/annoyed, but I am a _huge_ fan of ConfigParser (the python one that is), I use it in all my Python-based projects where persistent configuration is even slightly useful.. -- Bardur Arantsson <ba...@im...> <ba...@sc...> - I didn't have a blunt object with me, so I said "OK". David Letterman | The Late Show |
From: Nicolas C. <war...@fr...> - 2004-04-29 20:52:52
|
> > Hashtbl is constant time. > > That means that cost of call to next() does not depends of the number of the > > keys in the Hashtbl. > > It actualy depends of the size of the Array, which is unrelated and bounded > > to the hashing function. > > Evaluating the exact complexity is a bit more difficult. > > I am sorry to complain all the time, but you should seriously have a look > at the implementation in the standard library before claiming that kind of > wrong things. > The length of the array is doubled every time that the number of > bindings is found to be higher than 2 times the number of buckets. > Therefore the array is approximately as long as the number of bindings, > which is the expected property in a hash table (especially a resizable > one). You're true. I didn't look at how the hashtbl resizing was handled. I think then the best way to get an efficient enum is to not copy the Array, leaving the behavior of mutating the Hashtbl while enumerating on it unspecified (as it is for most of the mutable data structures in other langages). > let rec enum m = [...] Thanks, I slighty modified your code and commited it on the CVS. > > > If well-designed abstract data types are abstract and do not provide > > > iterators, it is exactly because iterators are impossible, meaningless or > > > simply unsafe? > > > > If you don't like enum, don't use them, and don't complain at people that > > are thinking they are, using poor arguments. Enum are functional iterators, > > they're different than the C++ STL ones, and are nice to write some > > algorithms that can work whatever the underlying data structure. > > I am still curious to see in what kind of situations you would use them. > Please give us some examples. The rational of Enums is the following : - we have increasing numbers of containers (list, arrays, dynarrays, hashtbl, pmap, .... ) - all theses containers need to implement all the functionnal ops : map, iter, fold... - conversions between each of the containers is a O(n^2). - enums are here to provide an easy way to convert between different containers, and to abstract them at the same time when using functionnal ops. There is nice side effects about their lazyness : - you never need to allocate intermediate data structure when filtering / mapping - you can work with a large collection of elements without any problem. For example, let's take a 1 M elements list. Each map will duplicate it into a brand new 1 M elements list. With enums you can stack several maps and filters, and then at the end, when you iter or fold, each readed element will go through your functionnal stack, be mapped or filtered by it, and eventually reach the output. Better : you can input to your algorithm some data coming from a list, a socket, an array, a file, or the container you need. Write once, use N times, where N is the number of "sources" for your data. If you're not convinced by this I don't know what I can add... > I can give several examples for the Hashtbl stuff that I already posted, > and I don't expect it to be at the core of the future "standard" library > for the Objective Caml language. Samples are not enough. I personaly prefer rationals. > I don't know what you plan to do about Int, Float and Bool additional > modules, or with tables of properties, as recently proposed by other > posters. Int , Float and Bool are useful with functors. ExtLib is functor-free and happy with it. Functors were already discussed and dismissed before : please watch the archives. We have a Polymorphic map (PMap) for Map replacement. The tables of properties are nice but IMHO are requiring more typing. OCaml is not python : providing a port of a Python library is certainly nice for interfacing, but as nothing to do in a general purpose library such as ExtLib. If you come up with a version of ConfigParser that can enforce the config file structure and types using a kind of typed-DTD then I'll be more than happy to put into ExtLib and promote it on the caml list as a good way to have persistent - still user readable - data . Having generators of caml type from the typed-DTD will be a killer. > And why don't you merge the project with the other ExtLib? This is out-of-question. Other ExtLib use C code and ExtLib is pure OCaml. > If you don't trust other people's work, the result will be that someone > else will decide to start one more general library project. I do trust, when there is some strong arguments in favor of an addition to the ExtLib : if I let everything end up into the ExtLib without some filtering and previous discussions over the usabality and general use of the stuff then it will grow like the Java library : big and unusable. Small and consistent is better. However I do understand your frustration and I'm making my best to answer your questions. Best Regards, Nicolas Cannasse |
From: Martin J. <mar...@em...> - 2004-04-29 17:41:06
|
On Thu, 29 Apr 2004, Nicolas Cannasse wrote: > > > 1) This would require Enum to know about internals of > > > other data structures > > > > Really? > > Give me examples. Hashtbl does not work anyway because at least one step > > is not in constant time unless you modify the representation of hash > > tables to fit into the enum model. > > Hashtbl is constant time. > That means that cost of call to next() does not depends of the number of the > keys in the Hashtbl. > It actualy depends of the size of the Array, which is unrelated and bounded > to the hashing function. > Evaluating the exact complexity is a bit more difficult. I am sorry to complain all the time, but you should seriously have a look at the implementation in the standard library before claiming that kind of wrong things. The length of the array is doubled every time that the number of bindings is found to be higher than 2 times the number of buckets. Therefore the array is approximately as long as the number of bindings, which is the expected property in a hash table (especially a resizable one). > > By the way, PMap.enum works in O(n) too. > > That's true. It should not. > You're welcome to provide an O(1) implementation ! > But that's a little bit tricky to do a depth tree traversal in an imperative > way. You need to simulate a stack by hand. let rec enum m = let rec next l () = match !l with [] -> raise Enum.No_more_elements | Empty :: tl -> l := tl; next l () | Node (m1, key, data, m2, h) :: tl -> l := m1 :: m2 :: tl; (key, data) in let count l () = let n = ref 0 in let r = ref !l in try while true do ignore (next r ()); incr n done; 0 with Enum.No_more_elements -> !n in let rec clone l () = let new_l = ref !l in Enum.make (next new_l) (count new_l) (clone new_l) in let l = ref [m.map] in Enum.make ~next: (next l) ~count: (count l) ~clone: (clone l) > > > 2) It would be cumbersome to extend Enum for user-defined > > > data structures. You would have to do what has been done > > > with ExtHashtbl, etc. for _every_ new ADT, and even then > > > you would have conflicts if two developers were to release > > > ADTs for which they had written such "wrappers". > > > > If well-designed abstract data types are abstract and do not provide > > iterators, it is exactly because iterators are impossible, meaningless or > > simply unsafe? > > If you don't like enum, don't use them, and don't complain at people that > are thinking they are, using poor arguments. Enum are functional iterators, > they're different than the C++ STL ones, and are nice to write some > algorithms that can work whatever the underlying data structure. I am still curious to see in what kind of situations you would use them. Please give us some examples. I can give several examples for the Hashtbl stuff that I already posted, and I don't expect it to be at the core of the future "standard" library for the Objective Caml language. I don't know what you plan to do about Int, Float and Bool additional modules, or with tables of properties, as recently proposed by other posters. And why don't you merge the project with the other ExtLib? If you don't trust other people's work, the result will be that someone else will decide to start one more general library project. Martin |
From: Nicolas C. <war...@fr...> - 2004-04-29 14:54:11
|
> > 1) This would require Enum to know about internals of > > other data structures > > Really? > Give me examples. Hashtbl does not work anyway because at least one step > is not in constant time unless you modify the representation of hash > tables to fit into the enum model. Hashtbl is constant time. That means that cost of call to next() does not depends of the number of the keys in the Hashtbl. It actualy depends of the size of the Array, which is unrelated and bounded to the hashing function. Evaluating the exact complexity is a bit more difficult. > By the way, PMap.enum works in O(n) too. That's true. It should not. You're welcome to provide an O(1) implementation ! But that's a little bit tricky to do a depth tree traversal in an imperative way. You need to simulate a stack by hand. > > 2) It would be cumbersome to extend Enum for user-defined > > data structures. You would have to do what has been done > > with ExtHashtbl, etc. for _every_ new ADT, and even then > > you would have conflicts if two developers were to release > > ADTs for which they had written such "wrappers". > > If well-designed abstract data types are abstract and do not provide > iterators, it is exactly because iterators are impossible, meaningless or > simply unsafe? If you don't like enum, don't use them, and don't complain at people that are thinking they are, using poor arguments. Enum are functional iterators, they're different than the C++ STL ones, and are nice to write some algorithms that can work whatever the underlying data structure. Nicolas Cannasse |
From: John G. <jgo...@co...> - 2004-04-29 13:58:54
|
On Thu, Apr 29, 2004 at 08:30:45AM +0200, Florian Hars wrote: > Alan Post wrote: > >In article <408...@bi...>, Florian Hars wrote: > >>Of course, including code from extlib into the core distribution > >>would kill ocaml for commercial development (due to the incompatible > >>license), so it will not happen in the forseeable future. > > > >I thought both libraries were LGPL? > > No, the standard Library is LGPL + linking exception, Extlib is plain LGPL, > which is almost the same as plain GPL for ocaml code, because the way the > ocaml linker works makes it virtually impossible to distribute object code > according to > > if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > executable containing the modified Library. I don't buy it. You are quoting from section 6 of the LGPL, which grants exceptions for programs that use the library and combine themselves with portions of it (statically linking in the C sense, standard procedure in the OCaml sense.) From my reading of it, you are merely required, for ocaml, to provide the source code for the library and either source or object code for your work. So, you could provide the source to the library and .cmo/.cma files for your work. That is akin to providing .o and .a files in C. I don't see the difference. Moreover, what you quoted is but one option of five. And you can still use runtime linking (Dynlink) to load up the library. > Getting the same effect as the LGPL has for C code is technically > impossible with the current ocaml toolcahin. Make up your mind and > either release under the GPL proper, or under a more liberal/less free > (pick your poison) licence like LGPL + linking exception, old X, new > BSD, or whatever. Or fix the linker to be compatible with the LGPL, > but that is a major (or, rather, MAJOR) project. I don't really understand how OCaml is different from statically-linking in C. This is not a new problem. |
From: Nicolas C. <war...@fr...> - 2004-04-29 13:40:19
|
> I ran through the .mli's to get an overview of what's in there, and in so > doing corrected some typos/minor spelling stuff in the comments. Did not > change the semantics of any comments. > There are 3 places though where the comment was really unclear, i marked > those with xxx. > > Henri Thats ! I fixed the xxx parts and commited your patch. Regards, NC |
From: Nicolas C. <war...@fr...> - 2004-04-29 13:20:49
|
> Nicolas Cannasse wrote: > > ExtLib is also LGPL + linking exception , since it's released under "the > > same licence as Ocaml stdlib". > > From the README.txt : > > I explicitely checked the licence statements in the HEAD version of severeal > source files in the repository before posting, and none of these were released > with the linking exception. (IO.ml, dbi.ml, enum.ml, extLib.ml, refList.ml ...) > The README.txt is mostly irrelevant if the actual files say something else if > you want to play safe on the IP side, sad as it is. I'm not familiar with IP ;) If someone could tell what exactly to put into the files in order to be consistent with the wanted licence, I'll do the changes before the upcoming release. Regards, NC |
From: Henri DF <hen...@ep...> - 2004-04-29 09:57:41
|
I ran through the .mli's to get an overview of what's in there, and in so doing corrected some typos/minor spelling stuff in the comments. Did not change the semantics of any comments. There are 3 places though where the comment was really unclear, i marked those with xxx. Henri > Hi list, > > I added documention for the IO module, and fixed the specification, > especialy regarding the pos_in, pos_out and available optional functions. > The OO wrappers have been commited but are still awaiting standardization > for interoperability with OCamlNet an Camomile libraries in order to be > confirmed and documented. Peer reviews and comments are of course welcome ! > > Regards, > Nicolas Cannasse > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > ocaml-lib-devel mailing list > oca...@li... > https://lists.sourceforge.net/lists/listinfo/ocaml-lib-devel > |
From: Florian H. <ha...@bi...> - 2004-04-29 09:05:32
|
Nicolas Cannasse wrote: > ExtLib is also LGPL + linking exception , since it's released under "the > same licence as Ocaml stdlib". > From the README.txt : I explicitely checked the licence statements in the HEAD version of severeal source files in the repository before posting, and none of these were released with the linking exception. (IO.ml, dbi.ml, enum.ml, extLib.ml, refList.ml ...) The README.txt is mostly irrelevant if the actual files say something else if you want to play safe on the IP side, sad as it is. Yours, Florian. |
From: Martin J. <mar...@em...> - 2004-04-29 07:42:12
|
On Wed, 28 Apr 2004, Nicolas Cannasse wrote: > [...] > > I was happy to play with this... However I am not convinced about > > the usefulness of iterators in OCaml. > > I think that it could be an interesting approach in some cases, like the > > example about graphs that was posted: for recording the current position > > in the iteration. This requires some memory allocation. > > > > Efficiency matters, and this is why higher order functions seem > > preferable in most cases. > > I am personaly quite convinced with Enums as forwards iterators. I am not > about bidirectional ones. > The nice thing about enums is that : > - you can apply all functional ops (map/fold/iter...) to any kind of > container without distinction I don't really see when it is more useful or more efficient than using directly "My_container.map f my_container". > - you can clone at any point of the enumeration in order to enumerate again Yes, I would like to see convincing examples. > - you can stack several enums (for example stack several map and filters) in > a lazy fashion > > > Some additional remarks: > > > > 1) Hashtbl.enum works in O(n), is this allowed? > > > > 2) The implementation of Hashtbl.keys is terribly inefficient: > > > > let keys h = Enum.map (fun (k,_) -> k) (enum h) > > > > Why not: > > > > let list_keys h = fold (fun key data accu -> key :: accu) h [] > > let enum_keys h = List.enum (list_keys h) > > One of the requirement of enums is that they're O(1) constructs. Hey, I want to get the keys, not build an enum. > Here you need to build first a list of keys, that's really ineficient. > But wait... I just noticed that Hashtbl.enum looks broken. > I'll fix this now. Thanks for the report ! Euh, you just delayed the Array.copy step. I thought that an iteration step also needed to be executed in constant time. I don't see how this could be done without modifying the internal representation of hash tables. Martin |
From: Martin J. <mar...@em...> - 2004-04-29 07:32:03
|
On Wed, 28 Apr 2004, Bardur Arantsson wrote: > 1) This would require Enum to know about internals of > other data structures Really? Give me examples. Hashtbl does not work anyway because at least one step is not in constant time unless you modify the representation of hash tables to fit into the enum model. By the way, PMap.enum works in O(n) too. > -- which would mean that they would > have to be exported! Not a good idea. Enum is a client of other data structures. Without other data structures Enum is useless, not list neither arrays. > 2) It would be cumbersome to extend Enum for user-defined > data structures. You would have to do what has been done > with ExtHashtbl, etc. for _every_ new ADT, and even then > you would have conflicts if two developers were to release > ADTs for which they had written such "wrappers". If well-designed abstract data types are abstract and do not provide iterators, it is exactly because iterators are impossible, meaningless or simply unsafe? Martin |
From: Bardur A. <oca...@sc...> - 2004-04-29 07:18:13
|
On Thu, Apr 29, 2004 at 09:10:36AM +0200, Nicolas Cannasse wrote: > > Alan Post wrote: > > > In article <408...@bi...>, Florian Hars wrote: > > >>Of course, including code from extlib into the core distribution > > >>would kill ocaml for commercial development (due to the incompatible > > >>license), so it will not happen in the forseeable future. > > > > > > I thought both libraries were LGPL? > > > > No, the standard Library is LGPL + linking exception, Extlib is plain > LGPL, > > ExtLib is also LGPL + linking exception , since it's released under "the > same licence as Ocaml stdlib". > From the README.txt : > > Licence : > --------- > > Licence is the same as OCaml standard Library: > LGPL without some linking restrictions. > That text is rather unclear... "*without* some linking *restrictions*"? Shouldn't that read LPGL **with** the linking **exception** ?? The full license text should also be available in a COPYING file!!! That would make it much clearer that it is indeed the same license as the OCaml stdlib. -- Bardur Arantsson <ba...@im...> <ba...@sc...> If at first you don't succeed, failure may be your style. http://www.demotivators.com |
From: Nicolas C. <war...@fr...> - 2004-04-29 07:11:31
|
> Alan Post wrote: > > In article <408...@bi...>, Florian Hars wrote: > >>Of course, including code from extlib into the core distribution > >>would kill ocaml for commercial development (due to the incompatible > >>license), so it will not happen in the forseeable future. > > > > I thought both libraries were LGPL? > > No, the standard Library is LGPL + linking exception, Extlib is plain LGPL, ExtLib is also LGPL + linking exception , since it's released under "the same licence as Ocaml stdlib". From the README.txt : Licence : --------- Licence is the same as OCaml standard Library: LGPL without some linking restrictions. Regards, Nicolas Cannasse |
From: Florian H. <ha...@bi...> - 2004-04-29 06:31:01
|
Alan Post wrote: > In article <408...@bi...>, Florian Hars wrote: >>Of course, including code from extlib into the core distribution >>would kill ocaml for commercial development (due to the incompatible >>license), so it will not happen in the forseeable future. > > I thought both libraries were LGPL? No, the standard Library is LGPL + linking exception, Extlib is plain LGPL, which is almost the same as plain GPL for ocaml code, because the way the ocaml linker works makes it virtually impossible to distribute object code according to if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ executable containing the modified Library. without supplying the source code to your application. This may be a major difference for closed source projects. The only difference to the GPL is that you can supply the source under a NDA, but that is a lot of hassle. To reiterate my pet peeve: Releasing ocaml code under an unmodified LGPL is in many cases a sign of a careless licence choice since it doesn't do for ocaml what it does for C code, and so probably doesn't do what the authors intended. Getting the same effect as the LGPL has for C code is technically impossible with the current ocaml toolcahin. Make up your mind and either release under the GPL proper, or under a more liberal/less free (pick your poison) licence like LGPL + linking exception, old X, new BSD, or whatever. Or fix the linker to be compatible with the LGPL, but that is a major (or, rather, MAJOR) project. Yours, Florian. |
From: Nicolas C. <war...@fr...> - 2004-04-28 22:06:18
|
Hi list, I added documention for the IO module, and fixed the specification, especialy regarding the pos_in, pos_out and available optional functions. The OO wrappers have been commited but are still awaiting standardization for interoperability with OCamlNet an Camomile libraries in order to be confirmed and documented. Peer reviews and comments are of course welcome ! Regards, Nicolas Cannasse |
From: Nicolas C. <war...@fr...> - 2004-04-28 21:06:26
|
> > Reading the news, it looks like GODI is taking off and that quite huge > > developments are being done. That's a nice thing for the ocaml community. > > As a window user, I cannot create a GODI package unless I switch to > > ocaml/Cygwin. Is there someone here willing to create an maintain the GODI > > package for ExtLib.... raise your hands :) > > I can do it, if nobody else wants to take a chance to learn how to create > GODI packages. I wish I only could :) > To do it, it will be convenient to have an updated release (the last > release seems quite out-dated, and does not have non-interactive > installation). As soon as we reach an agreement on abstract IO objects with Gerd an Yamagata, I'm planning an official release of ExtLib. It would be nice to have the GODI package available at the same time. > Also, as a side note, I don't think it is a good idea to use Sys.rename to > install the files (in install.ml). At least under Unix, this function does > not support cross-device moves. For Unix users, why not having a very > standard Makefile (which does not rely on ocamake; with "all", "opt" and > findlib-based "install" rules) ? I'm quite happy with the install.ml now, it's convenient and have been tested on several systems (it works well also on windows, without any "make" installed). It can also be driven from flags. Just modifying the "copy" function in order to avoid Sys.rename should be enough. Of course if you want to write a Makefile for GODI, I'm not against it. Please feel free to sent it back so I can update the - outdated - Makefile on the CVS (the CMA name is no longer ext-lib but extLib ). Best Regards, Nicolas Cannasse |
From: <Ala...@en...> - 2004-04-28 20:50:38
|
On Wed, 28 Apr 2004, Nicolas Cannasse wrote: > Reading the news, it looks like GODI is taking off and that quite huge > developments are being done. That's a nice thing for the ocaml community. > As a window user, I cannot create a GODI package unless I switch to > ocaml/Cygwin. Is there someone here willing to create an maintain the GODI > package for ExtLib.... raise your hands :) I can do it, if nobody else wants to take a chance to learn how to create GODI packages. To do it, it will be convenient to have an updated release (the last release seems quite out-dated, and does not have non-interactive installation). Also, as a side note, I don't think it is a good idea to use Sys.rename to install the files (in install.ml). At least under Unix, this function does not support cross-device moves. For Unix users, why not having a very standard Makefile (which does not rely on ocamake; with "all", "opt" and findlib-based "install" rules) ? -- Alain |
From: Nicolas C. <war...@fr...> - 2004-04-28 20:29:35
|
> One of the requirement of enums is that they're O(1) constructs. > Here you need to build first a list of keys, that's really ineficient. > But wait... I just noticed that Hashtbl.enum looks broken. > I'll fix this now. Thanks for the report ! ExtHashtbl.enum was broken, and was also O(N) while constructed. I used tricky hacks in order to make it work as specified : the first time the enumerator is called or cloned (and not constructed) the Array containing the buckets is cloned in order to avoid mutations-while-enumeration. Regards, Nicolas Cannasse |
From: Nicolas C. <war...@fr...> - 2004-04-28 19:49:38
|
[...] > I was happy to play with this... However I am not convinced about > the usefulness of iterators in OCaml. > I think that it could be an interesting approach in some cases, like the > example about graphs that was posted: for recording the current position > in the iteration. This requires some memory allocation. > > Efficiency matters, and this is why higher order functions seem > preferable in most cases. I am personaly quite convinced with Enums as forwards iterators. I am not about bidirectional ones. The nice thing about enums is that : - you can apply all functional ops (map/fold/iter...) to any kind of container without distinction - you can clone at any point of the enumeration in order to enumerate again - you can stack several enums (for example stack several map and filters) in a lazy fashion > Some additional remarks: > > 1) Hashtbl.enum works in O(n), is this allowed? > > 2) The implementation of Hashtbl.keys is terribly inefficient: > > let keys h = Enum.map (fun (k,_) -> k) (enum h) > > Why not: > > let list_keys h = fold (fun key data accu -> key :: accu) h [] > let enum_keys h = List.enum (list_keys h) One of the requirement of enums is that they're O(1) constructs. Here you need to build first a list of keys, that's really ineficient. But wait... I just noticed that Hashtbl.enum looks broken. I'll fix this now. Thanks for the report ! > 3) Why making every module depend on Enum? > I think that Enum should provide conversion functions from/to more basic > containers. In the standard lib, there are Array.to_list and Array.of_list > because lists are more important than arrays. > Since Enum provides a super container, I think it would be more natural > to make it depend on the core containers such as lists, arrays, and other > things that could be implemented independently from Enum. > Then Enum would have to define Enum.of_list, Enum.of_array and so on... > and I would avoid its use over mutable data, except in the very specific > cases of fixed length arrays and strings. Enum is a small module, depending on it is not a big deal. As Bardur answered, enumerators are implemented on the AST side, and Enum module just provide a common interface for them. We could not add a depency to Enum module if we were using objects but it cost more and objects are not the best part of OCaml :) - although they're useful to put common interface between independant librairies as we're currently talking on the caml list. Regards, Nicolas Cannasse |
From: Henri DF <hen...@ep...> - 2004-04-28 18:20:48
|
> > [1] And of course i could simply wrap Hashtbl.find and catch Not_found, > > but this is performance sensitive, and i have some vague recollection of > > there being a cost to putting stuff in a try.. with block. > > Exceptions in OCaml are very cheap (unlike Java for example) and very useful > to propagate some state. For instance, doing and Hashtbl.mem + an > Hashtbl.find looks more costly than wrapping the "find" into a try..with > block. > indeed, my vague recollections about exception costs were not only vague, but wrong ... http://groups.google.com/groups?q=exception+cost+group:fa.caml+author:leroy&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=fa.en864pv.1jlor34%40ifi.uio.no&rnum=1 thanks henri |
From: Bardur A. <oca...@sc...> - 2004-04-28 18:17:02
|
On Thu, Apr 29, 2004 at 02:00:58AM +0800, Martin Jambon wrote: > [inspired by discussions on caml-list] > 3) Why making every module depend on Enum? > I think that Enum should provide conversion functions from/to more basic > containers. In the standard lib, there are Array.to_list and Array.of_list > because lists are more important than arrays. > Since Enum provides a super container, I think it would be more natural > to make it depend on the core containers such as lists, arrays, and other > things that could be implemented independently from Enum. > Then Enum would have to define Enum.of_list, Enum.of_array and so on... > and I would avoid its use over mutable data, except in the very specific > cases of fixed length arrays and strings. > There are several reasons for this; two just off the top of my head: 1) This would require Enum to know about internals of other data structures -- which would mean that they would have to be exported! Not a good idea. 2) It would be cumbersome to extend Enum for user-defined data structures. You would have to do what has been done with ExtHashtbl, etc. for _every_ new ADT, and even then you would have conflicts if two developers were to release ADTs for which they had written such "wrappers". -- Bardur Arantsson <ba...@im...> <ba...@sc...> - In the forest lived... some trousers... called Dave. Richard Richard | Bottom |
From: Remi V. <rem...@la...> - 2004-04-28 18:16:35
|
Henri DF <hen...@ep...> writes: > hi list, > i find myself often having to do [1] > > if Hashtbl.mem h k then > let v = Hashtbl.find h k in ... do stg with k here try this : try let v = Hashtbl.find h k in ... do stg with k here with | Not_found -> () it's more efficient. > > I was wondering if it would be worth having a Hashtbl.find_opt, which > returns Some v if there is a binding, None otherwise. Well, then let find_opt h k = try Some (Hashtbl.find h k) with | Not_found -> None not sure it is so useful, but well, it might be. We could also have some use for findk : let findk h k found not_found = try found (Hashtbl.find h k) with | Not_found -> not_found () But there is not so many use for the continuation way of writing things. [...] -- Rémi Vanicat |