Fork me on GitHub
#lumo
<
2017-09-07
>
richiardiandrea14:09:45

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 😀

mfikes16:09:41

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

mfikes16:09:31

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

richiardiandrea16:09:19

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

richiardiandrea16:09:02

and by including I mean bundling

mfikes16:09:35

@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)

anmonteiro16:09:42

@richiardiandrea again, different concerns

anmonteiro16:09:06

Core.js.aot.map is for project compilation

anmonteiro16:09:30

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

anmonteiro16:09:44

Because it's hard to map stacktraces in the snapshot

richiardiandrea16:09:42

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

richiardiandrea16:09:13

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.

anmonteiro16:09:52

I may have screwed something up

anmonteiro16:09:59

Will take a look later

richiardiandrea17:09:47

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

richiardiandrea17:09:59

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

anmonteiro18:09:10

fixing the master builds?

anmonteiro18:09:30

yeah I’m an idiot

richiardiandrea19:09:37

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

mfikes19:09:27

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

richiardiandrea19:09:26

@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?

mfikes19:09:33

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

richiardiandrea19:09:09

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

mfikes19:09:11

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

anmonteiro19:09:31

@richiardiandrea you’re conflating things again

anmonteiro19:09:38

reading from JARs also works in Lumo

mfikes19:09:39

@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

anmonteiro19:09:59

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

anmonteiro19:09:06

we may be seeing a different problem with compilation

richiardiandrea19:09:36

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