From: Brian H. <bri...@ql...> - 2003-06-04 22:35:25
|
Here's an interesting debate point- what does a 1.0 release of ExtLib look like? How close are we? Starting this discussion is tantaumont to saying "I think it's ready now", which I'm not. I'm just thinking of maybe getting a rough sketch of what people want/are working on. Here's my short list in approximate order of priority: - fix the bug in psqueue - unit tests at least some - generic red-black tree library - doubly linked list library - bit fields/bit sets Comments? Brian |
From: Nicolas C. <war...@fr...> - 2003-06-05 02:33:01
|
> Here's an interesting debate point- what does a 1.0 release of ExtLib look > like? How close are we? > > Starting this discussion is tantaumont to saying "I think it's ready now", > which I'm not. I'm just thinking of maybe getting a rough sketch of what > people want/are working on. > > Here's my short list in approximate order of priority: > - fix the bug in psqueue > - unit tests at least some > - generic red-black tree library > - doubly linked list library > - bit fields/bit sets > > Comments? I think we should first review the current code, implement missing functions, add documentation everywhere, and have a look at several past projects ( CDK and friends ) to see if we've been including all needed "standard" functions. Then we should be able to make a first release, and then continue adding useful modules. Nicolas Cannasse |
From: John M. S. <sk...@oz...> - 2003-06-08 15:39:44
|
Brian Hurt wrote: > Here's an interesting debate point- what does a 1.0 release of ExtLib look > like? How close are we? > > Starting this discussion is tantaumont to saying "I think it's ready now", > which I'm not. I'm just thinking of maybe getting a rough sketch of what > people want/are working on. > > Here's my short list in approximate order of priority: > - fix the bug in psqueue > - unit tests at least some > - generic red-black tree library > - doubly linked list library > - bit fields/bit sets > > Comments? It is necessary to provide on-site documentation to what is *officially* working properly, and to include that in any release. If you do that, it doesn't matter if the other half of the library isn't ready. Release it anyhow. release early, release often is often quoted (though I don't know who said it). What would be important to me, if I found I wanted to use some functions from it, is that it can be EASILY USED BY DUMB PROGRAMMERS WHO NEVER WRITE OCAML. By which I mean, it should be trivial for them to download the library, build it, do some rudimentary testing, install it .. and then it is available for building the *actual* ocaml product they really want. On a Unix system an important requirement is to have a standard default place for it to live, so I can write scripts to build my ocaml software which happens to use ExtLib *as if* it were part of the standard distribution (after its been installed). I do hate the idea of polluting the offical distribution directories with third party software, since it is sometimes nice to rm -rf the whole official distribution installation and rebuild it (and if ExtLib lived inside, it too would have to be rebuilt). OTOH, even Python provides a 'site-packages' directory .. .. which is a subdirectory of the main library directory :( -- John Max Skaller, mailto:sk...@oz... snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 |
From: Diego O. F. P. <Die...@et...> - 2003-06-10 07:38:53
|
Bonjour, > It is necessary to provide on-site documentation to what is > *officially* working properly, and to include that in any release. Not stating clearly what does work and what doesn't is a mistake I have done in Baire. I really think Jonh Max Skaller is right in this point and OCaml-lib should avoid doing the same mistake I did. > If you do that, it doesn't matter if the other half of the library > isn't ready. Release it anyhow. > > release early, release often One of the problems is the stability of interfaces. I have broken and rewritten from scratch Baire several times, and I will continue doing so until I get it right. It is important to be able to do such things when you are not an experimented developer in the concerned field (and Baire surely is my first data structure library). I don't know how the Caml-lib team feels it, but I first though 'initial' Baire would be the only one and I realized much later there were a lot of wrong things in it. Diego Olivier |
From: John M. S. <sk...@oz...> - 2003-06-10 21:40:15
|
Diego Olivier Fernandez Pons wrote: > Bonjour, > > >>It is necessary to provide on-site documentation to what is >>*officially* working properly, and to include that in any release. >> > > Not stating clearly what does work and what doesn't is a mistake I > have done in Baire. I really think Jonh Max Skaller is right in this > point and OCaml-lib should avoid doing the same mistake I did. > > >>If you do that, it doesn't matter if the other half of the library >>isn't ready. Release it anyhow. >> >> release early, release often >> > > One of the problems is the stability of interfaces. I have broken and > rewritten from scratch Baire several times, and I will continue doing > so until I get it right. I am the same with Felix. It's been around for 3-4 years, and never announced. But really, I think it is necessary to credit the initial users of a package with a willingness to rewrite the code that uses your package as you change it. Unless of course, you are lucky, and get 100K users on the first day :-) > It is important to be able to do such things when you are not an > experimented developer in the concerned field (and Baire surely is my > first data structure library). > I don't know how the Caml-lib team feels it, but I first though > 'initial' Baire would be the only one and I realized much later there > were a lot of wrong things in it. So? There are a lot of things wrong with C++ too. And plenty of problems with Ocaml itself. And there are many that you won't even find yourself: you need users to help you both find problems, and also to prioritorise them. One thing Guido van Rossum, the inventor of Python, once said to me was that all that really mattered was users. (Meaning, your product is good if it attracts a lot of users). I don't entirely agree, but he has a point. And you won't have any users if you don't release :-) Be willing to be caught out making a mistake. [Arggg .. I can't release Felix yet .. its incomplete .. its got bugs ..] Yeah, its really hard to do, especially for an individual. Well, its easier for a group. So I vote: RELEASE ExtLib within one week no matter what. I want to use it! I don't CARE if its bugged, or if the interfaces aren't right yet. Thing is, I don't have any idea yet, because I haven't tried using it, and I CANNOT make my package depend on a CVS archive or my own private copy of the code. [indeed, there is a licencing issue: Felix is FFAU] -- John Max Skaller, mailto:sk...@oz... snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 |
From: Brian H. <bri...@ql...> - 2003-06-10 21:55:33
|
On Wed, 11 Jun 2003, John Max Skaller wrote: > One thing Guido van Rossum, the inventor of Python, > once said to me was that all that really mattered was > users. (Meaning, your product is good if it attracts > a lot of users). This I seriously agree with. A 1.0 release would help adoption. Especially as it seems we do have users, or at least potiential users. > Well, its easier for a group. > So I vote: > > RELEASE ExtLib within one week no matter what. > > I want to use it! I don't CARE if its bugged, > > or if the interfaces aren't right yet. I only know of one API question at this point: things that might change (go away): and that's precise/imprecise actions in psqueue. Currently there are two sets of operations: find, adjust, add, and remove, which throw an exception on "unexpected" conditions (adding a key that already exists, removing a key which doesn't, etc), and query, update, insert, and delete, which do something "intelligent" in those costs (adding a key that already exists becomes an update, removing a key that doesn't exist does nothing, etc). Now, my preference would be to pick one of the two sets and run with it- but I don't know which one. Feedback would be appreciated here. There are a number of functions I'd like to add (psqueue.enum for example). But adding functions isn't a problem (for compatibility)- it's removing or altering existing functions. Brian |
From: John M. S. <sk...@oz...> - 2003-06-11 14:35:48
|
Brian Hurt wrote: > On Wed, 11 Jun 2003, John Max Skaller wrote: > I only know of one API question at this point: things that might change > (go away): and that's precise/imprecise actions in psqueue. Currently > there are two sets of operations: find, adjust, add, and remove, which > throw an exception on "unexpected" conditions (adding a key that already > exists, removing a key which doesn't, etc), and query, update, insert, and > delete, which do something "intelligent" in those costs (adding a key that > already exists becomes an update, removing a key that doesn't exist does > nothing, etc). Now, my preference would be to pick one of the two sets > and run with it- but I don't know which one. Feedback would be > appreciated here. I'm afraid my comments won't help much .. but I'll make them anyhow. I use Hashtbl, and until recently only the basic functions. Now, sometimes, it does more than I want, for example, I've never use the pushdown stack of entries feature. So for me, the 'add' function is actually a pain, since I have to first check if a key is present to avoid duplicates. Similarly, sometimes I just want to either add or replace, and I had to write code to do that. Since I found 'replace' was added, I'm using that now. Its equivalent to 'add if not present otherwise update', which is easy enough to code, but I get a feeling the built-in update is more efficient, and I can check its semantics in the manual, rather than search my own code. So .. I wouldn't do without the raw primitives: they're the routines which form a basis, and which are expected to be fast. But some of the composite routines are also useful and perhaps more likely to be what is needed in many cases. So I'd probably include *both* the axioms and the theorems, without going overboard: include the extra stuff if it's likely to be heavily used OR allows for more efficient processing OR would be hard to code. Hmmm .. meaning: enrich the basic interface but not *too* much. You can always add in the extra routines later if someone complains, but you want the interface to be ready to use without needing a whole lot of client written auxilliaries. Which I think leaves you just as uncertain as before :-) -- John Max Skaller, mailto:sk...@oz... snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 |
From: Nicolas C. <war...@fr...> - 2003-06-11 02:17:52
|
> And plenty of problems with Ocaml itself. > And there are many that you won't even find yourself: > you need users to help you both find problems, > and also to prioritorise them. I agree on this one . Modern software development and Internet are enabling a quick bug reporting/fix and then users only have to update their version. About this "update" and installation-made-easy of the ExtLib, I was thinking writing a small and simple OCaml program that will check and download the last extlib version , compile using ocamake (I think perhaps we should then put ocamake in the ExtLib) and install it in 'ocamlc -where'/extlib . I would like to have some comments from Unix users to know how we can make the user being able to choose the install directory and still have a nice and portable way of retreiving the install dir (needed by Makefile of program using ExtLib at linking time). > RELEASE ExtLib within one week no matter what. > > I want to use it! I don't CARE if its bugged, > > or if the interfaces aren't right yet. Releasing with bugs is one point : theses can be fixed later. But releasing without any correct documentation IS a mistake. If users don't understand what's inside / how to use the version 1 , they'll not get "ext-addicted" :-) and will simply don't use it. If you want a quick release of ExtLib, please help with writing the documentation of existing modules ! Nicolas Cannasse |
From: John M. S. <sk...@oz...> - 2003-06-11 14:54:09
|
Nicolas Cannasse wrote: > I agree on this one . Modern software development and Internet are enabling > a quick bug reporting/fix and then users only have to update their version. > About this "update" and installation-made-easy of the ExtLib, I was thinking > writing a small and simple OCaml program that will check and download the > last extlib version , compile using ocamake (I think perhaps we should then > put ocamake in the ExtLib) and install it in 'ocamlc -where'/extlib . I tried to do that once and users hated it :-) They wanted a plain old tarball. Still, software like Internet Explorer and Redhat Linux use this idea, but I suspect it would be more useful if it could update multiple packages, not just Extlib. > I would like to have some comments from Unix users to know how we can make the > user being able to choose the install directory and still have a nice and > portable way of retreiving the install dir (needed by Makefile of program > using ExtLib at linking time). You can make an executable which is put in, say /usr/local/bin or ~/bin extlib which prints the install dir so people can write: ocamlc -I`extlib` and add some options: extlib --help --version --test it would also be tricky to have man extlib tell where the installation went. > Releasing with bugs is one point : theses can be fixed later. > But releasing without any correct documentation IS a mistake. I agree. -- John Max Skaller, mailto:sk...@oz... snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 |
From: Blair Z. <bl...@or...> - 2003-06-11 16:39:46
|
John Max Skaller wrote: > > Nicolas Cannasse wrote: > > > I agree on this one . Modern software development and Internet are enabling > > a quick bug reporting/fix and then users only have to update their version. > > About this "update" and installation-made-easy of the ExtLib, I was thinking > > writing a small and simple OCaml program that will check and download the > > last extlib version , compile using ocamake (I think perhaps we should then > > put ocamake in the ExtLib) and install it in 'ocamlc -where'/extlib . > > I tried to do that once and users hated it :-) > They wanted a plain old tarball. Still, software like Internet > Explorer and Redhat Linux use this idea, but I suspect > it would be more useful if it could update multiple packages, > not just Extlib. I agree a tarball release should be available. > > I would like to have some comments from Unix users to know how we can make the > > user being able to choose the install directory and still have a nice and > > portable way of retreiving the install dir (needed by Makefile of program > > using ExtLib at linking time). > > You can make an executable which is put in, say > > /usr/local/bin > > or > > ~/bin > > extlib > > which prints the install dir so people can write: > > ocamlc -I`extlib` > > and add some options: > > extlib --help --version --test > > it would also be tricky to have > > man extlib > > tell where the installation went. Instead of reinventing the wheel here, how about using pkg-config. It handles this kind of stuff and used by a large number of packages: % ls /usr/lib/pkgconfig/ fontconfig.pc gnome-python-2.0.pc* libxml-2.0.pc gconfgtk.pc gobject-2.0.pc libxml.pc gconf.pc gthread-2.0.pc libxslt.pc gdk.pc gthread.pc openssl.pc* glib-2.0.pc gtk+.pc ORBit.pc glib.pc libIDL.pc xcursor.pc gmodule-2.0.pc libmetacity-private.pc xft.pc gmodule.pc libnautilus.pc gnome-mime-data-2.0.pc libpng12.pc You can query arbitrary settings for your package: % pkg-config --help Usage: pkg-config [OPTION...] --version output version of pkg-config --modversion output version for package --atleast-pkgconfig-version=VERSION require given version of pkg-config --libs output all linker flags --libs-only-l output -l flags --libs-only-L output -L flags --cflags output all pre-processor and compiler flags --cflags-only-I output -I flags --variable=VARIABLENAME get the value of a variable --define-variable=VARIABLENAME=VARIABLEVALUE set the value of a variable --exists return 0 if the module(s) exist --uninstalled return 0 if the uninstalled version of one or more module(s) or their dependencies will be used --atleast-version=VERSION return 0 if the module is at least version VERSION --exact-version=VERSION return 0 if the module is at exactly version VERSION --max-version=VERSION return 0 if the module is at no newer than version VERSION --list-all list all known packages --debug show verbose debug information --print-errors show verbose information about missing or conflicting packages --silence-errors show verbose information about missing or conflicting packages --errors-to-stdout print errors from --print-errors to stdout not stderr Help options -?, --help Show this help message --usage Display brief usage message Best, Blair -- Blair Zajac <bl...@or...> Plots of your system's performance - http://www.orcaware.com/orca/ |
From: John M. S. <sk...@oz...> - 2003-06-12 05:41:17
|
Blair Zajac wrote: > Instead of reinventing the wheel here, how about using pkg-config. It > handles this kind of stuff and used by a large number of packages: > > % ls /usr/lib/pkgconfig/ Wow. I got a /usr/lib/pkgconfig directory on my box. Never heard of it before. Unfortunately, I don't seem to have the tool itself. So someone (like me) that wanted to use Felix would not only have to download Python, Interscript, and Ocaml, but also ExtLib and pkgconfig .. Hmmm .. -- John Max Skaller, mailto:sk...@oz... snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 |
From: Blair Z. <bl...@or...> - 2003-06-12 15:52:06
|
John Max Skaller wrote: > > Blair Zajac wrote: > > > Instead of reinventing the wheel here, how about using pkg-config. It > > handles this kind of stuff and used by a large number of packages: > > > > % ls /usr/lib/pkgconfig/ > > Wow. I got a /usr/lib/pkgconfig directory on my box. > Never heard of it before. > Unfortunately, I don't seem to have the tool itself. > > So someone (like me) that wanted to use Felix would not > > only have to download Python, Interscript, and Ocaml, > but also ExtLib and pkgconfig .. Which OS are you using? Best, Blair -- Blair Zajac <bl...@or...> Plots of your system's performance - http://www.orcaware.com/orca/ |
From: Nicolas C. <war...@fr...> - 2003-06-12 05:56:16
|
> I tried to do that once and users hated it :-) > They wanted a plain old tarball. Still, software like Internet > Explorer and Redhat Linux use this idea, but I suspect > it would be more useful if it could update multiple packages, > not just Extlib. [...] > You can make an executable which is put in, say [...] > extlib --help --version --test This is directly putting us back into the COAN thread. Multiple packages, dependencies, patches, install , compile , link , update. A lot of things to do , in a portable way. Right now some people from the Caml team and around have been talking about such a tool. I might start implementing such a thing quite soon, based on the statement they made and on several long talks I already have about it with Jacques Garrigue. I'll keep informed people on this list of further advances. Nicolas Cannasse |
From: Michal M. <mal...@pl...> - 2003-06-13 21:22:29
|
On Thu, Jun 12, 2003 at 02:54:45PM +0900, Nicolas Cannasse wrote: > > I tried to do that once and users hated it :-) > > They wanted a plain old tarball. Still, software like Internet > > Explorer and Redhat Linux use this idea, but I suspect > > it would be more useful if it could update multiple packages, > > not just Extlib. > [...] > > You can make an executable which is put in, say > [...] > > extlib --help --version --test > > This is directly putting us back into the COAN thread. > Multiple packages, dependencies, patches, install , compile , link , update. > A lot of things to do , in a portable way. > > Right now some people from the Caml team and around have been talking about > such a tool. I might start implementing such a thing quite soon, based on > the statement they made and on several long talks I already have about it > with Jacques Garrigue. I'll keep informed people on this list of further > advances. When designing such tool, take into account that lots of ocaml users out there is using rpms and debs with ocaml related stuff. Installing packages from sources, and managing it using specialized tools is often not an option. So please separate software installation from querying compiler options for given package and the like. For example create few conceptually simple tools, one can be pkgconfig look-alike, other rpm (package manager that can handle package installation and removal) with limited functionality, and yet another apt-get (tool to automagically fetch deps for given package) with recompilation support. As a side-note: I really regret pkgconfig didn't come out earlier, since it allows to get rid of all (or almost all) autoconfig stuff, but only if your required packages support it. Anyhow: [malekith@roke ~]$ ls /usr/lib/pkgconfig|wc -l 79 [malekith@roke ~]$ It got quite popular, not only for gnome-related stuff. I believe one of sources of its success was conceptual simplicity. All you need to support pkgconfig, is to put simple foo.pc file in /usr/lib/pkgconfig. Example: #v+ prefix=/usr exec_prefix=/usr libdir=/usr/lib includedir=/usr/include/alsa Name: alsa Description: Advanced Linux Sound Architecture (ALSA) - Library Version: 0.9.3 Requires: Libs: -L${libdir} -lasound -lm -ldl -lpthread Cflags: -I${includedir} #v- Of course for ocaml we would need somewhat different lines, but you get the idea. And yes, there is findlib already. But it's far too complex for my taste -- it tries to handle too much. -- : Michal Moskal :: http://www.kernel.pl/~malekith : GCS {C,UL}++++$ a? !tv : PLD Linux ::::::::: Wroclaw University, CS Dept : {E-,w}-- {b++,e}>+++ h |
From: Brian H. <bri...@ql...> - 2003-06-13 22:49:02
|
My opinion: version 1.0 should be a source tarbar. If we wait until we're all things to all people, we'll never release. A lot of the packaging should be done external to the build process anyways. Now, to a more relevent question: what's left that needs to be documented? Brian |
From: Amit D. <adubey@CoLi.Uni-SB.DE> - 2003-06-14 16:05:28
|
> > > My opinion: version 1.0 should be a source tarbar. If we wait until we're > all things to all people, we'll never release. A lot of the packaging > should be done external to the build process anyways. > > Now, to a more relevent question: what's left that needs to be documented? > > Brian Hi all, I made a couple additions to the in-code Ocamldoc documentation. The biggies that are left are: RefList and anything to do with Enum's. There are bits and pieces missing here and there... When I get the chance, I'll put the new htdocs on the webpage. -Amit |