Re: [Caml-list] standard regex package

Re: [Caml-list] standard regex package

[Arturo Borquez]

On Fri, 24 August 2001, Miles Egan wrote:

> 
> I'd be happy to do it, but I'm afraid it's a bit beyond my abilities.  What do
> you think of Markus' suggestion of simply keeping the current str module and
> adding a new pcre module?
> 
> -- 
> miles
> 
I believe that the best choice is what Markus proposed
that is to put PCRE as a different module and deprecate
Str (or not do any further development with Str).

Arturo.


Find the best deals on the web at AltaVista Shopping!
http://www.shopping.altavista.com
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Str.string_match raising Invalid_argument "String.sub" in gc

[Nicolas George]

Le mercredi 22 août 2001 à 13:31, Miles Egan a écrit :
>>		    PCRE-library (Perl Compatible Regular Expressions):
> I've asked this several times before, but I think it's worth asking again: is
> there any chance of adding pcre to the stock distribution?  It's superior in
> every way the the str module and much friendlier to python/perl refugees.

I second that too. And because PCRE is under LGPL (Str is based on GNU
regex, which is under GPL), it could be in the standard library and not
only in the distribution. Maybe we could even hope a regexp pattern
matching as a syntax extension :-)
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Str.string_match raising Invalid_argument "String.sub" in gc

[Brian Rogoff]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 3030 bytes --]

On Thu, 23 Aug 2001, Nicolas George wrote:
> Le mercredi 22 août 2001 à 13:31, Miles Egan a écrit :
> >>		    PCRE-library (Perl Compatible Regular Expressions):
> > I've asked this several times before, but I think it's worth asking again: is
> > there any chance of adding pcre to the stock distribution?  It's superior in
> > every way the the str module and much friendlier to python/perl refugees.
> 
> I second that too. And because PCRE is under LGPL (Str is based on GNU
> regex, which is under GPL), it could be in the standard library and not
> only in the distribution. 

Some other "pure OCaml" regexp engines were discussed here recently, including 
Claude Marche's and the one from Unison. Since the Unison code is under GPL 
and not LGPL, and I'm a (inverse) license ayatollah, I can only use the
LGPL'ed one. I've been playing with it and it's quite nice, though I think it
needs a few more bells and whistles to satisfy the Perlers. I don't know how 
it compares in performance against the Pcre C code. 

I agree that Str is suboptimal, but I think that there are also a few
other ways in which string handling could be improved, like 

(1) Very long strings (Sys.max_string_length = 16777211 on most
    machines). Please don't tell me that slurping a 100M file into a 
    string is probably not smart, I know that, but it's a restriction
    that annoys some (many?) programmers. 

(2) Wide character strings

(3) Functional strings (and functional arrays while we're at it :)

(4) Substrings

(1) and (3) could be fixed by adding a "ropes" library, or (1) alone could
be fixed by building strings over Bigarrays. (2) can also be fixed using 
Bigarrays, either building on top of them or just stealing the C code and 
specializing it. I ported the SML Basis library for substrings over to
OCaml, but I much prefer Hansen's subsequence reference approach (if
you've read Finkel's "Advanced Programming Language Design" you know what
I mean) and I've made a new module based on that which I'll release after
some more tire kicking; e-mail me if you want a version. Interestingly, it 
depends on physical reference equality so a semantics preserving port to
SML would require some uglification. 

So, I think we could use a richer set of string datatypes, and operations 
over them. It's not clear to me how much of this needs to be part of OCaml 
proper, and how much should just be, say, part of the CDK. It is clear that 
if there is going to be built-in regexp matching that Str is not the way to go. 
 
> Maybe we could even hope a regexp pattern matching as a syntax extension :-)

Some version of Haskell had a regexp matcher built in that worked on regexps over 
other types than characters. I don't think it survived, but it's certainly
a cool idea.

-- Brian


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

[Caml-list] standard regex package

[Miles Egan]

