Am Montag, 4. Juni 2007 03:40 schrieb chromatic:
> > > #define c_b 25245
> >
> > Another WTF from code history.
> >
> > leo - please remove this - kthx.
>
> We have to replace it with something; any ideas?
Well, just the "normal" way of parsing commands. Chained ifs:
if (!memcmp(cmd
On Wednesday 23 May 2007 14:49:02 Leopold Toetsch wrote:
> Am Mittwoch, 23. Mai 2007 15:26 schrieb Andy Dougherty:
> > /*
> > * These constants correspond to the debugger commands and are
> > * used in src/debug.c. To map command strings to their
> > * numeric values, use the algorithm from par
Am Mittwoch, 23. Mai 2007 15:26 schrieb Andy Dougherty:
> /*
> * These constants correspond to the debugger commands and are
> * used in src/debug.c. To map command strings to their
> * numeric values, use the algorithm from parse_command() in that file.
> */
>
> #define c_b 25245
On Wed, 23 May 2007, Klaas-Jan Stol wrote:
> > There are some magic numbers, like 255, and some other very unclear code
> > snippets like:
> >
> > for (i = 0; *command && isalpha((int) *command); command++, i++)
> > c += (tolower((int) *command) + (i + 1)) * ((i + 1) * 255);
> >
> >
>
On 5/23/07, Klaas-Jan Stol <[EMAIL PROTECTED]> wrote:
On 5/23/07, chromatic <[EMAIL PROTECTED]> wrote:
>
> This file implements most of the Parrot debugger. The interpreter
> struct has
> a slot called pdb that contains a PDB_t (parrot/debug.h).
>
> This file is somewhat messy. It has some s
On 5/23/07, chromatic <[EMAIL PROTECTED]> wrote:
This file implements most of the Parrot debugger. The interpreter struct
has
a slot called pdb that contains a PDB_t (parrot/debug.h).
This file is somewhat messy. It has some string manipulation functions
(nextarg(), skip_ws(), parse_int(), pa
This file implements most of the Parrot debugger. The interpreter struct has
a slot called pdb that contains a PDB_t (parrot/debug.h).
This file is somewhat messy. It has some string manipulation functions
(nextarg(), skip_ws(), parse_int(), parse_string()) that should probably go
elsewhere.
On 5/17/07, Andy Dougherty <[EMAIL PROTECTED]> wrote:
On Wed, 16 May 2007, jerry gay wrote:
> good comments... but why keep both function and macro? which would you
> prefer keeping over the other, and why? i can't understand why both
> exist.
In src/debug.c, for handling user input, I don't s
On Wed, 16 May 2007, jerry gay wrote:
> good comments... but why keep both function and macro? which would you
> prefer keeping over the other, and why? i can't understand why both
> exist.
In src/debug.c, for handling user input, I don't see any particular
advantage to the macro version. The f
On Wed, May 16, 2007 at 09:36:48AM -0700, jerry gay wrote:
> good comments... but why keep both function and macro? which would you
> prefer keeping over the other, and why? i can't understand why both
> exist.
Yes, sorry, I sort of missed that part.
Er. I don't know. One deserves to die.
Nichol
On 5/16/07, Nicholas Clark <[EMAIL PROTECTED]> wrote:
On Wed, May 16, 2007 at 08:45:04AM -0700, jerry gay wrote:
> here's a macro to move to the next argument (kjs mentioned in an
> earlier thread that this isn't a descriptive name)
>
> /* na(c) [Next Argument (Char pointer)]
> *
> * Moves t
here's a macro to move to the next argument (kjs mentioned in an
earlier thread that this isn't a descriptive name)
/* na(c) [Next Argument (Char pointer)]
*
* Moves the pointer to the next argument in the user input.
*/
#define na(c) { \
while (*c && !isspace((int) *c)) \
c
On Wed, May 16, 2007 at 08:45:04AM -0700, jerry gay wrote:
> here's a macro to move to the next argument (kjs mentioned in an
> earlier thread that this isn't a descriptive name)
>
> /* na(c) [Next Argument (Char pointer)]
> *
> * Moves the pointer to the next argument in the user input.
>
13 matches
Mail list logo
