Pike-devel December 2002

pike-devel@lists.lysator.liu.se

5 participants
68 discussions

Start a nNew thread

rsqld
by Martin Nilsson (alldaglig sebra-mongo) ＠ Pike (-) developers forum 17 Dec '02

17 Dec '02

Do we really want rsqld in Standalone? Doesn't that imply that we have to maintain it?

4 10

rsqld
by Martin Nilsson (alldaglig sebra-mongo) ＠ Pike (-) developers forum 17 Dec '02

17 Dec '02

Ah, that's how.

1 0

Java / testing for a working ls and Darwin 6.2 / Mac OS X Jaguar
by Xavier Beaudouin 17 Dec '02

17 Dec '02

Hello, I was wondering why Java was not working in Pike 7.4 and 7.5 under Jaguar... First test from me found that checking for a working ls didn't work like autoconf script likes... In fact in Java configure.in the following : if /bin/ls ./fnord/fnord/fnord/fnurkelfoo 2>/dev/null; then : else : pike_cv_ls="$ac_dir"/ls fi is never correctly checked in Darwin as you can see in this simple example : > kiwi@blackmagic:~/cvs/pike/Pike/7.4/src/modules/Java$ if /bin/ls > ./fnord/fnord ; > > then > > echo oo > > else > > echo zz > > fi > /bin/ls: ./fnord/fnord: No such file or directory > oo > kiwi@blackmagic:~/cvs/pike/Pike/7.4/src/modules/Java$ So this is really sure that /bin/ls will never be find for checking Java. Yes this is I think a bug from Darwin 6.2 /bin/ls but we have to find a workaround for this... Any ideas ? /Xavier

2 2

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

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 December 2002