Re: Tail-recursive lazy sequence construction by appending to the end of accumulator problem.

Alexander Semenov writes: Hi Alexander, > One can create lazy sequences by wrapping each sequence element inside > a 'lazy-seq' macro while constructing the sequence. Usually it's done > with recursion. But what if I need a tail recursive construction of > the sequence (using recur) accumulating

Re: Tail-recursive lazy sequence construction by appending to the end of accumulator problem.

Hi, I'm not sure I understand your problem. As soon as you talk about loop there is no laziness involved anymore. Then just use a vector. If you need laziness then use the usual lazy-seq approach with recursion (or if possible use higher-level sequence functions). Kind regards Meikel -- You

Re: [ANN] Yet another {{mustache}} for Clojure

Yes, you are right. Stencil did a very good job. I only implement a subset. Test code . "Set Delimiter" and "lambdas" and "Dotted Names" are not implemented. The algorithm of this implementation is borrowe

Re: clojurescript failing silently?

>But the real issue is the stacktrace one. In this case, the bug could >have been found by static analysis. But in general, it can not. I experienced this same issue and tracked it down to a bug in goog, at least in my case. In my case, I was making a JSON request to the server. When the response

Re: [ANN] Yet another {{mustache}} for Clojure

Stencil is spec compliant (the tests actually run against the spec) while this implementation is not. A major goal behind stencil is to be totally spec compliant and as fast as possible. However, implementing the slow parts of the spec is important too. On Wednesday, July 11, 2012 6:28:23 PM UT

Re: Clojure shell calls results inconsistent with actual shell calls.

It's very application specific, but it's "Object 'test' does not have a field named 'test1' c:/path/to/importTest", suggesting that it's not inferring the value of an 'I' parameter which should indicate a directory within which to search for a file called 'test' which included some trivial co

Tail-recursive lazy sequence construction by appending to the end of accumulator problem.

Hi, folks. Just a quick newbie question. One can create lazy sequences by wrapping each sequence element inside a 'lazy-seq' macro while constructing the sequence. Usually it's done with recursion. But what if I need a tail recursive construction of the sequence (using recur) accumulating resu

Re: [ANN] Yet another {{mustache}} for Clojure

>From http://mustache.github.com/, I only notice clostache, which is a little slow. I have not noticed stencil, if I do, probability, I will not do one myself. It's pretty fast. My implementation seems faster than stencil, in a test run, up to 10x. Test code: https://github.com/shenfeng/mustache

Re: core cache/memoize issue?

Thank you for the report. I have a fix for the LRU/LU caches on my box and will have it out in the next day or so. The core.memoize changes will follow soon after. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to cl

Re: Clojure shell calls results inconsistent with actual shell calls.

Eric in San Diego: > That's why I'm hoping there is some way I can compare and contrast the actual > inputs that get fed into the app. At least post your exception message. MK mich...@defprotocol.org signature.asc Description: Message signed with OpenPGP using GPGMail

Re: Clojure shell calls results inconsistent with actual shell calls.

Have you already tried println'ing the args out, and/or constructing a single line like this? (def problem-cmd (str "app" "arg1" "arg2" "etc")) (sh/sh problem-cmd) -Original Message- From: Eric in San Diego Sender: clojure@googlegroups.com Date: Wed, 11 Jul 2012 15:21:03 To: Reply-To

Re: Clojure shell calls results inconsistent with actual shell calls.

On Jul 11, 2012, at 5:40 PM, Eric in San Diego wrote: > Unfortunately the application in question is kinda...involved. It's a call > to a tool provided by a third party, and installing the whole thing is > non-trivial. > > That's why I'm hoping there is some way I can compare and contrast the

Re: Clojure shell calls results inconsistent with actual shell calls.

Unfortunately the application in question is kinda...involved. It's a call to a tool provided by a third party, and installing the whole thing is non-trivial. That's why I'm hoping there is some way I can compare and contrast the actual inputs that get fed into the app. On Wednesday, July 11

Re: Clojure shell calls results inconsistent with actual shell calls.

Eric in San Diego: > my app is throwing an error How about posting the error (and a snippet of your code)? Bonus points for a Github repository that can be used to reproduce. MK mich...@defprotocol.org signature.asc Description: Message signed with OpenPGP using GPGMail

Clojure shell calls results inconsistent with actual shell calls.

