Re: Problem filtering with definline'd function

[Colin Fleming]

So this has just happened to me again:

Clojure 1.5.1
(plugin.psi/symbol? 2)
=> false
(filter plugin.psi/symbol? [1 2 3])
=> (1 2 3)
((var-get #'plugin.psi/symbol?) 2)
=> (clojure.core/instance?
org.jetbrains.plugins.clojure.psi.api.symbols.ClSymbol 2)

What that looks like to me is that the macro fn (i.e. the one that is
usually in the :inline meta) is being stored in the var. So when it's used
by filter, it always returns true. Does anyone have any idea what else I
could try to debug this? I'll leave the REPL session open so I can try any
suggestions.

I just tried this, looks like the fns are not the same, at least, but they
do have the same effect:

(meta #'plugin.psi/symbol?)
=> {:inline plugin.psi$symbol_QMARK_@3781ff7f, :ns plugin.psi, :name
symbol?, :arglists ([element]), :column 1, :line 35, :file "plugin/psi.clj"}
(= plugin.psi/symbol?
   (:inline (meta #'plugin.psi/symbol?)))
=> false
plugin.psi/symbol?
=> plugin.psi$symbol_QMARK_@4ccc75ae
((:inline (meta #'plugin.psi/symbol?)) 2)
=> (clojure.core/instance?
org.jetbrains.plugins.clojure.psi.api.symbols.ClSymbol 2)



On 20 June 2013 22:48, Colin Fleming  wrote:

> ClSymbol is a Java class. I don't get the replacement warning because I've
> excluded that symbol explicitly in my ns declaration using :refer-clojure
> :exclude.
>
> I haven't done a 'lein clean' because I'm not using lein, but I have
> rebuilt various times. However, sometimes it will work and sometimes it
> won't. I just tried this now, and I've been unable to reproduce. I guess
> I'll keep working tomorrow and see if it crops up again. If I see it again
> I'm going to try ((var-get #'symbol?) 2) to see if the results from the
> function differ from the macroexpanded version.
>
>
>
>
> On 20 June 2013 22:21, Jim - FooBar();  wrote:
>
>> On 20/06/13 10:59, Colin Fleming wrote:
>>
>>> Because this tests for something different - that the element is an
>>> instance of ClSymbol. It's not testing the same thing as the core version.
>>> I qualify it (psi/symbol? in the examples above) to distinguish it from the
>>> core one.
>>>
>>> Basically, I'm trying to use definline to allow me to have a more
>>> Clojure-y API without having the performance hit of tons of tiny function
>>> calls.
>>>
>>> I agree that this is unlikely to be a bug in Clojure and is probably
>>> something I'm missing, but I can't figure it out.
>>>
>>
>> right I see...so if ClSymbol is a defrecord/deftype I don't see anything
>> wrong with your code...when you do (in-ns 'plugin.psi) do you get a warning
>> that core/symbol? is being replaced by psi/symbol?  ?
>>
>> what you tried on your repl works fine on mine:
>>
>> user=> (defrecord FOO [a])
>> user.FOO
>>
>> user=> (definline foo? [e]
>>   #_=>   `(instance? FOO ~e))
>> #'user/foo?
>>
>> user=> (foo? 2)
>> false
>>
>> user=> (filter foo? [1 2 3])
>> ()
>>
>> user=> (filter foo? [(FOO. 1) 2 3])
>> (#user.FOO{:a 1})
>>
>> Did you try 'lein clean' to get rid of already compiled classes? I'm
>> suspecting you have different versions of the same class lying around
>> because of what you said about compiling and recompiling...
>>
>> 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+unsubscribe@**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 unsubscribe from this group and stop receiving emails from it, send an
>> email to 
>> clojure+unsubscribe@**googlegroups.com
>> .
>> For more options, visit 
>> https://groups.google.com/**groups/opt_out
>> .
>>
>>
>>
>

-- 
-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

representing clojure source code as data?

[kovas boguta]

What's the latest opinion on parsing and representing clojure code as data?

I'm talking about representations suitable for code analysis; representing
the definition of the program as specified by the programmer.

 As opposed to:

1. a representation of the program implied by the source code (aka read)
2. a representation of the document that represents the source code.  (aka
sjacket)

To summarize the issues with read:

1. Reader macros like ` cause significant difference between the source
code and the return value of read. This is a problem for code analysis (and
complicates the matter of error messages..)

2. Read is tied to the state of the system. This means you cannot 100%
reliably and securely read arbitrary clojure source. *Read-eval* is a
tradeoff - you won't trash your env, but at the cost of not being able to
perceive the full domain of clojure source. And regardless the setting of
*read-eval*, mere perception is contingent on state: constructors will blow
up if you don't have the class.

The state problem is not only an edge case of JVM-clojure interop. It also
comes up in cljs compilation, where one is reading cljs source within the
clj reader and must be careful. And of course, its a problem if you want to
analyze a large amount of arbitrary source code :)

I'm aware of sjacket, but that's more about representing the document, not
the program description. Are there other things out there?

I think there are 2 representations that could be useful:
1. as pure EDN data that encodes the various reader macros within the
strict EDN subset, as a kind of minimal AST
2. as datoms in datomic, suitable for integration with codeq and more
forward-thinking ways of managing programs.

Besides use in tooling, I also think of this as a "serializable-fn"-plus,
more useful in distributed systems because of safer, easier analysis and
transformation.

Anyway, was wondering who else has thought about this, and has some
potential designs, implementation approaches, repos, opinions, etc

-- 
-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

More on Object Behavior System and "the entire hierarchy is a nested data structure"

[Leon Talbot]

Hello! 

I am interested in knowing more about the Object Behavior system presented 
by Chris Granger at Conj 2012. I find it really clean and the idea of 
having objects combined with the fact that "the entire hierarchy is a 
nested data structure that is easy to reason about and modify at runtime 
without the use of a fancy debugger" seems really interesting.

Where can we learn how to program like that? Who's doing this too? Where 
are some other code example (than Chris work)?

Thanks !

>From https://news.ycombinator.com/item?id=5116234
seanmcdirmid  146 days 
ago | link 

I don't really get it. From the blog post, Granger is describing a very 
imperative object system, but you seem to be claiming that it is somehow a 
value-oriented functional system. What am I missing?

-

krosaen  143 days ago | 
link

That's a good question - there are still objects, or groupings of data, and 
even tags that identify which behaviors or functions apply to them in 
various contexts. What strikes me as different is the entire hierarchy is a 
nested data structure that is easy to reason about and modify at runtime 
without the use of a fancy debugger. The use of 'encapsulation' that hid 
the underlying data in each grouping and also bind functions / methods 
directly to each object in this case would only make it harder to work 
with. Why? Because to view, construct, augment at runtime or serialize the 
hierarchy would require constructors, serializers, deserializers etc, 
instead of having something that is just a data structure, ready to be 
viewed, put on a queue, sent over the wire etc.

The idea of 'behaviors' also provides flexibility in what functions can act 
on any grouping of data - the key value pairs needn't be associated with a 
'class' which dictates what the associated functions will be adds more 
flexibility. As the author hints, there are other ways of achieving this 
agility - dynamic mixins.

Finally, while having a well defined protocol (or API or endpoint or 
whatever you want to call it) is valuable and helps organize code, I think 
taking this idea to the extreme and saying that every single object or 
piece of data you pass around as arguments or return values from these end 
points needs to be expressed as an abstract protocol itself is where you 
really start to lose. An expected format of the data structures of the 
arguments and return values can and should be part of an API, but needing 
to wrap them in objects doesn't really help - and that's where this trend I 
speak of begins to seem like progress to me.

-- 
-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Vector is only half associative?

[Stephen Compall]

On Fri, 2013-06-07 at 13:25 +0200, Robert Ewald wrote:
> But merge-with and other functions don't work, even though I
> think it is not unreasonable to expect that.

What do you expect the results of these to be?

(merge-with + [1 2])
(merge-with + [1 2 3] [])
(merge-with + [] [1 2 3])
(merge-with + [1 2 3] [4 5 6 7])
(merge-with + {6 7, 8 9} [1 2 3])
(merge-with + [1 2 3] {})

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Why does peek on a seq of vector fail?

[Jason Gilman]

I think I get the difference now between a sequence, list, and a vector. Thanks 
for the quick answers. 

On Jun 20, 2013, at 5:14 PM, "John D. Hume"  wrote:

> On Jun 20, 2013 3:11 PM, "Jason Gilman"  wrote:
> >
> > (defn bar [my-list n]
> >   (if (= n 0)
> >   (peek my-list)
> >   (bar (rest my-list) (dec n
> > (bar [1 2 3] 1)
> >
> 
> It seems likely you want either first and rest* (to work from the front of 
> any seqable) or peek and pop (to work from the back of a vector or the front 
> of a list or queue). Combining peek and rest on a vector as the bar function 
> does makes no sense, since they work at opposite ends.
> 
> *or next in place of rest.
> 
> -- 
> -- 
> 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 a topic in the Google 
> Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/7DzLLsmnm-E/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Why does peek on a seq of vector fail?

[John D. Hume]

On Jun 20, 2013 3:11 PM, "Jason Gilman"  wrote:
>
> (defn bar [my-list n]
>   (if (= n 0)
>   (peek my-list)
>   (bar (rest my-list) (dec n
> (bar [1 2 3] 1)
>

It seems likely you want either first and rest* (to work from the front of
any seqable) or peek and pop (to work from the back of a vector or the
front of a list or queue). Combining peek and rest on a vector as the bar
function does makes no sense, since they work at opposite ends.

*or next in place of rest.

-- 
-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: try* macro to catch multiple exception classes with one body. feedback is needed.

[Herwig Hochleitner]

One thing to consider: try* is a compiler builtin form. Those are currently
not even namespaced. That might lead to confusion for readers.


2013/6/20 Max Gonzih 

> I updated my macro to your solution, looks really simple and works like
> before. I don't know why I overcomplicated my original solution so much :).
>
> Thanks again!
>
>
> On Thursday, June 20, 2013 8:47:37 AM UTC+3, Meikel Brandmeyer (kotarak)
> wrote:
>>
>> Hi,
>>
>> Am Mittwoch, 19. Juni 2013 17:00:17 UTC+2 schrieb Max Gonzih:
>>>
>>> Hi, I implemented small macro to catch multiple exception classes with
>>> one body.
>>>
>>> https://gist.github.com/**Gonzih/5814945
>>>
>>> What do you think? Are there better ways to achieve similar results?
>>>
>>>
>> I would just extend try a simply as possible: simply add the catch-all,
>> but keep catch and finally as is. Here my try:
>>
>> (defmacro try*
>>   [& body]
>>   (let [catch-all?   #(and (seq? %) (= (first %) 'catch-all))
>> expand-catch (fn [[_catch-all exceptions & catch-tail]]
>>(map #(list* 'catch % catch-tail) exceptions))
>> transform(fn [form]
>>(if (catch-all? form)
>>  (expand-catch form)
>>  [form]))]
>> (cons `try (mapcat transform body
>>
>> (try*
>>   (println :a)
>>   (println :b)
>>   (catch-all [A B C] e (println (type e)))
>>   (catch D _ (println "Got D!"))
>>   (finally (println "Finally!")))
>>
>> expands to
>>
>> (try
>>   (println :a)
>>   (println :b)
>>   (catch A e (println (type e)))
>>   (catch B e (println (type e)))
>>   (catch C e (println (type e)))
>>   (catch D _ (println "Got D!"))
>>   (finally (println "Finally!")))
>>
>> Kind regards
>> Meikel
>>
>  --
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Why does peek on a seq of vector fail?

[László Török]

Hi,

I think it's by design.

It only works with concrete data structure (list, vector, queue) types that
implement

clojure.lang.IPersistentStack

Las




2013/6/20 Jason Gilman 

> Also, I really appreciate anyone who takes the time to answer. My company
> is currently evaluating Clojure. I'm trying to determine if this is
> non-idiomatic use of the language or some other issue. Doing something like
> this can cause the bug to occur without directly calling seq on a vector:
>
> (defn bar [my-list n]
>   (if (= n 0)
>   (peek my-list)
>   (bar (rest my-list) (dec n
> (bar [1 2 3] 1)
>
> Both rest and peek work on a vector without a problem but the combination
> of the two causes problems.
>
> On Thursday, June 20, 2013 3:54:43 PM UTC-4, Jason Gilman wrote:
>>
>> Why does (peek (seq [1])) result in:
>> ClassCastException clojure.lang.PersistentVector$**ChunkedSeq cannot be
>> cast to clojure.lang.IPersistentStack  clojure.lang.RT.peek (RT.java:634)
>>
>> Peek documentation "For a list or queue, same as first, for a vector,
>> same as, but much more efficient than, last. If the collection is empty,
>> returns nil." implies that there shouldn't be a problem working with
>> vectors.
>>
>> This works without issue:
>> (peek [1])
>>
>> This is on Clojure 1.5.1
>>
>  --
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
László Török

-- 
-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Why does peek on a seq of vector fail?

[David Nolen]

Calling seq on vector returns a sequence which is no longer a vector. The
docstring is pretty specific about which types it's supposed to work on.

clojure.core/peek
([coll])
  For a list or queue, same as first, for a vector, same as, but much
  more efficient than, last. If the collection is empty, returns nil.

David


On Thu, Jun 20, 2013 at 4:11 PM, Jason Gilman wrote:

> Also, I really appreciate anyone who takes the time to answer. My company
> is currently evaluating Clojure. I'm trying to determine if this is
> non-idiomatic use of the language or some other issue. Doing something like
> this can cause the bug to occur without directly calling seq on a vector:
>
> (defn bar [my-list n]
>   (if (= n 0)
>   (peek my-list)
>   (bar (rest my-list) (dec n
> (bar [1 2 3] 1)
>
> Both rest and peek work on a vector without a problem but the combination
> of the two causes problems.
>
> On Thursday, June 20, 2013 3:54:43 PM UTC-4, Jason Gilman wrote:
>>
>> Why does (peek (seq [1])) result in:
>> ClassCastException clojure.lang.PersistentVector$**ChunkedSeq cannot be
>> cast to clojure.lang.IPersistentStack  clojure.lang.RT.peek (RT.java:634)
>>
>> Peek documentation "For a list or queue, same as first, for a vector,
>> same as, but much more efficient than, last. If the collection is empty,
>> returns nil." implies that there shouldn't be a problem working with
>> vectors.
>>
>> This works without issue:
>> (peek [1])
>>
>> This is on Clojure 1.5.1
>>
>  --
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Why does peek on a seq of vector fail?

[Jason Gilman]

Also, I really appreciate anyone who takes the time to answer. My company 
is currently evaluating Clojure. I'm trying to determine if this is 
non-idiomatic use of the language or some other issue. Doing something like 
this can cause the bug to occur without directly calling seq on a vector:

(defn bar [my-list n]
  (if (= n 0)
  (peek my-list)
  (bar (rest my-list) (dec n
(bar [1 2 3] 1)

Both rest and peek work on a vector without a problem but the combination 
of the two causes problems.

On Thursday, June 20, 2013 3:54:43 PM UTC-4, Jason Gilman wrote:
>
> Why does (peek (seq [1])) result in: 
> ClassCastException clojure.lang.PersistentVector$ChunkedSeq cannot be cast 
> to clojure.lang.IPersistentStack  clojure.lang.RT.peek (RT.java:634)
>
> Peek documentation "For a list or queue, same as first, for a vector, same 
> as, but much more efficient than, last. If the collection is empty, returns 
> nil." implies that there shouldn't be a problem working with vectors.
>
> This works without issue:
> (peek [1]) 
>
> This is on Clojure 1.5.1
>

-- 
-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Why does peek on a seq of vector fail?

[Jason Gilman]

Why does (peek (seq [1])) result in: 
ClassCastException clojure.lang.PersistentVector$ChunkedSeq cannot be cast 
to clojure.lang.IPersistentStack  clojure.lang.RT.peek (RT.java:634)

Peek documentation "For a list or queue, same as first, for a vector, same 
as, but much more efficient than, last. If the collection is empty, returns 
nil." implies that there shouldn't be a problem working with vectors.

This works without issue:
(peek [1]) 

This is on Clojure 1.5.1

-- 
-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Project Euler problem in clojure

[Alan Malloy]

More importantly than any of these things, he is hanging onto the head of a 
very, very large sequence with (def lazytri (map triangle (range))). This 
will lead to serious memory pressure, and perhaps eventually a slowdown as 
this sequence takes up all the memory in his app and the GC strains to make 
a tiny bit of room for other temporary objects. Instead of defining it and 
then immediately using it, he should simply inline its definition into its 
use, so that the GC is able to free up the bits of it that are no longer in 
use.

On Thursday, June 20, 2013 7:23:43 AM UTC-7, Meikel Brandmeyer (kotarak) 
wrote:
>
> Hi,
>
> Am Donnerstag, 20. Juni 2013 15:19:40 UTC+2 schrieb John Holland:
>>
>> (defn triangle [n] (reduce + (range n))) 
>> (def lazytri (lazy-seq (map triangle (range 
>>
>>
> Some quick idea: here is a major difference in your clojure and your java 
> implementation. You always recompute the whole sum for each step. While you 
> only increase a counter in the java version. A better lazytri 
> implementation would be:
>
> (def lazytri (reductions + (range 1 Long/MAX_VALUE)))
>
> You don't use sqrt in your clojure version? inc is faster than (+ 1 ...). 
> zero? is faster than (= 0 ...).
>
> Kind regards
> Meikel
>
>

-- 
-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Heroku Clojure scheduled tasks versus worker threads

[Phil Hagelberg]

On Jun 18, 6:22 am, Jonathon McKitrick  wrote:
> So, the question then, is what would be the difference between a heroku
> scheduled command (which I currently am running, wakes up, does some work,
> etc) and a 'worker process' type?  Does the latter need a job queue set up?
>  Does it run constantly, checking that queue and consuming work items from
> it?

The reply from danneu is right; but more specifically you should set
up a worker process type if you've got enough work to keep a process
busy full-time or if you need a quicker turnaround time for the work
you're sending it. A scheduled process will be cheaper in terms of
time consumed, so if you're not currently bothered by its limitations
you should probably stick with it. Either a worker or a scheduled
process can use a queue to get its jobs, or it can get it from a DB if
the volume is low.

-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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Project Euler problem in clojure

[Meikel Brandmeyer (kotarak)]

Hi,

Am Donnerstag, 20. Juni 2013 15:19:40 UTC+2 schrieb John Holland:
>
> (defn triangle [n] (reduce + (range n))) 
> (def lazytri (lazy-seq (map triangle (range 
>
>
Some quick idea: here is a major difference in your clojure and your java 
implementation. You always recompute the whole sum for each step. While you 
only increase a counter in the java version. A better lazytri 
implementation would be:

(def lazytri (reductions + (range 1 Long/MAX_VALUE)))

You don't use sqrt in your clojure version? inc is faster than (+ 1 ...). 
zero? is faster than (= 0 ...).

Kind regards
Meikel

-- 
-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Namespace qualification of symbols

[Michał Marczyk]

On 20 June 2013 14:35, Phillip Lord  wrote:
> Oh yeah, how sneaky. In one case, you get a class, in the other, you get
> a symbol. Backtick is doing quite a bit more than letting you unquote
> and splice.

You get a symbol in both cases, though with a different name:

(import java.awt.image.BufferedImage)

(class `BufferedImage)
;= clojure.lang.Symbol

Cheers,
Michał


>
> Colin Fleming  writes:
>> Thank you for this, you just fixed a bug for me :-)
>>
>> I was trying to do some tricky type hinting with definline using amolloy's
>> great answer  on StackOverflow. Notice
>> that he uses `BufferedImage and not 'BufferedImage. I stupidly figured that
>> this was just a typo due to force of habit or similar and switched to using
>> quote, and discovered that I had problems when BufferedImage wasn't
>> imported when the inlined version of the function was called. Turns out
>> that ` expands an imported class name to the fully qualified name, whereas
>> ' does not.
>>
>> (import java.awt.image.BufferedImage)
>> => #=java.awt.image.BufferedImage
>> `BufferedImage
>> => java.awt.image.BufferedImage
>> 'BufferedImage
>> => BufferedImage
>>
>> Mea culpa. I'm not sure I would ever have made this connection, very timely
>> - thank you.
>>
>> Cheers,
>> Colin
>>
>>
>> On 19 June 2013 20:46, Phillip Lord  wrote:
>>
>>>
>>>
>>>
>>> So, I was thinking that ' and ` were basically the same, unless a ~ was
>>> involved somewhere. But I have discovered this.
>>>
>>>
>>>
>>> (ns john)
>>>
>>> (println '(paul))
>>> (println `(paul))
>>>
>>>
>>> ;;=>
>>> (paul)
>>> (john/paul)
>>>
>>> With the ' paul is not namespace qualified, while with the ` paul is.
>>>
>>>
>>> Turns out to be a bit of a pain, actually, although I have worked around
>>> it. But mostly I am surprised. Is this expected?
>>>
>>> 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
>>> ---
>>> You received this message because you are subscribed to the Google Groups
>>> "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>
>> --
>
> --
> Phillip Lord,   Phone: +44 (0) 191 222 7827
> Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
> School of Computing Science,
> http://homepages.cs.ncl.ac.uk/phillip.lord
> Room 914 Claremont Tower,   skype: russet_apples
> Newcastle University,   twitter: phillord
> NE1 7RU
>
> --
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 
-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Project Euler problem in clojure

[John Holland]

OK, with a coding improvement 


(defn factors-sqrt [n]
(filter #(= 0 (mod n %)) (range 1 (+ 1 (Math/sqrt n )

(defn num-of-factors [n] (* 2 (count (factors-sqrt n

it works for 499. (Idea being factors come in pairs, each factor >
sqrt(x) corresponds to one > sqrt(x))


Was it just running infinitely slow in Clojure relative to Java before??

John


pgpNcI629uGa4.pgp
Description: PGP signature

Project Euler problem in clojure

[John Holland]

I'm working on problems at projecteuler.net in Clojure. 

There is a particular problem that my code doesn't seem to work for. The
problem is: 


==
The sequence of triangle numbers is generated by adding the natural
numbers. So the 7th triangle number would be 1 + 2 + 3 + 4 + 5 + 6 + 7 =
28. The first ten terms would be:

1, 3, 6, 10, 15, 21, 28, 36, 45, 55, ...

Let us list the factors of the first seven triangle numbers:

 1: 1
 3: 1,3
 6: 1,2,3,6
10: 1,2,5,10
15: 1,3,5,15
21: 1,3,7,21
28: 1,2,4,7,14,28

We can see that 28 is the first triangle number to have over five
divisors.

What is the value of the first triangle number to have over five hundred
divisors?


I've written the following clojure code to solve it:



(defn triangle [n] (reduce + (range n)))

(defn factors [n] (conj 
(filter #(= 0 (mod n %)) (range 1 (+ 1 (/ n 2n ))

(defn num-of-factors [n] (count (factors n)))


(def lazytri (lazy-seq (map triangle (range

(take 1 (filter #(> (num-of-factors %) 499) lazytri))


with the cutoff of 499, this runs forever as far as I can tell. In fact
it will work up to 100, but not at 200.

The following Java code quickly returns the same answer as the clojure
code for the same cutoffs, and quickly returns the correct answer for
the 499 cutoff. 

Why doesn't my clojure code return for these larger values?

=

public class Triangles {

public static void main(String[] args){
int number = 0;
int i = 1;
 
while(numberOfDivisors(number) < 500){
number += i;
i++;
System.out.println(number);
}
}
private static int numberOfDivisors(int number){
int nod = 0;
int sqrt = (int) Math.sqrt(number);
 
for(int i = 1; i<= sqrt; i++){
if(number % i == 0){
nod += 2;
}
}
//Correction if the number is a perfect square
if (sqrt * sqrt == number) {
nod--;
}
 
return nod;

}

}


pgpMGf0mZMO_F.pgp
Description: PGP signature

Re: Namespace qualification of symbols

[Ambrose Bonnaire-Sergeant]

On Thu, Jun 20, 2013 at 8:50 PM, Phillip Lord
wrote:

> Thanks for the explanation. I was confused.


Cheers, glad it helped.

Ambrose

-- 
-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Namespace qualification of symbols

[Phillip Lord]

"Jim - FooBar();"  writes:
> On 20/06/13 08:49, Phillip Lord wrote:
>> Well, that doesn't answer the question. The backtick is useful in
>> writing macros (although the situation this caused me grief, actually, I
>> wasn't). So is quote. But then I do not understand why the behaviour is
>> different between the two.
>
> However, whenever you do `(map ~f ~coll) what you really mean is
> (clojure.core/map some-fn some-coll) and that is exactly what the
> macro will expand to.

In my case, when I really meant was "(map somefn somecoll)" hence the
confusion. 


> If you swap ` for ' then what you get is a list with a bunch of
> non-qualified symbols in. Not very useful is it?


It does depend on what you are doing. I was generating data that could
be evaluated as code at some point.


> Ambrose went a bit further and explained local-name capturing & gensym. Even
> though automatic namespace qualification helps with that, it seems to be that
> this is not the primary reason for it. Being able to generate code dynamically
> without having to qualify every single symbol sounds more important to
> me...


You can do this either way. 

(defmacro remap3 [f & c]
  `(map ~f ~@c))

(defmacro remap4 [f & c]
  (list* 'map f c))

I haven't qualified map in either case, both still work. But, as Ambrose
explanation shows, the former definition is better, because in the
former it is clearer what environment the qualitification takes place.

> hope this is clearer now...

It is! Both the reasoning behind the problem and how to avoid it was
causing me grief.

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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Namespace qualification of symbols

[Phillip Lord]

Oh yeah, how sneaky. In one case, you get a class, in the other, you get
a symbol. Backtick is doing quite a bit more than letting you unquote
and splice.

Colin Fleming  writes:
> Thank you for this, you just fixed a bug for me :-)
>
> I was trying to do some tricky type hinting with definline using amolloy's
> great answer  on StackOverflow. Notice
> that he uses `BufferedImage and not 'BufferedImage. I stupidly figured that
> this was just a typo due to force of habit or similar and switched to using
> quote, and discovered that I had problems when BufferedImage wasn't
> imported when the inlined version of the function was called. Turns out
> that ` expands an imported class name to the fully qualified name, whereas
> ' does not.
>
> (import java.awt.image.BufferedImage)
> => #=java.awt.image.BufferedImage
> `BufferedImage
> => java.awt.image.BufferedImage
> 'BufferedImage
> => BufferedImage
>
> Mea culpa. I'm not sure I would ever have made this connection, very timely
> - thank you.
>
> Cheers,
> Colin
>
>
> On 19 June 2013 20:46, Phillip Lord  wrote:
>
>>
>>
>>
>> So, I was thinking that ' and ` were basically the same, unless a ~ was
>> involved somewhere. But I have discovered this.
>>
>>
>>
>> (ns john)
>>
>> (println '(paul))
>> (println `(paul))
>>
>>
>> ;;=>
>> (paul)
>> (john/paul)
>>
>> With the ' paul is not namespace qualified, while with the ` paul is.
>>
>>
>> Turns out to be a bit of a pain, actually, although I have worked around
>> it. But mostly I am surprised. Is this expected?
>>
>> 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
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
> -- 

-- 
Phillip Lord,   Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Namespace qualification of symbols

[Phillip Lord]

Ambrose Bonnaire-Sergeant  writes:
> It's a good question.
>
> Syntax quote is designed for generating code/syntax that is deterministic
> and avoids accidental local name capture.
>
> 1. Automatic namespace qualification helps avoid accidental local name
> capture in macros.
>
> user=> `(let [a# 1
>   b# a]
>   a#)
> (clojure.core/let [a__48963__auto__ 1
>b__48964__auto__ user/a]
>a__48963__auto__)
>
> The binding for b# shows a common mistake. By namespace qualifying "a" to
> "user/a",
> we don't allow the possibility of accidentally capturing locals.
>
> eg. "a" is not captured in the body
> (let [a 'evil]
>   (clojure.core/let [a__48963__auto__ 1
>  b__48964__auto__ user/a]
>  a__48963__auto__))
>


Ah, yes, this makes sense. So, rewriting the macro without the backtick
looks exactly the same, but can capture locals.

(defmacro remap3 [f & c]
  `(map ~f ~@c))

(defmacro remap4 [f & c]
  (list* 'map f c))

(let [map (fn [f & c]
(println "evil")
(apply f c))]
  (remap3 identity (range 1 10)))

(let [map (fn [f & c]
(println "evil")
(apply f c))]
  (remap4 identity (range 1 10)))


Only the latter is evil.


> 2. Automatic namespace qualification helps make code deterministic with
> respect to the namespace of the consumer of a macro.
>
> Syntax quote resolves vars in the namespace the *macro* is defined in.
> This avoids odd situations where different vars are invoked depending
> on which namespace we use the macro.


Yeah, this was what was confusing me, and was breaking my code. I was
using it to generate code, but not in a macro; my code generates a set
of (specific) Java objects from clojure, and I wanted to be able to
reverse the process -- render clojure forms from Java objects; this
was failing because the symbols were always being qualified in the
namespace of the renderer. In essence, I'm using ` for it's syntactic
convienience, rather than in a macro.


> Bottom line: syntax quote is designed for macros by default. All the good
> properties of syntax quote can be avoided using
> combinations of quote, syntax quote and splice.
>
> eg. `~'a
> ;=> a


I have converted my code to use this! 

Thanks for the explanation. I was confused.

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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Problem filtering with definline'd function

[Colin Fleming]

ClSymbol is a Java class. I don't get the replacement warning because I've
excluded that symbol explicitly in my ns declaration using :refer-clojure
:exclude.

I haven't done a 'lein clean' because I'm not using lein, but I have
rebuilt various times. However, sometimes it will work and sometimes it
won't. I just tried this now, and I've been unable to reproduce. I guess
I'll keep working tomorrow and see if it crops up again. If I see it again
I'm going to try ((var-get #'symbol?) 2) to see if the results from the
function differ from the macroexpanded version.




On 20 June 2013 22:21, Jim - FooBar();  wrote:

> On 20/06/13 10:59, Colin Fleming wrote:
>
>> Because this tests for something different - that the element is an
>> instance of ClSymbol. It's not testing the same thing as the core version.
>> I qualify it (psi/symbol? in the examples above) to distinguish it from the
>> core one.
>>
>> Basically, I'm trying to use definline to allow me to have a more
>> Clojure-y API without having the performance hit of tons of tiny function
>> calls.
>>
>> I agree that this is unlikely to be a bug in Clojure and is probably
>> something I'm missing, but I can't figure it out.
>>
>
> right I see...so if ClSymbol is a defrecord/deftype I don't see anything
> wrong with your code...when you do (in-ns 'plugin.psi) do you get a warning
> that core/symbol? is being replaced by psi/symbol?  ?
>
> what you tried on your repl works fine on mine:
>
> user=> (defrecord FOO [a])
> user.FOO
>
> user=> (definline foo? [e]
>   #_=>   `(instance? FOO ~e))
> #'user/foo?
>
> user=> (foo? 2)
> false
>
> user=> (filter foo? [1 2 3])
> ()
>
> user=> (filter foo? [(FOO. 1) 2 3])
> (#user.FOO{:a 1})
>
> Did you try 'lein clean' to get rid of already compiled classes? I'm
> suspecting you have different versions of the same class lying around
> because of what you said about compiling and recompiling...
>
> 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+unsubscribe@**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 unsubscribe from this group and stop receiving emails from it, send an
> email to 
> clojure+unsubscribe@**googlegroups.com
> .
> For more options, visit 
> https://groups.google.com/**groups/opt_out
> .
>
>
>

-- 
-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Namespace qualification of symbols

[Jim - FooBar();]

On 20/06/13 08:49, Phillip Lord wrote:

Well, that doesn't answer the question. The backtick is useful in
writing macros (although the situation this caused me grief, actually, I
wasn't). So is quote. But then I do not understand why the behaviour is
different between the two.


I thought the question was whether this is expected or not that's why I 
answered accordingly...What I wanted to get across is that ` is critical 
for generating code (macro-writing) whereas ' has nothing to do with 
macros really. It's just a way of saying 'skip evaluation of this symbol 
- just pass it along'. However, whenever you do `(map ~f ~coll) what you 
really mean is (clojure.core/map some-fn some-coll) and that is exactly 
what the macro will expand to. Say, you had overwritten 'core.map' with 
your own version in that namespace...then the macro would expand to  
(some-namespace/map some-fn some-coll) . If you swap ` for ' then what 
you get is a list with a bunch of non-qualified symbols in. Not very 
useful is it?


Ambrose went a bit further and explained local-name capturing & gensym. 
Even though automatic namespace qualification helps with that, it seems 
to be that this is not the primary reason for it. Being able to generate 
code dynamically without having to qualify every single symbol sounds 
more important to me...after all, avoiding local name capturing can be 
considered the programmer's responsibility...ok, the language helps with 
gensym etc but it should always be in the back of your head when writing 
macros. Even with gensym and syntax-quote there is still a way to 
achieve name capturing and I think 'the joy of Clojure' demonstrates an 
'arguably useful'  example of this...


to sum up the behaviour is different because ` & ' are used to achieve 
different tasks. It often helps me to think of ` as resolving the symbol 
whereas ' doesn't do anything to it.


hope this is clearer now...

this is nice video http://www.infoq.com/presentations/Clojure-Macros 
that explains the compilation process of Clojure and how macros make it 
harder to grasp.


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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Problem filtering with definline'd function

[Jim - FooBar();]

On 20/06/13 10:59, Colin Fleming wrote:
Because this tests for something different - that the element is an 
instance of ClSymbol. It's not testing the same thing as the core 
version. I qualify it (psi/symbol? in the examples above) to 
distinguish it from the core one.


Basically, I'm trying to use definline to allow me to have a more 
Clojure-y API without having the performance hit of tons of tiny 
function calls.


I agree that this is unlikely to be a bug in Clojure and is probably 
something I'm missing, but I can't figure it out.


right I see...so if ClSymbol is a defrecord/deftype I don't see anything 
wrong with your code...when you do (in-ns 'plugin.psi) do you get a 
warning that core/symbol? is being replaced by psi/symbol?  ?


what you tried on your repl works fine on mine:

user=> (defrecord FOO [a])
user.FOO

user=> (definline foo? [e]
  #_=>   `(instance? FOO ~e))
#'user/foo?

user=> (foo? 2)
false

user=> (filter foo? [1 2 3])
()

user=> (filter foo? [(FOO. 1) 2 3])
(#user.FOO{:a 1})

Did you try 'lein clean' to get rid of already compiled classes? I'm 
suspecting you have different versions of the same class lying around 
because of what you said about compiling and recompiling...


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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Problem filtering with definline'd function

[Colin Fleming]

Because this tests for something different - that the element is an
instance of ClSymbol. It's not testing the same thing as the core version.
I qualify it (psi/symbol? in the examples above) to distinguish it from the
core one.

Basically, I'm trying to use definline to allow me to have a more Clojure-y
API without having the performance hit of tons of tiny function calls.

I agree that this is unlikely to be a bug in Clojure and is probably
something I'm missing, but I can't figure it out.

Cheers,
Colin


On 20 June 2013 21:47, Jim - FooBar();  wrote:

>  There is already a symbol? predicate in core. Why are you defining your
> own? Does your problem disappear when you use the one from core?
> What exactly are you trying to do? I use definline quite frequently and
> have never encountered such problems...
>
> Jim
>
>
>
> On 20/06/13 10:35, Colin Fleming wrote:
>
> Hi all,
>
>  I'm having a problem where a definline'd function is not working when
> used as a predicate for filtering. It seems to work sporadically -
> occasionally it works, occasionally it doesn't. I'm thinking it's probably
> a compile problem since it seems to work or not work consistently for each
> compile (i.e. if it's not working and I recompile, it may work).
>
>  The predicate looks like this:
>
>  (definline symbol? [element]
>   `(instance? ClSymbol ~element))
>
>  I'm using it like this:
>
>  (defn all-symbols [coll]
>   (filter psi/symbol? (psi/children coll)))
>
>  And calling all-symbols like this:
>
>  (map (fn [sym]
>(if-let [target (symbols (name sym))]
>  [sym target]))
>  (all-symbols exclude))
>
>  I then get an exception that one of the elements in the collection
> doesn't implement Named, which ClSymbol does.
>
>  I also tested this in the repl:
>
>  Clojure 1.5.1
> (in-ns 'plugin.psi)
> => plugin.psi
> (symbol? 2)
>  => false
> (filter symbol? [1 2 3])
> => (1 2 3)
>
>  Am I missing something obvious here?
>
>  Thanks,
> Colin
>--
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>  --
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Problem filtering with definline'd function

[Jim - FooBar();]

There is already a symbol? predicate in core. Why are you defining your 
own? Does your problem disappear when you use the one from core?
What exactly are you trying to do? I use definline quite frequently and 
have never encountered such problems...


Jim


On 20/06/13 10:35, Colin Fleming wrote:

Hi all,

I'm having a problem where a definline'd function is not working when 
used as a predicate for filtering. It seems to work sporadically - 
occasionally it works, occasionally it doesn't. I'm thinking it's 
probably a compile problem since it seems to work or not work 
consistently for each compile (i.e. if it's not working and I 
recompile, it may work).


The predicate looks like this:

(definline symbol? [element]
  `(instance? ClSymbol ~element))

I'm using it like this:

(defn all-symbols [coll]
  (filter psi/symbol? (psi/children coll)))

And calling all-symbols like this:

(map (fn [sym]
   (if-let [target (symbols (name sym))]
 [sym target]))
 (all-symbols exclude))

I then get an exception that one of the elements in the collection 
doesn't implement Named, which ClSymbol does.


I also tested this in the repl:

Clojure 1.5.1
(in-ns 'plugin.psi)
=> plugin.psi
(symbol? 2)
=> false
(filter symbol? [1 2 3])
=> (1 2 3)

Am I missing something obvious here?

Thanks,
Colin
--
--
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 unsubscribe from this group and stop receiving emails from it, send 
an email to clojure+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.




--
--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Problem filtering with definline'd function

[Colin Fleming]

Hi all,

I'm having a problem where a definline'd function is not working when used
as a predicate for filtering. It seems to work sporadically - occasionally
it works, occasionally it doesn't. I'm thinking it's probably a compile
problem since it seems to work or not work consistently for each compile
(i.e. if it's not working and I recompile, it may work).

The predicate looks like this:

(definline symbol? [element]
  `(instance? ClSymbol ~element))

I'm using it like this:

(defn all-symbols [coll]
  (filter psi/symbol? (psi/children coll)))

And calling all-symbols like this:

(map (fn [sym]
   (if-let [target (symbols (name sym))]
 [sym target]))
 (all-symbols exclude))

I then get an exception that one of the elements in the collection doesn't
implement Named, which ClSymbol does.

I also tested this in the repl:

Clojure 1.5.1
(in-ns 'plugin.psi)
=> plugin.psi
(symbol? 2)
=> false
(filter symbol? [1 2 3])
=> (1 2 3)

Am I missing something obvious here?

Thanks,
Colin

-- 
-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Namespace qualification of symbols

[Ambrose Bonnaire-Sergeant]

Hi Phil,

It's a good question.

Syntax quote is designed for generating code/syntax that is deterministic
and avoids accidental local name capture.

1. Automatic namespace qualification helps avoid accidental local name
capture in macros.

user=> `(let [a# 1
  b# a]
  a#)
(clojure.core/let [a__48963__auto__ 1
   b__48964__auto__ user/a]
   a__48963__auto__)

The binding for b# shows a common mistake. By namespace qualifying "a" to
"user/a",
we don't allow the possibility of accidentally capturing locals.

eg. "a" is not captured in the body
(let [a 'evil]
  (clojure.core/let [a__48963__auto__ 1
 b__48964__auto__ user/a]
 a__48963__auto__))

2. Automatic namespace qualification helps make code deterministic with
respect to the namespace
of the consumer of a macro.

Syntax quote resolves vars in the namespace the *macro* is defined in. This
avoids odd situations where
different vars are invoked depending on which namespace we use the macro.


Bottom line: syntax quote is designed for macros by default. All the good
properties of syntax quote can be avoided using
combinations of quote, syntax quote and splice.

eg. `~'a
;=> a

Thanks,
Ambrose

On Thu, Jun 20, 2013 at 3:49 PM, Phillip Lord
wrote:

> Jim  writes:
> > On 19/06/13 09:46, Phillip Lord wrote:
> >> With the ' paul is not namespace qualified, while with the ` paul is.
> >>
> >>
> >> Turns out to be a bit of a pain, actually, although I have worked around
> >> it. But mostly I am surprised. Is this expected?
> >
> > Yes, this is very much expected! :)
> >
> > How else would you be able to write macros without ` ?
>
> Well, that doesn't answer the question. The backtick is useful in
> writing macros (although the situation this caused me grief, actually, I
> wasn't). So is quote. But then I do not understand why the behaviour is
> different between the two.
>
> > Vars needs to resolve to something eventually...
>
> There are no vars involved here. `paul expands to a namespace qualified
> symbol irrespective of the existence of a var.
>
> 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
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Namespace qualification of symbols

[Phillip Lord]

Jim  writes:
> On 19/06/13 09:46, Phillip Lord wrote:
>> With the ' paul is not namespace qualified, while with the ` paul is.
>>
>>
>> Turns out to be a bit of a pain, actually, although I have worked around
>> it. But mostly I am surprised. Is this expected?
>
> Yes, this is very much expected! :)
>
> How else would you be able to write macros without ` ?

Well, that doesn't answer the question. The backtick is useful in
writing macros (although the situation this caused me grief, actually, I
wasn't). So is quote. But then I do not understand why the behaviour is
different between the two.

> Vars needs to resolve to something eventually...

There are no vars involved here. `paul expands to a namespace qualified
symbol irrespective of the existence of a var.

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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Clojure generates unnecessary and slow type-checks

[Jason Wolfe]

On Saturday, June 15, 2013 4:37:06 AM UTC-7, Mikera wrote:
>
> On Friday, 14 June 2013 18:15:34 UTC+1, Jason Wolfe wrote:
>
>> Hey Mikera, 
>>
>> I did look at core.matrix awhile ago, but I'll take another look. 
>>
>> Right now, flop is just trying to make it easy to write *arbitrary* 
>> array operations compactly, while minimizing  the chance of getting 
>> worse-than-Java performance.  This used to be very tricky to get right 
>> when flop was developed (against Clojure 1.2); the situation has 
>> clearly improved since then, but there still seem to be some 
>> subtleties in going fast with arrays in 1.5.1 that we are trying to 
>> understand and then automate. 
>>
>> As I understand it, core.matrix has a much more ambitious goal of 
>> abstracting over all matrix types.  This is a great goal, but I'm not 
>> sure if the protocol-based implementation can give users any help 
>> writing new core operations efficiently (say, making a new array with 
>> c[i] = a[i] + b[i]^2 / 2) -- unless there's some clever way of 
>> combining protocols with macros (hmmm). 
>>
>
> A longer term objective for core.matrix could be to allow compiling such 
> expressions. Our GSoC student Maik Schünemann is exploring how to represent 
> and optimised mathematical expressions in Clojure, and in theory these 
> could be used to compile down to efficient low-level operations. API could 
> look something like this:
>
> ;; define an expression
> (def my-expression (expression [a b] (+ a (/ (* b b) 2
>
> ;; compile the expression for the specified matrix implementation A
> (def func (compile-expression A my-expression)). 
>
> ;; now computation can be run using the pre-compiled, optimised function
> (func A B)
>
> In the case that A is a Java double array, then perhaps the flop macros 
> could be the engine behind generating the compiled function?
>
>  
>
>> I just benchmarked core.matrix/esum, and on my machine in Clojure 
>> 1.5.1 it's 2.69x slower than the Java version above, and 1.62x slower 
>> than our current best Clojure version.
>>
>
> Great - happy to steal your implementation :-) 
>
> Other core.matrix implementations are probably faster BTW: vectorz-clj is 
> pure Java and has esum for the general-purpose Vector type implemented in 
> exactly the same way as your fast Java example. Clatrix executes a lot of 
> operations via native code using BLAS.
>

I should follow up on this and clarify that core.matrix's esum is in fact 
as fast as Java -- I apologize for the false statement (I was unaware that 
new versions of leiningen disable advanced JIT optimizations by default, 
which lead to the numbers I reported).

Nevertheless, I hope there may be room for interesting collaboration on 
more complex operations, or code gen as you mentioned.  I'll follow up 
later when we're a bit further along.
 

>
>  
>
>> A collaboration sounds interesting -- although right now it seems like 
>> our goals are somewhat orthogonal.  What do you think? 
>>
>
> Seems like the goals are relatively complementary. I think the areas of 
> potential collaboration are of three kinds:
> 1) Leveraging flop to get the fastest possible implementations for 
> core.matrix
> 2) Using core.matrix to provide higher-level abstractions / operations on 
> top of basic arrays
> 3) Sharing tools / standards / approaches where it makes sense
>
> Clearly a significant area of overlap is that we both want the fastest 
> possible operations on double arrays. I'd be delighted if we could leverage 
> flop to get the best possible implementations for core.matrix. 
>
> Another potential area of collaboration is the planned NDArray 
> implementation. This will be a pure Clojure, NumPy-style, efficient 
> N-dimensional array implementation. Under the hood, this will need to run 
> on Java arrays. Dmitry Groshev is our GSoC student who will be working on 
> this.
>
>
>

-- 
-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: try* macro to catch multiple exception classes with one body. feedback is needed.

[Max Gonzih]

I updated my macro to your solution, looks really simple and works like 
before. I don't know why I overcomplicated my original solution so much :).

Thanks again!

On Thursday, June 20, 2013 8:47:37 AM UTC+3, Meikel Brandmeyer (kotarak) 
wrote:
>
> Hi,
>
> Am Mittwoch, 19. Juni 2013 17:00:17 UTC+2 schrieb Max Gonzih:
>>
>> Hi, I implemented small macro to catch multiple exception classes with 
>> one body.
>>
>> https://gist.github.com/Gonzih/5814945
>>
>> What do you think? Are there better ways to achieve similar results?
>>
>>
> I would just extend try a simply as possible: simply add the catch-all, 
> but keep catch and finally as is. Here my try:
>
> (defmacro try*
>   [& body]
>   (let [catch-all?   #(and (seq? %) (= (first %) 'catch-all))
> expand-catch (fn [[_catch-all exceptions & catch-tail]]
>(map #(list* 'catch % catch-tail) exceptions))
> transform(fn [form]
>(if (catch-all? form)
>  (expand-catch form)
>  [form]))]
> (cons `try (mapcat transform body
>
> (try*
>   (println :a)
>   (println :b)
>   (catch-all [A B C] e (println (type e)))
>   (catch D _ (println "Got D!"))
>   (finally (println "Finally!")))
>
> expands to
>
> (try
>   (println :a)
>   (println :b)
>   (catch A e (println (type e)))
>   (catch B e (println (type e)))
>   (catch C e (println (type e)))
>   (catch D _ (println "Got D!"))
>   (finally (println "Finally!")))
>
> Kind regards
> Meikel
>

-- 
-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.