Re: Odd error evaling

[N8Dawgrr]

Ok not to worry, my environment was bust, a repl restart sorted the
issue.

On Dec 2, 11:27 pm, N8Dawgrr  wrote:
> Hi Clojurians,
>
> I hit the following error today. My environment is Clojure 1.3
>
> (eval (read-string (clojure.repl/source-fn 'keep-indexed)))
>
> # $InvokeExpr cannot be cast to clojure.lang.Compiler$ObjExpr, compiling:
> (NO_SOURCE_PATH:1)>
>
> Do other people get the same exception? If so what am I doing wrong?
>
> Regards
>
> Nathan

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: running foo.clj no main?? install clojure

[Joost]

> I run this line
> java -cp c:/opt/jars/clojure.jar:. clojure.main foo.clj

On windows, the java classpath separator is ";", so that should be

java -cp c:/opt/jars/clojure.jar;. clojure.main foo.clj


> I get it can't find clojure.main

Doesn't really seem to matter here, but to eliminate
misunderstandings, it's better to copy & paste the exact error you get
instead of paraphrasing / typing from memory.

> What is the best way to install clojure???

Many people use leiningen these days, which does all the "download
dependencies (including clojure itself) and set up the classpath"
stuff for you. See https://github.com/technomancy/leiningen

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Can't get the debugger cdt run

[Chris Perkins]

On Saturday, December 3, 2011 12:16:43 AM UTC-5, Sean Corfield wrote:
>
> On Fri, Dec 2, 2011 at 12:37 PM, George Jahad
>  wrote:
> > The easiest way to use cdt is from emacs, as described here:
> > http://georgejahad.com/clojure/swank-cdt.html
>
> Could you add a note to clarify that connecting "as usual" to a swank
> server is via the Emacs slime-connect command since I had to ask on
> IRC?
>
> This is the first time I've tried CDT and I have to say, I'm very
> impressed with how easy it is to use! Thank you!!
> -- 
>
So I guess you didn't get this error then?

user> (require '[swank.cdt :as d])
warning: unabled to add tools.jar to classpath. This may cause CDT 
initialization to fail.

Anyone know how to fix that?

- Chris

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Can't get the debugger cdt run

[Edmund]

Chris, that's not fatal.  Mine works just fine despite the warning.

On 03/12/2011 11:29, Chris Perkins wrote:
> On Saturday, December 3, 2011 12:16:43 AM UTC-5, Sean Corfield
> wrote:
> 
> On Fri, Dec 2, 2011 at 12:37 PM, George Jahad 
>  wrote:
>> The easiest way to use cdt is from emacs, as described here: 
>> http://georgejahad.com/clojure/swank-cdt.html
> 
> 
> Could you add a note to clarify that connecting "as usual" to a
> swank server is via the Emacs slime-connect command since I had to
> ask on IRC?
> 
> This is the first time I've tried CDT and I have to say, I'm very 
> impressed with how easy it is to use! Thank you!! --
> 
> So I guess you didn't get this error then?
> 
> user> (require '[swank.cdt :as d]) warning: unabled to add
> tools.jar to classpath. This may cause CDT initialization to fail.
> 
> Anyone know how to fix that?
> 
> - Chris
> 
> -- 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 from new members are
> moderated - please be patient with your first post. To unsubscribe
> from this group, send email to 
> clojure+unsubscr...@googlegroups.com For more options, visit this
> group at http://groups.google.com/group/clojure?hl=en

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Can't get the debugger cdt run

[Chris Perkins]

I realize now that I just pasted the warning, but I was getting a class 
loading exception too.
>
> I seem to have solved it with this, in my project.clj:

  :extra-classpath-dirs ["/usr/lib/jvm/java-6-sun/lib/tools.jar"]

I still get the warning, but it works now.  Thanks Edmund.

- Chris

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: delayed recursive macro expansion?

[Tassilo Horn]

Hi Andrew,

your problem is that your recursive macro's termination criterion (no
exception thrown for exp) is only there at runtime, but not at macro
expansion time.

Why don't you use a function here?

  (defn itry
"Calls f until it succeeds, querying the user for help."
[f]
(try (f)
  (catch Exception e
...
(recur f)))

Bye,
Tassilo

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: How to attach debugger on clojure's repl ?

[Chris Perkins]

On Friday, September 23, 2011 8:00:36 AM UTC-4, Sam Aaron wrote:
>
> > 
>
> I'd be very happy to write up a "Getting Started" tutorial on the ritz 
> wiki if I can get things working.
>
> Sam
>
 (two months later)

Not to publicly shame you or anything, Sam, but... how's that tutorial 
coming along?  :)))

Seriously - did you ever manage to get ritz working? I would like to try 
it, but I really need a "for dummies" guide.

I think I have followed the instructions to the letter, but when I run lein 
ritz I see this:

% lein ritz
Listening for transport dt_socket at address: 37460
user=> Swank server listening on local port  4005

Note the user=> prompt - I don't think that should be there.

Then, when I run "slime-connect" (which I assume is the missing step in the 
ritz readme between "lein ritz" and "set a breakpoint"), I see:

Versions differ: 2010-11-13 (slime) vs. 20101113 (swank). Continue?

Simultaneously, another prompt appears over in the terminal (not in emacs):

Listening for transport dt_socket at address: 37460
user=> Swank server listening on local port  4005
user=> 

I answer yes to the "Continue" question, but no repl opens in emacs.

I can enter something at the user=> prompt in the terminal, but it doesn't 
respond.

Any idea where I went wrong?

- Chris

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: How to attach debugger on clojure's repl ?

[Sam Aaron]

On 3 Dec 2011, at 14:03, Chris Perkins wrote:

> On Friday, September 23, 2011 8:00:36 AM UTC-4, Sam Aaron wrote:
> > 
> I'd be very happy to write up a "Getting Started" tutorial on the ritz wiki 
> if I can get things working.
> 
> Sam
> 
>  (two months later)
> 
> Not to publicly shame you or anything, Sam, but... how's that tutorial coming 
> along?  :)))

