What about updating RFCs? Should I increment the version number and send
each new revision to perl-rfc? Do I need to be careful about the RFC
number when submitting updates?
Also, I assumed the intention of the RFCs was to stimulate focused
discussion and to keep a record of the decisions made
Tom Christiansen wrote:
So ripping all this 'cruft' would save us about 100-160 kB, still
leaving us with well over a 1MB-plus executable. It's Perl itself
that's big, not the thin glue to the system functions.
Moreover, if you rip out that 100-160 kb, allocating it to modules,
then I
dLux wrote:
/--- On Thu, Aug 24, 2000 at 12:30:25PM -0400, John Porter wrote:
| Still not good. "trans" is too overloaded word. "transaction"?
| "transactional"? (a bit too long...) "atomic"?
|
| "acid"?
\---
"transactional" and "transaction" are quite long, I don't like that.
How much optimization are we talking about?
Currently, toke.c turns "foo$bar" into "foo".$bar before the parser or
anything else sees it. So any features implemented in the tokenizer have
to get smarter about remembering what they did.
If you do common subexpression elimination, one opcode may
Bart Lateur wrote:
On Thu, 14 Sep 2000 15:47:43 -0700, Steve Fink wrote:
Currently, toke.c turns "foo$bar" into "foo".$bar before the parser or
anything else sees it. So any features implemented in the tokenizer have
to get smarter about remembering what they did.
(moved off of -meta)
"David L. Nicol" wrote:
Steve Fink wrote (and I edited slightly):
groan I can't figure out why so many people misinterpret my RFC12
as requiring a solution to the halting problem.
a large class of incompletely expressed
suggestions appear to g
Oops, replied to the wrong message (that's why there was a "(COPY)"
there).
"David L. Nicol" wrote:
Steve Fink wrote:
It's standard semantic analysis. Both your taintedness analysis and my
reachability analyses can be fully described by specifying wh
Most of the time, perl's performance is a total non-issue for me. When
it is, I'm generally doing the same things as Dan (ie, things resembling
dd if=/dev/hda | perl -e ...). I posted some vague benchmarky ideas to
perl6-meta at one point. Here they are again:
-
You did ask at one point for
Ken Fox wrote:
I was noodling around with a couple different VM implementations
and thought I would ask other people if they were doing the same.
It would be nice to divide and conquer the exploration of different
implementations.
I looked into 3 different dispatching techniques. Here's
Simon Cozens wrote:
On Wed, Nov 01, 2000 at 05:35:17PM -0800, Steve Fink wrote:
Algorithm Inline? OptimizationTime (sec)
GOTO- -O3 1.35
FUNCALL_HYBRID yes -O3 4.20
Jarkko Hietaniemi wrote:
Some sort of SGI megaserver, dunno MHz, but load is high (more than
five times the number of CPUs...), so the following numbers are a tad slow,
but I guess relatively right:
-O3 none
switch 7.027.70
orig16.59
Quoting Simon Cozens ([EMAIL PROTECTED]):
On Tue, Oct 09, 2001 at 11:50:55PM +0200, Benoit Cerrina wrote:
It is clear that PMCs are object but does the acronym has a signification?
Parrot Magic Cookie.
No matter how hard I try, my brain always expands it to Perl Meaty
Chunk. It kinda fits,
Quoting Dan Sugalski ([EMAIL PROTECTED]):
Okay, here's a quick rundown on PMCs and how we're handling opcodes called
on PMC registers. (This is mildly different than what's gone in the past, FWIW)
Every PMC has a set of static types, stored in the vtable. These types are
static, and stuck
On Tue, Dec 04, 2001 at 04:11:58PM -0500, Dan Sugalski wrote:
Seriously, there are real answers to a whole lot of design questions. Ask
'em and I'll get FAQable answers to 'em once and for all.
Whee! Ok. Some of these are probably duplicates, and some
inappropriate for a Parrot FAQ, but:
Q:
On Tue, Dec 04, 2001 at 10:45:53PM -0500, Adam Turoff wrote:
On Tue, Dec 04, 2001 at 06:29:34PM -0800, Steve Fink wrote:
On Tue, Dec 04, 2001 at 04:11:58PM -0500, Dan Sugalski wrote:
Seriously, there are real answers to a whole lot of design questions. Ask
'em and I'll get FAQable
On Wed, Dec 05, 2001 at 11:02:34AM -0500, Dan Sugalski wrote:
At 06:29 PM 12/4/2001 -0800, Steve Fink wrote:
Q: What about incremental matching?
A: What about it?
Is there any plan to support nonbuffered matching, as in, I have a
socket connection open that I want to scan for some pattern
Small cleanup patch:
- genclass.pl attempts to put $Id$ into generated files
but the $Id$ string gets mangled when it's committed.
This patch fixes the existing .pmc files and fixes genclass.pl.
- Makes capitalization in .pmc header match actual filenames
- The command for calling
Index: docs/vtables.pod
===
RCS file: /home/perlcvs/parrot/docs/vtables.pod,v
retrieving revision 1.5
diff -u -r1.5 vtables.pod
--- docs/vtables.pod8 Dec 2001 21:24:15 - 1.5
+++ docs/vtables.pod2 Jan 2002 21:24:06
This patch makes pmc2c.pl emit #line directives to .c files so the
debugger can trace the code back to the editable source. However, I
also have a larger patch that supersedes this one, but it changes
behavior. I just wanted to get this out first in case the later one is
deemed a bad idea.
The
On Wed, Jan 02, 2002 at 11:49:40PM +, Alex Gough wrote:
On Wed, 2 Jan 2002, Steve Fink wrote:
This patch makes pmc2c.pl emit #line directives to .c files so the
Good plan, saves me hitting M-x revert-buffer every time I try to
change something when hunting. Is this likely to make
On Mon, Jan 07, 2002 at 11:03:05PM +, Nicholas Clark wrote:
--- include/parrot/parrot.h~ Sat Dec 15 14:21:03 2001
+++ include/parrot/parrot.h Mon Jan 7 21:56:40 2002
@@ -68,6 +68,11 @@
typedef void* BIGINT;
typedef void* BIGFLOAT;
+/* define a macro to acknowledge an unused
On Wed, Jan 09, 2002 at 12:44:45PM -0800, Brent Dax wrote:
Steve Fink:
# On Wed, Jan 09, 2002 at 03:16:40AM -0800, Brent Dax wrote:
#
# Also, why specific opcodes for \w etc.? I would think you'd do those
# as constants. (Constant bitmaps for 8-bit, or constant
# MultiLevelFunkyThings
The naming of things is getting a bit messy. I'd like to propose a
convention that I use in my work. It's compatible with the last draft
of PDD 7 that I could find:
http://www.mail-archive.com/perl6-internals%40perl.org/msg03422.html
By example:
struct somename_t { ... };
typedef struct
On Thu, Jan 10, 2002 at 02:31:24PM -0600, David M. Lloyd wrote:
After looking through PDD 7, I wonder: were we planning on doing any of
this stuff? If so, maybe we should step back for a moment and do it. :-)
If developers are expected to follow these guidelines (not that I've done
any
I needed to use a generic stack, and the API in stacks.[ch] really
bothered me:
- it relied on the caller to maintain a pointer to the top of the
stack, rather than having a stack ADT that knows its own top. That
meant that anyone including a stack in its structure had to keep
around
On Thu, Jan 10, 2002 at 02:31:24PM -0600, David M. Lloyd wrote:
On Thu, 10 Jan 2002, Steve Fink wrote:
The naming of things is getting a bit messy. I'd like to propose a
convention that I use in my work. It's compatible with the last draft
of PDD 7 that I could find:
http://www.mail
New benchmark. Yummy.
Index: Makefile.in
===
RCS file: /home/perlcvs/parrot/Makefile.in,v
retrieving revision 1.112
diff -a -u -r1.112 Makefile.in
--- Makefile.in 9 Jan 2002 22:35:14 - 1.112
+++ Makefile.in 11 Jan 2002
On Fri, Jan 11, 2002 at 11:45:03AM -0800, Jonathan Leffler wrote:
On Thu, 10 Jan 2002, Steve Fink wrote:
[...] I'd like to propose a convention [...] By example:
struct somename_t { ... };
typedef struct somename_t { ... }* Somename;
The non-typedef'd name of a struct type ends in _t
On Fri, Jan 11, 2002 at 05:43:28PM -0500, Dan Sugalski wrote:
Okay, I've added some flags to pmc.h. They are:
PMC_active_destroy_FLAG = 2 8,
PMC_is_container_FLAG = 2 9,
PMC_is_buffer_ptr_FLAG= 2 10,
PMC_is_PMC_ptr_FLAG = 2 11,
On Mon, Jan 14, 2002 at 12:13:12PM -0500, Michel Lambert wrote:
This patch tests correctly on MSVC and cygwin. If this patch is too broad,
please let me know and I'll go back and split it up. It's my first patch,
and I'll be sure to use multiple checkout directories to allow future
patches to
Oops, this patch broke things. For example, the following is invalid:
Index: chartypes/unicode.c
===
RCS file: /home/perlcvs/parrot/chartypes/unicode.c,v
retrieving revision 1.5
diff -c -r1.5 unicode.c
*** chartypes/unicode.c
This patch adds a few more macros for .ops files to use. In addition
to the existing
goto OFFSET(...)
goto ADDRESS(...)
goto POP()
goto NEXT()
it adds
expr OFFSET(...)
expr ADDRESS(...)
expr POP()
expr NEXT()
This is intended mainly for use in helper functions in .ops files, but
also
On Tue, Jan 15, 2002 at 02:06:17PM -0500, Tanton Gibbs wrote:
You could break it up into:
else if( rx-startindex == 0 ) {
goto OFFSET($2);
}
else {
--rx-startindex
}
Or simply change the condition to 'if (rx-startindex-- == 0)'. But
the real question he's asking is: what is correct?
On Tue, Jan 15, 2002 at 03:06:45PM -0500, Melvin Smith wrote:
To be clear, what Andy is doing is the right thing (asking what the
intent of a piece of code is), but I doubt everyone does this and
I'm sure Dan doesn't check every single line of every patch before
eating each one, or if he does
On Wed, Jan 16, 2002 at 01:30:42AM -0800, Brent Dax wrote:
The attached patch adds a new stack type that only handles INTVALs.
These are much more efficient than generic stacks--on Win32 they shave a
few ten-thousandths of a second off each run of the rx_popindex op, and
take a full hundredth
On Wed, Jan 16, 2002 at 11:11:10AM -0500, Andy Dougherty wrote:
diff -r -u parrot/classes/pmc2c.pl parrot-andy/classes/pmc2c.pl
--- parrot/classes/pmc2c.pl Thu Jan 3 21:29:18 2002
+++ parrot-andy/classes/pmc2c.pl Wed Jan 16 10:57:04 2002
@@ -228,7 +228,12 @@
my $includes = '';
On Wed, Jan 16, 2002 at 11:25:29AM -0500, Dan Sugalski wrote:
should (Andy, Steve, Nick, Melvin, other folks I've forgotten) go over to
dev.perl.com, set up an account, and pop me mail with your account
dev.perl.org
On Fri, Jan 18, 2002 at 10:08:40PM +0200, Jarkko Hietaniemi wrote:
ints, or 176 bytes. Searching for membership in an inversion list is
O(N log N) (binary search). Encoding the whole range is a non-issue
bordering on a joke: two ints, or 8 bytes.
[Clarification from a noncombatant] You meant
On Sat, Jan 19, 2002 at 12:28:15AM +0200, Jarkko Hietaniemi wrote:
On Fri, Jan 18, 2002 at 02:22:49PM -0800, Steve Fink wrote:
On Sat, Jan 19, 2002 at 12:11:06AM +0200, Jarkko Hietaniemi wrote:
Complement of an inversion list is neat: insert 0 at the beginning
(and append max+1), unless
On Mon, Jan 14, 2002 at 01:49:44AM -0800, Brent Dax wrote:
I wrote a _very_ simple benchmark program to compare Perl 5 and Parrot.
Here's the result of a test run on my machine:
C:\brent\Visual Studio Projects\Perl 6\parrot\parrot..\benchmark
Benchmarking bbcdefg =~ /b[cde]*.f/...
All of your last several patches look good to me. Didn't Dan give you
commit rights yet? I'm pretty sure he intended to. Dan was also going
to have a discussion of commit policy -- when should we just commit,
and when should we discuss first -- as soon as he gets more settled,
but my vote would
On Mon, Jan 28, 2002 at 10:04:43PM +, Jonathan Stowe wrote:
On Mon, 28 Jan 2002, Dan Sugalski wrote:
At 4:25 PM + 1/28/02, Rafael Garcia-Suarez wrote:
Simon Cozens wrote in perl.perl6.internals:
Similarly, I'd like Parrot/ to move to lib/
And Test/, while you're at it.
On Mon, Jan 28, 2002 at 11:34:22PM -0500, Jeff G wrote:
I've just added a new 'Array' type alongside the current PerlArray. Some
target languages may not like to use Perl's array style, so they now can
use the basic Array type. As the test (t/op/pmc_array.t) indicates, no
preallocation is
On Mon, Jan 28, 2002 at 09:36:19PM -0500, Dan Sugalski wrote:
At 7:47 PM -0500 1/28/02, Michael G Schwern wrote:
On Mon, Jan 28, 2002 at 04:07:06PM -0500, Dan Sugalski wrote:
At 1:55 AM -0500 1/28/02, Michael G Schwern wrote:
This patch seems to have slipped by in the post New Year's haze.
On Tue, Jan 29, 2002 at 01:38:12AM -0500, Dan Sugalski wrote:
At 9:33 PM -0800 1/28/02, Steve Fink wrote:
On Mon, Jan 28, 2002 at 09:36:19PM -0500, Dan Sugalski wrote:
At 7:47 PM -0500 1/28/02, Michael G Schwern wrote:
On Mon, Jan 28, 2002 at 04:07:06PM -0500, Dan Sugalski wrote:
At 1
Here's a tiny doc update to reflect the improved test_parrot.
Index: docs/running.pod
===
RCS file: /home/perlcvs/parrot/docs/running.pod,v
retrieving revision 1.2
diff -p -u -b -r1.2 running.pod
--- docs/running.pod22 Jan 2002
On Tue, Jan 29, 2002 at 10:10:56AM -0800, Steve Fink wrote:
On Tue, Jan 29, 2002 at 01:38:12AM -0500, Dan Sugalski wrote:
At 9:33 PM -0800 1/28/02, Steve Fink wrote:
On Mon, Jan 28, 2002 at 09:36:19PM -0500, Dan Sugalski wrote:
At 7:47 PM -0500 1/28/02, Michael G Schwern wrote
On Tue, Jan 29, 2002 at 09:57:16PM +, Simon Cozens wrote:
JIT
---
More instructions needed!
Register my vote for some introductory documentation. docs/jit.pod is
good for someone who already knows how the JIT works, but I'd like
something for idiots like me who just want to know what
Any idea what of this will become 0.0.4?
I'm being anal again. Here's an update to docs/running.pod to better
reflect the current state (both the test_parrot and assemble.pl
improvements, plus documentation of a few more things.) And also a
speling fiks s/POST_MORTERM/POST_MORTEM/.
I could also replace some perl foo calls with ./foo if
On Wed, Jan 30, 2002 at 08:39:17PM +, Alex Gough wrote:
On Wed, 30 Jan 2002, Steve Fink wrote:
Any idea what of this will become 0.0.4?
Is there any chance someone (simon) could make a TODO_FIRST [1], which contains
the goals for our next point release. I'm far too lazy to search
On Wed, Jan 30, 2002 at 09:32:45PM +, Nicholas Clark wrote:
You can now do:
nick@thinking-cap maniskip$ make manitest
perl14405-32 -MExtUtils::Manifest=fullcheck -e fullcheck
Not in MANIFEST: Configure.pl.rej
Not in MANIFEST: MANIFEST.SKIP.orig
Not in MANIFEST: MANIFEST.SKIP~
Not in
I just committed a patch to jit2h.pl, Op.pm, and OpsFile.pm that
infers what ops may modify control flow, used by the jit to decide
whether to fall through to the next op or jump. (Daniel Grunblatt is
ok with it.) Just FYI.
On Wed, Jan 30, 2002 at 10:01:50PM +, Simon Cozens wrote:
begin quote from Steve Fink:
Perhaps a target version for each item?
Oh, bother. This is the second time I've been asked about this, so I
suspect that my goals for the forthcoming releases aren't amazingly
clear.
Or perhaps
On Wed, Jan 30, 2002 at 11:20:28PM +, Nicholas Clark wrote:
On Wed, Jan 30, 2002 at 02:55:54PM -0800, Steve Fink wrote:
Ah. This suggests that this bit of the proposed MANIFEST.SKIP:
...
becomes
^classes/.*\.[ch]$
Is it valid to assume that the only .h and .c files in classes
On Wed, Jan 30, 2002 at 08:37:30PM -0500, Bryan C. Warnock wrote:
But if you know they're going to be twenty times slower, why are you doing
it? Because we know / think / hope / pray / have been making sacrifices to
Tangential note: current benchmarking indicates that we're doing a lot
On Sun, Feb 03, 2002 at 09:29:27PM +0100, Juergen Boemmels wrote:
Hi there,
I played again a little with the vtables.
I noticed that all *.pmc function implement the methods type and name
are implemented the same way. Then I was wondering if its possible to
autogenerate this functions in
On Tue, Feb 05, 2002 at 01:06:25AM -0800, Brent Dax wrote:
This patch adds warnings capability to Parrot. It adds actual warnings
throughout the PerlUndef class, primarily to show how it's done. It
also adds a half-functional Parrot_sprintf() and friends.
On the Parrot_sprintf: a good
On Thu, Feb 07, 2002 at 06:13:47AM -0800, Ask Bjoern Hansen wrote:
Hi,
I am tired of people thinking that we are not getting anywhere at
all, so if (some|any|every)one can send me a reasonably updated text
for the Where are we section at http://www.parrotcode.org/ and
likewise for
On Thu, Feb 07, 2002 at 01:15:44AM -0500, Josh Wilmes wrote:
+sub goto_address {
+return return NULL; /* THIS IS BROKEN, but this op is for pbc2c.pl, so pre
deref isn't used yet. */;
+}
+
Hrm. I don't like that much, because my .ops file uses the goto
ADDRESS() form for several
On Thu, Feb 07, 2002 at 04:22:54PM -0500, Andy Dougherty wrote:
On Thu, 7 Feb 2002, Steve Fink wrote:
It also points to the question can we make the byte_code be an
opcode_t* already?
I've got it almost completely done on the C end, but I've hit a
discrepancy between packfile.c
On Fri, Feb 08, 2002 at 02:08:54PM -0800, Larry Wall wrote:
Dan Sugalski writes:
: At 5:17 PM + 2/8/02, Simon Cozens wrote:
: Dan Sugalski:
: Can't. Needs to be a linked list. Otherwise we can't nest data structures
: well.
:
: Thanks; I knew there had to be a reason, couldn't
On Mon, Feb 11, 2002 at 11:10:30PM +, Simon Cozens wrote:
Fine. But what if P1 could take multiple types and do different things
with them? In that case, which is more common than you think:
%foo = @bar;
P1 can't know what it wants out of P2 unless it knows what
P2 *is*! Just as
On Wed, Feb 13, 2002 at 10:43:38PM -0500, Jason Gloudon wrote:
The type changes in struct Packfile break the pointer math used in a few places
to calculate the address of the end of the loaded byte code. This causes
segfaults in build_asm in jit.c when using -j. It also breaks the bounds
On Fri, Feb 15, 2002 at 12:13:57PM -0800, Steve Fink wrote:
Looks like the commits since last night have re-broken pbc2c.pl, so
it'll be a little while before I can generate a patch.
My mistake, it was just that 'make clean' deleted my .pbc file and
pbc2c.pl wasn't very good about reporting
On Sat, Feb 16, 2002 at 01:26:31AM -0800, Brent Dax wrote:
These lines:
libparrot$(A) : $(O_FILES)
$(AR_CRS) $@ $^
hopelessly confuse nmake:
makefile(151) : fatal error U1001: syntax error : illegal character '^'
in macro
Oops, I was worried that something like that might
On Fri, Feb 15, 2002 at 11:37:23PM -0500, Dan Sugalski wrote:
At 12:35 PM -0800 2/15/02, Steve Fink wrote:
Anyway, here's a patch to repair pbc2c.pl, combined with removing
typecasts in various places throughout the code. It probably won't
work for Windows yet. The libparrot.a target might
On Sun, Feb 17, 2002 at 08:54:52PM +0100, Gerson Kurz wrote:
Besides, wasn't parrot supposed to be a VM and interpret the code,
rather than just compile-to-c? (And, the code doesn't even look like
normal C code - it has a static char program_code[] = { which it
executes).
Yes. You're using a
I've written a more or less working regular expression compiler and
optimizer. Where should I put it? It's not really part of Parrot, at
least no more than perl's eval would be. Would languages/regex be ok
for now?
On Mon, Feb 25, 2002 at 12:18:20AM -0800, Brent Dax wrote:
We have an opcode, rx_compile, slotted for a generic regex compiler.
The idea is that most regex-heavy languages (like Perl) would implement
their own compilers with the extra semantics necessary, but many
languages that don't need
On Tue, Feb 26, 2002 at 11:15:59AM -0800, Hong Zhang wrote:
The KVM of Java includes pre-verify info, which serves similar purpose.
The
reason behind is Java bytecode verification is (kind of) NP-complete. By
using pre-verify info, the problem can be reduced to linear in most case.
(No
On Mon, Mar 18, 2002 at 10:23:39AM +, Simon Cozens wrote:
Steve Fink:
Ok, you asked for it. I just committed the regular expression
compiler.
That might not have been an amazingly intelligent thing to do during
a feature freeze in the run up to a new release. :)
Can we only do bug
On Mon, Mar 18, 2002 at 09:13:45AM -0800, Steve Fink wrote:
On Mon, Mar 18, 2002 at 10:23:39AM +, Simon Cozens wrote:
Steve Fink:
Ok, you asked for it. I just committed the regular expression
compiler.
That might not have been an amazingly intelligent thing to do during
On Mon, Mar 18, 2002 at 09:09:59AM -0500, Dan Sugalski wrote:
At 4:17 PM -0800 3/17/02, Steve Fink wrote:
On Sat, Mar 16, 2002 at 04:34:34PM -0500, Dan Sugalski wrote:
Now's your time to speak up, please.
Ok, you asked for it. I just committed the regular expression
compiler. It has known
On Mon, Mar 18, 2002 at 03:17:40PM -0500, Dan Sugalski wrote:
At 3:14 PM -0500 3/18/02, Joshua Nye wrote:
I know someone is working on this probably but this was just driving me
mad.
On fresh check out of cvs:
Fixed, I think.
Isn't that function static anyway? It either shouldn't be,
What's the current status of support for keyed ops? I'm tempted to
slap together at least partial support for some keyed operations
(they'd make some of my test code simpler, at the very least), but I'd
rather not work on out of date code. And I don't completely understand
what needs to be done.
I'm probably misunderstanding something, but I'm using keys for groups
in regular expressions (the uses are internal and so require no
assembler support), and I was getting a lot of seg faults. After
taking a look, I don't understand the reason for the extra level of
indirection to KEY_PAIRs. A
On Wed, Mar 27, 2002 at 11:15:22AM -0800, Steve Fink wrote:
I'll send a followup patch that updates the .ops files (mainly rx.ops)
to define and use the working MAKE_KEY.
And here it is.
Index: core.ops
===
RCS file: /home
On Wed, Mar 27, 2002 at 02:46:21PM -0500, Michel J Lambert wrote:
My methodology in creating this patch was to first apply Daniel's patch,
and then get it working. His patch had significant changes to an older
version of pbc2c.pl, which I tried to apply to the newest version. I then
proceeded
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. Nothing
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:
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
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:
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,
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.pmc,v
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 you're right
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 allocate
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's
For example:
op puts(in STR) {
if (($1) string_length($1)) {
PIO_write(interpreter, PIO_STDOUT(interpreter), ($1)-bufstart,
string_length($1));
}
goto NEXT();
}
Everywhere else the code treats NULL as if it were the empty string.
On Fri, Mar 29, 2002 at 03:25:19AM -0500, Michel J Lambert wrote:
The attached patch fixes a bunch of bugs. They are:
From before, rolled into this patch:
+ Creates a new flag, immortal, which is intended for GC use only, so it
shouldn't be set in the init() function. This is used to
On Thu, Mar 28, 2002 at 12:18:48AM -0500, Michel J Lambert wrote:
Attached are my revised files. pbc2c.pl uses Parrot::OpTrans::Compiled,
and this patch uses Parrot::OpTrans::CGoto. It also fixed the issues with
the last patch:
- removed inadvertant keyed commenting
- fixed #include name
On Fri, Mar 29, 2002 at 10:28:09AM -0800, Brent Dax wrote:
Let's say my data pointer points to this struct:
typedef struct parrot_subroutine_t {
opcode_t *bytecode;
STRING *name;
proto*prototype;
(a bunch of other stuff
This patch obsoletes my previous two key-related patches. It's a large
patch that does a bunch of things, so I'd like somebody to give an
opinion before I commit it.
- Changes KEY to contain a KEY_PAIR* instead of a KEY_PAIR**
- Changes the MAKE_KEY macro to work within an expression
-
The two patches in this thread are obsoleted by the 'core key support'
patch I just posted.
Test 7 of t/op/stacks.t is failing for me right now. It fails even
when I back up to version 1.25 of stacks.c, and anything earlier
doesn't compile (without backing up other files too).
[I sent this out last night, but a word of advice: don't do
development on your active mail server!]
On Sat, Mar 30, 2002 at 09:38:31AM -0500, Dan Sugalski wrote:
With the recent stack and GC patches, are we pretty much solid now?
If so, a 0.0.5 bugfix release may well be in order.
--
I'm still getting a test failure on stacks.t, in test #7. Until that's
fixed, I'm holding off committing
On Sat, Mar 30, 2002 at 10:47:11AM -0800, Steve Fink wrote:
On Sat, Mar 30, 2002 at 09:38:31AM -0500, Dan Sugalski wrote:
With the recent stack and GC patches, are we pretty much solid now?
If so, a 0.0.5 bugfix release may well be in order.
--
I'm still getting a test failure
On Sun, Mar 31, 2002 at 07:44:11AM -0500, Michel J Lambert wrote:
I'm sorry, this new weapon is going to give a quick advantage to the fools
side, but luckily, should help the fool-proofers in the long run.
Which reminds me -- Dan, I hereby nominate Mike for commit access. :-)
With the following comment:
- Changes KEY to contain a KEY_PAIR* instead of a KEY_PAIR**
- Changes the MAKE_KEY macro to work within an expression
- Changes the MAKE_KEY macro to not return NULL if the value is 0 or
NULL. This is needed because an enum_int_val key, for example, will
1 - 100 of 466 matches
Mail list logo
