Right now you have to run dust get-deps to set the load path, even if you don't have any dependencies. This is potentially very confusing.

The following code should throw an exception because recur is not called from a tail position. Instead it always returns 1.

(defn factorial [n]
  (if (zero? n)
    1
    (* n (recur (dec n)))))

I just compiled the pixie-vm and put dust on my path from a fresh checkout of this repo and am having trouble getting the example/tests projects working. Any ideas on what I am doing wrong?

spencerherzberg@spencerherzberg-mbp~/workspace/dust/examples/tests[master]
$ dust test
[/Users/spencerherzberg/workspace/pixie /Users/spencerherzberg/workspace/pixie/lib /Users/spencerherzberg/workspace/pixie/include /Users/spencerherzberg/workspace/pixie/../lib /Users/spencerherzberg/workspace/pixie/../include . /Users/spencerherzberg/workspace/dust/src ./src]
Looking for tests...
Loading  /Users/spencerherzberg/workspace/dust/examples/tests/test/test-core.pxi
Running: 1 tests
Running: test-core/test-greet
while running test-greet   (do (t/assert= (greet Jane) Hello, Jane!))
in pixie function test-greet_fn

in /Users/spencerherzberg/workspace/dust/examples/tests/test/test-core.pxi at 6:15
  (t/assert= (greet "Jane") "Hello, Jane!"))
              ^
RuntimeException: :pixie.stdlib/AssertionException Var greet is undefined

{:fail 1, :errors [in pixie function test-greet_fn

in /Users/spencerherzberg/workspace/dust/examples/tests/test/test-core.pxi at 6:15
  (t/assert= (greet "Jane") "Hello, Jane!"))
              ^
RuntimeException: :pixie.stdlib/AssertionException Var greet is undefined
], :pass 0}

However this works just fine:

spencerherzberg@spencerherzberg-mbp~/workspace/dust/examples/tests[master]
$ dust
user => (use 'core)
nil
user => (greet "Spencer")
"Hello, Spencer!"

dust doc exists now, thanks to @alekcz. Here are a few possible improvements to it. (Feel free to work on any of these, or add more, just say so in a comment.)

• show usage message if no argument is passed (currently an exception)
• load ns if symbol has an ns part, e.g. dust doc 'pixie.csp/put!' should work, even without -all
• fix duplicate results for -all (with pixie.csp/put! it displays the docs multiple times, with somewhat strange output)
• display signatures and examples as well
• dust doc should work outside of project directories (for the default namespaces)

It has a bunch of issues:

• uses an incorrect load path and runs any test in the load path, including those of pixie
• uses an old version of the test runner from pixie (which is broken now)
• doesn't respect :test-paths

As mentioned previously (here and here, we want to be able to fetch dependencies from places other than GitHub.

I think we should support the following:

• [user/repo "version"] for GitHub and BitBucket (GitHub being the default)
• ["git://git.papill0n.org/awesome.git" :type "git"] and ["http://hg.papill0n.org/also-awesome" :type "hg"] to support git, hg and possibly others directly, on any server
• ["http://files.papill0n.org/awesome-1.0.0.tar.gz" :type "tar"]
• ["../awesome" :type "file"] for local dependencies, resolved relative to the project root directory

@kgann has suggested using multi-methods for this, seems like a good idea to me!

If you want to work on this, please say so here!

Not sure if here or pixie is the correct place for this. Two issues:

1. Exiting using Ctrl-D doesn't actually exit, but just prints out a new prompt
2. The exit function should at least be multivalent to default to exit status of 0, even better would be if dust recognized the keyword "exit" and just exited when it saw that, without having to call the pixie (exit 0) function.

I read issue #2 and the suggestion was to install rlwrap. I have rlwrap installed (on Debian), and yet starting dust repl gives me instructions on the usage of rlwrap. Dust does appear on my path.

Problem:
Often, project developers would like to package as much as possible into the smallest set of project names. This is to minimize creation of new project files and separate repositories (eg. on github), which is work/stress for the project creator. The users of the project, however, prefer everything to be split up as much as possible to minimize the expansion of dependencies that will be included in their project.

For example, with Raynes/conch https://github.com/Raynes/conch , let say I only want to use the low level library, and not use the higher level abstraction, then I would not need [org.flatland/useful "0.10.6"](which pulls in additional dependencies).

While I could exclude this as a dependency there are some issues:

1. It's not made explicit that I don't plan to use the high level namespace.
2. It removes the potential of me wanting to use it in the future (at runtime)

The cause of this is because dependencies are specified for all namespaces. If it can be specified per namespace, then we can guarantee that:

1. Changes in API of the dependency can occur in lock step, the user only needs to update the version of the project
2. The project developer can write as many utility namespaces that may be relevant and not be concerned with dependency bloat
3. The project user won't be afraid to depend on large framework/like libraries since they can specify just the subset they require
4. Lazy usage comes for free, we can choose to acquire the utility namespaces only as they are required

Other common use cases:
clojurescript/clojure libraries that share much common code, we don't want to pull in clojurescript if we only want the clojure side.

Solution:
Currently, I at least feel there should be some discussion about this.
The backwards compatible approach would be to have a project-wide dependencies via :dependencies, and then another one where you can specify per namespace like
:ns-dependencies {'pixie.core [[foo/bar "1"] [foo/baz "1"]], 'pixie.string [[poo/bez "2"]]}

I created a few suggestions for the Dust logo. Suggestions and remixes are encouraged. I suck at drawing so it can also be something totally different.

https://mix.fiftythree.com/919291-Francisco-Viramontes/1195284/remixes

Out of the box the command seems to depend on rlwrap which does not seem to be part of osx. Also readlink shows an illegal option --f

$ dust
readlink: illegal option -- f
usage: readlink [-n] [file ...]
usage: dirname path
/usr/local/bin/dust: line 20: rlwrap: command not found

After installing rlwrap I see other weird warnings:

$ dust repl
readlink: illegal option -- f
usage: readlink [-n] [file ...]
usage: dirname path
rlwrap: warning: on this system, the getopt() library function doesn't
grok optional arguments, so '-n' is taken as an argument to the -a option
Is this what you meant? If not, please provide an argument

warnings can be silenced by the --no-warnings (-n) option
Pixie 0.1 - Interactive REPL
(darwin_x86_64, clang)
:exit-repl or Ctrl-D to quit
----------------------------
user =>

dust help does not even work:

$ dust help
readlink: illegal option -- f
usage: readlink [-n] [file ...]
usage: dirname path
Error: Cannot open '/run.pxi'

I seem to have dust in the path:

$ which dust
/usr/local/bin/dust

I built and installed the non jut pixie-vm versions so I did not get the segfaults.

$ which pixie-vm
/usr/local/bin/pixie-vm

$ pixie-vm
Pixie 0.1 - Interactive REPL
(darwin_x86_64, clang)
:exit-repl or Ctrl-D to quit
----------------------------
user =>

I would propose that, rather than replicating leinigen's defproject form, that instead Dust take a more data driven approach to project specification while we/you still have the chance.

Defproject is nice and familiar to be sure, however I would argue that we can pack all the same information into a simple map (which is what leiningen builds internally anyway). Furthermore, as such a map is data and data alone it becomes easier to automatically manipulate project files with external tools.

Just an idea I've been kicking around since Dust was proposed. I don't have time right now to hammer out a patch (finals are next week) but I'd be curious to see what y'all think of this.

Run on an x64 system with ~ 4GB RAM running Ubuntu 16.04.1 LTS

steve@steve-Satellite-L555D:$ pixie-vm --version
Pixie 0.1
steve@steve-Satellite-L555D:$ which pixie-vm
/usr/local/bin/pixie-vm
steve@steve-Satellite-L555D:$ echo $PATH
/home/steve/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/opt/unicon/bin
steve@steve-Satellite-L555D:$ git clone git://github.com/pixie-lang/dust
Cloning into 'dust'...
remote: Counting objects: 360, done.
remote: Total 360 (delta 0), reused 0 (delta 0), pack-reused 360
Receiving objects: 100% (360/360), 53.03 KiB | 0 bytes/s, done.
Resolving deltas: 100% (153/153), done.
Checking connectivity... done.
steve@steve-Satellite-L555D:$ sudo ln -s /home/steve/dust/dust /usr/bin/dust
steve@steve-Satellite-L555D:$ cd dust
steve@steve-Satellite-L555D:/dust$ vi project.edn
steve@steve-Satellite-L555D:/dust$ dust get-deps
Downloading heyLu/hiccup.pxi
steve@steve-Satellite-L555D:~/dust$ dust repl
user => (use 'hiccup.core)
ERROR:
in pixie function repl_fn

in pixie/repl.pxi at 27:24
(let [x (eval form)]
^
in internal function eval

in internal function load-ns

in internal function load-file

in internal function load-reader

Running: (def h escape-html)
in deps/heyLu/hiccup.pxi/src/hiccup/core.pxi at 16:1
(def ^{:doc "Alias for hiccup.util/escape-html"}
^
in pixie function toplevel

in deps/heyLu/hiccup.pxi/src/hiccup/core.pxi at 17:5
h escape-html)
^
RuntimeException: :pixie.stdlib/AssertionException Var escape-html is undefined

user =>

Pixie certainly has potential to be a lot faster than leiningen at rendering mustache templates. Should we add a new task like in leiningen? Is there a way that we could be backwards compatible with most leiningen templates? If so, is that desirable?

Since we cannot statically compile (yet) libs + the runtime, it could be nice to have a way to bundle pixie-vm with a lib and it's dependencies and have some kind of startup script for it to make it "transparent".

This could be something similar to makeself or UPX
From a quick test we could shrink pixie-vm to 3.1 mo with compression. That command would resolve all depedencies of a project, trigger compilation (pxic), create a platform specific script and bundle all the compiled files with pixie-vm. Upon execution the first time it would uncompress all of it in a temp/local directory and run a startup command.

This is nothing too fancy but that would make distribution a bit easier.

https://github.com/pixie-lang/dust/blob/master/run.pxi#L66

As long as a file is in test-paths it should be considered a potential candidate for testing (it can be an helper but then no tests are picked up), the file name magic is counter intuitive imho.

Do we want to go the maven way? Should we rethink the way we qualify project names since we aren't on java?