Extended -e syntax

Extended -e syntax

[Clinton Ebadi]

[-- Attachment #1: Type: Text/Plain, Size: 1344 bytes --]

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

I've been trying to get guile-pg to compile and it hasn't been working out too 
well...ttn uses his new build system stuff with guile-pg and they only work 
with Guile 1.4.x unless Guile has support for his extended -e syntax.

As such, I copied ttn's code from Guile 1.4, changed one call (gh_symbol2scm 
into scm_str2symbol), and patched it into Guile CVS HEAD. Is ttn still 
assigning his copyright to the FSF? The copyright notices on all the files 
would make it appear so (I have sent this to guile-user as well as -devel so 
ttn will see it since he unsubscribed from guile-devel after he forked 
Guile).

Is there any chance of mainline Guile using the extended -e stuff or accepting 
patches to use ttn's nice build system and extended guile-config stuff? I am 
willing to chunk out anything from Guile 1.4.x that would be useful to the 
official Guile branch if there aren't any copyright issues / the patches will 
be accepted.
- -- 
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)

iD8DBQFAQq7hdgGh8PQDV0sRAgmaAKDOGauT/JB6deQImYK8f26YgzKW2wCfZtCw
0v5EcxFcvfUvhJS6xjyUx6w=
=uCBU
-----END PGP SIGNATURE-----

[-- Attachment #2: extended_e.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 1139 bytes --]

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

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

Re: Extended -e syntax

[Andreas Rottmann]

Clinton Ebadi <clinton@unknownlamer.org> writes:

> I am willing to chunk out anything from Guile 1.4.x that would be
> useful to the official Guile branch if there aren't any copyright
> issues / the patches will be accepted.
>
It would be really cool if that could happen. This fork-thing is quite
a f**ckup IMHO.

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



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

Re: Extended -e syntax

[Thien-Thi Nguyen]

   From: Andreas Rottmann <a.rottmann@gmx.at>
   Date: Mon, 01 Mar 2004 06:04:38 +0100

   This fork-thing is quite a f**ckup IMHO.

it's probably better to call it a forced-inconvenience than a fork.
in any case, it has demonstrated the delicate nature of using cvs for
revision control.  perhaps you could ask Miles Bader how he set up the
arch-cvs gateway for emacs, and do the same for guile.  i would like
to learn how to use such a gateway once it is available and there are
docs for the newbie (me).  btw, i'm glad to host such docs or links to
them in <http://www.glug.org/docbits/>.

previously i had thought it better to wait until there is available an
implementation of the arch "wire protocol" (whatever that may be) in
guile scheme, but perhaps that is too hard line...

thi


[cc trimmed]


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

Arch and Guile

[Andreas Rottmann]

Thien-Thi Nguyen <ttn@surf.glug.org> writes:

>    This fork-thing is quite a f**ckup IMHO.
>
> it's probably better to call it a forced-inconvenience than a fork.
> in any case, it has demonstrated the delicate nature of using cvs for
> revision control.
>
Using Arch would also make stuff easier for the "mainstream" Guile
developers to maintain their stable and development branches: They
could have an guile--fixes--1.6 branch, wich they'd simple star-merge
into HEAD.

> perhaps you could ask Miles Bader how he set up the arch-cvs gateway
> for emacs, and do the same for guile.
>
I already have a bit of experience with tla-cvs-sync from
tla-tools. For running a gateway in both directions, one needs Guile
CVS write access. I could set up a gateway that tracks CVS and hosts
additional stuff from various sources, however. A potential problem
with that is that merges into CVS (if to happen) should happen via a
tool such as tla-cvs-sync and not via ordinary patches.

> i would like to learn how to use such a gateway once it is available
> and there are docs for the newbie (me).  btw, i'm glad to host such
> docs or links to them in <http://www.glug.org/docbits/>.
>
Such a gateway is very simple to use: You have someone who is the
"Gatekeeper" between the Arch and CVS world. This person then merges
stuff form other people's branches into the dedicated "CVS" branch,
which is synced with CVS in both directions. 

Due to the distributed nature of Arch, such a Gatekeeper could have
"lieutenants", which are responsible accumulating the "good" stuff
from several people into their "integration" branches. This means
Gatekeeper doesn't (need to) become a bottleneck, even if there are a
a lot of people contributing on the Arch side.

I think that I'm not suitable as a Gatekeeper, since I'm not a Guile
(core) hacker and haven't assigned copyright (yet). It would be
really, really terrific if someone of the core hackers would take this
responsibility. I volunteer helping with

* Setting up the Gateway. If I get positive feedback, I might set up a
  CVS-tracking-but-not-commit gateway as described above. If the stuff
  in the Arch world is considered interesting enough for the Guile
  core hackers, one of them might want to take over
  Gatekeepership. Actually, this sounds like a good intermediate
  plan. Thoughts?

* As a (first? ;-) lieutenant, leaving the Gatekeeper only with a 
  single branch to deal with.

> previously i had thought it better to wait until there is available
> an implementation of the arch "wire protocol" (whatever that may be)
> in guile scheme, but perhaps that is too hard line...
>
I'm not totally clear what you mean here, and how that relates to an
Arch<->CVS gateway. Anyway, you might be interested in my ITLA
thingy[0].

Cheers, 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




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

ITLA (was Re: Arch and Guile)

[Tom Lord]

    > From: Andreas Rottmann <a.rottmann@gmx.at>

    > Using Arch would also make stuff easier for the "mainstream" Guile
    > developers to maintain their stable and development branches: They
    > could have an guile--fixes--1.6 branch, wich they'd simple star-merge
    > into HEAD.

Should work in this area start to take place, please let me know if I
can help in any way.


    > I'm not totally clear what you mean here, and how that relates to an
    > Arch<->CVS gateway. Anyway, you might be interested in my ITLA
    > thingy[0].

You appear to have left out the footnote.

I'd like to point out some info about the ITLA idea.  ITLA is not, at
it's core, tla specific -- it's a generic engine for making
interactive Scheme programs, both CLI and GUI.

See: 

     http://mail.gnu.org/archive/html/gnu-arch-users/2003-11/msg00291.html

Particularly the section "How it Would Work" which begins:


  * How it Would Work

    ITLA would be written as an "extensible shell".

    Most likely, especially since arch is a GNU project, in Guile.
    SCSH, MzScheme, and Systas Scheme are other possibilities.

    It's architecture would somewhat resemble Emacs' in the following
    way: [....]


The ITLA framework is one of the target applications for Pika Scheme
but it will be a long time before Pika is ready to start implementing
it.   There's no reason not to start on the framework earlier, using
Guile (and many good reasons to do so).


-t




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

Re: ITLA

[Andreas Rottmann]

Tom Lord <lord@emf.net> writes:

>     > I'm not totally clear what you mean here, and how that relates to an
>     > Arch<->CVS gateway. Anyway, you might be interested in my ITLA
>     > thingy[0].
>
> You appear to have left out the footnote.
>
Indeed: [0] http://stud3.tuwien.ac.at/~e9926584/ITLA

> I'd like to point out some info about the ITLA idea.  ITLA is not, at
> it's core, tla specific -- it's a generic engine for making
> interactive Scheme programs, both CLI and GUI.
>
> See: 
>
>      http://mail.gnu.org/archive/html/gnu-arch-users/2003-11/msg00291.html
>
I obviously missed the initial discussion. Big thanks for pointing
this out.

> The ITLA framework is one of the target applications for Pika Scheme
> but it will be a long time before Pika is ready to start implementing
> it.   There's no reason not to start on the framework earlier, using
> Guile (and many good reasons to do so).
>
I'll quote parts of your initial ITLA mail here, adding my view how
things would/could look like when *I*'d do this in Guile, building
upon/integrating my ITLA stuff.

,----
|   Each interactive command will be defined by an ordinary Scheme
|   procedure supplemented with a _declaration_.  The declaration lists:
| 
|   ~ the name of the command
|   ~ a documentation string for the command
|   ~ a list of options and parameters to the command, each
|     specified by:
| 
|         + a parameter name
| 
|         + a "type declaration" (e.g., "string", or "new-archive-name",
|           or "existing-archive-name", or "archive-name".)
| 
|         + a description of how it is parsed from options and
|           arguments provided on command lines
| 
|         + a default value
| 
|         + an optional prompt string
| 
|         + an optional help string for the parameter
| 
|   ~ a "type declaration" for the output of the command
| 
I'd make the declaration result in registering a GOOPS class instance
somewhere. Type declarations would map to classes directly, along with
generics that deal with I/O, completion, etc.

|   The "main loop" of itla reads partially specified command lines,
|   looks up the interactive command, parses any options and arguments
|   already provided, and enters a generic "argument editor" that
|   prompts for the remaining arguments
| 
|   Once the parameter editor is done collecting parameters, the 
|   procedure that defines the command is called.   Typically, it
|   works by running tla as a subprocess.
|
This is the part on which "my" ITLA focuses currently: Offering a
GOOPS-based scripting interface to tla.

|   It can also recursively
|   invoke the command loop to run particular commands (e.g., import 
|   might recursively call "prepare-tree" and/or "make-archive").
| 
Right now, I use the Guile repl (as can be seen from the screen-shot
at [0]), which is of course not the most user-friendly thing to do
:-).

