On Thu, 2013-01-31 at 11:32 +0100, Andy Wingo wrote:
> Hi :)
>
> On Fri 25 Jan 2013 17:46, Nala Ginrut writes:
>
> > Users just need a way to know what languages could be specified to
> > --language option.
>
> Can you update the patch to use the language-for-humans? accesor that
> Mark pushed
Hello,
On Thu, Jan 31, 2013 at 5:00 PM, Ludovic Courtès wrote:
> There are several issues IMO. First, some are subrs, so handling
> keyword arguments is going to be painful. Second, keyword arguments are
> inelegant IMO compared to:
>
> (set-port-encoding! port (file-encoding port))
>
I do
Andy Wingo skribis:
> On Thu 31 Jan 2013 06:06, Mark H Weaver writes:
>
>> From: Mark H Weaver
>> Date: Wed, 30 Jan 2013 14:45:28 -0500
>> Subject: [PATCH] Do not scan for coding declarations in open-file.
>
> The patch looks good to me but I am concerned about the behavior
> change, and that i
Mark H Weaver skribis:
> My position is that the current coding-auto-detection behavior of
> 'open-file' is likely to lead to security flaws in software built using
> Guile. The issue is that programs that receive text from an untrusted
> source, write those strings to a file, and then read them
Hi!
Mark H Weaver skribis:
> I researched this some more, and discovered that removal of byte-order
> marks (BOMs) is the responsibility of iconv, which discards BOMs from
> the beginning of streams when using the UTF-16 or UTF-32 encodings, but
> *not* for UTF-16LE, UTF-16GE, UTF-32LE, UTF-32GE
On Thu 31 Jan 2013 19:58, Mark H Weaver writes:
>> My instinct is that we should not merge this patch without including a
>> way to enable the coding sniff; which seems to mean adding keywords or
>> somehow extending the arguments of:
>>
>> open-file
>> with-input-from-file
>> with-output-t
Hi Andy,
Andy Wingo writes:
> The patch looks good to me but I am concerned about the behavior
> change, and that it is inconvenient to get the previous behavior.
>
> My instinct is that we should not merge this patch without including a
> way to enable the coding sniff; which seems to mean addin
Andy Wingo writes:
> One more thing, Mark; would you mind handling merges to master? The
> port code got rearranged there and merges can be tricky.
Sounds good, but first I need to think a bit more about seeking, and
also about an additional complication regarding the possibility that the
input
Andy Wingo writes:
> Here is where I think this code goes wrong: its correctness appears to
> depend on the default port encoding. That is totally bogus. It was
> written long before we had such a thing.
>
> Again, I think the default encoding for a string port should be one that
> can represent
On Thu 31 Jan 2013 17:57, Alexei Matveev writes:
>>static const scm_t_bits my_false = 0x4;
>>static const scm_t_bits my_true = 0x404;
>>static const scm_t_bits my_nil = 0x104;
>>static const scm_t_bits my_eof = 0xa04;
>>static const scm_t_bits my_eol = 0x304;
>>static cons
>static const scm_t_bits my_false = 0x4;
>static const scm_t_bits my_true = 0x404;
>static const scm_t_bits my_nil = 0x104;
>static const scm_t_bits my_eof = 0xa04;
>static const scm_t_bits my_eol = 0x304;
>static const scm_t_bits my_unspecified = 0x804;
I get slightly diff
Sorry again.
Forget to add it into test-suite/Makefile.am
So many things to do for a new feature ;-)
On Thu, Jan 31, 2013 at 10:31 PM, Nala Ginrut wrote:
> Sorry, forget to add it into ice-9/Makefile.am
> Send again.
>
>
> On Thu, Jan 31, 2013 at 10:25 PM, Nala Ginrut wrote:
>
>> patch updated.
Sorry, forget to add it into ice-9/Makefile.am
Send again.
On Thu, Jan 31, 2013 at 10:25 PM, Nala Ginrut wrote:
> patch updated.
> Thanks!
>
>
> On Mon, Jan 28, 2013 at 10:56 PM, Nala Ginrut wrote:
>
>> Thanks David!
>> It's nice to know that, I thought Guile use PCRE, but I realized it's
>> p
patch updated.
Thanks!
On Mon, Jan 28, 2013 at 10:56 PM, Nala Ginrut wrote:
> Thanks David!
> It's nice to know that, I thought Guile use PCRE, but I realized it's
> posix RE.
>
>
> On Mon, Jan 28, 2013 at 9:58 PM, David Pirotte wrote:
>
>> Hello,
>>
>> > But I have some trouble with the rege
>static const scm_t_bits my_false = 0x4;
>static const scm_t_bits my_true = 0x404;
>static const scm_t_bits my_nil = 0x104;
>static const scm_t_bits my_eof = 0xa04;
>static const scm_t_bits my_eol = 0x304;
>static const scm_t_bits my_unspecified = 0x804;
I see it is not com
I don't know much about language interfaces, but why not have these be
constants exported by libguile.so? Is there any reason for other languages
to have to make their own lists?
Thanks,
Noah
On Thu, Jan 31, 2013 at 6:45 AM, Andy Wingo wrote:
> On Thu 31 Jan 2013 12:27, Andy Wingo writes:
>
On Thu 31 Jan 2013 12:27, Andy Wingo writes:
> On Tue 22 Jan 2013 11:55, Andy Wingo writes:
>
>> SCM_BOOL_F
>> SCM_BOOL_T
>> SCM_ELISP_NIL
>> SCM_EOF_VAL
>> SCM_EOL
>> SCM_UNBOUND
>> SCM_UNDEFINED
>> SCM_UNSPECIFIED
>>
> Instead, users should just keep a t
On Tue 22 Jan 2013 11:55, Andy Wingo writes:
> [trimming out guile-user]
>
> For me, here is the list of symbols with no C counterpart, followed by a
> commented list of all of them.
>
> Symbols that a non-C program would need to interact with Guile:
>
> SCM_BOOL_F
> SCM_BOOL_T
> S
Hi,
On Wed 16 Jan 2013 19:16, Andy Wingo writes:
> On Wed 16 Jan 2013 18:37, l...@gnu.org (Ludovic Courtès) writes:
>
>> I just think [string port encodings] may have to wait until 2.2.
>
> Oh yes, agreed here. Anyway let's let it simmer for a while. Another
> two or three of these threads sho
One more thing, Mark; would you mind handling merges to master? The
port code got rearranged there and merges can be tricky. I'll merge
stable-2.0 as it is first and then you can just deal with these patches.
Andy
--
http://wingolog.org/
Hi :)
On Fri 25 Jan 2013 17:46, Nala Ginrut writes:
> Users just need a way to know what languages could be specified to
> --language option.
Can you update the patch to use the language-for-humans? accesor that
Mark pushed recently?
> From a6b321e51a19d3726620a68f8db4902877872460 Mon Sep 17 0
I am pleased to announce that Guile-Lib 0.2.2 has been released. It
may be obtained at:
http://download.savannah.gnu.org/releases/guile-lib/guile-lib-0.2.2.tar.gz
What is Guile-Lib
-
Guile-Lib is intended as an accumulation place for pure-scheme Guile
modules, allowing for peop
On Thu 31 Jan 2013 06:31, Daniel Hartwig writes:
> On 22 January 2013 05:16, Andy Wingo wrote:
>> Any chance on getting a test case as well? :-)
>> --
>> http://wingolog.org/
>
> Updated with tests from RFC 1321. Confirmed that the new test fails
> pre-patch.
Applied, thanks!
Andy
--
http:/
On Thu 31 Jan 2013 06:06, Mark H Weaver writes:
> From: Mark H Weaver
> Date: Wed, 30 Jan 2013 14:45:28 -0500
> Subject: [PATCH] Do not scan for coding declarations in open-file.
The patch looks good to me but I am concerned about the behavior
change, and that it is inconvenient to get the prev
On 22 January 2013 05:16, Andy Wingo wrote:
> Any chance on getting a test case as well? :-)
> --
> http://wingolog.org/
Updated with tests from RFC 1321. Confirmed that the new test fails pre-patch.
0001-md5-fix-errors-when-input-size-modulo-64-is-55-bytes.patch
Description: Binary data
On 31 January 2013 13:31, Daniel Hartwig wrote:
> On 22 January 2013 05:16, Andy Wingo wrote:
>> Any chance on getting a test case as well? :-)
>> --
>> http://wingolog.org/
>
> Updated with tests from RFC 1321. Confirmed that the new test fails
> pre-patch.
Please excuse the very long lines o
Hi Mark,
On Thu 31 Jan 2013 05:40, Mark H Weaver writes:
> From ceccaf59267bc98c86aae33809905f26b017ebc8 Mon Sep 17 00:00:00 2001
> From: Mark H Weaver
> Date: Wed, 30 Jan 2013 10:16:37 -0500
> Subject: [PATCH 1/3] Rewrite get_iconv_codepoint to fix a bug involving
> byte-order marks.
LGTM, t
On Wed 30 Jan 2013 22:18, l...@gnu.org (Ludovic Courtès) writes:
> Can we discuss this one in the other thread, so my little brain and
> mailbox don’t get confused? :-)
>
>> From 5512fe4f93e4e583ab538ae02dd98e5825252dc9 Mon Sep 17 00:00:00 2001
>> From: Andy Wingo
>> Date: Wed, 30 Jan 2013 10:17
28 matches
Mail list logo
