Re: Dereferencing Syntax (Was: Outer product considered useful)
Larry Wall wrote: Yes, * was originally a no-op in list context, but I think now we can use it to deref a list that would otherwise not interpolate itself. It maps better onto how a C programmer thinks, and if in scalar context it also happens to defer the signature checking to use the interpolated values, that's just an extra bonus. No! Please, God, no! I like perl, in no small part, because references are less confusing then pointers. Pointers, in no small part, are confusing because * means both this is a pointer (as in int*), and give me the thingy at (as in chr=*str). It seems like this is creating the same confusion. $foo = 0...;# take ref to an infinite range @bar = $foo;# puts in the iterator as a reference say @bar.elems; # prints 1 @bar = *$foo; # puts in 0... say @bar.elems; # prints Inf @bar = **$foo; # throws exception: Please install a lot more memory I hope that Perl will be intelegent enough to notice that the range is infinite, and say attempt to flatten infinite list rather then ENOMEM here. Also, how does the use of *$foo differ from @$foo here? Is the later going away? (I'd think that horrible, for the same reason as above: C is confusing because it's not always clear what you get when you *.) By the way, I like say, but wonder if we're going to become a horrible mix of APL and PHP. At least we don't have a Unicode alias for say (yet, why do I suspect we're about to get a unary » operator for it? Perhaps I'm just pessimistic this morning.) -=- James Mastros
New functions in the core (Was Re: Dereferencing Syntax)
- Original Message - From: Luke Palmer [EMAIL PROTECTED] Juerd writes: Has this Csay already been decided? Doesn't matter, because most of these decisions are up for discussion. I think everything that was decided when Apocalypse 3 was written has changed at least three times (contrast with Synposis 3 :-). If Larry is still adding functions to the core, maybe he can add the outer function that Luke suggested last week. This function would be very useful in inner loops, so if it is possible to implement it more efficiently in the core than as a sub in a module I think we should do so. Joe Gottman
Re: Dereferencing Syntax (Was: Outer product considered useful)
On Fri, Mar 26, 2004 at 08:59:36AM +0100, James Mastros wrote: : Larry Wall wrote: : Yes, * was originally a no-op in list context, but I think now we can : use it to deref a list that would otherwise not interpolate itself. : It maps better onto how a C programmer thinks, and if in scalar : context it also happens to defer the signature checking to use the : interpolated values, that's just an extra bonus. : No! Please, God, no! I like perl, in no small part, because references : are less confusing then pointers. Pointers, in no small part, are : confusing because * means both this is a pointer (as in int*), and : give me the thingy at (as in chr=*str). : : It seems like this is creating the same confusion. No, the confusion in C is because you never know whether * indicates a single item or the start of a list. In Perl it will only indicate that something should be considered listier than it otherwise would. : $foo = 0...; # take ref to an infinite range : @bar = $foo; # puts in the iterator as a reference : say @bar.elems;# prints 1 : @bar = *$foo;# puts in 0... : say @bar.elems;# prints Inf : @bar = **$foo; # throws exception: Please install a lot more : memory : I hope that Perl will be intelegent enough to notice that the range is : infinite, and say attempt to flatten infinite list rather then : ENOMEM here. Er, that was a joke... : Also, how does the use of *$foo differ from @$foo here? Is the later : going away? (I'd think that horrible, for the same reason as above: C : is confusing because it's not always clear what you get when you *.) No, @$foo is not going away. You can write it that way when you think it's clearer. The primary use of * is still to defeat the signature, and @$foo doesn't do that. : By the way, I like say, but wonder if we're going to become a horrible : mix of APL and PHP. At least we don't have a Unicode alias for say : (yet, why do I suspect we're about to get a unary » operator for it? I will let other people define their own Unicode alias for say. And I hope it takes them more than three keystrokes to type. :-) And say isn't in there because of APL or PHP. It's actually inspired by something worse in Ruby. : Perhaps I'm just pessimistic this morning.) Don't slit your wrists just yet... Larry
Re: Dereferencing Syntax (Was: Outer product considered useful)
On 2004-03-26 at 08:16:07, Larry Wall wrote:
And say isn't in there because of APL or PHP. It's actually inspired
by something worse in Ruby.
Presumably by something worse you mean puts? Not a great name, to
be sure, but it does have a venerable tradition behind it. :)
I do like having an auto-newline-appending version of print (without
having to make *all* my prints behave that way via -l), and my Perl
scripts of late often begin with a
sub puts(@) { for (@_) { print $_\n } }.
Of course, then I start forgetting my semicolons . . .
-Mark
Re: Dereferencing Syntax (Was: Outer product considered useful)
Larry Wall writes:
: Also, how does the use of *$foo differ from @$foo here? Is the later
: going away? (I'd think that horrible, for the same reason as above: C
: is confusing because it's not always clear what you get when you *.)
No, @$foo is not going away. You can write it that way when you think
it's clearer. The primary use of * is still to defeat the signature,
and @$foo doesn't do that.
Okay, good. So this is correct:
my $baz = @foo;
@bar = map { ... } @$baz;
(to be equivalent of mapping over @foo)?
Is @{$foo} going away? More specifically, how do I write that map if
$baz is some more complex expression, and I don't want to use * (say I
want to adhere if map decides to change its signature to take a real
array)?
Luke
Re: Dereferencing Syntax (Was: Outer product considered useful)
Larry Wall skribis 2004-03-25 12:33 (-0800): On Thu, Mar 25, 2004 at 11:35:46AM -0800, Brent 'Dax' Royal-Gordon wrote: : Larry Wall wrote: : say @bar.elems; # prints 1 : Csay? Not Cprint? It's just a println spelled Huffmanly. What happened to the principle that things that work similarly should look similarly? I dislike having another method/function/whatever to do exactly the same thing, yet a little different. That is PHP's niche. Can't we instead just have a pseudo-filehandle or perhaps a tied one and just use Cprint to print? ln.print @bar.elems; print ln : @bar.elems; Though I'm not sure why a feature like this would be needed at all, so I think this is something users should define something like this themselves if they want it: my say = print.assuming :ors \n; (Wildly guessing syntax here. I cincerely hope parens won't be needed.) I think I prefer things the way they happen to already be. print @bar.elems, \n; Also, I think Csay is a bad choice. Many people use a function called Csay for chat bots and text-to-speech. It will of course be possible to override the builtin, but for a good reason most people choose to not do that. Has this Csay already been decided? Juerd
Re: Dereferencing Syntax (Was: Outer product considered useful)
Juerd writes:
Larry Wall skribis 2004-03-25 12:33 (-0800):
On Thu, Mar 25, 2004 at 11:35:46AM -0800, Brent 'Dax' Royal-Gordon wrote:
: Larry Wall wrote:
: say @bar.elems;# prints 1
: Csay? Not Cprint?
It's just a println spelled Huffmanly.
Can't we instead just have a pseudo-filehandle or perhaps a tied one and
just use Cprint to print?
ln.print @bar.elems;
print ln : @bar.elems;
Though I'm not sure why a feature like this would be needed at all, so I
think this is something users should define something like this
themselves if they want it:
my say = print.assuming :ors \n;
(Wildly guessing syntax here. I cincerely hope parens won't be needed.)
Well I'm sincerely certain that they are.
my say := print.assuming(:ors(\n));
I think I prefer things the way they happen to already be.
print @bar.elems, \n;
Ugh. You do!? I think that's the biggest PITA in Perl. I never
thought of say, but I've been known to write:
sub p { print @_, \n }
In some of my more verbose scripts.
It's a sign that something's wrong when on every one-liner I write, and
in even some longer scripts, I specify -l on the command line. Csay
is indeed shorter than Cprint, and I like that, because I use it more
often.
Will there also be:
sub complain([EMAIL PROTECTED]) {
print $ERR: @_, \n;
}
:-)
Also, I think Csay is a bad choice. Many people use a function called
Csay for chat bots and text-to-speech.
Uh huh, but the ones I have experience with use it as a method, so it
doesn't interfere.
$bot.say(Welcome, $user)
Plus, a lot of people use Cindex to create an index, Clength to find
the length of an array, Cdelete to delete files, Cstudy to do their
homework, and Cdie to commit suicide (or was that Cgoto?). That's
why variables have sigils, and lexicals have scopes...
You even said yourself:
my say := ...
That works even if Csay is built-in.
It will of course be possible to override the builtin, but for a good
reason most people choose to not do that.
Has this Csay already been decided?
Doesn't matter, because most of these decisions are up for discussion.
I think everything that was decided when Apocalypse 3 was written has
changed at least three times (contrast with Synposis 3 :-).
Luke
Re: Dereferencing Syntax (Was: Outer product considered useful)
On Fri, Mar 26, 2004 at 09:41:23AM -0700, Luke Palmer wrote:
: Okay, good. So this is correct:
:
: my $baz = @foo;
: @bar = map { ... } @$baz;
:
: (to be equivalent of mapping over @foo)?
Yes, that's correct.
: Is @{$foo} going away? More specifically, how do I write that map if
: $baz is some more complex expression, and I don't want to use * (say I
: want to adhere if map decides to change its signature to take a real
: array)?
@{EXPR} still works.
Larry
Re: Dereferencing Syntax (Was: Outer product considered useful)
Larry Wall writes:
On Fri, Mar 26, 2004 at 09:41:23AM -0700, Luke Palmer wrote:
: Is @{$foo} going away? More specifically, how do I write that map if
: $baz is some more complex expression, and I don't want to use * (say I
: want to adhere if map decides to change its signature to take a real
: array)?
@{EXPR} still works.
Okay, now that that's all cleared up, time to propose something.
When writing Perl 5, I always find myself writing @{ more often than @$.
Maybe it's just a bad habit that I don't tend to use a lot of
intermediate variables.
I propose that the precedence of the of the dereferencing sigils be
loosened so I don't have to write those pesky squigglies all the time.
What used to be:
for my $i (@{$foo-{bar}[$ind]}) { }
Can now be:
for @$foo{bar}[$ind] - $i {...}
It doesn't feel quite right, but that's probably because I've written it
the other way so much.
The only reason to keep it around is if you wanted to use the archaic:
@$foo[2];
Or if you wanted to call methods on the array:
@$foo.sort;
But since you can call methods on a reference and get them delegated
anyway, that's not a problem. And as for the first one, well, who needs
that when they can just leave off the @ altogether?
Luke
Re: Dereferencing Syntax (Was: Outer product considered useful)
On Fri, 2004-03-26 at 15:20, Luke Palmer wrote:
When writing Perl 5, I always find myself writing @{ more often than @$.
Maybe it's just a bad habit that I don't tend to use a lot of
intermediate variables.
Well, one of the big problems with Perl 5's dereferencing is that it's
painful to create intermediate variables that make it any easier. For
example, you can say my $ref = $x{$y}{$z};@$ref or you can say local
*ary=$x{$y}{$z};@ary but the latter isn't that obvious to most, and can
run afoul of strict. In Perl 6:
my @ary := %x{$y}{$z};
should make it much more likely that we'll all use those intermediates.
I also seem to recall something about a .@ operator that would work
like so:
for %x{$y}{$z}.@ - $i {...}
No? If everything else is chained on the right for dereferencing, I
certainly see the utility in this. Am I imagining that it was stated
earlier?
What's more that could be:
for *%x{$y}{$z} - $i {...}
and I can't imagine it makes any sense to bind that * anywhere but:
for *(%x{$y}{$z}) - $i {...}
I like the division between @ and *, since the two meanings had somewhat
too much overlap in most code.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: parrot crash...
Will Coleda [EMAIL PROTECTED] wrote: I'm still seeing both bugs, with a cvs update, make realclean; perl Configure.pl, make. (if I do a cvs diff in my repo, the only changed files are tcl related.) What other intel do you need to help duplicate the bugs? Try with -G to turn off DOD/GC. Run it in the debugger ... leo
Re: [perl #27969] [BUG] ParrotIO crash
Will Coleda [EMAIL PROTECTED] wrote: This rather dodgy bit of code .sub main $S0 = read $P1, 1 end .end Causes a crash, instead of raising an exception. as probably any other IO opcode. Proper error handling for IO is much work and a lot of fun. Patches welcome. leo
Re: Dependency cleanup in generated makefile
Dan Sugalski wrote: I've fixed up the dependency problem in the makefile generation that was getting in the way of multithreaded makes. Shouldn't cause any problems, but it never hurts to double-check these things elsewhere. Was that were make -jN was failing. I tried to get this running for ages and got absolutely nowhere with it, it was like walking in a minefield. Harry -- Regards, Harry Jackson.
Re: [perl #27969] [BUG] ParrotIO crash
Leopold Toetsch [EMAIL PROTECTED] writes: Causes a crash, instead of raising an exception. as probably any other IO opcode. Proper error handling for IO is much work and a lot of fun. Patches welcome. These were things I wanted to do quite a while ago, but then I got a new job, moved too a new town, had no connection to the internet. At the moment I work through a huge backlog of mails and try to get familar with the recent changes of the code. So don't hold your breath. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: parrot crash...
Ah, good call. Adding -G causes the code to complete with no crash. (This also clears the two hurdles in the test suite I mentioned elsewhere.) (debugger) - I'm not sure I can get anything more helpful out of the debugger than the crash log (with stack trace) from an earlier post - Here's the backtrace, though (when run without -G) (gdb) backtrace #0 0x0002d310 in pobject_lives (interpreter=0x923400, obj=0x) at src/dod.c:179 #1 0x001067ec in mark_pmc_register_stack (interpreter=0x923400, chunk=0x9afb80) at src/register.c:129 #2 0x0010f294 in mark_context (interpreter=0x923400, ctx=0x947350) at src/sub.c:102 #3 0x001a8c6c in Parrot_Continuation_mark (interpreter=0x923400, pmc=0x984588) at continuation.c:53 #4 0x0002e38c in mark_special (interpreter=0x923400, obj=0x984588) at src/dod.c:114 #5 0x0002d358 in pobject_lives (interpreter=0x923400, obj=0x984588) at src/dod.c:199 #6 0x0002de74 in trace_mem_block (interpreter=0x923400, lo_var_ptr=3221223824, hi_var_ptr=3221221840) at src/dod.c:889 #7 0x001946f4 in trace_system_stack (interpreter=0x923400) at src/cpu_dep.c:117 #8 0x001946ac in trace_system_areas (interpreter=0x923400) at src/cpu_dep.c:98 #9 0x0002d578 in trace_active_PMCs (interpreter=0x923400, trace_stack=1) at src/dod.c:297 #10 0x0002e04c in Parrot_do_dod_run (interpreter=0x923400, flags=1) at src/dod.c:1028 #11 0x0010aef0 in more_traceable_objects (interpreter=0x923400, pool=0x923dc0) at src/smallobject.c:110 #12 0x0010b028 in get_free_object (interpreter=0x923400, pool=0x923dc0) at src/smallobject.c:176 #13 0xef0c in get_free_pmc (interpreter=0x923400, pool=0x923dc0) at src/headers.c:53 #14 0x00029ca0 in get_new_pmc_header (interpreter=0x923400, base_type=46, constant=0) at src/pmc.c:104 #15 0x00029fd0 in pmc_new_noinit (interpreter=0x923400, base_type=46) at src/pmc.c:208 #16 0x0003af64 in Parrot_newsub_p_ic_ic (cur_opcode=0x9c61b8, interpreter=0x923400) at ops/core.ops:508 #17 0x00111ddc in runops_slow_core (interpreter=0x923400, pc=0x9c61b8) at src/runops_cores.c:146 #18 0xaa10 in runops_int (interpreter=0x923400, offset=689) at src/interpreter.c:833 #19 0xaad8 in runops_ex (interpreter=0x923400, offset=689) at src/interpreter.c:863 #20 0xad04 in runops (interpreter=0x923400, offset=689) at src/interpreter.c:935 #21 0xea20 in Parrot_runcode (interpreter=0x923400, argc=2, argv=0xbcd8) at src/embed.c:692 #22 0x378c in main (argc=2, argv=0xbcd8) at imcc/main.c:556 #23 0x1d60 in _start (argc=3, argv=0xbcd4, envp=0xbce4) at /SourceCache/Csu/Csu-45/crt.c:267 #24 0x1be0 in start () On Friday, March 26, 2004, at 03:39 AM, Leopold Toetsch wrote: Will Coleda [EMAIL PROTECTED] wrote: I'm still seeing both bugs, with a cvs update, make realclean; perl Configure.pl, make. (if I do a cvs diff in my repo, the only changed files are tcl related.) What other intel do you need to help duplicate the bugs? Try with -G to turn off DOD/GC. Run it in the debugger ... leo -- Will Coke Coledawill at coleda dot com
Re: Safety and security
Larry Wall wrote: Do bear in mind that Perl can execute bits of code as it's compiling, so if a bit of code is untrustworthy, you shouldn't be compiling it in the first place, unless you've prescanned it to reject Cuse, CBEGIN, and other macro definitions, or (more usefully) have hooks in the compiler to catch and validate those bits of code before running them. In other words, the compiler must be sure to run immediate bits of code with the same restrictions as it would run the real code. This isn't a parrot issue per say; it's a compiler issue, and I don't see how it requires additional mechinisims for parrot, unless possibly it's running one pbc (the compiler itself) with one set of restrictions/quotas, and another bytecode segment (pbc generated during the compile) with another set. I think we were planning on that anyway (to allow libraries to be more trusted then the code that calls them, and callbacks to be less trusted). -=- James Mastros
Re: [perl #27962] [PATCH] bad error message for split.
At 11:01 PM -0500 3/25/04, Will Coleda wrote: Would a patch be accepted that let split work on non empty strings (not treated as REs) as a stopgap until RE support? Yep. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Safety and security
At 2:57 PM +0100 3/26/04, James Mastros wrote: Larry Wall wrote: Do bear in mind that Perl can execute bits of code as it's compiling, so if a bit of code is untrustworthy, you shouldn't be compiling it in the first place, unless you've prescanned it to reject Cuse, CBEGIN, and other macro definitions, or (more usefully) have hooks in the compiler to catch and validate those bits of code before running them. In other words, the compiler must be sure to run immediate bits of code with the same restrictions as it would run the real code. This isn't a parrot issue per say; it's a compiler issue, and I don't see how it requires additional mechinisims for parrot, unless possibly it's running one pbc (the compiler itself) with one set of restrictions/quotas, and another bytecode segment (pbc generated during the compile) with another set. I think we were planning on that anyway (to allow libraries to be more trusted then the code that calls them, and callbacks to be less trusted). Yup. Subroutines and methods are privilege boundaries, and code with extra rights may call into less privileged code safely. We need to work out the mechanism though. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Dependency cleanup in generated makefile
At 10:12 AM + 3/26/04, Harry Jackson wrote: Dan Sugalski wrote: I've fixed up the dependency problem in the makefile generation that was getting in the way of multithreaded makes. Shouldn't cause any problems, but it never hurts to double-check these things elsewhere. Was that were make -jN was failing. I tried to get this running for ages and got absolutely nowhere with it, it was like walking in a minefield. Yep. That now works for me, though it exposes some issues in the classes/ makefile. It's safe, for now, but make executes it N times for some odd reason. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Safety and security
On Fri, Mar 26, 2004 at 09:26:45AM -0500, Dan Sugalski wrote: : Yup. Subroutines and methods are privilege boundaries, and code with : extra rights may call into less privileged code safely. We need to : work out the mechanism though. One thing you'll have to do in that case is disable the ability to peek outward into your dynamic scope for various tidbits, such as $CALLER::_. Larry
Re: [perl #27962] [PATCH] bad error message for split.
On Fri, Mar 26, 2004 at 09:23:25AM -0500, Dan Sugalski wrote: : At 11:01 PM -0500 3/25/04, Will Coleda wrote: : Would a patch be accepted that let split work on non empty strings : (not treated as REs) as a stopgap until RE support? : : Yep. Especially since we'll be revising P6 split to do that as part of its functionality anyway. We're gonna try really hard not to confuse regexes and strings in P6... Larry
threads.t on NetBSD
I have built Parrot on NetBSD with GNU Portable Threads. All (except SKIP) threads.t tests is successful, BUT interp identity and thread - kill. Test interp identity sleep perpetual after printing ok1 and ok2. Test thread - kill running perpetual using 100% CPU. Than I can help? Nick.
Re: Optimizations for Objects
Dan Sugalski [EMAIL PROTECTED] wrote: At 6:46 PM +0100 3/17/04, Leopold Toetsch wrote: Or: after the 1st delegate lookup create a JITed stub Which is swell, except for that pesky can't-guarantee-a-JIT thing... :) I've running that now for the C__init call. In the absence of C__init the vtable function is replaced by Cret. When C__init is present a JITed function stub gets called that calls the PASM w/o method lookup. Speedup for missing C__init is 100%[1], with C__init around 10% [2] It doesn't work for superclasses' C__init yet though. Is it more swell or pesky? [1] new Px, Iclass in a loop [2] oo2.pasm bench leo
Re: CPAN Upload: A/AB/ABERGMAN/ponie-2.tar.gz - Ponie Development Release 2
Steve Hay [EMAIL PROTECTED] wrote: HANDLE __stdcall WSAAsyncGetServByName(HWND hWnd, u_int wMsg, const char * name, const char * proto, char * buf, int obj.u._b._buflen); In fact, just running this: #include parrot/parrot.h #undef buflen #include EXTERN.h #include config.h #undef HAS_OFF64_T #include perl.h before including perl.h should do it for now. It looks like the buflen expansion comes from this in parrot/include/parrot/pobj.h: /* BEGIN DEPRECATED BUFFER ACCESSORS */ Yep. It could do with being more than just deprecated ;) Work in progress ;) leo
Re: Optimizations for Objects
At 4:34 PM +0100 3/26/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: At 6:46 PM +0100 3/17/04, Leopold Toetsch wrote: Or: after the 1st delegate lookup create a JITed stub Which is swell, except for that pesky can't-guarantee-a-JIT thing... :) I've running that now for the C__init call. In the absence of C__init the vtable function is replaced by Cret. When C__init is present a JITed function stub gets called that calls the PASM w/o method lookup. Speedup for missing C__init is 100%[1], with C__init around 10% [2] It doesn't work for superclasses' C__init yet though. Is it more swell or pesky? Depends on whether it requires the JIT or not. :) FWIW, I figure the way to do this fast is to have two extra slots in the class object, one for constructors and one for destructors. The class can fill 'em in at construct time, and the object constructor/destructor stuff can just walk through the list. Saves us the hassle of doing all the lookups at runtime. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: threads.t on NetBSD
Nick Kostirya [EMAIL PROTECTED] wrote: I have built Parrot on NetBSD with GNU Portable Threads. All (except SKIP) threads.t tests is successful, BUT interp identity and thread - kill. Test interp identity sleep perpetual after printing ok1 and ok2. Strange. Actually no PASM thread is started here. Could you attach a debugger and look, where it hangs? Test thread - kill running perpetual using 100% CPU. That's clear. The thread is spinning in this loop: lp: noop branch lp As pth(3) doesn't preempt threads, it runs forever. Please try this: lp: sleep 0.1 branch lp Nick. leo
Re: CPAN Upload: A/AB/ABERGMAN/ponie-2.tar.gz - Ponie Development Release 2
Leopold Toetsch wrote: Steve Hay [EMAIL PROTECTED] wrote: HANDLE __stdcall WSAAsyncGetServByName(HWND hWnd, u_int wMsg, const char * name, const char * proto, char * buf, int obj.u._b._buflen); In fact, just running this: #include parrot/parrot.h #undef buflen #include EXTERN.h #include config.h #undef HAS_OFF64_T #include perl.h before including perl.h should do it for now. Thanks - that works a treat. The parrot build nearly worked OK now, but unfortunately it fell at the last hurdle: link -out:parrot.exe -nologo -nodefaultlib -debug -machine:x86 -debug imcc\main.obj blib/lib/libparrot_s.lib oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib libparrot_s.lib(perl5xpvhv.obj) : error LNK2001: unresolved external symbol __imp__win32_malloc libparrot_s.lib(perl5lv.obj) : error LNK2001: unresolved external symbol __imp__win32_malloc libparrot_s.lib(perl5av.obj) : error LNK2001: unresolved external symbol __imp__win32_malloc libparrot_s.lib(perl5xpvhv.obj) : error LNK2001: unresolved external symbol __imp__win32_abort libparrot_s.lib(perl5lv.obj) : error LNK2001: unresolved external symbol __imp__win32_abort libparrot_s.lib(perl5av.obj) : error LNK2001: unresolved external symbol __imp__win32_abort libparrot_s.lib(perl5xpvhv.obj) : error LNK2001: unresolved external symbol __imp__win32_printf libparrot_s.lib(perl5av.obj) : error LNK2001: unresolved external symbol __imp__win32_printf parrot.exe : fatal error LNK1120: 3 unresolved externals NMAKE : fatal error U1077: 'link' : return code '0x460' Stop. I've seen this sort of name munging problem on Win32 before, but I can't quite figure out what's wrong here. I think it's usually something to do with object files or libraries that were compiled using different MS C run-time libraries being linked together, but as far as I can see everything was compiled with the same options. Those options include -MD, which is correct for linking against msvcrt.lib. Any ideas what's wrong? Any Win32 gurus out there? - Steve Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Windows tinder builds
I finally figured out why the windows machine wasn't showing in the tinderbox, and fixed that. (System dates. D'oh!) We now have (again) a reliable windows machine building parrot for test, both under Cygwin and Visual Studio/.NET (though it builds a native executable there rather than a .NET one) The VS/.NET build works fine, though three of the tests fail for odd reasons. Those look like potential test harness errors. The cygwin build sorta kinda works OK, but the link fails because of a missing _inet_pton. I seem to remember this cropping up in the past and I thought we'd gotten it fixed, but apparently not. Anyway, these are set for hourly builds at half-hour offsets, so if you check in any significant changes it'd be advisable to take a look at the results. For those that don't know, all the tinderbox info is web-accessable at http://tinderbox.perl.org/tinderbox/bdshowbuild.cgi?tree=parrot -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Windows tinder builds
Dan Sugalski [EMAIL PROTECTED] wrote: The cygwin build sorta kinda works OK, but the link fails because of a missing _inet_pton. I seem to remember this cropping up in the past and I thought we'd gotten it fixed, but apparently not. Kind of fixed: $ perl Configure.pl --help ... --define=inet_aton Quick hack to use inet_aton instead of inet_pton leo
Re: Windows tinder builds
At 7:26 PM +0100 3/26/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: The cygwin build sorta kinda works OK, but the link fails because of a missing _inet_pton. I seem to remember this cropping up in the past and I thought we'd gotten it fixed, but apparently not. Kind of fixed: $ perl Configure.pl --help ... --define=inet_aton Quick hack to use inet_aton instead of inet_pton Sounds like a job for a hints file. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Windows tinder builds
Dan Sugalski wrote: At 7:26 PM +0100 3/26/04, Leopold Toetsch wrote: --define=inet_aton Quick hack to use inet_aton instead of inet_pton Sounds like a job for a hints file. :) Done. (Done hackishly, but done.) -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
[CVS ci] pmc-accessors-3
I finally applied the long missing bits of a patch by Gordon Henriksen - thanks again. So the macros Cbufstart and Cbuflen are already history. PObj_bufstart(b) and PObj_buflen(b) is now the way to go. leo
Languages testing
Another job for the intrepid configure and/or makefile hacker. Right now, there's a languages-test target in the top level makefile. This is good. Unfortunately, the way it works is... sub-good. What it does is do a make test in the languages directory, and that target runs each language test in turn. Not bad in itself, but it has two problems: 1) tinderbox clients pick up the language test as OK, even when its not. (cf the sprite/languages tinder build) 2) The language tests stop on the first language that dies hard, which at the moment is perl 6 So, what I'd like is for someone to figure a way to get all the languages test harnesses together under a single master harness, so all the languages will have their tests run all the time, and so tinderbox is happy with the results. (Get the first part done and I'll work out the tinder part--that's doable) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: parrot crash...
Will Coleda [EMAIL PROTECTED] wrote:
#3 0x001a8c6c in Parrot_Continuation_mark (interpreter=0x923400,
pmc=0x984588) at continuation.c:53
Seems to be dead context.
Does this help?
--- parrot/classes/continuation.pmc Mon Mar 22 13:38:09 2004
+++ parrot-leo/classes/continuation.pmc Fri Mar 26 21:04:51 2004
@@ -52,8 +52,10 @@
*/
void mark () {
+#if 0
struct Parrot_Sub * cc = (struct Parrot_Sub*)PMC_sub(SELF);
mark_context(INTERP, cc-ctx);
+#endif
}
/*
--- parrot/classes/coroutine.pmcWed Mar 24 18:02:16 2004
+++ parrot-leo/classes/coroutine.pmcFri Mar 26 21:08:45 2004
@@ -74,7 +74,7 @@
struct Parrot_Coroutine *c = (struct Parrot_Coroutine *)PMC_sub(SELF);
mark_stack(INTERP, c-co_control_stack);
/* mark_stack(INTERP, c-co_pad_stack); */
-SUPER();/* mark rest */
+mark_context(INTERP, c-ctx);
}
}
Re: Windows tinder builds
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote:
Done. (Done hackishly, but done.)
A bit too hackish IMHO. The Configure --define switch can take multiple
arguments, separated by commas.
A hint equivalent could be:
Configure::Data-set {
D_inet_aton = 1
D_xxx = 1
};
both should finally expand to the same PARROT_DEF_XXX define.
leo
Re: Windows tinder builds
At 9:19 PM +0100 3/26/04, Leopold Toetsch wrote:
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote:
Done. (Done hackishly, but done.)
A bit too hackish IMHO. The Configure --define switch can take multiple
arguments, separated by commas.
A hint equivalent could be:
Configure::Data-set {
D_inet_aton = 1
D_xxx = 1
};
both should finally expand to the same PARROT_DEF_XXX define.
If that works better, great. The hack fix apparently didn't, at least
according to the tinder builds.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Behaviour of PMCs on assignment
This has come up before and the discussion always semi-warnocks, but it's time to bring it up again. All the vtable operations that do PMC things are three-arg versions--they get both the args and the destination PMCs passed in. This is done specifically for speed reasons, as the assumption is that, for example, the add vtable method for a PMC represents the expression: a = b + c turns to add a, b, c in which case b's add function does the math and hand the result to a via it's set vtable function, which is fine. A has the option of overriding the assignment if that's necessary, for example if its tied to a backing store of some sort. Fine. The addition may create a temporary PMC, but there's really no way around that if we're to maintain the proper API. This becomes a bit less efficient when we're looking at intermediate values of expressions. Something like: a = b + c + d turns to new $P0, SomeIntermediateType add $P0, b, c add a, $P0, d and we need to create that $P0 temp beforehand. While that's fine, it leave things to the compiler to figure out what the intermediate type should be, and often ends up creating two temps instead of one. Moreover, it's distinctly possible that the temp that's created isn't the right type, as the compiler may not know what the intermediate expression will return. I see three options: 1) Have a version of the binary vtable methods that create the destination PMC 2) Make a universal assignment PMC that takes on the characteristics of the RHS of the assignment 3) Have a this PMC intentionally left blank flag to mark blank PMCs and have vtable methods check that first #1 doubles the number of vtable entries. Ick. #2 has the most overhead #3 leaves it to the vtable methods to check, which is error prone. (Though if the #2 and #3 schemes were implemented with the same PMC there'd be a good fallback) Discussion time, folks. Pointing out things I've missed wouldn't be out of line either... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Behaviour of PMCs on assignment
Dan Sugalski wrote:
This becomes a bit less efficient when we're looking at intermediate
values of expressions. Something like:
a = b + c + d
turns to
new $P0, SomeIntermediateType
add $P0, b, c
add a, $P0, d
Well...how about this:
1. Have all vtable methods which take a dest return a PMC *.
2. If dest is NULL, it's filled with the appropriate type before
anything else is done.
3. At the end of the method, there's a return dest;.
Thus, an op like add should be written like:
op add(inout PMC, in PMC, in PMC) {
$1=VTABLE_add(interpreter, $2, $3, $1); /* or whatever */
}
This does mean checking if dest == NULL at the beginning of each vtable
function, but other than that, it's fairly clean. It might even be
possible for pmc2c to insert this code automagically. (I believe PMC
registers are initialized to NULL, so it should Just Work most of the
time, and there's always the null_p op when you need to do it explicitly.)
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: Windows tinder builds
Dan Sugalski wrote: If that works better, great. The hack fix apparently didn't, at least according to the tinder builds. Had a massive think-o about the meaning of --define. The version now in CVS should work. (Tested it on my own box--had to add make, gcc, and perl to Cygwin, but it builds nicely. (I was previously just using Cygwin to get at its X server. (This message is starting to look like Lisp.))) -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: Nesting Test::Harness
On Fri, Mar 19, 2004 at 03:53:05PM +, [EMAIL PROTECTED] wrote: Is there a way to nest usage of Test::Harness? I have an application with a number of custom modules. I want to structure my test suite this way: myapp.t module_a.t module_b.t module_a.t foo.t bar.t module_a.t baz.t quux.t That is, I want the top-level test suite to call the module test suites, and the module suites to call their own test sets (often one *.t for each sub in the module). I want to do this because: 1) I want to be able to run either the full suite or just one module's tests. 2) I don't want to have to make changes in two places when I add a new subtest. 3) I want to tweak the flags to Devel::Cover for each module so that it only collects data for the module I'm actively testing and doesn't get incidental coverage for things it depends on. Test::Harness just runs the tests you give it. Simplest thing to do is to just write a little script that has the necessary logic to determine what set of tests to run and feed that file list to runtests(). -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ It's Paint Chip Eating time!
Re: New functions in the core (Was Re: Dereferencing Syntax)
[EMAIL PROTECTED] (Joe Gottman) writes: This function would be very useful in inner loops, so if it is possible to implement it more efficiently in the core than as a sub in a module I think we should do so. And, if it's possible to implement it more efficiently in the core than as a sub in a module that Parrot didn't live up to one of its design principles. -- yrlnry I think the real problem here is that he is a university CS professor and therefore knows very little about programming in the real world, in any languge.
Re: Behaviour of PMCs on assignment
Dan Sugalski [EMAIL PROTECTED] wrote: This becomes a bit less efficient when we're looking at intermediate values of expressions. Something like: a = b + c + d turns to new $P0, SomeIntermediateType add $P0, b, c add a, $P0, d and we need to create that $P0 temp beforehand. While that's fine, it leave things to the compiler to figure out what the intermediate type should be, and often ends up creating two temps instead of one. Well, yes. It's up to the compiler. Perl6 would insert $P1 = new PerlUndef and Pie-Thon would have a Cnew PieScalar or such. Why should it create two temps? Moreover, it's distinctly possible that the temp that's created isn't the right type, as the compiler may not know what the intermediate expression will return. The Cnew Undef something has to morph itself into an appropriate type IMHO. I see three options: I think its really up to the HLL compiler to generate a suitable LHS PMC that (accompanied by appropriate assign vtables) does the right thing. To you have examples, which indicate that this isn't possible? leo
Re: Behaviour of PMCs on assignment
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote: Dan Sugalski wrote: This becomes a bit less efficient when we're looking at intermediate values of expressions. Something like: a = b + c + d turns to new $P0, SomeIntermediateType add $P0, b, c add a, $P0, d Well...how about this: 1. Have all vtable methods which take a dest return a PMC *. 2. If dest is NULL, it's filled with the appropriate type before anything else is done. *Strong NAK* :) The register allocator has to track the life span of each variable and temp. If the life of a register ends at one point, this register is reused: # a = b + c + d $P0 = $P1 + $P2 # (1] $P3 = new PerlUndef # (2) $P3 = $P0 + $P4 Let's assume that C$P1 or C$P2 are also temps and not reused beyond instruction (1). With that in mind $P3 is assigned to the same Parrot register as one of this temps. With the Parrot Calling Conventions we did effectively cut down the assignable register range to P16..P31 (using registers in the low range is possible but not easy). So back to your proposal: Above example could look like: $P0 = $P1 + $P2 $P3 = $P0 + $P4 Now the register allocator does of course not know, *if* the C$P3 is CPMCNULL at runtime. It has to assume that it isn't. No register can be reused, the register allocator would run short of registers after very few instructions. (I believe PMC registers are initialized to NULL, That's a wrong assumption too. They are intially PMCNULL in @MAIN. But when you call a subroutine, the registers are just that, what they used to be in the caller. It could work, if the sequence is: $P0 = $P1 + $P2 null $P3 $P3 = $P0 + $P4 The Cnull (out PMC) opcode cuts the life range of C$P3 because of its Cout specifier. But now we have the runtime overhead in each such vtable method (test for PMCNULL) and one additional function argument to pass. leo
Re: MMD vtable functions in bytecode
Dan Sugalski [EMAIL PROTECTED] wrote: So, I'm doing these, because I need 'em, and we might as well get the things in now. For the record, these things will be called as functions (not methods), with three parameters, so the signature looks like: A short question WRT implementation: shouldn't all MMD functions just use one function slot? You now seem to duplicate the whole table. When a C function is inserted, it could be a CSub[1] PMC. When a bytecode function is registered it overrides the existing (or default) slot and gets called instead. Both functions could be called by Cinvoke. The invoke vtable of the function does the right thing. One further question: the Cmmddispatch opcode is supposed to explicitely run the function, isn't it? Is it needed? Why not just do: $P0 = $P1 + $P2 # call MMD func if registerd [1] The current CSub PMC looks totally bogus and seems to be unused. S. classes/nci.pmc::invoke. The CSub should have the same invoke call. leo
OpsFile hints - one more (perlish) task
Opcodes normally have a specifier that indicates, if a register is
written to or only used, e.g.
null (out PMC)
An Cout register gets a new value at that point, the register
allocator can reuse this register because the old contents got
discarded. This information is necessary for the register allocator.
Now we have some opcodes, that implicitely set new values on a range of
registers or silently use a register (it has to exist).
clearp # set P0..P31 to PMCNULL
poptopi # set I16..I31 from I register stack
callmethod # use existing P0, P2, S0
callmethodcc # use existing P0, P2, S0, create new P1
There are currently some hacks inside imcc[1], to handle some of these
opcodes but opcodes change faster then the code, so I'd rather have this
autogenerated from e.g.:
op clearp () :base_core,out=P0-P31
op callmethodcc :object_base,in=P0,P2,S0,I0-I4,out=P1,I0-I4
I'm not sure yet, if register stack store operations do need a hint:
pushbottomp# doesn't care if a register is valid or not
OTOH the equivalent pop definitely sets all P0..P15.
So that's part one - annotate the opsfiles.
2) is parse this information and generate bitmasks for the Cop_info_t
structure defined in Finclude/parrot/op.h.
That would be something like:
int {in,out}_{I,S,P,N}_argdir; # 1 bit per register per in/out
per kind
Thanks,
leo
[1] s. imcc/instructions.c: 87 ff
