Pike-devel December 2018

pike-devel@lists.lysator.liu.se

6 participants
6 discussions

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

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

03 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

Thread.ResourceCount: Fixed mutex handling.
by Stephen R. van den Berg 08 Dec '18

08 Dec '18

commit d168eb73a23756642bdc80451ba206a345471f6a Author: Henrik Grubbström (Grubba) <grubba(a)grubba.org> Date: Sun Aug 5 11:21:52 2018 +0200 Thread.ResourceCount: Fixed mutex handling. I'm not saying that this is not correct, I just want to make sure I understand the change. Can anyone elaborate on as to why this change is necessary/desirable? -- Stephen.

2 4

debugger, status and suggestions sought
by H. William Welliver III 07 Dec '18

07 Dec '18

Hi all, After a helpful conversation at the pike meet-up last month, I’ve been working on a proof-of-concept debugger for pike code. There is a lot of work left to do, and hopefully others will help me out, but I think that things are at a point where it can be used to do actual debugging. I’ve put together a page[1] with my notes (and the code contains a lot of TODOs as well). Please take a look at both the page and the branch (bill/debugger-poc) and let me know if you think there are glaring faults in the approach. I am certain that there are a lot of small bugs as well. Please feel free to dig in and help out. I suspect that a lot of the work to be done won’t really make a lot of sense until there’s a debugging client to use it with (beyond the hilfe I’ve been testing with). There are a few items that I think I probably need guidance with: 1. Local names aren’t available. Previously, I attempted to parse these out of the source code, but I suspect that’s a losing battle. 2. I was chatting with Mateusz and we were thinking that something that gave us access to the parse tree might be helpful for clients. I wrote a Pike parser in java that is used by the eclipse plugin I wrote, and this allowed generating useful navigation and variable data. Would a native pike equivalent be useful for this and things such as a hypothetical Language Server Protocol? Maintaining duplicate code is probably not the best use of our time; but I suspect that the existing source isn’t really set up to allow this sort of piggy-back use. As always, feedback and suggestions are welcome! Bill [1] http://wiki.gotpike.org/index.pike/PikeDevel/PikeDebugger

4 6

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 2018