[perl #53494] [BUG] --parrot_is_shared=0 IS shared?
# New Ticket Created by Will Coleda # Please include the string: [perl #53494] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53494 While trying to put the macport for 0.6.1 together, I noticed that the install failed. Tracked it down to the fact that --parrot_is_shared=0 seems to be generating a parrot that relies on a shared lib. This is happening for me on osx/86 (but the build works because it's finding the blib/lib version: once you install it, this fails because then it can't find the lib.), and on linux/x86 on feather (the build fails because miniparrot requires the shared library and can't find it, stopping the build immediately). This worked as recently as 0.5.2 (the last macport) -- Will Coke Coleda
[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.
# URL: 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;
[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.
# URL: 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 #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.
# URL: 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
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
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
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: 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, 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_methodP0=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_methodP0=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: [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, 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: [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: [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
[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.
# URL: 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 Cvoid Parrot_usleep(unsigned int microseconds)
+
+RT#48260: Not yet documented!!!
+
+=cut
+
+*/
+
+void
+Parrot_usleep(unsigned int microseconds)
+{
+Sleep(microseconds / 1000);
+}
+
+/*
+
=item Cstruct tm * Parrot_gmtime_r(const time_t *t, struct tm *tm)
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 Cvoid Parrot_usleep(unsigned int microseconds)
+
+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 Cvoid
+Parrot_usleep(unsigned int microseconds)
+
+RT#48260: Not yet documented!!!
+
+=cut
+
+*/
+
+void
+Parrot_usleep(unsigned int microseconds)
+{
+usleep(microseconds);
+}
+
+/*
+
=item Cstruct tm *
Parrot_gmtime_r(const time_t *t, struct tm *tm)
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 Cvoid
+Parrot_usleep(unsigned int microseconds)
+
+RT#48260: Not yet documented!!!
+
+=cut
+
+*/
+
+void
+Parrot_usleep(unsigned int microseconds)
+{
+usleep(microseconds);
+}
+
+/*
+
=item Cstruct tm *
Parrot_gmtime_r(const time_t *t, struct tm *tm)
[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. # URL: 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 #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.
# URL: 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]
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=enlnk=st#d7cb1751eea6b4c7
[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. # URL: 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]
[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. # URL: 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
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
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