|   The rationale for this approach is four-fold:
| 
[sip]

Full ACK here.

| * Usefulness for GUIs
| 
|   There is nothing that says that the parameter editor and output 
|   handler have to be TTY programs -- nothing that says they have
|   to do their work by printing prompts and reading keyboard input.
| 
|   For example, a GUI might include an alternative form of the 
|   parameter editor that knows how to translate _any_ command 
|   declaration into a "form".
| 
|   That approach can make writing a complete GUI a much smaller task
|   and effort can focus on generic parts that help the entire 
|   interface (such an an "archive name selector").
| 
|   It also means that a GUI can automatically just "work" as new
|   commands are added to itla.   For example, after I load a set
|   of extensions defining commands specific to the tla project,
|   these can automatically appear on a menu or toolbar and immediately
|   have a GUI interface.
`----

I'd use Guile-GObject[1] here. 

[1] http://www.gnu.org/software/guile-gtk/docs/

Cheers, 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

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: ITLA

[Tom Lord]

    > From: Andreas Rottmann <a.rottmann@gmx.at>

    > I'll quote parts of your initial ITLA mail here, adding my view how
    > things would/could look like when *I*'d do this in Guile, building
    > upon/integrating my ITLA stuff.

    > ,----
    > |   Each interactive command will be defined by an ordinary Scheme
    > |   procedure supplemented with a _declaration_.  The declaration lists:
    > |   [....]

    > I'd make the declaration result in registering a GOOPS class instance
    > somewhere. Type declarations would map to classes directly, along with
    > generics that deal with I/O, completion, etc.

"To GOOPS or not to GOOPS" is for me, at this stage, an implementation
detail -- it might or might not be the right thing.

The critical thing, in my view, is to have a data-driven system
(programmers write declarations) such that you can implement various
flavors of Emacs' function "call-interactively" -- for CLIs, for smart
terminals, for GUIs, etc.

Getting the abstraction level of the declarations right is critical --
both for abstraction over interaction environments (e.g., CLI vs. GUI)
and for accessability (e.g., make it possible to write  a single
implementation of "read-file-name" for blind users and have that used
for _all_ commands that read file names).

Ok, I exaggerate slightly -- I'm not quite agnostic about using GOOPS
in this particular area.  Really, I'm mostly against it except as it
helps "internally" in various modules.  And the reason has to do with
(surprise!) modularity.  Here's why:

Declarations are going to be _written_ as simple list structures
following some (extensible) syntax -- just as they are in emacs (the
"interactive" declaration mechanism).    There's a choice here between
having all the dependent code process that data directly, in that
simple form, and trying to make an abstraction around it.

Now, we're talking about making _extensible_ applications (like
Emacs).  So we should imagine lots of different people and code bases
here.  There are:

   ~ many, many people writing declarations.   Some of these wind up
     in the core distribution but many do not.    Therefore, it's
     important to Get Right, early on, a declaration syntax that will
     be stable for a very long time -- we can't afford to continuously 
     tweak it and then tell people "update your declarations".

   ~ a few people writing the core interaction engines.   There will
     be a _little_ bit of code to do things like CLI processing based
     on declarations.   This goes in the main distribution.   The
     challenge for this group is to build an interaction framework
     that is extensible in _unanticipated_ ways.

   ~ interaction customizers:  people who make local customizations of
     interaction loops (such as for accessibility)

The disaster that can happen here is if the code bases of these three
groups becomes two tightly interdependent or interdependent in too
complex ways.  There's no room in this wildly distributed and
uncollected style of development (the kind that characterizes
extensible applications) to make a "global change".  So, while it
might be ok if, say, the interaction engine uses GOOPS internally, it
would be disasterous if every little change to the interaction engine
classes required users in the other two classes to update their code
correspondingly.

One way to avoid such disasters is the "lego approach to lisp
programming".  People sometimes compare object oriented programming to
legos but it's a poor analogy.  Legos classically have a finite number
of types of parts, all of which plug together in simple ways.
Object-oriented style, on the other hand, winds up with hundreds or
thousands of parts, with lots of complex rules about what fits
together with what.  A better lego analogy than object oriented
programming is programming just using basic lisp types for everything
and taking great care to specify extensible syntaxes for data
structures built on top of those.  Perhaps you are familiar with the
famous debate between Jamie Zawinski and RMS about whether events and
keymaps should be built up out of simple lisp types (RMS) or should be
a special disjoint type (jwz).  RMS was, in effect, applying the "lego
principle" and I think his was the superior idea.

It's kind of a situation where K.I.S.S. is the dominant design
consideration.


-t



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

Re: ITLA

[Andreas Rottmann]

Tom Lord <lord@emf.net> writes:

> "To GOOPS or not to GOOPS" is for me, at this stage, an implementation
> detail -- it might or might not be the right thing.
>
> The critical thing, in my view, is to have a data-driven system
> (programmers write declarations) such that you can implement various
> flavors of Emacs' function "call-interactively" -- for CLIs, for smart
> terminals, for GUIs, etc.
>
> Getting the abstraction level of the declarations right is critical --
> both for abstraction over interaction environments (e.g., CLI vs. GUI)
> and for accessability (e.g., make it possible to write  a single
> implementation of "read-file-name" for blind users and have that used
> for _all_ commands that read file names).
>
So far, I agree.

> Ok, I exaggerate slightly -- I'm not quite agnostic about using GOOPS
> in this particular area.  Really, I'm mostly against it except as it
> helps "internally" in various modules.  And the reason has to do with
> (surprise!) modularity.  Here's why:
>
> Declarations are going to be _written_ as simple list structures
> following some (extensible) syntax -- just as they are in emacs (the
> "interactive" declaration mechanism).    There's a choice here between
> having all the dependent code process that data directly, in that
> simple form, and trying to make an abstraction around it.
>
> Now, we're talking about making _extensible_ applications (like
> Emacs).  So we should imagine lots of different people and code bases
> here.  There are:
>
>    ~ many, many people writing declarations.   Some of these wind up
>      in the core distribution but many do not.    Therefore, it's
>      important to Get Right, early on, a declaration syntax that will
>      be stable for a very long time -- we can't afford to continuously 
>      tweak it and then tell people "update your declarations".
>
I also agree here, but IMO, this doesn't speak against using GOOPS as
a "back end"; i.e. making the declarations create GOOPS instances, but
not letting that shine thru at the surface.

>    ~ a few people writing the core interaction engines.   There will
>      be a _little_ bit of code to do things like CLI processing based
>      on declarations.   This goes in the main distribution.   The
>      challenge for this group is to build an interaction framework
>      that is extensible in _unanticipated_ ways.
>
>    ~ interaction customizers:  people who make local customizations of
>      interaction loops (such as for accessibility)
>
> The disaster that can happen here is if the code bases of these three
> groups becomes two tightly interdependent or interdependent in too
> complex ways.  There's no room in this wildly distributed and
> uncollected style of development (the kind that characterizes
> extensible applications) to make a "global change".  So, while it
> might be ok if, say, the interaction engine uses GOOPS internally, it
> would be disasterous if every little change to the interaction engine
> classes required users in the other two classes to update their code
> correspondingly.
>
Sure, a clean seperation between surface syntax (for declarations) and
the internal workings is, to say the least, desirable.

> One way to avoid such disasters is the "lego approach to lisp
> programming".  [...]
>
> Perhaps you are familiar with the famous debate between Jamie
> Zawinski and RMS about whether events and keymaps should be built up
> out of simple lisp types (RMS) or should be a special disjoint type
> (jwz).  RMS was, in effect, applying the "lego principle" and I
> think his was the superior idea.
>
Do you have any references to this discussion?

> It's kind of a situation where K.I.S.S. is the dominant design
> consideration.
>
If you talk just about the "declarative level", I could well agree, if
stuff doesn't get too awkward because of it.

For instance, I just find that generics are just too damn convienent
for managing the namespace, so I don't really want to miss them: You
get away with short names, since generics are mergable (should names
ever collide) if you just keep prefixes for the classes. A short
example out out the (itla tla) module is:

(define-class <tla> ()
  (cwd #:init-thunk getcwd #:accessor working-directory)
  (flags #:init-value '() #:getter flags))

(define-method (invoke (tla <tla>) (command <string>) (args <list>))
  "Returns the output of the tla command as a list of lines."
  (if (flag-set? tla 'verbose)
      (format #t "invoking tla: ~S ~S\n" command args))
  (let ((check (if (string= command "changes")
                   (lambda (val) (<= 0 val 1))
                   (lambda (val) (= 0 val)))))
    (if (flag-set? tla 'dry-run)
      '()
      (apply command-output/check check "tla" (cons command args)))))

So you can just:

(define *tla* (make <tla>))

(invoke *tla* "get" '("--link" "foo--bar--1.0" "some-dir"))

Without using GOOPS, this would probably look more like:

(define *tla* (make-tla))

(tla-invoke *tla* "get" '("--link" "foo--bar--1.0" "some-dir"))

The tla- prefix in this case is not that inconvient, so this is a bad
example, but there are types, for which no suitable
(i.e. readable/easily recognicable) short prefixes can be found.

Of course, this is just low-level stuff, and would never shine thru up
to the "declarative level".

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

Python is executable pseudocode, Perl is executable line-noise.


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

Re: ITLA

[Tom Lord]

    > From: Andreas Rottmann <a.rottmann@gmx.at>

    > I also agree here, but IMO, this doesn't speak against using GOOPS as
    > a "back end"; i.e. making the declarations create GOOPS instances, but
    > not letting that shine thru at the surface.

    [....]

    > Sure, a clean seperation between surface syntax (for declarations) and
    > the internal workings is, to say the least, desirable.

I basically agree with all of that but with a caveat.   The
distinction between "interface" and "internals" in the command
processor of an extensible systems is bound to be fuzzy.   I'm not
saying that the coder of the command processor has to support every
gross hack that anyone ever thinks of --- just that having a really
simple design that promises to be stable and that invites and rewards
"suprising" hacks on top of it is a good thing.


    > > One way to avoid such disasters is the "lego approach to lisp
    > > programming".  [...]

    > > Perhaps you are familiar with the famous debate between Jamie
    > > Zawinski and RMS about whether events and keymaps should be built up
    > > out of simple lisp types (RMS) or should be a special disjoint type
    > > (jwz).  RMS was, in effect, applying the "lego principle" and I
    > > think his was the superior idea.

    > Do you have any references to this discussion?

Oh, foo.  Google around for Xemacs, and jwz, and rms until you get
bored.   The way it's gotten "recorded in history" really obscures the
underlying technical issues and tends to come out as some kind of
clash of personalities.   (But there's some funny, albeit ironic,
commentary around it.)

    > For instance, I just find that generics are just too damn convienent
    > for managing the namespace, so I don't really want to miss them: You
    > get away with short names, since generics are mergable (should names
    > ever collide) if you just keep prefixes for the classes. A short
    > example out out the (itla tla) module is:
    > 
    > (define-class <tla> ()
    >   (cwd #:init-thunk getcwd #:accessor working-directory)
    >   (flags #:init-value '() #:getter flags))
    > 
    > (define-method (invoke (tla <tla>) (command <string>) (args <list>))
    >   "Returns the output of the tla command as a list of lines."
    >   (if (flag-set? tla 'verbose)
    >       (format #t "invoking tla: ~S ~S\n" command args))
    >   (let ((check (if (string= command "changes")
    >                    (lambda (val) (<= 0 val 1))
    >                    (lambda (val) (= 0 val)))))
    >     (if (flag-set? tla 'dry-run)
    >       '()
    >       (apply command-output/check check "tla" (cons command args)))))
    > 
    > So you can just:
    > 
    > (define *tla* (make <tla>))
    > 
    > (invoke *tla* "get" '("--link" "foo--bar--1.0" "some-dir"))
    > 
    > Without using GOOPS, this would probably look more like:
    > 
    > (define *tla* (make-tla))
    > 
    > (tla-invoke *tla* "get" '("--link" "foo--bar--1.0" "some-dir"))
    > 
    > The tla- prefix in this case is not that inconvient, so this is a bad
    > example, but there are types, for which no suitable
    > (i.e. readable/easily recognicable) short prefixes can be found.
    > 
    > Of course, this is just low-level stuff, and would never shine thru up
    > to the "declarative level".

The last paragraph is probably the most important.

Keep in mind, too, that someone might want to write extensions that
crawl over the set of commands -- perhaps to format a help message or
perhaps to make some new kind of menu-driven interface.   Keeping all
the relevent data in the simplest format (e.g., s-exps following an
extensible syntax over basic types) makes that easy.

For example, since you have the basic idea of a command processor of
the sort we're discussing, can you:

  (a) imagine an implementation
  (b) presume the implementation is built, has at least a CLI a 
      front-end and maybe a GUI front end.
  (c) assume that lots of people have written code against this
      implementation.

and then:

  (d) imagine implementing something like:

        http://segusoland.sourceforge.net

      in a way that everybody's existing code "just works" with
      the new input method?


-t



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

Re: ITLA

[Andreas Rottmann]

Tom Lord <lord@emf.net> writes:

>     > Of course, this is just low-level stuff, and would never shine thru up
>     > to the "declarative level".
>
> The last paragraph is probably the most important.
>
> Keep in mind, too, that someone might want to write extensions that
> crawl over the set of commands -- perhaps to format a help message or
> perhaps to make some new kind of menu-driven interface.   Keeping all
> the relevent data in the simplest format (e.g., s-exps following an
> extensible syntax over basic types) makes that easy.
>
If you have a brief glance at the codebase, you'll see that there is a
(itla ui) module. This currently is a crude wrapper around a single
<tla> instance, using the Guile REPL and GOOPS for user-interaction. I
just came up with this as a quick hack to have something to play
around with, not intending it as a permanent solution. So my question
is: do you feel comfortable with this design (a low-level interface,
using GOOPS, designed for maximum flexibility) and an eventual command
processor/UI built on top of that?

I think this seperation is warranted, to quote you[0]:

,----
| (define-command (init-tree version dir nested?)
| 
| 	  (help-message   (category tree)
|                           (% tla init-tree -H))
| 
|           (parameters   (version	new-fq-version-name)
|                         (dir		(extended existing-directory))
|                         (nested?	(extended y-or-n)))
| 
|           (output	plain-text)
| 
| 	  (run-tla "init-tree"
|                    (if dir (list "-D" dir))
|                    (if nested? (list "--nested"))
|                    version))
`----

