Re: OO Programmer trying to move to Clojure: Namespace Organization
Hi Dru, I find it easier to organize things when I follow TDD. It's easier for me to spot something is in the wrong place (module or maybe as a responsibility of a function) by looking at the tests. (This is true for any language I work with.) http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd On Sat, Feb 7, 2015 at 6:23 PM, Dru Sellers wrote: > Greetings, > > I am trying to convert my mind from OO (C#) to one more functionally > friendly. I am increasingly comfortable with simple applications in > clojure, but as I start to build more complex applications, I start to fall > down about how to structure my application. I don't want to just shove OO > ideas into the functional nature of Clojure. I'm looking for any help > someone can provide to help shimmy my brain into the right mental patterns. > > Background: Long time C# developer who leans heavily on IoC / DI / > Interfaces / Testing / Object Encapsulation. > > Specific Questions: Namespace Organization > > Now I know this is almost entirely personal preference, but I'm playing > with a namespace model that looks like this and I'd love some feed back. > Tear it about, bust that red pen out and help me to better think of things > in clojure way. I only have my C# / OO background to lean on and need some > fresh brain juice. :) > > I currently organize my projects like this. a spin off of 'duct' > https://github.com/weavejester/duct but i'm looking for a bit more detail. > > Context: Project name is going to be "ford", feature is going to be a > simple log of text > > > ~/ > src/ > ford/ - the project > log/ - the feature name > http.clj - contains clojure routes at 'http/routes' - orchestrate > the business calls > model.clj - contains my 'defrecords' / yesql / db calls > core.clj - the "business" calls > > > I def have a preference for shorter files rather than longer files > I also tend to have a heavy use of 'ceremony' - right now I need a lot of > structure because I'm still learning to think in terms of clojure. and I > spend a lot of time still reading it rather than thinking about it. > > Again, thank you. > > -d > > -- > 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. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: Is this the good way to write get-percentage
> "))) > (round mode (/ (* place 100.0) total-count > > > I made two other handy functions: > (defn round-precision [value precision] > (let [multiplier (Math/pow 10.0 precision)] > (/ (Math/round (* value multiplier)) multiplier))) > > > (defn round-div-precision [dividend divisor precision] > (round-precision (/ (float dividend) divisor) precision)) > > For example: > (round-div-precision 22000 7 3) > gives: > 3142.857 > > and: > (round-div-precision 22000 7 -3) > gives: > 3000.0 > > -- > Cecil Westerhof > > -- > 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. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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] clecs 2.0.0
clecs is an entity component system library. Repo is here: https://github.com/muhuk/clecs API documentation is here: http://clecs.muhuk.com/2.0.x/api/ Changelog is here: http://clecs.muhuk.com/2.0.x/user_guide/#_changelog This version comes with some major changes which will hopefully make working with clecs easier. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: Best way to test multiple implementations of a protocol?
Hi Leif, What does this answer fail to address? http://stackoverflow.com/a/16579272/42188 On Wed, Mar 25, 2015 at 3:40 AM, Leif wrote: > > If I have a protocol that supposedly satisfies some constraints, and > multiple implementations that supposedly implement the protocol, what is > the best way to test them all? > > A minimal example is here: > https://gist.github.com/leifp/bf5c74eea98026329a76 > > This question on SO is basically the same as mine, but the answer seems > less than ideal to me: > > http://stackoverflow.com/questions/16578882/testing-to-the-interface-in-clojure > > In my mind, the ideal solution lets you: > * See the failing implementation in the test output > * Don't repeat yourself > > I'm surprised that this isn't well-trodden ground, given the amount of > people using Components to organize their apps, but I can't find any > examples. Perhaps I am just failing to use the internet properly. > > Thanks, > Leif > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com www.olcgen.com -- 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] ednsl-0.2.0: a super-simple DSL for building DSLs
Hi James,
Interesting library. I have a few comments on the readme.
The simple example is not so simple:
(ns my.app
(:use [ednsl]))
(defn main [& args]
(let [r (-> "config-file.edn" read-file ctx-form
(>>= emap (eithery (etuple ekey (eor (>>- esym eload-sym)
eany)
{:keys [main args]} r]
(apply main args)))
(defn real-main [& args]
;; Do something useful!
(prn args))
The calculation of r is supposed to demonstrate what this library does, but
a potential user will have no idea what any of those supposed to do.
Perhaps loosening the code and adding some comments that explain what's
going on there can help adoption.
I think main should do (apply real-main args), otherwise infinite recursion.
Codox docs are in the 'doc' directory or can be read on github. They
contain a good walkthrough.
github link here goes to your user page.
On Fri, Apr 3, 2015 at 5:43 PM, James Laver wrote:
> It’s not quite as stupid as it sounds and it’s mostly the result of
> factoring out the config handling code from oolong[1]
>
> https://github.com/jjl/ednsl/
> https://clojars.org/ednsl
>
> Happy hacking!
>
> James
>
> [1] https://github.com/jjl/oolong/
>
>
> --
> 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.
>
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
www.olcgen.com
--
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: Meaning of part of the doc string for `ns-resolve`
This fails: (ns-resolve 'sumtin 'clecs.world/remove-entity) Exception No namespace: sumtin found clojure.core/the-ns (core.clj:3830) But this succeeds: (ns-resolve 'seesaw.core 'clecs.world/remove-entity) #'clecs.world/remove-entity It seems when the 2nd argument is fully qualified, first argument is not important but it still needs to be a valid namespace. On Fri, Apr 24, 2015 at 1:43 AM, Brian Marick wrote: > The last sentence of the `ns-resolve` documentation reads: > > Note that > if the symbol is fully qualified, the var/Class to which it resolves > need not be present in the namespace. > > What does that mean? I would expect something like the following to > produce a non-nil value: > > user=> (ns-resolve 'clojure.core 'fofofof) > user=> (ns-resolve 'clojure.core 'clojure.core/fofofof) > user=> (ns-resolve *ns* 'clojure.core/fofofof) > > > ... to produce a non-nil value, but they're all nil. > > (Note: in the 1.6 API, it looks to me like the only other uses of "fully > qualified" refer to classes.) > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com www.olcgen.com -- 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: Crazy Need: Embed JavaScript Structure in Clojure
Hi JPatrick,
On Mon, Apr 27, 2015 at 11:50 PM, JPatrick Davenport
wrote:
> Hello,
> So just to get it out: I do not want to evaluate the JavaScript, simply
> preserve it.
>
> I'm working on an ArangoDB driver. Part of the wonder that is ArangoDB is
> its ability to support transactions. This is done using JSON. Part of the
> REST object for a transaction is what I want to do in the transaction. This
> is encapsulated in the "action" attribute of the posted JSON object.
>
> Here's an example
> {...JSON configuration
> action: "function (){many lines of stuff here",
> More JSON configuration}
>
> Now the way that this works in node is by converting the function into a
> String. I didn't know that String(function () {..valid JavaScript...})
> would kick out a string version of the function. Pretty neat.
>
> I want to do the same thing with Clojure. I presently take a map with one
> of the attributes of :action. I want something like this.
> {:some-key :some-value,
> :action (js-macro function(){
> console.log("pretty crappy transaction");
> console.log("another line");
> })}
>
> On the other side of the macro I want to get "function() {\t\t\t\n
> console.log(\"pretty crappy transaction\";\n\t\t\tconsole.log(\"another
> line\");\n} or there about.
>
> I've got
>
> (defmacro js [& js-fun]
>
> (let [body (str js-fun)]
>
> (subs body 1 (- (count body) 1
>
> That gets the idea. Unfortunately, I loose the ";" as well as the new
> lines.
>
Your macro thinks it receives the code as a string, but Clojure macros
receive their parameters as s-expressions. Just like functions, with the
only difference functions' params are evaluated.
>
> I'm pretty sure I don't *need* this macro. I can probably get away with
> "function () {
> console.log('println');
> }", but I feel like this would make the code nicer.
>
Perhaps you can write a function that builds a function somewhere and then
outputs a string containing JavaScript code that invokes it.
(defn js [& body]
(eval `(defn fn-name# [] ~@body))
(str "function() { your.ns." fn-name# "(); }"))
(I didn't test the code, it's just to give you an idea.)
>
> Thanks,
> JPD
>
> --
> 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.
>
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
www.olcgen.com
--
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: Crazy Need: Embed JavaScript Structure in Clojure
On Tue, Apr 28, 2015 at 10:44 AM, Gary Verhaegen
wrote:
> On 28 April 2015 at 07:39, Atamert Ölçgen wrote:
> > Perhaps you can write a function that builds a function somewhere and
> then
> > outputs a string containing JavaScript code that invokes it.
> >
> > (defn js [& body]
> > (eval `(defn fn-name# [] ~@body))
> > (str "function() { your.ns." fn-name# "(); }"))
>
> If the goal is to send this code to a database to be evaluated there,
> I do not think this would work, as the function is only defined within
> Clojure.
>
You are right. Now that I've read OP more carefully; I think exploring your
idea is really worth it, since it would allow the consumers of this library
to
write their transactions in ClojureScript instead of JavaScript.
>
> @OP: as you admit that this is a crazy need, here is a crazy solution:
> use the ClojureScript compiler directly within your Clojure code. I'm
> not familiar with it at all; after a quick glance at the Himera source
> code, here is a "proof of concept":
>
> --
>
> $ lein try org.clojure/clojurescript "0.0-3211"
> nREPL server started on port 52299 on host 127.0.0.1 - nrepl://
> 127.0.0.1:52299
> REPL-y 0.3.5, nREPL 0.2.6
> Clojure 1.6.0
> Java HotSpot(TM) 64-Bit Server VM 1.8.0_25-b17
> Docs: (doc function-name-here)
> (find-doc "part-of-name-here")
> Source: (source function-name-here)
> Javadoc: (javadoc java-object-or-class-here)
> Exit: Control+D or (exit) or (quit)
> Results: Stored in vars *1, *2, *3, an exception in *e
>
> user=> (require '[cljs.compiler :as comp])
> nil
> user=> (require '[cljs.analyzer :as ana])
> nil
> user=> (comp/emit-str (ana/analyze {:uses #{'cljs.core}} '(fn []
> (js/alert "hello"
> "(function (){\nreturn alert(\"hello\");\n});\n"
> user=>
>
> --
>
> The first argument to analyze is the environment; you'll probably have
> to dig a little deeper into the ClojureScript compiler to decide what
> to pass there. This should allow you to create a macro that let you
> write ClojureScript code directly:
>
> {:some-key :some-value,
> :action (js-macro (fn []
> (js/console.log "pretty crappy transaction")
> (js/console.log "another line")))}
>
> --
> 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.
>
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
www.olcgen.com
--
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: Help with async operations
Hi Oleg, On Sun, May 17, 2015 at 6:48 AM, Oleg Dashevskii wrote: > Hi, > > I’m new to Clojure async operations (while have a good understanding of > other things) and want to get a bit of advice. Atoms & agents still confuse > me. > > What I’m implementing is a small REST webservice with custom in-memory > database. Database is indexed by unique key, basically it’s a map (I’ll > denote it as MAP). There are two basic operations: > > *PUT /api/…/.* Initiate an update for given KEY. The HTTP response > should be returned immediately, and the processing should be done > asynchronously. The processing consists of downloading a data file from web > and doing some data crunching, the result should go into MAP. > > *GET /api/…/.* Use (get MAP KEY) and request params to generate > response synchronously. > > The tricky part (well, for me :) is that parallel PUT requests should be > possible. The downloading and processing can and should go in parallel, > independently, whereas updating the MAP should come synchronized, > one-after-the-other. > > How would you implement this? > While this can be done with atoms & agents, perhaps you should check out core.async or Lamina first. Neither atoms nor agents can be updated in a parallel manner. Only one update runs on a single atom/agent at a given time. If you really need parallelism and the updates affect small parts of MAP, perhaps you can model it using refs, but then it's not one big map anymore. (Still you can't update a single ref in more than one thread at the same time.) You probably also want to control how the files are downloaded and processed, so that there's not duplication of effort. So an event driven solution seems to fit this problem. > > -- > Oleg. > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com www.olcgen.com -- 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: Looking for a clojure expert to help fill in a language feature reference
Hi Dan, Who are the people you help understand the tradeoffs and features of technologies? Is this a public project with a public website? On Mon, May 18, 2015 at 11:51 AM, Dan Cancro wrote: > Hi, > > I'm not a Clojure user but I maintain a reference to help people > understand the tradeoffs and features of technologies. I was hoping > someone among you would be interested in helping to contribute some > knowledge about it to the project. > > Click here to see the reference > <https://docs.google.com/spreadsheets/d/1r8rJy2Q5p5QORYKcye93UECwOlSgFL24c5fyF7dqhaM/edit#gid=1534967054> > . > > It should not take more than a few minutes for someone who knows Clojure > well and will really help people understand quickly what it's about and how > it's different. > > If you would like to help out, I've made a questionnaire that should make > it a little easier: > > Click here to complete a short questionnaire about Clojure > <https://docs.google.com/forms/d/1uq2aavM2JfKkN5Exh15x8WejXoJQNf1rI8MTF62hPQs/viewform> > > I'm sure I've left out a lot of benefits that Clojure delivers. Please > let me know about the big things I've missed and I'll add them to the list. > > Thanks, > Dan > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com www.olcgen.com -- 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] - example : Stop writing unit tests and generate them instead (details inside)
Hi David, How does this integrate prerequisites? Even if my fn is pure, I still mock calls made within. On Mon, Jun 8, 2015 at 5:33 PM, David Sargeant wrote: > Speed up your development cycle using example. Here's the process: > > 1. Write your test code inline with your functions. > 2. Test the output of your functions in the REPL as you code. > 3. Generate unit tests when you're satisfied with the behavior of your > functions. > > See https://github.com/dubiousdavid/example for more information. > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com www.olcgen.com -- 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] - example : Stop writing unit tests and generate them instead (details inside)
I meant (provided), (against-background), etc. On Mon, Jun 8, 2015 at 6:02 PM, David Sargeant wrote: > If I need something more complicated in terms of testing my functions I > usually create a file dev/examples.clj and add dev to the source-paths in > my project's dev profile. I would require the namespace with my functions > and put the examples in dev/examples.clj. The rest of the process is the > same after that. > > In addition, I might create dev/generate.clj if I need to pass lot's of > arguments to gen-facts/gen-facts-file and wrap calls to those functions in > a function (e.g., gen-tests/gen-tests-file). > > I hope to have examples of these more complicated scenarios in the near > future. Suffice to say, this ends up being much faster than any other > workflow I've tried. > > David > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com www.olcgen.com -- 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] - example : Stop writing unit tests and generate them instead (details inside)
Got it. Thanks! On Mon, Jun 8, 2015 at 6:14 PM, David Sargeant wrote: > I'm not totally sure why you would need to use `provided` with pure > functions, but that is definitely not in scope for this project. example > isn't meant to replace all cases where you would write tests. It's designed > to streamline the creation of a certain class of tests that come with a lot > of unnecessary manual work. > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com www.olcgen.com -- 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: Actually using component.
mail 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. >> > > > > -- > “One of the main causes of the fall of the Roman Empire was that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com www.olcgen.com -- 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: Single-atom update ordering guarantees
On Tue, Jun 9, 2015 at 7:30 PM, Michael Gardner wrote: > This might be blindingly obvious to some, but I can't find any discussion > about it. Let's say I have code like the following: > > (def a (atom 1)) > ... > (swap! a inc) > (swap! a dec) > > Is there any possibility of another thread seeing a=0? If not, what > provides this guarantee? > No. Not if those two swap! calls are made from different threads. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com www.olcgen.com -- 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: stuartsierra/component is oop, can clojure namespace self init to solve the dependencies?
How is stuartsierra/component OOP when it is building an immutable object graph? (Contrast that to Guava etc.) On Thu, Jun 18, 2015 at 5:15 AM, Xiangtao Zhou wrote: > hi guys, > > Constructing simple clojure project is trival, just make functions. if the > project grows large, with more datasources, message queue, and other > storages, dependencies problem is on the table. > > One solution is stuartsierra/component, using system to configure > dependencies graph, make component and dependencies resolution separate. > > If we make namespace must run with code block that init the namespace, > like the "start" method in component, is this a good way to solve the > dependencies? > You can do that. But it's not a really good idea to have top-level side-effectful code within namespaces. How are you going to test that ns? How will you do (stop)? Namespaces should only define things. > > because when the namespace is required the first time, the init block > worked once. > > any suggestion is appreciated. > > > - Joe > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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] Introducing Yo-yo, a protocol-less, function composition-based alternative to Component
Hi James,
Interesting idea. Thanks for sharing.
I think you can simplify this:
(yoyo/run-system!
(fn [latch]
(ylet [db-pool (with-db-pool {...})
:let [server-opts {:handler (make-handler {:db-pool db-pool})
:port 3000}]
web-server (with-web-server server-opts)]
(do-this web-server)
(do-that db-pool web-server)
(latch
to:
(yoyo/foo! [db-pool (with-db-pool {...})
:let [server-opts {:handler (make-handler {:db-pool db-pool})
:port 3000}]
web-server (with-web-server server-opts)]
(do-this web-server)
(do-that db-pool web-server))
I believe with-* function can also be simplified further.
On Tue, Jun 23, 2015 at 1:18 AM, James Henderson
wrote:
> Hi all,
>
> I've just released an early version of 'Yo-yo', a protocol-less, function
> composition-based alternative to Component. It's still in its early stages,
> so feedback would be very much appreciated!
>
> https://github.com/james-henderson/yoyo
>
> Yo-yo was also an experiment to see what could be de-coupled from the
> concept of 'reloadable systems', so you won't find any configuration,
> dependency injection, etc - just a way to write a system that can be easily
> started, stopped, and reloaded.
>
> Fundamentally, we start by assuming there's a function available that only
> returns 'when the system stops' - a 'latch', say. If we had such a
> function, we could start our system, call that function, then stop the
> system (closing any necessary resources). A database pool, for example,
> might look like this:
>
> (defn with-db-pool [db-config f]
> (let [db-pool (start-pool! db-config)]
> (try
> (f db-pool)
>
> (finally
> (stop-pool! db-pool)
>
> Here, we're assuming that we'll be passed 'f', the 'latch' function. A
> web server would be similar, and, because they're both functions, they're
> very simple to compose:
>
> (with-db-pool {...}
> (fn [db-pool]
> (with-web-server {:handler (make-handler {:db-pool db-pool})
> :port ...}
> (fn [web-server]
> ;; TODO: Ah. We've run out of turtles. :(
>
>
> This is where Yo-yo comes in - there’s a function called run-system!,
> which takes a function that accepts a latch:
>
> (:require [yoyo])
>
> (yoyo/run-system!
> (fn [latch]
> (with-db-pool {...}
> (fn [db-pool]
> (with-web-server {:handler (make-handler {:db-pool db-pool}) ; n.b.
> we have access to the db-pool here - no need for global state!
> :port ...}
> (fn [web-server]
> (latch))) ; Aha!
>
> run-system! then returns a promise - deliver any value to it, and it'll
> stop the system.
>
> And that's pretty much it! There are a few more functions - mostly to do
> with easily starting/stopping/reloading a system through the REPL, and a
> macro to simplify the 'function staircase' - these are covered in more
> detail in the README. There are some also common components - a database
> pool, a web server, and a simple integration for existing Component systems.
>
> It'd be great to hear your thoughts/ideas, whatever they may be - either
> through here, e-mail, Github, or Twitter - thanks!
>
> 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.
>
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
--
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: Writing REST api the right way
On Tue, Jun 23, 2015 at 11:19 AM, Mike Grabowski wrote: > Hey guys, > > I am so excited to join Clojure bandwagon, last weeks have been super > exciting, pretty much in love with Clojure syntax. As we are currently > building an application broken into smaller micro services, I thought I am > gonna make one or two Clojure based modules. Although the initial purpose > of picking the language was to do some CPU demand calculations and data > processing, I found it really simple yet enjoyable to write REST api as > well (we also use Node.js and Elixir for that purpose and it works pretty > well - especially with Elixir thanks to awesome yet simple Erlang model > where you can `spawn&block` and be happy). > > I've seen lots of benchmarks already featuring Aleph, Jetty, Vert.x and > other HTTP servers and I am currently with `Aleph` thanks to its ability to > handle channels and futures out of the box. Unfortunately, because I spent > so many years with Node.js and stopped using Java ages ago, I just can't > stop thinking about non-blocking evented IO interactions. It just does not > feel right to me to block the thread when e.g. logging in an user. > Unfortunately, there are no NIO drivers for the database engines I am > interested in (Neo4J, Mongo) so async channels are not the way to go. > > Any advices or interesting thoughts? Maybe I am missing something as I am > not entirely sure if evented IO is always speeding up the overall > performance. Any performance optimisations are welcome. I am especially > unhappy with one Neo4J request that takes 1.5 second to finish (it's only > because the database is hosted on free Heroku plan and this is not going to > happen in production but I find it quite a good place to tweak the > optimisations and concurrency). > > Another question is - is there any documentation generator that can parse > your comments, take keywords like `:params` or `:returns` (just the idea) > and generate beautiful API docs out of the box? Swagger is not a way to go > as it requires me to use `Schema` plugin - I am currently with `bouncer` > thanks to more real-life validators as well as user friendly messages that > I can just print to users out of the box (maybe it's worth building as an > open source module then) > It would be really cool if documentation could be generated from Liberator resource defs (http://clojure-liberator.github.io/). Maybe it's possible right now and I don't know about it. > > Thanks > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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] Introducing Yo-yo, a protocol-less, function composition-based alternative to Component
On Tue, Jun 23, 2015 at 11:47 PM, James Henderson
wrote:
> Hi Atamert - thanks :)
>
> I thought it might be preferable to keep the call to (latch)explicit - it
> means that ylet can be used in nested calls, too - for example, to set up
> and compose groups of components/sub-systems: (contrived example, though!)
>
> ;; (docs for ylet at https://github.com/james-henderson/yoyo#introducing-ylet
> )
>
> (require '[yoyo :refer [ylet]])
>
> (defn with-connections [config f]
> (ylet [db-pool (with-db-pool (:db config))
> es-conn (with-es-connection (:elasticsearch config))]
>
> (f {:db-pool db-pool
> :es-conn es-conn})))
>
> (defn make-system [latch]
> (let [config ...]
> (ylet [connections (with-connections system)
>_ (with-webserver {:handler (make-handler (merge connections
> {:config config}))
> :port 3000})]
> (latch
>
>
> How would you see the with-* functions working, btw?
>
I think the general idea should be to provide a clean API to the consumer
(of your lib). Perhaps something that accepts a start function, a stop
function and some sort of main loop (f in your example).
>
> Cheers,
>
> James
>
> On Tuesday, 23 June 2015 09:57:16 UTC+1, Atamert Ölçgen wrote:
>>
>> Hi James,
>>
>> Interesting idea. Thanks for sharing.
>>
>> I think you can simplify this:
>>
>> (yoyo/run-system!
>> (fn [latch]
>>(ylet [db-pool (with-db-pool {...})
>> :let [server-opts {:handler (make-handler {:db-pool db-pool})
>> :port 3000}]
>> web-server (with-web-server server-opts)]
>> (do-this web-server)
>> (do-that db-pool web-server)
>> (latch
>>
>>
>> to:
>>
>> (yoyo/foo! [db-pool (with-db-pool {...})
>> :let [server-opts {:handler (make-handler {:db-pool db-pool})
>>:port 3000}]
>> web-server (with-web-server server-opts)]
>> (do-this web-server)
>> (do-that db-pool web-server))
>>
>>
>> I believe with-* function can also be simplified further.
>>
>>
>> On Tue, Jun 23, 2015 at 1:18 AM, James Henderson
>> wrote:
>>
>>> Hi all,
>>>
>>> I've just released an early version of 'Yo-yo', a protocol-less,
>>> function composition-based alternative to Component. It's still in its
>>> early stages, so feedback would be very much appreciated!
>>>
>>> https://github.com/james-henderson/yoyo
>>>
>>> Yo-yo was also an experiment to see what could be de-coupled from the
>>> concept of 'reloadable systems', so you won't find any configuration,
>>> dependency injection, etc - just a way to write a system that can be easily
>>> started, stopped, and reloaded.
>>>
>>> Fundamentally, we start by assuming there's a function available that
>>> only returns 'when the system stops' - a 'latch', say. If we had such a
>>> function, we could start our system, call that function, then stop the
>>> system (closing any necessary resources). A database pool, for example,
>>> might look like this:
>>>
>>> (defn with-db-pool [db-config f]
>>> (let [db-pool (start-pool! db-config)]
>>> (try
>>> (f db-pool)
>>>
>>> (finally
>>> (stop-pool! db-pool)
>>>
>>> Here, we're assuming that we'll be passed 'f', the 'latch' function. A
>>> web server would be similar, and, because they're both functions, they're
>>> very simple to compose:
>>>
>>> (with-db-pool {...}
>>> (fn [db-pool]
>>> (with-web-server {:handler (make-handler {:db-pool db-pool})
>>> :port ...}
>>> (fn [web-server]
>>> ;; TODO: Ah. We've run out of turtles. :(
>>>
>>>
>>> This is where Yo-yo comes in - there’s a function called run-system!,
>>> which takes a function that accepts a latch:
>>>
>>> (:require [yoyo])
>>>
>>> (yoyo/run-system!
>>> (fn [latch]
>>> (with-db-pool {...}
>>> (fn [db-pool]
>>> (with-web-server {:handler (make-handler {:db-pool db-pool}) ; n.b.
>>> we have access to the db-pool here - no need for global state!
>>>
[ANN] aleph-middleware: Ring middleware that support deferred responses.
Hi, https://github.com/muhuk/aleph-middleware This is library that provides deferred-friendly versions of some of the middleware that's shipped with ring-core. Specifically ones that modify responses. They were choking on deferred's so I had to modify them a bit. Let me know if it's useful. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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] Introducing Yo-yo, a protocol-less, function composition-based alternative to Component
mponent due to its invasive protocol but in essence
>>> I do the same.
>>>
>>> In my system I just set up a map of components and use that as a
>>> descriptor for wiring:
>>>
>>> {:a {:depends-on []
>>> :start my.components.a/start
>>> :stop my.components.a/stop}
>>> :b {:depends-on [:a]
>>> :start my.components.b/start
>>> :stop my.components.b/stop}}
>>>
>>> The key in the outer map becomes whatever the :start function returns
>>> and is refered to it by its name :a (the key of the map). The :start
>>> function of :b is called as (my.components.b/start instance-of-a). An
>>> instance of a component is treated as an opaque value and other components
>>> interact with it only via its "public" interface (ie. my.components.a).
>>> Whether this is done via a protocol or not doesn't matter. When a shutdown
>>> is requested the :stop function is called with the instance of the
>>> component as the argument.
>>>
>>> That is about it. Mocking is just assoc over default descriptor map and
>>> I have helper functions to only do partial start/stop calls if only a
>>> specific component is needed (eg. I only need :a).
>>>
>>> Like I said it basically does the same stuff as Component, just a little
>>> less invasive since I think a component should not know about the container
>>> it runs in.
>>>
>>
>> Looks another interesting approach :) I'm currently hacking on some
>> similar ideas myself - think there's plenty of room for iteration in this
>> area at the moment!
>>
>>
>>> Hope that was somewhat useful as feedback to Yo-Yo.
>>>
>>
>> Certainly was! Thanks! :)
>>
>>
>>>
>>> Cheers,
>>> /thomas
>>>
>>>
>>> On Sunday, June 28, 2015 at 4:03:34 PM UTC+2, James Henderson wrote:
>>>>
>>>> As promised, have blogged: 'Yo-yo & Component - Side by Side
>>>> <https://github.com/james-henderson/yoyo/blob/master/articles/side-by-side.org>
>>>> '
>>>>
>>>> Contents:
>>>>
>>>>
>>>>- Making components
>>>>
>>>> <https://github.com/james-henderson/yoyo/blob/master/articles/side-by-side.org#making-components>
>>>>- Using a component as a dependency
>>>>
>>>> <https://github.com/james-henderson/yoyo/blob/master/articles/side-by-side.org#using-a-component-as-a-dependency>
>>>>- Serving a REST API
>>>>
>>>> <https://github.com/james-henderson/yoyo/blob/master/articles/side-by-side.org#serving-a-rest-api>
>>>>- Wiring it all up
>>>>
>>>> <https://github.com/james-henderson/yoyo/blob/master/articles/side-by-side.org#wiring-it-all-up>
>>>>- Yo-yo / Component Interoperability
>>>>
>>>> <https://github.com/james-henderson/yoyo/blob/master/articles/side-by-side.org#yo-yocomponent-interoperability>
>>>>- Mockable Services
>>>>
>>>> <https://github.com/james-henderson/yoyo/blob/master/articles/side-by-side.org#mockable-services>
>>>>- ‘Mocking out’ dependencies
>>>>
>>>> <https://github.com/james-henderson/yoyo/blob/master/articles/mocking-out-dependencies>
>>>>
>>>> Let me know what you think!
>>>>
>>>> Cheers,
>>>>
>>>> James
>>>>
>>>> On Thursday, 25 June 2015 09:25:56 UTC+1, James Henderson wrote:
>>>>>
>>>>> Seems like the next step for this would be for me to put together a
>>>>> blog with an example Component system, and its equivalent Yoyo system?! :)
>>>>> Should have time for that over the weekend.
>>>>>
>>>>> James
>>>>>
>>>>> On Thursday, 25 June 2015 09:05:39 UTC+1, James Henderson wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wednesday, 24 June 2015 11:17:41 UTC+1, Atamert Ölçgen wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jun 23, 2015 at 11:47 PM, James Henderson <
>>>>>>> ja...@jarohen.me.uk> wrote:
>>>>>>>
>>>>>>>> Hi Atamert - thanks :)
>>>>>>>>
>>>>>
Re: Game logic with Clojure
+1 for Caves of Clojure. I would also take a look at these blog posts: http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/ Not Clojure specific, but I think they're good for getting the general concepts. On Mon, Jun 23, 2014 at 11:37 PM, Mark Mandel wrote: > If you are looking for another example, here is my pong clone with > play-clj, and my own Entity Component system, brute. > https://github.com/markmandel/brute-play-pong > > I also use an atom that I reset! on each game loop. Because it's > integrated with play-clj (and therefore libgdx) there is a bit more mutable > state in there than normal. > > Mark > > > On Tue, Jun 24, 2014 at 7:45 AM, James Reeves > wrote: > >> I typically keep my state in an atom, and use swap! to update it. This >> means I can decouple rendering and other things from the actual game logic. >> However, depending on how your application functions, you might just be >> able to keep the state in a loop. >> >> - James >> >> >> On 23 June 2014 21:53, Majen Ful wrote: >> >>> Thank you all ! >>> @James, I confirm it is like Bang! (same editor), but I prefer this ;-) >>> >>> So in fact I don't have to have a state to update, instead, I just pass >>> my init state to functions/loops to get a new one. >>> >>> Le lundi 23 juin 2014 21:54:56 UTC+2, Majen Ful a écrit : >>> >>>> Hello all, >>>> >>>> First, thank you all for your contribution and your help. I just follow >>>> Clojure's news and groups, and I'm really impressed by how this community >>>> is pleasant and helpful. >>>> >>>> Well, I am new to Clojure world, I do programming as a hobby (I'm not >>>> pro) and I don't have advanced knowledges. However I really enjoy >>>> programming and I like games. In a "classic" language, as Ruby or Java, I >>>> can use mutable states and objects so it is "easy" to reason. In Clojure, I >>>> understand how immutability works, but I still miss some reflexes. >>>> >>>> My goal is to build a little card game like http://boardgamegeek.com/ >>>> boardgame/128667/samurai-sword >>>> A lot of things to do, but I have some difficulties at beginning. >>>> >>>> For example, I can define cards, I can define some function (isdead, >>>> attack)... But how can I save the state of the game ? When a player attacks >>>> another player, the second player must have its life reduced. At this >>>> point, my OO reflexes are went back and don't find a solution. >>>> >>>> Could you give me some tips and lead me to the right things to do. >>>> >>>> Thanks by advance :-) >>>> >>> -- >>> 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. >> > > > > -- > E: mark.man...@gmail.com > T: http://www.twitter.com/
Re: Code health metrics
My toolbox is: lein-cloverage (mostly vanity), Midje (TDD), Eastwood (to decrease wtf/minute) + lein check (once in a while). No fancy cyclomatic coupling hyperdrives. Metrics become more important in larger teams, say 3+ people. They don't add much value for small teams as everyone can follow up with everybody else and provide direct feedback. What's the size of your team? It's harder to (programmatically and statically) analyze dynamic languages. On Wed, Jul 2, 2014 at 4:53 AM, Chris Ford wrote: > Hi all, > > Are there any good tools for measuring the health of a Clojure codebase? > What is even useful to measure for Clojure? Afferent/efferent coupling, > cyclomatic complexity and unit test coverage are metrics I would use for > Java, but do they apply equally to Clojure? > > I'm aware of Clique <https://github.com/Hendekagon/lein-clique> and Vanity > <https://github.com/dgtized/lein-vanity>, which look nice, but they don't > seem to perform any analysis. > > Cheers, > > 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. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: guide on how to plug eastwood into clojure.test unittests?
On Wed, Jul 2, 2014 at 3:01 PM, Andy Fingerhut wrote: > Hopefully someone else can describe their preferred method for adding a > command line invocation like 'lein eastwood' to their checkin/CI/release > process. > @Chris Have you tried adding `lein eastwood` to your build process? If you did, and it didn't work perhaps you can provide more details. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: Why does unquote clone values?
Hi Pascal, On Wed, Jul 2, 2014 at 10:19 PM, Pascal Germroth wrote: > I tried replacing a closure with a dynamically built and evaluated > metafunction but discovered that it was actually slower. > If evaluating code during run is slower than AOT compiling it, it wouldn't surprise me. > I guess f2 runs this much slower than f1 because it doesn't actually pass > a reference to x when unquoting, but clones the value, which means it needs > to compare the lists element-wise. > > This is interesting. Were you able to confirm it or are you just guessing? (I'm just curious.) -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: Why does unquote clone values?
On Thu, Jul 3, 2014 at 11:55 PM, Pascal Germroth wrote: > Hi Atamert, > > Here's a gist with the example code: > https://gist.github.com/neapel/4e502a14e3738b709672 > > I tried replacing a closure with a dynamically built and evaluated >>> metafunction but discovered that it was actually slower. >>> >> >> If evaluating code during run is slower than AOT compiling it, it >> wouldn't surprise me. >> > > I didn't actually try AOT compiling it, just using the REPL. As far as I > understand there shouldn't be a difference in speed, since (eval) runs the > same compiler as AOT does, and even writes out a .class file. > > OK, perhaps I could have phrased it better. I'm not an expert but I believe REPL does compile the forms you enter to bytecode. It compiles an fn form into a JVM class that implements IFn. It also compiles a quoted form (such as `(fn ...) ) but this time it takes the form of a list (as in (list ...) ), IOW it's still data after it is compiled. The latter is executed directly and the former is evaluated (turned into bytecode and then executed perhaps). If I'm wrong on any of these, I'd like to be corrected. I also realize AOT means something slightly different. Something compiled before REPL is started, right? -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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] Debug: clojure port of node debug
Awesome! Thanks for sharing. For those who are wondering what debug does exactly, I suggest checking out the screenshots in the node port's GitHub page. (Any chance you can borrowsteal them?) There's also flatland.useful.debug/? for inspecting forms. ( https://github.com/amalloy/useful/blob/develop/src/flatland/useful/debug.clj ) On Sat, Jul 5, 2014 at 7:10 AM, Sun Ning wrote: > Hi all, > > I just ported node debug[1] library to clojure, hoping it could be helpful > in clojure world. The debug library is widely used in node projects. The > usage is very simple: print debug message when certain namespace is enabled > via environment variable DEBUG. > > https://github.com/sunng87/debug > > The Clojure version of debug has almost all features of node one. And > there are some advantages: > > * No need to configure module name since we have *ns* in clojure > * Zero overhead in runtime if debug is disabled: the debug macro won't > produce anything > > Compared with logging tools of clojure, the debug library is: > > * Much simpler, no xml or properties at all > * Light weight, no additional dependencies > > > > [1] https://github.com/visionmedia/debug > > -- > 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. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
How can I add meta to an object that doesn't implement IObj?
Obviously I can't. But I need to add this capability to an object. During testing I attach meta to this object that contains an atom. Then I pass this object to other functions, known in runtime. I can't use a dynamic var because all this happens within a mock function that may be retried and run in different threads. I have seen this: http://stackoverflow.com/questions/20724219/simplest-possible-clojure-object-that-can-accept-a-primitive-and-metadata but can't deref it since I can't change the functions that will use it later. If I wrap this object I need to be able to delegate all of its functionality to the original object. I hope this all is not too vague. The code I'm working on is not online yet. But it's for clecs (https://github.com/muhuk/clecs/), I'm adding quickcheck to compare different world implementations. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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 can I add meta to an object that doesn't implement IObj?
Hi François, Thanks for the links. I can't really pass a list since the first function is expecting the object I am passing, then it calls some other functions that were supposed to extract the meta. The problem is, functions that are called later can be executed in a different thread. On Sat, Aug 30, 2014 at 4:29 PM, François Rey wrote: > On 30/08/14 05:15, Atamert Ölçgen wrote: > > Obviously I can't. > > But I need to add this capability to an object. During testing I attach > meta to this object that contains an atom. Then I pass this object to other > functions, known in runtime. I can't use a dynamic var because all this > happens within a mock function that may be retried and run in different > threads. > > In my case I used a list, e.g. (list obj), and used destructuring on the > other side when needed, e.g. [obj :as wobj]. > > > I have seen this: > http://stackoverflow.com/questions/20724219/simplest-possible-clojure-object-that-can-accept-a-primitive-and-metadata > but can't deref it since I can't change the functions that will use it > later. If I wrap this object I need to be able to delegate all of its > functionality to the original object. > > I don't think there's a quick solution without changing the contract. > Whatever solution is chosen you need to keep in mind how this will affect > things like equality, hashing, and instanceof? > Perhaps these links could be a start: > https://groups.google.com/forum/#!topic/clojure/9zCGdW_Q7o8 > > http://stackoverflow.com/questions/9086926/create-a-proxy-for-an-specific-instance-of-an-object-in-clojure > Also, if the meta data is just for you own use, then you might want to > store it yourself in a map with weak references, or just use WeakHashMap > <http://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html> > directly. But then you'll be stateful... > > -- > 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. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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 can I add meta to an object that doesn't implement IObj?
Hi Francis,
On Sat, Aug 30, 2014 at 1:34 PM, Francis Avila wrote:
> It would probably help if you said more about the source of this
> atom-holding object. Is it a plain Java class? A deftype/defrecord? Is it
> final?
>
It's not an atom-holding object. The only guarantee is that this object
extends one (or two) of these protocols:
http://clecs.muhuk.com/api/0.2.1/clecs.world.html
Other than that, it can be anything. A Java class, or a type or a record...
>
>
> If you can control the construction of this object and its class is not
> final, you can subclass it and add an IObj implementation. (Note that most,
> maybe all clojure ways of creating classes create final classes, so this
> technique won't work.) The easiest way to subclass is with `proxy`:
>
> (defn meta-AtomHolder [atom-value metadata]
> (proxy [AtomHolderClass clojure.lang.IObj] ;; [superclass, new
> interfaces]
> [atom-value] ;; constructor args
> (meta [] metadata) ;; subclass method
> (withMeta [newmeta] (meta-AtomHolder newmeta
> => (var user/meta-AtomHolder)
> (meta-AtomHolder (atom "x") {})
> => # user.proxy$AtomHolderClass$IObj$40298964@302c28cc>
> (meta (meta-AtomHolder (atom "x") {}))
> => {}
> (meta (with-meta (meta-AtomHolder (atom "x") {}) {:a 1}))
> => {:a 1}
>
This is really cool. So I can do (deref (meta-AtomHolder (atom "x") {}))
and it would return "x", right?
I have actually managed to solve it using vars, had to move things around a
bit:
https://github.com/muhuk/clecs/blob/master/src/clecs/world/check.clj#L73
>
> If the parent class is final or you can't construct the object yourself,
> you need to delegate method calls from one instance to this object
> instance. I think this is hard-but-not-impossible in java, but I'm not sure.
>
> (Clojurescript has `specify`, which does exactly what you want, but only
> exists because delegation between instances in javascript is trivial.)
>
> On Friday, August 29, 2014 10:16:05 PM UTC-5, Atamert Ölçgen wrote:
>>
>> Obviously I can't.
>>
>> But I need to add this capability to an object. During testing I attach
>> meta to this object that contains an atom. Then I pass this object to other
>> functions, known in runtime. I can't use a dynamic var because all this
>> happens within a mock function that may be retried and run in different
>> threads.
>>
>> I have seen this: http://stackoverflow.com/questions/20724219/
>> simplest-possible-clojure-object-that-can-accept-a-primitive-and-metadata
>> but can't deref it since I can't change the functions that will use it
>> later. If I wrap this object I need to be able to delegate all of its
>> functionality to the original object.
>>
>> I hope this all is not too vague. The code I'm working on is not online
>> yet. But it's for clecs (https://github.com/muhuk/clecs/), I'm adding
>> quickcheck to compare different world implementations.
>>
>>
>> --
>> Kind Regards,
>> Atamert Ölçgen
>>
>> -+-
>> --+
>> +++
>>
>> www.muhuk.com
>>
> --
> 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.
>
--
Kind Regards,
Atamert Ölçgen
-+-
--+
+++
www.muhuk.com
--
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 can I add meta to an object that doesn't implement IObj?
On Mon, Sep 1, 2014 at 1:52 AM, wrote:
> If you don't want to wrap the object in an atom, you can also reify an
> object that supports IDeref which returns your object. All reified objects
> support IObj out of the box.
>
As I said earlier:
... can't deref it since I can't change the functions that will use it
> later.
And again, later:
I can't really pass a list since the first function is expecting the object
> I am passing,
That was why I was asking how to attach metadata.
>
> On Sunday, August 31, 2014 4:55:58 AM UTC-4, Atamert Ölçgen wrote:
>
>> Hi Francis,
>>
>>
>> On Sat, Aug 30, 2014 at 1:34 PM, Francis Avila wrote:
>>
>>> It would probably help if you said more about the source of this
>>> atom-holding object. Is it a plain Java class? A deftype/defrecord? Is it
>>> final?
>>>
>>
>> It's not an atom-holding object. The only guarantee is that this object
>> extends one (or two) of these protocols: http://clecs.muhuk.
>> com/api/0.2.1/clecs.world.html
>>
>> Other than that, it can be anything. A Java class, or a type or a
>> record...
>>
>>
>>
>>>
>>>
>>> If you can control the construction of this object and its class is not
>>> final, you can subclass it and add an IObj implementation. (Note that most,
>>> maybe all clojure ways of creating classes create final classes, so this
>>> technique won't work.) The easiest way to subclass is with `proxy`:
>>>
>>> (defn meta-AtomHolder [atom-value metadata]
>>> (proxy [AtomHolderClass clojure.lang.IObj] ;; [superclass, new
>>> interfaces]
>>> [atom-value] ;; constructor args
>>> (meta [] metadata) ;; subclass method
>>> (withMeta [newmeta] (meta-AtomHolder newmeta
>>> => (var user/meta-AtomHolder)
>>> (meta-AtomHolder (atom "x") {})
>>> => #>> IObj$40298964@302c28cc>
>>> (meta (meta-AtomHolder (atom "x") {}))
>>> => {}
>>> (meta (with-meta (meta-AtomHolder (atom "x") {}) {:a 1}))
>>> => {:a 1}
>>>
>>
>> This is really cool. So I can do (deref (meta-AtomHolder (atom "x") {}))
>> and it would return "x", right?
>>
>> I have actually managed to solve it using vars, had to move things around
>> a bit: https://github.com/muhuk/clecs/blob/master/src/clecs/
>> world/check.clj#L73
>>
>>
>>
>>>
>>> If the parent class is final or you can't construct the object yourself,
>>> you need to delegate method calls from one instance to this object
>>> instance. I think this is hard-but-not-impossible in java, but I'm not sure.
>>>
>>> (Clojurescript has `specify`, which does exactly what you want, but only
>>> exists because delegation between instances in javascript is trivial.)
>>>
>>> On Friday, August 29, 2014 10:16:05 PM UTC-5, Atamert Ölçgen wrote:
>>>>
>>>> Obviously I can't.
>>>>
>>>> But I need to add this capability to an object. During testing I attach
>>>> meta to this object that contains an atom. Then I pass this object to other
>>>> functions, known in runtime. I can't use a dynamic var because all this
>>>> happens within a mock function that may be retried and run in different
>>>> threads.
>>>>
>>>> I have seen this: http://stackoverflow.com/questions/20724219/simplest-
>>>> possible-clojure-object-that-can-accept-a-primitive-and-metadata but
>>>> can't deref it since I can't change the functions that will use it later.
>>>> If I wrap this object I need to be able to delegate all of its
>>>> functionality to the original object.
>>>>
>>>> I hope this all is not too vague. The code I'm working on is not online
>>>> yet. But it's for clecs (https://github.com/muhuk/clecs/), I'm adding
>>>> quickcheck to compare different world implementations.
>>>>
>>>>
>>>> --
>>>> Kind Regards,
>>>> Atamert Ölçgen
>>>>
>>>> -+-
>>>> --+
>>>> +++
>>>>
>>>> www.muhuk.com
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>>
>>> Note that posts from new members are moderated -
[ANN] clecs 1.0.1
clecs is an entity-component-system framework for Clojure. The repo is here: https://github.com/muhuk/clecs Changes Since Version 0.2.x * Replaced function based queries with data driven queries. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: What is the best setup to program Clojurescript IF...
LightTable is awesome. On Thu, Oct 2, 2014 at 11:43 PM, Tony Tam wrote: > I use Sublime and Terminator (terminal) on Ubuntu > > (btw, there's a Clojurescript google group :)) > > On Thursday, October 2, 2014 8:13:14 PM UTC+1, Peter Mancini wrote: >> >> What is the best setup to program Clojurescript IF: >> >>- you hate EMACS >>- use linux or windows >> >> Any suggestions? >> > -- > 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. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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] Example project to illustrate usage of system library
prod-system has a REPL but dev-system doesn't. Is this intentional? https://github.com/danielsz/system/blob/master/example/src/example/systems.clj On Wed, Oct 8, 2014 at 7:57 PM, Daniel Szmulewicz < daniel.szmulew...@gmail.com> wrote: > Hello everybody, > > I noticed a demand for examples in how to put together a web app with the > reloaded approach (Stuart Sierra's components). > > For this reason, I've published an example project in the system library. > > https://github.com/danielsz/system/tree/master/example > > Enjoy. > > Please let me know if you have comments/suggestions/etc. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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] Example project to illustrate usage of system library
On Fri, Oct 10, 2014 at 2:06 PM, Daniel Szmulewicz < daniel.szmulew...@gmail.com> wrote: > Yes, because locally you are in the repl already. The repl in production > is brought in explicitly to be able to login/debug remotely into the > application where it’s hosted. > Does that make sense? > Makes sense. Thanks. > > On Friday, October 10, 2014 7:13:39 AM UTC+3, Atamert Ölçgen wrote: >> >> prod-system has a REPL but dev-system doesn't. Is this intentional? >> >> https://github.com/danielsz/system/blob/master/example/ >> src/example/systems.clj >> >> On Wed, Oct 8, 2014 at 7:57 PM, Daniel Szmulewicz >> wrote: >> >>> Hello everybody, >>> >>> I noticed a demand for examples in how to put together a web app with >>> the reloaded approach (Stuart Sierra's components). >>> >>> For this reason, I've published an example project in the system >>> library. >>> >>> https://github.com/danielsz/system/tree/master/example >>> >>> Enjoy. >>> >>> Please let me know if you have comments/suggestions/etc. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Kind Regards, >> Atamert Ölçgen >> >> -+- >> --+ >> +++ >> >> www.muhuk.com >> > -- > 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. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: State of Clojure 2014 Survey - please contribute!!
Dear Clojurians, > Inclusion of such questions on the survey would be another opportunity > for Clojure to be more than just not unwelcoming to atypical folks and > allow us to purposefully invite more people to this relative paradise we > inhabit. I would simply not fill the survey. Because what does my age or gender or race have to do with a programming language. There is nothing stopping the atypical folks from grabbing a REPL and typing away some code. On Wed, Oct 15, 2014 at 3:33 PM, Bruce Durling wrote: > Jony, > > It is being introduced into what was the intro to OO course. > > cheers, > Bruce > > On Fri, Oct 10, 2014 at 11:27 PM, Jony Hudson > wrote: > > If this is the unofficial survey post of academics using Clojure then I'd > > better add myself to the list :-) > > > > @Bruce do you know what course they're going to be teaching Clojure on at > > Birkbeck? > > > > > > Jony > > > > > > On Friday, 10 October 2014 08:08:28 UTC+1, Bruce Durling wrote: > >> > >> I also know that Birkbeck College University of London is going to be > >> teaching Clojure this year. > >> > >> On Oct 10, 2014 12:01 AM, "Lee Spector" wrote: > >>> > >>> > >>> FWIW I'm another person using Clojure mostly for academic research. And > >>> for computer science education, e.g. I'm currently teaching a > Clojure-based > >>> AI course. I'd be curious to know how many others of us are out there. > And > >>> BTW I think that attention to users in these categories could help to > grow > >>> the community. > >>> > >>> -Lee > >>> > >>> On Oct 9, 2014, at 12:32 AM, Mars0i wrote: > >>> > >>> > Thanks for the survey! > >>> > > >>> > I have a couple of suggestions/questions: > >>> > > >>> > For domains, there are no categories for scientific or other research > >>> > applications. For example, I mainly use Clojure for writing > agent-based > >>> > models for academic research. Would a set of categories in this > area be > >>> > usedful? > >>> > > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > >>> Groups "Clojure" group. > >>> To post to this group, send email to clo...@googlegroups.com > >>> Note that posts from new members are moderated - please be patient with > >>> your first post. > >>> To unsubscribe from this group, send email to > >>> clojure+u...@googlegroups.com > >>> For more options, visit this group at > >>> http://groups.google.com/group/clojure?hl=en > >>> --- > >>> You received this message because you are subscribed to the Google > Groups > >>> "Clojure" group. > >>> To unsubscribe from this group and stop receiving emails from it, send > an > >>> email to clojure+u...@googlegroups.com. > >>> For more options, visit https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > your > > first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > --- > > You received this message because you are subscribed to the Google Groups > > "Clojure" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to clojure+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this 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. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: State of Clojure 2014 Survey - please contribute!!
On Thu, Oct 16, 2014 at 8:30 AM, Ashton Kemerling wrote: > I'm curious if there's any empirical evidence that significant numbers of > people will do that. Suppose I have provided reliable data that shows only 0.1% would refuse to answer such a Survey. A programming related survey with questions about demographics and a stated mission of being inclusive. What would be your moral reasoning for not being inclusive for this group of people? > > > > On Wed, Oct 15, 2014 at 6:23 PM, Mars0i wrote: > >> I don't really get it. I don't see a legitimate reason why anyone would >> refuse to participate in the survey because it included demographic >> questions. The survey is anonymous. The combination of questions is not >> such that it would be at all plausible that anyone could be identified by >> their responses. At worst, answering a few additional questions--or simply >> skipping those questions--would be a very minor annoyance. Is it that some >> people object to the idea that there are disparities due to systemic >> factors in our society? If someone wants to disagree about that, OK, but I >> still don't see how boycotting a survey because it offers respondents the >> opportunity to provide demographic information is reasonable. >> >> On Wednesday, October 15, 2014 2:06:29 PM UTC-5, Sean Corfield wrote: >>> >>> On Oct 15, 2014, at 11:29 AM, Ashton Kemerling >>> wrote: >>> > "I would rather not say" is a common and valid response in these >>> scenarios. >>> >>> Yes, although that doesn't address that there are people who will not >>> complete a survey that even asks such questions (on a philosophical >>> objection to collecting such demographic information). As I said, it's a >>> sensitive issue. >>> >>> As Bridget noted, they'll consider the approach for 2015. >>> >>> 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) >>> >>> >>> >>> -- >> 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. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: Modelling in Clojure
Every programming language is a (somewhat) unique approach to programming. So they all have their ways. Java is best expressed using Java best practices. Python is best expressed using Python best practices. Of course Clojure too is best expressed using Clojure best practices. Having said that; I don't think object oriented paradigm makes a lot sense in a dynamic environment. Clojure is a dynamic language. Data can be the API without major issues because we can handle all kinds of data with ease. (= (seq []) nil), select-keys, fnil etc... Encapsulation is a valuable property when we're in a statically typed environment. We want to hide more because it's a more rigid environment. On Fri, Oct 17, 2014 at 12:23 PM, Armando Blancas wrote: > Sure, that's the theory behind encapsulation, but I'm not convinced there >> are many cases in practice where the API can remain consistent while the >> data changes. >> >> > > I'm not, either. Models that have little or no abstraction --basically > aggregates of related items-- end up having APIs that just reflect their > contents. For years, my tools were the Eclipse refactoring features and the > code (re)generation of the Eclipse Modeling Framework, not encapsulation. I > started using Clojure practices, though not totally convinced until a while > ago Stuart Sierra wrote: "The data *is* the API," which helped me > understand what I was really doing. Whereas I never faced the proverbial > computed-field change, I've now taken good advantage of generic functions > over maps and records. > > -- > 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. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: Modelling in Clojure
On Fri, Oct 17, 2014 at 12:47 PM, Rui Yang wrote: > I am new to clojure. > > My question how to handle version if we expose data directly as api, any > schema change will break the api which may impact third party users. > You can't protect the consumers of your API. You publish your new API and pray. As a consumer I do TDD. So my code is fully tested. Of course most of the 3rd party code is mocked in my tests. When I upgrade a dependency I read the changelog and run my code to see if anything breaks. Clojure is a dynamic language, so there's actually no schema. I suppose I can write integration tests and such... But I doubt they'll be able to catch everything. My point is; as a producer (of libraries) there's little you can do within your code. As a consumer you can do a bit more. > > On Friday, 17 October 2014 15:23:10 UTC+11, Armando Blancas wrote: >> >> Sure, that's the theory behind encapsulation, but I'm not convinced there >>> are many cases in practice where the API can remain consistent while the >>> data changes. >>> >>> >> >> I'm not, either. Models that have little or no abstraction --basically >> aggregates of related items-- end up having APIs that just reflect their >> contents. For years, my tools were the Eclipse refactoring features and the >> code (re)generation of the Eclipse Modeling Framework, not encapsulation. I >> started using Clojure practices, though not totally convinced until a while >> ago Stuart Sierra wrote: "The data *is* the API," which helped me >> understand what I was really doing. Whereas I never faced the proverbial >> computed-field change, I've now taken good advantage of generic functions >> over maps and records. >> > -- > 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. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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] outfn - A macro for clearer, more declarative functions (that are actually macros).
I think this is pretty cool. Instead of thinking it as functions on
steroids, I'd prefer looking at it as a powerful callable abstraction.
How does macroexpand-time validation play with apply (the function)? What
happens if I do (map some-outfn coll) ?
Also implicits confused me a bit. At first I thought they were parameter
defaults. But it seems they're some sort of inheriance mechanism for
callables.
BTW, thanks for taking the time to write a detailed readme. I know this is
a young project and it's probably in heavy development. It shows
professionalism (yes, professionalism in an open source context is a thing)
on your part.
On Thu, Oct 30, 2014 at 3:08 AM, Diogo Almeida wrote:
> Hi everyone,
>
> A couple of coworkers and I were chatting about what some of our biggest
> problems with (our) Clojure code was, and came up with this:
> https://github.com/diogo149/outfn ! We just finished making it, so we
> haven't really battle-tested it, but we would love to hear feedback and
> general thoughts about the approach, and possibly have it evolve with the
> community.
>
> The readme has a bunch examples, so I won't copy-paste it all here, but
> here is a list of things that we are hoping to acheive:
> - bad/inconsistent variable naming
> - function call clarity
> - function dispatch based on inputs instead of arity and allowing the
> usage of a threading macro no matter the order of arguments with 0 overhead
> - static DRY verification
> - decomposing big let blocks easily
> - dependency passing without coupling (and anything that makes us want to
> use a :dynamic var)
> - automatic creation of glue code
>
> Some of our favorite examples:
>
>
> - keyword arguments for function call clarity
> (do-something :user-map x :password-list y)
>
>
> - decomplecting order from function arguments:
> (defoutfn map-v2.0
> "Like map, but better"
> [f coll]
> (map f coll))
>
> ;; threading in a collection
> (->> 5
> range
> (map-v2.0 :f inc :coll)) ;; (1 2 3 4 5)
>
> ;; threading in a function
> (->> 5
> (partial +)
> (map-v2.0 :coll (range 5) :f)) ;; (5 6 7 8 9)
>
>
> - macroexpand-time validation
> (defoutfn outfn
> "what's up doc"
> [foo]
> :foo)
>
> (when nil
> ;; this doesn't get run
> (outfn :fo 2))
> ;; Error! Invalid set of keys #{:fo} for #'outfn.core/outfn
>
>
> - declarative function calls without glue code
> (defoutfn foo-fn {:output :foo}
> "Docstring"
> ([a] 3)
> ([b] 4)
> ([c d] 5))
>
> (defoutfn bar-fn {:implicits #{#'foo-fn}}
> "what's up doc"
> [foo] foo)
>
> ;; Look ma, no glue code
> (bar-fn :foo 2) ;; 2
> (bar-fn :a nil) ;; 3
> (bar-fn :b 42) ;; 4
> (bar-fn :c 11 :d 22) ;; 5
>
> ;; I don't need to know what bar-fn needs - decoupling
> (bar-fn :foo 2 :a 3 :b 4 :c 5 :d 6 :q 72) ;; 2
>
> ;; Laziness is a virtue
> (bar-fn :foo 42 :a (throw Exception.)) ;; 42
>
> --
> 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.
>
--
Kind Regards,
Atamert Ölçgen
-+-
--+
+++
www.muhuk.com
--
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: Transducers: Why left to right rather than right to left?
We had this exact discussion just yesterday. I'd suggest forgetting about the technical details, how comp works etc. for a minute. And think about what we're dealing with. 1. If we are dealing with functions, function composition makes sense to be written left to right and applied right to left. If you were working on paper this would feel natural to you. And that's exactly how comp works. 2. When we're dealing with transducers, they are functions under the hood but you know they're not functions that take a value and return another value[1]. Anyway that's an implementation detail. Rich describes transducers as processes, or steps of instructions. Natural way to deal with these things is to write them top to bottom or left to right and then assume they'll be applied in that same order[2]. 1: A transducer is a function that takes another transducer or a step function and returns a function that wraps it. If I'm not mistaken second application takes a collection and returns a reducing function on that collection. But I'm probably wrong. 2: How does the order change? I hope this incomplete example helps: ;; applied in reverse order (defn f [g] (fn [coll] (g (do-something coll ;; f is applied before g, like transducer composition (comp f g) ;; applied in given order (defn k [j] (fn [coll] (do-something (j coll ;; j is applied before k, like function composition (comp k j) On Thu, Oct 30, 2014 at 11:44 PM, Mars0i wrote: > Caveat: I am still feeling around in the dark in my understanding of > transducers. What I write below may just convey how clueless I am. > > (Meta-caveat: I'm probably spitting into the wind. I should no doubt use > my time more wisely.) > > > Normal function composition is done starting from the right. This is > familiar from mathematics, other Lisps, most languages, and it's how > Clojure's function application and 'comp' work. > > Sometimes it's easier to understand composition going from left to right, > as in many natural languages and as in unix pipes, and Clojure provides > '->' and '->>' to do that. That's good. Best of both worlds. One thing I > like about these operators is that their name clearly indicates the > direction of function application. > > Transducers allow function composition with potential efficiency gains, > but apply functions starting from left to right. But *it does this using > the name 'comp'*, which otherwise applies functions from right to left. > What?? Doesn't that seem like a Bad Thing? Why not use a different name? > (It's like overloading the minus sign so that in some contexts, it > subtracts the first argument from the second.) > > (Is Clojure is getting too popular? Its essential features--prefix > notation, parentheses, purely functional operations, and laziness--aren't > doing enough to scare away Java programmers? :-) > > -- > 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. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: About transients no longer being safe in 1.7-alpha2
On Mon, Nov 3, 2014 at 5:57 PM, Daniel Marjenburgh
wrote:
> Hi,
>
> I just want to address this issue (CLJ-1498
> <http://dev.clojure.org/jira/browse/CLJ-1498>). It was accepted in
> 1.7-alpha2 and I haven't seen a lot of discussion around it, even though
> it's quite a big change.
>
> With this change the following code is possible:
>
With persistents the result would be the same, every time. If this is now
valid Clojure, I didn't run it myself, we are sacrificing consistency. I
don't understand what we're getting in return.
Even the simple example in the ticket (with one future) doesn't make a lot
of sense to me.
Am I missing something obvious?
>
> (let [m (transient {:a 0})
> futs (for [n (range 100)]
> (future (assoc! m :a (inc (:a m)]
> (mapv deref futs) ; wait until futures are done
> (persistent! m))
>
>
> The results will vary per run, where it used to throw
> an IllegalAccessError: "Transient used by non-owner thread".
>
> I understand the problems of not being able to have 1 go routine access a
> transient, even though it would be safe, but this solution feels like it's
> throwing out the baby with the bathwater. Basically, it's doing away with
> what the following block on clojure.org <http://clojure.org/transients>
> says:
>
> *Transients enforce thread isolation**.* Because each result of a
>> transient operation shares (mutable) structure with the previous, it would
>> be very dangerous if more than one thread were to manipulate a transient at
>> once. In order to prevent this, transients will detect any (read or write)
>> use from a thread other than the one that created them and throw an
>> exception.
>
>
>
>>
>> This may not sound like a concurrency story, but single-thread isolation
>> is actually a very useful concurrency semantic. The whole point of using
>> transients is that doing so is safe, because their use is an isolated
>> implementation detail of otherwise functional code. Having that be enforced
>> means that some things that would normally be very hard to make safe with
>> ordinary mutable data structures become easy.
>
>
> I don't have a good solution for dealing with transients and logical
> threads, but I would much prefer keeping the semantics of transients as
> they are and maybe pass an option to transient to disable owner checking.
>
> --
> 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.
>
--
Kind Regards,
Atamert Ölçgen
-+-
--+
+++
www.muhuk.com
--
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: About transients no longer being safe in 1.7-alpha2
Thanks Alex!
Now that I took a second look at Daniel's code, it seems assoc! is used
like swap!, as if it would modify m in place. So I would expect, if it runs
without errors, result to be {:a 0}.
Given that transients are values (not reference types like ref or atom) I
can't think of a case where they can be modified concurrently.
On Tue, Nov 4, 2014 at 11:19 AM, Alex Miller wrote:
>
>
> On Monday, November 3, 2014 9:00:10 PM UTC-6, Atamert Ölçgen wrote:
>>
>>
>>
>> On Mon, Nov 3, 2014 at 5:57 PM, Daniel Marjenburgh
>> wrote:
>>
>>> Hi,
>>>
>>> I just want to address this issue (CLJ-1498
>>> <http://dev.clojure.org/jira/browse/CLJ-1498>). It was accepted in
>>> 1.7-alpha2 and I haven't seen a lot of discussion around it, even though
>>> it's quite a big change.
>>>
>>> With this change the following code is possible:
>>>
>>
>> With persistents the result would be the same, every time. If this is now
>> valid Clojure, I didn't run it myself, we are sacrificing consistency. I
>> don't understand what we're getting in return.
>>
>> Even the simple example in the ticket (with one future) doesn't make a
>> lot of sense to me.
>>
>> Am I missing something obvious?
>>
>
> Transients always expect thread isolation. In the past this was locked to
> a single thread (the one that made the transient). That restriction now
> extends to being used by multiple threads, but isolation should still be
> maintained for proper use.
>
> What we are gaining is the ability to use transient collections in go
> blocks with core.async, where the thread being used is just one pool out of
> a thread. For example (just typing this not running it, so excuse any
> typos):
>
> (defn drain [ch coll]
> (let [t (transient []]
> (go-loop
> (if-some [v ( (do (conj! t v) (recur))
> (persistent! t)
>
> This doesn't necessarily work in core.async because each time the parks, it may be woken up with a different thread from the pool. The
> transient change allows this kind of code to succeed.
>
>
>>
>>> (let [m (transient {:a 0})
>>> futs (for [n (range 100)]
>>> (future (assoc! m :a (inc (:a m)]
>>> (mapv deref futs) ; wait until futures are done
>>> (persistent! m))
>>>
>>>
>>> The results will vary per run, where it used to throw
>>> an IllegalAccessError: "Transient used by non-owner thread".
>>>
>>> I understand the problems of not being able to have 1 go routine access
>>> a transient, even though it would be safe, but this solution feels like
>>> it's throwing out the baby with the bathwater. Basically, it's doing away
>>> with what the following block on clojure.org
>>> <http://clojure.org/transients> says:
>>>
>>> *Transients enforce thread isolation**.* Because each result of a
>>>> transient operation shares (mutable) structure with the previous, it would
>>>> be very dangerous if more than one thread were to manipulate a transient at
>>>> once. In order to prevent this, transients will detect any (read or write)
>>>> use from a thread other than the one that created them and throw an
>>>> exception.
>>>
>>>
>>>
>>>>
>>>> This may not sound like a concurrency story, but single-thread
>>>> isolation is actually a very useful concurrency semantic. The whole point
>>>> of using transients is that doing so is safe, because their use is an
>>>> isolated implementation detail of otherwise functional code. Having that be
>>>> enforced means that some things that would normally be very hard to make
>>>> safe with ordinary mutable data structures become easy.
>>>
>>>
>>> I don't have a good solution for dealing with transients and logical
>>> threads, but I would much prefer keeping the semantics of transients as
>>> they are and maybe pass an option to transient to disable owner checking.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
Re: About transients no longer being safe in 1.7-alpha2
FWIW I can confirm the following code produces {:a 90} consistently:
(let [v (transient {:a 0})
f1 (delay (reduce #(assoc! % :a (+ (:a %) %2)) v (range 10)))
f2 (delay (reduce #(assoc! % :a (+ (:a %) %2)) v (range 10)))]
@f1 @f2 ; wait for futures
(persistent! @f1))
Note that there are no future calls here. Clojure 1.5.1
Part of me wants the result to be {:a 45}
On Tue, Nov 4, 2014 at 3:13 PM, Daniel Marjenburgh
wrote:
> I was a bit too quick there and posted some errors int he code:
>
> (let [v (transient {:a 0})
> f1 (future (reduce #(assoc! % (+ (:a %) %2)) v (range 10)))
> f2 (future (reduce #(assoc! % (+ (:a %) %2)) v (range 10)))]
> @f1 @f2 ; wait for futures
> (persistent! @f1))
>
>
>>>> --
> 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.
>
--
Kind Regards,
Atamert Ölçgen
-+-
--+
+++
www.muhuk.com
--
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: Deterministic Randomness in Functional Clojure
clojure-lanterna is pretty cool. https://github.com/sjl/clojure-lanterna I'm interested in hearing about alternatives as well. On Wed, Nov 5, 2014 at 4:09 AM, blake wrote: > Pardon my interruption: What are you using for screen output for your > roguelike? > > On Tue, Oct 28, 2014 at 12:08 PM, Isaac Karth > wrote: > >> I've been working on some projects (roguelikes, story-generators) that >> often have a reason to have a random outcome for things like procedurally >> generating a map. Ideally, they would be deterministically psuduorandom, so >> that I can generate the same results from the same seed. The part I'm >> having trouble with is figuring out what method to use to implement this in >> a functional way. >> >> The naive approach that first occurred to me was to pass a PRNG and seed >> value into each function. That would certainly keep the functions >> referentially transparent. But it would also require either rewriting a >> bunch of functions that don't directly use the randomness themselves or >> adding the RNG as part of the map that's already being passed. >> >> Plus, the seed should probably vary (deterministically) between calls to >> the subfunctions. It's not too useful if all the rooms on a map have the >> same type because they all pulled their die roll from the same-nth result >> of the exact same seed. Maybe the seed could be created from the contents >> of the vector or a UUID of a map object or something? >> >> The other suggestion I've run across is to rebind something like >> clojure.data.generators/*rnd* for each high-level procedural generation >> call. I think this requires the generation to be single threaded and >> otherwise deterministic. At the moment I don't feel like I know enough >> about how things work under the hood to say if this a good idea or not. >> >> I've poked around at the bigml.sampling and clojure.data.generators >> libraries, which look useful for dealing with some of this, but I haven't >> come across anything that directly addresses what kind of architecture to >> use for deterministic randomness. This may be my inexperience. I feel like >> I may be a bit too close to the problem, and I can't quite see what the >> idiomatic answer is. Re-read SICP? Implement some kind of monad? Just bite >> the bullet and pass the RNG+seed? Find the secret pure functional library >> everyone is using for repeatable stochastic simulations? >> >> Does anyone have any advice on this? Or prior experience with approaches >> that work? What are some best practices for approaching deterministic >> simulations in an idiomatic, functional way? >> >> -- >> 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. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: About transients no longer being safe in 1.7-alpha2
Hi Daniel, On Wed, Nov 5, 2014 at 3:06 PM, Daniel Marjenburgh wrote: > My concern is purely about the safety that is taken away when transients > 'are' used wrongly. All the examples would've throw exceptions before > 1.7-alpha2, and they don't do so anymore. > > But they would run fine, if you used delay's instead of future's. Same wrong usage, single threaded. So the issue is not really this new change. (See my code with delay's earlier) -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: Get the value of the persistentArrayMap from the exception which was thrown
It wouldn't matter which map is throwing the exception in this case. It's
an arity issue and maps accept 1 or 2 parameters.
https://github.com/clojure/clojure/blob/clojure-1.6.0/src/jvm/clojure/lang/APersistentMap.java
If this wasn't REPL, it would result in a larger stacktrace and sufficient
squinting would reveal the line of originating call.
On Thu, Nov 6, 2014 at 3:19 PM, Michael Blume wrote:
> Well, from the print of the exception, it looks unlikely, but let's look
> at the code. This stacktrace says the exception was thrown in line 429 of
> clojure.lang.AFn, and I'm going to assume you're using Clojure 1.6.0, so we
> want
> https://github.com/clojure/clojure/blob/clojure-1.6.0/src/jvm/clojure/lang/AFn.java#L429
>
> Looking at that line of code, it's creating the exception object using
> only the arity (a number) and the name of the class of the object, a
> string. So no, the map is not recoverable from the exception.
>
>
> On Wednesday, November 5, 2014 10:15:50 PM UTC-8, Sunil Nandihalli wrote:
>>
>> Hi Everybody,
>>
>> user=> ({:a 1})
>>
>> ArityException Wrong number of args (0) passed to: PersistentArrayMap
>> clojure.lang.AFn.throwArity (AFn.java:429)
>> user=> *e
>> #> passed to: PersistentArrayMap>
>>
>> From *e is it possible to infer that the object which threw it was {:a 1}?
>>
>> Thanks,
>> Sunil.
>>
> --
> 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.
>
--
Kind Regards,
Atamert Ölçgen
-+-
--+
+++
www.muhuk.com
--
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] Counterclockwise User Plugins reloaded
FWIW this sparked my interest to give CCW another try. I suggest everyone to at least take a look at the source of hello world plugin: https://github.com/laurentpetit/ccw-plugin-hello-world/blob/master/hello-world.clj I wanted to see what features of eclipse is exposed, but I couldn't find CCW's API docs hosted anywhere. Instead I've found this: https://github.com/laurentpetit/ccw/blob/ea26df9ff64464c6ed796cc12d60a41be0cd2b6f/ccw.core/src/clj/ccw/eclipse.clj On Fri, Nov 14, 2014 at 5:21 AM, Laurent PETIT wrote: > Hi again, > > I've published the 'Hello World' of User Plugins project: > https://github.com/laurentpetit/ccw-plugin-hello-world > > The README describes how to install it, and how to live code it. > > Cheers, > > -- > Laurent > > > 2014-11-13 17:34 GMT+01:00 Laurent PETIT : > >> Since there has been interest in writing User Plugins this last month, >> I've decided to be more serious about it. >> >> *Counterclockwise User Plugins allow you to customize Counterclockwise / >> Eclipse with Clojure!!* >> >> *User Plugins are...* >> >> - *Safe*: plug / unplug user plugins by adding / deleting repos clones >> from ~/.ccw/ >> - *Dynamic*: with the help of ccw-plugin-manager, you can open your user >> plugins as regular Eclipse projects, use the Eclipse embedded REPL to >> interact with your current environment *live*, as usual with Clojure! >> - *Powerful*: user plugins are added to Counterclockwise's classpath and >> can access the same Eclipse services Counterclockwise has access to. >> - *Agile*: updating a user plugin is as simple as 1. git checkout 2. >> Alt+U S (re[S]tart plugins) >> >> *[ANN] ccw-plugin-manager Plugin* >> I've created a Github repository for the mother of all CCW User plugins: >> ccw-plugin-manager. >> The intent of this plugin is to provide tooling for developing User >> Plugins ! >> >> The plugin is available at Github, with Installation and Usage in the >> README: https://github.com/laurentpetit/ccw-plugin-manager >> >> *Documentation:* >> User Plugins documentation: >> http://doc.ccw-ide.org/documentation.html#_user_plugins >> >> *More to come:* >> - ccw-plugin-hello-world: a project for helping get started with User >> Plugins, showing the basics and explaining the expected workflow. >> - ccw-plugin-async: a project for connecting to save actions, launch >> actions, repl interactions, etc. >> >> Enjoy! >> >> -- >> Laurent Petit >> > > > > -- > Laurent Petit > > -- > 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. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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] differ v0.1.0, a tool for creating, and applying, diffs on clojure(script) datastructures
Hi Robin,
Thanks for adding a README. It might contain a couple of errors though.
I can't make sense of this for example:
(def person-map {:name "Robin"
:age 25
:sex :male})
(def person-diff (differ/diff test-map {:name "Robin Heggelund Hansen"
:age 26})
;; person-diff will now be [{:name "Robin Heggelund Hansen", :age
26};; {:sex 0}]
Where did test-map come from? I'm assuming it's person-map. Why is :sex 0?
Is he fat and bald? If that's a list of keys that's removed, I suggest
using a set there.
(differ/patch {:specie :dog
:sex :female}
person-diff)
;; Will return {:name "Robin Heggelund Hansen";; :age
26;; :specie :dog}
Shouldn't the result contain [:sex :female] as well?
On Tue, Nov 18, 2014 at 3:51 AM, Robin Heggelund Hansen <
skinney...@gmail.com> wrote:
> https://github.com/Skinney/differ
>
> I needed a way to send diffs of data from a cljs web-app to a clj backend,
> and I found clojure.data/diff to be a pain to work with, so i created my
> own solution. It currently only supports maps (and nested maps...), but
> support for lists, vectors and sets is on the roadmap for the next version.
> This version is mostly for me to test with my own app, which currently only
> uses maps.
>
> --
> 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.
>
--
Kind Regards,
Atamert Ölçgen
-+-
--+
+++
www.muhuk.com
--
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] co-dependency in stuartsierra/component
Hi Juan, I thought co-dependencies ought to be designed out. Could you give a use case for co-dependency? On Tue, Dec 2, 2014 at 7:16 PM, JUAN ANTONIO Ruz wrote: > *co-dependency* is a library that lets you use "*cyclic*" dependencies in > stuartsierra/component systems > > In other words, :a depends-on :b, :b (co-)depends-on :a > > Although I used "cyclic" word, this co-dependency library is designed on > the idea that components don't need co-dependencies to start as normal > dependencies. > > co-dependency follows the pattern described in > stuartsierra/component#customization > <https://github.com/stuartsierra/component#customization> to accomplish > this "cyclic" feature > > You can find all the details about this lib on > https://github.com/tangrammer/co-dependency > > > -- > 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. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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] co-dependency in stuartsierra/component
Thanks for the explanation. Yes, it makes sense. Without this library I would do something similar myself. You are using deref (pragmatic clojure) and the relationship is explicit (in system map), both are advantages. It is possible to design around it though; separate the common parts, say the container of webservices in your first example (as :c) and then make both :a and :b depend on :c, and :b to depend on :a too for instance. A component doesn't have to be immutable, or has to be initialized all at once (during start). I imagine it can have other life-cycle event and change its state. Anyways I see myself as a potential user of your library. I'm just sharing my thoughts. On Tue, Dec 2, 2014 at 8:33 PM, JUAN ANTONIO Ruz wrote: > Hi Atamert, > I realised too the discouraged note > <https://github.com/stuartsierra/component#disadvantages-of-the-component-model> > about cyclic dependencies but although your closed "parent->child" > component relations is logically perfect on start your system, when system > "is ready to work" it's very useful to open the door to "child->parent" > relation too, so the "child" component can communicate with "parent" > component. > Here a couple of examples that you could find this reverse relation: > * routing (router and webservices). webservice could need to know which > other webservices are connected to its "parent" router to construct urls ( > modular/bidi <https://github.com/juxt/modular/tree/master/modules/bidi>) > * templating (menu and menu-items). Menu-items could need to know which > others menu-items are used/displayed on the menu component to adapt their > renderer > > Does this explanation make sense to you? > > Thanks for reviewing > Juan > > El martes, 2 de diciembre de 2014 12:55:42 UTC+1, Atamert Ölçgen escribió: >> >> Hi Juan, >> >> I thought co-dependencies ought to be designed out. Could you give a use >> case for co-dependency? >> >> >> On Tue, Dec 2, 2014 at 7:16 PM, JUAN ANTONIO Ruz >> wrote: >> >>> *co-dependency* is a library that lets you use "*cyclic*" dependencies in >>> stuartsierra/component systems >>> >>> In other words, :a depends-on :b, :b (co-)depends-on :a >>> >>> Although I used "cyclic" word, this co-dependency library is designed on >>> the idea that components don't need co-dependencies to start as normal >>> dependencies. >>> >>> co-dependency follows the pattern described in stuartsierra/component# >>> customization <https://github.com/stuartsierra/component#customization> to >>> accomplish this "cyclic" feature >>> >>> You can find all the details about this lib on https://github.com/ >>> tangrammer/co-dependency >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Kind Regards, >> Atamert Ölçgen >> >> -+- >> --+ >> +++ >> >> www.muhuk.com >> > -- > 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. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: Richelieu: a library for advising functions
Just a small suggestion; I would make :unadvisable namespaced since it's richelieu specific. On Wed, Dec 3, 2014 at 6:01 AM, Gary Verhaegen wrote: > At a very superficial glance, it looks like dire also sort of fits into > the same space: https://github.com/MichaelDrogalis/dire > > > On Tuesday, 2 December 2014, Edwin Watkeys wrote: > >> Phillip, >> >> Of Robert Hooke's features, I think the ability to suppress advice >> temporarily (its `with-hooks-disabled`) as well to advise a function within >> a particular dynamic scope (`with-scope`) are most relevant to Richelieu. >> Since one of the major goals of Richelieu is to serve as a generic basis >> for advising, I'll probably implement a `with-advice-disabled` form that >> takes a sequence of advisedf-and-advicef-set values to temporarily suppress. >> >> R.H. and Richelieu, while they do much the same thing, seem to be >> orthogonal to each other in terms of intent: Richelieu exists to allow >> folks to write arbitrary advice-based facilities that are oblivious to each >> others' existences, decorating functions that weren't written with being >> advised in mind—think tracing and profiling. Phil, on the other hand, >> focused on providing a facility for developers who anticipate that their >> code might be advised à la the Emacs hooks mechanism. Or not. I'm totally >> speculating. >> >> As for the name, I guess I'm willing to overlook some semantic >> quibbles—especially since something very similar to Emacs's normal hooks >> could easily built atop R.H.—in pursuit of a charming allusion. >> >> Edwin >> >> On Tuesday, December 2, 2014 8:39:37 AM UTC-5, Phillip Lord wrote: >>> >>> >>> I think yours might be nicer, to be honest, though, although Robert >>> Hooke has some features yours doesn't. Advising entire namespaces is an >>> interesting addition for sure. >>> >>> I still don't understand why Robert Hooke has this name though. I can't >>> have been the only person expecting it to implements hooks. >>> >>> Phil >>> >>> Edwin Watkeys writes: >>> >>> > Phillip, >>> > >>> > I’d cry if it weren’t so funny; I’ve just begun to make my way through >>> the >>> > lastest Read Eval Print λove and the first page or two dwells on >>> reinvention. >>> > At least mine wasn’t intentional. >>> > >>> > Edwin >>> >>> -- >>> Phillip Lord, Phone: +44 (0) 191 208 7827 >>> Lecturer in Bioinformatics, Email: philli...@newcastle.ac.uk >>> School of Computing Science,http://homepages.cs.ncl.ac. >>> uk/phillip.lord >>> Room 914 Claremont Tower, skype: russet_apples >>> Newcastle University, twitter: phillord >>> NE1 7RU >>> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > -- > 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. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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] silc - a tiny entity database for clojure (games)
This is a very nice example of abstraction. Using a hash-map is just an implementation detail. However I'd be very interested to hear if there are any other compelling > use cases for this. Sparsely populated tables, unstructured anything... We used an EAV abstraction (over SQL) to build a product database. Different product types have very different fields, even same types of product might have different fields sometimes. In hindsight normalized relational tables would have been a better fit (the decision was made before I joined). In your README, the change and delete examples give the impression that they're mutating the db, but they actually return an updated db if I'm not mistaken. On Wed, Dec 3, 2014 at 6:37 AM, wrote: > I have put together a quick library http://github.com/danstone/silc that > allows you to manage many entities and their attributes in a pure way with > indexing for performance, include composite indexes. > > The intention of the library is certainly as the basis for an entity > component system for games, that is how I am using it. However I'd be very > interested to hear if there are any other compelling use cases for this. > > Pull requests welcome! > > Thanks, > > Dan > > -- > 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. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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] silc - a tiny entity database for clojure (games)
Why are you using BigDecimal's for indices? If you want to go big, isn't BigInt a better choice? Actually, I would just use Long's. (MAX_VALUE = 9223372036854775807) On Wed, Dec 3, 2014 at 10:04 AM, Atamert Ölçgen wrote: > This is a very nice example of abstraction. Using a hash-map is just an > implementation detail. > > However I'd be very interested to hear if there are any other compelling >> use cases for this. > > > Sparsely populated tables, unstructured anything... We used an EAV > abstraction (over SQL) to build a product database. Different product types > have very different fields, even same types of product might have different > fields sometimes. In hindsight normalized relational tables would have been > a better fit (the decision was made before I joined). > > In your README, the change and delete examples give the impression that > they're mutating the db, but they actually return an updated db if I'm not > mistaken. > > > On Wed, Dec 3, 2014 at 6:37 AM, wrote: > >> I have put together a quick library http://github.com/danstone/silc that >> allows you to manage many entities and their attributes in a pure way with >> indexing for performance, include composite indexes. >> >> The intention of the library is certainly as the basis for an entity >> component system for games, that is how I am using it. However I'd be very >> interested to hear if there are any other compelling use cases for this. >> >> Pull requests welcome! >> >> Thanks, >> >> Dan >> >> -- >> 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. >> > > > > -- > Kind Regards, > Atamert Ölçgen > > -+- > --+ > +++ > > www.muhuk.com > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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] silc - a tiny entity database for clojure (games)
I don't feed trolls. On Wed, Dec 3, 2014 at 10:10 AM, Atamert Ölçgen wrote: > Why are you using BigDecimal's for indices? If you want to go big, isn't > BigInt a better choice? > > Actually, I would just use Long's. (MAX_VALUE = 9223372036854775807) > > On Wed, Dec 3, 2014 at 10:04 AM, Atamert Ölçgen wrote: > >> This is a very nice example of abstraction. Using a hash-map is just an >> implementation detail. >> >> However I'd be very interested to hear if there are any other compelling >>> use cases for this. >> >> >> Sparsely populated tables, unstructured anything... We used an EAV >> abstraction (over SQL) to build a product database. Different product types >> have very different fields, even same types of product might have different >> fields sometimes. In hindsight normalized relational tables would have been >> a better fit (the decision was made before I joined). >> >> In your README, the change and delete examples give the impression that >> they're mutating the db, but they actually return an updated db if I'm not >> mistaken. >> >> >> On Wed, Dec 3, 2014 at 6:37 AM, wrote: >> >>> I have put together a quick library http://github.com/danstone/silc >>> that allows you to manage many entities and their attributes in a pure way >>> with indexing for performance, include composite indexes. >>> >>> The intention of the library is certainly as the basis for an entity >>> component system for games, that is how I am using it. However I'd be very >>> interested to hear if there are any other compelling use cases for this. >>> >>> Pull requests welcome! >>> >>> Thanks, >>> >>> Dan >>> >>> -- >>> 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. >>> >> >> >> >> -- >> Kind Regards, >> Atamert Ölçgen >> >> -+- >> --+ >> +++ >> >> www.muhuk.com >> > > > > -- > Kind Regards, > Atamert Ölçgen > > -+- > --+ > +++ > > www.muhuk.com > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: micrologic - A tiny, literate implementation of miniKanren/core.logic
This is fantastic! Thanks a lot. On Thu, Jan 8, 2015 at 9:26 PM, David Nolen wrote: > Nothing to add other than this is really cool. > > David > > On Thu, Jan 8, 2015 at 1:56 PM, Russell Mull > wrote: > >> Hi fellow Clojurists, >> >> I've been working on a small miniKanren in Clojure. It started as a port >> of https://github.com/jasonhemann/microKanren. But this one is >> interesting because: >> - It's a literate program, with far more description and examples than >> actual code. >> - Many names have been changed to be more descriptive than that which is >> found in the literature, at least to my eye. >> - It's written in idiomatic Clojure. >> >> It should be a good introduction to the way miniKanren and core.logic >> work, especially if you're more software engineer than computer scientist. >> Is this useful, confusing? Wrong in places? please let me know if you have >> any feedback! >> >> http://mullr.github.io/micrologic/literate.html >> >> Cheers, >> >> Russell >> >> >> >> >> -- >> 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. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: Get the name of parameters in a function
On Sat, Jun 4, 2016 at 1:45 AM, James Reeves wrote:
> You can do it with a macro.
>
> - James
>
> On 3 June 2016 at 22:22, Steven Zhou wrote:
>
>> Is it possible to write down a function do the following?
>>
>> (defn foo
>> [input]
>>
>> )
>>
>> (def x "Hello")
>> (def y "Clojure")
>>
>> (foo [x y])
>> => {:x "Hello" :y "Clojure"}
>>
>
This seems to do what you want:
(defmacro foo [vars]
(let [keys_ (mapv keyword vars)]
`(zipmap ~keys_ ~vars)))
Note the difference between ~(mapv keyword vars) & ~vars. The former maps
(keyword) over a vector of symbols, then resolves their value (which is
themselves). The latter resolves the vector of symbols directly, each
element in turn gets resolved to their respective definitions.
If you rewrite this to use a (foo [& vars] ...) and be called as (foo x y),
I think it would be easier to see what's happening.
>
>>
>> Regards,
>> -Steven
>>
>> --
>> 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.
>
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
--
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.9.0-alpha4
On Sat, Jun 4, 2016 at 9:28 AM, <676c7...@gmail.com> wrote:
> This isn’t only an optimisation but also a change in behaviour, isn’t
> it?
>
> Clojure 1.9.0-alpha3:
>
> user=> (let [[x & xs] #{1 2 3}] x)
> UnsupportedOperationException nth not supported on this type:
> PersistentHashSet clojure.lang.RT.nthFrom (RT.java:948)
>
> Clojure 1.9.0-alpha4:
>
> user=> (let [[x & xs] #{1 2 3}] x)
> 1
>
I hope this will be considered a regression and the old behavior will be
restored.
>
> Perhaps the documentation needs to be updated?
> http://clojure.org/reference/special_forms#_vector_binding_destructuring
>
>
> --
> David
>
> --
> 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.
>
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
--
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.9.0-alpha4
Hi Alex,
On Sat, Jun 4, 2016 at 3:22 PM, Alex Miller wrote:
> Why?
>
Because unordered collections shouldn't have heads defined.
Is (first #{3 1 2}) => 3? or 2? or 1?
(I just tried it in a REPL and it is apparently 1.)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
--
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.
spec performance comparison
Hi, I have added spec to validation-benchmark[1]. The results are here: http://muhuk.github.io/validation-benchmark/ Could you please take check if the implementation is correct and reasonable? Also, I am trying to keep all benchmarks self-contained (in one def/defn). It there a way to perform map validation without spec/def'ing ::name, ::age & ::saiyan? 1: https://github.com/muhuk/validation-benchmark -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: spec performance comparison
Hi, I have updated the benchmark results. Thanks to Alex Miller's contributions the results should be a bit more accurate now. http://muhuk.github.io/validation-benchmark/ On Tue, Jun 7, 2016 at 3:16 AM, Daniel wrote: > Awesome! Would be interesting to see other metrics charted eg loc, memory. > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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.
Added truss to validation-benchmark
Hi, Peter Taoussanis was kind enough to contribute truss implementation to validation-benchmark. I have run it (with a few <https://github.com/muhuk/validation-benchmark/commit/7f501a5af769baca4c2fefe5733222a02ff77d7c> upgrades <https://github.com/muhuk/validation-benchmark/commit/68a75036efd28b5eb665406dd99690241eae48d3> to <https://github.com/muhuk/validation-benchmark/commit/edda54ed567c22aadd54d5b0e58b697b8be4c432> other <https://github.com/muhuk/validation-benchmark/commit/1f3b9c5034e5c654414b0d24ac5a60de9e3d4d30> dependencies) and updated the report page. - Personal note: truss is faster than anything else. Much faster. How can this be? It can't be an issue of no-op. Because the wrapper (validation-benchmark.lib.truss/wrapper) is calling the given function. And validation-benchmark.core/prepare-benchmark-for-lib wraps the benchmark function with an assertion on the result (true for valid, false for invalid). Either we have a bug or I am justified to be in awe. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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 1.9.0-alpha10: Semantic mismatch: any? vs not-any?
On Mon, Jul 11, 2016 at 9:01 PM, Alan Thompson wrote: > In clojure we are used to shortcuts involving not: > > (when-not x ...) => (when (not x) ...) > (if-not x ...) => (if (not x) ...) > (not-every? pred coll) => (not (every? pred coll)) > (not-any? pred coll) => (not (some pred coll)) > > However, the new function clojure.core/any? breaks this semantic pattern: > > > > (doc clojure.core/any?) > - > clojure.core/any? > ([x]) > Returns true given any argument. > > > > (doc clojure.core/not-any?) > - > clojure.core/not-any? > ([pred coll]) > Returns false if (pred x) is logical true for any x in coll, > else true. > > These two functions are not only unrelated to each other, but they don't > even accept the same number or type of arguments. Moreover, there is an > even more surprising property: > > > (clojure.core/any? nil) > true > > I would have bet money that, at least for nil, the result would not have > been true. > > Given the significant prior conventions in Clojure for functions like > some, every?, *-not, not-*, and also the general handling of nil, it seems > that the new any? function is bound to cause much confusion & > consternation, especially among people learning Clojure. > > Given the degenerate definition: > > > (source clojure.core/any?) > (defn any? > [x] true) > > I can't think of a single use case where this function would be useful. I would either inline true instead of a function call, or I would supply (constantly true) if a function is expected. I am sure it wouldn't be included in core if there wasn't a valid reason. Could you tell me what is this function good for? > would it not be simpler and more instinctive to rename the function > clojure.core/true: > > (defn clojure.core/true > [x] true) > > We could then have code with the obvious result: > > (true 1) => true > (true "hi") => true > (true [])=> true > (true nil) => true > > I believe that such a change would help to keep Clojure in line with users > instincts and assumptions, as well as past Clojure practices. I have often > felt that one of the most important principles in any sort of software > development is adherence to the Principle of Least Astonishment > <https://en.wikipedia.org/wiki/Principle_of_least_astonishment>. > > Alan > > > > On Mon, Jul 11, 2016 at 7:28 AM, Alex Miller wrote: > >> >> 1.9.0-alpha10 includes the following changes since 1.9.0-alpha9: >> >> - NEW clojure.core/any? - a predicate that matches anything. any? has >> built-in gen support. The :clojure.spec/any spec has been removed. >> Additionally, gen support has been added for some?. >> >> >> >> > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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 1.9.0-alpha10: Semantic mismatch: any? vs not-any?
Thanks Sean, Alex. I understand the rationale now. On Sat, Jul 16, 2016 at 12:38 AM, Alex Miller wrote: > > On Friday, July 15, 2016 at 2:27:56 PM UTC-5, Atamert Ölçgen wrote: >> >> >> I can't think of a single use case where this function would be useful. I >> would either inline true instead of a function call, or I would supply >> (constantly true) if a function is expected. >> >> I am sure it wouldn't be included in core if there wasn't a valid reason. >> Could you tell me what is this function good for? >> > > It's useful for defining specs. > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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] stateful-check 0.3.0 - test stateful systems with test.check
Hi Carlo,
This is an awesome lib. Thanks for sharing.
README mentions the queue example and goes directly into details. I would
inline the queue example and maybe move the Specifications section into a
different file.
On Fri, Jul 31, 2015 at 7:05 AM, Carlo Zancanaro
wrote:
> Hey everyone!
>
> I've just released a new version of my library for testing stateful
> systems with test.check!
>
> [org.clojars.czan/stateful-check "0.3.0"]
>
> https://github.com/czan/stateful-check
> https://clojars.org/org.clojars.czan/stateful-check
>
> Important changes in this version:
>
> + Updated to test.check 0.7.0
>
> + *Breaking: *Postconditions now take two states: the prior and the
> next states. This means that any postconditions being used with 0.2.0 need
> to be changed:
>
> (fn [state args result]
> arbitrary-logic-for-postcondition)
> ;; needs to change to
> (fn [prev-state next-state args result]
> arbitrary-logic-for-postcondition)
>
> + *Breaking: *The old `reality-matches-model?` function has been both
> renamed (to remove the '?', which implied it was a predicate when it's not)
> and deprecated. The `specification-correct?` form below is the preferred
> form now.
>
> + Add a new function, `specification-correct?`, which runs a
> stateful-test specification using test.check. If used within a clojure.test
> `is` assertion it will also print helpful output:
>
> (is (specification-correct? queue-spec {:seed 1417059242645}))
> ;;
> ;; FAIL in clojure.lang.PersistentList$EmptyList@1
> (form-init1067629020891437332.clj:1)
> ;;#<0> = (:new) => # clojure.lang.PersistentQueue@1>>
> ;;#<2> = (:push #<0> 0) => nil
> ;;#<3> = (:pop #<0>)=> # clojure.lang.PersistentQueue@1>
> ;; Error while checking postcondition
> ;; Seed: 1417059242645
> ;;
> ;; expected: :pass
> ;; actual: :fail
>
> I hope somebody finds this useful!
>
> Carlo
>
> --
> 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.
>
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
--
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: (fail promise exception)
Hi William, Manifold deferreds can capture exceptions like future does. http://aleph.io/manifold/deferreds.html On Sat, Aug 8, 2015 at 12:44 AM, William la Forge wrote: > Still a newbie here, about to release my first Clojure project. But that > clojure blob will take some digging on my part. I use a gummed up > dereference function that checks for Throwable in the meantime. > > My goal right now is to become a Dtomic freelancer. So much to learn! > Which is why I'm doing projects. Only way I know to become proficient! So > yeah, I need to get to the point where I can roll my own. Similarly, my > first project builds on the send method, but I really need to get to the > point where I can roll my own agent. > > In any case, thanks Francis. I can only promise more dumb questions in the > future. ;-) > > > On Friday, August 7, 2015 at 5:24:24 PM UTC-4, Francis Avila wrote: >> >> Huh, I was sure I had done this before, but I misremembered, I was using >> my own promise that rethrew Throwable instances on deref (and it was in >> clojurescript!) >> >> Clojure promises have no notion of failure, only realized/not-realized. >> You need to deliver a sentinel type or value and check for it on deref, or >> implement your own promise type which does it for you. (It's not that hard: >> https://github.com/clojure/clojure/blob/clojure-1.7.0/src/clj/clojure/core.clj#L6803 >> ) >> >> On Friday, August 7, 2015 at 4:09:39 PM UTC-5, William la Forge wrote: >>> >>> Sorry, I meant to ask how to fail with a promise? It seems that there is >>> no fail method. >>> >>> On Friday, August 7, 2015 at 4:52:47 PM UTC-4, Francis Avila wrote: >>>> >>>> Futures automatically capture exceptions raised in their bodies and >>>> reraise them when the future is derefed. Promises also throw exceptions >>>> when derefed. >>>> >>>> Unlike promises, futures are created with the code that delivers their >>>> value, so calling fail and deliver explicitly on a future makes no sense. >>>> >>>> Think of futures as a thin wrapper around a promise which spawns a >>>> thread, runs the code, and to the wrapped promise either delivers the >>>> result of the code or calls (fail private-promise raised-exception) for >>>> you. >>>> >>>> On Friday, August 7, 2015 at 2:14:30 PM UTC-5, William la Forge wrote: >>>>> >>>>> A future fails when it throws an exception. How to do that with a >>>>> future? >>>>> >>>>> It looks like (fail future exception) does not do the trick: >>>>> http://dev.clojure.org/display/design/Promises >>>>> >>>>> -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: Manifold streams/deferreds raising errors downstream of a sink
Hi Andy, I would provide a function that wraps put!. It would still return a deferred, but not the result of put!. It would create a deferred, representing the result of the computation and pass it down the stream together with the input. Consumers would set its value once the computation is done. I am actually using this technique in a couple of projects and very happy with it. On Mon, Aug 10, 2015 at 7:13 AM, Andy Chambers wrote: > Hey All, > > I'm trying to build a library that exposes manifold streams for data > producing applications. The intention > would be for these apps to s/put! to a sink stream returned by the > producer function. However, I need to > take the value that is put in and pipe it into some other function before > I know whether there is an error > and if there is an error, I'd like to propagate it back to the caller. > > I understand that the value returned by put! is a deferred, and how to set > the error state of a deferred but I > don't understand how I can arrange for the deferred to be manipulated > downstream of where it has been > taken off the stream. > > (defn producer [] > (let [in (s/stream)] > > (s/consume (fn [msg] > (d/future >(prn "oops, going to error now") >(throw (Exception. (str msg) in) > > in)) > > @(s/put! (producer) 42) > > As written, you get a success response even though an exception was > triggered by the function that consumes > the "in" stream. Is it possible to re-write this so that the exception > bubbles up to where the put! is deref'd? > > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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.
Hashing With Consistent Results
Hi,
I need a way to reduce a compound value, say {:foo "bar"}, into a number
(like 693d9a0698aff95c in hex). I don't necessarily need a very large hash
space, 7 hex digits is good enough for my purposes. But I need
this hash to be consistent between runs and JVM versions etc. So I guess
that rules out standard object hashes.
I would like to find a sufficiently fast way to do this. I can live with
MD5, but are there faster alternatives (but produce smaller hashes)? (
clj-digest <https://github.com/tebeka/clj-digest> provides a nice interface
to what Java provides but there are only usual suspects AFAICS
<http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#MessageDigest>
)
I will be dealing with unordered collections, but it seems hashing is
consistent when the input order is changed:
user=> (.hashCode {:foo "Bar" :baz 5})
2040536238
user=> (.hashCode {:baz 5 :foo "Bar"})
2040536238
(It even gave the same hash code in different runs.)
I will use these hashes to build index tables. My data, that contains these
things I hash is a set. I will store this as an ordered set and keep an
index pointing to where records from this hash to that hash lives. This is
all Clojure, but I can't keep all my data in memory. (So Clojure's
persistent data structures is out of the picture. life would've been much
simpler if I could.)
Thanks for reading. Any insight is appreciated.
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
--
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: Hashing With Consistent Results
Hi Christian,
hasch looks nice, I might end up just using it. I will be hashing smaller
collections
(maps where keys are keywords and values are atomic data like integers).
Collisions BTW are not such a big deal for my use case. I will have a
limited number
of fragments (buckets, index pages, etc.) anyway. 65536 of them perhaps.
The more
I think about the problem the more I realize I am implementing some sort of
hash map.
On Mon, Aug 10, 2015 at 3:49 PM, Christian Weilbach <
whitesp...@polyc0l0r.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> I am the author of https://github.com/whilo/hasch
>
> Would calling hasch.core/edn-hash satisfy your performance
> requirements? I tried hard to make the recursion of the protocol
> performant, but hashing a value is slower than the time needed to
> write the data to disk for big collections. You should pick a faster
> message-digest like you suggested, e.g. MD5:
>
> (defn ^MessageDigest md5-message-digest []
> (MessageDigest/getInstance "md5"))
>
> (edn-hash {:foo "Bar" :baz 5} md5-message-digest)
>
> You can use the criterium benchmarking snippets in platform.clj to do
> benchmarks. Object.hashCode() is a lot faster still and caches the
> result, I am not sure how much overhead the protocol dispatch causes.
>
> Note that if some collisions are ok for you, you might find a better
> tradeoff, since atm. commutative collections like maps and sets are
> hashed key-value wise and then XOR'd for safety. I am interested in
> your findings and decision, especially if you pick something else.
>
> Christian
>
> On 10.08.2015 09:00, Atamert Ölçgen wrote:
> > Hi,
> >
> > I need a way to reduce a compound value, say {:foo "bar"}, into a
> > number (like 693d9a0698aff95c in hex). I don't necessarily need a
> > very large hash space, 7 hex digits is good enough for my purposes.
> > But I need this hash to be consistent between runs and JVM versions
> > etc. So I guess that rules out standard object hashes.
> >
> > I would like to find a sufficiently fast way to do this. I can live
> > with MD5, but are there faster alternatives (but produce smaller
> > hashes)? ( clj-digest <https://github.com/tebeka/clj-digest>
> > provides a nice interface to what Java provides but there are only
> > usual suspects AFAICS
> > <
> http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#MessageDigest
> >
> >
> >
> )
> >
> > I will be dealing with unordered collections, but it seems hashing
> > is consistent when the input order is changed:
> >
> > user=> (.hashCode {:foo "Bar" :baz 5}) 2040536238 user=> (.hashCode
> > {:baz 5 :foo "Bar"}) 2040536238
> >
> >
> > (It even gave the same hash code in different runs.)
> >
> > I will use these hashes to build index tables. My data, that
> > contains these things I hash is a set. I will store this as an
> > ordered set and keep an index pointing to where records from this
> > hash to that hash lives. This is all Clojure, but I can't keep all
> > my data in memory. (So Clojure's persistent data structures is out
> > of the picture. life would've been much simpler if I could.)
> >
> > Thanks for reading. Any insight is appreciated.
> >
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJVyJ3vAAoJEKel+aujRZMkbhMIAJ61DGUWM9JoN/JcIxvh2Jph
> VohlWbr1yw69D+x4guGOk5AXUh7HMAkmlbuc+YRRnYqGhZtc3r/6C/d/aa5faBAh
> NdIeDa8yNHTAuYERDktfviy+q5a/blJRdvIIe7ntyjpDZyd2gD1AwUGYOKctXipS
> wMPan7v7yPfPlFfnl+VVXfP8yx/LWyZbwfu0Ugv2B2NhvqPMu8joyondOz7GPcLd
> P7EgpIrvfQAElA4c4+UB0BEeJkn+fnpYF3QLJIy5oQny5QwbVtxgVuUNES8EolYl
> HkpFY1ECV/M65fvP6wrcYPihuphSYQoPkfY4ZQfzWCq9mo+3Aj1Jq2u7QfG9HxM=
> =1UE6
> -END PGP SIGNATURE-
>
> --
> 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.
>
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
ww
Re: Unable to write GPL software with clojure?
On Wed, Aug 19, 2015 at 1:05 AM, Sean Corfield wrote: > On 8/18/15, 2:24 PM, "Kyle Sexton" k...@mocker.org> wrote: > > > >Can anyone weigh in on whether it is possible to write GPL code with > clojure? Seen some recent[1] tweets saying that the EPL on clojure core > prevents writing GPL code with clojure. > > You cannot write an application that is GPL and released as a standalone > program with EPL libraries embedded: > > https://eclipse.org/legal/eplfaq.php#GPLCOMPATIBLE > > "Based upon the position <http://www.fsf.org/licensing/licenses/> of the > Free Software Foundation, you may not combine EPL and GPL code in any > scenario where linking exists between code made available under those > licenses. The above applies to both GPL version 2 and GPL version 3." > > https://www.fsf.org/blogs/licensing/using-the-gpl-for-eclipse-plug-ins > > "However, developers who want to release GPL-covered plug-ins for Eclipse > can address this issue by providing an additional permission with their > license <http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs> > that grants users permission to combine their work with Eclipse in this > way." > > In other words, while you can’t write standalone GPL software using EPL > libraries, you could provide just your (Clojure) software under a modified > GPL that would allow end users to then combine it with the (EPL) libraries > it needs to make a complete piece of software — but that wouldn’t be very > convenient for your users. > I have added this extra clause to clecs' LICENSE <https://github.com/muhuk/clecs/blob/master/LICENSE>: If you modify this Program, or any covered work, by linking or combining it with clojure (or a modified version of that library), containing parts covered by the terms of EPL, the licensors of this Program grant you additional permission to convey the resulting work. Corresponding source for a non-source form of such a combination shall include the source code for the parts of clojure used as well as that of the covered work. To my understanding a game can be written with clecs & Clojure provided that it's distributed with GPL. Any other non-GPL clojure library cannot be included in the distribution though, as far as I can understand. It would be cool it would automatically work. > > This is part of why some people consider GPL to be a "viral" license and > why many companies will not use GPL software: it "taints" everything it > touches and requires "the whole thing" to be GPL. Proponents of GPL will > argue a different position (so, be careful, this is almost a religious > issue on both sides). > > Sean Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > > > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: Unable to write GPL software with clojure?
Hi Sean, On Thu, Aug 20, 2015 at 8:20 PM, Sean Corfield wrote: > Atamert Ölçgen said on August 20, 2015 at 8:51 AM: > > If you modify this Program, or any covered work, by linking or > combining it with clojure (or a modified version of that > library), containing parts covered by the terms of EPL, the licensors > of this Program grant you additional permission to convey the resulting > work. > > > Would you expect that to be read as just the Clojure JAR (which contains > the Clojure compiler itself as well as a number of "standard" namespaces), > or would you expect that to include the Contrib JAR libraries as well? Or, > further, any other Clojure libraries released under the EPL? > If you are saying what "clojure" there means is unclear, I agree with that. And I would like to work towards fixing it. I think, at the time I created this, my intent was just Clojure distribution (sans contrib) since clecs only depends on that. But now I realize a game made with clecs can depend on other libraries as well and this clause perhaps also need to cover them. > > I think the is the core issue of the confusion: what is "Clojure" for the > purpose of any such license exclusions? > > Corresponding source for a non-source form of such a combination > shall include the source code for the parts of clojure used as well as > that of the covered work. > > > Are you saying that the whole of the EPL-licensed Clojure source, for a > specific version of Clojure used in the combined work, should be physically > included into the source overall for the combined work? I.e., that any game > built with clecs and distributed in source form would have to include the > GitHub repos of any/all Clojure libraries used? *[I believe it’s > reasonable to say this — I just wanted to check this was your intent]* > If it included clecs' source and the game's source it would be enough for me. I wouldn't want to dictate terms for other people's code. If another library the game depends on is also GPL, it's source should be included as well. But that's because of the other author's licensing. If that library has a license that doesn't require source distribution, who am I to ask for that. Not directly related to licensing but my main intent is to get people to write games and share them. Not necessarily as a commercial activity but game development for game development's sake. Commercial side is IMO already covered well. > > 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) > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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] io.aviso/rook 0.1.36
Hi Howard, In the example application it seems the routing information is encoded in the beginning of the docstring and not the actual metadata. Is there an option to put this info in the metadata of the var? On Mon, Aug 24, 2015 at 6:31 PM, Howard Lewis Ship wrote: > Rook is a set of middleware and handlers to enable metadata-based routing > for Ring web applications. > > The intention is to expose a Clojure namespace as a web service resource; > there’s a default mapping of HTTP verbs and paths to function names; these > can be extended or overridden by metadata on the functions in the namespace. > > The end result is that a compliant web service resource can be created in > very little code. > > Rook also supports Swagger 2.0: a detailed JSON description of your web > service is generated directly from the functions and metadata. > > Recent changes: > > * Described more of the APIs using Prismatic Schema > * Added ability to reuse the argument resolution logic outside of endpoint > functions > * Many improvements to the Swagger 2.0 description support > > https://github.com/AvisoNovate/rook > > -- > Howard M. Lewis Ship > > Looking for Clojure engagements: coding, architecture, mentoring & more! > > Creator of Apache Tapestry > > (971) 678-5210 > http://howardlewisship.com > @hlship > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: I am looking for xml parsing lib
Just a general note: if a library is not updated for X months/years, it doesn't necessarily mean it's obsolete/totally useless. I sometimes do this myself too, but I've recently found a library that hasn't been updated for a looong time and it works perfectly fine. On Tue, Aug 25, 2015 at 11:31 AM, Josh Kamau wrote: > Thanks all. clojure.xml/parse worked for me. > > On Tue, Aug 25, 2015 at 1:52 AM, Jordan Schatz > wrote: > >> Which is the recommended xml parsing lib for clojure? >> >> >> I think you are after clojure.xml/parse >> http://conj.io/store/v1/org.clojure/clojure/1.7.0/clj/clojure.xml/parse/ >> and friends: >> >> http://conj.io/store/v1/org.clojure/clojure/1.7.0/clj/clojure.core/xml-seq/ >> http://conj.io/store/v1/org.clojure/clojure/1.7.0/clj/clojure.zip/xml-zip/ >> >> - Jordan >> >> On Mon, Aug 24, 2015 at 12:50 PM, blake watson >> wrote: >> >>> I believe that's it, though. >>> >>> On Mon, Aug 24, 2015 at 10:48 AM, Josh Kamau >>> wrote: >>> >>>> Hello; >>>> >>>> Which is the recommended xml parsing lib for clojure? >>>> >>>> clojure.data.xml was last updated 10months ago and is still on version >>>> 0.0.8 >>>> >>>> Thanks >>>> Josh >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Clojure" group. >>>> To post to this group, send email to clojure@googlegroups.com >>>> Note that posts from new members are moderated - please be patient with >>>> your first post. >>>> To unsubscribe from this group, send email to >>>> clojure+unsubscr...@googlegroups.com >>>> For more options, visit this group at >>>> http://groups.google.com/group/clojure?hl=en >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "Clojure" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to clojure+unsubscr...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clojure@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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.
Manifold questions: Creating sinks/sources
Hi, AFAIK the only way to create (just) a source (or sink) is: (def my-source (s/source-only (s/stream ...))) This results in creating a stream and then wrapping it with a SourceProxy. We don't keep a reference to the stream and the SourceProxy doesn't allow taking. But if I'm not missing something since SourceProxy keeps a reference of the original stream, there is a sink nobody is using there. If I create a sink separately and connect my-source to it, now my-source would be connected to two sinks. My questions are: 1. Is there another method for creating only sinks or sources? 2. Should the extra/unused source/sink I mentioned above cause concern? PS: I'm not talking about a scenario where we're creating thousands streams and connecting them all like there's no tomorrow. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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] io.aviso/rook 0.1.36
Got it, thanks. I think you still need to prepend ^'s to the metadata. On Thu, Aug 27, 2015 at 8:40 PM, Howard Lewis Ship wrote: > That's misleading. In the case of convention function names, (index, > show, create), there's default :route metadata that is used automatically > ... the docstrings are merely supplying a reminder. > > This is described in the "Getting Started" page: > https://portal.aviso.io/#/document/open-source/rook/Current/getting-started.html > > If you look at the increment endpoint function, which is not a convention > name, it has explicit :route metadata. > > I'll update the example to make this much more clear. > > > On Tue, Aug 25, 2015 at 7:43 AM, Atamert Ölçgen wrote: > >> Hi Howard, >> >> In the example application it seems the routing information is encoded in >> the beginning of the docstring and not the actual metadata. Is there an >> option to put this info in the metadata of the var? >> >> On Mon, Aug 24, 2015 at 6:31 PM, Howard Lewis Ship >> wrote: >> >>> Rook is a set of middleware and handlers to enable metadata-based >>> routing for Ring web applications. >>> >>> The intention is to expose a Clojure namespace as a web service >>> resource; there’s a default mapping of HTTP verbs and paths to function >>> names; these can be extended or overridden by metadata on the functions in >>> the namespace. >>> >>> The end result is that a compliant web service resource can be created >>> in very little code. >>> >>> Rook also supports Swagger 2.0: a detailed JSON description of your web >>> service is generated directly from the functions and metadata. >>> >>> Recent changes: >>> >>> * Described more of the APIs using Prismatic Schema >>> * Added ability to reuse the argument resolution logic outside of >>> endpoint functions >>> * Many improvements to the Swagger 2.0 description support >>> >>> https://github.com/AvisoNovate/rook >>> >>> -- >>> Howard M. Lewis Ship >>> >>> Looking for Clojure engagements: coding, architecture, mentoring & more! >>> >>> Creator of Apache Tapestry >>> >>> (971) 678-5210 >>> http://howardlewisship.com >>> @hlship >>> >>> -- >>> 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. >>> >> >> >> >> -- >> Kind Regards, >> Atamert Ölçgen >> >> ◻◼◻ >> ◻◻◼ >> ◼◼◼ >> >> www.muhuk.com >> >> -- >> 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. >> > > > > -- > Howard M. Lewis Ship > > Starting with WalMart Labs on Sep 28th! > > Creator of Apache Tapestry > > (971) 678-5210 > http://howardlewisship.com > @hlship > > -- > 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 &g
Re: Manifold questions: Creating sinks/sources
On Thu, Aug 27, 2015 at 10:51 PM, Zach Tellman wrote: > Hi Atamert, > > Hi Zach, > For future reference, posting these questions to > https://groups.google.com/forum/#!forum/aleph-lib will ensure I'll see > them sooner. > I've subscribed. Thanks. > > The `source-only` method is just a way to make sure that the chance for > confusion is minimized, it doesn't prevent the underlying object from being > used normally. As for your scenario, I'm not sure I completely > understand. In a standard stream, the flow of data is: > > [ sink -> source ] > > So if you `put!` something into the sink, you can `take!` it from the > source. If you use `source-only` and connect that to some other sink, then > the flow of data will be > > [ sink -> source ] -> sink > > So the source is only connected to one sink, not two. Maybe I'm > misunderstanding you, though. > I have initially written it right. I was looking through the docs and the source at the same time and I got confused. Then I replaced source with sink and vice versa. So if you are misunderstanding, you are understanding. :) Let me try again. If we have: (def my-sink (s/sink-only (s/stream ...))) (def my-source (s/source-only (s/stream ...))) (s/connect my-source my-sink) ;; BTW this got me confused, I thought flow was like my-source -> my-sink After I have written the comment above, and playing with this code in the REPL, I have realized the flow IS from source to sink. I think I am un-confused now, and it all makes sense. I have a producer side and a consumer side. Instead of repeating a function call, I want to connect these two components using a stream. I thought I'd need half a stream here and half a stream there. But now I realize I need two whole streams, connect them, put! on one side, take! on the other. I hope it makes sense. Sorry for the noise. > > Zach > > On Thursday, August 27, 2015 at 4:13:35 AM UTC-7, Atamert Ölçgen wrote: >> >> Hi, >> >> AFAIK the only way to create (just) a source (or sink) is: >> >> (def my-source (s/source-only (s/stream ...))) >> >> This results in creating a stream and then wrapping it with a >> SourceProxy. We don't keep a reference to the stream and >> the SourceProxy doesn't allow taking. >> >> But if I'm not missing something since SourceProxy keeps a reference of >> the original stream, there is a sink nobody is using there. >> >> If I create a sink separately and connect my-source to it, now >> my-source would be connected to two sinks. >> >> My questions are: >> >> 1. Is there another method for creating only sinks or sources? >> 2. Should the extra/unused source/sink I mentioned above cause concern? >> >> PS: I'm not talking about a scenario where we're creating thousands >> streams and connecting them all like there's no tomorrow. >> >> >> -- >> Kind Regards, >> Atamert Ölçgen >> >> ◻◼◻ >> ◻◻◼ >> ◼◼◼ >> >> www.muhuk.com >> > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: Generalizing -> and ->> forms
Hi, threading doesn't need to be a macro. In fact it would be easier to test if it's just a function. Also, you know about as->, don't you? On Fri, Aug 28, 2015 at 2:37 PM, Akhil Wali wrote: > I've been trying to refactor the -> and ->> forms to use a common macro > form. > Ended up with this. > > (defmacro threading [a b x forms] > (loop [x x > forms forms] > (if forms > (let [form (first forms) > f (first form) > r (rest form) > threaded (if (seq? form) >(with-meta > `(~f ~`(~a ~`(list ~x ~@r)) > ~`(~b ~`(list ~x ~@r))) > (meta form)) >(list form x))] > (recur threaded (next forms))) > x))) > > (defmacro -> [x & forms] > `(threading ~'first ~'second > ~x ~forms)) > > (defmacro ->> [x & forms] > `(threading ~'second ~'first > ~x ~forms)) > > > This does work, but it's a bit of whammy. > Anyone with suggestions for improvement? > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: Live rendering of AsciiDoc files in Chrome browser
I am using AsciiLight plugin for LightTable and very happy with it: https://github.com/rundis/AsciiLight On Wed, Sep 2, 2015 at 10:06 PM, Alan Thompson wrote: > Hey, > > As you all know, the README files on Github, etc can be formatted using > the either AsciiDoc (my favorite) or the older MarkDown format. However, > it is a pain to edit these files in just a plain text editor without a good > way of seeing the final, rendered format until you commit and push your > latest changes up to GH. > > If you haven't seen it yet, there is a Chrome extension named > "Asciidoctor.js" that will render both AsciiDoc *and* MarkDown files into > HTML right in your browser. It even features automatic reloading of > changes (~2 sec delay) whenever you make a change to the source file. > > If you are not already using this or a similar tool, you should give it a > try. Enjoy! > > Alan > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: midje only 1 test
Hi Brian,
On Sun, Sep 6, 2015 at 1:19 AM, Brian Marick wrote:
> I *strongly* recommend doing all your testing in a repl buffer. That
> given, there are two ways to solve your problem. The first, which I prefer,
> is to start by testing everything:
>
> (use 'midje.repl)
> (autotest)
>
Other than having a REPL, is this different than doing `lein midje
:autotest`?
>
> Then, when you change any text and save the namespace it's in, all tests
> that depend on that namespace will be rerun, including the one you're
> specifically working on.
>
> The other alternative is to rerun your specific test with something like:
>
> (check-facts #"fact description")
>
> ... or, once you've run a specific fact:
>
> (recheck-fact)
>
>
>
> r/ Wobben wrote:
>
>> hello,
>>
>> Suppose I have this test
>>
>> (facts "do-a-thing" {:exercise 1:points 1} (do-a-thing 3) =>
>> 46656.0 (do-a-thing 1) => 4.0 (do-a-thing 0) => 1.0)
>>
>>
>> Is there a way I can only run this test
>> I tried lein midje :filter exercise 1
>> but that one fails.
>>
>> Roelof
>>
>> --
>> 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
>> <mailto: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.
>
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
--
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] Shrubbery 0.3.0, a stubbing, spying, and mocking library for Clojure protocols
This is awesome! I might have more useful feedback (and PRs) in the future, because I can see myself using this extensively. It would be great if multiple return values for multiple calls were supported. First use case it something like an iteration, calling some protocol method repeatedly (possibly with different inputs). Another use case is just calling it with different inputs, expecting different outputs. Something like (add (square x) (square y)). Thanks for sharing Brian. On Tue, Oct 6, 2015 at 5:29 AM, Brian Guthrie wrote: > Great to hear! Let me know if there are any questions I can answer. > Feedback gratefully accepted. > > Cheers, > > Brian > > > On Mon, Oct 5, 2015 at 11:56 AM, James Reeves > wrote: > >> Very nice. I was looking for something like this. >> >> - James >> >> On 5 October 2015 at 15:14, Brian Guthrie wrote: >> >>> Clojure protocols are a great way to encapsulate operations with side >>> effects, but suffer from a lack of general test tooling. Shrubbery provides >>> a small set of basic building blocks for working with them: >>> >>> * stub, which accepts a variable list of protocols and a optional >>> hashmap of simple value implementations and returns an object that reifies >>> all given protocols; >>> * spy, which accepts an object with at least one protocol >>> implementation and returns a new implementation that tracks the number of >>> times each of its members were called; >>> * mock, which wraps a stub in a spy, allowing callers to supply basic >>> function implementations and assert against those calls; and >>> * calls/received?, which in conjunction with the Matcher protocol >>> provide a way to query spies and assert against their state. >>> >>> Shrubbery is test-framework-agnostic, avoids altering runtime state to >>> the degree possible, and uses no macros. It should work nicely with >>> refactorings like rename-function. >>> >>> https://github.com/bguthrie/shrubbery >>> >>> [com.gearswithingears/shrubbery "0.3.0"] >>> >>> >>> New in this release: >>> >>> – Support for multiple protocols in both spies and stubs. >>> – Spies attempt to automatically derive the given implementation's >>> protocols, and tracks calls to all of them. (This behavior can be >>> overridden.) >>> – Replaced all macros with plain functions. (Unfortunately, this means >>> leaning on eval in some cases.) >>> >>> Cheers, >>> >>> Brian >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clojure@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.
Re: Timbre corrupting EDN via prn-str
Hi Ken, Have you tried with-out-str? On Wed, Oct 7, 2015 at 11:18 AM, Ken Restivo wrote: > I was trying to save a data structure using prn-str. > > However, I'm also using Timbre for logging. > > My nice data structure is getting corrupted by INFO and DEBUG and other > log messages from Timbre. > > Is there any way to turn a Clojure data structure into EDN without mucking > around with things like pr-str that use *out*, which apparently is used for > logging, among other things? > > -ken > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: Timbre corrupting EDN via prn-str
So you actually want to print your data. I don't think it can be helped then, two threads writing to the same buffer. I would have one of them use a different buffer, write the logs to a file and tail it for instance. On Wed, Oct 7, 2015 at 11:36 AM, Ken Restivo wrote: > Yep. It doesn't help. > > I also tried (.flush *out*) before... no dice. > > -ken > -- > - > On Wed, Oct 07, 2015 at 11:31:12AM +0300, Atamert Ölçgen wrote: > > Hi Ken, > > > > Have you tried with-out-str? > > > > On Wed, Oct 7, 2015 at 11:18 AM, Ken Restivo wrote: > > > > > I was trying to save a data structure using prn-str. > > > > > > However, I'm also using Timbre for logging. > > > > > > My nice data structure is getting corrupted by INFO and DEBUG and other > > > log messages from Timbre. > > > > > > Is there any way to turn a Clojure data structure into EDN without > mucking > > > around with things like pr-str that use *out*, which apparently is > used for > > > logging, among other things? > > > > > > -ken > > > > > > -- > > > 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. > > > > > > > > > > > -- > > Kind Regards, > > Atamert Ölçgen > > > > ◻◼◻ > > ◻◻◼ > > ◼◼◼ > > > > www.muhuk.com > > > > -- > > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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] ring-transit-middleware 0.1.1
Hi, I've just released ring-transit-middleware 0.1.1 to clojars. - It has sane defaults, most of the time you just need to wrap with ring.middleware.transit/wrap-transit - Allows customisation (see API docs) - Is Aleph-aware (handles deferred responses) https://github.com/muhuk/ring-transit-middleware Your feedback & contributions are welcome. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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] ring-transit-middleware 0.1.1
Hi Sven, What is the difference to ring-transit ring-transit-middleware doesn't silence exceptions. Also the three points I listed in my original message. But _essentially_ they both do the same thing. On Sat, Oct 31, 2015 at 11:41 PM, Sven Richter wrote: > Hi Atamert, > > Thanks for your work. I am curious. What is the difference to ring-transit > (https://github.com/jalehman/ring-transit). Both libraries seem to have > the same goal. > > Best Regards, > Sven > > > Am Samstag, 31. Oktober 2015 14:30:21 UTC+1 schrieb Atamert Ölçgen: >> >> Hi, >> >> I've just released ring-transit-middleware 0.1.1 to clojars. >> >> - It has sane defaults, most of the time you just need to wrap with >> ring.middleware.transit/wrap-transit >> - Allows customisation (see API docs) >> - Is Aleph-aware (handles deferred responses) >> >> https://github.com/muhuk/ring-transit-middleware >> >> Your feedback & contributions are welcome. >> >> >> -- >> Kind Regards, >> Atamert Ölçgen >> >> ◻◼◻ >> ◻◻◼ >> ◼◼◼ >> >> www.muhuk.com >> > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: Help with decisions in threading macros
Perhaps you can replace (reduce ...) with (every? true?), which works with empty collections. On Tue, Nov 3, 2015 at 6:05 PM, Timur wrote: > Hi all, > > Often I need to make decisions in simple threading macros, for instance > consider the following code > > (->> m >:vector >(filterv #(= (:id %) (:id m))) >(reduce #(and %1 %2))) > > In this case, if the result of filter is empty reduce throws an exception > as it expects some values. Therefore, I want to include a decision between > filter and reduce for instance if empty then add false into the resulting > vector. What would be the best way to achieve this? I could add a function > that checks if empty then add sth into the vector but wanted to ask your > opinions if there is a better way to do this. > > Regards, > > Timur > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: Style, Efficiency, and updating nested structure
r assoc of new vector on project_roles, so they aren't
> included in allocations
> ;; below since both routines have to do it.
> ;;
> ;; Note that x-element map allocates storage for map and map-entries or
> clojure equivalent.
> ;; (and more expensive than an x-element vector, of course).
> ;;
> ;; n == length of input project list.
> ;; m == average length of input project list role vectors.
> ;;
> ;; Object Allocations
> ;; Function call:
> ;; update-roles:
> ;; 1 atom
> ;; 1 O(n) vector for mapv
> ;; update-or-insert-project-role:
> ;; 1 3-entry map + 1 single-element vector for prj-role argument
> input.
> ;; 1 n-element map for group-by
> ;; n vectors for group-by map values
> ;; 1 n-element map for update-in
> ;; 1 list/sequence for mapcat (+ n concat intermediaries?)
> ;; 1 vector for into
> ;;
> ;; If we discard the second 'into' and first 'mapv' allocations the
> update-or-insert-project-role routine allocates
> ;; 3 additional maps (two of which are O(n)), n additional vectors, and 1
> additional list/sequence.
> ;;
> ;; Searches/traversals/copies
> ;; update-roles:
> ;; O(n) - mapv
> ;; update-or-insert-project-role:
> ;; O(n) - group-by
> ;; O(n) - update-in
> ;; O(n) - mapcat
> ;; O(n) - into
> ;;
> ;; Here's what update-or-insert-project-role allocates (by way of
> assistance in assessing the above)
> ;;{1 [{:project_id 1, :project_name "One", :project_roles [:own]}], 3
> [{:project_id 3, :project_name "Three", :project_roles [:edit]}]}
> -- group-by
> ;;{1 [{:project_id 1, :project_name "One", :project_roles [:own :edit]}],
> 3 [{:project_id 3, :project_name "Three", :project_roles [:edit]}]}
> -- update-in
> ;;({:project_id 1, :project_name "One", :project_roles [:own :edit]}
> {:project_id 3, :project_name "Three", :project_roles [:edit]})
>-- mapcat
> ;;[{:project_id 1, :project_name "One", :project_roles [:own :edit]}
> {:project_id 3, :project_name "Three", :project_roles [:edit]}]
>-- into
>
> Thanks for your thoughts and suggestions.
>
> --
> 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.
>
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
--
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 call for an idiomatic rendering of Clojure EDN in info/error messages
Hi Colin, Why not just "2"? On Fri, Nov 13, 2015 at 1:55 PM, Colin Yates wrote: > Hi all, > > Can we, the community agree a consistent way of rendering Clojure EDN when > we report it in info or error. For example, given the EDN "2" (i.e. a > string containing a single character 2) I have seen various libraries > render it as: > > - 2 > - "2" > - ["2"] > - [2] > - (2) > - '"2"' > > I would like to propose that we standardise around "_" as the boundary > character as that isn't likely to be used in (except for some markup I > guess but that is pretty unlikely), so a test framework might render as > such: > > - expected _2_ but was _"2"_ > > Please? :-) > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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 call for an idiomatic rendering of Clojure EDN in info/error messages
+1 for no special markup, +1 for backquotes, -1 for underscore, -1 for pipe
char.
On Fri, Nov 13, 2015 at 7:18 PM, Colin Yates wrote:
> This. Confusing for the rubyists but hey :-).
>
> On 13 Nov 2015, at 17:13, Yuri Govorushchenko
> wrote:
>
> I recall Google uses vertical bars in ObjC comments for similar purposes,
> as stated in their style guide:
>
> Use vertical bars to quote variable names and symbols in comments rather
> than quotes or naming the symbol inline.
>
> This helps eliminate ambiguity, especially when the symbol is a common
> word that might make the sentence read like it was poorly constructed. E.g.
> for a symbol "count":
>
> // Sometimes we need |count| to be less than zero.
>
> or when quoting something which already contains quotes
>
> // Remember to call |StringWithoutSpaces("foo bar baz")|
>
>
> --
> https://google.github.io/styleguide/objcguide.xml?showone=Implementation_Comments#Implementation_Comments
>
> пятница, 13 ноября 2015 г., 13:55:40 UTC+2 пользователь Colin Yates
> написал:
>>
>> Hi all,
>>
>> Can we, the community agree a consistent way of rendering Clojure EDN
>> when we report it in info or error. For example, given the EDN "2" (i.e. a
>> string containing a single character 2) I have seen various libraries
>> render it as:
>>
>> - 2
>> - "2"
>> - ["2"]
>> - [2]
>> - (2)
>> - '"2"'
>>
>> I would like to propose that we standardise around "_" as the boundary
>> character as that isn't likely to be used in (except for some markup I
>> guess but that is pretty unlikely), so a test framework might render as
>> such:
>>
>> - expected _2_ but was _"2"_
>>
>> Please? :-)
>>
>
> --
> 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.
>
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
--
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: Ultralight Components
>> 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/7Q7QvlSUGL4/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. >>>> >>> >>> -- >>> 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/7Q7QvlSUGL4/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. >> > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: Ultralight Components
Hi Colin, > in this industry there are hardly any unambiguous and objective statements Either you contradict yourself or the following is ambiguous and/or subjective: > pragmatism throws it all out of the window - > One man’s complexity is another man’s simplicity and so on. Can you please give an example? - Are you suggesting we don't discuss merits and shortcomings of different approaches to design software? On Tue, Nov 24, 2015 at 10:11 AM, Colin Yates wrote: > I think this discussion has run into the age-old problem of ‘subjective > interpretation’, namely, multiple people all agreeing with a principle > (i.e. complexity sucks) but then having _different_ interpretations of > where that principle is challenged/upheld. Unfortunately in this industry > there are hardly any unambiguous and objective statements because most of > what we do is more artistic than engineering (zips up the flame suit now). > > And, as ever, pragmatism throws it all out of the window :-) > > One man’s complexity is another man’s simplicity and so on. > > > > On 24 Nov 2015, at 06:34, Atamert Ölçgen wrote: > > Hi William, > > How is this different than Yo-yo? ( > https://groups.google.com/forum/#!topic/clojure/PvCc5sSeSRY) > > > Justifying things is generally impossible. > > Actually, no. It is possible, at least when you are dealing with > reasonable people. And when you make claims like "lightweight" or > "ultralight", people will naturally ask "oh, interesting, how so?" > > - > > Some functional programming folks are allergic to exceptions. They go out > of their ways to prevent any and all exceptions and they end up > unnecessarily complicating their types for little or no gain. > > It seems to me, you are trying to avoid using protocols like it's a plague. > > > I am tired of doing ongoing refactorings interrupted periodically by > complete rewrites. Class hierarchies are the worst... > > When your ultralight function based components get out of hand, you will > have a worse time refactoring. With component you only have two functions, > your lightweight design will end up having (* n 2) functions. > > Also, looking at a component's code (it's defrecord form I mean) I can see > what other components it depends on. Your design would bury them inside > functions making it harder to read. > > > On Tue, Nov 24, 2015 at 6:57 AM, James Reeves > wrote: > >> Have you watched Simple Made Easy >> <http://www.infoq.com/presentations/Simple-Made-Easy>? >> >> I mention it because you remark about being tired of refactoring. It's my >> opinion that's a symptom of complexity, in the Hickey definition of the >> term. >> >> - James >> >> On 24 November 2015 at 03:31, William la Forge >> wrote: >> >>> James, >>> >>> Being fun is important but not a justification. We should strive to keep >>> things fun, but there are plenty of thing worth doing and our resources are >>> always limited. And if it is not fun, you are not going to do your best >>> work. >>> >>> Justifying things is generally impossible. If vanilla clojure meets your >>> needs, then vanilla clojure it is. If macros solve the problems you have >>> been dealt in the past, then three cheers for macros. If unifying client >>> and server addresses your needs, then Om Next may well be a major blessing >>> for you. >>> >>> For me, the winner is avoiding static structures. I am tired of doing >>> ongoing refactorings interrupted periodically by complete rewrites. Class >>> hierarchies are the worst--being the largest, they are the least stable. I >>> like small files that I can put to bed as finished. And self-defining >>> aggregation. Because these meet my very real needs. I constantly >>> reconceptualize what I am working on while bringing projects to completion. >>> So having a programming style which keeps code relevant in the face of such >>> an onslaught is very helpful and also a genuine delight. >>> >>> --b >>> >>> On Mon, Nov 23, 2015 at 10:08 PM, James Reeves >>> wrote: >>> >>>> I feel you might be barking up the wrong tree with this approach, as it >>>> seems to complicate things without providing any compelling advantages. >>>> >>>> That said, if it's fun then by all means continue to experiment. Maybe >>>> I'm wrong :) >>>> >>>> - James >>>> >>>> On 24 November 2015 at 02:45, William la Forge
Re: Ultralight Components
y we don’t, we only discuss the merits. > > The reason I posted initially is because I have wasted so many months > arguing details with other developers and having a black and white view of > things and it almost always turned out that we were agreeing with the > general principle but the application of that principle meant different > things in each of our different contexts. We were ‘violently agreeing’ :-). > > TLDR(2): there is no ‘better’ only ‘better in this context' > > I hope that clarified my view point. > > > > > On Tue, Nov 24, 2015 at 10:11 AM, Colin Yates > wrote: > >> I think this discussion has run into the age-old problem of ‘subjective >> interpretation’, namely, multiple people all agreeing with a principle >> (i.e. complexity sucks) but then having _different_ interpretations of >> where that principle is challenged/upheld. Unfortunately in this industry >> there are hardly any unambiguous and objective statements because most of >> what we do is more artistic than engineering (zips up the flame suit now). >> >> And, as ever, pragmatism throws it all out of the window :-) >> >> One man’s complexity is another man’s simplicity and so on. >> >> >> >> On 24 Nov 2015, at 06:34, Atamert Ölçgen wrote: >> >> Hi William, >> >> How is this different than Yo-yo? ( >> https://groups.google.com/forum/#!topic/clojure/PvCc5sSeSRY) >> >> > Justifying things is generally impossible. >> >> Actually, no. It is possible, at least when you are dealing with >> reasonable people. And when you make claims like "lightweight" or >> "ultralight", people will naturally ask "oh, interesting, how so?" >> >> - >> >> Some functional programming folks are allergic to exceptions. They go out >> of their ways to prevent any and all exceptions and they end up >> unnecessarily complicating their types for little or no gain. >> >> It seems to me, you are trying to avoid using protocols like it's a >> plague. >> >> > I am tired of doing ongoing refactorings interrupted periodically by >> complete rewrites. Class hierarchies are the worst... >> >> When your ultralight function based components get out of hand, you will >> have a worse time refactoring. With component you only have two functions, >> your lightweight design will end up having (* n 2) functions. >> >> Also, looking at a component's code (it's defrecord form I mean) I can >> see what other components it depends on. Your design would bury them inside >> functions making it harder to read. >> >> >> On Tue, Nov 24, 2015 at 6:57 AM, James Reeves >> wrote: >> >>> Have you watched Simple Made Easy >>> <http://www.infoq.com/presentations/Simple-Made-Easy>? >>> >>> I mention it because you remark about being tired of refactoring. It's >>> my opinion that's a symptom of complexity, in the Hickey definition of the >>> term. >>> >>> - James >>> >>> On 24 November 2015 at 03:31, William la Forge >>> wrote: >>> >>>> James, >>>> >>>> Being fun is important but not a justification. We should strive to >>>> keep things fun, but there are plenty of thing worth doing and our >>>> resources are always limited. And if it is not fun, you are not going to do >>>> your best work. >>>> >>>> Justifying things is generally impossible. If vanilla clojure meets >>>> your needs, then vanilla clojure it is. If macros solve the problems you >>>> have been dealt in the past, then three cheers for macros. If unifying >>>> client and server addresses your needs, then Om Next may well be a major >>>> blessing for you. >>>> >>>> For me, the winner is avoiding static structures. I am tired of doing >>>> ongoing refactorings interrupted periodically by complete rewrites. Class >>>> hierarchies are the worst--being the largest, they are the least stable. I >>>> like small files that I can put to bed as finished. And self-defining >>>> aggregation. Because these meet my very real needs. I constantly >>>> reconceptualize what I am working on while bringing projects to completion. >>>> So having a programming style which keeps code relevant in the face of such >>>> an onslaught is very helpful and also a genuine delight. >>>> >>>> --b >>>> >>>> On Mon, Nov 23, 2015 at 10:08 PM, James
Re: Check if value is a ring handler
You can check for a valid response using ring.util.response/response? (obviously requires calling the function in question) On Wed, Jan 27, 2016 at 7:42 AM, JvJ wrote: > Is there a way to dynamically check whether or not a given function > qualifies as a ring handler? > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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] rete4frames, v. 5.2.4 - CLIPS-like expert system shell
Hi, It seems this library has really good documentation, but the link is at the very end of readme. I think it would be great if "I see you are not familiar with rule engines, here's a real quick summary of what rete4frames is" comes before "and here is the detailed docs" which comes before "look, we're not faster than this Java thing, but we beat it in a few benchmarks". On Thu, Feb 4, 2016 at 4:19 PM, ru wrote: > Hi, > > New version 5.2.4 of rete4frames CLIPS-like expert system shell is > published on https://github.com/rururu/rete4frames. > > News: > > 1. Refactored functions "dissoc-in" and "remove-fmem" for better > performance and reliability. > 2. New compound example of expert system: "Real" air traffic control > system - client-server ClojureScript-Clojure application based on > Flightradar24 web service (http://www.flightradar24.com/), Leaflet > JavaScript libraty (http://leafletjs.com/), httpkit, compojure, > core.async and others Clojure libraries. This example is in a separate > repository https://github.com/rururu/rete4flights. > > Enjoy! > > Sincerely, > Ru > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: Question about Clojure function naming
> > why Clojure chose to name functions operating on refs and atoms so > differently swap! is not an alter on atoms. And vice versa. reset! is not a ref-set on atoms. And vice versa. The analogous functions names would make remembering which is which easier. Are you having trouble remembering them? On Fri, Feb 19, 2016 at 7:04 AM, Tianxiang Xiong wrote: > I'm currently reading Practical Clojure > <http://www.apress.com/9781430272311> by VanderHart and Sierra, and am on > the section about state management. > > I'm curious why Clojure chose to name functions operating on refs and > atoms so differently. As I understand it, > > swap! -> atoms, alter -> refs > reset! -> atoms, ref-set -> refs > > Why "swap!" and "reset!", instead of "atom-alter" and "atom-set"? The > analogous functions names would make remembering which is which easier. > > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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.
Validation Benchmark
Hi All, I have been working a benchmark for (runtime) validation libraries. I think it is mature enough to share the results with the group. The repo is here: https://github.com/muhuk/validation-benchmark Raw benchmark output as EDN is here: https://gist.github.com/muhuk/93d7d9e46bf5191310aaa4557379d10e More human readable results are in my blog: http://blog.muhuk.com/2016/04/18/performance_comparison_of_annotate_herbert_schema.html If you are familiar with Annotate, Herbert or Schema, please take a quick look at their implementations: https://github.com/muhuk/validation-benchmark/tree/master/src/validation_benchmark/lib Also contributions of other validation libraries are most welcome! - As an aside: what is the group policy for attachments? Would it be ok if I attached images of benchmark results? -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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: Validation Benchmark
Hi Jason, Thank you for the PR. I've just merged it. For now I have added this to the blog post: Results below and the comments about Schema being slow is no longer true. See this pull request <https://github.com/muhuk/validation-benchmark/pull/6> for the results Jason got with quick mode benchmark. I am thinking about generating a stand alone page (GH pages) so that I don't have to update or create a new post everytime the results are updated. The README for Schema doesn't mention checker function, FYI. On Tue, Apr 19, 2016 at 7:30 AM, Jason Wolfe wrote: > Thanks for putting this together! > > For schema, I think using `s/validate` is not a fair comparison with the > other libraries -- as you mention, it throws an exception on error, and it > also has to parse the schema each time. > > I think `s/checker` is the correct construct to use here -- it returns an > error or nil for success (no exceptions), and only parses the schema once. > (This is what's used by `s/defn`, for example). > > Here's a pull request that implements this change: > > https://github.com/muhuk/validation-benchmark/pull/6 > > I posted the updated results in the PR comments as well, which are > qualitatively quite different from the ones currently reported in your blog > post (with this change, schema is fastest on all but one benchmark, often > by a factor of 3 or more). > > Please let me know if you have any questions. > > Thanks, > Jason > > > On Tuesday, April 19, 2016 at 2:47:33 AM UTC+7, Atamert Ölçgen wrote: >> >> Hi All, >> >> I have been working a benchmark for (runtime) validation libraries. I >> think it is mature enough to share the results with the group. >> >> The repo is here: https://github.com/muhuk/validation-benchmark >> >> Raw benchmark output as EDN is here: >> https://gist.github.com/muhuk/93d7d9e46bf5191310aaa4557379d10e >> >> More human readable results are in my blog: >> http://blog.muhuk.com/2016/04/18/performance_comparison_of_annotate_herbert_schema.html >> >> If you are familiar with Annotate, Herbert or Schema, please take a quick >> look at their implementations: >> https://github.com/muhuk/validation-benchmark/tree/master/src/validation_benchmark/lib >> >> Also contributions of other validation libraries are most welcome! >> >> - >> >> As an aside: what is the group policy for attachments? Would it be ok if >> I attached images of benchmark results? >> >> -- >> Kind Regards, >> Atamert Ölçgen >> >> ◻◼◻ >> ◻◻◼ >> ◼◼◼ >> >> www.muhuk.com >> > -- > 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. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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.spec
Isn't s redefined in this example:
user=> (require '[clojure.spec :as s])
(s/def ::even? (s/and integer? even?))
(s/def ::odd? (s/and integer? odd?))
(s/def ::a integer?)
(s/def ::b integer?)
(s/def ::c integer?)
(def s (s/cat :forty-two #{42}
:odds (s/+ ::odd?)
:m (s/keys :req-un [::a ::b ::c])
:oes (s/* (s/cat :o ::odd? :e ::even?))
:ex (s/alt :odd ::odd? :even ::even?)))
user=> (s/conform s [42 11 13 15 {:a 1 :b 2 :c 3} 1 2 3 42 43 44 11])
{:forty-two 42,
:odds [11 13 15],
:m {:a 1, :b 2, :c 3},
:oes [{:o 1, :e 2} {:o 3, :e 42} {:o 43, :e 44}],
:ex {:odd 11}}
in http://clojure.org/about/spec
On Mon, May 23, 2016 at 5:12 PM, Rich Hickey wrote:
> Introducing clojure.spec
>
> I'm happy to introduce today clojure.spec, a new core library and support
> for data and function specifications in Clojure.
>
> Better communication
>
> Clojure is a dynamic language, and thus far we have relied on
> documentation or external libraries to explain the use and behavior of
> functions and libraries. But documentation is difficult to produce, is
> frequently not maintained, cannot be automatically checked and varies
> greatly in quality. Specs are expressive and precise. Including spec in
> Clojure creates a lingua franca with which we can state how our programs
> work and how to use them.
>
> More leverage and power
>
> A key advantage of specifications over documentation is the leverage they
> provide. In particular, specs can be utilized by programs in ways that docs
> cannot. Defining specs takes effort, and spec aims to maximize the return
> you get from making that effort. spec gives you tools for leveraging specs
> in documentation, validation, error reporting, destructuring,
> instrumentation, test-data generation and generative testing.
>
> Improved developer experience
>
> Error messages from macros are a perennial challenge for new (and
> experienced) users of Clojure. specs can be used to conform data in macros
> instead of using a custom parser. And Clojure's macro expansion will
> automatically use specs, when present, to explain errors to users. This
> should result in a greatly improved experience for users when errors occur.
>
> More robust software
>
> Clojure has always been about simplifying the development of robust
> software. In all languages, dynamic or not, tests are essential to quality
> - too many critical properties are not captured by common type systems.
> spec has been designed from the ground up to directly support generative
> testing via test.check https://github.com/clojure/test.check. When you
> use spec you get generative tests for free.
>
> Taken together, I think the features of spec demonstrate the ongoing
> advantages of a powerful dynamic language like Clojure for building robust
> software - superior expressivity, instrumentation-enhanced REPL-driven
> development, sophisticated testing and more flexible systems. I encourage
> you to read the spec rationale and overview http://clojure.org/about/spec.
> Look for spec's inclusion in the next alpha release of Clojure, within a
> day or so.
>
> Note that spec is still alpha, and some details are likely to change.
> Feedback welcome.
>
> I hope you find spec useful and powerful!
>
> Rich
>
> --
> 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.
>
--
Kind Regards,
Atamert Ölçgen
◻◼◻
◻◻◼
◼◼◼
www.muhuk.com
--
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.spec
Thanks Alex! I didn't know this.
On Tue, May 24, 2016 at 3:10 PM, Alex Miller wrote:
> The first use is a namespace alias and the second is a var - they don't
> overlap in usage.
>
>
> On Tuesday, May 24, 2016 at 2:28:11 AM UTC-5, Atamert Ölçgen wrote:
>>
>> Isn't s redefined in this example:
>>
>> user=> (require '[clojure.spec :as s])
>> (s/def ::even? (s/and integer? even?))
>> (s/def ::odd? (s/and integer? odd?))
>> (s/def ::a integer?)
>> (s/def ::b integer?)
>> (s/def ::c integer?)
>> (def s (s/cat :forty-two #{42}
>> :odds (s/+ ::odd?)
>> :m (s/keys :req-un [::a ::b ::c])
>> :oes (s/* (s/cat :o ::odd? :e ::even?))
>> :ex (s/alt :odd ::odd? :even ::even?)))
>> user=> (s/conform s [42 11 13 15 {:a 1 :b 2 :c 3} 1 2 3 42 43 44 11])
>> {:forty-two 42,
>> :odds [11 13 15],
>> :m {:a 1, :b 2, :c 3},
>> :oes [{:o 1, :e 2} {:o 3, :e 42} {:o 43, :e 44}],
>> :ex {:odd 11}}
>>
>>
>> in http://clojure.org/about/spec
>>
>>
>> On Mon, May 23, 2016 at 5:12 PM, Rich Hickey
>> wrote:
>>
>>> Introducing clojure.spec
>>>
>>> I'm happy to introduce today clojure.spec, a new core library and
>>> support for data and function specifications in Clojure.
>>>
>>> Better communication
>>>
>>> Clojure is a dynamic language, and thus far we have relied on
>>> documentation or external libraries to explain the use and behavior of
>>> functions and libraries. But documentation is difficult to produce, is
>>> frequently not maintained, cannot be automatically checked and varies
>>> greatly in quality. Specs are expressive and precise. Including spec in
>>> Clojure creates a lingua franca with which we can state how our programs
>>> work and how to use them.
>>>
>>> More leverage and power
>>>
>>> A key advantage of specifications over documentation is the leverage
>>> they provide. In particular, specs can be utilized by programs in ways that
>>> docs cannot. Defining specs takes effort, and spec aims to maximize the
>>> return you get from making that effort. spec gives you tools for leveraging
>>> specs in documentation, validation, error reporting, destructuring,
>>> instrumentation, test-data generation and generative testing.
>>>
>>> Improved developer experience
>>>
>>> Error messages from macros are a perennial challenge for new (and
>>> experienced) users of Clojure. specs can be used to conform data in macros
>>> instead of using a custom parser. And Clojure's macro expansion will
>>> automatically use specs, when present, to explain errors to users. This
>>> should result in a greatly improved experience for users when errors occur.
>>>
>>> More robust software
>>>
>>> Clojure has always been about simplifying the development of robust
>>> software. In all languages, dynamic or not, tests are essential to quality
>>> - too many critical properties are not captured by common type systems.
>>> spec has been designed from the ground up to directly support generative
>>> testing via test.check https://github.com/clojure/test.check. When you
>>> use spec you get generative tests for free.
>>>
>>> Taken together, I think the features of spec demonstrate the ongoing
>>> advantages of a powerful dynamic language like Clojure for building robust
>>> software - superior expressivity, instrumentation-enhanced REPL-driven
>>> development, sophisticated testing and more flexible systems. I encourage
>>> you to read the spec rationale and overview
>>> http://clojure.org/about/spec. Look for spec's inclusion in the next
>>> alpha release of Clojure, within a day or so.
>>>
>>> Note that spec is still alpha, and some details are likely to change.
>>> Feedback welcome.
>>>
>>> I hope you find spec useful and powerful!
>>>
>>> Rich
>>>
>>> --
>>> 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/gro
Re: ANN: [lein-describe 0.1.0] plugin for displaying detailed information about Clojure projects
The project URL is "https://github.com/noprompt/lein-garden";. (Sorry, if this was mentioned before, I joined recently.) On Wed, Feb 5, 2014 at 12:28 PM, wrote: > Looks cool. I'll be sure to check it out. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ANN: [lein-describe 0.1.0] plugin for displaying detailed information about Clojure projects
I posted to the correct thread. Check the project.clj please. On Thu, Feb 6, 2014 at 12:05 PM, Joel Holdbrooks wrote: > Wat? I think you may have meant to post this comment somewhere else. > That's certainly not the case. But I think I did forget to share the link > which is: https://github.com/noprompt/lein-describe > > > On Wednesday, February 5, 2014 6:23:25 PM UTC-8, Atamert Ölçgen wrote: > >> The project URL is "https://github.com/noprompt/lein-garden";. (Sorry, if >> this was mentioned before, I joined recently.) >> >> >> On Wed, Feb 5, 2014 at 12:28 PM, wrote: >> >>> Looks cool. I'll be sure to check it out. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com >>> >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com >>> >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+u...@googlegroups.com. >>> >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> >> >> -- >> Kind Regards, >> Atamert Ölçgen >> >> -+- >> --+ >> +++ >> >> www.muhuk.com >> > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
