Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

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 19 Aug '15

19 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

switch and Math.nan
by Arne Goedeke 08 Jul '15

08 Jul '15

Switches use binary search on a sorted array. Using floating point NaN either as a case entry or as a lookup value therefore does not work properly. I think the current situation can lead to bugs easily, e.g. when using case ranges with floats as in this rather artificial example: int is_in_range(float f) { switch (v) { case 0.0..1.0: return 1; default: return 0 } } I think we should (1) issue a warning when Math.nan is used inside a case and (2) make sure that switch (Math.nan) does not match any case. Any comments? arne

3 10

C++ conf test
by Jonas Walld�n ＠ Pike developers forum 26 Jun '15

26 Jun '15

By the way, does your system not have a C++ compiler, or is Pike testing it incorrectly? Also, why would the build process call the C++ preprocessor directly instead of having the compiler manage that?

2 1

cmod precompiler restricts functions to string(8bit)
by Chris Angelico 25 Jun '15

25 Jun '15

As of f3385a, precompile.pike seems to assume that strings are eight-bit by default. Consequently, the String.SingleReplace class (defined in builtin.cmod as single_string_replace and used automatically to optimize calls to "replace(variable, constant, constant)") chokes on wide strings: $ pike Pike v8.1 release 2 running Hilfe v3.5 (Incremental Pike Frontend) > String.SingleReplace("\u1234","1"); Bad argument 1 to create(). Expected string|void. Unknown program: create("\u1234","1") -:1: _static_modules.Builtin()->single_string_replace()->create("\u1234","1") HilfeInput:1: HilfeInput()->___HilfeWrapper() > replace("Hello, world!","!","\u1234"); (1) Result: "Hello, world\u1234" > string x="Hello, world!"; > replace(x,"!","\u1234"); Compiler Warning: 1: Optimizer failure in replace(). Compiler Warning: 1: Bad argument 2 to create(). Expected string|void. (2) Result: "Hello, world\u1234" It does appear to be functional (presumably by falling back on the unoptimized version), but it looks as if this could have consequences elsewhere. Thoughts? ChrisA

1 0

C++ conf test
by Jonas Walld�n ＠ Pike developers forum 22 Jun '15

22 Jun '15

I see at least one *.cc file in the tree, so how would that work if the configure stuff is removed?

3 4

How does one detect that a socket is being closed with Stdio.Buffer?
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 17 Jun '15

17 Jun '15

"The remote end closing the connection" is detected by getting EOF on a read. So to detect that you actually have to read everything the remote end sends first... Thus your requirements of not reading anything and detecting the remote end closing the connection are not compatible.

2 5

assign_array_level*
by Martin Karlgren (arga kodarn) ＠ Pike (-) developers forum 02 Jun '15

02 Jun '15

It seems to me that the (relatively) new assign_array_level* functions in array.c don't set type_field as it should in the destination array, right? I've committed a fix in 8.1, second opinions are most welcome.

2 1

*new*-style tail-recursion
by Arne Goedeke 07 May '15

07 May '15

I have been working on refactoring the API of mega_apply and friends. The purpose of that branch is to improve the performance of function calls. More specifically, in some cases (e.g. f_map) frame allocation, setup and deallocation could be avoided if the API permitted it. I will soon push a branch and ask for feedback on that. Now to the real questions: apply_low.h contains a FIXME notice talking about new-style tail recursion. Could anyone elaborate what that is, which code to look at and how that works? arne

2 1

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