I think there might be concepts apparent in this code that don't
belong into the low level interface: new-fq-version-name, for instance
(if I understand correctly) will cause the user to be prompted for a
*new* version name. I would consider the knowledge about existing
versions not something to be located at the low level interface (but
easily extracted using it). Also, prompting, as indicated by y-or-n
doesn't belong there.

But, on the other hand, this separation turns up the issue of
duplication: Since you'd want access most TLA commands also through
the low-level interface, you'd define most commands in two places,
which is unfortunate.

> For example, since you have the basic idea of a command processor of
> the sort we're discussing, can you:
>
>   (a) imagine an implementation
>   (b) presume the implementation is built, has at least a CLI a 
>       front-end and maybe a GUI front end.
>   (c) assume that lots of people have written code against this
>       implementation.
>
> and then:
>
>   (d) imagine implementing something like:
>
>         http://segusoland.sourceforge.net
>
Looks and sounds interesting, this segusoland stuff.

>
>       in a way that everybody's existing code "just works" with
>       the new input method?
>
I hope you didn't mean for me now to come up with an implementation
plan (cough), but I'll try to keep that in the back of my mind.


[0] http://article.gmane.org/gmane.comp.version-control.arch.user/18334

Cheers, 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

Say NO to Software Patents! -- http://petition.eurolinux.org/



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

