Re: ClassNotFoundException using try inside core.async go block
Thanks for checking into it. Using current master seems to fix it for me as well. I'll use a local copy until the next release. Thanks again! chap On Tuesday, April 28, 2015 at 8:44:59 PM UTC-4, Alex Miller wrote: I think this is a bug in the fairly old tools.analyzer version used in the latest released version. That's actually been updated for the next release and does not seem reproducible to me there. On Tuesday, April 28, 2015 at 6:04:19 PM UTC-5, Chap Lovejoy wrote: I'm running into a strange exception trying to handle exceptions within a go block. So far this is the simplest test case I've gotten to fail: (ns test-async (require [clojure.core.async :refer [go !] :as async])) (defn test-chan [chan] (go (try (! chan) (catch Throwable ex ex Requiring the namespace results in the following error: user= (require 'test-async :reload) CompilerException java.lang.RuntimeException: Unable to resolve symbol: test-async in this context, compiling:(test_async.clj:7:3) Using either ! or ! triggers the error. Removing these operations makes it go away. Is there something I'm missing here? I'm using the latest (0.1.346.0-17112a-alpha) version of core.async and have tried on both 1.6.0 and 1.7.0-beta1. Thanks, Chap -- 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 community organisation
This is a awesome idea! In my opinion, this organization would attract the maximum number of people if its mission is centred on Knowledge Management: 1. Wiki-based Clojure documentation, such as clojuredocs.org, containing the official documentation, but constantly improved by the community with more examples and rephrasing complex sentences, etc; 2. Wiki-based libraries documentation, related to Clojars and following the same model of the previous documentation; 3. Agregation of content produced by bloggers and websites out there, everything indexed by tags linked to Clojure versions and libraries in clojars for cross-navigation; 4. Agregation of videos and slides produced by conference speakers, instructors. 5. Everything gamefied so people can win points for their contributions and increase their reputation like in stackoverflow.com. I would love to join as a member to have discounts in books, conferences, courses, tshirts, etc. I absolutely rate professional certifications, but I'm in favour of certified courses, so we can be sure the instructors are capable of teaching Clojure properly, with idiomatic code. What about promoting Clojure as a first language in universities? We would need to help teachers to create equivalent syllabus to the ones they are already using to teach Python, for example. So, this is my brainstorming. On Wed, Apr 29, 2015 at 12:02 AM, Daniel Solano Gómez cloj...@sattvik.com wrote: Hello, all, I've brought up the idea of some sort of Clojure community organisation a few times on this mailing list. The ideas is to help grow the Clojure community by doing things like supporting GSoC students, run infrastructure like Clojars, help run conferences, etc. I have decided to start moving forward and apply for fiscal sponsorship from the Software Freedom Conservancy and Software in the Public Interest. Those things take time to work themselves out. In the meantime, I appreciate any input/feedback about what this org should do or what it should look like. As such, I have posted a page on the community wiki to start braainstorming and discussing ideas http://dev.clojure.org/display/community/Clojure+Community+Organisation. A big thank you to everyone. Participating in this community has been a very positive experience for me, and I would love to see it to continue to flourish. I appreciate any help or advice on how to make this initiative succeed in supporting the community. Sincerely, Daniel -- 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. -- Hildeberto Mendonça, Ph.D Blog: http://www.hildeberto.com Community: http://www.cejug.net Twitter: https://twitter.com/htmfilho -- 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: [ClojureScript] Re: [reagent] Re: [ANN] SF Reagent Meetup TODAY 6:30pm @Loyal3 @Meerkat
Our video production person is having to work on other more urgent stuff at the moment. We're not his hottest customer but hopeful he will get to it sometime soon... Sorry about that. Sent from my iPhone On Apr 28, 2015, at 10:02 PM, simon lomax simax.99...@gmail.com wrote: On Friday, 17 April 2015 16:25:34 UTC+1, Jamie Orchard-Hays wrote: Excellent. I tried to watch on periscope, but it never showed up. Jamie On Apr 17, 2015, at 10:20 AM, Marc Fawzi marc.fa...@gmail.com wrote: yes, will post link here sometime next week all 3 presentations were screen captured too so it will be very easy to follow Sent from my iPhone On Apr 17, 2015, at 7:12 AM, Jeremy Vuillermet jeremy.vuiller...@gmail.com wrote: Will the event video be uploaded somewhere ? If yes, where !? Missed the live stream unfortunately. Living in France doesn't help ... On Thursday, April 16, 2015 at 4:35:38 PM UTC+2, marc fawzi wrote: Thursday, April 16, 2015 6:30 PM Loyal3 150 California St Ste 400, San Francisco, CA (edit map) two blocks from the Embarcadero BART on California and Front SF Reagent Meetup Agenda: IMPORTANT: We will be streaming the event live MEERKAT @ 7:00PM PDT (GMT time -7 hours) today! -- Follow @marcfawzi on Twitter for live updates. To watch on the web (non-interactive mode) http://meerkatapp.co/marcfawzi/sch-1a612560-df50-4d13-a00c-c828eee742c9 Meerkat is available on iOS and viewers are encouraged to download the app (interactive mode) https://itunes.apple.com/us/app/meerkat-tweet-live-video/id954105918?mt=8 Unofficial Meerkat app for Android - made with love by Meerkat's engineers (interactive mode) https://play.google.com/store/apps/details?id=co.getair.meerkathl=en 1. 6:30pm - 7:00pm: meet greet, food and drinks, social 2. 7:00pm - 7:30pm: (LIVE STREAM via Meerkat) Intro to Reagent-Template (repo: https://github.com/reagent-project/reagent-template) --- by its author Dmitri Sotnikov(also author of Luminus.) Dmitri will be presenting via Google hangout on a big screen and you will be able to ask him questions live. This should be interesting. 3. 7:30pm - 7:45pm: (LIVE STREAM via Meerkat) Re-frame and Reagent port of Angular's phonecat (repo:https://github.com/dhruvp/angular-phonecat-re-frame) -- by its author Dhruv Parthasarathy (MIT) 4. 7:45-8:00pm (LIVE STREAM via Meerkat, updated description): Reusable Reagent Components with App-State Driven CSS Transitions (watch: http://imgur.com/04OaRw3) -- by Marc Fawzi -- this live demo will include Learning Outcomes for smooth animations, component styling, and sharing the components via internal maven repo Artifactory and our TeamCity deploy pipeline, among other things. A professionally produced video of the event that includes screen captures of on-stage and Google Hangout presentations will be shared within a week of the event. SF FOLKS, HOPE TO SEE YOU IN PERSON! LOCAL BEER CHOICES AND SAME AWESOME PIZZAS (w/ GF/DF options) -- You received this message because you are subscribed to the Google Groups Reagent-Project group. To unsubscribe from this group and stop receiving emails from it, send an email to reagent-project+unsubscr...@googlegroups.com. To post to this group, send email to reagent-proj...@googlegroups.com. Visit this group at http://groups.google.com/group/reagent-project. For more options, visit https://groups.google.com/d/optout. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescr...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. Hi, Did the videos ever get released? Regards, Simon -- You received this message because you are subscribed to the Google Groups Reagent-Project group. To unsubscribe from this group and stop receiving emails from it, send an email to reagent-project+unsubscr...@googlegroups.com. To post to this group, send email to reagent-proj...@googlegroups.com. Visit this group at http://groups.google.com/group/reagent-project. 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
Re: complex numbers in clojure
For me, having complex numbers not work seamlessly with other numbers and
core arithmetic ops is not viable. Doing arithmetic ops with any kind of
number is a real (pardon the pun) use case.
If complex numbers are not likely to be supported fully, then maybe it
makes sense to have complex numbers just inside of core.matrix. As you
suggest, a complex number is two double arrays under the hood for
performance, and wraps the Apache Commons Math library. If someone wants to
use complex numbers, they have to use core.matrix. Yes, it involves taking
on a whole library, but at least you can accomplish complex linear algebra.
On Tuesday, April 28, 2015 at 11:56:54 PM UTC-4, Mikera wrote:
You can do virtually all of that already with the Apache commons Complex
class. Any Java object can be just fine used with map / reduce / filter /
seqs etc.
If you want to avoid Java interop and make things more Clojure-like then
a lightweight wrapper library is all that is needed (my suggestion b) ).
You could probably also support tagged reader literals for complex numbers
pretty easily.
The only problem would be supporting complex types in numerical
clojure.core/+. That is very unlikely to happen - I doubt Rich and co want
to start adding complexity to the core functions which would hurt
performance and break the assumptions that people have about the numerical
functions in clojure.core. But that isn't ultimately a big problem, you can
just use a specialised addition operator like clojure.complex/+ or
clojure.core.matrix.operators/+ instead when you write complex-using code.
That's part of my suggestions b) and c), basically to have separate APIs
that understand complex types.
On Tuesday, 28 April 2015 19:42:23 UTC+8, Nik wrote:
What I would like is a complex type that plays well with Clojure's
generic abstractions and functional style (much like Ratio), and is
indistinguishable from other types - for example, the ability to work with
(map/reduce/filter), the ability to be a part of seqs and use Clojure core
functions on it, and so on. It might not as efficient as the complex type
in, say C++, but depending on your definition of reasonable, it might be
acceptable. I am willing to explore this further.
.
On Tuesday, April 28, 2015 at 12:22:08 AM UTC-4, Mikera wrote:
Complex numbers are tricky because:
- They need to be fast in order to be useful for numerical computing.
The obvious implementations that you might create with boxed values,
vectors/maps, multimethods and protocols are likely to be unacceptable for
many use cases
- You still want to be able to use them in a generic way, with
operations that play nicely with other values (Doubles etc.)
I have thought about this a lot w.r.t. core.matrix and have come to the
conclusion that there is no simple, elegant answer that meets all use cases.
What I'd like to suggest is:
a) The community converge on a single, minimal, lightweight
representation for a boxed complex scalar value. This is probably best as a
Java class (for easy interop with Java libraries). I think
http://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math3/complex/Complex.html
is a good candidate
b) A lightweight wrapper library that provides nice complex functions in
Clojure, using the above type. Nothing fancy. But can make extensive use of
type hints etc. for performance so should be pretty fast
c) A library using core.matrix that implements complex vectors, complex
matrices etc but also uses a) for complex scalar values. This should use a
underlying double-array backed implementation for performance, probably
vectorz-clj would be best (though that could be hidden as an implementation
detail). This library would also implement all the core.matrix protocols
for the chosen complex number type, mostly just by calling b) directly
On Monday, 27 April 2015 23:39:34 UTC+8, Nik wrote:
I have been thinking along the lines of mikera and Maik - and it seems
like there is no further progress here? I would like to take a crack at
creating a complex number type, but implemented as a library to Clojure. I
am not sure where to start, and if anyone here has suggestions, I'd be
happy to hear them.
A complex number could simply be a vector of two elements, or a map
with :real and :imag keys (or something lightweight) - and I am not sure
what it would require to make this type work happily with code arithmetic
functions in Clojure and Java Math.
It would also have to work with seq operations in Clojure - for
instance:
If I have a complex number c = {:real 3 :imag 4}, and a vector v = [1
-2 c], it would be nice to have the call 'map #(Math/abs %) v' produce (1
2
5).
I am having trouble figuring out all the pieces that need to be
implemented. Is it even possible to implement this as a library, or does
this need to be a part of clojure.core?
--
Re: complex numbers in clojure
Hi
Before we try to guess what Rich will or won't think or want, are you
interested in a proof of concept? So we could evaluate performance and
complexity issues before the subject is definitively buried.
What do you think about it?
Plínio
On Wed, Apr 29, 2015 at 12:56 AM, Mikera mike.r.anderson...@gmail.com
wrote:
You can do virtually all of that already with the Apache commons Complex
class. Any Java object can be just fine used with map / reduce / filter /
seqs etc.
If you want to avoid Java interop and make things more Clojure-like then
a lightweight wrapper library is all that is needed (my suggestion b) ).
You could probably also support tagged reader literals for complex numbers
pretty easily.
The only problem would be supporting complex types in numerical
clojure.core/+. That is very unlikely to happen - I doubt Rich and co want
to start adding complexity to the core functions which would hurt
performance and break the assumptions that people have about the numerical
functions in clojure.core. But that isn't ultimately a big problem, you can
just use a specialised addition operator like clojure.complex/+ or
clojure.core.matrix.operators/+ instead when you write complex-using code.
That's part of my suggestions b) and c), basically to have separate APIs
that understand complex types.
On Tuesday, 28 April 2015 19:42:23 UTC+8, Nik wrote:
What I would like is a complex type that plays well with Clojure's
generic abstractions and functional style (much like Ratio), and is
indistinguishable from other types - for example, the ability to work with
(map/reduce/filter), the ability to be a part of seqs and use Clojure core
functions on it, and so on. It might not as efficient as the complex type
in, say C++, but depending on your definition of reasonable, it might be
acceptable. I am willing to explore this further.
.
On Tuesday, April 28, 2015 at 12:22:08 AM UTC-4, Mikera wrote:
Complex numbers are tricky because:
- They need to be fast in order to be useful for numerical computing.
The obvious implementations that you might create with boxed values,
vectors/maps, multimethods and protocols are likely to be unacceptable for
many use cases
- You still want to be able to use them in a generic way, with
operations that play nicely with other values (Doubles etc.)
I have thought about this a lot w.r.t. core.matrix and have come to the
conclusion that there is no simple, elegant answer that meets all use cases.
What I'd like to suggest is:
a) The community converge on a single, minimal, lightweight
representation for a boxed complex scalar value. This is probably best as a
Java class (for easy interop with Java libraries). I think
http://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math3/complex/Complex.html
is a good candidate
b) A lightweight wrapper library that provides nice complex functions in
Clojure, using the above type. Nothing fancy. But can make extensive use of
type hints etc. for performance so should be pretty fast
c) A library using core.matrix that implements complex vectors, complex
matrices etc but also uses a) for complex scalar values. This should use a
underlying double-array backed implementation for performance, probably
vectorz-clj would be best (though that could be hidden as an implementation
detail). This library would also implement all the core.matrix protocols
for the chosen complex number type, mostly just by calling b) directly
On Monday, 27 April 2015 23:39:34 UTC+8, Nik wrote:
I have been thinking along the lines of mikera and Maik - and it seems
like there is no further progress here? I would like to take a crack at
creating a complex number type, but implemented as a library to Clojure. I
am not sure where to start, and if anyone here has suggestions, I'd be
happy to hear them.
A complex number could simply be a vector of two elements, or a map
with :real and :imag keys (or something lightweight) - and I am not sure
what it would require to make this type work happily with code arithmetic
functions in Clojure and Java Math.
It would also have to work with seq operations in Clojure - for
instance:
If I have a complex number c = {:real 3 :imag 4}, and a vector v = [1
-2 c], it would be nice to have the call 'map #(Math/abs %) v' produce (1 2
5).
I am having trouble figuring out all the pieces that need to be
implemented. Is it even possible to implement this as a library, or does
this need to be a part of clojure.core?
--
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
Re: How do we use a container class with a proxy?
Hi Elric, Since Clojure is untyped, you can just totally ignore the type parameter: (proxy [FooInitializer] [] (method [...])) Methods which accept or return F in the Java class will accept or return Object in Java, which is what happens under the hood anyway - type erasure means the type params are a figment of javac's imagination. Cheers, Colin On 29 April 2015 at 17:39, Elric Erkose elric.erk...@gmail.com wrote: How do we use a container class with a proxy? Given the following class signature, how would we write the proxy? ```java public abstract class FooInitializerF extends Foo ``` ```clojure (proxy [FooInitializer ???] [] ``` -- 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: wondering the reasons to choose defrecord vs reify in stuartsierra/component
Hi Stuart, Components are records in order to support the dependency-injection features of `component/start-system`, which work via `assoc`. That was the only reason that I could imagine but I wanted to double checked here :) I'm always inclined to think in performance reasons that I don't know yet I was thinking in having a protocol to replace this practical `assoc` behaviour of defrecor. So we can get components working with a global state tree structure instead of local state Thanks for having the time to answer this question! Juan 2015-04-29 18:04 GMT+02:00 Stuart Sierra the.stuart.sie...@gmail.com: Hi Juan, Components are records in order to support the dependency-injection features of `component/start-system`, which work via `assoc`. There are potentially many other ways to do dependency injection, but I found `assoc` to be practical. If you want to create a component that has a Lifecycle but no dependencies, then `reify` will work just fine. If you want to create a component that has dependencies but no Lifecycle, then an ordinary Clojure map will work. –S On Wednesday, April 29, 2015 at 2:41:54 PM UTC+1, Juan A. Ruz @tangrammer wrote: Hi guys, I'm just wondering the pros/contras that justify to choose defrecord vs reify as component fn constructor. in the component README we can read To create a component, define a Clojure record that implements the Lifecycle protocol. Yes I know that defrecord creates an immutable persistent map which implements a protocol. but I think that the same thing can be achieved with reify (BTW: om way to define component) over a persistent map... Do you think there are more reasons to set defrecord as default base fn for components? Thanks in advance Juan -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/xqU_JSFWK-k/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/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: wondering the reasons to choose defrecord vs reify in stuartsierra/component
Hi Juan, Components are records in order to support the dependency-injection features of `component/start-system`, which work via `assoc`. There are potentially many other ways to do dependency injection, but I found `assoc` to be practical. If you want to create a component that has a Lifecycle but no dependencies, then `reify` will work just fine. If you want to create a component that has dependencies but no Lifecycle, then an ordinary Clojure map will work. –S On Wednesday, April 29, 2015 at 2:41:54 PM UTC+1, Juan A. Ruz @tangrammer wrote: Hi guys, I'm just wondering the pros/contras that justify to choose defrecord vs reify as component fn constructor. in the component README we can read To create a component, define a Clojure record that implements the Lifecycle protocol. Yes I know that defrecord creates an immutable persistent map which implements a protocol. but I think that the same thing can be achieved with reify (BTW: om way to define component) over a persistent map... Do you think there are more reasons to set defrecord as default base fn for components? Thanks in advance Juan -- 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: [ANN][book] Clojure Reactive Programming
Started reading the book this week. I'm enjoying it a lot. Thank you for writing it. -- 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: complex numbers in clojure
Ideally math APIs would be cross-platform #ClojureScript -- 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: complex numbers in clojure
Let me first say I would definitely like to see complex arithmetic support in Clojure. Major hole for scientific computing in my opinion. And with the momentum that Clojure has in ML / data science, I think it's one that needs patching. As to you specific point Nik: For me, having complex numbers not work seamlessly with other numbers and core arithmetic ops is not viable. Doing arithmetic ops with any kind of number is a real (pardon the pun) use case. I believe what's being suggested here is that any functions that might live in a specialized namespace would still support arithmetic between any combination of standard numeric types and the added complex type. The usage I envision, and which I imagine is being envisioned by others, is that you would require + - * / etc from this special namespace, and they'd serve as drop in replacements for the standard functions, except that they support complex types as well. This is roughly how core.matrix works (hat tip to M. Anderson, once again), and should be fine here as well. The only slightly tricky thing would be making sure that core.matrix, complex numbers and the standard numerics could all work together. Seems like one of core.matrix or the complex library will have to know about the other... Unless someone has a clever idea around this? Chris -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To 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: complex numbers in clojure
Yes, it would be nice to have this available for cljs as well. With the new reader literals though, this doesn't preclude having a native java implementation that gets loaded in the :clj case, and some other implementation that gets loaded in the :cljs case. On Wednesday, April 29, 2015 at 2:06:54 PM UTC-7, nodename wrote: Ideally math APIs would be cross-platform #ClojureScript -- 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.
wondering the reasons to choose defrecord vs reify in stuartsierra/component
Hi guys, I'm just wondering the pros/contras that justify to choose defrecord vs reify as component fn constructor. in the component README we can read To create a component, define a Clojure record that implements the Lifecycle protocol. Yes I know that defrecord creates an immutable persistent map which implements a protocol. but I think that the same thing can be achieved with reify (BTW: om way to define component) over a persistent map... Do you think there are more reasons to set defrecord as default base fn for components? Thanks in advance Juan -- 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 do we use a container class with a proxy?
Thank you for your reply. -- 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: wondering the reasons to choose defrecord vs reify in stuartsierra/component
Often because components contain some form of data. For instance, a component that handles database connection may have a database connection instance. Reify produces objects that are essentially opaque, which is fine if you just want their behaviour, as in the case of Om, but not so good if you also want to carry around some form of data. Records are even useful for components that aren't usually dependencies, like a web server. Even though you may only need to start and stop the server component, it's often useful for debugging or monitoring purposes to be able to query the options that the server was set up with. - James On 29 April 2015 at 14:41, Juan A. Ruz @tangrammer juanantonio...@gmail.com wrote: Hi guys, I'm just wondering the pros/contras that justify to choose defrecord vs reify as component fn constructor. in the component README we can read To create a component, define a Clojure record that implements the Lifecycle protocol. Yes I know that defrecord creates an immutable persistent map which implements a protocol. but I think that the same thing can be achieved with reify (BTW: om way to define component) over a persistent map... Do you think there are more reasons to set defrecord as default base fn for components? Thanks in advance Juan -- 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.
[ANN] Ubergraph 0.1.0
https://github.com/Engelberg/ubergraph Ubergraph is a versatile, general-purpose graph data structure for Clojure. It is designed to complement and extend Loom, a popular Clojure collection of graph protocols and algorithms. Ubergraph implements all of Loom's protocols and draws them together in one namespace, making it a one-stop, batteries-included graph implementation. But more importantly, Ubergraph goes beyond Loom's protocols, allowing a mixture of directed and undirected edges within a single graph, multiple parallel edges between a given pair of nodes (aka multigraphs), multiple weight attributes per edge, and changeable weights. The ubergraph.alg namespace contains an assortment of algorithms compatible with graphs, digraphs, multigraphs, and multidigraphs (and backwards-compatible with Loom graphs). A highlight of the ubergraph.alg namespace is its feature-rich shortest-paths algorithm, which supports a number of useful search options: edge filters, node filters, goal predicates, multiple starting nodes, multiple ending nodes, using any attribute or function as the cost for an edge, and more. -- 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.
Minimum Viable Database Component
Hi All, I'm trying to follow the component architecture for an app I'm working on and wondered if I was missing something. In the Just enough structure talk, one of the examples Stuart presents is a DB component that contains just a small selection of DB related functions (i.e. insert, and query IIRC) so that when you need to mock it out for your tests, you don't have to implement the entire JDBC interface. This makes sense but I'm wondering if anyone has released such a subset (possibly expanded to include things like transactions, and maybe a few utility query builders) as open source ideally with a corresponding mock implementation. With the popularity of the component library, I'm surprised not to find ready made components I can just plug into my app. If there's nothing like this already, then I guess I have an idea for a new project. Anyone think this is a good idea or would everyone's ideal DB component look a little different? Look forward to hearing your thoughts. Cheers, Andy -- 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: wondering the reasons to choose defrecord vs reify in stuartsierra/component
Hi James I got this question after watching the David Nolen's video called The Functional Final Frontier https://www.youtube.com/watch?v=DMtwq3QtddYfeature=youtu.bet=663. Around minute 11th he talked about Local state is poison https://awelonblue.wordpress.com/2012/10/21/local-state-is-poison/ idea and how he tried (using cursors) to remove this local state from Om design After those David Nolen design ideas, it seems to me that stuartsierra/component is inclined on local state (Managed lifecycle of stateful objects in Clojure) more than global tree structure state... Thanks for your clarification! Juan 2015-04-29 16:38 GMT+02:00 James Reeves ja...@booleanknot.com: Often because components contain some form of data. For instance, a component that handles database connection may have a database connection instance. Reify produces objects that are essentially opaque, which is fine if you just want their behaviour, as in the case of Om, but not so good if you also want to carry around some form of data. Records are even useful for components that aren't usually dependencies, like a web server. Even though you may only need to start and stop the server component, it's often useful for debugging or monitoring purposes to be able to query the options that the server was set up with. - James On 29 April 2015 at 14:41, Juan A. Ruz @tangrammer juanantonio...@gmail.com wrote: Hi guys, I'm just wondering the pros/contras that justify to choose defrecord vs reify as component fn constructor. in the component README we can read To create a component, define a Clojure record that implements the Lifecycle protocol. Yes I know that defrecord creates an immutable persistent map which implements a protocol. but I think that the same thing can be achieved with reify (BTW: om way to define component) over a persistent map... Do you think there are more reasons to set defrecord as default base fn for components? Thanks in advance Juan -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/xqU_JSFWK-k/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/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.
