Pike-devel

pike-devel@lists.lysator.liu.se

2 participants
3046 discussions

Refdoc
by Pontus Östlund 29 Nov '16

29 Nov '16

Hi guys! I saw the refdoc on the Pike site is somewhat broken. The plan is to port the new refdoc layout in 8.1 to 8.0, and I'm working on that as we speak. But in order to make that work I need to add the standalone Tools.Standalone.pike_to_html tool since that is used to highlight example code in the refdoc. Is that ok? Regards ----------------------------- Pontus Östlund Developer • Roxen AB +46 70-662 81 69 www.roxen.com <http://www.roxen.com/> | twitter.com/roxen <https://twitter.com/roxen>

5 11

Segfault generating src/post_modules/GL/auto.c on PowerPC
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 29 Nov '16

29 Nov '16

For reference, Gentoo considers gcc 4.9.4 stable for all arches except x86 (where 4.9.3 is the latest stable). Anything beyond that is considered unstable.

1 0

EV_OOBAND etc. undefined in backend.cmod on Debian GNU/kFreeBSD
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 28 Nov '16

28 Nov '16

Sorry, I forgot that the build log doesn't show that bug but a earlier one caused by some clock problem causing src/configure to have a modification time in the future.

1 0

EV_OOBAND etc. undefined in backend.cmod on Debian GNU/kFreeBSD
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 28 Nov '16

28 Nov '16

Build on kfreebsd fails due to multiple undefined symbols; see https://buildd.debian.org/status/fetch.php?pkg=pike8.0&arch=kfreebsd-amd64&… It seems 6b9645e2708c53e92db4f752490f0d168280db10 introduced a bug among the #ifs in backend.cmod. At then line 2425, now line 2908, it did -#elif defined(BACKEND_USES_POLL) +#endif /* HAVE_SYS_DEVPOLL_H || HAVE_SYS_EPOLL_H */ + +#ifdef HAVE_POLL but then later we have #endif /* HAVE_POLL */ and then #elif defined(BACKEND_USES_KQUEUE) which doesn't match up with the other #ifdef BACKEND_USES_* conditionals any longer, so the KQUEUE part incorrectly gets omitted.

1 0

Buffer mode for SSL.File?
by H William Welliver III 25 Nov '16

25 Nov '16

Any plans to add buffer mode support to SSL.File? I just discovered this in Stdio.File and think it would be very nice if it were available here as well...

3 2

Re: Clean-room Engine.IO implementation committed to git 8.0/8.1
by Chris Angelico 23 Nov '16

23 Nov '16

On Thu, Nov 24, 2016 at 12:40 AM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: >>In Python, it's done with a prefix - u"asdf" is a Unicode string, and >>b"asdf" is a byte string. > > Since nominally strings are Unicode (with the extended ISO 10646 > range) strings now, I think "asdf" can be left as the syntax for that, > and we only need a new syntax for the byte string ("buffer") type. We > can also look at Java, which has byte[] as the type for byte strings, > requiring literals like {'a','s','d','f'}, but I would like to see > something a bit more convenient to use. :-) Agreed. In Python 3.0+, that's how it is - an unadorned string is Unicode, and b"asdf" is a byte string. (Python 2.7 has it the other way - an unadorned string is bytes, and u"asdf" for Unicode - and because of that, you're allowed to put the prefixes on both types of string. But Pike needn't do that.) ChrisA

3 2

Inheriting from a mapping
by Stephen R. van den Berg 23 Nov '16

23 Nov '16

Given the attached sample code. It tries to profile the difference between accessing a native mapping and accessing it through a class which is declared inline as much as possible. When I run it, I find that the native mapping is about twice as fast and the inlined amapping class. What would it take to make an amapping class less than a factor 1.2 slower than the native mapping? Would being able to inherit from some kind of "_Builtin._mapping" class be of any use? I ran the tests on Pike 8.1. ---------------------------------cut here-------------------- #!/usr/local/bin/pike #define REPEAT 10000 class timeit { protected void create(string name, function(:void) fn) { int i,t1,t2; mixed e; t1 = gethrtime(); e = catch { for (i=REPEAT; i>0; i--) fn(); }; if (e) write("Skipped %s\n", name); else { t2 = gethrtime(); write("%f %s\n", (t2-t1)/(float)REPEAT, name); } } } class amapping { private mapping values; inline protected void create(mapping v) { values = v; } inline private mixed `[](string key) { return values[key]; } inline private mixed `->(string key) { return values[key]; } inline private mixed `[]=(string key, mixed v) { return values[key] = v; } inline private mixed `->=(string key, mixed v) { return values[key] = v; } inline private Iterator _get_iterator() { return get_iterator(values); } inline private array(string) _indices() { return indices(values); } private string _sprintf(int type, void|mapping flags) { string res = UNDEFINED; switch (type) { case 'O': res = sprintf("%O", values); int indent; if (flags && (indent = flags->indent)) res = replace(res, "\n", "\n" + " " * indent); break; } return res; } } int main(int argc, array(string) argv) { mapping m = ([ "abc":8, "acc":1, "adc":2, "aec":3, "afc":4, "agc":5, "ahc":6, "adc":2, "1dc":3, "3dc":2, "4dc":2, "5dc":8, "6dc":7, "7dc":2, "8dc":3, "rdc":2, ]); amapping am = amapping(m); timeit("mapping", lambda(){ int total = 0; foreach (indices(m);; string id) total += m[id]; return total; }); timeit("amapping", lambda(){ int total = 0; foreach (indices(m);; string id) total += am[id]; return total; }); return 0; } ---------------------------------cut here-------------------- -- Stephen.