I never did manage to get ritz working. I believe the issue was with ritz <-> 
cake (I still use cake for Overtone hacking). However, now that cake and lein 
are going to be united, we can just focus on lein support for the future.

Alternatively, George Jahad has updated CDT (The Clojure Debugging Toolkit) to 
work with Clojure 1.3 which I'm testing out at the moment. He gave me a demo at 
the conj and it was insanely cool and worked perfectly.

Sam

---
http://sam.aaron.name

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: ANN: Clarity 0.5.1 - New GUI library

[Gary Trakhman]

Have you looked at seesaw?  What differences are there in the design and 
intent?

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: How to attach debugger on clojure's repl ?

[Chris Perkins]

On Saturday, December 3, 2011 9:50:21 AM UTC-5, Sam Aaron wrote:
>
>
> I never did manage to get ritz working. I believe the issue was with ritz 
> <-> cake (I still use cake for Overtone hacking). However, now that cake 
> and lein are going to be united, we can just focus on lein support for the 
> future.
>
> Alternatively, George Jahad has updated CDT (The Clojure Debugging 
> Toolkit) to work with Clojure 1.3 which I'm testing out at the moment. He 
> gave me a demo at the conj and it was insanely cool and worked perfectly. 
>
Yeah, I just got CDT working this morning too, but I wanted to try ritz as 
well to compare/contrast.

Does anyone know what the key differences are?  Do cdt and ritz do 
more-or-less the same things?

- Chris
 

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: delayed recursive macro expansion?

[Andrew]

Aren't the calls to itry-the-fn different from the calls to itry-the-macro? 
For example, let's say my expr is (/ a b) where b is currently zero and 
maybe the user decides to set a new value for b when prompted.

itry-the-macro can be called this way: (itry (/ a b)) and is able to print 
out the source code (/ a b) for the user as a string if it needs to.

