Pike-devel August 2008

pike-devel@lists.lysator.liu.se

8 participants
34 discussions

Overriding type checks in type^H^H^H^Hsoft casts
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 14 Aug '08

14 Aug '08

Consider this condensed case from real code: class A { protected int x; void init (int i) {x = i;} int get() {return x;} } class B { protected int x; void init (string s) {x = (int) s;} int get() {return x;} } A create_a() { B b = B(); b->init ("17"); return [object(A)] b; } In create_a() I try to cheat and return a B as if it were an A, by using a type cast. It doesn't work: /home/mast/foo.pike:19:Soft cast of { B = object(implements /home/mast/foo()->B) } to { A = object(implements /home/mast/foo()->A) } isn't a valid cast. (Side note: This error message doesn't explain why the cast is invalid. Presumably it's due to the prototype of init(), but unlike other type errors it doesn't go into detail.) Let's assume that in this case I know that the type difference of the init() prototype isn't relevant (e.g. it's a function only used in the object factory and therefore never called outside create_a). Shouldn't it be possible to use type casts to make the compiler shut up? I can do this workaround: A create_a() { B b = B(); b->init ("17"); object b2 = b; return [object(A)] b2; } But avoiding that phony extra variable isn't possible; this variant is still nailed: A create_a() { B b = B(); b->init ("17"); return [object(A)] [object] b; }

3 5

Re: 7.8 alpha 2
by Lance Dillon 14 Aug '08

14 Aug '08

I'm not sure it is only a 64-bit problem. I have this [root@hobbes ~]# cat /proc/version Linux version 2.6.25.14-108.fc9.x86_64 (mockbuild@) (gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) ) #1 SMP Mon Aug 4 13:46:35 EDT 2008 [root@hobbes ~]# [root@hobbes ~]# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 107 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ but mine didn't fail: [riffraff@hobbes Pike-v7.8.8]$ pike Pike v7.8 release 8 running Hilfe v3.5 (Incremental Pike Frontend) > Image.TIFF; (1) Result: _Image_TIFF > string s=Stdio.read_bytes("/usr/share/sane/xsane/doc/xsane-restore.jpg"); > object i=Image.JPEG.decode(s); > i; (2) Result: Image.Image( 26 x 26 /* 2.0Kb */) > Image.JPEG.encode(i); (3) Result: "\377\330\377\340\0\20JFIF\0\1\1\0\0\1\0\1\0\0\377\333\0C\0\b\6\6\a\6\5\b\a\a\a\t\t\b\n" ... ----- Original Message ---- From: "Mirar @ Pike developers forum" <10353(a)lyskom.lysator.liu.se> To: pike-devel(a)lists.lysator.liu.se Sent: Thursday, August 14, 2008 8:15:03 AM Subject: 7.8 alpha 2 That it's a 64-bit-only problem, I mean. Hmm. But... | > string s = Stdio.read_bytes("sugar.jpg"); | > object i = Image.JPEG.decode(s); | >> i; | (1) Result: Image.Image( 300 x 300 /* 263.7Kb */) | > Image.JPEG.encode(i); | *** glibc detected *** pike: munmap_chunk(): invalid pointer: 0x0000000000a9b5d0 | *** | ======= Backtrace: ========= | /lib/libc.so.6(cfree+0x1b6)[0x2ba515677d46] | /usr/lib/libjpeg.so.62[0x2ba516a52ffa] | /usr/lib/libjpeg.so.62(jpeg_abort+0x15)[0x2ba516a52505] | /usr/local/pike/7.7.133/lib/modules/_Image_JPEG.so[0x2ba51681b888] | pike(low_mega_apply+0x598)[0x434908] | ... [ http://www.mirar.org/sugar.jpg ]

2 2

7.8 alpha 2
by Mirar ＠ Pike developers forum 14 Aug '08

14 Aug '08

And still no test case. :p | iris% cat test_jpeg.pike | int main() | { | string s = Stdio.read_bytes("sugar.jpg"); | object i = Image.JPEG.decode(s); | string out = Image.JPEG.encode(i); | write("%O\n",out[..5]); | return 0; | } | iris% pike test_jpeg.pike | "\377\330\377\340\0\20"

1 0

7.8 blockers
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 14 Aug '08

14 Aug '08

Fixed that some time ago. Forgot to update the list. Sorry.

1 0

Pike git tracking repository is up
by Stephen R. van den Berg 12 Aug '08

12 Aug '08

For Pike there is a CVS-tracking git repository now which checks pikefarm for updates every minute. - The repository trails pikefarm by a minute of 4 tops for 7.8 (and 7.9). - It is synced daily at 06:00 for all other branches. - It has been pruned of all unnecessary branches and contains the repository proper now. - It basically is the version previously at git://git.cuci.nl/pike (which will continue to exist). - This is by no means the "final" version, things are still being tweaked (not in this version), but it works fine for current developmentwork. Suggested way of getting it: git clone git://pike-git.lysator.liu.se/pike cd pike for b in 7.8 7.6 7.4 7.2 7.0 0.6 0.5 nt-tools extra_tests do git branch $b origin/$b done git branch Sync at any later point with upstream: git pull (or just "git fetch" which doesn't alter your tracking branches) -- Sincerely, Stephen R. van den Berg. Father's Day Special at the local clinic -- Vasectomy!

