At 12:16 on 07/10/2003 PDT, Dan Sugalski [EMAIL PROTECTED] wrote:
At 11:56 AM -0700 7/10/03, Robert Spier wrote:
s/Yet Another Society/The Perl Foundation/g
The Perl Foundation is just a dba of YAS. The name should, unless
things have changed, be YAS.
We're generally encouraging the name
On Tue, Dec 16, 2003 at 11:54:27PM -0500, Dan Sugalski wrote:
At 12:00 AM + 1/1/04, Allison Randal (via RT) wrote:
# New Ticket Created by Allison Randal
# Please include the string: [perl #24682]
# in the subject line of all future correspondence about this issue.
# URL: http
Leo wrote:
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/op/hacks.t2 512 22 100.00% 1-2
Could you please run these 2 standalone:
$ parrot t/op/hacks_1.pasm
catched it
error
Leo wrote:
Very likely that SIGFPE isn't defined.
Does Fruntime/parrot/include/signal.pasm have an entry for SIGFPE?
(line 14)
.constant SIGFPE8
Is PARROT_HAS_HEADER_SIGNAL defined?
(Finclude/parrot/has_header.h: line 46)
define PARROT_HAS_HEADER_SIGNAL 1
Allison
Leo wrote:
I've added two test files, bitwise.t and concat.t, which go in t/op/
(the op/ directory doesn't exist yet)
Missing?
The directory needs to be added. We're gradually moving our way toward
the test hierarchy planned on p6d:
t/var
t/op
t/subs
t/regex
t/module
t/class
...
Or,
Piers wrote:
p6d?
The perl6-documentation list. Started around Nov. 2002, it had about 3
months of heavy traffic and not much since. But, we did get a good plan
for the direction of p6 testing out of it.
Allison
Leo wrote:
I had a short look at the subdir hierarchy, looks good.
Excellent.
(perl6:run_tests, Makefile, and t/harness have to learn how to deal with
differently deep nested test files though).
Yeah, that's on my Todo list. Hmmm... I should probably add the list to
the repository.
If
Dan wrote:
Allison, if you've not gotten a perl.org account head over to
bugs.perl.org and get one so we can get you checkin privs. Seems
silly to force a go-between for updates to the perl compiler.
I'm allison.
Allison
Dan wrote:
Full CVS checkin, or would you prefer to stick with just the perl 6
section?
At the moment I don't expect to work on much outside the perl 6 section
except the Perl PMC's and occasional OS X patches. That may change.
shrug
Allison
I checked in some changes that allow up to 3 levels of hierarchy in the
languages/perl6 tests (t/harness, Makefile, and run_tests() in 'perl6').
I also added a few new test files that use the new levels of hierarchy.
This is the first step in moving toward the new test hierarchy:
It's that time of year again, and we're looking for reviewers for the
2nd edition of Perl 6 Essentials. The review will start mid-March and
last about a week. Drop me a message if you're interested. We may have
to narrow down the list of volunteers a bit. 15 sets of comments is
about the maximum
Okay, languages/perl6 is failing all its tests.
The problem is in a few recent changes to lib/Parrot/Test.pm. The Perl
6 test module in languages/perl6/P6C/TestCompiler.pm inherits from
Parrot::Test, but overrides some subs. P6C::TestCompiler's
generate_pbc_for is writing the .pasm files in
Jerome wrote:
I'm sorry, I've been very busy for 2 weeks, and did not have the time to
continue things regarding this topic. :-(
I hope to have some more time this week-end, but I'm not even sure...
It happens. :)
So, very quickly:
1. The main goal is to have unified languages tests,
Dan wrote:
Well... the big problems we were make-related, with some tinder
issues. Basically if any test suite died really hard the testing
would stop, and only the last test suite run counted for tinder
good/bad reporting.
At this point, though, I'm comfortable making it so that any
Dan Sugalski wrote:
Applied. (Was there anything besides the /tmp change? That's all that
was in the attachment)
Calling 'rel2abs' was necessary so Parrot::Test would have the right
path to the test file later when it cd's to the main parrot directory
and calls './parrot'. That's all it
Steve Fink wrote:
I suspect a slight variant of the above may work best. Rather than
doing a full-out LALR(1) parser for the bottom-up components, you'd do
a somewhat more naive but still table-driven (shift/reduce) parser,
carefully limiting what it is assuming about the FIRST() etc. of the
Abhijit A. Mahabal wrote:
On Mon, 10 May 2004, Steve Fink wrote:
use File::Basename qw(dirname);
use lib dirname($INC{P6C/Parser.pm})./../../../../lib;
I had already tried that, and it doesn't seem to work. I guess it is some
timing issue: $INC{P6C/Parser.pm} gets defined after
Dan Sugalski wrote:
I'm not so sure about that. (Not that it won't be replaced, but that
it needs the grammar engine) I'm pretty sure that grammars as Larry's
defined 'em are recursive-descent, and if that's true then I've this
really nasty feeling we're going to find it insufficiently
Dan Sugalski wrote:
Might not be out of line to start a notes file or something to throw
in observations and whatnot that you and other folks come across as
you work on this stuff.
I just added languages/perl6/doc/developer_notes.pod, with a few current
notes. Add to it as relevant.
Allison
Dan Sugalski wrote:
I think the first step here is to get the low-level perl operations
defined, and their parrot translations worked out. For this I mean
that we need to have a list of:
Perl:
a = b + c;
Parrot:
add a, b, c
I expect things like the foreach loops
Abhijit A. Mahabal wrote:
this is my first patch ever (not just p6i: ever). So do tell me
what I have done wrong.
Sorry not to respond before the patch was applied. Crazy week.
This is a patch for one of the ToDo items in languages/perl6/Todo. I have
updated the calling conventions in
Alex Gutteridge wrote:
The example Perl6 'Game of Life' program
(parrot/languages/perl6/examples/life.p6) is broken. As it stands it
doesn't parse correctly but this is easily fixed by adding the correct
string concatenation operator '~':
I've checked in your update to the concat operator.
Leo wrote:
Fixed.
The code in smallobject.c that allocates new buffer memory did assume
that it gets zeroed memory, which of course depends on the OS and the
arena size. Now Cbuflen, which is used during GC, is cleared
explicitely.
Yup, that fixed it. Thanks!
Allison
On Jul 3, 2005, at 7:42, Will Coleda wrote:
I was under the impression that for any code to be included in the
parrot repository, that the copyright had to be assigned to the Perl
Foundation. But there are exceptions to this throughout the
repository, even in core files like imcc/main.c
I'd like to add Punie to the Parrot repository. It's a first step
toward a compiler for Perl 1 running on Parrot. Currently it's *very*
simple: it only parses and compiles a single statement printing a
single digit -- but it uses PGE grammars and the stub in ast/ to do it.
Punie is a test
On Jul 11, 2005, at 21:41, Autrijus Tang wrote:
Cool! However, I wonder if Punie is indeed targetting Perl 1.
As Schwern will attest, Perl 1 is a quite complicated language, with
nullary, unary, binary and ternary functions, arrays, hashes, pattern
matches, transliteration, format, loop
On Jul 12, 2005, at 0:37, Autrijus Tang wrote:
That's cool. In that case I'll commit the test suite from perl-1.0_16
as TODO tests to the Punie tree, if that's okay with you. :)
Most welcome. I'm following a naming convention in the t/ directory of
changing the original io.print-style file
On Jul 12, 2005, at 13:51, Will Coleda wrote:
Anyone have any ideas on how you might harness a PM group to work on
parrot?
Harness them to do what? Write tests? Clean up documentation? There's
certainly precedent (Phalanx), but you need a bunch of small,
achievable goals.
Allison
On Jul 12, 2005, at 15:59, Will Coleda wrote:
Hey, Allison - you drafted up the project plan for TPF grant for
parrot, neh?
Yup. With a good deal of input from Dan, Leo, Patrick and others.
Are you the defacto Project Manager for parrot? Or is that position
unfilled?
Indeed I am. Parrot
On Jul 14, 2005, at 7:26, Will Coleda wrote:
MUahahahahaha, my trap has been sprung! Perfect. I've been looking for
you since before we lost Dan. =-)
Had I know this at the conference, I would have had a much longer
conversation with you. =-)
I can't say I've ever made any secret of the
On Jul 14, 2005, at 12:51, Will Coleda wrote:
http://dev.perl.org/perl6/people.html
Perhaps we need a similar page on parrotcode. =-)
Seems unnecessary to maintain it in two locations, but you could link
to that one from parrotcode.org.
Ok. Does parrot/perl6 have a project planning tool?
On Oct 17, 2005, at 12:26, Joshua Hoblitt wrote:
Does sticking Copyright The Perl Foundation at the top of a file
constitute a legal transfer of copyright?
No, there's no such thing as an implicit transfer of copyright rights.
Which is what I've been doing
but It's my understanding that
On Nov 5, 2005, at 19:37, Will Coleda (via RT) wrote:
Sending as a patch since 1) we're close to a freeze, and 2) this is
allison's code.
Allison: this patch fixes a dependency issue in the makefile,
eliminates some deprecation issues, and corrects a small issue in the
grammar that allows
I've been developing the tree transformation stuff outside the parrot
repository, and ran into some problems writing tests for my PIR
libraries. After talking to Chip Patrick, I'll be moving my code
into the parrot repository anyway, which scratches my immediate itch.
But, long-term it's
On Nov 8, 2005, at 12:12, Joshua Hoblitt wrote:
Allison has an excellent document on the state of tool development in
her SVN tree. It would be nice to see it included with Parrot's
documentation.
It's still very rough, but will go into the Parrot repository after I
give it another pass
On Nov 29, 2005, at 15:08, Chip Salzenberg wrote:
Comments? Fresh or rotten vegetables?
My objections:
Consider:
P0 = P1
P0 = S1
P0 = I1
P0 = N1
o/~ One of these things is not like the others
One of these things just doesn't belong o/~
And if I have to read:
P0 =
I realize this is a side effect of the fact that method names are
actually strings, but it's an unfortunate result.
If I have a little bit of code that calls a method without quotes
around the name of the method, it calls the method (prints out
Boojum), exactly as expected:
.sub main
On Jan 17, 2006, at 18:01, Andrew Rodland wrote:
Doesn't that imply that print print print print 1; is a valid Punie
program? Is that intentional? It seems to me that the gprint rule
should instead contain cexpr:
rule gprint { (print) \s* PunieGrammar::cexpr }
print print print print 1;
This'll likely be out-of-date tomorrow, but I found it useful as a
quick snapshot/overview of the Parrot repository.
http://www.lohutok.net/parrot.pdf (200k)
Allison
On Jan 31, 2006, at 16:26, Allison Randal wrote:
This'll likely be out-of-date tomorrow, but I found it useful as a
quick snapshot/overview of the Parrot repository.
http://www.lohutok.net/parrot.pdf (200k)
Sadly, it doesn't display in acrobat, but is fine in xpdf and
Preview.app
On Feb 2, 2006, at 15:10, Patrick R. Michaud via RT wrote:
...as of r11409, I'm not seeing the 'make test' error for punie
(on my Linux/x86_64 box).
I don't know if this is because it's now working, or because you've
routed around the particular problem you were seeing, so let
me know if
On Feb 3, 2006, at 17:33, Joshua Isom via RT wrote:
But, I've encountered two major problems. On darwin, I can't finish
past_node.t, first parrot takes over 100 megs of ram, then perl(5.8.7)
wants 180 megs. On freebsd, it's actually worse, but more confusing.
It fails with past_*.t and
On Feb 4, 2006, at 8:09, Patrick R. Michaud via RT wrote:
Like others, problematic.t seems to runs okay on my system
(Linux x86_64). :-( Maybe I can get access to a platform on
which it fails...?
Long ago we had an OS X box available to developers. Is that still
around? If not, I can
On Feb 4, 2006, at 12:26, Leopold Toetsch via RT wrote:
Both on OS/X darwin and x86/linux 'make test' as well as
./parrot -p languages/punie/punie.pbc languages/punie/t/
problematic_1.p1
are succeeding here.
The error is gone here too now. Not sure if it's Leo's fix or unrelated.
Allison
On Feb 4, 2006, at 14:23, Joshua Isom via RT wrote:
Apparently I have a 267 megabyte past_node_5.out file... And if
past_op_2.pir and past_val_2.pir were printed to a file, I imagine
it'd
do the same(printing a lot of spaces). Seems to be more than just
Parrot::Test for me.
Could you
On Feb 4, 2006, at 16:51, Joshua Isom via RT wrote:
41 callmethodcc P1, dump -
P1=Object(PAST::Node)=PMC(0x50ba68),
102 get_params PMC_C[29] (2), P0, I0 - , P0=PMCNULL,
I0=5289976
106 repeat S0, , I0- , , I0=5289976
110 add I0, 1- I0=5289976,
On Feb 3, 2006, at 12:38, Nicholas Clark wrote:
This'll likely be out-of-date tomorrow, but I found it useful as a
quick snapshot/overview of the Parrot repository.
The process used to created it isn't amenable to automation into a
cron job?
It's just a Perl script, so yeah, could be
On Feb 5, 2006, at 3:05, Leopold Toetsch via RT wrote:
.sub dump method
.param int level
The level argument isn't optional at all. Turning on argument count
checks would prevent such errors.
It has to be:
.sub dump method
.param int level :optional
Okay, thanks, changed. Joshua,
On Feb 6, 2006, at 10:04, Leopold Toetsch via RT wrote:
Allison Randal wrote:
What's the difference between :optional and :opt_flag? I found a few
lines of documentation on these once I knew what to grep for, but
that's all.
Seed pdd03. :optional is the argument. :opt_flag is 1/0
On Feb 5, 2006, at 5:56, dakkar wrote:
I did, and the big problem is that it has a size of 106967 x 2031 pts,
which I think translates to 1485 x 28 inches. This not only makes it
hard to display, but also hard to follow...
That's more a result of Parrot than it is of any particular diagram
On Feb 10, 2006, at 9:56, Andy Dougherty via RT wrote:
I too had seen this memory problem before on Solaris/SPARC, but I'm
pretty sure I saw it even when running t/past_node_5.pir directly.
However, trying again today, I'm happy to report that that particular
problem seems to be gone.
The original bug is resolved. I'll move the Solaris/SPARC test
failures to a new ticket.
Allison
On Feb 20, 2006, at 9:56, Bernhard Schmalhofer wrote:
P.S
I suppose that I'm not the only one willing to help facing this
difficulty.
Maybe a tutorial or a FAQ could attract more contributors ?
Yes.
In fact, this may be the best place you can start, even if it's only
in the form of
On Feb 20, 2006, at 16:21, Karl Forner wrote:
I was expecting this kind of answer (Just Do It) ;-)
Where/How could I add this kind of FAQ ?
Write a draft, post it here for comments. Then polish it up and if it
looks good, one of us will commit it.
What you add may fit as a patch to
We're going to try something a little different. With Chip's blessing
I've written a very early draft of the PDD for I/O (not numbered
yet). The attached PDD isn't a completed document with Chip's seal of
approval, it's a seed for discussion.
What I need from you all is comments. What's
On Mar 5, 2006, at 15:35, chromatic wrote:
On Sunday 05 March 2006 11:46, Nicholas Clark wrote:
On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote:
[It's worth considering making all the network I/O opcodes use a
consistent way of marking errors. At the moment, all return
On Mar 6, 2006, at 4:08, Leopold Toetsch wrote:
Some remarks re the pdd and discussion so far.
o write ... [Is this redundant?]
write isn't needed. It is there, as some time ago, print was't
able to write strings with \0s inside.
Now marked in the PDD as deprecated.
(To make it
On Mar 5, 2006, at 13:52, Joshua Isom wrote:
On Mar 5, 2006, at 3:46 PM, Nicholas Clark wrote:
On Sun, Mar 05, 2006 at 02:53:29PM -0600, Joshua Isom wrote:
A pasm include, such as the signal.pasm(even though signals don't
work
yet), would suffice and is generated at compile time. Parsing
On Mar 11, 2006, at 2:07, Nicholas Clark wrote:
I feel more comfortable with the idea of IO being methods on PMCs
than raw
OPs.
They are methods on I/O objects internally. (Just as most opcodes on
PMCs actually call vtable methods.) So, the question isn't as
significant as it appears.
On Mar 3, 2006, at 15:54, Joshua Isom wrote:
Concerning all the byte/character issues, all the string opcodes
except bytelength work with characters. But the io subsystem
currently only deals with bytes. I know there is the speed issue
for things like reading with dealing with utf8, but
I just committed a more complete draft of the I/O PDD to docs/pdds/
clip/pddXX_io.pod. I've integrated or responded to the mailing list
comments. I also added a good bit of additional discussion of
asynchronous operations and error handling. The original draft was
how it works now, while
On Mar 18, 2006, at 4:18, Leopold Toetsch wrote:
On Mar 18, 2006, at 5:05, Allison Randal wrote:
+=head3 Hybrid solution
+
+Another option is to return a status object from each I/O
operation.
I'm in favour of such a solution.
Also my favorite.
+The disadvantage is that a status
On Mar 19, 2006, at 11:05, Nicholas Clark wrote:
Is the choice of implementation actually visible to a user of the API?
If yes, where, and can we avoid it?
No.
At which point we have flexibility in
how things are actually implemented.
Yes.
I can see that emulating asynchronous ops with
On Mar 19, 2006, at 0:23, Uri Guttman wrote:
if you look at the rfc's (remember those? :) i wrote on this topic,
you
will see that i proposed just that form of api (not at OO as
these). the
only difference between a sync and async i/o op was the addition of a
callback argument (and an
In: docs/pdds/clip/pddXX_exceptions.pod
As with the I/O PDD, this isn't a final form, it's just a draft to
seed discussion. What's missing? What's inaccurate? What's accurate
for the current state of Parrot, but is something you always intended
to write out later? What thoughts have you
On Apr 8, 2006, at 19:49, Bob Rogers wrote:
. . .
=item *
Cpush_eh creates an exception handler and pushes it onto the
control
stack. It takes a label (the location of the exception handler)
as its
only argument. [Is this right? Treating exception handlers as
label
Matt Diephouse wrote:
- languages/forth/
I was actually the last one to provide a patch to forth (there
were some other commits that modified things like copyright info, but
those don't count). That was 20 months ago. The implementation was
horribly dated then and things are far worse
The fundamental legal point is that we're not reserving all rights,
because we're distributing the code under an open source license. Many
open source developers include All Rights Reserved. in a cargo-cult
fashion, without understanding what it means.
Will Coleda via RT wrote:
How does this
Paul Johnson wrote:
I wouldn't have said anything, but your correction seems to indicate
that the (C) is important. Is my information outdated?
It wasn't a correction based on legal requirements, it was a correction
based on this is what we talked about earlier and decided to
standardize
(Randal L. Schwartz) via RT wrote:
According to Brad Templeton's copyright FAQ, it really doesn't mean anything
anyway. If I recall, It was needed in a few south american countries, all of
whom have become Berne-convention parties now, so it really means nothing.
It never meant rights in a
Robert Spier wrote:
Nothing is actually _deleted_ from SVN... it just gets harder to
find. So it'll be there later if you want it.
Aye, I wasn't afraid it would disappear forever. But the old What was
that deleted path I'm looking for, and what revision should I sync back
to? makes it just
Nicholas Clark wrote:
Would this be resolved by entries in the ChangeLog?
In Perl5 the version control history is added to a Changes file, which has
each commit message along with the perforce revision number. It makes it
very easy to search for these sorts of things. I assume that it's trivial
Charles Reiss wrote:
So, to start off, a copyright question:
It would be nice to use libraries that provide relatively portable
atomic operation support (needed for good implementations of most
lock-free schemes), such as HP's atomic_ops [
Chip Salzenberg wrote:
Allison, if you give me the OK, I'll recast pdd23 in the alternative way I
had in mind, where:
* exception handlers are closures,
* the closures are called _inside_ the dynamic scope where the throw occurred,
* a closure returning without executing Ccaught implies I
Chip Salzenberg wrote:
Darn, find_global has collided with pdd21.
Currently find_global is prepared to accept a key or a namespace, and
distinguishing namespaces from arrays is starting to get just a little
too polymorphic for an opcode.
I'm thinking that between get_namespace and the untyped
Will Coleda via RT wrote:
This feature is needed for how parrot currently handles dynamic pmcs. If :immediate is
deprecated, part of that deprecation needs to include keeping languages which use dynamic
pmcs (perl6, tcl) functioning.
:immediate won't be deprecated. It's a dynamic feature
Audrey Tang wrote:
But again, it's the architect's decision to make, and I will stop to
quibble. :-)
I'd rather help you understand why it's the right choice for a virtual
machine targeting dynamic languages, but if I can't, I can't. :)
Allison
Bob Rogers wrote:
If, as seems likely, exception bookkeeping is moved to a separate
stack in the interpreter (with or without dynamic-wind actions), then
Cbsr/Cret addresses can stay in the Parrot_Context, and all of
pdd23_exceptions.pod that is quoted below ceases to be problematic.
Does
chromatic wrote:
That doesn't quite seem fair; dynamic is a lot broader than just typing.
Certainly any statically typed language with decent support for generic
operations (or at least type-safe polymorphism) and a non-static loading
scheme would be sufficiently dynamic.
I can't
Audrey Tang wrote:
I already filed that as #39716 a few hours ago; also #39715 and #39714,
as per your suggestion:
Excellent.
As I cannot modify links on rt.perl.org, can you do that for me?
Done, and I also added Vishal as a requestor on the relevant tickets.
Thanks!
Allison
Chip Salzenberg wrote:
--- PART 2, IN WHICH AN ELEGANT SOLUTION IS PROPOSED --
On the other hand, we could extend the key PMC to represent emptiness,
i.e. zero dimensions. This seems useful for namespaces and could even prove
useful for real keys. And this makes keys even more compatible
Chip Salzenberg wrote:
On Thu, Jul 06, 2006 at 01:21:08AM -0700, Allison Randal wrote:
The problem is really that we're trying to simultaneously a) refer to
the root HLL namespace directly, and b) pretend that it doesn't exist.
I don't think (b) is quite true. It's more that we're avoiding
Chip Salzenberg wrote:
The below patches are my guess as to how to fix PGE and TGE for the recent
change in .namespace. (That is, C.namespace [''] now means what it says,
and the HLL root is reachable by C.namespace w/o parameters.)
TGE and PGE both need a thorough going-over for the new
jerry gay wrote:
On 7/6/06, Allison Randal [EMAIL PROTECTED] wrote:
meanwhile, back at the ranch, perl6 is failing all
t/00-parrot/08-regex.t tests due to the .namespace changes. chip's
proposed PGE patch fixes those failures.
Oh, I didn't mean don't apply it, just there's more work ahead. I
Chip Salzenberg wrote:
Well, I see a lot to like about this, but (and you knew there was a but
(but that's my job now :-))), in descending order of difficulty:
And you do it so well. Thank you. :)
* The division into two categories (global and symbol) leaves the third
category (current
I gave a Parrot talk at a Ruby user group meeting tonight. Someone
mentioned that they had seen somebody on #parrot who was working on a
new Ruby implementation based on Punie. Do you exist? And is there
anything we can do to help you?
Allison
Matt Diephouse wrote:
So for the runtime (this is the HLL runtime, not the PIR runtime, btw)
we're all set. Arrays fill the need perfectly and let us access the
root HLL namespace. That makes me think that we don't need any new
opcodes.
Chip's latest simplification eliminates the need for
Kevin Tew wrote:
That would be me!
PRuby is the project.
Suggestions of a better project name are welcome.
Possibly Cardinal? (A ruby-red bird.) The original Cardinal project was
started in 2002, but talking last night we decided it needed a complete
re-write in PGE/TGE (which is when you
Chip did a fantastic job on the Exceptions PDD. With a few refinements,
I'm pronouncing it ready to implement. We'll certainly work out more
details as we go along, but the best way to test the design is to start
on the code.
Allison
Chip Salzenberg wrote:
I think it'd be great to maintain a hackathon designated location for those
who are between tutorials, or who like me just show up during tutorial days
for the hell of it. :-)
There's a designated room for hackathon/Camp-style sessions inside the
convention center all
Chip Salzenberg wrote:
Hrm. Relative is the usual apposite to absolute, but we have a three-way
logic here, so appositives don't really work. I think that hll is the
best I can think of, and given the existing .HLL directive, its meaning
is immediately clear:
I like that.
Seems to me
Bob Rogers wrote:
From: Chip Salzenberg [EMAIL PROTECTED]
Date: Mon, 10 Jul 2006 19:41:38 -0700
(You'll probably want to know that get_base_global has a slight object-
orientation connotation from my C++ experience; in C++, a superclass is
called a base class. Whether this
Chip Salzenberg wrote:
[*] Just what it _is_ intended for is an open question. I think the user
base will answer it, if we let them, in time.
To give a concrete and immediately relevant example: the fact that
people are using :immediate to load libraries at compile-time is a good
sign
Audrey Tang wrote:
That is a sane argument, which is why I think punt-and-see has some merit:
as soon as there is a workaround forced to be expressed at :immediate
level, we can evaluate it and see if it's better handled declaratively.
Excellent. (Er, though you know that .loadlib isn't
It occurs to me, after thinking about it overnight, that the .loadlib
directive shouldn't operate at :immediate time, but at :init time,
because it's more common to want a library to load when you run the code
than to load only when you compile the code.
Which leaves us with :immediate for
Leopold Toetsch wrote:
Well, there was already one very legitimate usage of compile time
loadlib, which is now using C.loadlib for that:
We certainly need both compile-time and runtime loading of libraries.
So, it's just a question of which syntax to use for which case.
chromatic suggests
Will Coleda wrote:
I would prefer .include to maintain its current meaning. Not everything
you .include is a complete PIR program.
I think the most common case at the moment is stitching together .pir
files generated by PGE/TGE. Which is useful.
Allison
Patrick R. Michaud wrote:
IIUC, the loadlib opcode (and the new .loadlib directive) are used
strictly for dynamic libraries...
.include is currently compile-time only, and only works with .pir/.pasm
...
Yes, the suggestion is an extreme reuse of existing syntax. Something
that's good to
Leopold Toetsch wrote:
This means, we'd have:
.include file.pasm/.pir ... load macros or constants (no code)
load_bytecode file.pbc ... load a module
$P0 = loadlib file ... load a shared lib (pmc or ops)
.loadlib file... same during compilation
The 5
[EMAIL PROTECTED] wrote:
Modified: trunk/languages/perl6/perl6.pir
==
--- trunk/languages/perl6/perl6.pir (original)
+++ trunk/languages/perl6/perl6.pir Wed Jul 12 17:05:26 2006
@@ -24,9 +24,7 @@
.namespace [
1 - 100 of 845 matches
Mail list logo
