Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Ghost
    @ghost~540393fe163965c9bc2018ce
    try now
    Chip Senkbeil
    @chipsenkbeil
    Looks like that fixed sbt resolution.
    Still don't know why loading the project definition takes so long through Drone but is lightning quick on my local machines. That even includes a Macbook Air running an ArchLinux VM.
    Oh, wait.
    Dependencies. Of course. It's grabbing Coursier and the other plugins for the first time.
    Ghost
    @ghost~540393fe163965c9bc2018ce
    yeah, so this is what I meant by creating a new cached image
    ensime/ensime:latest is a small caching shim over ensime/ensime:v1.x
    Chip Senkbeil
    @chipsenkbeil
    Ah, I see.
    Ghost
    @ghost~540393fe163965c9bc2018ce
    but we don't have any caching shims over v2.x
    coursier bits should be way faster than sbt. the plugins will be the slowest bit
    btw, what are your scala dependenies?
    because we really need to minimise our scala deps in the server. we already have way too many
    plugins are fine, I mean runtime
    Chip Senkbeil
    @chipsenkbeil
    The API only depends on macros, which has no code in it, currently.
    And assumes there is logging provided.
    If not, it just uses the SLF4J static nop logger.
    Macros == the macros module of the Scala debugger.
    So, fairly lightweight.
    Ghost
    @ghost~540393fe163965c9bc2018ce
    ok all internal, that's fine
    Chip Senkbeil
    @chipsenkbeil
    Yep
    Ghost
    @ghost~540393fe163965c9bc2018ce
    you might have better luck using compiler plugins in ENSIME
    macros break the PC as you probably noticed
    Chip Senkbeil
    @chipsenkbeil
    Yep.
    Anyway, off to get lunch. Thanks for the help!
    Chip Senkbeil
    @chipsenkbeil
    Other than the fact that an implicit class can take one non-implicit value as a constructor argument, are there any advantages/disadvantages to using implicit methods that convert to wrapper classes as opposed to using implicit classes?
    I'd like the option to be something like this... 
    import org.scaladebugger.api.dsl._
val s: ScalaVirtualMachine = _

// Now implicitly added, normal method is getOrCreateBreakpointRequest(...)
s.forBreakpoint(...)
    import org.scaladebugger.api.dsl.BreakpointDSL
val s: ScalaVirtualMachine = _

// Does same thing as other DSL implicit
s.forBreakpoint(...)
    I would prefer not to stick a ton of implicit classes in one file (package object).
    So, if I could create individual files for BreakpointDSL and others, I would be happy.
    But I would need to stick into the package object implicit methods to convert to the wrapper classes.
    Chip Senkbeil
    @chipsenkbeil
    And I couldn't have the methods the same name as the classes, so that would flood the namespace when you want to import.
    So, that's an advantage for implicit classes, I guess.
    FYI, I'm converting to more standard names with the option of importing a DSL because some of the ways I'm using the api in Ensime don't make as much sense when you break up the method chain.
    E.g.
    // Looks weird by itself
val b = s.forBreakpoint(...)

// Looks better by itself (even though verbose) and explains what is going on
val b = s.getOrCreateBreakpointRequest(...)

// In another file
b.map(...).foreach(...)
    Ghost
    @ghost~540393fe163965c9bc2018ce
    btw, you could post this stuff on the ensime/ensime-server channel :-)
    worst that could happen is that somebody wants to help
    once people see activity in the debugging area, you might be surprised how interested people are
    you'll at least get thoughts on how people wish debugging worked
    Rory Graves
    @rorygraves
    P.s. for the record, I have no idea of the best approach here....
    Chip Senkbeil
    @chipsenkbeil
    If you're fine with me flooding ensime-server with questions as they pop up, I'll start doing that. :) Think I've got most of the technical questions answered for the time being, though. FYI, I went with methods and separate files for non-implicit classes.
    Ghost
    @ghost~540393fe163965c9bc2018ce
    it could do with some activity to be honest
    Chip Senkbeil
    @chipsenkbeil
    @rorygraves, sent you a reply with my abstract and general outline. There's too much to cover even in a normal talk, so I'll trim it down if the talk gets accepted. Any feedback at all on the bio, abstract, etc. would be much appreciated!
    I cc'd @fommil as well so he could get an idea of what the talk could potentially cover. Sam, I'd love to get any feedback you might have as well.
    Will probably forward it to @dickwall as well to get one more pair of eyes.
    I've had a really rough time getting accepted to talk anywhere, so going to give this one as much editing as possible before I submit.
    @dickwall, sent my ScalaSphere abstract to the email you have under github. Would really appreciate any feedback you could give me. Going to try to send it out tomorrow (Saturday) or Sunday at the latest.
    Ghost
    @ghost~540393fe163965c9bc2018ce
    Cool!
    Rory Graves
    @rorygraves
    Ping my thoughts. Sure @fommil and @dickwall will have some useful thoughts.
    Chip Senkbeil
    @chipsenkbeil
    @rorygraves, thanks for the feedback! I think I'm going to try merging your recommendations with my initial draft. I like bits and pieces from each. @fommil, I was more concerned with getting accepted than whether or not there was more than one track. It is good to know that I won't have to compete with others if I get accepted, though!
    Rory Graves
    @rorygraves
    Cool. Makes sense.