On Thu, Aug 23, 2001 at 10:31:46AM -0700, Brian Rogoff wrote:
> I agree that Str is suboptimal, but I think that there are also a few
> other ways in which string handling could be improved, like 
> 
> (1) Very long strings (Sys.max_string_length = 16777211 on most
>     machines). Please don't tell me that slurping a 100M file into a 
>     string is probably not smart, I know that, but it's a restriction
>     that annoys some (many?) programmers. 
> 
> (2) Wide character strings
> 
> (3) Functional strings (and functional arrays while we're at it :)
> 
> (4) Substrings

These would all be very nice, I agree, but I also think we need something better
than str and sooner than all these things could be implemented.  Maybe some kind
of transitional scheme would work?

While were on the subject of beginner usability, it seems to me that if dynamic
loading of c-libraries is still a ways off, it might be nice to build the unix
module into the toplevel at install time.

-- 
miles

"We in the past evade X, where X is something which we believe to be a
lion, through the act of running." - swiftrain@geocities.com
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] standard regex package

[Brian Rogoff]

On Thu, 23 Aug 2001, Miles Egan wrote:
[... snip ...]
> These would all be very nice, I agree, but I also think we need something better
> than str and sooner than all these things could be implemented.  Maybe some kind
> of transitional scheme would work?

I agree, from a pragmatic point of view a better regexp matcher would make OCaml 
significantly sexier to all of those poor deluded Python and Perl programmers. 
The other stuff can come later. I think Markus has a very good point about 
some distutils (Python) like facility being even more important. Once such
a framework is in place we can have an OCaml CPAN. Last time I looked findlib 
ran only on Unix, which is a big problem. 

On the subject of "social tools", the program Neel is looking for is this one 

http://www.lri.fr/~filliatr/ocamlweb/index.en.html

and Hevea of course. There is also OCamlDoc, which seems quite nice too,
but ocamlweb is used in a few more libraries I think. 

> While were on the subject of beginner usability, it seems to me that if dynamic
> loading of c-libraries is still a ways off, it might be nice to build the unix
> module into the toplevel at install time.

A better apporach might be to ape Python and the SML Basis Library by providing a 
generic "OS" module which abstracts at least Unix/Win/Mac away. I would
prefer this, since I feel silly using Unix.<blah> on a Windows box :-).

-- Brian


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] standard regex package

[Miles Egan]

On Thu, Aug 23, 2001 at 12:28:49PM -0700, Brian Rogoff wrote:
> The other stuff can come later. I think Markus has a very good point about 
> some distutils (Python) like facility being even more important. Once such
> a framework is in place we can have an OCaml CPAN. Last time I looked findlib 
> ran only on Unix, which is a big problem. 

I agree that a CPAN equivalent is more pressing, but I don't think regex should
be an add-on.  It's too fundamental, at least to the people coming from
'scripting' languages.

> > While were on the subject of beginner usability, it seems to me that if dynamic
> > loading of c-libraries is still a ways off, it might be nice to build the unix
> > module into the toplevel at install time.
> 
> A better apporach might be to ape Python and the SML Basis Library by providing a 
> generic "OS" module which abstracts at least Unix/Win/Mac away. I would
> prefer this, since I feel silly using Unix.<blah> on a Windows box :-).

Yeah, "Unix" seems like a bit of an anachronism.

-- 
miles

"We in the past evade X, where X is something which we believe to be a
lion, through the act of running." - swiftrain@geocities.com
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] standard regex package

[Gerd Stolpmann]

On Thu, 23 Aug 2001, Brian Rogoff wrote:
>On Thu, 23 Aug 2001, Miles Egan wrote:
>[... snip ...]
>> These would all be very nice, I agree, but I also think we need something better
>> than str and sooner than all these things could be implemented.  Maybe some kind
>> of transitional scheme would work?
>
>I agree, from a pragmatic point of view a better regexp matcher would make OCaml 
>significantly sexier to all of those poor deluded Python and Perl programmers. 

Agreed, too.

>The other stuff can come later. I think Markus has a very good point about 
>some distutils (Python) like facility being even more important. Once such
>a framework is in place we can have an OCaml CPAN. Last time I looked findlib 
>ran only on Unix, which is a big problem. 

