Q about eval-and-print function in clojurescript's cljs.repl (repl.clj)
I'm trying to understand the clojurescript-code of the repl functionality, and I'm confused… The following cljs.repl/eval-and-print function takes a cljs-form, compiles it, sends it to the browser as javascript, and then receives the result, and the… try's to use read-string on that return value: --- (defn- eval-and-print [repl-env env form] (let [ret (evaluate-form repl-env (assoc env :ns (ana/get-namespace ana/*cljs-ns*)) cljs repl form (wrap-fn form))] (try (prn (read-string ret)) (catch Exception e (if (string? ret) (println ret) (prn nil)) --- Why does it call read-string on the returned result from the js-eval? The eval'ed compiled javascript could result in a clojure-form that would be eval'ed on the return (???), and the result of the latter is then printed. Confusingly yours, FrankS. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Q about eval-and-print function in clojurescript's cljs.repl (repl.clj)
Sorry - I've answered part of my own Q by reading the read-string doc… nothing is eval'ed of the result - just the first object is read. Still unclear why read-string is used - why would a second object be discarded? Like: user= (read-string (+ 1 2) (- 3 2)) (+ 1 2) Still confused... -FS. On Sep 18, 2012, at 11:51 PM, Frank Siebenlist frank.siebenl...@gmail.com wrote: I'm trying to understand the clojurescript-code of the repl functionality, and I'm confused… The following cljs.repl/eval-and-print function takes a cljs-form, compiles it, sends it to the browser as javascript, and then receives the result, and the… try's to use read-string on that return value: --- (defn- eval-and-print [repl-env env form] (let [ret (evaluate-form repl-env (assoc env :ns (ana/get-namespace ana/*cljs-ns*)) cljs repl form (wrap-fn form))] (try (prn (read-string ret)) (catch Exception e (if (string? ret) (println ret) (prn nil)) --- Why does it call read-string on the returned result from the js-eval? The eval'ed compiled javascript could result in a clojure-form that would be eval'ed on the return (???), and the result of the latter is then printed. Confusingly yours, FrankS. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Evolving the Clojure contribution process and goals
On Wed, Sep 19, 2012 at 1:12 AM, Andy Fingerhut andy.finger...@gmail.com wrote: On Tue, Sep 18, 2012 at 9:01 PM, Paul deGrandis paul.degran...@gmail.com wrote: 1.) Clojure.org should have a better host of documentation, especially for newcomers. The only things required for someone to create a new web site dedicated to better Clojure documentation is time, knowledge, and some money. There are several intermingled issues: 1. People want to feel involved. Its the opposite of founding a new project, on your own. That their modest effort will be seen by others, since its a part of this bigger thing. Contributing to clojure.org versus your own personal project are 2 different things. 2. Clojure.org isn't sharing traffic, or google juice.. its a walled garden. Leiningen doesn't come up in the first 5 pages of google search results, for example. If a newbie can't find Leiningen, how are they gonna find my project? 3. People want clojure to be taken seriously, and want a public face that is in the same league as other popular languages, by whatever standards that entails. 4. Clojure.org hasn't evolved much, meanwhile the technology and the community have evolved a ton. That is a vacuum liable to be filled with opinionating. There is a cognitive dissonance there, and people want to resolve it somehow. 5. People are confused about what the purpose of clojure.org is. AFAICT it is a reference guide to the efforts of clojure/core. In that context, not including a reference to Leiningen makes sense. But people are confused if that is a suboptimal oversight, or a conscious decision. 6. People are disturbed by the no-handholding style of 3rd party libraries, and see it as a systematic problem in the community. The figurehead is the obvious focal point of this anxiety. Appropriately so, since it plays a big role in the community culture. So there are many dimensions to play in, to empower/mollify. If you've read this far I highly recommend going back to the survey results and analysis. Some strong words, and strong quantitative measures. http://cemerick.com/2012/08/06/results-of-the-2012-state-of-clojure-survey/ I didn’t think it possible, but an even larger proportion of respondents than last year — now up to a third — indicate that documentation is a key problem. This ties into the feedback seen earlier that library documentation is generally not what it should be. To a large degree, this is a self-inflicted wound: both Clojure and its libraries are technologically sufficient and effective and useful, but many, many people are tripping on their way towards using them. Given that the only other problems within 10 percentage points of the documentation issue are largely out of everyone’s direct control [...] the best thing anyone can do to help Clojure succeed is to help make documentation and tutorials better for every skill level and domain, anywhere. I do what I can in my projects and elsewhere; please do what you can, too. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Modelling for DAG with identity map - or not?
On Tuesday, September 18, 2012 10:10:35 PM UTC+1, hutch wrote: On 2012-09-16, at 3:21 PM, Patrik Sundberg patrik@gmail.comjavascript: wrote: I'm asking myself though if there's a more functional design for accomplishing the same goals? My main goals are to do things consistently so that changing a value X propagates properly, and being able to find dependencies of a given value. A DAG+identity map is my first take, but there may be something more natural for FP I'm completely missing. Sounds like a reasonable approach to me. There's nothing wrong with state, just how you manipulate it. The STM in Clojure is really nice in this regard. You might want to have a look at Functional Reactive Programming (FRP). There's a lot of stuff available about that in the Haskell community, but usually for UIs and things like that. They sometimes use spread sheets as an example (spread sheets can be thought of as a DAG with values and computations in cells… you can see the mapping between them in your application (where the mapping doesn't work or is hard might be pointing at something quite interesting). There's also something called 'Cells' in Common Lisp that might be interesting. I'm not sure what's been done in Clojure. yeah, it's essentially a big mushy complex and persistable spreadsheet I'm building, that's the right analogy that I tend to use myself (and should have done in my post as well to make it easier to follow :)). Thanks for the pointers, I'll go check those things out. btw, after started to play with it turns out records and protocols ends up being the convenient way to do it, seems I don't need the flexibility of multimethod dispatch + I do end up wanting some per type data to store. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Evolving the Clojure contribution process and goals
3.) Much like an Emergency Room, there should be a a fast-track to getting smaller patches approved and merged. This is actually not a problem consistent across all areas of the language - some contrib libraries and ClojureScript in particular seem to be getting this *just right*. Is there a way we can adjust the current workflow to fill need? It seems like even with more screeners, patches are sitting idle. One possible solution is if we extended contrib-like ownership into parts of Clojure proper, like clojure.test, clojure.string, etc. Better triage is high on my wish list, too. (Although I think the emergency room metaphor implies he opposite result for smaller patches.) Now that dependency management has improved to the point that Clojure has build-time dependencies down into contrib, another option is to take clojure.test et al out of Clojure into contribs. This would be a breaking change in that people would have to add such new contribs to their maven deps. 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
Re: Evolving the Clojure contribution process and goals
Andy Fingerhut: On Tue, Sep 18, 2012 at 9:01 PM, Paul deGrandis paul.de...@gmail.comjavascript: wrote: 1.) Clojure.org should have a better host of documentation, especially for newcomers. We saw from the Clojure Survey, as well as threads here on the mailing list, that documentation is still something on which we as a community need to work. Could perhaps a different process govern documentation contributions, something more akin to http://docs.scala-lang.org/contribute.html that doesn't involve the CA? How could we best integrate such a project into Clojure.org? Would anyone be willing to help push such a project forward? my guess is that it would be easier to create a new site than to expect someone else to do an overhaul on clojure.org. You would own your own destiny. You would never need to wait on someone else to do something for you, unless it was someone at the company you chose to host your site, or one of your colleagues to do their part. It is quick and easy for clojure.org to add one or several links to such a site once it is up and going. This suggestion ignores the fact that most newcomers are much more likely to head to clojure.org instead of some third party site and expect clojure.org to be at least somewhat helpful. Currently I advice Clojure newcomers to not use clojure.org for anything, it is hopelessly outdated, reference-oriented and will only confuse them more. Unsurprisingly, this does not encourage newcomers as they think that many other things are hopelessly broken and outdated in this community. clojure.org needs change, adding a yet another link won't help. MK -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Evolving the Clojure contribution process and goals
Currently I advice Clojure newcomers to not use clojure.org for anything, it is hopelessly outdated, reference-oriented and will only confuse them more. Unsurprisingly, this does not encourage newcomers as they think that many other things are hopelessly broken and outdated in this community. 1. Agreed that the outdated parts of clojure.org should be fixed. I hope to spend some time on that this week. 2. We can and should have better community-driven documentation. Currently clojure.org links out to http://dev.clojure.org/display/doc/Home in a few places, and could link out more. Leadership in making dev.clojure.org excellent would be most welcome. Don't ask for permission, just do it. Cheers, Stu Stuart Halloway Clojure/core http://clojure.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
Re: Anyone using Sublime Text 2 + SumblimeREPL with Windows?
I am trying this out with clojure on windows sublime 2.0.1. i get the clojure repl up using 'ctrl+f12' then 'c' then 's' then i type (println hello) then i have tried an array of keys F2 then ''l' (lower case 'L') ctrl+,, l shift+ctrl+,, l tried all the above with 'b' for block as well with nothing. this post looks similar http://www.sublimetext.com/forum/viewtopic.php?f=3t=7878 I've tried to set my own keys but i see nothing in the sublime console or anything. Any ideas to make this work? https://github.com/wuub/SublimeREPL you can see here that the windows defaults have changed some since the start of this thread but nothing is working yet On Wednesday, June 27, 2012 10:59:54 AM UTC-5, Jacobo Polavieja wrote: On Wednesday, June 27, 2012 5:07:05 PM UTC+2, Niels van Klaveren wrote: This combination of Sublime -text -REPL looks pretty useful, with little extra configuration (except that decommenting part :) ). When I have the REPL launched, when returning values I get a lot of lines with BS..BS sequences. Any idea how to get rid of those ? I'm just new using Clojure and Sublime but don't seem to have those lines. Does it always happend to you? Can you provide some code that does? Cheers! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Would you please help in migrating this code from Bishop to Liberator?
Hi,
I want to migrate this code written in Bishop REST framework to Liberator
REST framework:
(bishop/defresource ticket
{
text/html
(fn [request]
(let [request-method (:request-method request)]
(case request-method
:get (list-all-tickets request)
:post (create-ticket-per-uploaded-file request
}
{
:allowed-methods (fn [request] [:get :post])
})
I'm not really digesting the liberator approach.
Thanks for help and 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
Re: Q about eval-and-print function in clojurescript's cljs.repl (repl.clj)
If you look at cljs counterpart of it you'll see that maps are send as responses, that is why read-string is used. HTH Frank Siebenlist wrote: Sorry - I've answered part of my own Q by reading the read-string doc… nothing is eval'ed of the result - just the first object is read. Still unclear why read-string is used - why would a second object be discarded? Like: user= (read-string (+ 1 2) (- 3 2)) (+ 1 2) Still confused... -FS. On Sep 18, 2012, at 11:51 PM, Frank Siebenlistfrank.siebenl...@gmail.com wrote: I'm trying to understand the clojurescript-code of the repl functionality, and I'm confused… The following cljs.repl/eval-and-print function takes a cljs-form, compiles it, sends it to the browser as javascript, and then receives the result, and the… try's to use read-string on that return value: --- (defn- eval-and-print [repl-env env form] (let [ret (evaluate-form repl-env (assoc env :ns (ana/get-namespace ana/*cljs-ns*)) cljs repl form (wrap-fn form))] (try (prn (read-string ret)) (catch Exception e (if (string? ret) (println ret) (prn nil)) --- Why does it call read-string on the returned result from the js-eval? The eval'ed compiled javascript could result in a clojure-form that would be eval'ed on the return (???), and the result of the latter is then printed. Confusingly yours, FrankS. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Evolving the Clojure contribution process and goals
On Sep 19, 2012, at 12:11 AM, kovas boguta wrote: On Wed, Sep 19, 2012 at 1:12 AM, Andy Fingerhut andy.finger...@gmail.com wrote: On Tue, Sep 18, 2012 at 9:01 PM, Paul deGrandis paul.degran...@gmail.com wrote: 1.) Clojure.org should have a better host of documentation, especially for newcomers. The only things required for someone to create a new web site dedicated to better Clojure documentation is time, knowledge, and some money. There are several intermingled issues: 1. People want to feel involved. Its the opposite of founding a new project, on your own. That their modest effort will be seen by others, since its a part of this bigger thing. Contributing to clojure.org versus your own personal project are 2 different things. Kovas, have you used ClojureDocs.org? If not, I recommend trying it out. In under 5 minutes, you should be able to figure out how to add an example. One or two people started it, and dozens if not hundreds have added anywhere from 5 minutes to hours worth of extra effort adding examples. Several times in the last few months, there have been discussions on this list about what the documentation should say about a function. It takes me longer to think of what to add to ClojureDocs.org for the function than it does to go through the steps to add it. Your suggestions and mine are not mutually exclusive -- my suggestion is that one enable the other. A few people create an updated site that makes it as easy as ClojureDocs.org for everyone else who is willing to make a modest effort that will be seen by others. I'm not proposing that hundreds of people go out and create such a web site. Whether I did or not, I'm sure it wouldn't happen :-) 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
Negation in core.logic
Hello, Is there a way to negate a goal in core.logic? I have written this goal below, and I would like to use it to query all the pairs of people who are *not* relatives according to my facts (for dating purposes of course :-D) (defn relative [p1 p2] (conde [(parent p1 p2)] [(parent p2 p1)] [(sibling p1 p2)] [(cousin p1 p2)] [(nephew p1 p2)] [(uncle p1 p2)])) Thanks, Stathis -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Evolving the Clojure contribution process and goals
Andy - you're the perfect model of someone stepping up from the community and making the situation better for everyone. I'm sure I speak for a large population when I say, Thank You. For sure, I'd love to see an updated ClojureDocs-like system, hooked up to the build process and integrated into clojure.org. (Including all of contrib and CLJS) Pairing that with ClojureWerkz-style pages for all the contrib libraries would be an enormous leap forward (I'd love for the authors of ClojureWerkz to share the outline of the process that works for them). It would be in those dedicated pages that external links could guide the reader to further material. Kovas, I *very* much agree with all your points and think they are well said. Stuart, can you elaborate a little what better triage looks like? What are the current issues you're facing and what would make the process better for you? The ER metaphor perhaps isn't the best :) What are other ways the community can help get changes pushed along better and integrated? How might we better adjust the process to prevent patched and screened changes from sitting around for long stretches of time? My concern with growing the documentation on the dev.clojure is that it takes a CA to contribute. I think we'd be better served as a community to open up documentation contributions to everyone. One possible solution is moving clojure.org or a subset (docs.clojure.org) to a github repo, as integrated Markdown pages. Thoughts? Concerns? Paul -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
[ANN] Ducttape.cljs 0.1.0: A ClojureScript micro MVC framework
Hi, Ducttape.cljs is a ClojureScript micro MVC framework/library. https://github.com/hozumi/ducttape.cljs Here's a list of benefits: * Clear structure * Super thin * No original event system * Use functions and atoms as building blocks * Don't force to use specific library Check it out. Cheers, - Takahiro -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Evolving the Clojure contribution process and goals
2012/9/19 Paul deGrandis paul.degran...@gmail.com For sure, I'd love to see an updated ClojureDocs-like system, hooked up to the build process and integrated into clojure.org. (Including all of contrib and CLJS) This sounds like a good idea. Pairing that with ClojureWerkz-style pages for all the contrib libraries would be an enormous leap forward (I'd love for the authors of ClojureWerkz to share the outline of the process that works for them). It would be in those dedicated pages that external links could guide the reader to further material. For those who have no idea what ClojureWerkz is, see clojurewerkz.org. Some examples of doc guides for our projects: http://clojureriak.info http://clojureelasticsearch.info http://clojureneo4j.info They all are based on a template git repository that is cloned, modified and pushed into a new repo. All guides are written in Markdown, follow similar structure and use gist.github.com for code snippets. All contributions are the usual github process, everything is CC BY 3.0 licensed. The template repo: https://github.com/clojurewerkz/docslate My concern with growing the documentation on the dev.clojure is that it takes a CA to contribute. I think we'd be better served as a community to open up documentation contributions to everyone. One possible solution is moving clojure.org or a subset (docs.clojure.org) to a github repo, as integrated Markdown pages. Thoughts? Concerns? Using CA for documentation sounds unnecessary. Using GitHub, pull requests and writing in Markdown is a much more open process friendly to developers. docs.scala-lang.org is developed that way: https://github.com/scala/scala.github.com. -- MK -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Tagged literals: undefined tags blow up reader
I added the following comment to CLJ-927 as a possible solution.
It would be convenient if I could handle unknown tags using some sort of
catch-all key in data-readers (say 'default). The associated function should
take two arguments: the tag and the literal value. If there is no 'default key
in data-readers, then an error would be thrown (same as Clojure 1.4).
I think it's a simple way to allow the programmer to take control without
having to add new API or data types. It's just one distinguished key ('default,
:default something like that) and one additional line of doc.
I have a patch that I'm planning to submit if dev people indicate support for
it. The alternative of binding another dynamic var as the unknown tag handler
would also work for me.
Steve Miner
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Evolving the Clojure contribution process and goals
Paul deGrandis: 4.) What are the limitations behind changing the CA process? Can the CA process be made digital (a scan of a signed CA, SSH shared key, OAuth credential confirmation) or potentially reformed to allow more of the community to easily get involved, especially for smaller patches or doc changes? After looking at similar communities (Scala - http://docs.scala-lang.org/sips/sip-submission.html, Python - http://www.python.org/psf/contrib/), it seems like there are potential improvements we could make as the language, ecosystem, and community evolve. It would be great if someone from clojure/core could explain why CAs have to be submitted via snail mail. Oracle, OpenJDK, ASF, Neo Technologies and several other companies accept CAs as PDFs. From my personal experience with neo4j, it takes no more than a day to submit and have your CA confirmed. Sounds like if something is legally acceptable for Oracle, ASF, OpenJDK and significantly smaller yet not exactly young companies, it can work well for Clojure? The current process definitely does not take a day and is problematic for people who live outside of North America and Western Europe. People in Russia, South America, Asia don't necessarily have the luxury of cheap, reliable, fast snail mail delivery to North Carolina. FedEx and friends charge over $200 for a single sheet of paper mailed to Durham, NC from Moscow. $200+ for an opportunity to spend my time contributing to an OSS project in this age of GitHub sounds a little unreasonable. Last time I asked a clojure/core member about this I was told that's too bad. I don't have an opportunity to go to the Conj, don't have access to clojure-dev and consider myself a pretty active contributor to the ecosystem via clojurewerkz.org. I am sure there are many other people like me in the same situation. Please, clojure/core, explain why the CA process has to be so archaic. MK -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Negation in core.logic
On Wed, Sep 19, 2012 at 11:11 AM, Stathis Sideris side...@gmail.com wrote: Hello, Is there a way to negate a goal in core.logic? I have written this goal below, and I would like to use it to query all the pairs of people who are *not* relatives according to my facts (for dating purposes of course :-D) (defn relative [p1 p2] (conde [(parent p1 p2)] [(parent p2 p1)] [(sibling p1 p2)] [(cousin p1 p2)] [(nephew p1 p2)] [(uncle p1 p2)])) Thanks, Stathis core.logic currently only supports Prolog's negation as failure. You can write a goal that looks like this: (defn not [g] (fn [a] (if (nil? (g a)) a))) But you must be careful if you use this, all logic vars passed to the goal g must be ground. So it's not relational. I have some leads based on recent Prolog research (CiaoProlog, and an interesting dissertation on the abstract interpretation of Prolog) for really handling negation in core.logic but I don't think I'll have time to deal with it any time soon. Again, more than willing and excited to collaborate with people who would like to see it done sooner. 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
Re: Data Structure server (Redis in Clojure)
Those are a bit different. Naming of data structures in Redis can be a bit confusing. What's called a sorted set actually is more like a sorted map - keys mapped to scores and set is sorted by scores. On Tuesday, September 18, 2012 5:51:25 AM UTC-7, Moritz Ulrich wrote: Hi! I don't have the time to look at your code right now, but I have one suggestion: Artem Yankov writes: 2. What would be a best way to implement sorted sets (like in Redis)? I used sorted maps and sorting them by values which I highly doubt is a log(n) operation.. `clojure.core/sorted-set' and `clojure.core/sorted-set-by' http://clojuredocs.org/clojure_core/clojure.core/sorted-set -- Moritz Ulrich -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Evolving the Clojure contribution process and goals
Stuart, can you elaborate a little what better triage looks like? What are the current issues you're facing and what would make the process better for you? The ER metaphor perhaps isn't the best :) What are other ways the community can help get changes pushed along better and integrated? How might we better adjust the process to prevent patched and screened changes from sitting around for long stretches of time? Here are a few ideas: 1. Please be clear in marking something a defect vs. an enhancement requests. Defects have top priority, and I would guess that I reclassify 30% of the tickets I review from defect to enhancement request. 2. If you have found a defect for which you know of no workaround, shout *loudly*. Put a message on the mailing list, making it clear that you are stuck. These items should get the very highest priority. 3. If your enhancement can be library code, make a contrib library of it. Then you are not tied to Clojure's deliberately more conservative release cycle. I will put some more thought into this, and plan to host an unsession at the conj for people who want to work on it. 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
Zipper over a heterogeneous tree
Hey all,
I'm having problems writing a zipper that can traverse a heterogeneous tree
of nodes. I have i) a list of maps. Each map has ii) an :inputs key, whose
value is a list of maps.
I want to use a zipper to visit each of those leaves and add a computed
value. The code block and input tree data are below. I can't seem to get
the zipper code to visit the leaf nodes, and add { :thing 123 }. I must be
missing something simple. Any insights?
A)
(loop [loc (zip/zipper (or map? list?)
#((if (map? %1) ;; get children of a
node
(:inputs %1)
%1 ))
#(%1);; create a new
node
(:input-layer neural-network)) ]
(if (zip/end? loc)
(zip/root loc)
(if (map? loc)
(recur (zip/next
(zip/edit loc merge { :thing 123 } )))
(recur (zip/next loc))
)
)
)
B)
({:inputs
({:key :avolume, :value 2.25, :weight 0.4283380545172636, :bias 0}
{:key :bvolume, :value 3.0, :weight 0.6970037374879661, :bias 0}
{:key :ask, :value 1.32379, :weight 0.5387437158323669, :bias 0}
{:key :bid, :value 1.3239, :weight 0.4648184032361037, :bias 0}
{:key :time, :value 1.335902400676, :weight 0.43632873607404554, :bias
0}),
:id 583c10bfdbd326ba34aed329139df6be2487ffc}
{:inputs
({:key :avolume, :value 2.25, :weight 0.13162215440222336, :bias 0}
{:key :bvolume, :value 3.0, :weight 0.23886901184352727, :bias 0}
{:key :ask, :value 1.32379, :weight 0.8408470512339872, :bias 0}
{:key :bid, :value 1.3239, :weight 0.27071013797961796, :bias 0}
{:key :time, :value 1.335902400676, :weight 0.6304505838898373, :bias
0}),
:id 583c10bfdbd326ba34aed329139df6be2487ffd}
{:inputs
({:key :avolume, :value 2.25, :weight 0.8236972641966921, :bias 0}
{:key :bvolume, :value 3.0, :weight 0.32421537754016705, :bias 0}
{:key :ask, :value 1.32379, :weight 0.966306328543246, :bias 0}
{:key :bid, :value 1.3239, :weight 0.8891668220470931, :bias 0}
{:key :time, :value 1.335902400676, :weight 0.278993745549462, :bias
0}),
:id 583c10bfdbd326ba34aed329139df6be2487ffe}
{:inputs
({:key :avolume, :value 2.25, :weight 0.27388486254027167, :bias 0}
{:key :bvolume, :value 3.0, :weight 0.33659579299487363, :bias 0}
{:key :ask, :value 1.32379, :weight 0.16610378593177033, :bias 0}
{:key :bid, :value 1.3239, :weight 0.6964784902474896, :bias 0}
{:key :time, :value 1.335902400676, :weight 0.6306732906337643, :bias
0}),
:id 583c10bfdbd326ba34aed329139df6be2487fff}
{:inputs
({:key :avolume, :value 2.25, :weight 0.8819171698935051, :bias 0}
{:key :bvolume, :value 3.0, :weight 0.5944805362120958, :bias 0}
{:key :ask, :value 1.32379, :weight 0.9060962647355373, :bias 0}
{:key :bid, :value 1.3239, :weight 0.37647418075176464, :bias 0}
{:key :time, :value 1.335902400676, :weight 0.7797681719480866, :bias
0}),
:id 583c10bfdbd326ba34aed329139df6be2488000})
Thanks
Tim Washington
Interruptsoftware.ca
416.843.9060
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Evolving the Clojure contribution process and goals
On Wed, Sep 19, 2012 at 11:01 AM, Andy Fingerhut andy.finger...@gmail.com wrote: Kovas, have you used ClojureDocs.org? If not, I recommend trying it out. In under 5 minutes, you should be able to figure out how to add an example. ClojureDocs is pretty nice. Incidentally, I'm not personally endorsing any of the observations I made, that's just what I hear in other's comments, reading between the lines. IMHO just a couple links to the essentials on the front page and/or getting started would be helpful to many. Thanks to the clojure survey, there is an objective basis for figuring out what toolchain 95% of clojure users are on. Thanks everyone for their contributions. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: [ANN] nrepl.el 0.1.4 released
Hey, Still a fairly newbie emacs user. But when trying to evaluate a form with *C-x C-e ( *after* M-x nrepl-jack-in )*, I still get this error (was happening with nrepl 0.1.3): *Symbol's function definition is void: lisp-eval-last-sexp* This call looks like it's used in * ~/elpa/clojure-mode-1.11.5/clojure-mode.el*. I'm using GNU Emacs 24.0.92.1. I also still have these directories lying around. Should something be blown away, or uninstalled? Does clojure-mode need to be updated ( 1.11.5 looks like the latest )? ~/.emacs.d/swank/ ~/.emacs.d/elpa/nrepl-0.1.3/ ~/.emacs.d/elpa/nrepl-0.1.4/ Thanks Tim Washington Interruptsoftware.ca 416.843.9060 On Tue, Sep 18, 2012 at 9:54 AM, Tim King king...@gmail.com wrote: I am happy to announce the release of nrepl.el v0.1.4, an Emacs client for nREPL. https://github.com/kingtim/nrepl.el v0.1.4 is available now on Marmalade, and should also be available on Melpa. See the github Readme for installation and usage instructions. Notable additions since our last release: - Improvements and simplifications for completion (Tassilo Horn) - Fix paredit .. don't make clojure-mode-map parent of nrepl-interaction-mode-map (Tassilo Horn) - Documentation additions and fixes (Ryan Fowler, Nikita Beloglazov, Bozhidar Batsov, Juha Syrjälä, Philipp Meier) - Make completion back-end and error handler configurable (Hugo Duncan) - Accept host as well as port on connect (Ken Restivo) - Enable nrepl-interaction-mode in clojurescript-mode (Nelson Morris) - Emit stdout from interactive evaluations into the repl buffer - Various bug fixes: - Fixes for ECB interop (Matthew Willson) - Namespace qualify tooling calls (Justin Kramer) - Eldoc fixes (Jack Moffitt) - Fix path quoting in load file for Windows (Philipp Meier) - Fix nREPL / Emacs error Unable to resolve symbol: if-let Many thanks to all the contributors who have reported issues and submitted pull requests. Cheers, Tim -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Some feedback on clojurescript
On Monday, 2012-09-17 at 09:28 , David Nolen wrote: On Sun, Sep 16, 2012 at 8:32 PM, Irakli Gozalishvili rfo...@gmail.com (mailto:rfo...@gmail.com) wrote: Hi Folks, I'm still new to clojurescript, but I thought I would share with you some of the annoyances that person person coming from JS (like myself) will likely run into: http://jeditoolkit.com/2012/09/16/coljurescript-feedback.html Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ Thanks for the feedback! 1. Contributing - Send in your CA, get on clojure-dev, report issues on JIRA. Based on the fantastic contributions received thus far - the CA JIRA are not major road blocks towards contribution. In fact repo suggests discussion group and I had no idea there was JIRA for bug reports. https://github.com/clojure/clojurescript#questions-feedback At least putting a link in the repo readme or something would already help. Also to be fare you can evaluate received contributions, but you can not ones that you did not get. I personally have run into far more issues then I listed in my post but I just could no longer remember those. 2 3. Agreed that property interop with JS objects could probably be improved. Would suggested API for set! and implementation of ILookup be an option ? 4. Regular expressions - Also could be improved - part of the issue here is that regexes go through the Java. 5. try/catch - This change was made early on and as far as I can tell was intentional. But perhaps worth bringing up on clojure-dev for more discussion. ok I'll start a thread on this particular issue. 6. JVM dependence - would be nice but that's likely a pretty long term goal. 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 (mailto:clojure@googlegroups.com) Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com (mailto:clojure+unsubscr...@googlegroups.com) For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Some feedback on clojurescript
On Tuesday, 2012-09-18 at 11:49 , David Nolen wrote: On Tue, Sep 18, 2012 at 2:29 PM, Alexey Petrushin alexey.petrus...@gmail.com (mailto:alexey.petrus...@gmail.com) wrote: issues on JIRA Theres a barrier - You has to register to JIRA to submit issue - many people won't bother with that and just ignore small bugs or proposals vs. almost everyone has github account. Small bugs are submitted to JIRA all the time. It may be barrier for some, but more contributions does not mean better contributions. The contributions we've received so far have been stellar - so I'm inclined to think the barrier is an illusion. Bigger proposals generally need discussion - that's what the clojure-dev mailing list and the Confluence design pages are for. JVM Yeah, would be nice to have JS-on-the-fly compiler (like CoffeeScript) Yes it would, but by and large the users of ClojureScript are Clojure users. So we haven't seen much real interest in this yet. I strongly suspect that reason for this is that only clojure users are comfortable with an existing toolchain, as they already use it from day to day bases. It's a pretty high entry barrier if you just interested in clojurescript and have not used clojure / java before. Would be also nice to have Node.js and NPM support. There is rudimentary support for Node.js. I think everyone would love to see more support but any such additions will be driven by a community of people that actively develop these desirable features. The most popular usage of ClojureScript seems to be Clojure applications that want to target browser based clients. 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 (mailto:clojure@googlegroups.com) Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com (mailto:clojure+unsubscr...@googlegroups.com) For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: [ANN] nrepl.el 0.1.4 released
Timothy Washington twash...@gmail.com writes: Hi Timothy, Still a fairly newbie emacs user. But when trying to evaluate a form with *C-x C-e ( *after* M-x nrepl-jack-in )*, I still get this error (was happening with nrepl 0.1.3): *Symbol's function definition is void: lisp-eval-last-sexp* This call looks like it's used in * ~/elpa/clojure-mode-1.11.5/clojure-mode.el*. Hm, I think that's a SLIME function, and clojure-mode currently uses a bundled SLIME that is compiled when you do clojure-jack-in. With nrepl.el, you don't do that anymore. But anyway, once you've nrepl-jack-in'ed all (or the clojure buffers of that project?) should have nrepl-interaction-mode enabled, and that binds C-x C-e to nrepl-eval-last-expression. Does the buffer with the clj file have nrepl-interaction-mode enabled? You can see that by the nREPL lighter in the mode line or by doing C-h v nrepl-interaction-mode RET in that buffer. It should say the value is t. I'm using GNU Emacs 24.0.92.1. I also still have these directories lying around. Should something be blown away, or uninstalled? Does clojure-mode need to be updated ( 1.11.5 looks like the latest )? No, I use that successfully with nrepl.el, too. ~/.emacs.d/swank/ ~/.emacs.d/elpa/nrepl-0.1.3/ You can probably delete these two. ~/.emacs.d/elpa/nrepl-0.1.4/ But not this one. Bye, Tassilo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Some feedback on clojurescript
On Wed, Sep 19, 2012 at 2:28 PM, Irakli Gozalishvili rfo...@gmail.comwrote: I strongly suspect that reason for this is that only clojure users are comfortable with an existing toolchain, as they already use it from day to day bases. It's a pretty high entry barrier if you just interested in clojurescript and have not used clojure / java before. Yep. I think ClojureScript's appeal could be much, much broader than it currently is but there are lots of things to iron out first. 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
Re: Some feedback on clojurescript
Yep. I think ClojureScript's appeal could be much, much broader than it currently is but there are lots of things to iron out first. The least of which is a plan for distribution and development workflow. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Evolving the Clojure contribution process and goals
On Wednesday, September 19, 2012 11:43:45 AM UTC-4, Michael Klishin wrote: 2012/9/19 Paul deGrandis paul.de...@gmail.com javascript: My concern with growing the documentation on the dev.clojure is that it takes a CA to contribute. I think we'd be better served as a community to open up documentation contributions to everyone. One possible solution is moving clojure.org or a subset (docs.clojure.org) to a github repo, as integrated Markdown pages. Thoughts? Concerns? Using CA for documentation sounds unnecessary. Using GitHub, pull requests and writing in Markdown is a much more open process friendly to developers. docs.scala-lang.org is developed that way: https://github.com/scala/scala.github.com. I think a github project with markdown-formatted files is a good way to go. It strikes a pretty nice balance between a wiki (which tend toward being a free-for-all) and a more rigid centralized setup. Pull-requests are good, and there could be a general policy where the main or original author of the document in question has the major say-so about whether changed are merged or declined. Maybe have it look something like this: https://github.com/uvtc/clojure-docs-collection (though it should probably live under an organization, rather than one doc-focused user :) ). Contributors could propose adding new docs via github issues. ---John -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: [ANN] nrepl.el 0.1.4 released
Hey Tassilo, thanks for responding. Well after *M-x nrepl-jack-in*, I notice that the *Starting nREPL server... * message never goes away. But I don't *think* that's the main problem. *1)* That help window looks like the following. So it doesn't look like the *nrepl-interaction-mode* is enabled on emacs startup. *-UU-:F1 neuralnet.clj Top (16,0)Git:master (Clojure Fill) ...* nrepl-interaction-mode is a variable defined in `nrepl.el'. Its value is nil Automatically becomes buffer-local when set in any fashion. Documentation: Non-nil if nREPL-Interaction mode is enabled. Use the command `nrepl-interaction-mode' to change this variable. *2)* After executing the emacs command '*nrepl-interaction-mode*', I could then execute *C-x C-e*, but got the following message No buffer named *nrepl-connection* *3)* So I went ahead and fired up *M-x nrepl*, and supplied the host and port. Again, the result message *Connecting to nREPL on localhost:57260...* never goes away (hopefully not the real problem). After this, trying to execute *C-x C-e* or *C-x C-l* , gives me the error: Wrong type argument: stringp, nil Tim Washington Interruptsoftware.ca 416.843.9060 On Wed, Sep 19, 2012 at 2:38 PM, Tassilo Horn t...@gnu.org wrote: Timothy Washington twash...@gmail.com writes: Hi Timothy, Still a fairly newbie emacs user. But when trying to evaluate a form with *C-x C-e ( *after* M-x nrepl-jack-in )*, I still get this error (was happening with nrepl 0.1.3): *Symbol's function definition is void: lisp-eval-last-sexp* This call looks like it's used in * ~/elpa/clojure-mode-1.11.5/clojure-mode.el*. Hm, I think that's a SLIME function, and clojure-mode currently uses a bundled SLIME that is compiled when you do clojure-jack-in. With nrepl.el, you don't do that anymore. But anyway, once you've nrepl-jack-in'ed all (or the clojure buffers of that project?) should have nrepl-interaction-mode enabled, and that binds C-x C-e to nrepl-eval-last-expression. Does the buffer with the clj file have nrepl-interaction-mode enabled? You can see that by the nREPL lighter in the mode line or by doing C-h v nrepl-interaction-mode RET in that buffer. It should say the value is t. I'm using GNU Emacs 24.0.92.1. I also still have these directories lying around. Should something be blown away, or uninstalled? Does clojure-mode need to be updated ( 1.11.5 looks like the latest )? No, I use that successfully with nrepl.el, too. ~/.emacs.d/swank/ ~/.emacs.d/elpa/nrepl-0.1.3/ You can probably delete these two. ~/.emacs.d/elpa/nrepl-0.1.4/ But not this one. Bye, Tassilo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
I've had some success using edn
I've had some success using edn on one of my little projects. First a little background: We're running a code generator written in Clojure which consumes homogenous collections of Clojure maps and producing a Java enum for each such collection. (The input data is basically 'edn' except that all values are strings since the Excel macro exporting the input data it too stupid to do anything more sophisticated.) These generated enums are more than just an identity, they also carry additional (immutable) scalar attributes. Some enums are so large in number of members or number of attributes that we were bursting the 64KB method-size limit on the static initializer of the generated Enum class. To solve this problem, these additional attributes were moved out into a separate file, from which the data was retrieved to initialize the each enum's attributes at class loading time. The initial solution: The initial solution used Java serialization for this attribute data. This had two unfortunate properties: 1. Serialized data is not diff/merge friendly. 2. It proved useful to repeat all the attributes and their values as a giant comment in the generated source code. (This made the enum less opaque for the programmer using it.) Using EDN: I've now completed initial work on a feature branch which uses edn for data storage in place of serialization. I'm pleased with the results. The 'edn' data is over twice as large as the serialized data it's replacing, but after compression the difference is less than 50%. Initializing the enums from the approximately 6 MB of edn data takes about twice as long as from the serialized data (0.8 versus 0.4s). Yes, it's bigger and slower than what it's replacing, but in our case it's sufficiently small and sufficiently fast while at the same time addressing points 1 and 2 above. That's a win. I'm using 0.1-SNAPSHOT of my github.com/bpms/edn-java to do the parsing. edn-java has also benefited from seeing some real use. Still lots more to do on that front though. // Ben -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: [ANN] nrepl.el 0.1.4 released
Timothy Washington twash...@gmail.com writes: Well after *M-x nrepl-jack-in*, I notice that the *Starting nREPL server... * message never goes away. But I don't *think* that's the main problem. I think, it is. Normally, after that message it takes ~10secs and then a *nrepl* buffer should pop up. If that doesn't happen for some reason, then there's something wrong. *1)* That help window looks like the following. So it doesn't look like the *nrepl-interaction-mode* is enabled on emacs startup. It's enabled automatically in all clojure buffers as soon as nrepl successfully started, which doesn't seem to happen for you. *2)* After executing the emacs command '*nrepl-interaction-mode*', I could then execute *C-x C-e*, but got the following message No buffer named *nrepl-connection* Yeah, this buffer is also created once nrepl has successfully started. *3)* So I went ahead and fired up *M-x nrepl*, and supplied the host and port. Again, the result message *Connecting to nREPL on localhost:57260...* never goes away (hopefully not the real problem). Hm, hm, why doesn't it want to connect... What you could do to debug the issue is open nrepl.el, goto the function definition of nrepl-jack-in, place point (the emacs cursor) on the function name, do `M-x edebug-defun RET', and then `M-x nrepl-jack-in RET'. Now you'll see an arrow in the margin indicating the flow of control. With `n' you can step one expression further, and the results are printed in the echo area. What are those values? Especially the result of `start-process-shell-command' might give a clue. Bye, Tassilo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
ANN Ritz 0.5.0
Ritz provides a clojure debugger for nREPL.el and SLIME, other nREPL middleware, and a general repl-utils library. 0.5.0 adds several new features. * load-project will load the project for buffer you are currently visiting. This allows you to switch projects in an existing repl. * reload-project will reload the current project. If you have added dependencies to the project, these will be added to the classpath. If you have removed dependencies, the classpath will be updated appropriately and all user namespaces cleared. * lein will allow you to use the REPL vm to run lein command for you current project. The commands above should be prefixed with slime-ritz-, or nrepl-ritz- as appropriate. ritz-nrepl works with the recent nrepl.el 0.1.4 release. Change log: https://github.com/pallet/ritz/blob/develop/ReleaseNotes.md Project: https://github.com/pallet Hugo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: [ANN] nrepl.el 0.1.4 released
Oooh, this is interesting... Well the code block is below, and you can see where the arrow is stopping on execution. ;;;###autoload (defun nrepl-jack-in (prompt-project) (interactive P) *=*(let* ((cmd (if prompt-project (format cd %s %s (ido-read-directory-name Project: ) *nrepl-server-command*) nrepl-server-command)) (process (start-process-shell-command nrepl-server *nrepl-server* cmd))) (set-process-filter process 'nrepl-server-filter) (set-process-sentinel process 'nrepl-server-sentinel) (set-process-coding-system process 'utf-8-unix 'utf-8-unix) (message Starting nREPL server...))) That form has several calls, the first result is nil. The second result error's out with the message below. And this is where execution just dies and goes away - nil - *Symbol's value as variable is void: nrepl-server-command* I can see in nrepl.el where nrepl-server-command is defined. But I don't know enough about elisp to say what the problem is. Tim Washington Interruptsoftware.ca 416.843.9060 On Wed, Sep 19, 2012 at 3:31 PM, Tassilo Horn t...@gnu.org wrote: Timothy Washington twash...@gmail.com writes: Well after *M-x nrepl-jack-in*, I notice that the *Starting nREPL server... * message never goes away. But I don't *think* that's the main problem. I think, it is. Normally, after that message it takes ~10secs and then a *nrepl* buffer should pop up. If that doesn't happen for some reason, then there's something wrong. *1)* That help window looks like the following. So it doesn't look like the *nrepl-interaction-mode* is enabled on emacs startup. It's enabled automatically in all clojure buffers as soon as nrepl successfully started, which doesn't seem to happen for you. *2)* After executing the emacs command '*nrepl-interaction-mode*', I could then execute *C-x C-e*, but got the following message No buffer named *nrepl-connection* Yeah, this buffer is also created once nrepl has successfully started. *3)* So I went ahead and fired up *M-x nrepl*, and supplied the host and port. Again, the result message *Connecting to nREPL on localhost:57260...* never goes away (hopefully not the real problem). Hm, hm, why doesn't it want to connect... What you could do to debug the issue is open nrepl.el, goto the function definition of nrepl-jack-in, place point (the emacs cursor) on the function name, do `M-x edebug-defun RET', and then `M-x nrepl-jack-in RET'. Now you'll see an arrow in the margin indicating the flow of control. With `n' you can step one expression further, and the results are printed in the echo area. What are those values? Especially the result of `start-process-shell-command' might give a clue. Bye, Tassilo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Zipper over a heterogeneous tree
I actually got this problem sorted out. It's all outlined on
SOhttp://stackoverflow.com/questions/12501609/clojure-zipper-over-a-heterogeneous-tree,
or future reference.
Turns out I 1) didn't get the arity right when creating the
*make-node*function, when creating a zipper. I also 2) confused a
zipper's
*location* with it's *node* when traversing the tree.
Hope this helps.
Tim Washington
Interruptsoftware.ca
416.843.9060
On Wed, Sep 19, 2012 at 1:18 PM, Timothy Washington twash...@gmail.comwrote:
Hey all,
I'm having problems writing a zipper that can traverse a heterogeneous
tree of nodes. I have i) a list of maps. Each map has ii) an :inputs key,
whose value is a list of maps.
I want to use a zipper to visit each of those leaves and add a computed
value. The code block and input tree data are below. I can't seem to get
the zipper code to visit the leaf nodes, and add { :thing 123 }. I must be
missing something simple. Any insights?
A)
(loop [loc (zip/zipper (or map? list?)
#((if (map? %1) ;; get children of
a node
(:inputs %1)
%1 ))
#(%1);; create a new
node
(:input-layer neural-network)) ]
(if (zip/end? loc)
(zip/root loc)
(if (map? loc)
(recur (zip/next
(zip/edit loc merge { :thing 123 } )))
(recur (zip/next loc))
)
)
)
B)
({:inputs
({:key :avolume, :value 2.25, :weight 0.4283380545172636, :bias 0}
{:key :bvolume, :value 3.0, :weight 0.6970037374879661, :bias 0}
{:key :ask, :value 1.32379, :weight 0.5387437158323669, :bias 0}
{:key :bid, :value 1.3239, :weight 0.4648184032361037, :bias 0}
{:key :time, :value 1.335902400676, :weight 0.43632873607404554, :bias
0}),
:id 583c10bfdbd326ba34aed329139df6be2487ffc}
{:inputs
({:key :avolume, :value 2.25, :weight 0.13162215440222336, :bias 0}
{:key :bvolume, :value 3.0, :weight 0.23886901184352727, :bias 0}
{:key :ask, :value 1.32379, :weight 0.8408470512339872, :bias 0}
{:key :bid, :value 1.3239, :weight 0.27071013797961796, :bias 0}
{:key :time, :value 1.335902400676, :weight 0.6304505838898373, :bias
0}),
:id 583c10bfdbd326ba34aed329139df6be2487ffd}
{:inputs
({:key :avolume, :value 2.25, :weight 0.8236972641966921, :bias 0}
{:key :bvolume, :value 3.0, :weight 0.32421537754016705, :bias 0}
{:key :ask, :value 1.32379, :weight 0.966306328543246, :bias 0}
{:key :bid, :value 1.3239, :weight 0.8891668220470931, :bias 0}
{:key :time, :value 1.335902400676, :weight 0.278993745549462, :bias
0}),
:id 583c10bfdbd326ba34aed329139df6be2487ffe}
{:inputs
({:key :avolume, :value 2.25, :weight 0.27388486254027167, :bias 0}
{:key :bvolume, :value 3.0, :weight 0.33659579299487363, :bias 0}
{:key :ask, :value 1.32379, :weight 0.16610378593177033, :bias 0}
{:key :bid, :value 1.3239, :weight 0.6964784902474896, :bias 0}
{:key :time, :value 1.335902400676, :weight 0.6306732906337643, :bias
0}),
:id 583c10bfdbd326ba34aed329139df6be2487fff}
{:inputs
({:key :avolume, :value 2.25, :weight 0.8819171698935051, :bias 0}
{:key :bvolume, :value 3.0, :weight 0.5944805362120958, :bias 0}
{:key :ask, :value 1.32379, :weight 0.9060962647355373, :bias 0}
{:key :bid, :value 1.3239, :weight 0.37647418075176464, :bias 0}
{:key :time, :value 1.335902400676, :weight 0.7797681719480866, :bias
0}),
:id 583c10bfdbd326ba34aed329139df6be2488000})
Thanks
Tim Washington
Interruptsoftware.ca
416.843.9060
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
