First look at Guile Std Library available

First look at Guile Std Library available

[Richard Todd]

[-- Attachment #1.1: Type: text/plain, Size: 2758 bytes --]

I haven't heard back about my savannah project yet (probably a
combination of the security work and the holidays), but I don't want
to do too much more work without some feedback.  So I've put the work
I've done so far on my website.

http://www.vzavenue.net/~rwtodd5128/index.html

There's enough there now that you can get a sense of what I'm wanting
to do (and the rather large amount of work left to do).  Now would be
the best possible time to get your input in and help make this project
as useful to the guile community as possible.

The .info file has almost all the modules documented, and there is
passable coverage in the unit tests.  You should be able to 'make
check' before you 'make install' to run the unit tests.  

Modules currently in the project, about 1/2 lifted from other sources,
about 1/2 I wrote over the last couple weeks:

* container queue::             Queues, Stacks, and Deques
* logging logger::              Logging mechanism
* logging port-log::            A log handler that outputs to ports
* logging rotating-log::        A log handler for rotating text file logs
* math minima::                 Finding minimum values of functions
* math primes::                 Functions dealing with prime numbers
* os process::                  Manipulating and creating process chains
* search basic::                Classic searching algorithms
* string completion::           Facilities for things like TAB-completion
* string soundex::              Soundex Algorithm
* string transform::            Transformations of strings
* string wrap::                 String wrapping and filling functions
* term ansi-color::             Colors text with ANSI sequences

(not documented yet)
* unit-test guileUnit           Unit test framework

...plus a couple more that aren't quite there yet 

There are plenty of things to fill in, and help would be appreciated.  If you have
a few hours one weekend, pull out your 'numerical recipes' book and make a scheme
version of some algorithms.  Every time someone does this and contributes it to the
library, the entire guile community gets more efficient.

Larger Things I'm working on/investigating now:------------------------------
* List Comprehensions, porting from Swindle Scheme library (having trouble
  due to implementation differences)

* Regexps that can work on ports.  This is needed to do things like work across
  a buffer-gap.  (is there anything else this would be useful for?? oh
  well, it's needed)

* Lexer Generator -- need this to complement (parse lalr), which I have yet to put into the 
  library either.  Bigloo seems to have a nice one that I may be able to port

Richard Todd
richardt at vzavenue dot net

[-- Attachment #1.2: Type: application/pgp-signature, Size: 186 bytes --]

[-- Attachment #2: Type: text/plain, Size: 139 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Dale Mellor]

>>>>> "Richard" == Richard Todd <richardt@vzavenue.net> writes:

    Richard> Modules currently in the project, about 1/2 lifted from other
    Richard> sources, about 1/2 I wrote over the last couple weeks:

    Richard> * container queue:: Queues, Stacks, and Deques * logging logger::
    Richard> Logging mechanism * logging port-log:: A log handler that outputs
    Richard> to ports * logging rotating-log:: A log handler for rotating text
    Richard> file logs * math minima:: Finding minimum values of functions *
    Richard> math primes:: Functions dealing with prime numbers * os process::
    Richard> Manipulating and creating process chains * search basic:: Classic
    Richard> searching algorithms * string completion:: Facilities for things
    Richard> like TAB-completion * string soundex:: Soundex Algorithm * string
    Richard> transform:: Transformations of strings * string wrap:: String
    Richard> wrapping and filling functions * term ansi-color:: Colors text with
    Richard> ANSI sequences


   This is just a knee-jerk reaction I got on reading the e-mail, but without
looking into your work in any detail, and is probably more useful as a talking
point amongst the Guile community than a direct comment.

    The collection of modules seems to be something of a hodge-podge of utility
libraries (just because PERL and Python do it this way doesn't mean we have to),
and overlaps with other stuff we already have (notably ice-9 and slib). I think
that we should move towards developing some 'standard' libraries as separate,
community-managed projects.

- a low-level wrapper around libc (simple procedure definitions which reflect
    those in libc, much of which is already in ice-9, and a lot of the rest is
    hardwired in Guile anyway - it just needs documenting in one place)

- a library which provides UNIX functionality presented in a lispish programming
    paradigm (this should be Guile's workhorse UNIX interface, and is
    essentially a wrapper around the above library). Maybe add in here such
    things as string completion, ANSI colours, soundex...

- a library of lispish containers, iterators and algorithms (akin to the C++
    STL; much of which is slib)

- a library of mathematical algorithms (akin to the good ol' NAG routines; these
    will probably be better written in C and exposed to Guile through a thin
    wrapper)

                                   My two cents for the day,
                                                Dale

http://rdmp.org:20202
---------------------------------------------------------------------
Despite the brusque/curmudgeonly/terse nature of my e-mails I am
really a nice guy and wish you well.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Richard Todd]

[-- Attachment #1.1: Type: text/plain, Size: 3785 bytes --]

Thanks for the comments--I'll try to elaborate on my goals here,
although that may make you even more sure that I'm going in the wrong
direction! :) Please let me know.


On Fri, Jan 02, 2004 at 10:29:29AM +0100, Dale Mellor wrote:
>     The collection of modules seems to be something of a hodge-podge of utility
> libraries (just because PERL and Python do it this way doesn't mean we have to),
> and overlaps with other stuff we already have (notably ice-9 and slib). I think
> that we should move towards developing some 'standard' libraries as separate,
> community-managed projects.

I'm open to all suggestions on ways we can improve on the perl/python
approach.  (Note that other scheme implementations have libs like
this, also).  I've started there because:
  1) It is an existing, successful, and popular approach
  2) I can leverage the design of their modules to get farther, faster
  3) Guile currently doesn't have _any_ approach, as far as I can tell

As for the overlap, one of the problems I'm trying to address is that
ice-9 and SLIB are hodge-podges themselves, in my view.  SLIB overlaps
guile-core and ice-9, and doesn't use guile's native module system
either.  I want to incorporate a lot of both of them (several of the
parts I have so far are in fact derived from SLIB), but put them in a
framework of modules that are cohesive and documented.  I want to
produce _the_ basic set of guile modules, that allow development to
start with a largish base of stable, documented functionality
supporting it.

The hodge-podginess of what I've put out there so far is readily
apparent because it's so preliminary--there's just not much there yet.
Of course, you might be saying that once we've filled it out that it'll
just be a much more comprehensive hodge-podge :)


> - a low-level wrapper around libc (simple procedure definitions which reflect
>     those in libc, much of which is already in ice-9, and a lot of the rest is
>     hardwired in Guile anyway - it just needs documenting in one place)

Although it's a topic for much later, I don't think that all that
stuff _should_ be hard-wired in guile itself.  And even when it's not,
a single flat (ice-9 xxx) namespace for modules leaves something to be
desired (though my C++/Perl/Python/etc background my be shaping an
opinion other guile folks don't share..let me know).  Then, as you
say, there's that pesky documentation issue.



> - a library which provides UNIX functionality presented in a lispish programming
>     paradigm (this should be Guile's workhorse UNIX interface, and is
>     essentially a wrapper around the above library). Maybe add in here such
>     things as string completion, ANSI colours, soundex...

Do you have any further ideas on what this would look like?  Does it
already exist somewhere?



> - a library of lispish containers, iterators and algorithms (akin to the C++
>     STL; much of which is slib)
> - a library of mathematical algorithms (akin to the good ol' NAG routines; these
>     will probably be better written in C and exposed to Guile through a thin
>     wrapper)

I have places (container xxxx), (math xxxx) in my hierarchy waiting
to be filled in with these.

In addition to the list you gave, I think things like the ability to
parse/manipulate stadard data formats (emails, PNG files, AU files,
MID files, etc) would be a good fit.  I also would like to see a
database interface get in, which allows for plugins to various DB
products.  Yes, perl did that already (so did bigloo), but I don't see
why that makes it wrong for guile.  Missing modules of this type are
what keep pulling me away from guile when it comes time to do 'real'
work.  I can only marvel at tail-recursion and closures for so
long... :)


Richard Todd
richardt at vzavenue dot net

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 139 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Andreas Rottmann]

Richard Todd <richardt@vzavenue.net> writes:

> I have places (container xxxx), (math xxxx) in my hierarchy waiting
> to be filled in with these.
>
> In addition to the list you gave, I think things like the ability to
> parse/manipulate stadard data formats (emails, PNG files, AU files,
> MID files, etc) would be a good fit.  I also would like to see a
> database interface get in, which allows for plugins to various DB
> products.  
>
I have a preliminary libgda binding in my archive (see [0], module
guile-gtk--rotty--0.1) which (or rather does libgda) fullfills the
above predicate.

[0] http://stud3.tuwien.ac.at/~e9926584/Software.html#gnuarch

> Yes, perl did that already (so did bigloo), but I don't see
> why that makes it wrong for guile.  Missing modules of this type are
> what keep pulling me away from guile when it comes time to do 'real'
> work.  I can only marvel at tail-recursion and closures for so
> long... :)
>
I can also agree that a comprehensive library, diverse in functionalty
is something that guile misses. At least for the GObject[1] based APIs
(which include most of GNOME), it's really little effort to initiate a
binding with guile-gobject[2], so given a little more documentation to
lower the entry barrier, it may be feasible to get good GNOME API
coverage.

[1] http://developer.gnome.org/doc/API/2.0/gobject/index.html
[2] http://www.gnu.org/software/guile-gtk/docs/guile-gobject/

Cheers, Andy

DISCLAMER: This mail was written late and under the influence of alcohol
and other substances such as nicotine and tar.
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.at
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Latein ist das humanoide Äquivalent zu Fortran.
   -- Alexander Bartolich in at.linux


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Dale Mellor]

>>>>> "RT" == Richard Todd <richardt@vzavenue.net> writes:

    RT> On Fri, Jan 02, 2004 at 10:29:29AM +0100, Dale Mellor wrote:

    >> The collection of modules seems to be something of a hodge-podge of
    >> utility libraries (just because PERL and Python do it this way doesn't
    >> mean we have to), and overlaps with other stuff we already have (notably
    >> ice-9 and slib). I think that we should move towards developing some
    >> 'standard' libraries as separate, community-managed projects.

    RT> I'm open to all suggestions on ways we can improve on the perl/python
    RT> approach.  (Note that other scheme implementations have libs like this,
    RT> also).  I've started there because: 1) It is an existing, successful,
    RT> and popular approach 2) I can leverage the design of their modules to
    RT> get farther, faster 3) Guile currently doesn't have _any_ approach, as
    RT> far as I can tell

    That's all good. I guess I was arguing that Guile should have an
approach, and as that's what you're creating, I'm all in favour.


    RT> As for the overlap, one of the problems I'm trying to address is that
    RT> ice-9 and SLIB are hodge-podges themselves, in my view.  SLIB overlaps
    RT> guile-core and ice-9, and doesn't use guile's native module system
    RT> either.  I want to incorporate a lot of both of them (several of the
    RT> parts I have so far are in fact derived from SLIB), but put them in a
    RT> framework of modules that are cohesive and documented.  I want to
    RT> produce _the_ basic set of guile modules, that allow development to
    RT> start with a largish base of stable, documented functionality supporting
    RT> it.

    RT> The hodge-podginess of what I've put out there so far is readily
    RT> apparent because it's so preliminary--there's just not much there yet.
    RT> Of course, you might be saying that once we've filled it out that it'll
    RT> just be a much more comprehensive hodge-podge :)

    Point taken.


    >> - a low-level wrapper around libc (simple procedure definitions which
    >> reflect those in libc, much of which is already in ice-9, and a lot of
    >> the rest is hardwired in Guile anyway - it just needs documenting in one
    >> place)

    RT> Although it's a topic for much later, I don't think that all that stuff
    RT> _should_ be hard-wired in guile itself.  And even when it's not, a
    RT> single flat (ice-9 xxx) namespace for modules leaves something to be
    RT> desired (though my C++/Perl/Python/etc background my be shaping an
    RT> opinion other guile folks don't share..let me know).  Then, as you say,
    RT> there's that pesky documentation issue.

    We agree there.


    >> - a library which provides UNIX functionality presented in a lispish
    >> programming paradigm (this should be Guile's workhorse UNIX interface,
    >> and is essentially a wrapper around the above library). Maybe add in here
    >> such things as string completion, ANSI colours, soundex...

    RT> Do you have any further ideas on what this would look like?  Does it
    RT> already exist somewhere?

    Some examples off the top of my head (I'm in knee-jerk mode again ;-) ):

    In the low-level library may be functions like (fork), (exec string). In
a higher lispish library we might have (fork-with-pipe parent-proc
child-proc), where parent-proc and child-proc are procedures which take no
arguments and have their inputs and outputs set to talk to each other down a
pipe or socket. Another one might be (fork-child parent-proc child-proc)
where parent-proc is a procedure which takes one argument and this is passed
the PID of the child, and child-proc is a procedure of no arguments (or
maybe one which gets the PID of the parent). As far as I know it does not
already exist, it just occurs to me that whenever I use Guile's
(primitive-fork) and such like, I find myself forced into a more procedural
programming paradigm, with lots of (let ..)'s and (set! ..)'s. On the other
hand, imagine a world where a web server can spawn child helpers when the
load gets high just by recursion... Maybe the threads stuff could also get a
similar interface, thus abstracting the whole concept of sub-jobs.

   Another example is logging. The low-level library should contain (openlog
..)  (syslog ..) and (closelog ..), but a higher-level library should
provide in addition something like (with-output-to-syslog facility priority
proc).

   I guess in the long run we need an approach which allows people to
contribute facilities like these as they become needed, rather than trying
to design the whole high-level library up front. For my part, I am in need
of a syslog interface for my mcron project, and if I write it like I
mentioned above, I'll let you have the source so you can decide whether or
not you want to incorporate it into your library (I still haven't got round
to actually looking at your own efforts, yet).


    >> - a library of lispish containers, iterators and algorithms (akin to the
    >> C++ STL; much of which is slib) - a library of mathematical algorithms
    >> (akin to the good ol' NAG routines; these will probably be better written
    >> in C and exposed to Guile through a thin wrapper)

    RT> I have places (container xxxx), (math xxxx) in my hierarchy waiting to
    RT> be filled in with these.

    RT> In addition to the list you gave, I think things like the ability to
    RT> parse/manipulate stadard data formats (emails, PNG files, AU files, MID
    RT> files, etc) would be a good fit.  I also would like to see a database
    RT> interface get in, which allows for plugins to various DB products.  Yes,
    RT> perl did that already (so did bigloo), but I don't see why that makes it
    RT> wrong for guile.  Missing modules of this type are what keep pulling me
    RT> away from guile when it comes time to do 'real' work.  I can only marvel
    RT> at tail-recursion and closures for so long... :)

    I was not arguing against Perl or Python's approach, just making the
point that we don't have to be constrained by it. I am in agreement with all
you say above. Keep up the good work and hopefully the community will pull
together behind you on this.


    Reading the above passage gave me another knee-jerk reaction,
though. Rather than calling your modules (container xxxx) and (math xxxx), I
think I would prefer (std container xxxx) and (std math xxxx).


                                             Dale

http://rdmp.org:20202
---------------------------------------------------------------------
Despite the brusque/curmudgeonly/terse nature of my e-mails I am
really a nice guy and wish you well.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Dale Mellor]