When I developed findlib I had something like CPAN in mind. I started it when I
downloaded several 3rd party packages, and all had a different installation
routines I had to modify for my purposes. For those who don't know: You can
install almost every 3rd party Perl package by simply doing

perl Makefile.pl
make
make test
make install

It is simple to do, and that's an important aspect of the success of Perl (a
language which is nothing without CPAN).

I hope we will have CCAN. Of course, one precondition is a standard package
structure, and I can imagine the findlib tool could be an important part of it
(for a description see 
http://test.ocaml-programming.de/packages/documentation/findlib/).

Currently, findlib runs only on Unix (including cygwin), but this is mainly
because I have no native Windows installation on which I could test it.
Especially, I have removed all shell scripts (it is now purely programmed in
OCaml), and it is only a question of fixing details. (And of writing a
replacement for "configure".)

>On the subject of "social tools", the program Neel is looking for is this one 
>
>http://www.lri.fr/~filliatr/ocamlweb/index.en.html
>
>and Hevea of course. There is also OCamlDoc, which seems quite nice too,
>but ocamlweb is used in a few more libraries I think. 
>
>> While were on the subject of beginner usability, it seems to me that if dynamic
>> loading of c-libraries is still a ways off, it might be nice to build the unix
>> module into the toplevel at install time.
>
>A better apporach might be to ape Python and the SML Basis Library by providing a 
>generic "OS" module which abstracts at least Unix/Win/Mac away. I would
>prefer this, since I feel silly using Unix.<blah> on a Windows box :-).

"Unix" is only a name for an API (and not for a technology or a familiy of OSs),
and it is clearly MS's fault not to be Unix-compliant (other operating systems
originating in different worlds are, e.g. MVS includes a Unix API). But that's
politics... (MS had some times ago a Posix mode in NT but nobody used it, so I
think there are no real technical reasons.)

Being more abstract has also disadvantages because you don't know which system
calls are done for one abstract call. (Ironically, Perl tried to abstract from
the system calls, i.e. _the_ language used by system hackers. And Perl shows
clearly that this way is wrong. For example, Perl's flock is one of flock,
fcntl, or lockf, resulting in total confusion which semantics the program can
expect.)

So I think having a Unix module with Unix semantics is right.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] standard regex package

[Brian Rogoff]

On Thu, 23 Aug 2001, Gerd Stolpmann wrote:
> On Thu, 23 Aug 2001, Brian Rogoff wrote:
> >The other stuff can come later. I think Markus has a very good point about 
> >some distutils (Python) like facility being even more important. Once such
> >a framework is in place we can have an OCaml CPAN. Last time I looked findlib 
> >ran only on Unix, which is a big problem. 
> 
> When I developed findlib I had something like CPAN in mind. I started it when I
> downloaded several 3rd party packages, and all had a different installation
> routines I had to modify for my purposes. For those who don't know: You can
> install almost every 3rd party Perl package by simply doing
> 
> perl Makefile.pl
> make
> make test
> make install
> 
> It is simple to do, and that's an important aspect of the success of Perl (a
> language which is nothing without CPAN).

Right, and our advantage is that the language is something without CCAN
(COAN? KOAN? :) but will be much more with it. 

> I hope we will have CCAN. Of course, one precondition is a standard package
> structure, and I can imagine the findlib tool could be an important part of it
> (for a description see 
> http://test.ocaml-programming.de/packages/documentation/findlib/).
> 
> Currently, findlib runs only on Unix (including cygwin), but this is mainly
> because I have no native Windows installation on which I could test it.

Maybe the Consortium should just get you a few Windows machines? I'm
totally serious about that; once this hole is filled we can seriously talk 
about world domination. Err, benevolent world domination, of course. 

> Especially, I have removed all shell scripts (it is now purely programmed in
> OCaml), and it is only a question of fixing details. (And of writing a
> replacement for "configure".)
> 
[...snip...]

> >A better apporach might be to ape Python and the SML Basis Library by providing a 
> >generic "OS" module which abstracts at least Unix/Win/Mac away. I would
> >prefer this, since I feel silly using Unix.<blah> on a Windows box :-).
> 
> "Unix" is only a name for an API (and not for a technology or a familiy of OSs),

