In message <[EMAIL PROTECTED]>
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 10, 2001 at 12:49:50AM +0100, Tom Hughes wrote:
> > Attached is a patch to add string comparison ops, along with the
> > necessary infrastructure in the string c
At 05:04 AM 10/10/2001 -0400, Michel Lambert wrote:
> > As we're using garbage collection we shouldn't need to do an explicit
> > free though surely - in fact I'm not quite sure why string_destroy
> > even exists...
>
>I'm not sure if the GC'ing will apply to strings, or just PMCs. I imagine
>PMC'
>What about making an store_transcode( string, encodingtype ) function
>which
>takes a string, and stores the encodingtype version in it. Strings would
>then be able to store multiple versions of themselves, in utf32, utf8,
>etc
>format. The original format would still be remembered as the 'main'
In message <001d01c1516a$98c07ee0$7f03ef12@MLAMBERT>
Michel Lambert <[EMAIL PROTECTED]> wrote:
> > You're quite right that it doesn't, but neither does anything else
> > that creates temporary strings in a different encoding ;-)
>
> In my day-or-two-old parrot copy, the only other code t
> You're quite right that it doesn't, but neither does anything else
> that creates temporary strings in a different encoding ;-)
In my day-or-two-old parrot copy, the only other code that uses the
transcoding table only uses it with the second param != null (ie, save into
existing string). Other
Index: string.t
===
RCS file: /home/perlcvs/parrot/t/op/string.t,v
retrieving revision 1.8
diff -u -w -r1.8 string.t
--- string.t 2001/10/05 11:46:47 1.8
+++ string.t 2001/10/10 08:42:55
@@ -1,6 +1,6 @@
#! perl -w
-use Parrot::Test
In message <00b001c15166$a3b88ee0$7f03ef12@MLAMBERT>
Michel Lambert <[EMAIL PROTECTED]> wrote:
> Am I missing something here, or does this code not properly free transcoded
> s1's and s2's after it's done comparing them?
You're quite right that it doesn't, but neither does anything else
> Question about the following code.
>
> +INTVAL
> +string_compare(STRING* s1, STRING* s2) {
> +if (s1->encoding != s2->encoding) {
> +if (s1->encoding->which != enc_utf32) {
> +s1 =
Parrot_transcode_table[s1->encoding->which][enc_utf32](s1,
> NULL);
> +}
> +
In message <[EMAIL PROTECTED]>
Simon Cozens <[EMAIL PROTECTED]> wrote:
> I see no tests *or* documentation. Come on, Tom, you should know
> better than that. :)
Here's the doc patch:
Index: strings.pod
===
RCS file: /home/p
In message <[EMAIL PROTECTED]>
Gibbs Tanton - tgibbs <[EMAIL PROTECTED]> wrote:
> Does the call to the transcode function create a new string or change the
> string in place. I don't think we want to pass in a native string only to
> find out it is unicode after we get done comparing i
In message <[EMAIL PROTECTED]>
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 10, 2001 at 12:49:50AM +0100, Tom Hughes wrote:
> > Attached is a patch to add string comparison ops, along with the
> > necessary infrastructure in the string c
e. I don't think we want to pass in a native string only to
find out it is unicode after we get done comparing it.
-Original Message-
From: Tom Hughes
To: [EMAIL PROTECTED]
Sent: 10/9/2001 6:49 PM
Subject: String comparison ops
Attached is a patch to add string comparison ops, alon
On Wed, Oct 10, 2001 at 12:49:50AM +0100, Tom Hughes wrote:
> Attached is a patch to add string comparison ops, along with the
> necessary infrastructure in the string code.
I see no tests *or* documentation. Come on, Tom, you should know
better than that. :)
--
\let\l\let\l\d\def\l\a\ac
Attached is a patch to add string comparison ops, along with the
necessary infrastructure in the string code.
The current behaviour is that if the two strings do not have the
same encoding then both are promoted to UTF-32 before comparison
as that should generally preserve information.
Tom
14 matches
Mail list logo
