Hello
I'm trying to clean some warnings in parrot C source files and found
this casts in packfile/pf_items.c:
fetch_buf_le_8(u.buf, (unsigned char *) b);
fetch_buf_be_8(u.buf, (unsigned char *) b);
But the function definitions are (in src/byteorder.c):
void
fetch_buf_le_8(ARGOUT(unsigned char
Hello.
As I said in a previous message, there are two casts in pf_items.c
that are unnecessary and seems to be wrong.
This patch removes both, avoiding warnings. Tested in Ubuntu 7.10 on
Intel platform.
--
Salu2
Index: src/packfile/pf_items.c
Hello.
I sent to the list the message to parrotbug, and later to parrotbug
the apology message to the list, sorry.
--
Salu2
Hello.
This is where I ran into problems. Is get_string constable? It seems
possible that someone somewhere would want to cache a stringification
that was computationally intensive, for later reuse. So now (as
bernhard kindly pointed out to me), this is starting to sound like a
On Sun, Apr 20, 2008 at 12:17 AM, Andy Lester [EMAIL PROTECTED] wrote:
Just popping in to say that we cannot const any parms to vtable methods.
Parrot can't impose promises on the called code.
So take for example In default.pmc the method get_class:
VTABLE PMC *get_class() :const
That is
On Mon, Apr 21, 2008 at 12:25 AM, Mark Glines [EMAIL PROTECTED] wrote:
(Still debatable whether the rest of that #else clause in parrot.h is
valid, if it's causing issues like this one.)
This patch can avoid future problems, by defining and using using
specific macros.
I searched the source
Hello
Just popping in to say that we cannot const any parms to vtable methods.
Parrot can't impose promises on the called code.
The attached patch drops the :const attribute in isa and get_class
methods. A lot of cast warnings disappear, and all tests pass in my
system.
--
Salu2
Index:
Hello
The following lines that use the STRUCT_COPY macro are generating
build warnings.
src/charset/ascii.c:792: warning: the address of 'base_set' will
always evaluate as 'true'
(snip)
For example, the last line here is:
STRUCT_COPY(return_encoding, base_encoding);
but
On Sat, Apr 26, 2008 at 8:16 PM, chromatic [EMAIL PROTECTED] wrote:
That seems cleaner to me; want to try that patch?
I'm out for the weekend, tomorrow I will work on it.
--
Salu2
On Sat, Apr 26, 2008 at 8:16 PM, chromatic [EMAIL PROTECTED] wrote:
A possible solution is to add another macro taking as second argument
the struct instead of a pointer.
That seems cleaner to me; want to try that patch?
The attached patch adds the macro STRUCT_COPY_ST, and uses it in
On Mon, Apr 28, 2008 at 8:15 PM, NotFound [EMAIL PROTECTED] wrote:
All test pass with 27216 in my system (Ubuntu 8.04)
Sorry, I mean 27219, 27216 was from the modified files.
--
Salu2
On Mon, Apr 28, 2008 at 10:05 PM, chromatic [EMAIL PROTECTED] wrote:
I renamed it to STRUCT_COPY_FROM_STRUCT (but that's only a little better than
your version) and applied it as r27222.
Thanks, but in 27222 looks like only include/parrot/parrot.h reflects
the changes, not the files in
The attached patch redoes the changes in these files with the new name.
--
Salu2
Index: src/encodings/utf16.c
===
--- src/encodings/utf16.c (revisión: 27222)
+++ src/encodings/utf16.c (copia de trabajo)
@@ -708,7 +708,7 @@
On Mon, Oct 22, 2007 at 2:24 PM, via RT Paul Cochrane
[EMAIL PROTECTED] wrote:
TODO mulInteger, Complex
The attached patch is a simple implementation using
mulComplex,Integer and adds the operation in the multiply test in
complex.t (don't know if it's the correct place).
--
Salu2
Index:
Lurkers (potential contributors.) Posting it on use.perl.org (and/or
various other feed sources) would reach more of us.
But do those lurkers actually exist? My gut says no. My gut says
that the people who would be interested in a summary are already on
the list.
I started
On Mon, May 5, 2008 at 2:52 AM, via RT Tom Erdevig
[EMAIL PROTECTED] wrote:
Parrot segfaults running this:
.sub _ :main
null S0
loadlib P0, S0
.end
The segfault is caused by src/dynext.c:Parrot_load_lib setting
its local lib_name variable to NULL and then passing it along
to
On Tue, May 6, 2008 at 7:42 AM, chromatic [EMAIL PROTECTED] wrote:
I prefer this patch. It fixes the problem closer to its source. Does it
work
for you?
Works for me, but I wonder if the set_string_native function still
needs the fix, or an assertion about a forbidden combination of
In src/objects.c:Parrot_add_attribute() there is the todo item:
/* TODO escape NUL char */
I think this applies to calling real_exception just afterwards.
According a discussion in #parrot this function and some related parts
is dead code. The attached patch removes it.
--
Salu2
Index:
Sorry, forgot to attach the patch file.
--
Salu2
Index: src/pmc/class.pmc
===
--- src/pmc/class.pmc (revisión: 27379)
+++ src/pmc/class.pmc (copia de trabajo)
@@ -644,8 +644,11 @@
/* If we already have an attribute of
On Thu, May 8, 2008 at 9:55 PM, chromatic [EMAIL PROTECTED] wrote:
Your null-checking patch will work, but I don't want to add more checking to
parrot_mark_hash() right now, as it's already full of special cases. Here's
my inclination.
Looks good to me. I see you also get rid ot the value
The attached patch makes explicit the assumptions about non-nullness
in parrot_mark_hash and asserts them.
--
Salu2
Index: src/hash.c
===
--- src/hash.c (revisión: 27411)
+++ src/hash.c (copia de trabajo)
@@ -299,6 +299,7 @@
=item
On Fri, Feb 15, 2008 at 11:59 AM, via RT chromatic
[EMAIL PROTECTED] wrote:
$ ./parrot -O t/compilers/imcc/syn/const_24.pir
Null PMC access in get_string()
$ ./parrot t/compilers/imcc/syn/const_24.pir
Null PMC access in get_string()
current instr.: 'main' pc 5
On Mon, May 12, 2008 at 4:34 AM, Andy Lester via RT
[EMAIL PROTECTED] wrote:
This won't work because it modifies the sections in between HEADERIZER
BEGIN END sections. As of this writing, there is no solution for this
problem.
Maybe the solution is to avoid the problem, that is, put the
On Tue, Sep 18, 2007 at 6:59 PM, via RT Nuno Carvalho
[EMAIL PROTECTED] wrote:
While running 'make fulltest', for today's release, we noticed there
is a test failling for 't/op/string.t' when using jit runcore. This
test is currently being skipped.
The test that's failling is test
that
eventually take over the world, here is the partial list
@@ -498,6 +498,10 @@
N: Nigelsandever
D: Win32 patches
+N: NotFound
+D: Bug fixing and cage cleaning.
+E: [EMAIL PROTECTED]
+
N: Nuno 'smash' Carvalho
D: PGE/perl6/abc debugging and testing
E: [EMAIL PROTECTED]
Index: include/parrot
On Tue, May 13, 2008 at 1:50 AM, via RT Andrew Whitworth
[EMAIL PROTECTED] wrote:
src\oo.c(513) : warning C4189: '_class' : local variable is
initialized but not referenced
The function in question, Parrot_find_vtable_meth, declares the
variable _class twice: once at the beginning of the
No wonder that all test pass, this function is dead code.
It's only used by the static function in the same file
create_deleg_pmc_vtable, wich is never used.
--
Salu2
On Mon, May 12, 2008 at 7:40 PM, chromatic [EMAIL PROTECTED] wrote:
I fixed a few similar problems with the optimized build. Is r27069 any
guidance? r23771 looks like it might affect this function as well.
string_bool signature was modified in 23771, but was marked as not null anyway.
But
Here is a patch to remove these functions.
--
Salu2
Index: src/oo.c
===
--- src/oo.c (revisión: 27471)
+++ src/oo.c (copia de trabajo)
@@ -37,12 +37,6 @@
__attribute__nonnull__(1)
__attribute__nonnull__(2);
the world, here is the partial list
@@ -498,6 +498,10 @@
N: Nigelsandever
D: Win32 patches
+N: NotFound
+D: Bug fixing and cage cleaning.
+E: [EMAIL PROTECTED]
+
N: Nuno 'smash' Carvalho
D: PGE/perl6/abc debugging and testing
E: [EMAIL PROTECTED]
Index: include/parrot/string_funcs.h
The attached patch is a hack that uses the 0200 flag in --imcc-debug
to mean 'create debug segment regardless optimization level'
$ ./parrot -O --imcc-debug=0200 t/compilers/imcc/syn/const_24.pir
Null PMC access in get_string()
current instr.: 'main' pc 5 (t/compilers/imcc/syn/const_24.pir:11)
The function Parrot_remove_parent is used by the removeparent opcode.
The attached patch implements the remove_parent method in class.pmc,
and implement Parrot_remove_parent as a call to VTABLE_remove_parent
on the pmc supplied, thus implementing the removeparent functionality
for classes.
Don't
Forget to remove the return after real_exception, as recomended in a
talk in #parrot.
Second revision attached.
--
Salu2
Index: src/oo.c
===
--- src/oo.c (revisión: 27509)
+++ src/oo.c (copia de trabajo)
@@ -1148,8 +1148,7 @@
I have seen now that the functions if'ed out by DO_LOOP_OPTIMIZATION
are mentioned and proposed for deletion in #46291, this ticket can be
merged with him or closed.
--
Salu2
In src/objects.c:Parrot_add_attribute() there is the todo item:
This function was dead code and has been deleted in #45989
/ * TODO check if someone is trying to add attributes to a parent class
* while there are already child class attrs
*/
The checks are in add_parent on the class pmc.
The
On Tue, Oct 2, 2007 at 7:47 PM, via RT Paul Cochrane
[EMAIL PROTECTED] wrote:
In src/objects.c:Parrot_new_class() there is the todo item:
/* TODO create all class structures in constant PMC pool */
This function no longer exists. Looks like class creation now is done
by calling
On Tue, Oct 2, 2007 at 7:43 PM, via RT Paul Cochrane
[EMAIL PROTECTED] wrote:
In src/objects.c fail_if_exist() has the todo item:
XXX uses global class registry
I'm guessing by this comment that it shouldn't?
This function no longer exists.
--
Salu2
On Tue, Oct 2, 2007 at 7:44 PM, via RT Paul Cochrane
[EMAIL PROTECTED] wrote:
In src/objects.c there is the todo item within fail_if_exist():
/* TODO get printable name */
This function no longer exists.
--
Salu2
On Thu, Oct 25, 2007 at 5:28 PM, via RT Paul Cochrane
[EMAIL PROTECTED] wrote:
# XXX
# in plain functional run-loop result is 999
# other run-loops report 998
# TODO investigate this after interpreter strtup is done
# see also TODO in src/embed.c
I can't reproduce the problem, and looking
The split opcode gives failed assertion 's' when given a
null string argument. Perhaps it should pretend it got the
null string, or at least throw a more normal exception.
A problem is that the string_split functions declares his parameter as
non null. This function is used in several pmc, so
Updated patch:
Now it passes allmost all tests. A problem is the PIO_eprintf
function, that is not in any externally usable header.
There is a coding style fail with the #if indenter check, I'm unable
to locate that problem.
Fixed the perl6nool.pmc, that used a variable named class.
--
Salu2
Looking better at the Parrot_exec_rel_... vars, they are not intended
to be exported at all, they are globals for private usage between exec
and jit, so they don't need the API or DATA things. This patch cleans
it, make sure they are defined only in jit.c and declared as extern in
the others, and
Please try; ./parrot -t t/dynoplibs/myops_3.pir
And tell us if it's blocked while executing the hcf opcode.
The proposed change looks good to me, others C compilers can have the
same problem with returning a void result.
--
Salu2
On Wed, Oct 24, 2007 at 7:45 AM, via RT chromatic
[EMAIL PROTECTED] wrote:
There's a segfault in t/dynpmc/dynlexpad_2.pir with the gcdebug core. It
happens at the end of the program, during global destruction, when trying to
call the destroy() entry on the DynLexPad PMC.
Is this ticket still
On Sat, May 10, 2008 at 7:06 AM, Patrick R. Michaud via RT
[EMAIL PROTECTED] wrote:
As far as I can tell, this comment is no longer in config/inter/progs.pm
and there's no marker for this ticket. So I'm guessing it has been
resolved somehow and the ticket can be closed -- anyone want to
On Mon, Apr 14, 2008 at 3:18 PM, via RT Senaka Fernando
[EMAIL PROTECTED] wrote:
Including gmp.h causes build break in C++ build on Ubuntu Gutsy. The problem
is some down stream header adding libintl.h, which gives trouble. Thus, it
Works for me in Ubuntu after the recent C++ related changes.
Sorry, forgot to check coding standards. Fixed now.
--
Salu2
Index: config/auto/warnings.pm
===
--- config/auto/warnings.pm (revision 27920)
+++ config/auto/warnings.pm (working copy)
@@ -44,13 +44,10 @@
-W
-Wall
On Fri, May 30, 2008 at 5:56 PM, Geoffrey Broadwell [EMAIL PROTECTED] wrote:
Nit: three of those lines look like they've either got a real tab at the
front, or some other spacing oddity that makes them not line up
properly.
Sorry, forgot to cross-copy to the list the fixed version.
On Sun, Jun 1, 2008 at 6:56 PM, James Keenan via RT
[EMAIL PROTECTED] wrote:
1. What OS/platform combination are you seeing this non-detection on?
Ubuntu 8.04 i386, g++ 4.2.3
2. Assuming I applied this patch, how would I test it? Does 'building
with C++' imply some particular command-line
Previous version generates a warning when building with C, fixed now.
--
Salu2
Index: src/runops_cores.c
===
--- src/runops_cores.c (revisión: 28033)
+++ src/runops_cores.c (copia de trabajo)
@@ -242,13 +242,28 @@
opcode_t *
On Sun, Jun 1, 2008 at 1:31 PM, Vasily Chekalkin [EMAIL PROTECTED] wrote:
interp-exceptions initialized lazily. But really_destroy_exception have
signature with __attribute_notnull__. So we should either check this value
before function call or change function signature to accepts NULL.
I
Looking more carefully at this issue, it seems that those variables
and the code that uses them has no real effect. Without it, make test
pass, make testj pass, make hello and make perl6 builds and runs.
This patch cleans all. It needs to be tested with make testj in win
32, and for completeness
On Sat, Jan 19, 2008 at 7:08 AM, via RT Geoffrey Broadwell
[EMAIL PROTECTED] wrote:
'parrot -v -O2' segfaults in cases where both 'parrot -v' and 'parrot -O2'
succeed normally. For example:
./parrot -v -O2 examples/japh/japh1.pasm # Segfault before normal -v
This patch gets rid of the global pio_registered_layers, by putting it
in interpreter data, creating and destroying the the layers in the
first interpreter and propgating his value to the child ones. This way
will solve threading issues (supposed that creating several main
interpreters is not
On Thu, Jun 5, 2008 at 7:53 AM, chromatic [EMAIL PROTECTED] wrote:
... could be cleaner with the macro mem_allocate_n_typed.
Agree, corrected version attached.
--
Salu2
Index: src/io/io_layers.c
===
--- src/io/io_layers.c
On Fri, Jun 6, 2008 at 6:15 AM, via RT Will Coleda
[EMAIL PROTECTED] wrote:
I'm not sure that supporting this option (And having to fix bugs to do
it) is worth it. If we can remove this, we can also remove anything in
the code that is ifdef'd around MINIPARROT.
Several minipparot related
On Fri, Jun 6, 2008 at 4:39 AM, via RT Seneca Cunningham
[EMAIL PROTECTED] wrote:
I had started an attempt to determine which test in rakudo's spectest
was causing a SIGBUS on my system (OS X 10.5, ppc) by manually running
tests that occurred at the appropriate moment in time when the first
On Wed, Aug 8, 2007 at 9:17 AM, via RT chromatic
[EMAIL PROTECTED] wrote:
Another option is to cache the C string in the STRING structure itself in the
same way that Perl 5 caches IVs and NVs and PVs in the SV structure. (If
that doesn't mean anything to you, congratulations. I have this
Sorry, forgot to attach the file.
--
Salu2
Index: src/pdb.c
===
--- src/pdb.c (revisión: 28197)
+++ src/pdb.c (copia de trabajo)
@@ -219,9 +219,8 @@
Parrot_exception exp;
if (setjmp(exp.destination)) {
-char
I've made some more work on this patch. First, fixed an error that
breaks pdb build. Then, replacing the string_to_cstring function in a
lot more places, and adding a new packfile function to find the
location of a label without strings copying. The latter gives a
noticeable speedup. I'm not sure
(Looks like the second message in this thread was not forwarded to the list).
There are several problems related to LANG. As this ticket shows, perl
warns when it has no support for the locale specified, and the
warnings interferes with the output expected by the tests.
Also several Configure
On Wed, Jun 11, 2008 at 12:00 AM, chromatic [EMAIL PROTECTED] wrote:
Could Configure.pl warn when there's no LANG? How portable is that?
Actually Configure.pl warns at his start when the value of LANG is not
supported by perl, being itself a perl program. But I don't know if
this condition can
On Thu, Jun 12, 2008 at 1:23 AM, chromatic [EMAIL PROTECTED] wrote:
What's it look like when patching pmc_type to deal with NULL STRING *? I'm
not saying that's the best option; I'm just looking at the alternatives.
We must change his signature to do that. I tried the mininal change.
--
Some more details: adding:
Parrot_set_flag(interp, PARROT_DESTROY_FLAG);
in src/main.c it segfaults also when executing with perl6.pbc, and
also a lot of parrot test fails.
So it looks like there is a general problem of interpreter destruction
in exits from the exception handler.
--
Salu2
On Sun, Jun 15, 2008 at 12:47 AM, chromatic via RT
[EMAIL PROTECTED] wrote:
Seems reasonable to me. If you have tests, I'll apply it.
Patch updated to r28430 with a simple test added in t/oo/subclass.t
--
Salu2
Index: src/pmc/class.pmc
On Thu, Jun 19, 2008 at 4:23 AM, Andrew Whitworth via RT
[EMAIL PROTECTED] wrote:
Patch applies cleanly, but make perl6 fails on Debian(Ubuntu 8.04) x86
for me. I've attached a backtrace of the failure, for anybody who is
intrepid enough to take a look at it.
Thanks for the testing. I think
checked this on Linux and it builds
fine. Hence the attached patch to packfile.c
This sounds reasonable. I'd like to hear results from trying to compile with
a C++ compiler though. NotFound, any luck?
The goal of the PARROT_const_cast macro is to do the const-dropping
casting (given
Here is the patch. It avoids the warning both in C and C++ with gcc.
--
Salu2
Index: src/packfile.c
===
--- src/packfile.c (revisión: 28668)
+++ src/packfile.c (copia de trabajo)
@@ -348,7 +348,7 @@
#ifdef
On Mon, Jun 23, 2008 at 4:37 PM, Andrew Johnson [EMAIL PROTECTED] wrote:
It might be worth adding a comment into parrot.h to clarify that
PARROT_const_cast should *only* be used for c/v qualifier changes, and that
additional casting may be necessary.
Yes, but I don't know how to write it
This is a bigger patch that in addition to the checks does some
refactor in the debugger system: moves all acces to debugger internals
out of debug.ops, and moves the constants used only by debug.c out of
debug.h, converting them from macros to enum values at the same time.
The long term goal is
More refactor: in addition to the changes in the previous, this also
moves the PDB_extend_const_table from src/debug.c to
compilers/imcc/pbc.c, because is the only file that uses it and seems
to not be related to the debugger (historical reasons?), renames it
and makes it static, and add a few
On Tue, Jul 1, 2008 at 4:44 PM, Patrick R. Michaud (via RT)
[EMAIL PROTECTED] wrote:
$ cat x.pir
.sub 'main'
'foo'()
'bar'()
.end
.sub 'foo'
new $P0, String
assign $P0, abc
say $P0
.end
.sub 'bar' :lexid(abc)
new $P0, String
Looking at this problem, I noted that without jit two test fails:
perl Configure.pl --jitcapable=0 --floatval='long double'
Test Summary Report
---
t/op/jitn.t (Wstat: 256 Tests: 14 Failed: 1)
Failed test: 14
Non-zero exit status: 1
t/op/sysinfo.t
On Mon, Jun 23, 2008 at 4:37 PM, Andrew Johnson [EMAIL PROTECTED] wrote:
Here is the patch. It avoids the warning both in C and C++ with gcc.
Works fine for me, no warning.
It might be worth adding a comment into parrot.h to clarify that
PARROT_const_cast should *only* be used for c/v
On Wed, Jul 9, 2008 at 9:33 PM, Andrew Johnson [EMAIL PROTECTED] wrote:
The other warnings I get on Solaris are just these:
src/stm/backend.c, line 969: warning: statement not reached
./src/pmc/nci.pmc, line 486: warning: statement not reached
src/encodings/utf16.c, line 326: warning:
On Thu, Jul 10, 2008 at 7:44 PM, Andrew Johnson [EMAIL PROTECTED] wrote:
Except the src/pmc/nci.pmc line 486, there is not such line in the
file, and I'm unable to locate the problem.
If you look in the generated src/pmc/nci.c file at line 486, it has a #line
directive that purports to point
I changed the signature from PMC * to const PMC * in r29253, otherwise
using it with const gives warings in C and fails in C++.
What is the reason to have an interp parameter? Looks like an
unnecessary overhead in a frequently used function.
--
Salu2
src/exec_cpu.c
src/jit/i386/core.jit: In function 'Parrot_eq_n_n_ic_exec':
src/jit/i386/core.jit:1031: error: 'DO' undeclared (first use in
this function)
Looks like it was just a DO/do typo, but the file has been changed
before I can try to do some test.
--
Salu2
Looks like it was just a DO/do typo, but the file has been changed
before I can try to do some test.
No, it was a bad diagnostic from svn, my change has been commited.
--
Salu2
On Thu, Jul 3, 2008 at 11:12 PM, Allison Randal via RT
[EMAIL PROTECTED] wrote:
A bit more detail on the conversion process for a PMC:
(snip)
3) Change 'init' and 'init_pmc' to initialize the auto-generated struct
instead of whatever initialization it was doing before. For example, if
it was
Patch applied in r29301
I changed the test, because the unicode: prefixed string is utf8 by
default according the specs, and the current implementation seems to
agree, so the result in utf8 is the expectation both with or without
icu.
--
Salu2
When #39930 is resolved, we can eliminate the workaround.
After applying a patch to #39930 in r29301, deleted this workaround in r29304
--
Salu2
Applied in r29309
--
Salu2
Applied in r29356 with modified and enhanced test.
--
Salu2
On Sat, Jul 12, 2008 at 10:57 PM, Will Coleda [EMAIL PROTECTED] wrote:
On Sat, Jul 12, 2008 at 3:30 PM, NotFound via RT
[EMAIL PROTECTED] wrote:
imcc_init is now called during interpreter initialization. Does that
solve this problem?
I'd say we'd need a passing test to close this out. =-)
I
On Tue, Jul 15, 2008 at 3:58 PM, via RT Will Coleda
[EMAIL PROTECTED] wrote:
-- Forwarded message --
From: Reini Urban [EMAIL PROTECTED]
Date: Tue, Jul 15, 2008 at 9:52 AM
Subject: .parrot_current_rev
To: [EMAIL PROTECTED]
Worse, the logic the set the current revision for
On Tue, Jul 15, 2008 at 3:58 PM, Reini Urban via RT
[EMAIL PROTECTED] wrote:
This got warnocked for 0.6.4
rename the debugger, not the disassembler.
I don't like the name parrot_pdb. 'parrot Parrot DeBugger' ? Looks redundant.
I'll vote for parrot_debug
--
Salu2
I fixed the problem in r29488, but I don't have any windows
environment available to test.
--
Salu2
I don't like the name parrot_pdb. 'parrot Parrot DeBugger' ? Looks
redundant.
After some discussion in #parrotsketch, the name parrot_debugger wins.
--
Salu2
After some discussion in #parrotsketch, the name parrot_debugger wins.
Done in r29496, waiting for comments and fixes before closing the ticket.
--
Salu2
On Tue, Jul 15, 2008 at 11:45 PM, Mark J. Reed [EMAIL PROTECTED] wrote:
IMESHO, the encoding of the source code should have no bearing on the
interpretation of string literal escape sequences within that source
code. \ab should mean U+00AB no matter whether the surrounding
source code is
To open another can of worms, I think that we can live without
character set specification. We can stablish that the character set is
always unicode, and to deal only with encodings. Ascii is an encoding
that maps directly to codepoints and only allows 0-127 values.
iso-8859-1 is the same with
* Unicode isn't necessarily universal, or might stop to be so in future.
If a character is not representable in Unicode, and you chose to use
Unicode for everything, you're screwed
There are provision for private usage codepoints.
* related to the previous point, some other character
On Wed, Jul 16, 2008 at 1:32 AM, James Keenan via RT
[EMAIL PROTECTED] wrote:
Worse, the logic the set the current revision for svn updates is
wrong.
No, the logic was correct. As particle said on #parrot yesterday,
.parrot_current_rev should always reflect the last time you ran 'perl
Fixed parrot_debugger test in r29508
--
Salu2
On Wed, Jul 16, 2008 at 6:08 AM, Tim Heckman [EMAIL PROTECTED] wrote:
Starting in r29489, .parrot_current_rev contains 0 instead of the revision
number.
I was using a simplified way to call svn info avoiding locale
dependencies, and forgot to replace with a more generic way.
Fixed in r29509
On Wed, Jul 16, 2008 at 12:45 AM, [EMAIL PROTECTED] wrote:
I just ran a test on XP-Home (using Strawberry Perl) after updating to
r29495. Configure.pl creates the file (whether or not it was present), but
the value appears to be a constant 0. (Make test and perl6 have no
effect.)
Please
On Wed, Jul 16, 2008 at 1:12 PM, James Keenan via RT
[EMAIL PROTECTED] wrote:
I think this new subroutine could use some refactoring:
Yes, my goal was to fix the problem as fast as possible, and I'm not
very fluent with perl.
If no one gets to this today I will try to work on this this
On Wed, Jul 16, 2008 at 1:13 AM, Moritz Lenz
[EMAIL PROTECTED] wrote:
NotFound wrote:
* Unicode isn't necessarily universal, or might stop to be so in future.
If a character is not representable in Unicode, and you chose to use
Unicode for everything, you're screwed
There are provision
On Thu, Jul 17, 2008 at 5:20 AM, Allison Randal [EMAIL PROTECTED] wrote:
The thing is, there's a tendency for data for a particular program or
application to all be from the same character set (if, for example, you're
parsing a series of files, munging the data in some way, and writing out a
1 - 100 of 239 matches
Mail list logo