2 2

Request for 8.1 refdoc on the Pike devel website alongside 8.0 refdoc
by Stephen R. van den Berg 23 Nov '16

23 Nov '16

I'd like to suggest that we make available a generated Refdoc for the development tree (8.1 currently) on the pike website somewhere too. Regenerated regularly through xenofarm perhaps. -- Stephen.

2 2

Re: Clean-room Engine.IO implementation committed to git 8.0/8.1
by Chris Angelico 23 Nov '16

23 Nov '16

On Wed, Nov 23, 2016 at 11:10 PM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: >>I agree, but using string(8bit) to mean "binary data" is something >>that's 100% backward compatible. > > It would not be backwards compatible, since that is not what > string(8bit) means today. By "binary data", I mean eight-bit strings of arbitrary bytes - like you'd read from a file or something. Currently, functions like Stdio.read_file simply return "string", but they'll effectively be returning string(8bit). >>Unicode text would always be referred >>to as string(21bit), even if it happens to contain nothing but Latin-1 >>characters. > > That doesn't really make sense. So you say that "R\xe4ksm\xf6rg\xe5s" > would have type string(21bit)? What type would "\U12345678" have? \U12345678 possibly should be an error, as it's not valid Unicode. Maybe the Pike string type can be used for other things, but they're not Unicode text - so you could use string(32bit) for those sorts of non-textual strings. (I don't know of any use cases, so I can't say beyond that.) My statement about Unicode text specifically excludes anything that isn't valid according to the Unicode standard. > What type would "Foo" have? How would you specify a UTF-8 encoded > literal? Now, these are questions that can't truly be answered with the current system. I would like the former to be string(7bit), and the latter would be either string(7bit) or string(8bit) depending on whether there are non-ASCII characters in it. But they're probably both just type 'string' at the moment. ChrisA

3 5

Re: Clean-room Engine.IO implementation committed to git 8.0/8.1
by Chris Angelico 23 Nov '16

23 Nov '16

On Thu, Nov 24, 2016 at 12:20 AM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: >>\U12345678 possibly should be an error, as it's not valid Unicode. > > It's valid Pike. Pike supports the full ISO/IEC 10646 31-bit range, > plus an equally large negative range. > >> so you could use string(32bit) for those sorts of >> non-textual strings. > > Not string(31bit)? > >>My statement about Unicode text specifically excludes >>anything that isn't valid according to the Unicode standard. > > Which makes it even worse since the set of valid characters change > with each release of the Unicode standard... AIUI the Unicode Consortium has declared that they will never define any characters beyond 0x10FFFF, as that would destroy UTF-16 as a valid encoding. And you're right that "valid according to the Unicode standard" is a bit too restrictive, but certainly "valid within the declaration of character range" should be safe. >>> What type would "Foo" have? How would you specify a UTF-8 encoded >>> literal? >> >>Now, these are questions that can't truly be answered with the current >>system. I would like the former to be string(7bit), > > Then you are contradicting yourself, since you claimed that Unicode > text would _always_ be referred to as string(21bit), and "Foo" is > definitely Unicode text (both 'F' and 'o' have been part of the > Unicode standard since the first version). string(7bit) would be implicitly upcastable to string(21bit), since ASCII text can be represented validly as either bytes (with the top bit clear) or as Unicode codepoint sequences. >>and the latter >>would be either string(7bit) or string(8bit) depending on whether >>there are non-ASCII characters in it. > > But how would the compiler know that the characters are UTF-8 encoded, > so that it does not assign a type of string(21bit) instead? Right, and that's something that can't be done in the current standard. Hence this entire proposal has to wait until some major changes can be done. In Python, it's done with a prefix - u"asdf" is a Unicode string, and b"asdf" is a byte string. It would need to be something similarly syntactic, once the two become actually different types. For today's Pikes, though, that's not possible, so the safest way is to simply keep track of it in the programmer's mind, without language support. ChrisA

3 3

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