In a shell, I can call > app arg1 arg2 arg3 arg4 arg5 arg6 arg7 and get my expected results. However, if I make what I think is the same call programmatically in clojure: (ns ... (:require [clojure.java.shell :as sh] )) (defn test [] (sh/sh "app" "arg1" "arg2" "arg3" "arg4" "arg5" ar

Re: [ANN] ClojureScript release 0.0-1443

> > The user can, AFAIK, specify the org.clojure/clojurescript version in > their project, and that will take precedence over the version that > lein-cljsbuild depends on. > That's good. > I guess my main reason for tying lein-cljsbuild to a specific > ClojureScript release is that not all

Re: [ANN] Nippy, a fast Clojure serializer and drop-in reader replacement

On Jul 10, 2012, at 1:51 AM, Peter Taoussanis wrote: > With the tag literal support of 1.4+, is that kind of the idiomatic way of > the future to structure protocols for serialized clojure data/code? > > Sorry, could you clarify what you're asking here - I'm not sure if I follow > what you mea

core cache/memoize issue?

Hi, I have been exploring to use core.cache and core.memoize in our clojure app and have found several issues. Those issues should have been directed to Fogus but just in case anyone has clues. core.cache (v0.6.0): 1) it appears the cache is "broken" once two entries with a same key with di

Re: Help getting Clojure/Leiningen 2.0 building with LWJGL

On Sun, Jul 8, 2012 at 7:26 PM, Karl Smeltzer wrote: > Is anybody willing and able to walk me through getting a simple project > compiling which correctly manages all the dependencies required by LWJGL > [1]? It seems that Leiningen's handling of native dependencies has changed > over time and so

Re: Help getting Clojure/Leiningen 2.0 building with LWJGL

Here's how I did it: https://github.com/Syve/lwjgl-test I have team members on multiple platforms, so I chose to go a route that will enable a repl (and lein run) to be started no matter what platform they run, without configuration. N.B. I'm not sure if this solution will work on deployed code

Re: ClojureC - A Clojure to C compiler - Work in Progress

Llvm does target iOS already, plenty of other platforms aren't so lucky tho. There is a lot of value in having a c target, it's effectively the most portable assembly language in existence. SteveT On 10 Jul 2012, at 19:09, Timothy Baldridge wrote: >> Please don't bypass C! Almost all platforms

Re: ClojureC - A Clojure to C compiler - Work in Progress

I would agree with those not wanting to bypass C, every platform on the planet has a C compiler, only a few are targeted by LLVM. SteveT On Tue, Jul 10, 2012 at 2:20 PM, Mark Probst wrote: > On Mon, Jul 9, 2012 at 7:03 PM, Adam King wrote: > > However, thanks for your work on this! In the

[ANN] Clojure/conj 2012, Nov. 15-17

Hi all, We're happy to announce that the 3rd Annual Clojure/conj is taking place November 15-17, 2012, in Raleigh, North Carolina. Tickets are now available for purchase: http://clojureconj2012.eventbrite.com/ The Conj will be preceded by our 3-day Clojure course, for which tickets are also n

Re: critique my code!

On 7/8/12 10:58 AM, William Morgan wrote: Excerpts from Alex Robbins's message of 2012-07-06 05:27:28 -0700: Reading through your code, many of your functions have large cond or condp clauses. Sometimes those can be replaced with multimethods. Thanks, that's good to know. I think in this case t

Re: [ANN] ClojureC - A Clojure to C compiler - Work in Progress

>>> 3) Unless you plan on staying strictly AOT, and igoring the REPL, then >>> we're going to need a JIT, that's not exactly something you can hack >>> together in an afternoon >> >> I don't follow. > > With a AOT compiler like this project, you don't have the ability to > play at a repl. I guess i

Re: [ANN] ClojureC - A Clojure to C compiler - Work in Progress

>> 3) Unless you plan on staying strictly AOT, and igoring the REPL, then >> we're going to need a JIT, that's not exactly something you can hack >> together in an afternoon > > I don't follow. With a AOT compiler like this project, you don't have the ability to play at a repl. I guess if you don'

Re: [ANN] ClojureC - A Clojure to C compiler - Work in Progress

On Wed, Jul 11, 2012 at 3:05 PM, Timothy Baldridge wrote: >>> I've been debating on working on a native Clojure > > I've also been debating this for over two years now,y but I keep > coming back to the same problems over and over again: > > 1) A from-scratch native Clojure either needs to be just

Re: [ANN] ClojureC - A Clojure to C compiler - Work in Progress

