denobot on gh-pages
Update benchmarks (compare)
bartlomieju on master
refactor: snapshotting (#3753) (compare)
I had a gross problem with the tests hanging on that last pr,
the std tests would run, and then the deno process would just hang for ages after the tests had finished, and wait until a socket timed out, at which point the deno process would exit
adding an explicit
close(rid) after I get the EOF seemed to fix that, and also seemed to fix denoland/deno#2923
> third_party/v8/third_party/llvm-build/Release+Asserts/bin/clang --version clang version 10.0.0 (https://github.com/llvm/llvm-project/ 64a362e7216a43e3ad44e50a89265e72aeb14294) Target: x86_64-apple-darwin18.7.0 Thread model: posix InstalledDir: /Users/rld/src/rusty_v8/third_party/v8/third_party/llvm-build/Release+Asserts/bin
v8has much lower requirements for the compiler.
std::is_trivially_copyableis the same as in nodejs/node#30020, fixed by https://chromium-review.googlesource.com/c/v8/v8/+/1868622 ?
@chrmoritz I think I'd tried that permutation, does seem to hit that: https://gist.github.com/hayd/bf1abf2553dc328049313ec22cf91cf4
I guess that fix isn't in deno's v8 yet: https://github.com/denoland/deno_third_party/blob/master/v8/src/base/macros.h
So, the problem is deno isn't bleeding edge enough :laughing:
Unsupported architecture armv6l. Only x64 binaries are available.. Is there is any workarounds to install deno in my small pi ?
To announce to the channel, in case people aren't following #1456, I was able to get deno 0.22.0 working in AWS Lambda. An interesting part is you can pass the DENO_DIR to avoid any runtime compilation. https://github.com/hayd/deno_docker/tree/master/aws-lambda#prepare-zip-file-to-upload-to-aws-lambda
Still a bit to flesh out... also not sure on best practices (e.g. layers / serverless).
libraryby URL? is that what HTTP proxies are for? is there a recommended solution aside from a monorepo? just using import maps to a vendored copy?
Is there a way to prevent TS compiler from removing unused imports in compiled code?
This would render lock useless until I actually use stuff imported from remote module
There is a long standing issue of this, if you don't want it to elide, just use
import "foo.ts"... If you are using a type only imports, you need to do it twice then. Lots of people complain about it, but I side with TS team, if you only need types from the file, the import should be erased, just like types are erased. @kevinkassimo