Re: New ring middleware: browser-caching
Hello Stephen, Couple of comments about code: Instead of not nil? you can use some? since clojure 1.6: user= (doc some?) - clojure.core/some? ([x]) Returns true if x is not nil, false otherwise. str/split and get by 0 may result in error: user= (str/split : #:) [] user= ((str/split : #:) 0) clojure.core/eval core.clj: 3081 ... user/eval10817 form-init2396972653997124309.clj:1 ... java.lang.IndexOutOfBoundsException: Better use some- and first: user= (doc some-) - clojure.core/some- ([expr forms]) Macro When expr is not nil, threads it into the first form (via -), and when that result is not nil, through the next etc like user= (some- : (str/split #:) first) nil Also It will be helpful to add pre condition or other validation to wrap-browser-caching fn to check if filetypes is a map. Best regards, Eduard On Monday, July 27, 2015 at 5:54:03 AM UTC+3, Stephen Lester wrote: Hello everyone, I just wrote my first ring middleware (I'm pretty much a newbie to functional programming and Clojure in general), and I'd appreciate if someone wants to give me some tips or constructive criticism (and it can be off-list as well). The goal is to enable per-file-type browser caching hints. I had found some other plugins that either set it to 0 (no-cache) or did it based on server response code, but none that took into account filetype. I was inspired by a similar thing Apache can do. A big thank you to this community! #clojure on Freenode has been amazing, and most of the time this list is a very interesting read. https://github.com/slester/browser-caching -- 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: Java 8 Lambda Interop
Which seems unlikely given the conservatism of Clojure development. More than that, it would mean that Clojure required Java 8. On 28 July 2015 at 05:23, Mikera mike.r.anderson...@gmail.com wrote: Ah, I get what you are doing now. Don't think that is likely to work unless Clojure starts making IFn instances implement the right java.util.function.* interfaces. Which seems unlikely given the conservatism of Clojure development. Having said that, I do think it is possible, have been playing around with a little toy language implementation that does something similar. I think you are better off for now writing a function or macro that allows you to wrap a Clojure function as a java.util.function.Predicate and lets you do something like: (.filter (predicate odd?)) On Tuesday, 28 July 2015 09:53:25 UTC+8, Andrew Oberstar wrote: Mikera, I think you're addressing a different interop concern. I'm particularly interested in something like this: (- (IntStream/range 0 100) (.filter odd?) (.limit 5) (.collect Collectors/toList)) Where odd? is a normal Clojure IFn that I want to use when calling a Java API that expects something implementing a single-method-interface (Predicate in this case). Right now I need to do something like this: (defn lambda [f] (reify Predicate (test [x] (f x (- (IntStream/range 0 100) (.filter (lambda odd?)) (.limit 5) (.collect Collectors/toList)) Andrew Oberstar On Mon, Jul 27, 2015 at 8:16 PM Mikera mike.r.an...@gmail.com wrote: It could certainly be achieved in the Clojure compiler, by allowing (some-functional-interface .) to compile to the appropriate function call even if it doesn't implement IFn It would be quite a big change though and would probably have some limitations, e.g.: a) It probably wouldn't work with regular vars since it wouldn't be able to handle re-binding b) You would probably have to type hint the some-functional-interface object in some way so that the compiler knows to do this at compile time A less invasive option would be to just have some code to wrap functional interfaces in an appropriate IFn. Worth a JIRA ticket for consideration at least? On Tuesday, 28 July 2015 08:52:47 UTC+8, Andrew Oberstar wrote: Thanks for the reply Gary. Sounds like I'm on as good a track as I can be with current Clojure. I am curious though why you say that it is unrealistic for IFn to support arbitrary @FunctionalInterface. It certainly seems like it would require compiler changes, but I would think that either through emitting bytecode closer to Java 8 lambdas or through some form of type coercion it would possible. For example, Groovy just coerces their Closures to any Single Abstract Method type. I'm not sure how java.util.function.* as protocols would work, but still would require implementing for each SAM you come across. IFn as a protocol seems to address a different interop use case. Maybe for receiving a Java lambda you want to use as if it's a Clojure function. Most of the Java interop from Clojure is slick (sometimes more clear than in Java itself), it would be unfortunate to leave functions as second-class citizens for interop. Granted, there may be a simplicity argument against this (maybe that's why Java varargs require an explicit array?). Andrew Oberstar On Mon, Jul 27, 2015 at 4:16 AM Gary Verhaegen gary.ve...@gmail.com wrote: On Sunday, 26 July 2015, Andrew Oberstar ajobe...@gmail.com wrote: Hi, I'm wondering if anyone has a good approach for making calls from Clojure to Java APIs (e.g. Stream API) that expect a @FunctionalInterface type. Ideally, IFn would transparently work, but I'm guessing that requires some compiler changes. Right now, the best I can think of is a function or macro to reify a wrapper around a Clojure function to implement all of the usual interfaces from java.util.function. Anyone have any better ideas? Andrew Oberstar You're probably aware of this, but @FunctionalInterface is not a type, it's an annotation. All it does is ensure, at compile time, that the annotated element is an interface with a single non-default and non-static method. At the type-system level, it's just an interface like any other, and the lambda syntax is just a shorthand for an anonymous instance of a well-defined type. Since the lambda syntax is java-compiler magic, you can't access it from Clojure, and the most straightforward option right now is to actually know which type is expected, e.g.: user= (- (doto (java.util.ArrayList.) (.add 1) (.add 2)) (.stream) (.map (reify java.util.function.Function (apply [_ arg] (inc arg (.collect (java.util.stream.Collectors/toList))) [2 3] user= As neither IFn nor Function are Clojure protocols, I do indeed think you're best bet is a macro to essentially generate the above reify. You can of course do a single macro that reifies to all of the protocols that you need. I don't think it's
Re: a question about Chris Zheng's Abstract Container Pattern
Hey guys, Thanks for the feedback and your very insightful comments. Yep... this is OO alright =) I realised only after I wrote the article that I was implementing a Lifecycle clone with IRunnable example. However, the concept I am mentioning is much more general than components in terms of its scope: A similar `abstract class` for a reflective functional dispatch mechanism is defined here: https://github.com/zcaudate/iroh/blob/master/src/iroh/types/element.clj and extended by the `concrete classes' here: https://github.com/zcaudate/iroh/tree/master/src/iroh/element In the case of iroh... if I had used strictly multimethods, I would have been very confused. If I had used strictly protocols... well I couldn't for a number of reasons.. but if I did, I would have been even more confused because of the number of subconditions that I had to implement. iroh was the first library that I had built that used this pattern and it was so successful that I've been repeating the process over and over again since. What I wanted to achieve was to have the equivalent of an `abstract class` - the concept of code with abstract functionality that provides a framework for the heavy lifting to be done. `Concrete classes` can just extend aforementioned `abstract class` with minimal code and get all of the benefits. I've used this pattern with great success in many, many times and it provides a counter balance to the functional paradigm in terms of packaging up functionality. Clojure doesn't force us into one paradigm or the other and sometimes it is just more stylish to use the OO paradigm. The whole point of OO, multimethods and protocols is to do polymorphic dispatch, which is just a way to break a large cond statement into pieces that can then also be further extended. Please also note that not all OO frameworks are equal. Java uses a class inheritence approach whereas javascript uses a prototype model. The `abstract container` pattern that I was describing is probably closer to the JS model but to be honest, I don't really know what it is. Ultimately, it adds a middle tier of functionality in systems that have a plugin type mechanism. I'm sure there are equivalent functional contructs... but that was not the point of the pattern. This pattern has been very useful for me; clojure's protocols and multimethods were not enough to do what I needed to do - but combination of the two works wonders =) Since the article, the pattern has been codified here: https://github.com/zcaudate/hara/blob/master/src/hara/extend/abstract.clj#L196 Hope that helps in clarifying the motivation behind the article and the pattern Chris On Monday, July 27, 2015 at 11:42:21 PM UTC+5:30, Colin Yates wrote: I think his last sentence gives you the answer: A warm shoutout to Tushar, Lyndon, Dean, Alan, Hank, Derek, and all the guys at clj-melb that gave feedback and helped flesh out this rehash of *OO design*.” (my emphasis) He wanted an OO approach and has implemented one; specifically behaviour and state coupled together. I think neither Typed Clojure nor Contracts would have achieved this guy’s goal as they are about enforcing a contract (either the shape of data or effects of a fn) in the ‘functional’ paradigm; this guy clearly wanted something in the OO paradigm. Is there a ‘functional’ implementation which gives the same benefits; sure, but that isn’t what he wanted. Are there a bunch of ‘upgrades’ that I am sure we could all apply; sure, but again it seems like he was setting out with a very specific goal in mind and has achieved that. On 27 Jul 2015, at 18:37, Lawrence Krubner lawr...@rollioforce.com javascript: wrote: I have a question about this: Servers that are running on a particular port can be tracked and stopped. I have to say, this was the feature that I wanted the most, which motivated the framework's design. The annoying thing about development in emacs is that I have to be careful of not losing the reference to the server. Since there was no way of stopping it unless the repl is restarted. I wanted to implement a registery for references to running servers to be saved. http://z.caudate.me/the-abstract-container-pattern/ I have the impression that he's going over the same territory as that covered by Stuart Sierra, though Zheng doesn't mention Component nor Sierra. But he offers this as an example of what he's after: (defprotocol IRunnable (start! [system]) (stop! [system]) (restart! [system]) (started? [system]) (stopped? [system])) That much seems similar to Sierra's system. Zheng seems to add an additional layer by simulating an abstract class above his protocols. As he says: - A single deftype acts as the *abstract container*, extending one or more protocols - A set of methods defined through defmulti that is used within the deftype form act as *abstract methods* - The *abstract methods* all
[ANN] clojure.tools.cli 0.3.2 (was: Next release for clojure.tools.cli? Is it dead?
clojure.tools.cli — tools for working with command line arguments https://github.com/clojure/tools.cli I’m pleased to announce that Sung Pae has passed the torch on to me and I have released version 0.3.2 to Maven Central today. Thank you Sung for all your work on tools.cli so far! This release includes all of Sung’s work to date, including TCLI-9 which Keith Irwin asked about last week: • Release 0.3.2 on 2015-07-28 • Add :no-defaults to parse-opts: Returns sequence of options that excludes defaulted ones. This helps support constructing options from multiple sources (command line, config file). • Add get-default-options: Returns sequence of options that have defaults specified. • Support multiple validations TCLI-9 • Support in-order arguments TCLI-5: :in-order processes arguments up to the first unknown option; A warning is displayed when unknown options are encountered. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) On Jul 23, 2015, at 9:33 PM, Keith Irwin ke...@zentrope.com wrote: There are some handy additions committed to the tools.cli project at: https://github.com/clojure/tools.cli but there hasn’t been a release in ~1.5 years (not even a snapshot release). In fact, these commits have been sitting there for over a year. I’m especially interested in this one: http://dev.clojure.org/jira/browse/TCLI-9 Any chance of a new release? -- 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.
Small parsing bug in data.json - advice sought
Hello. I'm interested in fixing this bug: http://dev.clojure.org/jira/browse/DJSON-21 data.json/read currently reads from the start of a java.io.Reader and as soon as it has a read and parsed a complete form it returns it. This is good and logical but it leads to input like 123abc being parsed successfully as 123, which is confusing enough that the bug has been raised. Whitespace after a form like that would be fine, (ie (read-str123 ) = 123). So my questions: - Is it a sensible idea to consume the Reader until EOF checking that there's only whitespace remaining? - Can we just live with this bug as-is? - Is there a middle ground? (eg checking the next n bytes for non-whitespace then stopping) - Would it make sense if we treat 'read-str differently from 'read in this case? Thanks. Matthew -- 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] Pink 0.2.0, Score 0.3.0
This is so cool =) Can you put up a video? -- 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: a question about Chris Zheng's Abstract Container Pattern
On 29 July 2015 at 01:07, zcaudate z...@caudate.me wrote:
The example in the article is probably the smallest example I can come up
with.
http://z.caudate.me/the-abstract-container-pattern
The code for the concrete implementations speaks for itself I think, it is
about 10 lines to hook in jetty and http-kit to the framework.
I'm afraid I don't see the benefit of having two tiers of abstraction in
your example. I think you could achieve the same result with a simpler
architecture.
For example, consider a protocol:
(defprotocol Lifecycle
(-start [service])
(-stop [service]))
We can add additional functionality around this simply by wrapping the
protocol methods with functions:
(defn start [service]
(if (:started? service)
service
(- service -start (assoc :started? true
(defn stop [service]
(if-not (:started? service)
service
(- service -stop (dissoc :started?
So in this case we're adding idempotence and a key to determine whether or
not the service has been started. We assume that a service is a record that
implements Lifecycle.
We could also conceive of a function that globally registers services for
convenience:
(def running-services (atom #{}))
(defn register! [service]
(swap! running-services conj service))
(defn deregister! [service]
(swap! running-services disj service))
Then work that into the start and stop functions:
(defn start [service]
(if (:started? service)
service
(- service -start (assoc :started? true) (doto register!
(defn stop [service]
(if-not (:started? service)
service
(- service (doto deregister!) -stop (dissoc :started?
Now, if we actually want to create a service for an adapter like Jetty:
(defrecord JettyService [handler options]
Lifecycle
(-start [service]
(assoc service :instance (run-jetty handler (assoc options :join?
false)))
(-stop [service]
(.stop (:instance service))
(dissoc service :instance)))
Unless I've missed something, that seems like broadly equivalent
functionality, but with arguably less complexity. We stick with functions
for the most part, and only use polymorphism where it's necessary.
- James
--
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: Java 8 Lambda Interop
My use case isn't a particularly great one at that minute. It mainly just seemed like an unfortunate extra step to interacting with Java APIs. Essentially, I was trying to leverage APIs that return a Java Stream, but wanted to interact with them with Clojure goodness, like map/reduce/transduce. I ended up extending CollReduce to support BaseStream. The lambda interaction is a pretty minimal portion of that code, being a little more heavy in the supporting tests. Most of my interest is projecting into the future and presuming that more Java APIs will expect SAM arguments. If that is the case, it seems like a beneficial thing to support in Clojure. Though it depends on the impact to the compiler. I can see the argument either way. Andrew Oberstar On Mon, Jul 27, 2015 at 9:49 PM Sean Corfield s...@corfield.org wrote: I think Mike was suggesting something like this: (- (IntStream/range 0 100) (.filter ^Predicate odd?) (.limit 5) (.collect Collectors/toList)) and having the Clojure compiler figure out that you’re trying to cast an IFn to a functional interface and therefore do the magic for you. I don’t know whether this is even feasible (FWIW, I certainly don’t think it is desirable). The compiler would have to know about all the possible functional interfaces in order to reify them behind the scenes for you (since each one has a different method name, so something needs to know how to get from the Java interface type to the method name behind it). I’m not sure I get your use case — if you’re dealing with that much Java interop it seems like it might be a good idea to create a DSL (functions, maybe macros) that make the code cleaner and hide the low-level details of Java interop anyway. Besides, your example sounds like something Clojure can already do natively and much more cleanly. Can you perhaps give us more detailed motivation for what you’re trying to achieve? Perhaps there’s a cleaner way altogether…? Sean On Jul 27, 2015, at 6:53 PM, Andrew Oberstar ajobers...@gmail.com wrote: Mikera, I think you're addressing a different interop concern. I'm particularly interested in something like this: (- (IntStream/range 0 100) (.filter odd?) (.limit 5) (.collect Collectors/toList)) Where odd? is a normal Clojure IFn that I want to use when calling a Java API that expects something implementing a single-method-interface (Predicate in this case). Right now I need to do something like this: (defn lambda [f] (reify Predicate (test [x] (f x (- (IntStream/range 0 100) (.filter (lambda odd?)) (.limit 5) (.collect Collectors/toList)) Andrew Oberstar On Mon, Jul 27, 2015 at 8:16 PM Mikera mike.r.anderson...@gmail.com wrote: It could certainly be achieved in the Clojure compiler, by allowing (some-functional-interface .) to compile to the appropriate function call even if it doesn't implement IFn It would be quite a big change though and would probably have some limitations, e.g.: a) It probably wouldn't work with regular vars since it wouldn't be able to handle re-binding b) You would probably have to type hint the some-functional-interface object in some way so that the compiler knows to do this at compile time A less invasive option would be to just have some code to wrap functional interfaces in an appropriate IFn. Worth a JIRA ticket for consideration at least? On Tuesday, 28 July 2015 08:52:47 UTC+8, Andrew Oberstar wrote: Thanks for the reply Gary. Sounds like I'm on as good a track as I can be with current Clojure. I am curious though why you say that it is unrealistic for IFn to support arbitrary @FunctionalInterface. It certainly seems like it would require compiler changes, but I would think that either through emitting bytecode closer to Java 8 lambdas or through some form of type coercion it would possible. For example, Groovy just coerces their Closures to any Single Abstract Method type. I'm not sure how java.util.function.* as protocols would work, but still would require implementing for each SAM you come across. IFn as a protocol seems to address a different interop use case. Maybe for receiving a Java lambda you want to use as if it's a Clojure function. Most of the Java interop from Clojure is slick (sometimes more clear than in Java itself), it would be unfortunate to leave functions as second-class citizens for interop. Granted, there may be a simplicity argument against this (maybe that's why Java varargs require an explicit array?). Andrew Oberstar On Mon, Jul 27, 2015 at 4:16 AM Gary Verhaegen gary.ve...@gmail.com wrote: On Sunday, 26 July 2015, Andrew Oberstar ajobe...@gmail.com wrote: Hi, I'm wondering if anyone has a good approach for making calls from Clojure to Java APIs (e.g. Stream API) that expect a @FunctionalInterface type. Ideally, IFn would transparently work, but I'm guessing that requires some compiler changes. Right now, the best I can think of is a function or
Re: a question about Chris Zheng's Abstract Container Pattern
The example in the article is probably the smallest example I can come up
with.
http://z.caudate.me/the-abstract-container-pattern
The code for the concrete implementations speaks for itself I think, it is
about 10 lines to hook in jetty and http-kit to the framework.
if we think about how much code an interface/abstract/concrete design
pattern can potentially reduce over a strict interface/concrete design
pattern in the java, then it's exactly the same with clojure.
One particular benefit of this particular pattern that I am exploiting is
the fact that you can then specify exactly what you want in the config. I'm
a big fan of making everything explicitly clear within the config itself so
if we have a system with some a component-style dependency injection model
(see http://docs.caudate.me/hara/hara-component.html), you can easily do
something like this to get a jetty server up:
{:server {:type :jetty
:port 8080}
and if you want a :http-kit server, you just change the config as such:
{:server {:type :http-kit
:port 8080}
I've done this quite a bit with mocking... for example, here -
https://github.com/MyPost/cassius/blob/master/src/cassius/component.clj
changing
{:db {:type :database}}
to
{:db {:type :mock}}
will work exactly the same way, irrespective of dependency injection
framework - in this case, I'm using the stuartsierra/component framework.
On Tuesday, July 28, 2015 at 9:34:46 PM UTC+5:30, James Reeves wrote:
What are the benefits of designing an abstract class in this way,
compared to, say, using a protocol and normal functions? Could you provide
a small example?
- James
On 28 July 2015 at 10:09, zcaudate z...@caudate.me javascript: wrote:
Hey guys,
Thanks for the feedback and your very insightful comments.
Yep... this is OO alright =)
I realised only after I wrote the article that I was implementing a
Lifecycle clone with IRunnable example. However, the concept I am
mentioning is much more general than components in terms of its scope:
A similar `abstract class` for a reflective functional dispatch mechanism
is defined here:
https://github.com/zcaudate/iroh/blob/master/src/iroh/types/element.clj
and extended by the `concrete classes' here:
https://github.com/zcaudate/iroh/tree/master/src/iroh/element
In the case of iroh... if I had used strictly multimethods, I would have
been very confused. If I had used strictly protocols... well I couldn't for
a number of reasons.. but if I did, I would have been even more confused
because of the number of subconditions that I had to implement. iroh was
the first library that I had built that used this pattern and it was so
successful that I've been repeating the process over and over again since.
What I wanted to achieve was to have the equivalent of an `abstract
class` - the concept of code with abstract functionality that provides a
framework for the heavy lifting to be done. `Concrete classes` can just
extend aforementioned `abstract class` with minimal code and get all of the
benefits.
I've used this pattern with great success in many, many times and it
provides a counter balance to the functional paradigm in terms of packaging
up functionality. Clojure doesn't force us into one paradigm or the other
and sometimes it is just more stylish to use the OO paradigm. The whole
point of OO, multimethods and protocols is to do polymorphic dispatch,
which is just a way to break a large cond statement into pieces that can
then also be further extended.
Please also note that not all OO frameworks are equal. Java uses a class
inheritence approach whereas javascript uses a prototype model. The
`abstract container` pattern that I was describing is probably closer to
the JS model but to be honest, I don't really know what it is. Ultimately,
it adds a middle tier of functionality in systems that have a plugin type
mechanism. I'm sure there are equivalent functional contructs... but that
was not the point of the pattern. This pattern has been very useful for me;
clojure's protocols and multimethods were not enough to do what I needed to
do - but combination of the two works wonders =)
Since the article, the pattern has been codified here:
https://github.com/zcaudate/hara/blob/master/src/hara/extend/abstract.clj#L196
Hope that helps in clarifying the motivation behind the article and the
pattern
Chris
On Monday, July 27, 2015 at 11:42:21 PM UTC+5:30, Colin Yates wrote:
I think his last sentence gives you the answer:
A warm shoutout to Tushar, Lyndon, Dean, Alan, Hank, Derek, and all
the guys at clj-melb that gave feedback and helped flesh out this rehash of
*OO
design*.” (my emphasis)
He wanted an OO approach and has implemented one; specifically behaviour
and state coupled together. I think neither Typed Clojure nor Contracts
would have achieved this guy’s goal as they are about enforcing a
Re: [ANN] Clojure 1.8.0-alpha2
I use agents instead of atoms when the function altering the value has side
effects, or is especially expensive (and thus should not retry).
I haven't had to use refs yet, but my use case would be if the mutable data
has enough parallel modification that splitting one atomic map into
separate ref maps would be a performance boost.
On Monday, July 27, 2015 at 11:00:56 PM UTC-7, Daniel Compton wrote:
I think this is pretty unlikely. While megarefs look very cool, I'm not
sure what the benefit to having these directly in Clojure would be over
having them in a library.
Anecdotally, everyone I have talked to about Clojure's reference types
have said that they have never needed to use ref's or agents in real world
code (I'm sure some people have to good effect though).
That being said, you can always open a JIRA or design doc about this if
you feel strongly about it to start a discussion.
--
Daniel.
On Tue, 28 Jul 2015 at 9:05 AM Lawrence Krubner lawr...@rollioforce.com
javascript: wrote:
Off topic, but I wonder if there was ever any discussion of megarefs
being added to Clojure?
https://github.com/cgrand/megaref
On Tuesday, July 21, 2015 at 3:30:46 PM UTC-4, Rangel Spasov wrote:
Ok, I think someone already mentioned this - sorry. Got it to compile by
bumping to [potemkin 0.4.1] - thanks Zach + all : )
On Tuesday, July 21, 2015 at 12:24:43 PM UTC-7, Rangel Spasov wrote:
Hey guys,
Getting this error with 1.8.0-alpha2, I think related to aleph (using
0.4.0, latest version at the moment).
#error {
:cause IllegalName:
compile__stub.aleph.http.core.aleph.http.core/HeaderMap
:via
[{:type clojure.lang.Compiler$CompilerException
:message java.lang.NoClassDefFoundError: IllegalName:
compile__stub.aleph.http.core.aleph.http.core/HeaderMap,
compiling:(aleph/http/core.clj:81:1)
:at [clojure.lang.Compiler analyzeSeq Compiler.java 6798]}
{:type java.lang.NoClassDefFoundError
:message IllegalName:
compile__stub.aleph.http.core.aleph.http.core/HeaderMap
:at [java.lang.ClassLoader preDefineClass ClassLoader.java 654]}]
:trace
[[java.lang.ClassLoader preDefineClass ClassLoader.java 654]
[java.lang.ClassLoader defineClass ClassLoader.java 758]
[java.lang.ClassLoader defineClass ClassLoader.java 642]
[clojure.lang.DynamicClassLoader defineClass DynamicClassLoader.java
46]
[clojure.lang.Compiler$NewInstanceExpr compileStub Compiler.java 7815]
[clojure.lang.Compiler$NewInstanceExpr build Compiler.java 7680]
[clojure.lang.Compiler$NewInstanceExpr$DeftypeParser parse
Compiler.java 7590]
[clojure.lang.Compiler analyzeSeq Compiler.java 6791]
[clojure.lang.Compiler analyze Compiler.java 6592]
[clojure.lang.Compiler analyze Compiler.java 6553]
[clojure.lang.Compiler$BodyExpr$Parser parse Compiler.java 5929]
[clojure.lang.Compiler$LetExpr$Parser parse Compiler.java 6247]
[clojure.lang.Compiler analyzeSeq Compiler.java 6791]
[clojure.lang.Compiler analyze Compiler.java 6592]
[clojure.lang.Compiler analyze Compiler.java 6553]
[clojure.lang.Compiler$BodyExpr$Parser parse Compiler.java 5929]
[clojure.lang.Compiler$FnMethod parse Compiler.java 5359]
[clojure.lang.Compiler$FnExpr parse Compiler.java 3959]
[clojure.lang.Compiler analyzeSeq Compiler.java 6789]
[clojure.lang.Compiler analyze Compiler.java 6592]
[clojure.lang.Compiler eval Compiler.java 6847]
[clojure.lang.Compiler eval Compiler.java 6839]
[clojure.lang.Compiler load Compiler.java 7295]
[clojure.lang.RT loadResourceScript RT.java 372]
[clojure.lang.RT loadResourceScript RT.java 363]
[clojure.lang.RT load RT.java 453]
[clojure.lang.RT load RT.java 419]
[clojure.core$load$fn__5448 invoke core.clj 5866]
[clojure.core$load doInvoke core.clj 5865]
[clojure.lang.RestFn invoke RestFn.java 408]
[clojure.core$load_one invoke core.clj 5671]
[clojure.core$load_lib$fn__5397 invoke core.clj 5711]
[clojure.core$load_lib doInvoke core.clj 5710]
[clojure.lang.RestFn applyTo RestFn.java 142]
[clojure.core$apply invoke core.clj 632]
[clojure.core$load_libs doInvoke core.clj 5749]
[clojure.lang.RestFn applyTo RestFn.java 137]
[clojure.core$apply invoke core.clj 632]
[clojure.core$require doInvoke core.clj 5832]
[clojure.lang.RestFn invoke RestFn.java 551]
[aleph.http.server$eval9251$loading__5340__auto9252 invoke
server.clj 1]
[aleph.http.server$eval9251 invoke server.clj 1]
[clojure.lang.Compiler eval Compiler.java 6850]
[clojure.lang.Compiler eval Compiler.java 6839]
[clojure.lang.Compiler load Compiler.java 7295]
[clojure.lang.RT loadResourceScript RT.java 372]
[clojure.lang.RT loadResourceScript RT.java 363]
[clojure.lang.RT load RT.java 453]
[clojure.lang.RT load RT.java 419]
[clojure.core$load$fn__5448 invoke core.clj 5866]
[clojure.core$load doInvoke core.clj 5865]
[clojure.lang.RestFn
Re: a question about Chris Zheng's Abstract Container Pattern
What are the benefits of designing an abstract class in this way, compared to, say, using a protocol and normal functions? Could you provide a small example? - James On 28 July 2015 at 10:09, zcaudate z...@caudate.me wrote: Hey guys, Thanks for the feedback and your very insightful comments. Yep... this is OO alright =) I realised only after I wrote the article that I was implementing a Lifecycle clone with IRunnable example. However, the concept I am mentioning is much more general than components in terms of its scope: A similar `abstract class` for a reflective functional dispatch mechanism is defined here: https://github.com/zcaudate/iroh/blob/master/src/iroh/types/element.clj and extended by the `concrete classes' here: https://github.com/zcaudate/iroh/tree/master/src/iroh/element In the case of iroh... if I had used strictly multimethods, I would have been very confused. If I had used strictly protocols... well I couldn't for a number of reasons.. but if I did, I would have been even more confused because of the number of subconditions that I had to implement. iroh was the first library that I had built that used this pattern and it was so successful that I've been repeating the process over and over again since. What I wanted to achieve was to have the equivalent of an `abstract class` - the concept of code with abstract functionality that provides a framework for the heavy lifting to be done. `Concrete classes` can just extend aforementioned `abstract class` with minimal code and get all of the benefits. I've used this pattern with great success in many, many times and it provides a counter balance to the functional paradigm in terms of packaging up functionality. Clojure doesn't force us into one paradigm or the other and sometimes it is just more stylish to use the OO paradigm. The whole point of OO, multimethods and protocols is to do polymorphic dispatch, which is just a way to break a large cond statement into pieces that can then also be further extended. Please also note that not all OO frameworks are equal. Java uses a class inheritence approach whereas javascript uses a prototype model. The `abstract container` pattern that I was describing is probably closer to the JS model but to be honest, I don't really know what it is. Ultimately, it adds a middle tier of functionality in systems that have a plugin type mechanism. I'm sure there are equivalent functional contructs... but that was not the point of the pattern. This pattern has been very useful for me; clojure's protocols and multimethods were not enough to do what I needed to do - but combination of the two works wonders =) Since the article, the pattern has been codified here: https://github.com/zcaudate/hara/blob/master/src/hara/extend/abstract.clj#L196 Hope that helps in clarifying the motivation behind the article and the pattern Chris On Monday, July 27, 2015 at 11:42:21 PM UTC+5:30, Colin Yates wrote: I think his last sentence gives you the answer: A warm shoutout to Tushar, Lyndon, Dean, Alan, Hank, Derek, and all the guys at clj-melb that gave feedback and helped flesh out this rehash of *OO design*.” (my emphasis) He wanted an OO approach and has implemented one; specifically behaviour and state coupled together. I think neither Typed Clojure nor Contracts would have achieved this guy’s goal as they are about enforcing a contract (either the shape of data or effects of a fn) in the ‘functional’ paradigm; this guy clearly wanted something in the OO paradigm. Is there a ‘functional’ implementation which gives the same benefits; sure, but that isn’t what he wanted. Are there a bunch of ‘upgrades’ that I am sure we could all apply; sure, but again it seems like he was setting out with a very specific goal in mind and has achieved that. On 27 Jul 2015, at 18:37, Lawrence Krubner lawr...@rollioforce.com wrote: I have a question about this: Servers that are running on a particular port can be tracked and stopped. I have to say, this was the feature that I wanted the most, which motivated the framework's design. The annoying thing about development in emacs is that I have to be careful of not losing the reference to the server. Since there was no way of stopping it unless the repl is restarted. I wanted to implement a registery for references to running servers to be saved. http://z.caudate.me/the-abstract-container-pattern/ I have the impression that he's going over the same territory as that covered by Stuart Sierra, though Zheng doesn't mention Component nor Sierra. But he offers this as an example of what he's after: (defprotocol IRunnable (start! [system]) (stop! [system]) (restart! [system]) (started? [system]) (stopped? [system])) That much seems similar to Sierra's system. Zheng seems to add an additional layer by simulating an abstract class above his protocols. As he says: - A single deftype acts as the
Re: Advice on introducing a Java dev to Clojure
I wrote this for a blog post, but I think it is relevant here. After a long comparison of a bit of code, first in Javascript and then in Clojure, I wrote: At this point, a Javascript developer might say, “You've shown that the Functional style has some advantage, but why should I care? I can write in the Functional style using Javascript. I don't need Clojure.” That is absolutely true, and we all know that developers tend to be fiercely loyal to their languages, up 'til the moment they are not. I myself was fiercely loyal to Ruby, up 'til the moment when I wasn't. True moments of conversion are rare and always depend on a person reaching some point of pain with their current path. I myself suddenly realized that I was working with languages that would not carry me into a future full of multi-CPU computers and massive concurrency ... at which point I began to explore what the future might hold ... at which point I discovered Clojure. I would, however, counter the Javascript developer with my own set of questions. If you have realized that the Functional style is best, do you want to work in a language that undercuts that style, or supports it? Do you want to burden yourself with the extra discipline needed to pull off the Functional style in a highly mutable language, or do you want to work with a language that was designed from conception to make your life easier ? Do you want to “navigate disappointment” or travel directly in the direction of success? In his talk, “Why Clojure is my favorite Ruby,” Steven Deobald refers to dealing with pain points in a language as “Navigating disappointment.” On Thursday, July 23, 2015 at 9:04:42 AM UTC-4, Paul deGrandis wrote: I have had success here with a few approaches. For every company I work with that is new to Clojure, I provide them with a Quick Learn document. The document is split into 5-7 days, and every day they skim/read an article, poke around a resource (like ClojureDocs), and watch a talk. Sometimes that resource item is an exercise or something interactive. Your goal should never be to convince someone of Clojure - Clojure itself is convincing enough. Instead motivate someone to want to learn more - get them curious and self-driven to dive in wherever their interests lay. Get them well adapted to the Clojure culture and the radical approach to simplicity. Get them questioning their own practices and technologies. Entice them with the functional approach to system creation. Leon mentioned my talk, which claims, Clojure manages risk better than any other technology - http://www.infoq.com/presentations/Clojure-powered-Startups For well-established enterprise shops, I think my most recent Conj talk is more convincing - https://www.youtube.com/watch?v=BNkYYYyfF48 Consider the following talks by Rich: * Clojure, Made Simple - https://www.youtube.com/watch?v=VSdnJDO-xdg * Are we there yet? - http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey * Simple Made Easy - http://www.infoq.com/presentations/Simple-Made-Easy Nothing is more convincing than a working system. If it's possible, illustrate the virtues of Clojure and its approach to problem solving by walking the walk on a small scale, where the stakes and risks are low. Build a tool, prototype an idea in half the time it would normally take, show the power of Protocols within your own existing system, etc. Regards, Paul -- 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: ring.middleware.reload and figwheel
+1 Le mercredi 13 mai 2015 09:06:05 UTC-4, Paco Viramontes a écrit : Any luck with this? I want to do the same :P On Thursday, April 30, 2015 at 3:06:13 AM UTC-7, Dan Kersten wrote: Hi, I've got a clojure(script) project where I use figwheel to live-reload cljs and this works great, but I'm now trying to set up live reloading of the server-side clojure too. Since I don't want to run multiple jvm/lein instances, I'm using figwheels :ring-handler feature to add my server ring handler into figwheels embedded webserver. In the past, I've live-reloaded my server code using the reloaded workflow, but since figwheel gives me a cljs repl and not a clj repl, I don't know how to do that without running the server independently. So, instead I'm just trying to get ring.middleware.reload working, but its not picking up file changes. Has anyone got this working? Alternatively, does anyone have any tips on getting a nice workflow without running multiple jvm/lein instances? 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.
[JOB] Clojure/Clojurescript Software Engineer - Startup - SF or remote
Hi all, We're looking for Clojure/Clojurescript engineers (details below). Please email me directly at step...@fac.tt if you're interested in learning more. Stephen --- Fact Labs is a San Francisco-based startup that is building a quick and easy way for users to create and discover structured and semi-structured data on the Web. About the environment: We are a small team of experienced Clojure software engineers looking to add another engineer to the team. We are looking for candidates who are capable of self direction and making sound technology and design decisions quickly. This is a great opportunity to really flex and stretch your Clojure/Clojurescript skills while building a new product in a startup environment. Our core stack is Clojure, Clojurescript, and Datomic running on AWS. About the role: This is a generalist role across front end and back end, however an interest and/or strengths in the following are particularly relevant: - Web application / system design - data visualization - API design - data modeling Required: - 1+ year of Clojure experience - 4+ years of production software development experience - strong understanding of core computer science concepts This is a full-time position. Remote candidates working in a US timezone are welcome. Please email step...@fac.tt for details. -- 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: Tool authors: ClojureScript support in tools.namespace?
Yagni uses dir/scan-all and tracker. Would love to have ClojureScript support. On Saturday, July 25, 2015 at 7:29:24 PM UTC-4, Brian Marick wrote: Midje Stuart Sierra wrote: 1. Do you need/want ClojureScript support? Eventually, but not soon. 2. What namespaces (repl, find, dir, file, parse) do you call in tools.namespace? repl, dir, track, reload 3. How would you like to distinguish between get me Clojure sources and get me ClojureScript sources? I don't have an opinion. -- 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] Pink 0.2.0, Score 0.3.0
This might be a naive question, but for someone who's only tangentially familiar with the space, where does this fit in to the overall Clojure music/sound ecosystem (re: overtone et al)? On Saturday, July 25, 2015 at 1:03:44 PM UTC-4, Steven Yi wrote: Thanks Ruslan and best of luck in your musical work! On Sat, Jul 25, 2015 at 12:24 AM, Ruslan Prokopchuk fer@gmail.com javascript: wrote: Steven, thank you for continuing to develop Pink Score! I have some music projects as my slowly-moving-forward-hobbies, and having pure java, no deps like Supercollider, engine for one of them is very precious! пятница, 24 июля 2015 г., 23:47:30 UTC+3 пользователь Steven Yi написал: Hi All, I'd like to announce the release of Pink 0.2.0 and Score 0.3.0: [kunstmusik/pink 0.2.0] [kunstmusik/score 0.3.0] Pink is an audio engine library, and Score is a library for higher-level music representations (e.g. notes, phrases, parts, scores). ChangeLogs are available at: https://github.com/kunstmusik/pink/blob/master/CHANGELOG.md https://github.com/kunstmusik/score/blob/master/CHANGELOG.md The quick version is Pink now has some new effects (ringmod, freeverb, chorus) as well as some new filters and delay-based audio functions. Score has a new sieves namespace for Xenakis-style sieves. (An example of sieves and freeverb is available in the music-examples project [1]). For any questions, please feel free to email me or post on the pink-users list. For issues and PR's, please use the facilities on Github for each of the projects. Thanks! steven [1] - https://github.com/kunstmusik/music-examples/blob/master/src/music_examples/sieves.clj -- 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: Tool authors: ClojureScript support in tools.namespace?
Thanks for the responses everyone. So far, my general plan is starting to look like this: c.t.n.*dependency* and c.t.n.*track* are platform agnostic. c.t.n.*file* and c.t.n.*parse* can be extended to support Clojure ClojureScript by adding an optional argument read-opts passed through to tools.reader/read. c.t.n.*find* can be extended with optional arguments to select a platform, either Clojure or ClojureScript, which will encapsulate both valid file extensions and reader options. Reload/refresh functionality will remain Clojure(JVM) only for now: c.t.n. *dir*, c.t.n.*reload*, and c.t.n.*repl*. More notes and work-in-progress are visible on TNS-35 http://dev.clojure.org/jira/browse/TNS-35 I'm not saying there will *never* be any ClojureScript support for refresh/reload, just that I have no idea how to do it right now and I want to deal with the easier problems first. –S -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To 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] Pink 0.2.0, Score 0.3.0
Overtone has its own composition logic, but for synthesis it is a client for the open source Supercollider audio synthesis server (which is a cross platform C++ program that can be controlled via the network). Pink and Score are built in Clojure and Java without using an external server. On Tuesday, July 28, 2015 at 9:54:14 AM UTC-7, W. David Jarvis wrote: This might be a naive question, but for someone who's only tangentially familiar with the space, where does this fit in to the overall Clojure music/sound ecosystem (re: overtone et al)? On Saturday, July 25, 2015 at 1:03:44 PM UTC-4, Steven Yi wrote: Thanks Ruslan and best of luck in your musical work! On Sat, Jul 25, 2015 at 12:24 AM, Ruslan Prokopchuk fer@gmail.com wrote: Steven, thank you for continuing to develop Pink Score! I have some music projects as my slowly-moving-forward-hobbies, and having pure java, no deps like Supercollider, engine for one of them is very precious! пятница, 24 июля 2015 г., 23:47:30 UTC+3 пользователь Steven Yi написал: Hi All, I'd like to announce the release of Pink 0.2.0 and Score 0.3.0: [kunstmusik/pink 0.2.0] [kunstmusik/score 0.3.0] Pink is an audio engine library, and Score is a library for higher-level music representations (e.g. notes, phrases, parts, scores). ChangeLogs are available at: https://github.com/kunstmusik/pink/blob/master/CHANGELOG.md https://github.com/kunstmusik/score/blob/master/CHANGELOG.md The quick version is Pink now has some new effects (ringmod, freeverb, chorus) as well as some new filters and delay-based audio functions. Score has a new sieves namespace for Xenakis-style sieves. (An example of sieves and freeverb is available in the music-examples project [1]). For any questions, please feel free to email me or post on the pink-users list. For issues and PR's, please use the facilities on Github for each of the projects. Thanks! steven [1] - https://github.com/kunstmusik/music-examples/blob/master/src/music_examples/sieves.clj -- 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] Clojure 1.8.0-alpha2
I think this is pretty unlikely. While megarefs look very cool, I'm not
sure what the benefit to having these directly in Clojure would be over
having them in a library.
Anecdotally, everyone I have talked to about Clojure's reference types have
said that they have never needed to use ref's or agents in real world code
(I'm sure some people have to good effect though).
That being said, you can always open a JIRA or design doc about this if you
feel strongly about it to start a discussion.
--
Daniel.
On Tue, 28 Jul 2015 at 9:05 AM Lawrence Krubner lawre...@rollioforce.com
wrote:
Off topic, but I wonder if there was ever any discussion of megarefs being
added to Clojure?
https://github.com/cgrand/megaref
On Tuesday, July 21, 2015 at 3:30:46 PM UTC-4, Rangel Spasov wrote:
Ok, I think someone already mentioned this - sorry. Got it to compile by
bumping to [potemkin 0.4.1] - thanks Zach + all : )
On Tuesday, July 21, 2015 at 12:24:43 PM UTC-7, Rangel Spasov wrote:
Hey guys,
Getting this error with 1.8.0-alpha2, I think related to aleph (using
0.4.0, latest version at the moment).
#error {
:cause IllegalName:
compile__stub.aleph.http.core.aleph.http.core/HeaderMap
:via
[{:type clojure.lang.Compiler$CompilerException
:message java.lang.NoClassDefFoundError: IllegalName:
compile__stub.aleph.http.core.aleph.http.core/HeaderMap,
compiling:(aleph/http/core.clj:81:1)
:at [clojure.lang.Compiler analyzeSeq Compiler.java 6798]}
{:type java.lang.NoClassDefFoundError
:message IllegalName:
compile__stub.aleph.http.core.aleph.http.core/HeaderMap
:at [java.lang.ClassLoader preDefineClass ClassLoader.java 654]}]
:trace
[[java.lang.ClassLoader preDefineClass ClassLoader.java 654]
[java.lang.ClassLoader defineClass ClassLoader.java 758]
[java.lang.ClassLoader defineClass ClassLoader.java 642]
[clojure.lang.DynamicClassLoader defineClass DynamicClassLoader.java
46]
[clojure.lang.Compiler$NewInstanceExpr compileStub Compiler.java 7815]
[clojure.lang.Compiler$NewInstanceExpr build Compiler.java 7680]
[clojure.lang.Compiler$NewInstanceExpr$DeftypeParser parse
Compiler.java 7590]
[clojure.lang.Compiler analyzeSeq Compiler.java 6791]
[clojure.lang.Compiler analyze Compiler.java 6592]
[clojure.lang.Compiler analyze Compiler.java 6553]
[clojure.lang.Compiler$BodyExpr$Parser parse Compiler.java 5929]
[clojure.lang.Compiler$LetExpr$Parser parse Compiler.java 6247]
[clojure.lang.Compiler analyzeSeq Compiler.java 6791]
[clojure.lang.Compiler analyze Compiler.java 6592]
[clojure.lang.Compiler analyze Compiler.java 6553]
[clojure.lang.Compiler$BodyExpr$Parser parse Compiler.java 5929]
[clojure.lang.Compiler$FnMethod parse Compiler.java 5359]
[clojure.lang.Compiler$FnExpr parse Compiler.java 3959]
[clojure.lang.Compiler analyzeSeq Compiler.java 6789]
[clojure.lang.Compiler analyze Compiler.java 6592]
[clojure.lang.Compiler eval Compiler.java 6847]
[clojure.lang.Compiler eval Compiler.java 6839]
[clojure.lang.Compiler load Compiler.java 7295]
[clojure.lang.RT loadResourceScript RT.java 372]
[clojure.lang.RT loadResourceScript RT.java 363]
[clojure.lang.RT load RT.java 453]
[clojure.lang.RT load RT.java 419]
[clojure.core$load$fn__5448 invoke core.clj 5866]
[clojure.core$load doInvoke core.clj 5865]
[clojure.lang.RestFn invoke RestFn.java 408]
[clojure.core$load_one invoke core.clj 5671]
[clojure.core$load_lib$fn__5397 invoke core.clj 5711]
[clojure.core$load_lib doInvoke core.clj 5710]
[clojure.lang.RestFn applyTo RestFn.java 142]
[clojure.core$apply invoke core.clj 632]
[clojure.core$load_libs doInvoke core.clj 5749]
[clojure.lang.RestFn applyTo RestFn.java 137]
[clojure.core$apply invoke core.clj 632]
[clojure.core$require doInvoke core.clj 5832]
[clojure.lang.RestFn invoke RestFn.java 551]
[aleph.http.server$eval9251$loading__5340__auto9252 invoke
server.clj 1]
[aleph.http.server$eval9251 invoke server.clj 1]
[clojure.lang.Compiler eval Compiler.java 6850]
[clojure.lang.Compiler eval Compiler.java 6839]
[clojure.lang.Compiler load Compiler.java 7295]
[clojure.lang.RT loadResourceScript RT.java 372]
[clojure.lang.RT loadResourceScript RT.java 363]
[clojure.lang.RT load RT.java 453]
[clojure.lang.RT load RT.java 419]
[clojure.core$load$fn__5448 invoke core.clj 5866]
[clojure.core$load doInvoke core.clj 5865]
[clojure.lang.RestFn invoke RestFn.java 408]
[clojure.core$load_one invoke core.clj 5671]
[clojure.core$load_lib$fn__5397 invoke core.clj 5711]
[clojure.core$load_lib doInvoke core.clj 5710]
[clojure.lang.RestFn applyTo RestFn.java 142]
[clojure.core$apply invoke core.clj 632]
[clojure.core$load_libs doInvoke core.clj 5753]
[clojure.lang.RestFn applyTo RestFn.java 137]
[clojure.core$apply invoke core.clj 632]
[clojure.core$require
Re: [ANN] Pink 0.2.0, Score 0.3.0
I'd add a few other notes: * Overtone uses Supercollider 3 (SC3) for its audio processing. Pink relates more to SC3 than to Overtone, as Pink is an audio engine library, but there's some overlap. * You wouldn't likely use Overtone and Pink together. Score however is a generic library and could be used with Overtone. * Pink uses 64-bit (doubles) for its audio processing, Overtone--because it uses SC3--uses 32-bit (floats) for its signal processing chain * Overtone and SC3 are much more mature systems with a pretty deep set of signal processing and control signal generators. Pink has a lot less functions at this time. * Pink uses Clojure code for its signal processing, so one can write unit generators in Clojure code, as well as study the existing unit generator code as Clojure. You'd have to switch to C++ to read the unit generator code in SC3 (though, I'd say the codebase for SC3 is quite clean and easy to read, IMO) * Pink has a slightly more functional approach to audio and events. Overtone inherits SC3's approach, which ends up using busses for transferring audio between Synths. This then ends up requiring a little more management of ordering of nodes and processing order. * For events, because Pink's synths are just plain Clojure functions, it means you can write events where the arguments to the synths can be other audio functions. This means you could do things like reuse a synth-patch and give a fixed value for a frequency cutoff of a filter, but you could also pass in an LFO summed with an Envelope and a frequency value as the value for cutoff to get a dubsteb wobble, for just that note instance. (You could do something close in SC3 by using synth params but you'd have to schedule a separate synth to modify values I think.) * Pink's event system is processed synchronously with the audio engine. Pink also allows adding control functions to run synchronously with the engine. This allows one to do things like temporal recursion with events and have it done without jitter. As far as I understand, Overtone uses at-at, which uses a separate clock source from the SC3 engine. That would mean there'd be possible jitter between the event thread and the audio engine thread when firing events. * Overtone and SC3 will likely run faster as the audio processing is done natively. Pink is optimized pretty well for Clojure/Java, but I don't think it will ever get as fast as SC3. If you're expecting to do a large amount of processing in realtime, Overtone may be the better choice. * Pink, however, may be a bit easier to use for non-realtime processing. Since you can do anything synchronously with the engine, you can run control functions and do temporal recursion even if you're running faster than non-realtime, and you'd get the same exact results as in realtime. Just to note, I'm probably more familiar with SC3 than I am with Overtone, so if I've misunderstood anything, I'm happy to be corrected. Also, I'd say that Overtone will probably cover more musical use cases at this time, due to the depth of unit generators, but Pink's design covers some use cases that Overtone can not, and allows expressing musical ideas in a unique way. On Tue, Jul 28, 2015 at 2:13 PM, Justin Smith noisesm...@gmail.com wrote: Overtone has its own composition logic, but for synthesis it is a client for the open source Supercollider audio synthesis server (which is a cross platform C++ program that can be controlled via the network). Pink and Score are built in Clojure and Java without using an external server. On Tuesday, July 28, 2015 at 9:54:14 AM UTC-7, W. David Jarvis wrote: This might be a naive question, but for someone who's only tangentially familiar with the space, where does this fit in to the overall Clojure music/sound ecosystem (re: overtone et al)? On Saturday, July 25, 2015 at 1:03:44 PM UTC-4, Steven Yi wrote: Thanks Ruslan and best of luck in your musical work! On Sat, Jul 25, 2015 at 12:24 AM, Ruslan Prokopchuk fer@gmail.com wrote: Steven, thank you for continuing to develop Pink Score! I have some music projects as my slowly-moving-forward-hobbies, and having pure java, no deps like Supercollider, engine for one of them is very precious! пятница, 24 июля 2015 г., 23:47:30 UTC+3 пользователь Steven Yi написал: Hi All, I'd like to announce the release of Pink 0.2.0 and Score 0.3.0: [kunstmusik/pink 0.2.0] [kunstmusik/score 0.3.0] Pink is an audio engine library, and Score is a library for higher-level music representations (e.g. notes, phrases, parts, scores). ChangeLogs are available at: https://github.com/kunstmusik/pink/blob/master/CHANGELOG.md https://github.com/kunstmusik/score/blob/master/CHANGELOG.md The quick version is Pink now has some new effects (ringmod, freeverb, chorus) as well as some new filters and delay-based audio functions. Score has a new sieves namespace for Xenakis-style sieves. (An example of sieves and
Re: ring.middleware.reload and figwheel
I've never used ring.middleware.reload, but I do run client figwheel and
server in the same jvm.
In your project.clj, make figwheel listen on an nrepl port:
:figwheel
{:nrepl-port 7888
:server-port 3000 ; http
:repl false ; Optional: keep this off and bootstrap to cljs
repl: see below.
:ring-handler your-ring-handler}
Connect to that port with an nrepl client: this will be a clj repl for the
server.
To get the cljs repl, you can either leave :repl true and use it from
stdin/stdout, or you can piggieback to a cljs repl like so:
(do (use 'figwheel-sidecar.repl-api) (cljs-repl))
Since you can connect multiple nrepl clients to the same nrepl server, you
can easily have one client for the server clj and another for the client
cljs/figwheel.
On Thursday, April 30, 2015 at 5:06:13 AM UTC-5, Dan Kersten wrote:
Hi,
I've got a clojure(script) project where I use figwheel to live-reload
cljs and this works great, but I'm now trying to set up live reloading of
the server-side clojure too.
Since I don't want to run multiple jvm/lein instances, I'm using figwheels
:ring-handler feature to add my server ring handler into figwheels embedded
webserver.
In the past, I've live-reloaded my server code using the reloaded
workflow, but since figwheel gives me a cljs repl and not a clj repl, I
don't know how to do that without running the server independently.
So, instead I'm just trying to get ring.middleware.reload working, but its
not picking up file changes.
Has anyone got this working? Alternatively, does anyone have any tips on
getting a nice workflow without running multiple jvm/lein instances?
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.