> You don't really need a JIT for those things, smart compile time analysis > can get as good or better results. See Stalin scheme: > > http://en.wikipedia.org/wiki/Stalin_(Scheme_implementation) True if you don't want a repl or eval, then you need a JIT. Notice it is also a "full program optimize

Re: [ANN] ClojureC - A Clojure to C compiler - Work in Progress

You don't really need a JIT for those things, smart compile time analysis can get as good or better results. See Stalin scheme: http://en.wikipedia.org/wiki/Stalin_(Scheme_implementation) On Wednesday, July 11, 2012 3:05:50 PM UTC+2, tbc++ wrote: > > >> I've been debating on working on a native

Re: [ANN] Yet another {{mustache}} for Clojure

> I did yet another {{mustache}} implementation for Clojure > > https://github.com/shenfeng/mustache.clj > > I did it because I need a faster one when I am doing Rssminer . And I dit > it. > By the way, Rssminer is yet another RSS reader, but written in Clojure. > > Usage: > > [me.shenfeng/mustache

Re: [ANN] ClojureC - A Clojure to C compiler - Work in Progress

>> I've been debating on working on a native Clojure I've also been debating this for over two years now,y but I keep coming back to the same problems over and over again: 1) A from-scratch native Clojure either needs to be just a compiler (as this project is), or you're going to need a decent GC

Re: Parsing SGML

Wolodja Wentland writes: >> --8<---cut here---start->8--- >> (defn concat-input-stream >> "Gets one or many input streams and returns a new input stream that >> concatenates the given streams." >>^java.io.InputStream [^java.io.InputStream is & more] >>

[ANN] Yet another {{mustache}} for Clojure

Hi: I did yet another {{mustache }} implementation for Clojure https://github.com/shenfeng/mustache.clj I did it because I need a faster one when I am doing Rssminer . And I dit it. By the way, Rssminer is yet another RSS reader, but written in

Re: [ANN] ClojureC - A Clojure to C compiler - Work in Progress

On Wed, Jul 11, 2012 at 11:57 AM, John Szakmeister wrote: > Nice work! Are you looking to support multiple threads, STM, agents, > etc.? I've been debating on working on a native Clojure > implementation for a while, and that was one of my goals... I'm > interested if it's one of yours. Yes, it

Re: Parsing SGML

On Wed, Jul 11, 2012 at 12:32 +0200, Tassilo Horn wrote: > Wolodja Wentland writes: > > > On Tue, Jul 10, 2012 at 17:16 +0200, Tassilo Horn wrote: > >> I think, I'd simply copy the clojure.xml code and adapt it to my needs. > > > >> Not too pretty, but should be adequate for getting the job done.

Re: Parsing SGML

Wolodja Wentland writes: > On Tue, Jul 10, 2012 at 17:16 +0200, Tassilo Horn wrote: >> I think, I'd simply copy the clojure.xml code and adapt it to my needs. > >> Not too pretty, but should be adequate for getting the job done. > > I look into that, but it really wouldn't be pretty. I still thin

Re: [ANN] ClojureC - A Clojure to C compiler - Work in Progress

On Mon, Jul 9, 2012 at 7:03 AM, Mark Probst wrote: > Dear Clojurians, > > I'm excited to announce ClojureC, an effort to produce a Clojure > implementation that targets C: > > https://github.com/schani/clojurec > > My personal goals with this are to be able to write self-contained > (command-lin

Re: Parsing SGML

On Tue, Jul 10, 2012 at 17:16 +0200, Tassilo Horn wrote: > I think, I'd simply copy the clojure.xml code and adapt it to my needs. > Not too pretty, but should be adequate for getting the job done. I look into that, but it really wouldn't be pretty. I still think that it must be possible to add t

Re: Parsing SGML

On Tue, Jul 10, 2012 at 12:06 -0700, Alan Malloy wrote: >Just create a Reader over the file, and do something like (take-while >identity (repeatedly #(read-one-wellformed-xml-tag the-reader))). It needs >some fleshing out for boundary conditions, but I hope you get the general >idea

Re: Help getting Clojure/Leiningen 2.0 building with LWJGL

Try to add in project.clj: :jvm-opts ["-Djava.library.path=native/linux"]) where it will point to folder with OS specific libraries. Regards, Sanel On Monday, July 9, 2012 4:26:05 AM UTC+2, Karl Smeltzer wrote: > > Is anybody willing and able to walk me through getting a simple project >