>>>>> "Andreas" == Andreas Rottmann <a.rottmann@gmx.at> writes:

    Andreas> I can also agree that a comprehensive library, diverse in
    Andreas> functionalty is something that guile misses. At least for the
    Andreas> GObject[1] based APIs (which include most of GNOME), it's really
    Andreas> little effort to initiate a binding with guile-gobject[2], so given
    Andreas> a little more documentation to lower the entry barrier, it may be
    Andreas> feasible to get good GNOME API coverage.

   Okay, I'm out-voted - go for the monolith.


                                                       Dale

DISCLAIMER: This mail was written early in the morning and under the influence
of bacon and other substances such as Shreddies and milk.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Thien-Thi Nguyen]

   From: Richard Todd <richardt@vzavenue.net>
   Date: Thu, 1 Jan 2004 23:21:28 -0600

   Every time someone does this and contributes it to the
   library, the entire guile community gets more efficient.

this is debatable.  a numerical recipe derived from slib (for example)
has potential to suffer bit-rot when slib is enhanced.  i see that slib
now has a module system of sorts; maybe you could codify the derivation
methodology (steps to translate code from "slib module" format to "guile
module" format) so that it could be applied to each slib release, to
reduce your project's maintenance burden.

thi


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Nic Ferrier]

Or, you could just contribute your code to slib.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Clinton Ebadi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 03 January 2004 11:38, Thien-Thi Nguyen wrote:
>    From: Richard Todd <richardt@vzavenue.net>
>    Date: Thu, 1 Jan 2004 23:21:28 -0600
>
>    Every time someone does this and contributes it to the
>    library, the entire guile community gets more efficient.
>
> this is debatable.  a numerical recipe derived from slib (for example)
> has potential to suffer bit-rot when slib is enhanced.  i see that slib
> now has a module system of sorts; maybe you could codify the derivation
> methodology (steps to translate code from "slib module" format to "guile
> module" format) so that it could be applied to each slib release, to
> reduce your project's maintenance burden.

Grep the slib sources for all instances of "provide" and then generate a new 
file "std/slib/symbol-that-is-provided.scm" that does a (use-modules (ice-9 
slib)), does a (require 'symbol-that-is-provided) and then exports all the 
symbols in the current model to the outside world 

(set-module-uses! %module-public-interface
                  (list (nested-ref the-root-module '(app modules std slib 
symbol-that-is-provided))))

Then rewrite the doc schmooz stuff to generate the portions of the manual you 
need.
- -- 
http://unknownlamer.org
AIM:unknownlamer IRC:unknown_lamer@freenode#hprog
I use Free Software because I value freedom over features.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/9wfNdgGh8PQDV0sRAocfAKDOb4EhcNEZi+uDnpREKSGJ4r0mhACdFYTb
B/CbjV277ftTwj3yojM9DVs=
=g1EZ
-----END PGP SIGNATURE-----


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Thien-Thi Nguyen]

   From: Clinton Ebadi <clinton@unknownlamer.org>
   Date: Sat, 3 Jan 2004 13:19:49 -0500

   Grep the slib sources for all instances of "provide" [...]

have you actually tried this?

regardless, slib has other reflective capabilities nowadays anyway.

thi


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Richard Todd]

