This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-08-04
Channels
- # arachne (1)
- # beginners (41)
- # boot (92)
- # capetown (8)
- # cider (10)
- # cljsjs (4)
- # cljsrn (42)
- # clojure (94)
- # clojure-india (1)
- # clojure-russia (48)
- # clojure-sanfrancisco (1)
- # clojure-spec (34)
- # clojure-uk (13)
- # clojurescript (29)
- # cursive (12)
- # datavis (4)
- # datomic (10)
- # dirac (63)
- # editors-rus (16)
- # emacs (57)
- # funcool (5)
- # hoplon (22)
- # jobs (2)
- # lein-figwheel (3)
- # leiningen (5)
- # onyx (51)
- # other-languages (2)
- # proton (1)
- # protorepl (2)
- # re-frame (34)
- # remote-jobs (1)
- # sfcljs (5)
- # spacemacs (1)
- # specter (2)
- # sql (20)
- # test-check (54)
- # yada (1)
@pesterhazy: It looks like you’ve been doing some research on the react-native packager? I’ve hit a point where I can’t bundle my file anymore (due to the babel parser running out of memory). Have you had any luck circumventing it? I’m wondering if it’s possible to just give the packager a list of dependencies and then include the google closure output file in the bundling step?
yes I've run into this problem
Yeah, that workaround was working for a while, but no longer.
my workaround is to always use "--dev true"
that disables whole-program optimizations
I'd obviously like to see better solutions to this problem
the packager doesn't seem to be able to cope with the amount of code produced by the Google Closure compiler
I saw that you posted a request to have the packager follow the goog.require statements?
yes, my patch makes that work
does that help?
don't think it helps with the memory issue though
it's only relevant for development time
.. I think
to be honest, node is just not a great environment for a memory-hungry tool
especially annoying considering that it defaults to a 1.5G (?) max heap
I was never able to increase the heap for the packager workers
yeah, that’s my problem too
anyone here using DrawerLayoutAndroid
?
was trying to hook up a TouchableHighlight
to open the drawer, but its imperative interface is a bit awkward in re-frame
afaik we cant use refs
, so i was trying a wrapper component's component-did-mount
fn to get ahold of the drawer
why can't you use refs?
You can use a ref function that swaps an atom. It's a nice pattern
i was referring to react ref's, i might have read some old docs then maybe? http://stackoverflow.com/questions/32680725/show-drawerlayoutandroid-via-toolbarandroid-oniconclicked
@pesterhazy: could you show/link an example, please? i might be confused
You can use react ref, but I don't think it is anywhere in the reagent docs
Here is an example:
Inside the route-mapper, you can create a component that will then have a reference to the drawer, and can call (.openDrawer drawer)
(I haven't tested this specific code, but I implemented something like that a while ago, and it should demonstrate at least how to use ref)
@balint: here's a minimal example: https://gist.github.com/pesterhazy/4d9df2edc303e5706d547aeabe0e17e1
in the example the lifecycle method does something to the component
but you can use this in different ways
thanks a lot, guys! im gonna look at your examples when i get home (so i can replace my hacky first version of a solution)
okay this is an ugly hack, but if anyone else is desperate to just get the stupid bundler to work, try putting this at the top of this file: node_modules/babel-traverse/lib/index.js:
function scheduleGc() {
if (!global.gc) {
console.log('Garbage collection is not exposed');
return;
}
setTimeout(function(){
global.gc();
console.log('Manual gc', process.memoryUsage());
scheduleGc();
},30000);
}
// call this in the startup script of your app (once per process)
scheduleGc();
then call the bundler with these args:
node --expose-gc --max_old_space_size=4096 "./node_modules/react-native/local-cli/cli.js" bundle --entry-file ./worker.js --platform ios --dev false --reset-cache true --bundle-output "ios/worker.jsbundle”
(of course replace “worker” with whatever you are trying to build. Most likely index.ios.js?)
basically it schedules a garbage collection every 30 seconds to stop the heap size from getting too large.
does node not run GC as a last resort before crashing?
apparently not?
it'd be great to add that to the RN packager issue
that could save someone a day or two
hmm, I need to tweak it a bit. It keeps running the GC even after the thread exits.
Okay, I tweaked the code a bit to fix the thread not exiting and posted an updated comment on the github issue. https://github.com/facebook/react-native/issues/5196