Comment by richhickey, Tue Jul 19 14:41:05 2011:

in loops

Comment by Chouser, Tue Jul 19 18:50:18 2011:

Claggett and I wrote a patch, producing this for the snippet above:

(function (){
var G__1061,repeat1054;
var i__10521055 = 0;
var j__10531056 = cljs.core.List.EMPTY;
var G_1060 = function(i1052,j_1053){
repeat1054 = false;
cljs.user.PLUS.call(null,55);
if(cljs.core.truth_(cljs.user.LT.call(null,i__1052,5)))
{
{
repeat1054 = true;
i_10521055 = cljs.user.inc.call(null,i_1052);
j__10531056 = cljs.user.conj.call(
null,j__1053, (function (){ return i__1052; }));
}
}
else
{
return cljs.user.map.call(
null,(function (p1_1049_SHARP){ return p1__1049_SHARP_.call(null); }),j__1053);
}
};
do{G__1061 = G__1060(i__10521055,j__10531056)}while(repeat1054);
return G__1061;
})()

I think this is fixed.

Munge emitted var names and emitted names in goog.provide and goog.require.

https://github.com/clojure/clojurescript/commit/389b7289391413104574a5f4c4d94d01098abf8d

Create the correct file name for namespaces with dashes.

Munge the namespace names which are output to a dependency file.

Fix the get-compiled-cljs function so that it will only compile files on the classpath. The purpose of get-compiled-cljs is to compile ClojureScript dependencies. All ClojureScript dependencies should be on the classpath. Compiled files are stored in the output directory. If a file exists in the output directory then it will not be compiled but will instead be read from that location. Before this fix, compiled files from the user's project were being read from the output directory by this function. When dashes were used in the namespace this caused duplicates to appear in the final list of files which is sent to the Closure compiler. In the new version, get-compiled-cljs will only be passed files which are on the classpath.

https://github.com/clojure/clojurescript/commit/184e6d838326be9895434a3517b34742cffba0c4

Comment by ffailla, Mon Jul 18 14:32:00 2011:

also implemented rand so that i can test memoize. changes are on the 84-memoize branch

rem, mod, and quot are all present in core.cljs and have adequate tests around them.

release-night

release-night

Comment by alandipert, Fri Jul 15 06:44:16 2011:

This is where the live stream will be: http://www.ustream.tv/channel/clojurenyc

release-night

Comment by stuarthalloway, Thu Jul 14 10:20:05 2011:

Review requested. Please see https://github.com/relevance/clojurescript/wiki/Comparators for explanation of the approach I took.

Quite a few of these are done. Is there a reason we want to implement object-array or make-array?

fixed, https://github.com/clojure/clojurescript/commit/0b7d04bad801f49db9a7c3bf3004184c07fe6843

See: http://dev.clojure.org/jira/browse/CLJS-20

Comment by ffailla, Fri Jul 15 06:16:20 2011:

i'll take a stab at this.

Comment by ffailla, Fri Jul 15 06:31:45 2011:

I have an implementation of this in the 65-delay branch. Can someone please review before I merge into master.

Comment by ffailla, Fri Jul 15 19:57:34 2011:

Implemented realized? via an IRealized protocol as well. Also in this branch

Comment by ffailla, Sat Jul 16 07:33:01 2011:

merged into master

What approach do you envision here given that we can't reliably detect integers in JavaScript?

See CLJS-370 for more reliable integer detection

May be needed for #cljs-25

I've attached two patch versions for Externs support, one that includes support for directory paths `0001-CLJS10.patch` and another, simpler, version `0002-CLJS10.patch` that has support for only js source file paths. Version 0001 could maybe do with some cleanup if necessary in the letfn form section.

Noteworthy:

• Supported options: `externs`, `use-only-custom-externs`, `target`
• The java.io.FileNotFoundException is thrown implicitly via the call to js-source-file when js source file does not exist
• Single js source file paths as well as directories are supported
• Supports only absolute paths and not relative (context class-loader based) paths. (The thought is that classpath is for defaults and special extern files provided by ClojureScript)

I have applied this patch to the externs branch. If I hear no objections, I will merge this change into master later this week or early next week.

Thanks for the patch.

I just tested with the original repo, and it works for me. Whoo!

Support for externs has been added. There are many other options we can support. I will close this issue and we can add new issues when we believe an additional option should be added.

We have a command-line build tool. Create specific issues for improvements to this tool.

nailgun solves the jvm loading issue. I have successfully used it in an ad hoc way to compile my project on change (while mingling rake and livereload) into the mix.

Here is the gist of it: https://gist.github.com/1399995

