Pike-devel November 2019

pike-devel@lists.lysator.liu.se

3 participants
6 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

Pike Meet-up 2018-Q1
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 20 Oct '21

20 Oct '21

Hi. At Pike Conference 2017 it was decided that we ought to hold a more informal meeting in Linköping ~ once every quarter. As the three month mark from the conference is coming up soon, it seems time to announce the first such meeting for 2018: Pike Meet-up 2018-Q1 Date: 2018-02-03 (Sat) Time: 10:00 - afternoon/evening Place: Roxen IS AB S:t Larsgatan 22A Linköping Welcome! /grubba

2 13

Operator assignment and strict_types
by Marc Simpson 07 Jul '20

07 Jul '20

Hi folks, It looks like operator assignment (op=), increment and decrement statements aren't subjected to the same typechecks as their more explicit equivalents. For example, neither the post-increment nor += statements below warn with strict_types enabled, even though they assign values outside of foo's restricted int domain: int(3..3) foo = 3; foo++; // no warning foo += 1; // no warning foo = foo + 1; // warning from strict_types Similarly, operator assignment on aggregates fails to elicit a warning: array(int) a = ({}); multiset(int) b = (<>); mapping(int:int) c = ([]); // no warnings a += ({ "hey" }); b += (< "hey" >); c += ([ "hey": "there" ]); // warnings from strict_types a = a + ({ "hey" }); b = b + (< "hey" >); c = c + ([ "hey": "there" ]); I'm guessing this is because the checks provided by the F_ASSIGN/F_ASSIGN_SELF case (las.c) only apply to direct assignment; op= and friends are presumably not instrumented for strict_types in the same manner. Have there been any discussions around addressing this inconsistency? Thanks, Marc

3 3

Remixml, javascript module
by Stephen R. van den Berg 25 Feb '20

25 Feb '20

This might be of interest to the Pike and/or Roxen community: https://www.npmjs.com/package/remixml I just launched it. Using it in a Single-Page-Application website. Any critical feedback is welcome (I'm currently the only user, so changes in the API are easy and still allowed). >From the description: Remixml is an XML/HTML macro language/template engine. The language and primitives used blend in completely with standard XML/HTML syntax and therefore integrate smoothly with existing XML/HTML syntax colouring editors. Requirements It runs inside any webbrowser environment (starting at IE11 and up). For historical reference: Remixml was originally inspired by RXML, the Roxen webserver macro language. -- Stephen.

1 1

Segmentation fault pike 8.1
by Stephen R. van den Berg 06 Nov '19

06 Nov '19

This is in a heavy multithreaded application: Thread 1475 "pike" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff574c700 (LWP 14689)] ba_alloc (a=a@entry=0x55555575bf20 <object_allocator>) at /var/src/roxen/81pike/src/block_allocator.c:267 267 p->h.used++; (gdb) l 262 263 ptr = p->h.first; 264 PIKE_MEMPOOL_ALLOC(a, ptr, a->l.block_size); 265 PIKE_MEM_RW_RANGE(ptr, sizeof(struct ba_block_header)); 266 267 p->h.used++; 268 269 #ifdef PIKE_DEBUG 270 ba_check_ptr(a, a->alloc, ptr, NULL, __LINE__); 271 #endif (gdb) p p $1 = (struct ba_page *) 0x555555d298c0 (gdb) p *p $2 = {h = {first = 0x555555d35ae000, used = 681, flags = 0}} (gdb) p ptr $3 = (struct ba_block_header *) 0x555555d35ae000 (gdb) p *ptr Cannot access memory at address 0x555555d35ae000 (gdb) where #0 ba_alloc (a=a@entry=0x55555575bf20 <object_allocator>) at /var/src/roxen/81pike/src/block_allocator.c:267 #1 0x000055555560156f in alloc_object () at /var/src/roxen/81pike/src/object.c:135 #2 low_clone (p=0x5555557d2f70) at /var/src/roxen/81pike/src/object.c:135 #3 0x0000555555601ad2 in debug_clone_object (p=<optimized out>, args=args@entry=0) at /var/src/roxen/81pike/src/object.c:408 #4 0x000055555564b55c in f_mutex_trylock (args=1) at /var/src/roxen/81pike/src/threads.c:2333 #5 0x0000555555585a9c in low_mega_apply (type=<optimized out>, type@entry=APPLY_STACK, args=1, arg1=<optimized out>, arg1@entry=0x0, arg2=arg2@entry=0x0) at /var/src/roxen/81pike/src/apply_low.h:225 #6 0x000055555558624e in jump_opcode_F_CALL_FUNCTION () at /var/src/roxen/81pike/src/interpret_functions.h:2422 #7 0x00007ffff6a4c55c in ?? () #8 0x00007ffff574bd41 in ?? () #9 0x0000000000000001 in ?? () #10 0x00007fffffffe03e in ?? () #11 0x00007fffffffe03f in ?? () #12 0x00007ffff574c700 in ?? () #13 0x00005555559af8e0 in ?? () #14 0x0000000000000000 in ?? () Any ideas? I can still explore more structures, have the session still open. -- Stephen.

2 9

Re: debugger, status and suggestions sought
by Mateusz Krawczuk 04 Nov '19

04 Nov '19

I think having both LSP <https://microsoft.github.io/language-server-protocol/> and DAP <https://microsoft.github.io/debug-adapter-protocol/> implementations for Pike would be awsome, but I feel that this discussion is getting further away from it's main point. We've been talking about LSP for a little during the Conference. There is a huge interest in it and I think we should move the LSP discussion to another mailing thread to avoid mixing contexts. Having a Pike debug adapter would also be great, but since DAP is used for estabilishing communication between IDE and the debugger, we can't move on with it until we actually have a debugger. >From what I understand the greatest challenge now would be to reach the local variables. I've heard that long time ago, the language got some optimizations that makes retrieving local variable names very challenging. Is it true? If yes, how we can jump this through? I would be more than happy to help crossing-out the remaining TO-DOs, if I only could get some itroduction and clues.

5 25

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 November 2019