What is in ../lib/plt dir?

[KOLANICH]

I am trying to package waxeye for Debian and I wonder what is in ../lib/plt dir? Is it a binary generated specially for waxeye? I haven't found the file with such name in debian packages for racket. Or will it be the same for all the apps in racket built with the same compiler?

I mean if that file must be generated separately and put into a separate package (if it is the same for all the binaries) or should it do something else to it (can it be embedded into waxeye binary somehow?)

[orlandohill]

Sorry, I don't know the answer to this. You could probably find out by looking at how Waxeye is built in the Makefile with Racket's raco exe and raco distribute commands, then try building a hello world Racket program the same way. Perhaps compare that to a Racket program that uses the same Racket libraries and functions as Waxeye.

Are you planning to distribute this Debian package? We still need to finish the new version before it's ready for wide distribution.

It sounded like you were doing stuff with Python. We are looking for a volunteer to help port the TypeScript code to Python, while keeping the existing Python API. Are you interested in helping us?

[KOLANICH]

Are you planning to distribute this Debian package?

Of course yes. Though I don't think that it would prevent you from making incompatible changes. IMHO it is completely OK to break compatibility when it is needed and when the API stability haven't been claimed.

We still need to finish the new version before it's ready for wide distribution.

Not quite wide, I just want to add calling it into UniGrammar (UniGrammar is a unified JSON-based (and YAML, BSON, CBOR, everything that has the same capabilities as JSON) lang to describe grammars and the eponymous tool) and then use in CI pipelines to generate parsers to be used in some of my libs.

We are looking for a volunteer to help port the TypeScript code to Python, while keeping the existing Python API. Are you interested in helping us?

IDK, it depends on size and complexity of the project. Do you mean the JS runtime? Also is it strictly needed to keep the API? I know that a lang called Haxe (which

largely follows the ECMAScript standard, but deviates where necessary

) exists which purpose is to be transpiled to

JavaScript, C++, C#, Java, JVM, Python, Lua, PHP, Flash

(though when I have tried (the try is a bit old relative to the python code) to port one of my python libs to it I got a bit dissatisfied because it had been dissallowing to use the features of python I used extensively in that lib and because the generated code had some minor inefficiency flaws (I have tried to solve that by using python.Syntax). I am not an expert in Haxe though.).

So I wonder if there would be more sense to rewrite everything possible into Haxe, so that "everything" would have the similar API (which may look not native to the conventions and patterns used in the langs, but this may be OK), but also the same code base, so it may be easier to maintain?

[glebm]

Haxe seems to be the lowest common denominator and doesn't account for differences in native string encoding so I'm not convinced it'd work as well as advertised.

Another possible approach is to have a C backend supporting both UTF-8 and UTF-16.

The C backend could be wrapped from C++, C#, Lua, JavaScript (WebAssembly), Python (for CPython only), Ruby (for both MRI and JRuby), and PHP.

The current C runtime needs to be rewritten to the new parsing machine design first (see https://github.com/waxeye-org/waxeye/issues/41)

[KOLANICH]

The C backend could be wrapped

that would require it to be compiled into a module specific not only to a language, but to an impl (cpython, pypy, graalpython) and to its version (cpython 3.7, 3.8, etc). This can be a burden.