Perl Documentation Project (PDP) BOF
[Note: I've copied a few lists, but all replies should go to the perl-documentation list. Apologies if you receive this message more than too many times.] Open Source Convention (aka The Perl Conference (or reverse())) Date: 07/22/2002 Time: 8:00pm - 10:00pm Location: Grande Ballroom A in the East Tower Moderated by: Casey West, Aaronsen Group Ltd. The Perl Documentation Project (PDP) is my attempt to create a centralized documentation system for Perl like Linux has in it's Linux Documentation Project (LDP). The LDP has been a boon for Linux and I think Perl is lacking in the documentation arena. Well, the most important kind of documentation, problem domain documentation. The goal of this BOF is not to fight over odd implementation details or bicker aimlessly about licenses. Instead this is my opportunity to get the PDP out of my head and into all of yours. In the process I hope to excite you about the project and enlist your help in making it a success. I'll need a wide range of talents for the PDP: writers, web designers, programmers, editors, monkeys, and many more. Anyone can fill a hole if they want to. Please, come to the BOF and see where you fit into this project and find out how it fits into Perl. I'll need some help for this meeting, a good note taker and someone who care record it in a usable format. On or the other will do but both would be best. :-) -- Casey West
RE: [PATCH] rx.dev
Ok, I cleaned up the file a little bit, and added pod declarations. Should be finalized or close to it at least. If anyone likes it, I'll start working on making a .dev file for some other files, and start asking questions while I'm at it probably :) Stephen Rawls __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com rx.dev Description: rx.dev
[patch] win32 io
* win32 can flush it's file buffers (FlushFileBuffers())
* SetFilePointer knows about whence, win32 constants (values, not names) are the same
as in linux.
remarks:
FlushFileBuffers doesn't work for console handles, ms help file says:
Windows NT: The function fails if hFile is a handle to console output. That is because
console output is not buffered.
The function returns FALSE, and GetLastError returns ERROR_INVALID_HANDLE.
Windows 9x: The function does nothing if hFile is a handle to console output. That is
because console output is not buffered.
The function returns TRUE, but it does nothing.
well done microsoft...but it doesn't sound like a big deal. so calling the function
should be just fine.
-daniel
Index: io/io_win32.c
===
RCS file: /cvs/public/parrot/io/io_win32.c,v
retrieving revision 1.18
diff -u -r1.18 io_win32.c
--- io/io_win32.c 8 Jun 2002 03:37:07 - 1.18
+++ io/io_win32.c 16 Jul 2002 00:01:31 -
@@ -201,7 +201,7 @@
void
PIO_win32_flush(theINTERP, ParrotIOLayer *layer, ParrotIO *io)
{
-/* No op */
+FlushFileBuffers(io->fd);
}
@@ -268,7 +268,7 @@
offset.LowPart = lo;
offset.HighPart = hi;
p.LowPart = SetFilePointer(io->fd, offset.LowPart,
- &offset.HighPart, FILE_CURRENT);
+ &offset.HighPart, whence);
if (p.LowPart == 0x && (GetLastError() != NO_ERROR)) {
/* Error - exception */
return -1;
Some more documentation
Hi On my usual place (http://natura.di.uminho.pt/~albie/parrot) I put some more documentation: - PerlString examples - PMC Writting stub (will be, someday, a tutorial for writting PMC's. Meanwhile, I'm learning how to write them :)) Regards Alberto -- Alberto Manuel B. Simoes Departamento de Informática - Universidade do Minho http://alfarrabio.di.uminho.pt/~albie - http://numexp.sf.net
Re: [perl #823] [PATCH] put numeric comparisons in the right order
On Mon, Jul 15, 2002 at 10:17:51PM -0700, John Porter wrote:
>
> Sean O'Rourke wrote:
> > ... all it buys you is a few bits of precision when your ints
> > and floats are both 64-bit, and slower comparisons all the time.
> > IMHO it's a wash, so I did it this way.
>
> I would point out that integers have infinite precision.
> More than a few bits' difference, I'd say.
>
> But you're right. As long as the conversion from int to float
> is done just before the comparison -- i.e. no intervening
> floating-point ops on the numbers -- then the result of
> comparison should always be right, no precision issue.
> (I'm just talking about in the int-vs-int case.)
> So, never mind. :-)
I'm confused. For some values of 64 bit integers, given 64 bit doubles,
the comparison is not correct when both are converted to doubles:
perl5.6.1-64 -le '$a = ~0; $b = $a & ~1; printf "%x <=> %x\n", $a, $b; print $a <=>
$b; {use integer; print $a <=> $b}'
<=> fffe
0
1
5.8.0 does the full fun and games of integer or floating point comparison:
perl5.8.0-64 -le '$a = ~0; $b = $a & ~1; printf "%x <=> %x\n", $a, $b; print $a <=>
$b; {use integer; print $a <=> $b}'
<=> fffe
1
1
IIRC the speed difference was hard to benchmark. However, the ability to
deal with large file offsets, windows device numbers and other 64 bit
quantities correctly was seen as useful.
I presume multimethod dispatch will render this discussion obsolete.
Nicholas Clark
assembler key syntax behaviour
I have a couple of question regarding using keyed access in assembler. Lets say we create an Perlarray: new P0, .PerlArray set P0,5 Array with size 5. assembler.pl will call set_p_ic ( ? maybe im wrong here ) But what about setting size on multdimensional PMC's would it also be: set P0,5,5,5 assembler.pl would try to call set_p_ic_ic_ic This will break things when having N dimensions.. I dont know if im missing something but wouldnt it be better to use KEY structures when assigning sizes on PMC's eg: set P0[5][5][5] This would handle multidim's also wouldnt it be nice if we could do new P0, .PerlArray[10] Just some thoughts... /Josef
Re: hyper operators - appalling proposal
I still feel this adds yet another layer of inconsistency and confusion. I can't look at a piece of code and know what it does, without referring up N lines to the top of the scripts. How is the infinite loop problem any different from other Halting problems? Karl Christian Soeller wrote: > Trey Harris wrote: > >> Yes. This is my fear of hyperoperation being the default for normal >> aggregates. Loops--and large, multiply-nested, potentially-infinite >> ones--can spring out of code that doesn't look loopy at all. Erm... you >> know what I mean. :-) >> >> Karl, do you have any objection to marking aggregates for which >> hyperoperation is to be the default? Then you could say: >> >> my @foo, @bar; # Are the parens required in p6? >> # or >> my (@foo, @bar) is ; # Can you distribute properties? >> <...> >> @foo += @bar; >> >> where is matrix, hyper, or something along those lines (choosing >> great names is Larry, Damian and Allison's jobs, not mine :-) >> >> If we simply made such hyperoperated aggregates builtins rather than >> requiring user-defined classes, this would offer a compromise, would it >> not? > > > This is a good compromise. The numerics person might even be able to say: > > use default => hyperops; # somewhere at the top of your script > @res = @foo * sqrt(@bar); > > while brent and others can do their CGI scripts without having to wait > for the end of the known Perl universe. > >
Re: [perl #823] [PATCH] put numeric comparisons in the right order
On Tue, 16 Jul 2002, Nicholas Clark wrote:
> 5.8.0 does the full fun and games of integer or floating point comparison:
>
> perl5.8.0-64 -le '$a = ~0; $b = $a & ~1; printf "%x <=> %x\n", $a, $b; print $a <=>
>$b; {use integer; print $a <=> $b}'
> <=> fffe
> 1
> 1
>
> IIRC the speed difference was hard to benchmark. However, the ability to
> deal with large file offsets, windows device numbers and other 64 bit
> quantities correctly was seen as useful.
Let's not lose sight of the forest for the trees here -- the comparisons
are now *backwards*, which is considerably worse than imprecise. Here's
what I think the multimethod dispatch version would look like, without the
automatic multimethod dispatch:
INTVAL cmp (PMC* value) {
if (value->vtable == &Parrot_base_vtables[enum_class_PerlString]) {
FLOATVAL fdiff = (FLOATVAL)self->cache.int_val
- value->vtable->get_number(INTERP, value);
if (fdiff == 0) {
INTVAL idiff = SELF->cache.int_val
- value->vtable->get_integer(INTERP, value);
return idiff > 0 ? 1 : diff < 0 ? -1 : 0;
} else {
return fdiff > 0 ? 1 : -1;
}
}
else if (value->vtable == &Parrot_base_vtables[enum_class_PerlNum]) {
FLOATVAL diff;
diff = (FLOATVAL)SELF->cache.int_val
- value->vtable->get_number(INTERP, value);
return diff > 0 ? 1 : diff < 0 ? -1 : 0;
}
else {
/* int or indef */
INTVAL diff = SELF->cache.int_val
- value->vtable->get_integer(INTERP, value);
return diff > 0 ? 1 : diff < 0 ? -1 : 0;
}
}
Why not drop something like this in for the moment, then take another look
when we have multimethods?
/s
Re: hyper operators - appalling proposal
At 8:30 AM -0400 7/16/02, Karl Glazebrook wrote: >I still feel this adds yet another layer of inconsistency and >confusion. I can't look at a piece of code and know what it does, >without referring up N lines to the top of the scripts. > >How is the infinite loop problem any different from other Halting problems? It's not, the issue's really with what's better for the common case, which probably won't be PDL stuff. (Unfortunately--I think it's a nifty realm to work in) However... If operator overloading on particular classes doesn't work for you, and you don't want to just redefine the behaviour of an operator for a particular block, there's always the APL route. You've got all of Unicode handy--there's no reason we can't have a pragma that enables alternate characters for the hyperoperators. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Streams vs. Descriptors
On Mon, Jul 15, 2002 at 08:59:40PM -0400, Melvin Smith wrote: > True async IO implementations allow other things besides just notifying > the process when data is available. Things like predictive seeks, or > bundling up multiple read/writes, etc. aren't doable with select/poll loops. > And the aioread/aiowrite/listio, etc. are a POSIX standard now, so they > should be reasonably available on most UNIXen. I'm not familiar with "predictive seeks", and a quick google didn't turn up anything relevant; can you give a quick explanation? Bundling reads and writes sounds like a job for a buffered I/O layer. Are the aio* calls available on Windows? On the Macintosh? (My OS X system doesn't have a manpage for aioread, and man -k aio doesn't turn up anything obvious.) How about PalmOS? While the POSIX standard is a help, I think async I/O remains far less portable than the more traditional alternatives. > You are right, though, I blurred the concepts. Callbacks are good to have > as well, > for calling code blocks when data is available, and this might be done > as an event loop, or a thread. However, the talks I've had with Dan always > ended > up in us deciding that calling an event loop between every op, or even > every N ops wasn't what we wanted to do. Certainly, calling an event loop between every op would be insane. That's not the normal way of using one, however. Consider the (excellent) Tcl event loop as an example: When a condition triggers the loop, it invokes the appropriate callback which runs to completion before returning control to the loop. This doesn't allow an event to interrupt the current thread of control, of course. The most common way of having multiple concurrent threads is, however, exactly that--threads. Threads can be used independently (the Java approach; all I/O is blocking) or in conjunction with an event loop (the Macintosh OS X event loop takes this approach). I really recommend taking a look at the Tcl event loop and I/O system, if you haven't already. It's a joy to work with, and one of the best features of that language. > For many things, synchronous IO is adequate, and faster, but for people > that really want the aio interface, I'm not sure it is worth trying to fake > it. I'm sure that there are things async I/O is very good at, but I'm not certain it makes sense to design Parrot's I/O system around them. Might it not make more sense for async I/O to be available via an alternate API? - Damien
Re: Streams vs. Descriptors
Damien Neil wrote: > I'm not familiar with "predictive seeks", > can you give a quick explanation? It's very much like predictive loading of the instruction cache in a cpu. It makes a heuristic guess that since you just read 1000 bytes in order, you're probably going to want to read the next 1000 bytes in order, so it reads them in even before you ask for them. This can be extended to seeks in general. However, "prediction" is usually too strong a term. It's usually just pre-reading of the linear stream[1]. (The program is a lazy consumer. :-) > Consider the (excellent) Tcl event loop as an example > . . . > I really recommend taking a look at the Tcl event loop and I/O > system, if you haven't already. > It's a joy to work with, and one of the best > features of that language. I agree 1000%. I believe that one design goal of parrot should be to make it as easy, or easier, to write Expect in it. In the end, there should be nothing of which it can be said, "It is easier to do in Tcl than in Perl." [2] (Tcl fans should not be offended by this; it is sincere flattery.) [1] Advanced hardware CPUs do try to get fancier, though, I'm sure. [2] That is, until both languages target parrot. -- JohnDouglasPorter __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Re: Grammar (take V.00I_0I)
In his P6 Summary for 2002-07-14, in section
"Perl 6 grammar, take 5", Piers says:
someone pointed out that [the grammar] had a problem
with code like
{ some_function_returning_a_hash() }
Should it give a closure? Or a hash ref?
Larry hasn't commented so far.
I couldn't find where anyone said any such thing,
but regardless, it's still a good question.
I believe it should give a hash ref, for two (related)
reasons:
a. it is the more common case. Better Huffman coding.
b. there is a word to make it a closure explicitly
which the programmer can add if that's what she
wants. No such word (AFAIK) does the same for
a hash ref.
And if this is something that has already been hashed out,
never mind. :-)
--
JohnDouglasPorter
I am intrinsically no good
I have a heart that's made of wood
__
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com
Re: Streams vs. Descriptors
On Tue, Jul 16, 2002 at 11:35:10AM -0700, John Porter wrote: > Damien Neil wrote: > > I'm not familiar with "predictive seeks", > > can you give a quick explanation? > > It's very much like predictive loading of the instruction cache > in a cpu. It makes a heuristic guess that since you just read > 1000 bytes in order, you're probably going to want to read the > next 1000 bytes in order, so it reads them in even before you > ask for them. This can be extended to seeks in general. > However, "prediction" is usually too strong a term. > It's usually just pre-reading of the linear stream[1]. > (The program is a lazy consumer. :-) Ah, that I'm familiar with. Surely that isn't specific to async I/O? I'm fairly certain that many OSs will do readahead on ordinary read() calls. > In the end, there should be nothing of which it can be said, > "It is easier to do in Tcl than in Perl." [2] Hear, hear! :> I've been missing Tcl's event loop for years. - Damien
Re: Grammar (take V.00I_0I)
On Tue, 16 Jul 2002, John Porter wrote:
> In his P6 Summary for 2002-07-14, in section
> "Perl 6 grammar, take 5", Piers says:
>
> someone pointed out that [the grammar] had a problem
> with code like
>
>{ some_function_returning_a_hash() }
>
> Should it give a closure? Or a hash ref?
> Larry hasn't commented so far.
>
> I couldn't find where anyone said any such thing,
> but regardless, it's still a good question.
>
> I believe it should give a hash ref, for two (related)
> reasons:
>
> a. it is the more common case. Better Huffman coding.
Too bad its a closure, then. A4 says that bare braces will be a closure
unless they conatin a pair constructor => at the top level.
I imagine bare braces without a
pair construcor referring to a closure is more common than constructing a
hashref... in Perl 6, that is. (That's just a guess, though).
> b. there is a word to make it a closure explicitly
> which the programmer can add if that's what she
> wants. No such word (AFAIK) does the same for
> a hash ref.
C makes a closure. C makes a hashref. So there is a word.
> And if this is something that has already been hashed out,
> never mind. :-)
It is. Well, I minded anyway.
Luke
KEY* and multidim array access thoughts
Still trying to solve the assembly/PMC vector interface. Accosted Dan on IRC re: multidimentional indices. Looking for thoughts on this. Working under assumptions: * There is no assembler syntax yet, or atleast not final. * Hardcoding KEY *'s into the assembly is the only way so far. * Typically, an array index will be an int. * Multidimentional indices are only useful if they can be generated by executing code on the fly. The classic case of $map->[$x]->[$y]->[$z] comes to mind. This should collopse to $map->[$x,$y,$z] (or whatever the RFCs say the syntax should look like if anything). Two suggestions were made: * KEY * get_key() method added to PMCs. * PMC's be accepted in place of or in addition to KEY *'s in varients taking multidim subscripts. Working on a PMC representation that doesn't decompose, I'm eager to get this feature =) Thoughts? Thanks, -scott On Sun, 14 Jul 2002, Dan Sugalski wrote: > Yup. That's why I try and be on #parrot with some regularity. (The
Re: KEY* and multidim array access thoughts
Scott Walters wrote: > * PMC's be accepted in place of or in addition to KEY *'s > in variants taking multidim subscripts. In particular, a PMC containing a vector (aka tuple, aka array) of indices, one per dimension. As in so many other cases, the array object and the key vector object should intrinsically know how to work with each other; this should not need much if any additional support at the parrot language level. -- JohnDouglasPorter __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Re: assembler key syntax behaviour
> But what about setting size on multdimensional PMC's > would it also be: > set P0,5,5,5 > assembler.pl would try to call > set_p_ic_ic_ic > This will break things when having N dimensions.. I don't see how it could possible be workable to have all the indices listed out in the instruction... since the possible number of dimensions is >>1 (no, not right-shift 1) That's too many instructions and an onerous and arbitrary limitation. That's why I proposed the index vector PMC type. Gather all the indices up into a single thing. (Well, not a separate type, necessarily, but a special use for an array (or tuple) variable.) # P0[1][3][5] = 7; set P1, 0, 1 set P1, 1, 3 set P1, 2, 5 set P0, P1, 7 And if the length of the vector doesn't match the dimensionality of the array, throw up. -- JohnDouglasPorter __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Re: vtables and multimethod dispatch
On Mon, 15 Jul 2002, John Porter wrote: > "David M. Lloyd" wrote: > > Do we really want *two* inheritance trees per object > > in Perl 6? One language-level and one PMC-level? > > Well, parrot != perl6, so I don't see a problem. Ugh. > The MM dispatch problem is pretty much solidly in > the realm of pmc inheritance, There _is_ no pmc inheritance right now. There's just a set of default functions. > I'm guessing you didn't intend irony there? :-) No. > > There is really no inheritance of any kind going on, > > it just sticks pointers to the default functions into the vtable > > structure method entries for undefined methods. > > But that's what type inheritance is! Not really. There is only one "base class". Also, you're not inheriting a data structure or member variables. All you "inherit" (which actually happens at compilation of the PMC) are "member functions". If you happen to use your data differently than default.pmc then these functions are no longer valid. If any of this is to change then I haven't heard of it. - D <[EMAIL PROTECTED]>
Re: vtables and multimethod dispatch
David M. Lloyd wrote: > John Porter wrote: > > The MM dispatch problem is pretty much solidly in > > the realm of pmc inheritance, > > There _is_ no pmc inheritance right now. > There's just a set of default functions. Call it what you want. The point is that this type schema is at the parrot level, and is not the concern of a user-level language like perl (except where explicitly exposed by user parrot code, I suppose). -- JohnDouglasPorter __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Re: vtables and multimethod dispatch
John Porter wrote: > The point is that this type schema is at the parrot level, > and is not the concern of a user-level language like perl Of course this is not really true; perl scalars, arrays, and hashes (etc.?) are implemented as PMCs under the hood, so in that sense they are related by whatever familial associations exist between their respective PMC types. -- JohnDouglasPorter Remind me later to explain why all PMCs are of the same type, but of various different classes. __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Re: vtables and multimethod dispatch
On Tue, 16 Jul 2002, John Porter wrote: > > David M. Lloyd wrote: > > John Porter wrote: > > > The MM dispatch problem is pretty much solidly in > > > the realm of pmc inheritance, > > > > There _is_ no pmc inheritance right now. > > There's just a set of default functions. > > Call it what you want. The point is that this type schema is at the > parrot level, and is not the concern of a user-level language like perl > (except where explicitly exposed by user parrot code, I suppose). No, the point is that all this talk about type-space mm dispatch depends on there *being* type space. Since there is currently no inheritance to speak of then there really is no typespace so all of this talk is moot, unless Dan comes along and says that yes there will now be real inheritance on the PMC level. Whether or not that will cause problems will remain to be seen. - D <[EMAIL PROTECTED]>
[perl #825] [PATCH] Fix underflow error in fact_x_i
# New Ticket Created by Tony Payne
# Please include the string: [perl #825]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=825 >
Conversion from a signed (int,float) to an unsigned int was causing
underflow. Therefore, fact(-1) becomes fact(UINT_MAX), which is
absurdly large :-). With this patch, it returns 0. Tests are also
included.
++t
-- attachment 1 --
url: http://bugs6.perl.org/rt2/attach/3880/3590/523641/fact.diff
Index: math.ops
===
RCS file: /cvs/public/parrot/math.ops,v
retrieving revision 1.1
diff -u -r1.1 math.ops
--- math.ops 17 Jun 2002 18:06:11 - 1.1
+++ math.ops 16 Jul 2002 22:03:46 -
@@ -122,8 +122,9 @@
=cut
inline op fact(out INT, in INT) {
-
-UINTVAL i = $2;
+/* Coercing a negative to a UINT can get pretty ugly
+ * in this situation. */
+INTVAL i = $2;
UINTVAL q = 1;
while(i>0) {
q = q*i;
@@ -134,8 +135,9 @@
}
inline op fact(out NUM, in INT) {
-
-UINTVAL i = $2;
+/* Coercing a negative to a UINT can get pretty ugly
+ * in this situation. */
+INTVAL i = $2;
UINTVAL q = 1;
while(i>0) {
q = q*i;
Index: t/op/integer.t
===
RCS file: /cvs/public/parrot/t/op/integer.t,v
retrieving revision 1.25
diff -u -r1.25 integer.t
--- t/op/integer.t 28 Jun 2002 18:50:40 - 1.25
+++ t/op/integer.t 16 Jul 2002 22:03:46 -
@@ -1,6 +1,6 @@
#! perl -w
-use Parrot::Test tests => 33;
+use Parrot::Test tests => 35;
output_is(< 30;
+use Parrot::Test tests => 32;
use Test::More;
output_is(<
Re: [perl #823] [PATCH] put numeric comparisons in the right order
On Tue, Jul 16, 2002 at 07:42:25AM -0700, Sean O'Rourke wrote:
> On Tue, 16 Jul 2002, Nicholas Clark wrote:
>
> > 5.8.0 does the full fun and games of integer or floating point comparison:
> >
> > perl5.8.0-64 -le '$a = ~0; $b = $a & ~1; printf "%x <=> %x\n", $a, $b; print $a
><=> $b; {use integer; print $a <=> $b}'
> > <=> fffe
> > 1
> > 1
> >
> > IIRC the speed difference was hard to benchmark. However, the ability to
> > deal with large file offsets, windows device numbers and other 64 bit
> > quantities correctly was seen as useful.
>
> Let's not lose sight of the forest for the trees here -- the comparisons
> are now *backwards*, which is considerably worse than imprecise. Here's
I had. I didn't realise that this was the current situation.
> what I think the multimethod dispatch version would look like, without the
> automatic multimethod dispatch:
>
> INTVAL cmp (PMC* value) {
> if (value->vtable == &Parrot_base_vtables[enum_class_PerlString]) {
> FLOATVAL fdiff = (FLOATVAL)self->cache.int_val
> - value->vtable->get_number(INTERP, value);
> if (fdiff == 0) {
> INTVAL idiff = SELF->cache.int_val
> - value->vtable->get_integer(INTERP, value);
> return idiff > 0 ? 1 : diff < 0 ? -1 : 0;
> } else {
> return fdiff > 0 ? 1 : -1;
> }
When we get back to worrying about the details, I think NaNs are going to
return -1. I'm not sure if this is a huge concern yet, although it could
get confusing if A cmp B is -1, and so is B cmp A.
> }
> else if (value->vtable == &Parrot_base_vtables[enum_class_PerlNum]) {
> FLOATVAL diff;
> diff = (FLOATVAL)SELF->cache.int_val
> - value->vtable->get_number(INTERP, value);
> return diff > 0 ? 1 : diff < 0 ? -1 : 0;
> }
> else {
> /* int or indef */
> INTVAL diff = SELF->cache.int_val
> - value->vtable->get_integer(INTERP, value);
> return diff > 0 ? 1 : diff < 0 ? -1 : 0;
> }
> }
>
> Why not drop something like this in for the moment, then take another look
> when we have multimethods?
Putting in something that works well enough, and flagging it for a revisit
later seems like a very good solution.
Nicholas Clark
--
Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: Streams vs. Descriptors
On Mon, Jul 15, 2002 at 12:16:29AM -0400, Melvin Smith wrote: > 2) Filters (or IO disciplines) - People have different opinions on what > these > even mean. To me it means a "layer" that can be pushed onto an IO stack > that may filter or transform the data and/or perform opaque actions, while > representing the IO handle as a standard stream with a standard API. > Also think about how IO layers can be implemented completely in Parrot. Can we learn from the PerlIO system that 5.8 is about to give to the world? You can write this in C (and it is mostly C, not XS), or in perl. I can't comment on what they are like to write in perl, but they're not that hard to write in C. The two I've written (on a CPAN mirror near you) are PerlIO::gzip (does gzip compression and decompression), and PerlIO::subfile (treats a section of a file as if it is a whole file - lets you read direct from a tar on an uncompressed file stored in a zip file) The latter got written so that ex::lib::zip (zip files in @INC) could cope with files stored but not compressed in zip files. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: vtables and multimethod dispatch
David M. Lloyd wrote: > No, the point is that all this talk about type-space mm dispatch > depends on there *being* type space. Since there is currently > no inheritance to speak of then there really is no typespace so > all of this talk is moot, I agree; but you did express a concern earlier that there could be two different class hierarchies for parrot and perl; and I'm saying that it wouldn't be a problem. Even if/when there is a non-trivial PMC class tree, it won't be a problem. > ...unless Dan comes along and says that yes there will now be > real inheritance on the PMC level. As I (and I'm sure others) hope will be the case. -- JohnDouglasPorter __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Re: Streams vs. Descriptors
Nicholas Clark wrote:
> ... PerlIO::subfile (treats a section
> of a file as if it is a whole file - lets you read direct from a tar
> on an uncompressed file stored in a zip file)
Ah -- just like Virtual File Systems (VFS) from Tcl-land.
Good idea!
('COURSE it's a good idea!)
--
JohnDouglasPorter
__
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com
Quick Perl 6 regex question
I was reading through the Monastery, and I noticed a node (about the
line between what's considered Perl discussion and what's off-topic)
that had this regex in it:
m:iw/how [do[es]?|can] [I|one] @tasks in @non_perl_languages/
(Yes, people are already using Perl 6 regexes in text. :^) ) Reading
this, I noticed a potential problem in :w.
To put it simply, what do these expand to?
m:w/foo [~|bar]/
m:w/[~|bar] foo/
m:w/[~|bar] [^|baz]/
m:w/@foo @bar/
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
Re: Perl 6, The Good Parts Version
On Wed, Jul 03, 2002 at 10:52:58PM +0100, Tim Bunce wrote: > Don't forget Apocalypse 5. > > Personally I believe the elegant and thorough integration of regular > expressions and backtracking into the large-scale logic of an > application is one of the most radical things about Perl 6. How does one explain this to an audience that likely isn't convinced regexes are all that important in the first place? "Sure it's line noise, but it's new and improved line noise!" I may have to avoid the topic of regex improvements unless I can cover it in < 5 minutes. Maybe a quick poll of how many people are using one of the many Perl5-like regex libraries, if there's a high portion then talk about the new regex stuff. Grammars, OTOH, is something I think I'll mention. I also forgot hyperoperators. Also it's likely worth mentioning that perl's method call syntax will switch to the dot making it look more like other languages. Unicode from the ground up is probably also worth mentioning, though I'm not quite sure what forms this will take other than "Unicode will not be an awkward, bolt-on feature". I don't know how Java and Python handle Unicode. -- This sig file temporarily out of order.
Re: Streams vs. Descriptors
At 09:42 AM 7/16/2002 -0700, Damien Neil wrote: >On Mon, Jul 15, 2002 at 08:59:40PM -0400, Melvin Smith wrote: > > True async IO implementations allow other things besides just notifying > > the process when data is available. Things like predictive seeks, or > > bundling up multiple read/writes, etc. aren't doable with select/poll > loops. > > And the aioread/aiowrite/listio, etc. are a POSIX standard now, so they > > should be reasonably available on most UNIXen. > >I'm not familiar with "predictive seeks", and a quick google didn't >turn up anything relevant; can you give a quick explanation? Doing some research, it doesn't look like there is any such support for this type of thing with POSIX api. I was trying to stress that real async IO could do seeks/writes/reads in parallel to processing, and I thought you were confusing a callback/dispatch loop with this. Now it appears you weren't confusing anything. :) >Bundling reads and writes sounds like a job for a buffered I/O layer. You are probably right for most cases. I do know there are softwares that don't use a standard buffered layer, but still do large writes, either sequential or random. The former being multimedia apps, the latter being relational DB engines like Oracle. There is still advantage to providing a non-buffered, scatter/gather interface for less system call overhead, right? >Are the aio* calls available on Windows? On the Macintosh? (My OS X >system doesn't have a manpage for aioread, and man -k aio doesn't >turn up anything obvious.) How about PalmOS? While the POSIX standard >is a help, I think async I/O remains far less portable than the more >traditional alternatives. I doubt they are on Windows. On Mac, your guess is better than mine, since you actually run one. I can't speak for Palm, my only embedded experience is Win CE. I didn't make the decision that we should support the OS async facilities, Dan did, but I agree with him. IO is very commonly platform specific, no big deal there. >This doesn't allow an event to interrupt the current thread of >control, of course. The most common way of having multiple Which isn't acceptable. >concurrent threads is, however, exactly that--threads. Threads >can be used independently (the Java approach; all I/O is blocking) >or in conjunction with an event loop (the Macintosh OS X event loop >takes this approach). This is the most common, and robust way to do it in userland. Many OS vendors packages already implement async like this. Why can't we? No reason, except I would trust Sun's implementation more than mine if it were available, and would much rather design our code to use platform specific facilities if they _were_ available. >I really recommend taking a look at the Tcl event loop and I/O system, >if you haven't already. It's a joy to work with, and one of the best >features of that language. Maybe you can hit the high spots for me, I don't use Tcl. >I'm sure that there are things async I/O is very good at, but I'm >not certain it makes sense to design Parrot's I/O system around them. >Might it not make more sense for async I/O to be available via an >alternate API? Hmm. If we can reasonably expect threading to be available, I don't see why we can't design an abstraction layer for the async calls, and people can use the normal blocking/non-blocking calls if they choose, and even make use of callbacks, which we will have to implement in some sort of event loop/thread. Anyway, I've gotten over my head here. Originally I was quoting Dan's goals as for async. My personal experience is only in networking, and I've used two methods: 1) An event loop with select() and a dispatcher 2) A background thread 2 gives much better latency on incoming packets than 1 for a small number of connections; I know this for a fact, as I've implemented a multiplayer game engine with it. Now, if this applies to disk IO, databases, etc. I have no clue. Thanks for the very good comments, Damien, feel free to flesh out some initial design or maybe a list of pros/cons for the various methods, since you seem to have a good handle on things. -Melvin
RE: [PATCH] rx.dev
At 05:08 PM 7/15/2002 -0700, Stephen Rawls wrote: >Ok, I cleaned up the file a little bit, and added pod >declarations. Should be finalized or close to it at >least. If anyone likes it, I'll start working on >making a .dev file for some other files, and start >asking questions while I'm at it probably :) Applied, thanks much. I put it temporarily in the root dir, which I know is wrong. Where should .dev files go, anyway? -Melvin
RE: [PATCH] rx.dev
Melvin Smith wrote: > I put it temporarily in the root dir, which I know is wrong. > Where should .dev files go, anyway? Actually, I think that's right. ..dev files live alongside their .c/.h siblings, no? -- JohnDouglasPorter __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Re: [PATCH] rx.dev
Well, the .h files live elsewhere, but yeah, for now I think .dev files should live with the .c files. Unless someone has an alternative suggestion. I'll update "make check_source" and pdd07 to reflect this. --Josh At 18:14 on 07/16/2002 PDT, John Porter <[EMAIL PROTECTED]> wrote: > > Melvin Smith wrote: > > I put it temporarily in the root dir, which I know is wrong. > > Where should .dev files go, anyway? > > Actually, I think that's right. > ..dev files live alongside their .c/.h siblings, no? > > -- > JohnDouglasPorter > > > __ > Do You Yahoo!? > Yahoo! Autos - Get free new car price quotes > http://autos.yahoo.com
[perl #792] [PATCH] add some ops to Perl PMC's
Applied.
[perl #825] [PATCH] Fix underflow error in fact_x_i
Applied.
[perl #822] [PATCH] Fix segfault in intqueu
Applied, thanks!
[perl #821] [PATCH] Update hanoi.pasm to use new keyed ops
Applied, Thanks!
[perl #825] [PATCH] Fix underflow error in fact_x_i
Applied, thanks..
[perl #820] [PATCH] byteorder.c
Applied, thanks!
Re: Quick Perl 6 regex question
On Tue, 16 Jul 2002, Brent Dax wrote: > I was reading through the Monastery, and I noticed a node (about the > line between what's considered Perl discussion and what's off-topic) > that had this regex in it: > > m:iw/how [do[es]?|can] [I|one] @tasks in @non_perl_languages/ > > (Yes, people are already using Perl 6 regexes in text. :^) ) Reading > this, I noticed a potential problem in :w. > > To put it simply, what do these expand to? > > m:w/foo [~|bar]/ > m:w/[~|bar] foo/ > m:w/[~|bar] [^|baz]/ > m:w/@foo @bar/ A5 says: Another new modifier is :w, which causes an implicit match of whitespace wherever there's literal whitespace in a pattern. In other words, it replaces every sequence of actual whitespace in the pattern with a \s+ (between two identifiers) or a \s* (between anything else). So, since groups aren't identifiers, I imagine [the first] would expand to: m/ foo \s* [~ | bar] / But I could see reason for this: m/ foo [\s* ~ | \s+ bar] / But as your third and fourth case point out, this is not always easy to represent. Perhaps :w wouldn't transform the rexex, but keep "markers" on where there was whitespace in the regex. At each marker, If the last thing it matched was a \w, and it's currently trying to match a \w, match \s+ first, else match \s* first. This could have some problems that I'm not seeing... But I do think the idea would make sense. Luke
Re: Perl 6, The Good Parts Version
On Tue, Jul 16, 2002 at 05:42:18PM -0400, Michael G Schwern wrote: > I don't know how Java and Python handle Unicode. Java has always been 100% Unicode from the ground up; it's in the spec. The fundamental char type is a 16-bit value, you can use any "letterlike" characters in identifiers, there's an escape sequence to include untypable characters in strings, etc. I/O defaults to UTF-8 but you can arrange for other encodings. I don't know about Python. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754 -- You're never too old to become younger. -- Mae West
loop and the super comma
Long have I been a fan of giving pure Perl modules the power to change the rules and create a more built-in look, feel, and functionality. So, of course, I love %MY, I love real named parameters, I love the ability to create iterators that look just like native control structures. But while laying in bed (which I should be doing now) a thought occured to me. How would I create an itertor in pure Perl 6 which worked like a C style for, now loop? Pondering this, these vaguely related thoughts passed through my mind: 1. We now have the super comma,which can sperate arguements, so at least that looks right. But without changing the parsing rules, can I make the lack of a comma between the (...) and the block not an error? 2. This still won't work beacuse the three expressions will be evaluated before being passed to the iterator. I could get around this by having them be passed at strings and evaling them, but that defeats the idea of writing a control structure that's bulit in. What feature would Perl 6 have to have to make this possible? I remembered the ugly pass by name thread that I ignorantly started earlier, and realized that being able to hold the expression's evaluation until it's used makes it the perfect fit for this sort of thing. Can someone please show me I'm wrong and that this can be accomplished without pass by name? 3. Finally, if the above we're no longer issues,I realized that it would be easy to write an iterator that breaks our golden rule of blocks - lexical scope should not leak. I'm not yet adept at Perl 6 enough to write out an example of such an iterator, but it would be a simple matter of eva;uating the initial arg to loop, checking %MY to cee what lexicals were created, and then monkeying with the %MY of the closure passed to the iterator as a final argument. Is this an issue, or can does it fall under the "a use declaration makes a prgram a Perl 'dialect' and is free to break the rules"? -Erik Is your boss reading your email? Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com
PARROT QUESTION (/nitpick)
OK, I've been playing with Parrot and reading the mailing list for a while. (My first post; whee!) 1) What's with the big mess in Parrot_readbc? Why not just start a pbc file with something like: #comment bytecode[7345]:\n <7345 bytes of bytecode> This way you wouldn't have to worry about where the file was coming from or whether or not you could stat() it (and I like shebang lines). Forgive me if this is a stupid question. __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
RE: [PATCH] rx.dev
At 06:14 PM 7/16/2002 -0700, John Porter wrote: >Melvin Smith wrote: > > I put it temporarily in the root dir, which I know is wrong. > > Where should .dev files go, anyway? > >Actually, I think that's right. >..dev files live alongside their .c/.h siblings, no? Hmm, looking at the source directory, I'm starting to think maybe that isn't so good, it is pretty busy already. We have one vote for a /dev directory. -Melvin
Was: Re: Parrot contribution Is: Archiving IRC
Btw, to the best of the ability of my backscroll, I'm trying to archive useful conversations on http://www.slowass.net/wiki/?ParrotVirtualMachine. If I miss something, feel free to add it. -scott On Sun, 14 Jul 2002, Dan Sugalski wrote: > At 10:09 AM +0100 7/14/02, Simon Wistow wrote: > >On Sat, Jul 13, 2002 at 05:00:42PM -0400, Jim Cromie said: > >> can we could invent a super-lightweight markup language > >> that #parrot-eers would type into the stream to put meta-info into it ? > > > >Might it be worth using something like > > > >http://usefulinc.com/chump/ > > > >(as seen in use at http://pants.heddley.com/index.html) > >? > > > >It's written in Python but there's a Perl replacement (to stem the PR > >nightmare), which is 99% complete, lurking around which was written by > >#perl denizen blech. > > Could we get something like this lurking on #parrot? I don't care if > it's in perl or python (or ruby, or scheme, or...) just as long as > its hanging about and useful. > > At some point I suppose I'll have to try my hand at an IRC bot of some sort. > -- > Dan > > --"it's like this"--- > Dan Sugalski even samurai > [EMAIL PROTECTED] have teddy bears and even >teddy bears get drunk >
