Hi Marius,
Marius Vollmer wrote:
> Yes, but I think Guile is very reasonable with its "bunch of other
> stuff". It only really requires libgmp and libltdl. The versions of
> these that are in the mainstream distributions should suffice.
The mainstream distributions "of Linux" :). My world is
On Sunday 10 April 2005 03:17 pm, Kevin Ryde wrote:
> I propose to do 1+ and 1- in C so they're as fast as plain + and -.
> Calling scm_sum and scm_difference will still get goops/generics
> dispatch the same as the scheme code, if I'm not mistaken.
Shouldn't the name for the subtraction code be `
snarf-check-and-output-texi hangs forever:
creating guile
cat alist.doc arbiters.doc async.doc backtrace.doc boolean.doc chars.doc \
continuations.doc debug.doc dynl.doc dynwind.doc environments.doc eq.doc \
error.doc eval.doc evalext.doc extensions.doc feature.doc fluids.doc \
fports.doc gc.do
On Monday 25 April 2005 01:05 pm, Bruce Korb wrote:
> This time on Solaris with Guile 1.6.7.
> It seems that generating the docs is pretty difficult:
OK. Never mind. My fault. I've configured my default
configuration to up the optimizations a bit. Guile seg faults
on opt
On Sunday 12 June 2005 11:13 am, Bruce Korb wrote:
> HP/UX: "guile" never finishes generating "guile.texi".
> I solved it by copying it + guile-procedures.texi from the Solaris build.
> I am still building, so I don't know what else I'll encounter.
We
AIX:
> source='../../libguile/modules.c' object='modules.lo' libtool=yes
> DEPDIR=.deps \
> depmode=aix /bin/sh ../../depcomp /bin/sh ../libtool --tag=CC --mode=compile
> \
> /usr/bin/xlc -DHAVE_CONFIG_H -I. -I../../libguile -I.. -I..
> -I../../libguile/.. \
> -I../../libguile-ltdl -g -c
Hi Guys,
Please remember that there are systems out there still running
Guile 1.4 and haven't upgraded because there are issues with
newer sources. Please hold off removing interfaces for a decade
or so after deprecating them. Thank you. :) Regards, Bruce
-- Forwarded Message --
Hi all,
The following function is disliked by me and disliked by Guile 1.7.
It is a PITA to maintain, but it is compulsory until there is equivalent
functionality available. It is crucially important that error messages
point to the source file where the problem lies.
More and more installation
Hi all,
The following function is disliked by me and disliked by Guile 1.7.
It is a PITA to maintain, but it is compulsory until there is equivalent
functionality available. It is crucially important that error messages
point to the source file where the problem lies.
More and more installations
On Tuesday 29 November 2005 12:16 am, Ludovic Courtès wrote:
> Hi,
>
> Bruce Korb <[EMAIL PROTECTED]> writes:
>
> > Grumble, grumble. Anyway, this belongs in your code. We argued about this
> > before and someone said, "well, you could do it in any of several
On Wednesday 30 November 2005 12:39 am, Ludovic Courtès wrote:
> Hi Bruce,
>
> Bruce Korb <[EMAIL PROTECTED]> writes:
>
> > *I* certainly cannot.
>
> Do you mean that you don't *want* to, or that this is not possible?
Well, okay, I don't find the stuff
On Wednesday 30 November 2005 05:46 am, Ludovic Courtès wrote:
> Bruce Korb <[EMAIL PROTECTED]> writes:
>
> > Well, okay, I don't find the stuff obvious. With effort, I'm sure
> > I could puzzle it out. I have never found Lisp to be inherently
> > &quo
On Wednesday 30 November 2005 06:44 am, Ludovic Courtès wrote:
> Bruce Korb <[EMAIL PROTECTED]> writes:
>
> > Because the file is mostly *NOT* scheme.
>
> I did say that you could use "Scheme constructs", "be it from Scheme
> o[r] C code". In
On Wednesday 30 November 2005 08:04 am, Ludovic Courtès wrote:
*Thank you*, Ludvic! Now we're getting some where. :-D
> That the input file does not contain only Scheme source wasn't clear to
> me.
What I am doing is extracting Scheme code from an encompassing
template and handing it off fo
On Wednesday 30 November 2005 11:00 am, Rob Browning wrote:
> If so, then I wondered if it might be possible to just implement the
> function mentioned originally
> i.e. ag_scm_c_eval_string_from_file_line, and here's what I came up
> with. Note that I have no idea if this will actually work; I ha
On Wednesday 30 November 2005 02:35 pm, Rob Browning wrote:
> >SCM res = scm_call_3 (proc, str, file, line);
> >// Let's forget columns -- we don't have scm_call_4.
>
> Actually it looks like there is a scm_call_4.
OK. Let's put it in the doc then, too. :-)
> > I'll give this a spin
Hi Rob et al.,
Now for something completely different. Obviously, I have not yet
updated my code to figure out what sort of thing it is that I got
back from my eval call. Nevertheless, my understanding was that
you ought to be able to call WHATEVER_p with any bit pattern and
have it say, "Yes,
Hi Guys,
In trying to "upgrade" things and expunge the "gh_" interface, I
tried to use "scm_string_p()" as a replacement for "gh_string_p()".
That lead to an extraordinarily obtuse seg fault that was only
solved by using gh_string_p(), despite its being deprecated.
(Both would appropriately retur
I have *two* problems. First, after emitting the error text below,
Guile 1.7.2 is calling, "exit(0)" not "exit(EXIT_FAILURE)".
That's wrong. Additionally, I am not getting the file/line
stuff using the code I thought we worked out.
--- error.out6 Sun Dec 4 13:41:27 2005
***
*** 1,
On Wednesday 30 November 2005 04:44 pm, Kevin Ryde wrote:
> Collateral damage from the change to scm_inexact_p (other message).
> Not sure how one or both ought to work.
All *_p functions ought to accept anything without throwing an error.
Even if it doesn't seem to make sense. That way, I know I
On Sunday 04 December 2005 08:08 pm, Bruce Korb wrote:
> Anyway, *real bugs* in Guile 1.7.2 are:
>
> 1. When an error is thrown, "exit" should be called with EXIT_FAILURE, not 0.
The problem here is that the doc for "gh_enter()" (and successors?) says
that it do
On Monday 05 December 2005 02:27 pm, you wrote:
> Bruce Korb <[EMAIL PROTECTED]> writes:
> >
> > In particular, using "scm_makstr(_s, _ch)" causes faults,
>
> Looks like it ought to be ok. Post a failing example to guile-devel
> if you like.
Hi Kevin,
Hi Neil,
Neil Jerram wrote:
Bruce Korb <[EMAIL PROTECTED]> writes:
I have *two* problems. First, after emitting the error text below,
Guile 1.7.2 is calling, "exit(0)" not "exit(EXIT_FAILURE)".
What function in Guile is calling exit?
None. gh_enter is returning
Hi Guys,
I do not know if this is too aggressive or not, but I had to add this
to my valgrind "suppress this junk" file. It would be nice if someone
verified that the suppressed warnings are correctly suppressed and then
distributed the thing. It makes hunting down my own memory issues
a bit ea
x27;s a GNU tool, so any GNU archive should have it.
Bruce Korb is the author, and he is (kindly) working with me on this
project as we're doing some new things with it.
Just a quick note, Ive got to take a shower and get down to the lab.
But, pulled autogen from www.gnu.org, tried com
Someone, please correct me if I am wrong, but I think GCC-4 is
still too green for industrial use. Have you a GCC-3.x handy?
Reg Clemens wrote:
Hi Harlan, Reg, NTP developers (via relay) & Guile developers:
This is a problem. I (almost) only ever use pre-built Guile
packages and let others st
Reg Clemens wrote:
Humm.
Linux Fedora4 came with gcc 4.00 and was upgraded to 4.0.2 as some point,
so I dont easily have access to an older version on my home machines.
Checking at the Lab, where I still have Fedora2 loaded, I find gcc 3.3.3,
and guile-1.6.7 DOES compile there.
Still, the error
Bruce Korb wrote:
So, it seems to me that there is an inconsistency in the build
environment
and the defining of DYNAMIC_LINKING. The problem is almost certainly
in Guile. But, I have heard complaints (that I only fuzzily remember)
that Guile does not build with GCC-4. Assuming I am
Rob Browning wrote:
Bruce Korb <[EMAIL PROTECTED]> writes:
Guile folks, please, how is this supposed to work? The guile.c
module needs to see all three of these code fragments to compile
correctly. Anyway, for me it builds with GCC 3.x and fails with
4.x, but looks like it should f
Jason Meade wrote:
Is there a standard for regular expressions somewhere?
"a standard"? No. "are standards"? Yes. Many. Naturally,
that is the problem.
It seems like
most implements (from grep through tcl, perl, and beyond) seem to
agree on simple stuff like ^[a-c]?002*[^b]+$ etc... (not
Hi,
Um. I did. This is all I find:
-- Macro: char * SCM_STRING_CHARS (SCM X)
-- Macro: char * SCM_SYMBOL_CHARS (SCM X)
Return a pointer to the characters of X. The result is undefined
if X is not a symbol or string, respectively.
There are also a few magic values stuffed into memor
On 8/10/06, Greg Troxel <[EMAIL PROTECTED]> wrote:
Here's the list of programs that use guile (1.6) in pkgsrc.
./cad/libgeda
./databases/guile-pg
./devel/autogen
Does any know of any problems with any of them with 1.8?
I am trying to iron out "deprecated constructs" in autogen.
The latest r
Hi,
I've seen the manual. For Guile 1.8 it says:
-- Macro: char * SCM_STRING_CHARS (SCM X)
-- Macro: char * SCM_SYMBOL_CHARS (SCM X)
Return a pointer to the characters of X. The result is undefined
if X is not a symbol or string, respectively.
There are also a few magic values
Neil Jerram wrote:
Bruce Korb <[EMAIL PROTECTED]> writes:
Here's the deal: I just want access to the array of characters.
OK, for this you should use scm_to_locale_string().
Which allocates and copies, leaving the free() to me.
At least I get what I have to have. I did not find
/usr/local/gnu/include/libguile/smob.h:149: warning: declaration of 'free'
shadows a global declaration
/usr/local/gnu/include/libguile/filesys.h:75: warning: declaration of 'dirname'
shadows a global declaration
/usr/local/gnu/include/libguile/ports.h:233: warning: declaration of 'write'
shado
On 9/25/06, Ludovic Courtès <[EMAIL PROTECTED]> wrote:
Hi,
Bruce Korb <[EMAIL PROTECTED]> writes:
> /usr/local/gnu/include/libguile/smob.h:149: warning: declaration of 'free'
shadows a global declaration
> /usr/local/gnu/include/libguile/filesys.h:75: warni
Hi Ludovic,
On 9/25/06, Ludovic Courtès <[EMAIL PROTECTED]> wrote:
> GCC on Solaris. I agree that it is just a documentation name and serves
> no other purpose, but there it is. I do like -Wshadow, but it is not so
useful
> if cluttered up with these spurious messages.
So _all_ these message
Han-Wen Nienhuys wrote:
> I tend to disagree.
>
> At the current release rate of GUILE, I'd expect anyone using GUILE
> seriously to run the CVS version. I do, at least.
The last time I looked, you could find the 1.4 series being released
with some BSD distributions. That means my stuff has t
Han-Wen Nienhuys wrote:
> Bruce Korb escreveu:
>> By the way, have you all given any consideration to releasing a
>> valgrind config file that would clean out valgrind chaff?
>> I recently needed to do a valgrind run and it was quite painful.
>
> I always use the file
Han-Wen Nienhuys wrote:
> Well, as long as we keep 'supporting' the 1.4 interfaces, there is little
> incentive for developers to upgrade to the 1.6 or 1.8 API.
Let me be clear about this: it is (most likely) not the developers.
It is my clients. Some of them upgrade to bleeding edge Guile and
t
Han-Wen Nienhuys wrote:
By the way, have you all given any consideration to releasing a
valgrind config file that would clean out valgrind chaff?
>>> I always use the file below. I am not sure what the best way to
>>> distribute it would be.
>> I think there are two reasonable ways:
>>
Ludovic Courte`s wrote:
> Hi,
>
> Eventually, we may want to switch to LGPLv3. As you may already know,
> the main issue is that releasing `libguile' under LGPLv3 will preclude
> applications released under the GPLv2 *only* from using it [0].
...
> Opinions?
Ask the Guile user list? Isn't that w
test X"$TMPDIR" = X && TMPDIR=/tmp
> > +if [ x"$TMPDIR" = x ]; then TMPDIR="/tmp" ; else : ; fi
much less clutter.
# Don't use :- since 4.3BSD and earlier shells don't like it.
Amazing. Here I thought Solaris' /bin/sh was about as
decrepit as one could get nowadays
Our main development server was "upgraded" to 64 bits, but mostly
still runs 32 bit software,
so this is from a 32 bit build on a 64 bit platform. Naturally, this
all works on 32 on 32 and
on 64 on 64. But with 32 on 64, not so well:
Program received signal SIGSEGV, Segmentation fault.
0xb7f482f
On Wed, Jun 18, 2008 at 12:29 PM, Greg Troxel <[EMAIL PROTECTED]> wrote:
> Our main development server was "upgraded" to 64 bits, but mostly
> still runs 32 bit software,
> so this is from a 32 bit build on a 64 bit platform. Naturally, this
> all works on 32 on 32 and
> on 64 on 64. But wit
Ludovic Courte`s wrote:
Hi,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
Do we have a consensus?
Yes, fine by me, but no rush. ;-)
From a Guile-user and not developer perspective, the sequence needs to be:
1. the most retrograde platform must have all the GH capabilities in
the SCM int
Hi Neil,
On Sun, Sep 21, 2008 at 2:40 AM, Neil Jerram <[EMAIL PROTECTED]> wrote:
> Hi Bruce, and thanks for your input on this...
>
> 2008/9/18 Bruce Korb <[EMAIL PROTECTED]>:
>> 1. the most retrograde platform must have all the GH capabilities in
>> the SCM i
Hi,
On Mon, Sep 22, 2008 at 8:16 AM, Ludovic Courtès <[EMAIL PROTECTED]> wrote:
>> SCM expr = scm_makfrom0str( pzExpr );
>
> That's deprecated as of 1.8, use `scm_from_locale_string ()'.
This is used iff Guile antedates 1.6. I guess that can be junked now?
>> scm_t_port* pt;
>
101 - 148 of 148 matches
Mail list logo