itry-the-fn has to be called this way, right? (itry (fn [] (/ a b)) and is 
unable to print out the source code of the expression. Let me know if I'm 
mistaken.

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: A few enhancements

[Stuart Sierra]

A matter of curiosity: What are you doing that requires so much symbol 
manipulation?

-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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: FYI: problem I had with namespace, defrecord, and import, or "Hyphen characters in namespaces considered harmful"

[Stuart Sierra]

And even that (custom exception classes) should become unnecessary with the 
almost complete CLJ-733 (data conveying exception).

-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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: How to deal with parameters unused by intermediate functions?

[Stuart Sierra]

Map destructuring can help here:

(defn foo [{:keys [one two] :as args}]
  (bar args))

(defn bar [{:keys [three]}}
  ...)

(foo {:one 1 :two 2 :three 3})

-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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: How to deal with parameters unused by intermediate functions?

[Armando Blancas]

If foo is their only caller, bar and baz can be locals inside foo and
thus giving baz direct access to foo's params. Checkout (letfn):
http://clojuredocs.org/clojure_core/1.2.0/clojure.core/letfn

On Dec 2, 7:34 pm, Jim Crossley  wrote:
> Hi,
>
> I have a public function foo that uses two private functions bar and baz.
> So foo calls bar which calls baz. Two of the parameters passed to foo
> aren't used by bar, only baz.
>
> Though the segregation of behavior across foo, bar, and baz makes sense for
> my program, I feel dirty making the params required by baz a part of bar's
> signature.
>
> Should I just get over it or is there a better way?
>
> Thanks,
> Jim

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: delayed recursive macro expansion?

[Chris Perkins]

You should be able to just change your macro to a function, remove the 
backtick, and change (try ~expr ...) to (try (eval expr) ...).

- Chris

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

on lisp and scheme macros

[Razvan Rotaru]

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
preferable over the other (or not). I'd like to share with you some
ideas, and hopefully get some opinions back as well. Coming from the
lisp side, and without much knowledge on scheme macros, I'm also
trying to decide for myself whether scheme macros can have a
(practical) advantage.

One good point (found here http://lambdagrok.wikidot.com/forum/t-194636)
I think explains it pretty well: lisp macros merely transform a list
into another, while scheme macros use a pattern matching "sub-
language" to "apply transformations" on the input syntax, and produce
new syntax. I think this puts the finger on the spot.

It seems to me that with macros, scheme breaks out of the
homoiconicity of lisp, and opens up a new array of possibilities:
define new languages with different syntax (while lisp allows
new languages but with the same syntax). I'm saying this by looking at
Racket and the direction it has chosen to go (have a look at Typed
Scheme and Datalog). This looks like the world turned upside down: the
pattern matching macro system is the essence of the system, and scheme
is just another language defined with it. The list is not that
important anymore, since it's not so essential for the macro system.

Now, I have read some opinions which say that most who choose the
scheme macros, make it for the pattern matching abilities and not for
the hygienic part. This seems like a reasonable thing to do, since I
don't hear lispers complain about unhygienicity. If there are people
out there who had some practical experience with scheme macros, I hope
they read this post and share some thoughts.

I have a feeling that there's an additional gain with scheme macros:
debugging information given by the system when something goes wrong.
But it's only a feeling, I know too little of this subject to be sure.
Macros are hard to debug. The stacktrace displayed by clojure does not
contain information related to macro code. It's probably hard to do.
My feeling relates to the fact that in scheme macro processing is not
arbitrary, but rather strictly defined and under control. So I'm
thinking that this gives scheme more control over what's going on in a
macro and also enables scheme to give me more information in a
stacktrace. I'd love to hear other opinions on this.

Another point I find peculiar is the small attention that scheme
macros got during all these years. I wonder why it's like that. It
could be scheme's low score for practical stuff, but then again I
don't know of another language that borrows these kind of macros. Does
anybody know?

And lastly, a question to Rich Hickey, should he read this post: what
is the reasoning behind the choice of lisp macros over scheme's?

Cheers,
Razvan

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Can't get the debugger cdt run

[Sean Corfield]

On Sat, Dec 3, 2011 at 3:29 AM, Chris Perkins  wrote:
> So I guess you didn't get this error then?

I did get that warning on my desktop system but CDT worked just fine.

> user> (require '[swank.cdt :as d])
> warning: unabled to add tools.jar to classpath. This may cause CDT
> initialization to fail.

On my netbook, it actually did cause CDT to fail. I symlinked
tools.jar into ~/.lein/plugins/ so I wouldn't have to mess with
project.clj (since I have the same project.clj on both machines and
the tools.jar path is different!). That was based on a hint from Phil
H in a Leiningen thread about tools.jar (sorry, don't have the link
handy).
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: How to deal with parameters unused by intermediate functions?

[Jim Crossley]

I like that a lot, Stuart, thanks! Named params are a bonus, too:

Before I wasn't sure which was on top: (overlay x y pred)
Now it's more clear: (overlay :on x :with y :using pred)

Thanks again!
Jim

On Sat, Dec 3, 2011 at 1:03 PM, Stuart Sierra
wrote:

> Map destructuring can help here:
>
> (defn foo [{:keys [one two] :as args}]
>   (bar args))
>
> (defn bar [{:keys [three]}}
>   ...)
>
> (foo {:one 1 :two 2 :three 3})
>
> -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 from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: How to deal with parameters unused by intermediate functions?

[Jim Crossley]

Unfortunately, foo is not their only caller, but that's a cool technique
I'm sure I'll find a use for. :)

Thanks,
Jim

On Sat, Dec 3, 2011 at 1:05 PM, Armando Blancas  wrote:

> If foo is their only caller, bar and baz can be locals inside foo and
> thus giving baz direct access to foo's params. Checkout (letfn):
> http://clojuredocs.org/clojure_core/1.2.0/clojure.core/letfn
>
> On Dec 2, 7:34 pm, Jim Crossley  wrote:
> > Hi,
> >
> > I have a public function foo that uses two private functions bar and baz.
> > So foo calls bar which calls baz. Two of the parameters passed to foo
> > aren't used by bar, only baz.
> >
> > Though the segregation of behavior across foo, bar, and baz makes sense
> for
> > my program, I feel dirty making the params required by baz a part of
> bar's
> > signature.
> >
> > Should I just get over it or is there a better way?
> >
> > Thanks,
> > Jim
>
> --
> 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 from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Using goog.Timer from ClojureScript leads to compile error in advanced mode

[Paul Richards]

Hi,
I'm using goog.Timer inside my ClojureScript application.  When I
compile using the non-optimizing cljsc the code compiles and the
application works fine.  If I try to compile using the optimizing
compiler however I get the following error:

cljsc hello.cljs '{:optimizations :advanced}' > hello.js
Dec 3, 2011 7:26:50 PM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: hello:9: ERROR - required "goog" namespace never provided
goog.require('goog');
^

Dec 3, 2011 7:26:50 PM com.google.javascript.jscomp.LoggerErrorManager
printSummary
WARNING: 1 error(s), 0 warning(s)


My 'ns' line is as follows:

(ns hello
(:use
[goog.dom :only [appendChild createDom createTextNode removeChildren]]
[goog.events :only [listen]]
[goog.events.EventType :only [CLICK]]
[goog.graphics :only [createGraphics Stroke SolidFill Path]]
[goog :only [Timer]]
))



-- 
Paul Richards
@pauldoo

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

[ANN] dj-peg released 0.1.0

[Brent Millare]

dj-peg 0.1.0

A Ring inspired (aka functional and composable) parsing expression grammar 
(PEG) library.

A while back I wrote a PEG generator. Since it was buggy, I've completely 
rewritten it and also tried to write it psuedo literate programming (LP) 
style, in that I try to make it more of a story. I don't rely on any LP 
tools, its just heavily commented and should flow linearly. So if you never 
knew about PEGs before and want to dive into it, this would be a good 
opportunity to learn about it. Also I make good use of continuations, 
trampolines, and closures. Please check it out.

A quick example:

(require [dj.peg :as peg])

 (let [num (peg/alter-result (peg/token #"\d+") #(Integer/parseInt %))
   whitespace (peg/token #"\s+")
   triplet (peg/seq num whitespace num whitespace num)]
   (peg/parse triplet "3 44 2theremaininginput"))

;;user=> [[3 " " 44 " " 2] "theremaininginput"]   

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: [ANN] dj-peg released 0.1.0

[Brent Millare]

Forgot to post the github link:

git://github.com/bmillare/dj-peg.git

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

How do I identify Clojars clojure libraries that are 1.3 compatible?

[Tim Robinson]

Hello,

I'm just starting to upgrade to 1.3 ( I know, I know I should have
done this before :)

Like many of you, I am using lein, only I'm just starting to update
the dependency list. Clojure contrib seems pretty straight forward and
documented, but for what about libraries that are found on Clojars?
Are they flagged compatible somehow? i.e. ring, clj-json, clj-unit,
clj-stacktrace etc... or is it a research project for each one? Also,
it looks like many of them appear to be independent anyway, so it may
not be all that bad, but still I'm just wondering how everyone else
approached it.

Thanks,
Tim

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Agents vs. Actors

[Benny Tsai]

Hi Nils,

A while back, I also took a stab* at implementing Erlang-style actors in 
Clojure, along with solutions for a few classic concurrency problems 
(Dining Philosophers, Sleeping Barber).  I was blown away by how easy it 
was to implement actor semantics on top of agents.

Comparing our respective efforts, I see a lot of room for improvement in 
mine :)  I like how your actors send messages containing the address of the 
recipient, which seems truer to the actor model.  Also, you raise a great 
point regarding pattern matching; I think that can greatly simplify the 
message handlers in my code.  Looks like it's time for me to get acquainted 
with core.match :)

Thanks for the food for thought!

*https://github.com/bitsai/clojure-actors

On Friday, December 2, 2011 1:17:43 PM UTC-7, Nils Bertschinger wrote:
>
> Hi,
>
> how do Clojure agents relate to Erlang actors?
> To gain some insights, I tried to implement Erlang style message
> passing between agents. The first version is just a very incomplete
> sketch (no mailbox, case instead of pattern matching ...), but already
> shows that it is quite easily doable:
> https://github.com/bertschi/clojure-stuff/blob/master/src/stuff/actors.clj
>
> The idea is that the agent holds a dispatch function which is then
> called by ! (send) with the message to be send. Somehow it resembles
> the way closures can be used to implement an object system. Thus,
> agents seem to be the functional analog of agents:
> Functional programming Object-oriented
> programming
> sequential  closure
> object
> concurrent   agent
> actors
>
> Another great design from Rich Hickey! Clojure is fun and gets better
> every day ...
>
> Thanks,
>
> Nils
>
>

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: delayed recursive macro expansion?

[Andrew]

There's no light on in my attic. It's hollow and dark. :-P

(itry (/ 5 0)) 
==> exception

(itry (fn [] (/ 5 0))) 
==> #

But that's ok. I have my ugly macro that uses loop-recur. And I'll be fine.

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: How do I identify Clojars clojure libraries that are 1.3 compatible?

[Phil Hagelberg]

On Sat, Dec 3, 2011 at 11:50 AM, Tim Robinson  wrote:
> Like many of you, I am using lein, only I'm just starting to update
> the dependency list. Clojure contrib seems pretty straight forward and
> documented, but for what about libraries that are found on Clojars?
> Are they flagged compatible somehow? i.e. ring, clj-json, clj-unit,
> clj-stacktrace etc... or is it a research project for each one?

I would love to add this info as metadata to each project page on
clojars, but there are a few other additions that are more pressing on
the clojars codebase right now.

One thing you could look for is to see if the project.clj file uses
lein-multi; this is a good indicator that the project supports
multiple versions of Clojure. But this does require some digging. If
you have the time, it would be great if you could add lein-multi to
the project.clj file for projects that do intend to support multiple
versions of Clojure and send a pull request.

-Phil

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

How would you model this data?

[Base]

Hi All,

I currently have data stored in a hash-map as follows:
(atom
{ [1 2] "value 1",
  [1 3] "value 2",
  [4 5] "value 3"
  [4 6] "value 4"
})

I need to identify entries in this map where *either* the first or the
second value in the key matches a predicate.

(swap! my-map dissoc 1)
=> {
[4 5] "value 3"
[4 6] "value 4"
 }

and

(swap! my-map dissoc 6)
=> { [1 2] "value 1",
   [1 3] "value 2",
   [4 5] "value 3"}

What is the best way to handle this?  I could create a map of maps
instead...

{ 1 { 2 "value 1"
   3 "value 2"}
  4 {5 "value 3"
  6 "value 4"}}

but this just doesnt feel right.

I will need to add and remove values regularly and this will be a
large data structure (often 10K entries) and will need to do thousands
of these operations so efficiency will  be key.

Any ideas?

Thanks!
 Base

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: How would you model this data?

[Stephen Compall]

On Sat, 2011-12-03 at 13:14 -0800, Base wrote:
> I need to identify entries in this map where *either* the first or the
> second value in the key matches a predicate.

Unfortunately, you can only have one notion of key equality per map, so
you need to either introduce some linear-search component (as your
nested-maps example does), or add another map.  One or the other is
faster depending on how many values you have.

-- 
Stephen Compall
^aCollection allSatisfy: [:each|aCondition]: less is better

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: How would you model this data?

[Linus Ericsson]

I don't know what data the vectors depict, but if they are like floating
point numbers and you want to do distances etc (like geodata), and need
high performance on various strange matchings you should consider something
like R-trees

http://en.wikipedia.org/wiki/R-tree

(or check if there is some GIS-related stuff i clojure using this or
similar algoritms already)

Or if you have other needs, maybe create two datastructures in parallell
(maybe they could sorted or some other kind of indexing good for your
needs) and make lookups on either one depending on the question. If time is
more important than memory it could be a good idea to bloat the structure a
little.

/Linus


2011/12/3 Stephen Compall 

> On Sat, 2011-12-03 at 13:14 -0800, Base wrote:
> > I need to identify entries in this map where *either* the first or the
> > second value in the key matches a predicate.
>
> Unfortunately, you can only have one notion of key equality per map, so
> you need to either introduce some linear-search component (as your
> nested-maps example does), or add another map.  One or the other is
> faster depending on how many values you have.
>
> --
> Stephen Compall
> ^aCollection allSatisfy: [:each|aCondition]: less is better
>
> --
> 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 from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Agents vs. Actors

[Nils Bertschinger]

Hi Benny,

On Dec 3, 9:21 pm, Benny Tsai  wrote:
> Hi Nils,
>
> A while back, I also took a stab* at implementing Erlang-style actors in
> Clojure, along with solutions for a few classic concurrency problems
> (Dining Philosophers, Sleeping Barber).  I was blown away by how easy it
> was to implement actor semantics on top of agents.
looks good. Somewhat different approach where the state of the agent
is handled more explicitly. I tried to stay close to Erlang, so the
state is wrapped in a closire which acts as my matching function.
It might also be interesting to solve some of those classic
concurrency problems the Clojure way and compare to the actor
solutions.

>
> Comparing our respective efforts, I see a lot of room for improvement in
> mine :)  I like how your actors send messages containing the address of the
> recipient, which seems truer to the actor model.  Also, you raise a great
Actually, I do not include the address of the recipient into the
message. The message is simply a symbol and then dispatched in a case
statement.
The example might be slightly confusing since the actors are
named :ping and :pong and send messages "ping" and "pong" to each
other.
It's really a very simple sketch ... no pattern matching on messages
and no mailboxes.

> point regarding pattern matching; I think that can greatly simplify the
> message handlers in my code.  Looks like it's time for me to get acquainted
> with core.match :)
This seems to be the right approach to fake Erlang-style message
handlers.
>
> Thanks for the food for thought!
>
> *https://github.com/bitsai/clojure-actors
>

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: delayed recursive macro expansion?

