What can I do to help?

What can I do to help?

[Dr William Bland]

Hello all,
	I would like to start hacking guile and was wondering if people
could give me some pointers on what would be good to do.  I had a few
ideas myself:

1. Add a guile scripting plugin to Abiword.

2. Move the GIMP from script-fu (SIOD) to guile, perhaps by reviving
   gimple.

3. There is a TODO for writing a CORBA interface.  I've wanted to learn
   CORBA for a while now, and maybe this would be a good way to do it?

If anyone has any comments on these, or suggestions for others that may be
more important / easier for a guile newbie / etc. I'd be very
interested in hearing them.

Thanks for your help.
Best wishes,
		Bill.


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

What can I do to help?

[Han-Wen Nienhuys]

wjb@abstractnonsense.com writes:
> could give me some pointers on what would be good to do.  I had a few
> ideas myself:
> 
> 1. Add a guile scripting plugin to Abiword.
> 
> 2. Move the GIMP from script-fu (SIOD) to guile, perhaps by reviving
>    gimple.
> 
> 3. There is a TODO for writing a CORBA interface.  I've wanted to learn
>    CORBA for a while now, and maybe this would be a good way to do it?
> 
> If anyone has any comments on these, or suggestions for others that may be
> more important / easier for a guile newbie / etc. I'd be very
> interested in hearing them.

Don't know about the difficulty, and the actual need of such a
project, but maybe a set of GUILE bindings for libxml or somesuch --
XML is becoming the standard for storing various files, and there
GUILE doesn't come with any support for reading or writing it
(out-of-the-box, that is).


--
Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 


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

Re: What can I do to help?

[Dr William Bland]

On Sat, Sep 28, 2002 at 06:19:34PM +0200, Han-Wen Nienhuys wrote:
>
> Don't know about the difficulty, and the actual need of such a
> project, but maybe a set of GUILE bindings for libxml or somesuch --
> XML is becoming the standard for storing various files, and there
> GUILE doesn't come with any support for reading or writing it
> (out-of-the-box, that is).

