Re: Proposing a new Clojure documentation system (in Clojure)
On Tue, May 6, 2014, at 07:54 PM, Timothy Baldridge wrote: Clojure is being reworked into literate form already Proof of this claim? I think Tim referred to his personal project to convert Clojure code into a literate form: [1]https://groups.google.com/forum/#!topic/clojure/RgQX_kXzFMM References 1. https://groups.google.com/forum/#!topic/clojure/RgQX_kXzFMM -- 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/d/optout.
Re: core.async and Joy of Clojure
Hey Timothy, I just finished working through the code from your talk and have a question. In the code there is this code: (go (loop [] (when-let [v (! print-chan)] (println v) (recur I wanted to expand it into something like a logger that writes out to a file though, so I made the relevant test.txt file, stuck it in resources and changed the code to look like this: (use 'clojure.java.io) (use 'clojure.core.async) (def print-chan (chan)) (go (loop [] (when-let [v (! print-chan)] (with-open [wrtr (writer resources/test.txt :append true)] (.write wrtr v)) (recur (!! print-chan 42) But when I do this, I find that it will only replace what is in the file, and not append to it. Sometimes also, the output that ends up in the file is a little odd, too. I tried to put 42 and I got * instead. When I use the writer without the core.async functions, it works as expected. I am using light table. Jesse -- 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/d/optout.
Clojure Java 8 Compact Profiles
Hello, I mostly only lurk here, but I recently was running a small experiment with Java 8 Compact Profiles (essentially, restricted versions of the JRE designed for serverside deployments that only ship a subset of rt.jar) and thought it might be of interest. Clojure appears to depend on the full JRE, but this seems to be due to only a few packages. From my initial investigations, it seems that it wouldn't be too hard to persuade the main parts of Clojure (basically, everything which doesn't do Swing/GUI stuff) to only need compact1 (the most restrictive profile) instead. The benefits would be reduced disk footprint, better security and possible startup time and memory footprint improvements for the majority of Clojure users, at a cost of needing to subdivide the clojure jars. Is this something that the community would be interested in investigating, and if so, are there people who have cycles to contribute? Or has someone tried this already? Thanks, Ben -- 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/d/optout.
Re: Proposing a new Clojure documentation system (in Clojure)
Sean Corfield s...@corfield.org writes:
On May 6, 2014, at 8:11 AM, Phillip Lord phillip.l...@newcastle.ac.uk wrote:
I've used this example before; consider this unstructured string from
`cons`.
Returns a new seq where x is the first element and seq is
the rest.
Just because one (or several) of the clojure.core function docstrings are
poorly written, doesn't mean Clojure's current documentation system is broken.
This simply comes back to developers needing to write _better_ documentation,
not _more_ documentation.
Indeed, and the need for some standards comes from this. Let's rewrite
the cons docstring so my (perverse) interpretation cannot hold.
Returns a new seq where the value of the parameter x is the first
element and the value of the parameter seq is the rest.
Now, this is more correct, but hard to read.
This is why we need (at least) some standard markup in doc strings. The
Emacs style
Returns a new seq where X is the first element and SEQ is the rest.
Better, I think would be:
Returns a new seq where X is the first element and SEQ is the rest.
See also: seq, seq?, first, rest
And then add
Returns a new seq where X is the first element and SEQ is the rest.
See also: `seq', `seq?', `first', `rest'
http://clojure.org/sequences
These are small changes, no revolutionary ones. Literate programming or
otherwise is an interesting discussion, but at least getting up to the
level of Emacs (a 20 year old lisp!) would be good.
If you think I am wrong, then show me *any* book on programming that
uses no typography to distinguish semantically different parts of the
document.
Adding complexity and weaving heapings of prose in amongst the code isn't
going to make the developer that wrote the above rewrite it in a better way.
You'll just end up with more bad documentation getting in the way of what the
code actually does. Bad documentation is worse than no documentation. At least
with no documentation, the code doesn't lie.
The use the source, Luke argument is a good one in some cases.
In this case, though, this is the source.
(def
^{:arglists '([x seq])
:doc Returns a new seq where x is the first element and seq is
the rest.
:added 1.0
:static true}
cons (fn* ^:static cons [x seq] (. clojure.lang.RT (cons x seq
So, not that helpful. You can, of course, look up RT.java if you know
the . notation (which you might not, because it's not meant for normal
use).
which brings you to this...
static public ISeq cons(Object x, Object coll){
//ISeq y = seq(coll);
if(coll == null)
return new PersistentList(x);
else if(coll instanceof ISeq)
return new Cons(x, (ISeq) coll);
else
return new Cons(x, seq(coll));
}
which is not documented at all and which is defined to be an
implementation detail.
So, no the code doesn't lie, but it doesn't necessarily tell you much
either.
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/d/optout.
Re: Proposing a new Clojure documentation system (in Clojure)
Tim Daly d...@axiom-developer.org writes: - include diagrams and pictures It is easy to show the red-black tree rebalance algorithm with a few pictures whereas the words are rather opaque. Stacks and immutable copy algorithms are also easy in diagrams. You CAN do this with ascii-art but it IS the late 90s and some lucky few of us have 640x480 color terminals. Yes, I agree with this, images would be nice. 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/d/optout.
Re: Immutable or Effectively Immutable?
Since the data structures and interfaces, they are effectively
immutable.
Consider this:
final public class Cons extends ASeq implements Serializable {
private final Object _first;
private final ISeq _more;
public Cons(Object first, ISeq _more){
this._first = first;
this._more = _more;
}
}
Although Cons uses final fields and constructor fields, _more is an
ISeq; given that this could be mutable, so could cons.
Phil
Mike Fikes mikefi...@me.com writes:
Are the persistent immutable data structures in Clojure truly immutable
(using final fields, relying on constructor freezing), or are they mean to
be merely effectively immutable (as defined in JICP)?
--
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/d/optout.
Re: Proposing a new Clojure documentation system (in Clojure)
Gregg Reynolds d...@mobileink.com writes:
On Tue, May 6, 2014 at 10:11 AM, Phillip Lord
phillip.l...@newcastle.ac.ukwrote:
True, and, to some extent, it inherits the ; vs ;; comment
distinction. But, again, there is not structure. This is an unstructured
string also. Compare Emacs Lisp, for example, which uses semi-structure
in the comments to drive many of its features.
I'm ok with some kind of structure for comments and docstrings, but I would
relegate it to an add-on, not part of the Clojure language definition.
We're effectively talking about adding a second syntax. The original
poster (Val?) suggested using Clojure syntax for the documentation
language, but I'm not so sure about that yet; haven't thought about it
enough.
What we need and how we get it are two different things of course.
Should the documentation be in the language definition? Well, the
language needs to *support* it.
In Java, we have /** */ to support javadoc.
In terms of clojure documentation, we can already use clojure syntax for
the documentation. For instance:
(defn ^{:doc (str hello [] list)}
testfn [])
Of course, this loses all structure once the form is evaled, but you can
see what I mean. If we allow
(defn ^{doc (fn [] (str documentation))} testfn[])
then we have a whole new ball game. The documentation can do what ever
we want, including for example lazy loading of documentation that is
complex and which would otherwise slow loading.
I've used this example before; consider this unstructured string from
`cons`.
Returns a new seq where x is the first element and seq is
the rest.
So, cons returns a seq where x is the first element, and seq is the
rest? Which means that cons returns the same (constantly x) for which
(rest (constantly x)) could be said to equal (constantly x), as a
infinite string of x's is the same as an infinite string of x's one
shorter.
I would call that an example of sloppy documentation since it uses seq as
both a type name and a data name. Support for structured strings can't
prevent that.
Here is the documentation from Emacs.
(cons CAR CDR)
Create a new cons, give it CAR and CDR as components, and return it.
It's got it's problems but being unable to distinguish between CAR the
function and CAR the parameter is not one of them.
seq xs - x::xs ;; by convention, 'xs' means 'collection of somethings'
and 'x::xs' means sequence of somethings
seq nil - nil
I guess the point is that good, clear, concise, well-defined conventions
can solve a lot of problems before we even get to the issue of supporting
structured doc text.
I think all of this is good. You'll notice that the Emacs solution uses
a typographical convention -- very thin structuring.
I was never a great fan of writing XML by hand, to be honest (which is
what this appears to be). The first example that I looked at:
https://github.com/mobileink/leiningen-doc/blob/master/ug/classpath.dita
incidentally, appears to be ill-formed, having two /concept tags.
I only see one. Anyway, the processor didn't object.
Oops. conbody and concept.
XML is hard to write.
YMMV; I find it easy to write. To me, XML is no different than any other
language: if you work with it enough, it becomes second nature. I use
emacs + nxml + yasnippet and would not dream of editing xml in any other
way. Then again I do a lot of xml editing, and I'm happy as a clam with
nothing more than bash, emacs, and manpages, which makes me a throwback, I
suppose.
This is true, I guess, although I do find XML rather verbose; ironic,
given that you were complaining about structuring making things hard to
read earlier!
Documentation is about scalability; it only hits when you have a
reasonable amount of code (especially external libraries). It also hits
newcomers most.
So, perhaps, the time is now.
If not now, when? If not me, who? Answer: somebody else, I hope.
A noble sentiment! I can only agree.
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/d/optout.
Re: http-kit AsyncChannel and clojure.core.async.impl.channels.ManyToManyChannel
Sorry, but you guys didn't understand the problem.
*tbc++*, I don't use core.async, so I don't require it
dgrnbrg, I don't want to interface these libraries together.
Let me try explain again.
1. I have http-kit socket server running
2. When client connects I store its connection (http-kit's AsyncChannel) in
map @clients as a key, line 19 (swap! clients assoc con true)
3. Then when some data received from client line 21-22
(on-receive con (fn [data]
(handler)))
I invoke handler
(defn handler []
(future (let
[merged (merge {} @clients)]
(println merged)) ; = #ManyToManyChannel
clojure.core.async.impl.channels.ManyToManyChannel@5d9c832a, but expect to get
copy of @clients
#_(let
[into-map (into {} @clients)] ; here I get exception
IllegalArgumentException java.lang.IllegalArgumentException: No implementation
of method: :take! of protocol: #'clojure.core.async.impl.protocols/ReadPort
found for class: nil
(println into-map
Here I want just to make the copy of @clients with simple merge to empty map,
but I don't get a copied map, I get #ManyToManyChannel
clojure.core.async.impl.channels.ManyToManyChannel@5d9c832a
When trying use into I get I get exception.
I just want to know what is going on, why I get ManyToManyChannel instead of
@clients map copy?
--
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/d/optout.
Re: http-kit AsyncChannel and clojure.core.async.impl.channels.ManyToManyChannel
core.async provides its own implementation of merge that returns a
ManyToMany channel. So that's why the call to merge is returning a channel.
But why I haven't a clue. I still claim that you have a dirty repl or
something.
Timothy
On Wed, May 7, 2014 at 6:11 AM, Valentin Luchko akme...@gmail.com wrote:
Sorry, but you guys didn't understand the problem.
*tbc++*, I don't use core.async, so I don't require it
dgrnbrg, I don't want to interface these libraries together.
Let me try explain again.
1. I have http-kit socket server running
2. When client connects I store its connection (http-kit's AsyncChannel)
in map @clients as a key, line 19 (swap! clients assoc con true)
3. Then when some data received from client line 21-22
(on-receive con (fn [data]
(handler)))
I invoke handler
(defn handler []
(future (let
[merged (merge {} @clients)]
(println merged)) ; = #ManyToManyChannel
clojure.core.async.impl.channels.ManyToManyChannel@5d9c832a, but expect to
get copy of @clients
#_(let
[into-map (into {} @clients)] ; here I get exception
IllegalArgumentException java.lang.IllegalArgumentException: No
implementation of method: :take! of protocol:
#'clojure.core.async.impl.protocols/ReadPort found for class: nil
(println into-map
Here I want just to make the copy of @clients with simple merge to empty map,
but I don't get a copied map, I get #ManyToManyChannel
clojure.core.async.impl.channels.ManyToManyChannel@5d9c832a
When trying use into I get I get exception.
I just want to know what is going on, why I get ManyToManyChannel instead of
@clients map copy?
--
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/d/optout.
--
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)
--
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/d/optout.
Reduce vs. Comp
What is the difference between: (reduce #(%2 %) 6 [(partial + 12) (partial * -1)]) and ((apply comp [(partial * -1) (partial + 12)]) 6) Using reduce *looks* nicer to me, but I feel like I'm re-implementing comp. Their performance is also the same (go inlining!). -- 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/d/optout.
defrecord, looking for more info on the __meta and __extmap fields and constructor arguments
The documentation for defrecord mentions additional arguments but doesn't give any examples of their use. I take it that the __extmap field generated for the class is for map slots that aren't defined with the defrecord fields. What is the __meta slot for and how is it typically used? -- 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/d/optout.
Re: Immutable or Effectively Immutable?
Mike, I believe I understand the definition of truly immutable you are using here, and what it means in the JVM as far as synchronization of object values across threads. What seems a bit odd is to use the phrase truly immutable to describe something that is clearly mutable, or at least it is by the definition of mutable: can be modified after construction, which PersistentVector and others can be. Thanks, Andy On Tue, May 6, 2014 at 6:20 PM, Mike Fikes mikefi...@me.com wrote: Hi Andy, Marking Java fields as final has semantics with respect to threading, defined in the JLS in section 17.5 ( http://docs.oracle.com/javase/specs/jls/se5.0/html/memory.html#17.5) If you do this, then it makes it possible to freely pass a truly immutable object instance to another thread and be guaranteed that that other thread will see the value initialized for that field in the constructor. If you don't do this, then the object can still be effectively immutable, which essentially means that you can pass the object to another thread, so long as you do it in a safe manner (using a volatile, or some synchronization mechanism). JCIP helps clarify all of this unfortunately complex topic. The important thing (and key to Closure), is that, if you are implementing the class that you want to be immutable, then if you can mark everything as final, then you truly achieve the benefits immutability give you with concurrency (in short, you need no synchronization whatsoever). If you fail to do this, then you have effective immutability, which is good, but complex and comes with caveats on how you can safely pass objects between threads. JCIP is a great book. But, the approach taken by Clojure makes a lot of the complicated concerns covered by the book largely ignorable, IMHO. On Tuesday, May 6, 2014 8:35:43 PM UTC-4, Andy Fingerhut wrote: Alex, I may be unfamiliar with the definitions of truly immutable and effectively immutable being used here, but if I can mutate the contents of a Java Object array that is a final field after an object is constructed, does it really matter that much if it is final? It is trivially easy to mutate using Java access. Here is the example that I mentioned earlier in this thread, copied here for convenience: user= (def v [1 2 3]) #'user/v user= (class v) clojure.lang.PersistentVector user= v [1 2 3] user= (aset (.tail v) 1 -2) -2 user= v [1 -2 3] Andy On Tue, May 6, 2014 at 4:49 PM, Alex Miller al...@puredanger.com wrote: The Clojure persistent data structures are truly immutable - all fields are final and referred objects are not mutated after construction so that freeze occurs. One obvious exception are the transient variants ( http://clojure.org/transients). You can look at the code in https://github.com/clojure/clojure/tree/master/src/jvm/clojure/lang - any of the Persistent*.java. On Tuesday, May 6, 2014 4:11:49 PM UTC-5, Mike Fikes wrote: Are the persistent immutable data structures in Clojure truly immutable (using final fields, relying on constructor freezing), or are they mean to be merely effectively immutable (as defined in JICP)? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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/d/optout. -- 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
Re: Immutable or Effectively Immutable?
Sorry if I'm beating a dead horse here. I agree that my example is not using published Clojure APIs, and I never do that kind of thing in a Clojure program, except as an example that PersistentVector's are mutable if you use Java APIs instead of restricting yourself to Clojure APIs. You don't even need to use reflection in Java or know about JVM security policies to mutate them (I am not suggesting that Clojure should be changed in any way here). I've actually got a copy of Java: Concurrency in Practice, and looked up (some of) what they say about immutability. Here is one definition they give of immutability, with some preceding text. I have added emphasis to one phrase: Neither the Java Language Specification nor the Java Memory Model formally defines immutability, but __immutability is *not* equivalent to simply declaring all fields of an object 'final'__. An object whose fields are all final may still be mutable, since final fields can hold references to mutable objects. An object is *immutable* if: + Its state cannot be modified after construction; + All its fields are 'final'; and + It is *properly constructed* (the 'this' reference does not escape during construction). I have no argument with PersistentVector satisfying the 2nd and 3rd bullet points above, but (1) seems not to hold. According to JCIP's definition of effectively immutable (Objects that are not technically immutable, but whose state will not be modified after publication), PersistentVector appears to me to be effectively immutable, but not truly immutable. Andy On Tue, May 6, 2014 at 8:31 PM, Alex Miller a...@puredanger.com wrote: Hey Andy, It does matter with regard to visibility across threads - your example does not use a synchronization mechanism and there is no guarantee that other threads will ever see those changes (so don't ever ever do that :). But if you stick to the normal Clojure apis, all is good. I'd highly recommend reading JCIP to dive into the details. Final field freeze is particularly weird and it baked my noodle when I first encountered it - here's a blog I wrote about it approx 697 years ago in internet time (and Brian Goetz backs me up in the comments :) http://tech.puredanger.com/2008/11/26/jmm-and-final-field-freeze/ Alex On Tuesday, May 6, 2014 7:35:43 PM UTC-5, Andy Fingerhut wrote: Alex, I may be unfamiliar with the definitions of truly immutable and effectively immutable being used here, but if I can mutate the contents of a Java Object array that is a final field after an object is constructed, does it really matter that much if it is final? It is trivially easy to mutate using Java access. Here is the example that I mentioned earlier in this thread, copied here for convenience: user= (def v [1 2 3]) #'user/v user= (class v) clojure.lang.PersistentVector user= v [1 2 3] user= (aset (.tail v) 1 -2) -2 user= v [1 -2 3] Andy On Tue, May 6, 2014 at 4:49 PM, Alex Miller al...@puredanger.com wrote: The Clojure persistent data structures are truly immutable - all fields are final and referred objects are not mutated after construction so that freeze occurs. One obvious exception are the transient variants ( http://clojure.org/transients). You can look at the code in https://github.com/clojure/clojure/tree/master/src/jvm/clojure/lang - any of the Persistent*.java. On Tuesday, May 6, 2014 4:11:49 PM UTC-5, Mike Fikes wrote: Are the persistent immutable data structures in Clojure truly immutable (using final fields, relying on constructor freezing), or are they mean to be merely effectively immutable (as defined in JICP)? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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.
Re: Immutable or Effectively Immutable?
Phil, that's an interesting point.
Consider (def x (cons (new java.util.Date) ()))
The object identified by x is *mutable*, but if the contained Date will not
be modified by the program, then the resulting object can be treated as
*effectively
immutable, *as you pointed out.
But, it would seem that you could pass x to another thread without
synchronization, and then safely read the contained Date instance by that
thread, because it has been safely published by virtue of having been
conveyed by a final field of the Cons instance. Of course, you would run
into trouble if you took that Date instance and passed it directly to
another thread without synchronization.
In other words, you could step outside of the limited profile of the Java
memory model that JCIP prescribes treating x as something (useful) between
*effectively
immutable *and *immutable, *with the end result being that you can treat x as
being *immutable.*
On Wednesday, May 7, 2014 7:13:31 AM UTC-4, Phillip Lord wrote:
Since the data structures and interfaces, they are effectively
immutable.
Consider this:
final public class Cons extends ASeq implements Serializable {
private final Object _first;
private final ISeq _more;
public Cons(Object first, ISeq _more){
this._first = first;
this._more = _more;
}
}
Although Cons uses final fields and constructor fields, _more is an
ISeq; given that this could be mutable, so could cons.
Phil
Mike Fikes mike...@me.com javascript: writes:
Are the persistent immutable data structures in Clojure truly
immutable
(using final fields, relying on constructor freezing), or are they mean
to
be merely effectively immutable (as defined in JICP)?
--
Phillip Lord, Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email:
philli...@newcastle.ac.ukjavascript:
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/d/optout.
Re: Immutable or Effectively Immutable?
Yep. PersistentVector is *mutable* per the JCIP definition. If it is *mutable* then you need to use locks or synchronization to access its contents. If your program doesn't modify its the vector, it is *effectively immutable. *But, you need to ensure that you safely publish it. But, if you create a PersistentVector, and somehow ensure that the array's contents are never modified, you can pass it freely between threads without synchronization. In short, even though you can't claim that PersistentVector is *immutable*, if you discipline yourself on how you use it, you can pretend that it is. This is a consequence of the use of final on the array field in PersistentVector. On Wednesday, May 7, 2014 10:17:38 AM UTC-4, Andy Fingerhut wrote: Mike, I believe I understand the definition of truly immutable you are using here, and what it means in the JVM as far as synchronization of object values across threads. What seems a bit odd is to use the phrase truly immutable to describe something that is clearly mutable, or at least it is by the definition of mutable: can be modified after construction, which PersistentVector and others can be. Thanks, Andy On Tue, May 6, 2014 at 6:20 PM, Mike Fikes mike...@me.com javascript:wrote: Hi Andy, Marking Java fields as final has semantics with respect to threading, defined in the JLS in section 17.5 ( http://docs.oracle.com/javase/specs/jls/se5.0/html/memory.html#17.5) If you do this, then it makes it possible to freely pass a truly immutable object instance to another thread and be guaranteed that that other thread will see the value initialized for that field in the constructor. If you don't do this, then the object can still be effectively immutable, which essentially means that you can pass the object to another thread, so long as you do it in a safe manner (using a volatile, or some synchronization mechanism). JCIP helps clarify all of this unfortunately complex topic. The important thing (and key to Closure), is that, if you are implementing the class that you want to be immutable, then if you can mark everything as final, then you truly achieve the benefits immutability give you with concurrency (in short, you need no synchronization whatsoever). If you fail to do this, then you have effective immutability, which is good, but complex and comes with caveats on how you can safely pass objects between threads. JCIP is a great book. But, the approach taken by Clojure makes a lot of the complicated concerns covered by the book largely ignorable, IMHO. On Tuesday, May 6, 2014 8:35:43 PM UTC-4, Andy Fingerhut wrote: Alex, I may be unfamiliar with the definitions of truly immutable and effectively immutable being used here, but if I can mutate the contents of a Java Object array that is a final field after an object is constructed, does it really matter that much if it is final? It is trivially easy to mutate using Java access. Here is the example that I mentioned earlier in this thread, copied here for convenience: user= (def v [1 2 3]) #'user/v user= (class v) clojure.lang.PersistentVector user= v [1 2 3] user= (aset (.tail v) 1 -2) -2 user= v [1 -2 3] Andy On Tue, May 6, 2014 at 4:49 PM, Alex Miller al...@puredanger.comwrote: The Clojure persistent data structures are truly immutable - all fields are final and referred objects are not mutated after construction so that freeze occurs. One obvious exception are the transient variants ( http://clojure.org/transients). You can look at the code in https://github.com/clojure/clojure/tree/master/src/jvm/clojure/lang - any of the Persistent*.java. On Tuesday, May 6, 2014 4:11:49 PM UTC-5, Mike Fikes wrote: Are the persistent immutable data structures in Clojure truly immutable (using final fields, relying on constructor freezing), or are they mean to be merely effectively immutable (as defined in JICP)? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to
Re: http-kit AsyncChannel and clojure.core.async.impl.channels.ManyToManyChannel
Now it makes sense. Thank you
среда, 7 мая 2014 г., 15:39:38 UTC+3 пользователь tbc++ написал:
core.async provides its own implementation of merge that returns a
ManyToMany channel. So that's why the call to merge is returning a channel.
But why I haven't a clue. I still claim that you have a dirty repl or
something.
Timothy
On Wed, May 7, 2014 at 6:11 AM, Valentin Luchko akm...@gmail.comjavascript:
wrote:
Sorry, but you guys didn't understand the problem.
*tbc++*, I don't use core.async, so I don't require it
dgrnbrg, I don't want to interface these libraries together.
Let me try explain again.
1. I have http-kit socket server running
2. When client connects I store its connection (http-kit's AsyncChannel)
in map @clients as a key, line 19 (swap! clients assoc con true)
3. Then when some data received from client line 21-22
(on-receive con (fn [data]
(handler)))
I invoke handler
(defn handler []
(future (let
[merged (merge {} @clients)]
(println merged)) ; = #ManyToManyChannel
clojure.core.async.impl.channels.ManyToManyChannel@5d9c832a, but expect to
get copy of @clients
#_(let
[into-map (into {} @clients)] ; here I get exception
IllegalArgumentException java.lang.IllegalArgumentException: No
implementation of method: :take! of protocol:
#'clojure.core.async.impl.protocols/ReadPort found for class: nil
(println into-map
Here I want just to make the copy of @clients with simple merge to empty
map, but I don't get a copied map, I get #ManyToManyChannel
clojure.core.async.impl.channels.ManyToManyChannel@5d9c832a
When trying use into I get I get exception.
I just want to know what is going on, why I get ManyToManyChannel instead of
@clients map copy?
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.comjavascript:
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com javascript:
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+u...@googlegroups.com javascript:.
For more options, visit https://groups.google.com/d/optout.
--
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)
--
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/d/optout.
Re: Immutable or Effectively Immutable?
I would offer that the key distinction is whether final is used: This prescribes what you must do when using the object. Take Date for example. You can't just pass one directly from one thread to another. The receiving thread could read a date associated with System.currentTimeMillis() of 0. But, String, since it uses final on its char[], fundamentally changes this. (If the final keyword were not present in String, even though you have no way to change its char[], it would be broken with respect to threading semantics.) On Wednesday, May 7, 2014 10:35:04 AM UTC-4, Andy Fingerhut wrote: Sorry if I'm beating a dead horse here. I agree that my example is not using published Clojure APIs, and I never do that kind of thing in a Clojure program, except as an example that PersistentVector's are mutable if you use Java APIs instead of restricting yourself to Clojure APIs. You don't even need to use reflection in Java or know about JVM security policies to mutate them (I am not suggesting that Clojure should be changed in any way here). I've actually got a copy of Java: Concurrency in Practice, and looked up (some of) what they say about immutability. Here is one definition they give of immutability, with some preceding text. I have added emphasis to one phrase: Neither the Java Language Specification nor the Java Memory Model formally defines immutability, but __immutability is *not* equivalent to simply declaring all fields of an object 'final'__. An object whose fields are all final may still be mutable, since final fields can hold references to mutable objects. An object is *immutable* if: + Its state cannot be modified after construction; + All its fields are 'final'; and + It is *properly constructed* (the 'this' reference does not escape during construction). I have no argument with PersistentVector satisfying the 2nd and 3rd bullet points above, but (1) seems not to hold. According to JCIP's definition of effectively immutable (Objects that are not technically immutable, but whose state will not be modified after publication), PersistentVector appears to me to be effectively immutable, but not truly immutable. Andy On Tue, May 6, 2014 at 8:31 PM, Alex Miller al...@puredanger.comjavascript: wrote: Hey Andy, It does matter with regard to visibility across threads - your example does not use a synchronization mechanism and there is no guarantee that other threads will ever see those changes (so don't ever ever do that :). But if you stick to the normal Clojure apis, all is good. I'd highly recommend reading JCIP to dive into the details. Final field freeze is particularly weird and it baked my noodle when I first encountered it - here's a blog I wrote about it approx 697 years ago in internet time (and Brian Goetz backs me up in the comments :) http://tech.puredanger.com/2008/11/26/jmm-and-final-field-freeze/ Alex On Tuesday, May 6, 2014 7:35:43 PM UTC-5, Andy Fingerhut wrote: Alex, I may be unfamiliar with the definitions of truly immutable and effectively immutable being used here, but if I can mutate the contents of a Java Object array that is a final field after an object is constructed, does it really matter that much if it is final? It is trivially easy to mutate using Java access. Here is the example that I mentioned earlier in this thread, copied here for convenience: user= (def v [1 2 3]) #'user/v user= (class v) clojure.lang.PersistentVector user= v [1 2 3] user= (aset (.tail v) 1 -2) -2 user= v [1 -2 3] Andy On Tue, May 6, 2014 at 4:49 PM, Alex Miller al...@puredanger.comwrote: The Clojure persistent data structures are truly immutable - all fields are final and referred objects are not mutated after construction so that freeze occurs. One obvious exception are the transient variants ( http://clojure.org/transients). You can look at the code in https://github.com/clojure/clojure/tree/master/src/jvm/clojure/lang - any of the Persistent*.java. On Tuesday, May 6, 2014 4:11:49 PM UTC-5, Mike Fikes wrote: Are the persistent immutable data structures in Clojure truly immutable (using final fields, relying on constructor freezing), or are they mean to be merely effectively immutable (as defined in JICP)? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com. For more
Re: Contagious BigDecimals?
Reviving a thread from three years ago (feel free to point me to something more recent) ... In Clojure 1.6: (class (+ 1 1.0M)) ; == java.math.BigDecimal (class (+ 1.0 1.0M)) ; == java.lang.Double So combining a BigDecimal with a Long produces a BigDecimal, but combining it with a Double produces a Double. The demotion to Double is implied by the statement about contagion the Clojure data structures pagehttp://clojure.org/data_structures#Data%20Structures-Numbers, although nothing is said about the promotion from Long to BigDecimal: Contagion BigInts and floating point types are contagious across operations. That is, any integer operation involving a BigInt will result in a BigInt, and any operation involving a double or float will result in a double. To me, the fact that BigDecimal is contagious sometimes but not always, seems confusing in a way that could encourage bugs. The fact that BigInts are contagious would also lead one to assume that BigDecimals are contagious. puzzler's post in this thread explained that the rationale for making Doubles rather than BigDecimals contagious is that numeric type contagion should reflect the contagion of imprecision in calculations, which is going to happen no matter type is given to the result, once you introduce any imprecise number into the calculations, i.e. in this case, a Double. And I see that when combining a Long with a BigDecimal, imprecision is not introduced. I understand the point, but I'm not sure that I agree: If you used a Double, you knew (or should have known) that you were getting imprecision. And pmbauer's question about Floats wasn't answered. It's still true in Clojure 1.6 that Doubles are contagious over Floats: (class (+ (float 1.0) 1.0)) ; == java.lang.Double I think that at the very least, if BigDecimals are contagious only some of the time, it would be worth putting big warning signs in the documentation announcing this fact. (I understand, though, that Clojure documentation is a work in progress, and is lagging in some ways behind the language, as suggested by other recent threads.) -- 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/d/optout.
Re: Reduce vs. Comp
I agree with the re-implementing comp sentiment. It reminds me of *A tutorial on the universality and expressiveness of fold http://www.cs.nott.ac.uk/~gmh/fold.pdf *where, essentially lots of standard functions can be defined in terms of reduce which could be considered primitive. In fact, section 5 of that document defines comp as a reduce involving the identify function in some way. (Now, I want to re-read this paper, but translated into Clojure.) On Wednesday, May 7, 2014 9:17:46 AM UTC-4, Mark Watson wrote: What is the difference between: (reduce #(%2 %) 6 [(partial + 12) (partial * -1)]) and ((apply comp [(partial * -1) (partial + 12)]) 6) Using reduce *looks* nicer to me, but I feel like I'm re-implementing comp. Their performance is also the same (go inlining!). -- 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/d/optout.
Re: Reduce vs. Comp
Hi,
Mike Fikes mikefi...@me.com wrote:
In fact, section 5 of that document defines comp as a reduce
involving the identify function in some way. (Now, I want to re-read
this paper, but translated into Clojure.)
Here's one definition of comp in terms of reduce:
(defn comp [ fs]
(reduce (fn [result f]
(fn [ args]
(result (apply f args
identity
fs))
It's probably a bit clearer with one of the anonymous functions pulled
out and named:
(defn comp [ fs]
(letfn [(chain [result f]
(fn [ args]
(f (apply result args]
(reduce chain identity fs)))
They're less efficient than clojure.core/comp's implementation, but I
love the versatility of {reduce,fold,whatever}.
Best regards,
John
--
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/d/optout.
Re: Reduce vs. Comp
If you read the source for comp, you'll find that anything more than 3 args
gets turned into something like reduce anyways:
(defn comp
Takes a set of functions and returns a fn that is the composition
of those fns. The returned fn takes a variable number of args,
applies the rightmost of fns to the args, the next
fn (right-to-left) to the result, etc.
{:added 1.0
:static true}
([] identity)
([f] f)
([f g]
(fn
([] (f (g)))
([x] (f (g x)))
([x y] (f (g x y)))
([x y z] (f (g x y z)))
([x y z args] (f (apply g x y z args)
([f g h]
(fn
([] (f (g (h
([x] (f (g (h x
([x y] (f (g (h x y
([x y z] (f (g (h x y z
([x y z args] (f (g (apply h x y z args))
([f1 f2 f3 fs]
(let [fs (reverse (list* f1 f2 f3 fs))]
(fn [ args]
(loop [ret (apply (first fs) args) fs (next fs)]
(if fs
(recur ((first fs) ret) (next fs))
ret))
On Wed, May 7, 2014 at 10:34 AM, John Mastro john.b.mas...@gmail.comwrote:
Hi,
Mike Fikes mikefi...@me.com wrote:
In fact, section 5 of that document defines comp as a reduce
involving the identify function in some way. (Now, I want to re-read
this paper, but translated into Clojure.)
Here's one definition of comp in terms of reduce:
(defn comp [ fs]
(reduce (fn [result f]
(fn [ args]
(result (apply f args
identity
fs))
It's probably a bit clearer with one of the anonymous functions pulled
out and named:
(defn comp [ fs]
(letfn [(chain [result f]
(fn [ args]
(f (apply result args]
(reduce chain identity fs)))
They're less efficient than clojure.core/comp's implementation, but I
love the versatility of {reduce,fold,whatever}.
Best regards,
John
--
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/d/optout.
--
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)
--
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/d/optout.
clojure.repl/pst problem
Hi there Inside REPL there's a function pst that shows the stacktrace of last exception: (doc pst) - clojure.repl/pst ([] [e-or-depth] [e depth]) Prints a stack trace of the exception, to the depth requested. If none supplied, uses the root cause of the most recent repl exception (*e), and a depth of 12. So, if I cause an error and call pst without arguments I got the full stacktrace promptly: user= (/ 1 0) ArithmeticException Divide by zero clojure.lang.Numbers.divide (Numbers.java:156) user= (pst) java.lang.ArithmeticException: Divide by zero Numbers.java:156 clojure.lang.Numbers.divide Numbers.java:3691 clojure.lang.Numbers.divide ... 22 lines ... Thread.java:745 java.lang.Thread.run java.lang.Thread.run But the documentation also shows that I can set the depth of stacktrace, what I guess that can be a number of lines: (pst 5) IllegalArgumentException No matching field found: getStackTrace for class java.lang.Long clojure.lang.Reflector.getInstanceField (Reflector.java:271) Nope. So I tried to pass *e as argument and the depth I want to show: user= (pst *e 5) java.lang.ArithmeticException: Divide by zero Numbers.java:156 clojure.lang.Numbers.divide Numbers.java:3691 clojure.lang.Numbers.divide ... the same 22 lines ... Thread.java:745 java.lang.Thread.run java.lang.Thread.run Is pst doing wrong or am I missing something? Regards Plínio -- 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/d/optout.
Re: Reduce vs. Comp
Reduce is indeed a swiss-army knife for functional programming over sequences. Of course, in this particular case (i.e., apply a sequence of functions in order to an initial value), Clojure's threading operators are the idiomatic way to go. (- 6 (+ 12) (* -1)) Cheers, ~Gary -- 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/d/optout.
Re: Managing State Changes, using Component
Actually, now that I think about it, that's not right. It shouldn't matter where or when you create the Atom. Instead, what I suspect you have is two or more instances of the component containing the Atom, thus two different Atoms. You can tell if the Atoms are the same object by printing them, which shows a unique hash of each Atom's identity. -S On Monday, May 5, 2014 6:25:55 PM UTC-4, frye wrote: Ahh, so that was it then. Yeah, I definitely created that atom in the start method. On Mon, May 5, 2014 at 3:27 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: At what point did you **create** the Atom in :a? Any mutable references which need to be shared among all usages of a component must be created in the **constructor**, not the `start` or `stop` methods. -- 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/d/optout.
Re: Contagious BigDecimals?
On May 7, 2014, at 12:11 PM, Mars0i marsh...@logical.net wrote: To me, the fact that BigDecimal is contagious sometimes but not always, seems confusing in a way that could encourage bugs. The fact that BigInts are contagious would also lead one to assume that BigDecimals are contagious. I don't think it's a case of sometimes but not always. Instead there's a contagion precedence order such that any type earlier in the order combined with a type later in the order yields the type later in the order. Here's the order: Long BigInt Ratio BigDec Double Before applying the contagion order, narrower integer types are promoted to Long, and float is promoted to Double. See for reference the many implementations of opsWith in Numbers.java: https://github.com/clojure/clojure/blob/clojure-1.6.0/src/jvm/clojure/lang/Numbers.java#L411 --Steve -- 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/d/optout.
Re: defrecord, looking for more info on the __meta and __extmap fields and constructor arguments
On Wednesday, May 7, 2014 8:59:17 AM UTC-5, Dave Tenny wrote: The documentation for defrecord mentions additional arguments but doesn't give any examples of their use. There are none. I take it that the __extmap field generated for the class is for map slots that aren't defined with the defrecord fields. Yes. What is the __meta slot for and how is it typically used? To implement IObject to support meta. -- 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/d/optout.
Re: clojure.repl/pst problem
On May 7, 2014, at 12:55 PM, Plínio Balduino pbaldu...@gmail.com wrote: But the documentation also shows that I can set the depth of stacktrace, what I guess that can be a number of lines: (pst 5) IllegalArgumentException No matching field found: getStackTrace for class java.lang.Long clojure.lang.Reflector.getInstanceField (Reflector.java:271) Nope. I see the behavior you see with Clojure 1.5.1. With Clojure 1.6.0 I get 5 lines of stack trace. --Steve -- 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/d/optout.
Re: clojure.repl/pst problem
That's true. My Leiningen is using 1.5.1 yet. Thank you Stephen. On Wed, May 7, 2014 at 3:18 PM, Stephen Gilardi scgila...@gmail.com wrote: On May 7, 2014, at 12:55 PM, Plínio Balduino pbaldu...@gmail.com wrote: But the documentation also shows that I can set the depth of stacktrace, what I guess that can be a number of lines: (pst 5) IllegalArgumentException No matching field found: getStackTrace for class java.lang.Long clojure.lang.Reflector.getInstanceField (Reflector.java:271) Nope. I see the behavior you see with Clojure 1.5.1. With Clojure 1.6.0 I get 5 lines of stack trace. —Steve -- 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/d/optout. -- 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/d/optout.
Re: Contagious BigDecimals?
On Wednesday, May 7, 2014 1:00:01 PM UTC-5, squeegee wrote: On May 7, 2014, at 12:11 PM, Mars0i mars...@logical.net javascript: wrote: To me, the fact that BigDecimal is contagious sometimes but not always, seems confusing in a way that could encourage bugs. The fact that BigInts are contagious would also lead one to assume that BigDecimals are contagious. I don’t think it's a case of “sometimes but not always”. Instead there’s a contagion precedence order such that any type earlier in the order combined with a type later in the order yields the type later in the order. Here’s the order: Long BigInt Ratio BigDec Double Before applying the contagion order, narrower integer types are promoted to Long, and float is promoted to Double. Thanks Steve. That's very clear, and very helpful. It's no longer confusing to me. I still would say that it would be a good thing if precedence order were documented explicitly at clojure.org or another obvious documentation source. There's still some potential for confusion. The rule is not what I would have expected. -- 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/d/optout.
[did...@lrde.epita.fr: [clisp-list] [CfP] International Lisp Conference 2014, Aug. 14-17, Montreal]
From: Didier Verna did...@lrde.epita.fr ILC 2014 - International Lisp Conference Lisp on the Move August 14-17 2014, University of Montreal, Montreal, Canada Sponsored by the Association of Lisp Users In cooperation with: ACM SIGPLAN http://www.international-lisp-conference.org Scope: Lisp is one of the greatest ideas from computer science and a majorinfluence for almost all programming languages and for allsufficiently complex software applications. The International Lisp Conference is a forum for the discussion ofLisp and, in particular, the design, implementation and application ofany of the Lisp dialects. We encourage everyone interested in Lisp toparticipate. We invite high quality submissions in all areas involving Lispdialects and any other languages in the Lisp family, including, butnot limited to, ACL2, AutoLisp, Clojure, Common Lisp, ECMAScript, Dylan, Emacs Lisp, ISLISP, Racket, Scheme, SKILL, HOP etc. The conference proceedings will be published in the ACM Digital Library. This year's focus will be directed towards integrated solutions,including mobile computing. We especially invite submissions in thefollowing areas: * Pervasive computing Interoperability Portability Implementation * challenges/tradeoffs for embedded/mobile platforms Language * support for mobile toolkits and frameworks Language support for * distribution Language support for reliability, availability, and * serviceability Mobile IDEs Mobile applications Contributions are also welcome in other areas, including but not limited to: * Language design and implementation Language integration, * inter-operation and deployment Applications (especially commercial) * Reflection, meta-object protocols, meta-programming * Domain-specific languages Programming paradigms and environments * Efficient parallel and concurrent computation Language support for * managing both manual and automatic GC Theorem proving Scientific * computing Data mining Semantic web Technical Programme: Original submissions in all areas related to the conference themes are invited for the following categories: Papers: Technical papers of up to 10 pages that describe original results. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries and applications. Workshops: Abstracts of up to 2 pages for groups of people who intend to work on a focused topic for half a day. Tutorials: Abstracts of up to 2 pages for in-depth presentations about topics of special interest for 1 to 2 hours. Panel discussions: Abstracts of up to 2 pages for discussions about current themes. Panel discussion proposals must mention panel member who are willing to partake in a discussion. The conference will also provide slots for lightning talks, to be registered on-site every day. For inquiries about any other kind of participation (commercial exhibits, advertising, prizes, book signing etc.), please see the contacts below. Important Dates: - May18, 2014: Submission deadline - June 09, 2014: Notification of acceptance - June 29, 2014: Final Papers due - August 14, 2014: Conference All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. Submissions should be uploaded to Easy Chair, at the following address: https://www.easychair.org/conferences/?conf=ilc14 Organizing Committee: General Chair: Marc Feeley (Universitie de Montral, Montreal, Canada) Programme Chair: Didier Verna (EPITA Research lab, Paris, France) Local chair: Marc Feeley (Universitie de Montreal, Montreal, Canada) Programme Committee: Charlotte Herzeel, IMEC, ExaScience Life Lab, Belgium Damir Cavar, Eastern Michigan University, USA Dave Herman, Mozilla Research, USA Greg Pfeil, Clozure Associates, USAIrone Anne Durand, LaBRI University of Bordeaux, France Jim Newton, Cadence Design Systems, France Kuroda Hisao, Mathematical Systems Inc., Japan Matthew Might, University of Utah, USA Nicolas Neuss, Friedrich Alexander Universitat, Germany Ralf Meller, TUHH, Germany Sam Tobin-Hochstadt, Northeastern University, USA William Byrd, University of Utah, USA Contacts: * General Questions: ilc14-organizing-committee at alu.org * Programme Committee: ilc14 at easychair.org -- 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
Re: Reduce vs. Comp
I agree. I guess I was specifically thinking of a list of functions where the length of the list, and the functions themselves, are defined at run-time. Which would lead to some nasty code using the threading macros. (Unless someone has an example of this not being the case) On Wednesday, May 7, 2014 1:00:17 PM UTC-4, Gary Johnson wrote: Reduce is indeed a swiss-army knife for functional programming over sequences. Of course, in this particular case (i.e., apply a sequence of functions in order to an initial value), Clojure's threading operators are the idiomatic way to go. (- 6 (+ 12) (* -1)) Cheers, ~Gary -- 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/d/optout.
[ANN] Strange Loop 2014 - CFP closes May 9th
Strange Loop is a multi-language multi-paradigm multi-disciplinary industry/academic/dilettante/enthusiast conference bringing together software developers to look at the past, present, and future of what we do as developers. Strange Loop 2014 will take place Sept 18-19 (preconf Sept 17) in St. Louis, MO. The Call for Presentations closes this Friday, May 9th. Hotel and travel is covered (partial for international) for speakers. Home: http://thestrangeloop.com CFP: http://thestrangeloop.com/sessions-page/call-for-presentations 2013 talks for reference: http://thestrangeloop.com/archive/2013 Please direct any questions to i...@thestrangeloop.com or me. Alex -- 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/d/optout.
Tag classes required to be imported?
Hi all, I just came across a case with AOT compilation that I haven't seen before. I have the following code: (defn clojurescript? [element] (or (.isKindOf (psi/language element) (ClojurescriptLanguage/getInstance)) (.isKindOf (psi/language element) (CljxLanguage/getInstance psi/language looks like this: (defn language ^Language [^PsiElement element] (.getLanguage element)) This gives me the following error when compiling: Caused by: java.lang.IllegalArgumentException: Unable to resolve classname: Language at clojure.lang.Compiler$HostExpr.tagToClass(Compiler.java:1060) at clojure.lang.Compiler$InvokeExpr.getJavaClass(Compiler.java:3567) at clojure.lang.Compiler$InstanceMethodExpr.init(Compiler.java:1393) at clojure.lang.Compiler$HostExpr$Parser.parse(Compiler.java:952) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6560) I can get rid of this error importing Language into the original namespace. But I didn't expect this - does this mean that an import is required for the tag type of any function used in a particular namespace? Does this also apply to argument tags? 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/d/optout.
Re: Tag classes required to be imported?
Interestingly, this does not occur if the type hint is on the var rather than the arglist. According to the IRC conversation referenced herehttps://github.com/jonase/eastwood/issues/37, this should work fine for non-primitive type hints. On 8 May 2014 16:55, Colin Fleming colin.mailingl...@gmail.com wrote: Hi all, I just came across a case with AOT compilation that I haven't seen before. I have the following code: (defn clojurescript? [element] (or (.isKindOf (psi/language element) (ClojurescriptLanguage/getInstance)) (.isKindOf (psi/language element) (CljxLanguage/getInstance psi/language looks like this: (defn language ^Language [^PsiElement element] (.getLanguage element)) This gives me the following error when compiling: Caused by: java.lang.IllegalArgumentException: Unable to resolve classname: Language at clojure.lang.Compiler$HostExpr.tagToClass(Compiler.java:1060) at clojure.lang.Compiler$InvokeExpr.getJavaClass(Compiler.java:3567) at clojure.lang.Compiler$InstanceMethodExpr.init(Compiler.java:1393) at clojure.lang.Compiler$HostExpr$Parser.parse(Compiler.java:952) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6560) I can get rid of this error importing Language into the original namespace. But I didn't expect this - does this mean that an import is required for the tag type of any function used in a particular namespace? Does this also apply to argument tags? 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/d/optout.
