Here a example where midje could provide more info.
I have this function :
(defn pr134 [element a-seq]
(and (contains? a-seq element) (nil? element))
)
and I have this test-function :
(ns exercises.core-test
(:use midje.sweet)
(:use [exercises.core]))
(facts "about `pr134`"
(fa
http://jakemccrary.com/blog/2014/06/22/comparing-clojure-testing-libraries-output/
has some good examples. I'm currently using humane-test-output. It's worked
nicely for me.
'(Devin Walters)
> On Nov 1, 2014, at 7:00 PM, Alex Miller wrote:
>
> Additionally, I think it would be helpful to enum
Additionally, I think it would be helpful to enumerate example (failing)
tests and their output by current clojure.test.
On Saturday, November 1, 2014 1:58:32 PM UTC-5, Alex Miller wrote:
>
> It would be great if someone could enumerate more explicitly what "better"
> test output means. What ar
On Nov 1, 2014, at 1:58 PM, Alex Miller wrote:
> It would be great if someone could enumerate more explicitly what "better"
> test output means. What are the specific problems in the current test output
> reporting?
If there's any sort of consensus about test reporting, specifically how
diff
I can say for certain that at a minimum better indentation of data structures
to the console would be a must, a vector with 4+ hash maps in it are currently
unreadable and I have to copy to an editor to indent and analyze.
Beyond that, I can imagine the need for a structural diff that tells me
It would be great if someone could enumerate more explicitly what "better" test
output means. What are the specific problems in the current test output
reporting?
Similar problem list for test runner might be useful.
Discussion here is fine but ultimately needs to land on a design wiki page.
I
That's an excellent idea, currently at least test.check hacks on top of
clojure.test by using macros that emit clojure.test tests.
Beyond that it seems that the #1 wish is better output. I don't think that
ought to be very hard for us to pull off as a community.
On Fri, Oct 31, 2014 at 6:56 P
+1 to something like humane-test-output being part of core library.
There is value for the community to have some foundation library share
across our test frameworks? Something like `test.runners`, to encapsulate
error reporting and organization? Bit crazy, I know, but the idea come
after seein
Would be great if humane-test-output was part of clojure.test. Would make
it easier for beginners to find it.
On Friday, October 31, 2014 11:19:11 PM UTC+8, Eli Naeher wrote:
>
> On Fri, Oct 31, 2014 at 9:52 AM, Ashton Kemerling > wrote:
>
>
>> It's my opinion that these two libraries are lar
I totally agree about pr-str in test.check. Quite often I want to copy and
paste the failure into a repl and play around, but need to re-add missing
quotation marks or quote lists.
> On 31 Oct 2014, at 22:05, Jessica Kerr wrote:
>
> My top wish it more readable output from test.check when run
My top wish it more readable output from test.check when running within
clojure.test
In particular, I want to know the value of each generated parameter at the
first failure, and at the simplest failure. Currently that prints as part
of a map, but if empty-string is generated, that does not sho
On Fri, Oct 31, 2014 at 9:52 AM, Ashton Kemerling wrote:
> It's my opinion that these two libraries are largely complete aside from
> some human interface improvements (quality of output for example), but
> clearly not everyone agrees with me.
>
Hi Ashton,
Check out https://github.com/pjstadig
"I tweeted recently that I thought that Clojure is super testable, and I
was genuinely surprised about the number of people who disagreed with me."
My 2c.
Without explicitly citing those complaints, it will be difficult to conduct
a meaningful debate.
2014-10-31 14:52 GMT+00:00 Ashton Kemerling
I don't want to speak for others, I notified everyone involved on Twitter that
I made this thread so they can voice their own complaints.
On Fri, Oct 31, 2014 at 9:02 AM, László Török wrote:
> "I tweeted recently that I thought that Clojure is super testable, and I
> was genuinely surprised abo
@Timothy:
Looking forward to your changes. Thanks for all the existing work with
core.async! (I was half tempted to switch to Scala to use Akka right before
core.async came out.)
On Tue, Jan 14, 2014 at 10:30 AM, t x wrote:
> @Ghadi,
>
>
> Are you referring to the race condition between:
>
> (
@Ghadi,
Are you referring to the race condition between:
(check if channel is closed)
### BAM SOMETHING HAPPENS
(put something on to the channel)
?
I agree it's a race condition, however after some refactoring, I no longer
care if I'm >!-ing onto a closed channel, as long as I eventually know
It's a known problem (putting into a closed channel), and one we have a
possible solution for (it's in one of the branches of core.async). I'll
bring it up this Friday and see if we can't make some progress on the code.
Timothy
On Tue, Jan 14, 2014 at 10:43 AM, Ghadi Shayban wrote:
> This code
This code actually results in a subtle race condition as channels need to
be locked internally. It also won't work for other implementations of
channel, of which there are several in core.async besides
ManytoManyChannel. (For example, map< returns a reified channel.) Knowing
whether a channel
(let [c (async/chan 10)]
(println @(.-closed c))
(async/close! c)
(println @(.-closed c)))
And we're done. Sorry for the spam. Last message send in case someone finds
my question via Google.
On Mon, Jan 13, 2014 at 2:11 AM, t x wrote:
> Is there anyway, to "pierce the deftype"
>
>
> htt
Is there anyway, to "pierce the deftype"
https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/channels.clj#L31
to read the "closed" field of the ManytoMany Channel?
That's basically all I need to do.
On Mon, Jan 13, 2014 at 1:47 AM, t x wrote:
> Hi,
>
>
I seem to understand it. `nested' is seen non-null value in the thread
_that executes the action_. In any other threads, the default null value
will be seen. And in the executing thread, after pending sends are
released, no user code will be executed, so no actions will be dropped.
Best Regards
Hmm, I didn't read the definition of `board-map' carefully. It seems the
second form
(dosync (board-map deref board))
is the best among the three, as it views `board' as a whole. The other two
might have the potential problem of printing incoordinated values of
entries in `board', i.e. the e
I think I'm right. This is a program that demonstrates what I was thinking
o:
;; Program begins.
(defn traverse [f dat]
(vec (map #(f %) dat)))
(def data (traverse ref (take 10 (iterate inc 0
(-> (fn []
(dosync (loop [i 0
data data]
(when (seq d
On Fri, Jan 6, 2012 at 11:28 PM, Alan Malloy wrote:
> but if you look at the post
There is no call for taking a rude tone. I correctly answered the
question as originally posed.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group,
On Jan 6, 7:32 pm, Cedric Greevey wrote:
> On Fri, Jan 6, 2012 at 10:22 PM, Alan Malloy wrote:
> > On Jan 6, 6:16 pm, Cedric Greevey wrote:
> >> On Fri, Jan 6, 2012 at 4:34 PM, Alan Malloy wrote:
> >> > On Jan 6, 12:56 pm, Jozef Wagner wrote:
> >> >> Thank you,
>
> >> >> But the things are mor
On Fri, Jan 6, 2012 at 10:22 PM, Alan Malloy wrote:
> On Jan 6, 6:16 pm, Cedric Greevey wrote:
>> On Fri, Jan 6, 2012 at 4:34 PM, Alan Malloy wrote:
>> > On Jan 6, 12:56 pm, Jozef Wagner wrote:
>> >> Thank you,
>>
>> >> But the things are more complicated. In my case, I need to update the atom
On Jan 6, 6:16 pm, Cedric Greevey wrote:
> On Fri, Jan 6, 2012 at 4:34 PM, Alan Malloy wrote:
> > On Jan 6, 12:56 pm, Jozef Wagner wrote:
> >> Thank you,
>
> >> But the things are more complicated. In my case, I need to update the atom
> >> with the result of a (native) function which unfortunat
On Fri, Jan 6, 2012 at 4:34 PM, Alan Malloy wrote:
> On Jan 6, 12:56 pm, Jozef Wagner wrote:
>> Thank you,
>>
>> But the things are more complicated. In my case, I need to update the atom
>> with the result of a (native) function which unfortunately also performs
>> some side effects and cannot b
On Jan 6, 12:56 pm, Jozef Wagner wrote:
> Thank you,
>
> But the things are more complicated. In my case, I need to update the atom
> with the result of a (native) function which unfortunately also performs
> some side effects and cannot be split in two.
>
> Updated example:
>
> (def state {:resul
Thank you,
But the things are more complicated. In my case, I need to update the atom
with the result of a (native) function which unfortunately also performs
some side effects and cannot be split in two.
Updated example:
(def state {:result nil :input [1 2 3]})
(defn update-item!
[item]
On Fri, Jan 6, 2012 at 3:02 PM, Jozef Wagner wrote:
> Consider this contrived piece of code:
>
> (def aval (atom {:dumped false :contents "hello world"}))
>
> (defn update!
> [item]
> (when-not (:dumped item)
> (spit "a.out" (:contents item) :append true)
> (assoc item :dumped true)))
"Jose A. Ortega Ruiz" writes:
Hi Jose,
>> I don't know scheme macros, so could you please explain why they are
>> more powerful? What can you do with a syntax-case macro what you
>> cannot do with a Common Lisp (or Clojure) macro?
>
> In general, syntax-case lets you manipulate first-class synt
Hi Tassilo,
On Tue, Dec 06 2011, Tassilo Horn wrote:
> "Jose A. Ortega Ruiz" writes:
>
> Hi Jose,
>
>>> I think that Common Lisp macros are, strictly speaking, more powerful
>>> than Scheme macros, but I don't have a citation.
>>
>> That's only true for syntax-rules macros. syntax-case macros,
> Does that mean that Clojure's defmacro is aware of the lexical scope as
> well and is therefore equally powerful as Scheme's syntax-case?
>
> Bye,
> Tassilo
In my implementation of syntax-rules/syntax-case, I did essentially
the same thing as syntax-quote (had to reimplement it as there is no
pro
Stephen Compall writes:
> On Tue, 2011-12-06 at 16:09 +0100, Tassilo Horn wrote:
>> Wikipedia lists syntax-case as hygienic macro system, which would
>> make it less powerful than CL macros, because if that was true, you
>> could not write anaphoric macros with it.
>
> You can write anaphora with
On Tue, 2011-12-06 at 16:09 +0100, Tassilo Horn wrote:
> Wikipedia lists syntax-case as hygienic macro system, which would make
> it less powerful than CL macros, because if that was true, you could not
> write anaphoric macros with it.
You can write anaphora with syntax-case. In fact, defmacro i
"Jose A. Ortega Ruiz" writes:
Hi Jose,
>> I think that Common Lisp macros are, strictly speaking, more powerful
>> than Scheme macros, but I don't have a citation.
>
> That's only true for syntax-rules macros. syntax-case macros, which
> most schemes provide and are required by R6RS, are, stric
On Sat, Dec 03 2011, Stuart Sierra wrote:
> I think that Common Lisp macros are, strictly speaking, more powerful
> than Scheme macros, but I don't have a citation.
That's only true for syntax-rules macros. syntax-case macros, which
most schemes provide and are required by R6RS, are, strictly sp
You might be interested in the paper 'Fortifying Macros':
http://www.ccs.neu.edu/scheme/pubs/icfp10-cf.pdf syntax-parse is very
cool and can give good error messages if the user makes a mistake when
using the macro. About a year ago I tried making an implementation of
a system like syntax-parse f
Em 12/04/11 03:16, Razvan Rotaru escreveu:
Wow. I didn't thought this was possible. You know, I have seen a lot
of people saying that scheme macros are more "powerfull", citing the
fact that scheme also has lisp macros, while it's not possible to do
it the other way around.
Of course it's possibl
Wow. I didn't thought this was possible. You know, I have seen a lot
of people saying that scheme macros are more "powerfull", citing the
fact that scheme also has lisp macros, while it's not possible to do
it the other way around.
On Dec 4, 2:06 am, Scott Jaderholm wrote:
> Scheme style macros i
On Sun, 04 Dec 2011 00:08:36 +0100
Tassilo Horn wrote:
> Stuart Sierra writes:
>
> > I think that Common Lisp macros are, strictly speaking, more
> > powerful than Scheme macros, but I don't have a citation.
>
> Let over Lambda is essentially a huge essay about why there's and will
> never be
Scheme style macros in Clojure: https://github.com/qbg/syntax-rules
Scott
On Sat, Dec 3, 2011 at 1:20 PM, Razvan Rotaru wrote:
> Hi everyone,
>
> I was searching the web these days trying to find out more about these
> two macro systems and understand their differences, and why one is
> prefera
This talk of "Scheme macros" is a little weird: are we talking syntax-case,
explicit-renaming, or unhygienic defmacro? Scheme has them all.
There are also implementation-specific mechanisms for writing reader macros:
what's left?
On Dec 3, 2011, at 14:57, Stuart Sierra wrote:
> I think that
Stuart Sierra writes:
> I think that Common Lisp macros are, strictly speaking, more powerful
> than Scheme macros, but I don't have a citation.
Let over Lambda is essentially a huge essay about why there's and will
never be anything as powerful than the CL macro system.
Bye,
Tassilo
--
You r
I think that Common Lisp macros are, strictly speaking, more powerful than
Scheme macros, but I don't have a citation.
-S
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts f
On Fri, Sep 9, 2011 at 8:09 AM, Nicolas wrote:
> I would rather say difficult than impossible... and maybe not that
> important.
Clojure uses Java method-calling conventions for all method and
function invocation, for "tight integration" and best performance.
> After all JVM is turring complete.
I would rather say difficult than impossible... and maybe not that
important.
After all JVM is turring complete. If scheme can do it compiling down
to machine code, clojure could do it compiling down to JVM bytecode.
On Sep 7, 1:54 am, Brian Goslinga wrote:
> On Sep 6, 11:20 am, Michael Jaaka
>
On Sep 6, 11:20 am, Michael Jaaka
wrote:
> Btw. it looks like Clojure is missing an ability to program reader.
>
> It would allow to program a syntax.
This is by design as there is no good way to namespace syntax.
> The tail recursion and continuations also would be awesome.
Those aren't provided
And last tough is that maybe there should be a build in support for
trees.
Trees are to maps like lists to vectors.
They have different characteristic on CRUD operations and CPU/RAM
resources.
With reader macros it would be possible to implement it by even not
bothering Rich Hickey.
Also there is
Btw. it looks like Clojure is missing an ability to program reader.
It would allow to program a syntax.
==
9. The whole language always available. There is no real distinction
between read-time, compile-time, and runtime. You can compile or run
code while reading, rea
Well, these attempts stop very quickly.
But I have found code extract from the book
http://lib.store.yahoo.net/lib/paulgraham/onlisp.lisp
maybe someone with good knowledge could port it?
On Sep 2, 1:16 pm, Eric Lavigne wrote:
> > Is there any project on github which goal is to implement all co
> Is there any project on github which goal is to implement all code
> from On Lisp book in Clojure?
Michael Fogus and Stuart Halloway have both ported parts of On Lisp to Clojure.
Michael
http://blog.fogus.me/tag/onlisp/
Stuart
http://thinkrelevance.com/blog/2008/12/12/on-lisp-clojure.html
http
On Aug 11, 10:15 am, Remco van 't Veer wrote:
> There was a thread about this some months ago;
>
> http://groups.google.nl/group/clojure/browse_thread/thread/e95d477830...
>
> Somebody came up with his own version of insert-record:
>
> http://gist.github.com/373564#LC62
>
Thanks for linking to
I have decided to use binding to tackle this for now:
(defn do-prepared-insert [...] ;; custom version of do-prepared
...
(into [] (resultset-seq (.getGeneratedKeys stmt
(defn save-rows-returnid [...] ;; custom update-or-insert-rows
...)
(binding
[do-prepared do-prepared-insert
up
I have my own custom version where I bind the generated keys in the
metadata of the returned seq. I think that's only valuable for
clojure 1.2 though.
The problem with returning an int is that many keys might be
generated, though by the far the most common usage is simply an
autoincrement column
Noticed that thread earlier. I hope this fresh thread is noticed by
Stephen (C. Gilardi) and others and a consensus can be reached on this
to do in c.c.sql proper.
Cheers,
Shantanu
On Aug 11, 1:15 pm, Remco van 't Veer wrote:
> There was a thread about this some months ago;
>
> http://groups.go
There was a thread about this some months ago;
http://groups.google.nl/group/clojure/browse_thread/thread/e95d4778301be699/
Somebody came up with his own version of insert-record:
http://gist.github.com/373564#LC62
On 2010/08/11 09:10, Shantanu Kumar wrote:
> Hi,
>
> I need to retrieve au
Meikel,
Thanks for the quick answer.
So I was only one step away from a solution !
I had :
user=> (let [arg (with-meta 's {:tag String}) arglist [arg] body (list
'.length arg)] (eval (list 'fn arglist body)))
Reflection warning, NO_SOURCE_PATH:52 - reference to field length
can't be resolved.
#
Hi,
On Feb 24, 12:50 pm, Jules wrote:
> user=> (let [arg (with-meta 's {:tag String}) arglist [arg] body (list
> '.length arg)] (eval (list 'fn arglist body)))
> Reflection warning, NO_SOURCE_PATH:40 - reference to field length
> can't be resolved.
> #
> user=> (*1 "foo")
> 3
The following seem
Just a by-the-way:
I'm (now) aware of http://clojure.org/contributing and
http://clojure.org/patches . I'll put my CA in the mail on Monday and
pick this up again in the new year.
// Ben
On Wed, Dec 9, 2009 at 23:33, B Smith-Mannschott wrote:
> Duck-streams does good job supporting character ba
This change will break a bunch of my code, and nevertheless gets a big
+1.
Stu
> I use clojure.contrib.def/defvar a lot. It's really useful for adding
> docstrings to non-function vars. But I've been tripped up by the same
> mistake a lot now—I keep expecting the docstring to go after the
> in
2009/10/11 Tassilo Horn :
>
> Miron Brezuleanu writes:
>
> Hi Miron,
>
>> This thread is getting confusing. The initial question was about
>> GPL'ed libraries, yet the example used is clojure.jar. Isn't Clojure
>> licensed under the EPL?
>
> It is. The question was about licensing issues when bu
Miron Brezuleanu writes:
Hi Miron,
> This thread is getting confusing. The initial question was about
> GPL'ed libraries, yet the example used is clojure.jar. Isn't Clojure
> licensed under the EPL?
It is. The question was about licensing issues when building GPLed
stuff using clojure.
Bye,
Hello,
This thread is getting confusing. The initial question was about
GPL'ed libraries, yet the example used is clojure.jar. Isn't Clojure
licensed under the EPL?
What am I missing? Why the GPL talk about clojure.jar? Why ask the FSF
about clojure.jar licensing issues if the Clojure web site c
> It still holds. And telling your users to download the clojure.jar
> doesn't change anything. The problem is not distributing something with
> a GPL-incompatible license, but that simply using clojure and the
> stdlibs makes it a derivated work. (I was in the same situation like
> you and dr
Elliott Slaughter writes:
Hi Elliotts,
> Am I allowed to distribute and use unmodified copies of GPL'd libs as
> jars? I've been told that dynamic linking against GPL libs in C counts
> somehow as derivative work. But I don't know how valid this
> interpretation is, and whether it applies to J
These are all very good questions, but they are legal questions,
not technical questions, let alone Clojure questions.
The sad thing is that it really is not possible to give you a definite
answer to your questions.
Opinions differ. The answer might depend on the governing law of the
jurisdictio
On Sun, Oct 4, 2009 at 4:41 PM, samppi wrote:
>
> I want to do this:
>
> (defn a ...)
> (cache a) ; or (cache #'a) or (cache 'a); it doesn't matter to me
>
> ...instead of this:
>
> (def a (memoize (fn ...)))
>
> That way, it separates the concern of what a does from the
> optimization I'm doi
On Sun, Oct 4, 2009 at 4:41 PM, samppi wrote:
>
> I want to do this:
>
> (defn a ...)
> (cache a) ; or (cache #'a) or (cache 'a); it doesn't matter to me
>
> ...instead of this:
>
> (def a (memoize (fn ...)))
>
> That way, it separates the concern of what a does from the
> optimization I'm doi
What a lifesaver! Thanks a lot!
On Oct 4, 2:58 pm, Meikel Brandmeyer wrote:
> Hi,
>
> Am 04.10.2009 um 22:47 schrieb talk:
>
> >> (defn cache
> >> "Replaces the function that the given variable refers to
> >> with a memoizing version of it."
> >> [fn-var]
> >> (??? fn-var (memo
Hi,
Am 04.10.2009 um 22:47 schrieb talk:
(defn cache
"Replaces the function that the given variable refers to
with a memoizing version of it."
[fn-var]
(??? fn-var (memoize @fn-var)))
Macros to the rescue:
(defmacro cache
"Replaces the function that the given name refers
On Wed, Aug 26, 2009 at 1:13 PM, John Harrop wrote:
> This is important to know about for security reasons, also. Specifically, if
> you are receiving Clojure data structures in text form over the network, and
> don't set *read-eval* to false, you're vulnerable to a "Clojure injection
> attack". S
This is important to know about for security reasons, also. Specifically, if
you are receiving Clojure data structures in text form over the network, and
don't set *read-eval* to false, you're vulnerable to a "Clojure injection
attack". Someone could send you "(+ 5 #=(System/exit 0))" as a
denial-o
On Wed, Aug 26, 2009 at 1:13 PM, John Harrop wrote:
> This is important to know about for security reasons, also. Specifically,
> if you are receiving Clojure data structures in text form over the network,
> and don't set *read-eval* to false, you're vulnerable to a "Clojure
> injection attack".
That's great! Thanks a lot for the explanation.
On Aug 25, 2:58 pm, Richard Newman wrote:
> Incidentally, you can find this stuff out by reading the source, if
> you know where to look. It's a reader macro, so LispReader.java is the
> best place to start. Look for the metachar '=', which cro
Incidentally, you can find this stuff out by reading the source, if
you know where to look. It's a reader macro, so LispReader.java is the
best place to start. Look for the metachar '=', which crops up on line
91:
http://github.com/richhickey/clojure/blob/14316ae2110a779ffc8ac9c3da3f1c41852
> It's undocumented in http://clojure.org/reader. What is its name? What
> does it precisely do?
It's "EvalReader". What it does is cause the expression to be
evaluated at read time:
user=> (read-string "(+ 5 #=(* 9 9))")
(+ 5 81)
You can prevent this occurring by binding *read-eval*:
user=>
Hi,
Am 19.07.2009 um 06:06 schrieb Rowdy Rednose:
(defn db-push
([key val] (db-push key val *default-db*))
([key val db]
(swap! db assoc key (cons val (@db key)
But I think it's broken in the face of concurrency, as I capture the
value of @db at the time of the call to the function s
On Jul 19, 12:53 pm, Richard Newman wrote:
> > * Can the body of the db-push function be simplified?
>
> I think so. Untested:
>
> (defn db-push
> ([key val] (db-push key val *default-db*))
> ([key val db]
> (swap! db assoc key (cons val (db key))
If I add an @ it runs:
(defn db-pu
> * Is "function overloading" the idiomatic way to implement default
> params in clojure?
Typically, I think so. You could also use multimethods, but that might
be unnecessary flexibility.
Another approach is to emulate keyword arguments:
(defn foo [x y & args]
(let [{:keys [baz bar]} (app
That pages says the scopes system is already designed. To you have
any preliminary design docs posted somewhere?
On Jul 9, 2:59 pm, Stuart Sierra wrote:
> On Jul 9, 6:10 am, Mike wrote:
>
> > Is there a pattern out there in Clojure for handling laziness at the
> > same time as handling resourc
On Jul 9, 6:10 am, Mike wrote:
> Is there a pattern out there in Clojure for handling laziness at the
> same time as handling resource lifecycle (with-open, etc.)?
Not yet, but it is planned, in something called "scopes."
http://clojure.org/todo
-SS
--~--~-~--~~~--
On Thu, Jul 9, 2009 at 16:43, eyeris wrote:
>
> I ran the code you pasted here. It didn't throw an IOException for me.
> I am running 1.0.
I suspect that You're Doing it Wrong.
You'll see the exception only if you actually try to evaluate the lazy
sequence returned by byte-seq.
(import [java.io
I ran the code you pasted here. It didn't throw an IOException for me.
I am running 1.0.
On Jul 9, 5:10 am, Mike wrote:
> I wanted to grab bytes out of a stream, and didn't see an analogue to
> reader from duck-streams, so I made my own:
>
> (defn byte-seq
> "Returns the bytes from stream as
Hi Mike,
On Thu, Jul 9, 2009 at 12:10 PM, Mike wrote:
>
> I wanted to grab bytes out of a stream, and didn't see an analogue to
> reader from duck-streams, so I made my own:
>
> (defn byte-seq
> "Returns the bytes from stream as a lazy sequence of ints.
> stream must implement java.io.InputStre
On Thu, Jul 9, 2009 at 12:10, Mike wrote:
>
> I wanted to grab bytes out of a stream, and didn't see an analogue to
> reader from duck-streams, so I made my own:
>
> (defn byte-seq
> "Returns the bytes from stream as a lazy sequence of ints.
> stream must implement java.io.InputStream."
> [#^ja
On 20/04/2009, at 6:13 PM, fft1976 wrote:
> On Apr 19, 3:20 am, Antony Blakey wrote:
>
>> If I use Clojure commercially, I'll certainly pay for it.
>
> Please do not forget to pay for JVM, Java, Linux, tar and others.
When they start asking for donations, and don't use a GPL license
(which i
On Apr 19, 3:20 am, Antony Blakey wrote:
> If I use Clojure commercially, I'll certainly pay for it.
Please do not forget to pay for JVM, Java, Linux, tar and others.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
On Apr 19, 3:20 am, Antony Blakey wrote:
> Why not? There's a donation link for Clojure. You don't need to feel
> odd.
You are right of course. I just made a donation.
g
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Goo
On 19/04/2009, at 6:32 PM, Rayne wrote:
> Oh, I apologize. I didn't realize that Rich wrote that for Stu's book.
> I paid more attention to the insides of the book than the foreward :p.
>
> On Apr 19, 1:44 am, George Jahad wrote:
>> On Apr 18, 3:38 pm, Rayne wrote:
>>
>>> So you want him to wr
Oh, I apologize. I didn't realize that Rich wrote that for Stu's book.
I paid more attention to the insides of the book than the foreward :p.
On Apr 19, 1:44 am, George Jahad wrote:
> On Apr 18, 3:38 pm, Rayne wrote:
>
> > So you want him to write something that Rich hasn't said on his
> > webs
On Apr 18, 3:38 pm, Rayne wrote:
> So you want him to write something that Rich hasn't said on his
> website to market his book? :\ If not you're going to clarify a bit.
>
Rayne, I think you are getting stuck on the very point I was. It
feels very odd paying for Stuarts book, when Rich has do
On Sun, Apr 19, 2009 at 1:30 AM, Antony Blakey wrote:
>
> On 19/04/2009, at 8:08 AM, Rayne wrote:
>
>>
>> So you want him to write something that Rich hasn't said on his
>> website to market his book? :\
>
> But Rich has written that - it's from Rich's forward to Stuart's book.
> Am I misundersta
On 19/04/2009, at 8:08 AM, Rayne wrote:
>
> So you want him to write something that Rich hasn't said on his
> website to market his book? :\
But Rich has written that - it's from Rich's forward to Stuart's book.
Am I misunderstanding your point?
Antony Blakey
-
CTO, Linkuistics P
So you want him to write something that Rich hasn't said on his
website to market his book? :\ If not you're going to clarify a bit.
I wish Stuart would have open sourced the book, like Real World
Haskell did. Would have done all kinds of good for the language. But
each to his own and Stuart rock
Konrad Hinsen wrote:
> On Mar 12, 2009, at 10:59, Jeff Rose wrote:
>
>>> My main conclusion is that Clojure's system is a lot more flexible
>>> but also a lot more fragile. Any function can modify data of any
>>> "type" (as defined by metadata), even without being aware of this.
>> Modifying type
On Mar 12, 2009, at 10:59, Jeff Rose wrote:
>> My main conclusion is that Clojure's system is a lot more flexible
>> but also a lot more fragile. Any function can modify data of any
>> "type" (as defined by metadata), even without being aware of this.
>
> Modifying type tags without being aware o
Konrad Hinsen wrote:
> On 11.03.2009, at 23:34, Chouser wrote:
>
>> Interacting directly with a class dict feels a little dirty, because
>> you could be circumventing the API provided by the class methods,
>> making it easy to get the object into a bad state. Clojure's maps
>> being immutable re
On 11.03.2009, at 23:34, Chouser wrote:
> Interacting directly with a class dict feels a little dirty, because
> you could be circumventing the API provided by the class methods,
> making it easy to get the object into a bad state. Clojure's maps
> being immutable reduces the amount of trouble y
1 - 100 of 139 matches
Mail list logo
