Bob Rogers wrote:
Out of the possible hacks we could do, I'd rather go for the hack of
providing a way to create a new RetContinuation from within the C code
(even if it's a special kind of return continuation with the same
interface, but a different set of internal actions to
Patrick R. Michaud wrote:
I propose this is removed in a week, please respond if you'd have an
issue with that or think that's too short.
I think it's too long. :-)
Does anything fail if you eliminate it (e.g., via make tests)?
If no, then I think it's okay to eliminate, and we'll see
Bob Rogers wrote:
Almost two weeks ago, I had what I thought was a clever idea for
eliminating the continuation barrier from action invocation: Simply
call the action using the original continuation instead of creating a
new RetContinuation. The original continuation, I reasoned, should be
Pulled from the archive at Leo's request (thanks Leo).
Leopold Toetsch wrote:
It originated in a perl5-ism in the first array implementations, following the
perl-way:
$elems = scalar @array;
which was directly translated to:
set I0, P0
This works at least for small arrays.
The
[EMAIL PROTECTED] via RT wrote:
On Sun Oct 01 16:22:10 2006, mdiep wrote:
At the OSCON 2006 Hackathon, it was decided that we should separate
vtables from methods and add a new :vtable label for PIR subs to mark
them as vtable functions. This gets rid of the current namespace
pollution
To wrap up (or restart) the thread, here are some thoughts from a
high-level view:
HLL classnames should live in the symbol table (i.e. namespace), not in
Parrot's internal class registry. Yes, this means PIR/POST will need
different syntax for instantiating objects from HLL classes. But the
Jonathan Worthington wrote:
OK, so I've added a REQUIREMENTS section to the objects PDD now and
filled it out with some (hopefully most) of what Perl 6 and .Net need as
a start.
Thanks Jonathan, it's a great start!
Allison
chromatic wrote:
On Monday 23 October 2006 09:49, Jonathan Worthington wrote:
Would it be a good idea to start collecting requirements together from
different language implementors so that when the time comes to work on
the OO PDD, there is already a good description of what it needs to do?
Matt Diephouse wrote:
Patrick R. Michaud [EMAIL PROTECTED] wrote:
On Thu, Oct 19, 2006 at 10:01:29PM -0400, Matt Diephouse wrote:
This is unspecced. ATM, all classes go into the 'parrot' HLL. This is
a relic of the past and I think it needs to change. I'm pretty sure
that HLL classes will
must know how to walk each kind of structure: array, hash,
object, whatever and build new ones.
My 0.0002 cents.
Adriano Ferreira.
On 9/28/06, Allison Randal [EMAIL PROTECTED] wrote:
I need a volunteer write up the requirements for a mini transformation
language to use in the compiler tools
Patrick R. Michaud wrote:
On Thu, Sep 28, 2006 at 11:59:52AM -0700, chromatic wrote:
On Thursday 28 September 2006 11:25, Allison Randal wrote:
obj.{bar}() # a string method name
obj.{$S1}()
I'm not sure what's meant by a string method name above, but
I'd look
Leopold Toetsch wrote:
Am Donnerstag, 28. September 2006 21:42 schrieb Patrick R. Michaud:
obj.'abc'() # call 'abc' method of obj
obj.abc()# always the same as above
obj.{abc}() # call method indicated by abc symbol
This makes a lot of
I just got off the phone with Jonathan Worthington. At YAPC::EU he
agreed to draft a PDD for Parrot's bytecode file format. He has done a
fantastic job. He's checking it in now, so everyone will have a chance
to comment. The PDD incorporates a handful of important changes that
have been
I need a volunteer write up the requirements for a mini transformation
language to use in the compiler tools. You wouldn't have to write up the
specification for the language, just what features we need. This will
help us plan what it's going to take to get from here to there, and give
us a
Leo and I just chatted on the phone for a bit. I'll summarize here.
We went over two proposals that he put together, one on variable-sized
PMCs and one on creating a shared base class for some of the common PMC
types. (He's checking the proposals into the repository, so you can all
see them.
Congratulations! Many thanks for all the work you've done, and the work
still to come. :)
Allison
Leopold Toetsch wrote:
Hi folks,
After a long period of fulltime parrot addiction, I've to reduce my parrot
domestication time in favor of a day $job.
I'll try to follow continue parrot
A very simple concept, but one that has entirely changed the project for
me. (Blame Mark Shuttleworth.) The single most important thing is
shipping a 1.0 release of Parrot. We're so close I can taste it, but not
there yet. Elegant theory is a beautiful thing, but what we need now is
cold, hard
I've committed an updated I/O PDD. I'm close to pronouncing this ready
to implement, so get in your comments now.
One piece that is currently missing is a discussion of which lightweight
concurrency model we're going to use for the asynchronous operations.
I've had ongoing back-channel
jerry gay wrote:
but Csay $I0 does *not* work.
i find that annoying.
either make the syntax for methods different than ops (eg C$S0.say())
or make Csay an opcode,
or dodge the syntax issue and make Csay a method on all register types.
forcing me to convert the int to a string in order to
Chip Salzenberg wrote:
How about a 'default' opcode that provides a value instead of null? It
would work for strings and PMCs. Something like:
$S0 = default hsh['key'], ''
or
$P0 = new .Undef
...
$P1 = default hsh['key1'], $P0
$P1 = default hsh['key2'], $P0
Chip Salzenberg wrote:
pbc_merge doesn't allow multiple :load routines.
That's a bug, Shirley.
Currently it's a feature. Only one :load routine is allowed per PIR
file, and pbc_merge basically just packs all the compiled code together.
I could argue that maybe we should allow multiple
Leopold Toetsch wrote:
Am Montag, 17. Juli 2006 21:11 schrieb chromatic:
After discussing the idea with Allison, we both believe that Parrot should
be able to produce a single PBC file from a command like:
parrot -o all_files.pbc file1.pir file2.pir ... filen.pir
Well, that exists
Kevin Tew wrote:
Patrick R. Michaud via RT wrote:
So, if we're going to allow other languages in the transform
bodies, we may want a hereis or podly {{...}}, {{{...}}} syntax to
delimit the transform bodies. At the moment I'm leaning towards the
{{...}} form, if only because PGE is already
Chip Salzenberg wrote:
(And of course I repeat a gentle reminder that the old find_global and
store_global opcodes will eventually [eventually!] go away, so convert
to the {get,make}*namespace and {get,set}*global opcodes instead.)
Which reminds me that we need to propagate the change to
Bob Rogers wrote:
There's no way to get full Continuations working around such C code
barriers,
except by *not* entering secondary runloops at all for these cases[1].
This
could be achieved by (optionally) returning a new PC for all vtable/MMD
functions that is, by
Patrick R. Michaud wrote:
I'd like there to be an :init pragma to mark subs that are to be
executed anytime the file is loaded. In the case of loading from
the command line, the :init subs should be executed prior to the
:main sub.
Agreed and approved. I was going to say approved and added
Matt Diephouse wrote:
Namespace opcodes now accept arrays to select multidimensional
namespaces again. The namespace object methods for setting/retrieving
namespaces and globals are eliminated as redundant.
How does this handle the case where namespaces have a sigil or some
other sort of
Chip Salzenberg wrote:
Matt suggests that the get meme is better for retrieving from a single
known location, while the find meme is better for looking in multiple
places until success. If you agree, then find_lex can remain with its
current name. As can, for similar reasons, find_type.
Kevin Tew wrote:
I'm seeking information regarding TGE's design goals, aspirations,
future plans, etc.
I see that Perl6 implements its own version of PAST and POST nodes.
Is it possible to share basic PAST and POST nodes and extend them for
particular HLL needs?
I know that different HLLs
Another conference, and another opportunity to meet and talk face-to-face.
I'm pleased to announce that Patrick will be taking on the primary
development and maintenance of TGE. He and I will continue working
together on the architecture of TGE and rest of the compiler tool suite.
Patrick
I've just finished a read-through of all the PDDs (which I said I'd do
by OSCON), and will check in the embedded notes I made while reading
when I can connect to svn.perl.org again (known outage, nothing to worry
about).
The next step is to go through the PDDs one-by-one, updating/expanding
Bob Rogers wrote:
Two weeks ago I started writing something I had been thinking about for
a year now, tentatively called Continuations, Coroutines, And All That:
An informal introduction to creating advanced control structures in
Parrot. It is still mostly an outline, though -- it's hard to
chromatic wrote:
Here's what I don't understand. Why is there talk of a stack to keep track of
various flow control constructs? Doesn't a CPS system use a linked list of
continuations to handle normal flow control? If that works there, why not
another linked list of continuations to
Chip Salzenberg wrote:
Allison, I suppose that given get_root_namespace, that we should get rid of
Cinterpinfo .INTERP_ROOT_NAMESPACE?
If that's true, then a good little cleanup task would be removing all usage
of the latter and replacing it with the former.
Yes, agreed.
Allison
Audrey Tang wrote:
Indeed, and I'd like to apologize publicly for the snipping.
Accepted and forgiven.
However, the re2c or regel-based scanner refactoring isn't different
from a flex upgrade patch, as it (by definition) can't affect IMCC's
public API at all. An additional advantage is
[EMAIL PROTECTED] wrote:
* However, the bison interface does not support both interp
and yyscanner as flex inputs; so I created a patch file
at compiler/imcc/imcparser.c.diff -- it needs to be applied
manually whenever imcc.y is regenerated into imcparser.c.
This is really suboptimal,
Audrey Tang wrote:
This is not a maintainable build solution. Revert and come back when
you have one.
Please clarify: What, exactly, is not maintainable? The presence of
a .diff file, or the fact that it needs to be applied manually?
Both.
Assuming both were considered unmaintainable,
Patrick R. Michaud wrote:
Allison just updated pdd21, it looks great! Here's a first
cut at some suggested changes and wordsmithing to the text.
Feel free to adopt, ignore, or discuss any of the suggestions
below as you see fit.
Thanks, applied!
: =item get_global
:
: $P1 =
Kevin Tew (via RT) wrote:
adds preamble section to tge grammar to allow for includes and global
defines at the top of the PIR generated by TGE
For example, I use
preamble{
.include 'interpinfo.pasm'
}
You're on to an important idea, but it still needs refinement.
A bit of background
Chip Salzenberg wrote:
Looking over the recent editorial improvements in pdd21, I need to point out
that, right now, if a method is written in C, it can't have optional
arguments. (This is per Leo; I haven't checked into how/why this
restriction arose.)
Aye. This went through my mind as I
Vishal Soni wrote:
The current implementation is implemented using Flex and YACC. Flex
implementation has limitations in C mode. The C lexer generated by flex
cannot be reentrant/threadsafe. Flex generates thread-safe parsers only in
C++ mode. This limition of flex will defeat the whole
Vishal Soni wrote:
Allison having said that we need an API for byte code generation that
supports plug n play optimizers would it make sense to start
implementing this layer. This API could be used for OST to byte code
generation. Later when Patrick's PGE to C parser generator is ready we
could
Vishal Soni wrote:
Allison this sounds great. To get started I will need some reference to
the OST format. Can you please point me in the right direction (some
documentation or sample code shall do.)?
Start with languages/punie/lib/POST/ and
languages/punie/lib/PIRGrammar.tg. This is the
Audrey Tang wrote:
As I'm writing this, I noticed that Allison has ruled that we go with
PIR/PGE and eventually C-based libpge instead
-- since a lexer refactoring that doesn't affect the IMCC API will
somehow throw important projects on Parrot into a
dead stall, and thread safety for PIR
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 [
chromatic wrote:
On Wednesday 12 July 2006 16:11, Allison Randal wrote:
load_bytecode is good for runtime loading of PASM/PIR/PBC.
Except for the misleading name.
Oh, you mean the fact that much of the time it's not loading bytecode at
all? It has crossed my mind, but the irritation
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
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 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:
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 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
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
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
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
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 [
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
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
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
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
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 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
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 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 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
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 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
The original bug is resolved. I'll move the Solaris/SPARC test
failures to a new ticket.
Allison
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.
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 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
701 - 800 of 845 matches
Mail list logo