Re: ITLA

[Miles Bader]

Tom Lord <lord@emf.net> writes:
> I'm not quite agnostic about using GOOPS in this particular area.
> Really, I'm mostly against it except as it helps "internally" in
> various modules.
...
> It's kind of a situation where K.I.S.S. is the dominant design
> consideration.

Yeah...

When I read the post to which you replied, I had this sinking feeling I
was seeing the Beginning of the Creep.

-Miles
-- 
If you can't beat them, arrange to have them beaten.  [George Carlin]


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

Re: ITLA

[Neil Jerram]

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

> Tom Lord <lord@emf.net> writes:
> 
> ,----
> |   Each interactive command will be defined by an ordinary Scheme
> |   procedure supplemented with a _declaration_.  The declaration lists:
> | 
> |   ~ the name of the command
> |   ~ a documentation string for the command
> |   ~ a list of options and parameters to the command, each
> |     specified by:
> | 
> |         + a parameter name
> | 
> |         + a "type declaration" (e.g., "string", or "new-archive-name",
> |           or "existing-archive-name", or "archive-name".)
> | 
> |         + a description of how it is parsed from options and
> |           arguments provided on command lines
> | 
> |         + a default value
> | 
> |         + an optional prompt string
> | 
> |         + an optional help string for the parameter
> | 
> |   ~ a "type declaration" for the output of the command
> | 

I've already coded something roughly along these lines, from the point
of view of providing infrastructure for command line driven
applications (for example, the Guile debugger).

This is in the modules (ossau interactive) and (ossau interactive XXX)
in http://www.ossau.uklinux.net/guile/guile-interactive-0.7.tar.gz, and
(ossau command-loop) may also be relevant.

Anyone working on this might want to check if they can get some
initial mileage out of my code.

        Neil


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

Re: ITLA

[Andreas Rottmann]

Neil Jerram <neil@ossau.uklinux.net> writes:

> I've already coded something roughly along these lines, from the point
> of view of providing infrastructure for command line driven
> applications (for example, the Guile debugger).
>
> This is in the modules (ossau interactive) and (ossau interactive XXX)
> in http://www.ossau.uklinux.net/guile/guile-interactive-0.7.tar.gz, and
> (ossau command-loop) may also be relevant.
>
> Anyone working on this might want to check if they can get some
> initial mileage out of my code.
>
Thanks for providing this info! When/If I really start at the command
processor, I'll have a look at it.

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

Python is executable pseudocode, Perl is executable line-noise.


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

Archive of library modules for Guile

[Andreas Rottmann]

Neil Jerram <neil@ossau.uklinux.net> writes:

> This is in the modules (ossau interactive) and (ossau interactive XXX)
> in http://www.ossau.uklinux.net/guile/guile-interactive-0.7.tar.gz, and
> (ossau command-loop) may also be relevant.
>
> Anyone working on this might want to check if they can get some
> initial mileage out of my code.
>
Neil: I looked at the page http://www.ossau.uklinux.net/guile/ and I
  think there is some general use code there. If you don't have
  something against it, i'll reap what I consider useful, and toss it
  along with the guile-library-0.1 tarball into a an Arch archive for
  public consumption and hacking. I'll announce the availability to
  guile-user when ready.

ttn: I think it would be cool if the glug people could branch off this
  archive and add their general-use code to their branches. I'll then
  happily merge this code back in. Detailed instructions on how this
  would happen will be provided with the archive
  announcement. Thoughts? ]

And finally: what is the general feeling about such an archive among
the Guile user (and developer) community?

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

Python is executable pseudocode, Perl is executable line-noise.


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

Re: Archive of library modules for Guile

[Neil Jerram]

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

> Neil: I looked at the page http://www.ossau.uklinux.net/guile/ and I
>   think there is some general use code there. If you don't have
>   something against it, i'll reap what I consider useful, and toss it
>   along with the guile-library-0.1 tarball into a an Arch archive for
>   public consumption and hacking. I'll announce the availability to
>   guile-user when ready.

Please do!  Please also keep me in touch with what I need to do to
join in the hacking - I'm not yet familiar with Arch, but what I'm
hearing sounds fun.  It's possible that I have more up to date
versions of some of the bits that accessible from my web page, but I
can sort that out later as a way of getting myself used to the system.

> ttn: I think it would be cool if the glug people could branch off this
>   archive and add their general-use code to their branches. I'll then
>   happily merge this code back in. Detailed instructions on how this
>   would happen will be provided with the archive
>   announcement. Thoughts? ]
> 
> And finally: what is the general feeling about such an archive among
> the Guile user (and developer) community?

I've been wondering about (the hypothetical) GUMM again recently, and
having difficulty working out what GUMM would buy us that we can't get
just by maintaining a set of Debian packages.  The Debian approach
would automatically give us a central repository, mirrors, and
dependency tracking.  (What do things like CPAN provide beyond
Debian-like packages? - and sorry for being lazy by not going to look
for myself)

It may be that the key to a good GUMM is not so much distribution as
hackability - in which case your Arch archive might be just what we
need.  Definitely worth a go, anyway.

        Neil


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

Re: Archive of library modules for Guile

[Andreas Rottmann]

Neil Jerram <neil@ossau.uklinux.net> writes:

> Andreas Rottmann <a.rottmann@gmx.at> writes:
>
>> Neil: I looked at the page http://www.ossau.uklinux.net/guile/ and I
>>   think there is some general use code there. If you don't have
>>   something against it, i'll reap what I consider useful, and toss it
>>   along with the guile-library-0.1 tarball into a an Arch archive for
>>   public consumption and hacking. I'll announce the availability to
>>   guile-user when ready.
>
> Please do!  Please also keep me in touch with what I need to do to
> join in the hacking - I'm not yet familiar with Arch, but what I'm
> hearing sounds fun.  It's possible that I have more up to date
> versions of some of the bits that accessible from my web page, but I
> can sort that out later as a way of getting myself used to the system.
>
OK, will start things this weekend. I'll keep guile-user, you, and ttn
posted.

>> ttn: I think it would be cool if the glug people could branch off this
>>   archive and add their general-use code to their branches. I'll then
>>   happily merge this code back in. Detailed instructions on how this
>>   would happen will be provided with the archive
>>   announcement. Thoughts? ]
>> 
>> And finally: what is the general feeling about such an archive among
>> the Guile user (and developer) community?
>
> I've been wondering about (the hypothetical) GUMM again recently,
> [...]
>
I think it would be really cool if we could work together on
standardizing on a coherent module namespace, maybe with personal
modules that are integrated into the "core" namespace as they mature
and are used more widely.

> It may be that the key to a good GUMM is not so much distribution as
> hackability - in which case your Arch archive might be just what we
> need.  Definitely worth a go, anyway.
>
One the developer side, this may suffice. I intend to only host
scheme-only stuff in the archive (at least initially), since depending
on external ABIs will complicate stuff.

On a related issue I also wonder about ttn's new build system, which
seems like an automake-replacement at a first glance. Since it ties in
Guile into the configure process (or rather the autoconf run), it's
bound to be much more flexible. I imagine one would be able to make it
an interesting team together with tla's build-config command --
i.e. build different tarball distributions for different combinations
of components of the archive automatically, so we could easily release
subsystems of the library separatly, resulting in stuff like:

guile-lib-0.1.tar.gz
guile-lib-experimental-0.1.tar.gz
guile-lib-pers-ttn-0.1.tar.gz
...

With my itla-debuild tool[0], we could release stuff directly from the
archive as Debian packages in a really convinient fashion :-)

[0] See http://stud3.tuwien.ac.at/~e9926584/ITLA.html for a bit of
    info. My current working copy just sucessfully built its first
    packages, will commit to my archive soon, expect a debian package
    in < a few months.

Cheers, 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

Python is executable pseudocode, Perl is executable line-noise.


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

Re: Archive of library modules for Guile

[Thamer Al-Harbash]

On Thu, 4 Mar 2004, Andreas Rottmann wrote:

> ttn: I think it would be cool if the glug people could branch off this
>   archive and add their general-use code to their branches. I'll then
>   happily merge this code back in. Detailed instructions on how this
>   would happen will be provided with the archive
>   announcement. Thoughts? ]
>
> And finally: what is the general feeling about such an archive among
> the Guile user (and developer) community?

I'll help port any of ttn's work if you need the help. I've done
a bit with ttn's sdl module. Feel free to assign me something on
your todo list which would be in this category.

-- 
Thamer Al-Harbash
GPG Key fingerprint: D7F3 1E3B F329 8DD5 FAE3  03B1 A663 E359 D686 AA1F


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

Re: Archive of library modules for Guile

[Thien-Thi Nguyen]

   From: Andreas Rottmann <a.rottmann@gmx.at>
   Date: Thu, 04 Mar 2004 14:55:36 +0100

   Detailed instructions on how this would happen will be provided with
   the archive announcement.  Thoughts?

