Contract - 3 Months - Clojure/Clojurescript/Reagent - London
Morning, I have just had a 3 month contract come up for a Clojure/Clojurescript/Reagent engineer here in London. Working for a top Clojure house! Drop me a line for more info or if you are interested! a...@functionalworks.com thanks, 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.
Re: Memory Locality - Maps vs. Vectors vs. Transient Maps & Vectors
So, as Andy pointed, transients would do the trick for you. And maybe type hints could also help but, as Stuart said, benchmark it all the way down. Regards Plinio On Wednesday, April 20, 2016, JvJ wrote: > I don't think I'll go with primitive arrays. A big part of the reason I'm > using Clojure is for the immutable persistence. I just want to use them in > the most efficient way possible. I know I'm not going to get hyper-blazing > C-level performance. > > On Wednesday, 20 April 2016 15:38:11 UTC-7, Stuart Sierra wrote: >> >> The first answer: test & measure. Benchmark your code, use a JVM profiler >> to find hotspots, etc. Test every change you make to see if it has a >> measurable improvement. Any assumptions about what “should” be >> faster/slower are likely to be wrong. >> >> The long answer: >> >> The JVM does not give you much control over how objects are arranged in >> memory. In Java and Clojure, almost everything is a pointer to an object on >> the heap. Java collection classes and Clojure collections store pointers to >> objects; they do not store values “in-line” like an array of structs in C. >> The JVM *may* have optimizations that try to arrange objects “near” >> other objects, but you have no control over this. >> >> So my (untested) expectation is that all Clojure collection types are >> more-or-less equal in terms of memory locality. >> >> The only built-in data structure that offers the possibility of >> contiguous allocation in Java — without dropping down to native code — is >> an array of primitives, such as integers or doubles. Clojure has built-in >> functions to create and manipulate Java primitive arrays, if that works for >> your use case. >> >> –S >> >> >> On Wednesday, April 20, 2016 at 2:03:10 PM UTC-4, JvJ wrote: >>> >>> I'm writing some code that I would like to perform as quickly as >>> possible. Currently, I am iterating over large hash maps and performing >>> assocs and dissocs. >>> >>> I don't know much about performance optimization, but I am told that >>> memory locality is a big factor. I would like to know how Persistent Maps, >>> Persistent Vectors, Transient Maps, and Transient Vectors compare to one >>> another in this respect. >>> >>> Also, the objects in the collection that I'm iterating over will >>> themselves be maps. So, if I had a vector with good memory locality, but >>> it stored what are effectively pointers to maps allocated elsewhere, will >>> that nullify the benefits of memory locality? >>> >>> Thanks >>> >> -- > 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.
Are strings vectors? Should 'get' docstring be changed?
The docstring for 'get' says nothing explicit about vectors ("Returns the
value mapped to key, not-found or nil if key not present.") but most of us
know that vectors can be viewed as associative data structures where
indexes are like keys:
(get [\a \b \c] 1)
\b
'get' also works on strings:
(get "abc" 1)
\b
However, strings are not treated as vectors or maps in other contexts:
(assoc "abc" 1 \Z)
ClassCastException java.lang.String cannot be cast to
clojure.lang.Associative
This combination of behaviors is confusing. If strings are vectors, then
'assoc' and other similar functions should work with them, and maybe I
should be able to do this to index into a string:
("abc" 1)
ClassCastException java.lang.String cannot be cast to clojure.lang.IFn
If strings are not vectors, then they seem to be a special case for 'get'.
One might argue that the very terse docstring for 'get' should note its use
with vectors, but once you understand the sense in which vectors are like
maps, the of 'get' use with vectors is implicitly covered by what the
docstring says. However, the use of 'get' with strings is not implicitly
covered by what the docstring says. If it was, then the last two examples
I gave should work.
(I'd be willing to file a ticket on this, but the puzzling behavior is not
new, and I suspect that there's something I'm not understanding.)
--
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: Are strings vectors? Should 'get' docstring be changed?
This is a special case behavior of clojure.core/get, as you can see in the
RT.java source file at these lines:
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L750-L755
I have no idea if a JIRA would be accepted for any change on this or not,
but if one was, I suspect it would be an addition to the doc string for
clojure.core/get, mentioning that it also works on strings.
Most doc strings are considered terse by many people. This appears to be
considered a feature by those who maintain Clojure, not a bug, with one
reason given by Stuart Halloway in his recent talk on using the scientific
method in debugging [1]. Paraphrased from memory it was approximately "if
you have a bug in some API you are using, you should read all of the
documentation for it. That is easier if it is short."
If you want longer documentation and/or examples, ClojureDocs.org and
conj.io take user submissions for additional documentation, with quite low
friction.
Andy
[1] https://www.youtube.com/watch?v=FihU5JxmnBg
On Thu, Apr 21, 2016 at 8:48 AM, Mars0i wrote:
> The docstring for 'get' says nothing explicit about vectors ("Returns the
> value mapped to key, not-found or nil if key not present.") but most of us
> know that vectors can be viewed as associative data structures where
> indexes are like keys:
>
> (get [\a \b \c] 1)
> \b
>
> 'get' also works on strings:
>
> (get "abc" 1)
> \b
>
> However, strings are not treated as vectors or maps in other contexts:
>
> (assoc "abc" 1 \Z)
> ClassCastException java.lang.String cannot be cast to
> clojure.lang.Associative
>
> This combination of behaviors is confusing. If strings are vectors, then
> 'assoc' and other similar functions should work with them, and maybe I
> should be able to do this to index into a string:
>
> ("abc" 1)
> ClassCastException java.lang.String cannot be cast to clojure.lang.IFn
>
> If strings are not vectors, then they seem to be a special case for
> 'get'. One might argue that the very terse docstring for 'get' should note
> its use with vectors, but once you understand the sense in which vectors
> are like maps, the of 'get' use with vectors is implicitly covered by what
> the docstring says. However, the use of 'get' with strings is not
> implicitly covered by what the docstring says. If it was, then the last
> two examples I gave should work.
>
> (I'd be willing to file a ticket on this, but the puzzling behavior is not
> new, and I suspect that there's something I'm not understanding.)
>
> --
> 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: Are strings vectors? Should 'get' docstring be changed?
It doesn't necessarily follow that something that works with
clojure.core/get needs to work with clojure.core/assoc. You can have an
object that implements ILookup but not Associative, for instance.
The problem with using assoc with native JVM data structures like strings
and arrays is that there isn't an efficient way of implementing assoc for
those structures. You have to copy the entire structure, no matter how
large it might be. Clojure seems to avoid having functions that have
variable performance depending on the data structure they're applied to.
For example, trying to "get" on a seq also fails, presumably because seqs
have no efficient way of looking up a value by index. Instead we have
clojure.core/nth, which has predictable O(n) performance.
- James
On 21 April 2016 at 16:48, Mars0i wrote:
> The docstring for 'get' says nothing explicit about vectors ("Returns the
> value mapped to key, not-found or nil if key not present.") but most of us
> know that vectors can be viewed as associative data structures where
> indexes are like keys:
>
> (get [\a \b \c] 1)
> \b
>
> 'get' also works on strings:
>
> (get "abc" 1)
> \b
>
> However, strings are not treated as vectors or maps in other contexts:
>
> (assoc "abc" 1 \Z)
> ClassCastException java.lang.String cannot be cast to
> clojure.lang.Associative
>
> This combination of behaviors is confusing. If strings are vectors, then
> 'assoc' and other similar functions should work with them, and maybe I
> should be able to do this to index into a string:
>
> ("abc" 1)
> ClassCastException java.lang.String cannot be cast to clojure.lang.IFn
>
> If strings are not vectors, then they seem to be a special case for
> 'get'. One might argue that the very terse docstring for 'get' should note
> its use with vectors, but once you understand the sense in which vectors
> are like maps, the of 'get' use with vectors is implicitly covered by what
> the docstring says. However, the use of 'get' with strings is not
> implicitly covered by what the docstring says. If it was, then the last
> two examples I gave should work.
>
> (I'd be willing to file a ticket on this, but the puzzling behavior is not
> new, and I suspect that there's something I'm not understanding.)
>
> --
> 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: Are strings vectors? Should 'get' docstring be changed?
On Apr 21, 2016, at 10:04, James Reeves wrote: > > Clojure seems to avoid having functions that have variable performance > depending on the data structure they're applied to. But not always! (e.g. count) -- 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: Are strings vectors? Should 'get' docstring be changed?
That's a good point, but it should be noted that all collections for which clojure.core/counted? returns true (they implement clojure.lang.Counted) should implement count in constant time. So the design of the Counted interface was clearly intended to provide consumers a soft guarantee of performance invariability across data structures when necessary.. On Thursday, April 21, 2016 at 1:26:26 PM UTC-4, Michael Gardner wrote: > > On Apr 21, 2016, at 10:04, James Reeves > wrote: > > > > Clojure seems to avoid having functions that have variable performance > depending on the data structure they're applied to. > > But not always! (e.g. count) -- 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: Are strings vectors? Should 'get' docstring be changed?
That's a good point, but it should be noted that all collections for which clojure.core/counted? returns true (they implement clojure.lang.Counted) should implement count in constant time. So the design of the Counted interface was clearly intended to provide consumers a soft guarantee of performance invariability across data structures when required. On Thursday, April 21, 2016 at 1:26:26 PM UTC-4, Michael Gardner wrote: > > On Apr 21, 2016, at 10:04, James Reeves > wrote: > > > > Clojure seems to avoid having functions that have variable performance > depending on the data structure they're applied to. > > But not always! (e.g. count) -- 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: Are strings vectors? Should 'get' docstring be changed?
On Thursday, April 21, 2016 at 11:49:16 AM UTC-5, Andy Fingerhut wrote: > > Most doc strings are considered terse by many people. This appears to be > considered a feature by those who maintain Clojure, not a bug, with one > reason given by Stuart Halloway in his recent talk on using the scientific > method in debugging [1]. Paraphrased from memory it was approximately "if > you have a bug in some API you are using, you should read all of the > documentation for it. That is easier if it is short." > > If you want longer documentation and/or examples, ClojureDocs.org and > conj.io take user submissions for additional documentation, with quite > low friction. > Yeah, there are tradeoffs. I understand the value of brief docstrings. The current docstring for 'get' is correct for maps and vectors, even though the meaning for vectors won't be apparent for novices. Lots of things aren't apparent for novices. The behavior with strings is simply undocumented anywhere, afaik, though. That seems wrong. (Correction: I just added an example to clojure.docs. I still think that all of the intended behavior of a function should be at least tersely implied by its docstring.) -- 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: Are strings vectors? Should 'get' docstring be changed?
Strings are indexed. They are a special case because String is a Java final
class that cannot be "extended" to support the core interfaces inside
Clojure's Java implementation. If Clojure were itself protocol-based (like
ClojureScript is), the protocol could cover this without the special case.
On Thursday, April 21, 2016 at 10:48:18 AM UTC-5, Mars0i wrote:
>
> The docstring for 'get' says nothing explicit about vectors ("Returns the
> value mapped to key, not-found or nil if key not present.") but most of us
> know that vectors can be viewed as associative data structures where
> indexes are like keys:
>
> (get [\a \b \c] 1)
> \b
>
> 'get' also works on strings:
>
> (get "abc" 1)
> \b
>
> However, strings are not treated as vectors or maps in other contexts:
>
> (assoc "abc" 1 \Z)
> ClassCastException java.lang.String cannot be cast to
> clojure.lang.Associative
>
>
Being able to *add* something to an indexed collection is a totally
different "behavior" than looking something up by index. Strings don't do
that part.
> This combination of behaviors is confusing. If strings are vectors, then
> 'assoc' and other similar functions should work with them, and maybe I
> should be able to do this to index into a string:
>
> ("abc" 1)
> ClassCastException java.lang.String cannot be cast to clojure.lang.IFn
>
> If strings are not vectors, then they seem to be a special case for
> 'get'. One might argue that the very terse docstring for 'get' should note
> its use with vectors, but once you understand the sense in which vectors
> are like maps, the of 'get' use with vectors is implicitly covered by what
> the docstring says. However, the use of 'get' with strings is not
> implicitly covered by what the docstring says. If it was, then the last
> two examples I gave should work.
>
> (I'd be willing to file a ticket on this, but the puzzling behavior is not
> new, and I suspect that there's something I'm not understanding.)
>
I think the current behavior and docs are correct and I'm not yet convinced
there is a change needed. (But feel free to keep discussing and maybe I'll
change my mind. :)
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.
Re: Are strings vectors? Should 'get' docstring be changed?
On Thursday, April 21, 2016 at 2:20:11 PM UTC-5, Mars0i wrote: > The behavior with strings is simply undocumented anywhere, afaik, though. > Sorry, that was wrong even before I added an example to clojure.docs. The conj.io documentation is quite explicit and detailed. -- 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.
How to forward-declare deftypes
I'm working with two deftypes that I want to be able to references each other. (They're persistent and transient implementations of the same collection.) So far, it seems that the normal clojure.core/declare doesn't work in this case. Is there another way to do it? Thanks -- 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: How to forward-declare deftypes
Pretty sure Michal Marczyk mentioned this in his Clojure/West talk last week: https://www.youtube.com/watch?v=vZtkqDIicqI&index=14&list=PLZdCLR02grLq4e8-1P2JNHBKUOLFTX3kb (I don’t remember exactly what he said was the workaround) Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood On 4/21/16, 2:05 PM, "JvJ" wrote: I'm working with two deftypes that I want to be able to references each other. (They're persistent and transient implementations of the same collection.) So far, it seems that the normal clojure.core/declare doesn't work in this case. Is there another way to do it? Thanks . -- 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: How to forward-declare deftypes
Few things to consider: code against protocols where possible (removes the need to forward declare methods). Forward declare the constructor functions: (declare ->Foo) ... (defn some-code [] (->Foo 1 2)) (defrecord Foo [x y]) If you need to do type checks check for a protocol instead. Timothy On Thu, Apr 21, 2016 at 5:01 PM, Sean Corfield wrote: > Pretty sure Michal Marczyk mentioned this in his Clojure/West talk last > week: > > > > > https://www.youtube.com/watch?v=vZtkqDIicqI&index=14&list=PLZdCLR02grLq4e8-1P2JNHBKUOLFTX3kb > > > > (I don’t remember exactly what he said was the workaround) > > > > Sean Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > > > On 4/21/16, 2:05 PM, "JvJ" kfjwhee...@gmail.com> wrote: > > > > I'm working with two deftypes that I want to be able to references each > other. (They're persistent and transient implementations of the same > collection.) > > > > So far, it seems that the normal clojure.core/declare doesn't work in this > case. Is there another way to do it? > > > > Thanks > > . > > -- > 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.
Re: Incanter 1.9 and Clojure 1.7
I am running exactly the code in the example given in (doc principal-components). On Wed, Apr 20, 2016 at 11:46 AM, Bruce Durling wrote: > Myriam, > > Would you check with the latest commit on the develop branch please? > We're trying to get a new SNAPSHOT release out that might sort a > number of issues. > > If yours isn't sorted then I might look at it as we use PCA a fair bit too. > > Do you have a small example of some code that is failing? > > cheers, > Bruce > > On Wed, Apr 20, 2016 at 3:19 PM, myriam abramson > wrote: > > I am getting the following error with Incanter 1.9 running the PCA > example > > from the documentation: > > > > CompilerException java.lang.ClassCastException: java.lang.Boolean cannot > be > > cast to java.lang.Number, compiling:(pca.clj:17:10) > > > > That works fine with Clojure 1.6. (and yes, I know that the latest is > 1.8). > > > > What to do? > > > > > > -- > > 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. > -- 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: How to forward-declare deftypes
What I ended up doing was forward-declaring a wrapper to the constructor of the later class. I actually am implementing a protocol, but the concrete types representing the persistent and transient versions need to reference each other. Also, I'm using deftype over defrecord because I want the objects to be alternative map implementations, and I want mutable fields for the transients. On Thursday, 21 April 2016 16:22:14 UTC-7, tbc++ wrote: > > Few things to consider: code against protocols where possible (removes the > need to forward declare methods). Forward declare the constructor functions: > > (declare ->Foo) > > ... > > (defn some-code [] > (->Foo 1 2)) > > (defrecord Foo [x y]) > > If you need to do type checks check for a protocol instead. > > Timothy > > > On Thu, Apr 21, 2016 at 5:01 PM, Sean Corfield > wrote: > >> Pretty sure Michal Marczyk mentioned this in his Clojure/West talk last >> week: >> >> >> >> >> https://www.youtube.com/watch?v=vZtkqDIicqI&index=14&list=PLZdCLR02grLq4e8-1P2JNHBKUOLFTX3kb >> >> >> >> (I don’t remember exactly what he said was the workaround) >> >> >> >> Sean Corfield -- (904) 302-SEAN >> An Architect's View -- http://corfield.org/ >> >> "If you're not annoying somebody, you're not really alive." >> -- Margaret Atwood >> >> >> >> On 4/21/16, 2:05 PM, "JvJ" on >> behalf of kfjwh...@gmail.com > wrote: >> >> >> >> I'm working with two deftypes that I want to be able to references each >> other. (They're persistent and transient implementations of the same >> collection.) >> >> >> >> So far, it seems that the normal clojure.core/declare doesn't work in >> this case. Is there another way to do it? >> >> >> >> Thanks >> >> . >> >> -- >> 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. >> > > > > -- > “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.
