Pike-devel June 2015

pike-devel@lists.lysator.liu.se

2 participants
6 discussions

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

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

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