Pike-devel December 2016

pike-devel@lists.lysator.liu.se

7 participants
19 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

Bad function identifier on 8.1
by Stephen R. van den Berg 29 May '17

29 May '17

While trying to use Pike 8.1, I consistently get the following on stderr whenever I run pike: /usr/local/pike/8.1.6/lib/modules/Crypto.pmod/Random.pmod.o:-: Warning: Decode failed: Error while decoding program(/usr/local/pike/8.1.6/lib/modules/Crypto.pmod/Random.pmod:23): Bad function identifier offset for random_string:function(int(0..2147483647) : string(8bit)): 3 != 0 It's not immediately obvious to me how to fix this. Anyone? Or am I the only one seeing this? -- Stephen.

2 4

Protocols.SMTP.ClientHelper()->rfc2822date_time()
by Chris Angelico 24 Jan '17

24 Jan '17

What exactly is this function, and how does it differ from Calendar.Time.format_smtp()? The docs for the latter state that it's "as seen in Date: headers in mails", which seems to be the same purpose. They appear to give the same output. Should the ClientHelper function have a docs reference to format_smtp? Is there a reason to use ClientHelper instead? ChrisA

2 1

Optimised map
by Martin Karlgren 09 Jan '17

09 Jan '17

Hi, Having realised the benefits of functional programming, I’ve been quite annoyed by the rumour of how expensive function calls are in Pike. I decided to look into f_map and could see how much seemingly unnecessary work it does when it calls apply_svalue once for each entry in the array – it should be possible to reuse the pike_frame if it’s about to be thrown away after the function call (if it has other refs on the other hand, it can’t be reused – it’s probably used as a scope in some other frame). I’ve pushed my optimised variant in marty/optimised_map – it seems to work quite well and provides a major speedup. In fact, it’s a bit faster than the corresponding foreach variant. I haven’t verified correctness in various corner cases, and some input on whether it’s correct to do the things init_frame_reuse_context does only once before multiple function calls would be nice too. The *_reuse_context stuff in interpret.c should be applicable wherever the same svalue is applied repeatedly with the same number of arguments (I haven’t looked for it outside of f_map really). What do you all think? Good idea or did I overlook something? Without optimisation: map: 1.660797 array index: 1.335115 array append: 1.17917 With optimisation: map: 0.877659 array index: 1.351158 array append: 1.189812 Test program: int main() { array base = allocate(10000000, 1); float gmap = gauge { array res = map (base, lambda(int i) { return i + 2; }); }; float garrayindex = gauge { array res = allocate(sizeof(base)); foreach (base; int idx; int i) { res[i] = i + 2; } }; float garrayappend = gauge { array res = ({}); foreach (base, int i) { res += ({ i + 2 }); } }; werror ("map: %O\n", gmap); werror ("array index: %O\n", garrayindex); werror ("array append: %O\n", garrayappend); } /Marty

4 12

Christmas beta 2
by Peter Bortas 30 Dec '16

30 Dec '16

On request since there was some regression since the last release. Pike 8.0.388 beta/release candidate: https://pike.lysator.liu.se/pub/pike/beta/8.0.388/Pike-v8.0.388.tar.gz Other builds: https://pike.lysator.liu.se/pub/pike/beta/8.0.388/Pike-v8.0.388-Darwin-15.4… https://pike.lysator.liu.se/pub/pike/beta/8.0.388/Pike-v8.0.388-win32-oldli… Documented changes since Christmas beta 1: ------------------------------------------------------------------- New features ------------ o Thread _sprintf() improvements: Thread.Mutex now prints the ID of the thread holding the lock, and thread IDs are shown as hexadecimal numbers.

3 3

Christmas beta
by Peter Bortas 27 Dec '16

27 Dec '16

Grubba fixed a string bug that looks pretty nasty for some special edge cases, so despite not being the first Tuesday of the month, here's a beta. Pike 8.0.384 beta/release candidate: https://pike.lysator.liu.se/pub/pike/beta/8.0.384/Pike-v8.0.384.tar.gz Other builds: https://pike.lysator.liu.se/pub/pike/beta/8.0.384/Pike-v8.0.384-Darwin-15.4… https://pike.lysator.liu.se/pub/pike/beta/8.0.384/Pike-v8.0.384-win32-oldli… Changes since Pike 8.0.370 (release 6) ---------------------------------------------------------------------- Bug fixes --------- o String character range Fixed a bug where a string could incorrectly have it's character range start point set to 0 when added with an empty string. This in turn would incorrectly block the string from being used by functions that require strings without null characters as argument or incorrectly take optimization paths. o VCDiff Fixed type of decode_chunk(). o Parser.XML UTF-8 encoded documents with initial BOM was not decoded correctly. Serializing Parser.XML.Tree objects will now entity escape characters that can not be encoded in the selected output charset. Regards, -- Peter Bortas

2 1

smartlink and C++ name mangling on OS X
by H. William Welliver III 25 Dec '16

25 Dec '16

I tracked down a problem compiling a c++ module on OS X 10.12. Everything compiles properly but I get lots of symbol not found errors during linking. It seems that the mangled symbol names being generated for the module were a lot shorter than the ones in the library. For example: __ZN6Xapian11QueryParser11parse_queryERKSsjS2_ versus: __ZN6Xapian11QueryParser11parse_queryERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEEjS9_ After a good bit of messing around (I assumed it was due to some command line option passed to clang/ld) I discovered that there’s a line in smartlink that sets: MACOSX_DEPLOYMENT_TARGET=10.3 And this setting alters a number of behaviors in the compiler/linker including the style of name mangling used. It looks like the minimum version required for modern libraries to work is 10.9. Is there any chance we can bring that forward? Perhaps 10.9 for versions 10.9 and up, and whatever previous version makes most sense... I still compile for 10.6 as a courtesy for some folks but don’t know anyone running anything earlier. Any thoughts? Bill

2 1

Code climate
by Martin Nilsson (Coppermist) ＠ Pike (-) developers forum 19 Dec '16

19 Dec '16

I've set up code climate to analyze Pike. Very few relevant checkers, but some complaints about CSS... https://codeclimate.com/github/pikelang/Pike/issues?category=&engine=csslint

1 0

JSON
by Martin Nilsson (Coppermist) ＠ Pike (-) developers forum 16 Dec '16

16 Dec '16

A JSON feature request: Add a flag to the decoder that detects and strips comments from the in-data.

1 0

Re: C99, dynamic arrays, and branch rosuav/gtk2-drag-drop
by Chris Angelico 13 Dec '16

13 Dec '16

On Tue, Dec 13, 2016 at 10:25 AM, Peter Bortas @ Pike developers forum <10353(a)lyskom.lysator.liu.se> wrote: > I don't know the details, grubba is the one that has been trying to > get 8.1 to build on the existing VC9 Windows build machines. So > anything that doesn't break VC9 is probably fine. I'm having trouble finding authoritative information on what VC9 supports (MS don't seem to carry much information on their older compilers - they carry precious little even on the current ones - so I'm depending on Stack Overflow), but it looks like VLAs are *not* supported. Sigh. So I guess I'll change it up. Should I go with alloca, or does Pike have its own preferred way to do this? ChrisA

3 3

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 December 2016