[EMAIL PROTECTED] (Chromatic) writes:
Is 10 a string? Is it a number? Is 10base-T a string? Is it a
number? Is an object with overloaded stringification and numification a
number? Is it a string?
I don't know a good heuristic for solving these problems. If you have
one, it's worth
Jens Rieks [EMAIL PROTECTED] wrote:
On Wednesday 28 April 2004, Leopold Toetsch wrote:
STRING * Parrot_get_runtime_path(interp, file_type, filename)
or some such. File type is one of [dynamic/shared extension, include_file,
library] currently.
I had no luck with writing this function,
Dan Sugalski [EMAIL PROTECTED] wrote:
The question isn't whether they *do*--rather it's whether they
*should*. The current implementation's not all that relevant except
as a demonstration of one set of semantics. What I want to do is work
out what the 'proper' semantics ultimately should be.
William Coleda wrote:
Ah, thank you.
This brings up another issue. Now, when I try to freeze a PerlArray of
PerlArray of language/tcl/lib/tclword.imc's, I get:
unknown PMC type to thaw 1792
Something's broken here. '1792' isn't a valid PMC type. Please note that
freeze/thaw isn't yet
Nicholas Clark [EMAIL PROTECTED] wrote:
Move (at least) the refcount and SV flags into the PMC
I don't think that this is the best idea. You are later stopping
refcounting anyway. But I can imagine that you might present an SV with
a refcount to (GC-unaware, unmodified) XS code.
Nicholas
On 18 May 2004, at 08:10, Leopold Toetsch wrote:
I don't think that this is the best idea. You are later stopping
refcounting anyway. But I can imagine that you might present an SV with
a refcount to (GC-unaware, unmodified) XS code.
It is not the best idea, but it is a temporary solution to the
Alberto Manuel Brandão Simões wrote:
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/pmc/delegate.t1 256101 10.00% 8
t/pmc/objects.t 1 256371 2.70% 26
Yep. The
Ah, thank you.
This brings up another issue. Now, when I try to freeze a PerlArray of PerlArray of
language/tcl/lib/tclword.imc's, I get:
unknown PMC type to thaw 1792
Ok, I go digging through the docs, find pdd02, which mentions freeze to say XXX: ...
need documenting. =-) A similar entry for
28915 was resolved by the time I got to it, I closed 29653 as notabug.
Regards.
Jerome Quelin wrote:
On Monday 17 May 2004 18:50, you wrote:
Ticket 28915 is resolved, but I don't have rt rights to change its
status: can somebody close it please?
Oh, and ticket 29653 (fake one) too.
Jerome
# New Ticket Created by TOGoS
# Please include the string: [perl #29674]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=29674
This patch adds an extensive answer to what's with
lexical pads?, and simple answers to
J Either use --save as a command-line flag, or you will be prompted for an
action if you don't supply one of --send, --save, --dump.
I you chose to save to a file, either provide a filename with --output
(or -o or --output-file), or you will be prompted for one.
?? why not stdout?
(maybe
Luke Palmer wrote:
Aaron Sherman writes:
Ok, so in the case of:
my int $i = ...;
we should apply Cconvert:as(..., ::int) and fail at run-time,
correct? There's nothing wrong with TRYING to do the conversion, just as
there should not be anything wrong with:
my int $i = 4;
which has
On Monday 17 May 2004 19:55, ibotty wrote:
J Either use --save as a command-line flag, or you will be prompted
for an
action if you don't supply one of --send, --save, --dump.
I you chose to save to a file, either provide a filename with
--output (or -o or --output-file), or you will be
James Mastros writes:
In the case of ..., give it type error semantics. That is, any
expression involving ... gets type Except instead of reporting
at the end of the statement, just suppress the errors and move on.
Huh? Um, no, your ideas as to what happens don't give the desired
--- Luke Palmer [EMAIL PROTECTED] wrote:
People were talking about what type ... should be. So at static
type analysis time (if we even do that; I think we do, otherwise we
wouldn't have static type declarations), you give ... type error
semantics, but then don't die until you actually run
At 9:39 AM +0200 5/18/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
The question isn't whether they *do*--rather it's whether they
*should*. The current implementation's not all that relevant except
as a demonstration of one set of semantics. What I want to do is work
out
On Mon, 2004-05-17 at 19:40, TOGoS wrote:
This patch adds an extensive answer to what's with
lexical pads?, and simple answers to how do i call a
function?. It also adds several questions regarding
object methods and attributes, and manages to answer
one of them.
Thanks, I'll apply this in
Dan Sugalski [EMAIL PROTECTED] wrote:
If we do that it means every PMC class is essentially a base type as
far as Parrot's concerned.
Basically yes. We just borrow some functions from parents to avoid
reimplementation and to reduce code size. I don't think that we need
much more inside the
I use over and over this idiom in perl5:
$a{$_}++ for @a;
This is nice and perlish but it gets easily pretty boring
when dealing with many list/arrays and counting hashes.
I thought overloading the += operator
%a += @a;
Probably that operator should be smart enough to be fed with
a
On Mon, 2004-05-17 at 17:13, chromatic wrote:
As Luke suggests, there's also programmer clarity to consider. If
determining how to compare depends on how you've used the variables to
compare, is it harder to understand the code?
To be specific, what does:
my $a = foo();
my
On Tue, 18 May 2004, Stéphane Payrard wrote:
I use over and over this idiom in perl5:
$a{$_}++ for @a;
In perl6, using a hash slice and a hyper(increment)operator:
[EMAIL PROTECTED];
JW == John Williams [EMAIL PROTECTED] writes:
JW On Tue, 18 May 2004, Stéphane Payrard wrote:
I use over and over this idiom in perl5:
$a{$_}++ for @a;
JW [EMAIL PROTECTED];
i see dead languages (apl :)
uri
--
Uri Guttman -- [EMAIL PROTECTED]
St?phane Payrard skribis 2004-05-18 23:14 (+0200):
I use over and over this idiom in perl5:
$a{$_}++ for @a;
This is nice and perlish but it gets easily pretty boring
when dealing with many list/arrays and counting hashes.
A3 says something about tr being able to return a histogram (a hash
John Williams skribis 2004-05-18 16:07 (-0600):
$a{$_}++ for @a;
[EMAIL PROTECTED];
That's not a bad idea, even in Perl 5:
1;0 [EMAIL PROTECTED]:~$ perl -MBenchmark=cmpthese -e'my @foo = (1..16,
1..10); cmpthese -1, { a = sub { my %foo; $foo{$_}++ for @foo; }, i
b = sub {
On Tue, 2004-05-18 at 05:23, James Mastros wrote:
(Note: Aaron Sherman's syntax above doesn't match A12#Overloading. Was
the syntax changed, or is he wrong?)
Aaron Sherman was arm-waving as the important bits were not related to
the specific syntax of coerce overloading.
--
Aaron Sherman
Stphane Payrard writes:
I use over and over this idiom in perl5:
$a{$_}++ for @a;
This is nice and perlish but it gets easily pretty boring
when dealing with many list/arrays and counting hashes.
I thought overloading the += operator
%a += @a;
Though that would like to mean
On Tue, 2004-05-18 at 18:16, Juerd wrote:
St?phane Payrard skribis 2004-05-18 23:14 (+0200):
I use over and over this idiom in perl5:
$a{$_}++ for @a;
This is nice and perlish but it gets easily pretty boring
when dealing with many list/arrays and counting hashes.
I never saw the
Austin Hastings wrote:
Hmm. For junctions I was thinking:
++ all([EMAIL PROTECTED]);
Which is almost readable.
But unfortunately not correct. Junctions are value, not lvalues.
This situation is exactly what hyperoperators are for:
++ [EMAIL PROTECTED];
Damian
-Original Message-
From: Damian Conway [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 18 May, 2004 08:09 PM
To: [EMAIL PROTECTED]
Subject: Re: idiom for filling a counting hash
Austin Hastings wrote:
Hmm. For junctions I was thinking:
++ all([EMAIL PROTECTED]);
Which
Damian Conway writes:
Austin Hastings wrote:
Hmm. For junctions I was thinking:
++ all([EMAIL PROTECTED]);
Which is almost readable.
But unfortunately not correct. Junctions are value, not lvalues.
This situation is exactly what hyperoperators are for:
++ [EMAIL
On Tue, May 18, 2004 at 06:32:28PM -0600, Luke Palmer wrote:
: Damian Conway writes:
: Austin Hastings wrote:
:
: Hmm. For junctions I was thinking:
:
:++ all([EMAIL PROTECTED]);
:
: Which is almost readable.
:
: But unfortunately not correct. Junctions are value, not lvalues.
:
On Tue, May 18, 2004 at 11:14:30PM +0200, Stéphane Payrard wrote:
I thought overloading the += operator
%a += @a;
There's been lots of discussion of this, but:
Probably that operator should be smart enough to be fed with
a mixed list of array and hashes as well:
%a += ( @a, %h); #
Luke asked:
Er, did the hyper operator's direction flip? I thought it was:
++ [EMAIL PROTECTED];
My bad. 'Tis indeed.
Damian
Austin Hastings asked:
Junctions are value, not lvalues.
Why not bundle lvalues together?
Because, although this would mean what it says:
all($x, $y, $z)++;
None of these would:
any($x, $y, $z)++;
one($x, $y, $z)++;
none($x, $y, $z)++;
We're trying to avoid
J == Juerd [EMAIL PROTECTED] writes:
J John Williams skribis 2004-05-18 16:07 (-0600):
$a{$_}++ for @a;
[EMAIL PROTECTED];
J That's not a bad idea, even in Perl 5:
J 1;0 [EMAIL PROTECTED]:~$ perl -MBenchmark=cmpthese -e'my @foo = (1..16,
J 1..10); cmpthese -1, { a =
35 matches
Mail list logo
