Andy Wingo writes:
> Hi,
>
> On Mon 05 Dec 2011 15:54, Andy Wingo writes:
>
>> On Mon 05 Dec 2011 09:11, David Kastrup writes:
>>
>>> David Kastrup writes:
>>>
> (symbol-set! #f (string->symbol name) value)
(module-define! (current-module) (string->symbol name) value)
>>
>> Indeed, th
I wrote:
> 3. Make scm_nullstr into a mutable string. After all, it can't be
>changed anyway, and the _only_ reference to it is from
>scm_from_stringn, so the result should always be mutable.
For the record: my statement above was in error; scm_nullstr is actually
used in several files.
Bruce Korb writes:
> On 01/06/12 15:11, Mark H Weaver wrote:
>> Bruce Korb writes:
>>> scm_from_locale_stringn() makes an optimization when the length is zero.
>>> It returns an immutable string of length zero.
>>
>> Good catch!
>>
>>> Two possible fixes:
>>>
>>> 1. remove the "optimization"
>>>
> From: Mark H Weaver
>
> I wrote:
>> 3. Make scm_nullstr into a mutable string. After all, it can't be
>> changed anyway, and the _only_ reference to it is from
>> scm_from_stringn, so the result should always be mutable.
>
> For the record: my statement above was in error; scm_nullst
On 01/07/12 07:00, Mark H Weaver wrote:
I think you are presuming that that is the only source of zero length
immutable strings. Are you completely certain?
Empty string literals ("") in the program text are still immutable, so
(string-upcase! "") still throws an error.
I admit that this is a
> From a8da72937ff4d04e8d39531773cc05e676b2be1c Mon Sep 17 00:00:00 2001
> From: Mark H Weaver
> Date: Wed, 4 Jan 2012 17:59:27 -0500
> Subject: [PATCH] Fix bugs related to mutation-sharing substrings
>
> * libguile/strings.c (scm_i_is_narrow_string, scm_i_try_narrow_string,
> scm_i_string_set_x
Mark H Weaver writes:
> Empty string literals ("") in the program text are still immutable, so
> (string-upcase! "") still throws an error.
>
> I admit that this is an arguable point. Section 3.4 (Storage model) of
> the R5RS (and the R7RS draft) says "It is an error to attempt to store a
> new
Bruce Korb writes:
> Fail early and fail hard. Yes. But after all these discussions, I
> now doubt I have too many places where I am expecting to change a
> static value.
That's good news! :)
> Most of the strings that I wind up altering are created with a
> scm_from_locale_string() C function
On Sat 07 Jan 2012 16:43, Mark H Weaver writes:
>> Subject: [PATCH] Fix bugs related to mutation-sharing substrings
Cool!
> I committed this. Here's an example that segfaulted before these fixes:
>
> scheme@(guile-user)> (define s (string-copy "hello"))
> scheme@(guile-user)> (define ss (s
Bruce Korb writes:
> On 01/07/12 07:00, Mark H Weaver wrote:
>> The right place to fix this would probably be in
>> `scm_i_string_start_writing' (strings.c).
>
> I think it too much effort for that function. I looked at it.
> The problem is that you'd have to pass it the start and end points,
> t
Neil Jerram writes:
> I'm afraid I can't help in detail with those other ones, as I don't have
> those systems.
I should note that if anyone does come up with ideas or patches that
they'd like to try, I can test them.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-
David Kastrup writes:
> Mutating list operations are allowed on '() (and do not change it).
> '(), the empty list structure, is eq? to itself regardless how you
> arrived at it.
Excellent point. The R5RS says that `list' returns "a newly allocated
list", but that's obviously not true for (list).
Andy Wingo writes:
> Here's the thing, I think: FOO and (local-eval FOO (the-environment))
> should be equivalent.
Agreed. This is the equivalence that we should strive to achieve.
My simple patch honors this equivalence for the bindings that it
supports (which unfortunately does not yet includ
On 01/07/12 08:13, Mark H Weaver wrote:
Most of the strings that I wind up altering are created with a
scm_from_locale_string() C function call.
BTW, beware that scm_from_locale_string() is only appropriate for
strings that came from the user (e.g. command-line arguments, reading
from a port, e
On 01/07/12 08:38, Mark H Weaver wrote:
* Modify the interface to `scm_i_string_start_writing' to give it the
`start' and `end' indices.
* Add checks to all string mutation functions: if the range is empty,
then avoid calling `scm_i_string_start_writing'.
Yes. All of them. All four.
slight mistake in the last one, So I've sent another patch
<<< message/external-body; name*=us-ascii''~%2fsrc%2fguile%2f0001-document-syntax-parameters.patch; access-type=local-file: Unrecognized >>>
Bruce Korb writes:
> On 01/07/12 08:13, Mark H Weaver wrote:
>>> Most of the strings that I wind up altering are created with a
>>> scm_from_locale_string() C function call.
>>
>> BTW, beware that scm_from_locale_string() is only appropriate for
>> strings that came from the user (e.g. command-li
Neil Jerram writes:
> So, just to be clear, the sequence of events for libgc is
>
> - start from 9448012a
> - apply 0001-Debian-7.1-8.patch
> - apply 0001-Tweaks-for-successful-dpkg-buildpackage-using-libgc-.patch
So do I understand correctly that in order for this to work, we'll first
need an u
On Tue 03 Jan 2012 11:52, Mark H Weaver writes:
> +(define-record-type lexical-environment-type
> + (make-lexical-environment wrapper names boxes others module-name)
> + lexical-environment?
> + (wrapper lexenv-wrapper)
> + (names lexenv-names)
> + (boxes lexenv-boxes)
> + (
On Wed 04 Jan 2012 01:06, Mark H Weaver writes:
> Here's an improved version of the patch. Most notably, I removed the
> `#:to' parameter to `local-compile', since I realized it couldn't be
> implemented properly anyway. I also updated the copyright notices to
> 2012 in all changed files, and m
Bruce Korb writes:
> On 01/07/12 08:13, Mark H Weaver wrote:
>>> Most of the strings that I wind up altering are created with a
>>> scm_from_locale_string() C function call.
>>
>> BTW, beware that scm_from_locale_string() is only appropriate for
>> strings that came from the user (e.g. command-li
Replying to myself...
> Again, I stress that this has nothing to do with Guile. All software,
> if it wishes to be properly internationalized, needs to think about
> where a string came from. In general, your program's source code (and
> thus the C string literals it contains) will have a differ
Hi Andy, thanks for the code review! :)
Andy Wingo writes:
> On Tue 03 Jan 2012 11:52, Mark H Weaver writes:
>
>> +(define-record-type lexical-environment-type
>> + (make-lexical-environment wrapper names boxes others module-name)
>> + lexical-environment?
>> + (wrapper lexenv-wrapper)
>>
Mark H Weaver writes:
> As I understand it, in the Scheme standards (at least before R6RS's
> immutable pairs) the rationale behind marking literal constants as
> immutable is solely to avoid needlessly making copies of those literals,
> while flagging accidental attempts to modify them, since th
Hi Mark,
On Sat 07 Jan 2012 21:20, Mark H Weaver writes:
> The problem is that primitive-eval does not represent lexical variables
> as variable objects.
True.
> We could change that, but I'm reluctant to make the evaluator any
> slower than it already is.
Using variable objects has the possi
Hi,
Mark H Weaver skribis:
> I wrote:
>> 3. Make scm_nullstr into a mutable string. After all, it can't be
>>changed anyway, and the _only_ reference to it is from
>>scm_from_stringn, so the result should always be mutable.
>
> For the record: my statement above was in error; scm_nullst
Hi Andy, thanks for getting back to me. Considering the amount of mail you
must have to deal with, I'm surprised you're able to get way back to
November to follow up.
On 7 January 2012 04:04, Andy Wingo wrote:
> * Examine the state of things
> * Remind myself where we want to go
> * Figure ou
Hi!
Andy Wingo skribis:
> Are you OK with adding them like this:
>
> (define-syntax (when condition stmt stmt* ...)
>(if condition (begin stmt stmt* ...)))
>
> (define-syntax (unless condition stmt stmt* ...)
>(if (not condition) (begin stmt stmt* ...)))
Yes!
(‘define-syntax-rule’ I
On Fri 30 Dec 2011 16:12, Nala Ginrut writes:
> So the previous discussion didn't make this proc put into Guile?
> Now that so many people interested in this topic.
I think it would make a nice addition to (ice-9 regexp). I don't think
we need to capture the delimiters though; some other funct
Hi,
Andy Wingo skribis:
> Guile's REPL does do that, yes. I think that Noah's proposal was to pun
> the ,language command so that in a file, instead of
>
>#!lang r5rs
>(eval '(+ 1 2) (scheme-report-environment 5))
>
> you could have
>
>,language r5rs
>(eval '(+ 1 2) (scheme-rep
On Sat 31 Dec 2011 06:54, Daniel Hartwig writes:
> An attempt to summarize the pertinent points of the thread [1].
>
> [1]
> http://lists.gnu.org/archive/html/guile-devel/2011-12/msg00241.html
Thanks for doing this! I replied earlier without having read this
thread. Sorry for being a serial pr
On Tue 03 Jan 2012 23:28, Mike Gran writes:
>> From: Ludovic Courtès
>>> scm_sym2var
>>
>> It’s public for historical reason, but I personally don’t like it,
>> because it has a stupid name and complex semantics. ;-)
>
>>
>> Depending on what you’re doing, you may be able to use one of the
On Mon 02 Jan 2012 04:04, Mike Gran writes:
> scm_new_port_table_entry
As Ludo says, the port implementation is terrible underdocumented. But,
this function isn't really so great. It is what is available in 2.0,
but in 2.2 there are a couple of versions that work better:
scm_c_make_port, and s
Hi Mark,
On Thu 05 Jan 2012 18:20, Mark H Weaver writes:
> Andy Wingo writes:
>>> * Is there any way to embed references to non-serializable objects in
>>> compiled code?
>>
>> No. Can you give an example of when you would want this?
>
> My more complex `the-environment' patch fully supports
On Sat 07 Jan 2012 18:37, Ian Price writes:
> slight mistake in the last one, So I've sent another patch
Sorry for being an idiot, but I'm not able to download this one. Can
you send it again as a plaintext attachment?
Andy
--
http://wingolog.org/
Hello,
I'm going to try to combine the two parallel compiler threads into
one, by replying to two messages at once. I hope this makes things
simpler rather than more confusing. :-)
Message 1:
> Here is my calculus regarding this work, FWIW: it is low risk, and low
> cost, since it doesn't actual
Okay, let me see if this is right now.
In the expression
(list (call-with-current-continuation func) (+ 4 14)),
you want the addition to be done before the
call-with-current-continuation, as opposed to being part of the
continuation.
Right?
Noah
On Wed, Jan 4, 2012 at 9:00 AM, David Kastrup
Hi,
Andy Wingo skribis:
> On Sat 08 Oct 2011 18:04, l...@gnu.org (Ludovic Courtès) writes:
>
>>> And what about the seldom-used SCM_ASRTGO?
>>
>> Likewise (Google Codesearch finds a couple of external users.)
>
> Uf, I replied before I saw your message. It is gone in master. Do you
> think we
Andy Wingo writes:
> On Sat 07 Jan 2012 18:37, Ian Price writes:
>
>> slight mistake in the last one, So I've sent another patch
>
> Sorry for being an idiot, but I'm not able to download this one. Can
> you send it again as a plaintext attachment?
I thought I had, but it looks like I'd made a
Hi Ian!
Ian Price writes:
> Mark H Weaver writes:
>
>> As I understand it, in the Scheme standards (at least before R6RS's
>> immutable pairs) the rationale behind marking literal constants as
>> immutable is solely to avoid needlessly making copies of those literals,
>> while flagging accident
40 matches
Mail list logo