Sounds like a good idea to me.  Is anyone else working on this? (don't
want to step on anyone's toes).  Does anybody have any requests/advice for
how it should/shouldn't be done?

Best wishes,
		Bill.


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

Re: What can I do to help?

[Dale P. Smith]

On Mon, 30 Sep 2002 08:56:54 +0000
Dr William Bland <wjb@abstractnonsense.com> wrote:

> On Sat, Sep 28, 2002 at 06:19:34PM +0200, Han-Wen Nienhuys wrote:
> >
> > Don't know about the difficulty, and the actual need of such a
> > project, but maybe a set of GUILE bindings for libxml or somesuch --
> > XML is becoming the standard for storing various files, and there
> > GUILE doesn't come with any support for reading or writing it
> > (out-of-the-box, that is).
> 
> Sounds like a good idea to me.  Is anyone else working on this? (don't
> want to step on anyone's toes).  Does anybody have any requests/advice for
> how it should/shouldn't be done?

I *hope* this is just for interfacing with other systems.  Any beguiled
program should be using s-expressions for it's config file format. 
That's basically the whole point of using Guile, right? ;^)

-Dale

-- 
Dale P. Smith
Senior Systems Consultant,      | Treasurer,
Altus Technologies Corporation  | Cleveland Linux Users Group
dsmith@altustech.com            | http://cleveland.lug.net
440-746-9000 x339               |


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

Re: What can I do to help?

[Dr William Bland]

On Mon, Sep 30, 2002 at 06:57:53AM -0400, Dale P. Smith wrote:
> 
> On Mon, 30 Sep 2002 08:56:54 +0000
> Dr William Bland <wjb@abstractnonsense.com> wrote:
> 
> > On Sat, Sep 28, 2002 at 06:19:34PM +0200, Han-Wen Nienhuys wrote:
> > >
> > > Don't know about the difficulty, and the actual need of such a
> > > project, but maybe a set of GUILE bindings for libxml or somesuch --
> > > XML is becoming the standard for storing various files, and there
> > > GUILE doesn't come with any support for reading or writing it
> > > (out-of-the-box, that is).
> > 
> > Sounds like a good idea to me.  Is anyone else working on this? (don't
> > want to step on anyone's toes).  Does anybody have any requests/advice for
> > how it should/shouldn't be done?
> 
> I *hope* this is just for interfacing with other systems.  Any beguiled
> program should be using s-expressions for it's config file format. 
> That's basically the whole point of using Guile, right? ;^)
> 
> -Dale

If you think that libxml bindings won't/shouldn't get used much, please
feel free to suggest something else for me to work on.

Best wishes,
		Bill.


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

Re: What can I do to help?

[Han-Wen Nienhuys]

dsmith@altustech.com writes:
> > Sounds like a good idea to me.  Is anyone else working on this? (don't
> > want to step on anyone's toes).  Does anybody have any requests/advice for
> > how it should/shouldn't be done?
> 
> I *hope* this is just for interfacing with other systems.  Any beguiled
> program should be using s-expressions for it's config file format. 
> That's basically the whole point of using Guile, right? ;^)

Of course.  According to my overinflated ego, XML is just a complete
pain to parse, to handle and generate. Unfortunately, it *is* becoming
a standard, if we like it or not, and having no support for it raise
the barrier for using GUILE (imo). For example people just keep asking
me about XML file formats and MusicXML support for Lilypond.  Having
an XML lib in GUILE would make addressing this issue easier. 

BTW, I did read that there were bindings for expat. I don't know which
of the systems (expat and libxml) makes most sense to use, though. You
try to find out whether the old bindings still work with recent GUILE
releases.


-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 


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

Re: What can I do to help?

[Dale P. Smith]

On Mon, 30 Sep 2002 19:59:05 +0200
Han-Wen Nienhuys <hanwen@cs.uu.nl> wrote:

> dsmith@altustech.com writes:
> > > Sounds like a good idea to me.  Is anyone else working on this? (don't
> > > want to step on anyone's toes).  Does anybody have any requests/advice for
> > > how it should/shouldn't be done?
> > 
> > I *hope* this is just for interfacing with other systems.  Any beguiled
> > program should be using s-expressions for it's config file format. 
> > That's basically the whole point of using Guile, right? ;^)
> 
> Of course.  According to my overinflated ego, XML is just a complete
> pain to parse, to handle and generate. Unfortunately, it *is* becoming
> a standard, if we like it or not, and having no support for it raise
> the barrier for using GUILE (imo). For example people just keep asking
> me about XML file formats and MusicXML support for Lilypond.  Having
> an XML lib in GUILE would make addressing this issue easier.

Yes, I do believe it is necessary.  But it is a pain and it's ugly too.

> BTW, I did read that there were bindings for expat. I don't know which
> of the systems (expat and libxml) makes most sense to use, though. You
> try to find out whether the old bindings still work with recent GUILE
> releases.

I did get expat working at one time.  I'm not sure what changes need to
be made for 1.6.0 Guile.

Something else to consider is ssax: http://ssax.sourceforge.net/

-Dale

-- 
Dale P. Smith
Senior Systems Consultant,      | Treasurer,
Altus Technologies Corporation  | Cleveland Linux Users Group
dsmith@altustech.com            | http://cleveland.lug.net
440-746-9000 x339               |


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

Re: What can I do to help?

[Neil Jerram]

>>>>> "HW" == Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

    HW> BTW, I did read that there were bindings for expat. I don't
    HW> know which of the systems (expat and libxml) makes most sense
    HW> to use, though. You try to find out whether the old bindings
    HW> still work with recent GUILE releases.

Note:

http://www.thbz.org/mixp/
(and the download link isn't broken as I suggested earlier)

http://mixp.sourceforge.net/

http://mail.gnu.org/pipermail/guile-sources/2001-February/000100.html



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

Re: What can I do to help?

[Tom Lord]

    > According to my overinflated ego, XML is just a complete pain to parse

s/overinflated ego/good taste/

s/parse/parse, read, edit, and process with small tools[*]/

And beyond parsing, there's the arbitrary structural restrictions it
makes.

I'm tempted to gripe about the weakness of its type system, but one
thing it has the s-expressions don't is structure sharing with
external resources.  My vague impression is that a lot of the
abstractions they've thought about in that area deserve to be
captured, expressed _as_ abstractions, and recast in (extended) s-exp
form to achieve the best of both worlds.  (But I haven't done that
work, so I can't rule out the possibility that their abstractions
aren't just wrong.)

They also have various type systems on top of XML, too -- where
lispers would generally have more general pattern matching systems;
that looks to me like an XML area ripe for simplicifcation and
generalization.

-t

[*] Yes, DOM, expat, libxml and lots of other standards and libraries
supported by Perl, Python, etc. help disguise/work-around this.



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

Re: What can I do to help?

[Tom Lord]

       > maybe a set of GUILE bindings for libxml or somesuch

How about, instead of adding to the size of guile and the number of
primitive types, a filter program that translates between XML and
s-expressions?

Guile has some degree of SCSH support, already, right?
`run-process/sexp' or the like could be used for reading....

You'd have to handle exit status very carefully to make it robust.

It would also be useful for Emacs and for other Scheme
implementations.

-t


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

Re: What can I do to help?

[Rob Browning]

Tom Lord <lord@regexps.com> writes:

> How about, instead of adding to the size of guile and the number of
> primitive types, a filter program that translates between XML and
> s-expressions?

You won't get any argument from me.

I actually started work on something similar back when gnucash was
planning to switch to a text file format, but I didn't have time to
try anything other than a fairly simple solution in scheme, and for
large files, guile wasn't fast enough.  As a result, gnucash ended up
using libxml.

I still think this is an excellent approach to consider.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: What can I do to help?

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

> I still think this is an excellent approach to consider.

Though of course it's also important to bear in mind that an approach
like "read" might not be acceptable as the only approach.  If you have
a 30MB file, you might want to be able to handle it more
incrementally.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: What can I do to help?

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

> Tom Lord <lord@regexps.com> writes:
>
>> How about, instead of adding to the size of guile and the number of
>> primitive types, a filter program that translates between XML and
>> s-expressions?
>
> You won't get any argument from me.

One thing I did forget to mention that's probably key here, is that
while for some tasks a a trivial XML->sexp conversion might be great,
it isn't all that desirable for others, esp where large files are
concerned.  XML docs are usually organized as one giant tree, and so
if you have a 30MB data file, you may not want to have to convert it
*in-memory* to a giant ??MB sexp just so you can search it to find
some bank deposit (or whatever) on 2002-10-23.

With the libxml approach, you can (painfully) arrange for callbacks so
that you can incrementally parse the document and only capture as much
content as you need.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: What can I do to help?

[Jeff Read]

On Sun, Oct 13, 2002 at 11:50:26AM -0500, Rob Browning wrote:
> 
> One thing I did forget to mention that's probably key here, is that
> while for some tasks a a trivial XML->sexp conversion might be great,
> it isn't all that desirable for others, esp where large files are
> concerned.  XML docs are usually organized as one giant tree, and so
> if you have a 30MB data file, you may not want to have to convert it
> *in-memory* to a giant ??MB sexp just so you can search it to find
> some bank deposit (or whatever) on 2002-10-23.
> 
> With the libxml approach, you can (painfully) arrange for callbacks so
> that you can incrementally parse the document and only capture as much
> content as you need.

My xmlgrok module takes the xml->sexp approach, however, it parses strings and not files. It should be possible to extend it to incrementally parse XML from a stream, extract interesting-looking substrings, and then convert them into sexps.

Thanks for bringing this up; it's an interesting point and gives me some ideas for improvements.

As soon as I get some webspace for xmlgrok I will add it to the projects list.

-- 
Jeffrey T. Read
"I fight not for me but the blind babe Justice!" --Galford


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

Re: What can I do to help?

[Neil Jerram]

>>>>> "William" == William Bland <wjb@abstractnonsense.com> writes:

[gnucash list - pls ignore quote + first paragraph]

    William> On Sat, Sep 28, 2002 at 06:19:34PM +0200, Han-Wen Nienhuys wrote:
    >> 
    >> Don't know about the difficulty, and the actual need of such a
    >> project, but maybe a set of GUILE bindings for libxml or
    >> somesuch -- XML is becoming the standard for storing various
    >> files, and there GUILE doesn't come with any support for
    >> reading or writing it (out-of-the-box, that is).

    William> Sounds like a good idea to me.  Is anyone else working on
    William> this? (don't want to step on anyone's toes).  Does
    William> anybody have any requests/advice for how it
    William> should/shouldn't be done?

I'm pretty sure there are already two implementations of this - the
names `mixp', `guile-expat' and `Thierry Bezecourt' ring bells in my
memory, so you might like to google the web first.  ISTR that most
links for mixp are broken, but that I eventually managed to download a
copy by some semi-obvious modification of the broken URL.
(Unfortunately I don't still have a copy here.)

[gnucash list - the following is relevant]

My suggestion would be to get involved with GnuCash, if that
application area interests you, in particular facilitating the use of
Guile as an extension language for GnuCash.

GnuCash is already a tremendous application, but right now Guile is
really only used by GnuCash as an implementation language.  I think it
has the potential to become a flagship example of how users can extend
Guile-based applications for their own purposes, but currently the
hooks don't exist to allow this.  Or perhaps they do exist, but they
aren't sufficiently convenient to use in practice.

To repeat myself in another way :-) ...  If you follow the GnuCash
mailing lists, you'll see people asking questions like `how can I do
so-and-so to all transactions that such-and-such?'.  IMO, these
questions should be answerable by someone writing and contributing a
piece of Scheme code, just like Emacs Lisp libraries for Emacs.  But,
for whatever reason, this kind of activity isn't happening yet --
instead, all such requests are seen as problems for the core
developers to take on board.

I think that kickstarting this kind of activity would give a huge
boost to both GnuCash and Guile in general.

Best regards,
        Neil



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

Re: What can I do to help?

[Derek Atkins]

This is indeed the main goal behind using guile as an extension
language for GnuCash..  The main hurdle right now is the lack of a
user-created startup file (ala .emacs) that gets loaded at system
startup.  Similarly lacking is a plug-in directory to all the system
to autoload new modules (ala a system-wide '.emacs' ;) I think once
both of those issues are resolved it will be MUCH easier for users to
write gnucash applets.

So, if there is some guile guru who can help me implement the "load
all .scm files in directory <foo>", I'd be happy to listen.

-derek

PS: The next step after solving the autoload hurdle is going to be
wrapping the rest of the C API in scheme.... ;)

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

> My suggestion would be to get involved with GnuCash, if that
> application area interests you, in particular facilitating the use of
> Guile as an extension language for GnuCash.
> 
> GnuCash is already a tremendous application, but right now Guile is
> really only used by GnuCash as an implementation language.  I think it
> has the potential to become a flagship example of how users can extend
> Guile-based applications for their own purposes, but currently the
> hooks don't exist to allow this.  Or perhaps they do exist, but they
> aren't sufficiently convenient to use in practice.
> 
> To repeat myself in another way :-) ...  If you follow the GnuCash
> mailing lists, you'll see people asking questions like `how can I do
> so-and-so to all transactions that such-and-such?'.  IMO, these
> questions should be answerable by someone writing and contributing a
> piece of Scheme code, just like Emacs Lisp libraries for Emacs.  But,
> for whatever reason, this kind of activity isn't happening yet --
> instead, all such requests are seen as problems for the core
> developers to take on board.
> 
> I think that kickstarting this kind of activity would give a huge
> boost to both GnuCash and Guile in general.
> 
> Best regards,
>         Neil
> 
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@lists.gnucash.org
> http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available


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

Re: What can I do to help?

[gnucash]

Derek Atkins wrote:
> This is indeed the main goal behind using guile as an extension
> language for GnuCash..  The main hurdle right now is the lack of a
> user-created startup file (ala .emacs) that gets loaded at system
> startup.  Similarly lacking is a plug-in directory to all the system
> to autoload new modules (ala a system-wide '.emacs' ;) I think once
> both of those issues are resolved it will be MUCH easier for users to
> write gnucash applets.
> 
> So, if there is some guile guru who can help me implement the "load
> all .scm files in directory <foo>", I'd be happy to listen.

Here's something.

;;; To find all .scm files in a directory:

(define (find-scm-files dir)
   (let ((idir (opendir dir))
	 (matcher (make-regexp  ".*\.scm$")))
      (let loop ((files '()))
	 (let ((element (readdir idir)))
	    (if (eof-object? element)
		(begin
		   (closedir idir)
		   files)
		(if (regexp-exec matcher element)
		    (loop (cons element files))
		    (loop files)))))))

;;; To load all the files found using find-scm-files
(define (load-scm-files-from-dir dir)
  (for-each (lambda (file)
	       (load dir "/" file))
	    (find-scm-files dir)))

Note that this does _not_ load them in any special order, which is
almost certainly the /wrong/ thing to do.

The way that Emacs works, which seems entirely appropriate to follow, is
to (require "filename"), which searches a set of pathnames for
"filename.elc" and/or "filename.el".

I would think it almost certain that something analagous to that, which,
as it happens, is /already supported/, is /MUCH/ more appropriate than
"loading all the files in a directory."

What we /already have/ are three relevant functions, and one variable:
 gnc:depend, gnc:support, gnc:load, gnc:*load-path*

(gnc:depend "foo.scm")
  loads foo.scm, using gnc:load, if it has not yet been loaded.

(gnc:support "foo.scm")
  indicates that the present file implements "foo.scm", so that it'll
  "satisfy" a gnc:depend call. 

(gnc:load "foo.scm")
  tries to load foo.scm, and attempts to locate the file in all the
  directories specified by gnc:*load-path*

If you need to add an extra directory, such as ~/.gnucash, throw it into
gnc:*load-path* and "stuff'll work."

Conclusion:  While it's not hard to make a "load all these files"
function, I'd much rather suggest using the existent methods of 
gnc:depend, gnc:support, gnc:load, and gnc:*load-path*.  

Add the home directory to gnc:*load-path*, try to get GnuCash to
(trapped, in case the file isn't there) load some sort of
"gnucash-init.scm" file from that directory, and you've got /everything/
you need.

If a user wants to load-scm-files-from-dir, they can certainly do so,
but I'd suggest that this is not what is /really/ wanted.

The "hook" that is needed is for some reasonably conspicuous part of the
startup process to perform the following:

;;; Start user defined portion of processing...
(define gnc:*load-path* 
   (cons 
       (string-append (getenv "HOME") "/.gnucash") 
       gnc:*load-path*))

(if (file-exists? (string-append (getenv "HOME")
                                 "/.gnucash/customizations.scm"))
    (gnc:load "customizations.scm"))
--
(reverse (concatenate 'string "gro.mca@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/spiritual.html
Signs of a Klingon  Programmer - 5. "Indentation?! -  I will  show you
how to indent when I indent your skull!"


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

Re: What can I do to help?

[Derek Atkins]

gnucash@cbbrowne.com writes:

> I would think it almost certain that something analagous to that, which,
> as it happens, is /already supported/, is /MUCH/ more appropriate than
> "loading all the files in a directory."

Actually, there are reasons for both.  The "load everything in a
directory" is certainly appropriate for, say, adding new reports.  I
think it would be great if all a user (or, say, third party!) had to
do to add a new report was to add the file to some well-known
directory.  This way you don't need to modify any existing files in
order to add new reports.

Similarly, with optional packages, I'd like to be able to plug these
in by having a plugins directory that contains scm files that
minimally contain:

        (gnc:module-load "<this-module>" 0)

This way you don't need to modify main.scm every time you create a
new module (which is hard for third parties).

[snip]
> If you need to add an extra directory, such as ~/.gnucash, throw it into
> gnc:*load-path* and "stuff'll work."

No, it wont.  I still need the hook to call it.  I'd like to see a
world where third parties can supply gnucash plugins that can be
dropped into place without modifying anything in gnucash.

> Conclusion:  While it's not hard to make a "load all these files"
> function, I'd much rather suggest using the existent methods of 
> gnc:depend, gnc:support, gnc:load, and gnc:*load-path*.  

This requires a priori knowledge of what exists.  While this is great
for a .gnucash-init.scm file, or within packages, it is not reasonable
for a plug-in model, IMHO.

> The "hook" that is needed is for some reasonably conspicuous part of the
> startup process to perform the following:
>
> ;;; Start user defined portion of processing...
> (define gnc:*load-path* 
>    (cons 
>        (string-append (getenv "HOME") "/.gnucash") 
>        gnc:*load-path*))
> 
> (if (file-exists? (string-append (getenv "HOME")
>                                  "/.gnucash/customizations.scm"))
>     (gnc:load "customizations.scm"))

Yes, this definitely needs to be in there....

However, I'd like an equivalent to /etc/init.d/rc?.d/* for plugins,
too.

Thanks,

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available


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

Re: What can I do to help?

[Han-Wen Nienhuys]

warlord@MIT.EDU writes:
> 
>         (gnc:module-load "<this-module>" 0)
> 

just by-the-by: is this an official convention, I mean

     prefix:function-name

(just wondering whether I should follow that convention as well.)


--
Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 


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

Re: What can I do to help?

[Derek Atkins]

It is an official GnuCash convention..  I don't know if it is a
guile convention in general.

-derek

Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

> warlord@MIT.EDU writes:
> > 
> >         (gnc:module-load "<this-module>" 0)
> > 
> 
> just by-the-by: is this an official convention, I mean
> 
>      prefix:function-name
> 
> (just wondering whether I should follow that convention as well.)
> 
> 
> --
> Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available


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

Re: What can I do to help?

[Rob Browning]

Derek Atkins <warlord@MIT.EDU> writes:

> It is an official GnuCash convention..  I don't know if it is a
> guile convention in general.

This is definitely only a GnuCash convention.  As far as I recall,
none of the built-in guile functions use this approach, except for the
time tm:* functions, and they appear to be the exception rather than
the rule.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: What can I do to help?

[Rob Browning]

Derek Atkins <warlord@MIT.EDU> writes:

> This way you don't need to modify main.scm every time you create a
> new module (which is hard for third parties).

Emacs has a similar issue (at least in Debian).  Do you enable
tex-site for *all* users, or just for the ones that call

  (require 'tex-site)

?  I'd want to try to find an approach that makes it easy to make
add-ons available, but also provides some way the user can turn them
on/off for themselves.  This "turning-on/off" should be at a high
enough level so that turning it off means most of the modules code
isn't even loaded.  Once you get a large number of modules, especially
if you have some large ones, even the load times can become a
significant expense.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: What can I do to help?

[Neil Jerram]

>>>>> "Derek" == Derek Atkins <warlord@MIT.EDU> writes:

    Derek> [snip]
    >> If you need to add an extra directory, such as ~/.gnucash, throw it into
    >> gnc:*load-path* and "stuff'll work."

    Derek> No, it wont.  I still need the hook to call it.  I'd like to see a
    Derek> world where third parties can supply gnucash plugins that can be
    Derek> dropped into place without modifying anything in gnucash.

From my viewpoint, this is the missing piece of the jigsaw.  I can
load arbitrary Scheme code by putting stuff into config-1.6.user, but
I don't see (except in the case of reports) how to add a keystroke or
menu item that tells GnuCash to `call this function now'.

        Neil

PS. Many thanks for the positive discussion.



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

Re: What can I do to help?

[Rob Browning]

gnucash@cbbrowne.com writes:

> What we /already have/ are three relevant functions, and one variable:
>  gnc:depend, gnc:support, gnc:load, gnc:*load-path*
>
> (gnc:depend "foo.scm")
>   loads foo.scm, using gnc:load, if it has not yet been loaded.
>
> (gnc:support "foo.scm")
>   indicates that the present file implements "foo.scm", so that it'll
>   "satisfy" a gnc:depend call. 
>
> (gnc:load "foo.scm")
>   tries to load foo.scm, and attempts to locate the file in all the
>   directories specified by gnc:*load-path*

Ahh, right.

Though in the long run, I had thought about suggesting that gnucash
drop this stuff in favor of the normal guile module mechanisms.  One
of the main reasons I wrote the depend/support stuff in the first
place was because gnucash wasn't using modules at all.

Although you may be able to make a good argument for preserving some
sort of "separate" gnucash namespace/load-path, though the counter
argument would be that gnucash should just use sub-modules:

  (use-modules (gnucash extension foo))
  (use-modules (gnucash extension bar))
  (use-modules (gnucash extension baz))

or whatever.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: What can I do to help?

[Rob Browning]

Derek Atkins <warlord@MIT.EDU> writes:

> The main hurdle right now is the lack of a user-created startup file
> (ala .emacs) that gets loaded at system startup.

Hmm.  There used to be such a thing, though I don't know if it was
removed during one of the startup reworks.  It used to be that gnucash
created ~/gnucash/, and would save any user customizations to
~/.gnucash/auto, but if you created a ~/.gnucash/user ("user" might be
the wrong name), then that file would take precedence and be loaded
instead of the auto file.

The normal thing to do in ~/.gnucash/user would be to make any
customizations you wanted and load the "auto" file.  Depending on your
needs, you might load the auto file before your customizations, after,
or not at all.

> Similarly lacking is a plug-in directory to all the system to
> autoload new modules (ala a system-wide '.emacs' ;) I think once
> both of those issues are resolved it will be MUCH easier for users
> to write gnucash applets.

As a short-term solution, you could just require users to add a

  (use-modules (some-add-on))
  (some-add-on-init)

to their .gnucash/user file.  Add-on's would be placed in the normal
gnucash guile module dir.

You could also arrange a convention for the above two calls, and add a
gui for selecting modules.  When one is selected, lines like the above
are placed in the ./gnucash/auto file.

This might in fact be better than universally enabling all the modules
on the system for all users, though you can get the same effect if
modules by-default do nothing when loaded (if appropriate) until
"turned on" somehow in a given user's config.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: What can I do to help?

[Martin Grabmueller]

> From: Neil Jerram <neil@ossau.uklinux.net>
> Date: 30 Sep 2002 19:38:36 +0100
> 
> >>>>> "William" == William Bland <wjb@abstractnonsense.com> writes:
> 
>     William> On Sat, Sep 28, 2002 at 06:19:34PM +0200, Han-Wen Nienhuys wrote:
>     >> 
>     >> Don't know about the difficulty, and the actual need of such a
>     >> project, but maybe a set of GUILE bindings for libxml or
>     >> somesuch -- XML is becoming the standard for storing various
>     >> files, and there GUILE doesn't come with any support for
>     >> reading or writing it (out-of-the-box, that is).
> 
>     William> Sounds like a good idea to me.  Is anyone else working on
>     William> this? (don't want to step on anyone's toes).  Does
>     William> anybody have any requests/advice for how it
>     William> should/shouldn't be done?
> 
> I'm pretty sure there are already two implementations of this - the
> names `mixp', `guile-expat' and `Thierry Bezecourt' ring bells in my
> memory, so you might like to google the web first.  ISTR that most
> links for mixp are broken, but that I eventually managed to download a
> copy by some semi-obvious modification of the broken URL.
> (Unfortunately I don't still have a copy here.)

guile-expat was written by me [1], but I stopped working on it because
I looked into mixp and it looked better.  Nevertheless, guile-expat
works (at least with the version of expat I was using -- can't
remember which), and could be interesting to people who want to learn
about wrapping external libraries for Guile use.

But maybe looking into Gnucash or AbiWord would be more useful.

Happy Guiling,
  'martin

[1] http://www.pintus.de/mgrabmue/guile/guile.html#modules


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

Re: What can I do to help?

[Rob Browning]

Dr William Bland <wjb@abstractnonsense.com> writes:

> If anyone has any comments on these, or suggestions for others that may be
> more important / easier for a guile newbie / etc. I'd be very
> interested in hearing them.

Actually, as I recall, Jim Blandy had an interesting "wish list" a
long while back, but I can't find it anymore.  You might also want to
look at workbook/tasks/TODO from cvs.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: What can I do to help?

[Neil Jerram]

>>>>> "Rob" == Rob Browning <rlb@defaultvalue.org> writes:

    Rob> Dr William Bland <wjb@abstractnonsense.com> writes:
    >> If anyone has any comments on these, or suggestions for others that may be
    >> more important / easier for a guile newbie / etc. I'd be very
    >> interested in hearing them.

    Rob> Actually, as I recall, Jim Blandy had an interesting "wish
    Rob> list" a long while back, but I can't find it anymore.  You
    Rob> might also want to look at workbook/tasks/TODO from cvs.

Yes, but it's very out of date - so please check before starting work
on any of the items on there.

        Neil



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

Re: What can I do to help? (conclusions)

[Dr William Bland]

Thanks to everyone who replied to my original post.  Lots of good ideas
here.

I took a look at Jim Blandy's list, and guile/workbook/tasks/TODO, but
everything either looks too hard or doesn't interest me enough.

I've kind of gone off the idea of doing libxml bindings since most guile
people don't like xml much.  It may be something I return to in the future
however.  If anyone thinks libxml bindings are sufficiently important,
please feel free to try to convince me ;-)

GnuCash sounds pretty interesting, but I'm afraid I wouldn't be much
help.  I don't use GnuCash at all (or any program like it) and I don't
know anything about finance or accounting.

I'm swaying back towards the idea of scripting Abiword with guile, since I
use Abiword quite a bit and I can think of lots of neat things that guile
scripts could do there.

If anyone wants to try to talk me out of it though, I'm still open to
comments ;-)

Thanks again for all the suggestions.
Best wishes,
		Bill.


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

Re: What can I do to help? (conclusions)

[Neil Jerram]

>>>>> "William" == William Bland <wjb@abstractnonsense.com> writes:

    William> I'm swaying back towards the idea of scripting Abiword
    William> with guile, since I use Abiword quite a bit and I can
    William> think of lots of neat things that guile scripts could do
    William> there.

    William> If anyone wants to try to talk me out of it though, I'm
    William> still open to comments ;-)

Despite suggesting GnuCash, I would say that any work that is based in
real needs will contributing to enriching the Guile world.  And if you
don't mind thinking about how your work can be generalized and
modularized for purposes beyond Abiword specifically, it will almost
certainly benefit other applications in the end anyway.

So, best wishes!  I'll take a look at Abiword so that I can play with
your scripting when it is available.

        Neil



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

Re: What can I do to help? (conclusions)

[Evan Prodromou]

>>>>> "WB" == William Bland <wjb@abstractnonsense.com> writes:

    WB> If anyone wants to try to talk me out of it though, I'm still
    WB> open to comments ;-)

Dr. Bland,

It's absolutely criminal that you could come and ask for a job to do
and get turned away. There is so, so, so much to do. Shame on us!

I think there are a ton of projects that need to be done for Guile
that are not yet done. For example:

    * A SAX2 parser GOOPS interface and drivers for libxml, expat,
      xerces, etc.  (Whoever told you not to make it easy for Guile
      developers to use XML is a bonehead, by the way. XML will never
      be s-expressions, but that doesn't mean that using it isn't
      important!)

    * A DOM library for GOOPS. I've got one just about done, but not
      quite yet.

    * A module for using zlib, with a special mechanism for
      transparent compression on ports

    * A module for gdbm and/or Berkeley DB, with a mechanism for
      transparent storage
      
    * GUMM (talk to thi about this)

    * Modularization of many of the Guile built-ins (there's just too
      too many! This is, by the way, crappy grunt work, which is why
      the main developers should be shoveling it off on people like
      you and me B-))

    * Guile SOAP bindings (using guile-www as HTTP carrier)

    * URL parser module (string -> (protocol, server, path, fragment))

    * HTML parser module

    * GPG-ME bindings (see http://www.gnupg.org/ for details)

    * SMTP and POP3 modules
    
    * An NNTP module

    * An FTP module

    * Gnutella network module

    * Jabber module (sure would need XML there)

    * An interface meta-class for GOOPS. (Yes, I know interfaces
      aren't CLOS-y. Yes, they're still useful)

    * Drivers for guile-simplesql (http://guile-simplesql.sf.net/),
      esp. for commercial RDBMSes like Oracle.

    * An interface from Guile to a comprehensive image management
      library like ImageMagick

    * A library of simple AI tools, such as logic programming, fuzzy
      logic, planners, etc. 

Just for giggles, try comparing the Guile projects list:

         http://www.glug.org/projects/

...to CPAN:

         http://www.perl.com/CPAN/modules/by-category/

...or the Vaults of Parnassus (Python modules):

         http://www.vex.net/parnassus/

...or the Ruby Application Archive:

         http://www.ruby-lang.org/en/raa.html

There's a ton of stuff up there that have no equivalent in Guile. We
need to make those. 

I think in general it should be a goal to have Guile modules that wrap
_all_ the libraries on ftp.gnu.org. Another is to have modules for all
major Internet protocols. That should keep us all busy for the next
two years. B-)

~ESP

-- 
Evan Prodromou
evan@prodromou.san-francisco.ca.us



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

Re: What can I do to help? (conclusions)

[Andreas Rottmann]

Evan Prodromou <evan@prodromou.san-francisco.ca.us> writes:

>     * Drivers for guile-simplesql (http://guile-simplesql.sf.net/),
>       esp. for commercial RDBMSes like Oracle.
> 
I wanna jump in here and to point out that soon (in the next few
weeks) there will be releases of GQL (gql.sourceforge.net) and Yehia
(ucxx.sf.net) that provide Guile bindings to GQL, thus bringing a new,
object-oriented general SQL interface to Guile.

Regards, Andy
-- 
Andreas Rottmann         | Dru@ICQ        | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/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: What can I do to help? (conclusions)

[Clinton Ebadi]

On Thursday 03 October 2002 13:14, Evan Prodromou wrote:
>     * A module for gdbm and/or Berkeley DB, with a mechanism for
>       transparent storage

I thought this already existed somewhere? If it does (I think it does) it 
doesn't work and needs to be fixed anyway.

>     * Guile SOAP bindings (using guile-www as HTTP carrier)

I think Guile needs CORBA and DCOP bindings first. Almost now Free Software 
uses SOAP, so there is no real reason to support it. On the other hand, CORBA 
would help greatly with working with GNOME programs, and DCOP would enable 
the use of Guile to script KDE apps using their DCOP interfaces.

>     * URL parser module (string -> (protocol, server, path, fragment))

guile-www has this in the (www url) module.

> I think in general it should be a goal to have Guile modules that wrap
> _all_ the libraries on ftp.gnu.org. Another is to have modules for all
> major Internet protocols. That should keep us all busy for the next
> two years. B-)

A good idea would be to work on SWIG (http://www.swig.org) to make it not use 
GH anymore, do automatic garbage collection of wrapped objections (now you 
have to use two procedures SWIG adds, new and delete, and it doesn't GC any 
SWIG object...), and support GOOPS shadow classes for C++. Making SWIG 
objects GC-able would be really great (unless it was already fixed in the 
last release, I know two releases ago it wasn't). If SWIG used GOOPS shadow 
classes and generic procedures, it would be much nicer to use too. Then a 
large number of libraries could very easily be wrapped without much trouble 
(usually just modifying the header file of the library slightly makes it 
usable with SWIG).

-- 
http://unknownlamer.org
Truth lies in loneliness
When hope is long gone by


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

Re: What can I do to help? (conclusions)

[Dale P. Smith]

On Thu, 03 Oct 2002 13:14:27 -0400
Evan Prodromou <evan@prodromou.san-francisco.ca.us> wrote:

> >>>>> "WB" == William Bland <wjb@abstractnonsense.com> writes:
> 
>     WB> If anyone wants to try to talk me out of it though, I'm still
>     WB> open to comments ;-)
> 
> Dr. Bland,
> 
> It's absolutely criminal that you could come and ask for a job to do
> and get turned away. There is so, so, so much to do. Shame on us!
> 
> I think there are a ton of projects that need to be done for Guile
> that are not yet done. For example:
> 
>     * A SAX2 parser GOOPS interface and drivers for libxml, expat,
>       xerces, etc.  (Whoever told you not to make it easy for Guile
>       developers to use XML is a bonehead, by the way. XML will never
>       be s-expressions, but that doesn't mean that using it isn't
>       important!)

That must have been me.  Yes, I'm a bonehead a lot.  Sorry.

I had visions of Guile using xml as a doc format (and other horrors) and
responded without really reading your message.

Being able to interface with other systems using xml is a good thing and
needs to be done.  There is this stuff called soap that uses xml for
rpc's (iirc).

-Dale

-- 
Dale P. Smith
Senior Systems Consultant,      | Treasurer,
Altus Technologies Corporation  | Cleveland Linux Users Group
dsmith@altustech.com            | http://cleveland.lug.net
440-746-9000 x339               |


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

Re: What can I do to help? (conclusions)

[rm]

On Fri, Oct 04, 2002 at 08:26:05AM -0400, Dale P. Smith wrote:
> > It's absolutely criminal that you could come and ask for a job to do
> > and get turned away. There is so, so, so much to do. Shame on us!
> > 
> > I think there are a ton of projects that need to be done for Guile
> > that are not yet done. For example:
> > 
> >     * A SAX2 parser GOOPS interface and drivers for libxml, expat,
> >       xerces, etc.  (Whoever told you not to make it easy for Guile
> >       developers to use XML is a bonehead, by the way. XML will never
> >       be s-expressions, but that doesn't mean that using it isn't
> >       important!)
> 
> That must have been me.  Yes, I'm a bonehead a lot.  Sorry.

No, you're not! Let's not talk about libxml-bindings for a moment
(more on that in a later mail) -- the problem with the above mentioned
things is simply: there's (almost) no documentation on how to do it.
Yes, a GOOPS-ish guile-libxml would be great, but there _is_ currently
no C goops interface. Throwing such a task at a newcomer is "absolute
criminal" :-) Oh, and i guess we shouldn't forget that libxml has several
dozent functions and about two handfull of smobable objects (and a pretty
tricky memory concept when it comes to guile bindings, if i might add).
I agree on the comments on XMLs boneheadedness ;-)

> I had visions of Guile using xml as a doc format (and other horrors) and
> responded without really reading your message.
> 
> Being able to interface with other systems using xml is a good thing and
> needs to be done.  There is this stuff called soap that uses xml for
> rpc's (iirc).

Yes, considering the fact that xml seems to be GNOMEs configuration format
and the fact that many modern document formats are XML languages bindings
are important (SVG, XSL-FO, MS-Office, StarOffice, etc.).
For SOAP use i'd suggest a binding to one of the exisiting SOAP libraries,
it just doesn't pay of to deal with SOAP on the XML level.

  - Ralf 
> -Dale
> 
> -- 
> Dale P. Smith
> Senior Systems Consultant,      | Treasurer,
> Altus Technologies Corporation  | Cleveland Linux Users Group
> dsmith@altustech.com            | http://cleveland.lug.net
> 440-746-9000 x339               |
> 
> 
> _______________________________________________
> Guile-devel mailing list
> Guile-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/guile-devel


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

Re: What can I do to help? (conclusions)

[Andreas Rottmann]

rm@fabula.de writes:

> On Fri, Oct 04, 2002 at 08:26:05AM -0400, Dale P. Smith wrote:
> > > It's absolutely criminal that you could come and ask for a job to do
> > > and get turned away. There is so, so, so much to do. Shame on us!
> > > 
> > > I think there are a ton of projects that need to be done for Guile
> > > that are not yet done. For example:
> > > 
> > >     * A SAX2 parser GOOPS interface and drivers for libxml, expat,
> > >       xerces, etc.  (Whoever told you not to make it easy for Guile
> > >       developers to use XML is a bonehead, by the way. XML will never
> > >       be s-expressions, but that doesn't mean that using it isn't
> > >       important!)
> > 
> > That must have been me.  Yes, I'm a bonehead a lot.  Sorry.
> 
> No, you're not! Let's not talk about libxml-bindings for a moment
> (more on that in a later mail) -- the problem with the above mentioned
> things is simply: there's (almost) no documentation on how to do it.
> Yes, a GOOPS-ish guile-libxml would be great, but there _is_ currently
> no C goops interface. 
>
I always wonder why people say that... There is a goops.h, which
declares basically all the functions you need. Well, you could build
some higher-level/easier-to-use functions on top of them, and in some
areas there are no 'clean' bindings so you have to do a bit of
hackery, but I managed to implement a C++ interface to GOOPS - so it
*is* possible. It took me some hours of poking around in goops.c,
since the stuff is not really documented.

> Throwing such a task at a newcomer is "absolute
> criminal" :-) Oh, and i guess we shouldn't forget that libxml has several
> dozent functions and about two handfull of smobable objects (and a pretty
> tricky memory concept when it comes to guile bindings, if i might add).
> I agree on the comments on XMLs boneheadedness ;-)
> 
Hmm, you begin to provoke my interest. Maybe after my C++ interface is
mature enough (should be in a few weeks), I might give it a shot,
however, it would help me a lot to get going how you imagine the
interface to look like.

Talking about C++, I suggest adding configure flag that causes the
Guile interpreter to be linked by g++, so modules can be implemented
in C++. (Python, on Debian, for example is linked this way).

> > I had visions of Guile using xml as a doc format (and other horrors) and
> > responded without really reading your message.
> > 
> > Being able to interface with other systems using xml is a good thing and
> > needs to be done.  There is this stuff called soap that uses xml for
> > rpc's (iirc).
> 
> Yes, considering the fact that xml seems to be GNOMEs configuration format
> and the fact that many modern document formats are XML languages bindings
> are important (SVG, XSL-FO, MS-Office, StarOffice, etc.).
> 
I fully agree here, XML bindings are important.

Andy
-- 
Andreas Rottmann         | Dru@ICQ        | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/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: What can I do to help? (conclusions)

[rm]

On Fri, Oct 04, 2002 at 06:14:29PM +0200, Andreas Rottmann wrote:
> rm@fabula.de writes:
>  [...]
> > Yes, a GOOPS-ish guile-libxml would be great, but there _is_ currently
> > no C goops interface. 
> >
> I always wonder why people say that... There is a goops.h, which
> declares basically all the functions you need. i

I never said it wouldn'T be possible to write bindings that use goops --
as far as i understand there are no official (read: stable ) APIs, and
the last thing i want to do is to manually craft bindings that stop working
after the next major (minor?) version change. A while ago i really wanted
to use SCWM, but unfortunately the program used some carefully handcrafted
code to catch exceptions (see some of the recent posts in this mailing list)
that worked fine in the version of Guile it was designed for but broke 
misserably on my newer version. I'd be willing to do such work if unavoidable
but i would not want to write bindings for a monster like libxml2 unless
i know it's going to be there for a while ;-)

> Well, you could build
> some higher-level/easier-to-use functions on top of them, and in some
> areas there are no 'clean' bindings so you have to do a bit of
> hackery, but I managed to implement a C++ interface to GOOPS - so it
> *is* possible. It took me some hours of poking around in goops.c,
> since the stuff is not really documented.
> 
>> [...]
> Hmm, you begin to provoke my interest. Maybe after my C++ interface is
> mature enough (should be in a few weeks), I might give it a shot,
> however, it would help me a lot to get going how you imagine the
> interface to look like.

Well, i have one sitting on my box, but am reluctant to publish it 
because a) it's handcrafted (-> lot's of duplicated code and still  a
lot is missing) b) i don't like the API ... i find with such an important
lib it's of utter importance to find a 'natural' way of integrating 
XML into Scheme/Guile (i'm pretty impressed by Oleg's work) -- also,
i'm using Daniel Veillard's Python bindings daily (i have to, i'm affraid)
and i'm very unhappy with the way they feel (too C-ish). 
I envision to follow Daniel's path in auto-creating the bindings from the
exisiting API description in XML format.

> Talking about C++, I suggest adding configure flag that causes the
> Guile interpreter to be linked by g++, so modules can be implemented
> in C++. (Python, on Debian, for example is linked this way).

Hmmm, what are the consequences in terms of code emitted -- doesn't that
result in (horrible) stuff like symbol name mangling ?

 Ralf Mattes


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

Re: What can I do to help? (conclusions)

[Andreas Rottmann]

rm@fabula.de writes:

> On Fri, Oct 04, 2002 at 06:14:29PM +0200, Andreas Rottmann wrote:
> > Talking about C++, I suggest adding configure flag that causes the
> > Guile interpreter to be linked by g++, so modules can be implemented
> > in C++. (Python, on Debian, for example is linked this way).
> 
> Hmmm, what are the consequences in terms of code emitted -- doesn't that
> result in (horrible) stuff like symbol name mangling ?
> 
No, you don't compile using C++, just use g++ for the linking
stage. This way the executable will be linked against libstdc++, but
there should be no other user-visible effects except that C++ modules
will work.

Andy
-- 
Andreas Rottmann         | Dru@ICQ        | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/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: What can I do to help? (conclusions)

[Marius Vollmer]

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

> No, you don't compile using C++, just use g++ for the linking
> stage. This way the executable will be linked against libstdc++, but
> there should be no other user-visible effects except that C++ modules
> will work.

In my experience, you don't need to do that on GNU/Linux but you need
to on Solaris.  Does that match your experience?

In any case: do you have a patch?  We might even link with g++ by
default when it is available.

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


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

Re: What can I do to help? (conclusions)

[Rob Browning]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> In my experience, you don't need to do that on GNU/Linux but you need
> to on Solaris.  Does that match your experience?
>
> In any case: do you have a patch?  We might even link with g++ by
> default when it is available.

What actual differences are there when linking with g++ instead of
gcc?  For example, will it affect the size or performance of the
resulting binaries much?

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: What can I do to help? (conclusions)

[Andreas Rottmann]

Rob Browning <rlb@defaultvalue.org> writes:

> Marius Vollmer <mvo@zagadka.ping.de> writes:
> 
> > In my experience, you don't need to do that on GNU/Linux but you need
> > to on Solaris.  Does that match your experience?
> >
> > In any case: do you have a patch?  We might even link with g++ by
> > default when it is available.
> 
> What actual differences are there when linking with g++ instead of
> gcc?  For example, will it affect the size or performance of the
> resulting binaries much?
> 
I don't think so, nevertheless the resulting binary will be linked
against libstdc++. However, when I get guile working again (see my
other mail, subject "CVS Build problems"), I will suplly a patch and
can run some benchmarks (there are some, don't we?), if you'd like.

Andi
-- 
Andreas Rottmann         | Dru@ICQ        | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/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: What can I do to help? (conclusions)

[Andreas Rottmann]

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

> Rob Browning <rlb@defaultvalue.org> writes:
> 
> > Marius Vollmer <mvo@zagadka.ping.de> writes:
> > 
> > > In my experience, you don't need to do that on GNU/Linux but you need
> > > to on Solaris.  Does that match your experience?
> > >
> > > In any case: do you have a patch?  We might even link with g++ by
> > > default when it is available.
> > 
> > What actual differences are there when linking with g++ instead of
> > gcc?  For example, will it affect the size or performance of the
> > resulting binaries much?
> > 
> I don't think so, nevertheless the resulting binary will be linked
> against libstdc++. However, when I get guile working again (see my
> other mail, subject "CVS Build problems"), I will suplly a patch and
> can run some benchmarks (there are some, don't we?), if you'd like.
> 
s/don't we/ain't there/

Andy
-- 
Andreas Rottmann         | Dru@ICQ        | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/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: What can I do to help? (conclusions)

[Rob Browning]

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

> I don't think so, nevertheless the resulting binary will be linked
> against libstdc++. However, when I get guile working again (see my
> other mail, subject "CVS Build problems"), I will suplly a patch and
> can run some benchmarks (there are some, don't we?), if you'd like.

What would that do to our "minimal install size"?  We use guile in
situations where we need to keep things fairly small (aside from
guile), and if I'm not misreading, this would make guile depend (on a
debian system at least) on libstdc++5 which itself is 700K, and
sub-depends on: gcc-3.2-base, libc6 (>= 2.2.5-13), libgcc1 (>=
1:3.2-0pre4).

The benefit may outweigh the cost, but I'd like to make sure we have a
clear idea of the costs and benefits.

What would the alternative be for people using C++ if we *don't* link
with g++?  Is it still possible for them to write modules?  Would they
have to write an "interface stub file" or something using extern "C"
or similar?

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: What can I do to help? (conclusions)

[Andreas Rottmann]

Rob Browning <rlb@defaultvalue.org> writes:

> Andreas Rottmann <a.rottmann@gmx.at> writes:
> 
> > I don't think so, nevertheless the resulting binary will be linked
> > against libstdc++. However, when I get guile working again (see my
> > other mail, subject "CVS Build problems"), I will suplly a patch and
> > can run some benchmarks (there are some, don't we?), if you'd like.
> 
> What would that do to our "minimal install size"?  We use guile in
> situations where we need to keep things fairly small (aside from
> guile), and if I'm not misreading, this would make guile depend (on a
> debian system at least) on libstdc++5 which itself is 700K, and
> sub-depends on: gcc-3.2-base, libc6 (>= 2.2.5-13), libgcc1 (>=
> 1:3.2-0pre4).
> 
Yes, that's a clear disadvantage. However, in what environments does
that requirement exist? If you have a configure option, you can decide
both ways. There could even be a debian package 'guile' (with a C
linked executable) and a 'guile-c++' one, linked with g++, replacing
'guile' (or the other way round with a c++-linked guile as
default). Then C++ plugins could depend on guile-c++. However, I get
too much into debian pkg management now, I guess *waves to Rob*.

> The benefit may outweigh the cost, but I'd like to make sure we have a
> clear idea of the costs and benefits.
> 
Sure.

> What would the alternative be for people using C++ if we *don't* link
> with g++?  Is it still possible for them to write modules?  Would they
> have to write an "interface stub file" or something using extern "C"
> or similar?
> 
It is not possible to load this plugins with some C++ constructs
(e.g. exceptions, don't know the full list), since guile
crashes. However, if you embed guile in your C++ program, there is no
problem, since the executable is linked with g++.

Regards, Andy
-- 
Andreas Rottmann         | Dru@ICQ        | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/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: What can I do to help? (conclusions)

[Rob Browning]

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

> Yes, that's a clear disadvantage. However, in what environments does
> that requirement exist? If you have a configure option, you can decide
> both ways. There could even be a debian package 'guile' (with a C
> linked executable) and a 'guile-c++' one, linked with g++, replacing
> 'guile' (or the other way round with a c++-linked guile as
> default). Then C++ plugins could depend on guile-c++. However, I get
> too much into debian pkg management now, I guess *waves to Rob*.

I think this might be possible, but if it meant that not only guile,
but every lib and app that was linked against guile would have to be
packaged two ways, then it's probably not feasible.

> It is not possible to load this plugins with some C++ constructs
> (e.g. exceptions, don't know the full list), since guile
> crashes.

Are we talking about guile functions calling c++ functions, or c++
functions calling guile functions here, and are we talking about the
c++ code being accessed via guile loaded (dynamic-link)ed shared
libraries or via direct linking/loadinga?

Also is there a description of the problem available anywhere? i.e. in
the case of exceptions where c code is calling c++ code, is it a
problem if the c++ code throws an exception at all, or only if it
tries to throw one up to the c level.  If the latter, then can the c++
code just be required to have a catch-all "catch" at the top-level in
all of the functions guile will be calling?

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: What can I do to help? (conclusions)

[Andreas Rottmann]

Rob Browning <rlb@defaultvalue.org> writes:

> Andreas Rottmann <a.rottmann@gmx.at> writes:
> 
> > Yes, that's a clear disadvantage. However, in what environments does
> > that requirement exist? If you have a configure option, you can decide
> > both ways. There could even be a debian package 'guile' (with a C
> > linked executable) and a 'guile-c++' one, linked with g++, replacing
> > 'guile' (or the other way round with a c++-linked guile as
> > default). Then C++ plugins could depend on guile-c++. However, I get
> > too much into debian pkg management now, I guess *waves to Rob*.
> 
> I think this might be possible, but if it meant that not only guile,
> but every lib and app that was linked against guile would have to be
> packaged two ways, then it's probably not feasible.
> 
It's just about the main program (executable). Libs and thus modules
won't be affected. Apps can decide wether they want to support guile
modules written in C++ (and be linked appropriatly).

> > It is not possible to load this plugins with some C++ constructs
> > (e.g. exceptions, don't know the full list), since guile
> > crashes.
> 
> Are we talking about guile functions calling c++ functions, or c++
> functions calling guile functions here, and are we talking about the
> c++ code being accessed via guile loaded (dynamic-link)ed shared
> libraries or via direct linking/loadinga?
> 
c++ code being loaded into guile dynamically (i.e. shared libs).

> Also is there a description of the problem available anywhere? i.e. in
> the case of exceptions where c code is calling c++ code, is it a
> problem if the c++ code throws an exception at all, or only if it
> tries to throw one up to the c level.  If the latter, then can the c++
> code just be required to have a catch-all "catch" at the top-level in
> all of the functions guile will be calling?
> 
Sorry, there is no definite explanation (at least i didn't find
one). However, I'm going to investigate this more. It seems it may
have to do with most C++ shared libs ending up being linked by gcc
instead of g++ (due to a libtool bug).

Regards, Andy
-- 
Andreas Rottmann         | Dru@ICQ        | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/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: What can I do to help? (conclusions)

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> What actual differences are there when linking with g++ instead of
> gcc?  For example, will it affect the size or performance of the
> resulting binaries much?

I don't know for sure, but the startup code might be affected, for
example.

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


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

Re: What can I do to help? (conclusions)

[Andreas Rottmann]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> Andreas Rottmann <a.rottmann@gmx.at> writes:
> 
> > No, you don't compile using C++, just use g++ for the linking
> > stage. This way the executable will be linked against libstdc++, but
> > there should be no other user-visible effects except that C++ modules
> > will work.
> 
> In my experience, you don't need to do that on GNU/Linux but you need
> to on Solaris.  Does that match your experience?
> 
No, you have to link with C++ on both platforms, otherwise things like
exceptions won't work/crash, AFAIR.

> In any case: do you have a patch?  We might even link with g++ by
> default when it is available.
> 
I'll supply one, but currently guile CVS is fucked:

make[2]: Entering directory `/home/andy/src/foreign/guile/guile-core/libguile-ltdl'
source='guile-ltdl.c' object='guile-ltdl.lo' libtool=yes \
depfile='.deps/guile-ltdl.Plo' tmpdepfile='.deps/guile-ltdl.TPlo' \
depmode=gcc /bin/sh ../depcomp \
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../libguile -I.. -I./..    -g -O2 -Wall -Wmissing-prototypes -c -o guile-ltdl.lo `test -f 'guile-ltdl.c' || echo './'`guile-ltdl.c
gcc -DHAVE_CONFIG_H -I. -I. -I../libguile -I.. -I./.. -g -O2 -Wall -Wmissing-prototypes -c guile-ltdl.c -Wp,-MD,.deps/guile-ltdl.TPlo  -fPIC -DPIC -o guile-ltdl.lo
In file included from guile-ltdl.c:43:
raw-ltdl.c:245: warning: `strchr' redefined
/usr/include/bits/string2.h:391: warning: this is the location of the previous definition
In file included from guile-ltdl.c:43:
raw-ltdl.c:417: parse error before `rpl_argz_append'
raw-ltdl.c:418: warning: type defaults to `int' in declaration of `rpl_argz_append'
raw-ltdl.c:418: warning: data definition has no type or storage class
raw-ltdl.c:421: parse error before `rpl_argz_append'
raw-ltdl.c:422: warning: return-type defaults to `int'
raw-ltdl.c: In function `rpl_argz_append':
raw-ltdl.c:442: `ENOMEM' undeclared (first use in this function)
raw-ltdl.c:442: (Each undeclared identifier is reported only once
raw-ltdl.c:442: for each function it appears in.)
raw-ltdl.c: At top level:
raw-ltdl.c:459: parse error before `rpl_argz_create_sep'
raw-ltdl.c:460: warning: type defaults to `int' in declaration of `rpl_argz_create_sep'
raw-ltdl.c:460: warning: data definition has no type or storage class
raw-ltdl.c:463: parse error before `rpl_argz_create_sep'
raw-ltdl.c:464: warning: return-type defaults to `int'
raw-ltdl.c: In function `rpl_argz_create_sep':
raw-ltdl.c:486: `ENOMEM' undeclared (first use in this function)
raw-ltdl.c: At top level:
raw-ltdl.c:522: parse error before `rpl_argz_insert'
raw-ltdl.c:523: warning: type defaults to `int' in declaration of `rpl_argz_insert'
raw-ltdl.c:523: warning: data definition has no type or storage class
raw-ltdl.c:526: parse error before `rpl_argz_insert'
raw-ltdl.c:527: warning: return-type defaults to `int'
raw-ltdl.c: In function `rpl_argz_insert':
raw-ltdl.c:559: `ENOMEM' undeclared (first use in this function)
raw-ltdl.c: At top level:
raw-ltdl.c:719: `LTDL_OBJDIR' undeclared here (not in a function)
raw-ltdl.c:1666: parse error before `*'
raw-ltdl.c:1668: warning: type defaults to `int' in declaration of `find_file'
raw-ltdl.c:1668: warning: data definition has no type or storage class
raw-ltdl.c: In function `tryall_dlopen_module':
raw-ltdl.c:1977: warning: implicit declaration of function `sprintf'
raw-ltdl.c: In function `argzize_path':
raw-ltdl.c:2112: `error_t' undeclared (first use in this function)
raw-ltdl.c:2112: parse error before `error'
raw-ltdl.c:2118: `error' undeclared (first use in this function)
raw-ltdl.c:2122: `ENOMEM' undeclared (first use in this function)
raw-ltdl.c:2123: warning: unreachable code at beginning of switch statement
raw-ltdl.c: In function `find_file_callback':
raw-ltdl.c:2220: `FILE' undeclared (first use in this function)
raw-ltdl.c:2220: `pfile' undeclared (first use in this function)
raw-ltdl.c:2220: parse error before `)'
raw-ltdl.c:2227: warning: implicit declaration of function `fopen'
raw-ltdl.c:2229: warning: initialization discards qualifiers from pointer target type
raw-ltdl.c: At top level:
raw-ltdl.c:2242: parse error before `*'
raw-ltdl.c:2244: warning: return-type defaults to `int'
raw-ltdl.c: In function `find_file':
raw-ltdl.c:2248: `FILE' undeclared (first use in this function)
raw-ltdl.c:2248: `file' undeclared (first use in this function)
raw-ltdl.c:2253: warning: control reaches end of non-void function
raw-ltdl.c: In function `try_dlopen':
raw-ltdl.c:2576: warning: assignment discards qualifiers from pointer target type
raw-ltdl.c:2603: `FILE' undeclared (first use in this function)
raw-ltdl.c:2603: `file' undeclared (first use in this function)
raw-ltdl.c:2604: parse error before `char'
raw-ltdl.c:2626: `i' undeclared (first use in this function)
raw-ltdl.c:2628: warning: implicit declaration of function `isalnum'
raw-ltdl.c:2689: `line_len' undeclared (first use in this function)
raw-ltdl.c:2690: `line' undeclared (first use in this function)
raw-ltdl.c:2693: warning: implicit declaration of function `fclose'
raw-ltdl.c:2699: warning: implicit declaration of function `feof'
raw-ltdl.c:2701: warning: implicit declaration of function `fgets'
raw-ltdl.c:2727: `dlname' undeclared (first use in this function)
raw-ltdl.c:2735: `old_name' undeclared (first use in this function)
raw-ltdl.c:2741: `libdir' undeclared (first use in this function)
raw-ltdl.c:2749: `deplibs' undeclared (first use in this function)
raw-ltdl.c:2753: `installed' undeclared (first use in this function)
raw-ltdl.c:2769: warning: assignment discards qualifiers from pointer target type
raw-ltdl.c: In function `lt_dlopenext':
raw-ltdl.c:2945: warning: assignment discards qualifiers from pointer target type
raw-ltdl.c: In function `lt_argz_insert':
raw-ltdl.c:3021: `error_t' undeclared (first use in this function)
raw-ltdl.c:3021: parse error before `error'
raw-ltdl.c:3023: `error' undeclared (first use in this function)
raw-ltdl.c:3027: `ENOMEM' undeclared (first use in this function)
raw-ltdl.c:3028: warning: unreachable code at beginning of switch statement
make[2]: *** [guile-ltdl.lo] Error 1
make[2]: Leaving directory `/home/andy/src/foreign/guile/guile-core/libguile-ltdl'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/andy/src/foreign/guile/guile-core/libguile-ltdl'
make: *** [all-recursive] Error 1
make: Leaving directory `/home/andy/src/foreign/guile/guile-core'

Regards, Andy
-- 
Andreas Rottmann         | Dru@ICQ        | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/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: What can I do to help? (conclusions)

[Marius Vollmer]

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

> No, you have to link with C++ on both platforms, otherwise things like
> exceptions won't work/crash, AFAIR.

Ok.

> In file included from guile-ltdl.c:43:
> raw-ltdl.c:245: warning: `strchr' redefined

I've seen this, too.  Run "cvs update" so that you have the latest
autogen.sh, then run "./autogen.sh".  Previously, scmconfig.h.in
wouldn't always be updated.

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


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

Guile CVS Build Problems (was: Re: What can I do to help? (conclusions))

[Andreas Rottmann]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> Andreas Rottmann <a.rottmann@gmx.at> writes:
> 
> > No, you have to link with C++ on both platforms, otherwise things like
> > exceptions won't work/crash, AFAIR.
> 
> Ok.
> 
> > In file included from guile-ltdl.c:43:
> > raw-ltdl.c:245: warning: `strchr' redefined
> 
> I've seen this, too.  Run "cvs update" so that you have the latest
> autogen.sh, then run "./autogen.sh".  Previously, scmconfig.h.in
> wouldn't always be updated.
> 
Thx for the hint. Now I have problems linking my application:

/usr/local/lib/libguile-ltdl.so: undefined reference to `lt_preloaded_symbols'
collect2: ld returned 1 exit status

Any hint?

Regards, Andy
-- 
Andreas Rottmann         | Dru@ICQ        | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/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: Guile CVS Build Problems (was: Re: What can I do to help? (conclusions))

[Marius Vollmer]

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

> Thx for the hint. Now I have problems linking my application:
> 
> /usr/local/lib/libguile-ltdl.so: undefined reference to `lt_preloaded_symbols'
> collect2: ld returned 1 exit status

Rob, can you help?  I remember that you did something to
lt_preloaded_symbols...

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


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

Re: Guile CVS Build Problems (was: Re: What can I do to help? (conclusions))

[Rob Browning]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> Andreas Rottmann <a.rottmann@gmx.at> writes:
>
>> Thx for the hint. Now I have problems linking my application:
>> 
>> /usr/local/lib/libguile-ltdl.so: undefined reference to `lt_preloaded_symbols'
>> collect2: ld returned 1 exit status
>
> Rob, can you help?  I remember that you did something to
> lt_preloaded_symbols...

I can try, but I'll have to play around with it some.  I recall being
a little mystified by lt_preloaded_symbols myself.

I just created a function scm_lt_dlset_preloaded_symbols for us that
does the same thing as LT_DLSET_PRELOADED_SYMBOLS, so I thought it
would work, but perhaps I made a mistake.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: Guile CVS Build Problems (was: Re: What can I do to help? (conclusions))

[Marius Vollmer]

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

> Thx for the hint. Now I have problems linking my application:
> 
> /usr/local/lib/libguile-ltdl.so: undefined reference to `lt_preloaded_symbols'
> collect2: ld returned 1 exit status

Here is a workaround: replace LTDL_SET_PRELOADED_SYMBOLS() with

    scm_lt_dlset_preloaded_symbols ();

(even tho you don't get a prototype for it.)


We should try to find a source compatible solution as well.

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


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

Re: Guile CVS Build Problems (was: Re: What can I do to help? (conclusions))

[Andreas Rottmann]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> Andreas Rottmann <a.rottmann@gmx.at> writes:
> 
> > Thx for the hint. Now I have problems linking my application:
> > 
> > /usr/local/lib/libguile-ltdl.so: undefined reference to `lt_preloaded_symbols'
> > collect2: ld returned 1 exit status
> 
> Here is a workaround: replace LTDL_SET_PRELOADED_SYMBOLS() with
> 
>     scm_lt_dlset_preloaded_symbols ();
> 
> (even tho you don't get a prototype for it.)
> 
No, I don't even use that macro. The problem is, AFACIT, this code in
guile-ltdl.c:

void
scm_lt_dlset_preloaded_symbols (void)
{
  extern const lt_dlsymlist lt_preloaded_symbols[];
  lt_dlpreload_default(lt_preloaded_symbols);
}

Andy
-- 
Andreas Rottmann         | Dru@ICQ        | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/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: Guile CVS Build Problems (was: Re: What can I do to help? (conclusions))

[Rob Browning]

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

> No, I don't even use that macro. The problem is, AFACIT, this code in
> guile-ltdl.c:
>
> void
> scm_lt_dlset_preloaded_symbols (void)
> {
>   extern const lt_dlsymlist lt_preloaded_symbols[];
>   lt_dlpreload_default(lt_preloaded_symbols);
> }

If it helps someone track this down before I have a chance to look in
to it, that code is just a copy/paste expansion of the macro that used
to be in the same location where this new function
(scm_lt_dlset_preloaded_symbols) is called (I think in guile.c).

We used to call LT_DLSET_PRELOADED_SYMBOLS (), which expands into the
two lines above.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: Guile CVS Build Problems (was: Re: What can I do to help? (conclusions))

[Andreas Rottmann]

Rob Browning <rlb@defaultvalue.org> writes:

> Andreas Rottmann <a.rottmann@gmx.at> writes:
> 
> > No, I don't even use that macro. The problem is, AFACIT, this code in
> > guile-ltdl.c:
> >
> > void
> > scm_lt_dlset_preloaded_symbols (void)
> > {
> >   extern const lt_dlsymlist lt_preloaded_symbols[];
> >   lt_dlpreload_default(lt_preloaded_symbols);
> > }
> 
> If it helps someone track this down before I have a chance to look in
> to it, that code is just a copy/paste expansion of the macro that used
> to be in the same location where this new function
> (scm_lt_dlset_preloaded_symbols) is called (I think in guile.c).
> 
The problem is that lt_preloaded symbols is defined nowhere. I have no
idea where it should come from...

Andy
-- 
Andreas Rottmann         | Dru@ICQ        | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/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: Guile CVS Build Problems (was: Re: What can I do to help? (conclusions))

[Andreas Rottmann]

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

> Rob Browning <rlb@defaultvalue.org> writes:
> 
> > Andreas Rottmann <a.rottmann@gmx.at> writes:
> > 
> > > No, I don't even use that macro. The problem is, AFACIT, this code in
> > > guile-ltdl.c:
> > >
> > > void
> > > scm_lt_dlset_preloaded_symbols (void)
> > > {
> > >   extern const lt_dlsymlist lt_preloaded_symbols[];
> > >   lt_dlpreload_default(lt_preloaded_symbols);
> > > }
> > 
> > If it helps someone track this down before I have a chance to look in
> > to it, that code is just a copy/paste expansion of the macro that used
> > to be in the same location where this new function
> > (scm_lt_dlset_preloaded_symbols) is called (I think in guile.c).
> > 
> The problem is that lt_preloaded symbols is defined nowhere. I have no
> idea where it should come from...
> 
s/lt_preloaded symbols//lt_preloaded_symbols/



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

Re: Guile CVS Build Problems (was: Re: What can I do to help? (conclusions))

[Rob Browning]

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

>> The problem is that lt_preloaded symbols is defined nowhere. I have no
>> idea where it should come from...
>> 
> s/lt_preloaded symbols//lt_preloaded_symbols/

Right -- that's why I was originally confused, and just copy/pasted
the code from what we were already doing.  I'm getting ready to look
in to it.  Perhaps there's some libtool magic involved here...

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: Guile CVS Build Problems (was: Re: What can I do to help? (conclusions))

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

> Right -- that's why I was originally confused, and just copy/pasted
> the code from what we were already doing.  I'm getting ready to look
> in to it.  Perhaps there's some libtool magic involved here...

Apparently there is some libtool manipulation involved.

We're not calling LTDL_SET_PRELOADED_SYMBOLS from main anymore, and
from this[1] I'm guessing that somehow libtool injects the variable
into the build process during the main binary build.

Sure enough, if you check the resulting guile binary

  nm libguile/.libs/guile | grep lt_preload
  $ nm libguile/.libs/guile | grep lt_preload
  080488d8 R lt_preloaded_symbols

you see that lt_preloaded_symbols shows up in the read-only section of
the resultant guile binary even though AFAIK we don't define it
anywhere in our source code.  Looking at the libtool script itself, it
appears to add code to the binary during the build process that
defines the variable.

 [1] http://gcc.gnu.org/ml/java-patches/2000-q3/msg00220.html
     (and followup)

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: Guile CVS Build Problems (was: Re: What can I do to help? (conclusions))

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

> Looking at the libtool script itself, it appears to add code to the
> binary during the build process that defines the variable.

OK.  I think I may have fixed the problem.  Could you try CVS and let
me know?

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: Guile CVS Build Problems (was: Re: What can I do to help? (conclusions))

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

> OK.  I think I may have fixed the problem.  Could you try CVS and let
> me know?

...in the main trunk, not 1.6.  I'm going to backport if we get the
kinks out.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: What can I do to help? (conclusions)

[Rob Browning]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> I've seen this, too.  Run "cvs update" so that you have the latest
> autogen.sh, then run "./autogen.sh".  Previously, scmconfig.h.in
> wouldn't always be updated.

Also, make sure you consider adding "-Pd" to the update call so you'll
get the new dir(s) and get rid of the empty old dir(s).

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: What can I do to help? (conclusions)

[Daniel Skarda]

> > No, you don't compile using C++, just use g++ for the linking
> > stage. This way the executable will be linked against libstdc++, but
> > there should be no other user-visible effects except that C++ modules
> > will work.
> 
> In my experience, you don't need to do that on GNU/Linux but you need
> to on Solaris.  Does that match your experience?
> 
> In any case: do you have a patch?  We might even link with g++ by
> default when it is available.

  I guess that it would be sufficient to link C++ _modules_ with g++ (or link 
them explicitely with libstdc++). For example you do not have to link guile 
against libgtk to make guile-gtk modules work. 

  But do not believe me, it is just a guess few minutes before midnight...
I have never loaded C++ modules to C program.

0.


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

Re: What can I do to help? (conclusions)

[Daniel Skarda]

> > (or link them explicitely with libstdc++). For example you do not
> > have to link guile against libgtk to make guile-gtk modules work.
> > 
> Yes, I know that. This is a completly different problem, though. It's
> not about the C++ standard lib(s), but about C++ features such as
> exceptions and RTTI that must be 'supported' by the main program
> (don't ask me for details, however).

  If you want to _throw_ C++ exception through C code, than yes - libguile has to
be compiled using g++. But I do not think this is a good idea - because you
bypass Guile exception mechanism and you will not be able to catch C++
exceptions from scheme and vice versa.

  Recipe I used in my app: wrap all C++ "glue" functions with try/catch and
translate C++ exceptions to Scheme. Also all C++ -> Scheme entries must be
handled and Scheme exceptions translated to C++.

  I try to extract helper code from my app and create "libguile++" library, with
utilities that are necessary for Guile/C++ integration tasks.

> >   But do not believe me, it is just a guess few minutes before midnight...
> > I have never loaded C++ modules to C program.
> > 
> I don't since I know better ;-) The proof is left as an exercise to
> the reader: Just compile some c++ code (and do some exception stuff in
> it) into a guile module, and guile will crash on loading this module -
> same thing with s/guile/c-linked-app/g.

  See the code attached bellow - I have not any problems (on Debian Linux,
that's it). So reader is confused and tomorow he is going to try some SGI/Sun
machines... :-)

0.

;--- Makefile: --------------------------------------------------------
.SUFFIXES: .lo .la

CXXFLAGS = $(shell guile-config compile)
LDFLAGS =  $(shell guile-config link) -rpath $(shell pwd)


all: libfoo.la

libfoo.la: foo.lo
	libtool --mode=link $(CXX) -o $@ $^ $(LDFLAGS) $(LIBS)


%.lo: %.cc 
	libtool --mode=compile $(CXX) -c $(CPPFLAGS) $(CXXFLAGS) -o  $@ $<

clean:
	-rm -rvf .libs *.lo *.la *.a *.so

;--- foo.cc -------------------------------------------------------------------
#include <libguile.h>
#include <stdlib.h>

static SCM
scm_foo (void)
try
{ 
  if (random () & 1)
    throw "Something very bad happened";

  return scm_makfrom0str ("bar"); 
}
catch (const char* desc)
{ 
  scm_misc_error ("foo", desc, SCM_EOL);
  return SCM_UNSPECIFIED;
}

extern "C" 
void
init_foo (void)
{
  scm_c_define_gsubr ("foo", 0,0,0, scm_foo);
} 
;--- foo.scm ----------------------------------------------------------
(define-module (foo)
  :use-module (gtk-1.2 dynlink))

(merge-compiled-code "init_foo" "libfoo")


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

Re: What can I do to help? (conclusions)

[Evan Prodromou]

>>>>> "EP" == Evan Prodromou <evan@prodromou.san-francisco.ca.us> writes:

    EP> I think there are a ton of projects that need to be done for
    EP> Guile that are not yet done. For example:

Another one I just thought of:

        * A Guile LDAP module

So, is there a good place to start putting up a modules wishlist?
Maybe at GLUG, or here?

      http://www.gnu.org/software/guile/ideas.html

Also, is there a good reason that the news info isn't on the front
page of the Guile Web site, rather than buried somewhere else? I mean,
isn't 1.6 release kind of a big deal?

~ESP

-- 
Evan Prodromou
evan@prodromou.san-francisco.ca.us



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

Re: What can I do to help? (conclusions)

[Rob Browning]

Evan Prodromou <evan@prodromou.san-francisco.ca.us> writes:

> Also, is there a good reason that the news info isn't on the front
> page of the Guile Web site, rather than buried somewhere else? I mean,
> isn't 1.6 release kind of a big deal?

Hmm.  when I go to http://www.gnu.org/software/guile/, it's the first
thing I see.  Is that not what you mean?

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: What can I do to help? (conclusions)

[Rob Browning]

Evan Prodromou <evan@prodromou.san-francisco.ca.us> writes:

>     * SMTP and POP3 modules
>     
>     * An NNTP module

Anyone interested here should probably consider talking to the
mailutils people.  They already have a set of guile mail functions and
were interested (and had already hoped to) turn them into a guile
module and turn their "guile mail shell" (guimb) into a script that
just uses the module.

If no one else gets to it first, I may help them out if/when I have
the time.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: What can I do to help? (conclusions)

[Dale P. Smith]

On Thu, 03 Oct 2002 13:14:27 -0400
Evan Prodromou <evan@prodromou.san-francisco.ca.us> wrote:

> 
>     * A module for using zlib, with a special mechanism for
>       transparent compression on ports

I started working on this.  I can compress to/from strings.  I got stuck
on the ports.

If anyone want's what I have, I can send it.  If you can improve my clue
level on the inner workings of ports, I'd appreciate it.

-Dale

-- 
Dale P. Smith
Senior Systems Consultant,      | Treasurer,
Altus Technologies Corporation  | Cleveland Linux Users Group
dsmith@altustech.com            | http://cleveland.lug.net
440-746-9000 x339               |


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

Re: What can I do to help? (conclusions)

[Neil Jerram]

>>>>> "Evan" == Evan Prodromou <evan@prodromou.san-francisco.ca.us> writes:

    Evan> I think there are a ton of projects that need to be done for Guile
    Evan> that are not yet done. For example: [...]

Hmm.  I think that it's far more productive to have particular
application-level needs in mind, always keeping an eye on generality
where possible, than to work on a checklist per se (or a comparison
with what is available for other languages).

And, of course, if there is a ton of stuff available for, say, Ruby,
it would be far more efficient to try to write a translator for Ruby.

(I hesitate to suggest trying to translate Perl :-)

        Neil



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

Re: What can I do to help? (conclusions)

[Evan Prodromou]

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

    NJ> And, of course, if there is a ton of stuff available for, say,
    NJ> Ruby, it would be far more efficient to try to write a
    NJ> translator for Ruby.

Oh, brother. So, nobody writes native Guile modules because they
already exist for Python, and we can write a translator. And then
nobody writes a translator, or they write an abandonware one that
doesn't work, and it just goes on and on.

If someone's looking for a project to do, I say write a module. Nice
compact project, narrow definition, and will be of great use to the
Guile community. 

But that's just me.

~ESP

-- 
Evan Prodromou
evan@prodromou.san-francisco.ca.us



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

Re: What can I do to help? (conclusions)

[Tom Lord]

Yay!  Sanity:

       neil@ossau.uklinux.net

       > I think that it's far more productive to have particular
       > application-level needs in mind, always keeping an eye on
       > generality where possible, than to work on a checklist per se
       > (or a comparison with what is available for other languages).


How about:


*) some Sim* style games

*) a "robot-wars" game

*) a symbolic math package with nice display features

*) a customizable graphing package designed with your favorite
   nearby underbudgeted scientists

*) a customizable auto-classifier for incoming email

*) an implementation of the `arch' revision control system :-)

*) a customizable `lint' for C programs

*) a customizable file manager with both text-based and graphical
   interfaces

*) a _fast_ cellular automata toy, with gosper's 13-way recursion hack
   for peering _far_ into the future

*) (with apologies to GnuCash) a purely-scheme finance manager

*) a fancy wiki

*) a database and syntax-based query engine for programs ("precise tags")

*) an interactive shell

*) a suite of the standard, core PDA apps, with both text and
   graphical interfaces