3 2

Split me harder :-)
by Stephen R. van den Berg 12 Aug '08

12 Aug '08

Congratulations on a succesful move to 7.8. The git repositories have already been adjusted to track the new 7.8 tree. I'm in the process of setting up a tracking git on git clone git://pike-git.lysator.liu.se/pike as soon as Peter starts the ssh daemon there :-). It will be a copy of git://git.cuci.nl/pike excluding my personal branches (of course). -- Sincerely, Stephen R. van den Berg. Father's Day Special at the local clinic -- Vasectomy!

1 0

cvs build fails and where is the git repo?!
by Arne Goedeke 11 Aug '08

11 Aug '08

I was trying to build pike 7.7 from cvs and it failed when running configure for the Pipe module. There it complains that sources (interpret.c) are missing. === configuring in Pipe (/home/el/src/Pike/7.7/build/linux-2.6.25-gentoo-r7-i686/modules/Pipe) configure: running /bin/sh /home/el/src/Pike/7.7/src/modules/../configure '--prefix=/usr/local' --cache-file=../.././config.cache --srcdir=/home/el/src/Pike/7.7/src/modules/Pipe configure: error: cannot find sources (interpret.c) in /home/el/src/Pike/7.7/src/modules/Pipe configure: error: /home/el/src/Pike/7.7/src/modules/../configure failed for Pipe configure: error: /home/el/src/Pike/7.7/src/modules/configure failed for modules It seems like interpret.c is the default.. however it should be overwritten by that AC_INIT(pipe.c) in configure.in, afaik. something unrelated: I have a copy of the bugless git repo that compiles but has a missing specs file. I put one there (replacing the path and such) but cannot build cmods using pike -x: ** Old style module ** Running autoconf (with extra compat macros) autoconf --include=/home/el/src/pn.git/build/linux-2.6.25-gentoo-r7-i686/bundles/include/pike configure.in:4: error: possibly undefined macro: AC_MODULE_INIT If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. The module builds correctly using a pike 7.6. Also.. whats the url of a current working git repo, I got mine using rsync and cannot update because origin seems to be old/wrong. arne

8 29

resolv
by Mirar ＠ Pike developers forum 10 Aug '08

10 Aug '08

3 3

resolv
by Mirar ＠ Pike developers forum 10 Aug '08

10 Aug '08

all_constants() even. And you have to use both if you want to look for something that *can* become a constant?

1 0

eol-style properties
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 06 Aug '08

06 Aug '08

I added some logging to the subversion export script to find which files were modified by the end-of-line normalization. The complete list is currently as follows: nt-tools/init_nt nt-tools/tools/lib These are a bit special in that they use LF line terminations, but contain literal CR characters on some lines as part of shell arguments. I think it's safest to simply remove the eol-style property on these particular files, and treat them as "binary". packaging/fink/README packaging/fink/nettle.info packaging/fink/pike7.6.info The newest versions of these files in 7.6 use CRLF line terminations, but I think that is an accident, as the earlier versions did not, and neither do those which are currently in 7.7. Comments from fink people? packaging/windows/Copying.txt packaging/windows/finalizer.pike packaging/windows/nilsson-pike.iss packaging/windows/pike.iss These are used to create Windows dists, potentially from trees checked out on Unix, so CRLF eol-style is probably best here. For the ISS files it might even be required. I'll change the property. src/UnicodeData-ReadMe.txt src/UnicodeData.txt The earliest versions of the Unicode database used CRLF line terminations, but everything since Unicode 3.1.0 was imported using LF line terminations. Normalizing should be safe, but to be historically accurate I could set CRLF eol-style on those old versions. It would mainly affect 7.0 and older which still have the old Unicode versions at HEAD. src/modules/_Crypto/rijndael_cbc_d_m.txt src/modules/_Crypto/rijndael_cbc_e_m.txt src/modules/_Crypto/rijndael_ecb_d_m.txt src/modules/_Crypto/rijndael_ecb_e_m.txt src/modules/_Crypto/rijndael_ecb_iv.txt src/modules/_Crypto/rijndael_ecb_tbl.txt src/modules/_Crypto/rijndael_ecb_vk.txt src/modules/_Crypto/rijndael_ecb_vt.txt These used to have CRLF line terminations, but were explicitly changed to LF in the last day of 2001 (commit by nilsson). The file rijndaeltest.pike which uses these files has the corresponding line termination hardcoded in, so native eol-style will not work here. I'll change it to CRLF eol-style for the old versions, and LF eol-style for the newer. This only affects 7.4. src/post_modules/Nettle/byte-hashes.sha1 src/post_modules/Nettle/byte-messages.sha1 These have CRLF line terminations, but sha1test.pike which uses them strips all CR characters before processing, so either LF or CRLF terminations should work equally well. Unless someone protests, I'll keep native eol-style and perform the normalization for these files. src/post_modules/COM/examples/ads.pike src/post_modules/COM/examples/shelltest.pike src/post_modules/COM/examples/word.pike src/post_modules/COM/examples/word2.pike These have CRLF line terminations, presumably because they have been developed on Windows. Since they are pike scripts, the line termination chosen will not affect their function. So the question is whether there is a compelling reason to have CRLF terminations in these particular files even when checked out on Unix. Comments?

4 12

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 August 2008