Pike-devel

pike-devel@lists.lysator.liu.se

2 participants
3046 discussions

Codepage decoding tables have incorrect data
by Chris Angelico 04 Aug '14

04 Aug '14

Was doing some codepage work (playing with CP437), and found that the Pike CP-437 decoder actually produces wrong output, according to the unicode.org template file. I'm not sure what's going on here; is there some alternate standard that it's adhering to? Here are two scripts to compare codepage decoding in Pike and Python: int main(int argc,array(string) argv) { object decoder=Charset.decoder(argv[1]); for (int byte=128;byte<255;++byte) write("%02x: %04x\n",byte,decoder->feed((string)({byte}))->drain()[0]); } import sys for byte in range(128,255): print("%02x: %04x"%(byte,ord(bytes([byte]).decode(sys.argv[1],errors="replace")))) $ diff <(pike charsets.pike 437) <(python3 charsets.py 437) This should in theory be absolutely silent, but in practice it reports a number of differences in the decode. Wikipedia cites a file on www.unicode.org as its source: http://en.wikipedia.org/wiki/Code_page_437 http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/PC/CP437.TXT and that file agrees with Python's decoding. I've put together a script to download a file from the above URL and patch the info into the appropriate place in src/modules/_Charset/misc.c, and have run it on everything in the MICSFT/PC/ directory; the resulting patch is attached, as is a patch to create that file. ChrisA

2 2

Ancient touch syntax
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 03 Aug '14

03 Aug '14

You use an obsolete touch syntax in src/Makefile.in. Current GNU touch apparently won't recognize it unless _POSIX2_VERSION is set to 199209. (For some reason, building 7.8.866 from exported source still works, but when I tried building 8.0.2 the same way (I used make snapshot_export), the rebuilding of interpret_functions.h failed since precompile.sh couldn't find pike, which shouldn't be surprising since it's not built yet at that point, is it?) Do you know any relevant systems where the following, which is POSIX.1-2001, wouldn't work? --- a/src/Makefile.in +++ b/src/Makefile.in @@ -1357,7 +1357,7 @@ precompile.sh: $(SRCDIR)/precompile.sh.i # recursive use of make. precompile.sh-stamp: @if [ -f precompile.sh ]; then :; else $(MAKE) precompile.sh; fi - @touch 0101010185 precompile.sh-stamp 2>/dev/null + @touch -t 198501010101 precompile.sh-stamp 2>/dev/null $(SRCDIR)/machine.h.in: $(SRCDIR)/stamp-h.in @if test -f $(SRCDIR)/machine.h.in; then :; else \

1 0

Redefinition of size_t
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 03 Aug '14

03 Aug '14

This should work? --- Pike-v7.8.866.orig/src/modules/_Image_JPEG/transupp.c +++ Pike-v7.8.866/src/modules/_Image_JPEG/transupp.c @@ -36,17 +36,7 @@ * of internals, and added inclusion of jerror.h */ -#define FILE void -#define size_t unsigned int -/* NOTE: INT32 and INT16 are redefined by <jmorecfg.h>. */ -#if 0 -#ifdef INT16 -#undef INT16 -#endif /* INT16 */ -#ifdef INT32 -#undef INT32 -#endif -#endif /* 0 */ +#include <stdio.h> #define XMD_H /* Avoid INT16 / INT32 being redefined */

2 2

Possible bug in Gz with latest Pike 7.8.866 Windows?
by Chris Angelico 29 Jul '14

29 Jul '14

Not sure how to diagnose this. Test case: int main() { string zip="E\217Aj\3""1\fE\367s\212OV-\204\\\243\27\310\276(cMF\240X\306\226;8\247\217fh\323\225\340\363y\377\351\272JC\222\312\263[\35\230)\343\306\350\215\23\26\253P\233IQ\264\337%\267""3\266U\346\25T\31\331\34\205\252\303\26\370\312x\220\344\351k\224\326\37\250\\\254\311\316\273\340\272\362\300&\252;V\215R\200iq\256 }\203!\371\r\371\313\246\177\251\217\324\31nQ\t\327\33K\276\207\247j\220N\317\347\367\241x\2\345\24\205\336\320\254\372^Qj\376y\336\363\351\330\317\374\23\253aaq\267*\356\34\277\216(\f\364\222\310\217\215\337\27\304\33\353r\231^"; object infl=Gz.inflate(-15); string data=infl->inflate(zip); write("Inflated %d bytes to %d; end-of-stream ought to be \"\": %O\n",sizeof(zip),sizeof(data),infl->end_of_stream()); } Yeah, that's hardly minimal, sorry. It does seem to be data-dependent. On Pike 8.0 on Linux, this produces: Inflated 185 bytes to 287; end-of-stream ought to be "": "" This is correct. The given byte stream is a complete deflation sequence, and end-of-stream is reached with no additional data. Pike 7.8.866 on Windows (the current .msi) says 0 at the end, instead - implying that it's still looking for more data. I'm no expert on compression algorithms, so I have no idea what's going on here. Is it some kind of weird bug in zlib? ChrisA

2 2

Re: Pike 7.8.866 for Windows
by Peter Bortas 24 Jul '14

24 Jul '14

*checks* No, I'm quite sure the last win32 build I did was 7.8.856. -- Peter Bortas On Wed, Jul 23, 2014 at 11:35 PM, Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > Don't you mean 7.8.866?

1 0

Pike 7.8.866 for Windows
by H. William Welliver III 24 Jul '14

24 Jul '14

After a few weeks of messing around with libraries, I’ve got a windows build of Pike with a reasonably complete set of modules ready for testing. Please have a look and let me know if there are any problems or modules that would be advantageous to add. Pike-v7.8.866-win32.msi Thanks in advance! Bill Software......Pike Version.......Pike v7.8 release 866 WWW...........http://pike.ida.liu.se/ pike binary...c:\Program Files\pikeq\bin\pike.exe master.pike...: c:\Program Files\pikeq\bin/../lib/master.pike Module path...: C:/Program Files/PikeQ/lib/modules Include path..: C:/Program Files/PikeQ/lib/include Program path..: Features......auto_bignum machine_code dynamic_modules threads out-of-band_data COM GL GTK2 Gettext Gmp Gz HTTPAccept Image.FreeType Image.GIF Image.JPEG Image.PNG Image.TIFF Image.TTF Image.XFace Java Java.NATIVE_METHODS MIME Mysql Nettle Odbc PGsql Regexp.PCRE Regexp.PCRE.Widestring SQLite Standards.JSON WhiteFish

4 4

Hello
by Guillaume Collet 23 Jul '14

23 Jul '14

Hi, my name is Guillaume Collet, I'm a french bioinformatician interested in Pike. This message was just to introduce myself. I write C/C++ for for 10 years and I found Pike's features really interesting. That's why I'm here. Cheers, Guillaume.

4 7

Re: Float details
by Mirar ＠ Pike developers forum 09 Jul '14

09 Jul '14

Which serialization? Doesn't ASN.1 have a string format for floats if you want (third byte with value 3 followed by the string)?

2 1

Float details
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 04 Jul '14

04 Jul '14

So -0.0 is a thing. Should we fix any of these: > -0.0; (1) Result: -0.0 > equal(-0.0, 0.0); (2) Result: 1 > decode_value(encode_value(-0.0)); (3) Result: 0.0 > -0.0 < 0.0; (4) Result: 0

2 1

Build fail
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 27 Jun '14

27 Jun '14

Did you run ./run_autoconfig ? It seems configure thinks that its a good idea to rerun the main script in subdirectories that don't have their own configure scripts...

1 0

Jump to page:

2026

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