my interest in (re-)organization of things at this level is at a trough
at the moment.  the MO is simple: capable programmers post code and
those things that strike my fancy i will use or adapt to my needs, if i
am able.  what code i write i post (capable or not ;-).

   And finally: what is the general feeling about such an archive among
   the Guile user (and developer) community?

probably any "general feeling" you can glean is illusory at best.  my
personal feeling is that separating users and programmers in the context
of guile is a mistake, and not realizing this as a mistake is another
mistake.  this is the same spew i've spewed before so i'll stop now.

thi


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

Re: Arch and Guile

[Thien-Thi Nguyen]

   From: Andreas Rottmann <a.rottmann@gmx.at>
   Date: Mon, 01 Mar 2004 15:27:38 +0100

   Such a gateway is very simple to use: You have someone who is the
   "Gatekeeper" between the Arch and CVS world. This person then merges
   stuff form other people's branches into the dedicated "CVS" branch,
   which is synced with CVS in both directions. 

well, we already have capable goal keepers keeping the cvs sources pure
from the corrupting influence of users, so probably there is no need for
more of the same.

     [...] a CVS-tracking-but-not-commit gateway as described above.
     Actually, this sounds like a good intermediate plan.

to me it sounds like a very good plan, even if not intermediate.  a
constellation of source trees, one of which can be labeled "official"
but not requiring any particular additional attention (unless something
tasty appears there).

   > [...] perhaps that is too hard line...

   I'm not totally clear what you mean here, and how that relates to an
   Arch<->CVS gateway.

it was tangential reflection, harmlessly ignorable.

thi


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

Re: Arch and Guile

[Andreas Rottmann]

Thien-Thi Nguyen <ttn@surf.glug.org> writes:

>    Such a gateway is very simple to use: You have someone who is the
>    "Gatekeeper" between the Arch and CVS world. This person then merges
>    stuff form other people's branches into the dedicated "CVS" branch,
>    which is synced with CVS in both directions. 
>
> well, we already have capable goal keepers keeping the cvs sources pure
> from the corrupting influence of users, so probably there is no need for
> more of the same.
>
Since the Gatekeeper needs CVS write access, he needs to be one of
those "goal keepers" (typo?) anyway.

