wizawu / tyrian Goto Github PK

Hi.

Just for your information - the name 1c is the name of one of the biggest IT companies in russia. the offer a huge range of products for enterprise software and the whole programming language 1c script. if you package is going to be popular, you might get legal actions from them.

This is not actually an issue for me - just something you might want to consider

Regards

First, this is pretty cool. Nice job and thank you.

I walked through the tutorial at https://1c.wizawu.com/tutorial. It worked. However 1c env reported java 11 but the run reported java 1.8. I assume that's because nashon is deprecated in java 11?

$ 1c env

[node](https://nodejs.org/en/download)
v11.10.0

[npm](npm install -g npm)
6.9.0

[java](http://openjdk.java.net/install)
openjdk version "11.0.1" 2018-10-16
OpenJDK Runtime Environment (build 11.0.1+13-Ubuntu-3ubuntu3.18.10.1)
OpenJDK 64-Bit Server VM (build 11.0.1+13-Ubuntu-3ubuntu3.18.10.1, mixed mode, sharing)
jjs      - nashorn full version 1.8.0_191-b12
javap    - /usr/bin/javap
jar      - /usr/bin/jar

[gradle](https://gradle.org/install)
Welcome to Gradle 5.2.1!
Here are the highlights of this release:
 - Define sets of dependencies that work together with Java Platform plugin
 - New C++ plugins with dependency management built-in
 - New C++ project types for gradle init
 - Service injection into plugins and project extensions
For more details see https://docs.gradle.org/5.2.1/release-notes.html

------------------------------------------------------------
Gradle 5.2.1
------------------------------------------------------------
Build time:   2019-02-08 19:00:10 UTC
Revision:     f02764e074c32ee8851a4e1877dd1fea8ffb7183
Kotlin DSL:   1.1.3
Kotlin:       1.3.20
Groovy:       2.5.4
Ant:          Apache Ant(TM) version 1.9.13 compiled on July 10 2018
JVM:          11.0.1 (Oracle Corporation 11.0.1+13-Ubuntu-3ubuntu3.18.10.1)
OS:           Linux 4.18.0-16-generic amd64



$ 1c build main.ts
Starting type checking service...
Using 1 worker with 16095MB memory limit
Hash: 4e881c90302f6b49fa86
Version: webpack 4.29.6
Time: 1954ms
Built at: 03/15/2019 10:56:17 PM
[emit]   3.81 KiB main.js
[emit]    3.8 KiB main.js.map



$ 1c  run main.js
2019-03-15 22:56:31 [main] jdk.nashorn.internal.scripts.Script$Recompilation.L:89()
INFO: Java version 1.8.0_191

Perhaps a comment in the code itself? I was expecting these to be consistent. I was a little surprised when they weren't.

If I want to use Java in a Typescript environment, jsweet is a great option.

If I want to call Java jars from a Typescript environment, this project is a great option.

But what if I want to write Typescript in a Java environment? Java build system, java deps, I just want to create a .jar with some Java shim code and bundled javascript? This project looks like the start of a great option for that usecase.

Feel free to close, just wanted to toss it out there :)

I have a 45mb fat jar loaded with dependencies. When I loaded the fat jar into 1c, the resulting type definitions were 29mb. The definitions were so big, Visual Studio Code never managed to parse them in time for IntelliSense features. For the time being, I'm trying to find a "non-fat" (?) jar artifact. In the long run, it would be great if 1c could fragment fat jar definitions into a folder with multiple type definition files. Then, in your TypeScript files, you can individually import whatever dependencies you need. What are your thoughts on this?

Thank you.

Hi
I find this project very useful, but it has little documentation on how to setup a production ready web application, can you help ? I see it uses nashorn javascript engine so it can use multiple threads for processing?

Thanks.

It would be awesome if we could support a syntax like this for using java types, instead of the current way:

import { System } from "java.lang"

System.out.println("Test");

Is there a way to use the graalvm way var FileClass = Java.type("java.io.File"); and combine it with the autogenerated declarations? Instead of declaring the classes we could use interfaces and load the implementations as recommended by graalvm.

I can't tell you just how awesome this tool is---the only "oh man I wish it were better" for me is how long "1c build" takes even for the simple examples.

Any thoughts on why that is? Any thing I could do in terms of extra memory allocation or some such to make the build take a little less time?

Again thanks for a kick-butt tool---I've been dying for something like this to show up on the server side for a long time now

internal/modules/cjs/loader.js:1015
throw new ERR_REQUIRE_ESM(filename, parentPath, packageJsonPath);
^

Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /home/lxs/.nvm/versions/node/v12.22.10/lib/node_modules/tyrian/node_modules/antlr4/src/antlr4/index.js
require() of ES modules is not supported.
require() of /home/lxs/.nvm/versions/node/v12.22.10/lib/node_modules/tyrian/node_modules/antlr4/src/antlr4/index.js from /home/lxs/.nvm/versions/node/v12.22.10/lib/node_modules/tyrian/dist/parser/index.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename /home/lxs/.nvm/versions/node/v12.22.10/lib/node_modules/tyrian/node_modules/antlr4/src/antlr4/index.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from /home/lxs/.nvm/versions/node/v12.22.10/lib/node_modules/tyrian/node_modules/antlr4/package.json.

at Object.Module._extensions..js (internal/modules/cjs/loader.js:1015:13)
at Module.load (internal/modules/cjs/loader.js:863:32)
at Function.Module._load (internal/modules/cjs/loader.js:708:14)
at Module.require (internal/modules/cjs/loader.js:887:19)
at require (internal/modules/cjs/helpers.js:74:18)
at Object.<anonymous> (/home/lxs/.nvm/versions/node/v12.22.10/lib/node_modules/tyrian/dist/parser/index.js:26:34)
at Module._compile (internal/modules/cjs/loader.js:999:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
at Module.load (internal/modules/cjs/loader.js:863:32)
at Function.Module._load (internal/modules/cjs/loader.js:708:14) {

code: 'ERR_REQUIRE_ESM'
}

I just wasted an hour trying to make this work under windows 10, before finding about the slightly hidden limitation in guideline https://1c.wizawu.com/#/guideline. This really should be in home page and github readme.

I suggest creating a docker debian image with everything required to make it work, else I will try to setup one when i get some time.

I still didn't test it or see it in action, but this is really a cool project, an idea that can save many devs so much time 👍

Version 9.0.5 outputs the following warnings on several commans like tyrian init.

(node:32160) Warning: Accessing non-existent property 'INVALID_ALT_NUMBER' of module exports inside circular dependency
(Use `node --trace-warnings ...` to show where the warning was created)
(node:32160) Warning: Accessing non-existent property 'INVALID_ALT_NUMBER' of module exports inside circular dependency

Hi,

I was trying to build the example you provide in the repo by running tyrian build ./src/main.ts from within the http-server folder. But I got following error

Users/abaykal/.nvm/versions/node/v18.2.0/lib/node_modules/tyrian/dist/parser/index.js:26
const antlr4_1 = __importDefault(require("antlr4"));
                                 ^

Error [ERR_REQUIRE_ESM]: require() of ES Module /Users/abaykal/.nvm/versions/node/v18.2.0/lib/node_modules/tyrian/node_modules/antlr4/src/antlr4/index.js from /Users/abaykal/.nvm/versions/node/v18.2.0/lib/node_modules/tyrian/dist/parser/index.js not supported.
Instead change the require of /Users/abaykal/.nvm/versions/node/v18.2.0/lib/node_modules/tyrian/node_modules/antlr4/src/antlr4/index.js in /Users/abaykal/.nvm/versions/node/v18.2.0/lib/node_modules/tyrian/dist/parser/index.js to a dynamic import() which is available in all CommonJS modules.
    at Object.<anonymous> (/Users/abaykal/.nvm/versions/node/v18.2.0/lib/node_modules/tyrian/dist/parser/index.js:26:34)
    at Object.<anonymous> (/Users/abaykal/.nvm/versions/node/v18.2.0/lib/node_modules/tyrian/dist/commands/install.js:44:29)
    at Object.<anonymous> (/Users/abaykal/.nvm/versions/node/v18.2.0/lib/node_modules/tyrian/dist/commands/index.js:8:35)
    at Object.<anonymous> (/Users/abaykal/.nvm/versions/node/v18.2.0/lib/node_modules/tyrian/dist/main.js:29:36)
    at Object.<anonymous> (/Users/abaykal/.nvm/versions/node/v18.2.0/lib/node_modules/tyrian/bin/tyrian:3:1) {
  code: 'ERR_REQUIRE_ESM'
}

My environment is as such

java --version                
openjdk 18.0.1.1 2022-04-22
OpenJDK Runtime Environment (build 18.0.1.1+2-6)
OpenJDK 64-Bit Server VM (build 18.0.1.1+2-6, mixed mode, sharing)

gradle --version

------------------------------------------------------------
Gradle 7.1.1
------------------------------------------------------------

Build time:   2021-07-02 12:16:43 UTC
Revision:     774525a055494e0ece39f522ac7ad17498ce032c

Kotlin:       1.4.31
Groovy:       3.0.7
Ant:          Apache Ant(TM) version 1.10.9 compiled on September 27 2020
JVM:          16.0.1 (Homebrew 16.0.1+0)
OS:           Mac OS X 12.4 x86_64

node --version
v18.2.0

java.lang.System.out.println("hello world")

compile failed

I think there should be a complete example project.

Is the project backed by a company?
Maybe it would be a great endorsement to know the company using it in production and for what more specific usage.

Hi,

is there a way to actually debug the code (breakpoints, stepping through, inspection) using vscode?

I'm pleased to see how smooth it runs. But without a proper way to debug it's not really fun.

Given that nashorn is deprecated and apparently on its way out of the JDK is there a migration plan for 1c to something else?

Is it possible to use the generated JS file outside the 1c environment, i.e. without using "1c run?"

Can i take the built JS file and just run it using jjs for example, or do i need some magic bits to make that work?

Hello,

First, I'd like to thank you for making this project. I've always wanted to bridge together TypeScript with the JVM.

All of my dependencies are custom built jar artifacts that aren't available through MVN. Could there please be an option to build type definitions from manually supplied jars rather than having to go through mvnRepositories? Thank you.

Hello,
I got interested into this project and I would like to know if it's possible to have annotations working with this.
Would it be possible also to use Spring Boot?

Is it possible to have annotations?

Would the annotations be written into Typescript and then converted to AspectJ or what would be the process?

It will be nice to use 1c to generate typings for Java libraries but use graalvm (with all his node support https://www.graalvm.org/docs/reference-manual/languages/js/ ) instead of nashorn.

The 1c command-line interface is a very handy tool to get started fast, however, I believe that it'll also be great to expose internal functions such as jar disassembly as importable modules. eg:

import { parseJar, buildDefinition } from "1c";

buildDefinition("./lib/@types/a.d.ts", parseJar("./lib/a.jar"));

That way, developers can extend upon the features provided in 1c in their own applications or libraries.

Thank you.

Your connection is not private
Attackers might be trying to steal your information from tyrian.wizawu.com (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_DATE_INVALID