Re: [BUG] IMCC looking in P3[0] for 1st arg
On Oct-26, Melvin Smith wrote:
> At 06:25 PM 10/26/2003 -0800, Steve Fink wrote:
> > .pcc_sub _main prototyped
> > .pcc_begin_return
> > .return 10
> > .return 20
> > .pcc_end_return
> > .end
>
> It is still the same issue. This code explicitly mixes 2 call conventions.
> _main is declared as prototyped so it will return 1 in I0 which signals that
> it is returning its values in registers in prototyped convention. Your
> call explicitly calls in non_prototyped mode which does not generate any
> code to check the return convention since you are saying by your code
> that you _know_ what the call convention is.
Oops, I meant to leave the "prototyped" off of the _main sub. This
behaves indistinguishably from declaring it prototyped; it seg faults
if called non_prototyped. I believe it's supposed to work when called
with either style.
Sorry for the bad example.
Likewise, if I declare the .pcc_sub to be non_prototyped (so that both
the call and declaration are non_prototyped), I get the same error:
.sub _main
.local Sub myfunc
myfunc = newsub _myfunc
.pcc_begin non_prototyped
.pcc_call myfunc
ret:
.result $I0
.result $I1
.pcc_end
print "Returned "
print $I0
print ","
print $I1
print "\n"
end
.end
.pcc_sub _myfunc non_prototyped
.pcc_begin_return
.return 10
.return 20
.pcc_end_return
.end
% ./perl6 -Rt mini.imc
.
.
.
PC=60; OP=38 (invoke_p); ARGS=(P1=RetContinuation=PMC(0x40c04998))
PC=21; OP=1003 (restoretop)
PC=22; OP=801 (shift_i_p); ARGS=(I17=0, P3=NULL)
Error: '/home/sfink/parrot/parrot -t -r mini.imc ' failed
died with signal 11 (SIGSEGV)
> However, I see your point. To be orthogonal would suggest that we
> implement the same feature for .pcc_call that we do for the .pcc_sub
> declaration. If you left off the calling convention to .pcc_call it
> would generate code to check for either. Although this would really
> bloat the code, it might be wise to support the feature for some
> instances.
No, sorry, my bad example obscured the issue. I was not asking for a
.pcc_begin that works in either case; I just want it to be possible to
call a subroutine without a prototype and have it successfully return
values. True, I would also like to be able to call the same subroutine
*with* a prototype in another call site, but that is already
implemented. I don't think allowing people to leave off the
{non_,}prototyped declaration from .pcc_begin provides anything but
superficial syntactic orthogonality; a call site really ought to know
whether it can see the prototype of what it's calling or not! (Well...
except I sometimes call non_prototyped even when I know the prototype,
because pdd03 calling convention prototypes don't handle everything in
a Perl6 prototype. But that's irrelevant here.)
My brain doesn't seem to be working all that well this weekend...
I'll throw in one more thing just because I know a certain Mr. P.
Cawley dearly loves people to pile unrelated things into a single
thread: could there be a way to expose which continuation to invoke
when returning from a routine? In a regex, I'd really like a rule to
be invoked with a "success" continuation and a "fail, so backtrack"
continuation. And possibly with some more extreme failure
continuations for cuts and commits and things. But right now the
return continuation in P1 is hidden inside the PCC mechanism. (I guess
I could just manually overwrite P1, but that seems like it's working
against imcc rather than with it.)
I'm faking it for now by returning a boolean status code, but that
doesn't really feel like the "right" solution.
Re: [BUG] IMCC looking in P3[0] for 1st arg
I'll throw in one more thing just because I know a certain Mr. P. Cawley dearly loves people to pile unrelated things into a single thread: could there be a way to expose which continuation to invoke when returning from a routine? In a regex, I'd really like a rule to be invoked with a "success" continuation and a "fail, so backtrack" continuation. And possibly with some more extreme failure continuations for cuts and commits and things. But right now the return continuation in P1 is hidden inside the PCC mechanism. (I guess I could just manually overwrite P1, but that seems like it's working against imcc rather than with it.) Technically its not a problem and relatively easy to implement. I suppose it needs to be discussed as an addition to the calling convention first, though. I'm up for it. -Melvin
PCC (was: [BUG] IMCC looking in P3[0] for 1st arg)
Steve Fink <[EMAIL PROTECTED]> wrote: > That is working for me now for the parameter passing, but not for > return values. As Melvin said, you are still mixing calling conventsion. *But* return conventions are currently only prototyped. We don't have any syntax yet to denote the desired behavior. I'm still waiting on design documents about unification of call and return conventions. IMHO the whole PCC stuff needs some tweaking. Argument passing/param binding and return value passing/result binding seem to be almost the same to me. Though the former has some more variants like r/o, copy, by ref, whatever. The whole Ix register usage for prototyped calls seems rather unneeded to me. When both sides know, how they pass params and return values, there is no need for additional information. Depending on the run core, there can be significant (--profile shows one third of execution time in the fibonacci benchmark) overhead for register setup. For JIT this boils down to nothing though. Then we need some means to define and lookup function signatures for library code. When HLLs should finally be able to use any library of all HLLs that use Parrot, these libaries have to specify their interfaces. Prototyped and non-prototyped are two different ways to call a function (or return some values). But these are known ways. We might have additionally the case, that a function is called either way. leo
Re: [BUG] IMCC looking in P3[0] for 1st arg
Melvin Smith <[EMAIL PROTECTED]> wrote: > Technically its not a problem and relatively easy to implement. [ Aother note ] $ perldoc imcc/docs/calling_conventions.pod · pcc_call Takes either 2 arguments: the sub and the return continuation, or the sub only. For the latter case an invokecc gets emitted. > -Melvin leo
Re: [BUG] IMCC looking in P3[0] for 1st arg
Steve Fink <[EMAIL PROTECTED]> wrote: > Likewise, if I declare the .pcc_sub to be non_prototyped (so that both > the call and declaration are non_prototyped), I get the same error: Non-protyped returns are not implemented. > I'll throw in one more thing just because I know a certain Mr. P. > Cawley dearly loves people to pile unrelated things into a single > thread: could there be a way to expose which continuation to invoke > when returning from a routine? .pcc_call Sub, RetCont is implemented. S. e.g. imcc/t/syn/pcc_2.imc leo
[perl #24300] [PATCH] Error message when a non-existent file is included
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #24300] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=24300 > Hi, when trying to include a non-existent file in a PIR file, one gets a error message "No such file or directory". However the error claims to be from some line number in the non-existent file. As this isn't very helpful, I have twisted 'imclexer.c' such that the error is reported from where the '.include' statement is located. I have also added a test case in imcc/t/syn/file.t. Another thing to check, is wether files in "runtime/parrot/include" are really found. CU, Bernhard -- attachment 1 -- url: http://rt.perl.org/rt2/attach/66511/49694/1acec5/include_nonexistent.patch include_nonexistent.patch Description: include_nonexistent.patch
#define version obj.version is a kind of generic thing
Hi, Upgraded parrot today and ran into some snags with in my own perl5lv.pmc that includes perl.h The error was /Users/sky/Documents/Projects/ponie/perl/proto.h:778: parse error before '.' token That line is PERL_CALLCONV void Perl_utilize(pTHX_ int aver, I32 floor, OP* version, OP* idop, OP* arg); Which convienently gets converted to void Perl_utilize ( int aver , I32 floor , OP * obj . version , OP * idop , OP * arg ) ; because of include/parrot/pobj.h:# define version obj.version So I am wondering about the status of how to write my own pmc, should it not include parrot/parrot.h ? If it should, perhaps it would be good if all parrot things are prefixed as suck, at least when they have very generic meanings? Arthur
Re: #define version obj.version is a kind of generic thing
Arthur Bergman <[EMAIL PROTECTED]> wrote: > include/parrot/pobj.h:# define version obj.version Sorry for that :) We can AFAIK toss the version part of a PObj. Its almost unused and hardly needed. It could be renamed too inside parrot. It should be out of the way, if you "#define DISABLE_GC_DEBUG 1" before including parrot.h > Arthur leo
Re: Using extend.h to create a specific PMC
Arthur Bergman <[EMAIL PROTECTED]> wrote: > Hi, > Quick question, is it possible to create a specific type of PMC using > extend.h? t/src/extend.t has this: type = Parrot_PMC_typenum(interpreter, "PerlString"); testpmc = Parrot_PMC_new(interpreter, type); > Arthur leo
Re: #define version obj.version is a kind of generic thing
On Monday, October 27, 2003, at 02:10 pm, Leopold Toetsch wrote: Arthur Bergman <[EMAIL PROTECTED]> wrote: include/parrot/pobj.h:# define version obj.version Sorry for that :) We can AFAIK toss the version part of a PObj. Its almost unused and hardly needed. It could be renamed too inside parrot. It should be out of the way, if you "#define DISABLE_GC_DEBUG 1" before including parrot.h For the time being I just did #define version version :) Arthur
Re: Ordered destruction and object graph traversal
On Fri, 24 Oct 2003, Gordon Henriksen wrote: > On Monday, October 20, 2003, at 11:40 , Jeff Clites wrote: > > > My solution was to define a new vtable method--I've called it visit(), > > though the name's not the important part--to which you pass a callback > > (plus an optional context argument). It's job is to invoke that > > callback on each of it's referenced "children" (also passing the > > context object with each invocation), and that's it. The PMC doesn't > > know or care what the callback does--in a GC context the callback may > > set a flag on what's passed in and stash it for later processing; in > > another context it may be used inside of an iterator which vends out > > objects one-by-one and guards against loops. > > Great! This is exactly the fundamental operation I'd been musing would > be the best building block to enable serialization and pretty-print > operations, and I'm sad to see that your post has been Warnocked. :( Allow me to haul out this bucket of ice-water I keep around for just such an eventuality. :) There's a low limit to the complexity of any sort of traversal we can provide. We *can't* go recursive in a traversal, if it crosses the C->Parrot or Parrot->C boundary as part of the recursion, or stays entirely in C. We can only count on a 20-40K stack *total*, and it doesn't take too many calls into a recursive procedure to eat that up. That limits the mechanisms we can use to traverse the graph of objects pretty badly. The linked list mechanism the DOD system is using is one of the few that isn't recursive. There are other mechanisms that can be used for traversal that avoid recursion, but they generally trade off pretty heavy memory usage for that lack, which makes them unsuitable for general use. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #24300] [PATCH] Error message when a non-existent file is included
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote: > when trying to include a non-existent file in a PIR file, one gets a > error message "No such file or directory". However the error claims to > be from some line number in the non-existent file. As this isn't very > helpful, I have twisted 'imclexer.c' such that the error is reported > from where the '.include' statement is located. Applied to imcc.l, thanks, leo
Re: NULL Px proposal (was Re: [BUG] IMCC looking in P3[0] for 1st arg)
On Sun, 26 Oct 2003, Melvin Smith wrote: > At 07:21 PM 10/26/2003 +0100, Leopold Toetsch wrote: > >Steve Fink <[EMAIL PROTECTED]> wrote: > > > > > Although this does bring up another issue -- should parrot really be > > > seg faulting when it gets a uninitialized (null) PMC? > > > >The problem is of course that we call pmc->vtable->some_meth_od() on a > >NULL PMC. We could do the checks always, slowing down each PMC > >operation. But OTOH a correct HLL compiler wouldn't produce such broken > >code (hopefully). So that's probably something for the bounds-checking > > This is an old discussion. While I agree with Leo (and Dan) on not putting > checks everywhere, I also think segfaulting on faulty bytecode is > violating the "Virtual Machine" contract. > > I also don't wan't to see the performance hit of checking PMC regs everywhere. > > I think a compromise would be to do define a interpreter global PMCNull > and point (or init) all Px registers to it. > > All methods in this class would be implemented to throw an exception or > dump the bytecode for debugging and we could always trap a "NULL" > register access. > > This way we never have a NULL pointer access with regards to Px regs. This works. The safe code still needs to check, and null registers are still a possibility but the null op and the register block-clearing code can do this when they clear out register blocks. The Null PMC should pitch a fatal exception for everything it does, so we can catch this stuff. Probably should be a compile-time option so it can be turned on for debugging/development runs and off for general usage. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: #define version obj.version is a kind of generic thing
Arthur Bergman <[EMAIL PROTECTED]> wrote: > For the time being I just did > #define version version And I have checked in s/version/pobj_version/g :) > Arthur leo
Re: cvs commit: parrot/src runops_cores.c
On Sat, 25 Oct 2003, Leopold Toetsch wrote: > Dan Sugalski <[EMAIL PROTECTED]> wrote: > > At 10:10 AM +0200 10/25/03, Leopold Toetsch wrote: > > > Oh, it certainly can be an absolute address, if you know what the > > address is when you're generating the code. > > Did you ever try, what the assembler considers needing fixup: a > _non_local label. I don't know, if that's the problem. But local labels > (w/o underscores) are considered to be fixed up immediately, while global > labels are fixed up later. Right, bit this wasn't a label at all, unless the assembler's considering everything a label. (Which isn't unreasonable, certainly) The code looked something like: jsr 123325412 Give or take a couple digits. > > 2drop, for example, drops the two words on the top of the stack and > > is really just "drop drop", and can be build from existing words. > > (drop, in this case) The generated code for the word *should* look > > like: > > > jsr .drop > > jsr .drop > > ret > > Yep, that's right. It would be slightly simpler, if there were one or > two tests in the forth directory, anyway, after sneaking into "info > gforth", I figured out that ": bla 2 + ; 1 bla ." would compile the > "bla" opcode and print 3 :) Good point. I've been testing interactively, but as soon as I rejig it to use PMCs I'll add in some tests. > I didn't look at that immediate thing yet, but it would be fine if you > could extract some PASM lines, that exhibit this inconsistency. But IIRC > gets the integer argument fixed up, while the constant isn't. This is > due to the fact, that opcodes don't have any information, which argument > is a branch offset or address. There is only one assumption, that, when > there is a branch, the last argument of one opcode is the branch offset. > > So during label fixup there are some hardwired "is this a set_addr" or > such, and then when yes, fixup the second argument. Ah, that makes sense. The assembler expects a real label since it can't reasonably get an integer constant, and I'm providing an integer constant. :) > > I'm OK both with different bytecode > > segments sharing a constant table, as well as mandating that new > > segments may, if given the appropriate flags at creation time, can > > share the existing constant segment. > > That's the way to go. The compile stuff was a joke in the first place to > get Jerome's bfc compiler running. The first implementation just used the > (one and only) constant table and generated a new bytecode segment. But > generally, an eval()ed piece of code could produce constants en mass, > never going away and exhausting memory finally. While the *implementation* might've been for a joke, and what I did for forth was definitely a nasty hack, the actual semantics and facility's darned useful. (Though, arguably, not 100% essential) > So the plans (tm) are, to make such (compiled) code segments PMCs, which > can go out of scope like any other closure or such, and that get cleaned > up by DOD. Right, I've been thinking about that. For this to work right, code segments really need to be contained in something DOD-able and traceable, which would make things a bit more robust. Code segments wouldn't be moveable, of course, but it would be nice to be able to trace them and free the chunks up when we're done with them. > Coming back to your forth case. You didn't have constants in the > compiled code, so your hacks are working. But for general usage we need > some flags, what the compiled code should share with the calling > bytecode. This is not only the constant table but concerning all > segments like debug (currently line numbers only). Sharing the constant table amongst segments seems straightforward, and I can't think of a good reason to not do so, though I can see potential issues with safe mode code changing constants in shared segments, but that's more an issue of preventing the change (or sharing) in a safe environment. It may be reasonable to have an appendable bytecode segment that can be passed along to the compilation modules. The compiler modules can create a new segment if one's not passed in, or append to an existing one if it is, to save on segments. I can see allowing 'raw' bytecode with no segments at all (I almost went that route) but I think that'll make things too much of a pain in other places. > This also means, that there will be some restructuring of > interpreter->code (and ->constants), the former is now the packfile, and > will be a directory segment finally, the shortcuts like constants or jit_code > will probably die, they make a mess out of code segment switching ... :) If it doesn't lose us speed, I'm fine with things being rearranged. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even tedd
[CVS ci]: C Test changes
I just committed a change to Parrot::Test.pm
If a c_output_* test fails to generate an executable the test fails
instead of being silently ignored.
Hopefully the printf("Done\n") trick is not necessary any more.
Furthermore, if the C-Compiler fails to build an object-file the
output of the C-Compiler is passed to the user instead of the rather
useless linker error
"Failed to build 'test_1': cc: test_1.o: No such file or directory"
bye
boe
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: cvs commit: parrot/src runops_cores.c
Dan Sugalski <[EMAIL PROTECTED]> wrote: > On Sat, 25 Oct 2003, Leopold Toetsch wrote: >> So during label fixup there are some hardwired "is this a set_addr" or >> such, and then when yes, fixup the second argument. > Ah, that makes sense. The assembler expects a real label since it can't > reasonably get an integer constant, and I'm providing an integer constant. > :) Yep, that's the problem. While we have flags stating what kind of branch operation an opcode might be, we don't have any hints, which operand might need what kind of fixup. > Sharing the constant table amongst segments seems straightforward, and I > can't think of a good reason to not do so, The main reason is eval(). Evaluating code with varying constant strings in a loop would fill up the main/global constant table and exhaust memory finally. OTOH your usage of compile is totally different, it needs a shared constant table. > ... though I can see potential > issues with safe mode code changing constants in shared segments, but > that's more an issue of preventing the change (or sharing) in a safe > environment. Changing constants? > It may be reasonable to have an appendable bytecode segment that can be > passed along to the compilation modules. As soon as you start executing code in that segment, it can't be expanded (which possibly moves it). WRT forth, the compiler could append all compiled code from Cs, but before the first word is due to running, the fixups have to be done, if any, prederefed code may be produced or the segment might get JITted. > ... The compiler modules can create a > new segment if one's not passed in, or append to an existing one if it is, Not easily, as we have absolute branch addresses everywhere. Some time ago, I did propose relative addresses, which would allow appending easily, but this could slow down branches a bit. >> This also means, that there will be some restructuring of >> interpreter->code > :) If it doesn't lose us speed, I'm fine with things being rearranged. I'll try to not have another indirection and to have faster code segment switching. > Dan leo
Re: Trying to spear a phalanx shield for pod
On Mon, Oct 27, 2003 at 12:25:45PM +1100, Andrew Savige wrote: > Your version does not work (unless I've had a brain malfunction): No, I had the brain malfunction. I forgot that and has an even lower precedence than = so the expression comes out as: (my $have_testpod = !$@) and $Test::Pod::VERSION >= 0.95; I'll just go back to memorizing the precedence table now. > I hope Andy is listening. ;-) > Yes, I agree it'd be nice for Test::Pod to provide a little more help > for this very common chore for CPAN module authors. I do feel most > uncomfortable cut n' pasting this code all over the place. Of course, there's also Pod::Find, but it was introduced into the core around 5.6.0. While I have vague grumblings about replicating Pod::Find's functionality in Test::Pod, most people don't know about Pod::Find and anyway if its in Test::Pod then you only have to depend on one module instead pulling in the whole PodParser suite. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ We're talkin' to you, weaselnuts. http://www.goats.com/archive/000831.html
Re: How?
On Mon, Oct 27, 2003 at 03:33:47AM +0200, Dmitry Nikolayev wrote: > Hello > How can I be involved in the project? Maybe, some help is needed? > If you're interesting about me: http://buildbn.net/resume.html http://www.parrotcode.org/ should have the basic information you need to jump in. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/
Re: Halloween release
Dan Sugalski <[EMAIL PROTECTED]> wrote: > On Wed, 22 Oct 2003, Melvin Smith wrote: >> I propose a Halloween release. Nothing fancy, just something fun. :) >> We should be able to reach some sort of minor milestone to >> justify it I'm sure. > Oct 31, the screaming pumkin release? :) Sounds good -- lets see where we > stand on Monday and go from there. Seems to be Monday today. How are the plans? I've collected a rough list of changes[1] from 0.0.11 til end of last week, looks quite impressive. > Dan leo [1] - The Big Move: Parrot source and build files rearanged into sub dirs - Build imcc as parrot - Objects more finished - Delegate vtable methods to bytecode - Binary multi-method dispatching - Call bytecode from C - Extension interface - Dynamic opcode libraries - PCC argument flattening - Experimental network socket interface code and opcodes - Fix assigned opcode numbers - Ncurses, postgres, and pcre interface librarys - More NCI signatures - Experimental struct handling - Many new tests and fixes
Re: How?
Dmitry Nikolayev <[EMAIL PROTECTED]> wrote: > Hello > How can I be involved in the project? Maybe, some help is needed? What would you like to contribute? Help is always welcome. Did you read the docs (either at parrotcode.org or in the src? intro.pod has a "Getting involved" chapter. There is a TODO file too. If unsure, where to start, try writing some tests: You can learn Parrot assembly and see how things are working. > Dmitry Nikolayev leo
Re: Halloween release
I can get the null register access exception support patched in. -Melvin Leopold Toetsch <[EMAIL PROTECTED]> 10/27/2003 11:53 AM Please respond to lt To: [EMAIL PROTECTED] (Dan Sugalski) cc: [EMAIL PROTECTED] Subject:Re: Halloween release Dan Sugalski <[EMAIL PROTECTED]> wrote: > On Wed, 22 Oct 2003, Melvin Smith wrote: >> I propose a Halloween release. Nothing fancy, just something fun. :) >> We should be able to reach some sort of minor milestone to >> justify it I'm sure. > Oct 31, the screaming pumkin release? :) Sounds good -- lets see where we > stand on Monday and go from there. Seems to be Monday today. How are the plans? I've collected a rough list of changes[1] from 0.0.11 til end of last week, looks quite impressive. > Dan leo [1] - The Big Move: Parrot source and build files rearanged into sub dirs - Build imcc as parrot - Objects more finished - Delegate vtable methods to bytecode - Binary multi-method dispatching - Call bytecode from C - Extension interface - Dynamic opcode libraries - PCC argument flattening - Experimental network socket interface code and opcodes - Fix assigned opcode numbers - Ncurses, postgres, and pcre interface librarys - More NCI signatures - Experimental struct handling - Many new tests and fixes
[RfC] Header Dependencies
Hi,
Currently there 64 header files in include/parrot. From these 64
header files 36 can be included directly, i.e.
#include
will compile, but
#include
will fail with errors. In the case of chartype this can be easily
fixed [1].
Other headers are a little bit harder.
Would it be a good idea to fix the other headers the same way? This is
not a really hard task. A next step could be not simply include
, but only the headers, that are really needed. This
is currently a real pain because some header files have hidden
asumptions to be included only after other header files.
A simple src test can enforce this policy [2].
Comments?
bö
Index: chartype.h
===
RCS file: /cvs/public/parrot/include/parrot/chartype.h,v
retrieving revision 1.19
diff -u -r1.19 chartype.h
--- chartype.h 23 Sep 2003 10:19:17 - 1.19
+++ chartype.h 27 Oct 2003 16:56:17 -
@@ -13,6 +13,8 @@
#if !defined(PARROT_CHARTYPE_H_GUARD)
#define PARROT_CHARTYPE_H_GUARD
+#include
+
struct parrot_chartype_t;
typedef Parrot_UInt (*Parrot_CharType_Transcoder)
(const struct parrot_chartype_t *from,
@@ -32,8 +34,8 @@
* Character code to digit value translation map
*/
struct chartype_digit_map_t {
-UINTVAL first_code;
-UINTVAL last_code;
+Parrot_UInt first_code;
+Parrot_UInt last_code;
int first_value;
};
@@ -54,7 +56,7 @@
struct parrot_chartype_t {
-INTVAL index;
+Parrot_Int index;
const char *name;
const char *default_encoding;
Parrot_Int (*is_digit)
# perl -w
@headers = map { s!^include/!!; $_ } glob "include/parrot/*.h";
require Parrot::Test;
import Parrot::Test tests => scalar @headers;
for $header ( @headers ) {
c_output_is(<<"CODE", '', $header);
#include <$header>
int
main()
{
return 0;
}
CODE
}
Re: Ordered destruction and object graph traversal
On Oct 27, 2003, at 6:21 AM, Dan Sugalski wrote: On Fri, 24 Oct 2003, Gordon Henriksen wrote: On Monday, October 20, 2003, at 11:40 , Jeff Clites wrote: My solution was to define a new vtable method--I've called it visit(), though the name's not the important part--to which you pass a callback (plus an optional context argument). It's job is to invoke that callback on each of it's referenced "children" (also passing the context object with each invocation), and that's it. The PMC doesn't know or care what the callback does--in a GC context the callback may set a flag on what's passed in and stash it for later processing; in another context it may be used inside of an iterator which vends out objects one-by-one and guards against loops. Great! This is exactly the fundamental operation I'd been musing would be the best building block to enable serialization and pretty-print operations, and I'm sad to see that your post has been Warnocked. :( Allow me to haul out this bucket of ice-water I keep around for just such an eventuality. :) There's a low limit to the complexity of any sort of traversal we can provide. We *can't* go recursive in a traversal, if it crosses the C->Parrot or Parrot->C boundary as part of the recursion, or stays entirely in C. We can only count on a 20-40K stack *total*, and it doesn't take too many calls into a recursive procedure to eat that up. That limits the mechanisms we can use to traverse the graph of objects pretty badly. The linked list mechanism the DOD system is using is one of the few that isn't recursive. There are other mechanisms that can be used for traversal that avoid recursion, but they generally trade off pretty heavy memory usage for that lack, which makes them unsuitable for general use. Who said anything about recursion? JEff
Re: Halloween release
On Mon, 27 Oct 2003, Melvin Smith wrote: > I can get the null register access exception support patched in. And I think I'll have working conditional logic for Forth in, possibly with access to Parrot's calling conventions. (life.forth has an interesting ring to it... :) > Dan Sugalski <[EMAIL PROTECTED]> wrote: > > On Wed, 22 Oct 2003, Melvin Smith wrote: > > >> I propose a Halloween release. Nothing fancy, just something fun. :) > >> We should be able to reach some sort of minor milestone to > >> justify it I'm sure. > > > Oct 31, the screaming pumkin release? :) Sounds good -- lets see where > we > > stand on Monday and go from there. > > Seems to be Monday today. How are the plans? I've collected a rough list > of changes[1] from 0.0.11 til end of last week, looks quite impressive. > > > Dan > > leo > > [1] > > - The Big Move: Parrot source and build files rearanged into sub dirs > - Build imcc as parrot > - Objects more finished > - Delegate vtable methods to bytecode > - Binary multi-method dispatching > - Call bytecode from C > - Extension interface > - Dynamic opcode libraries > - PCC argument flattening > - Experimental network socket interface code and opcodes > - Fix assigned opcode numbers > - Ncurses, postgres, and pcre interface librarys > - More NCI signatures > - Experimental struct handling > - Many new tests and fixes > > > Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Halloween release
On Thu, 23 Oct 2003, Dan Sugalski wrote: > On Wed, 22 Oct 2003, Melvin Smith wrote: > > > I propose a Halloween release. Nothing fancy, just something fun. :) > > We should be able to reach some sort of minor milestone to > > justify it I'm sure. > > Oct 31, the screaming pumkin release? :) Sounds good -- lets see where we > stand on Monday and go from there. Well on Solaris, I found a few problems. They don't stand in the way of "something fun", but they do need fixing. 1. MANIFEST error. imcc/unit.h was missing. 2. Configure.pl warning: Determining some signal stuff... (sigaction) (setitimer) done. Determining if your C library has setenv / unsetenv...Use of uninitialized value in string ne at (eval 21) line 91, chunk 10. (no) done. Generating config.h...done. 3. Fatal error in Makefile. make: Fatal error in reader: Makefile, line 650: Unmatched `)' on line The problem is the Parrot/Config.pm variable gc_c. Here's what it's set to: 'gc_c' => '1000 3100 2004 2000 1000SRC)/resources$(O): $(GENERAL_H_FILES) $(SRC)/resources.c I don't know why it has '1000 3100 2004 2000 1000SRC)' instead of the expected $(SRC). Anybody have any ideas? I've fixed that by hand and have started running 'make' and 'make test'. I'll next have a chance to look at the output tomorrow. -- Andy Dougherty [EMAIL PROTECTED]
Re: Halloween release
On Mon, 27 Oct 2003, Andy Dougherty wrote: > On Thu, 23 Oct 2003, Dan Sugalski wrote: > > > On Wed, 22 Oct 2003, Melvin Smith wrote: > > > > > I propose a Halloween release. Nothing fancy, just something fun. :) > > > We should be able to reach some sort of minor milestone to > > > justify it I'm sure. > > > > Oct 31, the screaming pumkin release? :) Sounds good -- lets see where we > > stand on Monday and go from there. > > Well on Solaris, I found a few problems. They don't stand in the way of > "something fun", but they do need fixing. > > 1. MANIFEST error. imcc/unit.h was missing. Seems to be fixed. > 2. Configure.pl warning: > > Determining if your C library has setenv / unsetenv...Use of uninitialized value in > string ne at (eval 21) line 91, chunk 10. > (no) done. I think this might have something to do with #3: > 3. Fatal error in Makefile. > make: Fatal error in reader: Makefile, line 650: Unmatched `)' on line I missed backwhacking a $ in a heredoc. Fixed and committed. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [RfC] Header Dependencies
Juergen Boemmels <[EMAIL PROTECTED]> wrote: > Would it be a good idea to fix the other headers the same way? Cleanup in the headers is for sure a good thing. OTOH I don't know, if its really useful to only include some headers. Some compilers can AFAIK precompile header files, so always having just parrot.h is ok. > b=F6 leo
Re: Storing external data in PMCs
Arthur Bergman <[EMAIL PROTECTED]> wrote: > The function is a C function. And yes it is a custom PMC which I have > already created. The interface for calling C code from PASM is NCI (native call interface). s. e.g. library/*.pasm or t/pmc/nci.t. But inside your custom PMC you can do all kinds of things, to stuff a pointer into e.g. data. - at init time init_pmc() has an extra pointer argument - via a customized vtable method: e.g. set_pmc, set_pmc_keyed or push or whatever Vtable calls seem still to be missing in the extension interface though. > Dan pointed out the unmanagedstruct.pmc which but I fail to see how > that would help me, I think we need an external API for stashing raw > pointers. unmanagaged struct isn't finished yet. But extending the switch statements by an enum_type_ptr case is really simple. library/libpcre.imc has an example to get match results via an unmanagedstruct PMC. > Arthur leo
Tinderboxens
Hi, I just took the time and looked through the failing tinderboxens: - sprite and ariete: They have an old dynoplibs/Makefile lying around, which leads to a failing MANIFEST check. Solution: just remove dynoplibs/Makefile. - adrastea Conflict in MANIFEST, which lets Configure.pl fail, and the Makefiles are not regenerated. Solution: Remove conflicts in MANIFEST - Irresolute (FreeBSD) Configure is failing: Determining some sizes...Linker failed (see test.ldo) at lib/Parrot/Configure/Step.pm line 181. Question: what says test.ldo - Irresolute (Windows) Fails in compiling jit_cpu.c: with d:\cvsprojects\parrot\src\jit_cpu.c(95) : error C2065: 'RTYPE_COM' :undeclared identifier hidden a huge bunch of warnings. Does JIT work on windows? Maybe it works if configured with --jitcapable=0 BTW: It does make but nmake test and make seems to fail right away. - actinium This is a harder error: # Failed to build 't/src/extend_1.o': "./include/parrot/extend.h", line 76.23: 1506-120 (S) Function cannot return a const qualified type. # "./include/parrot/extend.h", line 78.23: 1506-120 (S) Function cannot return a const qualified type. # Failed test (t/src/extend.t at line 7) The offending code section is: const Parrot_CharType Parrot_find_chartype(Parrot_INTERP, char*); Parrot_Language Parrot_find_language(Parrot_INTERP, char*); const Parrot_Encoding Parrot_find_encoding(Parrot_INTERP, char*); It seems like AIX does not like functions returning a const variable even though its a void *. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Tinderboxens
On Mon, 27 Oct 2003, Juergen Boemmels wrote: > Hi, > > I just took the time and looked through the failing tinderboxens: > - sprite and ariete: I've cleaned out the sprite tinder directories, so we'll see what happens. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Tinderboxens
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, October 27, 2003 11:01 AM > To: Perl6 Internals > Cc: Dan Sugalski; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Tinderboxens > > - actinium > This is a harder error: > # Failed to build 't/src/extend_1.o': > "./include/parrot/extend.h", line 76.23: 1506-120 (S) > Function cannot return a const qualified type. > # "./include/parrot/extend.h", line 78.23: 1506-120 (S) > Function cannot return a const qualified type. > # Failed test (t/src/extend.t at line 7) > The offending code section is: > const Parrot_CharType Parrot_find_chartype(Parrot_INTERP, char*); > Parrot_Language Parrot_find_language(Parrot_INTERP, char*); > const Parrot_Encoding Parrot_find_encoding(Parrot_INTERP, char*); > It seems like AIX does not like functions returning a const variable > even though its a void *. I supplied a fix for this; see RT ticket #24247 for a full explanation of the general problem. Seems it never made it to the list, so I've attached a new patch for current CVS. The other problematic test is ye olde -0 error, which Dan seemed to think was best left failing for the time being. A simple fix to make the test pass is attached to RT #24088. -Adam extendtype.patch Description: extendtype.patch
Re: Tinderboxens
Hi all, > - Irresolute (Windows) > Fails in compiling jit_cpu.c: with > d:\cvsprojects\parrot\src\jit_cpu.c(95) : error C2065: 'RTYPE_COM' :undeclared identifier > hidden a huge bunch of warnings. > Does JIT work on windows? > Maybe it works if configured with --jitcapable=0 > BTW: It does make but nmake test and make seems to fail right away. Just checked into all of this and no, things are not at all good on Win32 - warnings galore. It does work with --jitcapable=0, but it used to work without that. How long it's been broken I can't say - I have just started uni, and haven't had as much time as I would have liked to follow things on parrot. The errors making JIT fails with include:- jit_cpu.c(95) : error C2065: 'RTYPE_COM' : undeclared identifier jit_cpu.c(149) : error C2065: 'EXEC_CALLDISP' : undeclared identifier The warnings mostly all take this kinda form:- jit_cpu.c(318) : warning C4305: '=' : truncation from 'const long ' to 'char ' jit_cpu.c(319) : warning C4305: '=' : truncation from 'const int ' to 'char ' There are also various other warnings of a similar nature in non-JIT stuff (but not so many) and a few "unreferenced local variable" warnings. As for tests:- Failed TestStat Wstat Total Fail Failed List of Failed --- t\src\extend.t1 256121 8.33% 11 t\src\io.t2 512162 12.50% 9-10 3 subtests skipped. Failed 2/9 test scripts, 77.78% okay. 3/59 subtests failed, 94.92% okay. NMAKE : fatal error U1077: 'F:\Perl\bin\perl.exe' : return code '0xff' Stop. Here's one of them:- t\src\extend..NOK 11# got: 'in sub1 # hello in sub2 # back # back # ' # expected: 'in sub1 # back # hello in sub2 # back # ' And the others:- t\src\io..NOK 9# Failed test (t\src\io.t at line 242) # got: '"temp.file" ">" should have opened # "temp.file" ">>" should have opened # "temp.file" "+<" should have opened # "temp.file" "+>" should have opened # "does_not_exist" ">>" should have opened # "does_not_exist" "+<" should have opened # "does_not_exist" "+>" should have opened # done # ' # expected: 'done # ' # Failed test (t\src\io.t at line 293) t\src\io..NOK 10# got: 'should have read "." not ".?2"done # ' # expected: 'done # ' If anyone wants to see all the errors, let me know. It's kinda long so I didn't wanna send it straight to the list. Hope this helps, Jonathan
Using extend.h to create a specific PMC
Hi, Quick question, is it possible to create a specific type of PMC using extend.h? Arthur
Storing external data in PMCs
Hi, So I am currently trying to do a Perl5LVALUE pmc, a stumbling block is however that I need to pass the PMC the thing that it is lvalueling, I was planning to use the pmc data field for storing this but I cannot access it as a extender without violating the API and guessing at layouts which is kind of bad (Dan says so ;) Arthur
Re: Storing external data in PMCs
At 02:56 PM 10/27/2003 +, Arthur Bergman wrote: So I am currently trying to do a Perl5LVALUE pmc, a stumbling block is however that I need to pass the PMC the thing that it is lvalueling, I was planning to use the pmc data field for storing this but I cannot access it as a extender without violating the API and guessing at layouts which is kind of bad (Dan says so ;) I don't know Perl5 internals enough to know exactly what Perl5LVALUE does. Do you want a way to pass a value to the PMC and let the PMC type morph itself based on the data representation? -Melvin
Re: Storing external data in PMCs
On Monday, October 27, 2003, at 03:26 pm, Melvin Smith wrote: At 02:56 PM 10/27/2003 +, Arthur Bergman wrote: So I am currently trying to do a Perl5LVALUE pmc, a stumbling block is however that I need to pass the PMC the thing that it is lvalueling, I was planning to use the pmc data field for storing this but I cannot access it as a extender without violating the API and guessing at layouts which is kind of bad (Dan says so ;) I don't know Perl5 internals enough to know exactly what Perl5LVALUE does. Do you want a way to pass a value to the PMC and let the PMC type morph itself based on the data representation? -Melvin An lvalue holds usually a function, and when set is called that function is called. So no morthing required at all! For example: perl -le '$foo = hi; $bar = \substr($foo,1); print "$bar-$foo"; $$bar = "b"; print "$bar-$foo"'; LVALUE(0x513ec)-hi LVALUE(0x513ec)-hb so the reference points to a lvalue which has a reference to $bar and a special function on the set to actually execute the substr. The reason I am starting with this is that it is so obscure that it is hardly used anywhere and is limited to a few small areas in the core making it a good testing ground. Arthur
Re: Storing external data in PMCs
In this case I assume the function can either be Perl5 or Parrot? Sounds like a custom PMC to me. Given the PMC that could stash function pointers and correctly dispatch gets/sets you have the option of writing a PNI method for setting the stashed routine from C or we have to add a call to the extension API to stash a raw pointer. -Melvin Arthur Bergman <[EMAIL PROTECTED]> 10/27/2003 10:35 AM To: Melvin Smith <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject:Re: Storing external data in PMCs On Monday, October 27, 2003, at 03:26 pm, Melvin Smith wrote: > > At 02:56 PM 10/27/2003 +, Arthur Bergman wrote: >> So I am currently trying to do a Perl5LVALUE pmc, a stumbling block >> is however that I need to pass the PMC the thing that it is >> lvalueling, I was planning to use the pmc data field for storing this >> but I cannot access it as a extender without violating the API and >> guessing at layouts which is kind of bad (Dan says so ;) > > I don't know Perl5 internals enough to know exactly what Perl5LVALUE > does. Do you want a way to pass a value to the PMC and let the PMC > type morph > itself based on the data representation? > > -Melvin > > An lvalue holds usually a function, and when set is called that function is called. So no morthing required at all! For example: perl -le '$foo = hi; $bar = \substr($foo,1); print "$bar-$foo"; $$bar = "b"; print "$bar-$foo"'; LVALUE(0x513ec)-hi LVALUE(0x513ec)-hb so the reference points to a lvalue which has a reference to $bar and a special function on the set to actually execute the substr. The reason I am starting with this is that it is so obscure that it is hardly used anywhere and is limited to a few small areas in the core making it a good testing ground. Arthur
Re: Storing external data in PMCs
On Monday, October 27, 2003, at 04:44 pm, Melvin Smith wrote: In this case I assume the function can either be Perl5 or Parrot? Sounds like a custom PMC to me. Given the PMC that could stash function pointers and correctly dispatch gets/sets you have the option of writing a PNI method for setting the stashed routine from C or we have to add a call to the extension API to stash a raw pointer. -Melvin The function is a C function. And yes it is a custom PMC which I have already created. Dan pointed out the unmanagedstruct.pmc which but I fail to see how that would help me, I think we need an external API for stashing raw pointers. (I don't know what PNI is, but I assume it is to execute bytecode from C and I do not want to do that). Arthur
Re: Storing external data in PMCs
Apologies for the formatting of these replies, I'm at work with Lotus Notes. PNI (Parrot Native Interface) is for writing native extensions in C. So, what I meant is you can write a method for stashing a raw pointer with the API today (probably using char *). I'm not sure if it is your preferred method, and I understand your wariness of bytecode in this case. I was 1/2 asleep this morning on IRC when I suggested it, not understanding the case you were dealing with. You can see samples that Dan has played with such as ncurses somewhere in the examples area. (I'm still not saying you don't need API added to extend.h though, but I'd have to be very clear on what you are asking for...) -Melvin Arthur Bergman <[EMAIL PROTECTED]> 10/27/2003 12:09 PM To: Melvin Smith/ATLANTA/Contr/[EMAIL PROTECTED] cc: Melvin Smith <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED] Subject:Re: Storing external data in PMCs On Monday, October 27, 2003, at 04:44 pm, Melvin Smith wrote: > > In this case I assume the function can either be Perl5 or Parrot? > Sounds like a custom PMC to me. Given the PMC that > could stash function pointers and correctly dispatch gets/sets > you have the option of writing a PNI method for setting the stashed > routine from C or we have to add a call to the extension API to stash a > raw pointer. > > -Melvin > The function is a C function. And yes it is a custom PMC which I have already created. Dan pointed out the unmanagedstruct.pmc which but I fail to see how that would help me, I think we need an external API for stashing raw pointers. (I don't know what PNI is, but I assume it is to execute bytecode from C and I do not want to do that). Arthur
Re: Storing external data in PMCs
On Monday, October 27, 2003, at 05:20 pm, Melvin Smith wrote: Apologies for the formatting of these replies, I'm at work with Lotus Notes. PNI (Parrot Native Interface) is for writing native extensions in C. So, what I meant is you can write a method for stashing a raw pointer with the API today (probably using char *). I'm not sure if it is your preferred method, and I understand your wariness of bytecode in this case. I was 1/2 asleep this morning on IRC when I suggested it, not understanding the case you were dealing with. You can see samples that Dan has played with such as ncurses somewhere in the examples area. (I'm still not saying you don't need API added to extend.h though, but I'd have to be very clear on what you are asking for...) -Melvin I just want to be able to say Parrot_PMC_attach_data(Parrot, PMC, *void); so the PMC code can get to it Arthur
[PATCH] Clear up some of the Win32 warnings
Hi, The attached patch fixes [1] some of the warnings given when compiling on Win32, namely:- ops/io.ops(497) : warning C4244: 'function' : conversion from 'long ' to 'unsigned short ', possible loss of data ops/string.ops(59) : warning C4244: '=' : conversion from 'long ' to 'char ', possible loss of data Jonathan [1] Whether it fixes them in the Right Way is a different matter. ;-) opsfix.diff Description: Binary data
Re: Halloween release
On Mon, 27 Oct 2003, Dan Sugalski wrote:
> On Mon, 27 Oct 2003, Andy Dougherty wrote:
>
> > On Thu, 23 Oct 2003, Dan Sugalski wrote:
> >
> > Determining if your C library has setenv / unsetenv...Use of uninitialized value
> > in string ne at (eval 21) line 91, chunk 10.
> > (no) done.
>
> I think this might have something to do with #3:
Turns out not. What's partly confusing is buffering. Since stdio and
stderr are buffered differently, it turns out that the error did not
appear near the thing that was triggering it.
Specifically, the problem is ${inline} in config/gen/feature_h/feature_h.in
if (${inline} ne '') {
# . . .
}
but config/auto/inline.pl does
if ($test) {
Configure::Data->set(
inline => $test
);
}
i.e., there is no 'else' clause.
I think the best fix is simply to unconditionally set inline:
diff -r -u parrot-current/config/auto/inline.pl parrot-andy/config/auto/inline.pl
--- parrot-current/config/auto/inline.plFri Oct 24 04:40:44 2003
+++ parrot-andy/config/auto/inline.pl Mon Oct 27 16:51:46 2003
@@ -41,9 +41,7 @@
}
}
-if ($test) {
- Configure::Data->set(
- inline => $test
- );
-}
+Configure::Data->set(
+ inline => $test
+);
}
Tracking this would have been easier with the following patch:
--- parrot-current/Configure.pl Thu Sep 25 19:00:25 2003
+++ parrot-andy/Configure.plMon Oct 27 16:52:58 2003
@@ -16,6 +16,8 @@
use Parrot::BuildUtil;
use Parrot::Configure::RunSteps;
+$| = 1;
+
$parrot_version = parrot_version();
@parrot_version = parrot_version();
--
Andy Dougherty [EMAIL PROTECTED]
[PATCH] Get rid of (most) Win32 JIT Warnings
Hi, Spent a little time looking into the source of all the JIT warnings on Win32. It appears the MS VC++ compiler is emitting warnings on lines like this:- *(pc++) = 0x8b; Which look something like:- warning C4305: '=' : truncation from 'const int ' to 'char ' Changing these lines to:- *(pc++) = (char) 0x8b; e.g. explicitly casting to a char, clears up the warnings. I've managed to track down the vast majority of these and put the casts in. I've missed a few (and try as I might, I can't find them), but 60 warnings is somewhat better than 2500. :-) I've attached the diff for the changes. Please note - this does not fix JIT, it's still broken because:- src\jit_cpu.c(95) : warning C4013: 'Parrot_exec_add_text_rellocation' undefined; assuming extern returning int src\jit_cpu.c(95) : error C2065: 'RTYPE_COM' : undeclared identifier src\jit_cpu.c(149) : error C2065: 'EXEC_CALLDISP' : undeclared identifier src\jit_cpu.c(166) : error C2065: 'RTYPE_DATA' : undeclared identifier I don't know the system well enough to know where to start looking for these, so I'll leave that to somebody far wiser than I. ;-) As always, hope this helps. Jonathan jitemith.diff Description: Binary data
Re: Alternately named arguments
On Sunday, October 26, 2003, at 05:05 PM, Damian Conway wrote: Err, no. Or at least: "Please, No!". ;-) That would certainly be a way cool abbreviation, but I suspect it would be a Very Bad Idea for unary plus to have two unrelated meanings out in the actual code. I suspect that the "named-only" markers are only available within actual parameter lists. Damian Welcome back, Damian. Lo, how we've missed you and Larry these many long months! Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://www.kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: Alternately named arguments
David Wheeler wrote: Welcome back, Damian. Lo, how we've missed you and Larry these many long months! Thanks to everyone for the warm welcome. Just to give you an update, I've be ill too (nothing nearly as serious as Larry...just a mild influenza and a little light pneumonia ;-) and I've also been busy attempting to earn a living. I'm close to a first draft of Exegesis 7 (on formatting), including a module implementing the full functionality. And then I'm looking forward to working with Larry and the rest of the Design Team on Apocalypse/Exegesis 12 (Objects), when Larry is well enough to do so. I've made no further progress on Perl6::Rules, though I did but in a TPF grant application for a few month's support to let me finish it. I will of course continue working on the module in any case, but only *very* slowly since it will have to be shoe-horned between design, module maintenance, and various income-earning activities. Meanwhile, we should continue to bear in mind how much *has* already been achieved. Whilst I was on my most recent speaking tour I had the opportunity to give several updated versions of my Perl 6 talk (including the marathon 6-hour version). And once again it brought home to me just how far we've come and how elegant and powerful the result is. We ought to have a: Perl 6: Worth waiting for! t-shirt, because it truly is. :-) Damian
Brass Parrot
Here's a suggestion for some upcoming release: Brass Parrot. http://www.avonpage.com/brassparrot.html http://usvi.diningguide.net/data/d100132.htm Maybe a deep-winter release, so us folks in the Northern hemisphere can think pleasant tropical thoughts about St. Croix... Regards, -- Gregor -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: NULL Px proposal (was Re: [BUG] IMCC looking in P3[0] for 1st arg)
On Oct 26, 2003, at 10:39 AM, Melvin Smith wrote: I think a compromise would be to do define a interpreter global PMCNull and point (or init) all Px registers to it. ... The downside is fast initialization of register blocks. memsetting with NULL (0) will not be possible, but I'd have to actually go check and see if that is really all that common. If we determine that it makes a difference, we can store away a register block filled with our PMCNull, and memcpy (or memmove) from that to initialize a block. Should be nearly as fast. JEff
Re: NULL Px proposal (was Re: [BUG] IMCC looking in P3[0] for 1st arg)
At 05:28 PM 10/27/2003 -0800, Jeff Clites wrote: On Oct 26, 2003, at 10:39 AM, Melvin Smith wrote: I think a compromise would be to do define a interpreter global PMCNull and point (or init) all Px registers to it. ... The downside is fast initialization of register blocks. memsetting with NULL (0) will not be possible, but I'd have to actually go check and see if that is really all that common. If we determine that it makes a difference, we can store away a register block filled with our PMCNull, and memcpy (or memmove) from that to initialize a block. Should be nearly as fast. If the obvious were a truck, I'd be dead. Thanks for pointing that out. :) Luckily we init registers with a for loop so there won't be any change. Either way it won't affect the opcode loop (or will barely). -Melvin
[COMMIT] Parrot catches null Px register access
Just in time for the "screamin' punkin" release I've patched in a quick and dirty implementation of the previous discussion regarding Parrot segfaulting on access to a null register. Of course, HLL compilers shouldn't generate code that results in an uninitialized Px register, but we would like to do something more elegant than just dump core. You'll have to edit interpreter.h and set PARROT_CATCH_NULL to 1 to enable it. The patch adds the Null PMC class, only instantiated once in system memory. PMC register banks are set to PMCNULL now. The null op returns PMCNULL as well. Also patched it into extend.c so extension writers can get at it. I didn't turn it on by default yet as we need to check over the code to see where assumptions are being made about PMC pointers just being NULL. However, all tests pass except the pmc create test (you can't do a new .Null). This is good enough to start, I think. We should also integrate the null.pmc generation into pmc2c or pmc2c2. -Melvin
Re: #define version obj.version is a kind of generic thing
On Oct-27, Leopold Toetsch wrote: > Arthur Bergman <[EMAIL PROTECTED]> wrote: > > > include/parrot/pobj.h:# define version obj.version > > Sorry for that :) We can AFAIK toss the version part of a PObj. Its > almost unused and hardly needed. It could be renamed too inside parrot. I'm the guilty one who added the version field (though back then, it was added to a Buffer object, IIRC). I found it very helpful in debugging GC problems -- I would have a problem where memory was being stomped on, and trace it back to a prematurely freed and reused header. But in order to figure out what was going on, I needed to trace it back to the point of allocation of the header, but headers get reused so frequently that setting a conditional breakpoint on the address of the header was useless. So I added in the version number to provide something to set a breakpoint on. It is very possible that this is no longer useful; I haven't been working on stuff where I have needed it for long enough that the code has mutated significantly. Is it still useful? If not, then go ahead and rip it out.
Wrapping C/C++ libraries
I am not sure if this is the correct place to ask this, so please point me to correct direction if it is not. As far as I know, there is no "native" way of calling C/C++ libraries from within Perl 5. When C/C++ API involves structures, the corresponding Perl binding uses hashes, and an intermediate step converts the hash to a structure, and call the C program with the converted structure. An example of an elegent system which does this is in gtk2-perl (http://gtk2-perl.sourceforge.net). Muppet, please correct me if I am wrong here. Interfacing C/C++ libs this way involves creation of intermediate structures that duplicates lots of data. (Reminds me the the page cache and buffer cache of the old Linux kernels.) Obviously, Perl can't convert a hash to a structure, because the structure of the structure is not known, although it is a structure ;-) But if the structure of the structure _is_ known, then there is the possibility of kind of "rearranging" the hashes and calling the C/C++ library without duplicating the related data to a seperate structure. I like to get involved in the parrot/perl6 development, and was just wondering if this is something to work on. Anuradha -- http://www.linux.lk/~anuradha/
Re: How?
Thank you, I read them more deeply.. Dmitry - Original Message - From: Leopold Toetsch To: Dmitry Nikolayev Cc: [EMAIL PROTECTED] Sent: Monday, October 27, 2003 6:39 PM Subject: Re: How? Dmitry Nikolayev <[EMAIL PROTECTED]> wrote: > Hello > How can I be involved in the project? Maybe, some help is needed? What would you like to contribute? Help is always welcome. Did you read the docs (either at parrotcode.org or in the src? intro.pod has a "Getting involved" chapter. There is a TODO file too. If unsure, where to start, try writing some tests: You can learn Parrot assembly and see how things are working. > Dmitry Nikolayev leo
Re: Wrapping C/C++ libraries
On Tue, 2003-10-28 at 11:24, Anuradha Ratnaweera wrote: > > As far as I know, there is no "native" way of calling C/C++ libraries > from within Perl 5. When C/C++ API involves structures, the > corresponding Perl binding uses hashes, and an intermediate step > converts the hash to a structure, and call the C program with the > converted structure. An example of an elegent system which does this is > in gtk2-perl (http://gtk2-perl.sourceforge.net). Muppet, please correct > me if I am wrong here. Just another quick, and possibly dumb, question: Is XS the standard way of binding Perl to a C/C++ library? Anuradha -- http://www.linux.lk/~anuradha/