>      [...] a CVS-tracking-but-not-commit gateway as described above.
>      Actually, this sounds like a good intermediate plan.
>
> to me it sounds like a very good plan, even if not intermediate.  a
> constellation of source trees, one of which can be labeled "official"
> but not requiring any particular additional attention (unless something
> tasty appears there).
>
Yeah. I have hoped my SRFI-35 implementation could be considered
"something tasty" (it's more or less complete now), but so far, there
was no response to this :-(

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

Make free software, not war!


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

Re: Arch and Guile

[Thien-Thi Nguyen]

   From: Andreas Rottmann <a.rottmann@gmx.at>
   Date: Tue, 02 Mar 2004 01:23:40 +0100

   Yeah. I have hoped my SRFI-35 implementation could be considered
   "something tasty" (it's more or less complete now), but so far, there
   was no response to this :-(

it is your opportunity to go into scientist mode: response by humans is
just one measurement of its worth (and not a very reliable one although
entertaining at times).  you can also measure/observe its complexity in
time and/or space, its dependency graph, its behavior when faced w/ bad
input, etc.  you can write another implementation and do a side by side
comparison of above.  you can do a non-quantitative comparison to those
implementations that cannot run on your machine.  you can try compiling
your code or deducing what extra hints a compiler would need to do so.

thi


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

Re: Extended -e syntax

[Thien-Thi Nguyen]

   From: Clinton Ebadi <clinton@unknownlamer.org>
   Date: Sun, 29 Feb 2004 22:32:45 -0500

   Is ttn still assigning his copyright to the FSF?

i assigned (in writing) copyright on all future changes to guile to the
FSF.  there were no sunset or revocation clauses.  this happened circa
2000/2001 iirc.

thi


[cc trimmed]


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

Re: Extended -e syntax

[Christopher Cramer]

On Sun, Feb 29, 2004 at 10:32:45PM -0500, Clinton Ebadi wrote:
> I've been trying to get guile-pg to compile and it hasn't been working out
> too well...ttn uses his new build system stuff with guile-pg and they only
> work with Guile 1.4.x unless Guile has support for his extended -e syntax.

Here's a patch for the sourceforge guile-pg that gets it to compile
with Guile 1.6. No idea if it works with 1.7. I sent this to the (then)
guile-pg maintainer years ago but he never released another version.

I have been using this for a long time now with no problems, but I've
never used large objects so that part is not tested. You need to run
automake after applying this patch.

	* Makefile.am: change to work with Guile 1.6 snarfer

	* libpostgres.c, libpostgres_lo.c, scm/postgres.scm.in:
	update to use Guile 1.6 API

diff -ur guile-pg-0.07/Makefile.am guile-pg-0.07-new/Makefile.am
--- guile-pg-0.07/Makefile.am	Fri Jun  2 02:52:34 2000
+++ guile-pg-0.07-new/Makefile.am	Sat Jul 20 19:04:00 2002
@@ -43,7 +43,7 @@
 
 SUFFIXES = .x
 .c.x:
-	guile-snarf $(DEFS) $(INCLUDES) $(CPPFLAGS) $(CFLAGS) $< > $@
+	guile-snarf $< $(DEFS) $(INCLUDES) $(CPPFLAGS) $(CFLAGS) > $@
 
 ## Add -MG to make the .x magic work with auto-dep code.
 MKDEP = gcc -M -MG $(DEFS) $(INCLUDES) $(CPPFLAGS) $(CFLAGS)
diff -ur guile-pg-0.07/libpostgres.c guile-pg-0.07-new/libpostgres.c
--- guile-pg-0.07/libpostgres.c	Tue Jun 20 04:41:51 2000
+++ guile-pg-0.07-new/libpostgres.c	Sat Jul 20 22:02:05 2002
@@ -37,7 +37,6 @@
 #include <guile/gh.h>
 
 #include <libpq-fe.h>
-#include <postgres.h>
 #include <libpq/libpq-fs.h>
 
 #include <libpostgres.h>
@@ -1151,14 +1150,14 @@
 
 #include <libpostgres.x>
 
-    scm_sysintern("PGRES_TUPLES_OK", SCM_MAKINUM(PGRES_TUPLES_OK));
-    scm_sysintern("PGRES_COMMAND_OK", SCM_MAKINUM(PGRES_COMMAND_OK));
-    scm_sysintern("PGRES_EMPTY_QUERY", SCM_MAKINUM(PGRES_EMPTY_QUERY));
-    scm_sysintern("PGRES_COPY_OUT", SCM_MAKINUM(PGRES_COPY_OUT));
-    scm_sysintern("PGRES_COPY_IN", SCM_MAKINUM(PGRES_COPY_IN));
-    scm_sysintern("PGRES_BAD_RESPONSE", SCM_MAKINUM(PGRES_BAD_RESPONSE));
-    scm_sysintern("PGRES_NONFATAL_ERROR", SCM_MAKINUM(PGRES_NONFATAL_ERROR));
-    scm_sysintern("PGRES_FATAL_ERROR", SCM_MAKINUM(PGRES_FATAL_ERROR));
+    scm_c_define("PGRES_TUPLES_OK", SCM_MAKINUM(PGRES_TUPLES_OK));
+    scm_c_define("PGRES_COMMAND_OK", SCM_MAKINUM(PGRES_COMMAND_OK));
+    scm_c_define("PGRES_EMPTY_QUERY", SCM_MAKINUM(PGRES_EMPTY_QUERY));
+    scm_c_define("PGRES_COPY_OUT", SCM_MAKINUM(PGRES_COPY_OUT));
+    scm_c_define("PGRES_COPY_IN", SCM_MAKINUM(PGRES_COPY_IN));
+    scm_c_define("PGRES_BAD_RESPONSE", SCM_MAKINUM(PGRES_BAD_RESPONSE));
+    scm_c_define("PGRES_NONFATAL_ERROR", SCM_MAKINUM(PGRES_NONFATAL_ERROR));
+    scm_c_define("PGRES_FATAL_ERROR", SCM_MAKINUM(PGRES_FATAL_ERROR));
 
     init_libpostgres_lo();
 
diff -ur guile-pg-0.07/libpostgres_lo.c guile-pg-0.07-new/libpostgres_lo.c
--- guile-pg-0.07/libpostgres_lo.c	Fri Jun  2 05:14:55 2000
+++ guile-pg-0.07-new/libpostgres_lo.c	Sat Jul 20 20:05:16 2002
@@ -197,7 +197,7 @@
   SCM_SETSTREAM (port, (SCM) lobp);
 
   pt->rw_random = 1;
-  if (SCM_INPORTP (port)) {
+  if (SCM_INPUT_PORT_P (port)) {
       pt->read_buf = malloc (LOB_BUFLEN);
       if (pt->read_buf == NULL)
         scm_memory_error (s_lob_mklobport);
@@ -207,7 +207,7 @@
       pt->read_buf = ((unsigned char *) pt->read_pos) = pt->read_end = &pt->shortbuf;
       pt->read_buf_size = 1;
   }
-  if (SCM_OUTPORTP (port)) {
+  if (SCM_OUTPUT_PORT_P (port)) {
       pt->write_buf = malloc (LOB_BUFLEN);
       if (pt->write_buf == NULL)
         scm_memory_error (s_lob_mklobport);
@@ -219,7 +219,7 @@
   }
   pt->write_end = pt->write_buf + pt->write_buf_size;
 
-  SCM_SETCAR (port, SCM_CAR (port) & ~SCM_BUF0);
+  SCM_SET_CELL_WORD_0 (port, SCM_CELL_WORD_0 (port) & ~SCM_BUF0);
 
   SCM_ALLOW_INTS;
 
@@ -315,7 +315,7 @@
               }
               pt->write_pos = pt->write_buf + remaining;
           }
-          if (!terminating)
+          if (1 /*!terminating*/)
              scm_syserror ("lob_flush");
           else {
               const char *msg = "Error: could not flush large object file descriptor ";
@@ -445,7 +445,7 @@
              lob_flush (port);
       }
       /* handle line buffering.  */
-      if ((SCM_CAR (port) & SCM_BUFLINE) && memchr (data, '\n', size))
+      if ((SCM_CELL_WORD_0 (port) & SCM_BUFLINE) && memchr (data, '\n', size))
           lob_flush (port);
    }
 }
diff -ur guile-pg-0.07/scm/postgres.scm.in guile-pg-0.07-new/scm/postgres.scm.in
--- guile-pg-0.07/scm/postgres.scm.in	Wed May 31 04:59:07 2000
+++ guile-pg-0.07-new/scm/postgres.scm.in	Sat Jul 20 21:11:43 2002
@@ -20,10 +20,56 @@
 
 ;; Load the C interface functions
 
-(if (not (defined? 'pg-guile-pg-loaded)) ;; Unless already loaded (static) ...
-  (dynamic-call "init_postgres" (dynamic-link "libpostgres.so")))
+(define-module (database postgres)
+  :export (
+	PGRES_TUPLES_OK
+	PGRES_COMMAND_OK
+	PGRES_EMPTY_QUERY
+	PGRES_COPY_OUT
+	PGRES_COPY_IN
+	PGRES_BAD_RESPONSE
+	PGRES_NONFATAL_ERROR
+	PGRES_FATAL_ERROR
+	pg-connectdb
+	pg-reset
+	pg-get-client-data
+	pg-set-client-data!
+	pg-exec
+	pg-error-message
+	pg-get-db
+	pg-set-db
+	pg-get-user
+	pg-get-pass
+	pg-get-host
+	pg-get-port
+	pg-get-tty
+	pg-get-options
+	pg-get-connection
+	pg-backend-pid
+	pg-result-status
+	pg-ntuples
+	pg-nfields
+	pg-cmdtuples
+	pg-oid-status
+	pg-oid-value
+	pg-fname
+	pg-fnumber
+	pg-ftype
+	pg-fsize
+	pg-getvalue
+	pg-getlength
+	pg-getisnull
+	pg-binary-tuples?
+	pg-fmod
+	pg-guile-pg-version
+	pg-getline
+	pg-putline
+	pg-endcopy
+	pg-trace
+	pg-untrace))
 
-(define-module (database postgres))
+(if (not (defined? 'pg-guile-pg-loaded)) ;; Unless already loaded (static) ...
+  (load-extension "libpostgres" "init_postgres"))
 
 (define-public (pg-guile-pg-module-config-stamp) "@GUILE_PG_STAMP@")
 (define-public (pg-guile-pg-module-version) "@VERSION@")

-- 
Christopher Cramer <crayc@pyro.net> <http://www.pyro.net/~crayc/>
In politics you have to understand not where the voters are when a poll
is taken, but where they are likely to end up on Election Day.
-- Rep. Tom Davis, former NRCC Chairman


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

Re: Extended -e syntax

[Clinton Ebadi]

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

On Monday 01 March 2004 15:20, Christopher Cramer wrote:
> On Sun, Feb 29, 2004 at 10:32:45PM -0500, Clinton Ebadi wrote:
> > I've been trying to get guile-pg to compile and it hasn't been working
> > out too well...ttn uses his new build system stuff with guile-pg and they
> > only work with Guile 1.4.x unless Guile has support for his extended -e
> > syntax.
>
> Here's a patch for the sourceforge guile-pg that gets it to compile
> with Guile 1.6. No idea if it works with 1.7. I sent this to the (then)
> guile-pg maintainer years ago but he never released another version.

ttn's Guile-pg is a bit...improved. As are several things in his Guile tree 
(extended -e, extended getopt, improved regexp support, really nice build 
system, improved guile-config, etc.).

The only problem I see with merging anything is that Guile 1.4.x uses the old 
Guile license and Guile CVS now uses the LGPL. Since the FSF owns the 
copyrights, they can be relicensed fairly easily, correct?
- -- 
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)

iD8DBQFARBPYdgGh8PQDV0sRAtSyAJ96C8ica/XKAqdhI+tAZpkaG++JJwCcD79e
NTr9IfpgATt3tTbkNtqvbkc=
=1fnS
-----END PGP SIGNATURE-----


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

ttn's build system [was: Extended -e syntax]

[Andreas Rottmann]

[ Tom: Thien-Thi Nguyen has written a buildsystem for his Guile branch
  which uses autoconf, but replaces automake, suing Guile. I intend to
  make that play well with Arch, akin to your package-framework, so
  you might be interested in this message ]

Clinton Ebadi <clinton@unknownlamer.org> writes:

> I've been trying to get guile-pg to compile and it hasn't been
> working out too well...ttn uses his new build system stuff with
> guile-pg and they only work with Guile 1.4.x unless Guile has
> support for his extended -e syntax.
>
> As such, I copied ttn's code from Guile 1.4, changed one call
> (gh_symbol2scm into scm_str2symbol), and patched it into Guile CVS
> HEAD. Is ttn still assigning his copyright to the FSF? The copyright
> notices on all the files would make it appear so (I have sent this
> to guile-user as well as -devel so ttn will see it since he
> unsubscribed from guile-devel after he forked Guile).
>
> Is there any chance of mainline Guile using the extended -e stuff or
> accepting patches to use ttn's nice build system and extended
> guile-config stuff? I am willing to chunk out anything from Guile
> 1.4.x that would be useful to the official Guile branch if there
> aren't any copyright issues / the patches will be accepted. 
>
Have you already started this? I'm especially interested in the
build-system, and will break that out into a separate piece, since I
intend to use it for the Guile-Library thing and possible at a later
point in Guile-Gnome. I can't wait for this being perhaps eventually
integrated into Guile (I suspect this might take *some* time to
happen). So if you haven't started tackling "porting" the build
system, it *might* make sense to wait for what I'll produce, which
will be a piece of software building on Guile, but not integrated into
guile-tools. This means just shipping it with Guile in the future,
making guile-tools tie it in, could be an alternative of a direct
port, avoiding duplicate effort.

Cheers, 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

Any technology not indistinguishable from magic is insufficiently advanced.
   -- Terry Pratchett



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

Re: ttn's build system

[Andreas Rottmann]

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

>> Is there any chance of mainline Guile using the extended -e stuff or
>> accepting patches to use ttn's nice build system and extended
>> guile-config stuff? I am willing to chunk out anything from Guile
>> 1.4.x that would be useful to the official Guile branch if there
>> aren't any copyright issues / the patches will be accepted. 
>>
> Have you already started this? I'm especially interested in the
> build-system, and will break that out into a separate piece, since I
> intend to use it for the Guile-Library thing and possible at a later
> point in Guile-Gnome. I can't wait for this being perhaps eventually
> integrated into Guile (I suspect this might take *some* time to
> happen). So if you haven't started tackling "porting" the build
> system, it *might* make sense to wait for what I'll produce, which
> will be a piece of software building on Guile, but not integrated into
> guile-tools. This means just shipping it with Guile in the future,
> making guile-tools tie it in, could be an alternative of a direct
> port, avoiding duplicate effort.
>
Mostly ignore the above. My current aproach will make use of
autofrisk, but not break it out or change it. However, I'm not even
sure it will work as in Guile 1.7, as guile-tools read-scheme-source
is broken (omits forms under some conditions). So any work to patch
autofrisk and the related tools like read-scheme-source is highly
appreciated and will happily be merged into the ttn-features branch of
my unofficial archive.

Cheers, 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

The best way to accelerate a Windows machine is at 9.81 m/s^2



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

Re: ttn's build system [was: Extended -e syntax]

[Clinton Ebadi]

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

On Saturday 06 March 2004 10:47, Andreas Rottmann wrote:
> Clinton Ebadi <clinton@unknownlamer.org> writes:
> > I've been trying to get guile-pg to compile and it hasn't been
> > working out too well...ttn uses his new build system stuff with
> > guile-pg and they only work with Guile 1.4.x unless Guile has
> > support for his extended -e syntax.

> Have you already started this? I'm especially interested in the
> build-system, and will break that out into a separate piece, since I
> intend to use it for the Guile-Library thing and possible at a later
> point in Guile-Gnome. I can't wait for this being perhaps eventually
> integrated into Guile (I suspect this might take *some* time to
> happen). So if you haven't started tackling "porting" the build
> system, it *might* make sense to wait for what I'll produce, which
> will be a piece of software building on Guile, but not integrated into
> guile-tools. This means just shipping it with Guile in the future,
> making guile-tools tie it in, could be an alternative of a direct
> port, avoiding duplicate effort.

I haven't started to work on the build system stuff so I'll focus on other 
stuff for now (modsup and friends).

- -- 
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.4 (GNU/Linux)

iD8DBQFAT5aMdgGh8PQDV0sRAh9UAJ0QLDHlH4y0aYgwssoi5/3jGTD7kACgo9OV
w2PU+lnOA2IfAkknrVTZEGU=
=9Ou9
-----END PGP SIGNATURE-----


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

Re: ttn's build system [was: Extended -e syntax]

[Tom Lord]

    > From: Andreas Rottmann <a.rottmann@gmx.at>

    > [ Tom: Thien-Thi Nguyen has written a buildsystem for his Guile branch
    >   which uses autoconf, but replaces automake, suing Guile. I intend to
    >   make that play well with Arch, akin to your package-framework, so
    >   you might be interested in this message ]

Sort of.   I cut my professional teeth working on build systems and
have some definate ideas about them.   auto* (including -conf) is
... um ... suboptimal.

It would merit its own big-ass project to replace them in a
comprehensive way --- something I'm interested in but don't have much
bandwidth to work on.  And, anyway, few people have enough experience
in this area to do it well or understand why a good design is good --
so volunteer contributions would be hard to shepherd.   And also:
obtaining _adoption_ of new systems is steep uphill climb -- there's a
lot of inertia to overcome.

Personally, with due respect to the list, it's something I'm more
likely to want to work on once Pika is humming along rather than
before.   It's an area that has pretty touchy requirements for the
scripting language used.

So, yes, I'm interested -- but no, I'm not about to delve into it in
depth.


-t


p.s.: why are package systems and configuration systems different
  things?  Makes no sense (other than historical) at all.




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