*) an extensible text formatting system to replace texinfo


I think all the apps in that list would benefit from (or even require)
extensibility.  They'd all benefit from the conciseness that can be
achieved by doing them in Scheme.   Several of them require some GUI
tools.  Several will put pressure on text processing and/or shell
features.  All of them will present some performance challenges.

An alternative would be to pick a handful of such apps and then start
architecting a framework first -- but my sense is that that would
require a dedicated team of people hacking Guile full-time for it to
take less than an eternity.   So, yeah, using some specific apps to
drive a hill-climbing approach to framework evolution might yield
interesting results.

-t



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

Fast format (was Re: What can I do to help?)

[Daniel Skarda]

Hello,

  I think Guile does not have fast formated output (see simple benchmark).

  `simple-format' now implements only basic `format' subset. I think that fast
format could be critical for some type of applications, but simple-format does
not even implement simple number (or string) formating.

0.

;--- simple (simple-)format benchmarks: -------------------------------

(use-modules (ice-9 format))

guile> (define p (open-output-file  "/dev/null"))

guile> (time (do-ntimes (n 100000) (simple-format p "~s" 3.14159265358979)))
Elapsed time: 1.875558 sec
  Real  1.88 sec
  User  1.88 sec
  Sys   0.0 sec
  Gc    0.62 sec

