Pike-devel February 2020

pike-devel@lists.lysator.liu.se

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

Debugger status
by H William Welliver 28 Feb '20

28 Feb '20

Hi all- I anticipate having some free time coming up and thought I might spend some of that working on the debugger project. However, I’m not really sure where things stand. So, here are some questions to help me understand the situation: 1. How much of the code in play is related to what I originally had in the debugger concept branch? 2. Has any of that been merged into another working location? 3. I seem to recall there being a review of (some) debugging code. Has action been taken on any of those suggestions? 4. Mateusz had been working on an implementation of the debug server protocol. Is that complete from a client server standpoint? 5.I think at one point there was a demo project but that it didn’t actually connect to pike. What exactly is the status of that, or of the inevitable javascript-based plugin for VS Code? 6. Anything else I’m missing? Or put another way: I want to write a pike program in, say, VS Code, and I want to be able to debug it there. How far from that goal will I be, and what needs to be done to get there? Thanks in advance! Bill

3 2

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

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 February 2020