Pike-devel January 2019

pike-devel@lists.lysator.liu.se

5 participants
11 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

Re: QuickType support
by Mateusz Krawczuk 22 Jan '19

22 Jan '19

Hey! Thank you very much for feedback. I've applied most of the suggested changes. As for the lfun::create() approach to object deserializing - I've been thinking about it, but it's troublesome for some edge cases, like arrays and tuples. czw., 17 sty 2019 o 18:56 Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> napisał(a): > Hi. > > >I came to the point where I spent so much time on providing Pike support > >for QuickType, that I'd probably manage to manually write DAP and LSP > pmods > >by now. So I've decided to stop there and deliver it as-is. Despite the > >generated code's likely poor performance, it's been thoroughly tested and > >proven to work for most test cases both for JSON, and JSON Schema. > > > >I really, really wanted to reuse Standards.JSON API, or else I would wind > >up rewriting the whole JSON serialization module. That's why I ended up > >calling JSON.encode, which invokes the encoded object's encode_json > method, > >inside JSON.decode. It's necessary because Pike member names are not > >necessary JSON's keys. For exmaple, 'else' is a perfectly valid key name > in > >JSON, while it's a reserved keyword in many programming languages. > >QuickType has it's ways to handle such situations. > >Another known blunder is that it tends to append member declarations with > >'mixed' when rendering from JSON Schemas. It's likely related to how > >QuickType handles Schema's optional properties. > >Here you can play around with it: https://app.quicktype.io/#l=pike > > Hmm... From the JSON example: > > | #define TO_MIXED(x) Standards.JSON.decode(Standards.JSON.encode(x)) > > Why do the above? Under normal circumstances it should be a (slow) > no-op (at least when it is called from encode_json()). > > [...] > | string encode_json() { > | mapping(string:mixed) json = ([]); > | > | json["greeting"] = TO_MIXED(greeting); > | json["instructions"] = TO_MIXED(instructions); > > More efficient would be to create the mapping inline: > > string encode_json() { > mapping(string:mixed) json = ([ > > "greeting": TO_MIXED(greeting), > "instructions": TO_MIXED(instructions), > ]); > > [...] > | Welcome Welcome_from_JSON(mixed json) { > > Why is json declared mixed above? > > | Welcome retval = Welcome(); > | > | retval.greeting = json["greeting"]; > | retval.instructions = json["instructions"]; > | > | return retval; > | } > > I'd prefer having an lfun::create() in the Welcome class, > that knows how to initialize from the mapping. > > protected void create(mapping(string:mixed)|void json) > { > if (!json) return; > greeting = json["greeting"]; > instructions = json["instructions"]; > } > ... > Welcome Welcome_from_JSON(mapping(string:mixed) json) > { > return Welcome(json); > } > > /grubba >

2 1

Re: Pike Meet-up 2019-Q1
by Mateusz Krawczuk 22 Jan '19

22 Jan '19

I'll be there! sob., 19 sty 2019 o 14:12 Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> napisał(a): > 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 latest conference is coming up soon, > it seems time to announce the first such meeting for 2019: > > Pike Meet-up 2019-Q1 > Date: 2018-02-02 (Sat) > Time: 10:00 - afternoon/evening > Place: Roxen IS AB > S:t Larsgatan 22A > Linköping > > Welcome! > > /grubba >

1 0

Re: QuickType support
by Mateusz Krawczuk 17 Jan '19

17 Jan '19

I came to the point where I spent so much time on providing Pike support for QuickType, that I'd probably manage to manually write DAP and LSP pmods by now. So I've decided to stop there and deliver it as-is. Despite the generated code's likely poor performance, it's been thoroughly tested and proven to work for most test cases both for JSON, and JSON Schema. I really, really wanted to reuse Standards.JSON API, or else I would wind up rewriting the whole JSON serialization module. That's why I ended up calling JSON.encode, which invokes the encoded object's encode_json method, inside JSON.decode. It's necessary because Pike member names are not necessary JSON's keys. For exmaple, 'else' is a perfectly valid key name in JSON, while it's a reserved keyword in many programming languages. QuickType has it's ways to handle such situations. Another known blunder is that it tends to append member declarations with 'mixed' when rendering from JSON Schemas. It's likely related to how QuickType handles Schema's optional properties. Here you can play around with it: https://app.quicktype.io/#l=pike If anyone's interested in improving this feature, hit me up or issue a pull request straight to the QuickType repo. If you find any more bugs, do not hesitate to open an issue there. pt., 11 sty 2019 o 16:30 Tobias S. Josefowitz @ Pike developers forum < 10353(a)lyskom.lysator.liu.se> napisał(a): > >Those don’t count ;) > > Well, yes, my point being these are why the return type even includes > |object. >

2 1

Re: sortera filer
by Peter Bortas 14 Jan '19

14 Jan '19

On Mon, Jan 14, 2019 at 10:35 AM Mateusz Krawczuk <mkrawczuk(a)opera.com> wrote: > > Wouldn't it be better to go straight to Pike-devel to preserve the wisdom for broader audience? On the odd chance that pike-devel want late night musings in Swedish, then sure. I'm going to veto anyone else doing that though, so I don't think the chances of everyone agreeing to see my badly thought thru rants are high. Anyways, time to write something more coherent: We need a better API for handling directory listing, especially for coupling the listings with their metadata (stat struct). At the moment this is the most compact way of listing files in a dir sorted by creation time I could come up with: string mydir = "/tmp"; array files = get_dir(mydir); files = combine_path(mydir, files[*]); sort(files, file_stat(files[*])->ctime); And whenever automap feels like a good idea the API probably needs to be looked at. This will also explode in your face if files have been deleted between get_dir() and file_stat(). The question is what that API should be. We have a slightly extended API available in Filesystem: object fs = Filesystem.System("/tmp"); array files = fs->get_dir(); sort(files, fs->get_stats()->ctime); While this is cute if the directory contents is completely static (see Filesystem.Tar), not so much otherwise. I have some ideas of how a new API should look, basically: 1. Add a function (possibly to Filesystem) that returns both the listing and stats, so that TOCTOU error handling can be kept away from the user. 2. Add a convenience function where you can request a already sorted list based on any criteria you want. 3. bonus: more iterators Regards, -- Peter Bortas

1 0

Re: QuickType support
by Tobias S. Josefowitz ＠ Pike developers forum 11 Jan '19

11 Jan '19

>Those donât count ;) Well, yes, my point being these are why the return type even includes |object.

1 0

QuickType support
by Mateusz Krawczuk 09 Jan '19

09 Jan '19

Inspired by the debugger discussion, I've started implementing QuickType support for the Pike language. You can check it out by cloning my github fork[1], checking out to 'Pike' branch, and following the 'Contribute' section in README.md. After successful installation, you can run $ ./script/quicktype --lang pike test/inputs/json/samples/pokedex.json to see if it's working fine. The main motivation for this is generate Pike classes for the JSON-RPC messages specified in Microsoft's Debugger Adapter Protocol and Language Server Protocol. I imagine this could also turn out handy for people working with JSON-based APIs. There is plenty of work to be done here, like supporting enums and handling reserved statements, so I encourage you to contribute! Any feeback is more than appreciated. Mateusz [1] https://github.com/mkrawczuk/quicktype/tree/Pike

3 4

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