Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

Start a nNew thread

Pike tutorial
by Martin Nilsson (hehe Torgny) ＠ Pike (-) developers forum 13 Dec '02

13 Dec '02

But it's the wrong shade of blue to fit the page perfectly.

2 1

incorrect rfc2047 MIME decoding?
by Dan Nelson 12 Dec '02

12 Dec '02

It looks like MIME.decode_words_text_remapped eats spaces in places it shouldn't: > MIME.decode_words_text_remapped("=?ISO-8859-1?Q?a?= b c =?ISO-8859-1?Q?d?="); (17) Result: "ab cd" The result should have been "a b c d". Whitespace is only supposed to be removed between adjacent encoded-words (section 6.2). Maybe the samples from rfc2047 should be added to the MIME testsuite?

3 9

incorrect rfc2047 MIME decoding?
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 12 Dec '02

12 Dec '02

In face, the examples _only_ deal with _comments_ in structured fields. Here, you are correct in that the handling is incorrect though: > MIME.decode_words_tokenized_labled_remapped("(=?ISO-8859-1?Q?a?= b)"); (9) Result: ({ /* 1 element */ ({ /* 2 elements */ "comment", "ab" }) }) > Here, the example says that the command should be decoded as "a b", so the result is wrong.

1 2

gcc 3.2
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 12 Dec '02

12 Dec '02

But then you better use --without-machine-code too, since valgrind gets very confused when machine code is overwritten.

6 8

Pike 7.4
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 12 Dec '02

12 Dec '02

I have a suggestion: Before committing changes to the compiler in the stable version of Pike, check that "make verify" passes.

4 12

gcc 3.2
by Mirar ＠ Pike developers forum 12 Dec '02

12 Dec '02

Maybe I should throw away -mcpu and -march with --without-copt?

5 9

lurigt
by Mirar ＠ Pike developers forum 12 Dec '02

12 Dec '02

Sorry, I'll translate: Recursion seems to behave funny in a normal-optimized Pike. I run the test I wrote earlier on 1) my valgrind-deoptimized Pike and 2) my normal optimized one: test 1) 2) Pike start overhead........ 0.000s 0.000s Ackermann.................. 1.172s 0.576s Array & String Juggling.... 0.693s 0.636s Compile.................... 1.393s 1.010s Compile & Exec............. 1.383s 1.018s Matrix multiplication...... 0.968s 0.407s Loops Nested............... 0.762s 0.292s Loops Recursed............. 1.090s 1.625s <- Why is the normal one *that* slow? The funniest of it all is that Ackermann isn't slow at all.

1 0

lurigt
by Mirar ＠ Pike developers forum 12 Dec '02

12 Dec '02

Rekursion verkar lite lurigt i en normal Pike. Jag körde tested jag gjorde tidigare på min valgrind-deoptimerade pike och min normala: test 1) 2) Pike start overhead........ 0.000s 0.000s Ackermann.................. 1.172s 0.576s Array & String Juggling.... 0.693s 0.636s Compile.................... 1.393s 1.010s Compile & Exec............. 1.383s 1.018s Matrix multiplication...... 0.968s 0.407s Loops Nested............... 0.762s 0.292s Loops Recursed............. 1.090s 1.625s <- Varför är den normala *så* långsam där? Det lurigaste är att Ackermann inte alls är lika långsam.

1 0

gcc 3.2
by Mirar ＠ Pike developers forum 11 Dec '02

11 Dec '02

Now gcc 3.2 bit me and allowed code before declaration. Any flags you can add to CFLAGS to not allow that sort of evilness?

10 44

Removed need for cflags_make_conf kludge.
by Mirar ＠ Pike developers forum 11 Dec '02

11 Dec '02

Never mind, I solved it using the optimize/cflags split loop to only use the first mentioned -O, -march and -mcpu.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pike-devel