Really that API is "Posix", right? Yeah, I know, a small matter of spelling.

> and it is clearly MS's fault not to be Unix-compliant (other operating systems
> originating in different worlds are, e.g. MVS includes a Unix API). But that's
> politics... (MS had some times ago a Posix mode in NT but nobody used it, so I
> think there are no real technical reasons.)

My memory is that NT's Posix mode was not truely Posix compliant, but it's
been a while and I could be wrong. 

> Being more abstract has also disadvantages because you don't know which system
> calls are done for one abstract call. 

I was thinking of "OS" as providing a high level view of a fairly generic
OS with a hierarchical file system. I agree that a Posix module with Posix 
semantics is also required, as is a WindowsNT/2000/XP or whatever they
decide to call it. Or to sound hip, a thick binding to generic OS features
and numerous thin bindings which are mostly just stubs for the system  
calls. 

-- Brian


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] standard regex package

[Benjamin C. Pierce]

> For those who don't know: You can
> install almost every 3rd party Perl package by simply doing
> 
> perl Makefile.pl
> make
> make test
> make install
> 
> It is simple to do, and that's an important aspect of the success of Perl (a
> language which is nothing without CPAN).

Having just spent 90 minutes last weekend trying to get a PERL package
installed and working, I can say with confidence that PERL's standard
installation procedure, while slick, leaves one big thing to be desired:
following dependencies.  The problem with the "CPAN way" is that it leads
to 10,000 people writing cool little packages, all of which depend on ten
other cool little packages written by somebody else, etc., etc.
Following all these dependency chains manually by trying to install one
package, failing, grepping around in CPAN for the ones it depends on,
downloading them, trying to install, failing, ... is a pretty boring way
to spend a morning.

I really wish that I'd been able to say to some tool, "I want to use
module X; please go off to CPAN and find, download, and install me the
current versions of X and all the modules it transitively depends on."  I
know that it would be reallyreally hard to design a framework that would
always do the right thing, but if it did the right thing 99% of the time
and gave me a type error in 99% of the cases where it did not do the
right thing, it would be fantastic (and I believe both of these numbers
would be rather easy to achieve by low-tech means).

    Benjamin

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] standard regex package

[Gerd Stolpmann]

On Thu, 23 Aug 2001, Benjamin C. Pierce wrote:
>> For those who don't know: You can
>> install almost every 3rd party Perl package by simply doing
>> 
>> perl Makefile.pl
>> make
>> make test
>> make install
>> 
>> It is simple to do, and that's an important aspect of the success of Perl (a
>> language which is nothing without CPAN).
>
>Having just spent 90 minutes last weekend trying to get a PERL package
>installed and working, I can say with confidence that PERL's standard
>installation procedure, while slick, leaves one big thing to be desired:
>following dependencies.  The problem with the "CPAN way" is that it leads
>to 10,000 people writing cool little packages, all of which depend on ten
>other cool little packages written by somebody else, etc., etc.
>Following all these dependency chains manually by trying to install one
>package, failing, grepping around in CPAN for the ones it depends on,
>downloading them, trying to install, failing, ... is a pretty boring way
>to spend a morning.
>
>I really wish that I'd been able to say to some tool, "I want to use
>module X; please go off to CPAN and find, download, and install me the
>current versions of X and all the modules it transitively depends on."  I
>know that it would be reallyreally hard to design a framework that would
>always do the right thing, but if it did the right thing 99% of the time
>and gave me a type error in 99% of the cases where it did not do the
>right thing, it would be fantastic (and I believe both of these numbers
>would be rather easy to achieve by low-tech means).

The CPAN module does it; see perldoc CPAN.

For O'Caml the corresponding functionality would be much harder because
of possible version conflicts. Say you have packages A and B already installed,
and A depends on B. Furthermore, you want to install package C, but package C
requires the new version B'. For Perl, this is less dramatic than it seems to
be because everything is dynamic, and the packages can themselves cope with
version conflicts. For Caml, a clever automatic installer must decide:

