At 8:54 AM -0500 1/21/03, Christopher Armstrong wrote:
On Tue, Jan 21, 2003 at 08:41:47AM +, Simon Wistow wrote:
Speaking of games, it would be interesting to see Parrot be used in that
direction. A lot of games currently are pretty much developed along the
lines of 'custom scripting langu
At 6:10 PM +0100 1/21/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
Okay, I can be a bit slow, but I finally figured out what's going
on with IMCC and OS X. imclexer.c is autogenerated (duh!) and flex,
or whatever's being used to do it, spits out bad code. Could the
IMCC folks upgrade to the
At 5:48 PM +0100 1/21/03, K Stol wrote:
Is it possible for parrot-code to call functions in other parrot files?
(which implies there is some program which consists of multiple files)
Oh, absolutely.
What one generally does is load in other bytecode files. Those files,
on loading, will install
At 9:24 PM + 1/21/03, Piers Cawley wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Hrm, interesting. Single symbol table for methods and attributes,
though that's not too surprising all things considered. That may make
interoperability interesting, but I was already expecting that to som
At 11:43 PM -0800 1/21/03, Paul Du Bois wrote:
The advantage of Lua (at least for my project, which is a game) is that it
is quite easy to embed, and quite easy to customize. The C API is small and
easily understandable (at the expense of being a little bit of a pain to
use), and the internals ar
Jason Gloudon wrote:
On Tue, Jan 21, 2003 at 08:21:42PM +0100, Leopold Toetsch wrote:
# #!/usr/bin/perl -w
# my $i= 5;
# LAB:
#$i++;
#eval("goto LAB if ($i==6)");
Ok. Having inter_cs call DO_OP just seems more involved than it has to be.
Yep.
How about a single self-contained
On 01/21/2003 5:24 AM, Leopold Toetsch wrote:
Jürgen Bömmels (via RT) wrote:
PS orig description again:
This patch is the beginning of an effort to make PackFile format
extendible. At the moment its combatible with the old bytecode
format.
Ok, to the details:
It appends a 4th segment behind the
I lost the original mail asking for suggestions, so there is no quoted
text here, but have you looked at Joy
(http://www.latrobe.edu.au/philosophy/phimvt/joy.html). Looks to be quite
clean and simple. I haven't had the time to delve into it, but when I was
reminded of it on the Ruby list, I t
This patch adds a new opcde for intersegment branches. I named it
"branch_cs". This takes one $I param, which is the entry in the
fixuptable.
Thanks to Jason Gloudon for hinting me, how to handle this beast.
(s thread "[perl #20315] [PATCH] eval - inter code segment branches")
The fixuptable may h
James Mastros wrote:
I'd be much happier seeing a packfile format that began with DIRECTORY,
and then had the other major sections located dynamicly.
Yep. The simple reason for keeping the old format still a while is
assemble.pl. When switching to imcc is done, there is no need to keep
the o
At 4:53 PM +0100 1/22/03, Leopold Toetsch wrote:
This patch adds a new opcde for intersegment branches. I named it
"branch_cs". This takes one $I param, which is the entry in the
fixuptable.
Thanks to Jason Gloudon for hinting me, how to handle this beast.
(s thread "[perl #20315] [PATCH] eval - i
Dan Sugalski wrote:
At 4:53 PM +0100 1/22/03, Leopold Toetsch wrote:
This patch adds a new opcde for intersegment branches. I named it
"branch_cs". This takes one $I param, which is the entry in the
fixuptable.
Thanks to Jason Gloudon for hinting me, how to handle this beast.
(s thread "[perl #
At 6:13 PM +0100 1/22/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
At 4:53 PM +0100 1/22/03, Leopold Toetsch wrote:
This patch adds a new opcde for intersegment branches. I named it
"branch_cs". This takes one $I param, which is the entry in the
fixuptable.
Thanks to Jason Gloudon for hintin
Dan Sugalski wrote:
At 6:13 PM +0100 1/22/03, Leopold Toetsch wrote:
IMHO plain jumps do not work:
Sure they do. They work as well as jumps within code, which also has a
not-insignificant potential for problems.
But the issues you raised are some of the reasons I'd prefer
inter-segment jum
All~
Regarding MM dispatch, I implemented a version of this for a class of mine
once. The version I have is in C++, and heavily uses templating to provide
compile time type checks where appropriate. Despite these differences,
however, I think that the system of caching methods and the system of
Since it looks like it's time to extend the packfile format and the
in-memory bytecode layout, this would be the time to start discussing
metadata. What sorts of metadata do people think are useful to have
in either the packfile (on disk) or in the bytecode (in memory).
Keep in mind that parrot
Okay, since this has all come up, here's the scoop from a design perspective.
First, the branch opcodes (branch, bsr, and the conditionals) are all
meant for movement within a segment of bytecode. They are *not*
supposed to leave a segment. To do so was arguably a bad idea, now
it's officially
Since face to face meetings are usually a lot more productive than
e-mail exchanges when working design things out, I figure that maybe
it'd be in our best interests to see if it's worth having a parrot
developer day somewhere, where some set of us can get together and
hash out things.
It's di
At 12:28 AM -0500 1/22/03, James Mastros wrote:
If we care about reading old packfiles on newer parrots,
Until we reach 1.0, we don't. As long as we make sure the magic
number in the header of the file is sufficient to make the execution
fail, that's fine for now.
--
At 03:00 PM 1/22/2003 -0500, you wrote:
Okay, since this has all come up, here's the scoop from a design perspective.
First, the branch opcodes (branch, bsr, and the conditionals) are all
meant for movement within a segment of bytecode. They are *not* supposed
to leave a segment. To do so was a
On Wed, Jan 15, 2003 at 01:57:28AM -0500, Dan Sugalski wrote:
> At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote:
> >But who knows, maybe it could be made modular enough (i.e., more
> >interface-oriented?) to allow the best of both worlds -- I'm far too
> >novice wrt Parrot to figure out what
Dan --
Cincinnati, Ohio.
And, I'll make my office available for the meeting, if there aren't so
many
people that it would be impractical (unlikely, I expect, but CMA anyway).
-- Gregor
Dan Sugalski <[EMAIL PROTECTED]>
01/22/2003 03:22 PM
To: [EMAIL PROTECTED]
cc:
I'm confused by nci.pmc's mark() routine. It calls pobject_lives() on
the ->cache.struct_val pointer. But in set_string_keyed(), that seems
to be set to a pointer to a function, which is definitely not a PObj*.
The ->data field, on the other hand, appears to be a PObj*. And
changing mark() to mark
At 6:24 PM -0500 1/22/03, Benjamin Stuhl wrote:
At 03:00 PM 1/22/2003 -0500, you wrote:
Okay, since this has all come up, here's the scoop from a design perspective.
First, the branch opcodes (branch, bsr, and the conditionals) are
all meant for movement within a segment of bytecode. They are *
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Since it looks like it's time to extend the packfile format and the
> in-memory bytecode layout, this would be the time to start discussing
>
> metadata. What sorts of metadata do people think are useful to have
> in either the packfile (on disk) or
The Perl 6 Summary for the week ending 20030119
Summary time again, damn but those tuits are hard to round up. Guess,
what? perl6-internals comes first. 141 messages this week versus the
language list's 143.
Objects (again)
Objects were still very much on everyone's mind as the d
On Wed, 2003-01-22 at 19:46, Christopher Armstrong wrote:
> On Wed, Jan 15, 2003 at 01:57:28AM -0500, Dan Sugalski wrote:
> > At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote:
> > >But who knows, maybe it could be made modular enough (i.e., more
> > >interface-oriented?) to allow the best of b
Christopher Armstrong:
# On Wed, Jan 15, 2003 at 01:57:28AM -0500, Dan Sugalski wrote:
# > At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote:
# > >But who knows, maybe it could be made modular enough (i.e., more
# > >interface-oriented?) to allow the best of both worlds --
# I'm far too
# > >
28 matches
Mail list logo
