At 11:22 AM 8/9/2004 -0400, Dan Sugalski wrote:
At 1:13 PM +0200 8/8/04, Leopold Toetsch wrote:
Leopold Toetsch [EMAIL PROTECTED] wrote:
You can verify this step by running -v:
$ parrot -v inv_mod.imc 21 | grep symb
build_reglist: 5783 symbols
allocate_non_interfering, now: 2205 symbols
It really
At 10:54 AM 8/7/2004 -0400, Dan Sugalski wrote:
At 12:45 PM +0200 8/7/04, 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
At 05:13 PM 8/3/2004 -0700, Gregor N. Purdy wrote:
Did I miss the creation of the compiler-writer list? I need to figure
No, we are still holding our breath (and turning blue, purple, green, ...)
Btw, I'll poke the Cola rewrite I have here and see where it stands. It
gathered a bit of dust in the
At 08:57 AM 3/19/2004 +0100, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
At 10:38 PM +0100 3/18/04, Leopold Toetsch wrote:
Which brings up again my warnocked question: How can return
continuations get reused?
Works like this. (No pasm, but it should be obvious)
I was aware of
At 02:42 PM 3/13/2004 -0800, Steve Fink wrote:
currently, the pir line
S5 = S5 . 'foo'
produces
error:imcc:object isn't a PMC
concatenation with . seems to be gone
i cannot think of a good replacement for it
This should be fixable with some lexer or parser tweaking.
Well,
At 03:52 PM 3/9/2004 -0800, Edward S. Peschko wrote:
On Tue, Mar 09, 2004 at 04:21:24PM -0500, Gordon Henriksen wrote:
Not an opcode doesn't mean balkanized. There is a parrot/stdlib
directory.
fair enough, but then where does the distinction lie? Why put gmtime, et al.
in opcodes? As well as
Hi Brent,
Welcome back to p6i. ;)
At 08:12 PM 3/9/2004 -0800, Brent \Dax\ Royal-Gordon wrote:
On a platform with a halfway decent JIT, a pure-PASM implementation
could be as fast as an op-based one, given liberal use of the non-PMC
Agree.
Besides, how fast does your date handling really need to
At 11:37 AM 3/3/2004 -0500, Dan Sugalski wrote:
I'm torn here as to what to do. On the one hand, it's supremely tempting
to punt and not have parrot do a darned thing with the time and leave it
to library code to handle it. On the other, CPAN is littered with the
carcasses of time and date
At 08:01 PM 2/28/2004 -0800, Gregor N. Purdy wrote:
I made the change, and now I get consistent results. I'll check that in.
I am still not clear, though, on why we wouldn't have the same failure
in all cases. I'd think these should be equivalent:
* Running parrot on 'foo.imc'
* Running
At 03:56 PM 2/24/2004 -0500, Andrew Dougherty wrote:
On Tue, 24 Feb 2004, Jarkko Hietaniemi wrote:
PackFile_unpack: Not a Parrot PackFile!
Magic number was [0x4c524550] not [0x013155a1]
Parrot VM: Can't unpack packfile t/native_pbc/integer_1.pbc.
error:imcc:main: Packfile loading failed
That
At 10:29 AM 2/23/2004 -0500, Dan Sugalski wrote:
So, the question--shall we do objects and maybe miss the Feb 29th release,
or do the Feb 29th release and do objects for the next release? As I think
I'm only a little while off (maybe a day or so) from getting it working,
I'm tempted to take a
At 05:09 PM 2/23/2004 +0100, Leopold Toetsch wrote:
WRT feature freeze: I'd say: Starting from Tue, 24th 8.00 GMT no more
feature patches *should* go in, *except* objects.
Basically that means: everyone will get really quiet and we will all watch
Dan. :)
-Melvin
At 09:27 AM 2/19/2004 -0800, Goplat wrote:
--- Dan Sugalski [EMAIL PROTECTED] wrote:
At 12:40 AM +0300 2/18/04, Vladimir Lipsky wrote:
From: Goplat [EMAIL PROTECTED]
--- Vladimir Lipsky [EMAIL PROTECTED] wrote:
From: Goplat [EMAIL PROTECTED]
flags_to_win32 sets fdwShareMode to
At 10:02 AM 2/19/2004 -0800, Goplat wrote:
--- Melvin Smith [EMAIL PROTECTED] wrote:
Where is the hassle? It's just a few lines of code to check windows
version. It's easier to code that than to make another configure option.
Then submit a patch.
Okay. (attached)
Very good, thank you sir. I
At 01:34 PM 2/19/2004 -0500, Dan Sugalski wrote:
At 10:21 AM -0800 2/19/04, Steve Fink wrote:
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
At 11:57 AM 2/19/2004 -0800, Goplat wrote:
Failed Test Stat Wstat Total Fail Failed List of Failed
imcc/t/syn/file.t1 256121 8.33% 11
t/pmc/env.t 3 768 63 50.00% 3 5-6
At 04:07 AM 2/20/2004 +0100, Jens Rieks wrote:
Hi all,
here is a first alpha version of my upcoming tetris example for parrot. It is
a good demonstration that parrot is already very powerful.
Very cool. Great work.
Assembling the sources to a single tetris.pasm seems to not work,
parrot
At 10:26 AM 2/12/2004 -0500, Andrew Dougherty wrote:
A fresh checkout of parrot won't build for me due to the missing
inet_aton symbol on Solaris 8. My perl5 configuration correctly
records $Config{d_inetaton}=undef, but io_unix.o unconditionally
expects inet_aton.
cc -o parrot -L/usr/local/lib
At 05:16 PM 2/12/2004 +0100, Leopold Toetsch wrote:
Melvin Smith [EMAIL PROTECTED] wrote:
I'm not sure why Leo changed it, but I'll put it back.
I'm not sure either ;) Must have been in one of the cleanup or such
patches, I had put in.
Sorry,
No problem. I haven't really taken a survey of which
RFD = Request For Discussion ;)
Much discussion has been made on IRC concerning
symbol names.
The request, mainly, is for imcc to handle sigil characters
from other languages which basically equates to exposing
a lot to imcc from the high-level language. I won't
argue how much of that is good or
At 07:26 PM 2/5/2004 -0500, Will Coleda wrote:
Melvin:
Here's a warnocked imcc issue for you:
int main () {
int if = 1;
if (if) {
if = 0;
}
}
do you have a patch? I think its a nice to have so If you sourself
provide a nice patch guess it would be applied :)
I thought I replied to this
At 02:00 PM 2/9/2004 -0500, Michal Wallace wrote:
On Mon, 9 Feb 2004, Melvin Smith wrote:
My take on it is, since it is an intermediate language, we don't need
ability to have keywords as variables. Compilers can generate all
variables with names like $T01JHGJ_001
That can make it kind of nasty
Hopefully this makes it to p6i list this week.
It seems with the recent worm activity, some ISPs
have locked down mail servers even more.
I have replied to several personal emails (WRT Parrot)
and they are bouncing for various reasons, one of
which is because my new ISP is on the DUL blacklist,
At 11:45 PM 1/28/2004 -0500, Gordon Henriksen wrote:
On Wednesday, January 28, 2004, at 12:53 , Melvin Smith wrote:
At 12:27 PM 1/23/2004 -0800, Damien Neil wrote:
Java Collections are a standard Java library of common data structures
such as arrays and hashes. Collections are not synchronized
At 11:56 AM 1/19/2004 -0500, Will Coleda wrote:
Trying to get the tcl interpreter working with all the changes in the past
few months:
I used to be able to say:
.pcc_sub _dumper prototyped
.param PMC original
... but now PMC isn't a valid type anymore. Is there another way to get an
IMC
To
At 03:16 PM 1/19/2004 -0700, Luke Palmer wrote:
Will Coleda writes:
I didn't expect the code to be very usable, merely compilable. =-)
If I want to call myself from myself, how do I do that then?
For anything else, I do:
.local Sub foo_sub
newsub foo_sub, .Sub, __foo
.pcc_begin
I'm freezing imcc as version 1 except for bug fixes.
I'm working on fixing the PCC code emitter before
freezing it.
Besides the bugs concerning non-scalability of the register
allocator, I'm interested in any bug reports (for IMCC only) that may
have been Warnocked until now.
I'd like to get imcc1
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 REGSET_MAX; set++) {
As most loops
At 11:05 AM 1/15/2004 +0100, Leopold Toetsch wrote:
Melvin Smith wrote:
Feel free to checkout branch imcc1final to test with.
The command should be:
cvs checkout -r imcc1final parrot
Could you be a bit more verbose about that. I've now checked out the branch
I would not checkout the branch
At 10:28 AM 1/15/2004 +, you wrote:
On Thu, Jan 15, 2004 at 02:21:56AM -0500, Melvin Smith wrote:
I'd like to get imcc1 working as correct as possible and frozen
within a couple of weeks, then I'll start on the really major rework
for imcc2 (including all the deprecation that is going
At 04:17 PM 1/15/2004 +, Jonathan Worthington wrote:
From: Melvin Smith [EMAIL PROTECTED]
I'd like to get imcc1 working as correct as possible and frozen
within a couple of weeks, then I'll start on the really major rework
for imcc2 (including all the deprecation that is going to make
At 10:27 AM 1/15/2004 -0500, Melvin Smith wrote:
At 11:05 AM 1/15/2004 +0100, Leopold Toetsch wrote:
Melvin Smith wrote:
Feel free to checkout branch imcc1final to test with.
The command should be:
cvs checkout -r imcc1final parrot
Could you be a bit more verbose about that. I've now checked out
At 01:08 PM 1/15/2004 -0500, Dan Sugalski wrote:
At 11:05 AM +0100 1/15/04, Leopold Toetsch wrote:
Melvin Smith wrote:
Feel free to checkout branch imcc1final to test with.
Could you be a bit more verbose about that. I've now checked out the
branch imcc1final, which switched the whole tree
While sitting on IRC with Dan and Jonathan discussing how to
optimizer a certain construct with how we handle globals/package
variables, etc. I came to the conclusion that it would be valuable
to not have to fetch each and every global, lexical or package
variable by name, individually, but
At 10:02 PM 1/15/2004 +0100, Elizabeth Mattijsen wrote:
At 15:51 -0500 1/15/04, Melvin Smith wrote:
IMCC could analyze a module, decide if the optimization makes
sense, and place commonly used values (constants or
variables) in a pre-packaged register frame. (or more than 1)
This is done
At 06:13 PM 1/15/2004 -0500, Melvin Smith wrote:
At 10:02 PM 1/15/2004 +0100, Elizabeth Mattijsen wrote:
At 15:51 -0500 1/15/04, Melvin Smith wrote:
Comments questions welcome.
Why am I thinking of the register keyword in C?
I have no idea and I can't see the relationship. :)
I just realized my
At 04:26 PM 1/15/2004 -0700, Luke Palmer wrote:
Melvin Smith writes:
My email was concerned with storing/retrieving multiple variables
with a single lookup, not with hinting to the compiler.
Okay. Can you show an example of this optimization. I'd rather see it
in a HLL talking about PIR
At 11:18 PM 1/12/2004 -0500, Michal Wallace wrote:
On Mon, 12 Jan 2004, Luke Palmer wrote:
A continuation is one snapshot -- it never changes, it never runs.
To invoke the continuation is to take you back to that snapshot and
start running from there. To invoke it a second time is exactly
At 09:55 PM 1/12/2004 +0100, Stéphane Payrard wrote:
On Mon, Jan 12, 2004 at 03:16:50PM -0500, Dan Sugalski wrote:
Which brings up a question. What's the difference between .local and .sym?
--
Currently, there is none. So I went for the shortest:
grep -n -e LOCAL imcc.l
imcc.l:181:.sym
At 08:58 AM 1/9/2004 +0100, Leopold Toetsch wrote:
Melvin Smith [EMAIL PROTECTED] wrote:
This also means .pasm files won't be able to .include these anymore,
you'd have to use IMC.
Why not just make .const work in both modes?
Because pure PASM doesn't currently use type names.
.const expects
At 09:01 AM 1/9/2004 +0100, Leopold Toetsch wrote:
Melvin Smith [EMAIL PROTECTED] wrote:
IMCC macros are gone. Volunteers feel free to reimplement a
pre-processor (outside of IMCC) using the macro expansion code
that was removed from IMCC.
Melvin, that's not the way to go. We can remove
:)
At 08:44 PM 1/9/2004 +, Harry Jackson wrote:
Melvin Smith wrote:
But, if you want macros to stay, let them stay.
So, are they staying, staying for now or not sure yet? I have a few
hundred lines of imcc that uses macros and if they are being removed then
I would rather change now and save
At 07:36 PM 1/9/2004 +0100, Leopold Toetsch wrote:
Melvin Smith [EMAIL PROTECTED] wrote:
At 09:01 AM 1/9/2004 +0100, Leopold Toetsch wrote:
Which is why I hoped people would pitch in and help fix the tests.
Its not tests only. There's already production code out there using
Parrot - ask Dan
As planned, macros have been removed from IMCC.
The downside is that this just revealed scads of instances
where people were using macro expansion in the tests,
especially the .constant directive.
One particular problem is runtime/parrot/include/*.pasm
These will need to be changed to .imc files
Since all of the Parrot includes are .pasm and are using the old .constant
directive, which was a macro expansion in the IMCC lexer, and
I've removed macros from IMCC, I have a pending patch to
parrot_include.pl and all of the parrot header files to change it to generate
.imc include files rather
At 06:37 PM 1/7/2004 -0700, Luke Palmer wrote:
Leopold Toetsch writes:
Jeff Clites [EMAIL PROTECTED] wrote:
On Jan 7, 2004, at 1:46 AM, Leopold Toetsch wrote:
That part is already answered: create a buffer_like structure.
*But* again register backing stacks are *not* in the interpreter
At 07:53 AM 1/6/2004 -0700, Luke Palmer wrote:
Aren't continuations supposed to close over the register stacks? In
this code:
I should hope to get 42, but instead I get no more I frames to pop.
They're not very good continuations if you have to treat them just like
an address stack!
Currently the
At 10:59 AM 1/5/2004 -0500, Dan Sugalski wrote:
Optimized for speed, at least.
I'm finding that large subs seem to give imcc headaches. I'm not sure if
it's O(n^2) or O(2^n) headaches, but definitely issues. At the moment I've
got parrot churning on some pir code and it's taking quite a while.
At 07:55 PM 1/5/2004 +0100, Lars Balker Rasmussen wrote:
The Perl 6 Summarizer [EMAIL PROTECTED] writes:
people's salaries will depend on Parrot. I confess I wouldn't be
surprised if, by the end of the year, we haven't seen the full
implementation of at least one of the big non-Perl
At 09:30 PM 1/5/2004 +, Piers Cawley wrote:
Melvin Smith [EMAIL PROTECTED] writes:
At 07:55 PM 1/5/2004 +0100, Lars Balker Rasmussen wrote:
The Perl 6 Summarizer [EMAIL PROTECTED] writes:
people's salaries will depend on Parrot. I confess I wouldn't be
surprised if, by the end
At 07:38 PM 12/28/2003 -0500, Dan Sugalski wrote:
At 7:19 PM -0500 12/28/03, Matt Fowles wrote:
Dan Sugalski wrote:
At 3:27 PM -0500 12/28/03, Matt Fowles wrote:
Leopold Toetsch wrote:
I'd use a custom hash with the PMC address being the key[1]. /Me
thinks, it
doesn't help, when a PMC gets
At 05:45 PM 12/30/2003 +0100, Bernhard Schmalhofer wrote:
Hi,
I have been playing around with 'libpcre' for Parrot m4.
For some reason I couldn't compile two regular expressions in the same
PIR script.
I created a sample C program and that worked like it should.
It looks like the error has
At 12:27 PM 12/30/2003 -0500, Dan Sugalski wrote:
IMCC bus errors (at least on OS X) when presented with the construct:
set $P0[$I1], Params[$I1]
This little test program triggers it for me:
.sub _MAIN prototyped
.local Array Foo
.local Array Bar
set Foo[1], Bar[1]
.end
IMCC also
At 10:07 AM 12/23/2003 +0100, Elizabeth Mattijsen wrote:
I think I agree with you in spirit, that we should have high expectations
for Parrot and hopefully make the scripting
languages that we are running more realistic as all-around programming
languages.
Eh, I think you should cross out the
At 11:02 AM 12/22/2003 -0700, Cory Spencer wrote:
The program I'm writing is passing a ParrotIO object about to various
functions (the ParrotIO object being either stdin or a file handle to a
regular file). Each function can read as many bytes as it likes from the
descriptor. There are times,
At 11:59 PM 12/22/2003 +0100, Elizabeth Mattijsen wrote:
At 14:14 -0500 12/22/03, Dan Sugalski wrote:
At 1:49 PM -0500 12/22/03, Josh Wilmes wrote:
I think it might be good to get started on regretting that as soon as
possible ;-)
Still, at the moment, so far as I can tell, most perl, python, and
At 10:42 PM 12/17/2003 +0100, Leopold Toetsch wrote:
While playing with calling threaded subs, I came along a thing which I
think might be suboptimal:
pdd03 states that the method PMC should go into P2. This doesn't really
play with Perl5 - Perl6 interoperbility IMHO. Perl5 methods are plain
At 02:00 PM 12/12/2003 -0700, Cory Spencer wrote:
Can anyone tell me why the following code:
.sub _main
.local PerlUndef val
val = new PerlUndef
_foo(bar, val)
end
.end
.sub _foo
.param string v1
.param pmc v2
.pcc_begin_return
At 11:57 AM 12/11/2003 -0500, Dan Sugalski wrote:
That does, though, argue that we need to revisit the global access
opcodes. If we're going hierarchic, and we want to separate out the name
from the namespace, that would seem to argue that we'd want it to look like:
find_global P1,
I think a heirarchy is a good idea for namespacing in general. I've
always wanted to be able to tie namespaces in Perl 5. It would only
make sense that if I tie Foo::, that Foo::anything:: would also go
through that tie to get the anything:: stash.
What do you mean by tie here? Are you talking
At 06:06 PM 12/11/2003 -0500, Dan Sugalski wrote:
Folks,
As IMCC's in some flux and likely to get gutted and reworked, the question
of macros has come up. (They cause some grammar issues) So, to make life
easier:
Parrot's built-in PIR and PASM parsing modules do *not* need to do macros.
At 01:37 AM 12/10/2003 -0700, Luke Palmer wrote:
Dan Sugalski writes:
At 05:14 PM 12/5/2003 +0100, Leopold Toetsch wrote:
set I2, P1[Foo\x00i] # I1 == I2
gets currently the attribute idx (0) of $Foo::i.
Q: Should the assembler mangle the Foo::i to Foo\0i
I don't like it either, but
At 12:16 PM 12/10/2003 +, Tim Bunce wrote:
*{Foo\0Bar\0Baz}-{var};
or
*{Foo\0Bar\0Baz\0var};
[snip]
I think Dan was proposing the first and that's fine.
I think the second would be a mistake.
Using a character that won't collide with HLL has a disadvantage
in the general
At 11:34 AM 12/10/2003 -0600, Robert Eaglestone wrote:
Quoth Melvin Smith:
It be a bit friendlier to make the scope resolution operator something
^^ ACK
that at least 1 or 2 languages use as their own already; then all the rest
still have to mangle.
Uh oh, time to vote?
Voting
At 11:52 AM 12/9/2003 -0500, Dan Sugalski wrote:
may not branch to OK. (There's no requirement that high-level
comparisons require a PMC to be equal to itself)
Although committing such a confusing PMC to Parrot is certainly questionable.
-Melvin
At 04:20 PM 12/9/2003 -0500, Dan Sugalski wrote:
Just ran across a bug in IMCC.
The .const directive is incorrectly available only within a .sub/.end
block. Silly. (And wrong) That makes it very difficult to usefully use
constants--generally they're defined at the top of a file (or in a file
At 10:04 PM 12/9/2003 -0500, Melvin Smith wrote:
AWhen someone gets a chance to patch this one up, I'd much appreciate it.
Fixed.
Parser will not allow .const outside of a compilation unit and make it
global to the
compilation. .const inside a .sub will be local to the sub only (no change
At 07:58 AM 12/10/2003 +0300, Vladimir Lipsky wrote:
From: Melvin Smith [EMAIL PROTECTED]
At 04:20 PM 12/9/2003 -0500, Dan Sugalski wrote:
which is .included) and visible through the rest of the compilation unit.
Parser will not allow .const outside of a compilation unit and make it
global
At 05:14 PM 12/5/2003 +0100, Leopold Toetsch wrote:
set I2, P1[Foo\x00i] # I1 == I2
gets currently the attribute idx (0) of $Foo::i.
Q: Should the assembler mangle the Foo::i to Foo\0i
Something about this embedded \0 character
bugs me. I know its what Dan has in the design doc but
it just
At 11:10 AM 12/3/2003 +0100, Leopold Toetsch wrote:
I've put in a really long pending patch. The upcoming vtable changes are
simplified a lot, as e.g. null.pmc is fully generated now.
Currently line numbers in generated .c files are wrong and disabled. Fixes
welcome.
I think we still have 2
At 03:01 PM 12/3/2003 +0100, Leopold Toetsch wrote:
Pete Lomax [EMAIL PROTECTED] wrote:
The following demonstrates that $I1 and .local int i map to the same
register in the output pasm code:
Yep. The problem seems to be the backward branch. When you put the
test sub after the end op, its working
At 10:37 AM 12/3/2003 +0100, Leopold Toetsch wrote:
Melvin Smith [EMAIL PROTECTED] wrote:
1) Currently typenames are not checked except with 'new classname'
As Dan layed out WRT PMC enums, we might have to defer type checking to
runtime. That is for core PMCs we do strict type checking, other
At 03:46 PM 12/3/2003 +0100, Juergen Boemmels wrote:
I'm curently playing around with open calls returning a PMCNULL
instead of a half valid IO-Object. But the main problem with that is
that there is currently no way for the byte-code to detect such a
case.
The if and unless ops call the
We should have 1 recommended way for testing NULL registers.
If we support get_bool() then lets make sure it works for REAL NULL
pmc registers as well as PMCNULL.
If not, code will appear to work correctly on a safe core
but will seg fault on some other. Also, I see no reason not
to use PMCNULL
I don't think there was ever a consensus about opcode naming.
It seems that we need this but can you give an example
of where you are using it, just to give me some context to think
with?
-Melvin
Cory Spencer [EMAIL PROTECTED]
12/03/2003 11:18 AM
To: [EMAIL PROTECTED]
In an effort to improve its error reporting ability and internal
maintainability,
I'm considering the following changes; well number (1) is already decided,
but I need feedback from compiler maintainers before doing so.
1) Currently typenames are not checked except with 'new classname'
At 10:52 AM 12/2/2003 -0500, Dan Sugalski wrote:
Single-inheritance objects seem to be done. The code can use a lot of
abuse and cleanup, and we need actual tests to make sure that it functions
as it should, but they're in.
Let me start the abuse.
*(cough)* examples would be nice ;)
Ok, abuse
At 07:59 PM 12/2/2003 -0800, Steve Fink wrote:
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
Hi Pete,
Looks like what you really need is a good way for IMC to handle:
1) Globals
2) Package (or file local) variables
3) Class definitions (with class locals or fields)
All of these are planned, right now the only equivalent to 'local int a'
in your code sample is a global variable.
At 01:14 PM 11/27/2003 -0500, Dan Sugalski wrote:
At 5:38 PM + 11/27/03, Pete Lomax wrote:
On Thu, 27 Nov 2003 09:52:10 -0500, Melvin Smith
[EMAIL PROTECTED] wrote:
At 12:02 PM 11/27/2003 +, Pete Lomax wrote:
Perl6 already does interpolation without special support from IMCC.
I'll rephrase
At 08:10 PM 12/1/2003 -0700, Cory Spencer wrote:
However, if giving up IMCC's register allocator is worth gaining
the extra control of PASM, by all means do it, however I'm all ears
on suggestions for IMCC for features. *hint*
In that case, I don't suppose it would be possible for IMCC to
At 10:40 AM 11/28/2003 +0100, Leopold Toetsch wrote:
As outlined some time ago, when ops.num made it into the core, we need fix
assigned PMC class enums too. (Changed class enums invalidate existing PBC
files).
1) lib/Parrot/PMC.pm is the canonical source of PMC class = enum mapping.
2) the
At 12:02 PM 11/27/2003 +, Pete Lomax wrote:
Perl6 already does interpolation without special support from IMCC.
That's nice for it. Where do I go crib from?
?
-Melvin
At 05:03 PM 11/25/2003 +0100, Juergen Boemmels wrote:
Melvin Smith [EMAIL PROTECTED] writes:
In PIO_open the ParrotIO object never gets created if there is
an error condition.
But PIO_open returns a valid IO-PMC which just has a NULL in its data
segment. Maybe it should return PMCNULL
.
Leo says [1] that labels should not start with an _ so the obvious
(attached) patch might be wrong.
bye
bö
[1] http://groups.google.com/groups?selm=200311190952.hAJ9qm812051%40thu8.leo.home
imcc_test.diff has been removed from this note on November 25, 2003
by Melvin Smith
At 11:45 AM 11/24/2003 +0300, Vladimir Lipsky wrote:
Hi everyone!
In t/src/io.c, specifically test 9 and 10, I wonder if the PIO_eof check up
works anywhere; because I didn't manage to find any place where the
PIO_F_EOF flag is set up when the PIO_*_open function fails neither
in io_stdio.c,
At 07:18 PM 11/24/2003 +0100, Jerome Quelin wrote:
Dan Sugalski wrote:
On Mon, 24 Nov 2003, Jerome Quelin wrote:
* How does one launch an exception? trap an exception?
* How does one create a class? instanciate an object?
With the exception of the second bullet item, these are generic
At 12:13 PM 11/22/2003 +, you wrote:
* write intval size into PBC header
Leo, I know this is a first cut at freeze/thaw, and I'm happy you've
done it. Let me make some comments to you and Dan.
I'm pretty sure Dan and I discussed this when I was reworking bytecode
to be portable last year,
At 03:18 PM 11/21/2003 -0500, Dan Sugalski wrote:
These could use some documenting (and yes, I know the answer to many) for
future use for folks generating PIR. (Hint, hint -- documentation is a
good thing)
I will make an attempt at answering all of these regarding how it is today,
as opposed to
At 10:14 PM 11/22/2003 -0500, Melvin Smith wrote:
At 11:34 PM 11/22/2003 +0100, Leopold Toetsch wrote:
Melvin Smith [EMAIL PROTECTED] wrote:
to override it, it is not supported to choose INTVAL OPCODE, though
the inverse is. So storing it in the header is probably redundant, unless
we change
At 01:50 PM 11/18/2003 +0100, Leopold Toetsch wrote:
Melvin Smith [EMAIL PROTECTED] wrote:
I propose creating 'parrot-compilers' as a general
purpose list for any and all language development
As long as traffic on p6i is as low as current, I don't see the need for
another list.
I'm concerned
Can you confirm that this is fixed? Upgrading my flex from 2.5.4 - 2.5.6
fixed the unist.d include issue. I checked in a new lexer just now.
-Melvin
At 09:49 AM 11/18/2003 +0200, Nick Kostirya wrote:
Again broken :-)
See http://bugs6.perl.org/rt2/Ticket/Display.html?id=24260
Hi,
When
PARROT_HAS_HEADER_UNISTD
+# define YY_NO_UNISTD_H 1
+#endif
+
#define IMCC_MAX_REGS PARROT_MAX_ARGS
#if IMCC_MAX_REGS 16
#error: flags wont fit
At 06:37 PM 11/18/2003 +, Jonathan Worthington wrote:
- Original Message -
From: Melvin Smith [EMAIL PROTECTED]
Can you confirm that this is fixed
Added 'num' as an alias for 'float'. Both map to the Parrot Nx registers.
-Melvin
In the past couple of years we've seen several sub-projects pop-up
and subsequently fizzle out (maybe due to Parrot slow
progress or maybe due to lack of critical mass).
I propose creating 'parrot-compilers' as a general
purpose list for any and all language development
(until an appropriate time
Various people have bugged me about this for a long time so I figured
it was time, since it was the logical next step in hiding the Parrot
calling convention implementation details.
I've patched in initial support for IMCC to compile high level sub calls.
0, 1 and multiple return values are
At 07:51 PM 11/16/2003 -0500, Dan Sugalski wrote:
At 4:00 PM -0800 11/16/03, Joe Wilson wrote:
Dan Sugalski wrote:
1) The changes I proposed are going in. We get arg counts for I/S/N
registers if they're used.
What purpose do these individual I/S/N arg counts serve exactly?
You missed a bit when
At 01:45 AM 11/17/2003 +, Jonathan Worthington wrote:
I've attached a couple of working samples.
Please may I suggest/request that you pop them in the imcc/examples
directory? There's very little in there as it stands; it'd be nice to at
least put examples in that demonstrate things that are
I'll admit I sometimes can't think that far ahead to see all of the
problems, but when I have problems sitting in front of me, I can
usually solve them.
The situation we have now is: Parrot is a VM, and technically we could
just punt the whole calling convention issue to a high level languages
1 - 100 of 511 matches
Mail list logo