[-- Attachment #1.1: Type: text/plain, Size: 2586 bytes --]

On Sat, Jan 03, 2004 at 04:48:40PM +0000, Nic Ferrier wrote:
> Or, you could just contribute your code to slib.
> 

(sorry for the long-winded respose..I kind of get carried away.  I
don't think your suggestion is a bad one--it needs more consideration,
and I look forward to hearing other opinions on this matter)

That said, my thought process went like this:

The SLIB suggestion could apply to any other scheme implementation,
and yet other schemes all have libraries of their own.  I wonder why
no one has suggested that I just contribute it all to ice-9?  I would
give much the same response:

I read somewhere (have no idea if it's true, but still..) that, years
back, sales of books in America skyrocketed.  Not because the books
were better.  Not because more people were literate.  But because book
publishers paid house builders to build bookcases into new homes.  Now
people had all these bookshelves and needed to fill them!

That's what I'm trying to do for guile.  I (with some help, I hope!)
am building a large hierarchy that's calling out to be filled in.
It's built from the start to be huge.  Furthermore, it's not some
bridge to a generic library with some single-namespace'd 'require'
mechanism...it's written in guile, for guile users.  Just as people
don't buy books to fill other people's bookshelves, it seems to me
that people aren't writing much guile code to enhance SLIB.  I hope
they will want to get new code into a guile standard library.
Especially if it is organized and documented.

My hope is this helps validate guile as a powerful tool and not a toy.

This is gonna sound harsh, but if a new guile user wants to write an
extension to some program that sends emails, what do they do?  They
can search guile's core and find they can build their own smtp/rfc2822
system on top of tcp/ip.  No, thonks.  They can look through ICE-9
(once they figure out that this thing called 'ice-9' is guile's
library of modules, which isn't immediately obvious--trust me) and
come up short.  They can click on the dead links to version 0.3a of
this-and-that on the projects list (can this not be cleaned out?).  If
they persevere, they will eventually find some email stuff in
ttn-pers-scheme.  Who can tell their boss with conviction that they
need to build important systems tied together with ttn's personal
scheme library?

The basis for this project is that it should just be:
(use-modules (net email sendmail))
...or they are probably heading straight back to perl.

Richard Todd
richardt at vzavenue dot net

[-- Attachment #1.2: Type: application/pgp-signature, Size: 186 bytes --]

[-- Attachment #2: Type: text/plain, Size: 139 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Richard Todd]

[-- Attachment #1.1: Type: text/plain, Size: 2154 bytes --]

On Sat, Jan 03, 2004 at 03:36:08PM +0100, Dale Mellor wrote:
>     RT> Do you have any further ideas on what this would look like?  Does it
>     RT> already exist somewhere?
> 
>     Some examples off the top of my head (I'm in knee-jerk mode again ;-) ):

<<snip stuff about high-level interface to fork-exec>>

With Gary Houston's blessing, I've incorporated the Goosh module as
(os process). that allows for syntax like

(tail-call-pipeline ("ls" "/etc") ("grep" "passwd"))

ond other higher-level fork-type constructs.  Its quite possible that
more of your ideas like this can be incorporated between now and the
first release in June.  Unifying this with threads (at least to the
point where similar operations have similar interfaces) sounds like a
very good idea indeed.

 >  Another example is logging. The low-level library should contain
 > (openlog  ..)  (syslog ..) and (closelog ..), but a higher-level
 > library should provide in addition something like
 > (with-output-to-syslog facility priority proc).

In my development branch I'm already working on nearly exactly that!
Something like (with-output-to-log "main" 'CRITICAL (lambda () ...)).
So we are definitely on the same wavelength here.  I had not previously
given much thought to separating out the low level and high level
interfaces.  They might have both ended up in (logging logger).  I'll
give some more thought to how I can do this.

 > Reading the above passage gave me another knee-jerk reaction,
 > though. Rather than calling your modules (container xxxx) and 
 > (math xxxx), I think I would prefer (std container xxxx) and 
 > (std math xxxx).

Whenever I finally get a listing on savannah, this was going to be the
first question I posed to the guile-library mailing list.  I keep
changing my mind about what would be best.  I could forsee in a few
years needing to reorganize the modules once we get to a certain size,
and jumping to (std2 xxx) would be a nice way to split with the past.
Of course doing this mare than once or twice a decade would make
things quite messy...

Richard Todd
richardt at vzavenue dot net

[-- Attachment #1.2: Type: application/pgp-signature, Size: 186 bytes --]

[-- Attachment #2: Type: text/plain, Size: 139 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Richard Todd]

[-- Attachment #1.1: Type: text/plain, Size: 1771 bytes --]

On Sat, Jan 03, 2004 at 05:38:28PM +0100, Thien-Thi Nguyen wrote:
>    From: Richard Todd <richardt@vzavenue.net>
>    Date: Thu, 1 Jan 2004 23:21:28 -0600
> 
>    Every time someone does this and contributes it to the
>    library, the entire guile community gets more efficient.
> 
> this is debatable.  a numerical recipe derived from slib (for example)
> has potential to suffer bit-rot when slib is enhanced.  i see that slib
> now has a module system of sorts; maybe you could codify the derivation
> methodology (steps to translate code from "slib module" format to "guile
> module" format) so that it could be applied to each slib release, to
> reduce your project's maintenance burden.

Yes, there will be maintenance to do when significant changes to the
source material appear.  I don't have a really good answer for that
problem, since anything but copying and (slightly) modifying their
sources conflics with the other goals I have for the project.

What I have done, is start a mapping between the project modules and
their SLIB sources.  I'm not sure, but if I re-sync with SLIB once a
year or so, that doesn't seem like too much of a maintenance headache.
I may feel differently the first time I actually have to *do* it!

For the stuff already written for guile that gets pulled in, I hope
the maintainers will either maintain their modules as part of the
standard lib, or actively help push their changes into the library at
their major updates.

This topic is definitely still up for debate.. I have pulled in some
SLIB sources as examples of what it would look like, but I have no
problem completely changing direction on that issue if guile users
think it would be best.

Richard Todd
richardt at vzavenue dot net

[-- Attachment #1.2: Type: application/pgp-signature, Size: 186 bytes --]

[-- Attachment #2: Type: text/plain, Size: 139 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Thien-Thi Nguyen]

   From: Richard Todd <richardt@vzavenue.net>
   Date: Sat, 3 Jan 2004 16:18:57 -0600

   I wonder why
   no one has suggested that I just contribute it all to ice-9?

probably because the most important thing about a project where you plan
to harvest contributions from fellow programmers is its methodology and
how comfortably that sits w/ those programmers.  next-most important is
the structure and vision of your project (x and dx, respectively, if you
consider methodology the dx2).  ice-9 has no dx and guile maintenance
behavior demonstrates little to encourage dx2, so the end result is x
remains static (or circles the drain slowly, depending on your poetic
mood :-).  for this reason i don't suggest you to direct energy towards
ice-9, but others may have their own reasons.

   [...] a large hierarchy that's
   calling out to be filled in.  It's built from the start to be huge.
   Furthermore, it's not some bridge to a generic library with some
   single-namespace'd 'require' mechanism...it's written in guile, for
   guile users.

i like the idea of providing a framework, but caution you against
getting stuck on the implementation details.  for slib (for example), if
the bridging is as easy as another poster has intimated, why preclude
that from your plans?  the bridge is still guile scheme (it has to be),
and the beneficiaries are still guile users (who are all programmers,
btw, and presumably appreciative of the value of not relying on possibly
out-of-date bits of rewritten slib).  IMHO, the interesting problem to
be solved in this case is not in the code per se, but in its management.

btw, i consider "generic library" high (and deserved) praise for slib.

   Just as people don't buy books to fill other people's
   bookshelves, it seems to me that people aren't writing much guile
   code to enhance SLIB.

hmmm, i'm stretching my brain to understand this sentence... ok.

   I hope they will want to get new code into a
   guile standard library.  Especially if it is organized and
   documented.

if you write the docs first (taking the definition of an "interface" to
include proc signatures, docs, error behavior, etc.), it will be easy
for people to see if the code they may have sitting around already fits
into the organization, and if not, to write or adapt it so that it does.

   Who can tell their boss with conviction that they
   need to build important systems tied together with ttn's personal
   scheme library?

well, ttn can, to his boss...

excuse this smarmy blurb, it's for the ignorant: ttn-pers-scheme is
released under the GNU GPL, which stipulates for its users certain
freedoms related to its source code.  germaine to this discussion is the
freedom to locally modify the source for whatever reason necessary, even
for "internal marketing/sales" purposes such as...

   The basis for this project is that it should just be:
   (use-modules (net email sendmail))

... something like:

(define-module (net email sendmail)
  #:use-module (ttn parse-rfc822)            ; for auto-reply
  #:use-module (j-r-hacker mail-utils)       ; for compose-mail
  ...)

(define (auto-reply ...) ...)
(define (compose-mail ...) ...)

and so on.  it could be that people are doing this already, but more
locally than not (and w/ little fanfare or further distribution).  who
knows?  who cares?

anyway, to sum up my pov: a nice GPLed user-supported standard library
for guile would be very welcome, and most welcome would be a standard
set of well-organized interfaces, responsibly maintained.  otherwise,
no matter the name, it will simply be another *-pers-scheme package in
spirit (nothing wrong w/ that, of course ;-).

thi


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Thien-Thi Nguyen]

   From: Richard Todd <richardt@vzavenue.net>
   Date: Sat, 3 Jan 2004 16:52:26 -0600

   I may feel differently the first time I actually have to *do* it!

anything you have to do manually that you could have described to a
computer to do for you, is an opportunity for growth (for you and the
computer, both :-).

thi


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Richard Todd]

[-- Attachment #1.1: Type: text/plain, Size: 1644 bytes --]

On Sat, Jan 03, 2004 at 01:19:49PM -0500, Clinton Ebadi wrote:
> Grep the slib sources for all instances of "provide" and then generate a new 
> file "std/slib/symbol-that-is-provided.scm" that does a (use-modules (ice-9 
> slib)), does a (require 'symbol-that-is-provided) and then exports all the 
> symbols in the current model to the outside world 

If I'm understanding you, this would be an slib wrapper such that guile users
would say:

(use-modules (slib factor))

and that file would look like:
----
(define-module (slib factor)
  #:uses-module (ice-9 slib))

(require 'factor)

;; and then export whatever slib factor uses for a public interface?
----

> (set-module-uses! %module-public-interface
>                   (list (nested-ref the-root-module '(app modules std slib 
> symbol-that-is-provided))))

I'm not familiar with the set-module-uses! interface, so I'm not sure
what you are getting at there.  The guile info pages seem to be silent
on them as well.  Any hints?

This would certainly make slib more seamless for guile users.  I like
that it should allow people to use the guile renaming mechanism to
manage naming conflicts, whereas I don't think SLIB's require
mechanism accounts for that sort of thing.

For my tastes I'd still prefer (math primes) rather than (slib
factor), so that it fits into a larger, cohesive library.  I was also
hoping to not absorb parts of slib that overlap what guile already
provides, and that means changing the slib sources.  Maybe that's the
wrong answer, and I should just accept the duplication.

Richard Todd
richardt at vzavenue dot net


[-- Attachment #1.2: Type: application/pgp-signature, Size: 186 bytes --]

[-- Attachment #2: Type: text/plain, Size: 139 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Richard Todd]

[-- Attachment #1.1: Type: text/plain, Size: 3803 bytes --]

On Sun, Jan 04, 2004 at 02:49:01AM +0100, Thien-Thi Nguyen wrote:
> i like the idea of providing a framework, but caution you against
> getting stuck on the implementation details.  for slib (for example), if
> the bridging is as easy as another poster has intimated, why preclude
> that from your plans? 

I'm not precluding it--but I'm trying to think through other options,
since I think the coherence of the whole library would suffer.  Maybe
not as much as I worry, but it would have to.  Let's say we take in a
logging framework, and then find some other code that does syslogging.
What are our options:

  1) We could include that code too.  So now there are two logging
mechanisms in the library.  With potentially very different styles of
interfaces, and different naming conventions.  In one all functions
are log:xxx and log:yyy, but in the other all the function names are
write-syslog.

  2) We could make the needed modifications to fit the new syslogging
behavior into the logging framework (leading to bit-rot if the
syslogger is updated and I don't take those changes right away).

The situation can be even more complicated, like if both allow you to
filter the logs by regexp, but use two different regexp libraries with
different capabilities.  Now there's another decision point.

Another example would be slib minimize.scm, which has one method for
minimization in it.  If I find another lib with four more methods in
it, should I combine them into a single, coherent module, or leave two
modules out there (possibly with contrived names so that they are
different)--one with one function and one with four?  Or wrap them in
a third module that re-exports all the methods, and attempt to keep
the two 'base' madules private?

This type of problem will show up time and again.  I have been leaning
towards the option that produces the most coherent product so far, but
like all complicated decisions, there are downsides to it.  


Another option for the project would be to actively avoid things
that are already in SLIB, Guile-core, or wherever else, and just 'fill
in the gaps.'  I'm having trouble taking that road, because it's
asking users to look 5 places for everything they think might be
available, and deal with all the variations and overlap inherent in
it.  And, though people may get tired of me waving the python standard
around, you just don't have this problem with other languages.  Sure,
there are lots of independent libraries out there, but the basics are
covered 'out of the box'.

And this is exactly the kind of discussion I'd like to have and
resolve before I put too much effort into this.  I'd like everyone to
be happy with the outcome, and contribute to a successful project.


> btw, i consider "generic library" high (and deserved) praise for slib.

I'm not knocking it for being generic--I'm saying no major scheme
implementation that I know of just points you to SLIB..  they all have
libraries of their own.


> (define-module (net email sendmail)
>   #:use-module (ttn parse-rfc822)            ; for auto-reply
>   #:use-module (j-r-hacker mail-utils)       ; for compose-mail
>   ...)
> 
> (define (auto-reply ...) ...)
> (define (compose-mail ...) ...)
> 
> and so on.  it could be that people are doing this already, but more
> locally than not (and w/ little fanfare or further distribution).  who
> knows?  who cares?

I care, because building an infrastructure that others can build on is
an important part of making guile useful in the real world.  If lots
of people are out there quietly cobbling together email packages out
of fragments of people's pet projects, then we are not acting in a
very efficient manner.

Richard Todd
richardt at vzavenue dot net

[-- Attachment #1.2: Type: application/pgp-signature, Size: 186 bytes --]

[-- Attachment #2: Type: text/plain, Size: 139 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Thien-Thi Nguyen]

   From: Richard Todd <richardt@vzavenue.net>
   Date: Sat, 3 Jan 2004 21:50:22 -0600

   I'm trying to think through other options,
   since I think the coherence of the whole library would suffer.

from lurking on the emacs-devel mailing list, i've come to understand
the word "coherence" in an application context (app == emacs) to be
definition 1b from webster's[1], the operative word being "integration".
in a library context, what kind of integration are we talking about?  if
integration is actually not what you mean, could you explain how would
"coherence of the whole library" be measured?

   1) We could include that code too.  [...]
   2) We could make the needed modifications [...]

   The situation can be even more complicated, like if both allow you to
   filter the logs by regexp, but use two different regexp libraries with
   different capabilities.

here are two decisions you can make early on:

(a)
what is the policy re proliferation of work-alike (but not exactly
identical) interfaces?  one-size-fits-all vs pluralistic-menu.  for
the latter, you would probably want to specify "adapter" modules to
reduce interface complexity from NxM to N+M.  for the former, the
proliferation problem is defined away but the immediate usefulness of
the library is reduced for some users, who would be forced to do the
adaptation outside the library (probably in isolation, without
further distribution) -- same boat as the *-pers-scheme approach,
basically.

(b)
what is the policy for changing an interface wrt backwards
compatibility?  if you allow backward-incompatible changes, users
will learn to not trust the library (or at least allocate trust to
those elements that have changed in this way very begrudgingly).  if
you disallow backward-incompatible changes, you need to be supremely
careful when defining interfaces for one-size-fits-all approach,
slightly less careful for pluralistic-menu.

figure out (a) and (b) and a maintenance strategy will probably
present itself naturally.

   Another example would be slib minimize.scm [...]  Or wrap them in
   a third module that re-exports all the methods, and attempt to
   keep the two 'base' madules private?

perhaps figuring out the maintenance axioms can help answer this.
certainly, separating the design of the interface from that of the
implementation allows you some flexibility.

   Another option for the project would be to actively avoid things
   that are already in SLIB, Guile-core, or wherever else, and just
   'fill in the gaps.'  I'm having trouble taking that road, because
   it's asking users to look 5 places for everything they think might
   be available, and deal with all the variations and overlap
   inherent in it.  And, though people may get tired of me waving the
   python standard around, you just don't have this problem with
   other languages.  Sure, there are lots of independent libraries
   out there, but the basics are covered 'out of the box'.

i think it would be a mistake to willfully ignore what is out there,
but that doesn't mean you can't provide a valuable bundling service.
much depends on how you feel about not being the only such service.

   I care, because building an infrastructure that others can build
   on is an important part of making guile useful in the real world.
   If lots of people are out there quietly cobbling together email
   packages out of fragments of people's pet projects, then we are
   not acting in a very efficient manner.

IME as a "user" of programming languages, tools, and employees,
useful trumps standard trumps efficient.  in practice, efficiency is
such a fuzzy concept, it is often measured in terms of usefulness!

thi


______________________________
[1] M-x dict sez:
    Main Entry: co·her·ence # #
    Pronunciation: kO-'hir-&n(t)s, -'her-
    Function: noun
    Date: 1580
    1 : the quality or state of cohering : as a : systematic or
    logical connection or consistency b : integration of diverse
    elements, relationships, or values
    2 : the property of being coherent


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Dale Mellor]

>>>>> "Thien-Thi" == Thien-Thi Nguyen <ttn@surf.glug.org> writes:
    Thien-Thi> from lurking on the emacs-devel mailing list, i've come to
    Thien-Thi> understand the word "coherence" in an application context... in a
    Thien-Thi> library context, what kind of integration are we talking about?
    Thien-Thi> if integration is actually not what you mean, could you explain
    Thien-Thi> how would "coherence of the whole library" be measured?

    IMHO, in this case, coherence = efficiency, and efficiency is defined as the
ratio of satiated user's expectations over lines of code to implement. In other
words, a good library is one that meets a lot of people's needs without imposing
a massive maintainence burden on the library maintainer (which in turn delivers
reliability).


    Thien-Thi> here are two decisions you can make early on:

    Thien-Thi> (a) what is the policy re proliferation of work-alike (but not
    Thien-Thi> exactly identical) interfaces?  one-size-fits-all vs
    Thien-Thi> pluralistic-menu...

    Thien-Thi> (b) what is the policy for changing an interface wrt backwards
    Thien-Thi> compatibility?
    Thien-Thi> IME as a "user" of programming languages, tools, and employees,
    Thien-Thi> useful trumps standard trumps efficient.  in practice, efficiency
    Thien-Thi> is such a fuzzy concept, it is often measured in terms of
    Thien-Thi> usefulness!

    IMHO, we should be looking at a well designed one-size-fits-all interface
approach (otherwise it will never be documented properly, and will be a slur
against the purity of the scheme programming language). We should use three-part
version numbers, and within a major version release there should be complete
backwards compatibility among minor version changes (there may be localized
compatibility breakages amongst micro versions as interfaces are worked out and
stabilized). If one day it transpires that a wrong turn was made and a new
direction is needed, then the major version should be incremented, and a new
namespace (std-2, say) be introduced, ***but the older (std) namespace should be
kept in the library so as not to break any existing code***.


                                                          Dale


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Arno Peters]

[-- Attachment #1.1: Type: text/plain, Size: 1021 bytes --]

On Thu, Jan 01, 2004 at 11:21:28PM -0600, Richard Todd wrote:

> There are plenty of things to fill in, and help would be
> appreciated.  If you have a few hours one weekend, pull out your
> 'numerical recipes' book and make a scheme version of some
> algorithms.  Every time someone does this and contributes it to the
> library, the entire guile community gets more efficient.

Please check out my guile-numerics project on Savannah
(http://www.nongnu.org/guile-num).  It wraps most of the GNU
Scientific Library, FFTW and libsndfile through SWIG.  It also
includes some higher level functions to provide a simpler interface to
the math routines.  For numerical work, GSL and FFTW have a proven
track record and it would be foolish to duplicate much of that work.

What is still lacking, though, is a uniform interface for hiding the
low-level GSL interactions and presenting the user/programmer with a
consistent scheme interface.  Help with this is always welcome.

Regards,
-- 
Arno Peters



[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 139 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Richard Todd]

(writing from my windows machine, so not set up to gpg sign it, but it's 
me I promise!)

Thien-Thi Nguyen wrote:
> here are two decisions you can make early on:
> 
> (a)
> what is the policy re proliferation of work-alike (but not exactly
> identical) interfaces?  one-size-fits-all vs pluralistic-menu.  for
> the latter, you would probably want to specify "adapter" modules to
> reduce interface complexity from NxM to N+M.  for the former, the
> proliferation problem is defined away but the immediate usefulness of
> the library is reduced for some users, who would be forced to do the
> adaptation outside the library (probably in isolation, without
> further distribution) -- same boat as the *-pers-scheme approach,
> basically.

I thought that's what I was trying to ask in my post, via the examples I 
gave.  I'm looking for input on what the community wants, and (more 
importantly) would help contribute to.  I don't want to go this alone, 
and in fact I think it would be ridiculous to generate a 'standard' 
library in isolation!

I don't follow why one-size-fits-all would reduce the immediate 
usefulness of the libarary for some users.  Are you are talking about a 
user who was already using an interface from another library that I 
incorporated and changed?  Compared to the benefit to new users who 
would not be faced with several disjoint interfaces, I think this is 
insignificant (especially since they can keep on using the old lib if 
they want).


> (b)
> what is the policy for changing an interface wrt backwards
> compatibility?  if you allow backward-incompatible changes, users
> will learn to not trust the library (or at least allocate trust to
> those elements that have changed in this way very begrudgingly).  if
> you disallow backward-incompatible changes, you need to be supremely
> careful when defining interfaces for one-size-fits-all approach,
> slightly less careful for pluralistic-menu.

I agree with Dale Mellor's response.  It's standard practice to stay 
compatible along minor version numbers, and OK to break backwards 
compatibility across major version numbers.  This code base should grow 
over time, and the ideal organization and interface to the modules will 
certainly shift, even if we do get it perfect in the first place (which 
we won't, of course).

What do you think of (std ...) => (std2 ...) as a means of letting older 
code run forever?  I've read c++ is considering this approach.  I don't 
think it should happen but every 5 years or so, and only then if 
backwards compatibility has become a burden.

As for 'supremely careful', this is why I have released work so early, 
and plan for all of us working on the project to do the same.  I want 
the time between now and June to be the period where people attempt to 
use and criticize what's out there.  Anything that is still 
controversial will be left out of the first release.

I'm a little disappointed that all the response I've gotten has been 
about the library concept, and no one has yet appeared to be interested 
in the code I've put out there to date.  Do you like it?  Hate it? 
Don't care about it?  Can it be that only Java/Python/Perl/Ruby need 
logging services, and scheme does not?


> > Another example would be slib minimize.scm [...]  Or wrap them in
> > a third module that re-exports all the methods, and attempt to
> > keep the two 'base' madules private?
 >
> perhaps figuring out the maintenance axioms can help answer this.
> certainly, separating the design of the interface from that of the
> implementation allows you some flexibility.

Again, yes, figuring that stuff out would help, and that's why I brought 
it up.  I'm looking for input.  Much of your post seems to be re-asking 
the same questions I was asking.

I can answer these questions on my own (and I think I mostly have done 
so by way of releasing code that has a certain slant to it), but I am 
trying to get a feel for what others think is best for guile.  I think 
we all at least agree that having _something_ is desireable.


> i think it would be a mistake to willfully ignore what is out there,
> but that doesn't mean you can't provide a valuable bundling service.
> much depends on how you feel about not being the only such service.

I am trying to start a project, but it's not about me, or being the only 
service.  It's a question of whether we want a bundle or a framework.

I have said, and do believe, that it would be good to have a single 
library that provides the baseline infrastructure for doing useful work. 
  Would everyone be satisfied if we grouped 6 packages and made sure 
they all 'configure && make install' properly, or do people want 
something more than that?  I was imagining they would want more, but now 
would be the best time to find out I'm wrong about that.

Where are the other such services, anyway?

>  > I care, because building an infrastructure that others can build
>  > on is an important part of making guile useful in the real world.
>  > If lots of people are out there quietly cobbling together email
>  > packages out of fragments of people's pet projects, then we are
>  > not acting in a very efficient manner.
> 
> IME as a "user" of programming languages, tools, and employees,
> useful trumps standard trumps efficient.  in practice, efficiency is
> such a fuzzy concept, it is often measured in terms of usefulness!

Regardless of which trumps which, what is 'useful', 'standard', *OR* 
'efficient' about what a guile user has today?  When I download the JDK 
I have a ton of 'useful', 'standard', *AND* 'efficient' components from 
which I can start useful work.  There is no comparison, even if you 
start with (+ guile ice-9 slib).

I've had a serious suggestion that I redirect this effort to SLIB, and 
I'm mulling that over.  I would have to make serious changes, since I've 
been freely using guile-specific code so far (such as goops classes). 
I'm also not thrilled with the way slib is organized, but there would be 
some benefits to going that way.  We could still produce a (use-modules) 
interface to the entire SLIB library, which I think makes sense in any 
case.  Any thoughts?

Richard Todd




_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Andreas Rottmann]

Richard Todd <richardt@vzavenue.net> writes:

>> (b)
>> what is the policy for changing an interface wrt backwards
>> compatibility?  if you allow backward-incompatible changes, users
>> will learn to not trust the library (or at least allocate trust to
>> those elements that have changed in this way very begrudgingly).  if
>> you disallow backward-incompatible changes, you need to be supremely
>> careful when defining interfaces for one-size-fits-all approach,
>> slightly less careful for pluralistic-menu.
>
> I agree with Dale Mellor's response.  It's standard practice to stay
> compatible along minor version numbers, and OK to break backwards
> compatibility across major version numbers.  This code base should
> grow over time, and the ideal organization and interface to the
> modules will certainly shift, even if we do get it perfect in the
> first place (which we won't, of course).
>
> What do you think of (std ...) => (std2 ...) as a means of letting
> older code run forever?  I've read c++ is considering this approach.
> I don't think it should happen but every 5 years or so, and only then
> if backwards compatibility has become a burden.
>
Hmm, I always kind of disliked that approach. 

1) It's probably very hard for a standard library (which presumably
   consists of lots of modules) to stay API-compatible over an
   longer period of time. Consider the GNOME project -- they have
   the concept of the "GNOME developer platform", which will, given a
   constant *minor* release number stay API compatible, but may (and
   mostly will) break API every minor release number change, which
   happens about every six months.

2) Presumed the need for API-breaking changes are needed, in turn not
   to hinder development of the library itself, in intervals quite
   smaller than 5 years, it would be more of a annoyance to developers
   regularly adapting to the API changes (which indeed should only be
   "major" in the sense that they require a lot of adaption to
   existing code accross major version changes) to require changing
   all their code to use stdY instead of stdX.

> I'm a little disappointed that all the response I've gotten has been
> about the library concept, and no one has yet appeared to be
> interested in the code I've put out there to date.  Do you like it?
> Hate it? Don't care about it?  Can it be that only
> Java/Python/Perl/Ruby need logging services, and scheme does not?
>
I just skimmed a bit over your code, and it seems quite OK. A few bits
I've noticed:

------- (logging logger) -----------

1)

,----
| (define (register-logger! str lgr)
|   (if (not (string? str))
|       (throw 'bad-type "Expected a string for the log registration"))      
|   (hash-set! all-loggers str lgr))
`----

Why not make GOOPS care for type-checking (given GOOPS is used)?


2) Have you considered the need for a "log domain" as in GLib? This
   can be useful e.g. for an application to dump most logs including
   all those generated by libraries into a file and present all logs
   messages from its own domain and above a certain level in a special
   way (e.g. message dialog).

Regards, Andy
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.at
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Packages should build-depend on what they should build-depend.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Paul Jarc]

Richard Todd <richardt@vzavenue.net> wrote:
> It's standard practice to stay compatible along minor version
> numbers, and OK to break backwards compatibility across major
> version numbers.
...
> What do you think of (std ...) => (std2 ...) as a means of letting
> older code run forever?

It's doubtful that incompatible changes will happen to all modules in
this collection all at the same time.  Coercing them all into a single
version number/compatibility schedule doesn't seem helpful.

> Can it be that only Java/Python/Perl/Ruby need logging services, and
> scheme does not?

I don't think syslog is a good idea regardless of the language.  It's
more flexible to print logs to stdout/stderr; then it's easy to choose
another program to add to the pipeline for filtering and storing the
logs.

> I have said, and do believe, that it would be good to have a single
> library that provides the baseline infrastructure for doing useful
> work.

As long as the code exists, I don't think there's much benefit in
aggregating it.  It just has to be easy for users to find.

Of course, all this applies to all software, not just Guile modules.
So I think a Guile-only solution would be wasted effort.  We'd be
better off with language-independent version management and a software
directory that could be filtered and searched to find, e.g., a Guile
SMTP library.  slashpackage would be a good place to start.
<URL:http://cr.yp.to/slashpackage.html>


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Richard Todd]

Paul Jarc wrote:
> It's doubtful that incompatible changes will happen to all modules in
> this collection all at the same time.  Coercing them all into a single
> version number/compatibility schedule doesn't seem helpful.

Helpful to whom?  I'd argue that it's extremely helpful to users if they 
only have to deal with "package X requires Guile-Library v1.5 or above", 
rather than "package X requires these versions of these 17 modules: ..."


> I don't think syslog is a good idea regardless of the language.  It's
> more flexible to print logs to stdout/stderr; then it's easy to choose
> another program to add to the pipeline for filtering and storing the
> logs.

If Chewbacca lives on Endor, you must acquit! The defense rests.
(in other words, what does this have to do with the topic at hand???)


> As long as the code exists, I don't think there's much benefit in
> aggregating it.  It just has to be easy for users to find.

Ok, I am definitely starting to feel like a stranger in a strange land, 
here.  If this many people really don't think that guile is missing 
basic library services, maybe it's just not right for guile.  I expected 
several classes of response to this project, but I never anticipated 
that people didn't think it was needed.  Having used many languages over 
the years, to me it stands out as an obvious hole.  But that's just me.

Searching with google, I found a pretty good sounding proposal from 2001 
by Martin Grabmueller for reorganizing ice-9 into a hierarchy a lot like 
what I was working towards.  It even happened to have some of the same 
names like (math primes) in it!  It was addressing other topics I have 
yet to bring up, but planned to, such as putting srfi capabilities in 
named modules and making (srfi srfi-XX) the alternate interface.

What happened to that?  Based on the surrounding messages it seemed to 
be received well.  Nearly three years have passed...
(http://mail.gnu.org/archive/html/guile-devel/2001-03/msg00116.html)

Richard Todd




_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Richard Todd]

Andreas Rottmann wrote:
> Hmm, I always kind of disliked that approach. 
> 

<snip>

> 2) Presumed the need for API-breaking changes are needed, in turn not
>    to hinder development of the library itself, in intervals quite
>    smaller than 5 years, it would be more of a annoyance to developers
>    regularly adapting to the API changes (which indeed should only be
>    "major" in the sense that they require a lot of adaption to
>    existing code accross major version changes) to require changing
>    all their code to use stdY instead of stdX.

You could be right.  I was thinking along these lines:

There is a lot that can be done to preserve compatibility over a period 
of time, that essentially builds up cruft in the library.  Things like 
leaving the old function name _and_ the new function name in.  Things 
like moving the module _and_ leaving a module in the original location 
to load it, too.  Things like adding the second XML processing module 
but leaving the original one there too.

Then, (I was hoping only once every few years), you have to say 
"Enough!" and break with the past.

It could be that it's best to do something in-between, and let small 
incompatibilities in over time, and reserve std2 for a massive 
reorganization.  Some people do a "deprecate-for-1-major-release" 
strategy, after which deprecated things disappear.  That might be an 
option also.

> 1)
> 
> ,----
> | (define (register-logger! str lgr)
> |   (if (not (string? str))
> |       (throw 'bad-type "Expected a string for the log registration"))      
> |   (hash-set! all-loggers str lgr))
> `----
> 
> Why not make GOOPS care for type-checking (given GOOPS is used)?

Good question!  I'll do this.

> 2) Have you considered the need for a "log domain" as in GLib? This
>    can be useful e.g. for an application to dump most logs including
>    all those generated by libraries into a file and present all logs
>    messages from its own domain and above a certain level in a special
>    way (e.g. message dialog).
Not familiar with GLib, but if you mean that different parts of the 
program talk to different named 'domains', then that you should be able 
to get something similar with the register-logger! mechanism, right? 
You could log to as many named loggers as you want.  You can even assign 
the same handlers to different named loggers.  So, your "gtk" logger 
could be sending its logs to the same files as your "app" logger, for 
instance.  I may not fully understand the domain concept, yet, though.

thanks,
Richard





_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Paul Jarc]

Richard Todd <richardt@vzavenue.net> wrote:
> I'd argue that it's extremely helpful to users if they only have to
> deal with "package X requires Guile-Library v1.5 or above", rather
> than "package X requires these versions of these 17 modules: ..."

As long as each module does a decent job of not breaking compatibility
too much, and as long as modules are easy to install, I don't think
it's much of a problem for them to be separated.

>> I don't think syslog is a good idea regardless of the language.  It's
>> more flexible to print logs to stdout/stderr; then it's easy to choose
>> another program to add to the pipeline for filtering and storing the
>> logs.
>
> If Chewbacca lives on Endor, you must acquit! The defense rests.
> (in other words, what does this have to do with the topic at hand???)

You asked about logging, so I was responding to that individual point.
Maybe I misunderstood you.

> If this many people really don't think that guile is missing basic
> library services, maybe it's just not right for guile.

I'm not saying that nothing is missing; I agree that for many tasks,
it's much easier to find libraries for Perl or Python than for Guile.
I'm saying that the problem (finding and organizing software) is
bigger than Guile, and so the solution should be as well.  Solving the
same problem over and over again in different microcosms is a waste of
effort.  I also don't think aggregation of separate modules into a
single package is necessarily a good idea.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Dale Mellor]

>>>>> "Andreas" == Andreas Rottmann <a.rottmann@gmx.at> writes:

    Andreas> Richard Todd <richardt@vzavenue.net> writes:
    >> What do you think of (std ...) => (std2 ...) as a means of letting older
    >> code run forever?  I've read c++ is considering this approach.  I don't
    >> think it should happen but every 5 years or so, and only then if
    >> backwards compatibility has become a burden.
    >> 
    Andreas> Hmm, I always kind of disliked that approach.

    Andreas> 1) It's probably very hard for a standard library (which presumably
    Andreas> consists of lots of modules) to stay API-compatible over an longer
    Andreas> period of time. Consider the GNOME project -- they have the concept
    Andreas> of the "GNOME developer platform", which will, given a constant
    Andreas> *minor* release number stay API compatible, but may (and mostly
    Andreas> will) break API every minor release number change, which happens
    Andreas> about every six months.

    There is a big difference between the Guile stdlib and GNOME. GNOME is a
tight-knit community of advanced developers (for the most part, anyway), whereas
the Guile lib has to appeal to and be used by complete novices (people who only
pick the language up because it is used in the configuration of another program,
for example). The Guile lib is much more like C++ STL than libgnome. It has to
set the standard for people to use, and keep it. You cannot expect every
developer of a Guile script to keep step with API changes. Breaking API every
six months is, simply, not acceptable for the Guile lib.



    Andreas> 2) Presumed the need for API-breaking changes are needed, in turn
    Andreas> not to hinder development of the library itself, in intervals quite
    Andreas> smaller than 5 years, it would be more of a annoyance to developers
    Andreas> regularly adapting to the API changes (which indeed should only be
    Andreas> "major" in the sense that they require a lot of adaption to
    Andreas> existing code accross major version changes) to require changing
    Andreas> all their code to use stdY instead of stdX.

    They don't have to change all of their code to stdY if stdX remains
available.


    >> I'm a little disappointed that all the response I've gotten has been
    >> about the library concept, and no one has yet appeared to be interested
    >> in the code I've put out there to date.  Do you like it?  Hate it? Don't
    >> care about it?  Can it be that only Java/Python/Perl/Ruby need logging
    >> services, and scheme does not?
    >> 
    Andreas> I just skimmed a bit over your code, and it seems quite OK. A few
    Andreas> bits I've noticed:

    I'm sorry I'm making blind comments without yet having looked at your
code. I keep meaning to do it but am having difficulty making the
space. However, I think the question of the approach to design is much more
important right now than the implementation details.

                                                 Dale


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Thien-Thi Nguyen]

   From: Richard Todd <richardt@vzavenue.net>
   Date: Sun, 04 Jan 2004 15:51:17 -0600

   I don't follow why one-size-fits-all would reduce the immediate
   usefulness of the libarary for some users.  Are you are talking about
   a user who was already using an interface from another library that I
   incorporated and changed?  Compared to the benefit to new users who
   would not be faced with several disjoint interfaces, I think this is
   insignificant (especially since they can keep on using the old lib if
   they want).

i presumed you wanted to build something useful to more than just new
users.  it seems to me you want to "ask the community" to tell you what
to do, but are not clear what comprises "the community", so now i'll ask
explicitly: what is your target audience?  what assumptions are you
making about this audience?  these answers will let me know if i am
included, so that i can continue discussion or withdraw as appropriate.

   What do you think of (std ...) => (std2 ...) as a means of letting
   older code run forever?

that depends on what "=>" means precisely.

   I'm a little disappointed that all the response I've gotten has been 
   about the library concept, and no one has yet appeared to be interested 
   in the code I've put out there to date.

personally, i don't care about code as much as interfaces (and their
proper care and feeding).  bad code under a good interface can be fixed.
bad interfaces can also be fixed, but at a higher cost.

   what is 'useful', 'standard', *OR* 'efficient' about what a guile
   user has today?  [...]  There is no comparison [...]

well, some wise dude said the first mistake is making comparison, and
i've gone very far beyond that first mistake by now (so due to the fog
of recent mistakes i can't really remember enough to comment in this
way :-)...  i admire your enthusiasm nonetheless.

thi


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Robert Uhl]

Richard Todd <richardt@vzavenue.net> writes:
> 
> Then, (I was hoping only once every few years), you have to say
> "Enough!" and break with the past.

I'm not certain about that--after all, libc has stayed pretty much the
same for decades.  Heck, we still have gets(), for the truly perverse.

Standard libraries should, as a rule, not change their interfaces.
Given the right thought into their APIs at the outset, it's not needed.
Even where it would be nice, it must be weighed against the need to
maintain compatibility.

I can still pick up little C progs from the clory days and have a _very_
good chance of compiling them; that would not be possible of libc kept
changing.

-- 
Robert Uhl <ruhl@4dv.net>
What parts of `shall make no law,' `shall not be infringed,' and `shall
not be violated' don't you understand?


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Richard Todd]

[-- Attachment #1.1: Type: text/plain, Size: 1639 bytes --]

On Mon, Jan 05, 2004 at 09:03:52AM -0700, Robert Uhl wrote:
> Richard Todd <richardt@vzavenue.net> writes:
> > 
> > Then, (I was hoping only once every few years), you have to say
> > "Enough!" and break with the past.
> 
> I'm not certain about that--after all, libc has stayed pretty much the
> same for decades.  Heck, we still have gets(), for the truly perverse.

The basis of the proposal was that you'd still have whatever schemely
'gets' we were living with, but it would stay in (std xxx).  We would
be encouraging the new development to move to (std2 xxx).  The C
language doesn't have a similar mechanism to make such a clean break.

We're also presuming there's sufficient legacy code to save that it is
worth saving.  In a few years, when std2 may become desireable, we can
look around.  If there is still very little guile use, we may just say
to ourselves, "why bother?" and make the incompatible cleanups.

At the other end of the spectrum, where we have grown to C-like
popularity, then we will certainly care a lot more about compatibility
than fixing a few warts.

I'm hoping it ends up in-between, where we care enough to leave 
(std ...) behind.  Maybe indefinitely.  Maybe for a couple years, so
people can upgrade old code.  Who knows?  I don't want to argue about
a hypothetical library cleanup for a library that doesn't exist yet.
I would like to put some effort into producing that library.

(also, lets look at our peers.  Python (to take one example) has changed
its libraries over time, and I hear very few complaints.  It certainly
hasn't hurt its popularity)

Richard Todd

[-- Attachment #1.2: Type: application/pgp-signature, Size: 186 bytes --]

[-- Attachment #2: Type: text/plain, Size: 139 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Richard Todd]

[-- Attachment #1.1: Type: text/plain, Size: 1692 bytes --]

On Sun, Jan 04, 2004 at 09:34:04PM +0100, Arno Peters wrote:
> On Thu, Jan 01, 2004 at 11:21:28PM -0600, Richard Todd wrote:
> 
> > There are plenty of things to fill in, and help would be
> > appreciated.  If you have a few hours one weekend, pull out your
> > 'numerical recipes' book and make a scheme version of some
> > algorithms.  Every time someone does this and contributes it to the
> > library, the entire guile community gets more efficient.
> 
> Please check out my guile-numerics project on Savannah
> (http://www.nongnu.org/guile-num).  It wraps most of the GNU
> Scientific Library, FFTW and libsndfile through SWIG.  It also
> includes some higher level functions to provide a simpler interface to
> the math routines.  For numerical work, GSL and FFTW have a proven
> track record and it would be foolish to duplicate much of that work.

Ok, that is two people that have taken my 'numerical recipes'
statement very literally.  I was just trying to say, "if you have a
few hours free, you CAN contribute.  Just pick something that's
missing and write it."  I looked to my left, saw the "Numerical
Recipes in C" book on my bookshelf, and used it as an example of
something you can do in a couple hours.

I obviously do not want to blindly duplicate the work of others.


> What is still lacking, though, is a uniform interface for hiding the
> low-level GSL interactions and presenting the user/programmer with a
> consistent scheme interface.  Help with this is always welcome.

I also didn't see any documentation for the interfaces being exported
in the browseable CVS tree off the savannah site, though I may have
missed it.

Richard Todd

[-- Attachment #1.2: Type: application/pgp-signature, Size: 186 bytes --]

[-- Attachment #2: Type: text/plain, Size: 139 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Richard Todd]

[-- Attachment #1.1: Type: text/plain, Size: 1805 bytes --]

On Mon, Jan 05, 2004 at 03:00:28PM +0100, Thien-Thi Nguyen wrote:
>    From: Richard Todd <richardt@vzavenue.net>
>    Date: Sun, 04 Jan 2004 15:51:17 -0600
> 
>    I don't follow why one-size-fits-all would reduce the immediate
>    usefulness of the libarary for some users.  Are you are talking about
>    a user who was already using an interface from another library that I
>    incorporated and changed?  Compared to the benefit to new users who
>    would not be faced with several disjoint interfaces, I think this is
>    insignificant (especially since they can keep on using the old lib if
>    they want).
> 
> i presumed you wanted to build something useful to more than just new
> users.  it seems to me you want to "ask the community" to tell you what
> to do, but are not clear what comprises "the community", so now i'll ask
> explicitly: what is your target audience?  what assumptions are you
> making about this audience?  these answers will let me know if i am
> included, so that i can continue discussion or withdraw as appropriate.

In my view, the current level of guile usage is close to nil.  I want
to make steps to put guile in a place where it can reach a wider
audience.  So, the target audience does not yet exist, and this
project will succeed only to the extent that the current users want
that audience to materialize.

> personally, i don't care about code as much as interfaces (and their
> proper care and feeding).  bad code under a good interface can be fixed.
> bad interfaces can also be fixed, but at a higher cost.

Then perhaps you could critique the *interface* to the code I've put
out??  I agree that work on the interface would be more valuable than
if you found an off-by-1 error.  I'm not asking for that.

Richard Todd

[-- Attachment #1.2: Type: application/pgp-signature, Size: 186 bytes --]

[-- Attachment #2: Type: text/plain, Size: 139 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Dale P. Smith]

Richard Todd <richardt@vzavenue.net> writes:

> In my view, the current level of guile usage is close to nil.  I want
> to make steps to put guile in a place where it can reach a wider
> audience.  So, the target audience does not yet exist, and this
> project will succeed only to the extent that the current users want
> that audience to materialize.

Back when there was some debate about changing the Guile license, istr
that quite a few people spoke up that they used Guile quite a bit, but
the projects were mostly unknown because they were internal or
commercial, and didn't have a large "internet presence".

The Guile Community might be quite a bit larger than what you might
think based solely on mailling list activity or sourceforge projects
(or whatever).

I agree that there should be a nice library of code that people can
depend on.  When I first started learning Python, I was stunned by the
size of the library that came with it.

Fwiw, I've got some half finished zlib code laying around somewhere.
It could compress/decompress memory, but I got stuck trying to
compress/decompress scheme ports.  Anyone intrested in looking at it
and maybe adding it to the new Guile Library?

-Dale

-- 
Dale P. Smith
dsmith at actron dot com


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Robert Uhl]

Richard Todd <richardt@vzavenue.net> writes:
> 
> I'm hoping it ends up in-between, where we care enough to leave (std
> ...) behind.  Maybe indefinitely.  Maybe for a couple years, so people
> can upgrade old code.

The nice thing about permanent interfaces is that one can always compile
against them--which is why C code written by college students in the
early 80s is often still useful.  Or at least can be made to be so,
anyway:-)

> I don't want to argue about a hypothetical library cleanup for a
> library that doesn't exist yet.  I would like to put some effort into
> producing that library.

Naturally; it's very silly to care about supporting something which
doesn't even exist yet.  But it does make sense to consider what a good
usable design would entail ahead of time, so that no
backwards-incompatible changes to the API are needed in the future.
Scheme is nicer than C in this regard, of course, as optional & rest
parameters give one a certain flexibility.

Anyway, what's the URL again?  I really should try my hand at it.
Although my one true project is to figure out number->string well enough
to make it Do the Right Thing for decimals in bases other than 10 (I'm a
big fan of duodecimal).

-- 
Robert Uhl <ruhl@4dv.net>
According to the National Crime Survey administered by the Bureau of
the Census and the National Institute of Justice, it was found that
only 12 percent of those who use a gun to resist assault are injured,
as are 17 percent of those who use a gun to resist robbery.  These
percentages are 27 and 25 percent, respectively, if they passively
comply with the felon's demands.  Three times as many were injured if
they used other means of resistance.
          --G. Kleck, Policy Lessons from Recent Gun Control Research


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Thien-Thi Nguyen]

   From: Richard Todd <richardt@vzavenue.net>
   Date: Mon, 5 Jan 2004 14:32:15 -0600

   Then perhaps you could critique the *interface* to the code I've put
   out??  I agree that work on the interface would be more valuable than
   if you found an off-by-1 error.  I'm not asking for that.

but that's what i'm doing already (if you up-scope and substitute
"project" for "code" and "project management style" for "interface").
this is probably not what you're asking for, so i'll bow out of this
discussion now.

thi


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

number->string radix patch (Was Re: First look at Guile Std Library available)

[Richard Todd]

[-- Attachment #1.1.1: Type: text/plain, Size: 1354 bytes --]

On Mon, Jan 05, 2004 at 06:36:07PM -0700, Robert Uhl wrote:
> Although my one true project is to figure out number->string well enough
> to make it Do the Right Thing for decimals in bases other than 10 (I'm a
> big fan of duodecimal).

I've seen this wish twice from you in the short time I've been
watching guile-user, so I took a crack at it.  You are right, the
algorithm is hard to follow, but I think I worked it out.  I only
tested it by typing in random numbers and eyeballing the results, so
if you don't mind try it out and let me know if you get bad answers.

The patch should apply to CVS guile.
(supports the full 2 -> 36 radix range that integers enjoyed)

(PS I used CAPS for the letters since, as the last two examples show,
you need a way to differentiate the 'e' and 'i' from the digits in the
number.  Should this patch ever make it into guile, maybe all
string->number operations should switch to uppercase.)

Example:
guile> (number->string 35.25 36)
"Z.9"
guile> (number->string 0.25 2)
"0.01"
guile> (number->string 255.0625 16)
"FF.1"
guile> (number->string (/ 1 3) 3)
"1/10"
guile> (number->string 11.33333333333333333 12)
"B.4"
guile> (number->string 11.33333333333333333+23i 12)
"B.4+1B.0i"
guile> (number->string 1.324e44 16)
"5.EFE0A14FAFEe24"


Richard Todd 
richardt at vzavenue dot net

[-- Attachment #1.1.2: radix.patch --]
[-- Type: text/plain, Size: 7797 bytes --]

Index: libguile/numbers.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/numbers.c,v
retrieving revision 1.220
diff -u -r1.220 numbers.c
--- libguile/numbers.c	3 Jan 2004 21:38:38 -0000	1.220
+++ libguile/numbers.c	6 Jan 2004 18:13:50 -0000
@@ -91,7 +91,7 @@
 /* FLOBUFLEN is the maximum number of characters neccessary for the
  * printed or scm_string representation of an inexact number.
  */
-#define FLOBUFLEN (10+2*(sizeof(double)/sizeof(char)*SCM_CHAR_BIT*3+9)/10)
+#define FLOBUFLEN (40+2*(sizeof(double)/sizeof(char)*SCM_CHAR_BIT*3+9)/10)
 
 #if defined (SCO)
 #if ! defined (HAVE_ISNAN)
@@ -1848,19 +1848,71 @@
 #undef FUNC_NAME
 
 /*** NUMBERS -> STRINGS ***/
-int scm_dblprec;
-static const double fx[] =
-{  0.0,  5e-1,  5e-2,  5e-3,   5e-4, 5e-5,
-  5e-6,  5e-7,  5e-8,  5e-9,  5e-10,
- 5e-11, 5e-12, 5e-13, 5e-14,  5e-15,
- 5e-16, 5e-17, 5e-18, 5e-19,  5e-20};
+#define SCM_MAX_DBL_PREC  60
+#define SCM_MAX_DBL_RADIX 36
+
+/* this is an array starting with radix 2, and ending with radix SCM_MAX_DBL_RADIX */
+static int scm_dblprec[SCM_MAX_DBL_RADIX - 1];
+static double fx_per_radix[SCM_MAX_DBL_RADIX - 1][SCM_MAX_DBL_PREC];
+
+static
+void init_dblprec(int *prec, int radix) {
+   /* determine floating point precision by adding successively
+      smaller increments to 1.0 until it is considered == 1.0 */
+   double f = ((double)1.0)/radix;
+   double fsum = 1.0 + f;
+
+   *prec = 0;
+   while (fsum != 1.0)
+   {
+      if (++(*prec) > SCM_MAX_DBL_PREC)
+         fsum = 1.0;
+      else
+      {
+         f /= radix;
+         fsum = f + 1.0;
+      }
+   }
+   (*prec) -= 1;
+}
+
+static
+void init_fx_radix(double *fx_list, int radix)
+{
+  /* initialize a per-radix list of tolerances.  When added
+     to a number < 1.0, we can determine if we should raund
+     up and quit converting a number to a string. */
+   int i;
+   fx_list[0] = 0.0;
+   fx_list[1] = 0.5;
+   for( i = 2 ; i < SCM_MAX_DBL_PREC; ++i ) 
+     fx_list[i] = (fx_list[i-1] / radix);
+}
+
+/* use this array as a way to generate a single digit */
+static const char*number_chars="0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
 
 static size_t
-idbl2str (double f, char *a)
+idbl2str (double f, char *a, int radix)
 {
-  int efmt, dpt, d, i, wp = scm_dblprec;
-  size_t ch = 0;
-  int exp = 0;
+   int efmt, dpt, d, i, wp;
+   double *fx;
+#ifdef DBL_MIN_10_EXP
+   double f_cpy;
+   int exp_cpy;
+#endif /* DBL_MIN_10_EXP */
+   size_t ch = 0;
+   int exp = 0;
+
+   if(radix < 2 || 
+      radix > SCM_MAX_DBL_RADIX)
+   {
+      /* revert to existing behavior */
+      radix = 10;
+   }
+
+   wp = scm_dblprec[radix-2];
+   fx = fx_per_radix[radix-2];
 
   if (f == 0.0)
     {
@@ -1870,7 +1922,6 @@
       if (sgn < 0.0)
 	a[ch++] = '-';
 #endif
-
       goto zero;	/*{a[0]='0'; a[1]='.'; a[2]='0'; return 3;} */
     }
 
@@ -1896,10 +1947,15 @@
 
 #ifdef DBL_MIN_10_EXP  /* Prevent unnormalized values, as from 
 			  make-uniform-vector, from causing infinite loops. */
-  while (f < 1.0)
+  /* just do the checking...if it passes, we do the conversion for our
+     radix again below */
+  f_cpy = f;
+  exp_cpy = exp;
+
+  while (f_cpy < 1.0)
     {
-      f *= 10.0;
-      if (exp-- < DBL_MIN_10_EXP)
+      f_cpy *= 10.0;
+      if (exp_cpy-- < DBL_MIN_10_EXP)
 	{
 	  a[ch++] = '#';
 	  a[ch++] = '.';
@@ -1907,10 +1963,10 @@
 	  return ch;
 	}
     }
-  while (f > 10.0)
+  while (f_cpy > 10.0)
     {
-      f *= 0.10;
-      if (exp++ > DBL_MAX_10_EXP)
+      f_cpy *= 0.10;
+      if (exp_cpy++ > DBL_MAX_10_EXP)
 	{
 	  a[ch++] = '#';
 	  a[ch++] = '.';
@@ -1918,25 +1974,27 @@
 	  return ch;
 	}
     }
-#else
+#endif
+
   while (f < 1.0)
     {
-      f *= 10.0;
+      f *= radix;
       exp--;
     }
-  while (f > 10.0)
+  while (f > radix)
     {
-      f /= 10.0;
+      f /= radix;
       exp++;
     }
-#endif
-  if (f + fx[wp] >= 10.0)
+
+  if (f + fx[wp] >= radix)
     {
       f = 1.0;
       exp++;
     }
  zero:
-#ifdef ENGNOT
+#ifdef ENGNOT 
+  /* adding 9999 makes this equivalent to abs(x) % 3 */
   dpt = (exp + 9999) % 3;
   exp -= dpt++;
   efmt = 1;
@@ -1963,15 +2021,15 @@
     {
       d = f;
       f -= d;
-      a[ch++] = d + '0';
+      a[ch++] = number_chars[d];
       if (f < fx[wp])
 	break;
       if (f + fx[wp] >= 1.0)
 	{
-	  a[ch - 1]++;
+          a[ch - 1] = number_chars[d+1]; 
 	  break;
 	}
-      f *= 10.0;
+      f *= radix;
       if (!(--dpt))
 	a[ch++] = '.';
     }
@@ -2006,26 +2064,25 @@
 	  exp = -exp;
 	  a[ch++] = '-';
 	}
-      for (i = 10; i <= exp; i *= 10);
-      for (i /= 10; i; i /= 10)
+      for (i = radix; i <= exp; i *= radix);
+      for (i /= radix; i; i /= radix)
 	{
-	  a[ch++] = exp / i + '0';
+          a[ch++] = number_chars[exp / i];
 	  exp %= i;
 	}
     }
   return ch;
 }
 
-
 static size_t
-iflo2str (SCM flt, char *str)
+iflo2str (SCM flt, char *str, int radix)
 {
   size_t i;
   if (SCM_REALP (flt))
-    i = idbl2str (SCM_REAL_VALUE (flt), str);
+    i = idbl2str (SCM_REAL_VALUE (flt), str, radix);
   else
     {
-      i = idbl2str (SCM_COMPLEX_REAL (flt), str);
+      i = idbl2str (SCM_COMPLEX_REAL (flt), str, radix);
       if (SCM_COMPLEX_IMAG (flt) != 0.0)
 	{
 	  double imag = SCM_COMPLEX_IMAG (flt);
@@ -2033,7 +2090,7 @@
 	     NaN.  They will provide their own sign. */
 	  if (0 <= imag && !xisinf (imag) && !xisnan (imag))
 	    str[i++] = '+';
-	  i += idbl2str (imag, &str[i]);
+	  i += idbl2str (imag, &str[i], radix);
 	  str[i++] = 'i';
 	}
     }
@@ -2114,7 +2171,7 @@
   else if (SCM_INEXACTP (n))
     {
       char num_buf [FLOBUFLEN];
-      return scm_mem2string (num_buf, iflo2str (n, num_buf));
+       return scm_mem2string (num_buf, iflo2str (n, num_buf, base));
     }
   else
     SCM_WRONG_TYPE_ARG (1, n);
@@ -2129,7 +2186,7 @@
 scm_print_real (SCM sexp, SCM port, scm_print_state *pstate SCM_UNUSED)
 {
   char num_buf[FLOBUFLEN];
-  scm_lfwrite (num_buf, iflo2str (sexp, num_buf), port);
+  scm_lfwrite (num_buf, iflo2str (sexp, num_buf, 10), port);
   return !0;
 }
 
@@ -2138,7 +2195,7 @@
 
 {
   char num_buf[FLOBUFLEN];
-  scm_lfwrite (num_buf, iflo2str (sexp, num_buf), port);
+  scm_lfwrite (num_buf, iflo2str (sexp, num_buf, 10), port);
   return !0;
 }
 
@@ -5538,13 +5595,12 @@
 #undef FUNC_NAME
 
 #endif
-
 void
 scm_init_numbers ()
 {
+  int i;
   abs_most_negative_fixnum = scm_i_long2big (- SCM_MOST_NEGATIVE_FIXNUM);
   scm_permanent_object (abs_most_negative_fixnum);
-
   mpz_init_set_si (z_negative_one, -1);
 
   /* It may be possible to tune the performance of some algorithms by using
@@ -5559,25 +5615,17 @@
   scm_add_feature ("complex");
   scm_add_feature ("inexact");
   scm_flo0 = scm_make_real (0.0);
+
+  /* determine floating point precision */
+  for(i=2; i <= SCM_MAX_DBL_RADIX; ++i)
+    {
+      init_dblprec(&scm_dblprec[i-2],i);
+      init_fx_radix(fx_per_radix[i-2],i);
+    }
 #ifdef DBL_DIG
-  scm_dblprec = (DBL_DIG > 20) ? 20 : DBL_DIG;
-#else
-  {				/* determine floating point precision */
-    double f = 0.1;
-    double fsum = 1.0 + f;
-    while (fsum != 1.0)
-      {
-	if (++scm_dblprec > 20)
-	  fsum = 1.0;
-	else
-	  {
-	    f /= 10.0;
-	    fsum = f + 1.0;
-	  }
-      }
-    scm_dblprec = scm_dblprec - 1;
-  }
-#endif /* DBL_DIG */
+  /* hard code precision for base 10 if the preprocessor tells us to... */
+      scm_dblprec[10-2] = (DBL_DIG > 20) ? 20 : DBL_DIG;
+#endif
 
 #ifdef GUILE_DEBUG
   check_sanity ();

[-- Attachment #1.2: Type: application/pgp-signature, Size: 186 bytes --]

[-- Attachment #2: Type: text/plain, Size: 139 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Richard Todd]

[-- Attachment #1.1: Type: text/plain, Size: 775 bytes --]

On Tue, Jan 06, 2004 at 05:54:38PM +0100, Thien-Thi Nguyen wrote:
>    From: Richard Todd <richardt@vzavenue.net>
>    Date: Mon, 5 Jan 2004 14:32:15 -0600
> 
>    Then perhaps you could critique the *interface* to the code I've put
>    out??  I agree that work on the interface would be more valuable than
>    if you found an off-by-1 error.  I'm not asking for that.
> 
> but that's what i'm doing already (if you up-scope and substitute
> "project" for "code" and "project management style" for "interface").
> this is probably not what you're asking for, so i'll bow out of this
> discussion now.


Well, then let me say that I'm sad to end such a pleasant exchange, 
if you substitute "thrilled" for "sad" and "frustrating" for "pleasant".    

:)


[-- Attachment #1.2: Type: application/pgp-signature, Size: 186 bytes --]

[-- Attachment #2: Type: text/plain, Size: 139 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Richard Todd]

[-- Attachment #1.1: Type: text/plain, Size: 1196 bytes --]

On Sat, Jan 03, 2004 at 08:02:18PM -0600, Richard Todd wrote:
> On Sat, Jan 03, 2004 at 01:19:49PM -0500, Clinton Ebadi wrote:
> > Grep the slib sources for all instances of "provide" and then generate a new 
> > file "std/slib/symbol-that-is-provided.scm" that does a (use-modules (ice-9 
> > slib)), does a (require 'symbol-that-is-provided) and then exports all the 
> > symbols in the current model to the outside world 
> 
<snip>
> 
> > (set-module-uses! %module-public-interface
> >                   (list (nested-ref the-root-module '(app modules std slib 
> > symbol-that-is-provided))))
> 
> I'm not familiar with the set-module-uses! interface, so I'm not sure
> what you are getting at there.  The guile info pages seem to be silent
> on them as well.  Any hints?
> 

I'm going to start investigating this in the guile code taday, but I thought 
I'd ask again in case someone can just tell me: What does that set-module-uses! 
expression quoted above mean?  I assume this is attempting to export the slib 
functions that were just 'require'd, right?  When I tried it verbatim (except
for symbol-that-is-provided, of course!) guile freaked out on me.

Richard

[-- Attachment #1.2: Type: application/pgp-signature, Size: 186 bytes --]

[-- Attachment #2: Type: text/plain, Size: 139 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Paul Jarc]

Richard Todd <richardt@vzavenue.net> wrote:
>>> (set-module-uses! %module-public-interface
>>>                   (list (nested-ref the-root-module '(app modules std slib
>>> symbol-that-is-provided))))
...
> I'm going to start investigating this in the guile code taday, but I
> thought I'd ask again in case someone can just tell me: What does
> that set-module-uses!  expression quoted above mean?  I assume this
> is attempting to export the slib functions that were just
> 'require'd, right?

First, the nested-ref call resolves a name in the module hierarchy.
For example:
guile> (nested-ref the-root-module '(app modules srfi srfi-1))
#<directory (srfi srfi-1) 8085b90>
guile> (nested-ref the-root-module '(app modules srfi srfi-1 map))
#<procedure map (f list1 . rest)>

set-module-users! modifies %module-public-interface (i.e., the public
interface of the current module, where names are searched for by code
that uses this module) so that if something tries to look up a name in
%module-public-interface and it isn't directly there, then the search
will continue in the (list ...)  given.  But you might be better off
with module-use! than set-module-uses!.  See ice-9/boot-9.scm.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Ludovic Courtès]

Hi,

On Sun, Jan 04, 2004 at 10:28:44PM -0600, Richard Todd wrote:
> Searching with google, I found a pretty good sounding proposal from 2001 
> by Martin Grabmueller for reorganizing ice-9 into a hierarchy a lot like 
> what I was working towards.  It even happened to have some of the same 
> names like (math primes) in it!  It was addressing other topics I have 
> yet to bring up, but planned to, such as putting srfi capabilities in 
> named modules and making (srfi srfi-XX) the alternate interface.

For features that are not defined in any SRFI, why not build on other
schemers' experience rather than write whole new interfaces?  Bigloo,
for instance, already has clean interfaces for various things including
bit manipulation, dates, object serialization, fair threads (à la GNU
Pth), parsing, etc.  It would also greatly contribute to portability
among Scheme interpreters and compilers.

My two cents.

Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Richard Todd]

[-- Attachment #1.1: Type: text/plain, Size: 990 bytes --]

On Tue, Jan 06, 2004 at 11:25:25PM +0100, Ludovic Courtes wrote:
> For features that are not defined in any SRFI, why not build on other
> schemers' experience rather than write whole new interfaces?  Bigloo,
> for instance, already has clean interfaces for various things including
> bit manipulation, dates, object serialization, fair threads GNU
> Pth), parsing, etc.  It would also greatly contribute to portability
> among Scheme interpreters and compilers.

This has always been in the plans.  In my original posting I mentioned
attempting ports of pieces of both bigloo and PLT Scheme.  It makes
sense, I think, to leverage the designs of libraries from other
languages as well, if there's no scheme equivalent around, and
'schemify' them.

I was suprised at how hard some of this stuff has been to port,
though...especially when a scheme has different/more macro
capabilities than guile, I have to learn a lot about the other dialect
just to understand what they're doing!

Richard

[-- Attachment #1.2: Type: application/pgp-signature, Size: 186 bytes --]

[-- Attachment #2: Type: text/plain, Size: 139 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: number->string radix patch (Was Re: First look at Guile Std Library available)

[Robert Uhl]

Cool!  It's always annoyed me how broken number->string was.

Of course, now my one idea for how to contribute to Guile is gone.  And
you managed to figure out the conversion code, too.  I've taken a look
at it before, but was never able to figure out how to hook in the Right
Thing.  Says something about my programming skills:-)

Seriously, thanks very much.  I really do hope that this makes it into
the main branch.

-- 
Robert Uhl <ruhl@4dv.net>
OTOH there are some of us in .UK who would rather like NAFTA to
become the North Atlantic Free-Trade Area, and for .UK to sign
up to it instead of us piddling around on the periphery of some
wannabe second-rate-superpower European bureaucracy that, in all
honesty, couldn't come to a consensus on how many primary colours
there are.                                               --Tanuki


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: number->string radix patch (Was Re: First look at Guile Std Library available)

[Richard Todd]

[-- Attachment #1.1: Type: text/plain, Size: 1002 bytes --]

On Tue, Jan 06, 2004 at 09:04:03PM -0700, Robert Uhl wrote:
> Cool!  It's always annoyed me how broken number->string was.
> 
> Of course, now my one idea for how to contribute to Guile is gone. 

There's plenty of things that people can do!  And they definitely
don't have to be in libguile.  (I've been arguing for the last few
days that the most important work right now is actually _outside_, in
the reusable module arena).

> Seriously, thanks very much.  I really do hope that this makes it into
> the main branch.

You are welcome!  I took a couple days off to have my wisdom teeth
pulled, so I've had an odd combination of free time and poinkillers
for the last couple days.  Your mail got my attention last night, and
I couldn't resist giving it a try.

Please, if you haven't, do try this patch and tell me if you see any
problems with the conversions.  Once you agree that it seems to be
working, I'll clean it up and see if the maintainers want the change.

Richard 

[-- Attachment #1.2: Type: application/pgp-signature, Size: 186 bytes --]

[-- Attachment #2: Type: text/plain, Size: 139 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: number->string radix patch (Was Re: First look at Guile Std Library available)

[Robert Uhl]

Richard Todd <richardt@vzavenue.net> writes:
>
> > Of course, now my one idea for how to contribute to Guile is gone. 
> 
> There's plenty of things that people can do!

Perhaps I should better have written, 'the one area I might have had
something to contribute in is now gone.'  I'm not very good at
programming, I'm afraid, despite how much I like it.  Sad but true.

The general radix conversion algorithm was the one thing I though I
might have a chance at.  Of course, I couldn't wrap my head around the
_old_ code, so that's really rather doubtful.

> Please, if you haven't, do try this patch and tell me if you see any
> problems with the conversions.

I'm afraid that I don't actually have an up-to-date guile installation
to test against.  Maybe this'll give me an incentive to do it.

The one thought I had was that it should be possible to do away with the
static array initialisation.  Maybe someday I'll be able to work on
_that_:-)

Once again, thanks for the good work.

-- 
Robert Uhl <ruhl@4dv.net>
The power of Satan is as nothing before the might of the Lord, so don't
go getting any ideas.                             --I Abyssinians 20:20


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

I get unknown immediate error in guile 1.7

[Roland Orre]

I've tried to get guile 1.7 work but I seem to have a problem with
loadable modules. As soon as I call a function in them I get an
"unknown-immediate" error. This possibly sounds like some include
problem but as far as I know tag principles has not changed between
1.6 and 1.7.

The most basic is readline of course as I haven't recompiled other
modules yet. About readline, the file "libtool" was not created by
autogen.sh in guile-readline so I linked to ../libtool instead.

If I load an old (1.6) libguilereadline I get segmentation fault, which
indicates some significant change. When I load the 1.7 libguilereadline
I get the errors below after (activate-readline), any ideas?
I've used gcc 3.3.2.

	Best regards
	Roland

guile-user> ERROR: In procedure apply:nconc2last:
ERROR: Wrong type argument in position 1: #<unknown-immediate 0x2974>
ABORT: (wrong-type-arg)
ERROR: In procedure %readline:
ERROR: readline is not reentrant
ABORT: (misc-error)
ERROR: In procedure %readline:
ERROR: readline is not reentrant
ABORT: (misc-error)
ERROR: In procedure %readline:
ERROR: readline is not reentrant
...



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: I get unknown immediate error in guile 1.7

[Roland Orre]

I solved the problem. It seems as linking (at least for me) is not done
in the right way for modules, neither for 1.6 or 1.7. Explanation below.

On Thu, 2004-01-08 at 08:11, Roland Orre wrote:
> I've tried to get guile 1.7 work but I seem to have a problem with
> loadable modules. As soon as I call a function in them I get an
> "unknown-immediate" error. This possibly sounds like some include
> problem but as far as I know tag principles has not changed between
> 1.6 and 1.7.
> 
> The most basic is readline of course as I haven't recompiled other
> modules yet. About readline, the file "libtool" was not created by
> autogen.sh in guile-readline so I linked to ../libtool instead.
> 
> If I load an old (1.6) libguilereadline I get segmentation fault, which
> indicates some significant change. When I load the 1.7 libguilereadline
> I get the errors below after (activate-readline), any ideas?
> I've used gcc 3.3.2.

The problem showed to be that guile loaded wrong libraries, which was
caused by the the correct library files not having been created. Guile
had been reading wrong libguilereadline.la all the time. I noticed this
when I deinstalled the (debian distributed) guile-1.6. Then the
libguilereadline.la library was not found for my locally compiled
guile-1.6 either, despite that I had included both
/usr/local/guile/guile-1.6.0/lib
/usr/local/guile/guile-1.6.0/guile-readline in the LTDL_LIBRARY_PATH.

I then relinked the readline.o file under guile-readline with
the settings I use for my own modules, then it worked. The make
script is at the end. The correct guile-1.6 libguilereadline
file was read and the same procedure worked for guile-1.7 as well.
The problem probably has to do with the guile-readline autogen.sh
but how this script works is above my head.

The fundamental problem seems to be that the installation linking
is not done in the right way. None of the .la files under the
lib directory (${exec_prefix}/lib) contains any library references.
Observe that I used the name "libgreadline" in the script.

Here are the error messages given.
After a normal make install, where LTDL library is set as:
export LTDL_LIBRARY_PATH=/usr/local/guile/guile-1.7/lib

I get the following (empty) error message:
  /usr/local/guile/guile-1.7/guile/1.7/ice-9/readline.scm:38:5:
  In procedure dynamic-link in expression 
  (load-extension "libguilereadline" "scm_init_readline"):
  /usr/local/guile/guile-1.7/guile/1.7/ice-9/readline.scm:38:5:
  file: "libguilereadline", message: ""

If I then also include /usr/local/guile/guile-1.7/guile-readline
first in the LTDL path, then I get the following error message:
 /usr/local/guile/guile-1.7/guile/1.7/ice-9/readline.scm:38:5:
 In procedure dynamic-link in expression
 (load-extension "libguilereadline" "scm_init_readline"):
 /usr/local/guile/guile-1.7/guile/1.7/ice-9/readline.scm:38:5:
 file: "libguilereadline", message: "|o\"@àÌ\x11\x08readline.a:
 cannot open shared object file: No such file or directory"

If I then run the make script below under guile-readline then
it works. This newly created .la files contains library references
to the .so files created under .libs. 
I also included my configuration parameters below.

Have I done anything obviously wrong in the configuration?

=============================================================
# This make file generates a working libguilereadline

top_builddir = /usr/local/guile/guile-1.6.0
libdir=/usr/local/guile/guile-latest/guile-readline/..//lib
LIBS=../libguile/libguile.la -lreadline -lncurses
EXTRA=-version-info 10:0:0 -export-dynamic -no-undefined
CC=gcc

all: libgreadline

libgreadline: readline.o
	echo sh ${top_builddir}/libtool --mode=link $(CC) $^ $(EXTRA) $(LIBS)
-rpath $(libdir) -o libgreadline.la
	sh ${top_builddir}/libtool --mode=link $(CC) $^ $(EXTRA) $(LIBS) 
-rpath $(libdir) -o libgreadline.la

=============================================================

#These are my configuration parameters:

GUILEROOT=`pwd`
echo ${GUILEROOT}

./configure --with-threads --with-readline \
 --prefix=${GUILEROOT}                  \
 --build=i686                           \
 --exec-prefix=${GUILEROOT}             \
 --bindir=${GUILEROOT}/bin              \
 --sbindir=${GUILEROOT}/bin             \
 --sysconfdir=${GUILEROOT}/etc          \
 --datadir=${GUILEROOT}                 \
 --sharedstatedir=${GUILEROOT}/com      \
 --localstatedir=${GUILEROOT}/var       \
 --includedir=${GUILEROOT}/include      \
 --oldincludedir=/usr/include           \
 --mandir=/usr/local/man                \
 --infodir=/usr/local/info              \
 --enable-maintainer-mode               \
 --enable-ltdl-install




_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: I get unknown immediate error in guile 1.7

[Roland Orre]

I found the problem. It seems as linking (at least for me) is not done
in the right way for modules, neither for 1.6 or 1.7. Explanation below.

On Thu, 2004-01-08 at 08:11, Roland Orre wrote:
> I've tried to get guile 1.7 work but I seem to have a problem with
> loadable modules. As soon as I call a function in them I get an
> "unknown-immediate" error. This possibly sounds like some include
> problem but as far as I know tag principles has not changed between
> 1.6 and 1.7.
> 
> The most basic is readline of course as I haven't recompiled other
> modules yet. About readline, the file "libtool" was not created by
> autogen.sh in guile-readline so I linked to ../libtool instead.
> 
> If I load an old (1.6) libguilereadline I get segmentation fault, which
> indicates some significant change. When I load the 1.7 libguilereadline
> I get the errors below after (activate-readline), any ideas?
> I've used gcc 3.3.2.

The problem showed to be that guile loaded wrong libraries, which was
caused by the the correct library files not having been created. Guile
had been reading wrong libguilereadline.la all the time. I noticed this
when I deinstalled the (debian distributed) guile-1.6. Then the
libguilereadline.la library was not found for my locally compiled
guile-1.6 either, despite that I had included both
/usr/local/guile/guile-1.6.0/lib
/usr/local/guile/guile-1.6.0/guile-readline in the LTDL_LIBRARY_PATH.

I then relinked the readline.o file under guile-readline with
the settings I use for my own modules, then it worked. The make
script is at the end. The correct guile-1.6 libguilereadline
file was read and the same procedure worked for guile-1.7 as well.
The problem probably has to do with the guile-readline autogen.sh
but how this script works is above my head.

The fundamental problem seems to be that the installation linking
is not done in the right way. None of the .la files under the
lib directory (${exec_prefix}/lib) contains any library references.
Observe that I used the name "libgreadline" in the script.

Here are the error messages given.
After a normal make install, where LTDL library is set as:
export LTDL_LIBRARY_PATH=/usr/local/guile/guile-1.7/lib

I get the following (empty) error message:
  /usr/local/guile/guile-1.7/guile/1.7/ice-9/readline.scm:38:5:
  In procedure dynamic-link in expression 
  (load-extension "libguilereadline" "scm_init_readline"):
  /usr/local/guile/guile-1.7/guile/1.7/ice-9/readline.scm:38:5:
  file: "libguilereadline", message: ""

If I then also include /usr/local/guile/guile-1.7/guile-readline
first in the LTDL path, then I get the following error message:
 /usr/local/guile/guile-1.7/guile/1.7/ice-9/readline.scm:38:5:
 In procedure dynamic-link in expression
 (load-extension "libguilereadline" "scm_init_readline"):
 /usr/local/guile/guile-1.7/guile/1.7/ice-9/readline.scm:38:5:
 file: "libguilereadline", message: "|o\"@àÌ\x11\x08readline.a:
 cannot open shared object file: No such file or directory"

If I then run the make script below under guile-readline then
it works. This newly created .la files contains library references
to the .so files created under .libs. 
I also included my configuration parameters below.

Have I done anything obviously wrong in the configuration?

=============================================================
# This make file generates a working libguilereadline

top_builddir = /usr/local/guile/guile-1.6.0
libdir=/usr/local/guile/guile-latest/guile-readline/..//lib
LIBS=../libguile/libguile.la -lreadline -lncurses
EXTRA=-version-info 10:0:0 -export-dynamic -no-undefined
CC=gcc

all: libgreadline

libgreadline: readline.o
	sh ${top_builddir}/libtool --mode=link $(CC) $^ $(EXTRA) $(LIBS) \
-rpath $(libdir) -o libgreadline.la

=============================================================

#These are my configuration parameters:

GUILEROOT=`pwd`
echo ${GUILEROOT}

./configure --with-threads --with-readline \
 --prefix=${GUILEROOT}                  \
 --build=i686                           \
 --exec-prefix=${GUILEROOT}             \
 --bindir=${GUILEROOT}/bin              \
 --sbindir=${GUILEROOT}/bin             \
 --sysconfdir=${GUILEROOT}/etc          \
 --datadir=${GUILEROOT}                 \
 --sharedstatedir=${GUILEROOT}/com      \
 --localstatedir=${GUILEROOT}/var       \
 --includedir=${GUILEROOT}/include      \
 --oldincludedir=/usr/include           \
 --mandir=/usr/local/man                \
 --infodir=/usr/local/info              \
 --enable-maintainer-mode               \
 --enable-ltdl-install




_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: I get unknown immediate error in guile 1.7

[Roland Orre]

Sorry all, the problem was my fault. I had given to many (and obviously
some erroneous) parameters to configure. When I gave only a few
necessary parameters it worked very well, all module .so files were
created.
	Best regards
	Roland


On Fri, 2004-01-09 at 00:16, Roland Orre wrote:
> I found the problem. It seems as linking (at least for me) is not done
> in the right way for modules, neither for 1.6 or 1.7. Explanation below.
<snip>
> =============================================================
> 
> #These are my configuration parameters:
> 
> GUILEROOT=`pwd`
> echo ${GUILEROOT}
> 
> ./configure --with-threads --with-readline \
>  --prefix=${GUILEROOT}                  \
>  --build=i686                           \
>  --exec-prefix=${GUILEROOT}             \
>  --bindir=${GUILEROOT}/bin              \
>  --sbindir=${GUILEROOT}/bin             \
>  --sysconfdir=${GUILEROOT}/etc          \
>  --datadir=${GUILEROOT}                 \
>  --sharedstatedir=${GUILEROOT}/com      \
>  --localstatedir=${GUILEROOT}/var       \
>  --includedir=${GUILEROOT}/include      \
>  --oldincludedir=/usr/include           \
>  --mandir=/usr/local/man                \
>  --infodir=/usr/local/info              \
>  --enable-maintainer-mode               \
>  --enable-ltdl-install




_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: I get unknown immediate error in guile 1.7

[Kevin Ryde]

Roland Orre <roland.orre@neurologic.se> writes:
>
> The problem showed to be that guile loaded wrong libraries, which was
> caused by the the correct library files not having been created. Guile
> had been reading wrong libguilereadline.la all the time.

I think I might have struck that too, but with debian guile 1.4
getting in the way of cvs guile.

I had an idea I thought the guile library search path ought to include
its configured $prefix/lib ahead of /usr/lib, but I forget exactly.

Library versioning is probably supposed to protect against some of
this sort of thing.  Dunno what the status on that currently is
though.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: First look at Guile Std Library available

[Andy Wingo]

Hi Richard,

Sorry I didn't respond when the thread was fresh, I was on holiday...

On Sun, 04 Jan 2004, Richard Todd wrote:

> Paul Jarc wrote:
> >As long as the code exists, I don't think there's much benefit in
> >aggregating it.  It just has to be easy for users to find.
> 
> Ok, I am definitely starting to feel like a stranger in a strange land, 
> here.

It's weird, no? I too am a newcomer to the scheme world (I'm a GNOME
hacker, really) and I'm baffled by the response. It's just so damn easy
to make a perl module, pop it up on CPAN, and have it available to
anyone with the base CPAN installation. It is one of the key factors in
perl's ascendence as a scripting language. I agree that it's desirable
for Guile, especially once you start to write apps in Guile itself. And
what a waste to write something and have it languish on a forgotten web
page.

So I share your spirit. I do have a concern about versioning, however.
Versioning the whole thing will be unwieldy as the package expands in
size. Then we have the problem of guile modules that link to C libraries
that may or may not be available, or whose available versions correspond
to only one module interface. It becomes clear that a provide/require
interface is needed as well, although it might not be implemented by
SLIB.

 [ SLIB's virtue and weakness is that it is a cathedral product. Virtue,
   because you know it's well designed and stable, but weakness because
   you or I don't feel attracted to contributing, especially
   contributing modules whose code is useful but maybe weaker than
   Jaffer's. ]

OK, punt the question about C library-backed guile modules for another
day. But for changing interfaces in scheme modules, what is needed is a
versioned `use-modules', maybe like (use-modules (math primes 1)).

Actually now that I think about it you can play nifty tricks with this.
Maybe you have a 1.2 and a 1.1 series of your primes module. So you
have

(define-module (math primes 1 1))
... code ...

(define-module (math primes 1 2))
... interface is different ...

Then you can have

(define-module (math primes 1))
;; re-export the interface of the latest version in the 1.x series
(module-use! (current-module) (resolve-interface '(math primes 1 2)))

(define-module (math primes))
;; The 1.x series is the latest one
(module-use! (current-module) (resolve-interface '(math primes 1)))

So, use (math primes) while you're developing, but then before you
release change the use-modules statement on your code to reflect the
version you are using. It's kindof like linking, I guess. Still a PITA
though.

My concern is that we don't fall in the pit of having to change module
names (think (use (gfxlib sdl1.3debian+4)) or something). Maybe my
concern is overblown, like this isn't such a big deal in interpreted
languages or something.

So thoughts about versioning in general, and this method in particular?

Regards,

wingo.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: number->string radix patch

[Marius Vollmer]

Richard Todd <richardt@vzavenue.net> writes:

> On Mon, Jan 05, 2004 at 06:36:07PM -0700, Robert Uhl wrote:
>> Although my one true project is to figure out number->string well enough
>> to make it Do the Right Thing for decimals in bases other than 10 (I'm a
>> big fan of duodecimal).
>
> I've seen this wish twice from you in the short time I've been
> watching guile-user, so I took a crack at it.

Ok, I have finally installed your patch.  Thanks again!  (I wrote a
basic ChangeLog entry, but please do that yourself for the next
patch.)

I used your examples as test cases, but cannot reproduce some:

> guile> (number->string 0.25 2)
> "0.01"
> guile> (number->string 11.33333333333333333 12)
> "B.4"
> guile> (number->string 1.324e44 16)
> "5.EFE0A14FAFEe24"

I get

  guile> (number->string 0.25 2)
  "0.010"
  guile> (number->string 11.33333333333333333 12)
  "B.400000000000009"
  guile> (number->string 1.324e44 16)
  "5.EFE0A14FAFDF8e24"

The first looks certainly wrong, but I'm not sure about the other two.
Richard, could you try to investigate this?

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: number->string radix patch

[Richard Todd]

On May 10, 2004, at 3:34 PM, Marius Vollmer wrote:

[...test case results snipped...]
> The first looks certainly wrong, but I'm not sure about the other two.
> Richard, could you try to investigate this?

It could be architecture differences?  I run on Macintoshes...  Or 
maybe something in the last few months has interfered... I will look 
into this tomorrow night.  Thanks for installing this!

Richard



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: number->string radix patch

[Keith Wright]

> From: Marius Vollmer <mvo@zagadka.de>
> Cc: Robert Uhl <ruhl@4dv.net>, guile-user@gnu.org
> 
> Richard Todd <richardt@vzavenue.net> writes:
> 
> Ok, I have finally installed your patch.  Thanks again!  (I wrote a
> basic ChangeLog entry, but please do that yourself for the next
> patch.)
> 
> I used your examples as test cases, but cannot reproduce some:
       <two deleted> 
>   guile> (number->string 1.324e44 16)
>   "5.EFE0A14FAFDF8e24"
> 
> The first looks certainly wrong, but I'm not sure about the other two.
> Richard, could you try to investigate this?

The third one worries me too.  Does this use the case of the
#\E (or #\e) to differentiate a hex digit from an exponent marker?
Scheme (or SCHEME) is supposed to be case insensitive, and I would
not want to break that useful and expected propery just to get this
rather special purpose "extension".

Maybe, since the Scheme report does not specify an exponent mark for
hex numbers, some other character should be chosen (after all, it no
longer means ten-to-the-power, but rather sixteen-to-the-power).  Or
else hex constants could be required to have an exponent marker of
either S (short) or L (long).  Unfortunately F and D (single and
double) have the same problem as E

Does this patch also change STRING->NUMBER to accept the extended
syntax?  What about in program text?

       -- Keith



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: number->string radix patch

[Richard Todd]

I built guile from CVS on my Mac G5, and I get the same results I did 
originally:

/tmp/bldguile richardt$ guile
guile> (number->string 0.25 2)
"0.01"
guile>  (number->string 11.33333333333333333 12)
"B.4"
guile> (number->string 1.324e44 16)
"5.EFE0A14FAFEe24"
guile>

I had done the original patch on a G4 machine.  I'm thinking it's a 
precision difference between macs and intel machines.  Those second two 
answers are only different in the least significant numbers, which 
looks like different amounts of rounding error to me.  Someone with an 
intel box may be able to do some tuning of the tolerance parameters in 
the algorithm.  I'd be happy to help in any way I can, but it may be an 
unavoidable difference.


On May 10, 2004, at 3:34 PM, Marius Vollmer wrote:

> Richard Todd <richardt@vzavenue.net> writes:
>
>> On Mon, Jan 05, 2004 at 06:36:07PM -0700, Robert Uhl wrote:
>>> Although my one true project is to figure out number->string well 
>>> enough
>>> to make it Do the Right Thing for decimals in bases other than 10 
>>> (I'm a
>>> big fan of duodecimal).
>>
>> I've seen this wish twice from you in the short time I've been
>> watching guile-user, so I took a crack at it.
>
> Ok, I have finally installed your patch.  Thanks again!  (I wrote a
> basic ChangeLog entry, but please do that yourself for the next
> patch.)
>
> I used your examples as test cases, but cannot reproduce some:
>
>> guile> (number->string 0.25 2)
>> "0.01"
>> guile> (number->string 11.33333333333333333 12)
>> "B.4"
>> guile> (number->string 1.324e44 16)
>> "5.EFE0A14FAFEe24"
>
> I get
>
>   guile> (number->string 0.25 2)
>   "0.010"
>   guile> (number->string 11.33333333333333333 12)
>   "B.400000000000009"
>   guile> (number->string 1.324e44 16)
>   "5.EFE0A14FAFDF8e24"
>
> The first looks certainly wrong, but I'm not sure about the other two.
> Richard, could you try to investigate this?
>
> -- 
> GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405
>



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: number->string radix patch

[Kevin Ryde]

Richard Todd <richardt@vzavenue.net> writes:
>
> Those second
> two answers are only different in the least significant numbers, which
> looks like different amounts of rounding error to me.

Neither input nor output code keeps a tight rein on accuracy as far as
I can tell, it loses on decimal I think.

But what's not good is that there's some rounding in hex output, for
instance

	(number->string #i#x1FFFFFFFFFFFF 16)
	=> "2.0eC"

where I expected "1.FFFFFFFFFFFFeC" or whatever.  Non-power-of-2 bases
are going to round, but I'd have thought an important point for power
of 2 bases would be that they don't round.

I haven't tried to look where it goes wrong, but this is on my i386
debian, built with CFLAGS=-g (ie. no optimizations).  I added some
printfs into idbl2str and saw the value from the input is correct,
ie. contains lots of 1 bits, the rounding to 2.0 is apparently in the
output.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: number->string radix patch

[Kevin Ryde]

Keith Wright <kwright@free-comp-shop.com> writes:
>
> Does this use the case of the
> #\E (or #\e) to differentiate a hex digit from an exponent marker?

That worries me a bit too.  It's also vital to have a proper
description in the manual, since this is an extension over r5rs.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: number->string radix patch

[Marius Vollmer]

Keith Wright <kwright@free-comp-shop.com> writes:

> [...] Does this use the case of the #\E (or #\e) to differentiate a
> hex digit from an exponent marker?  Scheme (or SCHEME) is supposed
> to be case insensitive, and I would not want to break that useful
> and expected propery just to get this rather special purpose
> "extension".

This is not an extension to Scheme syntax, only number->string has
been extended.  The reader can not read non-decimal floating point
numbers, and probably shouldn't try to.  Also, 'write' and 'display'
will not produce new non-standard number syntax.

So, this is maybe not such a problem as you are fearing.  It is a
useful, compatible extension of number->string.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: number->string radix patch

[Marius Vollmer]

Kevin Ryde <user42@zip.com.au> writes:

> Keith Wright <kwright@free-comp-shop.com> writes:
>>
>> Does this use the case of the
>> #\E (or #\e) to differentiate a hex digit from an exponent marker?
>
> It's also vital to have a proper
> description in the manual, since this is an extension over r5rs.

Yes, definitely.  (I'll see to this.)

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: number->string radix patch

[Marius Vollmer]

Richard Todd <richardt@vzavenue.net> writes:

> I had done the original patch on a G4 machine.  I'm thinking it's a
> precision difference between macs and intel machines.

For me, the difference is between compiling with optimization and
without.

Compiled with gcc 3.3.3 (Debian 20040422) on i386, CFLAGS=-g:

  guile> (number->string 0.25 2)
  "0.01"

Compiled with CFLAGS=-O2:

  guile> (number->string 0.25 2)
  "0.010"

So, what can we do about this?

Reliable floating point reading and writing can be tricky, and we will
eventually need to improve our routines anyway, see

  http://lists.gnu.org/archive/html/guile-devel/2002-05/msg00021.html

For now, I'm inclined to mark the tests as unresolved.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: number->string radix patch

[Kevin Ryde]

Marius Vollmer <mvo@zagadka.de> writes:
>
> For me, the difference is between compiling with optimization and
> without.

On i386 with optimization you get a few extra bits of precision
because gcc holds values in the 8087 registers.  Without optimization
it writes back to memory after every op, forcing rounding at each
stage.

(Unoptimized is still not always the same as an actual 53-bit chip
like ppc, since there's two roundings, first to 64 bits then to 53.)


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user