Re: parrot cvs mirrored with svk
This now lives at http://svn.perl.org/parrot/cvs/ (use guest/guest) http://svn.perl.org/viewcvs/parrot/cvs/trunk/ It is updated from CVS once an hour. Have fun! -R At Sat, 7 Aug 2004 09:52:30 +0100, Chia-liang Kao wrote: [1 text/plain; us-ascii (7bit)] Hi, I've just setup a Subversion mirror of the parrot cvs repository with svk. Will try to keep it in sync until Robert have time to do similar setup on perl.org. So you could now use the Subversion repository (readonly) at: svn://svn.clkao.org/parrot/cvs/trunk web interface at http://svn.clkao.org/svnweb/parrot/ and for people with unfortunate per-minute metered ISDN, svk could be used to mirror the above url, create local branch and do commits locally. Later on generate a diff to apply to cvs, or if the development trunk switches to svn it would be even eaiser. Hopefully this could eventually allow more time for fine white wine while retaining the same excellent productivity. Cheers, CLK [2 application/pgp-signature (7bit)]
Re: Invalid value for shared scalar
Andrew Pimlott wrote:
I got this error, which I traced down to accidentally calling is() with
a hashref as the third argument, where the name should have been:
use Test::More 'no_plan';
is(1,1,{});
Autrijus has fixed this bug in bleadperl, see the patch at
http://public.activestate.com/cgi-bin/perlbrowse?patch=23167
It should be integrated in the next Test::Builder CPAN release.
I found some mailing list discussions about this problem without much
conclusion. This leads me to believe that perl threads are not mature
enough to foist on people without their express consent. Of course,
this case can be fixed, but if such innocent code can be broken by
threads, I'm sure there are more bugs lurking. And they are very
frustrating to debug for people without experience in perl threads.
In this case that's a bug in Test::Builder, not in perl.
So I suggest that Test::Builder not enable threads itself, unless
explicitly requested. Even if your code uses threads, it seems unlikely
that you'd want to run your tests in parallel anyway. You could perhaps
enable thread-safe tests with
use Test::Builder 'thread_safe';
Re: Invalid value for shared scalar
On Fri, Aug 27, 2004 at 09:24:20AM +0200, Rafael Garcia-Suarez wrote: In this case that's a bug in Test::Builder, not in perl. Sure, but it is a very easy bug to make. For perfectly normal code to break with threads is scary to me. And the fix looks fragile, especially without a comment. I would still prefer that Test::Builder not use threads if I don't ask for it. Can you tell me where this limitation in perl threads is documented? Is there any hope that it will be removed in the future? Andrew
Re: Invalid value for shared scalar
Andrew Pimlott wrote: Can you tell me where this limitation in perl threads is documented? Is there any hope that it will be removed in the future? It's not a limitation, if you share a hash it looks normal to me that you should share its elements too. (or you end up with weird quantum hashes that don't look the same from different threads...) That said, threads are underdocumented and the error message could be made much clearer.
Re: NCI Tests Failing
Joshua Gatcomb wrote: This might help shed some light: $ cd t/pmc $ parrot nci_1.pasm Not really. bash: parrot: command not found ;) You got an old parrot around somewhere in the path? $ parrot --gc-debug nci_1.pasm Segmentation fault (core dumped) Well, I just don't have these segfaults. Wait ... Oops, I've turned on incremental GC here, which could make it succeed. Recompiling ... another coffee ... No. All NCI tests are running fine here with --gc-debug leo
Re: Compile op with return values
Steve Fink wrote: On Aug-26, Leopold Toetsch wrote: .sub @regex_at_foo_imc_line_4711 # e.g. Yes, this illustrates what I was really getting at. My compiler can certainly take a subroutine name (or file and line number, or whatever) to use to generate the code with, but what is the proper way to pass that infomation in through the compile op? I don't know how your compiler generates the code. But you are probably concatenating a string of PIR instructions and pass that over to the Ccompile opcode. Anyway, the identifier you are using for the C.sub directive gets stored in globals and is the name of the subroutine. ... I can just stick it in some register, but it seems like there ought to be some standard-ish way of passing parameters to compilers. Which then makes me wonder why compile is done as an opcode rather than a method invocation on the return value of compreg. Ccompile as a method call for the compiler would really be a worthwhile extension. But you can provide your own compiler wrapper and pass the subroutine name to that function. [1] ... I see that for Compiler and NCI PMCs, that's exactly what it does, but for anything else it does the Parrot_runops_fromc_args_save thing; couldn't that be somehow exposed separately so that the compile op goes away? My only complaint about Ccompile is that it isn't transparent how to use it, whereas I am comfortable with invoking things and following the calling conventions. Well, there isn't much difference. The compile function is called as a plain function. A method call would additionally pass Cself, which you can pass as an argument too, if you need it. leo [1] sub test @MAIN .local NCI compiler find_global compiler, xcompile compreg XPASM, compiler .local pmc my_compiler my_compiler = compreg XPASM .local pmc the_sub .local string code code = print \ok\\n\\n code .= end\n the_sub = my_compiler(_foo, code) the_sub() the_sub = global _foo the_sub() .end .sub xcompile .param string sub_name .param string code $S0 = .pcc_sub $S0 .= sub_name $S0 .= :\n $S0 .= code .local NCI pasm_compiler pasm_compiler = compreg PASM # print $S0 $P0 = compile pasm_compiler, $S0 .pcc_begin_return .return $P0 .pcc_end_return .end
Re: NCI Tests Failing
At 10:06 AM +0200 8/27/04, Leopold Toetsch wrote:
Joshua Gatcomb wrote:
$ parrot --gc-debug nci_1.pasm
Segmentation fault (core dumped)
Well, I just don't have these segfaults. Wait ... Oops, I've turned
on incremental GC here, which could make it succeed. Recompiling ...
another coffee ...
No. All NCI tests are running fine here with --gc-debug
I can trigger the problem locally, though not with the nci tests.
(And, indeed, it may not be the NCI tests ultimately at fault) The
core dump shows things dying in the dod run. GDB's backtrace is:
Interestingly, in all the backtraces I've looked at, the obj=0x34 is constant.
#0 0x080d426d in pobject_lives (interpreter=0x8298528, obj=0x34) at
src/dod.c:198
198 if (PObj_is_live_or_free_TESTALL(obj)) {
(gdb) bt
#0 0x080d426d in pobject_lives (interpreter=0x8298528, obj=0x34) at
src/dod.c:198
#1 0x081eb524 in Parrot_PerlString_mark (interpreter=0x8298528,
pmc=0x82ca370) at classes/perlstring.c:61
#2 0x080d425b in mark_special (interpreter=0x8298528, obj=0x82ca370)
at src/dod.c:132
#3 0x080d42b2 in pobject_lives (interpreter=0x8298528,
obj=0x82ca370) at src/dod.c:218
#4 0x08092c35 in mark_hash (interpreter=0x8298528, hash=0x82d44b0)
at src/hash.c:319
#5 0x081fae50 in Parrot_PerlHash_mark (interpreter=0x8298528,
pmc=0x82ca388) at classes/perlhash.c:180
#6 0x080d4778 in Parrot_dod_trace_children (interpreter=0x8298528,
how_many=4294967292) at src/dod.c:451
#7 0x080d45b1 in trace_active_PMCs (interpreter=0x8298528,
trace_stack=1) at src/dod.c:369
#8 0x080d4ee3 in parrot_dod_ms_run (interpreter=0x8298528, flags=1)
at src/dod.c:1153
#9 0x080d502a in Parrot_do_dod_run (interpreter=0x8298528, flags=1)
at src/dod.c:1210
#10 0x080d2f87 in more_traceable_objects (interpreter=0x8298528,
pool=0x843a9b8) at src/smallobject.c:117
#11 0x080d302b in gc_ms_get_free_object (interpreter=0x8298528,
pool=0x843a9b8) at src/smallobject.c:183
#12 0x080d342a in get_free_buffer (interpreter=0x8298528,
pool=0x843a9b8) at src/headers.c:56
#13 0x080d3ad6 in new_bufferlike_header (interpreter=0x8298528,
size=96) at src/headers.c:465
#14 0x0808c5a2 in cst_new_stack_chunk (interpreter=0x8298528,
chunk=0x843aad8) at src/stack_common.c:168
#15 0x0808c5f2 in stack_prepare_push (interpreter=0x8298528,
stack_p=0x82987b0) at src/stack_common.c:192
#16 0x08085550 in Parrot_push_s (interpreter=0x8298528,
where=0x82986e8) at src/generic_register.c:51
#17 0x08101045 in Parrot_savetop (cur_opcode=0x405842b0,
interpreter=0x8298528) at ops/stack.ops:337
#18 0x0817e341 in runops_slow_core (interpreter=0x8298528,
pc=0x405842b0) at src/runops_cores.c:147
#19 0x0817bbc0 in runops_int (interpreter=0x8298528, offset=0) at
src/interpreter.c:809
#20 0x0817ca9a in runops (interpreter=0x8298528, offset=0) at
src/inter_run.c:69
#21 0x080ccb4f in Parrot_runcode (interpreter=0x8298528, argc=1,
argv=0xbbe8) at src/embed.c:701
#22 0x080cc94e in Parrot_runcode (interpreter=0x8298528, argc=1,
argv=0xbbe8) at src/embed.c:635
#23 0x0808468a in main (argc=1, argv=0xbbe8) at imcc/main.c:584
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: [perl #31346] [PATCH] tests and fixes for Undef PMC
At 1:43 PM -0700 8/26/04, Bernhard Schmalhofer (via RT) wrote: This patch adds some test for the Undef PMC. Apparently not -- the patch wasn't included... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: NCI Tests Failing
--- Leopold Toetsch [EMAIL PROTECTED] wrote: Joshua Gatcomb wrote: This might help shed some light: $ cd t/pmc $ parrot nci_1.pasm Not really. bash: parrot: command not found ;) You got an old parrot around somewhere in the path? No - believe it or not I only ever keep 1 version of parrot around at one time. It is a PITA when trying to experiment, but it makes accidents less likely - for me at least. Since I know when it stopped working (sometime between Friday afternoon and Monday morning), I am backtracking in CVS to find the exact change. leo Cheers Joshua Gatcomb a.k.a. Limbic~Region __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail
Re: parrotbench.pl - massive update (smaller update)
At 8:15 AM -0700 8/26/04, Joshua Gatcomb wrote: I found a few and have erradicated them. I also added some new functionality. You can now switch between CPU time and real (wall-clock) time Applied, thanks. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #31302] NCI GC issues
Dan Sugalski [EMAIL PROTECTED] wrote: Current CVS parrot looks to be losing track of NCI PMCs. Once a DOD run goes they get swept collected up, which is a Bad Thing. I think I could track it down. It wasn't strictly NCI related, though. The split of dynamic loaders init/load code caused an unitialized property setting (_type) in the library PMC. Marking this property hash then lead to an SIGSEGV or not, depending on the moon phase, RAM contents, and office temperature. leo
Re: NCI Tests Failing
--- Dan Sugalski [EMAIL PROTECTED] wrote:
I can trigger the problem locally, though not with
the nci tests.
(And, indeed, it may not be the NCI tests ultimately
at fault) The
core dump shows things dying in the dod run. GDB's
backtrace is:
Dan
Ok, I tracked it down to a CVS change of
include/parrot/dynext.h and src/dynext.c made in the
early morning hours on Monday (local time).
Here is the result of the diff:
$ diff include/parrot/dynext.h ../bad/dynext.h
3c3
* $Id: dynext.h,v 1.5 2004/04/22 08:55:05 leo Exp $
---
* $Id: dynext.h,v 1.6 2004/08/23 09:09:59 leo Exp $
14a15,20
/* dynamic lib/oplib/PMC init */
PMC *
Parrot_init_lib(Interp *interpreter,
PMC *(*load_func)(Interp *),
void (*init_func)(Interp *, PMC *));
and
$ diff src/dynext.c ../bad/dynext.c
3c3
$Id: dynext.c,v 1.26 2004/05/26 13:04:07 jrieks Exp
$
---
$Id: dynext.c,v 1.27 2004/08/23 09:10:02 leo Exp $
228a229,263
Parrot_init_lib(Interp *interpreter,
PMC *(*load_func)(Interp *),
void (*init_func)(Interp *, PMC *))
{
STRING *type;
PMC *lib_pmc;
if (!load_func) {
/* seems to be a native/NCI lib */
/*
* this PMC should better be constant, but
then all the contents
* and the metadata have to be constant too
* s. also build_tools/ops2c.pl and
lib/Parrot/Pmc2c.pm
*/
lib_pmc = pmc_new(interpreter,
enum_class_ParrotLibrary);
type = const_string(interpreter, NCI);
}
else {
lib_pmc = (*load_func)(interpreter);
/* we could set a private flag in the PMC
header too
* but currently only ops files have
struct_val set
*/
type = const_string(interpreter,
PMC_struct_val(lib_pmc) ? Ops :
PMC);
}
/*
* call init, if it exists
*/
if (init_func)
(init_func)(interpreter, lib_pmc);
return lib_pmc;
}
PMC *
266a302
/* get load_func */
272,292c308
if (!load_func) {
/* seems to be a native/NCI lib */
/*
* this PMC should better be constant, but
then all the contents
* and the metadata have to be constant too
* s. also build_tools/ops2c.pl and
lib/Parrot/Pmc2c.pm
*/
lib_pmc = pmc_new(interpreter,
enum_class_ParrotLibrary);
type = const_string(interpreter, NCI);
}
else {
lib_pmc = (*load_func)(interpreter);
/* we could set a private flag in the PMC
header too
* but currently only ops files have
struct_val set
*/
type = const_string(interpreter,
PMC_struct_val(lib_pmc) ? Ops :
PMC);
}
/*
* call init, if it exists
*/
---
/* get init_func */
298,299c314,316
if (init_func)
(init_func)(interpreter, lib_pmc);
---
lib_pmc = Parrot_init_lib(interpreter,
load_func, init_func);
If there is anything else I can do to help, please let
me know.
Joshua Gatcomb
a.k.a. Limbic~Region
__
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
Pathological Register Allocation Scenarios
Dan -- I think it would be interesting to find out how, say, gcc behaves on the pathological code structures you've run into. Could your compiler spit out a structurally (although not semantically! :) equivalent piece of C code that could be used with a C compiler to see how we do vs. C compilers in these cases? Regards, -- Gregor
Re: [perl #31302] NCI GC issues
--- Leopold Toetsch [EMAIL PROTECTED] wrote: I think I could track it down. It wasn't strictly NCI related, though. I guess you didn't need me to track down the CVS changes as this fixed the problem - THANKS. Cheers Joshua Gatcomb a.k.a. Limbic~Region ___ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush
Re: NCI Tests Failing
Dan Sugalski [EMAIL PROTECTED] wrote: I can trigger the problem locally, though not with the nci tests. (And, indeed, it may not be the NCI tests ultimately at fault) The core dump shows things dying in the dod run. It's fixed. See answer to your ticket. leo
Re: NCI Tests Failing
At 3:32 PM +0200 8/27/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: I can trigger the problem locally, though not with the nci tests. (And, indeed, it may not be the NCI tests ultimately at fault) The core dump shows things dying in the dod run. It's fixed. See answer to your ticket. Yep, I saw. Looks good. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
S5 tr concern
In S5, the following is stated:
The tr/// quote-like operator now also has a subroutine form.
* It can be given either a single PAIR:
$str =~ tr( 'A-C' = 'a-c' );
* Or a hash (or hash ref):
$str =~ tr( {'A'='a', 'B'='b', 'C'='c'} );
$str =~ tr( {'A-Z'='a-z', '0-9'='A-F'} );
$str =~ tr( %mapping );
I don't think that hashes of translation patterns should be allowed.
It's just too dangerous and too likely to result in hours of trying to
understand why tr is doing the wrong thing, but only sometimes.
Specifically, hashes do not maintain ordering, so a program like this:
$downcaserule = 'A-Z' = 'a-z';
$l33trule = 'EISTA' = '31574';
$str =~ tr( { $l33trule, $downcaserule } );
may or may not do what the naive reader expects, and randomly so!
I'd much rather that tr simply take an ordered list of pairs.
--
781-324-3772
[EMAIL PROTECTED]
http://www.ajs.com/~ajs
Re: [perl #31302] NCI GC issues
Joshua Gatcomb wrote: I guess you didn't need me to track down the CVS changes Well, I just started updating some slides for tomorrows Perl workshop in Bupapast: http://www.perl.org.hu/english/ changed a single line of code and got a segfault in the slide presentation program (slpod.imc). The gdb backtrace showed marking a PerlHash up the stack, so I compared the address of that hash generated in nci.c with the faulting one - they did differ. Ok what now: gdb p dump_hash(interpreter, hash) revealed two hash keys: _type and _filename. Grepping in the Parrot source gave 2 possible hashes that have a _type key, but only the library PMC has both. The rest was easy ;) ... THANKS. welcome Cheers Joshua Gatcomb leo
Re: Invalid value for shared scalar
On Fri, 2004-08-27 at 01:09, Andrew Pimlott wrote:
I would still prefer that Test::Builder not use threads if I don't ask
for it.
if( $] = 5.008 $Config{useithreads} ) {
require threads;
require threads::shared;
threads::shared-import;
}
If you don't have an ithreads-capable Perl, T::B won't use threads.
If you do, it must, because it has global data to which all threads need
access. T::B can't know how people will call it, so it takes the
approach of being safe and at least attempting to work on both threaded
and non-threaded Perls.
Requiring a compile-time flag isn't a solution because you don't know
*how* other people will use your code, the characteristics of their
installations, or what other modules they will have installed.
-- c
Re: S5 tr concern
Aaron Sherman writes:
Specifically, hashes do not maintain ordering, so a program like this:
$downcaserule = 'A-Z' = 'a-z';
$l33trule = 'EISTA' = '31574';
$str =~ tr( { $l33trule, $downcaserule } );
may or may not do what the naive reader expects, and randomly so!
you're assuming a particular implementation of tr in which it iterates
over the hash in default order on every character. being a fan of dfas
myself, it might compile a dfa of those substitutions and find out that
it's ambiguous right off the bat.
or not. the point is that it's only undefined for certain
implementations, and if we're smart, we'll use an implementation for
which it is not undefined.
but you're right, it could also take ordered pairs and disambiguate
based on that. that actually seems like a better way to go, since A-Z
isn't really a hash key but a pattern/replacement. looking up X in
the hash won't bring you to A-Z's value, so pairs sounds better to me.
luke
Re: [perl #31292] [PATCH classes/unmanagedstruct.pmc] Don't Share Nested Structs Across Parents
On Mon, 2004-08-23 at 03:17, Leopold Toetsch via RT wrote: I'd rather not have the cloning in the C code. If you don't reuse the nested structure descriptor, it's wasting resources. There could be another property that tells how many times someone is using it. I don't think you will like that idea much either though. On the other hand, duplicating only nested structs seems like it would use *less* memory than cloning the entire initializer. I think implementing the C clone vtable in unmanaged struct would be much cleaner. If you want to reuse a structure then clone it in the code. The question with C clone just is: how deep should it copy. This holds as well for arrays and hashes. Anyway, if it's a deep copy, then we probably would need freeze/thaw in the UnManagedStruct PMC. I prefer a deep copy; I really don't want to keep around every initializer in a complex struct such as SDL_Surface to clone each *Struct and rebuild it every time. -- c
Re: Invalid value for shared scalar
On Fri, Aug 27, 2004 at 10:16:48AM +0200, Rafael Garcia-Suarez wrote: Andrew Pimlott wrote: Can you tell me where this limitation in perl threads is documented? Is there any hope that it will be removed in the future? It's not a limitation, if you share a hash it looks normal to me that you should share its elements too. (or you end up with weird quantum hashes that don't look the same from different threads...) I would have expected the referent of a value assigned to a shared scalar would be automatically shared (ie, promoted to shared if it is unshared). It seems like that is what the programmer is probably asking for. That said, threads are underdocumented and the error message could be made much clearer. Something like reference to an unshared value assigned to a shared scalar? Does that cover all the cases? Andrew
Re: Invalid value for shared scalar
On Fri, Aug 27, 2004 at 09:20:09AM -0700, chromatic wrote: If you don't have an ithreads-capable Perl, T::B won't use threads. If you do, it must, Ideally, I would agree. But I think a compromise is in order, because perl threads aren't that mature and are error-prone to program. And most tests, even of threaded code, will call T::B from a single thread anyhow. There are two ways to do the compromise: 1. Go thread safe in T::B if threads has already been used, which just requires the programmer to use threads (or use a library that uses threads) before T::B--which he probably would do anyway. 2. Go thread safe in T::B only if the programmer requests it explicitly. I would favor this, because I still see perl threads as experimental. I think either of these is a reasonable trade-off. Andrew [1] http://www.nntp.perl.org/group/perl.perl5.porters/65583
Re: Invalid value for shared scalar
On Fri, 2004-08-27 at 11:03, Andrew Pimlott wrote: And most tests, even of threaded code, will call T::B from a single thread anyhow. How do you know what tests people will write? How do you know where people will run those tests? There are two ways to do the compromise: 1. Go thread safe in T::B if threads has already been used, which just requires the programmer to use threads (or use a library that uses threads) before T::B--which he probably would do anyway. use_ok( 'Some::Module::Requiring::Threads' ); 2. Go thread safe in T::B only if the programmer requests it explicitly. I would favor this, because I still see perl threads as experimental. It doesn't matter how *you* see Perl threads if users who may run your tests see them as worth using -- everyone using ActiveState's Perl for example, or all of Red Hat's users (I believe), use threaded Perls. How does the programmer know the characteristics of all of the Perl installations on which the test will run? How does he know the current and future internals of all supporting modules and whether they use threads or not? If you can't know all of this, then you have two options: 1) Ignore thread-safety altogether always. 2) Try to be thread-safe always. Test::Builder takes the second approach. -- c
Re: Invalid value for shared scalar
On Fri, Aug 27, 2004 at 12:06:47PM -0700, chromatic wrote:
It doesn't matter how *you* see Perl threads if users who may run your
tests see them as worth using
First, as I said, I agree with you ideally. I understand all the
points you're making, and they're basically valid. But the reality is,
there's a trade-off: By making it more convenient for people using
threads, we increase the probability of bugs for everyone.
Second, you're overblowing the problems with T::B not being thread-safe.
If my tests look like
use T::B;
use_ok('Module::Using::Threads');
ok(M::U::T::function_that_uses_threads);
ok(M::U::T::function_that_talks_to_threads);
...
it doesn't matter if T::B is thread-safe, because all of the calls to
T::B are in a single thread. I'm not saying you can't write tests that
use T::B from multiple threads, just that most people probably don't.
In other words, it's not like using a threaded perl or even threaded
libraries suddenly requires all code to be thread safe. Your claim that
my tests may break when run on a threaded perl is mistaken.
Third, it is not outlandish to require people to explicitly ask for
thread-safe behavior. This is common in the C world. It's not a good
thing, but it's not a disaster, especially as long as most perl code
doesn't use threads.
Anyway, I accept the decision against me, and hopefully there won't be
any more thread bugs in T::B, so this will never come up again!
Andrew
Synopsis 4: Return type of a ~~ b
I just reread the table of smart matches in Synopsis 4, and I realized that it doesn't say what is returned by a ~~ b. For example, the first line of this table says $_ $xType of Match ImpliedMatching Code == = == Any Code$ scalar sub truth match if $x($_) This is fine when $_ ~~ $x is called in boolean context. But what if the smart match operator is called in array or list context? Does $_ ~~ $x then return the result of $x($_)? I would expect that it does. After all, in Perl 5, the expression $string =~ /(a+)(b+)/ returns a list of captured substrings in list context Joe Gottman
Add functions in dynext to the extending interface?
Hello, should they be? I think they are covered by the statemente in pdd11 (... about the same level of access to Parrot that bytecode programs ...). Regards Mattia
