On Jan-11, Peter Christopher wrote:
Last I checked (which was moments ago) it was either (a)
impossible to, or (b) I couldn't figure out how to, search the parrot
mailing list archive. I.e. I can't search
www.nntp.perl.org/group/perl.perl6.internals
for key words. Could someone
On Dec-01, Dan Sugalski wrote:
C, for example, is weakly typed. That is, while you tell the system
that a variable is one thing or another (an int, or a float), you're
perfectly welcome to treat it as another type. This is *especially*
true of values you get to via pointers. For example,
On Nov-10, Will Coleda via RT wrote:
This is now obsolete, neh?
I hack round this with
$ cp dynclasses/foo.dump .
Alternativley, change line 609 of pmc2c2.pl to read
unshift @include, ., $FindBin::Bin/.., $FindBin::Bin;
adding . to search path
I believe so. I
This doesn't address the deeper problem, but we could also simplify the
whole function by just doing:
static size_t
find_common_mask(size_t val1, size_t val2)
{
size_t mask = ~0;
size_t diff = val1 ^ val2;
while (diff mask)
mask = 1;
return mask;
}
Bit twiddling
This doesn't address the deeper problem, but we could also simplify the
whole function by just doing:
static size_t
find_common_mask(size_t val1, size_t val2)
{
size_t mask = ~0;
size_t diff = val1 ^ val2;
while (diff mask)
mask = 1;
return mask;
}
Bit twiddling
On Oct-17, Dan Sugalski wrote:
At 9:49 AM -0400 10/17/04, Jacques Mony wrote:
Hello,
I'm trying to port parrot to the unununium operating system, which
uses a modified version of 'diet lib c'. Can anyone tell me if this
is actually possible to force the use of this library using the
Perl5 has the notion of contexts, where an expression may behave very
differently in string, boolean, or list context. Perl6 intends to expand
that notion. What if the whole context notion were moved down into
Parrot? Every function call and every MMD dispatch could have an
additional context
Ok, it's in. I did not add the 'cd dynclasses; make' to the default
target; I though I'd see what regular builds I broke first. Testers
wanted, especially on platforms other than darwin and linux.
On Oct-08, Andy Dougherty wrote:
Sorry -- offhand I don't have any sense of any standard names, and I
won't have time till late next week to look at it at all. The most
important thing is to *DOCUMENT CAREFULLY* exactly what the names are and
what they mean.
Whatever names you add,
If I just do
perl Configure.pl
make
right now, it builds the parrot executable ok but then fails when it
tries to compile the library .imc files. It's looking for the icu data
dir in $(prefix)/blib/lib/2.6.1. It works if I do
perl Configure.pl --prefix=$(pwd)
make
or set
I've been struggling with getting Darwin to build the dynclasses/ stuff,
and I seem to have it working now. (Oh, and it fixes the Linux build
too.) It's a fairly large change, and I would like to use standard
naming conventions throughout, but I haven't really found any
convincing, definitive
On Oct-07, Dan Sugalski wrote:
At 9:55 PM +0200 10/7/04, Leopold Toetsch wrote:
Steve Fink [EMAIL PROTECTED] wrote:
Clearly, I'm not very experienced with dealing with these things across
platforms, so I was hoping somebody (Andy?) might have a better sense
for what these things
On Oct-06, Leopold Toetsch wrote:
William Coleda [EMAIL PROTECTED] wrote:
Any chance of getting:
'cd dynclasses; make'
working on OS X by then?
It's broken on Linux too. The problem seems to be that non-existing
shared libs are used for the final perl build.pl copy phase. These
On Oct-06, Leopold Toetsch wrote:
Andy Dougherty [EMAIL PROTECTED] wrote:
There are some changes e.g. when different CFLAGS settings are used, or
for compiling classes. When there is a problem with compiling, just type
another 'make' and you'll get again Compiling with
I think this may
On Oct-05, Andy Dougherty wrote:
The following patch makes compilation both slightly quieter and also
slightly more informative.
Or, with less spin, it fixes bad advice I gave previously. Specifically,
I had previously noted that it's generally helpful if the Makefile prints
out the
On Oct-05, Andy Dougherty wrote:
This patch removes two files that are no longer generated from
MANIFEST.generated.
Thanks, applied.
On Oct-05, Leopold Toetsch wrote:
Wed 6.10. 18:00 GMT - feature freeze
Sat 9.10. 8:00 GMT - code freeze - no checkins please
- Parrot 0.1.1 will go out on Saturday.
- nice release name wanted
0.1.1 - Hydroparrot
0.1.2 - Helioparrot
0.1.3 - Parrolith
0.1.4 - Perylous
0.1.5 - Porn (um...
On Oct-02, Nicholas Clark wrote:
$ make install
/home/nick/Install/bin/perl5.8.4 tools/dev/install_files.pl --buildprefix=
--prefix=/home/nick/Install/parrot --exec-prefix=/home/nick/Install/parrot
--bindir=/home/nick/Install/parrot/bin --libdir=/home/nick/Install/parrot/lib
On Sep-24, Aaron Sherman wrote:
On Fri, 2004-09-24 at 10:03, KJ wrote:
So, my question is, why would one need lexical pads anyway (why are they
there)?
They are there so that variables can be found by name in a lexically
scoped way. One example, in Perl 5, of this need is:
my
On Sep-22, Will Coleda wrote:
ld: /Users/coke/research/parrot/blib/lib/libparrot.dylib is input for the dynamic
link editor, is not relocatable by the static link editor again
compile foo.c failed (256)
As for the next error... huh?
Not surprising. What architecture and linker are you
On Sep-20, Dan Sugalski wrote:
Now, the issue is how to actually build a compiler. Right now a
compiler is a simple thing -- it's a method hanging off the __invoke
vtable slot of the PMC. I'm not sure I like that, as it seems really,
really hackish. Hacks are inevitable, of course, but it
On Sep-17, Matt Diephouse wrote:
Having mentally absorbed the forth.pasm code, I thought I'd rewrite it
in PIR and try to make it a full parrot compiler and, hopefully, a bit
more approachable. I've already begun on this (see attached file).
Unfortunately, I've run into a few issues/questions
On Sep-09, Brent 'Dax' Royal-Gordon wrote:
Tiny nit: for consistency with other Configure source files, this
should probably be named dynclasses_pl.in. No big deal, though.
Consistency is good, and you're the authority. Change committed.
On Sep-09, [EMAIL PROTECTED] wrote:
On Wed, 8 Sep 2004, Chip Salzenberg wrote:
According to [EMAIL PROTECTED]:
So how many stores do we expect for
($a = xxx) =~ s/a/b/g
and which of the possible answers would be more useful?
I think it depends on C($a = aaa) =~ s/a/b/g.
I
On Sep-09, Leopold Toetsch wrote:
Steve Fink (via RT) wrote:
I won't go through all the details of what I looked at (though I'll
post them in my blog eventually), but what's happening is that this
line (from perlhash.pmc's clone() implementation) is corrupting the
flags field
On Sep-07, Leopold Toetsch wrote:
Steve Fink [EMAIL PROTECTED] wrote:
This patch introduces something that feels suspiciously like libtool,
despite the fact that libtool has never been very kind to me. But for
now I am targeting this only at the dynamic PMC generation problem
On Sep-06, Jens Rieks wrote:
Leopold Toetsch wrote:
So first:
- do we keep these opcodes?
If yes some permutations are missing.
- if no,? we should either not include experimental.ops in the default
opcode set or move it to dynops.
I have not used them yet, but I think that they can
On Sep-01, Leopold Toetsch wrote:
Below is a pod document describing some IMHO worthwhile changes. I hope
I didn't miss some issues that could inhibit the implementation.
Overall, I like it, although I'm sure I haven't thought of all of the
repercussions.
The one part that concerns me is the
On Aug-30, Dan Sugalski wrote:
I've been watching this thread with some bemusement -- I've got to
admit, I don't see the problem here.
I'm not sure what the point of passing in parameters to the
compilation is. (Not that I don't see the point of having changeable
settings for compilers,
On Aug-28, Dan Sugalski wrote:
We dynamically load libraries. Whee! Yay, us. We need a set of
semantics defined and an API to go with them so we can meaningfully
and reliably work with them.
Hm. Today I was working with the current implementation of this stuff,
and uncovered a bunch of
On Aug-21, Mattia Barbon wrote:
Hello,
as promised with this patch:
pmc2c2 ... --library foo --c pmc1.pmc pmc2.pmc pmc3.pmc ...
outputs pmcX.c and pmc_pmcX.h as it did before, plus
foo.c and pmc_foo.h containig a single Parrot_lib_foo_load
that initialized vtables and MMD
On Aug-27, Leopold Toetsch wrote:
Steve Fink wrote:
On Aug-26, Leopold Toetsch wrote:
.sub @regex_at_foo_imc_line_4711 # e.g.
Yes, this illustrates what I was really getting at. My compiler can
certainly take a subroutine name (or file and line number, or whatever)
to use to generate
On Aug-22, Leopold Toetsch wrote:
Steve Fink [EMAIL PROTECTED] wrote:
I am experimenting with registering my own compiler for the regex
language, but the usage is confusing. It seems that the intention is
that compilers will return a code object that gets invoked, at which
time it runs
I am experimenting with registering my own compiler for the regex
language, but the usage is confusing. It seems that the intention is
that compilers will return a code object that gets invoked, at which
time it runs until it hits an Cend opcode. But what if I want to
return some values from the
As I prepared to dive into a big area of parrot that I'm completely
unfamiliar with, I decided to log my travels in hopes of helping out
the next poor soul who happens along a similar path.
For now, the focus is on converting my toy languages/regex compiler
into more of a real Perl6-style rule
I don't know what's eating my mail, but evidently the attachment never
made it out. I tracked down this particular problem and fixed it for
the actual case I was using, which was not a PerlHash at all but
rather my own custom Match PMC for use in regexes. The attached patch
resolves the exact
Oh, and while I have my fingers crossed, I may as well throw in the
original test patch as well. I'll let these messages go to hell
together.
Urk! Except I used stupid filenames, and swapped the attachments. So
this attachment is actually the patch. Need more sleep.
? src/py_func.str
Index:
I needed to create a Match PMC object for holding the match groups
(parenthesized expressions and capturing rules) from a regex match.
Unfortunately, it works by using another new PMC type, the MatchRange
PMC, to signal that an element of its hashtable should be interpreted
specially (as a
Oh, and here's my test code for the Match PMC. This is really just a
copy of t/pmc/perlhash.t (since the Match PMC is supposed to behave
like a hash for the most part), but with one added test case at the
end showing how this would be used to store and retrieve
hypotheticals.
Index: t/pmc/match.t
Sorry if this is a repeat, but I didn't get my own mail back, so I
think I may have had sending problems.
On Aug-09, Patrick R. Michaud wrote:
Luke Palmer and I started work on the grammar engine this past week.
It's a wee bit too early in the process for us to be making any
promises about
On Aug-07, Leopold Toetsch wrote:
Sean O'Rourke [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Leopold Toetsch) writes:
The interference_graph size is n_symbols * n_symbols *
sizeof(a_pointer). This might already be too much.
2) There is a note in the source code that the interference
On Jul-04, Jeff 'japhy' Pinyan wrote:
I want to make sure I haven't misunderstood anything. *What* purpose will
my module that will be able to parse Perl 6 regexes into a tree be? You
must be aware that I have no power Damian does not possess, and I cannot
translate *all* Perl 6 regexes to
On Jun-27, Jeff 'japhy' Pinyan wrote:
On Jun 27, Steve Fink said:
On Jun-26, Jeff 'japhy' Pinyan wrote:
I am currently completing work on an extensible regex-specific parsing
module, Regexp::Parser. It should appear on CPAN by early July (hopefully
under my *new* CPAN ID JAPHY
On Jun-26, Jeff 'japhy' Pinyan wrote:
I am currently completing work on an extensible regex-specific parsing
module, Regexp::Parser. It should appear on CPAN by early July (hopefully
under my *new* CPAN ID JAPHY).
Once it is completed, I will be starting work on writing a subclass that
On Jun-16, Dan Sugalski wrote:
At 8:24 PM +0200 6/16/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
I'm wondering if it'd be useful enough to be worthwhile to have
non-flowcontrol min/max ops. Something like:
min P1, P2, P3
max P1, P2, P3
Which cmp
On May-30, Leopold Toetsch wrote:
Steve Fink [EMAIL PROTECTED] wrote:
Anyone mind if I commit this?
The patch is fine.
... One thing I'm not sure of, though -- I
try to behave myself and use Parrot_getenv rather than a plain
getenv(), but I'm not convinced the API is complete
The Perl6 compiler often appends on array onto another. Right now, it
does this by iterating over the source array. I would like to just use
the Csplice op, but I am now getting a mixture of PerlArrays (from
Perl6) and Arrays (from Cfoldup), and the Csplice vtable entry
only works if the types of
On May-31, Nicholas Clark wrote:
On Sat, May 29, 2004 at 11:03:12PM -0700, Steve Fink wrote:
+/* DEFAULT_ICU_DATA_DIR is configured at build time, or it may be
+ set through the $ICU_DATA_DIR environment variable. Need a way
+ to specify this via the command line as well
Anyone mind if I commit this? One thing I'm not sure of, though -- I
try to behave myself and use Parrot_getenv rather than a plain
getenv(), but I'm not convinced the API is complete -- Parrot_getenv
saves back a boolean saying whether to free the returned string or
not, but what should I call to
On May-29, Brent 'Dax' Royal-Gordon wrote:
William Coleda wrote:
=head2 How do I generate a sub call with a variable-length parameter
list in PIR?
This is currently not trivial.
...
=head2 How do I retrieve the contents of a variable-length parameter
list being passed to me?
The
On May-25, Dan Sugalski wrote:
At 10:31 AM +0200 5/25/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
An unsolicited event, on the other hand, is one that parrot generates
as the result of something happening external to itself, or as the
result of some recurring event
On May-15, Jeff Clites wrote:
When linking against (using) a static library version of ICU, we need
a C++-aware linker (because ICU contains C++ code); with a
dynamic-library version of ICU presumably we wouldn't.
I don't know if this applies here, but there is a good reason to use a
On May-10, Joseph Ryan wrote:
The Parse::RecDescent in parrot/lib is a hacked version that removes
a bunch of stuff (tracing code, iirc) from the outputted grammer so
that it runs many orders faster than the regular version. Or, to
put it another way, it increases P6C's runspeed from
Top-down and bottom-up are not mutually exclusive. At least not
completely. But self-modifying parsers are *much* easier to do with
top-down than bottom-up, because the whole point of bottom-up is that
you can analyze the grammar at compile (parser generation) time, and
propagate the knowledge
On May-09, Abhijit A. Mahabal wrote:
On Sat, 8 May 2004, Abhijit A. Mahabal wrote:
I was writing a few tests for the P6 parser and ran into a weird problem.
If I have the following in a file in languages/perl6, it works as
expected:
[...]
Now, if I put exactly the same contents in
On May-09, Allison Randal wrote:
BTW, should I keep working on P6C? As A12 has just come out P6C may be
heavily under construction, and I don't want to be in the way...
Please do. I'm working on a first rough implementation of classes, but
it shouldn't interfere with general patches.
I am
On Apr-24, Leopold Toetsch wrote:
I've extended the config system by CPU specific functionality:
- new config step config/gen/cpu.pl is run after jit.pl
- this step probes for config/gen/cpu/$cpu/auto.pl and runs it if present
For i386 we have:
- a new tool as2c.pl, which creates hopefully
On Apr-21, Leopold Toetsch wrote:
Is IntList used outside of some tests?
Can we rename it to IntvalArray?
Yes, it is used in the languages/regex compiler (at least when
embedded in Perl6, but IIRC in all cases.)
But yes, go ahead and rename it.
On Apr-14, Jeff Clites wrote:
For Unix platforms at least, you should be able to do this:
executablePath = isAbsolute($0) ? dirname($0) : cwd().dirname($0)
Nope.
sub executablePath {
return dirname($0) if isAbsolute($0);
return cwd().dirname($0) if hasSlash($0);
foreach
On Mar-26, Dan Sugalski wrote:
The VS/.NET build works fine, though three of the tests fail for odd
reasons. Those look like potential test harness errors.
The cygwin build sorta kinda works OK, but the link fails because of
a missing _inet_pton. I seem to remember this cropping up in the
On Mar-24, Dan Sugalski wrote:
At 12:36 PM +1100 3/24/04, [EMAIL PROTECTED] wrote:
On 24/03/2004, at 6:38 AM, Dan Sugalski wrote:
This is a question without a simple answer, but does Parrot provide
an infrastructure so that it would be possible to have
proof-carrying[1] Parrot bytecode?
On Mar-12, Leopold Toetsch wrote:
Steve Fink [EMAIL PROTECTED] wrote:
The attached patch should remove all of the conflicts, and replace
them with a single shift/reduce conflict that appears to be a bug in
the actual grammar, namely:
x = x . x
Ah yes. Or course, Thanks a lot
On Mar-13, Luke Palmer wrote:
luka frelih writes:
But how should the two interpretations of x.x be resolved? Is that
concatenation or method calling?
currently, the pir line
S5 = S5 . 'foo'
produces
error:imcc:object isn't a PMC
concatenation with . seems to be gone
On Mar-11, Leopold Toetsch wrote:
Jens Rieks [EMAIL PROTECTED] wrote:
attached is a patch to t/pmc/object-meths.t that adds a test that is
currently failing because IMCC rejects code like self.blah()
Yep. It produces reduce/reduce conflicts. Something's wrong with
precedence. I'd be
On Mar-12, Dan Sugalski wrote:
At 9:49 AM +0100 3/12/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
Calling a method:
object.variable(pararms)
Do we need the more explicit pcc_call syntax too:
.pcc_begin
.arg x
.meth_call PObj, (meth | PMeth ) [, PReturnContinuation ]
.
.
.
P docs/pmc/subs.pod
cvs server: internal error: unsupported substitution string -kCOPY
U docs/resources/parrot.small.png
U docs/resources/perl-styles.css
cvs server: internal error: unsupported substitution string -kCOPY
U docs/resources/up.gif
.
.
.
Should those perhaps be -kb
On Feb-19, Dan Sugalski wrote:
At 7:30 PM -0500 2/18/04, Simon Glover wrote:
One really pedantic comment: wouldn't it make sense to rename the
fetchmethod op to fetchmeth, for consistency with callmeth, tailcallmeth
etc?
Good point. I'll change that, then.
D yo reall wan t repea C's
On Feb-02, Andrew Dougherty wrote:
[EMAIL PROTECTED] 19184 languages/perl6/t/rx/call test error
1 years
Keep this one open. The tests still fail.
How recently did you check? I committed a reimplementation of perl6
regexes about a
Here's another obnoxious test case. I started to try to strip it down,
but it starts working again if I even delete nonsense lines from a
subroutine that is never called. And I'm working on something else and
not at all in the mood to re-learn how to debug parrot internals. It
turns out that I
On Jan-15, Melvin Smith wrote:
At 11:20 AM 1/15/2004 +0100, Leopold Toetsch wrote:
Melvin Smith [EMAIL PROTECTED] wrote:
For some reason 1 test in pcc.t is failing (the nci call)
Off by one error caused by:
-for (j = 0; j 4; j++) {
+for (set = 0; set
I did a cvs update, and it looks like imcc doesn't properly return
integers anymore from nonprototyped routines. Or maybe it never did,
and the switchover from nonprototype being the default to prototyped
is what triggered it (because I had to add some explicit
non_prototyped declarations,
On Dec-02, Melvin Smith wrote:
1) Currently typenames are not checked except with 'new classname'
I would vote for no aliases at all. I propagated the existing uses of
.local object in the Perl6 compiler and introduced several more
uses, but that was only because I wasn't sure at the time
I'm staring at a crash, my eyes are glazing over, and I need sleep. So
I was wondering if anyone would be interested in taking a look at a
.imc file that is giving me a seg fault while marking a hash in a gc
run triggered by a hash PMC allocation. Or at least tell me whether
it's seg faulting on
On Nov-21, Leopold Toetsch wrote:
Steve Fink [EMAIL PROTECTED] wrote:
I'm staring at a crash
I'll attach the 5KB compressed .imc file (25KB uncompressed; PIR code
Its really good, to have such short code snippets, that clearly show,
where a bug is coming from ;) Anyway, it was again me
On Nov-21, Dan Sugalski wrote:
I was mostly thinking that some step or other in the Makefile has a
dependency on that file, and some other step creates it, but the
dependency's not explicit. I'd like to find the step(s) that require it
and make it a dependency for them, then add in a
I'm getting a little confused about what we're arguing about. I will
take a stab at describing the playing field, so people can correct me
where I'm wrong:
Nonprototyped functions: these are simpler. The only point of
contention here is whether args should be passed in P5..P15,
overflowing into
On Nov-12, Leopold Toetsch wrote:
I've committed a change that speeds up hash_compare considerably[1],
when comparing hashes with mixed e.g. ascii and utf8 encodings.
I read the patch, and thought that we'll also have a lot of ($x eq $y)
and ($x ne $y) statements that this won't accelerate --
On Oct-26, Melvin Smith wrote:
At 06:25 PM 10/26/2003 -0800, Steve Fink wrote:
.pcc_sub _main prototyped
.pcc_begin_return
.return 10
.return 20
.pcc_end_return
.end
It is still the same issue. This code explicitly mixes 2 call conventions
On Oct-27, Leopold Toetsch wrote:
Arthur Bergman [EMAIL PROTECTED] wrote:
include/parrot/pobj.h:# define version obj.version
Sorry for that :) We can AFAIK toss the version part of a PObj. Its
almost unused and hardly needed. It could be renamed too inside parrot.
I'm the guilty one who
I am getting a seg fault when doing a very simple subroutine call with
IMCC:
.sub _main
newsub $P4, .Sub, _two_of
$P6 = new PerlHash
.pcc_begin prototyped
.arg $P6
.arg 14
.pcc_call $P4
after:
.pcc_end
On Oct-26, Leopold Toetsch wrote:
Steve Fink [EMAIL PROTECTED] wrote:
I am getting a seg fault when doing a very simple subroutine call with
IMCC:
.sub _main
newsub $P4, .Sub, _two_of
$P6 = new PerlHash
.pcc_begin prototyped
On Oct-26, Leopold Toetsch wrote:
Steve Fink [EMAIL PROTECTED] wrote:
I am getting a seg fault when doing a very simple subroutine call with
IMCC:
.sub _main
newsub $P4, .Sub, _two_of
$P6 = new PerlHash
.pcc_begin prototyped
On Oct-15, Adam Thomason wrote:
# New Ticket Created by Adam Thomason
# Please include the string: [perl #24226]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=24226
IBM VisualAge C 6 complains about some
For those of you not on the CVS list, I just committed a rather large
change to the perl6 compiler that implements a subset of the A6
subroutine signature rules. My implementation is rather ad-hoc, but it
is a decent representation of my slowly evolving understanding of how
this stuff's supposed
On Oct-10, Melvin Smith wrote:
At 08:31 AM 10/10/2003 -0400, Dan Sugalski wrote:
I think it's time to start thinking about it. (And I think we need a new
name, but that's because I've always hated 'ioctl' :)
:)
I also considered iocmd, ioattr and ioset.
IPop your favorite into the
On Oct-11, Melvin Smith wrote:
At 09:19 AM 10/11/2003 -0700, Steve Fink wrote:
On Oct-10, Melvin Smith wrote:
At 08:31 AM 10/10/2003 -0400, Dan Sugalski wrote:
I think it's time to start thinking about it. (And I think we need a new
name, but that's because I've always hated 'ioctl
Ok, I'm back to argument passing. I'm starting a new thread because
I'm lazy and I have to scroll back too far in my mailer to see the old
arg passing thread. :-) And yes, most of this message should also be
on -languages.
Could somebody tell me where I go wrong:
If you have a prototype
sub f
On Oct-05, Luke Palmer wrote:
Steve Fink writes:
Ok, I'm back to argument passing. I'm starting a new thread because
I'm lazy and I have to scroll back too far in my mailer to see the old
arg passing thread. :-) And yes, most of this message should also be
on -languages.
Which it now
On Sep-26, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
[ splatted function args ]
... For this, I think we're
going to need a setp Ix, Py op which does indirect register addressing.
Done.
Cool, thanks!
With it, I've been able to get a bit farther. Found a minor bug
On Sep-28, Leopold Toetsch wrote:
Steve Fink [EMAIL PROTECTED] wrote:
I'm not sure IMCC is going to be able to autogenerate the prototyped
and nonprototyped versions of the callee's entry code from the same
set of .param declarations.
This is currently implemented as the unprototyped
I am getting strange behavior from IMCC if the first line after
.pcc_sub is a comment. It seems to misinterpret things and ends up
emitting a restore_p op that triggers a No entries on UserStack!
exception.
I've attached a diff to languages/imcc/t/syn/pcc.t, but I'm not sure
if that's the right
On Sep-28, Steve Fink wrote:
I've attached a diff to languages/imcc/t/syn/pcc.t, but I'm not sure
if that's the right place for the test.
Oops. Except CVS is being very flaky right now, so the patch hadn't
been written to the file before I sent it.
Oh well. I'm committing a fix for the bug
On Sep-26, Leopold Toetsch wrote:
Filtering the output through a small
script, that just does something like:
if ($_ !~ /^cvs server: Updating/) {
print $_;
}
helps to unclutter update results.
cvs -q will suppress those lines for you.
Ah, I reread one of your earlier posts. It appears that you are
proposing to pass the arguments in a PerlArray. So flattening is
possible.
Then what I am saying is that
sub f($a,$b) { ... }
is going to expect $a to be in P5 and $b to by in P6. In your scheme,
$a would be in P5[0] and $b would
On Sep-24, Leopold Toetsch wrote:
No. But you are right. That's the code (/s\$I2/\$I1/) that .args
should produce. Perhaps we shoud name the directive .flatten_arg.
Yes, that makes its purpose more clear than calling it .args.
Is it supposed to do deep flattening? Do we need
On Sep-22, Leopold Toetsch wrote:
Steve Fink [EMAIL PROTECTED] wrote:
Then we need code from HLL to see, how efficient (or not) parameter
passing does look like.
I've been trying to implement A6 for languages/perl6. My first cut was
to have all calls, prototyped or not, take three
On Sep-23, Leopold Toetsch wrote:
Steve Fink [EMAIL PROTECTED] wrote:
Just to be sure we're talking about the same thing:
sub f ($a, $b, $c) { ... }
$x = phase_of_moon('waxing') ? \f : \CORE::print;
$x-(3, [EMAIL PROTECTED], [EMAIL PROTECTED]);
I don't expect such contrived
On Sep-21, Leopold Toetsch wrote:
Steve Fink [EMAIL PROTECTED] wrote:
That would make it fun to track register usage.
And here is the problem with all these shortcuts.
But any one of these instructions could be treated by IMCC as
potentially reading from and writing to all PMC registers
On Sep-21, Gregor N. Purdy wrote:
Nick --
Looks like I'm the guilty party. I do tend to do this
every now and again, even though I don't consider myself
thoughtless or careless.
I think sometimes I get focused on my local changes and
as I'm testing and committing it just isn't natural to
On Sep-21, Gerrit P. Haase wrote:
Hallo again,
http://cpan.perl.org/authors/id/S/SF/SFINK/parrot-0.0.11.1.tar.gz
And all we need now is a 0.0.11.2, with patches to allow four-element
version numbers...
[...]
Ouch, better take this:
$ diff -urd parrot-0.0.11.1/VERSION~
1 - 100 of 552 matches
Mail list logo