Re: [9fans] APE: a further note.

2010-04-17 Thread C H Forsyth
-T is great. But Python can't be built with it. Python explicitly creates functions with type signatures that don't match and this makes -T very unhappy. the examples i had to fix (that didn't simply require #pragma incomplete) were errors, for instance something like the following: one

Re: [9fans] APE: a further note.

2010-04-16 Thread tlaronde
On Thu, Apr 15, 2010 at 02:30:15PM -0400, erik quanstrom wrote: gcc(1) is very verbose (well: I always set -Wall). ken-cc is---surprise---more laconic; but when he was saying: no! he was right, for things that were going silently under NetBSD. compile with -FVTw. -T causes type

Re: [9fans] APE: a further note.

2010-04-16 Thread ron minnich
-T is great. But Python can't be built with it. Python explicitly creates functions with type signatures that don't match and this makes -T very unhappy. Just a warning: it's good to turn it on, but there are cases where it will lead to an error that is not an error (depending on how you define

Re: [9fans] APE: a further note.

2010-04-16 Thread Steve Simon
-T is great. But Python can't be built with it. Python explicitly creates functions with type signatures that don't match and this makes -T very unhappy. Is there a #pragma to turn off type checking on a symbol, somthing like #pragma incomplete? -Steve

Re: [9fans] APE: a further note.

2010-04-16 Thread erik quanstrom
On Fri Apr 16 05:23:38 EDT 2010, rminn...@gmail.com wrote: -T is great. But Python can't be built with it. Python explicitly creates functions with type signatures that don't match and this makes -T very unhappy. why would they do that? Just a warning: it's good to turn it on, but there are

Re: [9fans] APE: a further note.

2010-04-16 Thread erik quanstrom
compile with -FVTw. -T causes type signatures to be emitted. the linker won't link mismatched type signatures. i've found this to be very useful. Thanks: I will add the flags by default in the Plan9 parameter file in my framework. Even if it does not catch all, it will help. -T is

[9fans] APE: a further note.

2010-04-15 Thread tlaronde
Still fixing things for correct compilation of TeX and al. under Plan9, I stumbled upon this one. Traditional lex(1) uses: char yytext[]; The code (main code for translation between Pascal and C), was declaring in the external units: char *yytext; The result is no problem at

Re: [9fans] APE: a further note.

2010-04-15 Thread erik quanstrom
gcc(1) is very verbose (well: I always set -Wall). ken-cc is---surprise---more laconic; but when he was saying: no! he was right, for things that were going silently under NetBSD. compile with -FVTw. -T causes type signatures to be emitted. the linker won't link mismatched type signatures.

Re: [9fans] APE: a further note.

2010-04-15 Thread Federico G. Benavento
-T with in APE for lunix code doesn't cut it without hand editing tons of it, there's always a function prototype missing or even conflicting... hand depending on the size of the project it can be unmanageable... On Thu, Apr 15, 2010 at 3:30 PM, erik quanstrom quans...@quanstro.net wrote: gcc(1)

Re: [9fans] APE: a further note.

2010-04-15 Thread erik quanstrom
On Thu Apr 15 14:52:12 EDT 2010, benave...@gmail.com wrote: -T with in APE for lunix code doesn't cut it without hand editing tons of it, there's always a function prototype missing or even conflicting... hand depending on the size of the project it can be unmanageable... excellent reason to