What is in ../lib/plt dir? 8000 #103
Comments
|
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?
… |
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.
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.
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
) exists which purpose is to be transpiled to
(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 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? |
|
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 #41) |
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. |
I am trying to package waxeye for Debian and I wonder what is in
../lib/pltdir? 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?)
The text was updated successfully, but these errors were encountered: