Skip to content

Latest commit

 

History

History
295 lines (239 loc) · 10.9 KB

Notes.org

File metadata and controls

295 lines (239 loc) · 10.9 KB

Notes About Camp

Features

new command

$ camp new myapp

This should:

  • create a new directory
  • add a .gitignore
  • add a project.clj
    • includes lein-esque deps
  • add src/myapp/core.clj

deps command

  • fetch deps from nuget
  • be able to gather all target framework compatible libs, content, and tools.
$ camp deps

compile command

  • fetch deps in not already there
    • Oops, forgot about this part. I’ll get to it later.
  • construct a Clojure.Compiler command line
  • output goes in targets dir
$ camp compile

fix compile task to check deps

License

License

README.md

  • Give vision
  • Show example
  • Mention road map

Packaging

  • nuget package
    • update: I actually don’t think this is necessary. Choco package is needed anyway, and consists of a nuget package already.
  • chocolatey package
    • This is easy and will add a lot of value in not making people have to futz with their PATH.

templates

  • I like the way leiningen templates work. Something like that…

repl

  • just fire up a repl with the project loaded for now.

WIP icon for camp.exe

  • Make chocolatey stop complaining about missing icon.
  • Tried adding an icon URL, but that appears to be for the chocolatey website, not shimgen.

Announce

  • screen casts
  • clojure-clr google group
  • twitter
  • seajure
  • reddit
  • lobste.rs/hackernews, …

deploy task

  • I want this now, since tools.nrepl has no nuget package yet
  • Must handle project names like org.clojure.clr/tools.nrepl

BACKLOG Camp always compiles with clojure it was compiled with

  • It’s going to pick up the Clojure.dll in the camp.exe directory.
  • Maybe switch to doing something like what the camp build script does, where tools are copied into a working directory from deps, and use the Clojure.Compiler.exe from deps?

BACKLOG Tests for camp itself

  • Try different testing libs and see which one works.
  • Strategy: 0.1.0 is a spike. Need to think about maintenance from 0.1.1 on wards.

BACKLOG clean task

BACKLOG nrepl

  • read somewhere that it “almost works”

BACKLOG test task

  • based on experience with lein test and whatever I learn doing tests for camp itself.

BACKLOG assembly merging

  • ILMerge has issues.
  • Maybe try Jeffery Richter idea
    • have a stub EXE with assemblies embedded as resources
    • there was some problem with that, though, too, AFAIR.
  • Try using GenContext and Compiler directly, with one context, generating one assembly.

BACKLOG assembly attributes

  • Especially version attributes
  • Looks like it might be a pain.
  • Check with MSOT: if I can sign contrib agreement, maybe just send a patch.
  • But then I’m dependent on a future release of ClojureCLR nuget package.

BACKLOG resources

Need a way to embed resources in assemblies.

  • resource compiler
  • lots of JVM projects depend on resources and I imagine CLR ones will too.

BACKLOG run task

  • Is it even needed?
  • Should be pretty simple to get going.

BACKLOG Mono?

  • This is probably really important
  • Just don’t do anything that won’t run on mono - keep it simple.
  • Less worried about building camp itself on mono.
  • Research how platform works in nuget with mono
    • Maybe making some bad assumptions in deps.clj?

BACKLOG plug-ins

BACKLOG compiling other languages

  • C#, F#
  • Similar to how leiningen compiles java

BACKLOG profiles

BACKLOG Support multiple nuget repositories

  • For people that have private repos
  • So project :nuget-repository would be a vector or something

BACKLOG Library for making webapi more palatable for clojure use

  • defcontroller?

Ideas

Camping Metaphor

Winnebago or One-Person Tent

  • You can go crazy and :require all the things (Winnebago), or travel light and keep it simple.

Base Camp

  • You can create one project, then take what you want for it and go on up the mountain to the next project, establishing a new camp.
  • Mountaineering with a base camp and camp I, camp II, …
    • Vague…I am really thinking about being able to quickly re-use assets (think: “I have bootstrap over there already. Just use that!”, or “On a plane. Can’t restore packages. Please re-use package I already downloaded over there.”, like maven.)
  • Also like the George Carlin sketch about going to Honolulu with a bunch of stuff, then taking less stuff for a couple of days to Maui, then even less stuff somewhere else…

