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 2>&1 | grep symb
build_reglist: 5783 symbols
allocate_non_interfering, now: 2205 symbols
It rea
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) Ther
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 p
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 a
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 twe
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 t
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
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 modul
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 parrot
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
T
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 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 mi
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 tetris.p
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
t/pmc/perlar
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 callm
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.
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]>
> >> >
> >> > > flag
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&#x
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 -R
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 b
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 m
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
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,
an
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
Pardon me, I am trudging through all this thread backlog and
have been trying not to post to add to the bandwidth.
At 12:27 PM 1/23/2004 -0800, Damien Neil wrote:
An existence proof:
Java Collections are a standard Java library of common data structures
such as arrays and hashes. Collections are
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_
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 cl
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 ab
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.
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
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 instead
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 th
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 checke
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 a
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 deprecati
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 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 < REGSE
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 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 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 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
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 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 t
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 curre
At 09:26 PM 1/8/2004 -0500, Michal Wallace wrote:
I love the new syntax for calling functions!
Thanks Melvin!!!
And... here's a weird bug. :)
The following code fails with the message
"No Entries on UserStack!" But, if you
delete either/both of the empty comment
lines and it works fine. :)
Thanks
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 t
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 a
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 interp
At 04:41 PM 1/6/2004 -0700, Luke Palmer wrote:
I want these things to be garbage collected, but DOD doesn't trace the
buffer. I can't seem to find a way to mark the frames without making
the chunks into PMCs (yuck). Is there a way to do this?
I was about to answer your question when I saw your f
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 th
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
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-
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. F
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 does
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 nothing
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 regi
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 "ho
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 r
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, how
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
s
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 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.
(Thoug
At 03:05 PM 12/11/2003 -0500, Gordon Henriksen wrote:
Melvin Smith <[EMAIL PROTECTED]> wrote:
> my $foo = Oracle::Instance::DEV1::db_block_buffers;
>
> The namespace lookup in Oracle::Init checks the Oracle config
> parameters which is external code.
>
> All sorts of neat
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 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, ['global',
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?
V
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 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 li
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 outs
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 c
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
wh
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 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
i
As discussed in the last IMCC RFC, I've committed a few of the changes.
IMCC will now generate an error if the register type is unknown
rather than just assign it a PMC register.
P reg types are pmc, object, or a valid classname. Use pmc or
object for "generic" P register to defer type checking.
I
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]
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 PMCNUL
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 get_boolea
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 '
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 ch
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
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 versi
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 '
I would vote for no aliases at all. I propagated the existing uses of
".local object" in the Perl6 compiler and introduced sever
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 o
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 '
C<.local iden
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 cla
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 a
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
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.
Hopef
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
ead of @ like the test suggests.
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 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 PM
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 06:49 PM 11/24/2003 +0100, Jerome Quelin wrote:
Jerome Quelin wrote:
> Melvin Smith wrote:
> > I just checked in an intial IMCC faq (parrot/imcc/docs/imcfaq.pod)
> Great job. Attached you'll find some corrections for typos.
And of course I forgot the patch file. Here it is
At 06:48 PM 11/24/2003 +0100, Jerome Quelin wrote:
Melvin Smith wrote:
> I just checked in an intial IMCC faq (parrot/imcc/docs/imcfaq.pod)
Great job. Attached you'll find some corrections for typos.
Thanks. BTW Robert has linked the HTML FAQ to the site.
You can get to it from the Resou
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, io_un
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)
*) How do I declare an externally visible subroutine?
*) How do I store a global variable
At 01:07 PM 11/23/2003 +0100, Leopold Toetsch wrote:
Melvin Smith <[EMAIL PROTECTED]> wrote:
> At 11:34 PM 11/22/2003 +0100, Leopold Toetsch wrote:
> Ix regs are for:
> 1) Fast integer stuff
> 2) Iteration (increment variables)
> 3) Conditional checks
> 4) Branching a
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 redunda
At 11:34 PM 11/22/2003 +0100, Leopold Toetsch wrote:
Melvin Smith <[EMAIL PROTECTED]> wrote:
> Parrot currently assumes INTVAL size == OPCODE size because
> both get configured as the same integral type, although you can choose
> to override it, it is not supported to choose
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 ho
1 - 100 of 597 matches
Mail list logo
