"Nelson H. F. Beebe" <[EMAIL PROTECTED]> writes:
>
> Subtracting one produces a significant of all
> 1-bits: 2**53 - 1 = +0x1.fp+52,
Yes.
> and that is the
> next-to-largest exactly representable whole number in this arithmetic
> system. Its floor is identical, so "x == floor()" is
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Please, do read the thread on `bug-gnulib'.
I did.
> Widespread libraries already fixed the problem,
No.
> the most straightforward solution being to
> use Libtool's `-export-symbols-regex' link option (which is a single
> line in `Makefile.am').
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> No it can't. AFAICS, there's nothing in the C standard forcing fields
> of unions to be stored at offset zero when said fields have different
> sizes.
Union elements start at the start of the combined space. In particular
if the elements are struct
Rob Browning <[EMAIL PROTECTED]> writes:
>
> Perhaps Guile should use a different name for the threaded libs if
> they're not compatible.
I suppose that'd help against mysterious crashes, but leaves the same
problem as in every incompatibility, ie. that add-ons do or don't
switch, making various c
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> I have not taken any action yet but what you suggest is doable.
Revert it for now, and look again if/when there's a system for
libraries. (And not the first blush version of something, give it a
chance for someone else to be the guinea pigs.)
Whil
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> `accept' would randomly yield a "bus error" on SPARC).
Looks ok.
> + if (((struct sockaddr *) &addr)->sa_family ...
That can use the union member instead of a cast, can it?
___
Guile-devel mailing list
I gave Rob's new debian packaged 1.8.2 a go and found a bit of a problem
with scm_cell. The new packages have threads enabled, where the old
ones had it disabled, and alas that setting infects the inlined
scm_cell(). If you built your app against the old and run it against
the new then it bombs o
Greg Troxel <[EMAIL PROTECTED]> writes:
>
> During the thread test, I got 69 instances of:
>
> guile: Error detected by libpthread: Unlocking unlocked mutex.
> Detected by file
> "/usr/home/gdt/NetBSD-current/src/lib/libpthread/pthread_mutex.c", line 357,
> function "pthread_mutex_unlock".
I sup
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> As good as 1.6?
Total space is bigger, but at least it doesn't grow unboundedly.
> Hopefully removal of globals made it slightly simpler to follow...
No, that's made it harder to see what actually changed. I suppose a
block copy of the changes wit
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> `(%make-void-port "r")' would have the same effect
Yes, that'd be fine.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> /* Return a list of ports using a given file descriptor. */
> SCM_DEFINE (scm_fdes_to_ports, "fdes->ports", 1, 0, 0,
> (SCM fd),
I didn't think of that one.
> void
> -scm_remove_from_port_table (SCM port)
> -#define FUNC_NAME "scm_
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Did you actually trigger it
Yes, it broke the self-tests of my lint program. :) (My program assumed
any pair returned by the reader would have source properties. I've
loosened that, since at least in principle it might not be true of stuff
generate
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> +scm_read_quote (int chr, SCM port)
I think you may have lost source properties from quote and quasi-quote
forms,
(read-enable 'positions)
(source-properties (read (open-input-string "'x")))
=> ()
There wasn't a case in read
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Did you try running it with HEAD? There were small GC-stats "cleanups"
> committed there that are not in 1.8, so it may be worth trying.
Ah yes, it's better there. What bit is the operative fix? Both the
per-freelist min_yield adjust and the count
Actually I see the flush func of a soft port is entirely unused, it's
never called by a force-output because nothing is ever put in the port
buffer as such. The manual could be clearer about what it's supposed to
be for :-(.
At any rate, I put in the failing test below for port-for-each, and I
th
Is it supposed to work to set the default duplicates handling to an
empty list? Eg. foo.scm containing
(define-module (foo)
#:duplicates ()
#:use-module (srfi srfi-1))
(pk map)
It seems to work in 1.8, but in the head it's giving
=> Unbound variable:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> In the latter case, GC would modify the port table, potentially beneath
> the feet of functions that iterate over it, or that cached indices
> within the table, things like that.
I think you're meant to hold scm_i_port_table_mutex if looking at or
mo
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Changing `record-accessor' as in the attached file yields
Gets rid of one scheme function call in the normal case does it?
I expect an apply-able smob thingie would be fastest (and smaller too)
for accessors and modifiers, if anyone felt like going
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> However, the `strcasecmp' module gets compiled iff `strcasecmp' was
> not found at configure time.
The problem is if other libraries do the same thing, ie. put an
strcasecmp in. I expect you get clashes that'd stop an application
using certain combi
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> How about switching from CVS to Git [0]?
I would say no. All these other revision systems seem to come and go,
but their supposed features rarely seem to justify the learning curve
(the frequently steep, time consuming, and frustrating curve :-).
>
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> `struct-copy' must check fields permission
I didn't want to do that.
> `s' fields must be updated
Ah yes, I forgot that.
> `o' fields cannot be copied I think.
I had in mind just bitwise copying them. But I guess that slightly
defeats the purpos
I've struck, in 1.8, port-for-each passing a freed cell to its iterator
func. Eg. "guile -s foo.scm" on
(define lst '())
(gc) (gc) (gc)
(make-list 1000)
(open-input-file "/etc/passwd")
(make-list 1000)
(open-input-file "/etc/passwd")
(make-list 1000)
(open-input-fi
This is an idea I had for copying structures, mainly to make a
`record-copy' function (just an alias of struct-copy). I've found it
pretty useful.
You can do a record copy with `record-constructor' and a map over
`record-accessor' for each field, but of course a block copy is heaps
more efficient
I'm having trouble in my charting program with the amount of heap space
allocated for cells in 1.8. It ends up allocating more and more heap
(as reported by gc-stats 'cell-heap-segments and confirmed by
mallinfo()), apparently without bound. I've got between 150k and 200k
objects according to gc-
"Mikael Djurfeldt" <[EMAIL PROTECTED]> writes:
>
> Yes, ideally, you should coordinate this with Aubrey. Why not explain
> the situation for him? I think the simplest solution would be to use
> the main idea of (ice-9 slib) explained above. Maybe Aubrey could
> strip down guile.init a bit so tha
Greg Troxel <[EMAIL PROTECTED]> writes:
>
> Running threads.test
> guile: Error detected by libpthread: Unlocking unlocked mutex.
> Detected by file
> "/usr/home/gdt/NetBSD-current/src/lib/libpthread/pthread_mutex.c", line 357,
> function "pthread_mutex_unlock".
Sounds bad.
> Perhaps someone co
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Currently, the only imported modules are `alloca' and `strcasecmp'
> (see `m4/gnulib-cache.m4').
What prefix does it put on the names that get into libguile.so?
It's not namespace clean to have an strcasecmp() in libguile (likely
to create subtle hav
gc-live-object-stats returns big, real and complex numbers only as "tag
23" (which is scm_tc7_number). I'm looking at the following to fix
that, and also get separate counts of each type.
* gc-card.c (scm_i_card_statistics): Record scm_tc7_number types as
tc16 values so big, real,
"Mikael Djurfeldt" <[EMAIL PROTECTED]> writes:
>
> Isn't the original and only purpose of Guile's provide/require to be
> part of support for slib?
It wasn't a clone of what's in emacs was it? And/or a way to have
built-time optional bits present or not in the guile core, like threads?
"Mikael Djurfeldt" <[EMAIL PROTECTED]> writes:
>
> slib.scm makes sure that each time
> some module requires new slib code, it will be loaded into the module
> (ice-9 slib) and exported from there. I'm not at all sure that
> guile.init does that,
I suspect it doesn't. It'd be cute if going throu
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> replacement `cexp ()'
I think I have to put my hand up for some of the blame there. I added
those uses of cexp and friends, but made the rash assumption that if
"complex double" exists then the functions do.
My intention (never acted on) was to sim
I did a branch merge for my recent bits. There's enough pointless
changes in the head I'll probably give up on that soon.
At any rate the bit below has conflicts. Perhaps it's already in the
head, or perhaps it's not wanted. But I don't understand either it or
the changes it conflicts with, so
What is struct-vtable-tag meant to be for? Or what can be said about
it in the manual?
I see it's the given vtable's data array address, munged by a
divide-by-8. But I can't tell if it's meant as an id, or for hashing,
or what.
___
Guile-devel mailin
I wrote:
>
> rdelim `read-line'
Oops, I confused myself. It already looks in the buffer - it's the
model not the improvable - a few more bits could be like it ...
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/g
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> N calls to `scm_getc ()'
Speaking of scm_getc ... I've wondered for a while if some of the low
level reading funcs ought to be looking directly into the read buffer
instead of making a call to scm_getc for every char. My experience
has usually been
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> of `scm_getc ()' translates in one `scm_fill_input ()' call, which in
> turn translates in one `select ()' and one `read ()'
Coming back to this bit: that select really does seem pretty doubtful.
The more I think the more it sounds like a hangover fr
I'm looking at the code below for my new `make-vtable'. I'm still not
completely convinced it's a great idea, but it does at least find a
use in stacks.c, so it can't be all bad!
--- struct.c.~1.111.2.6.~ 2007-03-06 11:19:49.0 +1100
+++ struct.c 2007-03-06 11:20:55.0 +1100
@@ -560
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> +SCM_DEFINE (scm_setvbuf_output, "setvbuf-output", 2, 0, 0,
> + (SCM port, SCM size),
Can that take a mode, so it's possible to set _IOLBF ?
setvbuf-input could also take a mode, though _IOLBF wouldn't be wanted
there, but it'd make the args
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> There's `scm_c_read ()' for "read N bytes", but it translates into N
> calls to `scm_getc ()'.
Then that's where it can best be fixed.
> IMO it feels wrong to dismiss the port abstraction
There's nothing super fantastic about the ptab funcs, there'
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> 1. I don't understand how `scm_shap2ra ()' is supposed to behave when
> LBND > UBND since it doesn't check it.
Dunno, except that in general "(10 9)" makes an empty array these
days, but say "(10 8)" is an error.
> Should it instead inve
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
>(uniform-vector-read! vec port)))
Slackness in the implementation of that function. It knows a size to
read and should come out as a read() system call of that size. Yet it
always goes through the port buffer. You need to post the probl
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Below is a tentative patch (I chose more meaningful names since they
> don't relate to `setvbuf(3)').
Call them setvbuf. Two names for the same thing is more confusing
than one (slightly obscure) name.
> Besides, how about applying the change I ori
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> "tail array not allowed if struct has a zero length layout"
You don't think "unless ends in R,W,O" is enough to exclude an empty
layout? The aim, slightly, is to hint at the solution within the
error message, for the benefit of those not 100% up with ho
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> I have played with a few
> TCP-based Guile applications (including the Emacs debugging interface)
> and not noticed any obvious performance problem.
Likewise. I've been reading http headers byte by byte - because I was
too lazy to do it properly yet - w
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Right. That's an incompatible change if the _output_ is buffered.
> Input can be buffered, though, without this being visible by users.
Alas, that too is in an incompatible change, because recv! ignores
buffering.
> Fortunately, port buffering does
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Writing in C or assembly doesn't free from choosing appropriate
> algorithms.
It's rather unfair to the data structure to say it's no good when
there's likely to be an easy speedup between perhaps 2x and 5x. In
principle all core primitives should b
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> Where are you seeing that, in the manual or in the libltdl code?
The ltdl.c code, in try_dlopen,
/* Now try to open the .la file. If there is no directory name
component, try to find it first in user_search_path and then other
p
I'm looking at this to allow non-zero tail array only when the layout
provides for it. I think all the internal uses of structs have no
tail array (and a zero size) so that should all be ok. Dunno if
anyone else might have used the tail size to get some sneaky extra
space. Sounds like the wrong
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Well it _does_ hurt, even with real-life numbers of imports, as the
> experiments I made tend to show
If that's true you'll have to start from the beginning again,
everyone's eyes glaze over at "1000 modules".
> From a performance viewpoint, the que
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Is there a reason why `SCM_SOCK_FD_TO_PORT ()' in `socket.c' asks for an
> unbuffered port?
To make send and receive conversations reliable, according to sockets
section in the manual. (I don't think I added that. I hope I'm not
claiming my own wor
Steven Wu <[EMAIL PROTECTED]> writes:
>
> + start = pthread_get_stackaddr_np (self_id); \
Thanks, in fact we have some code in the cvs with that,
/* This method for MacOS X.
It'd be nice if there was some documentation on pthread_get_stackaddr_np,
but as of 2006 there's nothing
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> I noticed from strace (below) that, on my machine, ltdl tries to open
> libguile-i18n-v-0.so from libguile/.libs, once it has failed with the
> locations in LTDL_LIBRARY_PATH. I'm guessing that this is a piece of
> fallback "try to open .so in the same d
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Ok to commit?
No. Please don't move stuff around, it works fine like it is.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> The measurements in the `module-duplicates.scm' file I posted choose
> USES = 1 by default, which is arguably unrealistic.
Was that 1 imported modules? That's well outside the realm of
reason! :) Normally there'll be perhaps up to 20 import
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> -subdirs_with_ltlibs="srfi guile-readline" # maintain me
> +subdirs_with_ltlibs="srfi guile-readline libguile" # maintain me
Yep, sounds right.
___
Guile-devel mailing list
Guile-devel@gnu.org
htt
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Actually, `process-duplicates' is O(N*USES) _for each module used_. So
> the overall duplicate processing is really O(N*USES^2). With the
> patched version, the whole process is O(N*USES). That can make quite a
> difference when USES > 1.
It shoul
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> That's a fair point, but IMO Kevin's doc layout allows for it by
> putting the vtable-vtable stuff last.
It's last because it's the most brain twisting :).
Is the "ball" example your code? It looks fairly typical (a "colour"
field in the vtable which i
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> (1) has to do mainly with `module-use!' vs. `module-use-interfaces!' (as
> was discussed recently). Namely the fact that duplicate processing is
> not always performed, depending on whether one uses `module-use!' or
> some other means to use a module
I had a bit of a go at polishing the docs on sleep, usleep, getitimer
and setitimer. The bit that said usleep wasn't available on all
platforms wasn't true any more, it goes via the common select
mechanism, so it doesn't matter if there's a usleep() library func or
not.
-- Scheme Procedure: sle
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> When creating stack
> objects with (roughly) `(make-struct stack-type)', VTABLE is _not_
> consulted at all. The layout of stack objects is determined only by
> that specified in SCM_STACK_TYPE.
Yes.
> Thus, VTABLE is redundant.
Well, except for t
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> I'm not sure the indirection in `scm_init_stacks ()' is needed since it
> uses STACK_LAYOUT for both VTABLE and SCM_STACK_TYPE,
Not sure what you mean there.
> and `make-struct'
> doesn't look at the vtable's vtable anyway (when creating instances o
Unless it's meant to be a secret :), I thought I'd show the printer
func argument of make-record-type in the manual,
-- Scheme Procedure: make-record-type type-name field-names [printer]
Create and return a new "record-type descriptor".
TYPE-NAME is a string naming the type. Currentl
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> (let* ((vtable (make-vtable-vtable "pr" 0))
> (s1 (make-struct vtable 0 "hello"))
> (s2 (make-struct vtable 0 "hello")))
>;; S1 and S2 are both "regular" one-field structs.
I know the "values" struct is do
I made a bit of a start trying to improve the structures section of
the manual, I always found it pretty hard to follow. One big
stumbling block for me was vtables, but I now see if you want to make
a struct you have to make a vtable vtable, and from that a vtable, and
only then your struct. Seem
Brought across from bug-guile ...
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Actually, `scm_i_struct_equalp ()' should also compare the "tail
> elements" (when there are tail elements),
Is it as easy as using getting the size (of each) from
"scm_struct_i_n_words", instead of just using the l
Another error thrown from within an SCM_CRITICAL_SECTION_START,
(define vv (make-vtable-vtable "" 0))
(define v (make-struct vv 0 (make-struct-layout "uw")))
(make-struct v 0 'x)
=> abort
scm_make_struct has a critical section around the struct
initialization, but
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> (1) autoreconf exits with error status, because it thinks that the
> expansion of AM_GNU_GETTEXT requires a definition of
> AM_INTL_SUBDIR, and AM_INTL_SUBDIR isn't defined.
If it thinks that then I guess it's not recognising "external" in
AM_GNU
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> Anyway, does the 1.8 ChangeLog look OK now?
Yes, but I think I changed my mind about putting it in at the orginal
date. That might make it look like it was in 1.8.0 or 1.8.1 (which it
wasn't of course). Would you like to move it up to a current date,
a
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Not possible, because "Internationalization" already names the parent
> node, and "Introduction" alone probably isn't a good idea.
"Internationalization Introduction" will be a goer then. It's
self-explanatory so there's no need for extra words on t
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> One detail of the merging... I gather we're preferring to merge
> ChangeLog fragments directly, so as to minimize the diffs between the
> ChangeLogs in two branches,
Yep.
> This seems fine to me, but it does mean we lose info about when the
> change wa
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> (Doing AM_GNU_GETTEXT_VERSION causes autopoint to be run, which causes
> the creation of a po subdir, with various boilerplate files, but I see
> no harm in that.)
An actual release doesn't have a po subdir yet does it? Can you make
the autogen give wha
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> col is 0x0FFF max, which 4096. Seems plenty for me.
ice-9/psyntax.pp overflows it. You need to make sure unusually big
values don't result in garbage, even if the storage is optimized for
sensible or usual cases.
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> [EMAIL PROTECTED] {Scheme Procedure} locale-yes-regexp [locale]
> [EMAIL PROTECTED] {Scheme Procedure} locale-no-regexp [locale]
> +Return a string that can be used as a regular expression to recognize
> +a positive (respectively, negative) response t
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> Perhaps, but I'm for cleaner code. Having to keep deprecated stuff
> around (and worse: having to write various deprecation wrappers for
> them) is detrimental to code quality.
I would say the contrary is worse. Users following the advertised
rules
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> As such, it does not conform to the GUILE naming standards.
Where? string-move! is the same, and copy-file is similar.
In any case as I said it can't be changed, but if you think the docs
are unclear then propose new words or a sentence of caution
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> what is the status of the eval options structure wrt binary compatibility?
I remeber now: changing the size of a data object in a shared library
breaks mainlines using it, or even just taking its address. And both
mainline and the library are broke
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Agreed, but that's only the name of the Info node. Changing it here
> would make the line too long for Info.
Call the node just "Internationalization" and then call the sub nodes
something else, that should fit fine. There's a good chance people
co
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> If not now, is there any sort of timescale for when this is scheduled?
Hopefully never for many bits. I think several things have been
tagged unnecessarily.
If something is not very nice, then by all means shunt it off to a
corner of the manual a
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> (trap-enable 'memoization)
> ?
My remark on "test_flag" was just that set-test-flag sounds like it
could be anything, and could perhaps be more cleanly handled in the
debug-options. trap-options would be also ok.
_
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> The idea is that eventually we could plug in `localeconv' support
> transparently, i.e., the user-visible API would remain the same but it
> would become capable of using `localeconv' when `nl-langinfo' is not
> available (that would work only for mon
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> 4. No attempt is made to convert to a different encoding the strings
> returned by `nl_langinfo ()'.
Good.
> 5. High-level procedures for locale-dependent number output are
> provided, namely `number->locale-string' and
> `monetar
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> Should this be fixed,
No, that'd be an incompatible change (it's in the manual).
Slightly unfortunate, but not the end of the world.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> It's ok for 1.9 to break binary compatibility,
Don't do it gratuitously though, just because something will look
better.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listi
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> does this also mean that we can (finally!) summarily throw away anything
> that is marked as "deprecated GUILE 1.7" ?
The short answer would be no, much too soon. The whole idea of
discouraged etc is really bad. Forcing everyone to change their
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> See attached patch.
Sounds worryingly specific to what you're doing. Perhaps something
which was just a hook to each function call made (by the debug
evaluator), with the memoized and unmemoized form if that's necessary.
> +int test_flag;
An entr
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> SCM
> scm_make_srcprops (long line, int col, SCM filename, SCM copy, SCM plist)
> {
> + if (!SCM_UNBNDP (filename))
> +plist = scm_acons (scm_sym_filename, filename, plist);
Can those two cells be shared among all source props for the same
f
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> why use a separate storage pool for srcprop objects?
At a guess, is it because that they're likely to never need freeing,
hence can be laid down in big blocks.
___
Guile-devel mailing list
Guile-devel@gn
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> From some outstanding reports, I'm not sure this area is fully
> correct yet,
Yep. As long as it's not going backwards of course :).
> Have you already done the merge of these changes to 1.8,
No.
> or should I do that?
Yes please.
>> * Is the readl
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> (define coverage-trap (make #:behaviour cover-entry))
You don't have to use goops to get a trap do you?
> guile-statprof does a better job of trying to mitigate the
> latter factor, so is in fact a better current bet for profiling Guile
> code.
I ex
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> ERROR: Unbound variable: exception:string-contains-nul
Oops, not enough checkin, fixed now.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> This might also be a good idea to apply to 1.8.
Yes, it's a bit obscure otherwise.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
I did another dreaded merge from the 1.8 onto the head. Insert the
usual whinge, but the specifics this time are:
* If it's going to be utf-8 for the changelogs then please make that
change in 1.8 too or merges are going to go haywire.
* Are the hpux ia64 bits meant to be in 1.8? If it's a po
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> Is argv normally NULL-terminated?
Yes, if it's from main().
> I would have thought that "argc-i" would be more reliable than "-1"
> here.
I guess it's clearer to use one method or the other (not a mixture).
I changed it to below (with set-program-argum
Incidentally, I called the scheme func "scm_set_program_arguments_scm",
because plain "scm_set_program_arguments" is taken by the C interface.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> (I wondered about (set-program-arguments . lst) instead of
> (set-program-arguments lst), but I suspect cases where you already
> have a list in hand will be more common.)
Yes, especially if you got it from a (program-arguments) call.
>> +"Progr
I wrote a few words for scm_set_program_arguments, which is mentioned
under scm_boot_guile but not otherwise described.
-- C Function: void scm_set_program_arguments (int argc, char **argv,
char *first)
Set the list of command line arguments to be returned by
`program-argume
How about making scm_set_program_arguments() available at the scheme
level too? As say
(set-program-arguments lst)
(without the "first" arg business of the C level).
The C func is good for when you munch some options at the C level in
an scm_boot_guile, having it at the scheme level wou
In regexp-exec in 1.8, a nul in the input string, or a bad flags arg,
results in a throw from a critical section, which calls abort(). Eg.
(regexp-exec (make-regexp "x") "\0")
=> abort
(regexp-exec (make-regexp "x") "hello" 0 'badflags)
=> abort
What's the reason
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> - at the top of deval(), find out current source file and line
I suppose even cuter would be tracking each form being evaluated, not
just by line. Does the debugger interface have some single step that
could help? (I've never gotten into that.)
Steve Ellcey <[EMAIL PROTECTED]> writes:
>
> switch (i) {
> case ((unsigned long) (0 ? (x = 4) : 4)):
>
> I am not sure if this is legal C or not
Looks doubtful for an "integer constant expression". It probably
bombs even worse on SCM_DEBUG_TYPING_STRICTNESS == 2 (though t
1 - 100 of 412 matches
Mail list logo
