P
GraalVM seems very promising
Size: a a a
2019 December 20
AA
estcontainers->Testcontainers ;-)
Вообще, "эстконтейнерс" тоже неплохое название :)
ВВ
И ещё мозг может переносить мешанину внутри слова, но первая и последняя буквы должны быть на месте.
ВВ
Видимо тут-то меня и заклинило...
OS
слушайте кто-нибудь знает хороший ssh shell в браузере?
λ
слушайте кто-нибудь знает хороший ssh shell в браузере?
Уверен, что стоит?)
λ
Доверяешь таким сервисам ?
ST
Доверяешь таким сервисам ?
возможно, Олег имеет ввиду нечто on-prem, что можно стартануть у себя и ходить на сервер по ssh через браузер
ST
но я могу ошибаться
ST
я на vertx что-то подобное поднимал
AA
слушайте кто-нибудь знает хороший ssh shell в браузере?
стартуешь виртуалку GCP, и через веб-консоль можешь любой шелл запустить 🙂
OS
Ну вот типа такого да только мне просто ссх, не в gcp :)
ST
https://vertx.io/docs/vertx-shell/java/
вот такой штукой баловался, а команд можно напихать кучу, или вообще попробовать мапить всё вводимое на OS, где шелл запущен
вот такой штукой баловался, а команд можно напихать кучу, или вообще попробовать мапить всё вводимое на OS, где шелл запущен
λ
Вообще Гугл много чего выдаёт
OS
Надо знать как спрашивать :) мне не очень много выдавал спасибо большое!
2019 December 22
OC
Each execution context is a Java object (you can think of it as an V8 engine), it's not thread-safe — so you need to access it from 1 thread at a time, but you can have multiple threads doing it at different times
is it possible to spin an event loop outside of graal-node? Promises are not working which is... sad I guess. Modern JS is all about async functions, generators and promises
we tried to understand how it's working in graal-node, and it's very simple - GraalVM have its own fork of Node, so it just rely on Node's implementation of the event loop. It's not reusable inside JS execution context created inside a raw Java process
we tried to understand how it's working in graal-node, and it's very simple - GraalVM have its own fork of Node, so it just rely on Node's implementation of the event loop. It's not reusable inside JS execution context created inside a raw Java process
OS
is it possible to spin an event loop outside of graal-node? Promises are not working which is... sad I guess. Modern JS is all about async functions, generators and promises
we tried to understand how it's working in graal-node, and it's very simple - GraalVM have its own fork of Node, so it just rely on Node's implementation of the event loop. It's not reusable inside JS execution context created inside a raw Java process
we tried to understand how it's working in graal-node, and it's very simple - GraalVM have its own fork of Node, so it just rely on Node's implementation of the event loop. It's not reusable inside JS execution context created inside a raw Java process
Of course it's possible to spin up an event loop outside of GraalVM's node. For example, I'm pretty sure deno for example has an event loop, vert.x has an event loop, plenty of other projects have event loops.
And of course promises are available and working with GraalVM. Promise is a part of ecmascript, look https://kangax.github.io/compat-table/es6/
Code that relies on the node availability and services it offers, like the event loop, of course doesn't work in a js engine that doesn't have node. This is very similar to how it won't work in v8, quickjs, etc.
And of course promises are available and working with GraalVM. Promise is a part of ecmascript, look https://kangax.github.io/compat-table/es6/
Code that relies on the node availability and services it offers, like the event loop, of course doesn't work in a js engine that doesn't have node. This is very similar to how it won't work in v8, quickjs, etc.
2019 December 24
λ
А тот баг с гц тож завезли ?