[perl #35048] [PATCH] Building pge.dll with MinGW
# New Ticket Created by Francois PERRAD # Please include the string: [perl #35048] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=35048 > Small patch for building and coping pge.dll with MinGW. Francois Perrad. pge_mingw.patch Description: Binary data
[perl #35049] [PATCH] MANIFEST.generated
# New Ticket Created by FranÃois PERRAD # Please include the string: [perl #35049] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=35049 > Add parrot utils (pdump, pdb, pbc_info, disassemble) Remove obsolete files. Francois Perrad. MANIFEST.generated.patch Description: Binary data
Re: Perl 6 Summary for 2005-04-12 through 2005-04-19
On Tue, 19 Apr 2005, Matt Fowles wrote:
Python on Parrot
^^
Kevin Tew wondered what the state of pyrate was. Sam Ruby provided a
general explanation.
(I'm not on all of the lists, so this may have come out before and I just
ignore it, but...) this is a pun, isn't it?!?
Michele
--
sub printpages
{
return;
}
This sub is the best code you have written so far.
- A. Sinan Unur in clpmisc, "Re: Free source guestbook - unfinished"
Re: More registers
Gregor N. Purdy <[EMAIL PROTECTED]> wrote: > Leo -- > I had posted a program a while ago that generates large > fake programs for testing such things. Did that not help? I've that program or a successor of it still around somewhere. But unfortunately it doesn't help. The register usage pattern of the simulation is totally different: it creates too much long ranged globals and too much interferences between registers compared to RL programs like Dan's Big Subs. Such a simulation should create much more lines (selectable) almost only temporary register access inside basic blocks and some access to long-ranged globals within reasonable (tweakable) limits i.e. from around 16 to e.g. 64. leo
Re: State of the Tcl [r7890]
William Coleda <[EMAIL PROTECTED]> wrote: > Still some GC bugs kicking around that neither Leo nor I have been > able to find yet. (Note that the bug in [string] may actually be a PGE > leak, as that code uses the glob rules). Well there are GC and other bugs, probably. I get really strange results when running the tcl tests: $ make test Failed Test Stat Wstat Total Fail Failed List of Failed --- t/cmd_continue.t1 256 21 50.00% 2 *but* I see much more failing: some of cmd_concat, cmd_insert, cmd_proc, and cmd_string, which aren't shown in the summary. Turning off DOD/GC gives this result: $ TEST_PROG_ARGS=-G make test All tests successful. Files=36, Tests=228, 43 wallclock secs (35.93 cusr + 6.15 csys = 42.08 CPU) again with above failing tests unnoticed. Running with -G didn't flush output w/o newlines properly, which is fixed now. Some more remarks: lib/tclword.imc: .local pmc me me = interpinfo 16 #INTERPINFO_CURRENT_OBJECT setattribute me, "TclWord\x00chunks", emptyArray this is extremly prone to errors. We don't guarantee that the constant 16 stays the current object. Just use C here, which does the same: setattribute self, "TclWord\x00chunks", emptyArray tcl.imc: $P2 = parser."parse"(input_line_PMC,zero,zero) (retcode,retval) = interpret($P1) $P1 / $P2 seems to be a typo, which happens to work as it's likely that the register allocator will use the same register. leo
[perl #35052] [MSWin32] PGE doesn't link
# New Ticket Created by Ron Blaschke # Please include the string: [perl #35052] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=35052 > C:\parrot\compilers\pge>nmake Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. link -dll -def:libparrot.def -nologo -nodefaultlib -o pge.dll pge_parse.obj pge_gen.obj pge_opt.obj pge_parsep5.obj pge_parseglob.obj LINK : warning LNK4044: unrecognized option '/o'; ignored LINK : fatal error LNK1181: cannot open input file 'pge.dll' NMAKE : fatal error U1077: 'link' : return code '0x49d' Stop.
Re: [svn:parrot] rev 7886 - in trunk: . config/gen/makefiles dynclasses languages/tcl/lib/commands languages/tcl/lib/macros
Ah. That would explain why I had to back in and delete the file that I had already deleted - because I deleted the wrong file! Fixed. Leopold Toetsch wrote: [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: --- trunk/MANIFEST (original) +++ trunk/MANIFEST Tue Apr 19 16:51:10 2005 @@ -50,7 +50,6 @@ -classes/boolean.pmc [] I don't understand this change to MANIFEST. classes/boolean.pmc is for sure used, but $ perl tools/dev/manicheck.pl doesn't complain at all. leo
Re: New language: Parrot Common Lisp
Cory Spencer <[EMAIL PROTECTED]> wrote: >* There are some outstanding issues with the Dead Object > Detection/Garbage collection systems that I've yet to track down. I've fixed a bug that happened in combination with Hash iterators. Exactly the symptoms that I saw, when running: (print (+ 2 3)) i.e. vanishing strings from global namespace hashes. leo
Re: [svn:parrot] rev 7886 - in trunk: . config/gen/makefiles dynclasses languages/tcl/lib/commands languages/tcl/lib/macros
William Coleda <[EMAIL PROTECTED]> wrote: > Ah. That would explain why I had to back in and delete the file that I > had already deleted - because I deleted the wrong file! Ok. But: > Leopold Toetsch wrote: >> $ perl tools/dev/manicheck.pl >> >> doesn't complain at all. leo
Re: State of the Tcl [r7896]
Leopold Toetsch wrote: William Coleda <[EMAIL PROTECTED]> wrote: Still some GC bugs kicking around that neither Leo nor I have been able to find yet. (Note that the bug in [string] may actually be a PGE leak, as that code uses the glob rules). Well there are GC and other bugs, probably. I get really strange results when running the tcl tests: $ make test Failed Test Stat Wstat Total Fail Failed List of Failed --- t/cmd_continue.t1 256 21 50.00% 2 *but* I see much more failing: some of cmd_concat, cmd_insert, cmd_proc, and cmd_string, which aren't shown in the summary. These are probably the TODO tests - you still get the failure output when they run, but they don't count against the total. Turning off DOD/GC gives this result: $ TEST_PROG_ARGS=-G make test All tests successful. Files=36, Tests=228, 43 wallclock secs (35.93 cusr + 6.15 csys = 42.08 CPU) again with above failing tests unnoticed. Running with -G didn't flush output w/o newlines properly, which is fixed now. Thanks Some more remarks: lib/tclword.imc: .local pmc me me = interpinfo 16 #INTERPINFO_CURRENT_OBJECT setattribute me, "TclWord\x00chunks", emptyArray this is extremly prone to errors. We don't guarantee that the constant 16 stays the current object. Just use C here, which does the same: setattribute self, "TclWord\x00chunks", emptyArray Heh. I had done this before, and, as today, it didn't work. self wasn't recognized as a variable: __init was not declared as a method. Fixed. tcl.imc: $P2 = parser."parse"(input_line_PMC,zero,zero) (retcode,retval) = interpret($P1) $P1 / $P2 seems to be a typo, which happens to work as it's likely that the register allocator will use the same register. Good catch, thank you. That'd've been easier to see if it failed. ^_^ Also, I see you found a bug in my fix to dynclasses/tclstring.pmc - I forgot to actually mark the strings. Sadly, with all these updates, no changes in test status. (Even with your other GC fix for lisp).
Re: How do I... tie hashes/arrays?
On Wed, Apr 20, 2005 at 08:39:02AM +0200, Leopold Toetsch wrote:
: Larry Wall <[EMAIL PROTECTED]> wrote:
: > On Tue, Apr 19, 2005 at 02:02:41PM +, Ingo Blechschmidt wrote:
:
: >: # Possibility #2
: >: multi sub *postcircumfix:<'[', ']'>(TiedArray $self, $index) {
: >: # Body as above
: >: }
:
: > None of those are quite right, because you have to be prepared to deal
: > not only with slices, but with multiple dimensions of slices.
:
: Then again the question arises, if all the possible indexed access isn't
: clearer written as multi subs:
:
: multi sub *postcircumfix:<[ ]>(TiedArray $self, int $index) {...}
: multi sub *postcircumfix:<[ ]>(TiedArray $self, Int $index) {...}
: multi sub *postcircumfix:<[ ]>(TiedArray $self, Slice $index) {...}
: multi sub *postcircumfix:<[ ]>(TiedArray $self, MyDims $index) {...}
:
: or with FETCH and STORE as distinct variants too, and r/w ...
Depends on whether the user is actually expecting equal MMD there,
or tie-breaking between multi methods within the particular class.
My gut-level feeling is that they expect the latter.
: > ... However, that being
: > said, there's enough flexibility in the FETCH/STORE proxy that you
: > could "defactor" the identification code out to the various handlers
: > and get the same benefit.
:
: Well, isn't the "defactorized" code just a bunch of multi subs?
I don't think of it that way. Considering the code is bound to a
particular proxy object before it is ever called, it seems to fall
even more into the category of multi method rather than multi sub.
This is one of the big flying leaps that Perl 6 is trying to take.
We've had lots of MMD implementations in the world, but Perl 6 is
attempting to make that orthogonal to all the other scoping mechanisms,
including lexical scopes and class scopes. If there's prior art,
I'm not aware of it. I suppose the non-brain-burning view of it is
that any extra lexical or class scope dimension just turns into an
extra absolute constraint on which subset of the global subs of that
short name can be called.
Larry
[perl #35053] [PATCH] classes/float.pmc: void function can't return a value
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #35053]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=35053 >
In classes/float.pmc, the MMD_DEFAULT branch of i_subtract tries to
return a value, even though the function is defined as 'void'.
I haven't worked my way through the pmc generation stuff to be certain
this is the right patch, but it will at least compile.
--- parrot-current/classes/float.pmcMon Apr 18 11:22:52 2005
+++ parrot-andy/classes/float.pmc Wed Apr 20 08:58:44 2005
@@ -245,11 +245,11 @@
void i_subtract (PMC* value) {
MMD_Complex: {
Parrot_scalar_i_subtract_Complex(interpreter, SELF, value);
}
MMD_DEFAULT: {
-return SUPER(value); /* XXX inheritance problem */
+SUPER(value); /* XXX inheritance problem */
}
}
/*
--
Andy Dougherty [EMAIL PROTECTED]
[perl #30604] [BUG] Re: cvs commit: parrot/t/pmc complex.t
t\pmc\complexok All tests successful. Files=1, Tests=26, 3 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) Seems to be fixed, should be closed.
Re: [RFC] some doubtable MMDs?
At 2:38 PM +0200 4/15/05, Leopold Toetsch wrote:
I'm not quite sure, but it seems that some of the MMD functions may
better be vtable methods:
- bitwise_sh[rl]*shift by anything other then int?
- bitwise_lsris missing generally
or even just a plain opcode only:
- logical_{or,and,xor} return a PMC depending on the boolean value
What are HLLs expecting of these infix operations?
These were in because I fully expected people would want to override
"<<", ">>" and their ilk. Basically any overridable operation got an
entry in the MMD table.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
[perl #22706] IMCC (& Parrot) crash with -t when invoke is run
Can't reproduce, seems to pass C call. Should be closed. .sub _main # void win32_setup(void) loadlib P1, "kernel32.dll" dlfunc P0, P1, "GetStdHandle", "pi" set I0, 1 set I5, -11 invoke # Will crash here. store_global "kernel32", P1 store_global "Win32handle", P5 end .end C:\parrot>parrot -t targ_test.imc 0 loadlib P1, "kernel32.dll" - P1=RetContinuation=PMC(0x627998 Adr:0x0), 3 dlfunc P0, P1, "GetStdHandle", "pi" - P0=PMCNULL, P1=ParrotLibrary=PMC(0x627980), , 8 set I0, 1- I0=0, 11 set I5, -11 - I5=0, 14 invoke 15 store_global "kernel32", P1 - , P1=ParrotLibrary=PMC(0x627980) 18 store_global "Win32handle", P5 - , P5=UnManagedStruct=PMC(0x6278f0) 21 end
[perl #22174] [PATCH] snprintf link errors on Win32
Seems to have been applied, in one way or the other. F uses C. This ticket should be closed.
Re: [perl #32646] [TODO] Convert Perl* PMCs to dynamic classes.
Per Leo, this is unnecessary, as Perl will be one of the magic dynamic pmcs that will sneakily load the dynamic library for you if you have yet to do so. Bernhard Schmalhofer via RT wrote: [coke - Fr 26. Nov 2004, 16:21:31]: Like all other language specific PMCs, Perl PMCs should only be loaded at runtime if necessary. When the Perl PMCs are dynamic, then the tests need to look up the type dynamically. As this also works for static types, the tests can be prepared for that in advance. See also the diffs between the SVN revisions 7896 and 7897
