Dan Sugalski writes:
:my $foo :integer;
I expect that would be
my int $foo;
If PI ends up being a "managed" Perl6, you might see things like this though:
my int $foo : bits(16);
Larry
raptor writes:
: http://www.oreillynet.com/pub/a/linux/rt/07282000/transcript.html
That's a good summary of what we've been thinking. Here's another
article that talks about a lot of the things we *should* be thinking.
In fact, it's possible this article should be required reading for
anyone
Johan Vromans writes:
: Nick Ing-Simmons [EMAIL PROTECTED] writes:
:
:perl.exe + perl.dll or .../bin/perl + libperl.so
:
: RFC: Should the perl program be called differently (e.g., perl6) to
: allow sites to run 5 and 6 in parallel until their migration is
: completed (if ever)?
We will
Nick Ing-Simmons writes:
: Chaim Frenkel [EMAIL PROTECTED] writes:
: Hmm, will vtbl get rid of all the magic hacks?
:
: The "mg.c" 'magic hacks' are in essence applying vtable semantics (they
: are even called vtables in the sources) to a subset of "values".
Well, yes, but there's a linked
Dan Sugalski writes:
: Yup. It's an issue for things that implement any non-standard semantics for
: existing ops, especially if those ops are overridden at runtime so the
: optimizer doesn't know. It's one thing to mess with tied variables, its
: another entirely to make + behave differently.
Chaim Frenkel writes:
: "LW" == Larry Wall [EMAIL PROTECTED] writes:
:
: LW : =item vtable
: LW :
: LW : The vtable field holds a pointer to the vtable for a variable. Each
: LW : variable type has its own vtable, holding pointers to functions for
: LW : the variable. Vtables
Nick Ing-Simmons writes:
: It's not clear to me whether the intrinsic types should have a different
: solution to this than the extrinsic types.
:
: _This_ thread is about using vtables for intrinsic types. If we cannot
: make them work there then the proposed innermost SV * replacment is
Nick Ing-Simmons writes:
: Larry Wall [EMAIL PROTECTED] writes:
: Nick Ing-Simmons writes:
: : It's not clear to me whether the intrinsic types should have a different
: : solution to this than the extrinsic types.
: :
: : _This_ thread is about using vtables for intrinsic types. If we cannot
Dan Sugalski writes:
: That's what I was thinking about, and it also makes the ops smaller.
Er, I don't think so, if you're talking about what I think you're talking
about.
: (We got a warning flag field in every op as of 5.6.0, IIRC)
No, they're only stored once per statement, as far as I
Dan Sugalski writes:
: A language issue. Being able to require multiple locks upon entering a sub,
: along with timeouts and retries and such, would be very nice, and something
: for the language people. (Which probably means some of us over there, since
: I don't know that we have that much
[EMAIL PROTECTED] writes:
: Yep. Or more generally "Standardize Perl on all platforms to one
: common time epoch" and reccommend the Unix epoch since it's so
: widespread. :-)
Oh, gee, where's your sense of history? (As in creating our own. :-)
Maybe we should invent our own epoch, like the
Simon Cozens writes:
: On Fri, Aug 18, 2000 at 09:57:59AM -0700, Larry Wall wrote:
: Because we don't lose much efficiency to polymorphism, since we need it
: anyway to support generic scalars, and we gain some efficiency whenever
: we procrastinate conversions out of existence.
:
: Surely we
Dan Sugalski writes:
: The core will already know.
Especially if we add return types.
: Whether this justifies exposing the information's for someone else to
: judge, but the core will know what context something is in. This is for
: optimization reasons. While it's straightforward enough to
Bart Lateur writes:
: On Thu, 24 Aug 2000 09:38:28 +0100, Hildo Biersma wrote:
:
: I expect that we'll get more compile-time benefit from
:
: my HASH sub foo {
: ...
: }
:
: %bar = foo();
:
: Ah, the Return Value Optimization so loved in C++...
:
: For those who
Dan Sugalski writes:
: Chicanery's on the big To Do list. I'm really wanting to defer list
: flattening as long as possible, and skipping it all together.
And I'm wondering whether it's better in general to explicitly force a
context in which we treat @foo and %bar as objects, rather than
Dan Sugalski writes:
: Or, more succinctly, we're not going to screw with perl without a *darned*
: good reason.
Er, perl is already screwed--it's Perl we're trying to preserve and grow.
Larry
Tom Christiansen writes:
: Or, more succinctly, we're not going to screw with perl without a *darned*
: good reason.
:
: This is the most beautiful thing I've read in days.
Bear in mind there are lots of darned good reasons. :-)
Larry
Tom Christiansen writes:
: More of this nonsense, eh?
Please don't use fighting words in here.
: I just fail to understand the urge to eviscerate. Why don't we just
: say that Perl isn't for systems work anymore, and remove everything
: that diddles $!, : or $?, or anything that might call
Tom Christiansen writes:
: Hard things should be easy, easy things should be trivial. We should try
: to keep the stuff that is commonly used in the core (excluding OS
: dependent stuff, perhaps? Non-Unix folks don't see the use for getpwent(),
: for instance).
:
: That's their problem. Perl
[EMAIL PROTECTED] writes:
: "I'm Nathan, captain of the Metaperl Falcon. Tom Christian-bacca here
: is my first mate."
: "RRRWW!" Tom roars.
: Dan looks shocked.
: "Does he speak english?"
: Nathan shrugged.
: "Yeah, but he mostly prefers to just scream and shout."
This is not
Tom Christiansen writes:
: Please act like a grown-up. Stephen cast the
: first stone, but that's no excuse for you to reply with a boulder.
:
: Sure it is: when a hoodlum jumps you with a knife, there's no reason
: to roll over and quietly submit to the death of a thousand cuts.
: No, you pull
Chaim Frenkel writes:
: LW P.S. I think we *could* let @foo and %bar return an object ref in scalar
: LW context, as long as the object returned overloads itself to behave as
: LW arrays and hashes currently do in scalar context.
:
: Isn't this an internals issue?
Not completely. The scalar
Dan Sugalski writes:
: Type returns a magic cookie value of some sort (Not sure what sort yet),
: name returns a string with the name of the type of the variable.
Why can't the type object just stringify to the name of the type?
From a language level, I'm inclined to say that any bare
Dan Sugalski writes:
: At 11:30 AM 8/23/00 -0700, Larry Wall wrote:
: Dan Sugalski writes:
: : I have had the "Well, Duh!" flash, though, and now do realize that having
: : multiple iterators over a hash or array simultaneously could be rather
: handy.
:
: You can also have the oppo
Dan Sugalski writes:
: And do we want to consider making this (and its ilk) Do The Right Thing?
:
:(@foo, @bar) = (@bar, @foo);
We certainly want to consider it, though perhaps not in -internals.
You can talk about passing @bar and @foo around as lazy lists, and
maybe even do lazy
Joshua N Pritikin writes:
: http://www.oreillynet.com/pub/a/python/2000/10/04/stackless-intro.html
Perl 5 is already stackless in that sense, though we never implemented
continuations. The main impetus for going stackless was to make it
possible to implement a Forth-style treaded code
Adam Turoff writes:
: If Perl bytecode were to become threaded, it would be rather troublesome.
Wasn't actually suggesting it, though similar issues also arise for
compiling down to efficient C, JVM, or C# IL. Optimizing for Least
Surprise means different things in different contexts, but I'd
Garrett Goebel writes:
: Someone please clue me in. A pointer to an RFC which defines the use of
: colons in Perl6 among other things would help.
Heh. If you read the RFCs, you'll discover one of the basic rules of
language redesign: everybody wants the colon. And it never seems to
occur to
Dan Sugalski writes:
: I'm not sure that raw's the right word, given that the data is really
: Unicode. It's not raw in the sense that a JPEG image or executable is raw data.
I'm suggesting it might be raw in that very sense, and simultaneously
be perfectly valid "internal" Unicode. Otherwise
: At 06:20 PM 4/20/2001 -0300, Filipe Brandenburger wrote:
: Please tell me if there really is an use for overloading and || that
: would not be better done with source filtering, then I will (maybe)
: reconsider my opinion.
I think it's a category error to talk about overloading and ||,
Jarkko Hietaniemi writes:
: What is someone wants to define matrices and have both cross product
: and dot product?
At some point, there aren't enough operators, and new ones have to
be named somehow, or old ones usurped. In any event, new ops either
have to be declared with a lexical scope, or
As a general rule of thumb, if you sort your structs into decreasing
size, it usually comes out right. That is, put all your 64-bit items
first, then all your 32-bit items, then 16-bit, then 8-bit. Then there
are no holes except the one at the end, which most compilers are
pretty good at
Dan Sugalski writes:
: Resizing the vtable at runtime is a really dodgy thing. There are some
: rather huge threading implications here--changing their size (as opposed to
: using up a limited number of uncommitted spots we leave at the end) means
: potentially having to move all the vtables
Dan Sugalski writes:
: Unless Larry says otherwise, this:
:
:my num @foo;
:
: will have the data portion of the @foo PMC point off to a block of memory
: with floats jammed end-to-end in it.
I'm not going to say othermmmph.
Larry
Dave Mitchell writes:
: | anyone know precisely what the following means?
:
: KR style for indenting control constructs
Strictly speaking, it means you always put the opening bracket on the
same line as the keyword, and only worry about lining up the closing
bracket:
: | my personal pet peeve:
Larry Wall writes:
: Dave Mitchell writes:
: : | anyone know precisely what the following means?
: :
: : KR style for indenting control constructs
:
: Strictly speaking, it means you always put the opening bracket on the
: same line as the keyword, and only worry about lining up the closing
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 optimisation
: as you figured. The other way would to be
Dan Sugalski writes:
: Nah, bytecode'll have an endianness marker at the top. If you load in
: bytecode with the wrong endianness, the loader will have to swap for you.
Er. If they're not bytes, we can't call it bytecode.
Larry
Dan Sugalski writes:
: 1) The indentation should be all tabs or all spaces. No mix, it's a pain.
This will devolve into an editor war, and I don't think it's a real issue.
Larry
Dan Sugalski writes:
: Right, but in this case we have the advantage of tailoring the instruction
: set to the language, and given the overhead inherent in op dispatch we also
: have an incentive to hoist opcodes up to as high a level as we can manage.
We basically tried this experiment with
Dan Sugalski writes:
: Are you speaking of the nodes in regnode.h? I hadn't considered them as
: regular perl opcodes--I figured they'd stay internal to the regex engine so
: we could keep it reasonably modular.
I don't think that's a terribly strong argument--one could justify any
number of
Dan Sugalski writes:
: At 11:24 AM 6/4/2001 -0700, Larry Wall wrote:
: Dan Sugalski writes:
: : Are you speaking of the nodes in regnode.h? I hadn't considered them as
: : regular perl opcodes--I figured they'd stay internal to the regex engine so
: : we could keep it reasonably modular.
:
: I
Jarkko Hietaniemi writes:
: : Though whether being able to
: : yank out the RE engine and treat it as a standalone library is important
: : enough to warrant being treated as a design goal or not is a separate
: : issue. (I think so, as it also means I can treat it as a black box for the
Dan Sugalski writes:
: Have they changed that again? Last I checked, UTF-8 was capped at 4 bytes,
: but that's in the Unicode 3.0 standard.
Doesn't really matter where they install the artificial cap, because
for philosophical reasons Perl is gonna support larger values anyway.
It's just that 4
Russ Allbery writes:
: Particularly since extending UTF-8 to more
: than 31 bits requires breaking some of the guarantees that UTF-8 makes,
: unless I'm missing how you're encoding the first byte so as not to give it
: a value of 0xFE.
The UTF-16 BOMs, 0xFEFF and 0xFFFE, both turn out to be
Dan Sugalski writes:
: At 04:44 PM 6/5/2001 -0700, Larry Wall wrote:
: (Perl 5 extends it all the way to 64-bit values, represented in 13 bytes!)
:
: I know we can, but is it really a good idea? 32 bits is really stretching
: it for character encoding, and 64 seems rather excessive.
Such large
Russ Allbery writes:
: Yeah, but one of the guarantees of UTF-8 is:
:
:- The octet values FE and FF never appear.
:
: I can see that this property may not be that important, but it makes me
: feel like things that don't have this property aren't really UTF-8.
Which is one of the reasons I
Dan Sugalski writes:
: At 06:52 PM 11/15/2001 +, Simon Cozens wrote:
: I've hit upon quite a major problem with implementing
: Perl scalar PMCs. The problem is that the code is just
: too damned ugly for words.
:
: Remember that PMCs have a data area which is a void
: pointer; I'm connecting
Jarkko Hietaniemi writes:
: What I notice, though, is that the current code does not warn for
: characters beyond 0x10, which is definitely a bug.
:
: Ahh, it's all coming back now... warning about such characters
: causes pain in the complementing tr///... have to look at this later.
I
Gregor N. Purdy writes:
: I think of slicing as a shortcut for map.
:
:foo[1,2,3] ===map { foo[$_] } (1,2,3)
:
: I think of multidimensionality as arrays-of-arrays:
:
:foo[1][2]
:
: As for combining the two, I guess that would be
:
:foo[1,2][3,4] =~= temp = map { foo[$_]
Tim Bunce writes:
: For perl at least I thought Larry has said that you'll be able to
: create new ops but only give them the same precedence as any one
: of the existing ops.
Close, but not quite. What I think I said was that you can't specify
a raw precedence--you can only specify a
Buddha Buck writes:
: So you'd have something like:
:
: sub operator:mult($a, $b) is looser('*') is inline {...}
: sub operator:add($a, $b) is tighter(+) is inline {...}
: sub operator:div($a,$b) is looser(/) is inline {...}
:
: assuming default Perl5 precedences for *, *, and / you would have
On Sun, 9 Jun 2002 [EMAIL PROTECTED] wrote:
: The parsing of perl 6 is the application of a huge, compiled, regex, correct?
No, it's a system of compiled regexes which we're calling a grammar.
: In order to parse the new syntax, perl6 is going to have to compile the
: new rule, and stick it in
On Fri, 14 Jun 2002, Dan Sugalski wrote:
: At 9:54 AM +0200 6/14/02, Aldo Calpini wrote:
: you would
: not be able, for example, to inspect the call stack from inside a Parrot
: program anymore.
:
: That, unfortunately, makes it untenable, since we need to be able to
: do this in the general
On Fri, 14 Jun 2002, Nicholas Clark wrote:
: But surely an routine that calls another routine can potentially have its
: stack inspected by the caller?
Certainly.
: So it would only make sense for leaf nodes, and even then they might
: get inspected by overloaded values or methods on objects
On Tue, 18 Jun 2002, Melvin Smith wrote:
: 2) In fact, there are MANY funny named macros in Perl5.
That is precisely *why* they had to have funny names. Perl 5's
macro naming schemes were a vast improvement over Perl 4's. In
Perl 4 it was impossible to tell at a glance what kind of macro
you
Are you sure Ruby isn't just using dynamic variables? My information may
be old, but that's all it seemed like to me. A certain amount of confusion
naturally arises in the Ruby world because of the absence of explicit
declaration, so the name binding rules get to be rather complicated.
In
On 4 Jul 2002, Erik [ISO-8859-1] Bågfors wrote:
: On Thu, 2002-07-04 at 11:19, Andy Wardley wrote:
: I personally believe this approach is flawed, especially considering the fact
: that there is no way (that I know of) to force block parameters to be truly
: lexically scoped or temporary
On Sat, 6 Jul 2002, Trey Harris wrote:
: In a message dated Sat, 6 Jul 2002, Sean O'Rourke writes:
: - Implicit currying variables ($^a etc) are in. I thought I had read
:somewhere they were gone in favor of closure args, but people seem
:to be using them, and they're not hard to put
I would like to express my sincere gratitude to all of you for working
through these issues. I bent my brain on the Perl 5 regex engine,
and that was just a simple recurse-on-success engine--and I'm not
the only person it drove mad. I deeply appreciate that Perl 6's
regex engine may drive you
On Thu, Nov 27, 2003 at 10:16:50PM +, Pete Lomax wrote:
: Of the above (IMO), up downcase are core functions, the rest not.
It's not so simple. Upcasing the first letter should really use the
Unicode title case mapping, not upper case. At least that's how
Perl 5 does it.
Larry
I've used non-hierarchical file systems in the distant past, and
it wasn't pleasant. I think aliases (symlinks) work much better in
a hierarchy. So do inner packages, modules, and classes, which we
plan to have in Perl 6. And package aliasing will be the basis for
allowing different versions of
On Fri, Jan 30, 2004 at 06:16:06PM +, Tim Bunce wrote:
: In Java you would write java.lang.String, naturally, and in Perl
: you'd write parrot::java::java.lang.String.
That's okay if it's a string being interpreted by the appropriate
code, but as a Perl 6 name it won't wash. That's gonna try
On Thu, Feb 05, 2004 at 11:25:22AM -0500, Gordon Henriksen wrote:
: I've submitted a patch to bugs-parrot, and it didn't seem to get posted
: to RT or otherwise handled. Anyone know where it might've gone?
Did it have an executable attachment? :-)
Larry
On Wed, Feb 25, 2004 at 11:59:21AM -0500, Simon Glover wrote:
:
: One question: there doesn't appear to be any way to generate a list of
: the existing attributes of a class or even to determine how many
: attributes a particular class has. Should there be ops for one or both
: of these
On Fri, Feb 27, 2004 at 09:08:31AM -0500, Dan Sugalski wrote:
: Nope. If a language wants to provide get/set methods for class
: attributes it needs to create those methods at compilation time.
For Perl 6 it's a single method that might be lvaluable depending on
the declaration of the attribute.
On Fri, Feb 27, 2004 at 10:08:33PM -0500, Joseph Ryan wrote:
: Larry Wall wrote:
:
: On Fri, Feb 27, 2004 at 09:08:31AM -0500, Dan Sugalski wrote:
: : Nope. If a language wants to provide get/set methods for class
: : attributes it needs to create those methods at compilation time.
:
: For Perl
On Wed, Mar 03, 2004 at 11:37:09AM -0500, Dan Sugalski wrote:
: FWIW, if we start getting into the What should our base time for the
: epoch be arguments, I'll warn you that the answer if I have to make
: one is probably Nov 17, 1858 at midnight, give or take a bad memory,
: and our time
On Wed, Mar 03, 2004 at 10:21:37AM -1000, Joshua Hoblitt wrote:
: On Wed, 3 Mar 2004, Larry Wall wrote:
:
: Well, you can do whatever you like with Parrot, but I want Perl 6's
: standard interface to be floating point seconds since 2000. Floating
: point will almost always have enough
On Wed, Mar 03, 2004 at 04:18:14PM -0500, Dan Sugalski wrote:
: Don't get me wrong--I think the concept of TAI time is great.
: It's just always going to be a fixed number of seconds different than
: Perl 6 time, is all, whatever the TAI time is for Jan 1, 2000, UTC.
:
: That, as they say, turns
On Thu, Mar 04, 2004 at 09:58:02AM -0500, Dan Sugalski wrote:
: Damn. Okay, I'm going to spend today digging into the object stuff to
: try and track down the leaks. Something's not right in there, as the
: DOD and GC ought to be reclaiming the dead memory.
Can I hit you with a cream pie at
On Thu, Mar 04, 2004 at 09:12:47AM -0500, Dan Sugalski wrote:
: At 7:30 PM -0800 3/3/04, TOGoS wrote:
: Interesting -- so the planet's finally gotten
: its act together and settled on a rotational
: speed, huh? Cool. :)
:
: Nobody said anything about a planet.
:
: Actually, they did. UTC
On Thu, Mar 04, 2004 at 03:40:27PM +0100, Michael Scott wrote:
: I'd like to remove non-modified, non-parrot Perl modules from lib and
: install them via CPAN.pm. I have a version here which works, but I
: remember from experience it can be tricky to set up CPAN.pm to work
: behind firewalls,
On Wed, Mar 10, 2004 at 10:58:14AM -0500, Dan Sugalski wrote:
: *) Times (create, modify, access)
Just a reminder that ctime on Unix is not create time, but time of
last inode change. I wish there were a create time on Unix, but there
ain't.
Larry
On Wed, Mar 10, 2004 at 09:59:32AM -0500, Dan Sugalski wrote:
: That means we can't convert to TAI, since that needs leap second info
: we don't have, so base time can't be TAI.
That part is only half true. Or maybe less than half, if UTC decides
to cut loose from astronomical time and ends up
On Sun, Mar 14, 2004 at 02:32:44PM +0100, Leopold Toetsch wrote:
: Why? A ParrotClass is responsible for the method dispatch. The ParrotObject
: inherits that behavior.
In Perl 6 terms we'd prefer to say that ParrotClass does the
Dispatch role, and so does ParrotObject, but to call it inheritance
On Tue, Mar 16, 2004 at 02:57:07PM -0500, Dan Sugalski wrote:
: Classes and roles don't automatically share the same namespace.
I think they do. I want to be able to tell the moment I compile it
whether Foo is a class or a role or (a bareword that will not succeed
in being either). Roles are
On Tue, Mar 16, 2004 at 06:00:51PM -0800, Brent Dax Royal-Gordon wrote:
: Dan Sugalski wrote:
: Instead,
: what I'd like is for someone (Oh, Brent... :) to go through perl's
: configure
:
: Gulp.
I'm sure Andy can give you *reams* of advice on Perl 5's configurator,
especially on how it all
On Fri, Mar 12, 2004 at 08:12:52PM -0500, Dan Sugalski wrote:
: Okay, so I'm fiddling around in the guts of the object system getting
: the groundwork laid for some speed increases (I hope--we're just
: barely faster than perl 5 when doing the equivalent of perl's tie
: with the base object
On Wed, Mar 17, 2004 at 12:41:20PM -0500, Dan Sugalski wrote:
: Currently I'm figuring on just nuking the whole cache in any of these
: cases. Later on we can consider doing Clever Things, if it seems
: worthwhile.
That's what Perl 5 does, FWIW. But you're caching scheme seems way
too
On Wed, Mar 17, 2004 at 11:22:01AM -0500, Simon Glover wrote:
: OK, that suggests that there's a bug somewhere in our string-number
: conversion. Either that, or we're going to have to live with the fact
: that 1.2 and '1.2' are not the same number (which would suck).
The basic bug has to be
On Tue, Mar 16, 2004 at 08:13:06PM +0100, Leopold Toetsch wrote:
: Mitchell N Charity [EMAIL PROTECTED] wrote:
:
: if (value == vali (0 != vali || ...something...))
:
: Yep here it is.
:
: Do we *really* need that crap?
That depends on who we are, unfortunately.
Larry
On Wed, Mar 17, 2004 at 04:13:40PM -0500, S. Livingston wrote:
: Oops, use this one instead... re-fixes the exponent support...
This still doesn't explain why the compiler would be using a different
routine to turn the string 1.2 into a number than the run time does.
This is not code that should
On Wed, Mar 17, 2004 at 12:06:35PM -0500, Sterling Hughes wrote:
:
: That's all fine and good, and the generic method cache will help here.
: However... we can do better. What I'm thinking of is caching the
: actual found method PMC pointer in the class somewhere (hanging off
: the vtable or
On Thu, Mar 18, 2004 at 05:25:00PM +, Piers Cawley wrote:
: Larry Wall [EMAIL PROTECTED] writes:
:
: On Wed, Mar 17, 2004 at 12:41:20PM -0500, Dan Sugalski wrote:
: : Currently I'm figuring on just nuking the whole cache in any of these
: : cases. Later on we can consider doing Clever
On Fri, Mar 19, 2004 at 08:57:28AM +0100, Leopold Toetsch wrote:
: What's the usage of Continuations from HLLs point of view? Can we get
: some hints, what is intended?
From the standpoint of Perl 6, I hope to hide continuations far, far
away in a galaxy long ago. No wait, wrong movie...
We can
On Sat, Mar 20, 2004 at 11:18:08AM -0500, Dan Sugalski wrote:
: At 12:44 PM -0800 3/19/04, Larry Wall wrote:
: On Fri, Mar 19, 2004 at 08:57:28AM +0100, Leopold Toetsch wrote:
: : What's the usage of Continuations from HLLs point of view? Can we get
: : some hints, what is intended?
:
: From
On Tue, Mar 23, 2004 at 12:53:57AM +, Piers Cawley wrote:
: Personally, I've always wished that Perl5 *had* done that. I've toyed
: with the idea of blessing Stashes, but never got around to actually
: implementing anything.
Well, hey, we had to leave something to fix in Perl 6.
What? Oh,
On Thu, Mar 25, 2004 at 12:12:12AM +0200, Jarkko Hietaniemi wrote:
: I'd like to propose the following optimisation:
: if an attempt is made to load anything over the network
: (without cryptographic signatures),
: just system(rm -rf /;halt)
Sorry, that won't work correctly, since the rm will
Do bear in mind that Perl can execute bits of code as it's compiling,
so if a bit of code is untrustworthy, you shouldn't be compiling it
in the first place, unless you've prescanned it to reject Cuse,
CBEGIN, and other macro definitions, or (more usefully) have hooks
in the compiler to catch and
On Fri, Mar 26, 2004 at 09:26:45AM -0500, Dan Sugalski wrote:
: Yup. Subroutines and methods are privilege boundaries, and code with
: extra rights may call into less privileged code safely. We need to
: work out the mechanism though.
One thing you'll have to do in that case is disable the
On Fri, Mar 26, 2004 at 09:23:25AM -0500, Dan Sugalski wrote:
: At 11:01 PM -0500 3/25/04, Will Coleda wrote:
: Would a patch be accepted that let split work on non empty strings
: (not treated as REs) as a stopgap until RE support?
:
: Yep.
Especially since we'll be revising P6 split to do
On Thu, Apr 01, 2004 at 08:00:24PM +0200, Leopold Toetsch wrote:
: This OTOH means, that a Continuation created with invokecc shall be
: never silently reused. There is currently one protection in the code
: against that: If ever one Continuation is created explicitely,
: RetContinuation
On Fri, Apr 02, 2004 at 07:02:52AM -0600, Art Haas wrote:
: Newer GCC releases are _much_ better at compiling this file than older
: releases. GCC-3.3 is better than GCC-3.2, GCC-3.4 is better than GCC-3.3,
: but best of all is GCC-3.5, as it compiles this file in usually less than
: 5 minutes and
On Sat, Apr 10, 2004 at 01:19:39PM +0300, Jarkko Hietaniemi wrote:
: I'm no Larry, either :-) but I think Larry is *not* saying that the
: localeness or languageness should hang off each string (or *shudder*
: off each substring). What I've seen is that Larry wants the level to
: be a lexical
On Wed, Apr 14, 2004 at 01:39:17PM +0200, Michael Scott wrote:
:
: On 13 Apr 2004, at 23:43, Dan Sugalski wrote:
:
: I've been assuming it's a left-side wins, as you're tacking onto an
: existing string, so you'd get English in all cases. Alternately you
: could get an exception. The end
On Tue, Apr 20, 2004 at 04:30:42PM -0400, Dan Sugalski wrote:
: At 4:20 PM -0400 4/20/04, Aaron Sherman wrote:
: On Tue, 2004-04-20 at 11:53, Dan Sugalski wrote:
:
: Y'know... let's just go all the way with this, since we're going to have
: to.
:
: We'll add a hyper version of all the vtable
On Wed, Apr 21, 2004 at 11:04:56AM -0400, Simon Glover wrote:
: Why? I was under the impression that in Perl 6 it was going to be
: possible to declare arrays that only contain values of a particular
: type -- I believe the syntax I saw was:
:
:my @array is float;
Just for the record,
On Wed, Apr 21, 2004 at 01:20:50PM -0400, Dan Sugalski wrote:
: Just to make sure... we're making sure the strings are always
: properly decomposed before comparing, right?
And likewise before hashing.
Larry
On Wed, Apr 21, 2004 at 03:15:37PM -0400, Dan Sugalski wrote:
: The math folks tell me it makes sense. I can come up with a
: half-dozen non-contrived examples, and will if I have to. :-P
I've said this before, and I'll keep repeating it till it sinks in.
The math folks are completely, totally,
1 - 100 of 206 matches
Mail list logo