Camping is just fun

eval-in-project

  • Leverage app domains to make it easier to eval-in-project

Use other tools as exes or libs

Camp needs to use other tools, like the clojure compiler, nuget, etc. Is it better to use those other tools as executables, as a rule, or use as a library when available?

For example, to restore dependencies, camp could generate a packages.config file and shell out to nuget.exe to restore them.

Notes

Clojure Compiler

  • Compiling and loading in ClojureCLR
  • `clojure.core/compile’ calls /load, then eventually, `clojure.lang.RT/load’.
    • clojure.core/compile also binds compile-files true.
  • If the .clj file is newer than the .clj.dll, it compiles the source file.
  • It looks at `Compiler.CompileFilesVar.’ to determine if it wants to Compile or LoadScript.
  • The clojure symbol for CompileFilesVar is `clojure.core/*compile-files*’ and it defaults to false.
  • Eventually this makes it’s way to clojure.lang.Compiler.Compile.
  • This uses a GenContext, a TypeBuilder, and a CljILGen to generate IL into the context, then finally save it to an assembly with GenContext::SaveAssembly.
  • GenContext::SaveAssembly uses the DLR to actually write out the assembly.
  • compile-path is where the assemblies go, not where it expects to find src files.
  • When looking for source files, the compiler looks at the environment variable CLOJURE_LOAD_PATH, in addition to a bunch of other places.
    • CLOJURE_LOAD_PATH can contain multiple paths delimited by Path.PathSeparator.
  • clojure.core/*compiler-options*
    • {:elide-meta #{:some-key :some-other-key} :disable-locals-clearing true|false{}

NGen

  • I would hate working on this if I hadn’t NGen’d Clojure.Compile…so fast!
  • x64 vs. x32

ClojureScript

  • If we make a nuget package for it, we could make a camp task to compile ClojureScript.

How I work on camp

2014-02-18

  • In emacs, with projectile, clojure-mode
  • I have my compile command set to something like:
    msbuild /t:CampExe /verbosity:minimal && targets\camp.main.exe ...
        
  • When I was making the new task, I created a scratch project like:
    targets\camp.main.exe new scratch-project
        
  • For other tasks, I just cd into the scratch project and run camp out of targets. Like right now, working on compile task:
    msbuild /t:CampExe /verbosity:minimal && \
      cd scratch-project && \
      ..\targets\camp.main.exe compile
        
  • With the NGen’d compiler being so fast, I have been using println debugging and just looking at the compilation buffer output. That has been working pretty well so far.
  • Many times, I’ve really wanted to use a repl, though.
    • I don’t know how well nrepl works with ClojureCLR yet, but it’s on my TODO list to investigate this.
    • I’m not that interested in a plain-old REPL, I want to be able to use the REPL in emacs and eval forms while I am working.

2014-02-21

I added build targets for testing, so “msbuild /verbosity:minimal /t:TestCompile”, etc.

Deploy Task Package Naming

  • NuGet Guidance on Package Id Conventions
    • Like .NET namespaces
    • Don’t use dashes, use dots instead
  • Maybe camp itself could turn slashes in dependency specs into dots?
    • This would look more like clojure
  • Not finding much else in the way of guidance or specification of legal package ids.

NuGet Packaging

  • IncludeReferencedProjects option to nuget pack
  • Configuration option to nuget pack
    • Seems related to profiles
  • tools files
    • Might make sense to support designating some files as tools
    • tools is how chocolatey works, so maybe this would be a nice way to unify application and library packaging.
  • content
    • Gets copied to root of application, so need to support paths.
    • Coming around to the idea that this is where most of the things packaged into jars as resources on JVM clojure belong.
      • Of course there are other kinds of resources, like the ones that belong

in .NET assembly resources.

  • Deploying web applications this way makes a lot of sense.

Sources