- Does the already installed package A work with the new version B'? If yes, 
  is it necessary to recompile package A?

- If package A must be renewed, too: Is there a version A' that works with B'?

- If there are other packages that depend on A: Is it necessary to
  recompile/relink them?

Because these questions are difficult, findlib does not include versioned
dependencies (but it includes versions as such, and dependencies as such). So
it requires still an intelligent operator that helps finding the right versions.

One feature that should be added is automatic recompilation of dependent
packages (from known sources).

-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] standard regex package

[Miles Egan]

On Thu, Aug 23, 2001 at 11:49:50PM +0200, Gerd Stolpmann wrote:
> Because these questions are difficult, findlib does not include versioned
> dependencies (but it includes versions as such, and dependencies as such). So
> it requires still an intelligent operator that helps finding the right versions.

One danger in developing such a system is that you'll wind up duplicating the
rather extensive functionality of existing package management systems.  RPM and
DEB both handle these kinds of dependencies and are fairly complex systems for
it.  CPAN has its shortcomings, but it also works suprisingly well most of the
time.  I think you should at least consider taking a "worse-is-better" approach
and build something that works and leave the delicate dependency management to
the distribution packagers.

-- 
miles

"We in the past evade X, where X is something which we believe to be a
lion, through the act of running." - swiftrain@geocities.com
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] standard regex package

[Gerd Stolpmann]

On Fri, 24 Aug 2001, Miles Egan wrote:
>On Thu, Aug 23, 2001 at 11:49:50PM +0200, Gerd Stolpmann wrote:
>> Because these questions are difficult, findlib does not include versioned
>> dependencies (but it includes versions as such, and dependencies as such). So
>> it requires still an intelligent operator that helps finding the right versions.
>
>One danger in developing such a system is that you'll wind up duplicating the
>rather extensive functionality of existing package management systems.  RPM and
>DEB both handle these kinds of dependencies and are fairly complex systems for
>it.  CPAN has its shortcomings, but it also works suprisingly well most of the
>time.  I think you should at least consider taking a "worse-is-better" approach
>and build something that works and leave the delicate dependency management to
>the distribution packagers.

As far as I know, RPM/DEP focus on binary installations, and source packages
exist only to conveniently make binary packages. This means: Someone already
has reviewed the package and decided which versions to take.

For a CPAN-like system, the primary goal is to simplify installations from
source. This is far more complicated because typically nobody has checked which
package versions (reliably) work together. As pointed out in my last mail,
there is no definite algorithm, and at most it would be possible to find some
heuristics working in many cases.

But this doesn't mean that CPAN isn't possible for Caml. It only means: Don't
begin with a fully automatic installation routine, and lower your goals. It
would be already great if we had a standard package format and a standard
procedure to install packages, even if we would have to call it manually (at the
beginning).

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] standard regex package

[Claudio Sacerdoti Coen]

 By the way, someone mentioned the debian effort to package OCaml stuff.
 Well, Gerd has recently modified findlib in such a way that it is now
 almost trivial to make a debian package of a findlib-ed one. (And there
 are already many of them available.) I think that the same thing is
 true also for other packaging systems (e.g. RPM).

 Hence, if findlib was widely adopted, there would be no conflict at
 all between it and the debian-ized stuff.

 					Cheers,
					 C.S.C.

-- 
----------------------------------------------------------------
Real name: Claudio Sacerdoti Coen
PhD Student in Computer Science at University of Bologna
E-mail: sacerdot@cs.unibo.it
http://caristudenti.cs.unibo.it/~sacerdot
----------------------------------------------------------------
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] standard regex package

[Sven]

