Hello,
> >I'll try to test it here as well but i'll have to convert it to an
> > equivalent C code first.
>
> Out of interest, why is that? (It's easy enough to call Scheme-defined
> code from C, isn't it?)
Yes! I think i my mind is stuck in the world of C. :(
> That sounds more comple
Neil Jerram <[EMAIL PROTECTED]> writes:
> This way there is no magic, and the visibility of the plugin bindings
> is under the control of the plugin author. Also, this way you could
> stay pure-R5RS if you like, as you don't really need any features of
> the module system.
This made me wonder --
Hello again,
> > Why not use a registration
> > API instead? In other words, instead of this:
> >
> > (define (do-plugin-thing-1 ...) ...)
> > (define (do-plugin-thing-2 ...) ...)
> > ...
> >
> > do this:
> >
> > (let ()
> >(define (do-plugin-thing-1 ...) ...)
> >(define (do-plugin-thing
Kevin Ryde <[EMAIL PROTECTED]> writes:
> (I notice "write" style string output in iprin1() always goes
> char-by-char, it'd be nice if it scanned ahead for a char needing an
> escape, to send the non-escape block as a single lfwrite. Decent size
> runs of plain chars are probably quite likely.)
Zeeshan Ali wrote:
Hello,
It seems to survive 5 minutes of testing by me, but there could well be
problems lurking, so please test carefully in your context.
I'll try to test it here as well but i'll have to convert it to an
equivalent C code first.
Out of interest, why is that? (It's
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Obviously, the best solution would be to expose the relevant functions
> to the user. :-)
Yes, we should do that, following the scm_to and scm_from naming scheme.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_
Marius Vollmer wrote:
I agree that this is not really wanted. So I vote for removing the
last line of the code snippet above. The (guile) module is used
anyway in every module. Ok?
OK with me.
Neil
___
Guile-user mailing list
Guile-user
Ludovic Courtès wrote:
Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
Isn't the rule we want "whenever a new definition shadows an existing
definition in a module, and the existing definition did not originate
in the current module"? This rule would also avoid giving unwanted
warnings when an e
Rick Taube <[EMAIL PROTECTED]> writes:
> Im having a problem getting the srfi-1 definition of list-index (which
> is defined in both guile and srfi-1) to stay in effect when I load my
> system from the command line using the -l option. im not sure what is
> going wrong.
That is actually a 'featu
David Pirotte <[EMAIL PROTECTED]> writes:
> But passing a guile string containing glyphs symbols for non ascii
> characters does not work for all of them,
What happens?
> ps: is there any hope that guile handles internationalisation
> in its core modules some time soon?
Yes, but probabl
Hello,
> It seems to survive 5 minutes of testing by me, but there could well be
> problems lurking, so please test carefully in your context.
I'll try to test it here as well but i'll have to convert it to an
equivalent C code first.
BTW guys,
I have been told that the fate of 'undefi
Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
> Isn't the rule we want "whenever a new definition shadows an existing
> definition in a module, and the existing definition did not originate
> in the current module"? This rule would also avoid giving unwanted
> warnings when an edited module is rel
12 matches
Mail list logo
