Re: crashing parrot for fun and profit.
William Coleda <[EMAIL PROTECTED]> wrote: > So, it's possible for someone to crash parrot by writing questionable PIR? ^_^ Yes. It's assembler programming basically. But eventually we'll have to set GCed items in such a way that an access doesn't segfault but throws an exception. > (This was working fine for quite some time, btw.) Yes. Recent changes to compile caused a different behavior. I've already asked a few times about the wanted default behavior of compiled code subroutines. .sub sub1 ... .sub sub2 ... Should compile return the first sub as the result? .sub sub1 @ANON ... .sub sub2 @MAIN, @ANON ... This should return 'sub2' and not install the globals. How is 'sub1' kept alive and how long? Currently in all cases a *new* Eval object is returned, which represents the compiled code. It overlaps the first compiled subroutine - both have the same start address. And this returned object has to be kept alive. > Also, what do I need to do to save these subroutines? See above. leo
Re: [perl #33801] [PATCH] GDBMHash - a dynamic PMC that binds to GNU dbm
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote: > Hi, > I have been working on a dynamic PMC that calls into 'gdbm'. 'gdbm' is a > file based database, that provides dictionary lookup. > There are no fancy features yet. INVAL, FLOATVAL, PMC and STRINGS are > converted to char arrays and are written to the database file. Shouldn't PMC use freeze/thaw? > The availability of 'libgdbm.so' is checked during the Parrot configuration, > which is not nice. Why? > CU, Bernhard leo
Re: [perl #33801] [PATCH] GDBMHash - a dynamic PMC that binds to GNU dbm
Leopold Toetsch wrote: Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote: I have been working on a dynamic PMC that calls into 'gdbm'. 'gdbm' is a file based database, that provides dictionary lookup. There are no fancy features yet. INVAL, FLOATVAL, PMC and STRINGS are converted to char arrays and are written to the database file. Shouldn't PMC use freeze/thaw? That depends on what GDBMHash is used for. I was thinking primarily about data exchange with non-Parrot programs. In this case one wouldn't expect a frozen PMC as content. The availability of 'libgdbm.so' is checked during the Parrot configuration, which is not nice. Why? As an extension writer, or language implementator, my prefered starting point is a completely built Parrot core. So when adding things I wouldn't want to rebuild or reconfigure Parrot itself. CU, Bernhard -- ** Dipl.-Physiker Bernhard Schmalhofer Senior Developer Biomax Informatics AG Lochhamer Str. 11 82152 Martinsried, Germany Tel: +49 89 895574-839 Fax: +49 89 895574-825 eMail: [EMAIL PROTECTED] Website: www.biomax.com **
[perl #33815] resove ticket via e-mail
# New Ticket Created by prashanth # Please include the string: [perl #33815] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=33815 > Hi, I want to set RT to resolve ticket via mail by requester or CC. please any body give the solution how to set scrips and how to send mail to resolve tickets via mail. regards, prashanth.
Re: [perl #33801] [PATCH] GDBMHash - a dynamic PMC that binds to GNU dbm
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote: > Leopold Toetsch wrote: >> Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote: >> >>>There are no fancy features yet. INVAL, FLOATVAL, PMC and STRINGS are >>>converted to char arrays and are written to the database file. >> >> Shouldn't PMC use freeze/thaw? > That depends on what GDBMHash is used for. I was thinking primarily > about data exchange with non-Parrot programs. In this case one wouldn't > expect a frozen PMC as content. Ah, ok. >>>The availability of 'libgdbm.so' is checked during the Parrot configuration, >>>which is not nice. >> >> Why? > As an extension writer, or language implementator, my prefered starting > point is a completely built Parrot core. So when adding things I > wouldn't want to rebuild or reconfigure Parrot itself. Ok. In the long run I expect a multi-stage config system. First is to get miniparrot built and running, then Parrot core. Extensions like gdbm could be configured at that point or even in a third step. > CU, Bernhard leo
Re: [perl #33801] [PATCH] GDBMHash - a dynamic PMC that binds to GNU dbm
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote: > I have been working on a dynamic PMC that calls into 'gdbm'. 'gdbm' is a > file based database, that provides dictionary lookup. Thanks, applied. leo
Re: [perl #33815] resove ticket via e-mail
This is a deployment of RT for issuings regarding http://www.parrotcode.org, not the ticketing system for RT itself. I would suggest checking http://www.bestpractical.com/rt/. Regards. prashanth (via RT) wrote: # New Ticket Created by prashanth # Please include the string: [perl #33815] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=33815 > Hi, I want to set RT to resolve ticket via mail by requester or CC. please any body give the solution how to set scrips and how to send mail to resolve tickets via mail. regards, prashanth.
Proposed vtable changes WRT method lookup
Below inline attached is a proposal for vtable changes, mainly WRT
method lookup.
Comments welcome,
leo
Proposed vtable changes WRT method lookup
1) rename vtable->data to vtable->class
All current usage of the 'void *data' vtable element is as the object's
class. So it should read "PMC *class".
2) add vtable->mro - an array-ish PMC of classes
'PMC *mro' is a list of class PMCs - the "method resolution order".
mro[0] := this class
mro[1] := first parent
...
This replaces the current classsearch_array PCD_ALL_PARENT for real
objects. Additionally plain PMCs can place their parent classes here
so that the distinction of PMCs vs objects vanishes, when it comes to
method lookup.
3) add vtable->methods - an hash PMC of method_name => sub_PMC
mappings
Currently the methods of a class are stored inside Parrot globals in a
namespace "\x0$class_name". I think the proper place for method
storage should be inside the class itself.
This has some nasty implications though. When reading a packfile with
a Sub PMC inside a namespace this class might not exist yet. So
probably a bare class with just the method hash is pre-created.
4) add vtable->dispatch
This vtable method does the full method lookup and returns the
callable subroutine object, if any. It's basically what the current
VTABLE_find_method is doing.
PMC* dispatch(STRING* meth_name) {}
Find a method for invocant C and arguments set according to
pdd03 to handle the given method. Return a Sub PMC or NULL.
The default implementation calls C repeatedly for classes
in C until a proper method is found. It's likely that it also has
to look into lexicals for local overrides.
5) change vtable->find_method
It get's one additional argument C as described in the
subject "MMD and VTABLE_find_method". The difference to that proposal
and to the current implementation is, that C just
returns, if *that very* object (probably via its class) can do the
method or not. The search inside parents is handled by
Cdispatch>.
So we'll have:
PMC* find_method(STRING* meth_name, INTVAL mmd_nr) {}
return a Sub PMC or NULL, if the object C can handle the given
method, where C is the C-th argument in the call.
6) remove vtable->can
This is redundant, AFAIK. If C (or currently C)
returns != NULL then C is true else it's false.
Comments welcome,
leo
RE: Background materials
Shevek wrote: > > As I do random research into garbage collection and language > design, I wonder whether there is a page of academic backgrounds > and comments thereon for perl6? I'm mooching around Jones and > Lins and citeseer, and I thought it might be useful to have a > list of papers and our thoughts on their utility and applicability. Back in April of 2004, I posted this: > > Richard Jones is the author of "Garbage Collection: algorithms > for automatic dynamic memory management" > http://www.amazon.com/exec/obidos/tg/detail/-/0471941484. A book > that I believe has been mentioned on the list before. > > I do not believe anyone has mentioned his website: > http://www.cs.kent.ac.uk/people/staff/rej/gc.html > > Among other things, Jones maintains a bibliography of > 1875 > references to papers relevant to GC. Many are linked to online > copies of the referenced works. -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com
Re: Proposed vtable changes WRT method lookup
Leopold Toetsch wrote: 1) rename vtable->data to vtable->class All current usage of the 'void *data' vtable element is as the object's class. So it should read "PMC *class". Its a minor thing, but I would try to avoid using identifiers that are keywords in C++: especially in header files. The fact that Parrot is pure C doesn't mean that no one will attempt to use a C++ compiler on it in the next 20 years. I've been bitten by this sort of thing too many times. Dave.
Re: Proposed vtable changes WRT method lookup
Leopold Toetsch wrote: Below inline attached is a proposal for vtable changes, mainly WRT method lookup. First, a general question: under what circumstances is it OK and/or expected for the opcode C and the VTABLE entry VTABLE_get_class to return different results? At the moment, these return quite different results for all of the standard PMCs. The more general observation behind this question: if Parrot is going to provide a mechanism by which a class can override get_class, then the runtime should depend on such interfaces instead of bypassing them and attempting to standardize on mechanisms. - Sam Ruby
