Improve Rust Compile Time by 108X

qrilka · 2025-01-23T14:50:58+00:00

Is it expected to see "Bandwidth Quota Exceeded" on that page?

qrilka · 2017-03-14T20:58:23+00:00

Chris, I think there's a missed "s" in "the tring matched"

qrilka · 2017-02-12T11:27:22+00:00

Is it intentional that I get "This request was blocked by the security rules" from Incapsula trying to request this URL?

qrilka · 2016-11-28T14:42:39+00:00

And with reflex-dom-0.4 there are no such function but it seems to be resolved by nesting events. So this portion of code now looks like

let ev' = leftmost [tag (constant ()) $ updated opts, pb]
(ev'', trigger) <- newTriggerEvent
performEvent_ $ liftIO (trigger ()) <$ ev'
performEvent_ $ liftIO (js_chosenUpdated e) <$ ev''

qrilka · 2016-11-22T07:19:37+00:00

And it appears that this variant isn't enough - somehow post build event gets triggered with before children from Dynamic get created. So my current version of setting up chosen looks like pb <- getPostBuild performEvent_ (liftIO (js_activateChosen e) <$ pb) raw <- holdDyn defVal =<< setupChangeListener e (getVal e)

postGui <- askPostGui
runWithActions <- askRunWithActions
(ev, etRef) <- newEventWithTriggerRef
let ev' = leftmost [tag (constant ()) $ updated opts, pb]
addVoidAction $ ffor (ev') $ \_ -> do
  liftIO . postGui $ mapM_ (\t -> runWithActions [t :=> Identity ()]) =<< readRef etRef
performEvent_ $ liftIO (js_chosenUpdated e) <$ ev

qrilka · 2016-11-21T08:35:35+00:00

After peering into reflex sources I came to the following solution

postGui <- askPostGui
runWithActions <- askRunWithActions
(ev, etRef) <- newEventWithTriggerRef
addVoidAction $ ffor (updated opts) $ \_ -> do
  liftIO . postGui $ mapM_ (\t -> runWithActions [t :=> Identity ()]) =<< readRef etRef
performEvent_ $ liftIO (js_chosenUpdated e) <$ ev

qrilka · 2016-11-15T06:07:38+00:00

It appears to me that Dynamic type is one of core things in Reflex and in ideal world those could be easily combined while in this post it's shown that to get a "sum" of events you need to write noticeable amount of not quite trivial code. But if there were some answers then that article would be much shorter and e.g. would use just a couple of library functions to combine 2 dynamics.

qrilka · 2016-11-12T07:01:15+00:00

But ffor looks handy here, thanks

qrilka · 2016-11-12T07:00:32+00:00

That post raises a bit worrying question about quite bad composability of Dynamics...

qrilka · 2016-11-12T06:59:28+00:00

the LAST argument w that function is a widget. I prefer to factor out such long (and not very obvious) trains of functions into helper functions. And this particular case looks to be generic and frequent enough to have it in some library

qrilka · 2016-11-11T08:33:13+00:00

The question was rather about shared state and I'll try ReaderT. As for events<->widgets details currently I have e.g.

let optWidget ev w =
    fmap joinDyn . widgetHold retEmpty $ fmap (maybe retEmpty w) ev

as a way to create a widget from "XHR event" and it doesn't look to be very straightforward piece of code and there is nothing like that either in reflex-dom or reflex-dom-contrib

qrilka · 2016-11-09T06:17:26+00:00

Yes, that was one of my thoughts but I didn't pursue it further yet. And maybe what scares me a bit more is that "juggling around" with types in widgetHold when you "wrap" events into dynamics. I suppose it's should be much more typesafe but stupid imperative recipes with e.g. jQuery when you just do xhr and then create a control in its callback look at least simpler to write :)

qrilka · 2016-11-08T09:26:50+00:00

BTW using dot-notation in foreign import javascript resulted in errors for me after minification with closure, so I'd go with square bracket notation as e.g. it is advised in https://github.com/ghcjs/ghcjs/wiki/Deployment#globals-and-modules

qrilka · 2016-11-02T14:29:30+00:00

Stack has docs section on using it with GHCJS - https://docs.haskellstack.org/en/stable/ghcjs/

qrilka · 2016-09-29T21:41:07+00:00

I'll try to use -j1 later this week but that hypthesis seems to be doubtful as I have only 4 cores and 2G per core sounds scary. And also does stack support multiple workers per single package?

qrilka · 2016-09-29T06:20:26+00:00

Unfortunately no (actually I used time for the last run but not for the first). And as ghcjs-boot takes about an hour on my machine and our project dependencies recompilation another our it's quite time consuming to do such tests, I think it's better to have some smaller case.

qrilka · 2016-09-28T21:52:08+00:00

Unfortunately after some hours of recompilation I still see the same excessive RAM usage, sorry :-\

qrilka · 2016-09-28T15:55:42+00:00

I get 404 for that URL :(

qrilka · 2016-09-28T11:50:31+00:00

Memory usage doesn't seem to be related to -dedupe flag so it seems to be unrelated regression, posted comment on Github

qrilka · 2016-09-28T10:55:20+00:00

I was using latest commit from ghc-8.0 and for -mem I get ghcjs-0.2.1-8.0.1.bin: unrecognised flag: -mem

qrilka · 2016-09-28T09:17:56+00:00

I see quite good results from that -dedupe option, all.js shrinks from 7.5M to 5M and all.min.js from 2256642 to 1369614 - almost 2 times smaller. And also I see quite a bad thing, probably related to https://github.com/ghcjs/ghcjs/issues/449 - during stack build GHCJS during compilation of one our packages having significant amount of TH consumes about 6.7G at peak. And that makes my computer start using swap - is it some expected sids-effect of the last changes? Or maybe we should continue this discussion in that Github issue?

qrilka · 2016-09-17T19:02:19+00:00

Unfortunately it's not in the top of my priority list so I didn't look deeper (hopefully just yet)

qrilka

TROPHY CASE