Phalanx Devel::Cover

2003-10-12 Thread Mark Stosberg
I'm excited to see that the Phalanx project is happening. On the website I see this unfiled item: Use Devel::Cover and gconv. One way that seems useful to use Devel::Cover is to have an automated coverage testing system that would test the 100 module periodically. All the phalanx page, an

Re: Phalanx Devel::Cover

2003-10-12 Thread Tony Bowden
On Sun, Oct 12, 2003 at 01:08:39PM +, Mark Stosberg wrote: A second sticking point could be that code is OS-specific, so it's not ever going to get testing by just one build machine. And also, in the case of things like Class::DBI, have database specific code in them, that is tested, but

running both test.pl and t/*.t ?

2003-10-12 Thread Gabor Szabo
I was under the impression (I think I read it somewhere) that when running make test if there is a test.pl file and a set of tests in t/*.t only the former (test.pl) will run an the t/ directory will be skipped. I have just checked it and it seems to be not true. That is, both test.pl and t/*.t

Re: Phalanx Devel::Cover

2003-10-12 Thread Paul Johnson
On Sun, Oct 12, 2003 at 01:08:39PM +, Mark Stosberg wrote: I'm excited to see that the Phalanx project is happening. On the website I see this unfiled item: Use Devel::Cover and gconv. One way that seems useful to use Devel::Cover is to have an automated coverage testing system

Macros and PCC calls

2003-10-12 Thread Gregor N. Purdy
I have a PCC sub: .pcc_sub _char_is_white_space prototyped .param int c # Character to test (as an integer representing its ASCII code)

PCC and IMC

2003-10-12 Thread Gregor N. Purdy
Is there any good reason why prototyped PCC subs shouldn't be callable with IMC syntax that looks like a macro call, without having to make a macro wrapper manually? (I know its not the way it works now, but you can almost simulate it with a PCC sub def and a macro, and it seems to me it would be

Re: PCC and IMC

2003-10-12 Thread Melvin Smith
I was already talking to Leo offline a bit about refactoring some of the IMCC syntax. We have incrementally added some features at different times that could be handled with a more compact syntax if we rework it. 1) Combine .pcc_sub and .sub and go back to using the single keyword .sub. *This

Re: cvs commit: parrot KNOWN_ISSUES TODO

2003-10-12 Thread Leopold Toetsch
Melvin Smith [EMAIL PROTECTED] wrote: At 12:07 PM 10/12/2003 +, Leopold Toetsch wrote: -Bytecode - -- Byteordering works for most stuff except floating point (N regs) - Cross platform bytecode doesn't convert floats yet - Leo, I assume this works now since you removed this?

Re: PCC and IMC

2003-10-12 Thread Leopold Toetsch
Gregor N. Purdy [EMAIL PROTECTED] wrote: Is there any good reason why prototyped PCC subs shouldn't be callable with IMC syntax that looks like a macro call, without having to make a macro wrapper manually? Could be done, but for sure unlikely. PASM/PIR are still assembler languages. You can

Re: Macros and PCC calls

2003-10-12 Thread Leopold Toetsch
Gregor N. Purdy [EMAIL PROTECTED] wrote: .pcc_call char_is_white_space ### unexpected identifier?o [snip ] .char_is_white_space(c) if test goto ... The macro better should take the test result too: .CHAR_IS_WS(c,test) Except, the line marked in the macro def above shows that parrot

Re: PCC and IMC

2003-10-12 Thread Gregor N. Purdy
Leo -- The Jako compiler spits stuff out from Perl. I'm writing some new experimental stuff in PIR directly. I'm curious about other stuff, too. I don't see any of the languages/imcc/t/**/*.t files doing anything with the ord op, and when I try to use it as .local int c .local str s and

Re: PCC and IMC

2003-10-12 Thread Luke Palmer
Gregor N. Purdy writes: Leo -- The Jako compiler spits stuff out from Perl. I'm writing some new experimental stuff in PIR directly. I'm curious about other stuff, too. I don't see any of the languages/imcc/t/**/*.t files doing anything with the ord op, and when I try to use it as

Re: PCC and IMC

2003-10-12 Thread Gregor N. Purdy
Luke -- Yeah. That falls into the duh category, I guess. But, I'm still having some trouble: .pcc_sub _consume_string prototyped .param str input .local int c .local int test .local Sub __char_is_white_space newsub __char_is_white_space, .Sub, _char_is_white_space .local Sub

Re: [RfC] return value of PIO_seek

2003-10-12 Thread Dan Sugalski
At 7:01 PM +0200 10/10/03, Juergen Boemmels wrote: So i think it would be better to let PIO_seek return the current offset. So I purpose a change of the prototype of PIO_seek to If you've not already done this, go ahead. (I'm a bit behind :) -- Dan

Re: PCC and IMC

2003-10-12 Thread Luke Palmer
Gregor N. Purdy writes: Luke -- Yeah. That falls into the duh category, I guess. But, I'm still having some trouble: .pcc_sub _consume_string prototyped .param str input .param string input Now the error makes sense. .local int c .local int test .local Sub

More missing files

2003-10-12 Thread Dan Sugalski
The tinders are all failing to be ablaze, yet still failing horribly, with the compilation of dynext.c whining about a missing enum_class_ConstParrotLibrary. (I note that local builds for me are complaining about the same problem) Since there's no constparrotlibrary.pmc in the repository, I'm

Re: cvs commit: parrot KNOWN_ISSUES TODO

2003-10-12 Thread Melvin Smith
At 08:46 PM 10/12/2003 +0200, Leopold Toetsch wrote: Melvin Smith [EMAIL PROTECTED] wrote: At 12:07 PM 10/12/2003 +, Leopold Toetsch wrote: -Bytecode - -- Byteordering works for most stuff except floating point (N regs) - Cross platform bytecode doesn't convert floats yet -

Re: running both test.pl and t/*.t ?

2003-10-12 Thread Michael G Schwern
On Sun, Oct 12, 2003 at 06:28:52PM +0200, Gabor Szabo wrote: That is, both test.pl and t/*.t were executed. AFAIK its always been this way. DBI relies on it. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ It should indeed be said that notwithstanding the fact