Re: How?
Leo (Michael, and Dmitry), Thanks, I am also interested in contributing and I'll put your suggestions to good use! -- George Plumfield > Dmitry Nikolayev <[EMAIL PROTECTED]> wrote: > > > Hello > > How can I be involved in the project? Maybe, some help is needed? > > What would you like to contribute? Help is always welcome. > > Did you read the docs (either at parrotcode.org or in the src? > intro.pod has a "Getting involved" chapter. There is a TODO file too. > If unsure, where to start, try writing some tests: You can learn Parrot > assembly and see how things are working. > > > Dmitry Nikolayev > > leo
Re: [perl #24371] [PATCH] Unescaped metachars in output_like tests
Adam Thomason <[EMAIL PROTECTED]> wrote: > A few tests using output_like and friends have unescaped '.' chars. Thanks, applied. leo
Re: [perl #24376] [PATCH] NetBSD
Nick Kostirya <[EMAIL PROTECTED]> wrote: > With this patch Parrot is being successfully built on NetBSD 1.6. > > All tests successful, 27 subtests skipped. Just curious: is "make testexec" successful? Anyway applied, thanks, [ BTW please send diffs relative to parrot root or one dir below, so that they can be applied with patch -p0 or -p1 respectively ] leo
Re: [perl #24378] [PATCH] fix warnings in cpu_deps.c on Solaris
David Robins <[EMAIL PROTECTED]> wrote: > "src/cpu_dep.c", line 36: warning: initializer does not fit or is out of > The patch changes the type that stores the instruction from int to unsigned > int. Thanks, applied, leo
Character classification functions
The current chartype struct contains an is_digit function. Do we want to add is_alpha, is_space, etc., or will a single is_ctype function, with an enum parameter, suffice? A single function would simplify the addition of new character classes, but at a (small?) cost in speed. It would also keep the chartype struct smaller, but there is unlikely to be enough of those to make any significant difference. Since the current prototype includes the chartype, existing functions (eg ICU u_is) could not be called without a wrapper function anyway, so a single function would mean one wrapper with a switch statement, versus individual wrappers for each class. I prefer the single function approach, so that is what I will start implementing if there are no timeous objections. Regards Peter Gibbs EmKel Systems
[CVS ci] use pointer vtables for passing Sub address
I've remove the rather hackish set_integer_native() and get_integer() methods for Sub-like PMCs. The old sequence: set_addr I0, _label set P0, I0 is now just set_addr P0, _label This might break some languages using such constructs. Also obtaining the address of a Sub-like PMC is changed, its now: get_addr I0, P0 leo
Re: Character classification functions
On 1 Nov 2003, at 16:37, Peter Gibbs wrote: The current chartype struct contains an is_digit function. Do we want to add is_alpha, is_space, etc., or will a single is_ctype function, with an enum parameter, suffice? Excuse me for being naming fusspot for a second. What Parrot calls a chartype is more commonly called a character set. I mention this because it's the kind of thing you really notice when writing documentation http://www.vendian.org/parrot/wiki/bin/view.cgi/Main/ ParrotDiagramsString and therefore puts me in this frame of mind. Since the enum will specify what you yourself call character classes can't we call the function is_charclass() instead? BTW the related get_digit() function currently fails some test that I'm working on. If you pass it a non-digit character it blithely calculates from first_code and first_value. Rather, it should indicate failure in some way. Mike A single function would simplify the addition of new character classes, but at a (small?) cost in speed. It would also keep the chartype struct smaller, but there is unlikely to be enough of those to make any significant difference. Since the current prototype includes the chartype, existing functions (eg ICU u_is) could not be called without a wrapper function anyway, so a single function would mean one wrapper with a switch statement, versus individual wrappers for each class. I prefer the single function approach, so that is what I will start implementing if there are no timeous objections. Regards Peter Gibbs EmKel Systems
Re: Character classification functions
Peter Gibbs <[EMAIL PROTECTED]> wrote: > I prefer the single function approach, so that is what I will start > implementing if there are no timeous objections. Yep, a single is_ctype() should really be enough. > Regards > Peter Gibbs leo
Re: Character classification functions
"Michael Scott" <[EMAIL PROTECTED]> wrote: > Since the enum will specify what you yourself call character classes > can't we call the function is_charclass() instead? The isascii etc macros have been defined in a header called ctype.h for some time, and glibc actually has a macro 'isctype' which does the exact equivalent of what I am proposing, which is why I chose the name; however, I have no personal preference, so I'll go with whatever seems most popular. Your suggestion wins so far. > BTW the related get_digit() function currently fails some test that I'm > working on. If you pass it a non-digit character it blithely calculates > from first_code and first_value. Rather, it should indicate failure in > some way. That depends on the definition, which I can't find anywhere. Throwing an exception seems reasonable, so I'll do that. > Mike Peter
