How about we implement some way to peer into coderefs? Maybe just on the
top level, with attributes, or maybe a syntax tree (probably not).
Because here, what both arguments (in the discussion) are missing, is the
ability to look at their arguments' (the uh, ones you pass in) internal
struct
I have traced the problems with Josh's deep stack pushp/popp test to two
problems with the garbage collector:
1) Strings pointed to by pmc->cache.struct_val are not marked as live
2) If a dod run is initiated while a pmc is being created, it will be freed
as nobody points to it yet
Since both th
Aaron Sherman:
> This just brought something to mind when I re-read it. I was thinking
> about how this would transform back into Perl, and I thought... gee, you
> can't do that easily because you're taking the result of a block, and
> Perl can only do that via function call or eval,
Or do, whic
Oh, yay. Orange tinderboxen rule, only because I haven't seen that much
orange in quite awhile. :)
Anyways, I looked into the bug. There's actually a few problems...First,
is that perlstrings use the structval to store the buffer, and so it gets
missed by the GC. The patch below fixes perlstring
Hm...so I'm guessing my patch is the 'quick hacks' you tried and found
worked?
I agree my solution is a bit hackish. But I'm not sure how else to keep
them. The only other solution I can think of is to make a 'GC linked
list', which we put items on to immediately after construction, and take
them
>Regardless, this patch does make 'make test' happy again, and should be
>safe to apply apply, as long as we don't forget about the afore-mentioned
>caveat, which will probably come back to bite us in the future if we don't
>take care of it. I wonder how many more GC bugs are lurking, waiting for
Wouldn't it be nice if you could do:
class Foo {
...
&{intern('{}')} := method ($self: $key) is lvalue {
...
}
}
So, later, you could do:
$obj = Foo.new;
$obj{something} = $something_else;
ie, overriding hash lookups, array lookups, whatever. (I'm using a
Lispish 'intern
Piers Cawley:
> ie, overriding hash lookups, array lookups, whatever.
Ah, you want C#/Python indexers, you do. So do I.
--
"If that makes any sense to you, you have a big problem."
-- C. Durance, Computer Science 234
>Try out bug #465 for size, as it's my current holdup (for some reason it
>didn't forward to p6i). In this case a restore instruction sends the
>parrot runtime into a loop from which it never (28 hours later)
>recovers. It's probably Yet Another Garbage Collection bug or related to
>the stu
Clinton
The following patch seems to fix both these problems. It makes some slight
changes to the logic, so should be considered a temporary fix until Dan has
time to take a look at the code.
--
Peter Gibbs
EmKel Systems
Index: resources.c
===
Simon Cozens <[EMAIL PROTECTED]> writes:
> Piers Cawley:
>> ie, overriding hash lookups, array lookups, whatever.
>
> Ah, you want C#/Python indexers, you do. So do I.
Um... is that what you call 'em. Actually, you can already do
'use overload q|%{}|', to sort of do this...
--
Piers
"It i
At 12:59 PM + 3/28/02, Piers Cawley wrote:
>Wouldn't it be nice if you could do:
>
>class Foo {
> ...
>
> &{intern('{}')} := method ($self: $key) is lvalue {
> ...
> }
>}
>
>So, later, you could do:
>
>$obj = Foo.new;
>
>$obj{something} = $something_else;
>
>ie, overriding
On Wed, 2002-03-27 at 19:46, Michel J Lambert wrote:
> > Macros could add something to Perl, but I don't see why having a macro
> > return a string instead of looking and acting like a subroutine would be
> > a bad thing. In fact, as I pointed out before, you can do almost all of
> > the scoping
At 07:10 AM 3/28/2002 -0500, Clinton A. Pierce wrote:
>Try out bug #465 for size, as it's my current holdup (for some reason it
didn't >forward to p6i). In this case a restore instruction sends the
parrot runtime into a >loop from which it never (28 hours later)
recovers. It's probably Yet A
On Thu, 2002-03-28 at 10:19, Aaron Sherman wrote:
> Here's what I suggest as a compromise:
>
> macro forall ($iterator, $list, $block) {
> my @ltmp = ($list);
> foreach $iterator -> @ltmp $block
> }
> forall{$var}{@list}{{print;}};
>
> Where the parser sees "macro NAME P
I forgot to send this patch last night. I was browsing through the code and
noticed these "return NULL"s for what I think are probably really fatal
conditions.
Here's a patch which switches them to internal_exceptions. Hopefully i'm
not missing the point here.
--Josh
Index: chartype.c
==
When you come across bugs, or there are things that should be
implemented but aren't, could folks make entries in the perl 6
bugtracking system so we don't lose track? http://bugs6.perl.org.
Thanks.
(And don't feel like any code I've written is sacrosanct--it's not,
and I'm happy to have it y
Should we be using bugs6 for all patches?
--Josh
At 15:04 on 03/28/2002 EST, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> When you come across bugs, or there are things that should be
> implemented but aren't, could folks make entries in the perl 6
> bugtracking system so we don't lose track? ht
At 3:38 PM -0500 3/28/02, Josh Wilmes wrote:
>Should we be using bugs6 for all patches?
Certainly not required--I want the patches more than I want people to
jump through any extra hoops. I won't object if people do, though. :)
>At 15:04 on 03/28/2002 EST, Dan Sugalski <[EMAIL PROTECTED]> wrote
Are, as mentioned, Unicode and keyed aggregates. Dan's volunteered to
work on keyed aggregates, which leaves me to work on Unicode. I hope to
have something put together over the weekend.
--
Jeff <[EMAIL PROTECTED]>
On Thu, Mar 28, 2002 at 06:50:06PM -0500, Jeff wrote:
> Are, as mentioned, Unicode and keyed aggregates. Dan's volunteered to
> work on keyed aggregates, which leaves me to work on Unicode. I hope to
> have something put together over the weekend.
I have some stuff done on keyed aggregates. Nothi
This should enable writing tests which call parrot C functions directly,
which could be useful for increasing coverage to things which aren't easy to
call via opcodes.
--
Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org
Index: Makefile.in
===
[EMAIL PROTECTED]:
# This should enable writing tests which call parrot C
# functions directly,
# which could be useful for increasing coverage to things which
# aren't easy to
# call via opcodes.
And it will shatter Windows. Don't even think about committing it.
--Brent Dax <[EMAIL PROTECTED
Could you be specific? I was careful to do things identically to
Configure.pl (because we lack any common code I can use right now- that's
another problem we need to solve)
--Josh
At 22:03 on 03/28/2002 PST, "Brent Dax" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED]:
> # This should enable w
Anyone else like to keep generated .c files around for stepping
through with gdb? (Does this work with Windows make?)
--
Gimme a job! http://foxglove.dnsalias.org/~sfink/job.html
C, perl, networking, performance optimization, Java, XML.
Index: Makefile.in
===
Is the new assembler going to land soon? If not, this has been helpful
to me.
--
Gimme a job! http://foxglove.dnsalias.org/~sfink/job.html
C, perl, networking, performance optimization, Java, XML.
Index: assemble.pl
===
RCS file: /
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
# Could you be specific? I was careful to do things identically to
# Configure.pl (because we lack any common code I can use right
# now- that's
# another problem we need to solve)
libparrot.a isn't even the right name on Windows, and the target itsel
I didn't commit this directly in case string_ord isn't supposed to be
doing what it's doing. (It always seemed kind of odd to me to have a
positional ord -- why not call that index? But it's extremely useful.)
And I'd have to reread Jarkko's Unicode primer to have any clue
whether I'm using the te
Returning NULL seems rather harsh. Is this the right way?
--
Gimme a job! http://foxglove.dnsalias.org/~sfink/job.html
C, perl, networking, performance optimization, Java, XML.
Index: classes/perlundef.pmc
===
RCS file: /home/perlc
OK- i assumed that target was OK, since it was in the makefile. I'll
discuss this with you some more- perhaps this is the time to abstract away
some of this building-things stuff.
--Josh
At 22:23 on 03/28/2002 PST, "Brent Dax" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] [mailto:[EMAIL PR
Steve Fink:
# Returning NULL seems rather harsh. Is this the right way?
#
# --
# Gimme a job! http://foxglove.dnsalias.org/~sfink/job.html
# C, perl, networking, performance optimization, Java, XML.
#
# Index: classes/perlundef.pmc
#
When you call pmc_new, the init() routine is run before the PMC is
anchored to the root set. This is a problem for things like
aggregates, because they are likely to want to allocate a big Buffer
during initialization. And disabling GC entirely just feels wrong --
especially with pmc_new_sized, it
On Thu, Mar 28, 2002 at 10:34:48PM -0800, Brent Dax wrote:
> Steve Fink:
> # Returning NULL seems rather harsh. Is this the right way?
> #
> # Index: classes/perlundef.pmc
> # ===
> # RCS file: /home/perlcvs/parrot/classes/perlundef.p
At 10:30 PM 3/28/2002 -0800, Steve Fink wrote:
>When you call pmc_new, the init() routine is run before the PMC is
>anchored to the root set. This is a problem for things like
>aggregates, because they are likely to want to allocate a big Buffer
>during initialization. And disabling GC entirely ju
At 10:50 PM 3/28/2002 -0800, Steve Fink wrote:
> > The string_* functions treat NULL and an empty string as equivalent, so
> > this saves time in case we don't actually do anything with the string.
>
>Okay, I just checked and you're right. I ran into it because not
>everything goes through the str
Whatever the answer is, it better end up in a PDD :)
--Josh
At 2:00 on 03/29/2002 EST, Melvin Smith <[EMAIL PROTECTED]> wrote:
> At 10:50 PM 3/28/2002 -0800, Steve Fink wrote:
> > > The string_* functions treat NULL and an empty string as equivalent, so
> > > this saves time in case we don't a
On Fri, Mar 29, 2002 at 02:00:16AM -0500, Melvin Smith wrote:
> At 10:50 PM 3/28/2002 -0800, Steve Fink wrote:
> >> The string_* functions treat NULL and an empty string as equivalent, so
> >> this saves time in case we don't actually do anything with the string.
> >
> >Okay, I just checked and yo
FWIW, I've already submitted a patch which fixes this bug. I'm also about
to submit a patch which fixes it in a slightly better way, along with a
few of other (mostly GC) bugs I've tracked down tonight with the help of
clint's wonderfully abusive code.
The original email was:
http:[EMAIL PROTECTE
> > At one point I heard someone in charge say that NULLs were treated
> > as invalid internal state and a routine was not obligated to check for
> > NULL registers.
> >
> > If this is no longer the case, or never was, then I was either mistaken or
> > missed the email. Especially since I was arg
On Fri, Mar 29, 2002 at 01:54:00AM -0500, Melvin Smith wrote:
> At 10:30 PM 3/28/2002 -0800, Steve Fink wrote:
> >When you call pmc_new, the init() routine is run before the PMC is
> >anchored to the root set. This is a problem for things like
> >aggregates, because they are likely to want to allo
At 2:14 on 03/29/2002 EST, Melvin Smith <[EMAIL PROTECTED]> wrote:
> Boy a searchable archive would be nifty right about now. Might be
> time for me to slurp the archive down to a local copy.
Try this:
http://www.mail-archive.com/perl6-internals@perl.org/
--Josh
At 02:25 AM 3/29/2002 -0500, Josh Wilmes wrote:
>Try this:
>
>http://www.mail-archive.com/perl6-internals@perl.org/
Ah great! Last time I tried this it was dead. Must have
been a temporary thing.
-Melvin
On Fri, Mar 29, 2002 at 02:14:09AM -0500, Michel J Lambert wrote:
> FWIW, I've already submitted a patch which fixes this bug. I'm also about
> to submit a patch which fixes it in a slightly better way, along with a
> few of other (mostly GC) bugs I've tracked down tonight with the help of
> clint
>That's what confused me too. But now I think that must have been for
>PMC registers only, not string registers.
From the archive:
So speaketh Dan.
>I seem to remember someone unpatching a couple of if (NULL == string)
>statements recently. I'll be blunt and say: DON'T DO THAT. Defens
44 matches
Mail list logo
