Clojurians Log v2

planting ideas: https://github.com/nodejs-tensorflow/nodejs-tensorflow

Sometimes I feel like we should have two versions of the lumo exec. One is for fast repl (startup counts). One maybe slower but with source maps enabled, v8 inspector...all this. Or at least have a way to generate it from boot for power users...just a random thought 😀

@richiardiandrea Planck lazily loads source maps to try to get the best of both worlds

Also, there are some ridiculous optimizations you can do to source maps, given that there is no browser involved. https://twitter.com/mfikes/status/901247359174275077

@mfikes yes that is a good solution I guess, but Antonio was wondering whether including the *aot.js.map file was slowing down lumo

and by including I mean bundling

@richiardiandrea I suspect that simply bundling would only make the binary larger, and perhaps not slow it down, unless the source map file is extracted from the bundle and used in any way. For example, nothing at all occurs with respect to source maps in Planck, until planck.repl/load-bundled-source-maps! is called, at which point they are “unbundled” into the runtime environment. This function doesn’t get called until an exception is printed (which may never occur for most scripts)

@richiardiandrea again, different concerns

Core.js.aot.map is for project compilation

There's no support for source maps at the repl in lumo yet

Because it's hard to map stacktraces in the snapshot

yeah the slower lumo would be for compiling only...but please disregard my words, first of all we need to see if things are slower

related to this @anmonteiro master is failing here:

==== C stack trace ===============================

    /home/arichiardi/git/lumo/tmp/node/8.4.0/node-v8.4.0/out/Release/mksnapshot(v8::base::debug::StackTrace::StackTrace()+0x16) [0x134b526]
    /home/arichiardi/git/lumo/tmp/node/8.4.0/node-v8.4.0/out/Release/mksnapshot() [0x109fef6]
    /home/arichiardi/git/lumo/tmp/node/8.4.0/node-v8.4.0/out/Release/mksnapshot(V8_Fatal+0xea) [0x109c19a]
    /home/arichiardi/git/lumo/tmp/node/8.4.0/node-v8.4.0/out/Release/mksnapshot(main+0x361) [0x7e3421]
    /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7fd794897830]
    /home/arichiardi/git/lumo/tmp/node/8.4.0/node-v8.4.0/out/Release/mksnapshot(_start+0x29) [0x7e3ad9]
Received signal 4 ILL_ILLOPN 00000109f1f9
Illegal instruction (core dumped)
make[1]: *** [/home/arichiardi/git/lumo/tmp/node/8.4.0/node-v8.4.0/out/Release/obj.target/v8_snapshot/geni/snapshot.cc] Error 132
deps/v8/src/v8_snapshot.target.mk:13: recipe for target '/home/arichiardi/git/lumo/tmp/node/8.4.0/node-v8.4.0/out/Release/obj.target/v8_snapshot/geni/snapshot.cc' failed
rm d8b01c6ff73109cd7c9acae668e77052cc5cc14f.intermediate
Makefile:76: recipe for target 'node' failed
make: *** [node] Error 2
....> ERROR: The release executable has not been generated. This indicates a failure in the build process. There is likely additional information above.

I may have screwed something up

Will take a look later

kk tnx!

Antonio thanks! I was going to say that I compiled without the last stuff and everything was good

I think that if I/we solve the macro issue we are good for a new shiny version 😄

@richiardiandrea thanks for what? 😛

fixing the master builds?

yeah 😄

yeah I’m an idiot

@mfikes is planck able to read macros files from within jars?

the use case would be this: https://github.com/anmonteiro/lumo/issues/239#issuecomment-327901031

@richiardiandrea Sure. It can load *.clj and *.cljc files on the classpath, be they in JARs or on disk

@mfikes maybe I am missing the "how" there, because basically all I am receiving in my load-fn is a path...and I wouldn't want to scan all the jars for fetching...probably my question is, how can planck do the mapping from .clj file to .jar file?

@richiardiandrea It does exactly that, it scans for *.clj first, and then scans for *.cljc

so for all entries in the classpath? isn't it slow?

You could perhaps build an index of files to speed things up if the scanning proved to be a performance issue.

yeah

@richiardiandrea you’re conflating things again

reading from JARs also works in Lumo

@richiardiandrea Planck used to keep zip archives open just to ensure the index could be read quickly (when it was in Objective C). It no longer even does that and simply calls zip_open

if you require core.async at the REPL it’ll work

we may be seeing a different problem with compilation

@anmonteiro it works at repl because you have load-fn passed in right?

wait