Pike-devel

pike-devel@lists.lysator.liu.se

1 participants
3045 discussions

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

Process.run( ... ({ "stdin": "" }) ) fails
by ceder (-) Per Cederqvist ＠ Pike (-) developers forum 09 Jan '19

09 Jan '19

Process.run fails if stdin is an empty string. Here is a toy program that demonstrates it: -- cut here -- void run(string input) { werror("Input: %O\n", input); werror("Result: %O\n", Process.run( ({ "od", "-c" }), ([ "stdin": input ]) )); } int main() { run("foo"); run(""); return 0; } -- cut here -- The for invocation (which essentiall runs "echo foo | od -c") works fine. The second crashes with an error message: "Failed to convert argument to a source". This used to work in Pike 7.8, but fails in Pike 8.0.388 (in the version distributed with Debian 9 ("stretch")), and on the 8.0 and master branches in the Pike git repo. The complete output I'm seeing is: Input: "foo" Result: ([ /* 3 elements */ "exitcode": 0, "stderr": "", "stdout": "0000000 f o o\n" "0000003\n" ]) Input: "" Failed to convert argument to a source /usr/lib/pike8.0/modules/Shuffler.so:1: Shuffler.Shuffle()->add_source("") /usr/lib/pike8.0/modules/Process.pmod:617: Process.run(({"od","-c"}),mapping[1]) run-stdin.pike:4: /main()->run("") run-stdin.pike:11: /main()->main()

3 4

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

line number storage and included files
by H. William Welliver III 26 Nov '18

26 Nov '18

Hi all, I’ve been looking at the linenumbers element in struct program as a means of getting offsets for a given line number. Since a program can be made up of multiple files through includes, I need to make sure that when I look through the entries, that I’m only comparing line numbers that come from the file I’m interested in. The initial file marker entry appears correctly, however, when the file changes, a new marker entry doesn’t seem to be inserted in the array. I see that the line numbers jump correctly, but there is no other indication that the source of the lines has changed. Is this intentional, or am I missing something? Here’s an example tracing through a program with a file included within a function definition. cnt: 127 <— beginning of program new file file: /Users/hww3/bpt.pike cnt: 0 line: 0 0x0 cnt: 36 line: 2 0x24 cnt: -127 line: 4 0xcd cnt: 54 line: 5 0x103 cnt: -127 line: 8 0x1ab cnt: -127 line: 9 0x23e cnt: 34 line: 10 0x260 cnt: 116 line: 12 0x2d4 cnt: -127 line: 14 0x37d cnt: 69 line: 15 0x3c2 cnt: -127 line: 16 0x467 cnt: -127 line: 18 0x52c cnt: -127 line: 19 0x5ff cnt: 76 line: 1 0x64b <— included file, line number jumps to 1, but no marker cnt: 114 line: 2 0x6bd cnt: 80 line: 21 0x70d <— back to original file, but also no marker cnt: -127 line: 22 0x7a6

4 10

Jump to page:

2026

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