Re: [perl #801] [PATCH] PerlArray in scalar context
Joshua Hoblitt via RT [EMAIL PROTECTED] writes: Isn't this a semantics issue that needs to be resolved via p6l? It is however a design issue so I'm passing the buck to Chip to make a call about this. Parrot/perl6 was completely different then, so this bug should be marked irrelevant or something. /s
Re: [perl #16935] [PATCH] more regex stack manipulation
Joshua Hoblitt via RT [EMAIL PROTECTED] writes: Since the rx_* ops are on the chopping block is there any objection to closing this bug? No objection from me. Actually, I'm not an active Parrot developer now, and don't see myself becoming one again in the near future, so you can probably assume that I don't have objections to closing out my old bugs. /s
Re: Namespaces, part 1 (new bits)
At Sat, 25 Sep 2004 00:53:25 -0400, By the way, this isn't the list for it, but it would be cool if perl6 had an interactive mode as good as python's. It's one of the few places I think python has a compelling lead. I'm sort of partial to: perl -MTerm::ReadLine -le '$t = new Term::ReadLine; print eval while $_ = $t-readline( );' Other than having to retrain yourself not to use my (because you don't get lexicals across promps), it's not that bad. Or, if you're an Emacs user and don't mind a few rough edges: http://search.cpan.org/~seano/sepia-0.57/ /s
Re: Numeric semantics for base pmcs
At Tue, 24 Aug 2004 15:19:52 -0400, Dan Sugalski wrote: At 11:47 AM -0700 8/24/04, Sean O'Rourke wrote: At Tue, 24 Aug 2004 13:33:45 -0400, Dan Sugalski wrote: 7) Strings are treated as floats for math operations I think we can do better than this by first converting a string to the least reasonable numeric type (with int float bignum), then re-dispatching to the appropriate numeric x numeric operation. Always treating strings as floats means we lose both when 2+3 != 2+3 and when one of the strings is too large to be a floating-point number. Also, doing this redispatch means that the printed and internal representations of numbers will always behave the same way. I'm still not sure about doing dynamic down-typing (or whatever it's called) to get the tighest possible type. I'm getting the distinct feeling that it's what most people want, though. :) This doesn't have to involve dynamic down-typing, only a string-to-numeric converter that returns the most specific type. After that, operations between two numeric objects are welcome to do whatever they want. I actually agree with you that it's just not worth it to check for possible down-conversions. /s
Re: register allocation
[EMAIL PROTECTED] (Leopold Toetsch) writes: The interference_graph size is n_symbols * n_symbols * sizeof(a_pointer). This might already be too much. 2) There is a note in the source code that the interference graph could be done without the N x N graph array. Any hints welcome (Angel Faus!). It looks like the way things are used in the code, you can use an adjacency list instead of the current adjacency matrix for the graph. If interference is typically sparse, which I think it should be, this is a win. So Dan -- while you're in there with the debugging statements, you might also want to keep a count of how many registers interfere with each other. /s
one shootout result
fib_native_nopcc.pasm Description: Binary data fib_native.imc Description: Binary data fib_pmc.imc Description: Binary data
Re: one shootout result
fib_native.imc Description: Binary data
Re: Some PIR How do I? questions
At 5:38 PM + 11/27/03, Pete Lomax wrote:
At 12:02 PM 11/27/2003 +, Pete Lomax wrote:
Perl6 already does interpolation without special support from IMCC.
I'll rephrase. Is there anything knocking about which would help with
eg:
printf (pFile, Amount %12.3f [%-10.10s]\n,balance,name);
Also, interpolation and (printf-style) formatting are completely
different beasts. Just think of interpolation as fancy syntax, or as
a mini-language:
$x and @y and @{[something()]}
becomes
stringify($x).' and '.stringify(@y).' '.stringify(something())
inside the compiler. P6C rips apart strings inside the parser and
outputs code for the above. Since this translation will be different
for every language, I don't think there's much code that can be
shared.
/s
Re: [perl #24403] [PATCH] Force Perl6's make test to use perl6 rather than prd-perl6
Thanks. 'bout time, I suppose, since even _I_ have stopped using
prd-perl6.pl...
/s
[EMAIL PROTECTED] (Joseph F . Ryan) writes:
# New Ticket Created by Joseph F. Ryan
# Please include the string: [perl #24403]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=24403
Just a simple consistancy patch; as perl6 itself becomes more complex,
there is a greater chance of a program running differently compared
to prd-perl6.
- Joe
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/67019/50015/e2e3d9/TestCompiler.diff
--- parrot/languages/perl6/P6C/TestCompiler.pm~ Sun Nov 2 15:06:26 2003
+++ parrot/languages/perl6/P6C/TestCompiler.pmSun Nov 2 15:06:26 2003
@@ -59,7 +59,7 @@ sub generate_pbc_for {
my $pbc_f = Parrot::Test::per_test('.pbc',$count);
my $parrot = ..$PConfig{slash}..$PConfig{slash}parrot$PConfig{exe};
-Parrot::Test::_run_command($PConfig{perl} prd-perl6.pl --batch=$p6_f --imc,
'STDOUT' = $imc_f, 'STDERR' = $err_f);
+Parrot::Test::_run_command($PConfig{perl} perl6 $p6_f --imc, 'STDERR' =
$err_f);
Parrot::Test::_run_command($parrot -o $pasm_f $imc_f, 'STDERR' = $err_f);
my $pasm;
{
Re: [perl #24391] [PATCH] P6C closures use 'newsub' instead of assigning integer address
thanks, applied. /s
Re: [perl #24392] [PATCH] P6C xor really does return a value
applied thanks. /s
Re: P5 B backend for languages/perl6 - quasi-announcement
[EMAIL PROTECTED] (Scott Walters) writes: I have work-related reason to add a B backend for Perl 5 to the perl6 compiler. I'm looking at creating an assembler for Perl 5's B bytecode along the lines of IMCC, and creating patches against languages/perl6/IMCC.pm and languages/perl6/IMCC/* to conditionally, using some sort of phrasebook, generate assembly for either Parrot or B. This would involve some nontrivial refactoring, since both are unashamedly machine-dependent, and freely emit blocks of assembly directly from the AST walk. Unless B assembly is a lot like parrot assembly, simply replacing (or factoring out) these chunks might not be the best way. Of course, I've never used B assembly, so discount this impression appropriately. Everything up to IMCC* (i.e. parsing, tree munging, and context (wannabe typing)) should be fine, though. The B assembler would use B::Generate to build up a bytecode tree, and then B::Deparse to dump P5 or else more likely dump the raw bytecode and use ByteLoader to suck it back in. Far be it from me to discourage you, but IMHO languages/perl6 is less complete and correct than the rest of Parrot. However, while the grammar reflects an older incarnation of Perl 6, it's written in fairly clean Parse::RecDescent, and it is ahead of the code generation in terms of completeness. You might be better off both performance-wise and other-wise either: 1. just using Parrot to run the subset of perl6 you need; or 2. using the languages/perl6 parser to translate directly to Perl 5. Since the languages are similar in a lot of ways, this should not be too hard in most cases (and very painful in a few), and since languages/perl6 doesn't do any optimization, you're not losing anything. This should have been posted to perl6-language, but I'm not subscribed there. This is probably internals, since it doesn't concern language design. Let me know if you have any other questions. /s
Re: Pondering argument passing
Leopold Toetsch [EMAIL PROTECTED] writes: Luke Palmer [EMAIL PROTECTED] wrote: Okay, considering that it's hard to pack registers into an array, and that it's easy to unpack an array into registers (in the context of signatures), why don't we make the unprototyped calling conventions just to pass everything in the overflow array? (Hmm, I think I remember saying this before... sorry if I'm repeating myself) This doesn't help for flattening (splat) function call arguments: f([EMAIL PROTECTED], [EMAIL PROTECTED]) repacking everything (at runtime!) into P3? Yes. It seems to me that this is exactly what has to happen, at least conceptually. Luke's point is clearest when considering how to implement a Perl5-style sub with a variable number of arguments. If args are passed in an array, they're all clustered together and easily handled by a for-loop (or assembly equivalent). If they're passed in registers, you have to have a huge, nasty switch statement at the start of the function like so: if $nargs == 0 goto done # handle P5 if $nargs == 1 goto done # handle P6 ... if $nargs == 10 goto done # handle overflow And that's just not pleasant. And what if the call is: f([EMAIL PROTECTED], $b, $c) I'm not understanding your point here -- wouldn't this create an array [EMAIL PROTECTED]@a[n], $b, $c] in P3, just like the above? Steve -- As I see it, prototypes have two functions: (1) catching wrong-arguments errors at compile time, and (2) (perhaps) allowing for faster parameter passing. Since the second's really just an optimization, I'd suggest skipping it for the time being, doing the syntactic checking during compilation, but then passing everything in P3. This also gives us a baseline against which to benchmark prototyped passing. It's not clear to me a priori that it can be reasonably used often enough to actually be faster. /s
Re: cvs commit: parrot/languages/imcc/t/syn pcc.t
Leopold Toetsch [EMAIL PROTECTED] writes: Gordon Henriksen [EMAIL PROTECTED] wrote: | A C D E G I| | N S T V| WTF ... Hangman -- the goal is to guess the letters of a word or phrase, and unguessed letters are represented as _s (like ge_n_ic_ic). /s
Re: Problems building perl6 (perl version dependency?)
Andy Dougherty [EMAIL PROTECTED] writes:
So the problem is actually a dependency on a module not shipped with
perl5.00503.
This problem's been around a while -- I know I've reported it before. Is
it time to give up on 5.00503? I will retest with 5.8.x, but the
compilation takes a *long* time.
I'm not personally a fan of 5.005 compatibility, but it looks to me
like the use charnames was gratuitous, since charnames is already
being used inside the nearby eval. Does this fly?
/s
*** String.pm.~1.6.~Sun Mar 16 01:02:08 2003
--- String.pm Mon Sep 15 09:07:00 2003
***
*** 216,222
error (Error in interpolation of control-char: $@),die if $@;
}
else {
- use charnames qw(:full);
# The charnames doesn't seem to propagate into the eval
# for me -- sfink
$val = eval qq[use charnames qw(:full); \\N{$_}];
--- 216,221
Re: mission haiku
Nicholas Clark [EMAIL PROTECTED] writes: Perl internals slow, nigh on unmaintainable. So we write parrot. Parrot: not just Perl but punctuated prowess perfected -- Befunge. /s
Re: [CVS ci] PackFile-15: print warning location
Benjamin Goldberg [EMAIL PROTECTED] writes:
I like the ideas of a range of characters, and of variable amount of
information. So, how about multiple setline variants?
setline Ix # all code from here to the next set{line,file} op is line
x
setline Ix, Iy # set line,col number from here to next set* op.
setline_i Ix # the next line is x, each succeeding line increases.
setlinerange Ix, Iy # the following represents lines x..y of hll
code.
setlinerange Ix, Iy, Iz, Iw # line x, col y .. line z, col w.
setdim Ix # sets number of dimensions for subsequent code
setvel Px # set code velocity (general setline_i; Px is an Array)
Just making sure Parrot debug info can support Jerome's trefunge
interpreter.
/s
Re: Registers vs. Stack
Tom Locke [EMAIL PROTECTED] writes: p.s. (and at the risk of being controversial :) Why did Miguel de Icaza say Parrot was based on religion? Was it realted to this issue? Why is he wrong? IIRC it is -- his take is that stack VM code provides useful information about variable lifetimes, which can help the JIT produce good code. If everything's jitted, then his contention is that bytecode opcount doesn't matter that much. I'm not going to stick my neck out and offer a technical opinion, but I'll just note that religion has been the driving force behind some great things in the past -- witness Europe's cathedrals ;). Oh, wait... we're supposed to be the bazaar. /s
Re: hash access
Leopold Toetsch [EMAIL PROTECTED] writes: We have keyed_int shortcuts to get/set items on array like aggregates. Is there a reason, that we not have keyed_str to access hash elements by STRING directly. I'm not so sure this would be worth it; since hash lookups are much more expensive than array indexing, the gain from avoiding a wrap/unwrap won't be nearly as significant. Of course the only way to tell would be to do some benchmarks, but it seems to me like ops and optimization time could better be spent elsewhere. /s
Re: languages using parrot
Leopold Toetsch [EMAIL PROTECTED] writes: What about one subdir per language under languages containing at least a README with a pointer to the author(s) webpage. How about just a single languages/OTHER or some such (maybe in doc/ instead) with this information? Adding extra directories may imply that we want these languages to become part of the standard Parrot distribution. While this will be true of some, some languages will no doubt always be distributed separately. /s
Re: there's no undef!
Benjamin Goldberg [EMAIL PROTECTED] writes:
There's no way, in this program, for $x to be out of scope while $y is
in scope.
But we're in Perl6(66)-land, where delete caller.MY{'$x'} and
delete %OUTER::x (sp?) can wreak havoc on your pad from all
sorts of strange places. It ain't moral, but it sure is legal.
/s
Re: keyed vtables
Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: And semantic differences--don't forget those. A keyed add vtable doesn't help to provide more semantics. The set vs assign thread applies here too. On the contrary: to provide all semantics you would need add_set_p_k_p_k_p_k and add_assign_p_k_p_k_p_k and possibly add_clone_p_k_p_k_p_k. If I'm on target, what Dan's trying to avoid is having to create magic proxy objects for autovivification. If this is all we want out of keyed ops, then we can get it more cheaply by only adding keyed variants for the _out_ parameters of each op. That way the standard get_*_keyed ops can either return NULL, return a new PMC without insertion, or insert and return a new PMC for read parameters, while the *_pk_*_* ops can do the right thing with respect to autovivification. No temporary keys or null keys need be created. I think this covers the semantics. Beyond that, it's just a matter of performance -- extra opcodes vs. extra ops -- that we can fight out in the benchmark arena. /s
Re: [perl #23346] [PATCH] docs/running.pod: command line arguments
Kenneth A Graves (via RT) [EMAIL PROTECTED] writes: Should the word argv be explicitly mentioned, or is command line arguments clear enough? Thanks, applied (w/ mention of argv). /s
Re: [PATCH] imcc vim syntax file
Luke Palmer [EMAIL PROTECTED] writes: FWIW, here's my personal imcc syntax highlighting file for vim. I've found it very useful in reading imc code (but then, I'm very attached to my syntax highlighting). Auto-generated editor configuration? Cool... I'm still not sure how to add new files with cvs diff, so I used a normal diff against /dev/null. `-N' Applied, /s
Re: getprop and find_lex?
Michal Wallace [EMAIL PROTECTED] writes: I expected getprop to behave like find_lex and throw an exception if the property doesn't exist, but it doesn't: Are you sure that properties are what you want to use here, rather than attributes (via get_pmc_keyed() or similar)? IIRC parrot's properties are supposed to support out-of-band data like Lisp's plists or Perl 6 properties (http://dev.perl.org/perl6/apocalypse/2#properties) /s
Re: pirate 0.01 ALPHA!
Michal Wallace [EMAIL PROTECTED] writes: Tadaa! /me blinks at the list comprehensions. Cool stuff. test_microthreads failed for some reason I still need to look into, but there's a lot of cool stuff working already. Time for Dan to begin thinking about which direction the pie will fly. /s
Re: Calling parrot from C?
Luke Palmer [EMAIL PROTECTED] writes: How does one call a parrot Sub from C and get the return value(s)? I'd vote for stuffing args into the interpreter, calling the sub's invoke() method, then digging through the registers to pull out the return values (see e.g. Parrot_pop_argv in method_util.c, which may be outdated). Then again, it would be _your_ pain, not mine ;). /s
Re: pirate status / need help with instances
K Stol [EMAIL PROTECTED] writes: I may be wrong, but where should the class be stored? The newclass op has an out-parameter where the newly created class is stored. Invoke doesn't have that. (right?) Presumably it would just return the new object like an ordinary function call. /s
Re: why new_pad *INT*?
Michal Wallace [EMAIL PROTECTED] writes: Okay, I definitely need some help understanding this. Okay, I definitely did a suboptimal job trying to clarify... Here's some python code that defines a closure: def make_adder(base): def adder(x): return base+x return adder h = make_adder(10) print h(5) When I run this in python 2.2, it prints 15. When I run it through pirate, I get this: -scratch_pad: too deep Now, in my mind: depth 0 has: make_adder, h depth 1 has: base, adder depth 2 has: x This sounds right. The top level .sub should start with 'new_pad 0' The make_adder .pcc_sub should start with 'new_pad 1' The adder .pcc_sub should start with 'new_pad 2' Right. I think the error happens because I'm calling a depth 2 function from depth 0, but if I change adder's new_pad depth to 1, it can't find base. I don't know how to get this to work the way I want. Can anyone help me out here? ... # make_adder from line 2 .pcc_sub _sub0 non_prototyped .param object base new_pad 1 store_lex -1, 'base', base setline 3 newsub $P1, .Sub, _sub1 The problem is that when adder() gets returned, it needs to remember the enclosing pad. So this needs to be newsub $P1, .Closure, _sub1 which (IIRC) will save the lexical environment in which it was created (see closure.pmc), then restore that when it is invoked. /s
Re: Approaching m4
Bernhard Schmalhofer [EMAIL PROTECTED] writes: I have started an implementation of m4 in PIR. The implications are staggering... Sure, plenty of compilers can bootstrap themselves, but how many can generate their own configure scripts via autoconf? With p4rrot, we may live to see this dream. /s
Re: pirate status / need help with instances
Michal Wallace [EMAIL PROTECTED] writes: Py-pirate can now handle: Cool... * make parrotclass handle invoke this strikes me as the most efficient, but I'm not really confident with C so I'm hesitant to try it This seems to me like the way to go, except you might subclass parrotclass to pythonclass (since this lack- of-new seems to be the Pythonic way). The C should pretty much just turn around and call pmc_new, then return the original return address that was passed in. /s
Re: why new_pad *INT*?
Michal Wallace [EMAIL PROTECTED] writes: 1. Should there be a new_pad that takes no arguments to do this, so we don't have to keep count manually? 2. When would you NOT want to use new_pad (current_depth+1) ? Remember, the pad depth reflects lexical scope nesting, not dynamic scoping. So if you mean current_depth as current compile-time depth above, then you're right, but the VM would have no way to tell. If you mean run-time depth, which the compiler could know about... A top-level sub should not create a new pad at depth + 1, since that would put it inside its caller's lexical scope, which would just be weird. /s
Re: parrot, win32, stand-alone distribution, separate Parrot maillist
Jonathan Worthington [EMAIL PROTECTED] writes: work something out. :-) However, Brent said If you mean precompiled binaries, not yet. Parrot is still under development, so we aren't shipping binaries., This doesn't make sense to me. People who don't like hacking C can still use a precompiled binary to hack in PASM or IMC. Heck, most of the languages in languages/* are written in Perl -- no whatsoever to configure and compile. /s
Re: [perl #23203] [PATCH] move languages/scheme to continuation passing style.
Jürgen Bömmels (via RT) [EMAIL PROTECTED] writes: # New Ticket Created by Jürgen Bömmels # Please include the string: [perl #23203] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=23203 Hello, this patch lies in my tree for month now, finally I got around to finish it up: ... Thanks, applied. /s
Re: PMC methods?
On 23 Jul 2003, Luke Palmer wrote: Instead of having a bunch of specialized ops made for constructing/working on specific pmcs, have, say, four general-purpose ops whose meaning could be given by each pmc that uses them. So, instead of, for instance, newsub, we'd make a new .Sub pmc and call the pmc1 op on it with the label. For a socket pmc, we'd call pmc1 to set the port, pmc2 to set the protocol, etc. One problem with this is that it hides errors, since you can mistakenly send a message to a different type of PMC and still have it be legal. How much do you think this would save over doing a single findmethod and caching the result? On the other hand, the profusion of special-purpose ops has been bothering me as well. I'm not sure where we're drawing the line between ops and methods. For example, should socket operations be ops, or methods on a core Socket PMC? I think the latter, but only because sockets don't seem as core as addition, not for any principled reason. Another example: why does interpinfo exist, rather than the interpreter just looking like a hash or array and using the standard keyed get/set ops? Do others (Dan? Juergen? Leo?) have some stronger sense of what should and shouldn't be an op? /s
Re: Event handling (was Re: [CVS ci] exceptions-6: signals, catch a SIGFPE (generic platform)
On Thu, 17 Jul 2003, Leopold Toetsch wrote: PC = ((op_func_t*) (*PC)) (PC, INTERP); // prederef functions To be able to switch function tables, this then should become: PC = ((op_func_t*) (func_table + *PC)) (PC, INTERP); Thus predereferncing the function pointer would place an offset into the function table, not an absolute address. Or is there a better way to do it? Replacing the next instruction with a branch to the signal handler (like adding a breakpoint) out of the question? Of course, if we're sharing bytecode this is expensive, since you'd have to do something like this: bsr handler ... handler: if cur_thread == thread_with_signal goto real_handler # replaced instruction ret which penalizes all other bytecode users. I guess it depends how common we expect signal handling to be. /s
Re: Event handling (was Re: [CVS ci] exceptions-6: signals, catch a SIGFPE (generic platform)
On Thu, 17 Jul 2003, Leopold Toetsch wrote: Replacing the next instruction with a branch to the signal handler (like adding a breakpoint) out of the question? I don't know, how to get the address of the next instruction i.e. the PC above. Going this way would either mean: - fill the bytecode segment with the handler opcode function or Yuck. - locate the PC on the stack or in registers (like %esi in CGP) The former seems rather expensive (at least if we heavily use events), the latter seems to be possible only per platform/compiler(-revision). For non-jit code, the latter seems doable if we can find a way to force registers back out to memory if necessary (short of declaring the PC volatile, which would just suck). The Boehm collector uses a platform-independent setjmp() hack to do this. For jit code, we know the jit PC reg, so it shouldn't be a problem. Of course, you should probably take this with a grain of salt with size inversely proportional to the amount of the solution I've coded. (An infinite grain in this case...) /s
Re: [CVS ci] hash iter: buggy initial try
On Sat, 5 Jul 2003, Leopold Toetsch wrote: This is a first attempt to iterate over hashes. The hash is scanned linearly, until the given integer index is found. Is there a better way to locate the next entry, either by an integer idx or by a key or some other means? It's constant time if you keep a bucket index and a pointer to the current hash bucket in the iterator (see e.g. hash.c:hash_clone()). /s
Re: [perl #22765] Unary '+' is not symmetric to unary '-' in languages/perl6
Looks good, except that this needs to make sure an int is being
returned, e.g.
+42- 42
+forty-two - 0
The lazy man in me would just shove it through an int reg, but that
loses precision if we go to bignums. Though for the moment I can't
think of a better way.
/s
+# unary plus.
+sub prefix_pos {
+my $x = shift;
+my $tmp = $x-args-val;
+my $res = newtmp;
+code(END);
+ $res = $tmp
+END
+return scalar_in_context($res, $x-{ctx});
+}
On Mon, 23 Jun 2003, Bernhard Schmalhofer wrote:
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #22765]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22765
Hi,
when playing with the stuff in 'languages/perl6', I noticed that code like
print( +42, \n );
didn't do the right thing. 'perl6' printed '42' but forgot about the \n.
The cause seemed to me that '+' isn't set up as an unary operator in
'P6C/Parser.pm'.
After adding '+' in 'Parser.pm' and in a couple of othe files, it now seems
to behave as expected.
On my Linux machine there are some other tests failing in t/compiler, but
these seem not to be related to unary '+'.
One of these failures is a 'inf' vs. 'Inf' issue.
A patch is attached.
CU, Bernhard
--
+++ GMX - Mail, Messaging more http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/59761/44242/d4c34a/prefix_pos.patch
Re: This week's summary
On Tue, 24 Jun 2003, Leopold Toetsch wrote: Piers Cawley [EMAIL PROTECTED] wrote: He's worried that the P6C tests break, ... albeit this is still an issue. Nobody answered, if we need another Sub class implementing the old invoke/ret scheme ... I'd say no. P6C is now compiling to an obsolete architecture. While we should all step back and be impressed at how well Intel has maintained backward compatibility in the x86, there's no particular reason we should do so ourselves. Rather, someone (me) needs to port P6C to the new machine. Whee! My first anniversary! Congrats and thanks for your great summaries. Seconded. /s
Re: [perl #21668] APL doesn't use sigils
On Mon, 24 Mar 2003, Benjamin Goldberg wrote: And what happens if a programmer wants to have two different variables, of two different types, with the same name, such as @data and %data? Without sigils, it cannot be done. Actually, if you squint, other languages are far ahead of Perl in this respect -- Hungarian notation! sData, aData, hData, ppiData, ... /s
Re: Rules and hypotheticals: continuations versus callbacks
On Wed, 19 Mar 2003, Matthijs van Duin wrote: (4) (internals) Given that Parrot has so many different control mechanisms (call/ret, exceptions, closures, continuations, ...), how do we maintain consistency? And how much of that is parrot's responsibility (versus the perl6 compiler's)? I don't think there will be a big problem with that, but maybe I'm just overlooking things. Exceptions, for example, will have to unwind dynamic bindings, stack frames, call user-defined exception handlers, etc. Using continuations for everything, this isn't a problem -- get it right once and it works everywhere (btw, languages/perl6 uses continuations for its exceptions now). However, they're much more expensive than normal sub calls, so we probably don't want to use them there. I'll let Dan talk about potential issues with throwing exceptions across languages, since he's given it much more thought than yours truly, /s
Re: Rules and hypotheticals: continuations versus callbacks
On Tue, 18 Mar 2003, Matthijs van Duin wrote: and maybe also: What is the current plan? although I got the impression earlier that there isn't any yet for invoking subrules :-) See line 1014, languages/perl6/P6C/rule.pm. The hack I used was to call rules like ordinary subs, and have them push marks onto the regex stack before they return. I'm not sure if this can be made to work with hypotheticals, and I'm sure it won't interact kindly with continuation-taking, but there's _something_. As for the interaction with continuations, I was about to post some of my concerns when I received your long and well-thought-out mail. I need to think about the discussion so far a bit more, but briefly: (1) There's more than one way to go when combining dynamically-scoped variables with continuations: for example, do you use dynamic bindings from where the continuation was taken, or from where it's invoked? (see e.g. Scheme's dynamic-wind). (2) (internals) The functional-language people have found that full continuations are slow, and put a lot of effort into avoiding them where possible. Backtracking languages like Icon and Prolog are implemented by special mechanisms rather than general continuations, probably for this reason. So if we're forced to do a regex engine using full continuations, it will probably be dog-slow (3) On the other hand, we probably want people to intermix regex backtracking, continuation-taking, and hypothetical/dynamic variables, and have it do the right thing, where right means something like mind-bendingly difficult to reason about, but consistent. How do we want these features to play with each other? (4) (internals) Given that Parrot has so many different control mechanisms (call/ret, exceptions, closures, continuations, ...), how do we maintain consistency? And how much of that is parrot's responsibility (versus the perl6 compiler's)? /s
Re: This week's Perl 6 Summary
First off, thanks to our relentless..., er, tireless summarizer for continuing to digest and clarify our wandering discussion. On Tue, 25 Feb 2003, Piers Cawley wrote: Using IMCC as JIT optimizer Apparently, Leo Tötsch finds it unbearable that 'optimized compiled C is still faster than parrot -j' so he's been experimenting with adding smarts to IMCC, making it add hardware register allocation hints to its emitted bytecode. Sean O'Rourke liked the basic idea, but reckoned that the information generated by IMCC should really be platform-independent, suggesting that it'd be okay to pass a control flow graph to the JIT, This isn't really my idea, but is instead an area of active research. A good jumping-off point is http://citeseer.nj.nec.com/krintz01using.html. Dan thought the idea was interesting too, but worried that the JIT might spend more time optimizing code than it could possibly gain from the optimization. Dan -- you might be interested in http://www.usenix.org/events/javavm02/chen_m.html (if you have a USENIX subsription or a nearby university library). They stuff a full data-flow compiler into a JVM and, by carefully minimizing the number of passes, make it end up faster than a lightweight JIT on a number of programs. Granted, (IIRC) the real wins are on longer-running programs, so the result isn't as relevant to Parrot, but it _does_ show that there's room to put a fair amount of optimization into a JIT. /s
Re: Using imcc as JIT optimizer
On Thu, 20 Feb 2003, Leopold Toetsch wrote: What do people think? Cool idea -- a lot of optimization-helpers could eventually be passed on to the jit (possibly in the metadata?). One thought -- the information imcc computes should be platform-independent. e.g. it could pass a control flow graph to the JIT, but it probably shouldn't do register allocation for a specific number of registers. How much worse do you think it would be to have IMCC just rank the Parrot registers in order of decreasing spill cost, then have the JIT take the top N, where N is the number of available architectural registers? /s
Re: Bytecode metadata
On Sat, 25 Jan 2003, Leopold Toetsch wrote: Dan Sugalski wrote: At 5:32 PM + 1/24/03, Dave Mitchell wrote: I just wrote a quick C program that successfully mmap-ed in all 1639 files in my Linux box's /usr/share/man/man1 directory. Linux is not the universe, though. How true. On Solaris, for example, mmap's are aligned on 64k boundaries, which leads to horrible virtual address space consumption when you map lots of small things. If we're mmap()ing things, we want to be sure they're fairly large. /s
Re: Bytecode metadata
On Sat, 25 Jan 2003, Dave Mitchell wrote: On Sat, Jan 25, 2003 at 06:18:47AM -0800, Sean O'Rourke wrote: On Sat, 25 Jan 2003, Leopold Toetsch wrote: Dan Sugalski wrote: At 5:32 PM + 1/24/03, Dave Mitchell wrote: I just wrote a quick C program that successfully mmap-ed in all 1639 files in my Linux box's /usr/share/man/man1 directory. Linux is not the universe, though. How true. On Solaris, for example, mmap's are aligned on 64k boundaries, which leads to horrible virtual address space consumption when you map lots of small things. If we're mmap()ing things, we want to be sure they're fairly large. Okay, I just ran a program on a a Solaris machines that mmaps in each of 571 man files 20 times (a total of 11420 mmaps). The process size was 181Mb, but the total system swap available only decreased by 1.2Mb (since files mmapped in RO effecctively don't consume swap). The problem's actually _virtual_ memory use/fragmentation, not physical memory or swap. Say you map in 10k small files -- that's 640M virtual memory, just over a fourth of what's available. Now let's say you're also using mmap() in your webserver to send large (10M) files quickly over the network. The small files, if they're long-lived get scattered all over VA-space, so there's a non-trivial chance that the OS won't be able to find a 10MB chunk of free addresses at some point. To see it, you might try changing your program to map and unmap a large file periodically while mapping the man pages. Then take a look at the process's address space with /usr/proc/bin/pmap to see what the OS is doing with the maps. Weird, I know, but that's why it stuck in my mind. You have to map quite a few files to get this to happen, but it's a real possibility with a 32-bit address space and a long-running process that does many small mmap()s and some large ones. Anyways... /s
Re: The perl 6 parser
On Wed, 8 Jan 2003, Dan Sugalski wrote: Could one of the folks working on the perl 6 parser give us a status update as to where it stands? languages/perl6/README mostly reflects the status with respect to the language definition of about 4-5 months ago. Differences include: - IIRC hyper-assignment operators are there. - regex capture groups are partial/flaky, not completely unimplemented. Joseph Ryan has updated string and numeric literals to correspond to the latest consensus on the list. Other than that, it's inconsistent with the current spec in a number of ways. A lot of it's just syntax (e.g. hyper-ops, for which I'll have to cut-and-paste the non-ASCII bits). The tests should all still pass (barring inclement GC bugs), but they reflect the outdated spec. /s
Re: [perl #19183] languages/perl6/t/compiler.t -- multiple ways to spell Inf
On Mon, 16 Dec 2002, Nicholas Clark wrote: Also, is the first of these a bug? $ ./perl6 -e 'print 3/undef; print \n' Can't call method tree on an undefined value at ./perl6 line 342. Yes. The Cundef function isn't fully, well, defined. /s
[perl #19090] [PATCH] make parrot_v[sfn]*printf behave itself
# New Ticket Created by Sean O'Rourke
# Please include the string: [perl #19090]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=19090
The following defines a macro VA_TO_VAPTR(x) to convert va_list arguments
to pointers in a platform-independent way. Works for me on Linux-ppc.
Could someone with another CPU give it a spin and/or make sure I hid the
macro in the right part of {config/,lib/Parrot/Configure,...}?
/s
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/45059/35500/f05e2e/va.patch
Index: misc.c
===
RCS file: /cvs/public/parrot/misc.c,v
retrieving revision 1.30
diff -p -u -w -r1.30 misc.c
--- misc.c 10 Dec 2002 14:24:12 - 1.30
+++ misc.c 12 Dec 2002 23:51:53 -
@@ -35,7 +35,7 @@ STRING *
Parrot_vsprintf_s(struct Parrot_Interp *interpreter, STRING *pat, va_list args)
{
SPRINTF_OBJ obj = va_core;
-obj.data = args;
+obj.data = VA_TO_VAPTR(args);
return Parrot_sprintf_format(interpreter, pat, obj);
}
Index: config/gen/feature_h/feature_h.in
===
RCS file: /cvs/public/parrot/config/gen/feature_h/feature_h.in,v
retrieving revision 1.1
diff -p -u -w -r1.1 feature_h.in
--- config/gen/feature_h/feature_h.in 12 Dec 2002 11:20:44 - 1.1
+++ config/gen/feature_h/feature_h.in 12 Dec 2002 23:51:55 -
@@ -15,6 +15,15 @@ if (${jit_i386} ${jit_i386} eq 'fcomi
print OUT #endif\n;
}
+if (${jitcpuarch} eq 'ppc') {
+print OUT 'END';
+#define VA_TO_VAPTR(x) (x)
+END
+} else {
+print OUT 'END';
+#define VA_TO_VAPTR(x) ((x))
+END
+}
#endif guard
print OUT \n\n#endif\n
Re: RFC: static line number information
On Mon, 7 Oct 2002, Nicholas Clark wrote: On Mon, Oct 07, 2002 at 08:27:29PM +0200, Juergen Boemmels wrote: But there must also be a way the higher level languages can assign line numbers. Maybe C-like #line 1 foo.c directives are a solution. or create dedicated assembler macros ..line ..file (maybe) .column ooh. nice. That's built in full debugging support for befunge, isn't it? We should probably add a .plane to support Trefunge, as well. Or just make source position a vector, to generalize to scripting languages of any dimension. /s
Re: Return of RE match
On Mon, 7 Oct 2002, Dakkar wrote: print Yes r\n if 0 =~ /0/; print Yes s\n if 0 =~ 0; prints: Yes s It appears that the RE match returns a false value. If I match: print Yes r\n if 1 =~ /1/; it does print Yes r. I also tried: Probably a bug. Is this CVS parrot? If you want to take a whack at it yourself, have a look at IMCC/rule.pm or IMCC/Binop.pm (near the bottom, where smartmatch is handled). If not, could you run a perl6 -k, then send me the resulting .imc file? /s
Re: Parrot file list
On Fri, 4 Oct 2002, mark sparshatt wrote: Basically I'd like to know if there's any sort of listing that gives a general description of what each file is used for. If there isn't, I've started making some notes of my own and if anyone else thinks this would be useful then I can type them up in POD format and send them in. I'd actually like to see this sort of info at the top of each file, perhaps in the overview section. That way it's less likely to drift away from reality when existing files are changed or new ones are added. For files where this is not possible (e.g. the pdds), maybe a per-directory README or WTFISTHIS could be used instead. Just a thought -- I have enough trouble keeping the manifest in sync ;). /s
Re: Parrot file list
On Fri, 4 Oct 2002, Tanton Gibbs wrote: I agree with this; however, I also think it would be nice to have it all in one place. It's a nuisance to have to open every file just to see what it is. By the time I figure out what the 60th file does, I've forgotten what the first does. It would be nice to have the information at the top of the file and then have a program pull it and create a separate file...that way they are always in sync. My thoughts exactly. Hopefully the boilerplate comment is regular enough that this should be easy-ish to write. /s
Re: Self documenting comments for parrot
On Wed, 2 Oct 2002, Erik Lechak wrote: I was wondering if you could take a look at it and tell me if it has any merrit, or if I should not waste my time on it and get back to the getting started guide. Have you had a chance to look at doxygen? It doesn't support Perl, but Perl is on the todo list, and (at least a couple of years ago) its C++ support was pretty impressive. http://www.stack.nl/~dimitri/doxygen/ /s
Re: Self documenting comments for parrot
On Wed, 2 Oct 2002, Erik Lechak wrote: I'm looking at it right now. Thanks for the link. This is the first time I have heard of doxygen. I meant the pointer at least partly as a reminder that this is one wheel we shouldn't have to reinvent. I think there are plenty of solutions out there to the easy problem of marking up documentation, and to that of embedding blocks of doc in a program. At some point, we may also want to cross-link the documentation based on information gathered from the code, and (at least for C/C++) there are already good tools (doxygen among them) to handle this much more difficult problem. Rewriting any of these things sounds like a lot of work to me. If it's interesting work to you, please don't let me hold you back, but if the task were left to me, I'd grab something ready-made if it were at all possible to do so. By the way is this an RFC thing? Should this concept be submitted to someone other than this group? Who makes the call about what finds its way into perl err ... I mean parrot? I'm sure we have a form for wanting to change the official project documentation format, but I don't remember the number. If others want me to continue with this. The next step would be to throw away 90% of my code and parse the parrotdoc into true XML. Then that opens up parrotdoc to all the functionality of XML. Gack! :) The beauty of POD is that human beings can actually read it. XML, on the other hand, can easily become more than half meta-information, and thus less than half legible. If I were going the XML route, however, I'd suggest making it DocBook compatible, since people I've known who like their docs in XML seem to use that. btw, I think we'd have a much better idea of whether or not POD does what we need if we were a bit better at following our existing doc standards... /s
Re: Split Buffer
On Thu, 26 Sep 2002, Luke Palmer wrote: Before people get Itoo far on the regex engine, is there any plan to implement split buffers; i.e. storing one string in multiple places and tying them together? Has this already been done? I don't understand how this would affect the regex engine -- wouldn't it either be done inside the string implementation (since we always call string_index() to get the next char) or in its own PMC? /s
Re: perl6 on HP-UX 11.00
On Thu, 26 Sep 2002, Andy Dougherty wrote: On Thu, 26 Sep 2002, Dan Sugalski wrote: At 5:05 PM +0200 9/26/02, H.Merijn Brand wrote: perl t/harness t/builtins/array.Can't bless non-reference value at ../../assemble.pl line 163. Hrm. What version of perl are you running? Doesn't matter (within reason). It's a 'make test' bug. Specifically, cd languages/perl6 make test fails, but cd languages/perl6 ./perl6 --test might succeed. I suspect it's actually an imcc calling-convention problem -- I see a generated a.pasm file in my perl6 directory, but all of the t/*/*.pasm files are empty. Sounds likely (Quick fix: change the makefile to use ./perl6 --test ;). though perhaps a patch to assemble.pl to detect an empty .pasm file and give a better warning would be in order. Probably. Though if we go in the imcc generates bytecode direction, assemble.pl can be mercifully laid to rest for P6C's purposes. 'make test' ought to work. Yes. It ought to automatically handle any Perl6Grammar regenerations needed. This is a red herring for the problem you're seeing (though it is true that Perl6grammar.pm isn't automatically regenerated unless it doesn't exist). /s
Re: pre-PATCH: functions in languages/scheme
On 26 Sep 2002, Juergen Boemmels wrote: These may be nice but not needed for scheme * get keyed with INTVAL (getting direct to the Hashes) * set keyed with INTVAL;STRING Both get(INTVAL;STRING) and set(INTVAL;STRING) are needed (or at least useful) for accessing hidden lexicals in outer scopes (e.g. $OUTER::x). /s
Re: [perl #17549] [PATCH] direct accesss for intlist 10 times faster
On Tue, 24 Sep 2002, Leopold Toetsch wrote: Sean O'Rourke (via RT) wrote: What happens if you presize the PerlArray to its final size Then it is of course faster, but this is not a real world proposal IMHO, The real-world version would increase the array's allocation by some fixed multiple, e.g. double its size, which would still improve things from O(n) to O(log n) reallocations. I suspect that this would be almost as fast. you don't know in advance the usage pattern, so you can't do this. Of course, the memory management of array/PerlArray could be smarter - but what about shift/unshift? If we expect these (especially shift) to be as frequent as push/pop, and we want fast indexing as well, then maybe something like the SGI STL implementation of a dequeue (dequeueue?) would be best: keep an array of (pointers to) fixed-size chunks (rather than intlist's linked-list). This would also allow gaps in the middle to remain unallocated, and could speed up some splices. So we should use a intlist based solution anyway. It's an improvement over the current implementation, but I don't think it's the best solution for perlarray's requirements: 1 - front insertion/removal 2 - back insertion/removal 3 - indexing 4 - less-frequent insertion/removal in the middle (splice) The current approach is necessarily bad for 1, good for 3, and unnecessarily bad for 2. IntList is good for 1 and 2, but bad for 3. Both are not-so-hot for 4, but I don't think a lot of people use splice. /s
Re: [perl #17549] [PATCH] direct accesss for intlist 10 times faster
On Tue, 24 Sep 2002, Leopold Toetsch wrote: Sean O'Rourke wrote: If we expect these (especially shift) to be as frequent as push/pop, and we want fast indexing as well, then maybe something like the SGI STL implementation of a dequeue (dequeueue?) would be best: keep an array of (pointers to) fixed-size chunks (rather than intlist's linked-list). Exactly this is, what my recent patch actually did: list-chunk_list holds pointers to chunks, an index lookup is one div more expensive then in array. It's not in #17549. Is it in an earlier patch? /s
Re: [perl #17537] [PATCH imcc 0.0.9.2 containing #17533
On Tue, 24 Sep 2002, Leopold Toetsch wrote: Andy Dougherty wrote: On Mon, 23 Sep 2002, Leopold Toetsch wrote: ./imcc examples/sample.imc This doesn't even compile on my computer. I'm away from parrot-source at the moment, but if sample.imc breaks, that sounds like a bug. /s
Re: pre-PATCH: functions in languages/scheme
On 24 Sep 2002, Juergen Boemmels wrote: I just got functions running in scheme. It uses a pre-version of Sean O'Rourkes scratchpad.pmc. (Sean, I had to reimplement some functions to get it compile, did I get them right?) Hopefully it will be easy to reconcile our different versions (and will teach me not to send people partial patches ;). I'll look at this in the next couple of days, and hopefully send you a full clean patch before that. and a (scheme-)list of the formal parameters. I hope it will be possible to replace this by a Sub.pmc once it will be capable to store the environment. I've done this in my local version, so let's see if it (or something like it) will meet your needs here. /s
Re: [perl #17549] [PATCH] direct accesss for intlist 10 times faster
On Tue, 24 Sep 2002, Leopold Toetsch wrote: intlist_3.pbc is with 1) already 10 times faster then the same test with PerlArray (ok, that's not fair, .PerlArray has to new_pmc, which accounts for ~40% difference). What happens if you presize the PerlArray to its final size before the loop? i.e. set P0, 1000 or whatever. IIRC PerlArray extends by a single element each time you add an element off the end. This seems like an implementation wart to me, but fixing it takes a bit of doing, since PerlArray doesn't have a place to store an allocated size as well as a real size. /s
Re: fingerprinting PBC files
On Sat, 21 Sep 2002, Leopold Toetsch wrote: As PBC files might be built from different core.ops aka core_ops.c, it is necessary to add a fingerprint to PBC files, to validate, that the interpreter uses the very same ops, when running the PBC. - during make a fingerprint of core_ops.c is generated: $ perl -pe's/\s//g' core_ops.c | md5sum | cut -f1 -d' ' [1] 305c25a0a3fe675f7fdc5d323020eae2 I think we could do better than checksumming the whole file, since that will pick up changes in comments, etc. What we really want to know is whether or not the opcode numbers have changed, and I think two things will handle this sufficiently: - a parrot version number in the bytecode file; and - developers remembering not to run old pbc files when adding core ops /s
Re: 16 Bit integer math
On Fri, 20 Sep 2002, Clinton A. Pierce wrote: I have a sudden need to do signed 16-bit integer math in PASM. Any suggestions on where to begin? Does shifting everything left by 16 bits (on 32-bit platforms) to operate on, then shifting it back to the right to use, work? /s
Re: pdd06_pasm, pdd08_keys: _keyed ops
On 18 Sep 2002, Tom Hughes wrote:
In message [EMAIL PROTECTED]
Sean O'Rourke [EMAIL PROTECTED] wrote:
Actually, if scratchpads become proper PMC's these ops would be incredibly
useful and common. For example, @a[0] = %b{1} + $c might become
add P0[@a;0], P0[%b;1], P0[$c]
This is rather speculative, but if many operations will be on lexicals as
opposed to registers/temporaries, such hoariness might be worth it.
Except those indexes are key constants which are type kc but Leopold
only wants to allow dynamically created keys of type k on the other ops.
Hm... maybe I'd rather have constant and run-time keys go through the same
op. An alternative would be to build up the lexical refs from constant
key-construction ops, then use the _k versions.
/s
Re: languages/perl6/t/compiler/2.t factorial issue
On Wed, 18 Sep 2002, Andy Dougherty wrote: That's what I would have thought, but it seems that 12! is already testing recursive functions. Unless there's an objection, I'll just delete the 14! test. Sure. /s
Re: [perl #17358] [PATCH] default.pmc #2
On Tue, 17 Sep 2002, Leopold Toetsch wrote:
... and the default.pmc will catch any abuse of adding a Sub to an int
and throw an exception.
Right. The current default.pmc non-error implementation of get_integer
(returning cache.int_val) is wrong, and should go away.
... IMHO once a class
says how it can be interpreted as e.g. a number, it's eminently reasonable
to default the rest of its numeric operations, and to do widening
conversions to take advantage of implemented ops.
Yes of course. What once was in default.pmc will be scalar.pmc,
where all scalar like classes can inherit from.
And from which perlarray.pmc, perlhash.pmc, and (probably) a whole host of
other types that need scalar-like operations will inherit.
I guess one way to measure which way makes more sense is to put in the new
default.pmc, then see if there end up being any classes inheriting from it
directly, or if everything goes through an intermediate conversion class.
As I already stated, we had til now _no_ inheritance from default.pmc
except for the famous Subscript on something that's not an aggregate.
And invoke for integers.
Then they should implement an empty init() function (Currently we don't
have this case AFAIK).
Should not! ;)
This is one additional line. Please compare this with 5KB lines I saved
in array.pmc.
Okay, but these two things are unrelated. We can save both the 5k in
array.pmc _and_ the two lines in every single other class by having a
default empty init.
Summary:
default.pmc catches errors, and may provide e.g. -name or -type.
scalar.pmc will be the default scalar base class.
Why only (or even) -name and -type?
Here's a list of what seems reasonable to me, default-wise. I suspect we
agree more than it seems. You also might want to take a look at
pdd02_vtables, which gives some indication of what should and should not
throw exceptions. These will doubtless need some tweaking, but better to
figure this out once now than to keep playing with it into the indefinite
future, when a bunch of dependent classes may have to change along with
it.
/s
For X_keyed_int(y) where X_keyed() exists, the default should be to
call X_keyed(make_key(y)). When X_keyed() is the default/error
implementation, doing so will throw an error.
For X_keyed(k, y), call get_pmc_keyed(k)-X(y), e.g. elements_keyed(k)
becomes get_pmc_keyed(k)-elements().
For X_keyed(k, y, value_key), call
get_pmc_keyed(k)-X_keyed(rest_of_key, y, value_key).
For set_X(PMC p) where set_X_native(n) exists, call
set_X_native(p-get_X()) if it exists in non-default form. If not,
call set_pmc(p), e.g. set_number(p) becomes either
set_number_native(p-get_number()) or set_pmc(p), depending on what
our derived class implements.
Analogously, for set_X_same(PMC p), call set_X(p) if it is
non-default, or set_same(p).
For arithmetic op OP (add,subtract,multiply,divide,mod):
- OP_int(v, res) - res-set_integer_native(v OP
SELF-get_integer())
- OP_number(v, res) - res-set_number_native(v OP
SELF-get_number())
- OP_bignum(v, res) - res-set_bignum_native(bignum_OP(v,
SELF-get_bignum())
- OP_same - OP
- OP(v, res) - error
- OP_keyed[_int] - (see above)
For bitwise op OP (or,and,xor,shl,shr,not):
- OP_int(v, res) - res-set_integer_native(v OP
SELF-get_integer())
- OP_same - OP
- OP - error
void init()
- do nothing (or call init_pmc(NULL))
void init_pmc(PMC* initializer)
- do nothing
void morph(INTVAL type)
- error
PMC* mark(PMC* tail)
- nothing
void destroy()
- nothing
INTVAL type()
- return whatever type this has been enumerated to be
INTVAL type_keyed(PMC* key)
- error
UINTVAL subtype(INTVAL type)
- subtypes don't seem to be used now
UINTVAL subtype_keyed(PMC* key, INTVAL type)
- error
STRING* name()
- return whoami?
STRING* name_keyed(PMC* key)
- error
PMC* clone()
- memcpy
PMC* clone_keyed(PMC* key)
- error
PMC* find_method(STRING* method_name)
- error
PMC* find_method_keyed(PMC* key, STRING* method_name)
- error
INTVAL get_integer()
- error
FLOATVAL get_number()
- (FLOATVAL)get_integer(), or maybe an error if FLOATVALs lose
precision when converting to INTVALs on this platform.
BIGNUM* get_bignum()
- make_bignum(get_{integer,number}()) -- depends which people
prefer
STRING* get_string()
- error
INTVAL get_bool()
- error, unless everyone agrees on a common standard of truth
w.r.t. get_string or get_integer.
INTVAL elements()
- error
PMC* get_pmc()
- return SELF, assuming very few classes will return something
other than themselves.
INTVAL is_same(PMC* value)
- return value == SELF (i.e. same address)
void set_integer_native(INTVAL value)
- set_number_native((FLOATVAL)value), or
Re: P6C and closures
On Thu, 12 Sep 2002, Piers Cawley wrote:
So, do we have a timetable for when the Perl 6 interpreter is going
handle closures?
When it uses find_lex/store_lex instead of registers for locals, which
will take a bit of doing, though it's near the top of more than one todo
list.
Also, consider the following:
sub fac($n) {
when 0 { 1 }
default { $n * fac($n - 1) }
}
print1 fac(10);
Compiling this barfs because there's 'no topic in fac', despite the
apocalypse stating that the first argument to a function shall be the
default topic.
Sorry, that hasn't been implemented yet. There are probably a number of
places where the current topic should be set, but is not. I haven't gone
through the apocalypse in detail to pin them all down, unfortunately.
This one should be easy to fix, though -- it needs a call to set_topic()
in P6C::closure::val.
So, putting in an explicit 'given', we have:
sub fac($n) {
given $n {
when 0 { 1 }
default { $n * fac($n - 1) }
}
}
print1 fac(10);
Which throws a runtime 'Wrong type on top of stack!' error.
Even using print instead of print1? This should be working, but I
think there's a bug with given. I'll take a look.
So, am I doing something utterly wrong, or is it really impossible to
write recursive functions with the current perl6 compiler?
You just have to coddle it a bit:
languages/perl6% ./perl6 -we 'sub fac($n) { \
if $n { $n * fac($n - 1) } else { 1 } }; print1 fac 10'
3628800
/s
Re: More fun with the perl 6 compiler.
On Thu, 12 Sep 2002, Piers Cawley wrote: So, I know that recursion doesn't seem to work in the simple case, but at least it reaches runtime. Mutual recursion doesn't even compile successfully. It should do about this, since you're calling it with parens, but for the moment, you need to declare subs before they're called. Pretend you're programming in Cerl, and be thankful you no longer have to have sub main ;). Even with this, however, it is displeased with your use of given/when, which suffers from the same problem as your previous example. Sorry to keep throwing up errors, but I don't have the time at present to go through the code to try and find where the problem arises, but I think it's good to at least document the problem cases; if only so they can get shoved into the test library... Fair 'nuff. Though you could take the opportunity to inaugurate that lonely perl6 queue in RT. /s
Re: More fun with the perl 6 compiler.
On Thu, 12 Sep 2002, Piers Cawley wrote:
Heh. I tried predeclaring using the apocalypse style:
sub odd($n) {...}
sub even($n) {...}
And that complained about the yadda, even though the functions were
then fully defined.
At the time I interpreted this as a stub definition, not a declaration
(e.g. sub foo($x);). Something tells me this maybe not be correct, but
I think there _should_ be a difference between saying I haven't done this
yet and I've done this somewhere else. Will look over apocalyptica.
/s
Re: Perl 6 bug on integer parameter handling
On 10 Sep 2002, Aaron Sherman wrote:
Here's my latest bug, which I will work on tracking down. It's a pretty
huge blocker for everything I've been working on, so there's no sense in
spending my time elsewhere:
sub def ($arg) {
return $arg;
}
$o = 25;
$q = def($o);
die Why is return value $q? unless $q == $o;
The problem seems to be that any numeric argument is converted to 1 (is
that a list length?)
Correct. List/scalar context is done at compile time, so all subs return
lists -- there is no wantarray. I believe ($q) = def($o) will work,
but I should probably fix that to put the last returned value in the
result if the function returns to a scalar. Or look at the return
statement, figure out whether it looks like a scalar, array, or
tuple/list, and use the existing logic for assigning between these things.
/s
Re: Bug in argument handling
On 10 Sep 2002, Aaron Sherman wrote:
This short bit of code does a good job of pointing out two bugs. One is
that the C*@y sucks up ALL of the arguments, not just C_[1..@_],
and also that C\$x prints a lone backslash.
Please correct me if I've misused these operators. Thanks!
sub abc($x,*@y) {
die Why is \$x undefined unless defined $x;
}
abc(1,2,3);
Heh. It appears that splat arguments have only been tested with _.
I'll fix this tonight. It should be easier than the return values thing.
/s
Re: Goal call for 0.0.9
On Mon, 9 Sep 2002, Andy Dougherty wrote: Thanks for running the tests. If you're really ambitious, you could cd languages/perl6 make and see what happens, but unless you've got bison and flex installed, don't bother (I submitted a patch to pregenerate the files, but it's currently stuck in the queue with other (mostly unrelated) imcc isues.) Now why that isn't part of the default build, I don't know. None of the stuff in languages/ is part of the default build, and I think it should stay that way. It seems like bad form to, by default, build parts of a package that the user may not want to use. /s
Re: Current Perl6 on MS Win32 status
On Fri, 6 Sep 2002, Mike Lambert wrote: t/compiler/8.t 1 256 61 16.67% 6 Good to know I can pass the buck on this one. t/compiler/a.t 1 256 31 33.33% 2 That sounds like P6C failing somewhere -- imcc parse errors typically are. t/rx/call.t1 256 21 50.00% 1 That missing `ok 10' disappears into the gaping maw of a segfault. If people would like the p6/imcc/pasm/pbc files, I can provide them. Just let me know. Unfortunately, I'm having no problem reproducing these in the comfort of my own home. /s
Re: [perl #17065] [PATCH] perl6 misc
On Sat, 7 Sep 2002, Steve Fink wrote: Apply as much or as little of this patch as you want. Looks good to me. - Add a few more patterns to various .cvsignore files - Add a -e (or --eval) flag to perl6. For those quick one-liners? - Reindent a bunch of code that had too few spaces - Make sure P6C::IMCC::code() adds a newline after every line (I was getting two consecutive lines of code smashed together) This will probably make the output pretty ugly. I'd rather find the culprit for the smashed-together lines, or only add a newline if there isn't one already. - redirect stdout differently The last is somewhat puzzling. perl6 was passing outfile as an array argument to system(), which on Unix at least won't work. I curse my carelessness. Before, it was sending it all as a big string, meaning the shell sometimes did nasty things to the arguments passed to your program. When changing that, I did not notice that it would break this. /s
interpolated strings
Thanks to Joseph Ryan, P6C does interploated strings now, meaning less underscore, which we can all agree is a Good Thing ;). /s
Re: [perl #17008] [PATCH] automatic PMC integration
Is there a reason you went for a deque instead of a stack? I can definitely see the need for a _PMC_ deque (unshift on the current PerlArray implementation blows), and for an integer _stack_ (regexes), but not for an int-only deque. I'm assuming you have a reason for this, which I have not yet discovered, and I'm curious what it is. /s On Thu, 5 Sep 2002, Steve Fink wrote: On Wed, Sep 04, 2002 at 08:48:29PM -0700, Sean O'Rourke wrote: On Wed, 4 Sep 2002, Steve Fink wrote: I tend to create new PMC classes frequently, and they're a pain to maintain without committing, because you have to touch lots of files to add a PMC, and in ways that are sure to cause conflicts. Is one of these an intstack PMC, perchance? Nope. It used to be. Now it's an integer dequeue, only I'm afraid that if I called it that nobody would use it. :-) It will be going in Real Soon Now. (It's been finished and heavily tested for quite some time, but I've had to sneak in a bunch of precursor patches to prepare things for it.)
Re: [COMMIT] A couple of patches from last night...
And a couple others: #16962 -- (docs) applied #16938 -- (imcc) applied /s On Thu, 5 Sep 2002, Jeff wrote: And some more marked as committed that got missed... Most of the time I'm looking at http://www.parrotcode.org/openpatches/ in order to find out what needs to be committed. I'm so far just marking patches as 'Applied', not closing out the RT report. (NOte: I'm not claiming that I committed all of these... Most of them were simply committed but not marked in RT as applied... Patch #17007 - This needs to be tested on HP/UX, and unfortunately caused a temporary but caught problem on Cygwin. Patch #16992 - Committed. Patch #17035 - Committed but not marked as such. Patch #17034 - Committed but not marked as such. Patch #17030 - Committed but not marked as such. Patch #17025 - Committed. Patch #17009 - Committed. Patch #17002 - Committed but not marked as such. Patch #17000 - Committed. -- Jeff [EMAIL PROTECTED]
Re: [netlabs #801] [PATCH] PerlArray in scalar context
On Wed, 4 Sep 2002, Peter Haworth wrote:
Having the iteration done in the bytecode could make this simpler,
although at the expense of needing more bytecode.
And fewer temporaries, by translating this:
a = b ^+ c ^+ d;
into this:
for a; b; c ; d - $a, $b, $c, $d is rw {
$d = $a + $b + $c;
}
/s
Re: [netlabs #801] [PATCH] PerlArray in scalar context
On Wed, 4 Sep 2002, H.Merijn Brand wrote:
On Wed 04 Sep 2002 20:31, Sean O'Rourke [EMAIL PROTECTED] wrote:
And fewer temporaries, by translating this:
@a = @b ^+ @c ^+ @d;
into this:
for @a; @b; @c ; @d - $a, $b, $c, $d is rw {
$d = $a + $b + $c;
$a = $b + $c + $d;
I might hope
Yes, that advanced correctness feature will be available in a future
release...
/s
RE: [netlabs #801] [PATCH] PerlArray in scalar context
On Wed, 4 Sep 2002, Brent Dax wrote: What if (say) b is a two-dimensional array? Then you get interesting values of undef :). Seriously, I suspect one of the following: 1 - runtime error 2 - each row (or column) of b numified to its length 3 - the first element of each row/col of b 4 - the other arrays boosted to the highest dimension I like #2, because it is easy and keeps hyper-operation simple. If those aren't just numeric operators, but some other weird user-defined thing, then an array as one operand makes sense. The simpler hyping is, the better, IMHO. Some people doubtless like #4 because it's a natural extension of the way scalars get auto-boosted to one-dimensional arrays. As a middle ground, we could have 5 - use /\^$noperator/ to do a nested $n-dimensional hype Oh, yeah. /s who regrets opening his mouth...
Re: Parrot: maximizing the audience
On Tue, 3 Sep 2002, Markus Laire wrote: On 3 Sep 2002 at 22:17, Jerome Quelin wrote: Hi there, As a recent parroter, what striked me most while reading perl6-internals, is that it's very perl-centric. Ok, I agree that: ... * the name perl6-internals is really too restrictive (but this point has already been discussed last week). ... Would it be possible to rename perl6-internals now to something better like parrot-internals? I think aliases can take care of this, though I'm not the sysadmin. Maybe it makes people feel better to send mail to parrot-internals instead of perl6-internals, but I don't see how giving the list a different name will have any real effect beyond breaking my procmail setup. /s
Re: Goal call for 0.0.9
On Mon, 2 Sep 2002, Dan Sugalski wrote: Here's a call for potential goals for the 0.0.9 release of parrot. My list: *) Exceptions *) initial PMC freeze/thaw API *) Sub indicators in bytecode *) On-the-fly bytecode section generation *) methods (in PASM and C) *) implementation of some methods for the Perl classes *) stashes /s
approximate string matching in regexes
Edit distance is a measure of the number of edits required to turn one string into another, basically the size of a character-by-character diff. For example, the edit distance between aches and access is one change and one insert: aches acCes accesS Depending on how you define the costs of edit operations, this could either cost 2 (one for the change and one for the insert) or 3 (the change counts as a delete followed by an insert). Edit distance can be used for approximate string matching, by saying that one string equals another if the edit distance between the two strings is less than some threshhold. Approximate matching cannot be done with regular expressions short of making an alternation consisting of all possible alternatives withing a given distance. Using an edit distance algorithm, it can be done in O(nm) time and space, where n and m are the lengths of the two strings to be compared. When matching a pattern against a substring of a text this becomes O(n^2), where n is the pattern length. Since it solves a common class of pattern-matching problems not addressed by regexes or grammars, I think this would make a valuable addition to the Parrot regex engine. I propose something along the following lines: rx_amatch Sx, Ix, Sy, Nx Do an approximate match of Sy against Sx at Ix with maximum edit distance floor(Nx * length(Sy)). Push a mark, then the end positions of the approximate matches, onto the regex stack, with the closest match on top. Using this op, matching /[:approx(0.3) aches] s/ against a substring of access at position 0 would be turned into Parrot bytecode like so: set S0, access set S1, aches set I0, 0 rx_amatch S0, I0, S1, 0.3 next_amatch: rx_popindex I0, fail rx_literal S0, I0, s, next_amatch branch succ fail: print no succ: print match\n I attached an implementation of this op. Comments welcome. /s amatch.tgz Description: Binary data
[perl #16935] [PATCH] more regex stack manipulation
# New Ticket Created by Sean O'Rourke
# Please include the string: [perl #16935]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=16935
This adds the following two regex ops:
rx_stackdepth Ix -- Store the size of the regex stack in Ix
rx_stackchop Ix -- shorten the regex stack to have Ix entries
I found these useful in implementing explicit backtracking control, and
much better than the alternative, a bytecode loop popping entries and
counting marks.
Steve, others: do you find these useful?
/s
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/36335/29365/24afcb/stacks.patch
Index: rx.ops
===
RCS file: /cvs/public/parrot/rx.ops,v
retrieving revision 1.30
diff -p -u -w -r1.30 rx.ops
--- rx.ops 25 Aug 2002 00:20:22 - 1.30
+++ rx.ops 2 Sep 2002 15:51:14 -
-209,6 +209,17 op rx_clearstack () {
intstack_free(interpreter, interpreter-ctx.intstack);
goto NEXT();
}
+
+op rx_stackdepth (out int) {
+ $1 = intstack_depth(interpreter, interpreter-ctx.intstack);
+ goto NEXT();
+}
+
+op rx_stackchop (in int) {
+ intstack_chop(interpreter, interpreter-ctx.intstack, $1);
+ goto NEXT();
+}
+
=item Crx_pushmark(in pmc)
Index: rxstacks.c
===
RCS file: /cvs/public/parrot/rxstacks.c,v
retrieving revision 1.8
diff -p -u -w -r1.8 rxstacks.c
--- rxstacks.c 22 Aug 2002 20:08:24 - 1.8
+++ rxstacks.c 2 Sep 2002 15:51:14 -
-101,6 +101,27 intstack_pop(struct Parrot_Interp *inter
return entry-value;
}
+void intstack_chop (struct Parrot_Interp *interpreter, IntStack stack,
+INTVAL n)
+{
+INTVAL depth = intstack_depth(interpreter, stack);
+IntStack_Chunk chunk = stack-prev;
+IntStack_Entry entry;
+
+if (depth n) {
+internal_exception(ERROR_STACK_EMPTY, popn: stack underflow\n);
+}
+while (depth - chunk-used n) {
+depth -= chunk-used;
+if (chunk-next != stack) {
+chunk-next = stack;
+}
+
+chunk = chunk-prev;
+stack-prev = chunk;
+}
+chunk-used -= depth - n;
+}
void intstack_free (struct Parrot_Interp *interpreter, IntStack stack)
{
Index: include/parrot/rxstacks.h
===
RCS file: /cvs/public/parrot/include/parrot/rxstacks.h,v
retrieving revision 1.4
diff -p -u -w -r1.4 rxstacks.h
--- include/parrot/rxstacks.h 22 Aug 2002 20:08:59 - 1.4
+++ include/parrot/rxstacks.h 2 Sep 2002 15:51:14 -
-37,6 +37,8 INTVAL intstack_depth(struct Parrot_Inte
void intstack_push(struct Parrot_Interp *, IntStack, INTVAL);
INTVAL intstack_pop(struct Parrot_Interp *, IntStack);
+void intstack_chop(struct Parrot_Interp *interpreter, IntStack stack,
+ INTVAL n);
void intstack_free(struct Parrot_Interp *, IntStack);
Re: [perl #16935] [PATCH] more regex stack manipulation
On Mon, 2 Sep 2002, Dan Sugalski wrote: At 3:59 PM + 9/2/02, Sean O'Rourke (via RT) wrote: rx_stackdepth Ix -- Store the size of the regex stack in Ix Make that intstackdepth, since it's a general-purpose stack. If so, we'll probably also want to change rx_clearstack and rx_initstack. I thought the rx_ was the naming convention for things that dealt with the interpreter intstack. rx_stackchop Ix -- shorten the regex stack to have Ix entries Yeek--that's from the wrong end. We need to chop entries off the top, as we have no idea how many entries were already there. Either way. I thought it was more natural to be able to save and restore absolute stack depths, so you don't have to track how much stuff gets pushed onto the stack between when you record the depth and when you pop back to it. I think it ends up being two more ops if you say chop X entries -- getdepth; subtract; chop vs. setdepth. I think I'm really, *really* close to tossing the last pretense of being a stack-based system and move all the way to routine-based frames instead, which'd definitely make some things easier. I don't think frames help us here. This is basically a poor man's exceptions. It's useful for regexes, where you are only accumulating state on the intstack, so using full exceptions or (heaven forbid) continuations is overkill. I don't know if it's a useful approach outside of a limited regex-backtracking context. Anyway, it should be intstackchop, and chop X entries off the top of the stack. Or, if you'd rather, intstackpop ix, and add in pop X versions for the other stacks too. I think these could be useful as well. /s
Re: Regex status?
On Wed, 28 Aug 2002, Dan Sugalski wrote:
How're we coming with the perl 6 regex stuff? What works, what
doesn't, and are we at a state where we can release something for
people to play with?
There are plenty of things, like anonymous rules, any of the builtin
assertions, and modifiers, that simply aren't implemented. Backtracking
control is in the code, but the current implementation needs to be taken
out and redone, so it falls into this first category as well.
I know that backtracking is not correct for stingy repetition, and for
repetitions with a non-zero minimum count.
What is implemented (in no particular order):
- [...] character classes
- many/most escaped characters (\R, \x..) and their complements
(\R, \X).
- alternations
- stingy and greedy repetition (modulo backtracking issues)
- interpolated arrays and scalars
- code assertions (( $x + 23 5 ))
- named rules with parameters
- (possibly recursive) calls to named rules (with params)
- non-capturing groups
- blocks of code (/x+ { print 'hello' } .$/)
What is tested: see t/rx/*.t. It could certainly use more testing, and if
said testing doesn't uncover more bugs that I don't know about, I'll eat
my keyboard.
As to whether or not it's something that can be released for people to
play with, I really can't say -- I think it's fun to play with, but that
could be the parent's irrational fondness for his child.
/s
significant imcc commit
Okay, I just added a big chunk of code to imcc. The code does two main
things:
- changes imcc syntax to disallow newlines within ops. You can
still have all the newlines you want between ops and after labels, but
this:
if $P1
goto label
will no longer work. Since no one appeared to be emitting imcc code
like this, it shouldn't be missed.
- Makes some significant changes to register allocation and spilling.
For the details, you'll have to ask Leo.
The upshot is that none of the tests behave worse, and some behave better.
If anyone besides languages/{cola,perl6} is using imcc, please let me
know.
/s
Re: perl6 test failures
On Tue, 27 Aug 2002, Steve Fink wrote: For those following along at home: regex engines seem to be too much fun for people to resist. I know of at least 5 parsers, 4 compilers, and 5 backend op sets that have been written over the course of the Parrot project: Parsers: - My languages/regex/lib/Regex/Grammar.y (only perl5 re's, crappy) - Jeff's languages/perl6re.bnf - Didn't Sean have another one? Yes -- the one that's being used by P6C starts at line 700 in Parser.pm. It's pretty clean, and could stand apart from the rest of the grammar with a few tweaks, if anyone wants to use it. Backend ops: - Brent's original rx ops - The rx ops with Angel's modifications - My abandoned implicitly backtracking re ops Are these abandoned for good, or just for the moment? - Plain pasm ops - Simon Cozen's tree walkers Many of these fed off of each other. Brent Dax's rx.ops documentation gave both Sean and me the initial start on explicit backtracking code generation, Thanks, Brent. Sean and I discuss implementation ideas a little, and I think some more happens on IRC that I don't know about. Actually, there's hardly any irc discussion of regexes -- us regex re-implementors seem to suffer from a failure to communicate... Currently, Sean's stuff is very well integrated with perl6; my stuff is pretty much ignored; s/well/tightly/. After 0.0.8, I'm planning on taking a much more serious look at Steve's stuff. I'm hoping that, with the right interface there will be very little overhead in sticking externally-created bits into Steve's regexes. And I'm not sure why I just wrote all that up. Well, thanks anyways for getting all carried away like that. /s
Re: DOD etc
On Mon, 26 Aug 2002, Nicholas Clark wrote: All ways of doing deterministic destruction seem to have considerable overhead. One possible alternative would be to have file handles and other objects with destructors that have to be called in a timely fashion keep ref-counts. When the refcount drops to zero, they release whatever critical resource they are holding. Then the GC comes by later to reclaim the memory. /s
Re: [perl #16745] imcc doesn't compile anymore
Added the necessary files, so it should be working again. There are still a couple outstanding syntax issues, but you should only run into those on some of the regex tests. /s On Sun, 25 Aug 2002, Markus Laire wrote: # New Ticket Created by Markus Laire # Please include the string: [perl #16745] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=16745 Compiling imcc dies on Cygwin with error No rule to make target 'anyop.h', needed by 'imcparser.o'.
Re: [netlabs #801] [PATCH] PerlArray in scalar context
I ran across this in looking at tidying up old bugs. It seems like things are backwards below -- hyper-operation is a language-level shorthand for iteration over a container, so there's no reason for the container's vtable methods to be hyper. Actually, it seems like there are at least a couple ways in which pushing this responsibility onto vtable methods may not be the best way: if we hype non-vtable methods, we have to handle explicit iteration in bytecode; and if we hyper-operate on tied variables, they have to re-implement this looping behavior in their add, etc methods. It looks like the standard perl5 behavior is implemented by the current vtable methods (hyping done separately), but I wanted to make sure we were on the same page before closing the bug. /s On Wed, 14 Aug 2002, David M. Lloyd wrote: [what PerlArray vtable methods should do for $x = a + b] I thought about this more. Here's a brain dump: Here's how I'd expect these expressions to be executed internally, in gross pseudocode, ignoring for the moment the multimethod vaporware: $r = $a + $b; # $a-add($a, $b, $r) $r = a + $b; # $t = a-get_pmc(a); $t-add($t, $b, $r) $r = $a + b; # $t = b-get_pmc(b); $t-add($a, $t, $r) $r = a + b; # $t = a-get_pmc(a); $u = b-get_pmc(b); $t-add($t, $u, $r); r = $a ^+ $b;# Something that makes one-elment arrays and # uses add method on array object? Or perhaps # error r = a ^+ $b;# Does this distribute? If so, # a-add(a, $b, r) else see above r = $a ^+ b;# See above r = a ^+ b;# a-add(a, b, r), easy
Re: [perl #16755] imcc requires Parrot_dlopen but HAS_DLOPEN isnever defined
On Sun, 25 Aug 2002, Tom Hughes wrote: That sounds like a separate bug in the imcc makefile - the main parrot makefile only links against libdl if Configure.pl discovers that perl5 does. Yes. I will update imcc to do so as well. /s
Re: [perl #16755] imcc requires Parrot_dlopen but HAS_DLOPEN isnever defined
On Sun, 25 Aug 2002, Tom Hughes wrote:
In message 20020825155505$[EMAIL PROTECTED]
Tom Hughes (via RT) [EMAIL PROTECTED] wrote:
Recent changes to imcc make it require a working Parrot_dlopen but
unfortunately as things stand it never does work because Configure.pl
never sets HAS_DLOPEN so Parrot_dlopen is also stubbed out.
There is a second problem in that platform.c only include dlfcn.h if
a particular symbol is defined but that symbol is not defined until
parrot.h is included which is after the include of dlfcn.h.
Here's a patch that addresses both those issues and makes imcc
work again.
Here's a patch that hopefully addresses the makefile issue. imcc.in
belongs in config/gen/makefiles/. Could you please try it out to see if
it works on your platform?
/s
O = ${o}
RM_F = ${rm_f}
INC=../../include/parrot
H_FILES = $(INC)/parrot.h imc.h imcparser.h stacks.h cfg.h \
instructions.h cfg.h debug.h sets.h anyop.h
O_FILES = imcparser$(O) imclexer$(O) imc$(O) stacks$(O) symreg$(O) \
instructions$(O) cfg$(O) sets$(O) debug$(O) anyop$(O) \
../../platform$(O)
#DO NOT ADD C COMPILER FLAGS HERE
#Add them in Configure.pl--look for the
#comment 'ADD C COMPILER FLAGS HERE'
CFLAGS = ${ccflags} -I../../include
C_LIBS = ${libs}
CC = ${cc}
PERL = ${perl}
MAKE_F=${make}
YACC = bison -v -y
LEX = flex
all : imcc
cd ../.. $(MAKE) shared $(RM_F) parrot${exe} $(MAKE)
imcparser.c imcparser.h : imcc.y
$(YACC) -d -o imcparser.c imcc.y
imclexer.c : imcc.l $(HEADERS)
$(LEX) imcc.l
.c$(O):
$(CC) $(CFLAGS) ${cc_exe_out}$@ -c $
clean:
$(RM_F) core
$(RM_F) $(O_FILES)
$(RM_F) imcparser.output
$(RM_F) imcc
realclean: clean
$(RM_F) a.pasm
$(RM_F) imcparser.*
$(RM_F) imclexer.*
imcc: $(O_FILES)
$(CC) ${ld_out}imcc $(LDFLAGS) $(O_FILES) $(C_LIBS)
Index: config/gen/makefiles.pl
===
RCS file: /cvs/public/parrot/config/gen/makefiles.pl,v
retrieving revision 1.2
diff -u -r1.2 makefiles.pl
--- config/gen/makefiles.pl 29 Jul 2002 04:41:24 - 1.2
+++ config/gen/makefiles.pl 25 Aug 2002 20:24:36 -
@@ -17,6 +17,7 @@
genfile('config/gen/makefiles/miniperl.in', 'languages/miniperl/Makefile');
genfile('config/gen/makefiles/scheme.in','languages/scheme/Makefile');
genfile('config/gen/makefiles/perl6.in', 'languages/perl6/Makefile');
+ genfile('config/gen/makefiles/imcc.in', 'languages/imcc/Makefile');
}
-1;
\ No newline at end of file
+1;
Re: [perl #16755] imcc requires Parrot_dlopen but HAS_DLOPEN isnever defined
On Mon, 26 Aug 2002, Markus Laire wrote: I tested than on Cygwin and imcc does compile, but I have some problems: If I compile imcc with 'make imcc', most perl6 tests will fail with error readline() on closed filehandle P6C::TestCompiler::PASM at P6C/TestCompiler.pm line 55. make imcc only rebuilds imcc, while the default target also makes libparrot.so. I suspect this is the problem, what with imcc needing libparrot. If I compile imcc with plain 'make' (which also remakes shared parrot), I get about 1000 lines undefined reference to warnings from core.ops, debug.ops, io.ops and rx.ops, Does the same thing happen when you do a make shared in the base parrot directory? but perl6 works better with only 35% test failed and no readline-errors. Okay. I thought it did better on Windows. What does it say when you run one or two of the failed tests individually? e.g. ./perl6 -w t/compiler/1_3.p6 /s
Re: imcc hack for perl6 regexes
Replying to myself because I forgot to include these files... /s anyop.tgz Description: Binary data
Re: imcc hack for perl6 regexes
On Wed, 21 Aug 2002, Angel Faus wrote: About the implementation, I think we will need the following metadata about each op: i) the opcode, and the op name. ii) the type of arguments, including in/out/etc.. Both of these are available, though there currently isn't an efficient interface to say give me all possible sets of parameter types for an op called 'X' -- you can only look up the op quickly if you know the exact parameter types. This lookup would be easy to add, though. iii) whether the opcode has side-effects or not. This, unfortunately, is not available. Since many ops just call into vtable methods, it would need to be set in stone in the vtable doc as well, e.g. the add op MUST NOT appear to have a side-effect, and vtable writers would need to take this into account. /s
Re: imcc hack for perl6 regexes
On Wed, 21 Aug 2002, Melvin Smith wrote: At 11:15 PM 8/21/2002 +0200, Leopold Toetsch wrote: _SV_s1 = clone $P1 I've considered changing '=' to mean clone, and add ':=' to imply set. What do you think? Heh. What's the universal sign for assign (as opposed to clone or set)? Since we're going to have all three at some point, we'll need to come up with something for that, too. /s
