On Wed, Nov 20, 2002 at 05:51:17PM -0500, Tanton Gibbs wrote:
> It's going to be hard to beat sprintf( "%x", $i ) for clarity or
> conciseness.
my $s = "%x" % $i; # python wins for conciseness :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
On Thu, Nov 21, 2002 at 01:02:57PM -0800, Michael Lazzaro wrote:
>_01.23 # wrong
>01.23_ # wrong
Is _ not space eater, or was that not decided? If it is then aren't
these two just literals with space eaters.
andrew
--
Capricorn: (Dec. 22 - Jan. 19)
You will soon be unwillingly
> > Are you suggesting this?
> >
> > if($error) {
> > use visible '&croak';
> > require Carp;
> > import Carp: 'croak';
> > croak($error);
> > }
>
> No - that would be pointless as well as error-prone.
>
> My idea of "visible" is that it would make a lexically scoped thing
> accessible to an inn
On Thu, Nov 21, 2002 at 11:59:36AM -0500, Andy Dougherty wrote:
> While compiling, I did get the warnings:
>
> "cpu_dep.c", line 24: warning: initializer does not fit or is out of
> range: 0x91d02003
> "cpu_dep.c", line 26: warning: initializer does not fit or is out of
> range: 0x81c3e008
That
On Thu, 2002-11-21 at 20:11, Brent Dax wrote:
> Are you suggesting this?
>
> if($error) {
> use visible '&croak';
> require Carp;
> import Carp: 'croak';
> croak($error);
> }
No - that would be pointless as well as error-prone.
"Chromatic" <[EMAIL PROTECTED]> asked:
> Where would you like to generate the test files? Would it be part of the
> standard 'make' target? Would it happen at the start of 'make test'?
Would we
> do it before checking the test files into source control?
My usual approach is to checkin the genera
On Wed, 20 Nov 2002 19:59:56 +, Dave Whipp wrote:
> I was wondering when someone would bring that up (someone always
> does). Extensibility doesn't matter: the code generator's specific purpose
> is to generate tests of numeric literals. If that isn't what you want, use
> a different generator
Larry Wall <[EMAIL PROTECTED]> writes:
> On Thu, Nov 21, 2002 at 12:27:01PM -0500, Joseph F. Ryan wrote:
> : So how should this behave:
> :
> : print "$('one','two','three')"
>
> Probably prints "['one','two','three']" or whatever an array ref
> stringifies to by default in Perl 6. It's certainl
Larry Wall <[EMAIL PROTECTED]> writes:
> On Thu, Nov 21, 2002 at 01:29:32AM -0500, Tanton Gibbs wrote:
> : Properties have bothered me, but for a different reason. It appears that
> : everyone's answer to everything is "make it a property!"
>
> Yes, properties should generally be a last resort, n
I'll have some time over the Thanksgiving holiday to work on some
polished, "finished" Section 1 docs, so if anyone has anything more for
numeric behaviors that they want to contribute, please send it to me
before next Monday. (Other things on variables, literals in general,
string handling,
If memory serves me right, Dan Sugalski wrote:
> I do actually like it. I was shooting for simplicity with the
> assumption that, since we were calling out to non-parrot-aware code,
> all bets were off with respect to type safety. If you load in
> libgtk.so and call functions dynamically there'
With the very latest corrections. The last remaining known "numeric
literals" issue is whether we want to allow '.' in explicit radix, e.g.
10#1.234, or whether we want to disallow it as being Way Too Creepy.
Am I missing anything else, or is this part done?
--- Numeric Literals ---
decimal
On Thu, Nov 21, 2002 at 11:27:07AM -0600, Me wrote:
: And documenting this by the '->' distinction
: described above (ie -> means private $_ set
: by mumble, no -> means $_ is just the outer
: lexical) would look natural as well being
: logical and strikingly simple.
It would, however, force peopl
On Thu, Nov 21, 2002 at 12:27:01PM -0500, Joseph F. Ryan wrote:
: So how should this behave:
:
: print "$('one','two','three')"
Probably prints "['one','two','three']" or whatever an array ref
stringifies to by default in Perl 6. It's certainly not going to do
what Perl 5 does with a reference,
On Thu, Nov 21, 2002 at 09:10:53AM -0800, Larry Wall wrote:
> On Wed, Nov 20, 2002 at 10:16:54PM -0800, Dave Storrs wrote:
> : As a tangent...one of the things that has bothered me about "but" and
> : "is" for properties since the beginning is that they make for
> : excessively long code. Does th
On Thu, Nov 21, 2002 at 02:41:33AM -0800, Ask Bjoern Hansen wrote:
> [EMAIL PROTECTED] (Dave Storrs) writes:
>
> > send in our Contributor License Forms. You can read all the license
> > details at:
> > http://snipurl.com/bkt
>
> http://pdp.perl.org/contributor_agreement also sends you to th
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote :
>
> 1) "Formats" as classes. What I _want_ to do is to be able to
> associate a named "format" with a given class/instance/output, because
> I tend to use the same few formats over and over. So if I want to
> frequently output numbers as '%-4.2d', I j
> 1) "Formats" as classes. What I _want_ to do is to be able to
> associate a named "format" with a given class/instance/output, because
> I tend to use the same few formats over and over. So if I want to
> frequently output numbers as '%-4.2d', I just call it "MoneyFormat" or
> something:
>
>
On Thursday, November 21, 2002, at 12:16 AM, Dave Storrs wrote:
I do agree that having it be a method (and hence overloadable) is the
best solution. I just wish there were some way to get away from those
dratted sprintf format strings.
Amen. God, I've hated those things for years. And yet m
At 10:17 PM +0530 11/21/02, Gopal V wrote:
If memory serves me right, Dan Sugalski wrote:
Currently open is the situation of flags and such from more complex
calls. (Like what we do if we get back a pointer that's getting
stuffed into a PMC--do we set the type, if so what type, and what do
we
If memory serves me right, Dan Sugalski wrote:
> Currently open is the situation of flags and such from more complex
> calls. (Like what we do if we get back a pointer that's getting
> stuffed into a PMC--do we set the type, if so what type, and what do
> we set the flags to?)
So is it totally
> If I'm understanding them correctly, another way to think of runtime
> properties is "dynamic inheritance", or more specifically
> "instance-based inheritance". When you say:
>
> $v but foo(5);
>
> You're saying that instance/value $v now inherits the behaviors of
> foo(5), in addition to it
On Thursday, November 21, 2002, at 12:24 AM, Dave Storrs wrote:
On Thu, Nov 21, 2002 at 01:29:32AM -0500, Tanton Gibbs wrote:
Properties have bothered me, but for a different reason. It appears
that everyone's answer to everything is "make it a property!"
Properties are just strange to compre
> [perhaps]
> : bare blocks (even those passed as args) just
> : pick up from the surrounding lexical context.
This is definitely a significant simplification.
Is it a problem?
> Yes, that's the problem. A bare block would
> have to notice at run time that it was called
> with unexpected argument
Larry Wall wrote:
: >You seem to agree with this in the later array interpolation section where
: >"@(1, 2)" becomes
: >12
: >instead of
: >1 2
: >
: >Does a list still return its last element in scalar context? I thought I
: >remembered something about that changing?
: >
:
: I think you may
On Thu, Nov 21, 2002 at 01:29:32AM -0500, Tanton Gibbs wrote:
: Properties have bothered me, but for a different reason. It appears that
: everyone's answer to everything is "make it a property!"
Yes, properties should generally be a last resort, not a first resort.
: Properties are just strange
On Wed, Nov 20, 2002 at 10:16:54PM -0800, Dave Storrs wrote:
: # Could you really tell what this does at a glance?
: my $s = ~hex:w4p2d0rs $i;
:
: my $s = ~hex $i but width 4
: but precision 2
: but padded 0
:
On Wed, Nov 20, 2002 at 10:35:31PM -0500, Joseph F. Ryan wrote:
: >Does q)hi( really DWIM?? I haven't kept up with it, so I didn't
: >know...that
: >is really odd if so.
: >
:
: Yep, Apoc 5. Personally, I'm not a big fan, but I'm not a language
: designer.
It's because s]foo]bar] is really ugl
On Thu, 21 Nov 2002, Dan Sugalski wrote:
> At 9:53 AM -0500 11/21/02, Jason Gloudon wrote:
> >On Thu, Nov 21, 2002 at 08:34:04AM +0100, Leopold Toetsch wrote:
> >
> >My patch in 16237 has the code to flush register windows on v8 and
> >older and v9
> >(64-bit) SPARC systems, which is what one is
On Thu, Nov 21, 2002 at 10:28:42AM -0500, Andy Dougherty wrote:
> > +#ifdef HAS_HEADER_SETJMP
> > +jmp_buf env;
> > +
> > +/* this should put registers in env, which then get marked in
> > + * trace_system_stack below
> > + */
> > +setjmp(env);
> > +#endif
>
> Alas, no, though
At 9:53 AM -0500 11/21/02, Jason Gloudon wrote:
On Thu, Nov 21, 2002 at 08:34:04AM +0100, Leopold Toetsch wrote:
My patch in 16237 has the code to flush register windows on v8 and
older and v9
(64-bit) SPARC systems, which is what one is really trying to achieve via
setjmp.
If this hasn't been
Damian Conway writes:
>
> There's no second iterator. Just C walking through an array.
>
( questions in the form of answers :-)
so :
* "for" impose array context for first argument and doesnt care about
"nature" of the array which it was given eventually as an argument .
no multiple st
At 9:12 AM +0100 11/21/02, Leopold Toetsch wrote:
Brent Dax wrote:
Dan Sugalski:
# ... Later the # ancillary routine may be nonexistant if we build
up the function # headers on the fly and embed the destination
function into them.
Oh JITters... ;^)
jit/i386 has already code to call (specific
At 11:01 PM -0800 11/20/02, Brent Dax wrote:
Dan Sugalski:
# which builds up a native call pmc that can be invoked. W is the new
# PMC for the function (we create it), X is a handle to a dlopened
# library, Y is the function name, and Z is the signature.
OK, clarification on something please. Is
On Thu, 21 Nov 2002, Leopold Toetsch wrote:
> > A bit more ... In particular, on Solaris, I've been able to track down
> > one way of triggering the the t/op/lexicals.t failure to list.c. If I
> > compile list.c without any optimization, the test passes. If I compile
> > just the list_new functi
They can't be very serious -- the archive link is dead.
Or perhaps everyone agrees that something needs to be done, but no-one
has any ideas?
=Austin
--- "Joseph F. Ryan" <[EMAIL PROTECTED]> wrote:
> david wrote:
>
> > The brazen heresy continues...
> >
> > http://mail.nongnu.org/mailman/listin
On Thu, Nov 21, 2002 at 08:34:04AM +0100, Leopold Toetsch wrote:
My patch in 16237 has the code to flush register windows on v8 and older and v9
(64-bit) SPARC systems, which is what one is really trying to achieve via
setjmp.
--
Jason
Leon Brocard (via RT) <[EMAIL PROTECTED]> writes:
> (To be honest, it would be wonderful if exceptions gave you a line
> number and code too, but let's keep it simple for now).
Without varargs macros this is not really simple. (IIRC they are
introduced in C99, but are in gcc for years now).
This
# New Ticket Created by Leon Brocard
# Please include the string: [perl #18566]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18566 >
I've posted a Brainfuck interpreter on list in the past, but it kept
on getting made out
On Thu, 2002-11-21 at 05:12, Piers Cawley wrote:
> As you may know, I do the weekly perl6 summaries...
Yes, and I believe I've neglected to thank you *tremendously* for, er,
picking up the slack for me. :-)
>
> I'm finding this group rather hard to summarize effectively, so much
> of the impor
Damian Conway <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>
>>> C is compile-time.
>> So, how would one create a class which inherits from some other
>> class
>> when you don't know what said other class is until runtime?
>
> Use Perl5-ish classes, or an C.
Perl5-ish classes? You mean 'ble
# New Ticket Created by Leon Brocard
# Please include the string: [perl #18565]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18565 >
A minor change to aid debugging.
(To be honest, it would be wonderful if exceptions gav
On Wed, Nov 20, 2002 at 10:54:24PM -0500, Joseph F. Ryan wrote:
> Alright, I've incorporated everyone's suggestions and
> fixes, so everything should be correct now.
>
> Next, we need bool types, bool type conversion,
AFAIK the answer to that is either "Perl 6 doesn't have boolean types
—it it on
[EMAIL PROTECTED] (Dave Storrs) writes:
> Allison has asked me to be the coordinator to make sure that we all
> send in our Contributor License Forms. You can read all the license
> details at:
>
> http://snipurl.com/bkt
http://pdp.perl.org/contributor_agreement also sends you to that pag
I think this week's review was fine. I consider p6d more of perl6 Black Ops
anyway. Basically, no one should know about us until we want them to.
Therefore, minimal summarization fits right in with that philosophy.
Tanton
As you may know, I do the weekly perl6 summaries...
I'm finding this group rather hard to summarize effectively, so much
of the important, fine tooth comb type work that goes on here is,
frankly unsummarizable, so I'm leaning towards summarizing the entire
list with a couple of paragraphs and link
The Perl 6 Summary for the week ending 20021117
"Oh! my ears and whiskers, I'm late!"
It's 0650, it's 20021120 and I've only just started writing the summary.
Call me lazy, call me a shirker, call me anything you damn well please,
just don't interrupt me while I'm writing this.
Brent Dax wrote:
Dan Sugalski:
# ... Later the
# ancillary routine may be nonexistant if we build up the function
# headers on the fly and embed the destination function into them.
Oh JITters... ;^)
jit/i386 has already code to call (specific) functions e.g. vtable funcs
or pmc_new_noinit.
On Thu, Nov 21, 2002 at 03:26:09AM -0500, Tanton Gibbs wrote:
> Dave Storrs wrote
> > best solution. I just wish there were some way to get away from those
> > dratted sprintf format strings.
>
> Well, for the general case, you could create convienence functions that
> handle getting the correct
> > > my str $s = sprintf("%x", $i);# 30 characters
> > > my str $s = hex $i; # 19 characters
> > > my $s = ~hex $i; # 16 characters
> >
> > I think these are good, but I really think that Larry's idea of an "as"
> > function is the best. Not only does it provide
On Thu, Nov 21, 2002 at 01:29:32AM -0500, Tanton Gibbs wrote:
>
> > As a tangent...one of the things that has bothered me about "but" and
> > "is" for properties since the beginning is that they make for
> > excessively long code. Does this bother anyone else?
> >
> > --Dks
>
> Properties have b
On Thu, Nov 21, 2002 at 01:22:50AM -0500, Tanton Gibbs wrote:
> > I actually rather like MikeL's suggestion for the unary ops; clear,
> > concise, and highly readable. And look:
> >
> > my str $s = sprintf("%x", $i);# 30 characters
> > my str $s = hex $i; # 19 characters
> > my $
52 matches
Mail list logo
