Daniel Chetlin wrote:
>
> On Wed, Sep 20, 2000 at 07:20:44PM -0700, Steve Fink wrote:
> > % perl -le '$x = 3; eval "\$x++"'
> > (no warning issued)
>
> [~] $ perl -wle'$x = 3; eval "\$x++"'
> Name "main::x" used only once: possible typo at -e line 1.
Doh! Thanks.
Eric Roode wrote:
>
> Steve Fink, via the Perl6 Librarian, wrote:
> >=head2 EXAMPLE
> >
> >1 my ($x, $y, $z, $r);
> >2 $z = 1;
> >3 f(\$r);
> >4 my $logfile = "/tmp/log";
> >5 $x = 1 if cond();
> >6 prin
Michael Fowler wrote:
>
> Ok, at this point I'm trying to clear up misunderstandings. I believe you
> know where I stand with relation to your RFC.
Thanks, you caught several of my mistakes.
>
> On Wed, Sep 20, 2000 at 06:41:52PM -0700, Steve Fink wrote:
>
Tom Christiansen wrote:
>
> As we sneak under the wire here, I'm hoping someone
> has posted an RFC that alters the meaning of my/local.
> It's very hard to explain as is. my is fine, but local
> should be changed to something like "temporary" (yes, that
> is supposed to be annoying to type) or
Larry Wall spoke:
>
> Here are some from the "bad" directory. (reads from one) ... and they
> want us to solve the halting problem. No.
That was RFC12, mine. I can't figure out why so many people
interpret that RFC as requiring a solution to the halting problem. If
anything, it explicitly rec
(moved off of -meta)
"David L. Nicol" wrote:
>
> Steve Fink wrote (and I edited slightly):
>
> > I can't figure out why so many people misinterpret my RFC12
> > as requiring a solution to the halting problem.
>
> a large class of incompletely exp
Oops, replied to the wrong message (that's why there was a "(COPY)"
there).
"David L. Nicol" wrote:
>
> Steve Fink wrote:
>
> > It's standard semantic analysis. Both your taintedness analysis and my
> > reachability analyses can be fully d
Larry Wall wrote:
>
> David L. Nicol writes:
> : Steve Fink wrote (and I edited slightly):
> :
> : > I can't figure out why so many people misinterpret my RFC12
> : > as requiring a solution to the halting problem.
> :
> : a large class of incompletely expr
Most of the time, perl's performance is a total non-issue for me. When
it is, I'm generally doing the same things as Dan (ie, things resembling
dd if=/dev/hda | perl -e ...). I posted some vague benchmarky ideas to
perl6-meta at one point. Here they are again:
-
You did ask at one point for
Hey, it's finally a use for the 'use less space/use less time' pragma!
'use less space' means share the bytecode and either do computed jumps
or unshared lookup tables; 'use less time' means fixup unshared bytecode
at load time (or page fault time, or whatever). :-)
Simon Cozens wrote:
>
> On Wed, Nov 01, 2000 at 05:35:17PM -0800, Steve Fink wrote:
> > Algorithm Inline? OptimizationTime (sec)
> > GOTO- -O3 1.35
> > FUNCALL_HYBRID yes
Jarkko Hietaniemi wrote:
>
> Some sort of SGI megaserver, dunno MHz, but load is high (more than
> five times the number of CPUs...), so the following numbers are a tad slow,
> but I guess relatively right:
>
> -O3 none
>
> switch 7.027.70
> orig16.
Ken Fox wrote:
>
> I was noodling around with a couple different VM implementations
> and thought I would ask other people if they were doing the same.
> It would be nice to divide and conquer the exploration of different
> implementations.
>
> I looked into 3 different dispatching techniques. H
We threw the floodgates open and a lot of stuff washed in. The overall
odor and consistency of the stuff wasn't that great, and the number of
real gems mixed in was kind of low. 'Nuff said. What's the point in a
purely retrospective analysis? We do need to take the lessons learned,
but only in ord
Dan Sugalski wrote:
>
> At 12:11 PM 11/22/00 -0800, Steve Fink wrote:
> >Dan Sugalski wrote:
> > >
> > > It's also possible we'll do the parser mainly in C with perl hooks, but
> > > that's not the direction I've been poin
Bart Lateur wrote:
>
> On Tue, 21 Nov 2000 17:24:49 +, Simon Cozens wrote:
>
> >I really *would* recommend Aho, Sethi, Ullman, "Compilers: Principles,
> >Techniques and Tools".
>
> AKA "The Dragon Book". You're not the only one to mention this book on
> this list.
>
> IMO, this book is rea
Dan Sugalski wrote:
>
> You're not wrong, but I don't think this is a huge problem. Lots of systems
> do it like this at the moment--GCC comes to mind as a first one, but there
> are lots of others. Granted it does mean that we'll need to ship a
> bytecode-compiled version of the parser as part o
Dan Sugalski wrote:
>
>int perl6_parse(PerlInterp *interp,
>void *source,
>int flags,
>void *extra_pointer);
Given that other things may want to be streamable in similar fashion (eg
the regular expression engine), why not have a Per
Dan Sugalski wrote:
>
> Sure. Suggestions?
int perl6_parse(PerlInterp* interp, PerlIO* input);
PerlIO* make_memory_stream(char* buf, ssize_t length); // length=-1 for
nul-terminated
int close_stream(PerlIO* stream);
then if you read further, you'll eventually see:
PerlIO* make_callback_stream(
Tom Hughes wrote:
>
> In message <[EMAIL PROTECTED]>
> Simon Cozens <[EMAIL PROTECTED]> wrote:
>
> > In a sense, though, you're right; this is a general problem. I'm currently
> > trying to work out a design for a tokeniser, and it seems to me that
> > there's going to be a lot of comm
Chaim Frenkel wrote:
>
> >>>>> "SF" == Steve Fink <[EMAIL PROTECTED]> writes:
>
> SF> Handling the parser's state can be done in a backtracking DFA-like or a
> SF> direct NFA-like way. The NFA way is to keep track of all possible parse
&
Dan Sugalski wrote:
>
> At 04:16 PM 11/28/00 -0800, Steve Fink wrote:
> >Perl5 is parseable with a single token of lookahead and lots of
> >parser/lexer communication. Sort of. It would be nice to prevent it from
> >getting any worse.
>
> I'm really t
Bryan C. Warnock wrote:
> On Mon, 04 Dec 2000, Nathan Torkington wrote:
>
>> Nice. An apprentice is an administrative assistant with a career
>> path. If people are happy to do this, we'd be happy to use them. The
>> chairs proved weak at reporting on their list's activities (I know I
>> was)
David Grove wrote:
> Also, as far as documentation goes, I think it _should_ be written by
> apprentices, so that non-masters can understand it too. That's always been
> a huge criticism of the perldocs. That's not grunt work. That's proper
> allocation of duties to the best suited personnel for
I'm wondering if we should explicitly break out the languages that
comprise perl today. That'd be at least toplevel perl, regular
expressions, and pack. Maybe tr// and the second half of s/// are
sufficiently different too. If nothing else, it would highlight the
problems in switching languages mi
That is way cool.
Though I'm not sure that all of the constructs of another language are
going to be that easy to map into perl opcodes. Arithmetic, sure. But
perl opcodes aren't exactly a universal intermediate language.
Just in looking at your example, it seems like some complex replacements
w
Nathan Torkington wrote:
>
> Here's a quote from Jim McCarthy's "Dynamics of Software Development"
> that seems relevant given the recent fracas on perl6-language-regexp:
>
> Someone once asked me, "What's the hardest thing about software
> development?"
>
> I didn't hesitate. "Getting people
[EMAIL PROTECTED] wrote:
> Here's me thinking out loud. I'm thinking about how to avoid alot of
> explicit type casting without entering a maze of twisty typecasing
> rules, all different.
>
>
> Imagine we have a typing system where types are allowed to
> automatically cast AS LONG AS NO INFOR
Michael G Schwern wrote:
> On Mon, Jul 09, 2001 at 08:54:49PM -0700, Steve Fink wrote:
>
>>my Num $x = 3.0;
>>$x++;
>>my Int $y = $x;
>>
>>Could be compile-time, if you do constant folding first.
>>
>
> Alot of how much checking we can do
[EMAIL PROTECTED] wrote:
> On Sat, Jul 21, 2001 at 02:47:43PM -0700, Dave Storrs wrote:
>
>>I discovered today that I had forgotten to put 'use strict' at the top of
>>one of my modules...it was in the script that _used_ the module, but not
>>in the module itself. Putting it in instantly caught
On my wishlist is forbidding the use of # just about anywhere but as a
comment starter and in strings or regular expressions. Not a big deal,
but it would make it easier to write 90% correct perl syntax parsers.
It's a pain dealing with q#not a comment# and m#still not# and
s(even)#this#. Espe
On Sun, May 26, 2002 at 01:52:58AM -0400, Jeff wrote:
> 3) KEYED ACCESS
>
> Yes, you heard me. The new assembler accepts the following test program
> (which is what I used to test the feature, so I know it works):
>
> set_keyed P0[S0],1 # HERE IT IS
> set_keyed P0[S1],2
> get_keyed I0,P0[S0]
> g
On Tue, May 21, 2002 at 03:57:33PM -0500, David M. Lloyd wrote:
> Are the REGEX structure and the match vtable methods officially dead? The
> POD inside of rx.ops does not mention them at all, and right now REGEX is
> typedef'd to void and no-one uses the 'match' method for anything.
>
> Since r
On Mon, May 20, 2002 at 10:53:46PM +0200, Peter Gibbs wrote:
> Steve Fink wrote:
> > Is there some way to make the default be that things will not get
> > moved around, and allow routines to volunteer to have their guts
> > scrambled if they know how to handle it?
>
&g
Wow, this thread is looking bad -- I'm replying to my own reply to my
own message. Sorry; I accidentally hit reply instead of reply to list,
and from the resulting off-list discussion with Sean O'Rourke I have
updated the patch. I won't resend it, because it may require more
changes and it's gotte
On Thu, Aug 08, 2002 at 03:28:18PM -0400, Dan Sugalski wrote:
> At 11:00 AM -0700 8/8/02, Steve Fink wrote:
> >Oh, yeah. The perl6 summary reminded me: I forgot to mention that this
> >would also make $a[-6] (or @a[-6] if you're writing perl6) on a
> >4-element array thr
On Fri, Aug 09, 2002 at 04:10:50PM -0400, Dan Sugalski wrote:
> Okay, one of the first things we need to do to support multiple
> segment bytecode is to be able to swap in constant tables. (Since we
> access constants by offset from the table, and we don't want to go
> fix up the offsets every
Wow. Since you went to the trouble of writing all this up, it really
ought to go in a FAQ somewhere.
On Thu, Aug 08, 2002 at 12:05:00AM -0400, Mark J. Reed wrote:
> Finite state machines can match regular expressions whose only operations
> are closure (*), alternation (|), and grouping. Some of
On Fri, Aug 09, 2002 at 09:50:00PM -0400, Mark J. Reed wrote:
> On Fri, Aug 09, 2002 at 05:23:58PM -0700, Steve Fink wrote:
> > On Thu, Aug 08, 2002 at 12:05:00AM -0400, Mark J. Reed wrote:
> > > Finite state machines can match regular expressions whose only operations
On Mon, Aug 12, 2002 at 03:56:27AM -0400, Mike Lambert wrote:
> - hashes (these were recently rewritten to use indices, a step forward,
> but they aren't 100% clean yet)
I know of at least one remaining problem with these, but...
> Anyone more well-versed in these departments than I care to take
On Mon, Aug 12, 2002 at 12:34:28PM -0700, Sean O'Rourke wrote:
> On Mon, 12 Aug 2002, Steve Fink wrote:
> > farther yet. Oh, and I do have your recent patch to set
> > interpreter->lo_var_ptr early.
>
> How early is "early"? It looks like setting lo_var_pt
On Mon, Aug 12, 2002 at 04:04:40PM -0400, Jason Gloudon wrote:
> On Mon, Aug 12, 2002 at 03:56:27AM -0400, Mike Lambert wrote:
>
> Here is a workaround for one hash related GC bug.
Nice catch. That, in combination with the patch I just posted, fixes
all but 4 of the failures for me.
On Mon, Aug 12, 2002 at 04:23:14PM -0400, Mike Lambert wrote:
> Weird. I had to move the lo_var_ptr initialization code to runcode instead
> of runops, in order to avoid collecting the ARGV pmc. The new code looks
> like:
>
> void *dummy_ptr;
> PMC *userargv;
You sure? That's what I thought at f
In tracing down the next crash bug using GC_DEBUG, I found that the
following code in new_stack is unsafe:
stack->buffer = new_buffer_header(interpreter);
Parrot_allocate(interpreter, stack->buffer,
sizeof(Stack_Entry_t) * STACK_CHUNK_DEPTH);
A GC can be triggered by
This is a patch that clears up all of the GC_DEBUG-revealed bugs, at
least on my machine. As I enumerated in my previous email, there are a
lot of different ways to fix these sorts of problems, and this just
kinda picks one for each problem encountered. This patch includes the
stuff done by Jason
On Mon, Aug 12, 2002 at 12:37:09AM -0700, Sean O'Rourke wrote:
> What Dan says. If you're interested, there are at least three options:
>
> - a fairly well-developed compiler for perl 5 regexes (languages/regex).
>
> - a less well-developed compiler built into the prototype Perl 6 compiler
>
On Wed, Aug 14, 2002 at 03:16:20AM -0400, Mike Lambert wrote:
> > If the rx info object is going away, then obviously those parts of the
> > patch need not be applied. But in the meantime, it's nice to have a
> > Parrot that doesn't crash.
>
> I agree. My disclaimer about the regex code in my ori
On Sun, Aug 18, 2002 at 02:35:09PM +, Jarkko Hietaniemi wrote:
>
> Tru64 finds the following objectionable spots from a fresh CVS checkout:
Does this patch fix it? (Though even if it does, I wouldn't be at all
surprised if some other compiler choked on it.)
Index: rx.ops
===
It also reverts my bugfix for missing the first PMC allocated. I have
re-applied the fix.
On Mon, Aug 19, 2002 at 11:31:23AM +, Leopold Toetsch wrote:
>
> recent changes in hash.c seems to hang[1] hash_clone.
> This patch works, but I don't know, if it is the correct way to solve
> the problem.
>
> [1]
> $perl6 -Rt -vwk t/compiler/a_2.p6
> ..
> PC=726; OP=183 (clone_p_p); ..
On Tue, Aug 20, 2002 at 07:39:28PM +0200, Leopold Toetsch wrote:
>
> Dunno, how expensive getBucket is, but wouldn't it be faster, to check,
> if a GC run was actually done, and only then recalculate the pointers?
> This would apply too similar operations (clone ...) too.
Probably not worth it.
On Tue, Aug 20, 2002 at 09:12:36PM +0200, Leopold Toetsch wrote:
> Leopold Toetsch (via RT) wrote:
>
> >attached patch uses now a similar startup code for native compiled
> >programs like test_main.c.
>
> Rediffed and additional patch to compile natively .pasm containing keyed
> access (pack_k
Yay! The COW has landed! All praise the newly bovine Parrot! (Now
THAT's an odd image... gimp, anyone?)
Favorite quote from the patch:
+ /* Buffer's memory data is in this header's header pool's memory pool */
Many thanks to Peter and Mike for implementing this and pushing it all
the way throug
On Wed, Aug 21, 2002 at 02:10:22PM +0200, Peter Gibbs wrote:
> Mike Lambert wrote:
> > If you don't mind, please feel free to continue your work on parrot-grey.
> The problem arises with trying to do new experimental development,
> which still keeping sufficiently in sync with cvs parrot that I ca
On Wed, Aug 21, 2002 at 10:05:57AM -0400, Melvin Smith wrote:
>
> Sean, I'm replying publicly because I'd like to hear other opinions than
> mine, yours, Angel's and Leopold's.
Can I respectfully request that you guys make a lot more of your
discussions public? languages/imcc and languages/perl6
On Wed, Aug 21, 2002 at 04:17:30AM -0400, Mike Lambert wrote:
> Just to complete this thread, I have committed the current version of my
> COW code, as I promised earlier this week.
Did you try running tests with GC_DEBUG on? I get numerous failures.
Here's a patch with a couple of fixes (not all
I would like to take a shot at making perl6 front- and backend
adapters for languages/regex, but so far I have seen all the tests in
languages/perl6 pass exactly once (and I updated again immediately
after, and a bunch of them broke again.) So I'm a little nervous about
digging into it just yet.
On Tue, Aug 27, 2002 at 01:23:50PM -0700, Sean O'Rourke wrote:
> On Tue, 27 Aug 2002, Mike Lambert wrote:
> > Is there still a need for determinstic destruction, even in light of the
> > alternative approaches mentioned above?
>
> Yes, if the destruction of the resource is itself important to the
On Tue, Aug 27, 2002 at 01:53:06PM -0700, Sean O'Rourke wrote:
> On Tue, 27 Aug 2002, Leopold Toetsch wrote:
> > Steve Fink wrote:
> > On a recent tree try this:
> >
> > $ perl6 --force --test# force rebuid grammar, run all tests
>
> s/force/force-gramm
On Tue, Aug 27, 2002 at 01:38:26PM -0700, Sean O'Rourke wrote:
> On Tue, 27 Aug 2002, Steve Fink wrote:
> > I would like to take a shot at making perl6 front- and backend
> > adapters for languages/regex, but so far I have seen all the tests in
> > languages/perl6 pass e
On Tue, Aug 27, 2002 at 03:42:18PM -0700, Sean O'Rourke wrote:
> On Tue, 27 Aug 2002, Steve Fink wrote:
> > Backend ops:
> > - Brent's original rx ops
> > - The rx ops with Angel's modifications
> > - My abandoned implicitly backtracking re ops
>
On Wed, Aug 28, 2002 at 12:55:44PM -0400, Deven T. Corzine wrote:
> On Wed, 28 Aug 2002, Dan Sugalski wrote:
> > At 10:57 AM -0400 8/28/02, Deven T. Corzine wrote:
>
> On the other hand, :, ::, ::: and don't necessarily need to be a
> problem if they can be treated as hints that can be ignored.
On Wed, Aug 28, 2002 at 01:18:19PM -0400, Deven T. Corzine wrote:
> Re: [perl6-language] Does ::: constrain the pattern engine implementation?
>
> On Wed, 28 Aug 2002, Dan Sugalski wrote:
>
> > A medium-term goal for the regex engine is to note where a DFA would give
> > correct behaviour and u
On Thu, Aug 29, 2002 at 01:05:33PM -0700, Robert Spier wrote:
> Bryan C. Warnock writes:
> >How does one patch a file to delete?
> >
> >docs/a5_draft.html can go away now, thank you for playing.
>
> rm
> cvs delete
> cvs commit
Not if you don't have commit access! :-)
You can diff against /de
On Thu, Aug 29, 2002 at 04:31:14PM -0400, Dan Sugalski wrote:
> I ran some quick time tests on the GC, and hashes are relatively
> expensive to GC, relative to other things. (They're an order of
> magnitude slower than perlstrings, and two orders of magitude slower
> than perlints) They're slow
On Thu, Aug 29, 2002 at 04:48:20PM -0400, Andy Dougherty wrote:
> On Thu, 29 Aug 2002, Steve Fink wrote:
>
> > - Adds %option nounput to imcc.l. This avoids a warning when
> >compiling the output file. This one is correct, at least.
>
> Hmm. Sun's lex(1) does
On Thu, Aug 29, 2002 at 11:56:42PM +0200, Leopold Toetsch wrote:
> Steve Fink (via RT) wrote:
>
> >This patch trims off the period at the end of executable filenames for
> >C-based tests on unix.
>
> Nice, but I'm a little bit Warnocked.
>
> 1) I did pos
On Fri, Aug 30, 2002 at 03:49:07PM -0400, Andy Dougherty wrote:
> By default, traditional yacc puts its output files in y.tab.[ch]. Thus
> my imcc/Makefile currently has
>
> $(YACC) -d -v imcc.y
> mv y.tab.c imcparser.c
> mv y.tab.h imcparser.h
>
> That's no problem, and works
On Mon, Sep 02, 2002 at 08:25:30AM -0700, Sean O'Rourke wrote:
> On Mon, 2 Sep 2002, Dan Sugalski wrote:
>
> > Here's a call for potential goals for the 0.0.9 release of parrot. My list:
> >
> > *) Exceptions
> > *) initial PMC freeze/thaw API
> > *) Sub indicators in bytecode
> > *) On-the-fly b
On Sun, Sep 01, 2002 at 02:32:26AM -0400, Mike Lambert wrote:
> Mr. Nobody wrote:
>
> > Date: Fri, 30 Aug 2002 18:13:27 -0700 (PDT)
> > From: Mr. Nobody <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: [PATCH] in makefile, move libparrot.a from "test" to "all"
> >
> > libparrot.a is not
On Sun, Sep 01, 2002 at 02:30:35AM -0400, Mike Lambert wrote:
> > Small cleanups, but also a piece of my attempted fixes to the
> > BUFFER_external_FLAG. (The CVS version currently doesn't work anyway,
> > so don't worry about only getting parts of my fixes in; nothing
> > depends on it.)
>
> I'm
On Mon, Sep 02, 2002 at 01:33:45PM +0200, Aldo Calpini wrote:
> INTVAL iterator_sizeof()
> void iterator_reset()
> void iterator_set(void *data)
> void iterator_get(void *data)
> PMC* iterator_get_current()
> void iterator_next();
What is the advantage of having the aggregat
I think those are necessary operations -- if you're going to use the
intstack in the first place. And personally, I don't intend to. I
think it's much easier to deal with a separate data structure than
something tied into the interpreter struct. A free-floating intstack,
if you will. But this has
On Tue, Sep 03, 2002 at 04:59:44PM +, Andy Dougherty wrote:
>
> The following patch causes Configure to generate a 'myconfig' file that
> summarizes the current parrot configuration (much like perl5's 'myconfig'
> or perl -V output).
>
> This patch also includes makefile targets to generate
On Tue, Sep 03, 2002 at 02:55:05PM +, Andy Dougherty wrote:
> # New Ticket Created by Andy Dougherty
> # Please include the string: [perl #16965]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=16965 >
>
>
> This pa
On Wed, Sep 04, 2002 at 06:00:17PM +, Andy Dougherty wrote:
>
> Configure.pl's 'copy_if_diff()' function was actually calling rename()
> and moving the file. The net result was that if you tried to re-run
> Configure.pl, it failed at the MANIFEST check point because
> the config/gen/platfor
I'm actually somewhat surprised at how little Parrot is tied to Perl.
Most of the active developers seem to be working on parrot for its
merits as a VM. Perl6, for me at least, mostly provides evidence that
this isn't just an exercise in intellectual masturbation, as Simon
would say -- there will
Oh, right. The patch. Here it is.
Index: .cvsignore
===
RCS file: /cvs/public/parrot/.cvsignore,v
retrieving revision 1.19
diff -p -u -a -r1.19 .cvsignore
--- .cvsignore 14 Jul 2002 10:25:55 - 1.19
+++ .cvsignore 4 Sep 20
On Wed, Sep 04, 2002 at 08:07:21PM +0200, Peter Gibbs wrote:
> For anybody who may be interested, the latest news from the
> pirate cave follows.
>
> Recent changes:
> * New aligned memory page allocator
> * Above allocator used for PMC/buffer header arenas and memory
> pool pages; this has al
On Wed, Sep 04, 2002 at 11:11:45PM -0400, John Porter wrote:
> Thanks, Steve. I agree 100% with everything you said!
>
> Except:
>
> > ... the best way to that
> > goal is to use Perl6 as the driver, at least until something else
> > shows up, because that's the only way to derive realistic req
On Wed, Sep 04, 2002 at 08:48:29PM -0700, Sean O'Rourke wrote:
> On Wed, 4 Sep 2002, Steve Fink wrote:
> > I tend to create new PMC classes frequently, and they're a pain to
> > maintain without committing, because you have to touch lots of files
> > to add a PM
On Thu, Sep 05, 2002 at 10:33:50AM -0700, Sean O'Rourke wrote:
> Is there a reason you went for a deque instead of a stack? I can
> definitely see the need for a _PMC_ deque (unshift on the current
> PerlArray implementation blows), and for an integer _stack_ (regexes), but
> not for an int-only
I have applied at least one other not on your list (#17008). Should I
be marking things as applied? I didn't think I had the permissions to
do that, so I've just been trying to make sure I post a "Thanks,
applied" so it gets into RT's reply set. Can I do more than that?
On Fri, Sep 06, 2002 at 12:47:11AM +0200, Leopold Toetsch wrote:
> Steve Fink (via RT) wrote:
>
> ># New Ticket Created by Steve Fink
> ># Please include the string: [perl #17039]
> ># in the subject line of all future correspondence about this issue.
> >#
I guess I'll brave the chaos...
Ok, I have undone the accidental reversion.
Leo, can you send me the patch and ChangeLog? I'd rather have Melvin
commit it, but I was just trying to get something to work with imcc
and I won't bother if you've already fixed it.
Also:
On Sat, Sep 07, 2002 at 12:2
On Fri, Sep 06, 2002 at 06:01:20PM -0700, Sean O'Rourke wrote:
> On Sat, 7 Sep 2002, Steve Fink wrote:
>
> > - Add a -e (or --eval) flag to perl6.
>
> For those "quick" one-liners?
For running things under the debugger. It's easier to mess with
@DB::ARGS t
On Fri, Sep 06, 2002 at 09:32:27PM -0400, Andy Dougherty wrote:
> On Thu, 5 Sep 2002, Andy Dougherty wrote:
>
> > Ok, with the alignment hack now in (see resources.c) and lots of various
> > and sundry portability fixes, it looks like we're on our way to turning
> > the tinderbox a lovely shade o
On Fri, Sep 06, 2002 at 08:09:21PM -0700, Sean O'Rourke wrote:
> On Fri, 6 Sep 2002, Steve Fink wrote:
> > > > - Make sure P6C::IMCC::code() adds a newline after every line
> > > > (I was getting two consecutive lines of code smashed together)
> > >
On Sat, Sep 07, 2002 at 09:03:43AM -0700, Mr. Nobody wrote:
> While Apocolypse 5 raises some good points about problems with the old regex
> syntax, its new syntax is actually worse than in perl 5. Most regexes, such
> as this one to match a C float
Wrong list. You want the second door down the h
On Thu, Sep 05, 2002 at 07:46:38PM -0400, John Porter wrote:
> Steve Fink wrote:
> > Here is the new PMC I keep babbling about. Before I commit it, any
> > comments? Like, does anybody think this should be named differently?
> > It's really a dequeue (double-ended queue)
On Sun, Sep 08, 2002 at 11:50:10AM +0200, Peter Gibbs wrote:
> Jerome Quelinm wrote:
> > > In fact, I tried to change S0, and whatever S0 value is (I tried with
> > > several values: "<", ">", "A", "0", " "), I always get a 60 as its
> ordinal
> > > value...
> >
> > I forgot to tell you: it doesn'
On Sun, Sep 08, 2002 at 10:35:16AM +, Peter Gibbs wrote:
>
> Attached patch fixes a problem with ord reported by Jerome Quelin.
> It also includes a test case in string.t.
Oops, I thought this patch was for something else. Oh well, I've
applied the fix already, with an equivalent test case, s
On Sat, Sep 07, 2002 at 09:17:38AM +, Peter Gibbs wrote:
>
> Mike's changes to integrate the external and selfpoolptr flags
> have resulted in the on_free_list flag remaining set when a
> buffer header is reallocated.
>
> This breaks life, so I have had to fix it to be able to compare
> tim
On Mon, Sep 09, 2002 at 11:42:23AM -0400, Andy Dougherty wrote:
> I wrote,
>
> > The t/src/intlist test still fails for me -- I just got
> > ...
>
> and here's the simple fix:
Doh! Thanks, sheepishly applied. I want a flag
-fwhen_behavior_is_undefined_do_the_worst_possible_thing.
On Mon, Sep 09, 2002 at 01:28:37PM +, Andy Dougherty wrote:
>
> Under traditional Unix loaders (ld), the order in which items are
> specified in the command line matters. Without this patch, -lm appears
> before libparrot.a, so at the time libm is encountered, no symbols are
> needed and not
On Tue, Sep 10, 2002 at 07:53:10PM +0100, Nicholas Clark wrote:
> On Tue, Sep 10, 2002 at 12:08:31PM -0400, Andy Dougherty wrote:
> > This won't necessarily work if sizeof(INTVAL) != sizeof(INT). (And since
> > the prototypes are hidden in the C file, not in a shared header file, the
> > compiler
On Mon, Sep 16, 2002 at 10:32:17AM +0300, Markus Laire wrote:
> On 15 Sep 2002 at 22:41, Steve Fink wrote:
>
> Your code seems to backtrack to the beginning at every failure. First
> code only backtracks one char at time.
> > Huh? What implementation is that? I think my na
On Wed, Sep 18, 2002 at 05:01:35PM +0200, Damian Conway wrote:
> Steve Fink wrote:
>
> >What possible outputs are legal for this:
> >
> > "aaa" =~ /( a { print 1 } | a { print 2 })* { print "\n" } x/
>
> Unless Larry specifies a required seman
On Sun, Sep 22, 2002 at 01:39:29PM -0500, Me wrote:
> So, how about something like:
>
> : # lock in current atom, ie as now
> :] # lock in surrounding group, currently ::
> :> # lock in surrounding rule, currently :::
> :/ # lock in top level r
On Mon, Sep 23, 2002 at 07:41:09PM +, Leopold Toetsch wrote:
> # New Ticket Created by Leopold Toetsch
> # Please include the string: [perl #17537]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=17537 >
>
>
> Attac
1 - 100 of 614 matches
Mail list logo