On Fri, Aug 24, 2001 at 01:55:25AM +0200, Gerd Stolpmann wrote:
> On Fri, 24 Aug 2001, Miles Egan wrote:
> >On Thu, Aug 23, 2001 at 11:49:50PM +0200, Gerd Stolpmann wrote:
> >> Because these questions are difficult, findlib does not include versioned
> >> dependencies (but it includes versions as such, and dependencies as such). So
> >> it requires still an intelligent operator that helps finding the right versions.
> >
> >One danger in developing such a system is that you'll wind up duplicating the
> >rather extensive functionality of existing package management systems.  RPM and
> >DEB both handle these kinds of dependencies and are fairly complex systems for
> >it.  CPAN has its shortcomings, but it also works suprisingly well most of the
> >time.  I think you should at least consider taking a "worse-is-better" approach
> >and build something that works and leave the delicate dependency management to
> >the distribution packagers.
> 
> As far as I know, RPM/DEP focus on binary installations, and source packages
> exist only to conveniently make binary packages. This means: Someone already
> has reviewed the package and decided which versions to take.

debian package include source dependencies, and you are true, it is the work
of the package maintainer to provide those, aided by the numerous bug reports
we get from the porters if the build dependencies are bad.

That said, normally each package has listed in it's INSTALL/README the
dependencies, though in an informal way.

Maybe a kind of more formal dependency listing would be nice, which would be
shared by all ocaml related sources, and may then be filled in the
corresponding debian/rpm control files.

Friendly,

Sven Luther
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] standard regex package

[Sven]

On Thu, Aug 23, 2001 at 11:49:50PM +0200, Gerd Stolpmann wrote:
> On Thu, 23 Aug 2001, Benjamin C. Pierce wrote:
> >> For those who don't know: You can
> >> install almost every 3rd party Perl package by simply doing
> >> 
> >> perl Makefile.pl
> >> make
> >> make test
> >> make install
> >> 
> >> It is simple to do, and that's an important aspect of the success of Perl (a
> >> language which is nothing without CPAN).
> >
> >Having just spent 90 minutes last weekend trying to get a PERL package
> >installed and working, I can say with confidence that PERL's standard
> >installation procedure, while slick, leaves one big thing to be desired:
> >following dependencies.  The problem with the "CPAN way" is that it leads
> >to 10,000 people writing cool little packages, all of which depend on ten
> >other cool little packages written by somebody else, etc., etc.
> >Following all these dependency chains manually by trying to install one
> >package, failing, grepping around in CPAN for the ones it depends on,
> >downloading them, trying to install, failing, ... is a pretty boring way
> >to spend a morning.
> >
> >I really wish that I'd been able to say to some tool, "I want to use
> >module X; please go off to CPAN and find, download, and install me the
> >current versions of X and all the modules it transitively depends on."  I
> >know that it would be reallyreally hard to design a framework that would
> >always do the right thing, but if it did the right thing 99% of the time
> >and gave me a type error in 99% of the cases where it did not do the
> >right thing, it would be fantastic (and I believe both of these numbers
> >would be rather easy to achieve by low-tech means).
> 
> The CPAN module does it; see perldoc CPAN.
> 
> For O'Caml the corresponding functionality would be much harder because
> of possible version conflicts. Say you have packages A and B already installed,
> and A depends on B. Furthermore, you want to install package C, but package C
> requires the new version B'. For Perl, this is less dramatic than it seems to
> be because everything is dynamic, and the packages can themselves cope with
> version conflicts. For Caml, a clever automatic installer must decide:
> 
> - Does the already installed package A work with the new version B'? If yes, 
>   is it necessary to recompile package A?
> 
> - If package A must be renewed, too: Is there a version A' that works with B'?
> 
> - If there are other packages that depend on A: Is it necessary to
>   recompile/relink them?
> 
> Because these questions are difficult, findlib does not include versioned
> dependencies (but it includes versions as such, and dependencies as such). So
> it requires still an intelligent operator that helps finding the right versions.
> 
> One feature that should be added is automatic recompilation of dependent
> packages (from known sources).

Also a way to export the dependencies in a string format, and be able to turn
all this stuff of in the case your OS/distribution/whatever already handles
this would be nice too.

Friendly,

Sven Luther
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] standard regex package

[Ian Zimmerman]

Sven> be able to turn all this stuff of in the case your
Sven> OS/distribution/whatever already handles this would be nice too.

Why?

