Re: [ANN] aprint (awesome print) released
great stuff. thanks. On Friday, 12 September 2014 01:06:29 UTC+10, Vladimir Bokov wrote: Yes. I use clansi: (clansi.core/without-ansi (aprint issues)) Thanks for feedback, I updated README too четверг, 11 сентября 2014 г., 21:58:57 UTC+7 пользователь Dave Sann написал: Is there an easy way to get the same compact layout but without the colour control codes? On Friday, 5 September 2014 07:50:10 UTC+10, Vladimir Bokov wrote: Hi folks, I got just tired to gazing into big amount of data and scroll 3-4 screens of my 13' laptop to grasp the structure, so I used pprint's pretty printer, but add colors and changed indentation *by default* (actually pprint has tuning parameters, too, but anyway it's breaking maps by single entry by line...) Now the screen area gets used more effectively and looks more friendly imo :) See it: https://github.com/razum2um/aprint Looking forward yours opinion if I should make a nrepl middleware to use it *right away*, without doing (ap) every time ;) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group 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 terminology
That's a neat trick! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group 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: (Request) Rich Hickey's EuroClojure 2014 slides
Thank you. BTW, I really liked Clojure/West video editing style. Andy On Fri, Sep 12, 2014 at 8:55 AM, John Gabriele jmg3...@gmail.com wrote: A format I particularly like is when there's simply one video file where: * the main portion of the window shows the slides, * a small thumbnail-size portion shows the speaker, and * the remaining rectangle shows static details such as the name of the talk, name of speaker, subject, and date. As in this style: https://skillsmatter.com/skillscasts/3445-functional-web. -- John On Thursday, September 11, 2014 10:33:41 AM UTC-4, Alex Miller wrote: Usually Rich doesn't release his slides as he prefers for them to be consumed in the context of the talk. On Thursday, September 11, 2014 8:44:47 AM UTC-5, Leon Grapenthin wrote: Hi, I am looking for the slides of this talk because one can't see them in the video: http://vimeo.com/100518968 Thanks, Leon. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Is Transit / core.async suitable for remote function invocation?
Sente works really well, I am using it in the Clojure rewrite of an application and I am using it to call functions on the server from the client by putting messages on core.async channels. I am even using it to get around the current limitation on the ClojureScript side that there's no *pprint* implementation (yet). Instead, I send my data structure for visual inspection to the server during the development process and have that pretty print to the console. Sounds like a hack but works really well. Here's the source code of that project: github.com/matthias/BirdWatch However, *@Mikera* I don't really think you want synchronous function invocation. You send messages and then move on and at some point, a result comes back. Why would you want to wait for anything to finish when you do not have the wire under control? *@Shaun* I don't think a client can ever be trusted enough to allow it to send arbitrary code for evaluation to the server. The idea alone makes me cringe, just like eval() in JavaScript does. Cheers, Matthias On Thursday, September 11, 2014 3:06:26 PM UTC+2, Shaun Robinson wrote: Check out Sente. It meets all your requirements. EDN is used as a transport mechanism, with experimental support for Transit -- but these are really implementation details. Values sent from the client shows up in tact on the server, and vice versa. https://github.com/ptaoussanis/sente * Sente provides a send function and a core.async channel on both the Clojure and Clojurescript sides. * Any value sent via the client's send function shows up on the server's channel intact, and vice versa * The server keeps an atom of connected clients, and a message from the server can target one or all of them * The excellent core.match is commonly used for pattern matching messages on the client and server sides and dispatching functions * There is robust support for re-connecting * The software is mature, and terse (~1000 lines). I've used it as a comms layer in several production apps with great success. * Regarding remote function serialization / invocation, assuming you trust your client, you could pass a function from client-server as data, and invoke it on the server side. No need for serialization, normal 'quoting' would work. - Shaun On Wednesday, September 10, 2014 1:39:24 AM UTC-4, Mikera wrote: I've encountered a couple of use cases where it would helpful to have some form of remote function invocation in Clojure/ClojureScript with the following characteristics: - Arbitrary functions can be effectively serialised and sent to remote machines - Remote functions can be invoked either synchronously or asynchronously - Parameters get passed as serialised values, which might in turn be other functions - Works across Clojure/ClojureScript boundary - Would need to allow for various error conditions (network failure etc.) Could this be achieved in a reasonably sane way with some combination of Transit and/or core.async? Has anyone tried this? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Schrodinger's cat in clojure?
By watching (println) the experiment we influence the outcome. Is the Schrodinger's cat present in Clojure? This example program that shows how printing a value can change the value under specific circumstances. It seems the case that it has to do with the lazy evaluation that happen in Clojure. Basically I map a pr-str over a list. When I print the list before realization it seems that println is modifies the value. Doing a doall or turning the lazy-list into a vector makes the circumvents the issue. The code showing this behavior is is attached. Loading the file will show the issue. I've tested it in Clojure 1.5.1, Clojure 1.6.0. I also tested it in Clojure-clr 1.5.0, and observed the same issue. Please let me know whether this is expected behavior, a known issue, or a new one. Cees. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. issue.clj Description: Binary data
Re: Schrodinger's cat in clojure?
A man walks into a bar and says I used lazy evaluation and things were confusing. Bartender says You mixed it with I/O without bothering to look at the code. :-) Your experiment uses pr-str, which uses a dynamically scoped resource *out* in order to create its result. Your observation uses println, which uses the same dynamically scoped resource. Mix in different evaluation strategies, and races can lead to different outcomes. Here is a much smaller example: (pr-str [1 2]) (pr-str (map #(doto % println) [1 2])) So this result is expected. Beware I/O, and in the presence of I/O be very careful in concluding that something is a value. Your quoted-pr-str is not a pure function, and so it does not make values. Regards, Stu On Sat, Sep 13, 2014 at 4:41 AM, cees van Kemenade cees.van.kemen...@gmail.com wrote: By watching (println) the experiment we influence the outcome. Is the Schrodinger's cat present in Clojure? This example program that shows how printing a value can change the value under specific circumstances. It seems the case that it has to do with the lazy evaluation that happen in Clojure. Basically I map a pr-str over a list. When I print the list before realization it seems that println is modifies the value. Doing a doall or turning the lazy-list into a vector makes the circumvents the issue. The code showing this behavior is is attached. Loading the file will show the issue. I've tested it in Clojure 1.5.1, Clojure 1.6.0. I also tested it in Clojure-clr 1.5.0, and observed the same issue. Please let me know whether this is expected behavior, a known issue, or a new one. Cees. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Schrodinger's cat in clojure?
A man walks into a bar and says I used lazy evaluation and things were confusing. Bartender says You might have mixed it with I/O, but then again maybe you're getting tripped up by other some other not-purely-functional aspect of your program or the JVM, like GC or thread transitions. Okay, it's not as good a joke that way, but it may be more accurate. While the OP's issue was IO-related, I've run into confusing laziness-related bugs, some of which were indeed Heisenbugs, that didn't have anything obvious to do with IO. I think some were related to GC not knowing that it could collect something, while others had to do with something lazy being realized in a different thread than I expected. For some, I've never really figured out what was happening, but I've nonetheless found that the problem went away when I switched map to mapv, or filter to filterv, etc. So now one of my first steps when I'm faced with a confusing bug is to stamp out all of the laziness except where I'm really doing things lazily on purpose, for a good reason. I've also come to think that the pervasiveness and defaultness of laziness in Clojure may not really be so wonderful after all. Laziness is beautiful when you want it, and when you do want it it's beautiful that so much of Clojure works with it so effortlessly and transparently, but it can also produce subtle problems when things aren't purely functional (which is a lot of the time, in my experience, sometimes for subtle reasons). -Lee On Sep 13, 2014, at 9:32 AM, Stuart Halloway stuart.hallo...@gmail.com wrote: A man walks into a bar and says I used lazy evaluation and things were confusing. Bartender says You mixed it with I/O without bothering to look at the code. :-) Your experiment uses pr-str, which uses a dynamically scoped resource *out* in order to create its result. Your observation uses println, which uses the same dynamically scoped resource. Mix in different evaluation strategies, and races can lead to different outcomes. Here is a much smaller example: (pr-str [1 2]) (pr-str (map #(doto % println) [1 2])) So this result is expected. Beware I/O, and in the presence of I/O be very careful in concluding that something is a value. Your quoted-pr-str is not a pure function, and so it does not make values. Regards, Stu -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
jetty restart failing
Hi,
I'm trying to apply the ideas from the component library:
https://github.com/stuartsierra/component
My problems is being about stop/start the Jetty server, for that purpose I
created this component:
(defrecord WebServer [app port join? jetty log]
component/Lifecycle
(start [c]
(log Starting jetty server...)
(let [jetty (jetty/run-jetty (:handler app) {:port port :join?
join?})]
(log Server started at port port)
(assoc c :jetty jetty)))
(stop [c]
(when (:jetty c)
(log Stopping jetty...)
(.stop (:jetty c))
(log Server stopped.))
(assoc c :jetty nil)))
(defn webserver-component
([port] (webserver-component port true))
([port join?]
(map-WebServer {:port port :join? join?})))
It works, sometimes, but often I get this when I try to reset:
Error starting #ExceptionInfo clojure.lang.ExceptionInfo: Error in
component :server in system com.stuartsierra.component.SystemMap calling
#'com.stuartsierra.component/start {:reason
:com.stuartsierra.component/component-function-threw-exception, :function
#'com.stuartsierra.component/start, :system-key :server, :component
#cadegp.components.web_server.WebServer{:app
#cadegp.components.web_app.CadegpApp{:conn
#cadegp.components.database.Database{:uri
datomic:free://localhost:4334/cadegp, :connection #Connection {:db-id
cadegp-48d87324-7849-4255-b798-865b02ee9d9d, :index-rev 0, :basis-t 1176,
:next-t 1177, :unsent-updates-queue 0, :pending-txes 0}}, :handler
#reload$wrap_reload$fn__1728
ring.middleware.reload$wrap_reload$fn__1728@6608b223, :handler-ext
#user$wrap_dev_handler user$wrap_dev_handler@7e174cba}, :port 8000,
:join? false, :jetty nil, :log #core$println clojure.core$println@7a2c3090},
:system #SystemMap}
Seems that it tries to start the server before it have time to shut it down.
Any of you had a similar issue or know how to work around that?
Thanks.
---
Wilker Lúcio
http://about.me/wilkerlucio/bio
Woboinc Consultant
+55 81 82556600
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group 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: jetty restart failing
I forgot to post before, here is the actual error:
BindException Address already in use sun.nio.ch.Net.bind0 (Net.java:-2)
Also, adding a (Thread/sleep 1000) seems to increase the success rate, but
would be nice to be able to really wait on Jetty to shutdown instead of
using arbitrary sleep.
Thanks.
---
Wilker Lúcio
http://about.me/wilkerlucio/bio
Woboinc Consultant
+55 81 82556600
On Sat, Sep 13, 2014 at 8:20 PM, Wilker wilkerlu...@gmail.com wrote:
Hi,
I'm trying to apply the ideas from the component library:
https://github.com/stuartsierra/component
My problems is being about stop/start the Jetty server, for that purpose I
created this component:
(defrecord WebServer [app port join? jetty log]
component/Lifecycle
(start [c]
(log Starting jetty server...)
(let [jetty (jetty/run-jetty (:handler app) {:port port :join?
join?})]
(log Server started at port port)
(assoc c :jetty jetty)))
(stop [c]
(when (:jetty c)
(log Stopping jetty...)
(.stop (:jetty c))
(log Server stopped.))
(assoc c :jetty nil)))
(defn webserver-component
([port] (webserver-component port true))
([port join?]
(map-WebServer {:port port :join? join?})))
It works, sometimes, but often I get this when I try to reset:
Error starting #ExceptionInfo clojure.lang.ExceptionInfo: Error in
component :server in system com.stuartsierra.component.SystemMap calling
#'com.stuartsierra.component/start {:reason
:com.stuartsierra.component/component-function-threw-exception, :function
#'com.stuartsierra.component/start, :system-key :server, :component
#cadegp.components.web_server.WebServer{:app
#cadegp.components.web_app.CadegpApp{:conn
#cadegp.components.database.Database{:uri
datomic:free://localhost:4334/cadegp, :connection #Connection {:db-id
cadegp-48d87324-7849-4255-b798-865b02ee9d9d, :index-rev 0, :basis-t 1176,
:next-t 1177, :unsent-updates-queue 0, :pending-txes 0}}, :handler
#reload$wrap_reload$fn__1728
ring.middleware.reload$wrap_reload$fn__1728@6608b223, :handler-ext
#user$wrap_dev_handler user$wrap_dev_handler@7e174cba}, :port 8000,
:join? false, :jetty nil, :log #core$println clojure.core$println@7a2c3090},
:system #SystemMap}
Seems that it tries to start the server before it have time to shut it
down.
Any of you had a similar issue or know how to work around that?
Thanks.
---
Wilker Lúcio
http://about.me/wilkerlucio/bio
Woboinc Consultant
+55 81 82556600
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Designing API for a Markov Model
Hi all, I'm new to Clojure and implementing a Markov Model as part of a larger project. I'd like some advice on the API for a progress-state function. I see two possible options. In the first option, we always ask the user to provide and keep track of the MSM state themselves: (progress-state markov-model previous-state) - new-state In the second approach, we create a record that combines a model and a current state: (defrecord MarkovProcess [model current-state]) (progress-state markov-process) - updated-markov-process, new-state Which of these approaches is more idiomatic for Clojure? Are multiple return types an accepted practice in Clojure? Is there a third, better way? Thanks in advance! RJ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group 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: Schrodinger's cat in clojure?
Thanks Stu Lee, I will be more careful next time I order a cocktail in a bar. I wasn't aware that pr-str depended on *out*, as it could be implemented as a pure function, without this harmful mixing effect. I guess pr-str is used to get something in edn-shape without (yet) going to the none-pure real-world. But I expect the current implementation is (via with-out-str) is the fastest and the most compact implementation. Lee, thanks for your suggestions on how to tackle the dreadful HeisenBugs. Regards, Cees. On Saturday, September 13, 2014 4:01:53 PM UTC+2, Lee wrote: A man walks into a bar and says I used lazy evaluation and things were confusing. Bartender says You might have mixed it with I/O, but then again maybe you're getting tripped up by other some other not-purely-functional aspect of your program or the JVM, like GC or thread transitions. Okay, it's not as good a joke that way, but it may be more accurate. While the OP's issue was IO-related, I've run into confusing laziness-related bugs, some of which were indeed Heisenbugs, that didn't have anything obvious to do with IO. I think some were related to GC not knowing that it could collect something, while others had to do with something lazy being realized in a different thread than I expected. For some, I've never really figured out what was happening, but I've nonetheless found that the problem went away when I switched map to mapv, or filter to filterv, etc. So now one of my first steps when I'm faced with a confusing bug is to stamp out all of the laziness except where I'm really doing things lazily on purpose, for a good reason. I've also come to think that the pervasiveness and defaultness of laziness in Clojure may not really be so wonderful after all. Laziness is beautiful when you want it, and when you do want it it's beautiful that so much of Clojure works with it so effortlessly and transparently, but it can also produce subtle problems when things aren't purely functional (which is a lot of the time, in my experience, sometimes for subtle reasons). -Lee On Sep 13, 2014, at 9:32 AM, Stuart Halloway stuart@gmail.com javascript: wrote: A man walks into a bar and says I used lazy evaluation and things were confusing. Bartender says You mixed it with I/O without bothering to look at the code. :-) Your experiment uses pr-str, which uses a dynamically scoped resource *out* in order to create its result. Your observation uses println, which uses the same dynamically scoped resource. Mix in different evaluation strategies, and races can lead to different outcomes. Here is a much smaller example: (pr-str [1 2]) (pr-str (map #(doto % println) [1 2])) So this result is expected. Beware I/O, and in the presence of I/O be very careful in concluding that something is a value. Your quoted-pr-str is not a pure function, and so it does not make values. Regards, Stu -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
