Re: propose renaming Hash to Dict
On Thursday 31 May 2007 17:36:40 Chas Owens wrote:
Except of course those poor schmucks who foolishly wrote code like
if (ref $arg eq 'HASH') { ... }
I know you're teasing, but it *would* be nice to see that sort of code just
magically go away.
-- c
Re: [perl #42938] [BUG] allocation failures in res_lea.c
On Sat, 12 May 2007 12:05:26 -0700
Allison Randal (via RT) [EMAIL PROTECTED] wrote:
On x86 Linux (Ubuntu), this configuration fails 2 tests:
t/library/string_utils.t0 134294 13.79% 28-29
t/op/stringu.t 2 512252 8.00% 1 19
Both tests are failing with the error:
parrot: src/encodings/utf8.c:271: utf8_encode_and_advance: Assertion
`i-bytepos = (s)-obj.u._b._buflen' failed.
Reproduced on Gentoo. Before patch, results are as above.
After patch:
t/library/string_utilsok
t/op/stringu..ok
The code in utf8_encode_and_advance is beautiful. It basically says,
add a utf8 character to the buffer. Ok, now did we overrun the buffer?
CRASH!
It seems safer to check the buffer size *before* writing to it, so
here's a patch to do so. Is it the right fix? I thought so when I
was doing it, but now I'm not so sure; it does introduce a const
warning. Maybe we can resolve that with a cast; maybe its the wrong
solution to the problem. Please provide guidance.
Might be worth it to prereserve 8 bytes or so, to avoid having to
realloc as often, if this will be called a lot. Currently it just
reallocs the minimum necessary to fit the existing string, the new
character and a null terminator.
Mark
=== src/encodings/utf8.c
==
--- src/encodings/utf8.c (revision 20520)
+++ src/encodings/utf8.c (local)
@@ -264,6 +264,9 @@
const STRING *s = i-str;
unsigned char *new_pos, *pos;
+if(i-bytepos + UNISKIP(c) = PObj_buflen(s)) {
+Parrot_reallocate_string(interp, i-str, i-bytepos + UNISKIP(c) + 1);
+}
pos = (unsigned char *)s-strstart + i-bytepos;
new_pos = utf8_encode(pos, c);
i-bytepos += (new_pos - pos);
Re: propose renaming Hash to Dict
On Fri, Jun 01, 2007 at 11:44:53AM +0200, Thomas Wittek wrote: Larry Wall: Nope. Hash is mostly about meaning, and very little about implementation. Please don't assume that I name things according to Standard Names in Computer Science. I name things in English. Hash is just something that is disordered, which describes the associative array interface rather nicely, distinguishing it from the ordered Array interface. I'm not a native english speaker, but I've never heard or read the word hash outside CS. I suppose that as a non-native English speaker you've never eaten corned beef hash. I quote from Wikipedia: Hash is a mixture of beef (often leftovers of corned beef or roast beef), onions, potatoes, and spices that are mashed together into a coarse, chunky paste, and then cooked, either alone, or with other ingredients. It's a bit of a working-class dish, for using up your leftovers, so not the sort of thing you'd eat as a tourist, but it seems many other countries have the same sort of thing: using your leftovers is a pretty universal need. In colloquial English there's also the expression, to make a hash of something, which means to make a mess of it, to screw up. That said, the dish and the idiom are both dying out, and the current generation of school leavers might not have heard of either. I didn't make the connection until Larry described it as being disordered. As a general point, I think it's pretty easy to make a mental distinction between a 5ish hash and a hashtable, just as it's easy to remember that 5's abstracted lists and arrays aren't the same concepts as linked lists and C-style concrete arrays. -- It must be accepted as a principle that the rifle, effective as it is, cannot replace the effect produced by the speed of the horse, the magnetism of the charge, and the terror of cold steel. -- British Cavalry training manual, 1907 ::: http://surreal.istic.org/ signature.asc Description: Digital signature
Re: propose renaming Hash to Dict
On 6/1/07, Larry Wall [EMAIL PROTECTED] wrote: Nope. Hash is mostly about meaning, and very little about implementation. Please don't assume that I name things according to Standard Names in Computer Science. I name things in English. Then why did we need a separate use English pragma? :) Are you the one who originally came up with hash for %vars? IIRC, they were officially called just associative arrays through Perl4, but hash was a well-understood community nickname for them for some time before you canonized it with ref($var) eq 'HASH' in Perl5... -- Mark J. Reed [EMAIL PROTECTED]
Re: propose renaming Hash to Dict
Larry Wall: Nope. Hash is mostly about meaning, and very little about implementation. Please don't assume that I name things according to Standard Names in Computer Science. I name things in English. Hash is just something that is disordered, which describes the associative array interface rather nicely, distinguishing it from the ordered Array interface. Hm, but with which would you explain a hash in plain english? What would be the closest equivalents in the real world? I'm not a native english speaker, but I've never heard or read the word hash outside CS. I guess this ones are close: - collection (contra: doesn't imply the access to an item) - dictionary (contra: might be assumed ordered) - directory (contra: might be assumed ordered, clashes with a file directory) - index (contra: might be assumed ordered, might be too technical) The problem with the implication of an order in the real world concepts is that you probably won't find one that isn't ordered. Those things allow us to find something easily by a word. But as we first have to find that word, we have an ordered list of the words... So there is no perfect candidate in the above list. But in my opinion they are still more english than hash. Additionally I believe it would be easier to learn that it's (e.g.) a dictionary that just is not ordered than learning a whole new word like a hash (which it was for me as a non-native english speaker). -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: propose renaming Hash to Dict
Let's not forget that the CS meaning of hash didn't spring forth fully-formed from the skull of Donald Knuth or anything. A hash function is so called because it makes a hash of the inputs. That is, its output, while deterministic, is at first glance a random rearrangement of the inputs. Hence, a hash. -- Mark J. Reed [EMAIL PROTECTED]
Re: propose renaming Hash to Dict
On Jun 1, 2007, at 5:44 , Thomas Wittek wrote: Larry Wall: Nope. Hash is mostly about meaning, and very little about implementation. Please don't assume that I name things according to Standard Names in Computer Science. I name things in English. Hash is just something that is disordered, which describes the associative array interface rather nicely, distinguishing it from the ordered Array interface. Hm, but with which would you explain a hash in plain english? What would be the closest equivalents in the real world? ...make a hash of things (meaning, a mess) corned beef hash -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: propose renaming Hash to Dict
On Fri, Jun 01, 2007 at 07:07:06AM -0400, Brandon S. Allbery KF8NH wrote: On Jun 1, 2007, at 5:44 , Thomas Wittek wrote: Larry Wall: Nope. Hash is mostly about meaning, and very little about implementation. Please don't assume that I name things according to Standard Names in Computer Science. I name things in English. Hash is just something that is disordered, which describes the associative array interface rather nicely, distinguishing it from the ordered Array interface. Hm, but with which would you explain a hash in plain english? What would be the closest equivalents in the real world? ...make a hash of things (meaning, a mess) corned beef hash That's two people that have given the same list, but both have omitted the more common (in modern times) phrase hash browned potatos which is a hash of chopped potato, onion, and sometimetimes other things fried brown. I'll ignore the McDonald's version which hashes together just the potatos, since a collective of a single element is still a collective mathematically, but not usually considered so linguistically unless you've got a big enough advertising budget to pull it off. --
Re: propose renaming Hash to Dict
On Fri, Jun 01, 2007 at 10:30:08AM -0400, John Macdonald wrote: ...make a hash of things (meaning, a mess) corned beef hash That's two people that have given the same list, but both have omitted the more common (in modern times) phrase hash browned potatos which is a hash of chopped potato, onion, and sometimetimes other things fried brown. Well, I have eaten hash browns on many occasions, but in my mind they just don't have the same association with a disordered mess, as they are served as discrete units rather than a mass. But let's stop talking about food now. -- There once was a teacher of great renown, Gather your goods Whose words were like the tablets of stone,and follow me Because it's easier to learn than unlearn, Or you will surely die. Because we've passed the point of no return. Paul Simon, 'The Teacher' signature.asc Description: Digital signature
Re: [perl #42938] [BUG] allocation failures in res_lea.c
On Thu, 31 May 2007 23:09:54 -0700 Mark Glines [EMAIL PROTECTED] wrote: Might be worth it to prereserve 8 bytes or so, to avoid having to realloc as often, if this will be called a lot. Currently it just reallocs the minimum necessary to fit the existing string, the new character and a null terminator. There is a performance impact from the additional check, but I don't think the above optimization is necessary... or its possible Parrot_reallocate_string() already reserves extra room internally. Either way, I don't see enough of a performance hit from the patch to be too worried about this. I tried prove t/op t/library with different scenarios, to try to measure the performance impact. Here are the setups and the results: Configure.pl with no args, and no patches applied All tests successful, 2 tests and 172 subtests skipped. Files=56, Tests=2488, 73 wallclock secs (51.64 cusr + 11.49 csys = 63.13 CPU) Configure.pl with no args, #42938 patch applied All tests successful, 2 tests and 172 subtests skipped. Files=56, Tests=2488, 72 wallclock secs (51.73 cusr + 11.59 csys = 63.32 CPU) Configure.pl --gc=libc, no patches applied Failed Test Stat Wstat Total Fail List of Failed --- t/library/string_utils.t0 6294 28-29 t/op/stringu.t 2 512252 1 19 2 tests and 176 subtests skipped. Failed 2/56 test scripts. 4/2488 subtests failed. Files=56, Tests=2488, 69 wallclock secs (50.57 cusr + 11.19 csys = 61.76 CPU) Failed 2/56 test programs. 4/2488 subtests failed. Configure.pl --gc=libc, #42938 patch applied All tests successful, 2 tests and 176 subtests skipped. Files=56, Tests=2488, 70 wallclock secs (50.67 cusr + 11.24 csys = 61.91 CPU) Mark
Re: propose renaming Hash to Dict
Daniel Hulme: Larry Wall: I name things in English. Hash is just something that is disordered I'm not a native english speaker, but I've never heard or read the word hash outside CS. you've never eaten corned beef hash. To conclude, as hash definitely tastes better than a dictionary, we should stick to that name. ;) At least nobody can say that Perl is bad taste! -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
mmd for bitwise_and causes a segfault with my pmc types
Hello,
I have two pmc classes PjsNumber and PjsBoolean, which define
bitwise_and like this:
PMC* bitwise_and(PMC* value, PMC* dest) {
FLOATVAL a, b;
if (! dest) {
dest = pmc_new(INTERP, dynpmc_PjsNumber);
} else if (dest-vtable-base_type != dynpmc_PjsNumber) {
VTABLE_morph(INTERP, dest, dynpmc_PjsNumber);
}
a = DYNSELF.get_number();
b = VTABLE_get_number(INTERP, value);
VTABLE_set_number_native(INTERP, dest, (INTVAL)a (INTVAL)b);
return dest;
}
It seems to work in general, but in some cases (especially when I
allocate too much memory) it causes me a segfault
or an error like: Trace/breakpoint trap (core dumped)
An example of such a case:
.HLL 'Pjs', 'pjs_group'
.loadlib 'pjs_group_ops'
.sub _ :main
use_much_memory()
test()
.end
.sub test :anon
.local pmc a, b, c, d, e
a = new .PjsBoolean
b = new .PjsNumber
c = new .PjsNumber
d = new .PjsNumber
e = new .PjsNumber
c = a b
trace 1
e = c d
.end
.sub use_much_memory
$P0 = new .ResizablePMCArray
$I0 = 0
loop:
$P1 = new .String
$P1 = 'hello world'
$P0[$I0] = $P1
inc $I0
if $I0 10 goto loop
.return ($P0)
.end
~/parrot_svn/parrot/languages/pjs$ parrot mmd.pir
43 bitwise_and P4, P2, P3 P4=PjsNumber=PMC(0xb62aa00c)
P2=PjsNumber=PMC(0xb62aa034) P3=PjsNumber=PMC(0xb62aa020)
Trace/breakpoint trap (core dumped)
~/parrot_svn/parrot/languages/pjs$ parrot --no-gc mmd.pir
43 bitwise_and P4, P2, P3 P4=PjsNumber=PMC(0xb60c0fa8)
P2=PjsNumber=PMC(0xb60c0fd0) P3=PjsNumber=PMC(0xb60c0fbc)
Segmentation fault (core dumped)
I am new to debugging, but (if I didn't do anything wrong) I think
that the problem resides in the mmd table of bitwise_and.
in function mmd_dispatch_p_ppp in src/mmd.c, while executing the
second bitwise_and:
real_function = (mmd_f_p_ppp)get_mmd_dispatcher(interp,
left, right, func_nr, is_pmc); // is_pmc is set to 0
here, but I set it to 1 from the debugger
if (is_pmc) {
PMC * const sub = (PMC*)real_function; // if I look at the
contents of sub, it is a .String pmc with content Hello world
I have the same problem with bitwise_or. I am suspecting that the mmd
table gets somehow overwritten, but I wasn't capable of finding out
if/how it's.
Any ideas? Did I do something wrong implementing my PMC's, or could it
be a general parrot problem? But I couldn't trigger the same problem
with parrot .Integer or .Float types.
--
Mehmet
Re: propose renaming Hash to Dict
On Fri, Jun 01, 2007 at 06:05:58PM +0200, Thomas Wittek wrote: : Daniel Hulme: : Larry Wall: : I name things in English. Hash is just something that is disordered : : I'm not a native english speaker, but I've never heard or read the word : hash outside CS. : : you've never eaten corned beef hash. : : To conclude, as hash definitely tastes better than a dictionary, we : should stick to that name. ;) : : At least nobody can say that Perl is bad taste! Then maybe we should rename Array to Skewer or Kabob or some such... Hmm, except it's hard to random access the middle... Maybe AntsOnALog... (celery, cream cheese/peanut butter, and raisins) Larry
Re: [perl #41168] graceful no compiler error message?
On Thursday 31 May 2007 18:01:55 James E Keenan wrote: Invoking the compiler on a simple source file, then checking that the generated code exists seems such an obvious test that there must be a fatal flaw in it. What am I missing? This patch grew out of Hackathon Toronto and was posted to RT, but not initially cc-ed to the list. Please review this patch. Thank you very much. This patch is very close. Instead of handling compilation manually, I recommend instead using cc_gen() and cc_build() from Parrot::Configure::Step. See config/auto/sizes.pm for an example. -- c
Re: propose renaming Hash to Dict
On Fri, Jun 01, 2007 at 06:52:37AM -0400, Mark J. Reed wrote: : On 6/1/07, Larry Wall [EMAIL PROTECTED] wrote: : Nope. Hash is mostly about meaning, and very little about implementation. : Please don't assume that I name things according to Standard Names in : Computer Science. I name things in English. : : Then why did we need a separate use English pragma? :) We needed use English because I was temporarily drawn to the shell side of the Force. I have repented. : Are you the one who originally came up with hash for %vars? IIRC, : they were officially called just associative arrays through Perl4, : but hash was a well-understood community nickname for them for some : time before you canonized it with ref($var) eq 'HASH' in Perl5... Yes, I believe I was the one who decided that associative arrays needed a shorter name, and after a period of discussion on perl5-porters, settled on hash as the new technical term in Perl culture. But I'm not sure the mailing list archive goes back far enough to verify the exact sequence of events. Certainly I made the final decision, but it's quite possible someone else suggested it first. But I seem to recall getting extremely tired of typing associative array while working on Camel II, and that was likely the instigation. Larry
Better GCC Visibility
I think this patch fixes the visibility problem with Linux and GCC versions
before 4.0. I think it also enables symbol hiding on other platforms with
GCC.
-- c
=== config/auto/gcc.pm
==
--- config/auto/gcc.pm (revision 3726)
+++ config/auto/gcc.pm (local)
@@ -132,6 +132,7 @@
# We shouldn't be using __packed__, but I doubt -Wpacked will harm
# us -Wpadded may prove interesting, or even noisy.
# -Wunreachable-code might be useful in a non debugging version
+4.0 = -fvisibility=hidden,
);
my @cage_opt_and_vers = (
0 =
@@ -265,6 +266,9 @@
HAS_aligned_funcptr = 1
);
+$conf-data-set( sym_export = '__attribute__ ((visibility(default)))' )
+if $gccversion 4.0;
+
$conf-data-set( HAS_aligned_funcptr = 0 )
if $^O eq 'hpux';
=== config/init/hints/linux.pm
==
--- config/init/hints/linux.pm (revision 3726)
+++ config/init/hints/linux.pm (local)
@@ -52,9 +52,6 @@
}
}
else {
-# hide non-exported symbols
-$cflags .= ' -fvisibility=hidden';
-
if ( $ld_share_flags !~ /-fPIC/ ) {
$ld_share_flags .= ' -fPIC';
}
@@ -90,7 +87,6 @@
libparrot_shared = 'libparrot$(SHARE_EXT).$(SOVERSION)',
libparrot_shared_alias = 'libparrot$(SHARE_EXT)',
libparrot_soname = '-Wl,-soname=libparrot$(SHARE_EXT).$(SOVERSION)',
-sym_export = '__attribute__ ((visibility(default)))',
);
if ( ( split( '-', $Config{archname} ) )[0] eq 'ia64' ) {
Re: propose renaming Hash to Dict
At 09:15 -0700 6/1/07, Larry Wall wrote: : To conclude, as hash definitely tastes better than a dictionary, we : should stick to that name. ;) : : At least nobody can say that Perl is bad taste! Then maybe we should rename Array to Skewer or Kabob or some such... Hmm, except it's hard to random access the middle... Maybe AntsOnALog... (celery, cream cheese/peanut butter, and raisins) Since Larry started it: Don't forget that a common form of hash as a food is SPAM in all capitals. Perhaps perl6 could get special dispensation from Hormel. -- -- From the U S of A, the only socialist country that refuses to admit it. --
[svn:perl6-synopsis] r14412 - doc/trunk/design/syn
Author: larry Date: Fri Jun 1 12:44:27 2007 New Revision: 14412 Modified: doc/trunk/design/syn/S06.pod Log: note that parsed/reparsed also influences whether trailing bracket is assumed Modified: doc/trunk/design/syn/S06.pod == --- doc/trunk/design/syn/S06.pod(original) +++ doc/trunk/design/syn/S06.podFri Jun 1 12:44:27 2007 @@ -13,9 +13,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 21 Mar 2003 - Last Modified: 30 May 2007 + Last Modified: 1 Jun 2007 Number: 6 - Version: 86 + Version: 87 This document summarizes Apocalypse 6, which covers subroutines and the @@ -1467,14 +1467,17 @@ =item Cis parsed Specifies the subrule by which a macro call is parsed. The parse -always starts after the macro's initial token. +always starts after the macro's initial token. If the operator has +two parts (circumfix or postcircumfix), the final token is also automatically +matched, and should not be matched by the supplied regex. =item Cis reparsed Also specifies the subrule by which a macro call is parsed, but restarts the parse before the macro's initial token, usually because you want to parse using an existing rule that expects to traverse the initial -token. +token. If the operator has two parts (circumfix or postcircumfix), the +final token must also be explicitly matched by the supplied regex. =item Cis cached
Re: propose renaming Hash to Dict
On 6/1/07, Doug McNutt [EMAIL PROTECTED] wrote: At 09:15 -0700 6/1/07, Larry Wall wrote: : To conclude, as hash definitely tastes better than a dictionary, we : should stick to that name. ;) : : At least nobody can say that Perl is bad taste! Then maybe we should rename Array to Skewer or Kabob or some such... Hmm, except it's hard to random access the middle... Maybe AntsOnALog... (celery, cream cheese/peanut butter, and raisins) Since Larry started it: Don't forget that a common form of hash as a food is SPAM in all capitals. Perhaps perl6 could get special dispensation from Hormel. -- -- From the U S of A, the only socialist country that refuses to admit it. -- That is just not kosher.
Re: [svn:parrot] r18726 - trunk/include/parrot
On Friday 01 June 2007 13:21:52 [EMAIL PROTECTED] wrote: Log: Add function attributes for noreturn to help GCC Are those C89 attributes? Do they break other compilers? -- c
Re: mmd for bitwise_and causes a segfault with my pmc types
It seems to work in general, but in some cases (especially when I allocate too much memory) it causes me a segfault or an error like: Trace/breakpoint trap (core dumped) It was caused by some unitialized memory in src/mmd.c. rt #43105 solves it. -- Mehmet
Use const proactively
From my wiki at http://xoa.petdance.com/Use_const_proactively
Const your local variables
The following is adapted from C++ Coding Standards by Herb Sutter and
Andrei Alexandrescu (with some C++-specific stuff removed):
const is your friend: Immutable values are easier to understand,
track, and reason about, so prefer consted variables wherever it is
sensible and make const your default choice when you define a value.
It's safe, and it's checked at compile time. Don't cast away const
except to call a const-incorrect function. Constants simplify code
because you only have to look at where the constant is defined to
know its value everywhere. Consider this code:
void Fun( const char * p ) {
const size_t len = strlen(p);
/* ... 30 more lines ... */
if (len 1)
...
}
When seeing len's definition above, you gain instance confidence
about len's semantics throughout its scope. It's a snapshot of p's
length at a specific point. Just by looking up one line, you know
len's semantics over its whole scope. Without the const, len might be
later modified. Best of all, the compiler will help you ensure that
this truth remains true.
Yes, const is viral -- add it in one place, and it wants to
propagate throughout your code as you call other functions who
signatures aren't yet const-correct. This is a feature, and this
quality greatly increases const's power.
Const-correctness is worthwhile, proven, effective, and highly
recommended. Understanding how and where a program's state changes is
vital, and const documents that directly in code where the compiler
can help to enforce it.
== Const your function parameters
Consting function parameters also lets the compiler know the behavior
of your function. Consider this snippet of code:
char buffer[20];
c = buffer[0];
The compiler or lint can now warn you that you're using buffer even
though it hasn't been initialized. But what about this:
void foo(char *p);
char buffer[20];
foo(buffer);
c = buffer[0];
Is foo() initializing what is sent into it? The compiler can't tell.
But if you define it like so:
void foo(const char *p);
now the compiler knows that buffer can't be getting initialized.
Think of consting your function parameters as a very basic contract
with the caller.
== What am I consting?
In an declaration such as
char *p;
there are two places const can be placed - with different effects.
const char* p;
The bytes p points at are considered const when accessed via p,
but the pointer p itself is not const
char* const p;
The pointer p is considered const, but the bytes it points at
are not
They can be combined:
const char* const p;
Both constant pointer and constant data
The rule is that const affects the thing immediately following it.
xoxo,
Andy
--
Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [svn:parrot] r18726 - trunk/include/parrot
On Jun 1, 2007, at 3:26 PM, chromatic wrote: Log: Add function attributes for noreturn to help GCC Are those C89 attributes? Do they break other compilers? They're stolen from p5, and they're macros that go away if you don't define things like -DHASATTRIBUTE_NORETURN. I'm all over the portability, c. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
[perl #43102] t/pmc/threads.t tests 5,7 fail with --gc=libc
# New Ticket Created by Mark Glines
# Please include the string: [perl #43102]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43102
While testing/trying to fix RT #42938, I noticed an additional test
failure in t/pmc/threads.t. Test 7 crashes with a signal 11
(segmentation fault), on my Gentoo Linux-x86 box. This is with svn
r18722.
I've stared at gdb, header files and preprocessor output for a while.
I'll include all the info I think is relevant.
t/pmc/threadsNOK 7/20
# Failed test (t/pmc/threads.t at line 290)
# Exited with error code: [SIGNAL 11]
# Received:
# thread
#
# Expected:
# /(done\nthread\n)|(thread\ndone\n)/
#
Starting program: /home/paranoid/parrot/parrot detach.pir
[Thread debugging using libthread_db enabled]
[New Thread -1227352400 (LWP 25907)]
warning: Lowest section in /usr/lib/libicudata.so.36 is .hash at 00d4
[New Thread -1227355216 (LWP 25910)]
[New Thread -1235747920 (LWP 25911)]
[New Thread -1244140624 (LWP 25912)]
thread
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1244140624 (LWP 25912)]
0xb7da53ab in clear_cow (interp=0x82256f0, pool=0x82285c8, cleanup=1)
at src/gc/dod.c:469
469 *refcount = 0;
(gdb) print refcount
$1 = (INTVAL * const) 0xb7eb4b41
The code in question:
INTVAL * const refcount = PObj_bufrefcountptr(b);
*refcount = 0;
Which expands to:
INTVAL * const refcount = Buffer_alloc_unit *)((char
*) (b)-obj.u._b._bufstart - (((size_t) ((Buffer_alloc_unit
*)0)-buffer-ref_ count));
*refcount = 0;
(gdb) bt
#0 0xb7da53ab in clear_cow (interp=0x82256f0, pool=0x82285c8,
cleanup=1) at src/gc/dod.c:469
#1 0xb7da30ae in sweep_cb_buf (interp=0x82256f0, pool=0x82285c8, flag=6,
arg=0x0) at src/headers.c:691
#2 0xb7da2f56 in Parrot_forall_header_pools (interp=0x82256f0, flag=6,
arg=0x0, func=0xb7da3080 sweep_cb_buf) at src/headers.c:640
#3 0xb7da318f in Parrot_destroy_header_pools (interp=0x82256f0)
at src/headers.c:732
#4 0xb7d490bb in Parrot_really_destroy (interp=0x82256f0, exit_code=0,
arg=0x0) at src/inter_create.c:390
#5 0xb7dc5399 in thread_func (arg=0x83c0c28) at src/thread.c:403
#6 0xb7b6f380 in start_thread () from /lib/libpthread.so.0
#7 0xb6f1554e in clone () from /lib/libc.so.6
(gdb) print *b
$3 = {obj = {u = {_b = {_bufstart = 0xb7eb4b45, _buflen = 6}, _ptrs = {
_struct_val = 0xb7eb4b45, _pmc_val = 0x6}, _i = {
_int_val = -1209316539, _int_val2 = 6},
_num_val = 1.425648877988937e-313, _string_val = 0xb7eb4b45},
flags = 196864}}
(gdb) print ((char*)(b-obj.u._b._bufstart))
$4 = 0xb7eb4b45 parrot
So it looks to me like it's expecting to find a refcount integer right
before the buffer, in memory. But the buffer is a null-terminated
string, packed in memory with another string directly preceding it...
no refcount integer!
Here's a hexdump of the memory:
b7eb4b30 75 70 2e 63 00 28 73 65 6c 66 29 2d 3e 70 6d 63 |up.c~(self)-pmc|
b7eb4b40 5f 65 78 74 00 70 61 72 72 6f 74 00 00 00 00 00 |_ext~parrot~|
_bufstart pointer: ^^ ^
(in the ASCII part of that hexdump, ~ means null.)
I'm in way over my head here, but I see 3 warning signs telling me
this is a bug:
1. The SIGSEGV, obviously.
2. The lack of refcount integer where the code expects to find one.
3. The buffer isn't dword-aligned. (Aren't allocated buffers aligned
by default? Could this be a constant string defined at compile time,
instead?)
I also get an intermittant failure of test 5 (occurs about once every 5
runs). I believe it is likely to be caused by the same issue, but I
have not debugged it to the same extent.
# Failed test (t/pmc/threads.t at line 204)
# Exited with error code: [SIGNAL 11]
# Received:
# start 1
# in thread
# done
#
# Expected:
# start 1
# in thread
# done
Mark
Use const proactively
Here's a bit of an explanation of why I const like I do:
http://xoa.petdance.com/Use_const_proactively
One of my jobs in Perl 5 and Parrot has been to apply const as much
as humanly possible.
== Const your local variables
The following is adapted from C++ Coding Standards by Herb Sutter and
Andrei Alexandrescu (with some C++-specific stuff removed):
const is your friend: Immutable values are easier to understand,
track, and reason about, so prefer consted variables wherever it is
sensible and make const your default choice when you define a value.
It's safe, and it's checked at compile time. Don't cast away const
except to call a const-incorrect function. Constants simplify code
because you only have to look at where the constant is defined to
know its value everywhere. Consider this code:
void Fun( const char * p ) {
const size_t len = p;
/* ... 30 more lines ... */
}
When seeing len's definition above, you gain instance confidence
about len's semantics throughout its scope. It's a snapshot of p's
length at a specific point. Just by looking up one line, you know
len's semantics over its whole scope. Without the const, len might be
later modified. Best of all, the compiler will help you ensure that
this truth remains true.
Yes, const is viral -- add it in one place, and it wants to
propagate throughout your code as you call other functions who
signatures aren't yet const-correct. This is a feature, and this
quality greatly increases const's power.
Const-correctness is worthwhile, proven, effective, and highly
recommended. Understanding how and where a program's state changes is
vital, and const documents that directly in code where the compiler
can help to enforce it.
== Const your function parameters
Consting function parameters also lets the compiler know the behavior
of your function. Consider this snippet of code:
char buffer[20];
c = buffer[0];
The compiler or lint can now warn you that you're using buffer even
though it hasn't been initialized. But what about this:
void foo(char *p);
char buffer[20];
foo(buffer);
c = buffer[0];
Is foo() initializing what is sent into it? The compiler can't tell.
But if you define it like so:
void foo(const char *p);
now the compiler knows that buffer can't be getting initialized.
Think of consting your function parameters as a very basic contract
with the caller.
--
Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [perl #43105] [PATCH] function mmd.c::mmd_expand_y: newly allocated memory unitialized
On Friday 01 June 2007 13:39:32 Mehmet Yavuz Selim Soyturk wrote:
Function mmd_expand_y in src/mmd.c allocates new memory for the mmd
table, but does not initialize the newy allocated memory to NULL,
which causes segfaults for some cases. The attached patch solves that
problem.
I thought that might happen. I prefer this memset() patch, but if it doesn't
work everywhere, your patch should work.
-- c
=== src/mmd.c
==
--- src/mmd.c (revision 3732)
+++ src/mmd.c (local)
@@ -623,19 +623,22 @@
static void
mmd_expand_y(Interp *interp, INTVAL func_nr, INTVAL new_y)
{
-funcptr_t *new_table;
-UINTVALnew_size;
+UINTVALnew_size, i, x, y;
MMD_table * const table = interp-binop_mmd_funcs + func_nr;
assert(table-x);
-new_size = sizeof (funcptr_t) * table-x * new_y;
+x= table-x;
+y= table-y;
+new_size = sizeof (funcptr_t) * x * new_y;
if (table-mmd_funcs)
table-mmd_funcs = mem_sys_realloc(table-mmd_funcs, new_size);
else
table-mmd_funcs = (funcptr_t *)mem_sys_allocate(new_size);
+memset(table-mmd_funcs + x * y, 0, x * (new_y - y));
+
table-y = new_y;
}
Re: [svn:parrot] r18724 - in trunk/config: auto init/hints
On Fri, Jun 01, 2007 at 01:04:48PM -0700, [EMAIL PROTECTED] wrote: Log: [Configure] Move the visibility hints into the GCC hints and enable it only for GCC 4.x and later. This makes it work other places than Linux and fixes the compilation for earlier GCC versions. Works for me! :-) Thanks. Nicholas Clark
[perl #43105] [PATCH] function mmd.c::mmd_expand_y: newly allocated memory unitialized
# New Ticket Created by Mehmet Yavuz Selim Soyturk
# Please include the string: [perl #43105]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43105
Function mmd_expand_y in src/mmd.c allocates new memory for the mmd
table, but does not initialize the newy allocated memory to NULL,
which causes segfaults for some cases. The attached patch solves that
problem.
--
Mehmet
Index: src/mmd.c
===
--- src/mmd.c (revision 18722)
+++ src/mmd.c (working copy)
@@ -624,18 +624,30 @@
mmd_expand_y(Interp *interp, INTVAL func_nr, INTVAL new_y)
{
funcptr_t *new_table;
-UINTVALnew_size;
+UINTVAL x;
+UINTVAL y;
+UINTVAL i;
+UINTVAL new_size;
MMD_table * const table = interp-binop_mmd_funcs + func_nr;
assert(table-x);
+
+x = table-x;
+y = table-y;
-new_size = sizeof (funcptr_t) * table-x * new_y;
+new_size = sizeof (funcptr_t) * x * new_y;
if (table-mmd_funcs)
-table-mmd_funcs = mem_sys_realloc(table-mmd_funcs, new_size);
+new_table = mem_sys_realloc(table-mmd_funcs, new_size);
else
-table-mmd_funcs = (funcptr_t *)mem_sys_allocate(new_size);
-
+new_table = (funcptr_t *)mem_sys_allocate(new_size);
+
+/* Initialize the newly allocated space with NULLs */
+for (i = x * y; i x * new_y; i++) {
+new_table[i] = NULL;
+}
+
+table-mmd_funcs = new_table;
table-y = new_y;
}
[perl #43107] t/tools/pmc2cutils/05-gen_c: Warnings being thrown in testing of Parrot::Pmc2c::Pmc2cMain
# New Ticket Created by James Keenan # Please include the string: [perl #43107] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43107 --- osname= linux osvers= 2.6.15 arch= i386-linux-thread-multi cc= cc --- Flags: category=core severity=medium ack=no --- Tonight, on both Linux and Darwin, I configured with the '--test' option to Configure.pl that runs, among other things, the build tools tests once Configure.pl itself has completed. These tests generally always pass -- and they did so tonight -- but tonight one test ran with warnings not previously seen. Here is the output of 'prove -v t/tools/pmc2cutils/05-gen_c.t on Linux: 11-226:parrot] 507 $ prove -v t/tools/pmc2cutils/05-gen_c.t t/tools/pmc2cutils/05-gen_c OK: Parrot top directory located 1..68 ok 1 - use Parrot::Pmc2c::Pmc2cMain; ok 2 - use Cwd; ok 3 - use File::Temp; ok 4 - changed to temp directory for testing ok 5 - created src/ under tempdir ok 6 - created src/pmc/ under tempdir ok 7 - all src/pmc/*.pmc files copied to tempdir ok 8 - The object isa Parrot::Pmc2c::Pmc2cMain ok 9 - dump_vtable created vtable.dump ok 10 - dump_pmc succeeded ok 11 - default.dump created as expected Cannot generate /tmp/cv7C2swFcy/src/pmc/default.c code for unknown method 'get_bool_keyed_int'. Cannot generate /tmp/cv7C2swFcy/src/pmc/default.c code for unknown method 'elements_keyed_int'. Cannot generate /tmp/cv7C2swFcy/src/pmc/default.c code for unknown method 'set_bool_keyed_int'. Cannot generate /tmp/cv7C2swFcy/src/pmc/default.c code for unknown method 'is_equal_str'. ok 12 - gen_c completed successfully; args: default.pmc ok 13 - changed back to original directory ok 14 - changed to temp directory for testing ok 15 - created src/ under tempdir ok 16 - created src/pmc/ under tempdir ok 17 - all src/pmc/*.pmc files copied to tempdir ok 18 - The object isa Parrot::Pmc2c::Pmc2cMain ok 19 - dump_vtable created vtable.dump ok 20 - dump_pmc succeeded ok 21 - default.dump created as expected ok 22 - array.dump created as expected Cannot generate /tmp/u7Ly25yooR/src/pmc/default.c code for unknown method 'get_bool_keyed_int'. Cannot generate /tmp/u7Ly25yooR/src/pmc/default.c code for unknown method 'elements_keyed_int'. Cannot generate /tmp/u7Ly25yooR/src/pmc/default.c code for unknown method 'set_bool_keyed_int'. Cannot generate /tmp/u7Ly25yooR/src/pmc/default.c code for unknown method 'is_equal_str'. ok 23 - gen_c completed successfully; args: default.pmc and array.pmc ok 24 - changed back to original directory ok 25 - changed to temp directory for testing ok 26 - created src/ under tempdir ok 27 - created src/pmc/ under tempdir ok 28 - all src/pmc/*.pmc files copied to tempdir ok 29 - The object isa Parrot::Pmc2c::Pmc2cMain ok 30 - dump_vtable created vtable.dump ok 31 - dump_pmc succeeded ok 32 - default.dump created as expected Cannot generate /tmp/51xFgg6kSM/src/pmc/default.c code for unknown method 'get_bool_keyed_int'. Cannot generate /tmp/51xFgg6kSM/src/pmc/default.c code for unknown method 'elements_keyed_int'. Cannot generate /tmp/51xFgg6kSM/src/pmc/default.c code for unknown method 'set_bool_keyed_int'. Cannot generate /tmp/51xFgg6kSM/src/pmc/default.c code for unknown method 'is_equal_str'. ok 33 - gen_c completed successfully; args: default.pmc ok 34 - debug option worked ok 35 - changed back to original directory ok 36 - changed to temp directory for testing ok 37 - created src/ under tempdir ok 38 - created src/pmc/ under tempdir ok 39 - all src/pmc/*.pmc files copied to tempdir ok 40 - The object isa Parrot::Pmc2c::Pmc2cMain ok 41 - dump_vtable created vtable.dump ok 42 - verbose option worked ok 43 - dump_pmc succeeded ok 44 - default.dump created as expected ok 45 - verbose option worked Cannot generate /tmp/8LfDhf4liZ/src/pmc/default.c code for unknown method 'get_bool_keyed_int'. Cannot generate /tmp/8LfDhf4liZ/src/pmc/default.c code for unknown method 'elements_keyed_int'. Cannot generate /tmp/8LfDhf4liZ/src/pmc/default.c code for unknown method 'set_bool_keyed_int'. Cannot generate /tmp/8LfDhf4liZ/src/pmc/default.c code for unknown method 'is_equal_str'. ok 46 - gen_c completed successfully; args: default.pmc ok 47 - debug option worked ok 48 - changed back to original directory ok 49 - changed to temp directory for testing ok 50 - created src/ under tempdir ok 51 - created src/pmc/ under tempdir ok 52 - src/pmc/*.pmc files copied to tempdir ok 53 - The object isa Parrot::Pmc2c::Pmc2cMain ok 54 - dump_vtable created vtable.dump ok 55 - gen_c() predictably failed because dump_pmc() was not called first ok 56 - changed back to original directory ok 57 - changed to temp directory for testing ok 58 - created src/ under tempdir ok 59 - created src/pmc/ under tempdir ok 60 - all src/pmc/*.pmc files copied to tempdir ok 61 - The object isa Parrot::Pmc2c::Pmc2cMain ok 62 - dump_vtable created vtable.dump ok 63 - dump_pmc succeeded
[perl #43108] [PATCH] Getting Parrot compiled with C++ - Part one
# New Ticket Created by Steve Peters
# Please include the string: [perl #43108]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43108
The attached patch gets Parrot partially compiles with C++ (g++ actually).
This work gets the compile going through the start of the imcc compiler.
Expect part two to get it the rest of the way tomorrow.
Steve Peters
[EMAIL PROTECTED]
Index: src/stm/waitlist.c
===
--- src/stm/waitlist.c (revision 18722)
+++ src/stm/waitlist.c (working copy)
@@ -11,7 +11,7 @@
txlog = Parrot_STM_tx_log_get(interp);
if (!txlog-waitlist_data) {
txlog-waitlist_data =
-mem_sys_allocate_zeroed(sizeof (*txlog-waitlist_data));
+mem_allocate_zeroed_typed(waitlist_thread_data);
MUTEX_INIT(txlog-waitlist_data-signal_mutex);
txlog-waitlist_data-signal_cond = interp-thread_data-interp_cond;
#if WAITLIST_DEBUG
@@ -36,13 +36,13 @@
thr = get_thread(interp);
if (!thr-entries) {
-thr-entries = mem_sys_allocate_zeroed(sizeof (*thr-entries) * 4);
+thr-entries = mem_allocate_zeroed_typed(waitlist_entry*);
thr-entry_count = 4;
}
if (thr-used_entries = thr-entry_count) {
size_t i;
-thr-entries = mem_sys_realloc(thr-entries,
+thr-entries = (waitlist_entry**)mem_sys_realloc(thr-entries,
sizeof (*thr-entries) * thr-entry_count * 2);
for (i = thr-entry_count; i thr-entry_count * 2; ++i) {
thr-entries[i] = NULL;
@@ -52,7 +52,7 @@
i = thr-used_entries++;
if (!thr-entries[i])
-thr-entries[i] = mem_sys_allocate_zeroed(sizeof (**thr-entries));
+thr-entries[i] = mem_allocate_zeroed_typed(waitlist_entry);
assert(thr-entries[i]-head == NULL);
assert(thr-entries[i]-next == NULL);
@@ -67,7 +67,7 @@
int successp = -1;
assert(entry-next == NULL);
do {
-PARROT_ATOMIC_PTR_GET(entry-next, waitlist-first);
+entry-next = (waitlist_entry *)waitlist-first.val;
assert(successp != -1 || entry-next != entry);
assert(entry-next != entry);
PARROT_ATOMIC_PTR_CAS(successp, waitlist-first, entry-next, entry);
@@ -100,7 +100,7 @@
return;
LOCK(waitlist-remove_mutex);
-PARROT_ATOMIC_PTR_GET(cur, waitlist-first);
+cur = (waitlist_entry *)waitlist-first.val;
/* if we became the first entry while we were acquiring the mutex */
while (cur == what) {
@@ -110,7 +110,7 @@
what-next = NULL;
return;
}
-PARROT_ATOMIC_PTR_GET(cur, waitlist-first);
+cur = (waitlist_entry *)waitlist-first.val;
}
if (!cur) {
@@ -178,7 +178,7 @@
/* make sure we are not interrupted by a concurrent removal */
LOCK(list-remove_mutex);
do {
-PARROT_ATOMIC_PTR_GET(cur, list-first);
+cur = (waitlist_entry *)list-first.val;
PARROT_ATOMIC_PTR_CAS(successp, list-first, cur, NULL);
} while (!successp);
Index: src/stm/backend.c
===
--- src/stm/backend.c (revision 18722)
+++ src/stm/backend.c (working copy)
@@ -47,7 +47,7 @@
static STM_tx_log *Parrot_STM_tx_log_alloc(Interp *interp, size_t size) {
int i;
STM_tx_log *log;
-log = mem_sys_allocate_zeroed(size);
+log = (STM_tx_log *)mem_sys_allocate_zeroed(size);
interp-thread_data-stm_log = (void *) log;
@@ -62,9 +62,9 @@
log-inner[0].first_read = log-inner[0].first_write = 0;
log-writes =
-mem_sys_allocate(sizeof (STM_write_record) * STM_START_RECORDS);
+(STM_write_record*)mem_sys_allocate(sizeof (STM_write_record) *
STM_START_RECORDS);
log-writes_alloced = STM_START_RECORDS;
-log-reads = mem_sys_allocate(sizeof (STM_read_record) *
STM_START_RECORDS);
+log-reads = (STM_read_record*)mem_sys_allocate(sizeof (STM_read_record) *
STM_START_RECORDS);
log-reads_alloced = STM_START_RECORDS;
log-last_read = log-last_write = -1;
@@ -89,7 +89,7 @@
if (!interp-thread_data || !interp-thread_data-stm_log)
return;
-log = interp-thread_data-stm_log;
+log = (STM_tx_log *)interp-thread_data-stm_log;
mem_sys_free(log-writes);
mem_sys_free(log-reads);
Parrot_STM_waitlist_destroy_thread(interp);
@@ -99,7 +99,7 @@
STM_tx_log *Parrot_STM_tx_log_get(Interp *interp) {
-STM_tx_log *log = interp-thread_data-stm_log; /* FIXME */
+STM_tx_log *log = (STM_tx_log *)interp-thread_data-stm_log; /* FIXME */
if (!log)
log = Parrot_STM_tx_log_alloc(interp, sizeof (STM_tx_log));
@@ -122,7 +122,7 @@
STM_TRACE(Parrot_STM_alloc);
make_bufferlike_pool(interp, sizeof (handle_data));
-handle = new_bufferlike_header(interp, sizeof (handle_data));
+handle = (handle_data
Re: propose renaming Hash to Dict
John Macdonald schreef: hash browned potatos which is a hash of chopped potato, onion, and sometimetimes other things fried brown. That comes from the French haché, meaning chopped. Best with lots of small pieces of beef in it as well. -- Groet, Ruud
SET_NULL
From include/parrot/parrot.h: /* weird architectures might need this, s. C-FAQ 5.17 * * the SET_NULL macros are only for system, where a NULL pointer * isn't represented by zeroes, so don't use these, for resetting * non-null pointers */ #ifdef HAS_NON_ZERO_NULL # define SET_NULL(x) x = NULL # define SET_NULL_P(x, s) x = (s)NULL #else # define SET_NULL(x) # define SET_NULL_P(x, s) #endif /* HAS_NON_ZERO_NULL */ This seems very wrong. SET_NULL() isn't actually setting any values if not HAS_NON_ZERO_NULL. Is there some reason it's not actually # define SET_NULL(x) x = 0 # define SET_NULL_P(x, s) x = (s)NULL And for that matter, what's wrong with just using x = NULL everywhere? Why do we need a macro to do this? xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [perl #43108] [PATCH] Getting Parrot compiled with C++ - Part one
On Friday 01 June 2007 16:51:18 Steve Peters wrote: The attached patch gets Parrot partially compiles with C++ (g++ actually). This work gets the compile going through the start of the imcc compiler. Danger! The patch to src/stm/waitlist.c causes segfaults in t/stm/runtime.t, test 3: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1230156912 (LWP 30260)] 0xb7e02645 in alloc_entry (interp=0x8231358) at src/stm/waitlist.c:57 57 assert(thr-entries[i]-head == NULL); (gdb) x thr 0x8237700: 0x (gdb) p thr $1 = (struct waitlist_thread_data *) 0x8237700 The patch to Parrot::Ops2c::Utils causes errors about multiple definitions of `core_numops' in interpreter.o and core_ops.o. This patch to the CGP core: --- lib/Parrot/OpTrans/CGP.pm. (revision 3741) +++ lib/Parrot/OpTrans/CGP.pm. (local) @@ -68,7 +68,7 @@ return $pred_def . END; /* defines - $0 - $type */ # define opcode_to_prederef(i, op) \\ - (void**) (op - CONTEXT(i-ctx)-pred_offset) + (opcode_t*) (op - (opcode_t*)CONTEXT(i-ctx)-pred_offset) ... causes segfaults for me in the shootout tests (probably because they run with -jC). If I remove the second cast from the line, the segfault goes away. I applied the rest as r18744. Thanks! -- c
Use const proactively
Here's a bit of an explanation of why I const like I do:
http://xoa.petdance.com/Use_const_proactively
One of my jobs in Perl 5 and Parrot has been to apply const as much
as humanly possible.
== Const your local variables
The following is adapted from C++ Coding Standards by Herb Sutter and
Andrei Alexandrescu (with some C++-specific stuff removed):
const is your friend: Immutable values are easier to understand,
track, and reason about, so prefer consted variables wherever it is
sensible and make const your default choice when you define a value.
It's safe, and it's checked at compile time. Don't cast away const
except to call a const-incorrect function. Constants simplify code
because you only have to look at where the constant is defined to
know its value everywhere. Consider this code:
void Fun( const char * p ) {
const size_t len = p;
/* ... 30 more lines ... */
}
When seeing len's definition above, you gain instance confidence
about len's semantics throughout its scope. It's a snapshot of p's
length at a specific point. Just by looking up one line, you know
len's semantics over its whole scope. Without the const, len might be
later modified. Best of all, the compiler will help you ensure that
this truth remains true.
Yes, const is viral -- add it in one place, and it wants to
propagate throughout your code as you call other functions who
signatures aren't yet const-correct. This is a feature, and this
quality greatly increases const's power.
Const-correctness is worthwhile, proven, effective, and highly
recommended. Understanding how and where a program's state changes is
vital, and const documents that directly in code where the compiler
can help to enforce it.
== Const your function parameters
Consting function parameters also lets the compiler know the behavior
of your function. Consider this snippet of code:
char buffer[20];
c = buffer[0];
The compiler or lint can now warn you that you're using buffer even
though it hasn't been initialized. But what about this:
void foo(char *p);
char buffer[20];
foo(buffer);
c = buffer[0];
Is foo() initializing what is sent into it? The compiler can't tell.
But if you define it like so:
void foo(const char *p);
now the compiler knows that buffer can't be getting initialized.
Think of consting your function parameters as a very basic contract
with the caller.
--
Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: SET_NULL
On Fri, Jun 01, 2007 at 07:53:35PM -0500, Andy Lester wrote: From include/parrot/parrot.h: /* weird architectures might need this, s. C-FAQ 5.17 * * the SET_NULL macros are only for system, where a NULL pointer * isn't represented by zeroes, so don't use these, for resetting * non-null pointers */ #ifdef HAS_NON_ZERO_NULL # define SET_NULL(x) x = NULL # define SET_NULL_P(x, s) x = (s)NULL #else # define SET_NULL(x) # define SET_NULL_P(x, s) #endif /* HAS_NON_ZERO_NULL */ This seems very wrong. SET_NULL() isn't actually setting any values if not HAS_NON_ZERO_NULL. Is there some reason it's not actually # define SET_NULL(x) x = 0 # define SET_NULL_P(x, s) x = (s)NULL And for that matter, what's wrong with just using x = NULL everywhere? Why do we need a macro to do this? I can't see any need for such a macro other than for the minor obfuscation that it allows. For most of the Parrot code, I haven't SET_NULL() used, and I haven't used it myself. I'm a bit curious how much it is actually used. Steve Peters [EMAIL PROTECTED]
Re: SET_NULL
On Jun 1, 2007, at 8:20 PM, Steve Peters wrote: I can't see any need for such a macro other than for the minor obfuscation that it allows. For most of the Parrot code, I haven't SET_NULL() used, and I haven't used it myself. I'm a bit curious how much it is actually used. $ ack SET_NULL src | wc -l 23 It looks like it's mostly for SET_NULL_P where they intent is to cast NULL to a given type, as in: src/inter_create.c:198:SET_NULL_P(CONTEXT(interp-ctx)- current_object, PMC*); But Lord knows there are enough cases where we're NOT using those macros and not getting problems. I'm gonna yank 'em. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: propose renaming Hash to Dict
On 6/1/07, Ruud H.G. van Tol [EMAIL PROTECTED] wrote: John Macdonald schreef: hash browned potatos which is a hash of chopped potato, onion, and sometimetimes other things fried brown. It's usually hash browns or hashed browns, and I've always assumed the former to be a shortened form of the latter. That comes from the French haché, meaning chopped. ...the past participle of hachier, which is literally to axe, from hache axe. Ultimately, yes, the English word hash comes from the French hache, but you have to go back to Norman times to get there. The word hash has been an English word for almost a millennium, and hashed browns are simply browns (browned potatoes) that have been hashed... -- Mark J. Reed [EMAIL PROTECTED]
[perl #43107] t/tools/pmc2cutils/05-gen_c: Warnings being thrown in testing of Parrot::Pmc2c::Pmc2cMain
From: James Keenan (via RT) [EMAIL PROTECTED] Date: Fri, 01 Jun 2007 16:46:06 -0700 Tonight, on both Linux and Darwin, I configured with the '--test' option to Configure.pl that runs, among other things, the build tools tests once Configure.pl itself has completed. These tests generally always pass -- and they did so tonight -- but tonight one test ran with warnings not previously seen . . . . . . I suspect the problem is to be found either in lib/Parrot/Pmc2c/Pmc2cMain.pm or in src/pmc/default.c. Could whoever has been working on these files in the past few days please take a look at this? The warnings are of very recent origin. Thank you very much. kid51 This is from the Small tweak to Pmc2c.pm I posted on 19-May and committed as r18646 on 26-May. Note that lib/Parrot/Pmc2c.pm is not actually doing anything different now, it's just telling you that none of the code for these methods is being used in the generated C file. So they are certainly not being tested now, and possibly haven't been for a while. -- Bob Rogers http://rgrjr.dyndns.org/