The Perl install routine works just fine alongside the Debian one.
When I'm installing a Perl module from source, the dependencies it is
looking for can come either from other modules I have installed the
same way, or from Debian packages.  It doesn't care, and that's how it
should be.

Once again, the thing to remember is: the dependencies we're talking
about in this thread are _for installation from sources_, when the
modules hasn't yet been packaged in the native OS form.  The initial
packaging is a special case of such source installation.

-- 
Ian Zimmerman, Oakland, California, U.S.A.
The easiest way to win an argument: ridicule your opponent's basic
assumptions by stating their negation and postfixing it with ", right?"
GPG pub key: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] standard regex package

[Sven]

On Mon, Aug 27, 2001 at 08:54:48AM -0700, Ian Zimmerman wrote:
> 
> Sven> be able to turn all this stuff of in the case your
> Sven> OS/distribution/whatever already handles this would be nice too.
> 
> Why?
> 
> The Perl install routine works just fine alongside the Debian one.
> When I'm installing a Perl module from source, the dependencies it is
> looking for can come either from other modules I have installed the
> same way, or from Debian packages.  It doesn't care, and that's how it
> should be.

Well, but the debian packager of the perl stuff, altough i didn't looked at it
in detail, will have to do the stuff needed to disable those dependencies in
the build system, and implement the debian one instead. Same goes for rpms and
others. 

So what i, as a debian packager of various ocaml stuff, was asking, was to
also have an _easy_ way of disabling the builtin dependency stuff, and use the
OSes dependencies in place, and maybe a compatible dependencies format, in
order to just be able to copy it to the packages control file. 

That said, i don't know what kind of dependencies you are speaking about, if
it will be only between ocaml stuff, or also outside libraries needed by your
packages (like gtk+ for lablgtk/mlgtk for example), and if you want to
maintain versionned dependencies on these.

> Once again, the thing to remember is: the dependencies we're talking
> about in this thread are _for installation from sources_, when the
> modules hasn't yet been packaged in the native OS form.  The initial
> packaging is a special case of such source installation.

Well, but don't forget about apt-get source -b package_name, which, if your
apt is new enough will hapilly download the source package from the debian
repository as well as all the needed source dependencies, and rebuild the
package on your system. This, altough debian specific, is something akin to
what you want, isn't it ?

Friendly,

Sven Luther
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] standard regex package

[Ian Zimmerman]

Brian> A better apporach might be to ape Python and the SML Basis
Brian> Library by providing a generic "OS" module which abstracts at
Brian> least Unix/Win/Mac away. I would prefer this, since I feel
Brian> silly using Unix.<blah> on a Windows box :-).

Surely you _don't_ mean the LCD of Unix/Win/Mac, and throwing out all
the APIs which are specific to Unix but _so_ darn useful?  Why do you
think I am a GNU/Linux user in the first place?

-- 
Ian Zimmerman, Oakland, California, U.S.A.
The easiest way to win an argument: ridicule your opponent's basic
assumptions by stating their negation and postfixing it with ", right?"
GPG pub key: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] standard regex package

[Brian Rogoff]

On 27 Aug 2001, Ian Zimmerman wrote:
> Brian> A better apporach might be to ape Python and the SML Basis
> Brian> Library by providing a generic "OS" module which abstracts at
> Brian> least Unix/Win/Mac away. I would prefer this, since I feel
> Brian> silly using Unix.<blah> on a Windows box :-).
> 
> Surely you _don't_ mean the LCD of Unix/Win/Mac, 

That's exactly what I mean. 

> and throwing out all the APIs which are specific to Unix but _so_ darn
> useful?  

Please read my reply to Gerd. I'm not suggesting throwing away anything,
in fact I suggest adding stuff. In case it wasn't clear, I meant to have a 
high level "LCD" module for generic OS stuff (call it GenerOS, or VirtuOS 
for virtual OS :), *and* have Unix, Windows, Mac, BeOS, Amiga (OK,
now I'm just being silly :) modules for those APIs. If you really want to 
get extreme there could be multiple Unix modules for each Unix variation, 
and multiple Windows and Mac modules for each variation of those OSes, but 
I think OS, Posix, Windows, Mac, etc should be sufficient. 

> Why do you think I am a GNU/Linux user in the first place?

Honestly, I haven't spent much time pondering the matter. :-)

-- Brian


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] standard regex package

