Pike-devel April 2003

pike-devel@lists.lysator.liu.se

11 participants
55 discussions

dirnode(0,0)
by Martin Nilsson (har bott i google) ＠ Pike (-) developers forum 09 Apr '03

09 Apr '03

In my effort to try to reduce the amount of magic in Pike I set out to remove the compatibility kludge in Sql.pmod/module.pmod. However, I fail to get the real compatibility system to work. I've tried both placing a Sql.pmod and a Sql.pmod/module.pmod in the 7.4-compat dir, but I end up with having a dirnode cloned with only zero as arguments, which of course breaks things. Can someone with more master mastering take a closer look at what is the problem?

1 0

First Opteron?
by David Hedbor ＠ Pike developers forum 08 Apr '03

08 Apr '03

Well, I think I have added the first opteron to the build farm. :)

8 26

_Charset
by Martin Nilsson (har bott i google) ＠ Pike (-) developers forum 08 Apr '03

08 Apr '03

Appearantly there's a lot of people that doesn't feel that there is enough character encodings available. I've run through the IANA list of characters encoding alias and come up with a list of encodings that Pike does not support. If you're looking for a bitesized project to spend some minutes on, then this list is a todo for you ;) I've listed them approximately in order of standard accessibility and interest of inclusion in Pike. Lets start with the RFCs. We do want to support the RFCs. RFC1345: us-dk dk-us MNEMONIC (mnemonic+ascii+38) MNEM (mnemonic+ascii+8200) RFC1428: UNKNOWN-8BIT RFC1456: VISCII VIQR RFC1556: ISO_8859-6-E ISO_8859-6-I ISO_8859-8-E ISO_8869-8-I RFC1641: UNICODE-1-1 RFC1642: UNICODE-1-1-UTF-7 RFC1815: ISO-10646-Unicode-Latin1 ISO-10646-J-1 RFC1842,1843: HZ-GB-2312 Then the nice people at Unicode never stops to impress each other with new and wider encodings of new and wider characters. We should probably try to support these as well. Unicode TR19 (http://www.unicode.org/unicode/reports/tr19) UTF-32 UTF-32BE UTF-32LE Unicode TR26 (http://www.unicode.org/unicode/reports/tr26) CESU-8 Unicode TN6 (http://www.unicode.org/notes/tn6/) BOCU-1 IANA is the one that registers "legal" charsets to be used in XML documents and emails and other stuff people use, so we should make an attempt to support these as well. When reading these granted applications you really would like to write an RFC that forces people to write better applications (Oh, wait. Someone did (2278), but didn't bother update the old information) http://www.iana.org/assignments/charset-reg/IBM00858 http://www.iana.org/assignments/charset-reg/IBM00924 http://www.iana.org/assignments/charset-reg/IBM01140 http://www.iana.org/assignments/charset-reg/IBM01141 http://www.iana.org/assignments/charset-reg/IBM01142 http://www.iana.org/assignments/charset-reg/IBM01143 http://www.iana.org/assignments/charset-reg/IBM01144 http://www.iana.org/assignments/charset-reg/IBM01145 http://www.iana.org/assignments/charset-reg/IBM01146 http://www.iana.org/assignments/charset-reg/IBM01147 http://www.iana.org/assignments/charset-reg/IBM01148 http://www.iana.org/assignments/charset-reg/IBM01149 http://www.iana.org/assignments/charset-reg/Big5-HKSCS http://www.iana.org/assignments/charset-reg/PTCP154 http://www.iana.org/assignments/charset-reg/SCSU http://www.iana.org/assignments/charset-reg/GBK http://www.iana.org/assignments/charset-reg/GB18030 Charsets thought up at ISO are also legal in IANAs eyes. I have no reference for these, but I guess that you either pay ISO money or google. ISO-8859-16 ISO-10646-UCS-Basic "ASCII subset of Unicode. Basic Latin = collection 1 See ISO 10646, Appendix A" Now we are in the land of really bizzare, but granted, character encodings. HP PCL 5 Comparison Guide (P/N 5021-0329): IBM775 (pp B-13, 1996) ISO-8859-1-Windows-3.0-Latin-1 (PCL id 9U) ISO-8859-1-Windows-3.1-Latin-1 (PCL id 19U) ISO-8859-2-Windows-Latin-2 (PCL id 9E) ISO-8859-9-Windows-Latin-5 (PCL id 5T) Ventura-US (PCL id 14J) Ventura-International (PCL id 13J) PC8-Danish-Norwegian (PCL id 11U) PC8-Turkish (PCL id 9T) HP-Legal (PCL id 1U) HP-Pi-font (PCL id 15U) HP-Math8 (PCL id 8M) HP-DeskTop (PCL id 7J) Ventura-Math (PCL id 6M) Microsoft-Publishing (PCL id 6J) Post Script Language Reference by Adobe Systems Incorporated, Addison-Wesley, 1990: Adobe-Standard-Encoding (PCL id 10J) Adobe-Symbol-Encoding (PCL id 5M) ABOUT TYPE: IBM's Technical Reference for Core Interchange Digitized Type, publication number S544-3708-01: IBM-Symbols (CPGID 259) IBM-Thai (CPGID 838) Thai Industrial Standards Institute (TISI): TIS-620 These encodings has no standard reference, but is only described in the IANA list of character encodings. ISO-10646-UTF-1 "Universal Transfer Format (1), this is the multibyte encoding, that subsets ASCII-7. It does not have byte ordering issues." ISO-10646-UCS-2 "the 2-octet Basic Multilingual Plane, aka Unicode this needs to specify network byte order: the standard does not specify (it is a 16-bit integer space)" ISO-10646-UCS-4 "the full code space. (same comment about byte order, these are 31-bit numbers." JIS_Encoding "JIS X 0202-1991. Uses ISO 2022 escape sequences to shift code sets as documented in JIS X 0202-1991." Extended_UNIX_Code_Fixed_Width_for_Japanese "Used in Japan. Each character is 2 octets. code set 0: US-ASCII (a single 7-bit byte set) 1st byte = 00 2nd byte = 20-7E code set 1: JIS X0208-1990 (a double 7-bit byte set) restricted to A0-FF in both bytes code set 2: Half Width Katakana (a single 7-bit byte set) 1st byte = 00 2nd byte = A0-FF code set 3: JIS X0212-1990 (a double 7-bit byte set) restricted to A0-FF in the first byte and 21-7E in the second byte" ISO-Unicode-IBM-1261 "IBM Latin-2, -3, -5, Extended Presentation Set, GCSGID: 1261" ISO-Unicode-IBM-1268 "IBM Latin-4 Extended Presentation Set, GCSGID: 1268" ISO-Unicode-IBM-1276 "IBM Cyrillic Greek Extended Presentation Set, GCSGID: 1276" ISO-Unicode-IBM-1264 "IBM Arabic Presentation Set, GCSGID: 1264" ISO-Unicode-IBM-1265 "IBM Hebrew Presentation Set, GCSGID: 1265" Windows-31J "Windows Japanese. A further extension of Shift_JIS to include NEC special characters (Row 13), NEC selection of IBM extensions (Rows 89 to 92), and IBM extensions (Rows 115 to 119). The CCS's are JIS X0201:1997, JIS X0208:1997, and these extensions. This charset can be used for the top-level media type "text", but it is of limited or specialized use (see RFC2278). PCL Symbol Set id: 19K" The charset IBM1047 (EBCDIC Latin 1/Open Systems) has a standard reference to a pdf on an IBM server. This URL now produces 404. Finally, for the interested, of the 802 registered IANA encodings and aliases Pike supports 626, given my Hilfe commands were bug free.

