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
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 s
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
>
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 t
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 gencl
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 -0
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 la
Oops, left out a chunk. I get confused when I have too many
interfering local changes. Here's a snippet for classes/Makefile.in
that needs to be applied along with the previous pmc2c.pl patch for
#lines.
Index: classes/Makefile.in
==
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 huntin
Well, I have Warnock's Dilemma with respect to people with commit
rights for my line numbering patch, but a vote of confidence from Alex
Gough. So here's the PMC inheritance patch (it also includes the line
numbering patch). It supersedes both my previous pmc2c.pl patch and
the followup classes/Ma
On Thu, Jan 03, 2002 at 11:10:56PM -0500, Bryan C. Warnock wrote:
> On Thursday 03 January 2002 08:40 pm, Paul Baranowski wrote:
> > Hi -
> > I love what you guys are doing with Parrot. I was just recently
> > wondering if it would be possible to transform a program compiled down
> > to machine l
On Mon, Jan 07, 2002 at 09:27:50AM +, Simon Cozens wrote:
> On Sun, Jan 06, 2002 at 03:20:27PM -1000, David & Lisa Jacobs wrote:
> > I recently did a build from scratch and noticed that vtable.ops,
> > vtable_ops.c etc are not being generated. Is there something new I need to
> > do in the co
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 unus
On Wed, Jan 09, 2002 at 03:16:40AM -0800, Brent Dax wrote:
> Okay, here it is. Attached is the regular expression patch. It
Is rx_advance necessary? What's the difference between
/R/
and
/^(.*?R)/
if you count the parens $& $1 $2 ... instead of $1 $2 $3 ...?
Speed, I guess?
(Okay, I r
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
>
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 somename
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 de
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 tw
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
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 01:5
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;
> &
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
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/unico
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 f
This patch add docs/running.pod, which lists the various executables
Parrot currently includes, examples of running them, and mentions of
where they fail to work. It's more of a cry for help than a useful
reference. :-) I've been having trouble recently when making changes
in figuring out whether
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 i
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 d
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 hundre
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 m
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 there already is one, in which case delete
> the 0 (and shift the list and delete the max+1). Again, O(N).
> (One could of course h
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
>
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 be
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/,
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
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, 20
On Tue, Jan 29, 2002 at 12:56:55AM -0800, Brent Dax wrote:
> Unfortunately, I will probably not be able to apply this myself. In the
> course of making the patch, I accidentally did a 'make distclean'
> instead of 'make cvsclean', and I *still* don't have a usable patch
> program, so I'll probabl
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 2
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
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 wha
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"
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.
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~
>
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&#
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 ass
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
b
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
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 goo
On Tue, Feb 05, 2002 at 10:06:42PM -0500, Josh Wilmes wrote:
>
> Who understands this? :)
>
> op enternative() {
> goto ADDRESS(( run_native(interpreter, CUR_OPCODE, (opcode_t *)interpreter->c$
> }
>
>
> The "goto ADDRESS()" syntax appears to be broken, but I have no idea how
> to fix it.
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 h
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 en
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,
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*! Ju
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
> c
On Thu, Feb 14, 2002 at 08:22:49PM -0500, Dan Sugalski wrote:
> If you choose to accept it, is to dig out the computed goto and
> switch runops cores from the archives, dust 'em off and get them up
> to snuff with the current sources.
>
> Takers, anone?
I spent about an hour on this last night
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
> - key->keys = (KEY_PAIR*)realloc(key->keys,sizeof(KEY_PAIR)*size);
> + key->keys = (KEY_PAIR**)realloc(key->keys,sizeof(KEY_PAIR)*size);
That seems rather suspicious. I don't know anything about the KEY_PAIR
type, but allocating a chunk of memory big enough to fit N structures
and the
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 mig
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
> >
Anyone object to eliminating the need for the 'struct'?
Index: include/parrot/interpreter.h
===
RCS file: /home/perlcvs/parrot/include/parrot/interpreter.h,v
retrieving revision 1.28
diff -a -u -r1.28 interpreter.h
--- include/parrot
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 us
On Mon, Feb 18, 2002 at 01:52:24PM -0500, Josh Wilmes wrote:
> Index: include/parrot/pmc.h
> ===
> RCS file: /home/perlcvs/parrot/include/parrot/pmc.h,v
> retrieving revision 1.17
> diff -u -r1.17 pmc.h
> --- include/parrot/pmc.h
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
On Wed, Feb 27, 2002 at 07:07:26PM +, Simon Cozens wrote:
> Granted, these components will share some library code, such as that to
> parse out a line of assembly source, but I think that specialized elements
> working on text is the way to go here.
>
> The real advantage of this method, othe
On Mon, Mar 11, 2002 at 03:24:56PM -0500, Simon Glover wrote:
>
> For more fun in the same vein, try this:
>
> length S0
> end
>
> In both cases the problem is that we're not checking the STRING*
> pointer passed to the function before we start trying to dereference it.
> This seems to
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 bugs, but I am completely out of tuits for now,
and have been since about the time I announced this thing's exi
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
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 be
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
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 shoul
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 KE
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
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
> procee
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
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 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
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/perl
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.
>
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
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
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 p
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 n
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 s
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
- Changes
The two patches in this thread are obsoleted by the 'core key support'
patch I just posted.
1 - 100 of 528 matches
Mail list logo