[Xavier Leroy]

We all agree that the Str regexp library has problems, both on the
interface side (too much global state) and on the implementation side
(fails mysteriously on complex regexps).

The last time this topic came up on this list, I said that we aren't
opposed to put PCRE in the OCaml distribution (provided Markus agrees
with that, of course).  BUT: in the name of backward compatibility, we
must have an Str-compatible interface to this library (same functions
and same regexp syntax as in Str), in addition to the native PCRE
interface.  I think it can be done, but the replies I got to this
request were of the form "I don't have time to do this".

Also: the PCRE interface is quite heavyweight, with a zillion options
whose purpose are not always clear to me.  This can be a bit frightening
and will need a lot of carefully worded documentation to explain that
most of these options are useless 99% of the time :-)  This is not a
criticism towards Markus' work, more like a criticism towards Perl's
and PCRE's "creeping featuritism" syndrom.

So: any taker for writing this Str-compatibility layer?

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] standard regex package

[Markus Mottl]

On Fri, 24 Aug 2001, Xavier Leroy wrote:
> The last time this topic came up on this list, I said that we aren't
> opposed to put PCRE in the OCaml distribution (provided Markus agrees
> with that, of course).

No objection on my side. That's why I have LGPLed it.

> BUT: in the name of backward compatibility, we must have an
> Str-compatible interface to this library (same functions and same
> regexp syntax as in Str), in addition to the native PCRE interface.

As was mentioned in our last discussion on this topic, backwards
compatibility would require writing a stateful interface around the
PCRE, conversion functions for regular expressions and compatible
implementations of the other functions. Is this really necessary? Why
not just keep the old Str-module and deprecate its use? Of course, if
the strange behaviour of Str wrt. large regexps is severe, somebody would
have to do it if debugging Richard Stallman's code is not an option... ;)

> I think it can be done, but the replies I got to this request were of
> the form "I don't have time to do this".

Ahem, well, what concerns me, this is unfortunately the case right now. I
really need to get on with my actual project (a machine learning system).

What about the many new heros on this list? This would be a good exercise!
:-)

> Also: the PCRE interface is quite heavyweight, with a zillion options
> whose purpose are not always clear to me.  This can be a bit frightening
> and will need a lot of carefully worded documentation to explain that
> most of these options are useless 99% of the time :-)  This is not a
> criticism towards Markus' work, more like a criticism towards Perl's
> and PCRE's "creeping featuritism" syndrom.

I agree. The reasons why I made it rather heavyweight are that hardly
anybody could argue that Perl or the PCRE support features he needs but
are not supported by this library, thus easing the change to OCaml. I
was also practicing writing C-interfaces at this time so I thought I'd
implement all PCRE-functions for practice.

I would certainly not have any objections against making the library more
lightweight: probably many functions could be removed without hesitation
(e.g. information on patterns). It may also be worthwhile to reconsider
the way labels and optional arguments are used, though the latter only
look evil in the interface but are extremely convenient to use once one
gets the scheme behind, which is invariant throughout the library.

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] standard regex package

[Miles Egan]

On Fri, Aug 24, 2001 at 11:13:31AM +0200, Xavier Leroy wrote:
> The last time this topic came up on this list, I said that we aren't
> opposed to put PCRE in the OCaml distribution (provided Markus agrees
> with that, of course).  BUT: in the name of backward compatibility, we
> must have an Str-compatible interface to this library (same functions
> and same regexp syntax as in Str), in addition to the native PCRE
> interface.  I think it can be done, but the replies I got to this
> request were of the form "I don't have time to do this".

I'd be happy to do it, but I'm afraid it's a bit beyond my abilities.  What do
you think of Markus' suggestion of simply keeping the current str module and
adding a new pcre module?

-- 
miles

"We in the past evade X, where X is something which we believe to be a
lion, through the act of running." - swiftrain@geocities.com
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr