Re: [perl #22706] IMCC ( Parrot) crash with -t when invoke is run
Clinton Pierce wrote: Clarification: running an invoke() at *any* time will cause all subsequent tracing to segfault. I can't reproduce that on Linux (even with Dan's patch not applied yet). leo
Re: [perl #22854] Incongruity in Parrot IO and/or Parrot I/O crashes on STDIN read
Clinton A. Pierce (via RT) wrote: Suggestions welcome! First, always check the result of IO operations. If something fails, these return a PerlUndef, so: .sub _main fdopen $P1, 0, r # STDIN defined $I0, $P1 unless $I0, err read $S0, $P1, 255 print $S0 end err: print fdopen failed\n end .end 2. Cfdopen was disabled totally due to a wrong #ifdef 3. its currently only defined for PIO_OS_UNIX 4. Thanks again for your really valuable bug reports. leo
Parrot Constants
Some parrot opcodes like interpinfo, stringinfo, warnings{on,off} have
constant items as an argument selecting some action. These are well
documented and working fine, but rather unreadable in PASM/PIR source
code and are suboptimal if some item ever needs a different value.
So I'd like to generate a new directory hierarchy e.g.
runtime/parrot/include
/parrot/libs # N/Y
and place files, containing such constant definitions in
Fruntime/parrot/include.
e.g.
# warnings.pasm # or .pinc (?)
.constant WARNINGS_UNDEF 1
.constant WARNINGS_IO2
...
# interpinfo.pasm
.constant GC_ALLOCATED_MEMORY 1
.constant GC_DOD_RUNS 2
...
# io.pasm
.constant IO_FD_STDIN 0
...
This would need finally some include search path (for an installed
parrot). Also the C.constant directive in imcc would be enabled - or
we use the typed C.const type ID = val directive of imcc.
I can imagine that the latter might be better for creating typed and PMC
constants:
.const float ONE = 1 # (NUMVAL)1.0
.const Exception FooBar_Exception = Fubared
Comments welcome.
leo
[perl #22855] [PATCH] build imcc as parrot
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #22855]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22855
Attached is a minimum patch to build imcc as the parrot executable
- renames orig parrot to test_main
- renames imcc to parrot
As the current build process needs rework anyway, I kept it to the bare
minimum.
Please give it a try on other platforms, especially non Linux.
$ make test # full speed ;-)
$ parrot -j examples/assembly/mops.pasm# run PASM/PIR
Thanks,
leo
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/60060/44488/3e05c3/imcc_is_parrot.patch
--- parrot/config/gen/makefiles/imcc.in Fri May 30 21:41:17 2003
+++ parrot-leo/config/gen/makefiles/imcc.in Mon Jun 30 13:41:48 2003
@@ -48,7 +48,7 @@
all : imcc${exe}
-../../$(PARROTLIB): ../../parrot$(EXE)
+../../$(PARROTLIB):
cd ..${slash}.. $(MAKE) $(PARROTLIB) cd languages${slash}imcc
# The .flag files are needed because we are keeping some derived files in CVS,
--- parrot/config/gen/makefiles/root.in Tue Jun 24 22:00:04 2003
+++ parrot-leo/config/gen/makefiles/root.in Mon Jun 30 13:45:49 2003
@@ -194,13 +194,14 @@
.c$(O) :
$(CC) $(CFLAGS) ${cc_o_out}$@ -c $
-all : $(TEST_PROG) docs
+all : $(TEST_PROG) docs $(IMCC_PROG)
mops : examples/assembly/mops${exe} examples/mops/mops${exe}
$(TEST_PROG) : test_main$(O) $(GEN_HEADERS) $(LIBPARROT) lib/Parrot/OpLib/core.pm
$(LINK) ${ld_out}$(TEST_PROG) $(LINKFLAGS) test_main$(O) $(LIBPARROT) $(C_LIBS)
+ $(PERL) -MExtUtils::Command -e mv $(TEST_PROG) test_main$(EXE)
lib_deps_object : $(O_FILES)
$(PERL) tools/dev/lib_deps.pl object $(O_FILES)
@@ -518,6 +519,10 @@
languages/imcc/*.l \
languages/imcc/*.o
cd languages${slash}imcc $(MAKE) cd ..${slash}..
+ $(PERL) -MExtUtils::Command -e mv $(IMCC_PROG) $(TEST_PROG)
+ cd languages${slash}imcc $(MAKE) cd ..${slash}..
+ # this doesn't work here
+ #$(PERL) -MExtUtils::Command -e chmod 0755 $(TEST_PROG)
###
--- parrot/lib/Parrot/Test.pm Sun Jun 1 11:10:26 2003
+++ parrot-leo/lib/Parrot/Test.pm Mon Jun 30 13:39:56 2003
@@ -95,6 +95,7 @@
$can_skip_compile = 0 if (not -e $by_f);
}
}
+ $ENV{IMCC} = 'parrot' . $PConfig{exe};
if (!$can_skip_compile) {
open ASSEMBLY, $as_f or die Unable to open '$as_f';
Re: [perl #22854] Incongruity in Parrot IO and/or Parrot I/O crashes on STDIN read
First, always check the result of IO operations. If something fails, these return a PerlUndef, so: .sub _main fdopen $P1, 0, r # STDIN defined $I0, $P1 *Doh* Stupid Newbie Error. unless $I0, err read $S0, $P1, 255 print $S0 end err: print fdopen failed\n end .end 2. Cfdopen was disabled totally due to a wrong #ifdef 3. its currently only defined for PIO_OS_UNIX Okaaay, so the plan is for this to work and I should probably code this way anyway, right?
[perl #22856] IMCC fails to build
# New Ticket Created by Simon Glover # Please include the string: [perl #22856] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22856 With a fresh checkout, I get: imcc.y:401: conflicting types for `YYSTYPE' imcparser.h:6: previous declaration of `YYSTYPE' /usr/lib/bison.simple: In function `yyparse': /usr/lib/bison.simple:432: warning: passing arg 1 of `yylex' from incompatible pointer type /usr/lib/bison.simple:614: warning: comparison between signed and unsigned /usr/lib/bison.simple:626: warning: comparison between signed and unsigned make: *** [imcparser.o] Error 1 when I try to build IMCC on a standard Linux/x86 platform. (NB This is without patch #22855 applied). Simon
Re: [perl #22856] IMCC fails to build
Simon Glover [EMAIL PROTECTED] wrote:
With a fresh checkout, I get:
imcc.y:401: conflicting types for `YYSTYPE'
imcparser.h:6: previous declaration of `YYSTYPE'
/usr/lib/bison.simple: In function `yyparse':
/usr/lib/bison.simple:432: warning: passing arg 1 of `yylex' from
incompatible pointer type
It seems, that Makefile did regenerate the imcparser.{c,h} files and
that for some reason (old bison?) this didn't work.
The generated files seem to have the same timestamp as imcc.y.
Please do a make clean in imcc and update from CVS, I'll refresh the
generated files with a newer time stamp.
Simon
leo
Re: [perl #22854] Incongruity in Parrot IO and/or Parrot I/O crashes on STDIN read
Clinton Pierce [EMAIL PROTECTED] wrote: .sub _main fdopen $P1, 0, r # STDIN BTW fdopen $P1, 0, # read STDIN 3. its currently only defined for PIO_OS_UNIX Okaaay, so the plan is for this to work and I should probably code this way anyway, right? You could just delete the #ifdef PIO_OS_UNIX in io.ops:fdopen and see, if its working. leo
[perl #22857] Parrot IO test failures
# New Ticket Created by Simon Glover # Please include the string: [perl #22857] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22857 Hi, I'm getting failures in tests 1 2 in t/pmc/io.t; however, both tests seem to run fine if I run them in the debugger. Furthermore, running test 1 on the command line, I find that for plain ./parrot and for ./parrot -g the test fails; for ./parrot -P and ./parrot -S, it succeeds; and for ./parrot -j, it succeeds and then segfaults. I have no idea what's going on here. Simon
Re: [perl #22856] IMCC fails to build
On Mon, 30 Jun 2003, Leopold Toetsch wrote:
Simon Glover [EMAIL PROTECTED] wrote:
With a fresh checkout, I get:
imcc.y:401: conflicting types for `YYSTYPE'
imcparser.h:6: previous declaration of `YYSTYPE'
/usr/lib/bison.simple: In function `yyparse':
/usr/lib/bison.simple:432: warning: passing arg 1 of `yylex' from
incompatible pointer type
It seems, that Makefile did regenerate the imcparser.{c,h} files and
that for some reason (old bison?) this didn't work.
The generated files seem to have the same timestamp as imcc.y.
Please do a make clean in imcc and update from CVS, I'll refresh the
generated files with a newer time stamp.
That did the trick - it builds fine now.
Simon
Re: [perl #22857] Parrot IO test failures
A further data point: the tests pass if I use IMCC to assemble them, rather than assemble.pl Simon
Re: [ANNOUNCE] Test::Warn::None 0.02
On Wednesday 25 June 2003 20:15, Adrian Howard wrote: Add an explicit test script finished footer? But how does the footer-adder know that the correct number of tests ran. You would need to declare a plan to run x additional extensions at which point you're doing sub-plans. I suppose I'm thinking of things from the I messed up my test script point of view rather than my test script died unexpectedly. Exit codes should catch the died unexpectedly stuff. A correct plan is good for catching the programmer errors but is a pain to maintain. I have some vague thoughts that there are some potentially cute things that you could do with extended plans that would be hard to do with sub-blocks/plans (e.g. any sort of test that cross-cuts several test scripts in an AOPish sort of way - checking that test data has returned to a state of grace for example). I guess that can be solved by controlling the timing of the output. I don't think there's a need for the results of test 1 to be printed before carrying out test 2, except maybe when the tests are being run by the developer. The patch I submitted almost allows that to work. Each block gets a Test::Builder object and whenever a block is finalised, it finalises all of it's sub blocks, so you could delay output until finalisation time. So, imagine that Test::Builder objects don't output anything until they are finalised, they just collect results quietly. You create an AOP block at the top level (ie a sub-block of the root Test::Builder). Then you do all your AOP tests using this Test::Builder::Block object. At the end, when all other tests are finished and output, your AOP test block will dump out it's results. F
Re: multi stack question/grumble
Dave Whipp wrote:
Matt Fowles
Were this C++ I would say that we could write a single general
purpose stack and use template meta-programming to avoid the
overhead. Is there a similar solution available in C?
My instincts tell me that this solution will be dirty to the tune of
massive macroing, but perhaps someone better with pure C than I am
could provide a better answer.
C does do templates, sort-of:
#define STACK_TYPE int
#define STACK_MAX_SIZE 1024
#include stack_template_decl.h
#include stack_template_impl.h
#undef STACK_TYPE
#undef STACK_MAX_SIZE
(often one instances the stack_decl in a header file, and the _impl in
a .c file.) I've also seen the calling convention where the template
files do the #undefs.
There can be some issues debugging this stuff though: gcc will give
currect line numbers, but will not tell you which instance of the
stack template you're in. So if a bug is only in, say, stacks of
double: then this won't be immediately apparent.
Any chance that this could be fixed with a #line pragma, with a filename
which is generated from the parameters? E.g., something like:
#define STRINGIFY(X) ??? /* make a string literal from a token */
#define STACK_TYPE_STR STRINGIFY(STACK_TYPE)
#define STACK_SIZE_STR STRINGIFY(STACK_MAX_SIZE)
#define GENFILENAME \
__LINE__ [ STACK_TYPE_STR x STACK_SIZE_STR ]
#line 0 GENFILENAME
On the plus side, the lack of type information means that you don't
get c++'s 8000-character error messages.
--
$a=24;split//,240513;s/\B/ = /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print [EMAIL PROTECTED]
]\n;((6=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))redo;}
Re: Exceptions
Brent Dax wrote:
Benjamin Goldberg:
# Concievably, we could then examine the exception, and maybe decide
# that it was nonfatal, and resume execution from just after the place
# it was thrown from.
The problem with that is that some exceptions are unresumable. For
example, exceptions thrown in C code are difficult to resume from,
especially if they represent e.g. a segfault. Exceptions that
represent things like a file failing to open can be difficult to
handle if they're thrown from an inner routine--you'd need to know
where to put the replacement filehandle.
Perhaps there can be an Exception::Resumable that inherits from both
Exception and Continuation, but I don't think that normal exceptions
can or should be resumable.
I thought that warnings were to be implemented as exceptions... in which
case, our exception handler (warning handler) needs to choose whether to
resume execution at the place that the warning was produced, or to die,
or... something.
Should the raise opcode produce resumable exceptions?
--
$a=24;split//,240513;s/\B/ = /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print [EMAIL PROTECTED]
]\n;((6=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))redo;}
Re: Exceptions
Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: Exception handlers really strike me as anonymous lexically scoped subroutines that get called with just one parameter--the exception object. As far as the engine should be concerned, when an exception is taken we just take a continuation with the address being the start of the code that handles the exception. Reading through pdd06 the following is not really speced (IMHO): Exception handlers are dynamically scoped, and any exception handler set in a scope will be removed when that scope is exited. How do we remove exception handlers on scope exit. Is this done, when we encounter a Cpop_pad instruction? Or should the HL emit a Cclear_eh opcode? As the exception handlers live on the control stack, there is not much connection between a lexical pad being popped off and removing exceptiion handlers in scope. What does a lexical pad have to do with dynamic scoping? I thought that the control stack was where dynamically scoped information lived... -- Piers
Re: [perl #22857] Parrot IO test failures
Simon Glover [EMAIL PROTECTED] wrote: I'm getting failures in tests 1 2 in t/pmc/io.t; however, both tests seem to run fine if I run them in the debugger. valgrind does indicate, that there are unitialized items in many parts of io_buf.c. (I don't know, if these tests even should use the bufferd IO layer, but there is for sure something wrong there) The arbitrary failures come from uninitialized memory. Simon leo
Re: Exceptions
At 11:53 AM -0400 6/30/03, Benjamin Goldberg wrote: Brent Dax wrote: Benjamin Goldberg: # Concievably, we could then examine the exception, and maybe decide # that it was nonfatal, and resume execution from just after the place # it was thrown from. The problem with that is that some exceptions are unresumable. For example, exceptions thrown in C code are difficult to resume from, especially if they represent e.g. a segfault. Exceptions that represent things like a file failing to open can be difficult to handle if they're thrown from an inner routine--you'd need to know where to put the replacement filehandle. Perhaps there can be an Exception::Resumable that inherits from both Exception and Continuation, but I don't think that normal exceptions can or should be resumable. I thought that warnings were to be implemented as exceptions... Nope. Warnings are warnings, and exceptions are exceptions. Warnings can be promoted to exceptions if need be, but they're separate things and don't share a common base. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[ANNOUNCE] Test::NoWarnings 0.01
Hi all, I've settled on Test::NoWarnings as the right name for this. This improves on Test::Warn 0.02 by - not running the test in forked children - capturing the warnings as objects which is to say that for most people, it's exactly the same. F
Re: [perl #22855] [PATCH] build imcc as parrot
On Mon, 30 Jun 2003, Leopold Toetsch wrote: Attached is a minimum patch to build imcc as the parrot executable Please give it a try on other platforms, especially non Linux. Sun's make failed with the following error: make: Fatal error: Don't know how to make target `languages/imcc/*.o' I guess it's because in the following segment of the Makefile, $(IMCC_PROG) : $(LIBPARROT)\ languages/imcc/*.c \ languages/imcc/*.h \ languages/imcc/*.y \ languages/imcc/*.l \ languages/imcc/*.o cd languages/imcc $(MAKE) cd ../.. languages/imcc/*.o doesn't match anything since nothing's been built in that directory yet. I suspect it's best to have an IMCC_PROG target that simply unconditionally does a cd to languages/imcc and calls $(MAKE). Apart from that, it built fine and passed all tests with Sun's cc and perl5.00503 on Solaris 8. -- Andy Dougherty [EMAIL PROTECTED]
Re: CPS invoke return context
Dan Sugalski [EMAIL PROTECTED] writes: At 11:19 PM +0200 6/29/03, Leopold Toetsch wrote: Dan Sugalski wrote: ... I'd also like to be able to manipulate the stacks in a context, pushing things on them, changing values on them, and generally messing about with the things, so I'm all for it. Do you have some examples for a usage of such manipulations? I thought that a return continuations should exactly match the state of the caller, so that the Cupdatecc op would do the work. But there are for sure some hacks, that might need some: updatecc .stack .action item Yep, that could work. There are a few actual good reasons to do this: *) A subroutine may want to affect the warnings state of its caller *) A sub may want to add in block exit actions (though that's more an inspection for the block exit item on the caller's stack) *) It's possible the callee may want to mess around with an exception handler at an outer level, though that's probably a bad idea *) The callee may want to insert elements onto the control stack of the caller Not *very* good reasons, mind, but... :) Yeah, but at least one of 'em is required in Perl 6 (the 'affect the warnings state of the caller' thing) isn't it? -- Piers
This week's summary
The Perl 6 Summary for the week ending 20030629 Welcome to the third of my US tour Perl 6 summaries. Once again I'm pleased to report that the denizens of the Perl 6 mailing lists continue to make the life of a touring summarizer an easy one by not posting all that much to the lists. So, I can sit here in my room at the Shaker Inn in Enfield and marvel at the traffic noise outside, wonder about the car next door with the New Hampshire plates reading PERLFAN, and just generally appreciate the loveliness of the room. But, while I'm doing that, I should start with perl6-internals Exceptions At the end of last week, Dan outlined his thoughts on how exception handling will work in Parrot. This week, people talked about it. Discussion revolved around how much information should be attached to an exception and how/whether we should support resumable exceptions. http://xrl.us/j73 More on Continuation Passing Last week I said that I get the strong feeling that Leo Tötsch isn't entirely happy with the new Continuation Passing Style. This week Leo corrected me; I hadn't noticed that the speed issues had been addressed by the latest changes to parrot (in fact the current CPS implementation is faster than the old invoke/ret scheme. Sean O'Rourke addressed Leo's problem with the Perl 6 Compiler tests failing by saying that the compiler should really be ported to use CPS rather than implementing a new variant of the Sub PMC that uses the old scheme. Leo reckoned that such a port wasn't currently doable because IMCC needed to be modified to use the CPS scheme, which would also involve reworking the register allocator. Given Leo's prodigious rate of implementation, this may have already happened. http://xrl.us/ktb IMCC/Parrot leak Clinton A. Pierce had reported a memory leak in Parrot, but tracked it down to a situation where he was doing: .arg 0 call _foo And forgetting to take the 0 off the stack. However, even after he'd fixed that, he had segfault issues, and posted a (largish) code fragment that tweaked the bug. It appears that Parrot wasn't throwing warnings when stacks get to big, just failing silently. Leo added a check for too deeply nested stacks, which at least avoids segfaulting on logic bugs. Leo and Dan discussed other places where such limit checking should be put in place. Dan also muttered something about turning stack chunks into PMCs, allowing for the garbage collection of stack frames. Leo also muttered about the proliferation of stack implementations in Parrot (there are five) and thinks it should be possible to have one general stack engine. http://xrl.us/ktc Making + a unary operator Bernhard Schmalhofer found a problem with the Perl 6 implementation. print +42, \n; printed '42', but omitted the carriage return. He fixed this by making + into a unary operator as well as a binary operator and sent the patch to the list, where it was applied. Good catch Bernhard. http://xrl.us/ktd ParrotIO File-Descriptors Jürgen Bömmels is in the process of porting the IO subsystem from its current mem_sys_alloc/free based implementation to the sunny, garbage collected, uplands of a PMC based implementation. However, he's run into a problem; some of the operations in op.ops use integer File Descriptors, grabbing information from a table in the interpreter structure. This gets in the way of garbage collection, since any integer could be a file descriptor. Jürgen proposed removing the integer file descriptors and mandating that ParrotIO PMCs be the only way to access IO (including the standard STDIN, STDOUT and STDERR). He proposed adding get_std[in|out|err] ops to get at the standard streams. Dan suggested that Jürgen Just Do It; the current IO system being more than slightly hackish, it was essentially put in place until something better came along. http://xrl.us/kte Small Perl task for the interested Want to get involved in the Parrot development process? Don't know much about Virtual Machine design and implementation? Do know Perl? Dan has a small but interesting task for you. At present, Parrot gets built without any compiler level optimizations turned on because files like tsq.c can't have any optimizations turned on (tsq.c is the thread safe queue module, which is annoyingly execution-order-dependent because it has to operate safely as interrupt code potentially interrupting itself). Dan would like a version of Configure.pl which can build a makefile (or whatever build tool we end up using) with per-C-file compiler flags, and it needs to be possible to override those flags, per file, by the platform configuration module. Interested? David Robins seems to be, and
Re: This week's summary
Piers Cawley wrote: Small Perl task for the interested Want to get involved in the Parrot development process? Don't know much about Virtual Machine design and implementation? Do know Perl? Dan has a small but interesting task for you. At present, Parrot gets built without any compiler level optimizations turned on because files like tsq.c can't have any optimizations turned on (tsq.c is the thread safe queue module, which is annoyingly execution-order-dependent because it has to operate safely as interrupt code potentially interrupting itself). Dan would like a version of Configure.pl which can build a makefile (or whatever build tool we end up using) with per-C-file compiler flags, and it needs to be possible to override those flags, per file, by the platform configuration module. Hmm, I'm only a lurker, but that looks *very* suspect to me. Some compilers may choose to reorder even without optimization turned on. I'd say that it is a bug in Parrot if it requires optimization to be off for this code - how many different compilers have you tried? -- Alan Burlison --
Re: This week's summary
Alan Burlison wrote in perl.perl6.internals : Piers Cawley wrote: Small Perl task for the interested Want to get involved in the Parrot development process? Don't know much about Virtual Machine design and implementation? Do know Perl? Dan has a small but interesting task for you. At present, Parrot gets built without any compiler level optimizations turned on because files like tsq.c can't have any optimizations turned on (tsq.c is the thread safe queue module, which is annoyingly execution-order-dependent because it has to operate safely as interrupt code potentially interrupting itself). Dan would like a version of Configure.pl which can build a makefile (or whatever build tool we end up using) with per-C-file compiler flags, and it needs to be possible to override those flags, per file, by the platform configuration module. Hmm, I'm only a lurker, but that looks *very* suspect to me. Some compilers may choose to reorder even without optimization turned on. I'd say that it is a bug in Parrot if it requires optimization to be off for this code - how many different compilers have you tried? That doesn't make this per-C-file-cc-option-tweaking necessarily unuseful. Perl 5 uses something similar, because the lexer is sometimes miscompiled when some compilers with a high optimization level. Example : see the hints files and lookup XXX_cflags or toke_cflags in hints/README.hints.
Re: This week's summary
Rafael Garcia-Suarez wrote: Hmm, I'm only a lurker, but that looks *very* suspect to me. Some compilers may choose to reorder even without optimization turned on. I'd say that it is a bug in Parrot if it requires optimization to be off for this code - how many different compilers have you tried? That doesn't make this per-C-file-cc-option-tweaking necessarily unuseful. Perl 5 uses something similar, because the lexer is sometimes miscompiled when some compilers with a high optimization level. Example : see the hints files and lookup XXX_cflags or toke_cflags in hints/README.hints. I'm not saying it isn't useful - per compiler workarounds for brokenness is one thing, but the implication was that this tweakage was needed for *all* compilers for those particular files, which spells 'broken' in my book. If the code makes assumptions about execution order without using the necessary mutexes/cvs to enforce these assumptions, it is very unlikely to work on large SMP machines, for example. -- Alan Burlison --
Re: [perl #22706] IMCC ( Parrot) crash with -t when invoke is run
Clinton Pierce [EMAIL PROTECTED] wrote: I checked in a fix for something that *may* have fixed this, but I'm not sure as I can't test it out at the moment. Try sync'ing up to CVS and giving it another whirl. Still no luck. No luck either in getting a stack trace to the problem. This may just be a quirk in MSVS.NET. I can't get the vcdg (debug) version of the program to run beyond: func(INTERP, SELF); // -- here Strange. Parrot_jit_build_call_func() even does emit a stack frame. Can you single step through it in assembly mode? leo
Re: [perl #22855] [PATCH] build imcc as parrot
Andy Dougherty [EMAIL PROTECTED] wrote: On Mon, 30 Jun 2003, Leopold Toetsch wrote: Attached is a minimum patch to build imcc as the parrot executable languages/imcc/*.o languages/imcc/*.o doesn't match anything Brain dead make? Anyway, this line could for sure be deleted. Apart from that, it built fine and passed all tests with Sun's cc and perl5.00503 on Solaris 8. Fine. Thanks for your feedback. leo
