>From: [EMAIL PROTECTED]
>The problem with using the >units(1) database is that it only >deals with
>multiplicative relations -- so, e.g., >It won't handle temperature.
So the temperature functions available in units(1) aren't defined in the
database? They're hard-coded? I find that unlikely.
Yes. I think it's both useful and fun. I was thinking something similar
to
@[EMAIL PROTECTED] = map{1} @a;
But getting "$hash->{E1}->{E2}->...->{En} = 1;" instead of "$hash{E1} =
1; ... $hash{En} =1;".
What I'd really like to do is:
Given @a = ('E1', 'E2', ..., 'En');
@b = ('K1', 'K2',
At 7:10 AM +0100 3/29/05, Piers Cawley wrote:
Doesn't that rather depend on the type of the attribute? Personally, if I get
an object back from accessor method then I expect that any modifications of
that object's state will be seen the next time I look at the results of that
accessor method. This
Larry Wall wrote:
On Sat, Mar 26, 2005 at 02:37:24PM -0600, Rod Adams wrote:
: Please convince me your view works in practice. I'm not seeing it work
: well when I attempt to define the relevent parts of S29. But I might
: just be dense on this.
Well, let's work through an example.
multi meth
Darren Duncan <[EMAIL PROTECTED]> writes:
> At 11:26 PM -0700 3/16/05, Luke Palmer wrote:
>> > For each of the above cases, is a copy of or a reference to the
>>> attribute returned? For each, will the calling code be able to
>>> modify $obj's attributes by modifying the return values, or not?
Larry Wall <[EMAIL PROTECTED]> writes:
> I've been thinking about this in my sleep, and at the moment I think
> I'd rather keep .foo meaning $_.foo, but break the automatic binding
> of the invocant to $_. Instead of that, I'd like to see a really,
> really short alias for $self. Suppose we pick
Leopold Toetsch wrote:
William Coleda <[EMAIL PROTECTED]> wrote:
When invoking a PIR-defined object from C, what's the proper call?
pmc_new ? (Does that handle class_init) ?
I don't understand the question. Do you want to instantiate an object?
If yes, just do the same as the respective opcodes
On Mon, Mar 28, 2005 at 06:59:59PM -0800, Yitzchak Scott-Thoennes wrote:
> > There is no build_requires or recommends equivalent in MakeMaker, nor will
> > there be,
>
> Too bad. Seems to me it would make sense to have MakeMaker support
> adding the tags to META.yml.
Yes, it would make perfect
I've come across another garbage collection/DOD issue that I'm trying to
solve (without much success) and would appreciate some tips/advice on how
to locate the source of the problem.
It appears (based on my tests) to cause strings to be marked as dead
objects before their time. It appears to
On Mon, Mar 28, 2005 at 03:10:52PM -0800, Michael G Schwern wrote:
> On Mon, Mar 28, 2005 at 08:42:50AM -0500, Christopher H. Laco wrote:
> > That's another gripe of mine about M::B and create_makefile_pl.
> > It puts the requires AND build_requires in the PREREQ_PM in the
> > Makefile.PL, which I
On Mon, 2005-03-28 at 17:41 -0800, chromatic wrote:
(apologies if this appears multiple times; I had the wrong address
earlier)
> It looks like the first element of interpreter->iglobals is wrong.
Obviously storing a null pointer in there doesn't help. Here's a patch
that fixes things for me.
On Mon, 2005-03-28 at 17:41 -0800, chromatic wrote:
> It looks like the first element of interpreter->iglobals is wrong.
Obviously storing a null pointer in there doesn't help. Here's a patch
that fixes things for me.
Now gdb says:
Breakpoint 1, Parrot_SArray_mark (interpreter=0x103ac920,
pmc=
Michael G Schwern wrote:
On Mon, Mar 28, 2005 at 07:52:22PM -0500, Christopher H. Laco wrote:
Michael G Schwern wrote:
Until such time as there are test_* flags, one should take a pragmatic
view.
And that view is "what is going to cause the least amount of hassle for
those who want to inst
Juerd <[EMAIL PROTECTED]> writes:
> I wonder now if that can just be
>
> my $password = any('a'..'z') x 5;
Wouldn't that generate a junction, and so need a .pick?
my $password = (any('a'..'z') x 5).pick;
Or perhaps just leave it a junction, to use as a generator:
my $any_passw
On Mon, 2005-03-28 at 11:42 +0200, Leopold Toetsch wrote:
> > (gdb) bt
> > #0 0x100b74f0 in pobject_lives (interpreter=0x103ac910, obj=0x35)
> > at src/dod.c:196
> > #1 0x10278d7c in Parrot_SArray_mark (interpreter=0x103ac910,
> > pmc=0x1056c540)
> > at classes/sarray.c:276
>
> At that
On Mon, Mar 28, 2005 at 07:52:22PM -0500, Christopher H. Laco wrote:
> Michael G Schwern wrote:
> >Until such time as there are test_* flags, one should take a pragmatic
> >view.
> >And that view is "what is going to cause the least amount of hassle for
> >those who want to install my module" beca
Michael G Schwern wrote:
Until such time as there are test_* flags, one should take a pragmatic view.
And that view is "what is going to cause the least amount of hassle for
those who want to install my module" because they don't know nor care about
the internal mechanics.
[snip]
Sticking with Ex
On Mon, Mar 28, 2005 at 06:20:32PM -0500, Christopher H. Laco wrote:
> >Its better than just dropping it and having the build fail.
>
> That's a matter of opinion; one I think should be left up to the person
> makeing Build.PL.
That sort of dubious flexibility is well out of the scope of
Module
Christopher H. Laco wrote:
Michael G Schwern wrote:
On Sun, Mar 27, 2005 at 08:32:59PM -0500, Christopher H. Laco wrote:
Along the lines of converting to Module::Build...it went well until I
started doing tests...things that worked now break, probably do to
how they're now run...
t\xsp.
Christopher H. Laco wrote:
Michael G Schwern wrote:
On Mon, Mar 28, 2005 at 08:42:50AM -0500, Christopher H. Laco wrote:
That's another gripe of mine about M::B and create_makefile_pl.
It puts the requires AND build_requires in the PREREQ_PM in the
Makefile.PL, which I won't want; nor do I think i
> "ZL" == Zhuang Li <[EMAIL PROTECTED]> writes:
ZL> Hi, given an array: @a = ('E1', 'E2', ..., 'En');
ZL> Is there an easy way, hopefully one liner, to do the following without a
ZL> loop? If not, will Perl support this in Perl 6?
ZL> $hash->{E1}->{E2}->...->{En} = 1;
i think perl6
Michael G Schwern wrote:
On Mon, Mar 28, 2005 at 08:42:50AM -0500, Christopher H. Laco wrote:
That's another gripe of mine about M::B and create_makefile_pl.
It puts the requires AND build_requires in the PREREQ_PM in the
Makefile.PL, which I won't want; nor do I think it right for everyone.
Ther
This message is largely FYI, and some of its details are only
relevant to Mac OS X users, though the general theme is not.
Following today's release of BBEdit 8.1 text editor, which among its
new features is integrated Subversion support (it had CVS for awhile
already), I have been compelled to
On Mon, Mar 28, 2005 at 08:42:50AM -0500, Christopher H. Laco wrote:
> That's another gripe of mine about M::B and create_makefile_pl.
> It puts the requires AND build_requires in the PREREQ_PM in the
> Makefile.PL, which I won't want; nor do I think it right for everyone.
There is no build_requi
On Monday 28 March 2005 05:48 pm, Craig DeForest wrote:
> The problem with using the units(1) database is that it only deals with
> multiplicative relations -- so, e.g., it won't handle temperature.
[EMAIL PROTECTED]:~$ units
2084 units, 71 prefixes, 32 nonlinear units
Among those "nonlinear unit
On Mon, 2005-03-28 at 17:48, Craig DeForest wrote:
> The problem with using the units(1) database is that it only deals with
> multiplicative relations -- so, e.g., it won't handle temperature.
Well, that's fine. You don't have to get everything from one source.
Larry is right though, units is a
The problem with using the units(1) database is that it only deals with
multiplicative relations -- so, e.g., it won't handle temperature.
Units resolvers are not so hard to come by -- the strategy is to try to break
each compound unit out into a collection of fundamental quantities that
are int
On Mon, 2005-03-28 at 16:00, Larry Wall wrote:
> I've always thought that we should make use of the database of the
> "units" program for standardized names of units. The units database
> has a pretty good list of which units are just differently scaled
> units of the actual underlying fundamenta
At 04:44 PM 3/28/2005, Ron Blaschke wrote:
MrJoltCola wrote:
> At 04:08 PM 3/28/2005, Ron Blaschke wrote:
>> > On the one hand, IMCC doesn't really help you _run_ code, so I'm not
>> > inclined to see it part of libparrot. On the other hand, I haven't
>> > grokked the entire code base organization
According to Ron Blaschke:
> The idea [of parrot01.dll] was mainly stolen from other projects,
> guess it's some sort of convention on Windows. [...] Adding all
> three parts, with dots, will work nicely, too, I guess.
That'd be great. If you get pushback from something that matters,
like an im
MrJoltCola wrote:
> At 04:08 PM 3/28/2005, Ron Blaschke wrote:
>> > On the one hand, IMCC doesn't really help you _run_ code, so I'm not
>> > inclined to see it part of libparrot. On the other hand, I haven't
>> > grokked the entire code base organization, so I could be Greatly
>> > Missing The Po
Hello all,
I am not even 100% sure these are bugs. I assume I should be able to do
this, but I dont know for sure.
These two test groups (taken from t/builtins/io/io_in_for_loop.t) below
will fail with the error:
pugs: tempfile: hGetLine: illegal operation (handle is closed)
it seems th
At 04:08 PM 3/28/2005, Ron Blaschke wrote:
> On the one hand, IMCC doesn't really help you _run_ code, so I'm not
> inclined to see it part of libparrot. On the other hand, I haven't
> grokked the entire code base organization, so I could be Greatly
> Missing The Point.
> On the gripping hand, if
Chip Salzenberg wrote:
> According to Ron Blaschke:
>> - The parrot library should be named C and
>> C on Windows
> OK, but will Windows allow delimiter(s) on the DLL name? Without
> them, there's an ambiguity (is "parrot110.dll" 1.10 or 11.0?).
> Also, Parrot release numbers currently have thr
On Mon, Mar 28, 2005 at 01:30:14PM -0700, Craig DeForest wrote:
: Yow -- units would be extra cool for perl6: I know of no other language that
: has units support built in. It would go a long way toward making perl6 the
: language of choice for students in the physical sciences...
Well, yes. I
On Mon, Mar 28, 2005 at 03:40:14PM -0500, Aaron Sherman wrote:
: Now you can ask for whatever you like:
:
: say "We have {â.new $money}â"
:
: Though you might have some snazzy way of saying that.
Just by the by, that's illegal syntax. Methods with arguments
require parens. You could, how
On Mon, 2005-03-28 at 15:07, Rod Adams wrote:
> Markus Laire wrote:
> > So do you actually envision perl6 to allow a junction of units on
> > numbers? This would have huge implications, depending on what exactly
> > is possible with these units...
> > # import proper MMD-subs for + - * etc.
Yow -- units would be extra cool for perl6: I know of no other language that
has units support built in. It would go a long way toward making perl6 the
language of choice for students in the physical sciences...
The perl5 CPAN modules already have a pretty good unit system that could be
ported
On Mon, Mar 28, 2005 at 11:53:07AM -0500, Chip Salzenberg wrote:
: According to Larry Wall:
: > On Fri, Mar 25, 2005 at 07:38:10PM -, Chip Salzenberg wrote:
: > : And might I also ask why in Perl 6 (if not Parrot) there seems to be
: > : no type support for strings with known encodings which ar
Since #parrot has many Parrot people talking about Parroty things all
the time, it's been suggested that we log #parrot somewhere. The sad
thing about IRC logs, however, is that they're 99% dross and only 1%
precious metals. Of course that 1% is often uniquely valuable.
So I'd like to suggest th
On Mon, 2005-03-28 at 13:38, Luke Palmer wrote:
> Your "list mod" idea is interesting, though. I fear that adding too
> many list operators will start to make us look like Haskell, where we
> have *extremely* expressive single lines that take an hour to write and
> an hour to read (I call this "c
Markus Laire wrote:
Larry Wall wrote:
Now, I admit that I've handwaved the tricksy bit, which is, "How do
you know, Larry, that substr() wants 5`Codes rather than 5`Meters?
It's all very well if you have a single predeclared subroutine and
can look at the signature at compile time, but you wrote th
Immediately after asking this:
> How is Perl 6 supposed to implement its idea of %MY:: if there's no
> lexical scoping other than in .subs, and there are no nested .subs?
... I read the *rest* of the IRC log, and ... well, let's just say I
feel a bit silly for not having read the whole transcript
Quoting #parrot:
<@autrijus> when I say ".local pmc foo", what happens at INS?
< leo> nothing - that just declares the name "foo" being a P symbol
<@autrijus> and its scope is... .sub ?
< leo> yep, .sub / .end
<@autrijus> so there's no notion of lexical scopes?
<@autrijus>
After a IRC meeting with Leo, I've outlined my roadmap of how to make the three
compiler backends in Pugs to work in concert to provide a much faster evaluator:
http://use.perl.org/~autrijus/journal/23890
Note that existing code in the Eval monad need not be rewritten; also
Pugs will still ru
According to Larry Wall:
> On Fri, Mar 25, 2005 at 07:38:10PM -, Chip Salzenberg wrote:
> : And might I also ask why in Perl 6 (if not Parrot) there seems to be
> : no type support for strings with known encodings which are not subsets
> : of Unicode?
>
> Well, because the main point of Unicod
Mon Mar 28 12:13:41 EST 2005 Mark Stosberg <[EMAIL PROTECTED]>
* add PORTING_HOWTO to darcs.
Mon Mar 28 12:19:27 EST 2005 Mark Stosberg <[EMAIL PROTECTED]>
* add request for specific example subroutine signature porting
Mon Mar 28 12:24:10 EST 2005 Mark Stosberg <[EMAIL PROTECTED]>
* enh
Mon Mar 28 12:13:41 EST 2005 Mark Stosberg <[EMAIL PROTECTED]>
* add PORTING_HOWTO to darcs.
Mon Mar 28 12:15:36 EST 2005 Mark Stosberg <[EMAIL PROTECTED]>
* add p5 -> p6 hash sigil change
New patches:
[add PORTING_HOWTO to darcs.
Mark Stosberg <[EMAIL PROTECTED]>**20050328171341]
<
> {
a
Juerd writes:
> What if instead of
>
> my @copy = @array;
> while (my @chunk = splice @copy, 0, $chunksize) {
> ...
> } # ^1
Well, I for one never write that. I very seldom use splice.
>
> we could just write
>
> for @array [/] $chunksize -> @chunk { ... }
Well, we c
mod_parrot 0.2 is now available from http://www.smashing.org/mod_parrot or
from SVN at http://svn.perl.org/parrot-modules/mod_parrot.
major changes include support for parrot 0.1.2 (phoenix), the beginnings
of a thread-safe interpreter pool, support for more apache hooks,
updated documentation, an
It was a matter of time, of course, after my last thread.
How often do we want chunks of a string or list? And how often do we
abuse a temporary copy and substr/splice for that?
What if instead of
my @copy = @array;
while (my @chunk = splice @copy, 0, $chunksize) {
...
} # ^
According to Ron Blaschke:
> - Parrot should be told during Configure to be built static
> or dynamic (shared); it should probably be dynamic on most systems
Yes.
> - The parrot library should be named C and
> C on Windows
OK, but will Windows allow delimiter(s) on the DLL name? Without
them,
Juerd skribis 2005-03-28 16:44 (+0200):
> splice @foo, $_, 1 given first { @foo[$_] ~~ 15 }, [EMAIL PROTECTED];
> @foo [-] 15; # whoa!
Note: unfair comparison. The equal thing would be [-]=.
In fact, this illustrates the problem even better, because to get
@foo [-] 15 without [-], you n
The discussion about x/xx made me wonder. We have this table:
string list
x xx
~ ,
And we also have this table:
string number
~ +
-
x *
eq ==
But there is overlap between the two tables:
string number list
x
Some experiments - might be quite wrong.
leo
lazy.tgz
Description: GNU Unix tar archive
Juerd skribis 2005-03-28 16:05 (+0200):
> In the context of x, it makes even more sense. Especially if you
> consider, for example, creating a random password:
> my $password = { any('a'..'z').pick } x 5;
I wonder now if that can just be
my $password = any('a'..'z') x 5;
(No reason to no
Luke Palmer skribis 2005-03-28 6:57 (-0700):
> We were discussing on #perl6, and thought that the feature:
> sub foo () {
> say "Blech";
> }
> { foo() } xx 5;
In the context of x, it makes even more sense. Especially if you
consider, for example, creating a random password:
Leo~
On Mon, 28 Mar 2005 12:22:29 +0200, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
> > 5) infix method signature change:
>
> >METHOD PMC* add( [INTERP, SELF,] PMC* rhs, PMC ´*dest) {
> > if (!dest)
> > dest = pmc_new(INTERP, SELF-
We were discussing on #perl6, and thought that the feature:
sub foo () {
say "Blech";
}
{ foo() } xx 5;
Would be useful. Since it is dwimmery, and you wouldn't want the
closure to execute if you didn't know it was there, we decided that it
would probably be best if this were
Larry Wall wrote:
> ... SKIP ...
Okay, that looks scary, but if as in my previous message we define
"chars" as the highest Unicode level allowed by the context and the
string, then we can just write that in some notation resembling:
substr($a, 5`Chars, 10`Chars);
or whatever notation we end up
Michael G Schwern wrote:
There is a create_makefile_pl option (see Module::Build::Compat) which
does a fair job of creating a Makefile.PL functionally equivalent to
your Build.PL. It comes in various flavors from passthrough (where it
writes a Makefile which simply calls Module::Build functions) t
Michael G Schwern <[EMAIL PROTECTED]> writes:
> There is a create_makefile_pl option (see Module::Build::Compat) which
> does a fair job of creating a Makefile.PL functionally equivalent to
> your Build.PL.
I'll definitely give it a try. Thanks.
-- Johan
Matt Diephouse <[EMAIL PROTECTED]> wrote:
> This patch (a) adds comments before each subroutine describing its
> parameters, its return values, and what it does, and (b) allows
> unbalanced {} to be used inside of strings and comments in PMC code.
Thanks, applied.
leo
Nick Glencross <[EMAIL PROTECTED]> wrote:
> This patch makes some small cosmetic changes to the md5 library, harness
> and tests (comments and formatting).
Thanks, applied.
leo
On Mon, Mar 28, 2005 at 01:04:45PM +0200, Johan Vromans wrote:
> Michael G Schwern <[EMAIL PROTECTED]> writes:
>
> > Switch to Module::Build anyway.
>
> I would love to.
> But the last time I submitted a M::B-only module I was 'kindly urged'
> to provide a Makefile.PL as well, factually defeating
# New Ticket Created by Nick Glencross
# Please include the string: [perl #34592]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=34592 >
Folks,
This patch makes some small cosmetic changes to the md5 library, harness
and
Michael G Schwern <[EMAIL PROTECTED]> writes:
> Switch to Module::Build anyway.
I would love to.
But the last time I submitted a M::B-only module I was 'kindly urged'
to provide a Makefile.PL as well, factually defeating the advantages
of using M::B.
Maintaining both a Build.PL and a Makefile.P
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> 5) infix method signature change:
>METHOD PMC* add( [INTERP, SELF,] PMC* rhs, PMC ´*dest) {
> if (!dest)
> dest = pmc_new(INTERP, SELF->vtable->base_type);
> ...
> return dest;
>}
> If the destination PMC is passed in, i
Chromatic <[EMAIL PROTECTED]> wrote:
> The current CVS HEAD has failed for about a week or so at the point
> where Parrot tries to generate its configuration library.
Strange.
> (gdb) bt
> #0 0x100b74f0 in pobject_lives (interpreter=0x103ac910, obj=0x35)
> at src/dod.c:196
> #1 0x10278d7c
Ron Blaschke <[EMAIL PROTECTED]> wrote:
> After
> Failed Test Stat Wstat Total Fail Failed List of Failed
> ---
> t\op\spawnw.t2 512 32 66.67% 2-3
Great.
[ ... the plan ]
> Comments are highly ap
Cory Spencer <[EMAIL PROTECTED]> wrote:
> ---354891615-125901741-966306=:18075
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
> I've been writing a Lisp implementation on top of Parrot for the last
> several months (and I'm just about at the point where I'm ready to unleash
> it
Matt Fowles <[EMAIL PROTECTED]> wrote:
> Leo~
> On Sun, 27 Mar 2005 16:37:41 +0200, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>> 5) infix method signature change:
>>
>>METHOD PMC* add( [INTERP, SELF,] PMC* rhs, PMC ´*dest) {
>> if (!dest)
>> dest = pmc_new(INTERP, SELF->vtable->b
Bob Rogers <[EMAIL PROTECTED]> wrote:
> ... If the prefix is disabled via
> PARROT_TEST, this fixes the immediate problem:
> [EMAIL PROTECTED]> PARROT_TEST=1 perl -Ilib t/dynclass/foo.t
> 1..1
> ok 1 - abs
> [EMAIL PROTECTED]>
> But shouldn't "make test" do this by default? Oth
Bob Rogers <[EMAIL PROTECTED]> wrote:
> IMHO, one can have too much overloading. It seems cleaner to
> distinguish between "+, the (sometimes overloaded) HLL operator" and
> "add, the Parrot addition operator" so that compiled code can opt out of
> the overloading when the compiler knows that it
74 matches
Mail list logo