2 1

Pike roadmap
by Johan Sundstr�m (folksk�dare) ＠ Pike (-) developers forum 07 Apr '03

07 Apr '03

We recently had a very inofficial real life discussion on the topic of a roadmap for Pike, and started bundling our ideas off the top of our heads. Further discussion is necessary, but to start off somewhere, here is our initial draft of things we find worth pursuing in the near future (say, within the scope of 7.5). What follows might need a correction or two of what was really meant by whomever said what and some of the issues are probably just another way of phrasing earlier ones. (I trust there will be keen minds busy rectifying what came out weird in my scratch pad. :-) * Improve the structure of the Pike header files - providing a more defined API for 3rd party pike module authors (today, this is essentially things marked PMOD_EXPORT) - specify an API we intend to be binary compatible with - make a pike lib with a version number - separate the low level implementation details from semantics - easen core changes without the need for recompiling all modules - address the valgrind dependency problem - split configure into two parts; one for the pike, one per module - rename ac_module_init to pike_module_init (we should not borrow autoconf namespace inappropriately) - the environment passing between makefiles and configure is hairy and could use a healthy refactoring * Extend pikedoc to handle c level APIs, and document them

3 3

`-=
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 07 Apr '03

07 Apr '03

Why does Parser.Pike accept a bunch of backquote identifiers that don't correspond to any lfuns and that pike itself doesn't accept? The reason I found this is because post_modules/_ADT/sequence.cmod tries to define an lfun `-=. That's currently meaningless since it will never be called, but perhaps the intention is to prepare for a future extension. Anyway, it means that 7.5 currently can't use a 7.4 Pike for precompilation, which I think should be possible. Maybe the stuff in precompile.sh.in that made older pikes use the latest parser modules should be resurrected.

