Re: Project Better Clojure/Android integration
Talk to the people on this forum https://groups.google.com/forum/#!forum/clojure-android and see how you go. I am sure that they would welcome your participation. There was an talk at euroclojure by Alexander Yakushev: https://www.youtube.com/watch?v=mVXTcAEKgF8 Dave On Thursday, 23 July 2015 14:33:15 UTC+10, Devang Shah wrote: I know, it's over. Can I do it as a project outside of the GSoC? I believe it should not be a problem. Would it be? On Wednesday, July 22, 2015 at 9:14:30 PM UTC-7, Di Xu wrote: I believe student application for GSoC 2015 is already closed at March, you can only try it next year. 2015-07-23 11:12 GMT+08:00 Devang Shah devang...@gmail.com: Can anyone please help? On Saturday, July 18, 2015 at 8:33:58 PM UTC-7, Devang Shah wrote: Hello I am a master's student and would like to contribute to the clojure/android platform. I found this project http://dev.clojure.org/display/community/Project+Ideas#ProjectIdeas-BetterClojureAndroidintegration on the project ideas site for GSoC 2015. I was hoping to submit the project proposal, however could not submit the proposal. I was wondering, if I still take up the project, will anyone be able to mentor me (very little time, by answering my questions on google groups). I checked the GSoC 2015 website and this is not something that's done by any student for GSoC 15. I also would like to take this project as my master's project, if that's OK to do so. I know Clojure (decent), Android(pretty good), Leiningen(used it for Clojure programming) and Gradle (beginner). Can someone please help me getting started and also comment on this? Thank you. Devang -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Clarity Keyboard by SwiftKey - Written in Clojure
Very good news for clojure-android. Keen to hear more. Dave On Friday, 8 May 2015 21:18:50 UTC+10, Adam Clements wrote: Hi all, Just thought you might be interested to know that last week we (SwiftKey) released an Android app, written from the ground up in Clojure, which as of this morning has had 65k downloads. It's a keyboard we're using to test UI ideas which didn't fit well with the existing app. We also took the opportunity to try out a totally different tech stack, central to which are Clojure and core.async. There's a tech blog on the subject at my personal blog http://adamclements.github.io/articles/clarity-keyboard-uses-clojure/ which is reposted on SwiftKey's tech blog http://swiftkey.com/en/blog/what-makes-clarity-keyboard-tick-clojure/ and you can download the app and try it out from Google Play https://play.google.com/store/apps/details?id=com.swiftkey.clarity.keyboardreferrer=utm_source%3Dclojurelist%26utm_medium%3Dmailinglist Many thanks go to everyone who's worked on clojure and clojure-android for making this possible, it's been a dream to develop! I hope this goes to show that it's perfectly reasonable and possible to develop significant, responsive mobile applications in pure Clojure. I'd be interested to know your thoughts and comments, and if you're interested we are currently hiring here at SwiftKey, both for this project and in general. Thanks, Adam Clements -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Too many words written on referential transparency in Clojure and Haskell
yes - ok - I agree with that. I don't see this as a problem with the definition of equality. D On Thursday, 23 April 2015 00:40:20 UTC+10, Hannes Steffenhagen wrote: This. x = y = f(x) = f(y) obviously doesn't hold for arbitrary functions and arbitrary notions of equality (e.g. all sets that contain the same elements are equal, but the structures used to implement 'equal' sets need not be equal themselves). So if you then introduce a function that derives its result from the internal structure of the set - such as seq does - then you obviously break that property for your notion of 'set equality'. This doesn't mean the function isn't pure. It means your assumptions are wrong. If you want to guarantee a specific ordering then you have to use containers and/or algorithms that do actually guarantee a specific ordering. On Wednesday, April 22, 2015 at 9:53:47 AM UTC-4, Andy Fingerhut wrote: Dave, you say seq on a set cannot be pure unless you were to provide an argument to explicitly specify which order the items should be in. I think I would instead say: seq *is* a pure function, even though it violates the property of x equals y implies f(x) equals f(y). There is nothing impure about the definition of seq on sets. I would say that it is the way equals is defined on hash sets, intentionally ignoring internal implementation details that are visible to seq, that leads to the violation of that property. I have updated my article with a Conclusion section since yesterday. I have copied it below for those that have already read the article and want to see only the new stuff: In hindsight after writing this, it now seems clear to me that if one wants to maintain the property x is equal to y implies f(x) is equalThis. to f(y) for all functions f, then it is pretty important to be clear on what equal means. As a silly example, if one gets to define their own equals for lists, and you decide to define lists as equal if they contain the same number of items, e.g. the list (1 2 3) is equal to the list (4 5 6) because they both have 3 items, then you are easily going to violate the property. Example 3 highlights this point: one can create implementations of data structures using only pure functions, and a 'reasonable' definition of equality, where the property can be violated. The root of this issue is: sometimes reasonable definitions of equality regard two values as equal, intentionally ignoring internal implementation details of the data structure, but those differences ignored by equal can be made observable by other functions you implement on the data structure (like `seq` / `toList`). Andy On Wed, Apr 22, 2015 at 1:22 AM, Dave Sann dave...@gmail.com wrote: x is equal to y to imply f(x) is equal to f(y) - can only be true where a function is really based only on its arguments. I hadn't considered this before - while it seems simple, it is also a bit subtle. for example: seq on a set cannot be pure unless you were to provide an argument to explicitly specify which order the items should be in. If you do not do this, the order is defined either by some random interaction of the of the data and function implementations - that you thought was irrelevant - or has to be literally picked at random by the implementation. The former of these will appear to be pure until you hit the special cases. I speculate that only functions that retain or reduce the information content of their inputs can be pure. So if you rearrange or filter or map they can be pure. But if you *implicitly* add new information - as (seq set) does - then they cannot be. Dave On Wednesday, 22 April 2015 15:28:30 UTC+10, Andy Fingerhut wrote: One thing I was surprised by in my investigation was the lengths that some people are willing to go to in order to avoid such things. Some people seem to *really* want the property x is equal to y to imply f(x) is equal to f(y) for all functions, without exception, and consider it a bug if a single function violates that property. I'm personally on the side of violating it if there is no good way to keep it true for a particular function, preferably with documentation if you are aware that you are not preserving it. Andy On Tue, Apr 21, 2015 at 8:32 PM, Dave Sann dave...@gmail.com wrote: Just to expand on this slightly - seq applied to a set must introduce an order that is not present in the set. This order in principle comes from nowhere in the data. But it does in practice come from some arbitrary decisions in the implementation. Maybe this was andy's point. On Wednesday, 22 April 2015 13:18:43 UTC+10, Dave Sann wrote: Agree it's an interesting writeup. I think that the behaviour of seq should be entirely expected though. Sets have no ordering (logically) so turning them into an ordered sequence should be considered to be an entirely arbitrary operation (unless
Re: Too many words written on referential transparency in Clojure and Haskell
x is equal to y to imply f(x) is equal to f(y) - can only be true where a function is really based only on its arguments. I hadn't considered this before - while it seems simple, it is also a bit subtle. for example: seq on a set cannot be pure unless you were to provide an argument to explicitly specify which order the items should be in. If you do not do this, the order is defined either by some random interaction of the of the data and function implementations - that you thought was irrelevant - or has to be literally picked at random by the implementation. The former of these will appear to be pure until you hit the special cases. I speculate that only functions that retain or reduce the information content of their inputs can be pure. So if you rearrange or filter or map they can be pure. But if you *implicitly* add new information - as (seq set) does - then they cannot be. Dave On Wednesday, 22 April 2015 15:28:30 UTC+10, Andy Fingerhut wrote: One thing I was surprised by in my investigation was the lengths that some people are willing to go to in order to avoid such things. Some people seem to *really* want the property x is equal to y to imply f(x) is equal to f(y) for all functions, without exception, and consider it a bug if a single function violates that property. I'm personally on the side of violating it if there is no good way to keep it true for a particular function, preferably with documentation if you are aware that you are not preserving it. Andy On Tue, Apr 21, 2015 at 8:32 PM, Dave Sann dave...@gmail.com javascript: wrote: Just to expand on this slightly - seq applied to a set must introduce an order that is not present in the set. This order in principle comes from nowhere in the data. But it does in practice come from some arbitrary decisions in the implementation. Maybe this was andy's point. On Wednesday, 22 April 2015 13:18:43 UTC+10, Dave Sann wrote: Agree it's an interesting writeup. I think that the behaviour of seq should be entirely expected though. Sets have no ordering (logically) so turning them into an ordered sequence should be considered to be an entirely arbitrary operation (unless specific guarantees are provided). The fact that the implementations sometimes maintain an order should not be used or relied upon at all. a seq of a set is not itself a set and therefore is not subject to the same referential transparency rules as a set. Dave On Wednesday, 22 April 2015 12:39:42 UTC+10, Mike Rodriguez wrote: Thanks for sharing this. I found the write-up to be very informative and to have good background sources. I certainly never thought about this sneaky behavior concerning `seq` and hash sets before now. I'll have to look out for that one! On Tuesday, April 21, 2015 at 8:13:48 PM UTC-5, Andy Fingerhut wrote: I had come across the issue of Clojure hash sets that contain the same set of elements returning their elements in different orders from each other, depending upon which order they were added to the set (only if they have equal values for (hash x)). This and other questions on referential transparency on the Clojure group got me thinking on my commutes about it some more, and I dug into it way more than I expected to, and wrote up an article on it. If you think such a topic would interest you, you can read more about it here: https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/referential-transparency.md Guaranteed at least 99% epiphany free Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. 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
Re: Too many words written on referential transparency in Clojure and Haskell
one thought - (set (seq a-set)) is pure even is (seq a-set) is not - because (set a-seq) throws away the (random) order information that was added. Dave On Wednesday, 22 April 2015 19:03:23 UTC+10, Mark Derricutt wrote: On 22 Apr 2015, at 20:22, Dave Sann wrote: for example: seq on a set cannot be pure unless you were to provide an argument to explicitly specify which order the items should be in. If you do not do this, the order is defined either by some random interaction of the of the data and function implementations - that you thought was irrelevant - or has to be literally picked at random by the implementation. The former of these will appear to be pure until you hit the special cases. This is exactly one of the reasons a bunch of folk ( aka, purests maybe ) don't like that map/filter etc. in Clojure convert the input collection into seqs, unlike Haskell or others where the those monad laws keep you in check that map/filter return the *same* container - so mapping a set would yield another set - also with no guaranteed order, and also with uniqueness applied - so technically a map over a set may yield a collection of an equal or smaller size, but never greater. This seems to fuel a lot of debate when entered into - so I guess I'm asking for trouble in replies here :) Mark -- Mark Derricutt http://www.theoryinpractice.net http://www.chaliceofblood.net http://plus.google.com/+MarkDerricutt http://twitter.com/talios http://facebook.com/mderricutt -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Too many words written on referential transparency in Clojure and Haskell
Agree it's an interesting writeup. I think that the behaviour of seq should be entirely expected though. Sets have no ordering (logically) so turning them into an ordered sequence should be considered to be an entirely arbitrary operation (unless specific guarantees are provided). The fact that the implementations sometimes maintain an order should not be used or relied upon at all. a seq of a set is not itself a set and therefore is not subject to the same referential transparency rules as a set. Dave On Wednesday, 22 April 2015 12:39:42 UTC+10, Mike Rodriguez wrote: Thanks for sharing this. I found the write-up to be very informative and to have good background sources. I certainly never thought about this sneaky behavior concerning `seq` and hash sets before now. I'll have to look out for that one! On Tuesday, April 21, 2015 at 8:13:48 PM UTC-5, Andy Fingerhut wrote: I had come across the issue of Clojure hash sets that contain the same set of elements returning their elements in different orders from each other, depending upon which order they were added to the set (only if they have equal values for (hash x)). This and other questions on referential transparency on the Clojure group got me thinking on my commutes about it some more, and I dug into it way more than I expected to, and wrote up an article on it. If you think such a topic would interest you, you can read more about it here: https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/referential-transparency.md Guaranteed at least 99% epiphany free Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Too many words written on referential transparency in Clojure and Haskell
Just to expand on this slightly - seq applied to a set must introduce an order that is not present in the set. This order in principle comes from nowhere in the data. But it does in practice come from some arbitrary decisions in the implementation. Maybe this was andy's point. On Wednesday, 22 April 2015 13:18:43 UTC+10, Dave Sann wrote: Agree it's an interesting writeup. I think that the behaviour of seq should be entirely expected though. Sets have no ordering (logically) so turning them into an ordered sequence should be considered to be an entirely arbitrary operation (unless specific guarantees are provided). The fact that the implementations sometimes maintain an order should not be used or relied upon at all. a seq of a set is not itself a set and therefore is not subject to the same referential transparency rules as a set. Dave On Wednesday, 22 April 2015 12:39:42 UTC+10, Mike Rodriguez wrote: Thanks for sharing this. I found the write-up to be very informative and to have good background sources. I certainly never thought about this sneaky behavior concerning `seq` and hash sets before now. I'll have to look out for that one! On Tuesday, April 21, 2015 at 8:13:48 PM UTC-5, Andy Fingerhut wrote: I had come across the issue of Clojure hash sets that contain the same set of elements returning their elements in different orders from each other, depending upon which order they were added to the set (only if they have equal values for (hash x)). This and other questions on referential transparency on the Clojure group got me thinking on my commutes about it some more, and I dug into it way more than I expected to, and wrote up an article on it. If you think such a topic would interest you, you can read more about it here: https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/referential-transparency.md Guaranteed at least 99% epiphany free Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] lein-docker, lein-beandock
see also https://github.com/palletops/lein-uberimage On Wednesday, 8 April 2015 07:35:54 UTC+10, Allen Rohner wrote: https://github.com/arohner/lein-docker https://github.com/arohner/lein-beandock `lein-docker` is a simple plugin for performing `docker build` and `docker push`. lein-beandock is a semi-fork of `lein-beanstalk`, specializing in deploying docker containers to AWS Elastic Beanstalk. Thanks, Allen -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN][book] Clojure Reactive Programming
Not being politically correct is fine.
But an attack on anonymous stupid people in this context is pointless and
sours the otherwise potentially useful commentary. It also completely
derails the topic.
Comment on the objective aspects of the technology. If you have a personal
issue with someone or their decision, maybe it is better to take it up with
them. That way you might get an outcome. If you don't think you get that
then maybe it is better just to move on and forget about it (they probably
have).
You don't have to agree but it is better to be constructive.
Dave
On Thursday, 26 March 2015 04:12:43 UTC+11, Luc wrote:
I support your statement.
I am fed up by this extreme political correctness era.
This leads directly to auto censorship.
I met numerous 'anarchitects' who never had to bring an app from inception
to
real life use but nonetheless where issuing 'profound' statements about
the last buzz word they
read from the news stand.
With unnecessary software complexity comes huge teams, dilution of
responsibilities and
expertise, aside from the one picked up through some headlines.
This leads to a lack of accountability overall.
No one is responsible, 'we followed best practices/processes according to
{put your favorite methodology name here}'
I saw 'anarchitects' fly out before integrated or acceptance tests because
they had realize that the monster they helped created could not lift from
the ground.
Human induced complexity killed it well before it started to breathe.
A kind of Frankenstein aborted experiments.
After spending zillions of customer $ of course...
If it swims like a duck, squeaks like a duck, walks like a duck, well it's
a duck.
Not some kind of abstract apparatus.
Nothing forces people to buy/listen to a book/news report/tv show/... if
they find it rude
or inappropriate to their taste.
They just have to zap like most of them are doing over any serious
thinking about
how they work, what's the purpose of it and what responsibilities comes
with it.
It's already a miracle that some people are actually saying publicly what
they really think,
let's not try to cut their wings...
Pleasing the majority is the path to mediocrity.
Luc P.
Trust me I have been using Scala + Akka + Play for past three years in
production, and had to deal with tons of incidental complexity plus a
lot
of noise they introduce as my daily job (in my code as well as other
developer's code). Now I am in the best position to judge and compare
them
with Clojure code that does similar job but ten times simpler (and I
don't
only mean 10 time less verbose).
I am sorry but I need to confess that within past 15 years that I have
been
working with numerous architects most of them choose technologies only
based on 1/2 hour googling or reading reviews (and I don't mean all
architects are like this). In particular the one I rightly called
ignorant
did not even write a simple poc to use AKKA and java8 to see how code
looks
like.
By pathetic technology (and I didn't mean java8) I mean a technology
that
you need to fish out less than 10 lines of business logic from 50 or
more
lines of noise introduced by Scala futures (in AKKA), Play promise
redeems,
matching classes (case classes in Scala)...
Remember when first time Spring was introduced, the original goal was to
take out all the noise and put them in XML file so the developer remain
focused on business logic. Here we are 10 or so years later: lots of
noise
and complexity added to the code to do orchestration. This is work of
intelligent fool... (look at Erlang which AKKA tried to copy, it does a
powerful orchestration without introducing much complexity, this is
touch
of genius)
These are the pain points in our field. I have deeply felt it and try to
point out that the life does not need to be that hard.
Clojure is the first real try in opposite direction (touch of genius)
Thanks a lot
Best regards
Shahrdad
On Wed, Mar 25, 2015 at 8:06 AM, Colin Yates colin...@gmail.com
javascript: wrote:
No - he is right, we just don't say it! Obviously I am kidding :).
On 25 March 2015 at 11:51, Hildeberto Mendonça m...@hildeberto.com
javascript: wrote:
On Wed, Mar 25, 2015 at 12:14 PM, Colin Yates colin...@gmail.com
javascript:
wrote:
Hi Shahrdad, just a point of etiquette, inferring that an architect
is
ignorant because they chose Java8, Akka and play is full of
assumptions.
Calling those technologies pathetic is very bad poor.
As I like to quote Any intelligent fool can make things bigger and
more
complex... It takes rude manners, assumptions and a whole bunch of
numptiness to claim 'bigger and more complex' means the author is a
fool.
That's why I love this community. Mutual
Re: [ANN] Dunaj project, an alternative core API for Clojure
very interesting work and well presented, keep going. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Buddy 0.4.0: Security library for clojure.
buddy-auth vs friend? What is the difference/motivation? On Monday, 23 February 2015 06:32:22 UTC+11, g vim wrote: On 22/02/2015 11:36, Andrey Antukh wrote: Documentation: https://funcool.github.io/buddy-core/latest/ https://funcool.github.io/buddy-auth/latest/ https://funcool.github.io/buddy-hashers/latest/ https://funcool.github.io/buddy-sign/latest/ Great addition to Clojure web development security. For new users might I suggest adding a namespace table to -core, -hashers and -sign as with -auth? gvim -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] tools.analyzer[.jvm] 0.6.0 release, pass scheduler
Hi Nicola, why do you pass a set of vars to schedule rather than a set of functions? I'm just interested. It's unusual to see #' Dave On Friday, 19 September 2014 05:07:08 UTC+10, Nicola Mometto wrote: Today I released version 0.6.0 of the tools.analyzer[1] and tools.analyzer.jvm[2] contrib libraries. With this release comes a new feature I'm really excited about and that I believe will help users of this library significantly: a pass scheduler. Previous to this release, tools.analyzer passes had to be combined manually, requiring deep knowledge of the implementation of those passes, whose dependencies were not explicit. That usually resulted in users copy-pasting the tools.analyzer.jvm run-passes function using that as a template. With the new scheduler, all of this is no longer necessary as all it takes care of automatically pulling in dependencies and composing the passes in the required and most efficient order, composing together passes whenever possible, to minimize the overhead of a full tree traversal. To get a sense of how that has improved, here's run-passes from 0.5.6: https://github.com/clojure/tools.analyzer.jvm/blob/be55b4e32371060932ac8d4094eb5b1b77fe4349/src/main/clojure/clojure/tools/analyzer/jvm.clj#L430-L477 and here it is from 0.6.0, using the pass scheduler: https://github.com/clojure/tools.analyzer.jvm/blob/1757871eb828c419f8de1cf177f125897f653829/src/main/clojure/clojure/tools/analyzer/jvm.clj#L397-L427 Exposing the default-passes set, users who want to add a pass to the default passes run by t.a.jvm need only to bind run-passes to `(schedule (conj default-passes #'my-pass))`, or dissoc a default pass if not needed. To get started with the pass scheduler, here's its extensive docstring: https://github.com/clojure/tools.analyzer/blob/7a8cba9b26689675debdaabc83f20e485003bf5a/src/main/clojure/clojure/tools/analyzer/passes.clj#L137-L168 and here is a comprehensive example of a pass configuration via :pass-info: https://github.com/clojure/tools.analyzer.jvm/blob/1757871eb828c419f8de1cf177f125897f653829/src/main/clojure/clojure/tools/analyzer/passes/jvm/validate_loop_locals.clj#L150 Nicola [1]https://github.com/clojure/tools.analyzer [2]https://github.com/clojure/tools.analyzer.jvm -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] tools.analyzer[.jvm] 0.6.0 release, pass scheduler
thanks On Friday, 19 September 2014 23:08:35 UTC+10, Nicola Mometto wrote: The :pass-info metadata needed to resolve the pass dependency order is attached to the Vars, not to the functions. Even though we could attach that meta to the functions rather than to the Vars, leaving aside that it would be less pleasant, multimethods can't have metadata attached as they are not AFunctions so that would require wrapping each pass in a fn even when unnecessary. Given all this, using a set of Vars is perfectly reasonable. Nicola Dave Sann writes: Hi Nicola, why do you pass a set of vars to schedule rather than a set of functions? I'm just interested. It's unusual to see #' Dave On Friday, 19 September 2014 05:07:08 UTC+10, Nicola Mometto wrote: Today I released version 0.6.0 of the tools.analyzer[1] and tools.analyzer.jvm[2] contrib libraries. With this release comes a new feature I'm really excited about and that I believe will help users of this library significantly: a pass scheduler. Previous to this release, tools.analyzer passes had to be combined manually, requiring deep knowledge of the implementation of those passes, whose dependencies were not explicit. That usually resulted in users copy-pasting the tools.analyzer.jvm run-passes function using that as a template. With the new scheduler, all of this is no longer necessary as all it takes care of automatically pulling in dependencies and composing the passes in the required and most efficient order, composing together passes whenever possible, to minimize the overhead of a full tree traversal. To get a sense of how that has improved, here's run-passes from 0.5.6: https://github.com/clojure/tools.analyzer.jvm/blob/be55b4e32371060932ac8d4094eb5b1b77fe4349/src/main/clojure/clojure/tools/analyzer/jvm.clj#L430-L477 and here it is from 0.6.0, using the pass scheduler: https://github.com/clojure/tools.analyzer.jvm/blob/1757871eb828c419f8de1cf177f125897f653829/src/main/clojure/clojure/tools/analyzer/jvm.clj#L397-L427 Exposing the default-passes set, users who want to add a pass to the default passes run by t.a.jvm need only to bind run-passes to `(schedule (conj default-passes #'my-pass))`, or dissoc a default pass if not needed. To get started with the pass scheduler, here's its extensive docstring: https://github.com/clojure/tools.analyzer/blob/7a8cba9b26689675debdaabc83f20e485003bf5a/src/main/clojure/clojure/tools/analyzer/passes.clj#L137-L168 and here is a comprehensive example of a pass configuration via :pass-info: https://github.com/clojure/tools.analyzer.jvm/blob/1757871eb828c419f8de1cf177f125897f653829/src/main/clojure/clojure/tools/analyzer/passes/jvm/validate_loop_locals.clj#L150 Nicola [1]https://github.com/clojure/tools.analyzer [2]https://github.com/clojure/tools.analyzer.jvm -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: ANN: Potemkin 0.3.0
to answer my own question. It does not play well. I created a couple of simple macros that mimics the import-vars behaviour for fns and vars in clojurescript. On Sunday, 14 September 2014 17:53:47 UTC+10, Dave Sann wrote: Does Potemkin work well with clojurescript? I have seen some discussion of issues in some places. Is there anywhere that notes challenges? I am particularly interested with the import-vars scenario (defining namespaces separately and then merging definitions into one namespace for usage). Dave On Thursday, 20 June 2013 13:38:32 UTC+10, Jason Wolfe wrote: We're starting to use potemkin at Prismatic, and the part we've found most useful which Zach didn't mention in his post are the smart types. Especially definterface+, which is like a love child of defprotocol and definterface: - Same syntax as defprotocol, and defines functions in your namespace that wrap the interface functions (without extend-protocol support, obviously) - Allows for primitive arguments and return values (like clojure.core/definterface), which are propagated to the wrapper functions for maximal performance - Doesn't re-evaluate if the body has not changed, which can make repl development less painful (especially when used with its defrecord+ counterpart). On Wednesday, June 19, 2013 12:12:41 PM UTC-7, Zach Tellman wrote: Potemkin [1] is a collection of facades and utilities that I've found helpful when writing larger-scale libraries or applications. I've never formally announced it before, but I think it's gotten to the point where others can benefit from it. A few highlights: * 'def-map-type', which allows for the definition of custom map-like objects with 10x less code * 'unify-gensyms', which allows for more concise nested syntax-quotes * 'import-vars', which allows for code sprinkled across multiple namespaces to be exposed via a single namespace It's been pointed out before that ideally a library should have no dependencies but Clojure itself, or we risk transitive dependency conflicts when everyone uses different versions of a utility library. In deference to this, Potemkin is licensed such that any piece of code can be simply pasted into your library, as long as there's a comment describing the origin. If anyone has questions, I'm happy to answer them. If anyone has moral or aesthetic objections to 'import-vars', you're not alone, but please remember you're under no obligation to use it. Zach [1] https://github.com/ztellman/potemkin -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: ANN: Potemkin 0.3.0
Does Potemkin work well with clojurescript? I have seen some discussion of issues in some places. Is there anywhere that notes challenges? I am particularly interested with the import-vars scenario (defining namespaces separately and then merging definitions into one namespace for usage). Dave On Thursday, 20 June 2013 13:38:32 UTC+10, Jason Wolfe wrote: We're starting to use potemkin at Prismatic, and the part we've found most useful which Zach didn't mention in his post are the smart types. Especially definterface+, which is like a love child of defprotocol and definterface: - Same syntax as defprotocol, and defines functions in your namespace that wrap the interface functions (without extend-protocol support, obviously) - Allows for primitive arguments and return values (like clojure.core/definterface), which are propagated to the wrapper functions for maximal performance - Doesn't re-evaluate if the body has not changed, which can make repl development less painful (especially when used with its defrecord+ counterpart). On Wednesday, June 19, 2013 12:12:41 PM UTC-7, Zach Tellman wrote: Potemkin [1] is a collection of facades and utilities that I've found helpful when writing larger-scale libraries or applications. I've never formally announced it before, but I think it's gotten to the point where others can benefit from it. A few highlights: * 'def-map-type', which allows for the definition of custom map-like objects with 10x less code * 'unify-gensyms', which allows for more concise nested syntax-quotes * 'import-vars', which allows for code sprinkled across multiple namespaces to be exposed via a single namespace It's been pointed out before that ideally a library should have no dependencies but Clojure itself, or we risk transitive dependency conflicts when everyone uses different versions of a utility library. In deference to this, Potemkin is licensed such that any piece of code can be simply pasted into your library, as long as there's a comment describing the origin. If anyone has questions, I'm happy to answer them. If anyone has moral or aesthetic objections to 'import-vars', you're not alone, but please remember you're under no obligation to use it. Zach [1] https://github.com/ztellman/potemkin -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] 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: [ANN] aprint (awesome print) released
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.
how do you name your protocols?
I saw a comment on protocol naming here: https://groups.google.com/d/msg/clojure/A4xIitQWloU/6E4xHDTPPaIJ there is nothing in the coding standards: http://dev.clojure.org/display/community/Library+Coding+Standards (are these maintained?) is there any sensible consensus on good naming convention? IBlah PBlah BlahP Blah ...other ...doesn't matter Dave -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Leiningen 2.3.4 released
https://github.com/technomancy/leiningen/issues/1652 On Sunday, 24 August 2014 18:50:36 UTC+10, Robin Heggelund Hansen wrote: Same here =( kl. 03:27:50 UTC+2 søndag 24. august 2014 skrev Dave Sann følgende: Do exclusions apply to plugins? if I have :plugins [[com.keminglabs/cljx 0.4.0 :exclusions [org.clojure/clojure]]] I get ([com.keminglabs/cljx 0.4.0] - [org.clojars.trptcolin/sjacket 0.1.0.6] - [org.clojure/clojure [1.3.0,)] Consider using [com.keminglabs/cljx 0.4.0 :exclusions [org.clojure/clojure]].) ([com.keminglabs/cljx 0.4.0] - [org.clojars.trptcolin/sjacket 0.1.0.6] - [net.cgrand/regex 1.1.0] - [org.clojure/clojure [1.2.0,)] Consider using [com.keminglabs/cljx 0.4.0 :exclusions [org.clojure/clojure]].) ([com.keminglabs/cljx 0.4.0] - [org.clojars.trptcolin/sjacket 0.1.0.6] - [net.cgrand/parsley 0.9.1] - [org.clojure/clojure [1.2.0,)] Consider using [com.keminglabs/cljx 0.4.0 :exclusions [org.clojure/clojure]].) ([com.keminglabs/cljx 0.4.0] - [org.clojars.trptcolin/sjacket 0.1.0.6] - [net.cgrand/parsley 0.9.1] - [net.cgrand/regex 1.1.0] - [org.clojure/clojure [1.2.0,)] Consider using [com.keminglabs/cljx 0.4.0 :exclusions [org.clojure/clojure]].) If it's a dependency, I don get the errors. Dave On Wednesday, 20 November 2013 05:41:07 UTC+11, Phil Hagelberg wrote: Hello folks. I'm happy to announce the release of Leiningen 2.3.4. This one is primarily a bugfix release; though there are a few minor enhancements. ## 2.3.4 / 2013-11-18 * Suggest `:exclusions` to possibly confusing `:pedantic?` dependencies. (Nelson Morris, Phil Hagelberg) * Optionally look for snapshot templates in `new` task. (Travis Vachon) * Allow task chains to be declared without commas in project.clj. (Jean Niklas L'orange) * Support extra configurability in `:pom-plugins`. (Dominik Dziedzic) * Fix a bug where implicit :aot warning triggered incorrectly. (Jean Niklas L'orange) * Fix a bug where `lein repl connect` ignored port argument. (Toby Crawley) This brings all the functionality of the deprecated lein-pedantic plugin into Leiningen itself. The snapshot template functionality allows template developers to test their changes more easily, and the support for improved task chaining allows us to express higher-order task invocations in project.clj in a properly nested way without resorting to commas, which are a hack to work around shell arguments' lack of structuring. As usual, running `lein upgrade` will pull in the latest stable release, and if you run into any issues you can always run `lein downgrade 2.3.3` to go back to the previous release. Please report any issues on the Leiningen mailing list or the GitHub issue tracker. Thanks to all the contributors and users who helped us get to this release. -Phil -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Leiningen 2.3.4 released
Do exclusions apply to plugins? if I have :plugins [[com.keminglabs/cljx 0.4.0 :exclusions [org.clojure/clojure]]] I get ([com.keminglabs/cljx 0.4.0] - [org.clojars.trptcolin/sjacket 0.1.0.6] - [org.clojure/clojure [1.3.0,)] Consider using [com.keminglabs/cljx 0.4.0 :exclusions [org.clojure/clojure]].) ([com.keminglabs/cljx 0.4.0] - [org.clojars.trptcolin/sjacket 0.1.0.6] - [net.cgrand/regex 1.1.0] - [org.clojure/clojure [1.2.0,)] Consider using [com.keminglabs/cljx 0.4.0 :exclusions [org.clojure/clojure]].) ([com.keminglabs/cljx 0.4.0] - [org.clojars.trptcolin/sjacket 0.1.0.6] - [net.cgrand/parsley 0.9.1] - [org.clojure/clojure [1.2.0,)] Consider using [com.keminglabs/cljx 0.4.0 :exclusions [org.clojure/clojure]].) ([com.keminglabs/cljx 0.4.0] - [org.clojars.trptcolin/sjacket 0.1.0.6] - [net.cgrand/parsley 0.9.1] - [net.cgrand/regex 1.1.0] - [org.clojure/clojure [1.2.0,)] Consider using [com.keminglabs/cljx 0.4.0 :exclusions [org.clojure/clojure]].) If it's a dependency, I don get the errors. Dave On Wednesday, 20 November 2013 05:41:07 UTC+11, Phil Hagelberg wrote: Hello folks. I'm happy to announce the release of Leiningen 2.3.4. This one is primarily a bugfix release; though there are a few minor enhancements. ## 2.3.4 / 2013-11-18 * Suggest `:exclusions` to possibly confusing `:pedantic?` dependencies. (Nelson Morris, Phil Hagelberg) * Optionally look for snapshot templates in `new` task. (Travis Vachon) * Allow task chains to be declared without commas in project.clj. (Jean Niklas L'orange) * Support extra configurability in `:pom-plugins`. (Dominik Dziedzic) * Fix a bug where implicit :aot warning triggered incorrectly. (Jean Niklas L'orange) * Fix a bug where `lein repl connect` ignored port argument. (Toby Crawley) This brings all the functionality of the deprecated lein-pedantic plugin into Leiningen itself. The snapshot template functionality allows template developers to test their changes more easily, and the support for improved task chaining allows us to express higher-order task invocations in project.clj in a properly nested way without resorting to commas, which are a hack to work around shell arguments' lack of structuring. As usual, running `lein upgrade` will pull in the latest stable release, and if you run into any issues you can always run `lein downgrade 2.3.3` to go back to the previous release. Please report any issues on the Leiningen mailing list or the GitHub issue tracker. Thanks to all the contributors and users who helped us get to this release. -Phil -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] lein-templater - automagically generate templates from your existing projects
Interesting Idea. I'll give it a go. On Wednesday, 20 August 2014 06:47:47 UTC+10, Dylan Butman wrote: I've been writing a lot of templates lately for various web stacks and whatnot, and I got really tired of having to copy my files into a template every time they changes. I figured it wouldn't be too hard to generate them programmatically, and after a few more days than expected, here you have it. Introducing lein-templater - https://github.com/pleasetrythisathome/lein-templater It generates templates for you! It has options! Feedback appreciated. I'm sure there are some kinks to iron out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: clojurescript: modifying function definitions
I have done this sort of this with with-redefs to look at the input and output of functions inside a library I was using. http://clojuredocs.org/clojure_core/clojure.core/with-redefs I may have a small macro to assist. I can post later if you wish. You need to be careful of binding boundaries though - so its not ideal in all situations (i.e later lazy evaluations). Dave On Wednesday, 14 May 2014 00:09:22 UTC+10, t x wrote: Suppose we had the following: (defn stupid-wrapper [f args] (. js/console log args) (let [ans (f args)] (. js/console log ans) ans)) It basically logs the arguments + return value on every function call. Now, suppose I wanted to do this to _functions that already existed_ . Is there a way to do this? I.e. someone already wrote: (defn foo [ ... ] ... ) now, I want to do : (black-magic! foo) ;; and have this wrap the foo function. Is there a way to make this work? Thnaks! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure RETE implementation - CLIPS-like expert system shell. New version 4.3
this code (and the related create) is unusual: (defn reset [] Reset: clear and initialize all memories (def =AMEM= (object-array @ACNT)) (def =BMEM= (object-array =BCNT=)) (def =FMEM= (create-fmem =TEMPL=)) (def =FMMB= (create-fmem =TEMPL=)) (def =FIDS= (HashMap.)) (def CFSET (atom nil)) (def FCNT (atom 0))) It implies that you can only have one set of rules/engine in any usage of the library. Even if you plan to use mutable data - this seems to create additional restrictions. Why not put all of these into a map and pass that around as the ruleset/engine state? On Tuesday, 13 May 2014 23:32:49 UTC+10, ru wrote: Alan. You absolutely right! Clojure must return thinking of programmers back to solving problems from vanity and narcissism of unnecessary complexity :) I certainly will look on Clara more attentively and may be switch to it in my applications. cheers, Ru понедельник, 12 мая 2014 г., 17:47:44 UTC+4 пользователь ru написал: New feature: added Java interface. Eclipse project example. Home: https://github.com/rururu/rete4frames Have fun! Sincerely, Ru -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Puppet Labs and Trapperkeeper
related http://puppetlabs.com/blog/new-era-application-services-puppet-labs On Monday, 14 April 2014 00:24:28 UTC+10, Brendan Younger wrote: I just saw that there's a library called TrapperKeeper https://github.com/puppetlabs/trapperkeeper from the folks at Puppet Labs. It looks to be a more opinionated and complete version of Stuart Sierra's Component library https://github.com/stuartsierra/component, in that it explicitly pays attention to things like logging configuration and JBoss support. Brendan Younger -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Zengarden. A Clojure library for generating CSS
ok, I understand now. thx D On Friday, 11 April 2014 12:16:02 UTC+10, frye wrote: I actually did take Joel up on his offer. But my feature requests are on the back burner for the moment. I happen to be building a product, that needs what Zengarden provides. Mainly authoring gnarly things like @import, @media queries, pseudo classes, etc, *declaratively, from edn*. That was the main impetus for this tool. I tried, and couldn't get that working with garden. You have to drop down to a repl to generate @import and @media queries. So while I personally need these things, I'm also happy to fold those features, back into garden. I'd actually prefer that, so we can have all of these features in one place. Tim Washington Interruptsoftware.com http://interruptsoftware.com On Thu, Apr 10, 2014 at 9:09 PM, Dave Sann dave...@gmail.comjavascript: wrote: what is different from what Joel already did? I think Joel was asking for input to help develop garden further it would be great to see efforts go into one thing - unless you have really divergent ideas Dave On Friday, 11 April 2014 01:07:47 UTC+10, frye wrote: Zengarden is a riff on Joel Holdbrooks' excellent gardenhttps://github.com/noprompt/gardenlibrary. Zengarden is a simple tool for generating CSS in Clojure. The goal is to cover most of CSS3https://developer.mozilla.org/en-US/docs/Web/CSS/CSS3. The spirit of the library is to have declarative syntax, and be controllable from edn. Github https://github.com/twashing/zengarden and Clojars https://clojars.org/zengarden resources are in the expected locations. This is an alpha release, so there's a lot of TODOs, and stuff that I haven't thought of. I've just built it for my own use case(s). When that happens, you can *i)* input raw CSS *ii)* send me feature requests or *iii)* send me a pull request. These are some things you get out of the box. - nesting syntax - declarative, controllable from edn - @import https://developer.mozilla.org/en-US/docs/Web/CSS/@import calls - @media https://developer.mozilla.org/en-US/docs/Web/CSS/@media queries - namespaceshttps://developer.mozilla.org/en-US/docs/Web/CSS/@namespace - pass in raw CSS I'm in the process of doing these other things. Pass in raw CSS, in lieu of. - pretty-printed or compressed output - inlined styling (for style attributes) - selectors (incl. *i.* attribute selectorshttp://dev.w3.org/csswg/selectors3/#attribute-selectors(ex: div[foo^=bar]) *ii.* combinators http://dev.w3.org/csswg/selectors3/#combinators *iii.* parent selectors ) - pseudo-elements (incl. pseudo-element functions (ex: div:lang(fr))) - @charsethttps://developer.mozilla.org/en-US/docs/Web/CSS/@charset, @supportshttps://developer.mozilla.org/en-US/docs/Web/CSS/@supports, ( @page https://developer.mozilla.org/en-US/docs/Web/CSS/@page, @documenthttps://developer.mozilla.org/en-US/docs/Web/CSS/@document, @font-facehttps://developer.mozilla.org/en-US/docs/Web/CSS/@font-faceand @keyframeshttps://developer.mozilla.org/en-US/docs/Web/CSS/@keyframes, not implemented; most are still experimental ) Please note that. - Zengarden makes no attempt to validate your CSS. it just knows how to handle a string pattern - Ensure to escape all quotations in a string - CSS Object Model http://dev.w3.org/csswg/cssom/ (ex: CSSImportRulehttp://dev.w3.org/csswg/cssom/#the-cssimportrule-interface, CSSMediaRulehttp://dev.w3.org/csswg/cssom/#the-cssmediarule-interface) is not implemented. I'll wait until the need arises. These are some scss http://sass-lang.com/ features that look interesting. - variables - partials - mixins - operators - inheritance But as we are in Clojure, I don't want to pull in sass idioms wholesale. So I think garden has the right idea in that respect. - garden declarations - garden units - garden color - garden arithmetic I'll wait for the need to arise, before wasting too much time or energy in any direction. Feedback is welcome. Tim Washington Interruptsoftware.com http://interruptsoftware.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Zengarden. A Clojure library for generating CSS
what is different from what Joel already did? I think Joel was asking for input to help develop garden further it would be great to see efforts go into one thing - unless you have really divergent ideas Dave On Friday, 11 April 2014 01:07:47 UTC+10, frye wrote: Zengarden is a riff on Joel Holdbrooks' excellent gardenhttps://github.com/noprompt/gardenlibrary. Zengarden is a simple tool for generating CSS in Clojure. The goal is to cover most of CSS3https://developer.mozilla.org/en-US/docs/Web/CSS/CSS3. The spirit of the library is to have declarative syntax, and be controllable from edn. Github https://github.com/twashing/zengarden and Clojars https://clojars.org/zengarden resources are in the expected locations. This is an alpha release, so there's a lot of TODOs, and stuff that I haven't thought of. I've just built it for my own use case(s). When that happens, you can *i)* input raw CSS *ii)* send me feature requests or *iii)* send me a pull request. These are some things you get out of the box. - nesting syntax - declarative, controllable from edn - @import https://developer.mozilla.org/en-US/docs/Web/CSS/@import calls - @media https://developer.mozilla.org/en-US/docs/Web/CSS/@media queries - namespaceshttps://developer.mozilla.org/en-US/docs/Web/CSS/@namespace - pass in raw CSS I'm in the process of doing these other things. Pass in raw CSS, in lieu of. - pretty-printed or compressed output - inlined styling (for style attributes) - selectors (incl. *i.* attribute selectorshttp://dev.w3.org/csswg/selectors3/#attribute-selectors(ex: div[foo^=bar]) *ii.* combinators http://dev.w3.org/csswg/selectors3/#combinators *iii.* parent selectors ) - pseudo-elements (incl. pseudo-element functions (ex: div:lang(fr))) - @charset https://developer.mozilla.org/en-US/docs/Web/CSS/@charset, @supports https://developer.mozilla.org/en-US/docs/Web/CSS/@supports, ( @page https://developer.mozilla.org/en-US/docs/Web/CSS/@page, @document https://developer.mozilla.org/en-US/docs/Web/CSS/@document, @font-facehttps://developer.mozilla.org/en-US/docs/Web/CSS/@font-faceand @keyframeshttps://developer.mozilla.org/en-US/docs/Web/CSS/@keyframes, not implemented; most are still experimental ) Please note that. - Zengarden makes no attempt to validate your CSS. it just knows how to handle a string pattern - Ensure to escape all quotations in a string - CSS Object Model http://dev.w3.org/csswg/cssom/ (ex: CSSImportRulehttp://dev.w3.org/csswg/cssom/#the-cssimportrule-interface, CSSMediaRulehttp://dev.w3.org/csswg/cssom/#the-cssmediarule-interface) is not implemented. I'll wait until the need arises. These are some scss http://sass-lang.com/ features that look interesting. - variables - partials - mixins - operators - inheritance But as we are in Clojure, I don't want to pull in sass idioms wholesale. So I think garden has the right idea in that respect. - garden declarations - garden units - garden color - garden arithmetic I'll wait for the need to arise, before wasting too much time or energy in any direction. Feedback is welcome. Tim Washington Interruptsoftware.com http://interruptsoftware.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
A thought on Om/React
I haven't built anything with OM or react as yet. But I have read about it and I like the model in principle. A thought which repeatedly pops into my mind when I read about this is - ok, react in written in js. which is great for the web. What would happen if it were written in Clojure and available on server (As well as client (I am not thinking nodejs here). Going on slightly, it might be possible to 1. have a generally useful delta calculation - for this sort of use. 2. have a DOM structure and event model that could be mapped/bridged to swing or javafx or other. 3. have different UI models other than DOM that could be mapped to DOM or swing of javafx or other. I have no plans to do anything with this currently - but am interested in peoples thoughts. Dave -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: rant / cljs in cljs ? :-)
or livejs
http://livejs.com/
On Sunday, 6 April 2014 04:58:51 UTC+10, Henrik Eneroth wrote:
If that is your criterion, use something that reloads the browser
automatically when the js is changed. I use CodeKit personally.
On Wednesday, April 2, 2014 10:09:45 PM UTC+2, lypanov wrote:
I hate REPLs. I also hate large compile times.
For me the hardest part of the ~5s compile time is not waiting, it's the
watching of the progress of the auto build and waiting until exactly that
moment
before pressing reload in the browser.
That being said, I find run this currently selected code block in my
connected browser functionality in editors (lighttable is the one I
use/know) to be
the best solution to this problem. It's painful as hell at first though.
I had a work around in the past via a fork of noir-cljs which would delay
the load of the .js files until compile completed via some hacks but
now that I've switched to a browser editor work flow I find myself
doing as much work as possible in the editor via the run it in the browser
REPL
script tag trick from lighttable that I'm no longer even noticing
compile times. I leave them to the end of the pomodoro.
On Friday, March 21, 2014 7:48:59 AM UTC+1, t x wrote:
Hi,
* I'm already using:
:incremental true
:compiler { :optimizations :none }
* I'm also aware of cljs brepl
However:
1) the cljs compiler is still too slow for my liking (even though it's
not calling closure)
2) I don't like the cljs repl nearly as much as I like the clj repl
Now, my dumb/stupid question:
Is there any cljs in cljs _slow_ interpreter? I'm perfectly happy
with an interpreter that runs 10x slower, if, in exchange, I get to
hit refresh and my new code starts running.
Furthermore, I'm _okay_ with their being a big delay every time I
introduce a new macro from clj land.
I realize this sounds spoiled -- but -- the cljs compiler delays are
really really breaking my flow.
Thanks!
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
namespace dependency
Assuming a set of directories/classpath, is there a simple way to determine the set of namespaces that are dependent on another namespace? in this case, by dependent I mean (for example): A refers B B refers C D dependents of B are A dependents of C are B and A dependents of D are B and A dependents of A are nothing. I had a look at tools.namespace but I didn't see an easy way to do this. Maybe I missed it. Thanks Dave -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: namespace dependency
thanks, that got me on the right track. it turns out that clojure.tools.namespace.dir/scan can do this. The reason I couldn't see the dependencies I was looking for was because I had managed to write (ns .. (require ...)) instead of (ns ... (:require ...)) in the files I was looking at. This caused the declaration parsing to miss the referred namespaces. Cheers Dave On Saturday, 22 March 2014 01:11:53 UTC+11, cjeris wrote: You might take a look at Tim McCormack's Nephila visualizer: https://github.com/timmc/nephila On Fri, Mar 21, 2014 at 6:33 AM, Dave Sann dave...@gmail.comjavascript: wrote: Assuming a set of directories/classpath, is there a simple way to determine the set of namespaces that are dependent on another namespace? in this case, by dependent I mean (for example): A refers B B refers C D dependents of B are A dependents of C are B and A dependents of D are B and A dependents of A are nothing. I had a look at tools.namespace but I didn't see an easy way to do this. Maybe I missed it. Thanks Dave -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- Chris Jeris cje...@brightcove.com javascript: freenode/twitter/github: ystael -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: ace / codemirror in cljs
have you considered reading the LightTable code? There is probably some cljs and editor in there On Saturday, 1 March 2014 17:26:18 UTC+11, t x wrote: Hi, Is there anything like http://codemirror.net/ or http://ace.c9.io/#nav=about in cljs ? The goal is not to use codemirror/ace in a cljs project. The goal is to read some interesting cljs code on how to write an editor. Thanks! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Some advice about introducing clojurescript into a project using js/jquery
It works pretty seamlessly. You will need to include a jquery externs file to avoid munging of function call names by the google closure compiler in advanced mode. See also https://github.com/ibdknox/jayq Which adds a few simplifications to usage (particularly some protocols for jQuery objects acting as sequences). There may be others out there too. if you plan to create elements on the client, you may want to use a hiccup style render, they are very effective and hiccup data is very amenable to composition. I use https://github.com/prismatic/dommy. but there are others too. Dave On Monday, 17 February 2014 01:47:18 UTC+11, Kashyap CK wrote: Hi, It took me some time to get started with clojurescript (on windows/cygwin) - http://swannodette.github.io/2013/11/07/clojurescript-101/ worked for me. I'd like to use clojurescript to do some UI component development for product which is built using webkit/js/jquery. I was wondering if it is okay to develop a feature in such an application, where most of the UI is in jquery, in clojurescript? I'd appreciate it very much to know if there are any known gotha's here or any tips that I could use? Regards, Kashyap -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] garden-watch
FYI, I think lein garden does this already. is there a particular difference? On Wednesday, 5 February 2014 13:03:55 UTC+11, frye wrote: *garden-watch* https://github.com/twashing/garden-watch is very similar to hiccup-watch https://github.com/twashing/hiccup-watch (previous annhttps://groups.google.com/forum/#!topic/clojure/7nglz0yz-9Q). But this time, we're compiling down to CSS, using the Gardenhttps://github.com/noprompt/gardenlibrary. Again, this is just a leiningen watcher plugin that monitors for changes in your Garden source files. And again, this is new software. So feel free to use, modify and make suggestions and / or pull requests. Treat this tool the same way you would treat guard-sass https://github.com/hawx/guard-sass. I like to serve up just raw HTML files and templates. So both these tools fit nicely into my toolbox. - [garden-watch 0.1.1] - Github https://github.com/twashing/garden-watch - Clojars https://clojars.org/garden-watch Tim Washington Interruptsoftware.com http://interruptsoftware.com/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
random thought on #_
I like #_, it's very useful I had a thought I'd like to have #__ - two _ to comment 2 expressions - specifically for commenting in maps Then I thought #_n where n is an integer - to comment as many as you need. end of my thought. Dave -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: random thought on #_
another little gem. Just what I wanted. It didn't occur to me that it would work this way - but now it seems obvious Thanks Christophe Dave On Thursday, 23 January 2014 00:21:53 UTC+11, Christophe Grand wrote: #_ nests nicely: #_#_ comments out the next two expressions. Christophe On Wed, Jan 22, 2014 at 2:03 PM, Dave Sann dave...@gmail.comjavascript: wrote: I like #_, it's very useful I had a thought I'd like to have #__ - two _ to comment 2 expressions - specifically for commenting in maps Then I thought #_n where n is an integer - to comment as many as you need. end of my thought. Dave -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- On Clojure http://clj-me.cgrand.net/ Clojure Programming http://clojurebook.com Training, Consulting Contracting http://lambdanext.eu/ -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Can you explain the result of a expression?
chunked lazy sequences On Wednesday, 28 August 2013 12:51:27 UTC+10, ljcp...@gmail.com wrote: Hi, (take 1 (map #(do (print \.) %) (range))) result: (0) I think it should be (.0), why? thank you! -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Does this abstraction have any existing name?
if you are thinking of the nested map as a sort of tree - which you seem to
be doing - then map-leaves or something similar might convey the intent.
On Saturday, 27 July 2013 04:30:30 UTC+10, Jay Fields wrote:
I'm not sure I'd call this more readable, but it's another option - using
clojure.walk
(defn deep-update-vals
[m f args]
(let [f (fn [[k v]] (if (map? v) [k v] [k (apply f v args)]))]
(clojure.walk/postwalk (fn [x] (if (map? x) (into {} (map f x)) x))
m)))
On Fri, Jul 26, 2013 at 2:06 PM, Jay Fields j...@jayfields.comjavascript:
wrote:
I defined update-vals in jry:
https://github.com/jaycfields/jry/blob/master/src/clojure/jry.clj#L74-L75
It doesn't traverse nested maps, but I haven't ever needed that ability
either.
1) I've never seen a name for that.
2) not in core. I'm sure it's been written 50 times in various helper
libs.
3) I'd probably write it like below, but I'm not convinced it's any
better.
(defn deep-update-vals
[m f args]
(if (map? m)
(reduce-kv #(assoc %1 %2 (apply deep-update-vals %3 f args)) {} m)
(apply f m args)))
On Fri, Jul 26, 2013 at 1:31 PM, Yoshinori Kohyama
yyko...@gmail.comjavascript:
wrote:
Thank you Gary.
There's no reason why this need to be a macro.
It has rewritten as a function.
And I'd still like to hear any response about the same three questions.
(require '[clojure.test :refer (with-test is run-tests)])
(with-test
(defn mapf [f m args]
((fn g [n]
(if (map? n)
(into {} (map (fn [[k v]] [k (g v)]) n))
(apply f n args)))
m))
(is (= (mapf #(* % %) {:a {:b 3 :c 4} :d 5})
{:a {:b 9 :c 16} :d 25}))
(is (= (mapf #(+ (* %1 %1) %2) {:a {:b 3 :c 4} :d 5} 1)
{:a {:b 10 :c 17} :d 26})))
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.comjavascript:
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com javascript:
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups Clojure group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure+u...@googlegroups.com javascript:.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: who's not using leiningen?
Thanks all. D -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
who's not using leiningen?
If you are not using Leiningen, what do you use? why do you prefer it? D -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Utility libraries and dependency hygiene
It may be pragmatic currently but *manually* copying code is a bad solution. Not depending on libraries is not a good solution either. The premise that there are only 3 levels of composition - clojure - library - application - I think is wrong, even if it works and is useful in some cases. Don't depend on things you don't need to. But don't turn this approach into dogma and give up on better answers. I think there are 3 problems here: 1. Possible library* *conflict - this is primarily a *Naming* conflict - i.e. currently you can only have one version because they are named the same. 2. Data incompatibility - this is incompatibility when passing data across interface boundaries. 3. Number of dependency versions - but only if you need to care about size. Library versioning is currently another example of place oriented programming. i.e same global name, different content = problem. Dave On Tuesday, 14 May 2013 22:19:15 UTC+10, Dave Kincaid wrote: This thread seems to have gotten way off track and I think that Stuart made a very important point in the original post that's getting lost. It would help all of us out if library authors stopped making their libraries dependent on 10+ other libraries. This issue does have the potential to really drag on Clojure adoption. Just try to maintain your own local repository for your projects and you'll see what I mean the first time you need to add a Clojure dependency. On Tuesday, May 14, 2013 4:22:59 AM UTC-5, Phillip Lord wrote: Stuart Sierra ma...@stuartsierra.com writes: On Tue, May 14, 2013 at 3:25 AM, Phil Hagelberg ph...@hagelb.org wrote: It's really not difficult to do if you limit yourself to Clojure since Clojure namespaces are first-class and easy to manipulate at run-time. We implemneted a prototype of this in under two hours at a Seajure meeting a while back: https://github.com/technomancy/metaverse However, it's significantly more difficult to do for arbitrary Java bytecode. That's cool, and it will work for the simple case of libraries A and B depending on different versions of C. But it still breaks down in more complex cases: e.g. if I want to share data between A and B using a protocol or type defined in C, and there are 2 incompatible versions of C. Even ClassLoaders can't help you there - I'm not aware of any solution. Automatically, no, but the solution would be to use something akin to an adaptor. The two versions of C would be manipulated to be in different namespaces; now you just have two libraries, so the task of plumbing them together remains the same. To be honest, though, this is unlikely; after all, if you are using A and B, and they are using C *as a utility*, my feeling is that C shouldn't really be in their public interface. If C *is* in their public interface, then again, you need adaptors. Or you can fork A and/or B, fix them to use the same version! Phil -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ANN: kits 1.5.1 - some of Runa's core utilities
A question for the community. There are several projects that provide a bunch of base level/common functions and extensions (similar to those here) beyond core Clojure. And I am sure that many people have their own collection of useful utilities like this. I know that I do. clojure/core.incubator doesn't move very quickly for obvious reasons Maybe the community could establish a common project or set of projects to pool these utilities as a common base. This could also potentially feed into core Clojure as relevant. I know this can have complications, it's just a thought to avoid duplication of effort. Dave On Friday, 10 May 2013 07:57:10 UTC+10, Alex Baranosky wrote: Runa has decided to open source a project of our utility namespaces that we call Runa Kits https://github.com/runa-dev/kits. At this point in time this includes: - benchmark.clj ;; simple timing functions - csv.clj ;; wrapper around clojure-csv library that turn csv in to column-name, column-value key value pair that can be configured via :key-fn, :val-fn and :reader for each field - db_migrator.clj ;; simple SQL schema migration library - foundation.clj ;; catchall ns of utils - homeless.clj ;; another catchall ns of utils - logging.clj ;; Simple wrapper library for java.util.logging - map.clj ;; Functions that operate on Clojure maps - match.clj ;; Supports the speed optimized 'matches?' macro and 'fmatches?' fn for checking if a string matches a sequence of strings or wildcard strings - queues.clj ;; Wrappers for constructing various java.util.concurrent queues - runtime.clj ;; Library to access run-time info from the JVM - seq.clj ;; Functions that operate on Clojure sequences - string.clj ;; Functions that operate on Strings or Keywords - structured_logging.clj ;; Logging Clojure data as JSON: supports :tags and log contexts - test_utils.clj ;; Functions and macros for making writing tests more effectively - timestamp.clj ;; Functions for creating and formatting timestamps (Longs) - xml.clj ;; To simplify working with clojure.xml These are tools we use everyday, and have not been spiffed up with many doc strings. In general these kits are offered up for use by the community as-is, and we hope you find something of use in there. Best, Alex -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Bug in reader or repl? reading keyword :#abc
I came across the following... ;; = ok; (let [v :abc] nil) ;; = ok; (let [v :abc] nil) ;; = ok; (let [v :#abc] nil) ;; = fail; (let [v :#abc] nil) $ lein repl nREPL server started on port 33719 REPL-y 0.1.10 Clojure 1.5.1 ... user= ;; = ok; user= (let [v :abc] nil) nil user= user= ;; = ok; user= (let [v :abc] #_=nil) nil user= user= ;; = ok; user= (let [v :#abc] nil) nil user= user= user= ;; = fail; user= (let [v :#abc] RuntimeException EOF while reading, starting at line 1 clojure.lang.Util.runtimeException (Util.java:219) user= nil) nil RuntimeException Unmatched delimiter: ) clojure.lang.Util.runtimeException (Util.java:219) user= -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Bug in reader or repl? reading keyword :#abc
Hi Ambrose. You are correct - but these are used frequently in both enlive and seesaw for selector tags. which is where this occurred. On Thursday, 2 May 2013 00:27:17 UTC+10, Ambrose Bonnaire-Sergeant wrote: According to the reader page, # isn't a valid character in a symbol/keyword. http://clojure.org/reader Thanks, Ambrose On Wed, May 1, 2013 at 10:22 PM, Dave Sann dave...@gmail.comjavascript: wrote: I came across the following... ;; = ok; (let [v :abc] nil) ;; = ok; (let [v :abc] nil) ;; = ok; (let [v :#abc] nil) ;; = fail; (let [v :#abc] nil) $ lein repl nREPL server started on port 33719 REPL-y 0.1.10 Clojure 1.5.1 ... user= ;; = ok; user= (let [v :abc] nil) nil user= user= ;; = ok; user= (let [v :abc] #_=nil) nil user= user= ;; = ok; user= (let [v :#abc] nil) nil user= user= user= ;; = fail; user= (let [v :#abc] RuntimeException EOF while reading, starting at line 1 clojure.lang.Util.runtimeException (Util.java:219) user= nil) nil RuntimeException Unmatched delimiter: ) clojure.lang.Util.runtimeException (Util.java:219) user= -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Fwd: Bug in reader or repl? reading keyword :#abc
-- Forwarded message -- From: Colin Jones trptco...@gmail.com Date: 2 May 2013 04:35 Subject: Re: Bug in reader or repl? reading keyword :#abc To: daves...@gmail.com On Wednesday, May 1, 2013 9:22:43 AM UTC-5, Dave Sann wrote: I came across the following... ;; = ok; (let [v :abc] nil) ;; = ok; (let [v :abc] nil) ;; = ok; (let [v :#abc] nil) ;; = fail; (let [v :#abc] nil) $ lein repl nREPL server started on port 33719 REPL-y 0.1.10 Clojure 1.5.1 ... user= ;; = ok; user= (let [v :abc] nil) nil user= user= ;; = ok; user= (let [v :abc] #_=nil) nil user= user= ;; = ok; user= (let [v :#abc] nil) nil user= user= user= ;; = fail; user= (let [v :#abc] RuntimeException EOF while reading, starting at line 1 clojure.lang.Util. **runtimeException (Util.java:219) user= nil) nil RuntimeException Unmatched delimiter: ) clojure.lang.Util.**runtimeException (Util.java:219) This is a symptom of how REPLy handles unexpected nodes that sjacket provides (and sjacket saying that :#abc is not a keyword). REPLy started to use sjacket for parsing input forms in 0.1.0 (final; not the betas), to handle situations like reader literals and read-eval that require the full execution context (which therefore need to execute remotely via nREPL). If there's an unexpected node, REPLy throws up its hands and ships the input off to nREPL. This appears to work fine when the input is complete, I'd expect due to coincidence in the reader's implementation. I agree with Ambrose; it's not promised to be a valid symbol or keyword by any documentation I can find. Another hint is https://github.com/edn-format/edn, where there's more specification of what characters a valid symbol/keyword can contain: # from EDN spec Symbols begin with a non-numeric character and can contain alphanumeric characters and . * + ! - _ ? $ % =. If -, + or . are the first character, the second character must be non-numeric. Additionally, : # are allowed as constituent characters in symbols other than as the first character. # So I think sjacket is doing the correct thing in this situation by saying the input is unexpected/incorrect, and that this input working in the reader itself is not by design. Note that this problem does not exist where the keyword in question is :a#bc user= (let [v :a#bc] #_= v) :a#bc - Colin user= -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Bug in reader or repl? reading keyword :#abc
This may be due to the version of Reply you have. See comments by Colin Jones, forwarded. On Thursday, 2 May 2013 00:28:40 UTC+10, Devin Walters (devn) wrote: I wasn't able to reproduce: nREPL server started on port 64767 REPL-y 0.1.0-beta10 Clojure 1.5.1 ... user= (let [v :#abc] #_= nil) nil user= -- '(Devin Walters) On Wednesday, May 1, 2013 at 9:22 AM, Dave Sann wrote: I came across the following... ;; = ok; (let [v :abc] nil) ;; = ok; (let [v :abc] nil) ;; = ok; (let [v :#abc] nil) ;; = fail; (let [v :#abc] nil) $ lein repl nREPL server started on port 33719 REPL-y 0.1.10 Clojure 1.5.1 ... user= ;; = ok; user= (let [v :abc] nil) nil user= user= ;; = ok; user= (let [v :abc] #_= nil) nil user= user= ;; = ok; user= (let [v :#abc] nil) nil user= user= user= ;; = fail; user= (let [v :#abc] RuntimeException EOF while reading, starting at line 1 clojure.lang.Util.runtimeException (Util.java:219) user= nil) nil RuntimeException Unmatched delimiter: ) clojure.lang.Util.runtimeException (Util.java:219) user= -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript:(mailto: clo...@googlegroups.com javascript:) Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: (mailto: clojure+u...@googlegroups.com javascript:) For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript: (mailto: clojure+u...@googlegroups.com javascript:). For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Bug in reader or repl? reading keyword :#abc
Comments from Colin Jones. This is a symptom of how REPLy handles unexpected nodes that sjacket provides (and sjacket saying that :#abc is not a keyword). REPLy started to use sjacket for parsing input forms in 0.1.0 (final; not the betas), to handle situations like reader literals and read-eval that require the full execution context (which therefore need to execute remotely via nREPL). If there's an unexpected node, REPLy throws up its hands and ships the input off to nREPL. This appears to work fine when the input is complete, I'd expect due to coincidence in the reader's implementation. I agree with Ambrose; it's not promised to be a valid symbol or keyword by any documentation I can find. Another hint is https://github.com/edn-format/edn, where there's more specification of what characters a valid symbol/keyword can contain: # from EDN spec Symbols begin with a non-numeric character and can contain alphanumeric characters and . * + ! - _ ? $ % =. If -, + or . are the first character, the second character must be non-numeric. Additionally, : # are allowed as constituent characters in symbols other than as the first character. # So I think sjacket is doing the correct thing in this situation by saying the input is unexpected/incorrect, and that this input working in the reader itself is not by design. Note that this problem does not exist where the keyword in question is :a#bc user= (let [v :a#bc] #_= v) :a#bc -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Observing namespace changes
Out of interest, did any library come out of this? On Thursday, 15 January 2009 06:46:52 UTC+11, Laurent PETIT wrote: OK thank you both Chris Mike for your answer. What I've done for the moment is similar to what Mike did: at any place where there is a chance for something to change namespaces, I reload a new snapshot (and I throw the old). Registering watchers for Vars seems very interesting, I'll investigate. Registering watchers for ns would be great too. But there still may be a case or two uncovered, even when we will be able to register watchers on ns : when new ns are created. Then we need so kind of watcher on the vector holding all the ns ... ? If this vector is implemented as a Var, it is maybe already possible to do this, even if it is undocumented ? Cheers, -- Laurent On Jan 14, 5:55 pm, MikeM michael.messini...@invista.com wrote: There's no event mechanism to monitor namespace changes. I accomplish this by taking a snapshot before and after any possible namespace- changing execution, using ns-map. Not as efficient as an event callback, but I haven't had any performance issues (map lookups are plenty fast for me). You can register a watcher for a Var to get notification of a root binding change using add-watcher - note that the clojure.org doc for add-watcher has not been updated to match the Var watcher revision. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Defining custom tags using hiccup ?
I replied to this a long time ago and in the original case - I did not see
huge value in the suggestion. But recently I wanted to do exactly what
Murtaza suggests.
There are a couple of reasons why I think this capability would be useful.
(And rereading Murtaza's email - I think this is what he meant)
1. The functions defined in hiccup and other libraries are not portable. if
you rely on these, they will only work if the library maintained has copied
the function interface exactly. This is not always the case. (as a separate
comment these utility functions
would be better separated from the rendering code).
2. I would be great to write markup that describes your domain, not HTML so
[:address :street here :city there]
rather than [:div lots of html specific bits ... street...]
3. It would be great to be able to switch the rendering of your domain
without editing the overall markup structure.
4. if webcomponents take off - which I hope they do - you may be able to
gracefully transition by disabling the various tag rewriting again, not
touching the main markup logic.
So I had a look to see if this can be done - and it can - relatively
easily.
I implemented it the easiest way initially - but there are alternative
possibilities for how this might work. Currently it uses a multimethod -
but it might be better to pass in tag expanding functions when rendering
- this would be more flexible.
The changes to hiccup to achieve this are quite minor.
See here: https://github.com/davesann/hiccup/commit/custom-tags
I added a basic repl example file
https://github.com/davesann/hiccup/blob/custom-tags/repl/example.clj
A nice thing here is that incompatibilities between hiccup and cljs
equivalents could be mitigated if we could agree on a standard for
allowing custom tags.
Thoughts anyone?
Dave
On Monday, 14 May 2012 00:31:48 UTC+10, Walter Tetzner wrote:
You could do this without adding anything to hiccup.
If you wrote a function that, say, used walk, you could have it go
through the vectors, and replace the custom tags with what they
represent. Then you could just call that before calling `html'.
(html
(transform
[:html
[:head
[:title some page]]
[:body
[:link-to {:url http://www.google.com/} Hi this is Google]]]))
The benefit to doing it this way over having the macro is that it's
clear where the custom tags come from when looking at the invocation
of `html'.
If you really want `html' to handle it, maybe it could be called with
a map of tranform functions?
(html {:link-to link-to}
[:html
[:head
[:title some page]]
[:body
[:link-to {:url http://www.google.com/} Hi this is Google]]])
Either way, I think this ends up being nicer than a macro that changes
the behavior of `html'.
On Sunday, May 13, 2012 12:35:46 AM UTC-4, Murtaza Husain wrote:
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Defining custom tags using hiccup ?
see this commit for main changes to hiccup
https://github.com/davesann/hiccup/commit/e8c06d884eb22a2cdd007f880a9dd5e1c13669a4
On Thursday, 25 April 2013 18:55:52 UTC+10, Dave Sann wrote:
I replied to this a long time ago and in the original case - I did not see
huge value in the suggestion. But recently I wanted to do exactly what
Murtaza suggests.
There are a couple of reasons why I think this capability would be useful.
(And rereading Murtaza's email - I think this is what he meant)
1. The functions defined in hiccup and other libraries are not portable.
if you rely on these, they will only work if the library maintained has
copied the function interface exactly. This is not always the case. (as a
separate comment these utility functions
would be better separated from the rendering code).
2. I would be great to write markup that describes your domain, not HTML so
[:address :street here :city there]
rather than [:div lots of html specific bits ... street...]
3. It would be great to be able to switch the rendering of your domain
without editing the overall markup structure.
4. if webcomponents take off - which I hope they do - you may be able to
gracefully transition by disabling the various tag rewriting again, not
touching the main markup logic.
So I had a look to see if this can be done - and it can - relatively
easily.
I implemented it the easiest way initially - but there are alternative
possibilities for how this might work. Currently it uses a multimethod -
but it might be better to pass in tag expanding functions when rendering
- this would be more flexible.
The changes to hiccup to achieve this are quite minor.
See here: https://github.com/davesann/hiccup/commit/custom-tags
I added a basic repl example file
https://github.com/davesann/hiccup/blob/custom-tags/repl/example.clj
A nice thing here is that incompatibilities between hiccup and cljs
equivalents could be mitigated if we could agree on a standard for
allowing custom tags.
Thoughts anyone?
Dave
On Monday, 14 May 2012 00:31:48 UTC+10, Walter Tetzner wrote:
You could do this without adding anything to hiccup.
If you wrote a function that, say, used walk, you could have it go
through the vectors, and replace the custom tags with what they
represent. Then you could just call that before calling `html'.
(html
(transform
[:html
[:head
[:title some page]]
[:body
[:link-to {:url http://www.google.com/} Hi this is
Google]]]))
The benefit to doing it this way over having the macro is that it's
clear where the custom tags come from when looking at the invocation
of `html'.
If you really want `html' to handle it, maybe it could be called with
a map of tranform functions?
(html {:link-to link-to}
[:html
[:head
[:title some page]]
[:body
[:link-to {:url http://www.google.com/} Hi this is Google]]])
Either way, I think this ends up being nicer than a macro that changes
the behavior of `html'.
On Sunday, May 13, 2012 12:35:46 AM UTC-4, Murtaza Husain wrote:
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Defining custom tags using hiccup ?
one other thought. It is possible just to manipulate the hiccup data as suggested by Walter above. This may be better because it is independent. But I wonder about performance costs of processing the structures twice (expand and then render) rather than once (render). Dave -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Linode compromise possibly affecting Clojars
+1 On Thursday, 18 April 2013 05:04:47 UTC+10, Andrew Wagner wrote: Just wanted to say, awesome job with this. I appreciate your diligence! On Wed, Apr 17, 2013 at 2:50 PM, Phil Hagelberg ph...@hagelb.orgjavascript: wrote: Update: thanks to an older backup from Ivan Kozik, we've been able to verify the integrity of all but 45 jars. It's likely these were legitimate redeployments by the maintainers, but I'm going to be reviewing the diffs by hand. I've attached a list of jars which haven't been verified. If your dependency tree (visible with `lein deps :tree` under Leiningen 2) does not include any of these then you should be completely clear. If it does you're probably still safe; I hope to have these cleared by the end of the day. From what we know from Linode, the exposed data could not have resulted in a compromise of the box without a reboot in order to reset passwords or use the rescue image, and we've confirmed that a reboot did not occur. So checking the jar diffs is probably not necessary, but we'd rather be extra-careful. thanks, Phil amazonica/amazonica/0.1.3/amazonica-0.1.3.jar amazonica/amazonica/0.1.4/amazonica-0.1.4.jar amazonica/amazonica/0.1.5/amazonica-0.1.5.jar antler/caribou-admin/0.10.0/caribou-admin-0.10.0.jar bwo/monads/0.1.0/monads-0.1.0.jar cc/qbits/alia/1.0.0-beta7/alia-1.0.0-beta7.jar chlorine/chlorine/1.5.2.1/chlorine-1.5.2.1.jar chlorine/chlorine/1.5.2.2/chlorine-1.5.2.2.jar chlorine/chlorine/1.5.3/chlorine-1.5.3.jarhttp://1.5.2.2/chlorine-1.5.2.2.jarchlorine/chlorine/1.5.3/chlorine-1.5.3.jar clj-diffmatchpatch/clj-diffmatchpatch/ 0.0.9.1/clj-diffmatchpatch-0.0.9.1.jar clj-diffmatchpatch/clj-diffmatchpatch/0.0.9.3/clj-diffmatchpatch-0.0.9.3.jar clj-diffmatchpatch/clj-diffmatchpatch/0.0.9/clj-diffmatchpatch-0.0.9.jar clojurewerkz/archimedes/1.0.0-alpha3/archimedes-1.0.0-alpha3.jar com/akolov/xelery/0.3.0/xelery-0.3.0.jarhttp://0.0.9.1/clj-diffmatchpatch-0.0.9.1.jarclj-diffmatchpatch/clj-diffmatchpatch/0.0.9.3/clj-diffmatchpatch-0.0.9.3.jarclj-diffmatchpatch/clj-diffmatchpatch/0.0.9/clj-diffmatchpatch-0.0.9.jarclojurewerkz/archimedes/1.0.0-alpha3/archimedes-1.0.0-alpha3.jarcom/akolov/xelery/0.3.0/xelery-0.3.0.jar com/narkisr/carmine/1.6.0/carmine-1.6.0.jar com/narkisr/gelfino-client/0.4.0/gelfino-client-0.4.0.jar conveyor-coffeescript/conveyor-coffeescript/0.1.4/conveyor-coffeescript-0.1.4.jar core-cl2/core-cl2/0.7.0/core-cl2-0.7.0.jar core-cl2/core-cl2/0.7.1/core-cl2-0.7.1.jar docopt/docopt/0.6.1/docopt-0.6.1.jar factual/c4/0.0.11/c4-0.0.11.jar homestake-server/homestake-server/0.1/homestake-server-0.1.jar info/yasuhisay/clj-utils/0.1.1/clj-utils-0.1.1.jar info/yasuhisay/liblinear/0.0.1/liblinear-0.0.1.jar lamina/lamina/0.5.0-beta15/lamina-0.5.0-beta15.jar lein-haml-sass/lein-haml-sass/0.2.5/lein-haml-sass-0.2.5.jar lein-package/lein-package/0.1.2/lein-package-0.1.2.jar lib-noir/lib-noir/0.5.0/lib-noir-0.5.0.jar luminus/lein-template/0.5.3/lein-template-0.5.3.jar luminus/lein-template/0.5.5/lein-template-0.5.5.jar me/arrdem/imprecise/me.arrdem.imprecise/0.1.0/me.arrdem.imprecise-0.1.0.jar net/clojure/monads/1.0.1/monads-1.0.1.jar nsfw/lein-template/0.5.2/lein-template-0.5.2.jar org/flatland/phonograph/0.1.4/phonograph-0.1.4.jar org/trpr/integration-rabbitmq/1.2.2/integration-rabbitmq-1.2.2.jar org/trpr/platform-core/1.2.2/platform-core-1.2.2.jar org/trpr/platform-integration/1.2.2/platform-integration-1.2.2.jar rojat/rojat-arrows/0.0.6/rojat-arrows-0.0.6.jar rojat/rojat-math/0.0.2/rojat-math-0.0.2.jar rojat/rojat-math/0.0.3/rojat-math-0.0.3.jar rst-format-parser/rst-format-parser/0.0.1/rst-format-parser-0.0.1.jar service-hub/service-hub/1.0.3/service-hub-1.0.3.jar stereotype/stereotype/0.2.1/stereotype-0.2.1.jar stereotype/stereotype/0.2.2/stereotype-0.2.2.jar thebusby/clj-aws-ec2/0.2.2/clj-aws-ec2-0.2.2.jar -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Advice on state handling for a multiplayer poker app
have a look at this for a discussion of exactly that question.
http://clj-me.cgrand.net/2011/10/06/a-world-in-a-ref/
https://github.com/cgrand/megaref
On Friday, 12 April 2013 07:35:03 UTC+10, James Adams wrote:
Hi,
I'm new to Clojure and trying to write a multiplayer poker web app. I'm
looking for advice early on regarding state management.
I'm using aleph and compojure for the communications with actions from
players coming in through compojure on different threads of the netty
server.
When a message arrives I check which rooms it corresponds based on the url
then update that rooms game state.
I could store all state in (def rooms (atom {})) with the keys being the
room name and each room containing users and the game state but this would
require that I deref swap! for every change to the state in any room
which would seem to be a bottleneck.
Timers are also needed to fold a player if they don't move in time.
How would you do this? All thoughts welcome and appreciated
Thanks
James
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [GSOC 2013] Android UI as Clojure Data
Caveat - I haven't do any android dev and don't know details of their UI apis But not letting that get in the way of an opinion, I also suggest that you look at what Dave Ray has done with Seesaw for swing. There my well be useful ideas in there for you. https://github.com/daveray/seesaw/ infoq preso http://www.infoq.com/presentations/Building-User-Interfaces-with-Seesaw Dave On Thursday, 11 April 2013 04:42:25 UTC+10, Junseok Lee wrote: Hello! My name is Junseok Lee, and I'm studying CS at UC Berkeley. I was lead to Clojure through my interest in the Lisp family of languages, initiated by my studies of Scheme in my coursework. I've been lurking on this group for a while and thought it was about time to introduce myself. I'm hoping to find an effective way to express Android UI layouts with Clojure during this year's Google Summer of Code. I'm very well versed in Java and the Android API, and am currently studying the core.match library. My first thought is to implement something similar to Hiccup's HTML generation. Am I on the right track or did I get the idea completely wrong? Any suggestions are welcome. Thanks in advance. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Concurrency and custom types.
how could it not be true? it's in data represented in memory. On Monday, 25 March 2013 23:37:33 UTC+11, Jim foo.bar wrote: On 25/03/13 12:28, Michael Klishin wrote: There is no absolute immutability on the JVM, .NET, in JavaScript. There is always a backdoor to mutability. But 99.9% of projects won't use it. Andy hinted this last night as well...is this true? if I declare a Integer/String object as private final within a class, is there a way to mutate it? I do find this very scary, even in Java as it contradicts certain things we take for granted... Jim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Exception propagation design in Clojure web APIs.
Interesting.
Validation is the case I am thinking of - but it might also apply to any
situation where you offer a different path of control - i.e. not stepping
back up the stack. That's why I mentioned CPS. That's also (maybe) why true
tail calls would be useful.
The mention of binding dynamic vars is interesting and I will look at this.
It still leaves the question of how/when to pass control to actually manage
or respond to the validation error. I have generally kept away from dynamic
vars to date because I don't have a good feel for when and where they are
and are not a good choice. This would be a great area for a blog post - or
clojure docs doco - if anyone who has used them extensively can offer a
good view of pros and cons, whens and when nots :)
Marko, do you have a good example of doing what you say?
The reasons given for not using Exceptions are still not really convincing
to me (yet). Although I do accept that some things may become more
difficult to manage if you don't take care in what you do. This is
generally true. I just see Exceptions as a way of managing control with
pros and cons, not an anti pattern.
Maybe a more general question is what alternative control flows are
available - which are possible but not available - and which are good for
which situations.
Apologies to the original questioner for changing the focus of the recent
posts.
Dave
On Wednesday, 20 March 2013 19:36:46 UTC+11, Marko Topolnik wrote:
Exceptions are a perfect tool for flow control, if used judiciously. The
typical criticism revolves around their incompetent usage, and a more
general criticism can be made against a mechanism that is subverted all too
easily.
If you responsibly keep to the good parts, exceptions could be the way
to go. Validation is one example where I love them because it happens all
around, but validation failures are all handled uniformly.
However, I would also urge you to explore other approaches, such as having
a dynamically-bound variable that collects all the validation failures,
which will potentially give you better diagnostics than the fail-fast
behavior of validation excptions.
-marko
On Wednesday, March 20, 2013 2:24:12 AM UTC+1, Dave Sann wrote:
I am interested in this view that exceptions are an anti pattern. I have
heard it voiced before.
I am not sure that I understand why.
As I see it you have a choices:
1. Handle in the result - and test this result repeatedly all the way
back to the caller
2. Handle out of band - Throw an exception, allow the stack to unwind
and catch where it matters
[And maybe - but I am not very knowledgeable on this and it won't work
today on the JVM anyway
3. Use continuation passing style with TCO to shortcut the return to
follow an exception path]
So, ignoring 3.
Why is 2 preferable over 1? There are certainly pros and cons.
Dave
On Wednesday, 20 March 2013 09:42:11 UTC+11, James Reeves wrote:
I'd argue that using exceptions for control flow is something of an
anti-pattern, even in Java.
In this case a better mechanism might be to use polymorphism. For
instance:
(defprotocol Validatable
(validation-errors [x] Return the validation errors for x.))
(defn valid? [x]
(empty? (validation-errors x)))
Then you can define a general function to validate and store that item
in a database:
(defn store-valid [db x]
(if (valid? x)
(store db x)
(validation-error-response x)))
- James
On 19 March 2013 16:43, Julien Dreux julien...@gmail.com wrote:
Hi all,
Coming from a Java background, I am having a hard time understanding
how validation error propagation should work in clojure web APIs.
To be clear, this is similar to how my Java web service would be setup:
/** Method that validates the model, accesses the DB. If something went
wrong, throw an exception */
public void validateAndCreateUser(User u) throws ValidationException,
EmailAlreadyInUseException, ... {
...
if(...) {
throw new ValidationException(fieldName);
} else if (...) {
throw new EmailAlreadyInUseException(u.getEmail());
}
}
/** Endpoint method, catches formats the exceptions thrown by the db
method. **/
@POST(/api/user/create)
public Response createUser (User u) {
..
try{
validateAndCreateUser(u);
return Response.ok();
} catch (Exception e) {
return generateExceptionResponse(e); //Method that maps exceptions
to responses.
}
}
For all of Java's clunkiness, this had the benefit of not having to
write tons of if/else statements for validation handling. Exception were
just thrown from anywhere, bubbling back up to inital call, and if not
handled in the endpoint method, a specialized class mapped them into a
proper response. The exceptions contained all the information needed to
generate 'rich' error messages back to the client.
Being a Clojure newbie, I wonder what a good pattern is for a similar
Re: Exception propagation design in Clojure web APIs.
Ok, but how do you take account of different processing (or non processing) needs in the handler (chain) given that something is awry half way down? (note that in my case the handler is not pure - the validation precedes the need for a state change. The state change should occur if the validation passes and must not if it fails. I can't validate in advance because that would lead to a race condition). On Wednesday, 20 March 2013 23:24:48 UTC+11, Marko Topolnik wrote: On Wednesday, March 20, 2013 1:06:54 PM UTC+1, Dave Sann wrote: Marko, do you have a good example of doing what you say? What I had in mind, related to OP's post, would be a middleware that does (binding [*validation-failures* []] (handler req) (do-something-about *validation-failures*)) There would be a global function, such as *add-failure*, which would *conj * a new failure to the vector. -marko -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Exception propagation design in Clojure web APIs.
I am interested in this view that exceptions are an anti pattern. I have
heard it voiced before.
I am not sure that I understand why.
As I see it you have a choices:
1. Handle in the result - and test this result repeatedly all the way back
to the caller
2. Handle out of band - Throw an exception, allow the stack to unwind and
catch where it matters
[And maybe - but I am not very knowledgeable on this and it won't work
today on the JVM anyway
3. Use continuation passing style with TCO to shortcut the return to
follow an exception path]
So, ignoring 3.
Why is 2 preferable over 1? There are certainly pros and cons.
Dave
On Wednesday, 20 March 2013 09:42:11 UTC+11, James Reeves wrote:
I'd argue that using exceptions for control flow is something of an
anti-pattern, even in Java.
In this case a better mechanism might be to use polymorphism. For instance:
(defprotocol Validatable
(validation-errors [x] Return the validation errors for x.))
(defn valid? [x]
(empty? (validation-errors x)))
Then you can define a general function to validate and store that item in
a database:
(defn store-valid [db x]
(if (valid? x)
(store db x)
(validation-error-response x)))
- James
On 19 March 2013 16:43, Julien Dreux julien...@gmail.com javascript:wrote:
Hi all,
Coming from a Java background, I am having a hard time understanding how
validation error propagation should work in clojure web APIs.
To be clear, this is similar to how my Java web service would be setup:
/** Method that validates the model, accesses the DB. If something went
wrong, throw an exception */
public void validateAndCreateUser(User u) throws ValidationException,
EmailAlreadyInUseException, ... {
...
if(...) {
throw new ValidationException(fieldName);
} else if (...) {
throw new EmailAlreadyInUseException(u.getEmail());
}
}
/** Endpoint method, catches formats the exceptions thrown by the db
method. **/
@POST(/api/user/create)
public Response createUser (User u) {
..
try{
validateAndCreateUser(u);
return Response.ok();
} catch (Exception e) {
return generateExceptionResponse(e); //Method that maps exceptions to
responses.
}
}
For all of Java's clunkiness, this had the benefit of not having to write
tons of if/else statements for validation handling. Exception were just
thrown from anywhere, bubbling back up to inital call, and if not handled
in the endpoint method, a specialized class mapped them into a proper
response. The exceptions contained all the information needed to generate
'rich' error messages back to the client.
Being a Clojure newbie, I wonder what a good pattern is for a similar
situation. So far, I have a method that validates models based on a schema,
that returns
{:success true}
or
{:success false :errors [error 1 error 2 ...]}
But I don't know how to avoid having to write if/else conditions of the
sort in each function between my endpoint and db functions.
(if (validation :success)
(follow-normal-path)
(handle-validation-errors validation))
Any guidance appreciated.
Cheers,
Julien
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.comjavascript:
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com javascript:
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+u...@googlegroups.com javascript:.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Exception propagation design in Clojure web APIs.
I am interested in this view that exceptions are an anti pattern. I have
heard it voiced before.
I am not sure that I understand why.
As I see it you have a choices:
1. Handle in the result - and test this result repeatedly all the way back
to the caller
2. Handle out of band - Throw an exception, allow the stack to unwind and
catch where it matters
[And maybe - but I am not very knowledgeable on this and it won't work
today on the JVM anyway
3. Use continuation passing style with TCO to shortcut the return to
follow an exception path]
So, ignoring 3.
Why is 2 preferable over 1? There are certainly pros and cons.
Dave
On Wednesday, 20 March 2013 09:42:11 UTC+11, James Reeves wrote:
I'd argue that using exceptions for control flow is something of an
anti-pattern, even in Java.
In this case a better mechanism might be to use polymorphism. For instance:
(defprotocol Validatable
(validation-errors [x] Return the validation errors for x.))
(defn valid? [x]
(empty? (validation-errors x)))
Then you can define a general function to validate and store that item in
a database:
(defn store-valid [db x]
(if (valid? x)
(store db x)
(validation-error-response x)))
- James
On 19 March 2013 16:43, Julien Dreux julien...@gmail.com javascript:wrote:
Hi all,
Coming from a Java background, I am having a hard time understanding how
validation error propagation should work in clojure web APIs.
To be clear, this is similar to how my Java web service would be setup:
/** Method that validates the model, accesses the DB. If something went
wrong, throw an exception */
public void validateAndCreateUser(User u) throws ValidationException,
EmailAlreadyInUseException, ... {
...
if(...) {
throw new ValidationException(fieldName);
} else if (...) {
throw new EmailAlreadyInUseException(u.getEmail());
}
}
/** Endpoint method, catches formats the exceptions thrown by the db
method. **/
@POST(/api/user/create)
public Response createUser (User u) {
..
try{
validateAndCreateUser(u);
return Response.ok();
} catch (Exception e) {
return generateExceptionResponse(e); //Method that maps exceptions to
responses.
}
}
For all of Java's clunkiness, this had the benefit of not having to write
tons of if/else statements for validation handling. Exception were just
thrown from anywhere, bubbling back up to inital call, and if not handled
in the endpoint method, a specialized class mapped them into a proper
response. The exceptions contained all the information needed to generate
'rich' error messages back to the client.
Being a Clojure newbie, I wonder what a good pattern is for a similar
situation. So far, I have a method that validates models based on a schema,
that returns
{:success true}
or
{:success false :errors [error 1 error 2 ...]}
But I don't know how to avoid having to write if/else conditions of the
sort in each function between my endpoint and db functions.
(if (validation :success)
(follow-normal-path)
(handle-validation-errors validation))
Any guidance appreciated.
Cheers,
Julien
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.comjavascript:
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com javascript:
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+u...@googlegroups.com javascript:.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Exception propagation design in Clojure web APIs.
That should have been why is 1 preferable over 2...
On Wednesday, 20 March 2013 12:24:12 UTC+11, Dave Sann wrote:
I am interested in this view that exceptions are an anti pattern. I have
heard it voiced before.
I am not sure that I understand why.
As I see it you have a choices:
1. Handle in the result - and test this result repeatedly all the way
back to the caller
2. Handle out of band - Throw an exception, allow the stack to unwind
and catch where it matters
[And maybe - but I am not very knowledgeable on this and it won't work
today on the JVM anyway
3. Use continuation passing style with TCO to shortcut the return to
follow an exception path]
So, ignoring 3.
Why is 2 preferable over 1? There are certainly pros and cons.
Dave
On Wednesday, 20 March 2013 09:42:11 UTC+11, James Reeves wrote:
I'd argue that using exceptions for control flow is something of an
anti-pattern, even in Java.
In this case a better mechanism might be to use polymorphism. For
instance:
(defprotocol Validatable
(validation-errors [x] Return the validation errors for x.))
(defn valid? [x]
(empty? (validation-errors x)))
Then you can define a general function to validate and store that item in
a database:
(defn store-valid [db x]
(if (valid? x)
(store db x)
(validation-error-response x)))
- James
On 19 March 2013 16:43, Julien Dreux julien...@gmail.com wrote:
Hi all,
Coming from a Java background, I am having a hard time understanding how
validation error propagation should work in clojure web APIs.
To be clear, this is similar to how my Java web service would be setup:
/** Method that validates the model, accesses the DB. If something went
wrong, throw an exception */
public void validateAndCreateUser(User u) throws ValidationException,
EmailAlreadyInUseException, ... {
...
if(...) {
throw new ValidationException(fieldName);
} else if (...) {
throw new EmailAlreadyInUseException(u.getEmail());
}
}
/** Endpoint method, catches formats the exceptions thrown by the db
method. **/
@POST(/api/user/create)
public Response createUser (User u) {
..
try{
validateAndCreateUser(u);
return Response.ok();
} catch (Exception e) {
return generateExceptionResponse(e); //Method that maps exceptions
to responses.
}
}
For all of Java's clunkiness, this had the benefit of not having to
write tons of if/else statements for validation handling. Exception were
just thrown from anywhere, bubbling back up to inital call, and if not
handled in the endpoint method, a specialized class mapped them into a
proper response. The exceptions contained all the information needed to
generate 'rich' error messages back to the client.
Being a Clojure newbie, I wonder what a good pattern is for a similar
situation. So far, I have a method that validates models based on a schema,
that returns
{:success true}
or
{:success false :errors [error 1 error 2 ...]}
But I don't know how to avoid having to write if/else conditions of the
sort in each function between my endpoint and db functions.
(if (validation :success)
(follow-normal-path)
(handle-validation-errors validation))
Any guidance appreciated.
Cheers,
Julien
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups Clojure group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Raw strings
I'd welcome the ability to change delimiter. I've found it very useful in the past to avoid illegible or hard to read strings. On Monday, 18 March 2013 19:57:06 UTC+11, Luc wrote: Looks fine to me. If it's an extension to the literal syntax it's also a narrow scope change. The standard escape sequences make things harder even for display purposes. We would also benefit from this, we are handling huge amounts of raw text and just for debugging purposes we have to mentally handle the \ escape character... berk. Our unit tests also suffer from this escaping mode. Using a literal syntax like this one would make life easier. Luc P. On Sun, Mar 17, 2013 at 11:23 PM, Softaddicts lprefo...@softaddicts.ca javascript:wrote: I find raw string handling in XML simply ugly :) Agreed. Do you have a suggestion on how to represent raw strings ? Something concrete we could discuss about ? In several languages, they use a sequence of three double-quotes to mark the beginning and the end of the raw string. In Clojure, I think raw strings would actually enhance the power of the edn format rather than detract, specifically the tagged elements. Right now, edn supports things like: #uuid f81d4fae-7dec-11d0-a765-00a0c91e6bf6and #inst 1985-04-12T23:20:50.52Zand you can create your own. The built-ins happen to not utilize double-quotes or backslashes, so escaping is not a big deal, but if you want your tagged element to use a syntax where quotes and backslashes are natural, you're out of luck and you get a big ugly mess. Think how much uglier the above inst element would look if - and : happened to be characters that required escaping. All I want is the ability to do something like *#my/tag 45 \ a \ 50* if that's the most natural way to express the element rather than having to type *#my/tag 45 \\ \a\ \\ 50* which is already starting to look ugly, and looks far uglier the more characters are in there that require escaping. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- Softaddictslprefo...@softaddicts.ca javascript: sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: What's the point of - ?
I don't see why this should be arcane. it is quite simple to understand. but yes, you do have to understand it. like anything. this is good sugar...probably a fructose derivative... On Tuesday, 12 March 2013 02:00:13 UTC+11, edw...@kenworthy.info wrote: But to understand the first you have to expand it into the second- which means understanding the arcane squiggle - and how it differs from the equally arcane squiggle -. Nasty, sticky, syntactic sugar :) I suspect that early on, still being a Clojure noobie, I'll stick with the 'proper' Lisp forms and no doubt as I become more experienced I'll pick more of the arcane Clojure idioms ;) On Monday, March 11, 2013 10:58:29 AM UTC, edw...@kenworthy.info wrote: So I understand that: (- foo bar wibble) is equivalent to (wibble (bar (foo))) With the advantage that the latter version is better, in the sense that it's clearer what the final result is (the result of the call to wobble). What I don't understand is the need for - the only thing it seems to do is make something Lispy appear to be imperative. Is that it? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Understanding map laziness in relation to vectors
It's to do with the chunking of sequences. they are taken in blocks of 32.
So minimum of 32 will be executed.
(first (remove nil? (map foo (vec (range 1 1000)
Exeuting for... 1
Exeuting for... 2
Exeuting for... 3
Exeuting for... 4
Exeuting for... 5
Exeuting for... 6
Exeuting for... 7
Exeuting for... 8
Exeuting for... 9
Exeuting for... 10
Exeuting for... 11
Exeuting for... 12
Exeuting for... 13
Exeuting for... 14
Exeuting for... 15
Exeuting for... 16
Exeuting for... 17
Exeuting for... 18
Exeuting for... 19
Exeuting for... 20
Exeuting for... 21
Exeuting for... 22
Exeuting for... 23
Exeuting for... 24
Exeuting for... 25
Exeuting for... 26
Exeuting for... 27
Exeuting for... 28
Exeuting for... 29
Exeuting for... 30
Exeuting for... 31
Exeuting for... 32
2
D
On Wednesday, 6 March 2013 22:11:43 UTC+11, Achint Sandhu wrote:
Hi,
In the sample code below, I'd like to rerun the first value that returns a
non-nil result upon the application of a function (foo in the code sample
below). In the real use case , the computation of the function is
expensive, so I'd only like to run foo until I find the first non-nil value.
Looking at the documentation for map indicates that it is lazy and does
what I need.
user (doc map)
-
clojure.core/map
([f coll] [f c1 c2] [f c1 c2 c3] [f c1 c2 c3 colls])
Returns a lazy sequence consisting of the result of applying f to the
set of first items of each coll, followed by applying f to the set
of second items in each coll, until any one of the colls is
exhausted. Any remaining items in other colls are ignored. Function
f should accept number-of-colls arguments.
nil
I believe the idiomatic way to write this in clojure would be:
user (clojure-version)
1.5.0
user (defn foo [x] (println Exeuting for... x) (when (even? x) x))
#'user/foo
user (foo 10)
Exeuting for... 10
10
user (foo 1)
Exeuting for... 1
nil
user (first (remove nil? (map foo '(1 3 5 2 7 6
Exeuting for... 1
Exeuting for... 3
Exeuting for... 5
Exeuting for... 2
2
user (first (remove nil? (map foo #{1 3 5 2 7 6})))
Exeuting for... 1
Exeuting for... 2
2
This works as expected, however when the collection is a vector, the
mapping is no longer lazy.
user (first (remove nil? (map foo [1 3 5 2 7 6])))
Exeuting for... 1
Exeuting for... 3
Exeuting for... 5
Exeuting for... 2
Exeuting for... 7
Exeuting for... 6
2
I would have expected map's behaviour to be agnostic of the collection
type passed in, but it appears not to be the case.
Insight into this would be greatly appreciated.
Thank you.
Cheers,
Achint
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
args destructuring in functions?
a minor thing. which do you prefer? (defn blah [x y zs] ...) , or, (defn blah [x y zs] ...) clojure core usually uses the first form. assoc, conj and so forth I have used this because it seems nicer for the caller (blah x y z1 z2 z3) rather than (blah x y [z1 z2 z3]) However, if you regularly use this you end up with apply calls all over the place. so, (defn other-blah [x zs] ...) (defn blah [x y zs] ... (apply other-blah x zs)) If you use the second form you can pass straight through - which seems to decrease code noise. (defn other-blah [x zs] ...) (defn blah [x y zs] ... (other-blah x zs)) and looks better to me. Dave -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ClojureScript] features expression
Honestly, writing clear understandable code is hard enough already. I have voiced this opinion before in other discussions on this topic - but my view is that inline feature expressions should be used very sparingly. And preferably, there should also be other options for portability - e.g. separated specific source. I like what kevin lynagh did with cljx. But this doesn't mean that it is the answer for all platform variation problems. The idea of multiple lines of conditional preprocessing in my (or, worse for me, in your) source and then having to mentally resolve from that what gets compiled for a particular platform sounds like a recipe for guaranteed confusion and a bug finding horror. The only way you could make that work would be with very good tooling. And I won't be holding my breath for that just yet. I really want some portability enhancements - but it has to be manageable. otherwise it's going to take more effort than it saves. Dave On Wednesday, 6 March 2013 05:44:14 UTC+11, Brandon Bloom wrote: I personally think the CL feature expression approach is satisfactory. The more I think about it, the less I think that the CL Feature Expression approach is satisfactory as is. I'm now reasonably convinced that, horror of horrors, we should look to the C preprocessor for inspiration. CL's approach only provides flags, not key/value pairs. Also, the CL approach does not provide a structured form for if/else or cond expressions and has only limited and/or/not predicate combinators. Experience in writing portable C code has proven that == and = are important for checking version numbers and feature levels. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
printing and reading functions
This may be a question for clojure dev
I find myself wanting to be able to print data-structures containing
resolvable functions
e.g.
(let [x assoc] (str [x :a :b]))
would be:
[#fn clojure.core/assoc :a :b]
or similar, rather than the current:
[#core$assoc clojure.core$assoc@6d289e48 :a :b]
which is unreadable.
I can read this tag very easily, using the data-reader
{fn resolve} or,
(set! *data-readers* {'fn resolve})
But I don't know of any way to get the name and namespace of a function to
write it out.
I think this is not possible at the moment.
Anyone?
Thanks
Dave
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: printing and reading functions
I think, that will only work if you do it directly.
It will not work in the example I gave.
Dave
On Sunday, 3 March 2013 22:43:14 UTC+11, AtKaaZ wrote:
On Sun, Mar 3, 2013 at 12:21 PM, Dave Sann dave...@gmail.comjavascript:
wrote:
This may be a question for clojure dev
I find myself wanting to be able to print data-structures containing
resolvable functions
e.g.
(let [x assoc] (str [x :a :b]))
would be:
[#fn clojure.core/assoc :a :b]
or similar, rather than the current:
[#core$assoc clojure.core$assoc@6d289e48 :a :b]
which is unreadable.
I can read this tag very easily, using the data-reader
{fn resolve} or,
(set! *data-readers* {'fn resolve})
But I don't know of any way to get the name and namespace of a function
to write it out.
Did you mean this?
= (meta #'assoc)
{:ns #Namespace clojure.core, :name assoc, :arglists ([map key val] [map
key val kvs]), :column 1, :added 1.0, :static true, :doc assoc[iate].
When applied to a map, returns a new map of the\nsame (hashed/sorted)
type, that contains the mapping of key(s) to\nval(s). When applied to a
vector, returns a new vector that\ncontains val at index. Note - index
must be = (count vector)., :line 177, :file clojure/core.clj}
I think this is not possible at the moment.
Anyone?
Thanks
Dave
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.comjavascript:
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com javascript:
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+u...@googlegroups.com javascript:.
For more options, visit https://groups.google.com/groups/opt_out.
--
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate it.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: printing and reading functions
because it is a macro, I am not sure it can work for y. (my macro skills
are limited)
but in the general case where the data is not available at compile time. I
am not sure macros will help.
On Sunday, 3 March 2013 23:44:56 UTC+11, AtKaaZ wrote:
oo, what do we have here?
= (defmacro get-lexical-asvar [q]
(let [
oem (zipmap (keys env) (vals env))
zz (.var (.init (second (find oem q
]
`~zz
)
)
#'runtime.q/get-lexical-asvar
= (let [x assoc
y x]
(str (get-lexical-asvar x))
)
#'clojure.core/assoc
but it doesn't (yeT) work for y
On Sun, Mar 3, 2013 at 1:27 PM, AtKaaZ atk...@gmail.com javascript:wrote:
ok you're right, it's impossible to get the var since those x and y are
already resolved to the function, and multiple vars could point to the same
function anyway.
= (let [x assoc
y x]
(get-lexical-env)
)
{x #core$assoc clojure.core$assoc@35fcd90c, y #core$assoc
clojure.core$assoc@35fcd90c}
for consistency, ignore the following:
;the following is inspired from
http://blog.jayfields.com/2011/02/clojure-and.html
(defmacro get-lexical-env []
= (let [a 1 b (+ 1 2)]
(let [c (do \a\ \b\)]
(q/get-lexical-env)
)
)
{a 1, b 3, c \b\}
(let [envkeys (keys env)]
`(zipmap (quote ~envkeys) (list ~@envkeys))
)
)
(defmacro show-lexical-env []
`(clojure.pprint/pprint (get-lexical-env))
)
On Sun, Mar 3, 2013 at 1:05 PM, AtKaaZ atk...@gmail.com javascript:wrote:
that's true but I thought you meant in general
basically, I'm looking for a way to get the var... ie.
= (let [x assoc
y x]
*(var y)*
)
CompilerException java.lang.RuntimeException: Unable to resolve var: y
in this context, compiling:(NO_SOURCE_PATH:3:3)
= (let [x assoc
y x]
y
)
#core$assoc clojure.core$assoc@35fcd90c
= (var assoc)
#'clojure.core/assoc
something that can replace that (var y) with something that actually
gets the var that y resolves to.
On Sun, Mar 3, 2013 at 12:58 PM, Dave Sann dave...@gmail.comjavascript:
wrote:
I think, that will only work if you do it directly.
It will not work in the example I gave.
Dave
On Sunday, 3 March 2013 22:43:14 UTC+11, AtKaaZ wrote:
On Sun, Mar 3, 2013 at 12:21 PM, Dave Sann dave...@gmail.com wrote:
This may be a question for clojure dev
I find myself wanting to be able to print data-structures containing
resolvable functions
e.g.
(let [x assoc] (str [x :a :b]))
would be:
[#fn clojure.core/assoc :a :b]
or similar, rather than the current:
[#core$assoc clojure.core$assoc@6d289e48 :a :b]
which is unreadable.
I can read this tag very easily, using the data-reader
{fn resolve} or,
(set! *data-readers* {'fn resolve})
But I don't know of any way to get the name and namespace of a
function to write it out.
Did you mean this?
= (meta #'assoc)
{:ns #Namespace clojure.core, :name assoc, :arglists ([map key val]
[map key val kvs]), :column 1, :added 1.0, :static true, :doc
assoc[iate]. When applied to a map, returns a new map of the\nsame
(hashed/sorted) type, that contains the mapping of key(s) to\nval(s).
When applied to a vector, returns a new vector that\ncontains val at
index. Note - index must be = (count vector)., :line 177, :file
clojure/core.clj}
I think this is not possible at the moment.
Anyone?
Thanks
Dave
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+u...@**googlegroups.com
For more options, visit this group at
http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups Clojure group.
To unsubscribe from this group and stop receiving emails from it,
send an email to clojure+u...@**googlegroups.com.
For more options, visit
https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.
--
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate it.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.comjavascript:
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com javascript:
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
Re: printing and reading functions
Thanks Phil. Is there an Jira issue for this? Is it worth raising one? I noted that my requirement is slightly different from yours. I want to print the function by name (and namespace) only. Serializable-fn prints the full definition. But this difference is only in print-method - if the meta-data were available on the function, both would be possible depending on need. Dave On Monday, 4 March 2013 02:50:36 UTC+11, Phil Hagelberg wrote: Getting at the var won't work, but you can get fns to print readably with their source using https://github.com/technomancy/serializable-fn Unfortunately you still have the problem that whoever defined it has to opt in. Ohil -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
(def function* ... ???
I see cases of * after function names. Can anyone enlighten me as to the specific meaning of this, if any. Is it specific to some clojure uses or more widely employed. thanks Dave -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: what on earth is happening?
Jim, I'm not answering your question here. but the subject you have chosen is not very descriptive of your problem/question/topic. On Friday, 1 March 2013 01:23:22 UTC+11, Jim foo.bar wrote: I've got a project 1. I can *'lein2 repl'* in it and navigate to any namespace - no problem 2. I can *'lein2 check'* it and it compiles everything - no problem 3. I can *'lein2 test'* or *'lein2 test some-namespace'* and BOOM! - * PROBLEM! * *Exception in thread main java.lang.VerifyError: (class: hotel_nlp/concretions/models/Workflow, method: run signature: ()Ljava/lang/Object;) Unable to pop operand off an empty stack, compiling:(hotel_nlp/concretions/models.clj:68:1)* * *What on earth does that mean? I've never had that before!!! The 'models' namespace has not been modified for 3 days now so it can't be the culprit! The thing is I don't understand the error message! anyone? going slightly mental here! To add to the confusion, sometimes the same thing happens with 'lein2 repl' + 'load' but only *some* times. Most times it doesn't complain ! I'm not AOT-ing... Jim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: In order to get java-like performance, one needs to write java-like code first?
Performance at doing what? why? what are your requirements and what is important to you? Your question is simple but can generate extensive debate. Don't expect a yes/no answer. See this extensive discussion and examples: https://groups.google.com/d/topic/clojure/byHO-9t6X4U/discussion it's funny how the phrase java-like performance is now used as a moniker for fast. when Java came out the phrase was c-like performance. when C came out, probably assembler-like ..its even faster if you build it in hardware too... just maybe not flexible in the way you would like. Dave On Friday, 1 March 2013 15:35:16 UTC+11, yizhen wei wrote: I just start learning clojure recently. So I was looking for some performance related post on the internet, and found some optimization tips, fast clojure code and so on. Which lead to the question above. It seems like most of the time we have to write longer, more java-like code (which I found less readable to java equivalence) to catch up java's speed. Is that just the trade-off we need to make in order to type less character? What is the difference in performance between true clojure (without using type hint or other java stuffs) and java? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: documentation for clojure core extension points - multimethods and protocols?
I did this. There are actually not many protocols. Likely because most of the original underlying implementation in terms of java interfaces. Few multi-methods beyond print-method stood out. I can post the output if anyone is interested. Dave On Friday, 22 February 2013 21:51:06 UTC+11, Andrew Sernyak wrote: I guess you should just grep clojure core source for defprotocol, defmulti and so on. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: documentation for clojure core extension points - multimethods and protocols?
This is for 1.4.0. Multi methods.
(Filenames come after)
(the two methods in dispatch are: simple-dispatch, code-dispatch
add -A 1 option to the grep to see this)
$ find . -name *.clj -exec grep defmulti \{\} \; -print -printf \n
(defmulti
(defmulti
./src/clj/clojure/pprint/dispatch.clj
(defmulti ^{:private true} write-token #(:type-tag %2))
(defmulti ^{:private true} emit-nl? (fn [t _ _ _] (:type t)))
(defmulti ^{:private true} tok :type-tag)
./src/clj/clojure/pprint/pretty_writer.clj
(defmulti
./src/clj/clojure/java/io.clj
(defmacro defmulti
(throw (Exception. The syntax for defmulti has changed. Example:
(defmulti name dispatch-fn :default dispatch-value
(defmulti print-method (fn [x writer]
(defmulti print-dup (fn [x writer] (class x)))
./src/clj/clojure/core.clj
(defmulti is-leaf collection-tag)
(defmulti get-child (fn [parent index] (collection-tag parent)))
(defmulti get-child-count collection-tag)
(defmulti list-provider class)
(defmulti table-model class)
./src/clj/clojure/inspector.clj
(defmulti ^:dynamic junit-report :type)
./src/clj/clojure/test/junit.clj
(defmulti ^:dynamic tap-report (fn [data] (:type data)))
./src/clj/clojure/test/tap.clj
(defmulti
(defmulti assert-expr
(defmulti use-fixtures
./src/clj/clojure/test.clj
(defmulti
./test/clojure/test_clojure/pprint/test_pretty.clj
; defmulti
./test/clojure/test_clojure/multimethods.clj
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: documentation for clojure core extension points - multimethods and protocols?
1.4.0 protocols
$ find . -name *.clj -exec grep defprotocol \{\} \; -print -printf \n
(defprotocol Reflector
(defprotocol TypeReference
./src/clj/clojure/reflect.clj
(defprotocol ClassResolver
./src/clj/clojure/reflect/java.clj
(defprotocol ^{:added 1.2} Coercions
(defprotocol ^{:added 1.2} IOFactory
./src/clj/clojure/java/io.clj
(defprotocol ^{:added 1.3} EqualityPartition
(defprotocol ^{:added 1.3} Diff
./src/clj/clojure/data.clj
(defmacro defprotocol
(defprotocol AProtocolName
Java parlance). defprotocol is dynamic, has no special compile-time
defprotocol will automatically generate a corresponding interface,
(defprotocol P
./src/clj/clojure/core_deftype.clj
(defprotocol CollReduce
(defprotocol InternalReduce
(defprotocol IKVReduce
./src/clj/clojure/core/protocols.clj
(defprotocol HintedProtocol
./test/clojure/test_clojure/compilation.clj
(eval '(defprotocol Elusive (old-method [x])))
(eval '(defprotocol Elusive (new-method [x])))
(defprotocol SyntaxQuoteTestProtocol
./test/clojure/test_clojure/protocols.clj
(defprotocol TestProtocolA
(defprotocol TestProtocolB
./test/clojure/test_clojure/protocols/hash_collisions.clj
(defprotocol ExampleProtocol
./test/clojure/test_clojure/protocols/examples.clj
(defprotocol SimpleProtocol
./test/clojure/test_clojure/protocols/more_examples.clj
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
documentation for clojure core extension points - multimethods and protocols?
Does anyone have a good source of summary documentation for core clojure extension points My this I mean either defined multi-methods that are intended to be extended, such as print-method, or Protocols that are intended to be re-used? Is there similar for clojurescript? just curious at the moment. ta Dave -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: RC 16: Last chance to test against Clojure 1.5 before it ships
I don't expect this to go into 1.5.
But the point raised by vemv is a good one.
Clojurescript makes ExceptionInfo available by default. If this were also
the case in clojure - it would help with portable code. Specifically
catching ExceptionInfo. (longer comments on the thread referenced
previously).
Dave
On Monday, 18 February 2013 12:18:15 UTC+11, Dave Sann wrote:
timely comment.
you can create and throw it but catching it requires the imported type.
(not withstanding catching the generic Exception on the JVM).
see the link for suggestion/discussion on making this more uniform for
clj and cljs:
https://groups.google.com/d/topic/clojurescript/A3wH_Hm3OmQ/discussion
Dave
On Monday, 18 February 2013 03:54:00 UTC+11, Baishampayan Ghose wrote:
You can create an ExceptionInfo instance easily by using the core fn
`ex-info`. So something like ... (throw (ex-info {:foo bar})) works
fine. ~BG
On Sun, Feb 17, 2013 at 10:05 PM, vemv ve...@vemv.net wrote:
Couldn't clojure.lang.ExceptionInfo be imported by default? That'd
surely
help making ExceptionInfo the idiomatic exception to be thrown.
On Thursday, February 14, 2013 4:33:42 AM UTC+1,
stuart@gmail.comwrote:
If you care about Clojure 1.5 compatibility for your codebase, please
test
it against RC 16 as soon as possible.
You can get the source and build it yourself from [1], or wait for
Maven
Central [2] to pick up the CI build, which usually takes a few hours.
Thanks!
Stu
[1] https://github.com/clojure/clojure
[2] http://bit.ly/WEnjAi
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with
your
first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Baishampayan Ghose
b.ghose at gmail.com
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: RC 16: Last chance to test against Clojure 1.5 before it ships
timely comment.
you can create and throw it but catching it requires the imported type.
(not withstanding catching the generic Exception on the JVM).
see the link for suggestion/discussion on making this more uniform for
clj and cljs:
https://groups.google.com/d/topic/clojurescript/A3wH_Hm3OmQ/discussion
Dave
On Monday, 18 February 2013 03:54:00 UTC+11, Baishampayan Ghose wrote:
You can create an ExceptionInfo instance easily by using the core fn
`ex-info`. So something like ... (throw (ex-info {:foo bar})) works
fine. ~BG
On Sun, Feb 17, 2013 at 10:05 PM, vemv ve...@vemv.net javascript:
wrote:
Couldn't clojure.lang.ExceptionInfo be imported by default? That'd
surely
help making ExceptionInfo the idiomatic exception to be thrown.
On Thursday, February 14, 2013 4:33:42 AM UTC+1, stuart@gmail.comwrote:
If you care about Clojure 1.5 compatibility for your codebase, please
test
it against RC 16 as soon as possible.
You can get the source and build it yourself from [1], or wait for
Maven
Central [2] to pick up the CI build, which usually takes a few hours.
Thanks!
Stu
[1] https://github.com/clojure/clojure
[2] http://bit.ly/WEnjAi
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.comjavascript:
Note that posts from new members are moderated - please be patient with
your
first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com javascript:
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to clojure+u...@googlegroups.com javascript:.
For more options, visit https://groups.google.com/groups/opt_out.
--
Baishampayan Ghose
b.ghose at gmail.com
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: :use an entire namespace full of protocols or stick with :require?
I don't like :use because I can't tell where things come from. require :refer [...] is good is you don't want the prefix. On Friday, 15 February 2013 00:26:50 UTC+11, Jim foo.bar wrote: I know that using a bare :use in the ns macro is generally frowned upon as it provides no hints about what is actually being used... However, I 've got 2 namespaces 'abstractions.clj' and 'concretions.clj'...concretions.clj will eventually use all the protocols defined in abstractions.clj...at the moment it doesn't but as I work through it I want to provide concrete records for *all* the protocols... Should I just go and :use the entire thing or should I stick with :require and keep typing 'pro/XXX' a million times? That specific namespace is very central to my work... Jim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure, Heroku and the dreaded R10 Boot Timeout Error
Maybe this past post helps https://groups.google.com/d/topic/clojure/tU1LJOXiDc4/discussion D On Thursday, 14 February 2013 14:12:07 UTC+11, Leonardo Borges wrote: Hi Timothy, I should have mentioned I'm using lein2. Heroku performs AOT compilation for you by default when that's the case. Cheers, Leonardo Borges www.leonardoborges.com On Thu, Feb 14, 2013 at 1:30 PM, Timothy Licata timothy...@gmail.com javascript: wrote: Hi Leonardo, I ran into something similar a while ago. To get around it, I setup :aot compilation. heroku config:add LEIN_BUILD_TASK=compile :all However, in order for config vars to work, I had to install the labs plugin and enable user_env_compile. heroku plugins:install http://github.com/heroku/heroku-labs.git heroku labs:enable user_env_compile -a app-name I am not sure if this info is up-to-date or if it applies to your situation, but I thought I'd mention it. Tim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure - Python Style suggestion
yes, I did not mean to imply otherwise. On Friday, 8 February 2013 09:04:43 UTC+11, Jason Lewis wrote: `quote` is a feature, not a bug. Its not just for distinguishing between lists and function calls, its for deferring evaluation. Its also been part of Lisp since the beginning... IIRC, its in McCarthy's paper that defined the first lisp. On Feb 4, 2013 7:58 PM, Dave Sann dave...@gmail.com javascript: wrote: The syntax does complect in one case. When you really do want a list as opposed to a function call. hence quote and (list ...) On Tuesday, 5 February 2013 07:06:37 UTC+11, tbc++ wrote: Parens actually don't complect, they have a very very clear meaning. They organize functions and arguments. Let's take one line from your example: filter smaller xs Sois that the python equivalent to which of these? filter(smaller(xs)) filter(smaller, xs) filter(smaller(), xs()) filter(smaller(xs())) I would also assert that Python complects formatting and semantic meaning of the code. I'm quite proficient at Python and even I hate that fact. Timothy On Mon, Feb 4, 2013 at 1:01 PM, Sergey Didenko sergey@gmail.comwrote: Hi, For us as Clojure community it is easy to see how Clojure benefits from being a Lisp. Homoiconity, extreme conciseness, esoteric look and feel, etc. However it is hard to see from the inside how Clojure as ecosystem (probably) suffer from being a Lisp. Please don't throw rotten eggs at me, I mean only the part of Lisp that is ... parentheses. I remember a number of people that mention parentheses as obstacles to the wider Clojure adoption, in the Clojure space - in the Clojure related discussions, even on this mailing list IIRC. But the number of people thinking this way outside the Clojure groups is even bigger! We probably don't notice it because got immune to this famous argument it has too many parentheses early when diving into Clojure. I suggest there are a big number of people that could gain interest in clojure if we provide them with parentheses-lite Clojure syntax. For example we can steal Python way of intending blocks. For example the following quicksort implementation (defn qsort [[pivot xs]] (when pivot (let [smaller #( % pivot)] (lazy-cat (qsort (filter smaller xs)) [pivot] (qsort (remove smaller xs)) could be written as (set! python-style-op-op true) defn qsort [[pivot xs]] when pivot let [smaller #( % pivot)] lazy-cat qsort filter smaller xs [pivot] qsort remove smaller xs What do you think? Isn't is less complex? P.S. Ok, I must confess, the mention of the C-Word in the last sentence was just a desperate way to get Rich's attention. P.P.S. Actually I would also love to see Clojure community making video clip Clojure - Python Style as a remix for G... Style, but this idea is probably way ahead of its time. Regards, Sergey. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@**googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@**googlegroups.com. For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post
Re: dictionary sort in sortedmap
http://clojuredocs.org/clojure_core/clojure.core/sorted-map-by
On Monday, 4 February 2013 21:37:13 UTC+11, Amir Wasim wrote:
I want to sort a map by its keys according to dictionary when i do the
following
(into (sorted-map) {1 A 2 B 11 C 3 D})
the result is
{1 A, 11 C, 2 B, 3 D}
which is expected result but what i expect is dictionary sort, {1 A,
2 B, 3 D, 11 C}. is there something in clojure or i just go with
java Collator
thanks
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure - Python Style suggestion
The syntax does complect in one case. When you really do want a list as opposed to a function call. hence quote and (list ...) On Tuesday, 5 February 2013 07:06:37 UTC+11, tbc++ wrote: Parens actually don't complect, they have a very very clear meaning. They organize functions and arguments. Let's take one line from your example: filter smaller xs Sois that the python equivalent to which of these? filter(smaller(xs)) filter(smaller, xs) filter(smaller(), xs()) filter(smaller(xs())) I would also assert that Python complects formatting and semantic meaning of the code. I'm quite proficient at Python and even I hate that fact. Timothy On Mon, Feb 4, 2013 at 1:01 PM, Sergey Didenko sergey@gmail.comjavascript: wrote: Hi, For us as Clojure community it is easy to see how Clojure benefits from being a Lisp. Homoiconity, extreme conciseness, esoteric look and feel, etc. However it is hard to see from the inside how Clojure as ecosystem (probably) suffer from being a Lisp. Please don't throw rotten eggs at me, I mean only the part of Lisp that is ... parentheses. I remember a number of people that mention parentheses as obstacles to the wider Clojure adoption, in the Clojure space - in the Clojure related discussions, even on this mailing list IIRC. But the number of people thinking this way outside the Clojure groups is even bigger! We probably don't notice it because got immune to this famous argument it has too many parentheses early when diving into Clojure. I suggest there are a big number of people that could gain interest in clojure if we provide them with parentheses-lite Clojure syntax. For example we can steal Python way of intending blocks. For example the following quicksort implementation (defn qsort [[pivot xs]] (when pivot (let [smaller #( % pivot)] (lazy-cat (qsort (filter smaller xs)) [pivot] (qsort (remove smaller xs)) could be written as (set! python-style-op-op true) defn qsort [[pivot xs]] when pivot let [smaller #( % pivot)] lazy-cat qsort filter smaller xs [pivot] qsort remove smaller xs What do you think? Isn't is less complex? P.S. Ok, I must confess, the mention of the C-Word in the last sentence was just a desperate way to get Rich's attention. P.P.S. Actually I would also love to see Clojure community making video clip Clojure - Python Style as a remix for G... Style, but this idea is probably way ahead of its time. Regards, Sergey. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Help with Clojurescript + DOM Manipulation
map is lazy so your console log is never done. use (doall ...) Dave On Thursday, 24 January 2013 12:38:37 UTC+11, Ari wrote: Hi, The following clojurescript code is *supposed* to identify all anchor tags and print them (originally, I was trying to attach listeners and callbacks); unfortunately, I can't get it to work. Confusingly, there are no compilation or runtime errors. Anyone see what could be wrong? Thanks. Note: Code uses jayq 2.0.0 lein-cljsbuild 0.2.10 --CLJS-- (ns myapp.example (:use [jayq.core :only [$]]) (:use-macros [jayq.macros :only [ready]])) (def links ($ :a)) (defn listen-to [links] (map (fn [link] (.log js/console link) links))) (ready (listen-to links)) --HTML-- !DOCTYPE html html head script type=text/javascript src=.../script /head body ul lia href=#firstFirst/a/li lia href=#secondSecond/a/li lia href=#thirdThird/a/li /ul /body /html -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Is contributing to clojurescript is intentionally made hard ?
It is great that questions are being asked about how things do, might or should work - but tone of the original question and the ensuing discussion, in my view, unfortunate. On Sunday, 20 January 2013 17:36:11 UTC+11, Irakli Gozalishvili wrote: Anyway it's seems to me that message in this thread is pretty clear: We're just doing fine without people like you It's a shame, but whatever I'll just shut up and let you guys roll as you pleased Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ On Saturday, 2013-01-19 at 22:31 , Irakli Gozalishvili wrote: I would be curious to also see number of lost contributors. Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ On Saturday, 2013-01-19 at 22:00 , David Nolen wrote: I have nothing to add to this thread beyond pointing out that ClojureScript has had _51_ contributors in the short year and a half of its existence: http://github.com/clojure/clojurescript/graphs/contributors. Via JIRA. David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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: Reader syntax for uri objects
why not just print/send your uris as strings?
you only need a reader tag if you want to read/interpret it in a particular
way at read time in the client. do you want to do this?
D
On Thursday, 10 January 2013 12:20:53 UTC+11, Taylor Sando wrote:
I am looking for a way to transfer URI objects from a clojure client to a
clojurescript client. The printed representation of a java.net.URI object
is #URI http//www.example.com The problem is that I can't read in
this data when it's structured like that. For example, I'd like to be able
to pass this data strucutre to the client {:uri #URI
http://www.google.com}. From my understanding, the extensible reader
needs something in the form of #symbol [value].
I know how to extend the clojurescript reader:
(defn make-url [stuff]
(str (first stuff)))
(reader/register-tag-parser! 'URI make-url)
(assert (= http://www.google.com; (reader/read-string #URI [
http://www.google.com];)))
I know that I could just map over the data structure and convert the uris
to strings, and then send that to the client, but it seems like there
should be a better way.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Delay with atom
Create the atom in a let, in the function - so it's new and isolated better still - use an accumulator in the loop, not an atom. take, map an others are lazy. you may need to (doall ...) Dave On Thursday, 10 January 2013 08:22:57 UTC+11, Simone Mosciatti wrote: Hi everybody, I was implementing a skip list, just for fun. I implemented the list and just to be sure that it were working I wanted to count how many steps it compute to find a value. SkipList -- http://en.wikipedia.org/wiki/Skip_list To do so I was using a atom, and the code looks like this: (def c (atom 0)) (defn search-n-count [s n] (letfn [(search-fn [s n] (reset! c 0) ;; I restart to count (loop [s s] (swap! c inc) ;; add a passage to the counter (when (seq s) (let [v (first s)] (cond ( v n) false (== v n) n ( v n) (recur (rest s)))] [(take 1 (drop-while #(or (false? %1) (nil? %1)) (map search-fn s (repeat n @c])) ;;the take and everything looks horrible, but I didn't find anything better, any ideas ? However the value that I get simply doesn't makes any sense, sometimes it looks like I get a value that could refer to the previous computation... Where is the problem ? If you don't get the code I can comment better the code, just let me know... Here the whole code and some example: https://gist.github.com/4497077 Thanks for any help :-) Simone -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Reader syntax for uri objects
It's not going to be easy to read the #URI form in clojurescript I think.
On the server, I would extend the the print-string (I think its called this
- you will need to look at the core source code) multi-method. You can use
this to make javaURI print as a string or as a tagged literal if you
need it.
D
On Thursday, 10 January 2013 12:42:33 UTC+11, Taylor Sando wrote:
The URIs are coming from a datomic database that actually stores the
values as java.net.URIs. All I'm doing is transferring the query values
from the database to the client. The server uses pr-str before sending
back the results, and the client uses reader/read-string to get the
results.
On Wednesday, January 9, 2013 7:35:31 PM UTC-6, Dave Sann wrote:
why not just print/send your uris as strings?
you only need a reader tag if you want to read/interpret it in a
particular way at read time in the client. do you want to do this?
D
On Thursday, 10 January 2013 12:20:53 UTC+11, Taylor Sando wrote:
I am looking for a way to transfer URI objects from a clojure client to
a clojurescript client. The printed representation of a java.net.URI
object is #URI http//www.example.com The problem is that I can't
read in this data when it's structured like that. For example, I'd like to
be able to pass this data strucutre to the client {:uri #URI
http://www.google.com}. From my understanding, the extensible reader
needs something in the form of #symbol [value].
I know how to extend the clojurescript reader:
(defn make-url [stuff]
(str (first stuff)))
(reader/register-tag-parser! 'URI make-url)
(assert (= http://www.google.com; (reader/read-string #URI [
http://www.google.com];)))
I know that I could just map over the data structure and convert the
uris to strings, and then send that to the client, but it seems like there
should be a better way.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Feature Expressions
there have been a number of previous discussions FYI. This was one I could find: https://groups.google.com/d/topic/clojure/LQcBEph-3Bg/discussion On Tuesday, 8 January 2013 22:24:26 UTC+11, Irakli Gozalishvili wrote: Hi Folks, I wanted to comment on Feature Expressions feature page, but it looks like special privileges are required, so I thought I'd post my questions / feedback here. I've being working on client side JS for a while and I'm well aware of hazards associated with platform specific code branching. Although solution that in my experience worked best, was move to more granular a codebase, isolating platform specific code from a common one. I think this would be a great direction for clojure / clojurescript ? As a matter of fact it would be tremendous help for newcomers like myself to have a baseline libraries abstracting platform differences that would not assume specific backgrounds in Java or JS. Please don't take this a wrong way, but I do believe most problems are not caused by inability to switch between platform specific code, but rather by a lack of baseline that would allow writing a common code. Here are few examples: Otherwise perfectly portable clojure compatible clojurescript code won't work because in clojurescript one needs to extend default type while in clojure it's Object instead. I don't know actual reason here but have a feeling that common thing could be created that would work for both. https://github.com/Gozala/eventual-cljs/blob/master/src/core.cljs#L26 Another interesting case is try special form which clearly does not fits JS since catching exceptions by a classname does not really make much sense there. http://clojure.org/special_forms#try Also as far as I can tell in order to throw an exception one need to either access js/Error or one of Exception classes on Java. I do believe identifying fixing such cases, so that non platform specific code could be written without accessing platform specific constructs would solve most of the issues without introducing further complexity. In fact it would make platform more accessible for others. Another thing I wanted to point out was racket's submodules which may be another interesting option to consider: http://blog.racket-lang.org/2012/06/submodules.html P.S: My apologies, if some of my comments are incorrect it could be that I'm still missing important parts of the puzzle. Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.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: [ANN] Dire, Erlang-style error handling
I see joe's thesis is linked on your github page. is this thesis the paper you are referring to? Do you have a link to the video you refer to? thanks Dave On Saturday, 29 December 2012 06:14:34 UTC+11, Michael Drogalis wrote: Hey folks, After watching The Language of the System and being directed to Joe Armstrong's paper on error handling, I concurred that his approach is fantastic. I really wanted the same thing for more rudimentary operations, like file handling. So I wrote Dire https://github.com/MichaelDrogalis/dire The pros are of this are that error handling code is removed from application logic and it is not order complected. The cons are that tasks are not as strongly isolated as they are in Erlang. Also, because it is so simple (16 lines), there's no way for a supervisor to restart a child task. (Yet, I guess. Ideas?) Can such a thing be useful in a non-distributed environment? Or does this look like a hassle to use? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: leiningen and updating project versions
Hi Frank, I do use checkouts (i.e symlinked to the project). The main reason I don't do what you suggest is that the jar dependencies of checkouts are not automatically picked up transitively which can lead to some fiddly problems. I used to use lein-deps-shares for this but do not any more. see: https://groups.google.com/d/topic/leiningen/lArvYZx72wc/discussion. If you want transitive jar dependencies correctly included in your project - you must go through an install process - because leiningen takes dependencies from the project.clj not from checkouts (unless this has changed). It was a long shot - I thought maybe someone had come up with a plugin :) D On Monday, 10 December 2012 06:50:47 UTC+11, FrankS wrote: When I'm working on a number of interdependent projects, I'm making symbolic links of the src directories of the dependent project inside my main project. In that way, I can easily make changes in the multiple projects without having to go thru the update version/jar/pom/install cycles for all associated projects, because the source changes are automatically picked-up when i remake the main project. Only after all works, you can remove the links and add the dependencies to project.clj... And test again ;-) Enjoy, Frank. On Dec 9, 2012, at 12:18 AM, Dave Sann dave...@gmail.com javascript: wrote: Has anyone looked at how to manage snapshots and dependencies in projects with checkouts - where the checkouts (also snapshots) are being edited along with the main project? As I look at my layers of projects, they looks like a lot of rather tedious manual work for each project to: bump the project version; check dependency versions are correct; commit; install; bump project version to the next snapshot; commit; check dependency versions are correct snapshots; ...etc. I am curious as to whether anyone has an effective way of dealing with this? Dave -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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
leiningen and updating project versions
Has anyone looked at how to manage snapshots and dependencies in projects with checkouts - where the checkouts (also snapshots) are being edited along with the main project? As I look at my layers of projects, they looks like a lot of rather tedious manual work for each project to: bump the project version; check dependency versions are correct; commit; install; bump project version to the next snapshot; commit; check dependency versions are correct snapshots; ...etc. I am curious as to whether anyone has an effective way of dealing with this? Dave -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: a question for crate and hiccup
I hadn't considered a need to generate html strings on the browser (at
least, not for performance). Do you have any references that demonstrate
that it is faster to parse strings than generate dom elements directly with
the js dom api. That seems counter-intuitive to me.
D
On Monday, 26 November 2012 01:51:30 UTC+11, Max Penet wrote:
Strong +1
This is a great idea.
This would allow more flexibility in some corner cases and
prevent unnecessary duplication, not to mention sharing.
Another example: I believe crate compiles templates using the DOM API,
which is often fine, but sometimes you'd want it to do this using raw
strings (when working with a large number of Elements), for performance
reason. This would help to solve such issues.
Max
On Sunday, November 25, 2012 12:11:09 PM UTC+1, Dave Sann wrote:
I wonder if it would be worth making the effort to separate the hiccup
rendering from the hiccup generation in these libraries.
By hiccup generation, I mean constructing data of the form [:tag {:attr
val} contents] ...
By rendering, I mean
in the case of hiccup - producing HTML strings
in the case of crate - directly producing DOM nodes in the browser
My thought is that this would give a generic set of hiccup data
generating functions that could be easily used across both libs with
rendering specific to the environment.
I don't generally use the libs in hiccup or crate because they are not
portable and slightly inconsistent in places - all my hiccup data
generation code can run on the server or on the browser. It might be good
to have a core unified set for both...
thoughts?
Dave
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: clojurescript: ex-info and ex-data
added http://dev.clojure.org/jira/browse/CLJS-429 for now On Monday, 26 November 2012 04:57:39 UTC+11, David Nolen wrote: Agreed. Patches welcome! On Saturday, November 24, 2012, Dave Sann wrote: Is there a plan to add these? It seems like a step towards more generic exception handling between clj and cljs code. Dave -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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
a question for crate and hiccup
I wonder if it would be worth making the effort to separate the hiccup
rendering from the hiccup generation in these libraries.
By hiccup generation, I mean constructing data of the form [:tag {:attr
val} contents] ...
By rendering, I mean
in the case of hiccup - producing HTML strings
in the case of crate - directly producing DOM nodes in the browser
My thought is that this would give a generic set of hiccup data generating
functions that could be easily used across both libs with rendering
specific to the environment.
I don't generally use the libs in hiccup or crate because they are not
portable and slightly inconsistent in places - all my hiccup data
generation code can run on the server or on the browser. It might be good
to have a core unified set for both...
thoughts?
Dave
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
clojurescript: ex-info and ex-data
Is there a plan to add these? It seems like a step towards more generic exception handling between clj and cljs code. Dave -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: what is the simplest user auth system possible?
For authorisation, I really like mozilla persona (previously browserid) which I discovered from refheap. javascript lib plus an http request from the server to validate. really simple. https://login.persona.org/ Dave On Friday, 26 October 2012 01:35:53 UTC+11, Stephen Compall wrote: On Oct 25, 2012 9:04 AM, larry google groups lawrenc...@gmail.comjavascript: wrote: For my next step, I need to come up with a user system. My needs are minimal: I only need to know when someone is logged in, and I need to associate them with some user id (the id will simply be the id from a user table kept in MySql). I am curious what is the absolutely easiest way to do this? The easiest auth system to write is the one that's already written. https://github.com/cemerick/friend -- Stephen Compall If anyone in the MSA is online, you should watch this flythrough. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: what is the simplest user auth system possible?
Sorry, I meant to say authentication. On Friday, 26 October 2012 22:06:48 UTC+11, Dave Sann wrote: For authorisation, I really like mozilla persona (previously browserid) which I discovered from refheap. javascript lib plus an http request from the server to validate. really simple. https://login.persona.org/ Dave On Friday, 26 October 2012 01:35:53 UTC+11, Stephen Compall wrote: On Oct 25, 2012 9:04 AM, larry google groups lawrenc...@gmail.com wrote: For my next step, I need to come up with a user system. My needs are minimal: I only need to know when someone is logged in, and I need to associate them with some user id (the id will simply be the id from a user table kept in MySql). I am curious what is the absolutely easiest way to do this? The easiest auth system to write is the one that's already written. https://github.com/cemerick/friend -- Stephen Compall If anyone in the MSA is online, you should watch this flythrough. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: UTF-8 behavior ClojureScript (vs. Clojure)
I notice this is fixed on clojurescript master. thanks guys. I can now delete my special edition clojure :) On Saturday, 20 October 2012 11:55:23 UTC+11, Chas Emerick wrote: I've filed a CLJS issue for this, and attached a patch: http://dev.clojure.org/jira/browse/CLJS-400 Thanks for keeping on this, Dave. :-) - Chas On Oct 19, 6:18 pm, Dave Sann daves...@gmail.com wrote: Chas, If your patch works without issue - this is probably better because it will then work with existing versions of Clojure - clojurescript is changing faster and people a probably upgrading faster. I don't think it does any harm for Clojure to be able to read these chars but fixing the interchange the the real issue (for me). Stu closed 1025 already. Dave -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Parsing Log Files with Interspersed Multi-line Log Statements
Look at: http://clojuredocs.org/clojure_core/clojure.core/line-seq to get a lazy sequence of lines of the file. I don't think that there is any need to sort here. (I think sorting wont help anyway because some lines are seem to be only identifiable based on the thread id in the current sequence) Process each line and build up the result data structure as you go. http://clojuredocs.org/clojure_core/clojure.core/assoc-in may help you for a nested map. Do not hold on to the head of the line seq and you should be able to process this without too much problem. (if the data structure you build up is itself too large, you may need to write out result data as you see each ReqEnd. In this case, dissoc that record so it can be garbage collected) Dave -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Parsing Log Files with Interspersed Multi-line Log Statements
btw, start simple and just see if you can scan the lines without doing anything in particular. Then take some sub sequence: (take 100 my-line-seq) Play in the repl to start building up the data you want. See what you get and work from there. D On Sunday, 21 October 2012 19:05:42 UTC+11, Dave Sann wrote: Look at: http://clojuredocs.org/clojure_core/clojure.core/line-seq to get a lazy sequence of lines of the file. I don't think that there is any need to sort here. (I think sorting wont help anyway because some lines are seem to be only identifiable based on the thread id in the current sequence) Process each line and build up the result data structure as you go. http://clojuredocs.org/clojure_core/clojure.core/assoc-in may help you for a nested map. Do not hold on to the head of the line seq and you should be able to process this without too much problem. (if the data structure you build up is itself too large, you may need to write out result data as you see each ReqEnd. In this case, dissoc that record so it can be garbage collected) Dave -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
