"Allison Randal (via RT)" <[EMAIL PROTECTED]> wrote:
One thing that would be nice is a bit of PIR syntactic sugar for
if_null and unless_null opcodes. Maybe something like:
if null $P5 goto LABEL
unless null $P5 goto LABEL
Done, enjoy.
Thanks,
Jonathan
"Will Coleda" <[EMAIL PROTECTED]> wrote:
I've done this now - hopefully it works?
Sorry, nope: :(
../../pbc_merge -o lib/tcllib.pbc lib/tcllib_temp.pbc lib/
tclbinaryops.pbc lib/tclcommand.pbc lib/tclcommandlist.pbc lib/
tclconst.pbc lib/tclfunc.pbc lib/tclops.pbc lib/tclvar.pbc lib/
tclwor
Hi,
It was pointed out to me that if you used load_bytecode with either PIR or
PASM then the debug info was wrong. This has now been sorted out. Also,
we've sometimes been getting line numbers wrong since the new calling scheme
went in, which has been fixed too. Plus other small boring twea
"Joshua Isom (via RT)" <[EMAIL PROTECTED]> wrote:
Because src/rx.c and src/rxstacks.c being deleted from 0.3.1, and
lib/Parrot/Docs/Section/C.pm not being updated to reflect it, make html
fails. Aside from some comments in the ChangeLog, there's not a
reference to those files in the 0.3.1 downl
Hi,
Writing a compiler for Parrot? I need your input! :-) I'm looking to work
on enabling Parrot to store away HLL debug info - that is, the file name,
line number, columns etc in the high level language source code. This data
can then be used to emit useful error messages that relate to th
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
On Nov 14, 2005, at 0:02, Jonathan Worthington wrote:
Hi,
.hll_debug file "something.pl"
.hll_debug line 1
Just
#line 123
#line 789 "file.foo"
looks simpler and well known to me - the latter is already
"Jonathan Worthington" <[EMAIL PROTECTED]> wrote:
.hll_debug file "something.pl"
.hll_debug line 1
# code from something.pl line 1 goes here
Here I meant the PIR (compiled) code for line 1 of the HLL source, which
will very likely in most cases be many PIR instructi
"Will Coleda" <[EMAIL PROTECTED]> wrote:
Storing the information is very good: how do we extract it, again? we
have {get,set}{file,line} opcodes, but if we're going to store more
generic information, we need a more generic way to extract it.
My current thinking on this is that a HLL will defin
"Roger Browne" <[EMAIL PROTECTED]> wrote:
> Does it make sense to have nestable structures?
Not always. Consider debug info that includes "line number" and
"statement number". You could have multiple statements per line, or
multiple lines per statement.
Actually the example notation looks qui
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
On Nov 14, 2005, at 0:02, Jonathan Worthington wrote:
* I'm thinking of a PIR syntax along the lines of this:-
The discussion goes forth and back, like all other discussion we already
had WRT syntax, months and years ago.
"Will Coleda" <[EMAIL PROTECTED]> wrote:
The actual source code is definitely needed, and is what I thought you
were talking about before. I don't particularly care about where it gets
stored, as either "debug segment" or "source segment" are below the level
I interact with parrot on.
I'
"Francois PERRAD" <[EMAIL PROTECTED]> wrote:
>
>This patch is required for pbc_merge on some platforms (HP-UX is the
>one that I see it on), particularly when creating tcllib.
Same problem on Win32, but this patch doesn't solve it with MinGW.
Yup, I know about this problem. We shouldn't be loa
Hi,
I seem to be touching a bug related to writing compiled code.
pir_comp = compreg "PIR"
pbc_out = pir_comp(gen_pir)
fh = open output
print fh, pbc_out
close fh
On the print line, I get this error:-
directory_pack segment 'BYTECODE_EVAL_1' used size 158 but reported 160
This used to work -
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
Jonathan Worthington wrote:
Hi,
I seem to be touching a bug related to writing compiled code.
pir_comp = compreg "PIR"
pbc_out = pir_comp(gen_pir)
fh = open output
print fh, pbc_out
close fh
On the print line, I get th
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
Jonathan Worthington wrote:
$ parrot -o breaks2.pbc breaks2.pir
$ parrot breaks2.pbc example.dll
directory_pack segment 'BYTECODE_EVAL_1' used size 158 but reported 160
Same answer as Jerry - works here on x86/linux.
U
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
* interfaces: start some brainstorming, what we might need in Parrot core
Having these would be great for the work I'm doing on the .NET => PIR
translator. Also I would really like to have support for:-
* Static methods
* Class level attributes (as
Hi,
I've attached a patch I've put together that includes Nick Glencross' patch
in ticket #37303 and additional changes that allow for a shared DLL to be
built on Win32 using MS VC++. This has the happy side-effect of fixing the
issues with pbc_merge and dynamic classes (I guess this was one
"Jonathan Worthington" <[EMAIL PROTECTED]> wrote:
Anyway, leo asked me to send this to the list for other people to try out
first before it goes in. So, voila.
And test they did. Thanks, ci'd.
Jonathan
"Nick Glencross" <[EMAIL PROTECTED]> wrote:
I'd appreciate a few volunteers to try out this patch and make sure that
it doesn't break building on your favourite platform.
A similar change to the one in dynclasses_pl.in may be required in
application directories at some point to run on certain
"Nick Glencross" <[EMAIL PROTECTED]> wrote:
Thanks. The hints file was an old version, so this patch fixes that.
Thanks again, also ci'd (10976).
Jonathan
Hi,
I have just checked in some changes that makes the dynamic op libraries
build process work very much like the dynamic PMCs one. This has two good
consequences:
* Dynamic op libraries can (hopefully) now be built anywhere dynamic PMCs
can. Including Win32. Yay.
* More importantly, thi
"Jonathan Worthington" <[EMAIL PROTECTED]> wrote:
Note that dynamic op libs do not *work* on Win32 yet
They do now - I'm using them with my .NET to PIR translator and they work
nicely.
I would really like some feedback from MinGW and cygwin folks on how
dynoplibs build
"Nick Glencross" <[EMAIL PROTECTED]> wrote:
On 1/10/06, Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> I would really like some feedback from MinGW and cygwin folks on how
> dynoplibs build and work for them
Works straight off on cygwin. :-) Gives the answer
Hi,
As of tonight, dynamic op librareis are now built as a standard part of the
Parrot build process, plus there are some tests for them.
Jonathan
"Greg Bacon (via RT)" <[EMAIL PROTECTED]> wrote:
The attached patch against r11052 adds a missing trailing comma so
parrot can configure and build on Cygwin.
Seems someone with a commit bit has beaten your patch to it. ;-) Though
the "libparrot_is_shared" line seems to be gone altogether now
"Greg Bacon (via RT)" <[EMAIL PROTECTED]> wrote:
[...]
/usr/bin/perl tools/build/parrot_config_c.pl --mini > \
src/null_config.c
src/null_config.c
gcc -o miniparrot.exe -s -L/usr/local/lib compilers/imcc/main.o \
-L/home/gbacon/src/parrot/blib/lib -lparrot -lcrypt src/null_config.o
compilers/
"Greg Bacon" <[EMAIL PROTECTED]> wrote:
Not quite. At r11144 on Cygwin, I see
[...]
gcc -o miniparrot.exe -s -L/usr/local/lib compilers/imcc/main.o \
-L/home/gbacon/src/parrot/blib/lib -lparrot -lcrypt src/null_config.o
compilers/imcc/main.o: In function `imcc_version':
/home/gbacon/src/parro
"Joshua Isom (via RT)" <[EMAIL PROTECTED]> wrote:
I tried building tcl today but got a failure in parrot, undefined
symbol. It happens when first outputting the first pbc. I did a
distclean and reconfigured without optimize or using ccache, but that
didn't help. 'make dynclasses-test' tests d
Hi,
* Fixed the Lua PMCs to no longer use the now-deprecated Parrot_PMC_typenum,
so it builds. Also tested out how Lua handles on Win32 - basically it builds
but all the tests give something like this:-
--
lua\t\while...NOK 2# Failed test (lua\t\while.t at line 37)
# got:
Hi,
Today I've essentially completed the work on moving us from working with
.def files, which list symbols to be exported, to just decorating them in
the code. That includes the Parrot core, PMCs (core and dynamic) and ops
(core and dynamic).
One result of this is that functions that can be
"Bernhard Schmalhofer (via RT)" <[EMAIL PROTECTED]> wrote:
I propose to rename 'src/classes' to 'src/pmc' as IMHO it makes
more sene. 't/pmc' is already named 'pmc'.
Yes, and for consistency please also rename dynclasses to dynpmc and the
t/dynclass to t/dynpmc.
Jonathan
"Larry Wall" <[EMAIL PROTECTED]> wrote:
I just had the same problem, and chased it down to the fact that it was
using -L/usr/local/lib ahead of its own blib, so it was linking against
an old libparrot of some sort or other. I'm not sure what the correct
solution is, but as a workaround I deleted
"Bob Rogers (via RT)" <[EMAIL PROTECTED]> wrote:
The attached code compiles to byte code OK in r11235, until you
comment out the push_eh indicated by the patch, which makes
compute_dominance_frontiers take forever. (Sorry; I wish I had time to
try to make it smaller.) TIA,
I hit upon this t
"Greg Bacon" <[EMAIL PROTECTED]> wrote:
I'm still seeing a link failure with r11221.
Discovered I have cygwin on this PC, went to investigate and...happens>...the link failure is gone as well as the auto-import warnings.
Sadly, there's a new problem that I really have no idea about (aside from
Hi,
A while back I announced that I was working on a .NET to PIR translator for
my final year project at uni. In case you've ever pondered how well it's
doing, and you don't read Planet Parrot or my blog, the answer is "pretty
well". So far I'm successfully translating:
* Parameters
* Loca
"Nicholas Clark" <[EMAIL PROTECTED]> wrote:
On Tue, Jan 24, 2006 at 12:11:14AM -, Jonathan Worthington wrote:
.NET has these managed reference thingies. They're basically like
b) Add a v-table flag saying "returning me is forbidden" and checking
that
"Chip Salzenberg" <[EMAIL PROTECTED]> wrote:
On Tue, Jan 24, 2006 at 12:11:14AM -, Jonathan Worthington wrote:
.NET has these managed reference thingies. They're basically like
pointers, but safe. [...]
Making them work on Parrot is no problem. Making them work wit
"Paolo Molaro" <[EMAIL PROTECTED]> wrote:
On 01/24/06 Jonathan Worthington wrote:
.NET has these managed reference thingies. They're basically like
They are called managed pointers.
Yes. And now I've misled Parrot folks into mis-naming them managed
references.
"Chip Salzenberg" <[EMAIL PROTECTED]> wrote:
On Tue, Jan 24, 2006 at 03:52:39PM -, Jonathan Worthington wrote:
"Chip Salzenberg" <[EMAIL PROTECTED]> wrote:
>The trick is to keep references to registers in a way that notices
>when the register set is
"Chip Salzenberg" <[EMAIL PROTECTED]> wrote:
On Tue, Jan 24, 2006 at 08:49:55PM -, Jonathan Worthington wrote:
"Chip Salzenberg" <[EMAIL PROTECTED]> wrote:
>I'd prefer to reuse something in the engine already for those callbacks.
>If a lightweight
"Sastry" <[EMAIL PROTECTED]> wrote:
The Parrot documet says that "Parrot compiles and runs on a large
number of platforms, including all common ones. The Parrot team is
committed to supporting the following combinations as "core
platforms": Linux (x86), Cygwin, Win32, Tru64, OpenVMS (Alpha),
Sola
Hi,
Earlier today I checked in a change that lets you add a :non_volatile flag
to a local or parameter.
.param int i :non_volatile
.local int j :non_volatile
This says to the register allocator "don't re-use the register that this
parameter or local goes in to", which is rather useful if you
"Chip Salzenberg" <[EMAIL PROTECTED]> wrote:
Please revert this change,
Done, along with the docs and test changes relating to it.
and refrain from checking in user-visible or
design-significant changes to the core until I've OK'd them.
Had mentioned this to leo, who said it sounded sane, and
"Nicholas Clark" <[EMAIL PROTECTED]> wrote:
I think that I must be missing something. In ponie, src/pmc/perl5pmcs.h
looks
like this:
--
/*
* !!! DO NOT EDIT THIS FILE !!!
*
* This file is generated automatic
"Joshua Isom" <[EMAIL PROTECTED]> wrote:
I guess this is one place where being CISC really is better than being
RISC. But how much improvement with outputting to a pbc first? But a
couple notes, there's no --help-optimize like --help-debug, and as far as I
know, there's no way to disable optim
"Jonathan Worthington" <[EMAIL PROTECTED]> wrote:
Better names and/or solutions welcome.
Chip has blessed this feature with a name - ":unique_reg" - and I've just
checked in the same stuff as before, but with the accepted name in place of
:non_volatile.
Jonathan
"jerry gay" <[EMAIL PROTECTED]> wrote:
while debugging partcl, leo asked will for some source comments to
understand where the generated code came from. i thought it should be
possible to walk the chain from the code emitter, and print the
calling sub's filename and line number in PIR.
walking t
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
Strange, but it exists for just on case (well not strange, there are just
more negative numbers ...):
$ cat div.pasm
set I0, 0x8000
Which is the largest negative number we can represent in 32 bit integers
(-2147483648).
div I1, I0, -1
print I
Hi,
The .NET translator ambles on and I can now translate a lot of stuff
relating to the .NET object model. Recently I've been working on mapping
.NET's static method overloading onto Parrot's MMD. With some evil tricks I
got it to work - almost.
The real issue is that .NET knows what meth
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
I'm still having troubles, when thinking about namespace PMCs and
implementation thereof.
Especially the relationship of class namespaces and the store_global
opcode.
We have e.g. this PIR snippets:
.sub main :main
cl = newclass 'Foo' #
"Sisyphus" <[EMAIL PROTECTED]> wrote:
My first post here. First up, is there a better place to ask questions
relating to the building of parrot ? If so ... where ? If not ... read
on.
Welcome to the list and yes, you're in the right place. :-)
I'm on Windows 2000, and parrot-0.4.1 builds
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
On Feb 12, 2006, at 2:27, Jonathan Worthington wrote:
This problem would go away if I had a way of doing a find_global or
findmethod but also specifying the types that make up the signature.
The sequence of:
set_args
"Joshua Hoblitt" <[EMAIL PROTECTED]> wrote:
I think your slightly confusing OPs and PMCs. Presumably the *dir
functionality would be implemented as OP codes
I thought The Plan was to have all the I/O stuff done with PMCs rather than
ops in the end. There's no real benefit in having ops - the
"Nicolas Cannasse" <[EMAIL PROTECTED]> wrote:
Yesterday I did a quick fib(30) benchmark comparing Parrot Win32 daily
build (using jit core)
I'm guessing that's the build that I'm to blame for, and it's maybe worth
pointing out that it ain't an optimized build. But I think leo supplied the
re
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
Mmm - actually -C needs computed goto, which isn't supported by all C
compilers.
Including the one that I produce the Win32 builds that I believe were being
tested with (MS Visual C++). Shouldn't it give a "we don't have a computed
goto runcore" err
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
* opcode vs function / method
open P0, "data.txt", ">"
print P0, "sample data\n"
Using opcodes for all the IO has some disadvantages:
a) namespace pollution: all opcodes are reserved words in Parrot
b) opcodes aren't overrida
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
Depending on the arch (32 vs 64 bits) one of these opcodes is
suboptimal. With a new "L" (Long) register type the functionality could
be handled transparently:
$L0 = pio.'tell'()
Yes, but as you add more register types you get a combinatorial b
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
There are some opcodes in core.ops which don't do anything:
I'd do:
setline ... delete, doesn't make sense
getline ... move to debug.ops, implement it
setfile ... delete
getfile ... mpve to debug.ops, implement it
Where getline and ge
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
Yup, and I really, really don't like the idea of making our bytecode
format non-portable. Part of the point of having a VM is portability,
right?
The described mapping doesn't have any PBC portability issues AFAIK. If
'L' is mapping to 'I' or not
"Patrick R. Michaud" <[EMAIL PROTECTED]> wrote:
At any rate, I suspect pbc_merge is the culprit.
If you have any simple(-ish ;-) test cases that demonstrate the particular
issue, I'll probably have a little time in the next few days to investigate.
I've not really had enough time to follow Par
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
Hey, new guy here.
Welcome. :-)
I'm really interested in the parrot bytecode. What are the files/dirs I
should be looking at to understand everything about packfiles, including
layout, api to deal with it, extracting, writing, JIT compiling, et
"Chip Salzenberg" <[EMAIL PROTECTED]> wrote:
I've got a partial solution to the pending question of namespace vs.
class.
Specifically, I've realized that Parrot already had most of a simple
solution to populating a class's methods even if the class has no public
namespace, what with the ".const
<[EMAIL PROTECTED]> wrote:
+Since the structure and content of a compiled subroutine are fixed at
compile
+time, it would be wasteful use the dynamic execution of opcodes at
runtime to
+keep track of meta-information about that structure -- Ispans
+of opcodes that the programmer expects to thro
"Jonathan Scott Duff" <[EMAIL PROTECTED]> wrote:
On Thu, Jun 01, 2006 at 02:22:12PM -0700, Jonathan Lang wrote:
Forgive this ignorant soul; but what is "STM"?
Software Transaction Memory
Well, Software Transactional Memory if I'm being picky. :-) Some info and
an interesting paper here:-
"Sage La Torra" <[EMAIL PROTECTED]> wrote:
I've got a design document detailing the first few translations I'll be
handling, and I'd greatly appreciate feedback and advice.
I may be off base here, or in the alternate pointing out a corner case
that's of little significance, but:
-Compound sta
Hi,
I just checked in the work I've been doing on tranlating .Net assemblies to
PIR. It's in languages/dotnet if you want to have a play with it. The docs
folder contains various bits of documentation on building it and loads on
the internals which should be mostly up to date, and of course
"Charles Reiss" <[EMAIL PROTECTED]> wrote:
Since I don't think the three-tiered threading system is going to be
implemented very soon, I'd like to propose that thread creation
instead be done with one new method of a ParrotThread object:
=item Carguments...)>
Maybe we should go for a name tha
"Vishal Soni" <[EMAIL PROTECTED]> wrote:
Is Parrot IO going to be implemented via opcodes or PMC?
I looked at some old email discussion. There were discussions on
refactoring
some IO opcodes to PMC's (e.g socket opcodes). Have we reached on any
decisions as to how we are going to implement th
Hi,
I just spent a wad of time figuring out why every single .Net regression
test was failing. Turns out that I had created a "t.pbc" in the same
directory as the Parrot executable. Each regression test script produces a
file of this name in the languages/dotnet folder as the output of the
"Matt Diephouse" <[EMAIL PROTECTED]> wrote:
The following code in lines 108-110 of languages/tcl/src/class/
tclcommand.pir are giving parrot some trouble:
inlined.emit(" if epoch != %0 goto dynamic_%1", epoch, label_num)
inlined .= retval
inlined.emit(" goto end_%0", label_num)
I
Hi,
As discussed at YAPC::Europe, here's my suggestions for two new core
PMCs to handle:
* References to a particular element in an aggregate type
* References to a register
The second of these needs an opcode to create it, which I have
proposed a name for. The first of them I'd *like* to
Hi,
Tonight I've been working to get BCG to compile, link and pass its
tests on Windows. It does, but I also spotted that the include path
for BCG has been hard coded into the dynamic PMC build script, which
is a Bad Thing. I had to do a similar-ish (but less obviously evil
looking) thing
Bernhard Schmalhofer (via RT) wrote:
http://svn.perl.org/viewcvs/parrot/trunk/src/ops/dotgnu.ops was meant for
conversion ops for a C#-Implementation.
It looks obsolete to me, especially as there now is languages/dotnet.
Does anybody mind, if I remove it?
I think remove it. I don't know ho
Hi,
Some first thoughts that come to mind after reading leo's two proposals.
+A typical C structure:
+
+ struct foo {
+int a;
+char b;
+ };
+
+could be created in PIR with:
+
+ cs = subclass 'CStruct', 'foo' # or maybe cs = new_c_class 'foo'
+ addattribute cs, 'a'
+ addattribute
Hi,
I've checked in the proposed bytecode PDD and also most of the changes
that I discussed with Allison earlier today. Feedback on it would be
greatly appreciated.
One of the areas that it would good to have some input on, even if it's
just a "yes, that's sane", is versioning. The current i
Ben Morrow wrote:
This is probably too late for a change like this, in which case ignore
me,
No, not too late - it's still a draft so there's time for suggestions.
but I don't suppose there's any chance that pbc files could allow an optional
#! line, so that they can be used as executables d
Bernhard Schmalhofer wrote:
One thing that I noticed is the naming of the new field UUID.
||| The UUID is |
||| computed by applying the hash function specified
in|
||| the UUID type field over the entire packfile
not |
||
Leopold Toetsch wrote:
Indeed. But we probably want to have an UUID to identify
loaded .pasm/.pir/.pbc to avoid loading duplicates.
The UUID as proposed was intended for that; I just hashed up the
definition in the PDD. Er, no pun intended.
As a side note: distinct PBC segments for checksu
[EMAIL PROTECTED] wrote:
What's a "C++ comment"? If you mean //...\n comments, those are legal
in ANSI-99 C
Parrot is using ANSI-98 C, I believe. And //\N+\n comments are not legal
in that.
Jonathan
Hi,
Thanks to @all working on getting dotnet translator back into unified
language testing. I'll be hacking on the translator more when I return
from consulting work in Spain, so this is certainly good to have. :-)
François PERRAD wrote:
Any other suggestions?
1) remove the need of the fi
Hi,
Muchly delayed reply, sorry.
Karl Forner wrote:
Just a little trick that can help. If the parrot interpreter in in
your path, you can workaround
the need to specify the aboslute path by using the env command. For
instance:
#! /usr/bin/env parrot
I used that trick to enable the use of per
Karl Forner wrote:
I've added one C src file, say src/foo.c, and include/parrot/foo.h, and a
test in t/src/foo.t.
I've changed the MANIFEST file accordingly, but I can not manage to
have my
foo.o file to be added in libparrot.a (after a make clean;perl
Configure.pl
;make)
What did I miss ?
No
Hi,
Sorry for delay in getting to this - been working on-site with $JOB for
a while. Comments and questions below, but please see r15001.
Leopold Toetsch wrote:
2) How should we handle changes to the core Parrot library (mostly PMCs,
but also consider anything we promise is available)? Should
Allison Randal wrote:
I think the object model needs a thorough going over in general
Yup. It's on the list right after I/O, threads, and events.
-- for
the reasons above and because it's an unproven system. I'm not
convinced that it will handle all of Perl 6's needs as is. No serious
OO langu
Allison Randal wrote:
More specifically: If you have any questions related to a PDD in clip,
please add them to a QUESTIONS section at the end of the PDD. For
requirements, use REQUIREMENTS. Neither of these sections will live in
the final version of the PDD, so it's a flag for me to process th
Hi,
At the moment, if you have some ParrotObject instance, say foo, and do
something like:
$S0 = foo
Then $S0 will contain the name of the class. This is BAD because it
means you can't overload what a class stringifies too! In fact, there is
a comment in the code saying that:
/*
=item C
Hi,
As of r15039, :vtable and :vtable("...") are now both implemented. See
example code at the end of this email.
As of now, please use this new syntax. I have left in support for the
old "__"-prefix lookup as plenty of old code is using it; please note
that if you have a :vtable("xxx") and
Jonathan Worthington wrote:
Tests and some extra error checking code to come.
Also now done. If you write one of:
.sub not_a_vtable_method :method :vtable
.sub badger :method :vtable("not_a_vtable_method")
It's a compiler error.
I'll leave this ticket open a few more day
Allison Randal wrote:
Updating Punie went smoothly, but when I updated TGE::Rule:
-.sub __init :method
+.sub 'init' :method :anon :vtable
I got this error:
../../parrot -o TGE/Rule.pbc --output-pbc TGE/Rule.pir
error:imcc:'init' is not a v-table method, but was used with :vtable.
in f
chromatic wrote:
On Sunday 29 October 2006 08:25, Jonathan Worthington wrote:
It'd be nice to actually attach these methods to a v-table itself
somehow. However, unless we make classes a compile-time construct rather than
"turning a namespace into a class" using newclass
Kevin Tew wrote:
I've had :init implemented for a couple of weeks now, but I can't
check it in because it needs its own flag.
SUB_FLAG_GENERATOR= PObj_private3_FLAG, /* unused old python
pmcs */
Have you tried this one? It's labeled unused, and I find no references
to it at all in sr
Allison Randal wrote:
Jonathan Worthington wrote:
I implemented this to test it out and it kinda worked. However,
properties don't get serialized so if you compile the program to a
PBC and run that it doesn't work.
Why don't they get serialized?
I guess, that's just no
Patrick R.Michaud (via RT) wrote:
The new :vtable pragma doesn't seem to work when used on methods
of subclasses of core classes. Here's a quick sample
(I'm also adding this test to t/pmc/parrotobject.t):
$ cat vt.pir
.sub main :main
$P0 = subclass 'Hash', 'Foo'
$P0 = s
(sorry for empty reply earlier)
Patrick R.Michaud (via RT) wrote:
The new :vtable pragma doesn't seem to work when used on methods
of subclasses of core classes. Here's a quick sample
(I'm also adding this test to t/pmc/parrotobject.t):
Thanks for the good test case, which has enabled me t
Leopold Toetsch wrote:
Class inheritance from PMCs is very static still (like PMC-only cases). I hope
that the :vtable patches will provide the base for a better solution. For now,
you can only implement the mssing _integer_keyed cases in Match so that default
isn't triggered. We could of cour
Jonathan Worthington wrote:
At the moment, if you have some ParrotObject instance, say foo, and do
something like:
$S0 = foo
Then $S0 will contain the name of the class.
...
=item C
Erm, what the heck was I smoking when I wrote this...the name method
doesn't control what an o
Nicholas Clark wrote:
To me that feels like a hack. The current rather-too-static dispatch (to me)
seems to be the bug, and the thing that needs fixing.
Yeah, you're right. So, I decided to try and address this. From what I
can see, the problem comes up in building the v-table for the subcla
Allison Randal wrote:
How about "Partridge"? It starts with 'p', it's a bird, and brings to
mind "Partridge in a Pear Tree" which goes with the theme of
tree-based compiler tools (PGE outputs trees, TGE munges trees). We
can pretend we named it after Kurt Partridge for his work on ZPL or
Andre
chromatic via RT wrote:
With ICU optional these days, is this still necessary?
Since Windows doesn't ship with a C compiler and this toolkit is one of
the easiest ways to get hold of one for free, then yes, it's good to
have it documented. (It may be *called* the C++ toolkit, but it's also
Ron Blaschke wrote:
Seems like the old Visual C++ Toolkit 2003 is discontinued.
http://msdn2.microsoft.com/en-us/visualc/aa336490.aspx
Aha. If you would have a moment to write these latest changes into
readme.win32.pod and send in a patch, that'd be awesome; otherwise I'll
get to it when I
1 - 100 of 563 matches
Mail list logo
