Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

Start a nNew thread

MySQL configure-script is borken
by Marcus Agehall (Tr�dl�s) ＠ Pike (-) developers forum 29 Jan '03

29 Jan '03

And a closer examination of my Pikefarm logs shows that the build done by Pikefarm works correctly! Very strange.

1 0

MySQL configure-script is borken
by Marcus Agehall (Tr�dl�s) ＠ Pike (-) developers forum 29 Jan '03

29 Jan '03

I belive that the configure-script for the MySQL is broken. It does detect my MySQL installation and allows for the module to be compiled, but it doesn't detect the features of the lib correctly. I belive that the problem is that the PIKE_CHECK_MYSQL_FUNC in configure.in somehow doesn't link against the libmysqlclient.so lib. Can somebody confirm this or give me some other explaination of why it won't work?

1 0

Death to strlen! Death to the demoness Allegra Geller!
by Martin Nilsson (�skblod) ＠ Pike (-) developers forum 29 Jan '03

29 Jan '03

I have a theory that strlen is bad. 1. The function itself is completly redundant, since it is a direct alias for sizeof. The language is simpler and faster to learn without strlen. (Although not by much.) 2. We'd like things in Pike to be as general as possible, e.g. + should add any kind of ADT, not just integers. Hence it is bad to make specializations of general functions. 3. As a specialization strlen is flawed, since it accepts nonstring arguments. 4. strlen provides a "transition aid" for C programmers, who can still write strlen and get a somewhat expected result. This advantage is however consumed by the implication that since Pike has strlen and sizeof, and strlen works as in C, sizeof would also work as in C. Proposed course of actions: 1. Document strlen as deprecated. 2. Replace all strlen instances in Pike with sizeof.

9 22

Re: reasons why pike is better than python?
by Mirar ＠ Pike developers forum 29 Jan '03

29 Jan '03

At a closer inspection, it seems that the culprit is that I use |, not +. + is optimized, while | isn't. That should be easy to fix, shouldn't it? (mapping size 100000:) > gauge { m|=([-1:17]); }; Result: 0.160000 > gauge { m=([-2:17])|m; }; Result: 0.170000 > gauge { m+=([-3:17]); }; Result: 0.000000 <- lo! > gauge { m=([-4:17])+m; }; Result: 0.030000

1 0

Re: reasons why pike is better than python?
by Martin Nilsson (�skblod) ＠ Pike (-) developers forum 28 Jan '03

28 Jan '03

Oh, I forgot the subject, but that message happened to be on topic.

1 0

How do you clone a program
by Peta, jo det �r jag ＠ Pike developers forum 28 Jan '03

28 Jan '03

How do you create a object from aprogram in C/CMOD? I've been trying with clone_object() but I just get a NULL value from it.

2 1

Module system and building modules (was Bz2)
by Bill Welliver 28 Jan '03

28 Jan '03

Actually, you're both correct. I worked on that macro as a project to write an autoconf script that installs a pike application, but the issues are still the same when talking about a pike module outside of the pike src tree: 1. identify the pike we want to compile/install for 2. find out where it expects to find its modules (/path/to/pike is often a symlink, so we have to follow that to it's source) 3. find out where its c includes are installed 4. make sure its a version that is supported by the "package", be it a pike c-module or a standalone pike app. No matter how you end up deciding how to manage the namespace, you still have to worry about the problem of configuring, compiling and installing the modules, wherever they fit in the namespace. My initial thoughts go something like this: A pike module should contain an autoconf script that takes several well-defined arguments, such as the --with-pike arg that the macro I worked on defines. Once the autoconf script is run, there should be a set of well defined make targets that build, test and install (and potentially uninstall) the module wherever it should go. Once you define the "interface", how it gets implimented is less important, although you're presumably want to provide a "toolkit" for making it easier to create the required interface, along with the requisite docs (how do smartlink, precompile.pike work, etc?) Once this consistent build/test/install method is available, you can think about how to automate the install process ala CPAN: hilfe> Tools.PPAN()->install("Protocols.OpenSSL", "1.2"); PPAN: Finding Protocols.OpenSSL PPAN: Downloading Protocols.OpenSSL PPAN: Unpacking ... and so on. Or am I over-simplifying things? Bill > 9634015 talks about "packages that require pike", which presumably > means other things than pike modules. In that case it might be > something useful, although I can't at the moment think of anything > that a simple AC_PATH_PROG(pike) wouldn't solve... > > / Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) > > Previous text: > >2003-01-26 20:06: > >Subject: Re: Bz2 > >-------------------------------------------------------------------- > >He made a short description of it in 9634015. I'm not familiar with > >the issue, so I can't say whether it solves the same problem. > > > > / Martin Stjernholm, Roxen IS > >

11 25

Pike 7.5 and exported sources
by Marek Habersack 27 Jan '03