It is by no means a perfect solution but might help in identifying some ways to solve problems or do things better (ie a way to have closure's require tree updated incrementally).

Comment by bobby, Fri Jul 8 11:54:30 2011:

Could this be a good use-case for cljs as a scripting language? I have not thought it through more than asking the question, but it seems worth asking.

Comment by brentonashworth, Fri Jul 8 13:16:52 2011:

Issue #52 has to do with shebang style scripting which is a little more involved and could make use of a command-line build tool. But yes, this could be used to do "scripting" in the same way you would in C or Haskell. i.e. compile source to a fast running executable.

It may be worth considering adding an output option to cljs.closure/build that produces JavaScript which is runnable from the command-line.

Comment by bobby, Fri Jul 8 20:18:08 2011:

I was thinking more that the build script itself would be implemented in cljs as the scripting language, rather than bash/make/java -jar/whathaveyou. Thoughts? Possible?

Comment by Chouser, Sat Jul 9 19:55:53 2011:

Are you talking about writing the compiler in ClojureScript instead of Clojure so that it can be started up more quickly? Rich said that's a non-goal, at least for now.

Comment by bobby, Sat Jul 9 20:10:56 2011:

No, the compiler would stay in Clojure. I was thinking more in the way of a small build DSL written in ClojureScript that would lash all of the build steps together for cljs projects, a la Leiningen. One of the tasks/targets would be compile, and the cljs script would call out to the compiler to do its thing, but then other tasks would be to combine the various compiled scripts into a single JavaScript, running the optimizer on it, gzipping, etc. I was mostly suggesting that instead of using bash, we use ClojureScript to do the things bash would have done, leaving the rest of the infrastructure in place. Again, I don't know if this is possible yet, as I've just jumped in the past week or so, but doing so might help support our case that ClojureScript can be a viable command-line scripting tool.

All functions have implementations. Added string tests from JVM Clojure plus some new tests. All tests pass in advanced mode.

Clojure.string needs a code review. Also, nil handling is not being tested and may not work the same way as JVM Clojure. This still needs to be investigated.

replace can leverage native JavaScript instead of doing a Reimplementation in Clojure (Patch enclosed).

I just did some profiling using Google Chrome (reversing 50000 long strings):
Performance improved from 3 to 0.5 seconds.

Jürgen,

Thank you for looking into this and for the patch. However, we can't apply this patch because you have not signed a CA. Please see:

http://clojure.org/contributing

I know it's a lot of work for one small patch but if you send in a CA then hopefully you will be able to send in more patches like this in the future.

I am going to close this issue because it was mainly about implementing clojure.string. If you could please open a new issue about the performance of (reverse), that would be awesome.

Comment by bobby, Thu Jul 7 20:29:32 2011:

To continue development on cljs.string, this issue requires support for both regular expressions (#54) and refer-clojure (#64) in the ns declaration.

Comment by stuarthalloway, Sun Jul 17 19:55:03 2011:

https://github.com/relevance/clojurescript/wiki/Differences-from-Clojure]]

docs

links to ClojureScript
docs and links to source/compiled code
leaderboard (make sure it doesn't consume API calls)
how to deal with/explain missing icons on inner ring
better evidence of activity (particularly when blocked by twitter api)

clean up the code (people will follow this example so it should be good)

Some progress has been made. We now load missing images in subsequent queries and the status box shows activity.

Remaining items:

• links to ClojureScript
• docs and links to source/compiled code
• clean up the code (people will follow this example so it should be good)
• add the view history slider (shows off immutable data structures)
• additional browser support

Complete:

• leaderboard (make sure it doesn't consume API calls)
• how to deal with/explain missing icons on inner ring
• better evidence of activity (particularly when blocked by twitter api)

Access to HTML5 LocalStorage via goog is dependent on CLJS-35, as latest release of closure-library doesn't support it yet.

The code has been cleaned up and links have been added to ClojureScript, documentation and Source code.

Remaining items:

• host the application somewhere
• links to compiled code
• someone other than Brenton should review the code (is this a good example of how to write ClojureScript?)
• could use a little more design work

Since I (Brenton) won't be able to do any of these things, I am relinquishing this task to someone who can.

This could be hosted on Github with Github Pages: http://pages.github.com/

This has been done.

Twitterbuzz was the sample application. If there are issues with Twitterbuzz that someone would like to address then those should be separate issues.

Comment by richhickey, Fri Jul 1 08:28:01 2011:

Must not have any other deps (other than goog)

Comment by fogus, Fri Jul 1 08:34:57 2011:

Here is an example of a simple TODO: http://nowdothis.com/

Comment by bobby, Fri Jul 1 11:45:05 2011:

Here are two other sample Todo apps for popular JavaScript libraries:

• Backbone.js: http://documentcloud.github.com/backbone/examples/todos/index.html
• Sproutcore: http://getting-started.strobeapp.com/

Comment by jessmartin, Fri Jul 15 08:46:12 2011:

Here's a wiki page describing a proposed Sample App: https://github.com/relevance/clojurescript/wiki/Demo-Application

Comment by richhickey, Mon Jul 18 09:50:55 2011:

I'm working on a simulated annealing based layout

Comment by Chouser, Mon Jul 18 21:13:43 2011:

Still to be done for the graph:

• Stop looping when graph settles
• Add margin so avatars aren't clipped
• Filter out islands
• Hook up to live data
• Figure out if there's any way to make the results less ugly and/or useless.

implements the range function in core.cljs

I added some tests to test-stuff, thank you for the patch Arthur!

There's a patch for Clojure, here CLJ-960

Related, https://github.com/brandonbloom/clojurescript/compare/clojure:master...brandonbloom:track-pos

wip here http://github.com/clojure/clojurescript/tree/source-map

Related ticket (tracking line & col during emission) that was resolved - http://dev.clojure.org/jira/browse/CLJS-176

Later

I've started on this, https://github.com/clojure/clojurescript/tree/4-math-op-macros. Seems to works as advertised, however for some reason function printing gets borked.

Fixed, https://github.com/clojure/clojurescript/commit/8e5662d9311c580f76a64b49c0b3422c598ee2c2

Later

Comment by stuarthalloway, Thu Jun 16 00:37:49 2011:

Can I import the goog libraries when and as necessary to implement core fns? I assume I will need some math support for test.generative.

Comment by richhickey, Thu Jun 16 04:45:01 2011:

Yes, you should be able to require them, depends on #8

Later

Merged into master. Work performed by mf and ss

Comment by richhickey, Wed Jun 15 05:35:44 2011:

Nope. Issues are:

laziness - apply is lazy when called with a lazy seq and a fn which consumes the & argument lazily
js apply expects an array, not a seq
we'd like our apply to work on all js functions, not just our fns

One approach:
Our variadic fns indicate they are such by the presence of applyTo (possibly by implementing IVariadicFn protocol? - probably not, as they are of type Function). Rather than handle all arities in applyTo, this applyTo need only handle the variadic method (if the fn is arity overloaded). The variadic fn further provides maxFixedArity. We'll need a boundedLength/count fn (which counts a seq, but only up to a limit). If we are putting applyTo and maxFixedArity on the function objects, they should be scoped names, e.g. cljs$lang&applyTo

The recipe then is:
check fn for applyTo, if not present dump the argseq into an array and call JS apply
else is variadic, call (bounded-count argseq (maxFixedArity fn))
if <= maxFixedArity, dump into array and call JS apply
else call applyTo

Comment by richhickey, Fri Jun 24 05:25:53 2011:

maxFixedArity as implemented ends up being a code-removal blocker for gclosure compiler. I'm not sure if there is another impl approach that will work, or if we need another strategy. Also, let's please avoid dynamic defns in our code.

Comment by stuartsierra, Fri Jul 1 14:24:47 2011:

Laziness defeats me. The trick is making sure that every fn has an `applyTo` property, even if it only has one arity.

Comment by stuartsierra, Mon Jul 4 12:35:00 2011:

There are 4 cases to deal with:

1. Single-arity function, non-variadic. These can stay as they are.
2. Multiple-arity function, non-variadic. These can stay as they are.
3. Single-arity variadic function.

• Need to add `applyTo`
• Only one code path for invocation
  4. Multiple-arity variadic function.
• Need to add `maxFixedArgs` and `applyTo`
• Different code paths when invoked with more or less than `maxFixedArgs`
• There can be only one variadic fn body!

Case 3 is complicated by the fact that single-arity functions are currently emitted in such a way that additional properties cannot be set on the Function object.

Comment by fogus, Sat Jul 16 07:42:59 2011:

This may not make the 7/20 demo. There is a lot conspiring against a solid (and minifiable) implementation. Apply works as always, it's a little smarter about gen'ing the right code in the correct contexts, but it's still not lazy. I believe the problem lies elsewhere, but have not tracked the issue yet. I have a branch at 11-apply-mf if anyone is interested in exploring.

Comment by stuartsierra, Sat Jul 16 20:22:06 2011:

For one thing, I think the definition of `apply` should say `(<= (bounded-count args (inc fixed-arity)) fixed-arity)` instead of `(<= (bounded-count args fixed-arity) fixed-arity)`. As written now, the condition is always true.

Changing this on master breaks `apply` in some cases because `cljs$lang$applyTo` is not correctly defined.

Comment by fogus, Sun Jul 17 07:15:53 2011:

Right. You'll notice I fixed the trivial case of apply to do (effectively) that in my branch, but ran out of time to find the source of full realization that it hitting us later on.

Clojure 1.5.1, ClojureScript, cljsbuild 0.3.2

Fresh CLJS checkout from github

Thanks for the patch. I doubt that array push is inefficient, but I imagine the regularity of TransientVector operations is something that V8 likes.

fixed, http://github.com/clojure/clojurescript/commit/30bb0b9e55fb77cdfe952fbf5df763a25c4a25c5

Patch 0001 depends on patches 0001 and 0002 from CLJS-480 because of changes to the test script.