Re: A thought for later -- POD tables
Aaron Sherman writes: Larry Wall wrote: $_ $xType of Match ImpliedMatching Code == = == Any Code$ scalar sub truth match if $x($_) This bit of POD made me think about POD's lack of tabular formatting, What? I see a table. What lack? It looks an awful lot more like a table to me than: H C$_ | C$x | Type of Match Implied | Matching Code T Any | CodeC $ | scalar sub truth | match if C$x($_) does. There are many great things about POD, and this is one of them. Okay, so I want a table in my docs. I don't want to read perlpod to figure out how to write a table. I just write my table and it works as long as I indent. Sure, it won't be as pretty when it gets turned into HTML or LaTeX, but the point is, that it's readable when it gets there in any case. The point of documentation isn't to be pretty, it's to be descriptive. Another great thing about POD is that it doesn't let you be pretty unless you're a brilliant ASCII artist. And then you can focus on your content rather than your look. Excuse me, you Ihave to focus on your content rather than your look. I've already had my epiphany about POD, though, so I'll spare doing it again. In short, there are two things that I see about POD that need to change: =over =item 1) C=directive lines shouldn't have to be in their own paragraph, in order to condense lists and make them more readable from POD source. =item 2) (The one that has been made clear several times) When an =end foo closes a =begin foo that opened the POD section, the =end should close the POD section. =back No tables. Keep the number of things that I can distract myself with when I should be writing documentation down to a clean 565. I don't need 566. Luke
Re: A thought for later -- POD tables
On Sat, Aug 21, 2004 at 12:03:10AM -0600, Luke Palmer wrote: : I've already had my epiphany about POD, though, so I'll spare doing it : again. In short, there are two things that I see about POD that need to : change: : : =over : : =item 1) : : C=directive lines shouldn't have to be in their own paragraph, in : order to condense lists and make them more readable from POD source. Yes, I plan to bless that one, though I don't think I've said it publicly. : =item 2) : : (The one that has been made clear several times) When an =end foo closes : a =begin foo that opened the POD section, the =end should close the POD : section. Likewise a bare =for in the middle of Perl code should revert to Perl code at the end. : No tables. Keep the number of things that I can distract myself with : when I should be writing documentation down to a clean 565. I don't : need 566. However. It's possible to make really clean pod tables by processing verbatim lines as tab-separated values. We did the tables in Camel 3 that way, though it took a special preprocessor/postprocessor that understood C=begin table and C=end table, and also understood that lines consisting of all fields are special, and that consecutive verbatim paragraphs are part of the same table. The main trick is to split not on /\t/ but on /\t+/. That way you can use multiple tabs to keep your columns aligned. The main downside is sometimes your tables get too wide for 80 columns. A secondary downside is that people's formatting gets off when they quote your table in email. I think our table processor also allowed a bit of font modification, which verbatim paragraphs don't normally allow. That was a necessary luxury in our case. But you can make some rather pretty POD tables that actually have enough information to keep the columns straight. Larry Larry
Re: A thought for later -- POD tables
L:uke, just a note before I reply to you specifically: I understand your concerns, and I have no interest in blurring the line between presentation and markup, which I think ultimately is where your concern comes from. In fact, if you re-read what I wrote (and what I write below), you'll see that I take great pains to make sure that that's not the case. Luke Palmer wrote: I don't want to read perlpod to figure out how to write a table. Well then don't. No one is prying ASCII-art tables out of your hands here. I just write my table and it works as long as I indent. Sure, it won't be as pretty when it gets turned into HTML or LaTeX, but the point is, that it's readable when it gets there in any case. The point of documentation isn't to be pretty Pretty is not the issue. The issue is markup. If, for example, I happen to be blind, and I'm reading Perl documentation via a text-to-speech program, it may well know how to take an HTML document and read a table to me in some reasonable way, but if you hand it a pre-formatted block of text that is supposed to LOOK like a table, I'm pretty (no pun intended) much SOL. Ok, so that's an extreme example (though, I have a mostly blind friend who might not think so). How about the simple fact that S4 is supposed to be a living document, but if Larry wants to change that table, he has to go in and re-hand-format that entire ASCII-art picture of it! I know that I've avoided making changes to tables in my documentation at work for EXACTLY that reason. If you have a table markup, then you can add or remove a column with minimal pain. If you just wanted to draw your documentation using ASCII-art, then there would be no need for POD at all. You would simply write plain text. The point behind POD was to make writing documentation for diverse markup systems more reasonable. Such markup systems all have the ability to format a table, so why exactly would you not want to take advantage of that? What happens when Larry w Also, you pointed out that my example was hard to read, but you only pointed out the particularly complex example (where I WANTED to demonstrate all of the complex cases), not the simple one. The general case would probably look like: H Function | Returns T foo | nothing T bar | a number between 1 and 1000 T baz | your program as a string That's certainly no harder to read than an ASCII-art table, and provides you with many more options in terms of presentation, accessibility and the ability to post-process the documentation (e.g. to extract information in an automated way).
Re: incremental garbage collection 1/2
André Pang [EMAIL PROTECTED] wrote:
On 21/08/2004, at 5:48 AM, Leopold Toetsch wrote:
3) The copying collector isn't integrated yet. But that should be easy.
After finishing sweep and if there is some possible wastage in the
memory pools, these get compacted.
I thought Parrot wasn't using copying collectors, since you're exposing
PMC addresses to C?
We have two kinds of managed items:
1) objects (PMCs, string headers, buffer headers)
2) variable-sized memory (string or buffer memory) These items always
hang off from 1)
1) get recycled by a non-copying mark and possibly sweep collector
2) gets recycled by either the GC - the copying collector or by using
system memory that gets freed with Configure --gc={malloc,libc}.
leo
Re: [PATCH] Re: [perl #31128] Infinite loop in key_string
Steve Fink wrote: ... For PerlHash, P0[foo;3] seems to be interpreted as an iterator access? I hope there's some other way of indicating that. Yep, KEY_integer_FLAG used to indicate, get me the next key and is used by the iterator. But as your test shows its ambiguous. We are already allowing integers and plain PMCs as aggregate keys, so we can't use that flag for iterator too. We still have KEY_number_FLAG. It's unused. I can't imagine that we gonna index aggregates by floating point numbers[1]. So if no one hollers I'll reuse this flag for denoting iterator access for hashes. leo [1] and it doesn't make it through imcc, it's an error anyway
Re: incremental garbage collection 1/2
Dan Sugalski [EMAIL PROTECTED] wrote: At 9:48 PM +0200 8/20/04, Leopold Toetsch wrote: 0) Parrot's nomenclature DOD vs GC is a bit misleading. The DOD subsystem is the stop-the-world mark sweep collector that recycles object headers. The GC is the copying collector for variable sized string and other buffer memory. The incremental mark sweep collector (src/gc_ims.c) is an alternative for the DOD thingy and reuses some code in src/dod.c. Nah, this is actually correct. The DOD does, in fact, look for dead objects (if you consider PMC and buffer headers objects. ... and frees dead objects. That's exactly a mark and sweep garbage collector. DOD is the first phase of that garbage collection. It would be rather useless, if we only detect garbage and not collect it. It's misleading. ... The GC, on the other hand, collects up garbage memory, making the assumption that all the objects marked live are, in fact, live. Separate phases, separate purposes. The GC is a separate phase, yes. It's a second garbage collector, this time a copying collector that takes advantage of liveness information of fix-sized headers. And it does *not* run on any assumption of all being marked live. It runs on the fact that all that's marked dead is dead. If a DOD run preceded the GC, then it collects all dead buffer memory. If not it would run inefficiently and copies buffer memory around that could be dead. This works on the presumption that our mutable strings chew up memory more than objects in the normal running of things, which seems bourne out by the programs that look like 'normal' code. Well, while it's an independent GC phase with a special purpose it can run efficiently only after DOD. leo
Re: Updates to modules-related pod
mAsterdam == mAsterdam [EMAIL PROTECTED] writes: mAsterdam Randal L. Schwartz wrote: BTW, isn't the habit to post to c.l.p.announce a bit deprecated now ? Not at all. More people should do it. Don't remove it. Either that, or entertain a proposal to cancel the group. mAsterdam Which of these are still alive and kicking? Not sure how that relates as a followup to my post. Or was it a non-sequitor? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Synopsis 2 draft 1 -- each and every
On Fri, 20 Aug 2004, Dan Hursh wrote:
Peter Behroozi wrote:
I'm not particular to any of the verbs used yet, but maybe that's
because I don't think of the as a general iterator, but more of a
gobbler-type creature (and formerly a globber, too). Could we try:
for $foo.fetch { ... } #or
for $foo.grab { ... } #or
for $foo.eat { ... }
And to replace $/ we could have something like:
for $foo.fetch :upto(,) { ... } #or
for $foo.fetch :until(,) { ... }
general impose scalar impose list
--- --
D $foo.eat$foo.bite $foo.gobble
N $foo.look $foo.peek $foo.peruse
hmm, I don't like eat in this case
D $foo.take $foo.grab $foo.horde
D $foo.drink $foo.sip$foo.slurp
N $foo.taste
Ok, I'll stop now. But I do sort of (very minorly) like sip as a mini-slurp.
That assumes folks think of grab as being singular and take as being
open ended. That, and I don't want take to colide with gather{take}.
Oh well.
Dan
--
Adam Lopresto
http://cec.wustl.edu/~adam/
Keyboard not found. Think F1 to continue.
Re: - as - with automatic is rw
On Fri, 20 Aug 2004, Larry Wall wrote:
On Fri, Aug 20, 2004 at 10:07:02PM +0200, Juerd wrote:
: I'm proposing
:
: for zip(@foos, @bars, @xyzzies) - $foo, $bar, $xyzzy { ... }
: for %quux.kv - $key, $value { ... }
That'd probably work on the keys only if the hash was declared to have
object keys. At least in Perl 5, the key is always a copy.
: to mean
:
: for zip(@foos, @bars, @xyzzies) - $foo is rw, $bar is rw, $xyzzy is rw { ... }
: for %quux.kv - $key is rw, $value is rw { ... }
:
: Comments, anyone?
It's really sick, and cute, and I love it. Unfortunately I'm not sure
it passes the Are there already too many ways to declare a sub? test...
It's vaguely possible I could be persuaded on the basis that
for zip @a ¥ @b - { ($^a,$^b) = ($^b,$^a) }
could be made to work. But I'm still dubious. And arguably - {...}
means the same as sub () {...}, implying there are no arguments.
Arguably it already means that. But if - were added, it might be a good
reason to make - {...} mean - $_ {...}, using - {...} for - $_ is rw
{...}. A good way to remove one more special case (maybe offsetting the extra
way to declare a sub, and sweeten the whole deal).
--
Adam Lopresto
http://cec.wustl.edu/~adam/
Yesterday upon the stair
I met a man who wasn't there.
He wasn't there again today --
I think he's from the CIA.
[perl #31260] CVS fails to build on ia64-linux
# New Ticket Created by Duraid Madina # Please include the string: [perl #31260] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31260 --- osname= linux osvers= 2.4.25-dsa-itanium-smp arch= ia64-linux-thread-multi cc= cc --- Flags: category=core severity=high ack=no --- CVS fails to build on ia64-linux: it _almost_ builds, but: c++ -o parrot -L/usr/local/lib -Wl,-E -g imcc/main.o blib/lib/libparrot.a blib/lib/libicuuc.a blib/lib/libicudata.a -ldl -lm -lpthread -lcrypt -lrt -lgmp blib/lib/libparrot.a(cpu_dep.o)(.text+0x52): In function `trace_system_areas': src/cpu_dep.c:77: undefined reference to `flush_reg_store' collect2: ld returned 1 exit status and it turns out that config/gen/platform/ia64/asm.s was never compiled into an object file. --- Summary of my parrot 0.1.0 configuration: configdate='Sat Aug 21 08:31:13 2004' Platform: osname=linux, archname=ia64-linux-thread-multi jitcapable=1, jitarchname=ia64-linux, jitosname=LINUX, jitcpuarch=ia64 execcapable=0 perl=/usr/bin/perl Compiler: cc='cc', ccflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', Linker and Libraries: ld='cc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-ldl -lm -lpthread -lcrypt -lrt -lgmp' Dynamic Linking: so='.so', ld_shared='-shared -L/usr/local/lib -fPIC', ld_shared_flags='' Types: iv=long, intvalsize=8, intsize=4, opcode_t=long, opcode_t_size=8, ptrsize=8, ptr_alignment=1 byteorder=12345678, nv=double, numvalsize=8, doublesize=8 --- Environment: HOMELANGLANGUAGELD_LIBRARY_PATHLOGDIRPATHSHELL
Re: Synopsis 2 draft 1 -- each and every
On 8/20/04, [EMAIL PROTECTED] (Luke Palmer) wrote:
So all the laziness goes into the array implementation. But you don't
even need to write your iterator fancily. If you just write your scalar
version of postcircumfix:, Perl will do the rest.
So if you use an iterator in list context, Perl will automatically call it
repeatedly for you?
That still means Perl has to know when something is an iterator, which is
fine for (or whatever it ends up being called), but when your object
has different ways to iterate (e.g. .keys, .values, .kv), they'd have to
be defined as is iterator or some such.
...or... you could just do the extra not-so-fancy work yourself. Multiple
iterators probably aren't really very common anyway, and it's not that
much work after all to make your own method that iterates lazily:
method postcircumfix: ($self: *%opt) returns List {
scalar $self.*%opt, $self.*%opt # [1]
}
If I write it functionally like that, Perl will still do all the rest.
Laziness is built right in the language.
Ah, nice! But doesn't the scalar definition need to be part of the method
too?
method postcircumfix: ($self: *%opt) returns Scalar|List #??
{
given want
{
when Scalar { get_next_value, increment_counter, etc; }
when List { return scalar $self.*%opt, list $self.*%opt; }
# hm, what about void context?
# (should probably iterate once, like scalar context)
}
}
Or can you define separate methods for scalar and list contexts, and have
Perl call whichever one is appropriate? (Which would be neat...
polymorphism from the other end.)
-David polly going crackers Green
Re: A thought for later -- POD tables
$_ $xType of Match ImpliedMatching Code == = == Any Code$ scalar sub truth match if $x($_) How about making paragraphs that have a line like the divider one above special? By simply parsing the = lines, it's easy to make it a table for formatters that understand tables, and you have full control over how things look in plain text. It would mean being a little more careful with the lines, as they should indicate column width, and not just end at the end of the column header. Podchecker can of course be made to warn if there is non-whitespace in a column that had an = in the divider (now: column specification) line. $_ $xType of Match ImpliedMatching Code - == = == + == === == Any Code$ scalar sub truth match if $x($_) An HTML formatter could generate code like: table tr thtt$_/tt/th thtt$x/tt/th thttType of Match Implied/tt/th thttMatching Code/tt/th /tr tr tdttAny/tt/td tdttCodelt;$gt;/tt/td tdttscalar sub truth/tt/td tdttmatch if $x($_)/tt/td /tr !-- ... -- /table I haven't thought of a solution for non-verbatim cells yet. I'm not convinced that they are needed. Juerd
Re: - as - with automatic is rw
Larry Wall skribis 2004-08-20 13:31 (-0700): Unfortunately I'm not sure it passes the Are there already too many ways to declare a sub? test... I'm not seeing it as another way. Technically, of course it is different, but by the user, - and - will probably be seen as one thing, with one of them being the other's specialized form. It's really sick Sick would be if - were introduced to make the variable write-only ;) W R @foos - $foo @foos - $foo @foos - $foo It would be consistent, though... Juerd
Re: Updates to modules-related pod
Randal L. Schwartz wrote: mAsterdam writes: Randal L. Schwartz wrote: Rafael Garcia-Suarez wrote: BTW, isn't the habit to post to c.l.p.announce a bit deprecated now ? Not at all. More people should do it. Don't remove it. Either that, or entertain a proposal to cancel the group. mAsterdam Which of these are still alive and kicking? Not sure how that relates as a followup to my post. Or was it a non-sequitor? ? I was not proving anything. Reading the thread I was reminded of the unclarity of the status of perl newsgroups. You advised Rafael Garcia-Suarez to either use a group (c.l.p.announce) or to entertain a proposal to cancel it. Well, that is a good idea. Expanding on that: A lot of the groups in the list served a purpose at some time but are dead now. It would be a good thing if somebody could do some cancellation proposals to clean it up. But wait - not so fast! Which ones should be cancelled? I cannot determine that. Maybe perl.qa can?
Re: Return with no expression
Larry Wall wrote: On Fri, Aug 20, 2004 at 09:21:02AM +0100, Matthew Walton wrote: : It would be nice if rand behaved a bit more sanely in Perl 6. I can : understand the reasoning for making rand 0 produce between 0 and 1, but : that doesn't mean I have to like it. What makes you think there was any reasoning involved? As far as I can recall, it was entirely due to random factors. :-) Sush, I'm giving you credit from pure blind faith here ;-) I suspect there's an argument that [0,0) ought to be considered undef (which would conveniently numerify to 0 with an optional warning). In the absence of a paradox value, undef would be fine there I think :-)
Re: A thought for later -- POD tables
Luke Palmer wrote: Aaron Sherman writes: H C$_ | C$x | Type of Match Implied | Matching Code T Any | CodeC $ | scalar sub truth | match if C$x($_) Oh, and BTW: My mailer seems to have snuck some extra noise in there. I think it got confused and thought there was inline quoting going on. That leading C should not be there. One of the things I was trying to demonstrate here was the fact that, even though, you could now have C, L (hey! imagine perl.com no longer having to hack perl.pod to make each manpage reference into a link!), or whatever other markup inside a table correctly, you could still visually line up the information so that when viewing the talble as plain text, it was still just as readable as C$_ C$x etc ever was. Woefully, my mailer thought that such clarity was a bad idea ;-)
Re: Return with no expression
Matthew Walton wrote: Larry Wall wrote: I suspect there's an argument that [0,0) ought to be considered undef (which would conveniently numerify to 0 with an optional warning). In the absence of a paradox value, undef would be fine there I think :-) Too bad we don't have NaRN (Not a Random Number)... that's in the IEEE spec, isn't it? ;-)
Re: Synopsis 2 draft 1 -- each and every
David Green writes:
On 8/20/04, [EMAIL PROTECTED] (Luke Palmer) wrote:
So all the laziness goes into the array implementation. But you don't
even need to write your iterator fancily. If you just write your scalar
version of postcircumfix:, Perl will do the rest.
So if you use an iterator in list context, Perl will automatically call it
repeatedly for you?
That still means Perl has to know when something is an iterator, which is
fine for (or whatever it ends up being called), but when your object
has different ways to iterate (e.g. .keys, .values, .kv), they'd have to
be defined as is iterator or some such.
Since operators are going to be less DWIMmy this time around, I suppose
I should have said Perl does the rest if your class does iterator. So
the iterator role would define the listy version for you.
method postcircumfix: ($self: *%opt) returns List {
scalar $self.*%opt, $self.*%opt # [1]
}
If I write it functionally like that, Perl will still do all the rest.
Laziness is built right in the language.
Ah, nice! But doesn't the scalar definition need to be part of the method
too?
method postcircumfix: ($self: *%opt) returns Scalar|List #??
{
given want
{
when Scalar { get_next_value, increment_counter, etc; }
when List { return scalar $self.*%opt, list $self.*%opt; }
# hm, what about void context?
# (should probably iterate once, like scalar context)
}
}
Or can you define separate methods for scalar and list contexts, and have
Perl call whichever one is appropriate? (Which would be neat...
polymorphism from the other end.)
That was the idea, but I realize that I did it wrong. I also realize
that there isn't a right way yet. Dispatching on return value is
something that is pretty hard to implement, and impossible to implement
correctly, as it has a tendency to create paradoxes.
So for now I'd say that you have to put them both in the same method.
Which seems to imply that the iterator role would look for a method name
to use for scalar context. Like sip :-)
Luke
Re: A thought for later -- POD tables
Maybe this train has already left the station, but I find myself preferring Kwiki syntax to POD these days... any chance we could use Kwiki with WAFL for the Perl 6 POD? That of course has already got tables. (Still bracketing with the =for ... =cut directives, though.) Just a thought... -- Peter Scott
Calling conventions for unprototyped subroutines?
Hello, crrently argument count is passed in I3. A comment in untils.c near foldup says that: TODO - IMCC and PDD 3 aren't yet in conformance. This uses the current IMCC setup, but should be changed as soon as IMCC modified to the correct calling conventions. while pdd03 says: ... 0 if all the parameters are jammed in P registers and the overflow array, with a count of parameters passed in PMC registers so: where is the argument count passed? Please note that I3 is also mentioned in compiler FAQ. Thanks! Mattia
[perl #31268] [PATCH] Dynamic library with multiple PMCs
# New Ticket Created by Mattia Barbon # Please include the string: [perl #31268] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31268 Hello, as promised with this patch: pmc2c2 ... --library foo --c pmc1.pmc pmc2.pmc pmc3.pmc ... outputs pmcX.c and pmc_pmcX.h as it did before, plus foo.c and pmc_foo.h containig a single Parrot_lib_foo_load that initialized vtables and MMD dispatch for all the PMCs, taking into account circular PMC dependencies in MMD dispatch. It also updated dynext/foo.pmc removing the now useless #define to -1 and pmc2c2.pl to search for PMCs/PMC dumps in the current directory, too. Nag: the dynext patch from the other week is still unapplied: is there any problem with it or did it just fall through the cracks? Thanks! Mattia pmc2c.diff Description: Binary data
[perl #31269] [PATCH] More packgile dixes
# New Ticket Created by Mattia Barbon # Please include the string: [perl #31269] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31269 Hello, this patch fixes some problems with previous week's patch: it allowed loading and running bytecode when there was no current packfile (interpreter-code == NULL) but created a circular dependency with the loaded packfile containing itself in its directory. The attached patch removes this circular dependency. Regards Mattia packfile.diff Description: Binary data
Re: A thought for later -- POD tables
Luke Palmer wrote: On the other hand, Larry had a good point. Why couldn't we do: =begin table ... =end table For some sufficiently simple ...? Obviously this gives the formatter control over how the table is formatted, which is arguably a bad thing since it won't be implemented (POD tools are mostly lazy about that kind of thing). There's nothing wrong with that. For long tables it would be more efficient, but for shorter tables it would be a tad more cumbersome. The only thing I wanted to avoid (like the plague) was an C=-introduced set of table elements like C=cell and so on. That would lead to a very anti-POD visual breakdown. So I'm starting to like it. I do think that it should be left aligned, as it'll be verbatim text if it's indented. We might want a =begin/=end table around it anyway, to avoid making the formatters do too much bookkeeping. A begin/end would also allow for paragraphs inside of table elements. You get to decide if that's a good or bad thing ;-)
Extending interface: PMC flags and marking
Hello, I think extenders should have access to at least some of the flags in PObj_enum. Should we have a different function for each flag (say: Parrot_PObj_set_custom_mark(INTERP, PMC, value), Parrot_PObj_set_is_class(INTERP, PMC, value) or a single Parrot_PObj_set_flag(INTERP, PMC, flag, value) where flag is an enumerated value declared in extend.h, NOT the values of PObj_enum. Extenders also need Parrot_PObj_mark(INTERP, PMC). Comments? Mattia
Re: Updates to modules-related pod
mAsterdam == mAsterdam [EMAIL PROTECTED] writes: mAsterdam Reading the thread I was reminded of the mAsterdam unclarity of the status of perl newsgroups. mAsterdam You advised Rafael Garcia-Suarez to either use a group mAsterdam (c.l.p.announce) or to entertain a proposal to cancel it. mAsterdam Well, that is a good idea. Expanding on that: mAsterdam A lot of the groups in the list served a purpose at some mAsterdam time but are dead now. A group that begins perl.* is not a Usenet news group. It may be carried amongst cooperating NNTP servers, but it doesn't have the same status as a group that begins comp.*, which is run by more-or-less formal means according to Usenet policy. Hence, my puzzlement. I was talking about a Usenet group (and starting the formal process to abandon it), and you brought up some random non-Usenet groups. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
[perl #31270] [PATCH] add test for op 'does'
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #31270] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31270 Hi, I have been adding tests for the op 'does' in most of the PMC test files. Assuming that the PMCs FloatvalArray, IntList, and MultiArray are doing the 'array' interface, I have added the declaration 'does array' for them. CU, Bernhard -- /* [EMAIL PROTECTED] */ NEU: Bis zu 10 GB Speicher fr e-mails Dateien! 1 GB bereits bei GMX FreeMail http://www.gmx.net/de/go/mail does_20040821.patch Description: Binary data
Re: Extending interface: PMC flags and marking
At 6:44 PM +0200 8/21/04, Mattia Barbon wrote: Hello, I think extenders should have access to at least some of the flags in PObj_enum. Should we have a different function for each flag (say: Parrot_PObj_set_custom_mark(INTERP, PMC, value), Parrot_PObj_set_is_class(INTERP, PMC, value) or a single Parrot_PObj_set_flag(INTERP, PMC, flag, value) where flag is an enumerated value declared in extend.h, NOT the values of PObj_enum. Nope. Flags are for internal PMC use or engine use, not for extenders, at least not for now. Extenders also need Parrot_PObj_mark(INTERP, PMC). Nope. That's for internal use, either by the DOD or the the PMC class functions. We should get the APIs better delineated, though, with the reasons for this stuff being where it is. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: - as - with automatic is rw
Juerd [EMAIL PROTECTED] writes:
Sick would be if - were introduced to make the variable write-only ;)
Sicker still would be if - were introduced to make the variable
neither readable nor writeable. HTH.HAND.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
