Matt Fowles <[EMAIL PROTECTED]> wrote:
> Leo~
> Why bother with the IS_NULL check if we have the "n_" variant already?
> Why not have one option unconditionally use the destination pmc and
> the other unconditionally create a new destination pmc?
I think, we can just have one method with the sam
Darren Duncan <[EMAIL PROTECTED]> writes:
> 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
Craig DeForest wrote:
Yet another point: there are plenty of non-obvious reductions that people
worry about, such as "N m" -> "J" (energy) but "m N" -> "m N" (torque); but
it's probably not worth worrying about such things: if the coder knows that
s/he wants a torque, s/he should be able to ask f
On Mon, Mar 28, 2005 at 08:35:34PM -0800, Michael G Schwern wrote:
> > Whether things that are required for *testing* belong in
> > build_requires really depends on whether you view testing as an
> > integral part of the build process. This is something that is likely
> > to depend on the *builder
Chip Salzenberg wrote:
> 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 some
Chip Salzenberg wrote:
As for the autrijus/leo IRC event: Much of it seemed to be things that
autrijus Really Needed To Know, but which without context would not
likely make a good general informational message. If I'm wrong about
that, I invite autrijus or leo to summarize what was discussed
Cory Spencer <[EMAIL PROTECTED]> wrote:
> 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.
When I'm investigating GC bugs, the usual procedure is like this:
-
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
[ lazy.tgz ]
> Some experiments - might be quite wrong.
That might have been a bit too terse. In yesterday's IRC session,
Autrijus asked about another missing Parrot feature: lazy evaluation. I
had experimented with it a bit and the outcome is in the ta
Chromatic <[EMAIL PROTECTED]> wrote:
> -(INTVAL)IGLOBALS_CLASSNAME_HASH, classname_hash);
> +(INTVAL)IGLOBALS_CLASSNAME_HASH, interpreter->class_hash);
Oouch. Good catch, thanks - applied.
leo
Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> According to Ron Blaschke:
>> - After I changed the linkage, some dynclasses failed, during access
>> of C. No surprise, as the array is only
>> C<#define PARROT_MAX_CLASSES 100>
>> long. After I changed it to 1000, the tests passed. Why gets no one
# New Ticket Created by FranÃois PERRAD
# Please include the string: [perl #34605]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=34605 >
After Dan's response concerning "Parrot_Exec_OS_Command interface ?".
He says : Thi
According to Ron Blaschke:
> Chip Salzenberg wrote:
> > How many variables need to be exported currently? I'd consider it an
> > API feature if there were no exported variables whatsoever ...
>
> Let's see...
> Parrot_base_vtables
> pio_stdio_layer
> op_jit
> yyin
>
> I guess that's it.
That's
According to Leo Toetsch:
> Chip Salzenberg <[EMAIL PROTECTED]> 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 Th
Piers Cawley writes:
> 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
Below inline attached is a scheme for an abstraction layer around
calling conventions.
Comments welcome,
leo
Parrot Calling Conventions
1) Rational
Calling conventions and opcodes (and of course the semantics of these)
define the ABI of the Parrot VM. Any change in the ABI creates
incompatibili
Zhuang Li wrote:
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
Zhuang Li writes:
> 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;".
Yeah, like this:
%hash{dims @a} = (1) xx Inf;
> What I'd r
Stevan Little writes:
> 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 o
Michael G Schwern wrote:
[snip]
Sticking with ExtUtils::MakeMaker. :-)
[But where's the fun in that.]
I know you're joking, but you've flipped my rant switch.
I was. But at some level, I'm not.
If after changing one dist to use M::B I have more issues than I started
with [which was just checking
Aaron Sherman writes:
> 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
>
Larry Wall wrote:
Yeah, I agree. How 'bout we go with something like you have to *
the actual hash (if it's the first thing) to make it look like a
list of pairs to the parser, and we can just get rid of 3 there.
I'm not sure if 3) was superflous depending on the definition of "non-pair".
Did you
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, my HP48 pocket calculator used to have it :)
--
TSa (Tho
Jeff Horwitz <[EMAIL PROTECTED]> wrote:
> 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.
Steadily evolving, great.
> major changes include support for parrot 0.1.2 (phoenix), the beginnings
> of a thread-safe
Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> OK, no point in dividing that. It's been suggested to create a
> libparrotvm at some point, with PBC support but no imcc/pir/ast(?);
> but given our target languages, I don't see that it would get much
> usage...?
No eval-like functionality. OTOH it c
According to Leo Toetsch:
> Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> > It's been suggested to create a libparrotvm at some point, with
> > PBC support but no imcc/pir/ast(?); but given our target
> > languages, I don't see that it would get much usage...?
>
> No eval-like functionality. OTOH i
On Tue, 29 Mar 2005, Leopold Toetsch wrote:
> Jeff Horwitz <[EMAIL PROTECTED]> wrote:
> > 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.
>
> Steadily evolving, great.
>
> > major changes include support for
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...
Frink is built around this idea: http://c2.com/cgi/wiki?FrinkL
Luke Palmer skribis 2005-03-29 6:14 (-0700):
> method iterate () {
> for (@.objs) {
> .process($_); # oops
> }
> }
There is an alarming similarity with
for (@hashes) {
.($_)
}
Which doesn't quite use $self! .<>, .[], .{} are method calls, vi
On Tue, Mar 29, 2005 at 06:38:31PM +0200, Juerd wrote:
(B: Luke Palmer skribis 2005-03-29 6:14 (-0700):
(B: > method iterate () {
(B: > for (@.objs) {
(B: > .process($_); # oops
(B: > }
(B: > }
(B:
(B: There is an alarming similarity with
(B:
(B:
Luke Palmer wrote:
So if you want things modified, you'd have to pass in a reference.
Arrays and hashes would not generally have this restriction, since we
pass references of those guys anyway.
But I would really like to see a declaration of any possible modification
in the interface of a sub. Othe
Leopold Toetsch wrote:
One thing still missing is to retrieve the current namespace inside a
subroutine, which will be in RSN, e.g.:
$P0 = interpinfo .INTERPINFO_CURRENT_NAMESPACE
Actually it is:
$P0 = interpinfo .INTERPINFO_CURRENT_SUB
ns = $P0."get_name_space"()
See the new tests in namespa
On Tue, 2005-03-29 at 11:38, Juerd wrote:
> Luke Palmer skribis 2005-03-29 6:14 (-0700):
> > method iterate () {
> > for (@.objs) {
> > .process($_); # oops
> > }
> > }
[...]
> $_ is the topic, and I think that if we have two topics, Perl gets as
> convoluted
Larry Wall skribis 2005-03-29 9:27 (-0800):
> and write _.method, which is of dubious merit. Or we could use `<>,
> `[], `(), and `method if we don't use ` for qx. I daresay `method
> would probably be used more than qx for many styles of programming.
Hey, look at that, backticks again :)
If t
Tue Mar 29 09:23:05 EST 2005 Mark Stosberg <[EMAIL PROTECTED]>
* add modules/README to darcsworld
I see several other files that are in SVN, that didn't show
up in darcs when I sync'ed this morning.
In particular, there are several more 'Algorithm-*' modules in SVN now.
Maybe y
Currently the configure script uses the presence of a perl module
(Term::ReadLine::Gnu) and a hard coded list of platforms to decide if
ghc has Readline and Posix support. This is fragile and often wrong.
This patch asks ghc-pkg which packages are supported and passes that
down to the script that
On Mar 28, 2005, at 4:21 PM, Randy W. Sims wrote:
I think someone had proposed a year or two ago that there should be a
test_requires options and I argued against it. Now, I think maybe it
was a good idea; especially, since the number of extra testing modules
being used have increased a lot over
"Michael G Schwern" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Tue, Mar 22, 2005 at 06:28:21PM +, Adrian Howard wrote:
>> PS "O'Reilly will have a small book soon" ?
>
> Oh yeah, that's the developer's testing notebook Ian Langworth and
> chromatic
> are working on.
>
# New Ticket Created by FranÃois PERRAD
# Please include the string: [perl #34606]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=34606 >
With this small patch, parrot.exe is installed.
Today, the file MANIFEST.generated
Paul Seamons wrote:
To sum up...
If you are in a method then you get .method and it always works even if $_ is
rebound to something else.
I also have problems to perceive .method beeing bound to $_ from a
typing point of view: $_ is a dynamic variable in the runtime
environment, while the method i
Leopold Toetsch wrote:
Cory Spencer <[EMAIL PROTECTED]> wrote:
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.
Running valgrind (on supported platforms, obvious
> -Original Message-
> From: Luke Palmer [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 29, 2005 5:43 AM
> To: Zhuang Li
> Cc: Jeff Yoak; fwp@perl.org; perl6-language@perl.org
> Subject: Re: Unknown level of hash
>
> Zhuang Li writes:
> > Yes. I think it's both useful and fun. I was th
On Tue, Mar 29, 2005 at 09:04:54AM -0500, Christopher H. Laco wrote:
> I was. But at some level, I'm not.
> If after changing one dist to use M::B I have more issues than I started
> with [which was just checking the syntax of my manually edited
> META.yml], then there's no reason to move all of
On Tue, Mar 29, 2005 at 11:05:28AM -0500, Robert wrote:
> "Tests let you know, right away, when they're screwed up your code"
>
> Should be: Tests let you know, right away, when they've screwed up your
> code
>
> or
>
> Should be: Tests let you know, right away, when they're are screwing up yo
Nick Glencross wrote:
The DOD certainly has a few things flagged up, which I'm going to
quickly investigate to see if they are serious or not...
I've learned alot about DOD since earlier (and watched telly). Not as
straightforward as I thought it would be to find if these traces should
be consid
Nick Glencross wrote:
I've learned alot about DOD since earlier (and watched telly). Not as
straightforward as I thought it would be to find if these traces should
be considered serious or not (I would say any logic based on unitialised
values will bite one day!).
Ok, now I understand. This is i
On Mar 28, 2005, at 6:21 PM, Randy W. Sims wrote:
I think someone had proposed a year or two ago that there should be a
test_requires options and I argued against it. Now, I think maybe it
was a good idea; especially, since the number of extra testing modules
being used have increased a lot over
Thomas Sandlaà writes:
> Luke Palmer wrote:
> >So if you want things modified, you'd have to pass in a reference.
> >Arrays and hashes would not generally have this restriction, since we
> >pass references of those guys anyway.
>
> But I would really like to see a declaration of any possible modif
# New Ticket Created by Peter Sinnott
# Please include the string: [perl #34608]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=34608 >
Moving the declaration of s up to the top of the block so declarations
are grouped to
On Tue, Mar 29, 2005 at 04:43:30PM -0600, Ken Williams wrote:
> I think there's one really good argument in favor of splitting it out
> and one really good argument against.
>
> In favor: if we knew the subset of build_requires that were actually
> needed for testing, then it would be easier for
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Mon, 28 Mar 2005 11:27:58 +0200
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 additio
Michael G Schwern wrote:
On Tue, Mar 29, 2005 at 04:43:30PM -0600, Ken Williams wrote:
I think there's one really good argument in favor of splitting it out
and one really good argument against.
In favor: if we knew the subset of build_requires that were actually
needed for testing, then it woul
On Mar 29, 2005, at 8:38 AM, Luke Palmer wrote:
Hmm... I believe that the behavior in this case is undefined. It sure
would be nice if it worked, but you see:
for =$fh -> $line { ... }
Evaluates `=$fh` in list context. In an eager world, this eats up the
whole file in one go. In the ideal la
Stevan Little writes:
>
> On Mar 29, 2005, at 8:38 AM, Luke Palmer wrote:
> >Hmm... I believe that the behavior in this case is undefined. It sure
> >would be nice if it worked, but you see:
> >
> >for =$fh -> $line { ... }
> >
> >Evaluates `=$fh` in list context. In an eager world, this eat
On Tue, Mar 29, 2005 at 08:33:48PM -0500, Randy W. Sims wrote:
> A quickie sample implementation to add more meat. I didn't apply yet
> mainly because I'm wondering if we shouldn't bail and do a complete
> roll-back (eg. don't generate a Build script) if there are any failed
> requirements. Or s
I noticed a curious inconsistency with our /modules collection of
ported CPAN modules wherein each of their Makefile.PL is written in
Perl 5 and invokes the Perl 5 Makefile.PL, but everything else in the
ported distro is written in Perl 6, both the modules and the test
suite.
I propose that sa
Michael G Schwern wrote:
On Tue, Mar 29, 2005 at 08:33:48PM -0500, Randy W. Sims wrote:
A quickie sample implementation to add more meat. I didn't apply yet
mainly because I'm wondering if we shouldn't bail and do a complete
roll-back (eg. don't generate a Build script) if there are any failed
r
On Tue, Mar 29, 2005 at 08:37:02PM -0700, Luke Palmer wrote:
: Stevan Little writes:
: >
: > On Mar 29, 2005, at 8:38 AM, Luke Palmer wrote:
: > >Hmm... I believe that the behavior in this case is undefined. It sure
: > >would be nice if it worked, but you see:
: > >
: > >for =$fh -> $line {
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> +void freeze(visit_info *info) {
> +IMAGE_IO *io = info->image_io;
> +io->vtable->push_integer(INTERP, io, PMC_int_val(SELF));
> +STRING * s = string_from_cstring(INTERP, PMC_data(SELF),
> PMC_int_val2(SELF)/BITS
Bob Rogers <[EMAIL PROTECTED]> wrote:
> I guess I was hoping for access to a lower-level mechanism. FWIW,
> Common Lisp is an example of a dynamic HLL that doesn't allow certain
> ops to be overloaded (at least not directly).
Overloading is a syntactic construct that the compiler supports (or
no
François" PERRAD <[EMAIL PROTECTED]> wrote:
> --- data.pl.orig 2005-02-21 11:56:08.0 +0100
> +++ data.pl 2005-03-19 11:53:30.0 +0100
^^^
Please provide one patch for #34605 and #34606, diffed from Parrot root
directory one directory outside, so that they can be ap
60 matches
Mail list logo
