joined macroid group so msg would go through (last didn't), but another thing I see come up and that's in your docs right now is slow compile times on large projects. I must be the only person to experience the exact opposite b/c I've seen that stated by a few people.
One of the sole reasons I even started using scala was (a) the incremental compiler actually worked and didn't spit out random bad builds on me (b) compilation times dropped roughly 30% (I have raw stats in some private emails somewhere) with a generic project conversion and then dropped even more, from 2.5 minutes on original java project (no proguard) to 45 seconds after diving in and writing proper scala. (c) Lines of code dropped significantly, from around 20k to 12k (and still dropping) On Tue, Jul 22, 2014 at 1:35 PM, Daniel Skinner <[email protected]> wrote: > well, coming from someone (me) who read the docs but didn't adopt macroid, >>> I thought the docs were great. >>> >> >> Thanks! You are more than welcome to elaborate why you did not adopt it >> though ;) >> >> >>> A short paragraph or two of a high level overview of the implementation >>> before diving into the samples would be nice. >>> >> >> I guess recipes have higher priority for now, but it would be interesting >> to see what aspects of implementation you are interested in (performance is >> different from implementation, as it has to be substantiated with >> benchmarks). >> > > You're right, talking about performance implies benchmarks. I'm not > promoting some set of microbenchmarks are needed here to be clear though. > My knowledge may be outdated but as I recall, xml templates are parsed to a > binary format during app packaging to speed up loading of a layout during > runtime. So an example question I had was, on orientation change, is what's > generated by macroid inspecting the view configuration and responding live > in the app by generating a new viewgroup or does it cache all the > possibilities in memory and return the appropriate one or does it transpile > to xml to take advantage of any tooling benefits, or so on. > > >> >> I vaguely recall something about it using ?compiler templates? somewhere >>> in the docs. Sorry, there's still plenty I'm not familiar with in scala. >>> >> >> Do you mean macros? That’s the closest thing I can think of. They don’t >> affect performance, as the expansion is done at compile-time. Anyway, >> speaking of performance, this is clearly not my primary concern :) There is >> some wrapping going on here and there, most notably everything is wrapped >> into UI actions, and a <~ b is turned into >> TweakingOps(a).<~(b)(someTypeclassInstance). I haven’t observed any >> significant “snappiness” degradation, but again, somebody might want to >> benchmark this. Overall, Macroid should be reasonably close to the vanilla >> Java API. Obviously it’s not a good idea to use it for modern game-dev :) >> > > Right, macros. I've been needing to read up on that to tidy up a managed > event trait I wrote that makes broadcast receiver and content observer use > more orthogonal across activities, fragments, and custom views. > > My concern again comes around in the implementation. I'm working on some > fairly mid sized projects and memory is already a concern, so if I have 184 > layout files (b/c I do just looking at this one project now), I'd want an > idea of what to expect based on at least a simplistic understanding of the > implementation. > > I'd actually like to use something like macroid b/c on this particular > project, I can't use certain resource qualifiers due to the target devices. > Do avoid dup layouts, I soft link locally but that's a bad approach. > > >> >> >>> But my main concern was the implementation and runtime performance. >>> Admittedly, I don't want to type tilde a lot either but that's more of a >>> minor note. >>> >> >> Not sure if you saw this coming, but could you suggest any alternatives >> to tilde? I’m happy to introduce aliases. >> > > I didn't see that coming, no :) > > If I'm being honest, I should probably just suck it up. Most of the scala > community doesn't seem to have a problem with such things or even using > unicode characters in place of things like -> or => or even the stuff i've > seen in scalaz. > > >> >> Nick >> >>> -- >> You received this message because you are subscribed to the Google Groups >> "scala-on-android" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "scala-on-android" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
