C-7, Josh Tilles wrote:
>>
>> I think the “reducible streams” approach described by Paul Stadig here
>> <http://paul.stadig.name/2016/08/reducible-streams.html> has potential.
>> It might not cover all of the scenarios you’re thinking of, though.
>>
>&g
:
>
> https://github.com/pjstadig/scopes
>
> perhaps inspired by this discussion:
>
> https://dev.clojure.org/display/design/Resource+Scopes
>
>
>
> On Friday, May 5, 2017 at 5:10:27 AM UTC-7, Herwig Hochleitner wrote:
>>
>> 2017-05-04 19:35 GMT+02:00 Brian Cr
>>
>> If there's only one with-open it can be reasonably simple to pass the
>> consumer into that context (though from ring it's pretty convoluted, due to
>> needing to pass control to ring first).
>>
>
> Creating streamed ring responses can be kind of tr
2017-05-04 19:35 GMT+02:00 Brian Craft :
>
> If there's only one with-open it can be reasonably simple to pass the
> consumer into that context (though from ring it's pretty convoluted, due to
> needing to pass control to ring first).
>
Creating streamed ring responses
Integer.MIN_VALUE serves as a signal to the driver to stream result sets
row-by-row. After this, any result sets created with the statement will be
retrieved row-by-row.
On Thursday, May 4, 2017 at 1:35:48 PM UTC-4, Brian Craft wrote:
>
> The with-open style is used a lot in the jdbc lib
t not cover all of the scenarios you’re thinking of, though.
>
> On Thursday, May 4, 2017 at 1:35:48 PM UTC-4, Brian Craft wrote:
>>
>> The with-open style is used a lot in the jdbc lib, and elsewhere. It's
>> pretty simple when data is very small, as you can just eval
I think the “reducible streams” approach described by Paul Stadig here
<http://paul.stadig.name/2016/08/reducible-streams.html> has potential. It
might not cover all of the scenarios you’re thinking of, though.
On Thursday, May 4, 2017 at 1:35:48 PM UTC-4, Brian Craft wrote:
>
> T
The with-open style is used a lot in the jdbc lib, and elsewhere. It's
pretty simple when data is very small, as you can just evaluate the entire
result with doall, etc.
How do you deal with larger data, where you need to evaluate iteratively?
If there's only one with-open it can be
I'm posting this on the off chance it's useful to those of you writing REPL
shell tools or I/O abstractions (e.g. java's NIO.2 DirectoryStream
wrappers) that might benefit from a close-when-GC'd backstop.
For example, clj-nio2 has a nice little lazy directory sequence function:
(defn- lazy-dir-
on't see a way to structure code like this to use with-open,
> since the backend would lose its open files when returning from any
> with-open it might do.
>
> Am I approaching this the wrong way? Is there a standard way of structuring
> code like this? It's a bit like the back
inish); close the files
Off-hand, I don't see a way to structure code like this to use with-open,
since the backend would lose its open files when returning from any
with-open it might do.
Am I approaching this the wrong way? Is there a standard way of structuring
code like this? It's
On Jun 11, 2013 8:25 AM, "Meikel Brandmeyer (kotarak)" wrote:
> Or another one:
>
> (defn filter-lines
> [rdr]
> (->> (line-seq rdr)
> (mapcat #(str/split % #"\s+"))
> (filter #(<= 4 (count %) 9))
> (into #{})))
>
> (def
Or another one:
(defn filter-lines
[rdr]
(->> (line-seq rdr)
(mapcat #(str/split % #"\s+"))
(filter #(<= 4 (count %) 9))
(into #{})))
(defn filter-file
[filename]
(with-open [rdr (io/reader filename)]
(filter-lines rdr)))
Meikel
Am Dienstag, 11. Juni
I haven't seen the use of multiple statements in the for comprehension
here, so perhaps it's nice to elaborate that this exists?
(defn filter-file [filename]
(with-open [rdr (io/reader filename)]
(set
(for [line (line-seq rdr)
word (str/split line #"\s+&quo
The 'reduce' solution is very elegant, but you can simplify it further:
(defn filter-file [filename]
(with-open [rdr (io/reader filename)]
(reduce (fn [words line]
(into words (filter #(<= 4 (count %) 9) (str/split line #"\s+"
#{}
On Sat, Jun 8, 2013 at 7:16 PM, Steven D. Arnold <
> thoth.amon.i...@gmail.com> wrote:
>
>> Thanks for the responses! As suggested, wrapping in 'doall' does work.
>>
>>
>> On Jun 8, 2013, at 3:28 AM, Thomas Heller wrote:
>>
>> (defn filter-
> (defn filter-file [filename]
> (with-open [rdr (io/reader filename)]
>(reduce (fn [words line]
> (->> (str/split line #"\s+")
> (filter #(and (<= (count %) 9)
> (>= (count
Thanks for the responses! As suggested, wrapping in 'doall' does work.
On Jun 8, 2013, at 3:28 AM, Thomas Heller wrote:
> (defn filter-file [filename]
> (with-open [rdr (io/reader filename)]
>(reduce (fn [words line]
> (-&
Hey,
for produces a lazy sequence (as does flatten) which is hurting you here.
You could wrap everything in a doall but I'd recommend using reduce since
thats technically what you want here. I'd probably go for something like:
(defn filter-file [filename]
(with-open [rdr (io/reade
On Sat, Jun 8, 2013 at 12:53 AM, Steven D. Arnold
wrote:
> (defn filter-file
> []
> (with-open [rdr (reader "/Users/thoth/wordlist.txt")]
>(flatten
> (for
>[line (line-seq rdr)]
>(filter
> (and #(<= (count %
online of 'with-open' use it in conjunction with 'doseq', but I
don't think doseq returns the value of expressions like for does.
As a Clojure newb, I'd welcome any feedback, but in particular I'm interested
in what's going on with the closed stream. Any
And yep, Kevin's change works. Looking into reducers + I/O sounds
interesting, I'll definitely check it out, thanks!
On Mon, May 27, 2013 at 11:21 PM, Sean Corfield wrote:
> On Mon, May 27, 2013 at 9:50 PM, Kevin Downey wrote:
> > doall doesn't recurse, so you are not realizing the lazy-seq, y
On Mon, May 27, 2013 at 9:50 PM, Kevin Downey wrote:
> doall doesn't recurse, so you are not realizing the lazy-seq, you want
> something like [msg (doall sig-strs)]
Thank you Kevin! When Elango said my suggestion didn't work, I was
puzzled. Now it makes sense!
--
Sean A Corfield -- (904) 302-SEA
doall doesn't recurse, so you are not realizing the lazy-seq, you want
something like [msg (doall sig-strs)]
if you are looking to play around with io stuff, I recommend looking in to
using reducers for io, they allow you to sort of invert control, keeping
the nice property of with-open a
of the file parsing:
> >
> > (defn- lic-file-msg-sigs
> > "return a vector containing the original license string/message and a
> seq
> > of each signature line generated. the input is the string of the entire
> > license file"
> > [lic-file-st
-msg-sigs
> "return a vector containing the original license string/message and a seq
> of each signature line generated. the input is the string of the entire
> license file"
> [lic-file-str]
> (let [result (promise)]
> (with-open [rdr (BufferedReader. (Strin
et [result (promise)]
(with-open [rdr (BufferedReader. (StringReader. lic-file-str))]
(let [lines (line-seq rdr)
line-sandwich-middle-fn (fn [lines line-before line-after]
(->> lines
(
Fiel,
Fixed on the master branch as of this morning.
-David
On Saturday, November 17, 2012 7:46:47 AM UTC-6, FC wrote:
>
> Hi DavidM and ClojureCLR users,
>
> In ClojureCLR built using .NET 3.5 framework, with-open needs some help
> finding the .Dispose method on IDisposable
Hi DavidM and ClojureCLR users,
In ClojureCLR built using .NET 3.5 framework, with-open needs some help
finding the .Dispose method on IDisposable objects:
It occurs when calling with-open on RegistryKey and System.IO.BinaryWriter
instances.
Here's the code snippet demonstrating this:
On Wednesday, November 7, 2012 2:29:06 PM UTC-5, Jim foo.bar wrote:
>
> This is exactly the approach I'm taking...'doall' retains the head so
> with massive files it will break...'doseq' will not. at least this is my
> understanding...
>
That is correct. `doall` retains the head because it retu
process-records [process file-name]
(with-open [r (reader file-name)]
(doseq [line (line-seq r)]
(process line
Thoughts?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegro
On Wed, Nov 7, 2012 at 11:09 AM, Dave Ray wrote:
> (defn get-records [file-name]
> (with-open [r (reader file-name)]
> (line-seq r)))
I suspect it's considered more idiomatic to do:
(defn process-records [process file-name]
(with-open [r (reader file-name)]
(doseq [li
aling a lot with file io, i can understand why you might
think this is still boilerplate (albeit massively less than Java) but I
imagine wrapping with-open/doseq/line-seq in a macro that accepts some
forms to execute within it would be trivial...
Jim
On 07/11/12 19:09, Dave Ray wrote:
There a
Hi Dave,
Am 07.11.2012 um 20:09 schrieb Dave Ray:
> There aren't any problems with with-open/doseq/line-seq. The issue is
> with with-open/line-seq. For example, it's instinctive (at least for
> me anyway) to want to write a function like this:
>
> (defn get-records [fi
There aren't any problems with with-open/doseq/line-seq. The issue is
with with-open/line-seq. For example, it's instinctive (at least for
me anyway) to want to write a function like this:
(defn get-records [file-name]
(with-open [r (reader file-name)]
(line-seq r)))
Of course, t
I know I'm coming a bit late in this thread but i did not have the
chance to reply earlier...
Can somebody elaborate briefly what is the problem with the combination
of with-open/doseq/line-seq? In a project of mine I'm dealing with files
larger than 200MB (which of course will not
Stuart,
Thanks for the link. It confirms the suspicions I had about a general
solution for this issue. For the particular code I'm working with,
I'll try pushing with-open further up and see if that gives me some of
the flexibility I'm looking for.
Cheers,
Dave
On Sun, Oct 28,
the stack. Instead of having a 'with-open' block that returns a sequence,
put the 'with-open' block at a higher level, so that it encompasses the
entire scope in which the file will be used.
-S
--
You received this message because you are subscribed to the Google
Groups &q
On Sun, Oct 28, 2012 at 9:38 AM, Christian Sperandio
wrote:
>
> I've got a question about lazy-sequence and file reading.
> Is line-seq good to process lines from huge file?
> Let take this case, I want to process each line from a file with one or more
> functions. All lines must be processed. Lin
line
by line. This enables code like:
(do-read-input-source-lines [x cmdline-args]
(println x))
where cmdline-args is a sequence of files. Useful for simple scripts. The
above expands roughly to:
(doseq [input-source# cmdline-args]
(with-open [rdr# (clojure.java.io/reader
es, especially
> large ones, as seqs of lines. In particular, the apparent conflict
> between using clojure.core/with-open to ensure a file is closed
> appropriately, and clojure.core/line-seq as a generic sequence of
> lines which may be consumed by code that has no idea it's
do that by default.
> >
> > '(Devin Walters)
> >
> > On Oct 26, 2012, at 6:45 PM, Dave Ray > (mailto:dave...@gmail.com)> wrote:
> >
> > > Hi,
> > >
> > > At work I've had a few conversations about treating files, especial
Dave Ray wrote:
>>
>>> Hi,
>>>
>>> At work I've had a few conversations about treating files, especially
>>> large ones, as seqs of lines. In particular, the apparent conflict
>>> between using clojure.core/with-open to ensure a file is
s, it's flawed :)
>>
>> Thoughs? I'm aware of the "custom seq that closes the file when the
>> end is reached" hack, but that doesn't seem very satisfying. How do
>> others process large files in Clojure? Just make sure that the
>> sequence
rote:
> Hi,
>
> At work I've had a few conversations about treating files, especially
> large ones, as seqs of lines. In particular, the apparent conflict
> between using clojure.core/with-open to ensure a file is closed
> appropriately, and clojure.core/line-seq as a generi
Hi,
At work I've had a few conversations about treating files, especially
large ones, as seqs of lines. In particular, the apparent conflict
between using clojure.core/with-open to ensure a file is closed
appropriately, and clojure.core/line-seq as a generic sequence of
lines which m
On Jan 25, 7:32 pm, Meikel Brandmeyer wrote:
> Hi,
>
> Disclaimer: I have no clue, what I'm talking about. Just making up
> contrived examples, which probably never happen in reality.
>
> On 25 Jan., 15:13, Ken Wesson wrote:
>
> > Remember, we're no longer using a "finally" clause, so for the .
Hi,
Disclaimer: I have no clue, what I'm talking about. Just making up
contrived examples, which probably never happen in reality.
On 25 Jan., 15:13, Ken Wesson wrote:
> Remember, we're no longer using a "finally" clause, so for the .close
> to be exception-safe *everything* must be caught. But
On Tue, Jan 25, 2011 at 1:03 AM, Shantanu Kumar
wrote:
> The changed code should catch 'Exception', not 'Throwable' because the
> latter is a common ancestor of both 'Exception' and 'Error'. An
> 'Error' must not be swallowed at any point in the system, unless you
> are writing an app server or a
On Tue, Jan 25, 2011 at 1:04 PM, Shantanu Kumar wrote:
I can't see the value in catching Throwable and then re-throwing it;
> idiomatically Throwable is rarely caught. Looking at code example, the
> following two snippets below are just the same:
>
> (try
> (.close resource)
> (catch Throwable t
On Jan 25, 4:22 pm, David Powell wrote:
> On 25 Jan 2011 06:04, "Shantanu Kumar" wrote:
>
>
>
> > The changed code should catch 'Exception', not 'Throwable' because the
> > latter is a common ancestor of both 'Exception' and 'Error'. An
> > 'Error' must not be swallowed at any point in the syst
On 25 Jan 2011 06:04, "Shantanu Kumar" wrote:
>
> The changed code should catch 'Exception', not 'Throwable' because the
> latter is a common ancestor of both 'Exception' and 'Error'. An
> 'Error' must not be swallowed at any point in the system, unless you
> are writing an app server or a JVM imp
se throws, the catch
> >> >> clause tries to close the stream again.
>
> >> > argh yes, this may be a problem ...
>
> >> There's also a bug: _ instead of _# in the close exception discarder. :)
>
> >> How's about:
>
> >
The one thing that's
>> >> a bit icky about that is that if the body close throws, the catch
>> >> clause tries to close the stream again.
>>
>> > argh yes, this may be a problem ...
>>
>> There's also a bug: _ instead of _# in the close exce
2011/1/25 Ken Wesson :
> Huh. We came up with almost the same final version. I guess I took 13
> minutes longer because I tested mine
And also because I was in a hurry to go to bed ! :)
>-- yours still has the missing #.
> :)
This was intentional, I had to let something for you to bite ;)
--
Y
2011/1/25 Meikel Brandmeyer :
> Hi,
>
> On 25 Jan., 01:57, Laurent PETIT wrote:
>
>> (try (. ~(bindings 0) close) (catch Throwable _))
>
> New code should use (.close foo) instead of (. foo close), IIRC.
Sure, but it's an enhancement over existing code, so I've followed the
convention (and I was
Hi,
On 25 Jan., 01:57, Laurent PETIT wrote:
> (try (. ~(bindings 0) close) (catch Throwable _))
New code should use (.close foo) instead of (. foo close), IIRC.
Sincerely
Meikel
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this grou
Hi,
On 25 Jan., 01:33, Ken Wesson wrote:
> It looks a little quirky in macroexpand output and seems slightly ugly
> but it works and probably isn't even inefficient at runtime, as the
> close symbol presumably has a name slot that takes up four bytes
> whether it's nil or a pointer to a string,
try and in the catch. The one thing that's
> >> a bit icky about that is that if the body close throws, the catch
> >> clause tries to close the stream again.
>
> > argh yes, this may be a problem ...
>
> There's also a bug: _ instead of _# in the close excep
Huh. We came up with almost the same final version. I guess I took 13
minutes longer because I tested mine -- yours still has the missing #.
:)
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.c
dy close throws, the catch
>> clause tries to close the stream again.
>
> argh yes, this may be a problem ...
There's also a bug: _ instead of _# in the close exception discarder. :)
How's about:
(in-ns 'clojure.core)
(defmacro with-open
"bindings => [name i
There it is, corrected:
(in-ns 'clojure.core)
(defmacro with-open
"bindings => [name init ...]
Evaluates body in a try expression with names bound to the values
of the inits, and a finally clause that calls (.close name) on each
name in reverse order."
{:added "1
[(do ~@body)]
>>>> (catch Throwable t# t#))]
>>>> (if (vector? res#) ; body didn't throw
>>>> (do
>>>> (.close ~sym) ; so let close throw
>>>> (res# 0))
>>>>
;t throw
>>> (do
>>> (.close ~sym) ; so let close throw
>>> (res# 0))
>>> (do ; body threw
>>> (try (.close ~sym) (catch Throwable _#)) ; eat close exception
>>> (throw res#))))))) ; a
On Mon, Jan 24, 2011 at 7:40 PM, Alan wrote:
> Thanks, Ken. Much more productive than all this philosophy about what
> "makes sense" the rest of us are discussing; I'd vote for this patch
> if you put it in JIRA.
No patch; sorry; don't have a CA. Laurent improved on it somewhat anyway.
You're we
;t throw
>>> (do
>>> (.close ~sym) ; so let close throw
>>> (res# 0))
>>> (do ; body threw
>>> (try (.close ~sym) (catch Throwable _#)) ; eat close exception
>>> (throw res#))))))) ; a
(do
> (.close ~sym) ; so let close throw
> (res# 0))
> (do ; body threw
> (try (.close ~sym) (catch Throwable _#)) ; eat close exception
> (throw res#))) ; and rethrow body exception
>
> user=> (with-open [x (Foo
(res# 0))
>> (do ; body threw
>> (try (.close ~sym) (catch Throwable _#)) ; eat close exception
>> (throw res#))) ; and rethrow body exception
>>
>> user=> (with-open [x (Foo.)] (doit x))
>> #> (NO_SOURCE_FILE:242)&g
On Mon, Jan 24, 2011 at 7:26 PM, Aaron Cohen wrote:
> The inner exception to me should clearly be caught and not rethrown.
> So I would really expect to see two printouts when this is run, once
> for doit and once for close.
Neither would I. I think you've misunderstood something, though.
> Why
(catch Throwable t# t#))]
> (if (vector? res#) ; body didn't throw
> (do
> (.close ~sym) ; so let close throw
> (res# 0))
> (do ; body threw
> (try (.close ~sym) (catch Throwable _#)) ; eat close exception
>
On Mon, Jan 24, 2011 at 4:54 PM, Shantanu Kumar
wrote:
>
>
> On Jan 25, 2:47 am, Aaron Cohen wrote:
>> On Mon, Jan 24, 2011 at 2:27 PM, Shantanu Kumar
>>
>> wrote:
>> > I noticed that in 'with-open' macro the .close() method is called
>> >
hat I tend to do in Java
else things get too verbose, but it would be possible for the
with-open macro to take the pain out of doing things slightly more
robustly.
A solution might be to change the macro to create a with-local-var var
at the top, and to add catch blocks with each finally that
(do
(.close ~sym) ; so let close throw
(res# 0))
(do ; body threw
(try (.close ~sym) (catch Throwable _#)) ; eat close exception
(throw res#))) ; and rethrow body exception
user=> (with-open [x (Foo.)] (doit x))
#
user=> (
#x27;m following you.
>> Especially, if my memories don't cheat on me, calling close() ensures
>> Bufferd[Writer|OutputStream]s are flushed, for example.
>
> Yes, but if that flush causes an IO error, you don't want it silently
> swallowed.
And now I'm beginning to
e record, references:
apache commons i/o:
http://commons.apache.org/io/api-release/org/apache/commons/io/IOUtils.html#closeQuietly(java.io.Closeable)
>
> Of course, with-open allowing to do several binding, the
> try/swallow-catch would have to be repeated for each nesting, IMHO.
>
> Che
) ensures
> Bufferd[Writer|OutputStream]s are flushed, for example.
Yes, but if that flush causes an IO error, you don't want it silently
swallowed.
> And also, what if the user code inside with-open throws an exception,
> but the close() calls also throw an exception.
> You cann
ushed when you call
>> close(). This is of course why close() throws Exception in the first
>> place.
>
> Could you please expand with an example, I'm not sure I'm following you.
> Especially, if my memories don't cheat on me, calling close() ensures
> Bufferd
hat I tend to do in Java
else things get too verbose, but it would be possible for the
with-open macro to take the pain out of doing things slightly more
robustly.
A solution might be to change the macro to create a with-local-var var
at the top, and to add catch blocks with each finally that
ws Exception in the first
> place.
Could you please expand with an example, I'm not sure I'm following you.
Especially, if my memories don't cheat on me, calling close() ensures
Bufferd[Writer|OutputStream]s are flushed, for example.
And also, what if the user code inside with-open t
> apache commons io and spring framework, to name 2 things I know for
> sure, are doing what you say: they swallow any exception that could be
> thrown within the finally block, for the reasons you mention.
True, but if the body doesn't throw an exception, but the close does,
I wouldn't want the
Yes, you're right Shantanu.
apache commons io and spring framework, to name 2 things I know for
sure, are doing what you say: they swallow any exception that could be
thrown within the finally block, for the reasons you mention.
Of course, with-open allowing to do several binding, th
On Jan 25, 2:47 am, Aaron Cohen wrote:
> On Mon, Jan 24, 2011 at 2:27 PM, Shantanu Kumar
>
> wrote:
> > I noticed that in 'with-open' macro the .close() method is called
> > without wrapping in another try-catch block. Exceptions raised in the
> > fina
On Mon, Jan 24, 2011 at 2:27 PM, Shantanu Kumar
wrote:
> I noticed that in 'with-open' macro the .close() method is called
> without wrapping in another try-catch block. Exceptions raised in the
> finally block prevails over the exception raised in the try block. Is
> this
On Mon, 24 Jan 2011 13:30:49 -0800 (PST)
Shantanu Kumar wrote:
>
>
> On Jan 25, 2:07 am, dysinger wrote:
> > (try (with-open [x y] ... )
> > (catch Exception)) ;; <- catches any exception from with-open
> > macro
> >
> > I don't think you
Yes. you are correct and I agree that you would lose the original exception
or return type. I was just saying you could catch the exception of the IO
close if needed.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email
On Jan 25, 2:07 am, dysinger wrote:
> (try (with-open [x y] ... )
> (catch Exception)) ;; <- catches any exception from with-open macro
>
> I don't think you are correct.
Maybe this is subjective, but I am rarely interested in knowing what
exception does .close() thr
On Mon, Jan 24, 2011 at 4:07 PM, dysinger wrote:
>
> (try (with-open [x y] ... )
> (catch Exception)) ;; <- catches any exception from with-open macro
>
> I don't think you are correct.
He is. Close exceptions lose any other exception or return value:
user=> (de
(try (with-open [x y] ... )
(catch Exception)) ;; <- catches any exception from with-open macro
I don't think you are correct.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@goo
On Jan 25, 1:26 am, dysinger wrote:
> Just wrap it if you are paranoid about exception on close
>
> (try (with-open [x y]
> (throw (Exception. "lololol")))
> (catch Exception e (println (.getMessage e
The problem is that exception thrown by .close
Just wrap it if you are paranoid about exception on close
(try (with-open [x y]
(throw (Exception. "lololol")))
(catch Exception e (println (.getMessage e
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
T
On Jan 24, 2011, at 1:54 PM, Laurent PETIT wrote:
> That's interesting. Indeed, it seems to me that the .close() call
> should be wrapped by a try / catch with an empty catch.
Why would client code want an exception thrown by .close() to get swallowed? Is
that not unexpected behavior in most cas
2011/1/24 Shantanu Kumar :
> I noticed that in 'with-open' macro the .close() method is called
> without wrapping in another try-catch block. Exceptions raised in the
> finally block prevails over the exception raised in the try block. Is
> this intended behavior or I am mis
I noticed that in 'with-open' macro the .close() method is called
without wrapping in another try-catch block. Exceptions raised in the
finally block prevails over the exception raised in the try block. Is
this intended behavior or I am missing something?
Is there an alternative
On Tue, Mar 30, 2010 at 10:26 PM, Daniel wrote:
> Thanks for all the quick replies. I should've mentioned that I'm
> already using leiningen, so the problem isn't so much getting the
> dependencies and building the application as it is figuring out a way
> to get inside the code and play with it
Thanks for all the quick replies. I should've mentioned that I'm
already using leiningen, so the problem isn't so much getting the
dependencies and building the application as it is figuring out a way
to get inside the code and play with it a bit. I'd like to be able to
load the source files, execu
If you're not stuck on using Compojure, you can try Conjure which will
includes all of the dependencies in the jar.
To start a hello world app:
1. Download conjure.jar from: http://github.com/macourtney/Conjure/downloads
2. java -jar conjure.jar hello_world
3. cd hello_world
4. ./run.sh script/se
Hi,
On Mar 30, 3:45 pm, Stuart Sierra wrote:
> Take a look at the dependency management tools. Most open-source
> Clojure projects use either Maven and Leiningen. Both use the same
> dependency model and provide similar capabilities for starting a REPL
> with the classpath configured automatic
Take a look at the dependency management tools. Most open-source
Clojure projects use either Maven and Leiningen. Both use the same
dependency model and provide similar capabilities for starting a REPL
with the classpath configured automatically.
-SS
On Mar 29, 11:39 pm, Daniel wrote:
> If t
> So here are my questions:
>
> Am I going about this the wrong way? Is there an easier way
> to explore existing open-source projects? I Is there a less
> cumbersome way to get a load of files on the classpath than
> manually editing the .clojure file? How do I tell the REPL
> where to find r
Daniel writes:
> Am I going about this the wrong way? Is there an easier way to explore
> existing open-source projects? I
Try this for any leiningen project (check for the existence of a
project.clj file). I'm assuming you're using a unixy operating system.
First and once-off, install leining
1 - 100 of 131 matches
Mail list logo