Garbage Collector:
  #exec                 16
  Time                  0.62 sec

guile> (time (do-ntimes  (n 100000) (format p "~s" 3.14159265358979)))       
Elapsed time: 21.257521 sec
  Real  21.26 sec
  User  21.25 sec
  Sys   0.01 sec
  Gc    9.44 sec

Garbage Collector:
  #exec                 244
  Time                  9.44 sec


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

Fast format (was Re: What can I do to help?)

[Han-Wen Nienhuys]

0rfelyus@ucw.cz writes:
> Hello,
> 
>   I think Guile does not have fast formated output (see simple benchmark).
> 
>   `simple-format' now implements only basic `format' subset. I think that fast
> format could be critical for some type of applications, but simple-format does
> not even implement simple number (or string) formating.
> 
> 0.
> 
> ;--- simple (simple-)format benchmarks: -------------------------------
> 
> (use-modules (ice-9 format))
> 
> guile> (define p (open-output-file  "/dev/null"))
> 
> guile> (time (do-ntimes (n 100000) (simple-format p "~s" 3.14159265358979)))

do-ntimes ?

	guile> (gc-stats)
	( .. (bytes-malloced . 118197) 
	guile> (simple-format p "~s" 3.14159265358979)
	guile> (gc-stats)
	(... (bytes-malloced . 118481) (gc-malloc-threshold . 204800)

each call costs 284 bytes. Multiply with 100000, and you're allocating
28 megs in miniscule chunks. The threshold is at 200k, so 16 times GC
seems reasonable - I don't really know how to speed up the GC part;
I'd guess that most time is spent in mallocing and freeing the strings
themselves.

-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 


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

Re: Fast format (was Re: What can I do to help?)

[Daniel Skarda]

> > guile> (time (do-ntimes (n 100000) (simple-format p "~s" 3.14159265358979)))
> do-ntimes ?

  Common-Lisp like macro dotimes (see HyperSpec).

  The speed of simple-format is not problem. simple-format (C implementation) is
fast, the real problem is format from (ice-9 format). It is scheme format
implementation (it accepts more formating parameters than simple-format does.

guile> (time (do-ntimes (n 100000) (simple-format p "~s" 3.14159265358979)))
Elapsed time: 1.875558 sec

guile> (time (do-ntimes  (n 100000) (format p "~s" 3.14159265358979)))       
Elapsed time: 21.257521 sec

  Do you see the diference? For example, if you want to pad numbers, you have to
use scheme format implementation. 

  Think in C: if you want to just print numbers ("%d") you can use "fast
"implementation", if you want to write "%3d", you have to use more than 10 times
slower implementation. Strange, is not it?

0.


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

Debian packages (Re: What can I do to help?)

[Daniel Skarda]

Hello,

  I do not know what Linux distribution you use or whether you use Linux at
all. Guile 1.6 was released sometime ago, but today new stable version still
does not have Debian package (not even in unstable branch of Debian).

  Read the message: people do not care about using Guile (otherwise there
would be demand for Debian package immediately after Guile release) and
Guile developers do not care about potential users (otherwise they would
offer such package along with the release).

  While I was browsing list of Debian packages, I noticed many packages of 
development beta versions (sometimes even checkouts from CVS). Though there
was not package for libguile1.7. I do not understand this "message" Guile
developers want to send to potential Guile users :-(please do not use Guile?)
  
  I think that pushing latest version of Guile (and language bindings for
Guile) to popular Linux distribution would be very useful (though it is not
"real programming").

Best regards,
Daniel Skarda


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

Re: Debian packages (Re: What can I do to help?)

[Evan Prodromou]

>>>>> "DS" == Daniel Skarda <0rfelyus@ucw.cz> writes:

    DS> Hello, I do not know what Linux distribution you use or
    DS> whether you use Linux at all. Guile 1.6 was released sometime
    DS> ago, but today new stable version still does not have Debian
    DS> package (not even in unstable branch of Debian).

OK, so, I know rlb has lots of other stuff to do, but I'll say it
right now: please finish and upload the 1.6 package(s). I'm sick of
using my /usr/local version.

~ESP

-- 
Evan Prodromou
evan@prodromou.san-francisco.ca.us



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

Re: Debian packages (Re: What can I do to help?)

[Rob Browning]

Daniel Skarda <0rfelyus@ucw.cz> writes:

> While I was browsing list of Debian packages, I noticed many
> packages of development beta versions (sometimes even checkouts from
> CVS). Though there was not package for libguile1.7. I do not
> understand this "message" Guile developers want to send to potential
> Guile users :-(please do not use Guile?)

How about the message: "please do not use (and link applications
against) development versions of guile".

And wrt to packaging 1.6, I'm going as fast as my time and the
complexity allows.  Last weekend was spent working on emacs21, which
has more important and longer-standing issues.  That work is just
about finished.  Last night I spent working with mvo on the ltdl
issue, arguably one that affects *every* platform, and one we may have
fixed for 1.6.1.

The 1.6. packages will be released soon, the debian/* files will be in
CVS (after I finish re-writing them to avoid copyright issues), and I
doubt the few week delay is likely to hurt anything.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: Debian packages (Re: What can I do to help?)

[Daniel Skarda]

Hello,

Rob Browning <rlb@defaultvalue.org> writes:
> Daniel Skarda <0rfelyus@ucw.cz> writes:
> > While I was browsing list of Debian packages, I noticed many
> > packages of development beta versions (sometimes even checkouts from
> > CVS). Though there was not package for libguile1.7. I do not
> > understand this "message" Guile developers want to send to potential
> > Guile users :-(please do not use Guile?)
> 
> How about the message: "please do not use (and link applications
> against) development versions of guile".

  I am sorry for my provocative and ungrateful writing. It seems I have to learn
how to write Debian packages so I could help and stop groaning. I have not look
in /usr/share/doc/ and I thought that guile*.deb packages are lonely orphans.
Thank you for maintaining guile packages.

  But I do not agree with you that Guile development versions should be hidden
from outside world. It should be released, but clearly marked as a development
version, which is unstable and it possible that its interface change in future.

  When fool shoots himself in his leg, even thought he was clearly warned, it
is his fault. If you want to think of all ways how fool can shoot himself in leg
and try to prevent it, it is very likely you spend a lot of time and resources,
but at the end you fail (and possibly you as a side effect prevent other people
to do something useful).

  IMHO to release a package for Guile development development version gives a
message: "Hey, this is new and exciting development version. It is unstable and
dangerous, but if you are brave enough, feel free to test it and join Guile
development." More eyes see more bugs and more brains have more ideas (however
crazy :-)

0.

ps: I have quickly browsed through CVS workbook directory but have I not seen
any schedule of 1.7.x development branch. What features will go to particular
1.7.x versions etc.

ps: Installing different guile versions with same prefix would cause conflicts. 
Are you going to use same "strategy" as Gtk+? (usr/include/gtk-1.2, /u/i/gtk-2.0 
etc..)


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

Re: Debian packages (Re: What can I do to help?)

[Rob Browning]

Daniel Skarda <0rfelyus@ucw.cz> writes:

>   I am sorry for my provocative and ungrateful writing. It seems I
> have to learn how to write Debian packages so I could help and stop
> groaning. I have not look in /usr/share/doc/ and I thought that
> guile*.deb packages are lonely orphans.  Thank you for maintaining
> guile packages.

Thanks, and you're certainly welcome, though I *am* definitely running
behind.

> But I do not agree with you that Guile development versions should
> be hidden from outside world. It should be released, but clearly
> marked as a development version, which is unstable and it possible
> that its interface change in future.

You have good points, but let's wait until I get the debian/* files
into CVS and finish packaging.  At that point we can talk about it.

As an example concern, note that during a development series, the
major number of the shared libs may change (or may *not* change when
they should), so I want to be a little cautious about uploading
development packages where other debian developers might grab it and
install the -dev package without realizing the implications, and then
start building/uploading their own guile-dependent packages.  This may
not be a big deal, but I'll need to think about it.

> ps: I have quickly browsed through CVS workbook directory but have I
> not seen any schedule of 1.7.x development branch. What features
> will go to particular 1.7.x versions etc.

The main resource right now is workbook/tasks/TODO, but it only has a
few items at a moment.

> ps: Installing different guile versions with same prefix would cause
> conflicts.  Are you going to use same "strategy" as Gtk+?
> (usr/include/gtk-1.2, /u/i/gtk-2.0 etc..)

That's a good question -- for my initial debian packages, I'm probably
only going to allow one set of development files to be installed at a
time...

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


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

Re: Debian packages (Re: What can I do to help?)

[Neil Jerram]

>>>>> "Daniel" == Daniel Skarda <0rfelyus@ucw.cz> writes:

    Daniel>   Read the message: people do not care about using Guile
    Daniel> (otherwise there would be demand for Debian package
    Daniel> immediately after Guile release) and Guile developers do
    Daniel> not care about potential users (otherwise they would offer
    Daniel> such package along with the release).

I think this is both untrue and unfair.

Untrue, because Guile users are either developers themselves or users
of Guile-based applications.  In the former case, they should be able
to manage installation from source; in the latter, there are wider
packaging issues to address that are more in the domain of the
distributor than of the core Guile developers.

Unfair, because everyone contributes to Guile for free and spends
their time according to their own perception of priorities.  No one
has a right to demand something different.  (Opinion is fine, but the
above doesn't read as an opinion.)

        Neil



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

Re: Debian packages (Re: What can I do to help?)

[Daniel Skarda]

>     Daniel>   Read the message: people do not care about using Guile
>     Daniel> (otherwise there would be demand for Debian package
>     Daniel> immediately after Guile release) and Guile developers do
>     Daniel> not care about potential users (otherwise they would offer
>     Daniel> such package along with the release).
> 
> I think this is both untrue and unfair.

  On my system, there are three Guile versions installed (1.4, 1.6 and 1.7 
from CVS). Personally I do not demand anythink. I understand that wonderful
world of Guile is the result of voluntary work. I just wonder why you do not
want to attract more developers and helping hands.

  I am sorry if my oppinion sounds unfair. I admit that my first email on this
topic was hyperbole, which sounded very ungreatful. In fact I just wanted to
point out problems I found serious.

0.



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

Re: Debian packages (Re: What can I do to help?)

[Jorgen Schaefer]

Daniel Skarda <0rfelyus@ucw.cz> writes:

> >     Daniel>   Read the message: people do not care about using Guile
> >     Daniel> (otherwise there would be demand for Debian package
> >     Daniel> immediately after Guile release) and Guile developers do
> >     Daniel> not care about potential users (otherwise they would offer
> >     Daniel> such package along with the release).
> > 
> > I think this is both untrue and unfair.
> 
>   On my system, there are three Guile versions installed (1.4, 1.6 and 1.7 
> from CVS). Personally I do not demand anythink. I understand that wonderful
> world of Guile is the result of voluntary work. I just wonder why you do not
> want to attract more developers and helping hands.

[...]

The biggest problem with no current guile package for Debian is
that one can't release any program that depends on current guile
features (and there are plenty!) because one can't demand from
users to manually install the newest guile version themselves...
:(
        -- Jorgen

-- 
((email . "forcer@forcix.cx") (www . "http://www.forcix.cx/")
 (gpg   . "1024D/028AF63C")   (irc . "nick forcer on IRCnet"))


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

Re: Debian packages (Re: What can I do to help?)

[Han-Wen Nienhuys]

forcer@forcix.cx writes:
> The biggest problem with no current guile package for Debian is
> that one can't release any program that depends on current guile
> features (and there are plenty!) because one can't demand from
> users to manually install the newest guile version themselves...
> :(
>         -- Jorgen

Hear, hear!


(we had to release 1.5.6 for windows to get lilypond running on cygwin, IIRC).

--
Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 


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

Re: What can I do to help?

[Marius Vollmer]

Dr William Bland <wjb@abstractnonsense.com> writes:

> 1. Add a guile scripting plugin to Abiword.
> 
> 2. Move the GIMP from script-fu (SIOD) to guile, perhaps by reviving
>    gimple.
> 
> 3. There is a TODO for writing a CORBA interface.  I've wanted to learn
>    CORBA for a while now, and maybe this would be a good way to do it?

I think these are all very good ideas.

If you want to hack in Guile itself, you might consider improving the
debugger, and/or Emcas integration, for example.

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


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

Re: What can I do to help?

[Neil Jerram]

>>>>> "Marius" == Marius Vollmer <mvo@zagadka.ping.de> writes:

    Marius> you might consider improving the debugger,

Please (people in general) don't do this without talking to me first,
though, and looking at my guile-debugger package.

        Neil



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

Re: What can I do to help?

[Marius Vollmer]

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

> >>>>> "Marius" == Marius Vollmer <mvo@zagadka.ping.de> writes:
> 
>     Marius> you might consider improving the debugger,
> 
> Please (people in general) don't do this without talking to me first,
> though, and looking at my guile-debugger package.

Err, yes, sorry.

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


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

guile-debugger (was Re: What can I do to help?)

[Neil Jerram]

>>>>> "Marius" == Marius Vollmer <mvo@zagadka.ping.de> writes:

    Marius> Neil Jerram <neil@ossau.uklinux.net> writes:
    >> >>>>> "Marius" == Marius Vollmer <mvo@zagadka.ping.de> writes:
    >> 
    Marius> you might consider improving the debugger,
    >> 
    >> Please (people in general) don't do this without talking to me first,
    >> though, and looking at my guile-debugger package.

    Marius> Err, yes, sorry.

Talking of which, has anyone tried using guile-debugger?  Does it do
what you want?  If not, what should I add or change?

Regards,
        Neil



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

guile-debugger (was Re: What can I do to help?)

[Han-Wen Nienhuys]

neil@ossau.uklinux.net writes:
>     >> though, and looking at my guile-debugger package.
> 
>     Marius> Err, yes, sorry.
> 
> Talking of which, has anyone tried using guile-debugger?  Does it do
> what you want?  If not, what should I add or change?

I didn't even know it existed. It's not in the doco, or am I missing
something?

-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 


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

Re: guile-debugger (was Re: What can I do to help?)

[Neil Jerram]

>>>>> "Han-Wen" == Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

    Han-Wen> neil@ossau.uklinux.net writes:
    >> Talking of which, has anyone tried using guile-debugger?  Does it do
    >> what you want?  If not, what should I add or change?

    Han-Wen> I didn't even know it existed. It's not in the doco, or am I missing
    Han-Wen> something?

It's packaged separately, and I have announced it a few times on the
mailing list: see http://www.ossau.uklinux.net/guile/.  I hope soon to
write some docs (in guile-core) on how to use the Guile REPL,
including debugging; when I do that, I will reference guile-debugger.

        Neil



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

Re: guile-debugger (was Re: What can I do to help?)

[Daniel Skarda]

>     Han-Wen> neil@ossau.uklinux.net writes:
>     >> Talking of which, has anyone tried using guile-debugger?  Does it do
>     >> what you want?  If not, what should I add or change?
> 
>     Han-Wen> I didn't even know it existed. It's not in the doco, or am I missing
>     Han-Wen> something?
> 
> It's packaged separately, and I have announced it a few times on the
> mailing list: see http://www.ossau.uklinux.net/guile/.  I hope soon to
> write some docs (in guile-core) on how to use the Guile REPL,
> including debugging; when I do that, I will reference guile-debugger.

  Oops, that's strange that even developers do not know about such quite
important package. Do you plan to merge it into guile-core?

0.


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

Re: guile-debugger (was Re: What can I do to help?)

[Marius Vollmer]

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

> It's packaged separately, and I have announced it a few times on the
> mailing list: see http://www.ossau.uklinux.net/guile/.

Can you move this code into the Guile CVS on Savannah?  I think a
debugger is pretty important to have in the core.

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


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