On 30 December 2011 17:00, Timothy Baldridge wrote:
> A few months back I released 1.0 of deep-freeze, a binary
> serialization library for Clojure. Due to recent additions by Peter
> Taoussanis I thought it would be about time to let some more people
> know about this project, and bump the versi
> I guess what I'd like a mode where I can say "act like read/pr" and> for
> deep-freeze to ignore metadata, refs and atoms.
I'm still not sure I'm getting this argument though. In its current
form, deep-freeze makes an attempt to preserve as much information as
it can. In the specific case of ST
http.async.client is Asynchronous HTTP Client for Clojure and just got
v0.4.0 release.
Code: http://github.com/neotyk/http.async.client
Docs: http://neotyk.github.com/http.async.client/
Changelog: http://neotyk.github.com/http.async.client/changelog.html
Clojars: http://clojars.org/http.async.clie
Looking at the clojure.main/repl code, I can see that they print the result
value to stdout, and that I can change that by assigning a different function
to the :print option at repl-startup.
It's a little tricky, but that does allow me to turn the printing of results
on/off, which would give m
On Fri, Dec 30, 2011 at 4:13 PM, Alan Malloy wrote:
> On Dec 30, 11:34 am, "Marshall T. Vandegrift"
> wrote:
>> Peter Taoussanis writes:
>> > Thanks- that explains it: dropping to extend works as expected.
>>
>> Another option I've been making use of for exactly this situation is to
>> use the #
On 30 December 2011 18:54, Timothy Baldridge wrote:
>> I think it might be more useful if freeze/thaw worked on the same
>> domain as read/pr by default. That way I can swap in and out different
>> serialization functions without altering the behaviour of the
>> application.
>
> Well, from my view
> Yes - I do get the result of the print function in the repl (i.e. nil), and
> I'm trying to see how I can somehow prevent that nil from printing to stdout.
Yeah, the point I was making is that you are always going to see that
'nil' printed at the repl because it always evaluates and prints the
"planned to support" sounds about right.
I do not know that it does not work.
If any adventuresome mono-ites (mono-istas?) cares to give it a
try ... .
-David
On Dec 30, 12:07 pm, Shantanu Kumar wrote:
> Does ClojureCLR work (or is planned to support) Mono[1] by any chance?
>
> [1] Mono –htt
On Dec 30, 11:34 am, "Marshall T. Vandegrift"
wrote:
> Peter Taoussanis writes:
> > Thanks- that explains it: dropping to extend works as expected.
>
> Another option I've been making use of for exactly this situation is to
> use the #= reader macro to evaluate the Class/forName at read-time.
> S
Yes - I do get the result of the print function in the repl (i.e. nil), and I'm
trying to see how I can somehow prevent that nil from printing to stdout.
I understand that you do not see any nil's in your example as you stay inside
of your loop and there is no result only side effects.
(which is
Hi,
Am 30.12.2011 um 20:34 schrieb Marshall T. Vandegrift:
> Another option I've been making use of for exactly this situation is to
> use the #= reader macro to evaluate the Class/forName at read-time.
> Something like:
>
> (extend-protocol MyProtocol
>java.lang.Integer (action [x] "Intege
are you sure you're not just seeing the result of the function call in
the repl? for example this:
(ns filter.core
(:require [clojure.string :as string])
(:gen-class))
(defn -main
[& args]
(loop []
(when-let [line (read-line)]
(println (string/upper-case line))
(recur
I'm trying to write some filters in clojure from stdin to stdout, but I have
this nil at the end of the stream, which is what print returns.
As an alternative, I can return strings, but then I have the surrounding "s.
Or I could end by printing (symbol ""), like (do (print "hi")(symbol "")) whic
Peter Taoussanis writes:
> Thanks- that explains it: dropping to extend works as expected.
Another option I've been making use of for exactly this situation is to
use the #= reader macro to evaluate the Class/forName at read-time.
Something like:
(extend-protocol MyProtocol
java.lang.Inte
> I think it might be more useful if freeze/thaw worked on the same
> domain as read/pr by default. That way I can swap in and out different
> serialization functions without altering the behaviour of the
> application.
Well, from my view, read-string/print-str is completely broken when it
comes t
+1 Luc,
You have to let go. There was something I read once from Alistair and said
that people prefer familiarity over comfort, this is a real problem,
because when people get used to something it's really hard to show them
something more comfortable. I was shocked when I found myself choosing
fam
On 30 December 2011 17:42, Peter Taoussanis wrote:
>> It would be nice if there was an option to make deep-freeze
>> interchangable with read/pr.
>
> Hmm- I don't follow. Interchangeable how? Could you explain what use
> you have in mind?
Well, currently it's not directly interchangeable because
> However, let's turn it around for a
> moment and ask another question: why is it that some newcommers year after
> year think that the choice of this syntax is arbitrary?
Some people come with lots of baggage from other languages they like.
That's why various complaints and proposals are so sup
Does ClojureCLR work (or is planned to support) Mono[1] by any chance?
[1] Mono – http://www.mono-project.com/Main_Page
Regards,
Shantanu
On Dec 30, 9:41 pm, dmiller wrote:
> As noted, the biggest difference is interop. I've started posting on
> such matters athttp://clojureclr.blogspot.com.
> How are atoms/refs supported?
Very simply: they're just dereferenced during freezing and that value
is reinserted into an atom/ref/whatever during thawing. Any metadata
is also retained.
> It would be nice if there was an option to make deep-freeze
> interchangable with read/pr.
Hmm- I don't f
As noted, the biggest difference is interop. I've started posting on
such matters at http://clojureclr.blogspot.com. These posts assume
basic familiarity with Clojure.
I highly recommend Rob's (@rippinrobr) series of posts at
http://www.myclojureadventure.com/ for getting started with
ClojureCLR
I am a polyglot programmer and never insisted to change the look of any
language.
I used them as is assuming that many people worked on their design for
several man years, more that I could spend myself on any of these design
decisions
and their impacts.
I worked with at least a dozen of these (
> Lisp experts don't quite understand
It's certainly possible. It wouldn't be the first time that Lispers
missed the forest for the trees. However, let's turn it around for a
moment and ask another question: why is it that some newcommers year after
year think that the choice of this syntax is
How about using a and b instead of ( ) so we could have faab which would be the
equivalent of (f a) so it would rule out symbolnames with an a in any place but
the first it, also we could go for less used characters as I don't know ¥ and µ
for example so that would not be half as fun I think.
--
Hi All,
md-clj (working name) is a wrapper around the ZeroMQ Majordomo
pattern. It implements some sugar for creating simple request-reply
service-oriented applications in Clojure. The core Majordomo code
currently uses the ZeroMQ Guide Java implementation.
At this point md-clj is about one step
On Fri, Dec 30, 2011 at 8:38 AM, James Reeves wrote:
> On 30 December 2011 06:00, Timothy Baldridge wrote:
>> A few months back I released 1.0 of deep-freeze, a binary
>> serialization library for Clojure.
>
> You might want to provide a link to the project home page :)
>
Wow, I can't believe I
True, lack of conciseness may not be the first thing that comes to mind
when speaking about Lisps :-)
What I should have said is that I think equivalent Python code has fewer
'noise' symbols than S-expressions. Of course, that depends greatly on how
the programs are structured.
And, that bri
On 30 December 2011 06:00, Timothy Baldridge wrote:
> A few months back I released 1.0 of deep-freeze, a binary
> serialization library for Clojure.
You might want to provide a link to the project home page :)
> deep-freeze is a simple serialization library that aims to be fast,
> generate conci
On Fri, Dec 30, 2011 at 9:19 AM, PC wrote:
> There's a very nice summary of previous attempts at this on David Wheeler's
> web page: http://www.dwheeler.com/readable/index.html
> I think these ideas have some merit. I would like to have the readability
> and conciseness of Python with the feature
There's a very nice summary of previous attempts at this on David Wheeler's
web page: http://www.dwheeler.com/readable/index.html
I think these ideas have some merit. I would like to have the readability
and conciseness of Python with the features and performance of Clojure.
--
You received t
Hi Jonas,
That's what I was looking for. Thanks for your reply
On Fri, Dec 30, 2011 at 8:16 AM, Jonas wrote:
> You should take a look at tools.trace [1]. A minimal example:
>
> (ns trc.core
> (:use [clojure.tools.trace :only [deftrace]]))
>
> (deftrace fib [n]
> (if (or (=
You should take a look at tools.trace [1]. A minimal example:
(ns trc.core
(:use [clojure.tools.trace :only [deftrace]]))
(deftrace fib [n]
(if (or (= n 0) (= n 1))
1
(+ (fib (- n 1)) (fib (- n 2)
the following is printed when (fib 4) is evaluated:
TRACE t
Hi Cedric,
I'm glad to know there's no such need for debugging. Maybe it's a need for
me right now due to my level, but the more I work with the language, the
more I'll learn. On top of that the community helps a lot, thanks to all of
you for that. I've been in a lot of places, and I can tell that
33 matches
Mail list logo
