Pike-devel

pike-devel@lists.lysator.liu.se

3044 discussions

MySQL V4
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 14 Apr '03

14 Apr '03

I have reverted the MySQL V4 changes to 7.4, since they stopped Pike from working with MySQL V3. In the future, please put experimental changes into 7.5, and then backport them after they have been proven correct by pikefarm.

1 0

MIME multipart message improperly terminated bug [3414]
by Martin Nilsson (har bott i google) ＠ Pike (-) developers forum 14 Apr '03

14 Apr '03

Spontaneous thought; Caudium truncates the data it sends to MIME (timeout?). Wasn't this a also problem in WebServer that has been fixed? / Martin Nilsson (har bott i google) Previous text: >2003-04-13 22:59: >Subject: MIME multipart message improperly terminated bug [3414] >-------------------------------------------------------------------- > > Product: Pike > Version: 7.4 > Component: Modules > Reporter: funk(a)softhome.net > URL: https://community.roxen.com/crunch/show_bug.cgi?id=3414 > >I'm using pike 7.4.21 with the Caudium web server. I've noticed a bug >related to uploading files using MIME attachments. IT seems that small >files work fine, however larger files do not. The web browser keeps saying >it's loading, but the caudium log gives error ouput as follows: > >multipart message improperly terminated ("\r\nContent-Disposition: >form-data; name=\"file\"; filename=\"drummer.png\"\r\nContent-Type: >image/png***Here it shows the text ouput of the file i cut it out to save >lots of space in the bug report*** ) >/usr/local/pike/7.4.21/lib/modules/MIME.pmod/module.pmod:1078: >MIME.Message()->create("-----------------------------47449013511489176341833204461\r\nContent-Disposition: >form-data; name=\"file\"; filename=\"drummer.png\"\r\nContent-Type: >image/png\r\n\r\n\211PNG\r\n\32\n\0\0\0\rIHDR\0\0\1g\0\0\1j\b\6\0"+[16854],mapping[11],0,0) >object_program(MIME): MIME->Message() >protocols/http.pike:200: protocols/http()->handle_body_encoding(21665) >protocols/http.pike:455: protocols/http()->parse_got() >protocols/http.pike:1657: >protocols/http()->got_data(0,"7\366$\336\31t\34\223\245\314)\262r\16\302\361D_\25\36PjZuk\27\7!\301""6\345D9s\224\277\7\341\317N|\24\215\255\234\233\220ES\355\273\274\36\361\310\310\373\354\350u\340-\334\23\212q\210\37\177=\322\216[9\367 >\35\345<\31\231\350\254\t\274\215< >\343\234\261\307J\243(\347\t1\367\347\227V`\245\30\373\253\364\203nD\345\274#\372\33\322?\220\207\\n\177lU<\217\373\\\276A}+g\27q\377\336""5\345\274\21b\352*\323\216\230\275\216#\207o+Y\257\352\247\365e\335\25s\177YQiG\323L2\365ls\326r\253|I\261\24""3\300\177\225\355CS\225\"]4_\347\264"+[1254]) >/usr/local/pike/7.4.21/lib/modules/Stdio.pmod/module.pmod:695: >Stdio.File("socket", "192.168.0.2 58269", 777 /* fd=19 >*/)->__stdio_read_callback() >module.c:58()->Builtin()->Backend: >module.c:58()->Builtin()->__backend->`()(3600.000000) >/usr/local/pike/7.4.21/lib/master.pike:1951: >master()->_main(({"bin/caudium","-DCAUDIUM","-DCAUDIUM_CACHE","-DROXEN","-DMODULE_DEBUG","-w","-Mlib/7.4.21/",,,6}),({"SSH_CLIENT=192.168.0.2 >63575 22","USER=root","MAIL=/var/mail/root","SHLVL=1",,,15})) > >The log keeps repeating this until i press stop in my browser... > >Here i'll include the code i use to upload the images. > >HTML PAGE: > ><form name="imhouploadform" method="POST" enctype="multipart/form-data" >action="/(dumpid)/upload"> ><br /> ><input name="file" type="file"> ><br /> ><input type="submit" name="1" value="Upload to attachments" /> ></form> > >excerpt from Caudium Pike Module: > >mixed find_file( string f, object id ) { > string sucpage = id->variables->success; > string fpage = id->variables->failed; > string contents = id->variables->file; > string filename = id->variables["file.filename"]; > string gallery; > if (id->variables->gallery) > gallery = id->variables->gallery; > else > gallery = QUERY(defaultgallery); > string galpath = Stdio.append_path(QUERY(albumpath), gallery); > string path = Stdio.append_path(QUERY(albumpath), gallery, filename); > if ( contents && filename && Stdio.is_dir(galpath) && >!Stdio.is_file(path) && isgood(filename) && sizeof(contents) < >QUERY(maxsize) ) { > Stdio.write_file ( path, contents ); > return http_string_answer("Upload Succeeded","text/html"); > } > >I hope this helps someone locate and troubleshoot this bug, it's seriously >stumping my productivity... Well thanks for any help. > > > / Brevbäraren >

3 7

PCRE license
by Martin Baehr 11 Apr '03

11 Apr '03

hi, since the inclusion of PCRE is still not done, i want to discuss the one question that has not been conclusively addressed: the license. http://www.pcre.org/license.txt the last discussion ended with the comment that the points 1. 2. and 3. still apply because of the mpl. my opinion is that these points do not conflict with the mpl. and in particular the last paragraph of #2 allows anybody to include pike without limitations through pcre. so the only thing holding us back is someone to take pcre and prepare it for pike 7.5 so that it can be tested... i am repeating the points for your convenience. full license is under the url above. greetings, martin. from: http://www.pcre.org/license.txt 1. This software is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 2. The origin of this software must not be misrepresented, either by explicit claim or by omission. In practice, this means that if you use PCRE in software that you distribute to others, commercially or otherwise, you must put a sentence like this Regular expression support is provided by the PCRE library package, which is open source software, written by Philip Hazel, and copyright by the University of Cambridge, England. somewhere reasonably visible in your documentation and in any relevant files or online help data or similar. A reference to the ftp site for the source, that is, to ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/ should also be given in the documentation. However, this condition is not intended to apply to whole chains of software. If package A includes PCRE, it must acknowledge it, but if package B is software that includes package A, the condition is not imposed on package B (unless it uses PCRE independently). 3. Altered versions must be plainly marked as such, and must not be misrepresented as being the original software.

3 2

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

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