store_global/find_global ops are in. Added storage of PMCs to PerlHash.
Sample:
new P0, PerlString
set P0, "Melvin\n"
store_global "first", P0
new P0, PerlString
set P0, "Smith\n"
store_global "last", P0
find_global P1, "first"
find_global P2, "last"
print P1
print P2
end
-Melvin
I've finished a new version of Configure which splits up the giant
script into a bunch of small files and moves all of Configure's files
into a new config/ directory. I just need a few guinea pigs^W^Wtesters
to make sure it works okay on various systems, especially systems with
hint files.
I wou
Clinton A. Pierce:
> No line number, no context, nearly impossible to find to debug.
> I think you're right, and you were given a pig in a poke.
Thanks, Clint and Jeff. I'll be sure not to contribute anything again.
--
Life's a switch() and then you die().
Jeff:
> > >Well, it's unhappy when you do lots of things. The code I was given was
> > >not as complete/functional as I had been led to believe, inasmuch as it
Eh, I didn't lead you to believe anything, and in fact I think I said it had
portability issues.
> > Unparsable argument, start
At 10:29 AM 5/19/2002 +0100, Simon Cozens wrote:
> > > Unparsable argument, starting from '"', QUOTE
> > > No line number, no context, nearly impossible to find to debug.
>
>That's an internal error with the assembler, shouldn't happen. It
>suggests the string regexp is broken. I delibera
Simon Cozens wrote:
>
> Jeff:
> > > >Well, it's unhappy when you do lots of things. The code I was given was
> > > >not as complete/functional as I had been led to believe, inasmuch as it
>
> Eh, I didn't lead you to believe anything, and in fact I think I said it had
> portability issues.
Many
Simon Cozens:
# Clinton A. Pierce:
# > No line number, no context, nearly impossible to find to debug. I
# > think you're right, and you were given a pig in a poke.
#
# Thanks, Clint and Jeff. I'll be sure not to contribute anything again.
God, Simon, get over it. You might very well say the s
On Sun, May 19, 2002 at 01:39:30AM -0400, Melvin Smith wrote:
> Filled in some missing holes:
> -Implement PMC inc/dec functions and add ops to engine.
> 'inc P0, 5' is faster than 'set P0, P1, 5' which uses a vtable.
> -Corrected 'inc Nx, Ny' to 'inc Nx, Iy' as per the PDD
> -Added missing 'add N
On Sat, May 18, 2002 at 07:33:53PM -0400, Dan Sugalski wrote:
> At 7:25 PM -0400 5/18/02, Melvin Smith wrote:
> >Yeh I know that word is yucky and from Java land, but in this case,
> >I think that
> >"system" PMCs should take liberties for optimization.
>
> *All* PMCs should take liberties for o
>Net result is Good.
>
>[If it wasn't clear, thanks for this, thanks for all the other good work
>you've
>done on parrot]
Thank you.
>Seriously though - is it possible to automate testing how many ops don't
>have tests? That way we could have a test that looked for untested ops, and
>failed if
On 19 May 2002 at 1:24, Brent Dax wrote:
> $CPAN/authors/id/B/BR/BRENTDAX/parrot/parrot-cfg.tar.gz
>
> This is a full Parrot distribution with the new Configure. Unpack it to
> an empty directory, run the normal Configure/make/make test, and report
> the results.
Cygwin (downloaded 2001-
I think I finally figured out what the problem was with the classes/
makefile, that caused strange things to happen. :)
Patch included below. Should the various files also depend upon pmc2c.pl,
so they will be regenerated in the event of a change to the generator? Or
is that going too far? Techn
On Sat, May 18, 2002 at 06:58:40PM -0400, Dan Sugalski wrote [to P. Gibbs]:
> Did we get you commit privs? If so, commit it. If not, get me your
> perl.org login and I'll get it taken care of.
In the meantime, I committed that patch.
This patch removes a bunch of warnings that have accumulated with MSVC
recently.
Mike Lambert
Index: byteorder.c
===
RCS file: /cvs/public/parrot/byteorder.c,v
retrieving revision 1.9
diff -u -r1.9 byteorder.c
--- byteord
> This patch removes a bunch of warnings that have accumulated with MSVC
> recently.
And since I tested the patch with MSVC running, I forgot to run make to
rebuild core_ops.c. Attached patch should be used instead of the previous
one, as this one actually compiles. :)
Mike Lambert
Index: byt
At 09:11 PM 5/19/2002 -0400, Mike Lambert wrote:
> > This patch removes a bunch of warnings that have accumulated with MSVC
> > recently.
Mostly applied. Here is your rejected hunk, sir.
-Melvin
resources.c.rej
Description: Binary data
> Mostly applied. Here is your rejected hunk, sir.
Much appreciated. Looks like Peter's patch also did some of the same
formatting fixes. Below is a re-patch that fixes the problem.
Mike Lambert
Index: resources.c
===
RCS file: /cv
Arg, looks like I'm on a roll today.
Ignore this latest patch. Looks like this particular line was needed with
the recent set of changes, and the below patch compilation of resources.c.
I need to learn to test even the most trivial of changes, as my
assumptions changed out from under me.
Just be
I started to look into the GC crashes with the perlhash tests. I'm not
sure I found the exact problem, but I found a bunch of dangerous things
that were being done, and could possibly cause the GC problems.
restore_invariants is an ugly hack that is prone to error. You have to
remember to restore
I'm remailing this idea since we haven't discussed it in a while.
I would like an elegant, easy to use solution for making the GC
play nicely.
I propose a solution that allows us to draw a electric fence around
the current scope by using some call as follows:
gc_crit();
gc_leave_crit
Aaron Sherman writes:
: > Alternately, I think we should be able to mark subs as 'final' or 'inline'
: > to indicate our guarantee that they won't be modified. Of course, it'll
: > conflict with auto memoizing or auto currying modules that'd want to
: > override it, but that's their fault. :)
:
:
Me writes:
: [modified repost due to warnock's dilemma]
:
: Would something like these DWIM?
:
: # match pat1 _ pat2 and capture pat2 match:
: / pat1 { ($foo) = / pat2 / } /
Yes, though I think we'll see people doing it more like this:
/ pat1 ( pat2 ) { $foo = $-1 } /
We might al
> I would like an elegant, easy to use solution for making the GC
> play nicely.
So would we all. :)
> This creates a sliding scope window that GC must not peep through,
> and provides a clean interface for internals writers.
I think you've explained this idea before, but I complained about it
At 02:23 AM 5/20/2002 -0400, Mike Lambert wrote:
>GC-sensitive functions must remember to mark themselves as critical.
>This will be a source of bugs (whether that's a big enough of a
>complaint is up for debate. ;)
I'll think about debating it tomorrow. :)
>Most vtable methods, and/or people th
I may be approaching semi-radical territory here with this idea.
I've read all the FAQs and reasons on why we choose a register
architecture versus a stack architecture. However, I recently thought of a
combination idea which, (although it was probably discovered in the
70s sometime,) I think pro
> >Most vtable methods, and/or people that call vtable methods, will end up
> >making themselves critical. This overhead will be imposed on most function
> >calls, etc. Lots of the string api will require the users to mark
> >themselves as critical.
>
> I don't think this is accurate. People calli
26 matches
Mail list logo