5 11

Do we have a floatingpoint bug?
by Marcus Agehall (Tr�dl�s) ＠ Pike (-) developers forum 06 Apr '03

06 Apr '03

Yesterday I had to write a program which rescaled and rounded off some coordinates for use in a lab. I found something that worries me quite a bit: ({ /* 22 elements */ ({ /* 2 elements */ 639.000000, 37.000000 }), ({ /* 2 elements */ 426.000000, 99.000000 }), ({ /* 2 elements */ 538.000000, 103.000000 }), ({ /* 2 elements */ 698.000000, 105.000000 }), ({ /* 2 elements */ 813.000000, 104.000000 }), ({ /* 2 elements */ 480.000000, 199.000000 }), ({ /* 2 elements */ 633.000000, 195.000000 }), ({ /* 2 elements */ 780.000000, 196.000000 }), ({ /* 2 elements */ 480.000000, 304.000000 }), ({ /* 2 elements */ 636.000000, 308.000000 }), ({ /* 2 elements */ 785.000000, 309.000000 }), ({ /* 2 elements */ 425.000000, 388.000000 }), ({ /* 2 elements */ 536.000000, 397.000000 }), ({ /* 2 elements */ 700.000000, 401.000000 }), ({ /* 2 elements */ 814.000000, 399.000000 }), ({ /* 2 elements */ 625.000000, 457.000000 }), ({ /* 2 elements */ 480.000000, 252.000000 }), ({ /* 2 elements */ 633.000000, 256.000000 }), ({ /* 2 elements */ 780.000000, 259.000000 }), ({ /* 2 elements */ 480.000000, 349.000000 }), ({ /* 2 elements */ 636.000000, 347.000000 }), ({ /* 2 elements */ 785.000000, 358.000000 }) }) ({ /* 22 elements */ ({ /* 2 elements */ 63.900002, 3.700000 }), ({ /* 2 elements */ 42.599998, 9.900000 }), ({ /* 2 elements */ 53.799999, 10.300000 }), ({ /* 2 elements */ 69.800003, 10.500000 }), ({ /* 2 elements */ 81.300003, 10.400000 }), ({ /* 2 elements */ 48.000000, 19.900000 }), ({ /* 2 elements */ 63.299999, 19.500000 }), ({ /* 2 elements */ 78.000000, 19.600000 }), ({ /* 2 elements */ 48.000000, 30.400000 }), ({ /* 2 elements */ 63.599998, 30.799999 }), ({ /* 2 elements */ 78.500000, 30.900000 }), ({ /* 2 elements */ 42.500000, 38.799999 }), ({ /* 2 elements */ 53.599998, 39.700001 }), ({ /* 2 elements */ 70.000000, 40.099998 }), ({ /* 2 elements */ 81.400002, 39.900002 }), ({ /* 2 elements */ 62.500000, 45.700001 }), ({ /* 2 elements */ 48.000000, 25.200001 }), ({ /* 2 elements */ 63.299999, 25.600000 }), ({ /* 2 elements */ 78.000000, 25.900000 }), ({ /* 2 elements */ 48.000000, 34.900002 }), ({ /* 2 elements */ 63.599998, 34.700001 }), ({ /* 2 elements */ 78.500000, 35.799999 }) }) [agehall@omicron ~] pike --version Pike v7.5 release 1 Copyright © 1994-2002 Linköping University Pike comes with ABSOLUTELY NO WARRANTY; This is free software and you are welcome to redistribute it under certain conditions; Read the files COPYING and COPYRIGHT in the Pike distribution for more details. The first array(array(float)) are the values as read from the file. The second array(array(float)) contains the values divided by 10. Note how some numbers become +-0.000001. This is very strange and not very good at all... I am able to reproduce the bug by doing > 358.0/10; (1) Result: 35.799999 on both my PPro/Linux running Pike 7.5 and a Sun/Solaris running Pike 7.3. Is this a known bug and is there a workaround?

