Christoph Otto wrote:
So you're saying that multiple inheritance in its current state should
be allowed to continue, and that there's only a problem with ATTRs if a
PMC tries to extend two PMCs, both of which have their own ATTRs?
I'm saying that multiple inheritance between two C-level
Christoph Otto wrote:
The PMC UnionVal deprecation can't be completed until Parrot has
improved ATTR
reuse between extending PMCs. I'm rewriting code to minimize dependence on
the PMC_x_val macros, but I can't eliminate them completely without better
inheritance support. I'd like to
Christoph Otto wrote:
Allison Randal wrote:
(Actually, at the moment you're required to declare
all parent attributes in the ATTR list before the child attributes, so
inherited attributes *are* child attributes.)
When I say attributes, I mean the things that are declared in .pmc
files right
Jonathan Worthington wrote:
I'm curious - is anyone else doing a HLL on Parrot that uses morph? If
nobody is, is it worth spending time on, or even worth keeping?
'morph' was added specifically for the Perl 5 behavior of changing types
when assigned to. But really, a more accurate
Patrick R. Michaud wrote:
Just for the record, AFAICT none of PGE/PCT/Rakudo make use of
morph any longer. We now have the 'copy' opcode to do what the
morph workaround was doing (and I don't think copy is using
VTABLE_morph).
We've been ripping out morph in all the core PMCs too. So, I'm
Christoph Otto via RT wrote:
I'm running into a snag trying to implement this. It turns out that
many lines which use the PMC_x_val macros use them on different types of
PMCs, especially parents and children (e.g. FixedPMCArray and
ResizablePMCArray). There are also some instances where the
Andrew Whitworth via RT wrote:
Okay, I did some work on this last night, and here's the current status.
1) Modified the behavior of the morph PIR override so that it takes a
string in trunk. We previously weren't able to override this method at
all, so nobody is used to the old way at the PIR
Bob Rogers wrote:
I can't log in, though that may just be because I've forgotten the
password. But the odd thing is that the Reset Password page says The
email and username do not match a known account, even though I know my
ID is rgrjr and there are only a few possible email addresses I would
Bob Rogers wrote:
What about those of us who can't log in? I can't even reset my
password, let alone update anything . . .
It won't let you log in at all? Or, once you log in it won't let you do
anything?
I just reset your password, let me know if you don't get an automated
email about
Our trac admins report that this is caused by users who don't have their
email authenticated (that is, Trac sends you a test email, and you
confirm that you got it, so Trac knows the address is valid). When we
upgraded, existing users needed to re-authenticate their email
addresses, but the
Allison Randal wrote:
Our trac admins report that this is caused by users who don't have their
email authenticated (that is, Trac sends you a test email, and you
confirm that you got it, so Trac knows the address is valid). When we
upgraded, existing users needed to re-authenticate their email
Will Coleda via RT wrote:
On Thu Aug 28 00:03:51 2008, alli...@perl.org wrote:
The plan is to make the regular variants (like 'add') create a new
destination PMC, and then deprecate the old n_* variants (like 'n_add').
Does this include n_not , n_bnot, and n_bnots ?
Yes. The 'not', 'abs',
Will Coleda via RT wrote:
Apparently remove the files isn't exactly what was meant here. This probably removes the
need for the remove_pic branch, which is in the process of taking this to its literal extreme.
We do need to remove the files, and the remove_pic branch is on the
right track.
Will Coleda via RT wrote:
I created a branch (remove_pic) to remove src/pic.c; This led to the removal of pic.ops, and
changes in imc, packfile... lots of references to PIC.
chromatic mentioned on #parrot that if we remove PIC, we're going to break all the
predereferenced runcores. After
chromatic wrote:
Within the cmp op bodies, we *know* the arity and most of the types of MMD-
participant arguments at compile time. We can get the types of PMC
participants within the body of the op itself. Thus we could avoid most of
the argument marshalling and counting and analysis if we
James Keenan via RT wrote:
On Wed Dec 17 13:29:59 2008, kjs wrote:
I thought I closed it last time. Trying again :-)
kjs
The ticket has 3 dependencies which are still open. Is it possible that
the ticket cannot be resolved until these dependencies are resolved?
Yes, but you can just remove
Will Coleda via RT wrote:
* Parrot_mmd_add_function
- src/inter_create.c //make_interpreter
Delete that line from src/inter_create.c. Also delete the line before
which initializes 'interp-binop_mmd_funcs' to NULL.
These two lines are initializing the storage for the old MMD subsystem,
Patrick R. Michaud via RT wrote:
Can (should) we do one or more of the following...?
1. Mark GC as a dependency for this ticket
2. Mark this ticket as stalled waiting for GC issues
3. Move this ticket to the new Trac ticket queue
This would help remove this from our active ticket queue,
Andrew Whitworth via RT wrote:
Since I'm monkeying around in the relevant code anyway, this might be
a good task for the next calling_conventions branch. Or, if you
prefer, we could create a second branch for this conversion and do the
work there.
The general consensus on this one is to wait
Will Coleda wrote:
Is the smoke server still used?
Can support for the smoke server be dropped?
+1 from me; I vote for smolder.
+1, on not maintaining two independent solutions for the same problem.
Allison
Will Coleda via RT wrote:
This appears to be the only .pragma; should we leave a placeholder or
just remove .pragma entirely when we remove this particular one?
Nuke it.
Allison
Martin D Kealey wrote:
What about keeping track of where the exception was originally created?
If we have lazy exceptions, then knowing where the fault they represent was
detected is probably more important than were (exactly) it was triggered.
Or does this all amount to the same thing? Is an
Andrew Whitworth via RT wrote:
On Tue Apr 22 10:05:57 2008, [EMAIL PROTECTED] wrote:
We've been kicking around the idea of removing new_from_string for a
while, but the pushback is always that it's useful to be able to create
a new PMC with some initialization data, without first creating a
Andrew Whitworth via RT wrote:
1) Rename this ticket to something more descriptive
2) Rename seatbelts.pod to something more descriptive, like
/docs/dev/C_Functions.pod or something.
3) Expand that documentation to include more cases (ARGIN, ARGMOD,
ARGOUT, all the *_NULLOK variants of those,
On Wed Oct 15 17:48:28 2008, Whiteknight wrote:
With the pdd27mmd branch merged in now, what's the status of this request?
The MMD table is now just a namespace, and namespaces are shareable
between interpreters. So, resolved.
Allison
Patrick R. Michaud wrote:
On Fri, Oct 24, 2008 at 12:18:40PM -0700, Allison Randal wrote:
(I suppose technically we should stop calling this a stack trace since
it's not a stack. But return continuation chain trace is just too
verbose.)
backtrace
Exactly the word I was looking
Will Coleda wrote:
Allison Randal wrote:
...you expect 'rethrow' to keep the stack trace of the original 'die'?
Yes.
The way to do this is to add stack trace information to the Exception's
'stacktrace' attribute when the exception is first thrown, and print
that out for an unhandled
Will Coleda (via RT) wrote:
I would expect both of these programs to output the same thing, but it
looks like rethrow is generating the same output that throw would
here.
What is the difference supposed to be between these two ops?
The two ops are intentionally almost entirely the same. The
Ovid wrote:
I can't speak for Android, but I know one of the constraints on the
iPhone is memory. This, as I recall, is part of the reason why they
don't have garbage collection available and force people to manage
memory directly (this, I might add, is a pain). Since I generally
don't worry
chromatic (via RT) wrote:
Several tests fail with the CGP runcore (parrot -C) when multidispatch
re-enters bytecode -- in specific, anything that calls into src/pic.c from
Parrot_pcc_invoke_sub_from_sig_object causes failures.
The problem appears to be that CGP's PIC tries to poke into the
On Tue Sep 23 22:34:38 2008, cotto wrote:
I propose to reject this ticket. Reducing code duplication is a good
idea, but it's not at all clear to me what this ticket is referring to.
If someone cares to point out what code should be merged, great.
Otherwise this ticket is too vague to be
On Mon Sep 22 06:37:24 2008, Whiteknight wrote:
Sept 08 milestone came and went. Any updates on this ticket? Maybe this
ticket should be closed out (since it's vague) and replaced with another
ticket or tickets for individual places where exit_fatal should be
replaced with real_exception,
James Keenan via RT wrote:
On Sat Oct 18 16:28:22 2008, coke wrote:
I'm submitting some every night at midnight on my osx/x86 box; if it's
obviously a temp directory and the right time frame, it's probably me.
Coke, can you confirm that the test is failing for you now? And, what
version of
chromatic wrote:
On Wednesday 15 October 2008 17:33:58 Will Coleda via RT wrote:
With the attached patch, parrot builds and tests with no errors[0]. A
re-configure is necessary to regenerate a file.
[0] well, no additional or unexpected errors.
Works for me. +1 to apply.
+1
Allison
jerry gay wrote:
On Thu, Oct 16, 2008 at 10:12 AM, Andrew Whitworth via RT
[EMAIL PROTECTED] wrote:
On Sat Jun 11 13:08:49 2005, chip wrote:
Short version: Up through version 0.8 or so, we promise to break
everything constantly (but not until we have a good reason). After
that, we will
NotFound (via RT) wrote:
The Parrot_get_runtime_prefix in src/library.c return a char *,
forcing the places that currently uses it to be more complicated than
desired for no real gain. I added and used a STRING * variant named
Parrot_get_runtime_path (that name makes more sense to me) in r31216
Chris Davaz wrote:
Ahh, cool I didn't even know we had parrot.org. Publishing docs/book/*
would be nice.
On Tue, Sep 23, 2008 at 10:27 PM, Will Coleda:
On Tue, Sep 23, 2008 at 9:04 AM, via RT Chris Davaz:
I suggest we automate the publishing of everything under docs/* and
putting it under
Andrew Whitworth via RT wrote:
The pdd15oo branch was merged in and conversation on this ticket stopped
almost a year ago now. Is there still outstanding documentation work to
do on this topic, besides the general all documentation should be
improved work that always needs to be done? Are there
Andrew Whitworth via RT wrote:
After the pdd27mmd merge, all the n_* opcodes are gone now. I assume the
.pragma n_operators can disappear with them?
Yes. (The n_* opcodes aren't quite all gone yet, but nearly and soon.)
Allison
James Keenan via RT wrote:
Still failing on Darwin/PPC as of r32014:
http://smolder.plusthree.com/app/public_projects/tap_stream/6320/163
Looking at the specific test in question, this may be an integer size
problem.
And I should note that it's also been failing on Darwin/i386:
On Wed Oct 15 12:42:23 2008, coke wrote:
Here's yet another updated version (this time for the exception handler)
of the test that doesn't segfault, but still generates incorrect output
(generates both an OK line and a NOK line)
It looks like the exception handler is resuming after the
NotFound wrote:
Where to put a test for this? There is no t/ops/io.t and creating a
file for each io opcode seems excessive
Create a t/ops/io.t. We'll add to it in the I/O milestone (the next one
on the list, which I'll create a branch for later this week).
Allison
jerry gay wrote:
.\src\pmc\float.c(3340) : warning C4204: nonstandard extension used
: non-constant aggregate initializer
there are now hundreds of these warnings in that build. we do have
warnings ratcheted up pretty high, but i don't think it's worth
relaxing them for this construct unless
Christoph Otto (via RT) wrote:
In response to a question about comparison operators in Pipp*, Allison
suggested that I add a variant cmp VTABLE function which returns a PMC instead
of an INTVAL. This patch adds such a function, named pmc_cmp. It's named
pmc_cmp rather than cmp_pmc to try
jerry gay wrote:
i believe (without looking) that the pmc pdd calls them vtable functions.
i really wish the vtable methods meme would die. they're not
methods. they are a collection functions which define the api to
access the pmc, parrot's abstract data type.
Yup. vtable functions is what
Patrick R. Michaud wrote:
I'm not at all arguing that this automatically means we should call
them methods, but at a conceptual level they certainly seem a lot
like methods, and the vtable implementations contain references to
things like SELF and STATICSELF that make them look awfully
Stephen Weeks wrote:
Commit 31294 implements this behavior. Can I get confirmation that it's
correct?
Just looked over the diff. Perfect. Thanks!
Allison
chromatic wrote:
On Sunday 21 September 2008 03:17:18 [EMAIL PROTECTED] wrote:
+dod_unregister_pmc(interp, sig_object);
[...]
That's far away from registering the PMC; is there a way to move them closer
together?
We could register it after it's returned from
jerry gay wrote:
Patrick R. Michaud wrote:
Other languages have adopted the Perl shortname of hash as well,
including Ruby and this odd little creature known as Parrot. Perhaps
we should rename Parrot's Hash class to AssociativePMCArray? 1/2 ;-)
I wouldn't mind. I mean, various languages
Patrick R. Michaud wrote:
It's also a little unique that the take/yield can happen from called
subs deep within the coroutine, and doesn't have to occur within
the coroutine itself.
That's a general characteristic of all the control exceptions: they can
be caught by any outer dynamic scope,
Patrick R. Michaud wrote:
I sent the appropriate patch to the webmaster, but it hasn't
been applied yet (and I lack a commit bit for the parrotcode.org site).
Once that's applied, the url should be fixed.
Thanks, applied. I also updated parrot.org.
Allison
Patrick R. Michaud wrote:
On Thu, Sep 18, 2008 at 11:00:31AM +0200, Allison Randal wrote:
We'll likely end up with messages scattered between both lists for a
little while, but the perl6-internals/parrot-porters addresses are
deprecated and will be disabled after a sensible deprecation cycle
James E Keenan wrote:
I set up the Google Group, because I know a number of people are
using it. Can I see a show of hands of people who are only using NNTP
and would have difficulty switching to a regular email subscription or
Google Group? (I can't send to a newsgroup from my email
James E Keenan wrote:
That's false. I replied to the newsgroup, which is mirrored by the
mailing list. Whenever I've posted to the list (independent of posts to
RT), the posts have been mirrored by the mailing list. You asked we to
forward this on, so I did exactly what I've done for
Andy Dougherty wrote:
I use NNTP. I much prefer the command-line news interface to Google
Groups, but I guess I wouldn't go so far as to say I would have
difficulty switching to a regular email subscription. Or, to put it
another way: If there were an NNTP interface, I would definitely use
Patrick R. Michaud wrote:
What's the language-agnostic term for this, then?
Well, 'gather' is basically a clever use of a coroutine, and 'take' is
basically a 'yield'. But, what's unique about the construct is that it
aggregates the results. So, 'gather' is an aggregating coroutine and
Stephen Weeks wrote:
This has now been committed to trunk. I'm pretty sure that I updated
every exception handler in the tree.
Apologies if my comments on this thread and update to the exceptions PDD
weren't clear. The resume continuation should continue to live within
the exception
The new Parrot mailing list (replacing perl6-internals/parrot-porters)
is [EMAIL PROTECTED]. If you were subscribed to the old
list, you're now subscribed to the new list. If you were a digest
subscriber to the old list, you're now a digest subscriber to the new list.
More information about
Patrick R. Michaud wrote:
I'm not sure about this last comment -- I think I can imagine
that other language implementations (including new ones we haven't
thought of yet but suddenly becomes possible with Parrot) might
want to make use of gather/take semantics if they're readily available --
Bob Rogers wrote:
Yes, once we have the ability to have exception handlers only handle
specific types of exceptions, then they'll allow all other types of
exceptions to pass through. (Which means we won't end up with the
infinite exception handler loops we currently get if
Patrick R. Michaud wrote:
PDD23:67 has:
: =item Bthrow IEXCEPTION
:
: Throw an exception consisting of the given IEXCEPTION PMC. Active exception
: handlers (if any) will be invoked with IEXCEPTION as the only parameter.
:
:
: =item Bthrow IEXCEPTION [ , ICONTINUATION ]
:
: Throw an
Will Coleda (via RT) wrote:
[...]
I would expect one of the following things to happen here, either:
- an error is generated when test2 is parsed because there is no name
for the named parameter, or
- test2's blarg .param should default to being named 'blarg', so both
calls should work
Christoph Otto (via RT) wrote:
I was looking at #45357 ([TODO] Which exception should be thrown with register
overflow?) and found that Parrot doesn't like subs with more than 205 params.
This seems like a perfectly reasonable limit, but perhaps the behavior could
be more user-friendly.*
Stephen Weeks wrote:
ExceptionHandler currently has a can_handle method that checks whether
the EH has been disabled or not. I propose adding some attributes to
store the minimum severity the EH will handle and the list of exception
types the EH will handle, methods to set and get these
Klaas-Jan Stol wrote:
This ticket doesn't seem to be closeable as is.Would it be good enough
if pmc2c.pl spit out an error on the above definition, or is this even
something that pmc2c.pl should be concerned about?
The goal of the ticket should be for pmc2c.pl to entirely parse the
input PMC
Klaas-Jan Stol wrote:
Allison:
I made the following changes in pirc/new:
.arg - .set_arg
.result - .get_result
.return - .tailcall (in context of .return foo() , which thus is now:
.tailcall foo() )
.return - .set_return (in long-style returning : .begin/end_return
.yield - .set_yield ( in
NotFound wrote:
By the way, as mentioned in other thread there is a problem with plain
%s in parrot printf-alike functions. It does not handle well a NULL c
string. This must be fixed. And before, given the current
implementation, the behavior of string_make and his successor in the
strings
Reini Urban (via RT) wrote:
Old: Guess extensions, so that the user can drop the extensions
leaving it up to the build process/install whether or not
a .pbc, .pasm, .past or a .pir file is used.
New: Search only for .pbc, .pasm, and .pir in that order.
The .past file-extension is *long*
Patrick R. Michaud wrote:
On Sat, Sep 13, 2008 at 01:55:05PM -0400, Will Coleda wrote:
+CONTROL_TAKE
} exception_type_enum;
Tcl can currently deal with OK, CONTINUE, BREAK, ERROR, and RETURN.
What's TAKE?
TAKE is like CONTROL_RETURN except that it signals that we expect
execution to
Vasily Chekalkin wrote:
And another question. Should all lvalue occurences of PMC_*_val(SELF) be
replaced with VTABLE_set_*_native? (Except for VTABLE method
implementation of cause)
In general, yes. You'll have to check each PMC to see if they have the
appropriate VTABLE_set_*(_native)
Christoph Otto via RT wrote:
On Mon Oct 22 07:01:59 2007, pcoch wrote:
In src/pmc/hash.pmc:thaw() there is the todo item:
/* TODO make a better interface for hash creation
... do this.
Where do we want to go with this?
Ax the ticket. Vague plans for future change aren't useful.
Allison
chromatic wrote:
That C string leaks. We should have a diagnostic printf which supports
the %Ss format we use in exception formatting strings.
We have one, it's called PIO_fprintf. But, it's only used once in the
repository, in an STM macro.
Added to the I/O milestone tasklist.
Allison
NotFound wrote:
On Wed, Sep 10, 2008 at 9:21 AM, Allison Randal [EMAIL PROTECTED] wrote:
chromatic wrote:
That C string leaks. We should have a diagnostic printf which supports
the %Ss format we use in exception formatting strings.
We have one, it's called PIO_fprintf. But, it's only used
jerry gay wrote:
On Mon, Sep 8, 2008 at 1:09 AM, Allison Randal [EMAIL PROTECTED] wrote:
a) Do abstract base classes as currently implemented in Parrot serve any
useful purpose? If not, eliminate them.
can they be replaced by roles?
Potentially, yes. In the case of the scalar PMC it would
Google has graciously agreed to host the first ever Parrot Developer
Summit. November 15th and 16th, 2008 on Google's Mountain View campus.
You can find directions to the campus at:
http://code.google.com/events/visitors
More details to follow. Hope to see you there!
Allison
chromatic wrote:
t/op/calling_61.pir crashes because Parrot's trying to treat the number -1 as
a PMC. Why?
The desired MMD sub should take two PMCs and returns an INTVAL (frame #5,
signature PP-I), but the invoked MMD sub takes two PMCs and returns a PMC.
The crash comes in convert_arg,
Patrick R. Michaud wrote:
Just for clarification: IIUC, the n_* opcodes and their semantics
aren't really going away -- they're simply being renamed to not
have the leading n_ prefix. It's the existing add, sub,
mul, div, etc. opcodes that are being eliminated.
Yes. That is, calling
Will Coleda wrote:
Instead of spending time fixing a probe that isn't being used, we
should rip it out. If we eventually need it again, we can start from
here, but there's no point in probing for features that we never use.
It's wasting developer (and less importantly, CPU) time better spent
Christoph Otto wrote:
If those are your thoughts on the subject, then it seems to make sense
to add the pdd format test to make test. The attached patch does this.
I'll apply it and mark this ticket as resolved before the next
#parrotsketch unless there are any objections.
Excellent idea.
Christoph Otto via RT wrote:
If there isn't a technical reason why this is necessary, there's no
reason to create such a limitation. If there is such a reason, just
pick something big and make the code enforce it.
The PDD should of course be kept in sync with reality, but that simply
entails a
chromatic wrote:
The scalar PMC is abstract, but it contains multis that need registration with
the MMD system at initialization time. PMCs containing multis register those
multis in their Parrot_PMC name_class_init() functions.
At least, non-abstract PMCs do.
I ran into a similar problem
Christoph Otto via RT wrote:
Is this something we want to go ahead with or should this ticket be
rejected?
I've had it on my hiveminder todo list for over a month now. The problem
is, it's not only a matter of annoying fiddly bookkeeping work now, it's
also annoying fiddly bookkeeping work
Christoph Otto via RT wrote:
I'll sign up to do the grunt work to fix the failing tests if someone
makes a decision on what the consistent behavior should be.
This falls under the I/O PDD, the next milestone. Hold for a couple of
days. I've added it to the tasklist for the milestone:
NotFound wrote:
Given that the name will be mainly used via macros, a long and
meaningful name can be used, such as Parrot_PMCdata_PMCname
That's a good refinement, we can make the change after the next release.
The attached patch does it. There is a lot of changes, I suspect many
of them are
Agreed that this particular ticket is not useful. Resolve it and replace
it with a [CAGE] ticket with explicit instructions on converting all
existing 'sprintf', 'strcat', etc calls with calls to 'snprintf',
'strlcat', etc. (Also include a list of all calls that should be converted.)
This can
I've just committed an initial pass on the Installation PDD. It's
looking good, definitely a good start. I've included some comments to
seed further discussion and development of the draft.
Also, we'll need to include more details on the installation of Parrot
itself (the draft leans pretty
Ronald Schmidt wrote:
I applied for an account and built what seems to me to be an appropriate
Parrot Testing Status page. My proposed link target is
http://www.parrot.org/wiki/some-testing-status-tools . If someone wants
to set me up as a site editor I will fix the link myself otherwise the
Christoph Otto wrote:
The non-draft PDDs are all passing t/codingstd/pdd_format.t as of
r30810, but two of the draft PDDs aren't. Since they're still drafts
and as such are very likely to change, it doesn't seem worthwhile to
bring them into compliance or to have a test depend on them.
I
jerry gay wrote:
the sugar for what can be on the left side of an equals sign needs to
be changed. simply having a first parameter with OUT isn't enough. the
same thing happens for
$P0 = push $S1
which is legal pir syntax, but obscure at best.
ops must have some means of specifying (perhaps
Alejandro Gómez de Argüello y de Laburu wrote:
Following the instructions I found in How to Get Involved at the
parrot.org website, I hereby volunteer to help maintain said website
by updating existing pages or adding new content, or in other ways
such as my skills and time allow.
Thanks for
The new Parrot website http://www.parrot.org/ is now live. Please take a
look, create an account for yourself, and report any broken links you find.
Just creating an account will allow you to create wiki pages. If you'd
like to help out with content on other parts of the site, let me know
and
Moritz Lenz wrote:
Creating an account leads directly to the front page again, without any
indication if it was successful or not.
There should be a message just below the mission statement box and
just above the first story on the main page. Possibly we should make the
text red or put it
Alejandro Gómez de Argüello y de Laburu wrote:
The How to Get Involved page at https://www.parrot.org/dev/get-involved
has a broken link: clicking on Report or fix a bug in this website takes
me to https://www.parrot.org/dev/site.html -- which says Page not found.
The page at
Klaas-Jan Stol wrote:
On Tue, Sep 2, 2008 at 2:28 PM, Allison Randal [EMAIL PROTECTED] wrote:
I'm not clear on why we need to reserve 'if', 'unless' and 'null' either,
since they never appear in locations that could be confused with variables.
there's not a strict reason, no. In fact
Klaas-Jan Stol wrote:
This must make the following syntax rule illegal:
target = null
because if null is declared as a .local, you can't know whether you want
to nullify target, or want to set target's value to that of the .local
variable null.
I take it this is no problem; just stick to
Klaas-Jan Stol wrote:
So, preferably, the special words in PIR will be allowed as identifiers
('if','unless', 'null') and PIR will DWIM. What about the type identifiers:
int, num, pmc, string; should these be allowed as identifiers? The currently
special PIR words such as if, unless, null are
Bob Rogers wrote:
Allison Randal wrote:
+Monkeypatching is certainly possible, but not encouraged.
Cool; a new term in Allison-speak! ;-}
As much as linguists love creating new words, I can't claim credit for
this one:
http://en.wikipedia.org/wiki/Monkey_patch
More later,
Allison
Bob Rogers wrote:
+{{ There seems to be an implied basic assumption here that language
+interoperability is the responsibility of the language
+implementor. It is not. We cannot require that language
+implementors design and implement their languages according to some
+global
As mentioned in RT #49168, I'm in favor of a --language flag, that selects the
default
PBC/PIR file to run, and passes all other arguments to the ':main' sub in that
file. It can also
select default paths based on the options set the the configuration file for
that language.
Then, using the
Klaas-Jan Stol (via RT) wrote:
The parentheses surrounding the arguments are mandatory. Besides making
sequence break more conspicuous, this is necessary to distinguish this
syntax from other uses of the C.return directive that will be probably
deprecated.
The open issue of the 'probably
1 - 100 of 845 matches
Mail list logo
