Pike-devel August 2015

pike-devel@lists.lysator.liu.se

4 participants
10 discussions

Re: Playing music using pike and SDL.
by Martin Nilsson (lvl 60) ＠ Pike (-) developers forum 03 Dec '25

03 Dec '25

Were you not able to get any C code to play through SDL either? Does your SDL library have a mixer compiled in it (I think it is optional)?

3 2

Re: Setting socket options: so many, uhh, options!
by Chris Angelico 15 Sep '16

15 Sep '16

On Tue, Mar 10, 2015 at 10:05 PM, Mirar @ Pike developers forum <10353(a)lyskom.lysator.liu.se> wrote: > Wait, I said REUSEPORT? What's the difference to REUSEADDR? Mysteries > of TCP sockets... Here's a decent explanation, I think: http://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and… ChrisA

3 6

split-string branch
by Per Hedbor () ＠ Pike (-) developers forum 01 Sep '15

01 Sep '15

Would it be OK to merge the split string code to pike 8.1? I have done the merge to a private branch, and now wonder if it would be OK to push it upstream. It splits strings into two parts: The pike_string structure and the actual string. There are at least two advantages that are available right now: 1: "static" strings (C-strings and static C-data) can be converted to pike strings without allocating any memory for the string data. This actually saves measurable amount of string bytes. Also, these strings are faster to create since there is no need to allocate storage for the actual string data (useful as an example in GTK2, there is an actual measurable speedup in the init of that function. Well. microseconds, but it's faster. :)) 2: It actually improves the speed of some string operations, probably because the string metadata is closer in memory (more likely to be cached). The disadvantages are, at least: 1: one more pointer in the string struct. This is, however, balanced for everythinge except short strings by the fact that malloc is not used to allocate them, so there is one less size_t in them (malloc overhead) 2: string data is individually mallocd (see 1), so here we get the overhead back, except for short strings. :) So, basically: 8 bytes more overhead for strings. As for the speed of string creation/free:ing: Without patch: | String Creation . . . . . . . . . . . . . . . . . . 2207k/s | String Creation (existing) . . . . . . . . . . . . 8335k/s With patch: | String Creation . . . . . . . . . . . . . . . . . . 3069k/s | String Creation (existing) . . . . . . . . . . . . 8771k/s Seen this way the split-method is faster for basic string operations. The numbers, however, vary so much that it's basically a wash. Another advantage with this method is that it is reasonably trivial to add new string types. As an example that I am seriously considering: A string that is a tail port of another string. The tail-string would be used for this somewhat unfortunate but rather common coding pattern: sscanf( str, "%2c%s", part, str ); and, in a similar manner: len = file->write(str); str = str[written..] These are both O(n^2), but if tail-of string are added they could both be about O(n), only reallocate the data if more than 50% is wasted. Unfortunately the same can not be done for random substrings, since strings are guaranteed to be 0-terminated. But that is probably not much of an issue in practice. Also, when gc:ing code could be added to "trim" all tail-of strings. There is at least one slightly incompatible change to the C-level API: push_constant_text and the related macros (create a static pike_string the first time it's called, and then use that from now on) now require actual static lifetime of the argument passed to it. This is already the case for all code in the pike tree, but external modules might break this assumption.

4 10

CID[1317352-1317354]
by Peter Bortas ＠ Pike developers forum 27 Aug '15

27 Aug '15

The three new complaints about "Assign instead of compare" in pike_tokenizer looks very, very intentional, but I'll leave it up to whoever introduced them (grubba?) to mark them as false positives.

4 7

Re: C99, variadic macros, and rbtree.c
by Chris Angelico 25 Aug '15

25 Aug '15

On Wed, Aug 26, 2015 at 1:25 AM, Per Hedbor () @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > C11 is default since gcc 5.2, I think. But C99 seems to have been > skipped (as the default) entirely. The example line of code that I gave works fine on my system (gcc 4.9.2), but that might be as an extension, not sure. But I have no idea what compilers Pike supports and what C standards they support. ChrisA

2 1

C99, variadic macros, and rbtree.c
by Chris Angelico 25 Aug '15

25 Aug '15

a5a15b makes rb_fatal identical to Pike_fatal when debugging is not active. This doesn't work, because Pike_fatal takes just sprintf format and args, but rb_fatal takes a node pointer first. Since variadic macros exist only in ISO C 1999 and newer, I'm guessing they shouldn't be used; otherwise, it'd be simple to change the definition of rb_fatal to: #define rb_fatal(NODE, ...) Pike_fatal(__VA_ARGS__) What's the best way to go about this? ChrisA

7 7

Re: split-string branch
by Chris Angelico 24 Aug '15

24 Aug '15

On Mon, Aug 24, 2015 at 11:00 PM, Per Hedbor () @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: >> Since this change does fix the testcase, should I commit it to 8.1? > > Please go ahead and commit it. Pushed. Thanks for the advice! ChrisA

1 0

Re: split-string branch
by Chris Angelico 24 Aug '15

24 Aug '15

On Sun, Aug 23, 2015 at 5:50 AM, Per Hedbor () @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > Ok.. I accidentally commited about half of the changes to 8.1, without > the other half (I did a 'git push' but aborted almost directly when I > noticed it was pushing 8.1. However, it seems aborting does not stop > the commiting, and in this case a lot of the commits were not actually > included). > > To fix this I just did a merge of the string split to 8.1. I assume > there are alternative solutions, but there had been other commits done > as well, and the merged commits are spread in time (some are merged), > so in order to fix it quickly I just basically did the full commit. It mostly works, but I did find one problem: some GTK signal connections don't seem to work. Reverting part of the staticification fixes it; I've committed such a reversion to branch rosuav/nonstatic-gtk-strings if anyone wants to eyeball it. Is there any way to verify that the reversion won't break anything? ChrisA

3 3

Re: split-string branch
by Chris Angelico 18 Aug '15

18 Aug '15

On Wed, Aug 19, 2015 at 6:13 AM, Per Hedbor () @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > Another advantage with this method is that it is reasonably trivial to > add new string types. As an example that I am seriously considering: A > string that is a tail port of another string. > > The tail-string would be used for this somewhat unfortunate but rather > common coding pattern: > > sscanf( str, "%2c%s", part, str ); > > and, in a similar manner: > > len = file->write(str); > str = str[written..] > > These are both O(n^2), but if tail-of string are added they could both > be about O(n), only reallocate the data if more than 50% is wasted. This specific improvement would be useful to this code, although I'm noticing the slowdown only when I do stupid stuff for benchmarking. https://github.com/Rosuav/Hogan/blob/master/hogan.pike#L25 Figuring out a good chunk size in application code is hard. If I could simply code idiomatically without chunking, and let the language worry about efficiency, it'd be awesome. ChrisA

2 4

intrinsics
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 01 Aug '15

01 Aug '15

configure fails to detect gcc intrinsic for me. Example: TEST_BUILTIN(__builtin_clz, 23) will generate configure:61584: checking for __builtin_clz configure:61608: /home/nilsson/pike/build/linux-3.19.0-25-generic-x86_64/smartlink gcc -o conftest -g -fvisibility=hidden -O3 -pipe -ggdb -fvar-tracking-assignments -funswitch-loops -m64 -mrdrnd conftest.c >&5 configure:61608: $? = 0 configure:61618: result: 9961pike_cv_builtin___builtin_clz I.e. one level too much quoting. I'm not sure what the correct portable fix is though.

1 0

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 August 2015