18 125

Predictable gc == manual
by David Hedbor ＠ Pike developers forum 05 Apr '03

05 Apr '03

Is there functionality to disable all automatic gc() without actually hardcoding it in the code? In certain cases, say if you make a game (no, I don't have an actual project - it's theoretical), you definitely would want to limit gc to predictable times (such as right after loading a new level - get any gc needed from the level loading and the previous level).

4 7

icc & INT64
by Mirar ＠ Pike developers forum 05 Apr '03

05 Apr '03

I see that icc no longer can compile long-long-int Pike's. [...]Gmp/mpz_glue.c(207): error: identifier "_I64_MIN" is undefined *i = MIN_INT64; ^ [...]Gmp/mpz_glue.c(210): error: identifier "_I64_MIN" is undefined *i = neg ? MIN_INT64 : MAX_INT64; ^ [...]Gmp/mpz_glue.c(210): error: identifier "_I64_MAX" is undefined *i = neg ? MIN_INT64 : MAX_INT64; ^ Did anyone do anything to how MAX & MIN_INT64 was defined?

2 2

Autodoc
by Martin Nilsson (har bott i google) ＠ Pike (-) developers forum 04 Apr '03

04 Apr '03

To all of you that helps out with the important tak of improving the Pike documentation (three, or so, people): The code/tt markup is now as follows. General computer-stuff should be marked with @tt, e.g. @tt{--help@}, @tt{/bin/sh@}, @tt{POST@}. Code expressions in flowing text should be marked with @expr, e.g. @expr{7@}, @expr{"POST"@}, @expr{i=i++;@}. Code expressions may be broken into several lines, as can @tt, but we have the possibility to break the expressions between tokens instead of at white spaces. Code snippets should be marked with @code, e.g. @code int i=4; i=i++; @endcode

3 5

7.4.20
by Johan Sundstr�m (folksk�dare) ＠ Pike (-) developers forum 04 Apr '03

04 Apr '03

A small heads up before airing on the Pike list; we have put up a 7.4.20 dist on the site now, and are busy preparing some binary dists for linux-ppc and solaris-8-sparc. Linux-x86 is already available. ftp://pike.ida.liu.se/pub/pike/latest-stable/Pike-v7.4.20.tar.gz Feel free to contribute a binary dist for your platform too; just make bin_export and upload the result along with your config.info to ftp://pike.ida.liu.se/incoming/. And thanks in advance. :-)

5 10

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 April 2003