[perl #53548] [PATCH] fix for auto-generation of runtime/parrot/include/interpflags.pasm
# New Ticket Created by Chris Dolan # Please include the string: [perl #53548] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=53548 > The file runtime/parrot/include/interpflags.pasm is auto-generated by config/gen/parrot_include.pm from include/parrot/interpreter.h. The .h parser didn't know how to handle or'd values like this: PARROT_THR_TYPE_2 = PARROT_IS_THREAD | PARROT_THR_COPY_INTERP, Thus, the generated file looked like: .macro_const PARROT_THR_TYPE_1 4096 .macro_const PARROT_THR_TYPE_2 4096 .macro_const PARROT_THR_TYPE_3 4096 With the attached patch, the generated file now (correctly) looks like this: .macro_const PARROT_THR_TYPE_1 4096 .macro_const PARROT_THR_TYPE_2 12288 .macro_const PARROT_THR_TYPE_3 28672 I did not check whether the parser change broke affected any other generated files. It would be a good idea to run the generator before and after applying this patch to see exactly what changes. There's a bit of code duplication in this patch, for example with the octal parsing. This could easily be factored out if desirable (by me or someone else). Chris P.S. I tested via the following command: perl -Ilib -Iconfig -MParrot::Configure -Mgen::parrot_include \ -e'gen::parrot_include->new->runstep(Parrot::Configure->new)' parrot_include.pm | 42 -- 1 files changed, 40 insertions(+), 2 deletions(-) parrot_include.pm.patch Description: Binary data
Re: [perl #53496] Re: [bug] Build failure with G++
On Monday 28 April 2008 23:52:44 Senaka Fernando wrote: > Attaching patch No. 2 for C++ Build Issue. > > I still need to resolve this bigint.c issue. This is something caused by > the GMP includes I suspect. This patch didn't apply cleanly as of r27247; is it still an issue for you? -- c
Re: [perl #53472] [PATCH] jit/(ppc|arm)/exec_dep.*
On Monday 28 April 2008 14:51:29 [EMAIL PROTECTED] wrote: > The attached patch fixes a breakage in the build on linux-ppc with jit. > Without it, "make" aborts while trying to link libparrot.so with > > cc -o miniparrot src/main.o \ > -Wl,-rpath=/home/victor/src/perl6/parrot/blib/lib > -L/home/victor/src/perl6/parrot/blib/lib -lparrot -ldl -lm -lpthread > -lcrypt -lrt -lgmp -lreadline -lglut -lGLU -lGL -lcrypto > -L/usr/local/lib -Wl,-E src/null_config.o > /home/victor/src/perl6/parrot/blib/lib/libparrot.so: undefined reference > to `offset_fixup' > > A change in the declaration of offset_fixup from void to static void > appears to have caused this. It's been a long time since I've done any > C programming (decades in fact) so go easy. I can include the myconfig > if requested. This fixes the build for me, but ymmv. I've included a > mysimilar change for ARM on the theory that the declarations are the > same there and may well be similarly broken. I'm not subscribed to the > list, so replies should go to my email rather than the list. This looks correct to me (and I think I'm the one who broke it). Thanks, applied as r27248. -- c
Re: [perl #53542] [PATCH] dynpmc.pl ignores compilation failures
On Tuesday 29 April 2008 20:28:25 Andy Dougherty wrote:
> When compilation of a file in src/dynpmc/ fails, the build continues
> anyway -- there was an existing "die" command, but it could never actually
> be triggered. This patch actually looks at the return value and dies if
> the compilation fails. (Otherwise, the error gets buried and is easy to
> miss.)
>
> --- parrot-svn/config/gen/makefiles/dynpmc_pl.in Mon Apr 28 12:31:26 2008
> +++ parrot-andy/config/gen/makefiles/dynpmc_pl.in Tue Apr 29 11:28:15 2008
> @@ -270,12 +270,10 @@
>
> $dest_stem ||= $src_stem;
> if (needs_build("$dest_stem$O", "$src_stem.c")) {
> -return run(compile_cmd("$dest_stem$O", "$src_stem.c"))
> +run(compile_cmd("$dest_stem$O", "$src_stem.c"))
>or die "compile $src_stem.c failed ($?)\n";
> }
> -else {
> -return 1;
> -}
> +return 1;
> }
>
> sub partial_link {
Thanks, applied as r27247.
-- c
Re: [perl #53544] [PATCH] digst_pmc.in: Void functions can not return values.
On Tuesday 29 April 2008 21:28:18 Andy Dougherty wrote: > If I have traced its lineage correctly, this patch fixes the following > problem in sha256.c and sha512.c: > > "./sha256.pmc", line 164: void function cannot return value > > (note that line 164 of sha256.pm is actually the "vim: ..." comment > at the end of the file. I'm not sure where the line numbers are > getting messed up.) > > --- parrot-svn/config/gen/crypto/digest_pmc.inMon Apr 28 12:31:25 2008 > +++ parrot-cc/config/gen/crypto/digest_pmc.in Tue Apr 29 11:35:03 2008 > @@ -134,7 +134,7 @@ > > RETURN(STRING *retval); > #else > -return NULL; > +return; > #endif > } Thanks, applied as r27246. -- c
Re: [perl #53546] [PATCH] RT#46785: [TODO] [Perl] Add more File-related tests to the smartlinks tests
On Tuesday 29 April 2008 22:25:34 Chris Dolan wrote: > I picked a random easy TODO off the list. This patch resolves > RT#46785 and does a tiny piece of RT#46787. Thanks, applied as r27245. -- c
[perl #53546] [PATCH] RT#46785: [TODO] [Perl] Add more File-related tests to the smartlinks tests
# New Ticket Created by Chris Dolan # Please include the string: [perl #53546] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=53546 > I picked a random easy TODO off the list. This patch resolves RT#46785 and does a tiny piece of RT#46787. Chris smartlinks.t | 32 1 files changed, 24 insertions(+), 8 deletions(-) smartlinks.t.patch Description: Binary data
[perl #53544] [PATCH] digst_pmc.in: Void functions can not return values.
# New Ticket Created by Andy Dougherty # Please include the string: [perl #53544] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=53544 > If I have traced its lineage correctly, this patch fixes the following problem in sha256.c and sha512.c: "./sha256.pmc", line 164: void function cannot return value (note that line 164 of sha256.pm is actually the "vim: ..." comment at the end of the file. I'm not sure where the line numbers are getting messed up.) --- parrot-svn/config/gen/crypto/digest_pmc.in Mon Apr 28 12:31:25 2008 +++ parrot-cc/config/gen/crypto/digest_pmc.in Tue Apr 29 11:35:03 2008 @@ -134,7 +134,7 @@ RETURN(STRING *retval); #else -return NULL; +return; #endif } -- Andy Dougherty [EMAIL PROTECTED]
The future of exception handling
As I said during #parrotsketch [1], I have recently (and belatedly) learned that exception handling is planned for a major shakeup. (FWIW, I now see that is because exceptions are being recast as events; I had assumed that PDD24 was just about asynchronous events. Since PDD23 hasn't changed much in the last year, it slipped past my radar.) However, having read the current versions of pdd23_exceptions.pod, pdd24_events.pod, and pdd25_concurrency.pod (albeit perhaps not thoroughly enough), I still have many questions; the most salient ones are below. Please don't hesitate to ask if any of this is unclear. (I'm not expecting immediate answers in any case.) 1. In the "schedule" opcode item, it says the following: If the concurrency scheduler for this interpreter (thread/clustered instance) is linked to another "primary" concurrency scheduler, this will pass along the event to the primary. Para 3 in the "Implementation" section says: In more complex cases (particularly on multi-processor machines), the concurrency scheduler runs in its own thread. However, I didn't see a mechanism for associating handlers or events with a particular thread. How do I implement synchronous (nonthreaded) exception handling on a multiprocessor? pdd23_exceptions.pod seems to assume single-threading; is this slated to change? (Are there any languages that really do exception handling concurrently? Even in Erlang, errors within each process seem to happen synchronously, and are propagated between processes only as messages [2].) 2. The "Event Type Hierarchy" section doesn't include "Exception" as a type. Is this an oversight? How are user-defined types introduced into the exception type hierarchy? In particular, is it possible to define new groupings, or add to old ones? 3. I assume "the core code object of the event handler" is what gets called when the event handler is invoked? Can it be a closure (as pdd23_exceptions.pod seems to imply)? What happens if it is (or it invokes) a continuation; do we get sent back to that thread? In the original interpreter, or the concurrency scheduler interpreter? 4. In Common Lisp, one can re-signal a condition in a handler [3], i.e. while it is already being signalled (thrown): (defun test-case () (handler-bind ((error #'(lambda (condition) (signal condition) ;; Not handled, so we get it. (format t "Error ~A was not handled.~%" condition) (return-from test-case nil (do-something-hairy))) This of course requires that the handler not be in its own scope (just as for Perl 6), so that the second "signal" can propagate outward. Is that handled automatically, or do event handlers have to disestablish themselves explicitly? I notice that "rethrow" is going away; is it OK to just "throw" the same exception again in order to implement "signal"? 5. On the flip side of the issue, if do-something-hairy creates a continuation that gets called after exiting test-case, how does the handler established by test-case get re-established? 6. As also mentioned in #parrotsketch, I (not to mention Coke and Patrick ;-) need something equivalent to "pushaction" in order to implement CL unwind-protect. I am also currently using it to implement dynamic global variable binding, but that is a kludge. (As discussed last fall [4], I hope to replace the kludge with a mechanism that also uses dynamic_env, so news of its planned demise is worrying.) For both applications, though, I need something that also respects continuations, i.e. they must be triggered when blocks are exited via continuation calling. So, how should I do this in the brave new world? My apologies if this is obscure, but I figured I had better speak up ASAP, and post clarifications as needed. -- Bob Rogers http://rgrjr.dyndns.org/ [1] http://www.parrotcode.org/misc/parrotsketch-logs/irclog.parrotsketch-200804/irclog.parrotsketch.20080429 [2] Joe Armstrong, "Programming Erlang", chapter 9. [3] See the "Default Handling" section of Kent Pitman, "Condition Handling in the Lisp Language Family", http://www.nhplace.com/kent/Papers/Condition-Handling-2001.html [4] http://groups.google.com/group/perl.perl6.internals/browse_thread/thread/158e5fbcc84479a8/d7cb1751eea6b4c7?hl=en&lnk=st#d7cb1751eea6b4c7
[perl #53542] [PATCH] dynpmc.pl ignores compilation failures
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #53542]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53542 >
When compilation of a file in src/dynpmc/ fails, the build continues
anyway -- there was an existing "die" command, but it could never actually
be triggered. This patch actually looks at the return value and dies if
the compilation fails. (Otherwise, the error gets buried and is easy to
miss.)
--- parrot-svn/config/gen/makefiles/dynpmc_pl.inMon Apr 28 12:31:26 2008
+++ parrot-andy/config/gen/makefiles/dynpmc_pl.in Tue Apr 29 11:28:15 2008
@@ -270,12 +270,10 @@
$dest_stem ||= $src_stem;
if (needs_build("$dest_stem$O", "$src_stem.c")) {
-return run(compile_cmd("$dest_stem$O", "$src_stem.c"))
+run(compile_cmd("$dest_stem$O", "$src_stem.c"))
or die "compile $src_stem.c failed ($?)\n";
}
-else {
-return 1;
-}
+return 1;
}
sub partial_link {
--
Andy Dougherty [EMAIL PROTECTED]
[perl #53538] [BUG] Parrot_floatval_time() and Parrot_intval_time() do not match up on Win32
# New Ticket Created by Mark Glines # Please include the string: [perl #53538] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=53538 > When running the following PIR: .sub main I0 = time print I0 print "\n" N0 = time print N0 print "\n" I0 = N0 print I0 print "\n" .end On linux, I get: 1209519949 1209519949.066321 1209519949 This is what we expected. On Mingw32, I get: 1209538332 12854011932.719000 -2147483648 On MSVC, wknight8111 got: 1209519873 12853993473.285999 -30908415 These numbers are completely wrong. This causes problems elsewhere; for instance, the code in Parrot_cx_schedule_sleep() expects the two timestamp formats to match up, so it can calculate the correct time to wake up again. (I believe this may be the root cause of RT #53458.)
[perl #53536] [PATCH] sub-second sleep precision for non-threaded architectures
# New Ticket Created by Mark Glines
# Please include the string: [perl #53536]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53536 >
The "sleep" op calls Parrot_cx_schedule_sleep(), which falls back to
Parrot_sleep() on non-threaded architectures. Here's a patch to
implement a Parrot_usleep() and call that instead, for those
platforms.
POSIX platforms have usleep(), with microsecond precision. Win32
has Sleep(), with millisecond precision. Are there any platforms which
*don't* have one of those? Such a platform can probably either use
select(), or some other platform-specific call.
I am having trouble finding a platform to test this on... everything
available to me seems to have threads, and I can't find a Configure.pl
option to disable them, so I can't test this effectively.
Anyway, it turns out I didn't need to shave this yak, but it might be
useful for someone else. I'm posting the patch for review, hopefully
someone smarter than me will speak up. :)
Mark
Index: src/scheduler.c
===
--- src/scheduler.c (revision 27229)
+++ src/scheduler.c (working copy)
@@ -655,7 +655,13 @@
MUTEX_DESTROY(lock);
#else
/* A more primitive, platform-specific, non-threaded form of sleep. */
-Parrot_sleep((UINTVAL) ceil(time));
+if(time > 1000) {
+/* prevent integer overflow when converting to microseconds */
+int seconds = floor(time);
+Parrot_sleep(seconds);
+time -= seconds;
+}
+Parrot_usleep((UINTVAL) time*100);
#endif
return next;
}
Index: config/gen/platform/win32/time.c
===
--- config/gen/platform/win32/time.c(revision 27229)
+++ config/gen/platform/win32/time.c(working copy)
@@ -91,6 +91,22 @@
/*
+=item C
+
+RT#48260: Not yet documented!!!
+
+=cut
+
+*/
+
+void
+Parrot_usleep(unsigned int microseconds)
+{
+Sleep(microseconds / 1000);
+}
+
+/*
+
=item C
RT#48260: Not yet documented!!!
Index: config/gen/platform/ansi/time.c
===
--- config/gen/platform/ansi/time.c (revision 27229)
+++ config/gen/platform/ansi/time.c (working copy)
@@ -79,6 +79,23 @@
/*
+=item C
+
+RT#48260: Not yet documented!!!
+
+=cut
+
+*/
+
+void
+Parrot_usleep(unsigned int microseconds)
+{
+Parrot_warn(NULL, PARROT_WARNINGS_PLATFORM_FLAG, "Parrot_usleep not
implemented");
+return;
+}
+
+/*
+
=back
=cut
Index: config/gen/platform/platform_interface.h
===
--- config/gen/platform/platform_interface.h(revision 27229)
+++ config/gen/platform/platform_interface.h(working copy)
@@ -72,6 +72,7 @@
*/
void Parrot_sleep(unsigned int seconds);
+void Parrot_usleep(unsigned int microseconds);
INTVAL Parrot_intval_time(void);
FLOATVAL Parrot_floatval_time(void);
struct tm * Parrot_gmtime_r(const time_t *, struct tm *);
Index: config/gen/platform/generic/time.c
===
--- config/gen/platform/generic/time.c (revision 27229)
+++ config/gen/platform/generic/time.c (working copy)
@@ -80,6 +80,23 @@
/*
+=item C
+
+RT#48260: Not yet documented!!!
+
+=cut
+
+*/
+
+void
+Parrot_usleep(unsigned int microseconds)
+{
+usleep(microseconds);
+}
+
+/*
+
=item C
Index: config/gen/platform/solaris/time.c
===
--- config/gen/platform/solaris/time.c (revision 27229)
+++ config/gen/platform/solaris/time.c (working copy)
@@ -80,6 +80,23 @@
/*
+=item C
+
+RT#48260: Not yet documented!!!
+
+=cut
+
+*/
+
+void
+Parrot_usleep(unsigned int microseconds)
+{
+usleep(microseconds);
+}
+
+/*
+
=item C
Re: [perl #53450] [PATCH] for file "parrot.spec"
On Tuesday 29 April 2008 08:45:33 Reini Urban wrote: > 2008/4/29 chromatic <[EMAIL PROTECTED]>: > > I want to keep the ICU, because we're likely going to need it, but SVK > > isn't necessary. > > libicu-devel is amn optional but recommended build-dep. > It is needed for the Configure detection and for the compilation > step for unicode support. > The runtime-dep is only libicu34 Do we need to add anything for libicu34 as a runtime-dep, or is the build-dep sufficient? -- c
Re: [svn:parrot] r27233 - in branches/pdd25cx/src: . pmc
On Tuesday 29 April 2008 10:01:27 [EMAIL PROTECTED] wrote:
> Log:
> [pdd25cx] Merge in my port of Exceptions PMC to use core struct instead of
> array for attribute storage.
> - Keep 'type' attribute.
> - Use attribute access macros instead of direct struct manipulation so
> Exception PMC is subclassable from HLL.
> --- branches/pdd25cx/src/pmc/exception.pmc(original)
> +++ branches/pdd25cx/src/pmc/exception.pmcTue Apr 29 10:01:26 2008
> @@ -71,23 +46,19 @@
>
> #include "parrot/parrot.h"
>
> -/*
> -
> -=head2 Methods
> +pmclass Exception extends ResizablePMCArray need_ext {
We should be able to remove 'extends ResizablePMCArray' now, right?
> @@ -98,16 +69,20 @@
> */
>
> VTABLE void init() {
> -Parrot_Exception * const exception =
> +Parrot_Exception * const core_struct =
> mem_allocate_zeroed_typed(Parrot_Exception);
>
> +/* Set flags for custom DOD mark and destroy. */
> PObj_custom_mark_SET(SELF);
> PObj_active_destroy_SET(SELF);
>
> -PMC_data(SELF) = exception;
> -exception->message = CONST_STRING(interp, "");
> -exception->severity = 0;
> -exception->payload = PMCNULL;
> +/* Set up the core struct and default values for the exception
> object. */ +PMC_data(SELF) = core_struct;
> +core_struct->message = CONST_STRING(interp, "");
> +core_struct->payload = PMCNULL;
> +core_struct->severity = 0;
> +core_struct->type = 0;
> +core_struct->exit_code = 0;
These are unnecessary; mem_allocate_zeroed_typed() has already set them to
zero.
-- c
Re: weird perl6/plumhead problem
On Tue, Apr 29, 2008 at 1:54 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 01:48:52PM -0400, Jeff Horwitz wrote: > > On Tue, 29 Apr 2008, Patrick R. Michaud wrote: > > > > >On Tue, Apr 29, 2008 at 12:34:47PM -0400, Jeff Horwitz wrote: > > >>mod_parrot can load multiple HLL compilers in the same interpreter, and > on > > >>my server i'm using both perl6 and plumhead. this works fine if i load > > >>perl6 before plumhead. however, if i load perl6 *after* plumhead, i get > a > > >>nasty error: > > >> > > >> push_pmc() not implemented in class 'Sub' > > ... > > My complete off-the-wall guess is that perl6.pbc has a :multi sub > that happens to have the same name as a non-multi sub in plumhead. > Or something like that. > > So, when perl6 is loaded first, the :multi sub in perl6 gets > replaced by the non-multi sub in plumhead. When plumhead is > loaded first, Parrot tries to push the :multi sub in perl6 onto > the (non-:multi) sub in plumhead and throws the exception. > > Again, it's just a guess based on only a cursory reading of the > backtraces, so don't put too much stock into it. > > Pm More guessing: this will go away once the PCT provides each language an .HLL sandbox in which to play. -- Will "Coke" Coleda
Re: [PATCH] Rearrange PObj Struct Members
On Mon, 28 Apr 2008, Andy Dougherty wrote:
> On Sun, 27 Apr 2008, chromatic wrote:
>
> > Here's another proposed patch for testing on various platforms. I'm trying
> > to
> > get rid of some dodgy casts (which likely don't help C++ and processors
> > with
> > stricter alignment than 32-bit x86). I'd also like to remove unnecessary
> > members from a few structs. This is the next step.
> >
> > Are there any weird errors or unexpected crashes on anything more exotic
> > than
> > 32-bit x86 GNU/Linux?
>
> > /* Parrot Object - base class for all others */
> > typedef struct pobj_t {
> > +Parrot_UInt flags;
> > UnionVal u;
> > -Parrot_UInt flags;
> > } pobj_t;
>
> I'll try building, but since there are 4 permutations to try (cc and gcc,
> and with and without this patch) and since each build takes 1 to 2 hours
> if everything goes well, it won't be until tomorrow at the earliest that
> I can report anything back. (Longer, if manual intervention is required
> to fix unrelated errors.)
For Solaris/SPARC I got no additional errors or test failures with this
patch. (the build fails due to unrelated issues in the crypto stuff, but
no additional failures show up.)
Under gcc, I do get a new warning:
src/gc/smallobject.c: In function 'Parrot_small_object_pool_merge':
src/gc/smallobject.c:520: warning: cast increases required alignment of target
type
src/gc/smallobject.c:522: warning: cast increases required alignment of target
type
The relevant lines are:
while (*free_list_end)
free_list_end = &PMC_struct_val((PObj *)free_list_end); /* 520 */
PMC_struct_val((PObj *)free_list_end) = source->free_list; /* 522 */
Where free_list_end is a void **, and casting it to a (PObj *) assumes a
stricter alignment. Since this is just the sort of thing you're hoping to
clean up anyway, and since gcc already raises 162 other warnings
(including 128 other alignment warnings, but not including the 149
different warnings Solaris cc raises) I'm not overly concerned by it.
--
Andy Dougherty [EMAIL PROTECTED]
Re: weird perl6/plumhead problem
On Tue, 29 Apr 2008, Patrick R. Michaud wrote: On Tue, Apr 29, 2008 at 12:34:47PM -0400, Jeff Horwitz wrote: mod_parrot can load multiple HLL compilers in the same interpreter, and on my server i'm using both perl6 and plumhead. this works fine if i load perl6 before plumhead. however, if i load perl6 *after* plumhead, i get a nasty error: push_pmc() not implemented in class 'Sub' i get the same error with this plain PIR: .sub main :main print "loading plumhead\n" load_bytecode "languages/plumhead/plumhead.pbc" print "loading perl6\n" load_bytecode "languages/perl6/perl6.pbc" print "done\n" .end [EMAIL PROTECTED]:~/build/parrot$ ./parrot foo.pir loading plumhead loading perl6 push_pmc() not implemented in class 'Sub' current instr.: 'main' pc 6 (foo.pir:5) any ideas? backtrace is below. How about with a -t 1 ? duh, should've given you that in the first place. the trace is HUGE, so here's the last 50 lines. you should be able to reproduce the error using the code above if you need more detail. 21 load_bytecode "compilers/tge/TGE/Tr" 0 newclass P0, "TGE::Tree" P0=PMCNULL 3 addattribute P0, "cell" P0=Class=PMC(0x845f814) 6 addattribute P0, "visit" P0=Class=PMC(0x845f814) 9 addattribute P0, "data" P0=Class=PMC(0x845f814) 12 addattribute P0, "grammar" P0=Class=PMC(0x845f814) 15 addattribute P0, "agid" P0=Class=PMC(0x845f814) 18 set_returns PC7 20 returncc 23 load_bytecode "compilers/tge/TGE/Pa" 0 push_eh 7 2 subclass P0, "PGE::Grammar", "TGE::Parser" P0=PMCNULL 6 pop_eh 7 set_returns PC3 9 returncc 25 load_bytecode "compilers/tge/TGE/Gr" 0 newclass P0, "TGE::Grammar" P0=PMCNULL 3 addattribute P0, "rules" P0=Class=PMC(0x8516ce4) 6 addattribute P0, "symbols" P0=Class=PMC(0x8516ce4) 9 set_returns PC5 11 returncc 27 load_bytecode "compilers/tge/TGE/Co" 0 load_bytecode "TGE.pbc" 2 get_class P0, "TGE::Grammar" P0=PMCNULL 5 subclass P1, P0, "TGE::Compiler" P1=PMCNULL P0=Class=PMC(0x8516ce4) 9 set_returns PC5 11 returncc 29 get_class P0, PC22 P0=Integer=PMC(0x846304c: 1) PC22=Key=PMC(0x820f890) 32 get_hll_global P1, PC24, "die" P1=PMCNULL PC24=Key=PMC(0x820f874) 36 set_args PC2 (3), P0, "die", P1 PC2=FixedIntegerArray=PMC(0x8463394) P0=Class=PMC(0x8518d28) P1=Sub=PMC(0x846836c pc:7) 41 get_results PC19 43 callmethodcc P0, "add_method"P0=Class=PMC(0x8518d28) 46 get_hll_global P1, PC24, "line_number" P1=Sub=PMC(0x846836c pc:7) PC24=Key=PMC(0x820f874) 50 set_args PC2 (3), P0, "line_number", P1 PC2=FixedIntegerArray=PMC(0x8463394) P0=Class=PMC(0x8518d28) P1=Sub=PMC(0x8467e80 pc:229) 55 get_results PC19 57 callmethodcc P0, "add_method"P0=Class=PMC(0x8518d28) 60 set_returns PC19 62 returncc 32824 push_eh 7 32826 subclass P0, "TGE::Grammar", "Plumhead::PAST::Gram" P0=PMCNULL 32830 pop_eh 32831 set_returns PC22 32833 returncc loading perl6 4 print "loading perl6\n" 6 load_bytecode "languages/perl6/perl" push_pmc() not implemented in class 'Sub' current instr.: 'main' pc 6 (foo.pir:5) ParrotIO objects (like stdout and stderr)are about to be closed, so clearing trace flags.
Re: weird perl6/plumhead problem
On Tue, Apr 29, 2008 at 12:34:47PM -0400, Jeff Horwitz wrote: > mod_parrot can load multiple HLL compilers in the same interpreter, and on > my server i'm using both perl6 and plumhead. this works fine if i load > perl6 before plumhead. however, if i load perl6 *after* plumhead, i get a > nasty error: > > push_pmc() not implemented in class 'Sub' > > i get the same error with this plain PIR: > > .sub main :main > print "loading plumhead\n" > load_bytecode "languages/plumhead/plumhead.pbc" > print "loading perl6\n" > load_bytecode "languages/perl6/perl6.pbc" > print "done\n" > .end > > [EMAIL PROTECTED]:~/build/parrot$ ./parrot foo.pir > loading plumhead > loading perl6 > push_pmc() not implemented in class 'Sub' > current instr.: 'main' pc 6 (foo.pir:5) > > any ideas? backtrace is below. How about with a -t 1 ? Pm
Re: weird perl6/plumhead problem
On Tue, Apr 29, 2008 at 01:48:52PM -0400, Jeff Horwitz wrote: > On Tue, 29 Apr 2008, Patrick R. Michaud wrote: > > >On Tue, Apr 29, 2008 at 12:34:47PM -0400, Jeff Horwitz wrote: > >>mod_parrot can load multiple HLL compilers in the same interpreter, and on > >>my server i'm using both perl6 and plumhead. this works fine if i load > >>perl6 before plumhead. however, if i load perl6 *after* plumhead, i get a > >>nasty error: > >> > >> push_pmc() not implemented in class 'Sub' > ... My complete off-the-wall guess is that perl6.pbc has a :multi sub that happens to have the same name as a non-multi sub in plumhead. Or something like that. So, when perl6 is loaded first, the :multi sub in perl6 gets replaced by the non-multi sub in plumhead. When plumhead is loaded first, Parrot tries to push the :multi sub in perl6 onto the (non-:multi) sub in plumhead and throws the exception. Again, it's just a guess based on only a cursory reading of the backtraces, so don't put too much stock into it. Pm
Re: [perl #53450] [PATCH] for file "parrot.spec"
2008/4/29 chromatic <[EMAIL PROTECTED]>: > On Monday 28 April 2008 09:06:15 [EMAIL PROTECTED] wrote: > > the command "rpmbuild -ba parrot.spec" did only work after I changed the > > file "parrot.spec" to hold a new line. > > > > The attached file "parrot.spec.patch" holds the output from the command: > > > diff -u parrot.spec parrot.spec.new > parrot.spec.patch > > > > After that change I produced rpms (make rpms) for the parrot version > > 0.6.1 under the operating-systems: > > Fedora 7, Fedora 8 and Fedora 9-Beta > > > > The rpms "libicu-devel" and "perl-SVK" are not needed to build parrot. > > So the following two lines should be removed or commented out: > > BuildRequires: libicu-devel > > BuildRequires: perl-SVK > > I want to keep the ICU, because we're likely going to need it, but SVK isn't > necessary. libicu-devel is amn optional but recommended build-dep. It is needed for the Configure detection and for the compilation step for unicode support. The runtime-dep is only libicu34 -- Reini Urban
weird perl6/plumhead problem
mod_parrot can load multiple HLL compilers in the same interpreter, and on my server i'm using both perl6 and plumhead. this works fine if i load perl6 before plumhead. however, if i load perl6 *after* plumhead, i get a nasty error: push_pmc() not implemented in class 'Sub' i get the same error with this plain PIR: .sub main :main print "loading plumhead\n" load_bytecode "languages/plumhead/plumhead.pbc" print "loading perl6\n" load_bytecode "languages/perl6/perl6.pbc" print "done\n" .end [EMAIL PROTECTED]:~/build/parrot$ ./parrot foo.pir loading plumhead loading perl6 push_pmc() not implemented in class 'Sub' current instr.: 'main' pc 6 (foo.pir:5) any ideas? backtrace is below. Breakpoint 2, cant_do_method (interp=0x804f048, pmc=0x829d204, methname=0x403cda8d "push_pmc") at default.pmc:63 63 real_exception(interp, NULL, ILL_INHERIT, (gdb) bt #0 cant_do_method (interp=0x804f048, pmc=0x829d204, methname=0x403cda8d "push_pmc") at default.pmc:63 #1 0x402a732e in Parrot_default_push_pmc (interp=0x804f048, pmc=0x829d204, value=0x82fcbac) at default.c:1632 #2 0x4016130a in store_sub_in_multi (interp=0x804f048, sub=0x82fcbac, ns=0x8092ec4) at src/global.c:739 #3 0x40161410 in Parrot_store_sub_in_namespace (interp=0x804f048, sub=0x82fcbac) at src/global.c:777 #4 0x401934de in PackFile_Constant_unpack_pmc (interp=0x804f048, constt=0x83271d0, self=0x81167e0, cursor=0x40aa94f4) at src/packfile.c:3584 #5 0x401933d8 in PackFile_Constant_unpack (interp=0x804f048, constt=0x83271d0, self=0x81167e0, cursor=0x40aa9428) at src/packfile.c:3526 #6 0x401930dc in PackFile_ConstTable_unpack (interp=0x804f048, seg=0x83271d0, cursor=0x40aa9424) at src/packfile.c:3322 #7 0x401907ea in PackFile_Segment_unpack (interp=0x804f048, self=0x83271d0, cursor=0x40a9ff50) at src/packfile.c:1601 #8 0x40190cfd in directory_unpack (interp=0x804f048, segp=0x8327028, cursor=0x40a9ff40) at src/packfile.c:1795 #9 0x401907ea in PackFile_Segment_unpack (interp=0x804f048, self=0x8327028, cursor=0x40a24040) at src/packfile.c:1601 #10 0x4018f8b1 in PackFile_unpack (interp=0x804f048, self=0x8327028, packed=0x40a24000, packed_size=1254976) at src/packfile.c:867 #11 0x40153b10 in Parrot_readbc (interp=0x804f048, fullname=0x8326fb8 "/home/jeff/build/parrot/./languages/perl6/perl6.pbc") at src/embed.c:503 #12 0x401937d4 in PackFile_append_pbc (interp=0x804f048, filename=0x8326fb8 "/home/jeff/build/parrot/./languages/perl6/perl6.pbc") at src/packfile.c:3701 #13 0x401939b2 in Parrot_load_bytecode (interp=0x804f048, file_str=0x81fba50) at src/packfile.c:3758 #14 0x400f5c4c in Parrot_load_bytecode_sc (cur_opcode=0x8248918, interp=0x804f048) at core.ops:151 #15 0x40199984 in runops_slow_core (interp=0x804f048, pc=0x8248918) at src/runops_cores.c:219 #16 0x4016ac26 in runops_int (interp=0x804f048, offset=0) at src/interpreter.c:916 #17 0x4016b525 in runops (interp=0x804f048, offs=0) at src/inter_run.c:104 #18 0x4016b7aa in runops_args (interp=0x804f048, sub=0x822ac6c, obj=0x8096098, meth_unused=0x0, sig=0x403c3727 "vP", ap=0xbbbc "P\"\b\220") at src/inter_run.c:230 #19 0x4016b8ec in Parrot_runops_fromc_args (interp=0x804f048, sub=0x822ac6c, sig=0x403c3727 "vP") at src/inter_run.c:299 #20 0x401545a7 in Parrot_runcode (interp=0x804f048, argc=1, argv=0xbd18) at src/embed.c:941 #21 0x4039f044 in imcc_run_pbc (interp=0x804f048, obj_file=0, output_file=0x0, argc=1, argv=0xbd18) at compilers/imcc/main.c:781 #22 0x4039faf2 in imcc_run (interp=0x804f048, sourcefile=0xbe33 "foo.pir", argc=1, argv=0xbd18) at compilers/imcc/main.c:1069 #23 0x080488d8 in main (argc=1, argv=0xbd18) at src/main.c:61
[perl #53492] [PATCH] for file "parrot.spec"
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #53492]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53492 >
Hello,
the command "rpmbuild -ba parrot.spec" did only work after I changed the
file "parrot.spec" to hold a new line.
The attached file "parrot.spec.patch" holds the output from the command:
> diff -u parrot.spec parrot.spec.new > parrot.spec.patch
After that change I produced rpms (make rpms) for the parrot version
0.6.1 under the operating-systems:
Fedora 7, Fedora 8 and Fedora 9-Beta
The rpms "libicu-devel" and "perl-SVK" are not needed to build parrot.
So the following two lines should be removed or commented out:
BuildRequires: libicu-devel
BuildRequires: perl-SVK
Gerd Pokorra
--- parrot.spec 2008-04-25 14:43:07.0 +0200
+++ parrot.spec.new 2008-04-28 13:03:43.0 +0200
@@ -81,7 +81,8 @@
rm -rf $RPM_BUILD_ROOT%{_usr}/compilers \
$RPM_BUILD_ROOT%{_usr}/config \
$RPM_BUILD_ROOT%{_includedir}/src \
-$RPM_BUILD_ROOT%{_usr}/src
+$RPM_BUILD_ROOT%{_usr}/src \
+$RPM_BUILD_ROOT%{_usr}/tools
%check
export LD_LIBRARY_PATH=$( pwd )/blib/lib
[perl #53496] Re: [bug] Build failure with G++
# New Ticket Created by "Senaka Fernando"
# Please include the string: [perl #53496]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53496 >
Attaching patch No. 2 for C++ Build Issue.
I still need to resolve this bigint.c issue. This is something caused by the
GMP includes I suspect.
Regards,
Senaka
On Sun, Apr 13, 2008 at 8:43 PM, Senaka Fernando <[EMAIL PROTECTED]>
wrote:
> The build of Parrot fails with g++, which is a possible indication that it
> fails on other C++ compilers too. I have attached herewith patches to some
> issues. However, I still get this error once I start with the build.
>
> Compiling with:
> xx.c
> g++ -I./include -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN
> -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC
> -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE
> -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16
> -fvisibility=hidden -maccumulate-outgoing-args -W -Wall -Waggregate-return
> -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wdisabled-optimization
> -Wendif-labels -Wextra -Wformat -Wformat-extra-args -Wformat-nonliteral
> -Wformat-security -Wformat-y2k -Wimplicit -Wimport -Winit-self -Winline
> -Winvalid-pch -Wmissing-braces -Wmissing-field-initializers
> -Wno-missing-format-attribute -Wmissing-include-dirs -Wpacked -Wparentheses
> -Wpointer-arith -Wreturn-type -Wsequence-point -Wno-shadow -Wsign-compare
> -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default -Wtrigraphs
> -Wundef -Wunknown-pragmas -Wno-unused -Wvariadic-macros -Wwrite-strings
> -DHAS_GETTEXT -g -DHAS_JIT -DI386 -DHAVE_COMPUTED_GOTO -fPIC -I. -o xx.o -c
> xx.c
> src/pmc/bigint.c
> /usr/include/libintl.h:83: error: expected unqualified-id before 'throw'
> /usr/include/libintl.h:83: error: expected initializer before 'throw'
> /usr/include/libintl.h:87: error: expected unqualified-id before 'throw'
> /usr/include/libintl.h:87: error: expected initializer before 'throw'
> make: *** [src/pmc/bigint.o] Error 1
>
> This error didn't come up with a check out I took around two weeks back,
> but with the latest svn up it does. Wondering what this could be.
>
> Regards,
> Senaka
>
>
>
Index: src/key.c
===
--- src/key.c (revision 26966)
+++ src/key.c (working copy)
@@ -445,7 +445,7 @@
key_next(PARROT_INTERP, ARGIN(const PMC *key))
{
return
-VTABLE_isa(interp, key, CONST_STRING(interp, "Key")) && key->pmc_ext ?
+VTABLE_isa(interp, (PMC *)key, CONST_STRING(interp, "Key")) && key->pmc_ext ?
(PMC *)PMC_data(key) :
NULL;
}
Index: compilers/imcc/imclexer.c
===
--- compilers/imcc/imclexer.c (revision 26966)
+++ compilers/imcc/imclexer.c (working copy)
@@ -5796,7 +5796,11 @@
/* whitespace can be safely ignored */
do {
+#ifdef __cplusplus
+c = yyinput(yyscanner);
+#else
c = input(yyscanner);
+#endif
} while (c == ' ' || c == '\t');
if (c != '(') {
Index: compilers/imcc/imcc.l
===
--- compilers/imcc/imcc.l (revision 26966)
+++ compilers/imcc/imcc.l (working copy)
@@ -1118,7 +1118,11 @@
/* whitespace can be safely ignored */
do {
+#ifdef __cplusplus
+c = yyinput(yyscanner);
+#else
c = input(yyscanner);
+#endif
} while (c == ' ' || c == '\t');
if (c != '(') {
[perl #53472] [PATCH] jit/(ppc|arm)/exec_dep.*
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #53472]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53472 >
Hi All,
The attached patch fixes a breakage in the build on linux-ppc with jit.
Without it, "make" aborts while trying to link libparrot.so with
cc -o miniparrot src/main.o \
-Wl,-rpath=/home/victor/src/perl6/parrot/blib/lib
-L/home/victor/src/perl6/parrot/blib/lib -lparrot -ldl -lm -lpthread
-lcrypt -lrt -lgmp -lreadline -lglut -lGLU -lGL -lcrypto
-L/usr/local/lib -Wl,-E src/null_config.o
/home/victor/src/perl6/parrot/blib/lib/libparrot.so: undefined reference
to `offset_fixup'
A change in the declaration of offset_fixup from void to static void
appears to have caused this. It's been a long time since I've done any
C programming (decades in fact) so go easy. I can include the myconfig
if requested. This fixes the build for me, but ymmv. I've included a
mysimilar change for ARM on the theory that the declarations are the
same there and may well be similarly broken. I'm not subscribed to the
list, so replies should go to my email rather than the list.
Cheers
Victor
--
Victor Brunsden
Associate Professor of Mathematics,
Penn State Altoona,
119 Hawthorn Bldg,
3000 Ivyside Drive
Altoona, PA 16601
(814) 949-5695 (work)
(814) 949-5547 (fax)
http://math.aa.psu.edu/~victor
Index: src/jit/arm/exec_dep.h
===
--- src/jit/arm/exec_dep.h (revision 27217)
+++ src/jit/arm/exec_dep.h (working copy)
@@ -29,7 +29,7 @@
Parrot_exec_restart_op(Parrot_jit_info_t *jit_info, PARROT_INTERP);
/* Assign the offset of the program_code */
-static void
+void
offset_fixup(Parrot_exec_objfile_t *obj);
#endif /* PARROT_ARM_EXEC_DEP_H_GUARD */
Index: src/jit/arm/exec_dep.c
===
--- src/jit/arm/exec_dep.c (revision 27217)
+++ src/jit/arm/exec_dep.c (working copy)
@@ -78,7 +78,7 @@
}
/* Assign the offset of the progra_code */
-static void
+void
offset_fixup(Parrot_exec_objfile_t *obj)
{
int i, j;
Index: src/jit/ppc/exec_dep.h
===
--- src/jit/ppc/exec_dep.h (revision 27217)
+++ src/jit/ppc/exec_dep.h (working copy)
@@ -28,7 +28,7 @@
void
Parrot_exec_restart_op(Parrot_jit_info_t *jit_info, PARROT_INTERP);
-static void
+void
offset_fixup(Parrot_exec_objfile_t *obj);
#endif /* PARROT_PPC_EXEC_DEP_H_GUARD */
Index: src/jit/ppc/exec_dep.c
===
--- src/jit/ppc/exec_dep.c (revision 27217)
+++ src/jit/ppc/exec_dep.c (working copy)
@@ -60,7 +60,7 @@
}
/* Assign the offset of the program_code */
-static void
+void
offset_fixup(Parrot_exec_objfile_t *obj)
{
int i, j;
