On Thu, 31 Jan 2002, Bryan C. Warnock wrote:
> print "There's a letter in here!\n" if (substr($pi, 0, 200) =~ /[a-z]/);
*shrug* I actually did think of that when I first proposed this;
doesn't substr make a fresh copy of the string? (I honestly don't know.)
What happens if you take a s
On Thu, 31 Jan 2002, Dan Sugalski wrote:
> There is an issue of time--what do we do, for example, in the case:
>
> my $pi = Pi::Generate;
> if ($pi =~ /[a-z]) {
> print "There's a letter in here!\n";
> }
>
> if Pi::Generate returns a generator object that will calculate pi for
On Sun, 7 Oct 2001, Dan Sugalski wrote:
> I ended up pitching WinCVS and went with the command-line version. Works
> well enough, though not all that spiffy.
Just a tip:
One of my coworkers had this problem recently and, when he finally gave up
on WinCVS, he was unable to make the command li
Any interest in using something less painful than Make for this? I was
thinking of Cons, myself...built in Perl 5 (which we are already requiring
you to have), and much more friendly than Make.
Of course, Make has the advantage of being the standard. I won't be at
all upset if people don't like
...on the feature freeze?
I.e., what is fair game to be worked on and what is a "hold off for now?"
Dave
Well, I'm in the process of fiddling with this stuff anyway...what do you
want me to make it do?
Dave
On Thu, 20 Sep 2001, Simon Cozens wrote:
> On Wed, Sep 19, 2001 at 10:32:18PM -0700, Dave Storrs wrote:
> > Ok, that was pretty much what I thought. But then what is the '
Ok, that was pretty much what I thought. But then what is the 'end'
opcode for? It does a 'RETURN 0', which would increment the PC by 0
opcodes...which either counts as an infinite loop or a no-op, and we've
already got a no-op op.
Dave
On Thu, 20 Sep 2001, Gibbs Tanton - tgibbs wrote:
> RE
I'm working on documenting the opcodes, and I want to make sure that I
understand the 'RETURN' code properly. I've poked around a little bit to
see if I coudl figure it out, but I don't want to divert too much. Would
someone please explain to me what each of the following does?
RETURN 4
RETURN
On Wed, 19 Sep 2001, Dan Sugalski wrote:
> Basically we're getting a free load on most architectures, so we ought to
> use it where we can. (And it doesn't hurt us on those architectures where
> we don't have it)
1) Does that make us freeloaders?
2) I guess the architecture designers are
There was a thread on this recently, but I'm not sure what was
resolved. Do we have a standard naming convention for opcodes?
Personally, I'd like to see that we stick with (what I thought was) the
original plan: a nice, simple ruleset that produces long but predictable
names.
- the opc
In strings.pod, the following string functions are documented and
(most|all) are already implemented:
DOCUMENTED:
chopn
concat
length
substr
string_nprintf
However, Perl5 also includes the following functions that operate on
or otherwise relate to strings:
(As previously remarked, I'm trying to catch up from a few days offline,
so excuse me if this is OOD.)
On Tue, 11 Sep 2001, Ken Fox wrote:
> The interpreter knows the internals of the stack structure and is
> responsible for managing it. To change the stack implementation, we'll
> have to caref
I've been offline for a few days and haven't caught up on email yet
(nor, most likely, will I ever), so I hope no one else has already
done this, but
Attached is a file, msv.tar.gz which contains a simple script and .pm
file (*) for editing the string vtable. It asks you for a bunch of
typed
putting
things in just because they are "trivial to code" when we don't have a use
for them.
In general, I would like to see the policy be "unless there is a
clear and demonstrated need, we don't do it." Let's just make the engine
easy enough to change that, as we discover things we didn't know we
needed, we can go back and add them in later.
Dave Storrs
=head1 TITLE
API for the Perl 6 debugger.
=head1 VERSION
1.1
=head2 CURRENT
Maintainer: David Storrs ([EMAIL PROTECTED])
Class: Internals
PDD Number: ?
Version: 1
Status: Developing
Last Modified: August 18, 2001
PDD Format: 1
Language: English
=head2
=head1 TITLE
API for the Perl 6 debugger.
=head1 VERSION
1
=head2 CURRENT
Maintainer: David Storrs ([EMAIL PROTECTED])
Class: Internals
PDD Number: ?
Version: 1
Status: Developing
Last Modified: August 18, 2001
PDD Format: 1
Language: English
=head2 HI
On Tue, 5 Jun 2001, Dave Mitchell wrote:
> dispatch loop. I'd much rather have a 'regex start' opcode which
> calls a separate dispath loop function, and which then interprets any
> further ops in the bytestream as regex ops. That way we double the number
> of 8-bit ops, and can have all the re
On Tue, 5 Jun 2001, Hugo wrote:
> I'd also like to see a specification for indentation when breaking long
> lines.
Fwiw, the style that I prefer is:
someFunc( really_long_param_1,
(long_parm2 || parm3),
really_long_other_param
On Wed, 9 May 2001, Larry Wall wrote:
> Dave Mitchell writes:
> : My thinking behind "if fails on one, avoid on all" was that if it failed
> : on at least one, then it may well fail on others that you dont have access
> : to - either now or in the future, and thus perhaps isnt as good an optimi
On Tue, 1 May 2001, Dan Sugalski wrote:
> Right. What I'm thinking would be a good place to get to is a list of the
> functionality that the debugger needs to provide or have available to it
> from the interpreter, rather than the actual interface to the user. (Which
> is important, but a se
Great, thanks very much.
Dave
On Fri, 27 Apr 2001, Jarkko Hietaniemi wrote:
> > > see it.) The debugger must be able to see two scopes at the same time:
> > > its own and the debuggee's.
> >
> > Could you expand on this?
>
> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-02
On Wed, 25 Apr 2001, Johan Vromans wrote:
> Andy Dougherty <[EMAIL PROTECTED]> writes:
>
> > Starting with 'P' is useful so we can keep our acronyms such as PMC and
>
> PERIL (hi Tom!).
>
> -- Johan
< ACCENT=ENGLISH>
Please, can't I have just a little PERIL?
< /AC
On Fri, 27 Apr 2001, Dan Sugalski wrote:
> Thanks much for putting this together. I do appreciate it.
You are most welcome. I enjoyed it, and I'm looking forward to
updating it (though I'm hoping there will be a little more feedback,
particularly concerning the new suggestions).
>
On Thu, 26 Apr 2001, Jarkko Hietaniemi wrote:
>
> You list the particular commands as 'existing functionality'. I think
> this is a mistake, even if you didn't mean it that way, if it was just
> an artifact of your presentation format. I know that breaking
> debugging habits that have been i
=head1 The Perl6 Debugger
=head2 Perl-level Debugging
=head3 Existing Functionality
The following is a list of the functionality in the existing Perl5
debugger; this functionality should, of course, be maintained for
backwards compatibility.
=over 4
=item T
Stack trace.
=item
Apologies all...I have the document, but I'm having trouble getting it out
of my computer. I don't have Internet access yet and my floppy drive is
refusing to read. I'll see if I can get the printer hooked up tonight,
print the thing out, retype it at work tomorrow, and send it in then.
Dave
Hey folks,
Ok, so I've picked up Dan's gauntlet on the debugging PDD. I've
got a pretty long list of things to put in it already, but if anyone would
care to send me their suggestions, I can get them integrated into the
initial draft. I probably won't have it ready by tomorrow, and I on
On Thu, 12 Apr 2001, Dan Sugalski wrote:
> I think Perl_ and maybe Perl__ would be fine. I'd rather Perl_ and _Perl_,
> but...
How about PerlF_ and PerlD_ (for Functions and Data)?
To also specify Exported and Private we could have PerlFE_,
PerlFP, etc.
7;)
represent( $foo, 'UTF-8D')
represent( $foo, 'UTF-16C')
represent( $foo, 'UTF-16D') ...etc
Maybe a couple of extra switchs on regexen as well, to force the matched
string (and any captured substrings) to be in a particular encoding.
Dave Storrs
On Wed, 31 Jan 2001, Tim Bunce wrote:
> Since this thread is in the mood for quotes, here's one I'm fond of...
> It goes something along the lines of:
>
> Any fool can create a complicated system.
> The real skill is in making a simple one.
Ok, if we're all contributing qu
On Tue, 21 Nov 2000, Jarkko Hietaniemi wrote:
> Yet another bummer of the current SVs is that they poorly fit into
> 'foreign memory' situations where the buffer is managed by something
> else than Perl. "No, thank you, Perl, keep your greedy fingers off
> this chunk. No, you may not play wit
Heh. In my youth, we said "Thanks a million." I see that inflation has
now turned that into "Thanks a million and twenty four thousand." :>
On 12 Oct 2000, John van V wrote:
>
> $thanks -> (1000K)
On Wed, 27 Sep 2000, Dan Sugalski wrote:
> At 05:37 AM 9/27/00 +, Perl6 RFC Librarian wrote:
> >Perl should adopt scheme-like symbols, both at the language level
> >and at the internals level.
>
> The explanation of this isn't that clear for me. (I have no scheme
> experience at all)
On Tue, 26 Sep 2000, Dan Sugalski wrote:
> What'd be a larger win would be if we have async I/O built into the core
> ...
> This is reasonably simple on Unices that support it, as well as on VMS and
> Windows. Can't speak for other platforms, but I'm not hugely worried that
> we won't get th
It seems to me that everyone in this thread pretty much agrees that this
is a good idea, but has one of the following reservations:
1) Tracking sufficient information to be able to report errors at the
exact spot they happen involves bloating the optree a lot and slowing down
the whole program;
On Wed, 13 Sep 2000, Nathan Torkington wrote:
> Simon Cozens writes:
> > > Nice!
> > Efficient!
> > Practical!
> >
> > Choose two.
>
> I take this oblique comment to mean that it'd bloat the op-tree too
> much?
Well, suppose we simply add the -FOO (choose your letter) flag to
perl...
On Fri, 11 Aug 2000, David L. Nicol wrote:
[...]
> Redefining a method during run time --- is that even a feature that
> needs to be supported?
I think so. A couple of examples are the Memoize module, which
works by rewriting your memoized function into something that uses
caching, th
37 matches
Mail list logo