This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-09-07
Channels
- # beginners (73)
- # boot (20)
- # chestnut (8)
- # cider (36)
- # clara (37)
- # cljs-dev (21)
- # cljs-experience (1)
- # cljsrn (2)
- # clojure (163)
- # clojure-austin (3)
- # clojure-dusseldorf (6)
- # clojure-finland (1)
- # clojure-ireland (4)
- # clojure-italy (45)
- # clojure-russia (9)
- # clojure-spec (47)
- # clojure-uk (20)
- # clojurescript (107)
- # cursive (24)
- # data-science (4)
- # datomic (4)
- # defnpodcast (1)
- # fulcro (1)
- # heroku (3)
- # jobs-discuss (4)
- # juxt (52)
- # lein-figwheel (1)
- # leiningen (4)
- # lumo (37)
- # midje (5)
- # off-topic (16)
- # onyx (15)
- # portkey (11)
- # re-frame (112)
- # reagent (12)
- # rum (1)
- # specter (35)
- # uncomplicate (6)
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.
@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?