[Nils Bertschinger]

Hi Andrew,

the approach suggested by Tassilo looks correct.
Macros are evaluated at compile-time, so you need a termination
condition that can be decided without actually running your form. In
you're case you want run-time delayed evaluation, which is easily
achieved by wrapping the expression into a closure.

On Dec 3, 6:45 pm, Andrew  wrote:
> Aren't the calls to itry-the-fn different from the calls to itry-the-macro?
> For example, let's say my expr is (/ a b) where b is currently zero and
> maybe the user decides to set a new value for b when prompted.
>
> itry-the-macro can be called this way: (itry (/ a b)) and is able to print
> out the source code (/ a b) for the user as a string if it needs to.
>
> itry-the-fn has to be called this way, right? (itry (fn [] (/ a b)) and is
> unable to print out the source code of the expression. Let me know if I'm
> mistaken.
You are right about the calling interface. itry-the-fn needs to have
its argument delayed explicitly, i.e. (itry (fn [] (/ a b))), and
cannot look into the form. A standard way to solve this problem is to
define both, a function and a macro which provides a more convenient
interface to the function.

(defmacro itry-the-macro [expr]
   `(itry-the-fn (fn [] ~expr)))
or in case you want to preserve access to the source code of the
expression:
(defmacro itry-the-macro [expr]
   `(itry-the-fn (fn [] ~expr)
'~expr)))
and itry-the-fn takes two arguments, one of which it can call and one
that can be expected, printed etc.

This approach of defining a macro as a shallow wrapper around a
function is quite common. It is also used in a couple of places in
clojure.core

Hope your attic lights up a little,

   Nils

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Clojure + Java Interop + Gnome Interop -- KeyPressEvent fails

[Henrik Lundahl]

Hi Rett

There is no such type as org.gnome.gtk.Window$**KeyPressEvents, at least
not in 4.1 of the Java Gnome
API
.  org.gnome.gtk.Window$**KeyPressEvent exists though. I'd guess you have a
typo somewhere, perhaps in the imports?


--
Henrik



On Sat, Dec 3, 2011 at 4:44 AM, Rett Kent  wrote:

> So, I've been dipping my toe in the waters of Clojure UI development using
> Gnome, and I immediately ran in into a problem making me regret my years of
> Java apathy.  I'm trying to write a toy program to processes generic key
> presses made to the Gnome window and I'm stuck as to how to translate the
> straight forward Java + Gnome interop into Clojure + Gnome Interop.  Here
> are the relevant pieces:
>
>
> w = new Window();
> l = new Label("Start Typing!\n" + "Start typing and details about\n"
>+ "your KeyEvents will\n" + "appear on the console.");
> l.setUseMarkup(true);
>  w.add(l);
>  w.connect(new Widget.KeyPressEvent() {
>public boolean onKeyPressEvent(Widget source, EventKey event) {
>final Keyval key;
>final ModifierType mod;
> key = event.getKeyval();
>mod = event.getState();
> System.out.print("Pressed: " + key.toString() + ", ");
>System.out.print("Modifier: " + mod.toString() + " ");
> if (mod == ModifierType.SHIFT_MASK) {
>System.out.print("That's Shifty!");
>}
>if (mod.contains(ModifierType.**ALT_MASK)) {
>System.out.print("Hooray for Alt!");
>}
>if (mod.contains(ModifierType.**SUPER_MASK)) {
>System.out.print("You're Super!");
>}
> System.out.println();
>return false;
>}
> });
>
> And in Clojure:
>
>  ...
>
>  (let [w (Window.)
>
>  ...
>
>(.connect w
>  (proxy [Widget$KeyPressEvent] []
>(onKeyPressEvent [source event]
>  (println (str "I was clicked: " (.getLabel b)))
>  ))
>  (proxy [Window$DeleteEvent] []
>(onDeleteEvent [source event]
>  (Gtk/mainQuit) false)
>(onDeleteEvents [source event]
>  (Gtk/mainQuit) false)
>))
>
>   ...
>
> And here's what I'm trying to do with it:
>
>
> (defn pushme []
>  (let [w (Window.)
>v (VBox. false 3)
>l (Label. "Go ahead:\nMake my day")
>b (Button. "Press me!")]
>(.connect b
>  (proxy [Button$Clicked] []
>(onClicked [source]
>  (println (str "I was clicked: " (.getLabel b)))
>  (println (str "I was clicked: " source))
>  )))
>(.connect w
>  (proxy [Widget$KeyPressEvent] []
>(onKeyPressEvent [source event]
>  (println (str "I was clicked: " (.getLabel b)))
>  ))
>  (proxy [Window$DeleteEvent] []
>(onDeleteEvent [source event]
>  (Gtk/mainQuit) false)
>(onDeleteEvents [source event]
>  (Gtk/mainQuit) false)
>))
>(.add v l)
>(.add v b)
>(.add w v)
>(.setDefaultSize w 200 100)
>(.setTitle w "Push Me")
>(.showAll w)
>(Gtk/main)
>)
>  )
>
>
> Results in:
>
> Exception in thread "main" java.lang.RuntimeException: 
> java.lang.**ClassNotFoundException:
> org.gnome.gtk.Window$**KeyPressEvents
>at clojure.lang.Util.**runtimeException(Util.java:**153)
>at clojure.lang.Compiler.eval(**Compiler.java:6417)
>at clojure.lang.Compiler.eval(**Compiler.java:6396)
>at clojure.lang.Compiler.load(**Compiler.java:6843)
>at clojure.lang.Compiler.**loadFile(Compiler.java:6804)
>at clojure.main$load_script.**invoke(main.clj:282)
>at clojure.main$script_opt.**invoke(main.clj:342)
>at clojure.main$main.doInvoke(**main.clj:426)
>at clojure.lang.RestFn.invoke(**RestFn.java:408)
>at clojure.lang.Var.invoke(Var.**java:401)
>at clojure.lang.AFn.**applyToHelper(AFn.java:161)
>at clojure.lang.Var.applyTo(Var.**java:518)
>at clojure.main.main(main.java:**37)
> Caused by: java.lang.**ClassNotFoundException: org.gnome.gtk.Window$**
> KeyPressEvents
>at java.net.URLClassLoader$1.run(**URLClassLoader.java:217)
>at java.security.**AccessController.doPrivileged(**Native Method)
>at java.net.URLClassLoader.**findClass(URLClassLoader.java:**205)
>at clojure.lang.**DynamicClassLoader.findClass(**
> DynamicClassLoader.java:61)
>at java.lang.ClassLoader.**loadClass(ClassLoader.java:**321)
>at java.lang.ClassLoader.**loadClass(ClassLoader.java:**266)
>at java.lang.Class.forName0(**Native Method)
>at java.lang.Class.forName(Class.**java:186)
>at user$eval21.invoke(main.clj:8)
>at clojure.lang.Compiler.eval(**Compiler.java:6406)
>
>
> Any thoughts or sugg

Re: How to deal with parameters unused by intermediate functions?

[Brian Goslinga]

In rare cases using vars + binding may be a good solution, although
your functions become impure and there can be interesting interactions
with laziness.

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: delayed recursive macro expansion?

[Brian Goslinga]

1) Write itry-fn which takes a function and the source of the
function. Example usage: (itry-fn (fn [] (/ 5 0)) '(/ 5 0))
2) Next write your itry macro to use the function:
(defmacro itry
  [expr]
  `(itry-fn (fn [] ~expr) '~expr))

A general rule of thumb for macros is that they should provide sugar
for underlying functions.

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: on lisp and scheme macros

[Stuart Sierra]

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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: on lisp and scheme macros

[Tassilo Horn]

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 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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: on lisp and scheme macros

[Peter Danenberg]

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 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 from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: on lisp and scheme macros

[Scott Jaderholm]

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
> preferable over the other (or not). I'd like to share with you some
> ideas, and hopefully get some opinions back as well. Coming from the
> lisp side, and without much knowledge on scheme macros, I'm also
> trying to decide for myself whether scheme macros can have a
> (practical) advantage.
>
> One good point (found here http://lambdagrok.wikidot.com/forum/t-194636)
> I think explains it pretty well: lisp macros merely transform a list
> into another, while scheme macros use a pattern matching "sub-
> language" to "apply transformations" on the input syntax, and produce
> new syntax. I think this puts the finger on the spot.
>
> It seems to me that with macros, scheme breaks out of the
> homoiconicity of lisp, and opens up a new array of possibilities:
> define new languages with different syntax (while lisp allows
> new languages but with the same syntax). I'm saying this by looking at
> Racket and the direction it has chosen to go (have a look at Typed
> Scheme and Datalog). This looks like the world turned upside down: the
> pattern matching macro system is the essence of the system, and scheme
> is just another language defined with it. The list is not that
> important anymore, since it's not so essential for the macro system.
>
> Now, I have read some opinions which say that most who choose the
> scheme macros, make it for the pattern matching abilities and not for
> the hygienic part. This seems like a reasonable thing to do, since I
> don't hear lispers complain about unhygienicity. If there are people
> out there who had some practical experience with scheme macros, I hope
> they read this post and share some thoughts.
>
> I have a feeling that there's an additional gain with scheme macros:
> debugging information given by the system when something goes wrong.
> But it's only a feeling, I know too little of this subject to be sure.
> Macros are hard to debug. The stacktrace displayed by clojure does not
> contain information related to macro code. It's probably hard to do.
> My feeling relates to the fact that in scheme macro processing is not
> arbitrary, but rather strictly defined and under control. So I'm
> thinking that this gives scheme more control over what's going on in a
> macro and also enables scheme to give me more information in a
> stacktrace. I'd love to hear other opinions on this.
>
> Another point I find peculiar is the small attention that scheme
> macros got during all these years. I wonder why it's like that. It
> could be scheme's low score for practical stuff, but then again I
> don't know of another language that borrows these kind of macros. Does
> anybody know?
>
> And lastly, a question to Rich Hickey, should he read this post: what
> is the reasoning behind the choice of lisp macros over scheme's?
>
> Cheers,
> Razvan
>
> --
> 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 from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: ANN: Clarity 0.5.1 - New GUI library

[Stathis Sideris]

Hello Gary,

Hello Gary,

To be honest I didn't look at seesaw much while developing Clarity, so
I didn't make any conscious decision to differentiate with seesaw.
It's very interesting to see that both me and Dave Ray came up with
similar solutions/features.

It seems that Seesaw is more concise in comparison to Clarity, and
from the project page it does look like a more mature project. On the
other hand, it seems to me (and I might be wrong) that Clarity has a
more complete solution when it comes to selectors because it supports
"categories" on top of the IDs, and the syntax caters for arbitrary
logic operations and custom selectors.

It seems that Seesaw uses binding for keeping GUI values and atoms/
refs in sync, and Clarity instead provides easy ways to retrieve all
the values of all components in a panel as a map (see the HasValue
interface). I like Clarity's approach better because it's more de-
coupled.

The other thing that I think differentiates Clarity is the live
preview of layouts using clarity.dev/watch-component.

Finally, let me repeat that all of the above are based on a
superficial reading of Seesaw's docs, I may as well be wrong!

Thanks,

Stathis


On Dec 3, 2:52 pm, Gary Trakhman  wrote:
> Have you looked at seesaw?  What differences are there in the design and
> intent?

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: The Clojure way to solve this problem?

[AndyK]

Thank you - that worked brilliantly. I'm using a Java load testing
tool called The Grinder and it has an instrumented HTTP library that
is dependent on running within The Grinder. So I have clj-http for
developing my tests and then I can drop them into load testing and
substitute the Grinder using with-redefs. Works so nicely. Loving
Clojure - wonderful for test automation.

On Nov 30, 8:13 pm, gaz jones  wrote:
> what about just re-defing the function inside the tests to the
> instrumented version?
>
> something like:
>
> (ns one.http)
> (defn get [] ...)
>
> (ns one.http-instrumented)
> (defn get [] ...)
>
> (ns one.test.blah)
> (with-redefs [one.http/get one.http-instrumented/get]
>   ...)
>
> guess you could put the redefs into a function and use it as a fixture
> if you're using clojure.test? that would get rid of the flag and fork
> in the code O_o
>
>
>
>
>
>
>
> On Wed, Nov 30, 2011 at 5:53 PM,AndyK wrote:
> > I have Clojure code which makes HTTP requests to a server. Depending
> > on the context, I want to swap out the underlying HTTP library code.
> > For example, I use an instrumented library in a testing context and a
> > different library in a REPL context where the instrumented library
> > will not work. These are low-lying functions - the http/get and http/
> > put - called within other functions for doing specific kinds of
> > requests which are called in turn by other functions.
>
> > What I'm wondering is what are good ways to dynamically choose which
> > versions of those low-lying functions to use?
>
> > For now, I'm doing this within the namespace that uses the low-lying
> > functions..
>
> > (def get (if (context-flag?) ns.one.http-instrumented/get ns.two.http-
> > repl/get))
>
> > What I don't like about this is that context-flag feeling like a hacky
> > approach.
>
> > Thoughts?
>
> > --
> > 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 from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: on lisp and scheme macros

[Marek Kubica]

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 anything as powerful than the CL macro system.

I'd love to see an example because I digged into Scheme macros for my
studies, and you can definitely break out of hygienic macros if you
want to. Which seems reasonable to me, to have a safe system by default
and then the ability to break out. Just like lexical and dynamic scope
in Clojure.

regards,
Marek

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: ANN: Clarity 0.5.1 - New GUI library

[Dave Ray]

Howdy,

I'll clarify some of Stathis' remarks about Seesaw below. Obviously,
I'm a little biased, but Clarity looks cool and I plan on "borrowing"
some of its features for Seesaw in the next release or two :)  I think
it's great to have multiple projects like this to inspire each other
and keep everyone honest. Keep up the nice work!

Cheers,

Dave

more inline below ...

On Sat, Dec 3, 2011 at 8:15 PM, Stathis Sideris  wrote:
> Hello Gary,
>
> Hello Gary,
>
> To be honest I didn't look at seesaw much while developing Clarity, so
> I didn't make any conscious decision to differentiate with seesaw.
> It's very interesting to see that both me and Dave Ray came up with
> similar solutions/features.
>
> It seems that Seesaw is more concise in comparison to Clarity, and
> from the project page it does look like a more mature project. On the
> other hand, it seems to me (and I might be wrong) that Clarity has a
> more complete solution when it comes to selectors because it supports
> "categories" on top of the IDs, and the syntax caters for arbitrary
> logic operations and custom selectors.

Seesaw selectors are basically Enlive selectors [1] ported to Swing.
So it supports all the usually CSS hierarchical stuff, ids and classes
(Clarity's categories). It can also select on Java class/sub-class
relationships. I left it at that since selector+filter seemed a
reasonable enough way to add custom predicates or whatever if
necessary.

[1] http://enlive.cgrand.net/syntax.html

> It seems that Seesaw uses binding for keeping GUI values and atoms/
> refs in sync, and Clarity instead provides easy ways to retrieve all
> the values of all components in a panel as a map (see the HasValue
> interface). I like Clarity's approach better because it's more de-
> coupled.

Yep. I like Clarity's (value) function as well, especially for forms
in dialogs. I'll be borrowing that. If you need to update one or more
aspects of the UI based on changes in a reference type or some aspect
of a widget, bindings (in the Seesaw sense) work nicely because they
provide that automatic propagation and fine granularity.

> The other thing that I think differentiates Clarity is the live
> preview of layouts using clarity.dev/watch-component.

I think that's very cool too. I approximate that workflow using
lazytest's watcher to re-run my code when it changes.

> Finally, let me repeat that all of the above are based on a
> superficial reading of Seesaw's docs, I may as well be wrong!
>
> Thanks,
>
> Stathis
>
>
> On Dec 3, 2:52 pm, Gary Trakhman  wrote:
>> Have you looked at seesaw?  What differences are there in the design and
>> intent?
>
> --
> 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 from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: on lisp and scheme macros

[Razvan Rotaru]

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 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
> > preferable over the other (or not). I'd like to share with you some
> > ideas, and hopefully get some opinions back as well. Coming from the
> > lisp side, and without much knowledge on scheme macros, I'm also
> > trying to decide for myself whether scheme macros can have a
> > (practical) advantage.
>
> > One good point (found herehttp://lambdagrok.wikidot.com/forum/t-194636)
> > I think explains it pretty well: lisp macros merely transform a list
> > into another, while scheme macros use a pattern matching "sub-
> > language" to "apply transformations" on the input syntax, and produce
> > new syntax. I think this puts the finger on the spot.
>
> > It seems to me that with macros, scheme breaks out of the
> > homoiconicity of lisp, and opens up a new array of possibilities:
> > define new languages with different syntax (while lisp allows
> > new languages but with the same syntax). I'm saying this by looking at
> > Racket and the direction it has chosen to go (have a look at Typed
> > Scheme and Datalog). This looks like the world turned upside down: the
> > pattern matching macro system is the essence of the system, and scheme
> > is just another language defined with it. The list is not that
> > important anymore, since it's not so essential for the macro system.
>
> > Now, I have read some opinions which say that most who choose the
> > scheme macros, make it for the pattern matching abilities and not for
> > the hygienic part. This seems like a reasonable thing to do, since I
> > don't hear lispers complain about unhygienicity. If there are people
> > out there who had some practical experience with scheme macros, I hope
> > they read this post and share some thoughts.
>
> > I have a feeling that there's an additional gain with scheme macros:
> > debugging information given by the system when something goes wrong.
> > But it's only a feeling, I know too little of this subject to be sure.
> > Macros are hard to debug. The stacktrace displayed by clojure does not
> > contain information related to macro code. It's probably hard to do.
> > My feeling relates to the fact that in scheme macro processing is not
> > arbitrary, but rather strictly defined and under control. So I'm
> > thinking that this gives scheme more control over what's going on in a
> > macro and also enables scheme to give me more information in a
> > stacktrace. I'd love to hear other opinions on this.
>
> > Another point I find peculiar is the small attention that scheme
> > macros got during all these years. I wonder why it's like that. It
> > could be scheme's low score for practical stuff, but then again I
> > don't know of another language that borrows these kind of macros. Does
> > anybody know?
>
> > And lastly, a question to Rich Hickey, should he read this post: what
> > is the reasoning behind the choice of lisp macros over scheme's?
>
> > Cheers,
> > Razvan
>
> > --
> > 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 from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en