27 Jan '03

Pike 7.5 from exported sources still runs precompile.sh == requires an existing pike on the system. I'm sorry I haven't even tried to look into it, but I'm in real hurry with other matters now... TIA, marek

1 0

INT_TYPE = INT64
by Mirar ＠ Pike developers forum 27 Jan '03

27 Jan '03

The testsuite fails with a rather odd error, | Doing tests in testsuite (10359 tests) | /home/mirar/pike/src/program.c:2477: Fatal error: | Variable outside storage! (__allow_rxml_entities) | Backtrace at time of fatal: | test-install/pike/7.5.1/lib/master.pike:631: | object(/home/mirar/pike/longlongint/test-install/pike/7.5.1/lib/master.pike)->low_findprog("/home/mirar/pike/longlongint/test-install/pike/7.5.1/lib/modules/spider",".so",0,1) | . | . | . but most things seem to work nicely: | > Calendar.Day(); | (2) Result: Day(Sun 26 Jan 2003) | > Protocols.HTTP.get_url("https://pike.ida.liu.se/development/pikefarm/7.5.xml"); | (5) Result: Protocols.HTTP.Query(200 OK)

4 14

Bz2 "test_codec2"
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 27 Jan '03

27 Jan '03

Im not sure the strategy to list "all possible compressions" in the Bz2 compression tests is really viable: Error: Bz2 deflate failed: "\0\1\2\3\4\5\6\7\b\t\n\13\14\r\16\17\20\21\22\23\24\25\26\27\30\31\32\33\34\35\36\37 !\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\177\200\201\202\203\204\205\206\207\210\211\212\213\214\215\216\217\220\221\222\223\224\225\226\227\230\231\232\233\234\235\236\237\240\241\242\243\244\245\246\247\250\251\252\253\254\255\256\257\260\261\262\263\264\265\266\267\270\271\272\273\274\275\276\277\300\301\302\303\304\305\306\307\310\311\312\313\314\315\316\317\320\321\322\323\324\325\326\327\330\331\332\333\334\335\336\337\340\341\342\343\344\345\346\347\350\351\352\353\354\355\356\357\360\361\362\363\364\365\366\367\370\371\372\373\374\375\376\377\0\1\2\3\4\5\6\7\b\t\n\13\14\r\16\17\20\21\22\23\24\25\26\27\30\31\32\33\34\35\36\37 !\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\177\200\201\202\203\204\205\206\207\210\211\212\213\214\215\216\217\220\221\222\223\224\225\226\227\230\231\232\233\234\235\236\237\240\241\242\243\244\245\246\247\250\251\252\253\254\255\256\257\260\261\262\263\264\265\266\267\270\271\272\273\274\275\276\277\300\301\302\303\304\305\306\307\310\311\312\313\314\315\316\317\320\321\322\323\324\325\326\327\330\331\332\333\334\335\336\337\340\341\342\343\344\345\346\347\350\351\352\353\354\355\356\357\360\361\362\363\364\365\366\367\370\371\372\373\374\375\376\377\0\1\2\3\4\5\6\7\b\t\n\13\14\r\16\17\20\21\22\23\24\25\26\27\30\31\32\33\34\35\36\37 !\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\177\200\201\202\203\204\205\206\207\210\211\212\213\214\215\216\217\220\221\222\223\224\225\226\227\230\231\232\233\234\235\236\237\240\241\242\243\244\245\246\247\250\251\252\253\254\255\256\257\260\261\262\263\264\265\266\267\270\271\272\273\274\275\276\277\300\301\302\303\304\305\306\307\310\311\312\313\314\315\316\317\320\321\322\323\324\325\326\327\330\331\332\333\334\335\336\337\340\341\342\343\344\345\346\347\350\351\352\353\354\355\356\357\360\361\362\363\364\365\366\367\370\371\372\373\374\375\376\377" -> "BZh91AY&SY\355\340k\314\200\0\1\177\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\300\1`\1/\377\365UH\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\23\t\200\0\0\0\0\0\0\0\0\0\0\0\0\0\23\0\211""0\0L\0\4\300\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\230\0&\0\2`\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\2L\0\23\0\1""0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\3\372\200@\320D\25\6A\320\204%\nB\320\304""5\16C\321\4E\22D\321DU\26E\321\204e\32F\321\304u\36G\322\4\205\"H\322D\225&I\322\204\245*J\322\304\265.K\323\4\305""2L\323D\325""6M\323\204\345:N\323\304\365>O\324\5\5BP\324E\25FQ\324\205%JR\324\305""5NS\325\5ERT\325EUVU\325\205eZV\325\305u^W\326\5\205bX\326E\225fY\326\205\245jZ\340P\26\305\265n[\327\5\305r\\\327E\325v]\327\205\345z^\327\305\365~_\337\343\0\300\260L\33\375a\30V\31\207b\30\226)\213c\30\326""9\217d\31\26I\223e\31VY\227f\31\226i\233g\31\326y\237h\32\26\211\243i\32V\231\247j\32\226\251\253k\32\326\271\257l\33\26\311\263m\33V\331\267n\33\226\351\273o\33\326\371\277p\34\27\t\303q\34W\31\307r\34\227)\313s\34\327""9\317t\35\27I\323u\35WY\327v\35\227i\333w\35\327y\337x\36\27\211\343y\36W\231\347z\36\227\251\353{\36\327\271\357|\37\27\311\363}\37W\374\373>\357\303\362\375?o\343\372\377\305\334\221N\24$;x\32\363\0", expected any of ({ /* 2 elements */ "BZh91AY&SY\355\340k\314\200\0\1\177\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\260\1`\1/\377\365UH\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\23\t\200\0\0\0\0\0\0\0\0\0\0\0\0\0\23\0\211""0\0L\0\4\300\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\230\0&\0\2`\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\7\365\0\201\240\210*\14\203\241\bJ\24\205\241\210j\34\207\242\b\212$\211\242\210\252,\213\243\b\312""4\215\243\210\352<\217\244\t\nD\221\244\211*L\223\245\tJT\225\245\211j\\\227\246\t\212d\231\246\211\252l\233\247\t\312t\235\247\211\352|\237\250\n\n\204\241\250\212*\214\243\251\nJ\224\245\251\212j\234\247\252\n\212\244\251\252\212\252\254\253\253\n\312\264\255\253\212\352\274\257\254\13\n\304\261\254\213*\314\263\255\13J\324\265\300\240-\213j\334\267\256\13\212\344\271\256\213\252\354\273\257\13\312\364\275\257\213\352\374\277\277\306\1\201`\230""7\372\302""0\254""3\16\304""1,S\26\306""1\254s\36\310""2,\223&\312""2\254\263.\314""3,\323""6\316""3\254\363>\320""4-\23F\322""4\255""3N\324""5-SV\326""5\255s^\330""6-\223f\332""6\255\263n\334""7-\323v\336""7\255\363~\340""8.\23\206\342""8\256""3\216\344""9.S\226\346""9\256s\236\350:.\223\246\352:\256\263\256\354;.\323\266\356;\256\363\276\360</\23\306\362<\257""3\316\364=/S\326\366=\257s\336\370>/\223\346\372>\257\371\366}\337\207\345\372~\337\307\365\377\213\271\"\234(Hv\360""5\346\0", "BZh91AY&SY\355\340k\314\0\0\1\177\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\260\1`\1/\377\365UP&\2`\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\2L\0\23\0\1""0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1&\0\t\200\0\230\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\375@P$\r\4A_\362\14\203\241\bJ\24\205\241\217\375\rC\220\364A\21D\221""4Q\25E\221ta\31F\221\264q\35G\221\364\201!H\222""4\221%I\222t\241)J\222\264\261-K\222\364\301""1L\223""4\321""5M\223t\341""9N\223\264\361=O\223\365\1AP\224""5\21EQ\224u!IR\224\265""1MS\224\365AQT\225""5QUU\225uaYV\225\265q]W\225\365\201aX\226""5\221eY\226u\241iZ\226\265\261m[\226\365\301q\\\227""5\321u]\227u\341y^\227\265\361}_\227\366\1\201`\230""6\21\205a\230v!\211b\230\266""1\215c\230\366A\221d\231""6Q\225e\231va\231f\231\266q\235g\231\366\201\241h\232""6\221\245i\232v\241\251j\232\266\261\255k\232\366\301\261l\233""6\321\265m\233v\341\271n\233\266\361\275o\233\367\1\301p\234""7\21\305q\234w!\311r\234\267""1\315s\234\367A\321t\235""7Q\325u\235wa\331v\235\267q\335w\235\367\201\341x\236""7\221\345y\236w\241\351z\236\267\261\355{\236\367\301\361|\237""7\321\365}\237w\341\371~\237\267\361\375\177\205\334\221N\24$;x\32\363\0" }) post_modules/Bz2/testsuite:17: testsuite()->a() /usr/local/xenofarm/xenoclient/pike-7.5/beldandy/buildtmp/Pike7.5-20030127-101826/bin/test_pike.pike:691: /usr/local/xenofarm/xenoclient/pike-7.5/beldandy/buildtmp/Pike7.5-20030127-101826/bin/test_pike()->main(3,({"/usr/local/xenofarm/xenoclient/pike-7.5/beldandy/buildtmp/Pike7.5-20030127-101826/bin/test_pike.pike",0,0})) Why not just test that the string gets shorter and expands to the original data if you inflate it?

3 3

Jump to page:

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