Re: Composing Stuart Sierra's components
On Tue, Mar 17, 2015 at 5:47 PM, James Gatannah james.gatan...@gmail.com wrote: FWIW, we've been using something that smells an awful lot like nested systems for months now. I never realized we weren't supposed to. It's not that nested systems *never* work, but from what I've seen they cause more complications than they're worth. The 'component' model doesn't forbid it, but it does not support dependencies between components in different subsystems. I've found it easier to keep system maps flat and use namespaced keywords to distinguish subsystem groups, even in large systems with 30+ components. –S -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [GSoC] core.typed Annotations and Macros Proposal
Read code base, submit some patches to get familiar with the process, etc. Also you can reach Ambrose to discuss your idea proposal. Di Xu 2015-03-18 13:29 GMT+08:00 ZhanLin Shang shangzhan...@gmail.com: Hi, Thanks for replying, I've signed the CA and forwarded this post to the core.typed mailing list. Can you tell me what should I do for now? Thanks, Z.Shang On Tuesday, March 17, 2015 at 5:49:34 PM UTC-7, Di Xu wrote: Welcome, I participated core.typed GSoC last year, and happy to see another Chinese student interested in core.typed project, you may forward your email to core.typed mail list[0], also you should first sign CA[1] (if you haven't) before any of your patches get accepted by core.typed or any core clojure library. You may submit some patches to JIRA[2] to make your application stronger. Also read base_env.clj[3] to get yourself familiar with core.typed annotation. Any question is welcomed. [0] https://groups.google.com/forum/#!forum/clojure-core-typed [1] http://clojure.org/contributing [2] http://dev.clojure.org/jira/browse/CTYP [3] https://github.com/clojure/core.typed/blob/ master/module-check/src/main/clojure/clojure/core/typed/base_env.clj Best wishes for your GSoC Thanks, Di Xu 2015-03-18 4:44 GMT+08:00 ZhanLin Shang shangz...@gmail.com: Hello all, My name is Zhanlin Shang and I'd like to work with the core.typed Annotations and Macros mentored by Ambrose Bonnaire-Sergeant this summer. This is the first time for me to take part in this kind of event and I hope this mailing list is the right place. I'm a second year undergraduate student of Arizona State University and I've been programming with Common Lisp for two years and I've played around with Racket and Clojure. I'm interested in type theory and typed lambda calculus, and I've created a Lisp dialect with a type system which shares some concept with Core.Typed. I'd like to join this project to make Core.Typed better using all my knowledge and learn from the process. And I'd like to discuss with you all about the best / most beneficial design of Core.Typed. Best Wishes, Z.Shang -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Dunaj project, an alternative core API for Clojure
Another big experiment for today. As new reducer features (continuations) will be applied heavily here, please read 5th experiment if you have not done so yet. Prepare for the longest write-up so far. Experiment #8 - Computer and Network Resources Most applications perform some file and networking I/O. Clojure leaves this domain largerly uncovered and advises users to use host facilities instead. Dunaj attempts to cover this realm with an extensive and powerful set of features dedicated to computer and network resources. Goals of this experiment are as follows: * Design and implement the concept of resource scopes * Develop facilities for implementers of computer and network resources * Create abstractions for basic resource functionalities and integrate them with the rest of core API, mainly with collections and transducers * Provide implementation for widely used resources * Devise abstraction for composing resources into 'systems' You can read more about this experiment at http://www.dunaj.org Regards, Jozef On Thursday, March 5, 2015 at 10:33:53 PM UTC+1, Jozef Wagner wrote: I'm happy to announce a project called Dunaj [1], which provides an alternative core API for Clojure. Its main aim is to experimentally test major additions to the language. Dunaj /ˈdunaɪ/ is a set of core language experiments aimed to improve Clojure language and its core API. It deals with language features that require changes across different parts of Clojure and which cannot be evaluated in isolation. Dunaj aims to bring Clojure even more towards simplicity, consistency and performance. It is intended to be used by regular Clojure developers, either for application or library development. Dunaj was created to test 10 experiments that bring significant changes to the Clojure language. As there is a substantial number of additions and changes, I want to try a bit unconventional approach here. Before I'll release the actual library, I will introduce Dunaj's experiments in a series of individual posts. Every part states the motivation behind the experiment, introduces changes and additions to the language and demonstrates its intended use. If you do not want to miss any of this, you may want to register for a mailing list at [1] or follow @dunajproject at Twitter. -- Jozef Wagner [1] http://www.dunaj.org/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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] Dunaj project, an alternative core API for Clojure
Amazing work Jozef. Very interesting experiments. On Wednesday, March 18, 2015 at 9:21:25 AM UTC+1, Jozef Wagner wrote: Another big experiment for today. As new reducer features (continuations) will be applied heavily here, please read 5th experiment if you have not done so yet. Prepare for the longest write-up so far. Experiment #8 - Computer and Network Resources Most applications perform some file and networking I/O. Clojure leaves this domain largerly uncovered and advises users to use host facilities instead. Dunaj attempts to cover this realm with an extensive and powerful set of features dedicated to computer and network resources. Goals of this experiment are as follows: * Design and implement the concept of resource scopes * Develop facilities for implementers of computer and network resources * Create abstractions for basic resource functionalities and integrate them with the rest of core API, mainly with collections and transducers * Provide implementation for widely used resources * Devise abstraction for composing resources into 'systems' You can read more about this experiment at http://www.dunaj.org Regards, Jozef On Thursday, March 5, 2015 at 10:33:53 PM UTC+1, Jozef Wagner wrote: I'm happy to announce a project called Dunaj [1], which provides an alternative core API for Clojure. Its main aim is to experimentally test major additions to the language. Dunaj /ˈdunaɪ/ is a set of core language experiments aimed to improve Clojure language and its core API. It deals with language features that require changes across different parts of Clojure and which cannot be evaluated in isolation. Dunaj aims to bring Clojure even more towards simplicity, consistency and performance. It is intended to be used by regular Clojure developers, either for application or library development. Dunaj was created to test 10 experiments that bring significant changes to the Clojure language. As there is a substantial number of additions and changes, I want to try a bit unconventional approach here. Before I'll release the actual library, I will introduce Dunaj's experiments in a series of individual posts. Every part states the motivation behind the experiment, introduces changes and additions to the language and demonstrates its intended use. If you do not want to miss any of this, you may want to register for a mailing list at [1] or follow @dunajproject at Twitter. -- Jozef Wagner [1] http://www.dunaj.org/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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: Announcing oolong: a config-based glue for `component`
Responses inline :) On 18 Mar 2015, at 09:49, James Henderson ja...@jarohen.me.uk wrote: On Wednesday, 18 March 2015 09:29:59 UTC, James Laver wrote: component’ is a difficult term to google for, so I hadn’t come across your project :) Same problem here when I started writing Phoenix - there could be many libraries trying to solve the same problem! I think there’s a general danger of this when writing tools that solve generic problems. The problem of discoverability is something that I found a lot of when I was writing a lot of perl as well. If you weren’t attending events and keeping up to date with what’s going on, you didn’t get to hear about all the cool things people were doing. I find the clojure IRC channel helps a bit with this. Fair enough! I went for giving people the option of either one config file or multiple (after all, you don't *have* to use :phoenix/includes!) mainly because I got a lot of requests in Nomad (Phoenix's predecessor) for separate apps within the same company to share common configuration. *nod* I haven’t dealt with this yet. This is something my forthcoming library ‘kombucha’ (that i’m supposed to be hacking on right now, ho hum…) will have to deal with as well. I’m currently trying to figure out the best way to deal with what leiningen calls profiles while keeping the configuration format sane and simple. I see you’ve got some support for that, so I’ll be having a look shortly. I see you note that phoenix is ‘batteries included’. That’s a great experience for new users, but i wasn’t trying to build that on this occasion :) The leiningen template and plugin are also nice additions, and reloaded workflow integration is very handy. Hmm - Phoenix is 'batteries included, but removable' (phrasing stolen from Docker) which is significantly different from 'batteries included'. I'm not a fan of 'batteries included' - it tends to mean libraries that are hard for users to customise at a later date, which (to me, and to you as well by the sounds of it) goes against Clojure ideals. Phoenix is deliberately written as a standalone runtime library, which composes with whatever other systems people dream up, and a separate, lightweight plugin (not so composable), which essentially just bootstraps the library and saves people the hassle of a separate 'system.clj', 'dev.clj' and 'user.clj', if they so wish. Yes. Sorry, I didn’t mean it as a negative comment. I think batteries included is great for getting people going quickly and I appreciate you’ve gone to some efforts to make it removable. However, you focus on the reloaded workflow aspect considerably in the documentation so I was under the assumption that was the case you were aiming to support. Happy to help with these - do you want to post some specifics? As a starting point, I've found that including an 'emergency nREPL' - an nREPL that starts before the application (and doesn't depend on the application compiling) gets you a long way. If the application doesn't compile, the system doesn't start, but I think that's actually preferable than half a system. Feel free to steal ideas from Phoenix - that's what open source is all about! More than happy to work together on this as well though - seems like we have both come to very similar conclusions about how we want to wire up Clojure components. I expect this could get lengthy so I’ll follow up offlist. More than happy to work together if our ideas coincide. James -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Extend java class to participate in sequence operations
So in Clojure, I'd have:
(defrecord MyNode [^Node node]
clojure.lang. ISeq
(seq [this] …))
Thanks Mikera! An enlightenment to me!
—
Sent from Mailbox
On Wed, Mar 18, 2015 at 2:11 PM, Mikera mike.r.anderson...@gmail.com
wrote:
In that case, I would suggest writing a minimal wrapper, either in Java or
Clojure.
To get the basic sequence operations, you can simply implement the
interface clojure.lang.ISeq on the wrapper.
On Wednesday, 18 March 2015 09:17:09 UTC+8, juvenn wrote:
Thanks Niels, but what if a java class is not available for rewrite? Say,
it is from an external library.
—
Sent from Mailbox https://www.dropbox.com/mailbox
On Tue, Mar 17, 2015 at 10:01 PM, Niels van Klaveren
niels.va...@gmail.com javascript: wrote:
If a java class implements Iterable, it automatically supports seq.
On Tuesday, March 17, 2015 at 11:34:17 AM UTC+1, juvenn wrote:
Dear all,
Given a node type from singly linked list:
class Node {
int val;
Node next;
}
How do I extend it so `(seq node)` will return a sequence of values? And
generally first, rest, and next will work on node too.
While in Java, we could define the class to implement Iterable to
achieve this. In Clojure we do have `extend-type`, but it seems not
accepting interfaces to extend, nor do I find protocol for seqable.
So generally, given a class defined in Java, assuming it is not
available for rewrite, how shall we extend the class to participate in
sequence operations in Clojure?
Thanks in advance!
—
Sent from Mailbox https://www.dropbox.com/mailbox
--
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/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: Announcing oolong: a config-based glue for `component`
Thanks - thoughts inline :) On Wednesday, 18 March 2015 09:29:59 UTC, James Laver wrote: Hi James, ‘component’ is a difficult term to google for, so I hadn’t come across your project :) Same problem here when I started writing Phoenix - there could be many libraries trying to solve the same problem! I think your module had slightly different design goals from mine. Mine were: * everything in one config file (although i also provide support for separate data-config and system config) * be minimal. i’ve got a bunch of things i’m building on top of oolong at present that will together provide a more “complete” experience Fair enough! I went for giving people the option of either one config file or multiple (after all, you don't *have* to use :phoenix/includes!) mainly because I got a lot of requests in Nomad (Phoenix's predecessor) for separate apps within the same company to share common configuration. I see you note that phoenix is ‘batteries included’. That’s a great experience for new users, but i wasn’t trying to build that on this occasion :) The leiningen template and plugin are also nice additions, and reloaded workflow integration is very handy. Hmm - Phoenix is 'batteries included, but removable' (phrasing stolen from Docker) which is significantly different from 'batteries included'. I'm not a fan of 'batteries included' - it tends to mean libraries that are hard for users to customise at a later date, which (to me, and to you as well by the sounds of it) goes against Clojure ideals. Phoenix is deliberately written as a standalone runtime library, which composes with whatever other systems people dream up, and a separate, lightweight plugin (not so composable), which essentially just bootstraps the library and saves people the hassle of a separate 'system.clj', 'dev.clj' and 'user.clj', if they so wish. Reloaded workflow has been an experience for me. I haven’t yet managed to get it working in the face of compile errors. I find myself restarting the leiningen repl about as much as before. For this reason I chose to keep it separate and delay dealing with it for a few weeks. Have you managed to overcome these problems? I’m definitely interested in knowing how if so. Happy to help with these - do you want to post some specifics? As a starting point, I've found that including an 'emergency nREPL' - an nREPL that starts before the application (and doesn't depend on the application compiling) gets you a long way. If the application doesn't compile, the system doesn't start, but I think that's actually preferable than half a system. I’ve only really given phoenix a few minutes of my attention so far, but I like what I see and I’m liable to steal ideas for some of the things i’ll be building on top of oolong. Feel free to reply offlist if you have any further questions. Feel free to steal ideas from Phoenix - that's what open source is all about! More than happy to work together on this as well though - seems like we have both come to very similar conclusions about how we want to wire up Clojure components. James On 18 Mar 2015, at 09:07, James Henderson ja...@jarohen.me.uk javascript: wrote: Hi James, This looks very similar to Phoenix - a project I've been working on for the last few months. It's pretty likely you hadn't heard of it (and that's fine - it's not been hugely publicised!), but if you have, I was wondering whether there was anything about it that you felt was missing/a bad design decision? If so, would be great to get your feedback! Cheers, James On Tuesday, 17 March 2015 10:02:51 UTC, James Laver wrote: I've been using stuartsierra's handy component library for a while now, but I wanted an easier way of connecting components together. To that end, I wrote oolong. The main mode of operation is to take an edn configuration file and connect the specified systems and components. https://github.com/jjl/oolong https://clojars.org/oolong Feedback welcome. I spent quite a while documenting it so hopefully it should be fairly clear to understand. James -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/T_skapDqZ0U/unsubscribe. To unsubscribe from this group and all its topics, send an email to
Re: Announcing oolong: a config-based glue for `component`
Hi James, This looks very similar to Phoenix https://github.com/james-henderson/phoenix - a project I've been working on for the last few months. It's pretty likely you hadn't heard of it (and that's fine - it's not been hugely publicised!), but if you have, I was wondering whether there was anything about it that you felt was missing/a bad design decision? If so, would be great to get your feedback! Cheers, James On Tuesday, 17 March 2015 10:02:51 UTC, James Laver wrote: I've been using stuartsierra's handy component library for a while now, but I wanted an easier way of connecting components together. To that end, I wrote oolong. The main mode of operation is to take an edn configuration file and connect the specified systems and components. https://github.com/jjl/oolong https://clojars.org/oolong Feedback welcome. I spent quite a while documenting it so hopefully it should be fairly clear to understand. James -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Announcing oolong: a config-based glue for `component`
Hi James, ‘component’ is a difficult term to google for, so I hadn’t come across your project :) I think your module had slightly different design goals from mine. Mine were: * everything in one config file (although i also provide support for separate data-config and system config) * be minimal. i’ve got a bunch of things i’m building on top of oolong at present that will together provide a more “complete” experience I see you note that phoenix is ‘batteries included’. That’s a great experience for new users, but i wasn’t trying to build that on this occasion :) The leiningen template and plugin are also nice additions, and reloaded workflow integration is very handy. Reloaded workflow has been an experience for me. I haven’t yet managed to get it working in the face of compile errors. I find myself restarting the leiningen repl about as much as before. For this reason I chose to keep it separate and delay dealing with it for a few weeks. Have you managed to overcome these problems? I’m definitely interested in knowing how if so. I’ve only really given phoenix a few minutes of my attention so far, but I like what I see and I’m liable to steal ideas for some of the things i’ll be building on top of oolong. Feel free to reply offlist if you have any further questions. James On 18 Mar 2015, at 09:07, James Henderson ja...@jarohen.me.uk wrote: Hi James, This looks very similar to Phoenix - a project I've been working on for the last few months. It's pretty likely you hadn't heard of it (and that's fine - it's not been hugely publicised!), but if you have, I was wondering whether there was anything about it that you felt was missing/a bad design decision? If so, would be great to get your feedback! Cheers, James On Tuesday, 17 March 2015 10:02:51 UTC, James Laver wrote: I've been using stuartsierra's handy component library for a while now, but I wanted an easier way of connecting components together. To that end, I wrote oolong. The main mode of operation is to take an edn configuration file and connect the specified systems and components. https://github.com/jjl/oolong https://clojars.org/oolong Feedback welcome. I spent quite a while documenting it so hopefully it should be fairly clear to understand. 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/T_skapDqZ0U/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [GSoC] core.typed Annotations and Macros Proposal
Thanks for the information :) On Wed, Mar 18, 2015 at 2:35 AM Di Xu xudi...@gmail.com wrote: Read code base, submit some patches to get familiar with the process, etc. Also you can reach Ambrose to discuss your idea proposal. Di Xu 2015-03-18 13:29 GMT+08:00 ZhanLin Shang shangzhan...@gmail.com: Hi, Thanks for replying, I've signed the CA and forwarded this post to the core.typed mailing list. Can you tell me what should I do for now? Thanks, Z.Shang On Tuesday, March 17, 2015 at 5:49:34 PM UTC-7, Di Xu wrote: Welcome, I participated core.typed GSoC last year, and happy to see another Chinese student interested in core.typed project, you may forward your email to core.typed mail list[0], also you should first sign CA[1] (if you haven't) before any of your patches get accepted by core.typed or any core clojure library. You may submit some patches to JIRA[2] to make your application stronger. Also read base_env.clj[3] to get yourself familiar with core.typed annotation. Any question is welcomed. [0] https://groups.google.com/forum/#!forum/clojure-core-typed [1] http://clojure.org/contributing [2] http://dev.clojure.org/jira/browse/CTYP [3] https://github.com/clojure/core.typed/blob/ master/module-check/src/main/clojure/clojure/core/typed/base_env.clj Best wishes for your GSoC Thanks, Di Xu 2015-03-18 4:44 GMT+08:00 ZhanLin Shang shangz...@gmail.com: Hello all, My name is Zhanlin Shang and I'd like to work with the core.typed Annotations and Macros mentored by Ambrose Bonnaire-Sergeant this summer. This is the first time for me to take part in this kind of event and I hope this mailing list is the right place. I'm a second year undergraduate student of Arizona State University and I've been programming with Common Lisp for two years and I've played around with Racket and Clojure. I'm interested in type theory and typed lambda calculus, and I've created a Lisp dialect with a type system which shares some concept with Core.Typed. I'd like to join this project to make Core.Typed better using all my knowledge and learn from the process. And I'd like to discuss with you all about the best / most beneficial design of Core.Typed. Best Wishes, Z.Shang -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/vslKwQ-0Mss/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving
Re: Composing Stuart Sierra's components
I've also been investigating the nested system approach/problem.
The primary use case that I have is composing subsystems which are mostly
independent modules using a higher order system to run in one process. The
modules themselves can be easily extracted into separate applications thus
becoming their own top level systems which makes it desirable to keep their
system maps intact.
Components inside modules might depend on the *whole* modules, not their
constituent parts. This allows to have modules call each other through the
API's in-process as well as being easily replaced by remote endpoints when
separated into multiple processes.
This mostly works except for the components depending on other
modules/systems, e.g.:
(require '[com.stuartsierra.component :as cmp])
(defrecord X [x started]
cmp/Lifecycle
(start [this] (if started (println Already started x) (println
Starting x this)) (assoc this :started true))
(stop [this] (println Stopping x this) this))
(def sys1 (cmp/system-map :x (cmp/using (X. depends on dep nil) [:dep])))
(def sys2 (cmp/system-map :y (cmp/using (X. depends on sys1 nil)
[:sys1])))
(def hsys (cmp/system-map :sys1 (cmp/using sys1 [:dep]), :sys2 (cmp/using
sys2 [:sys1]) :dep (X. dependency nil)))
(cmp/start hsys)
Starting dependency #user.X{:x dependency, :started nil}
Already started dependency
Starting depends on dep #user.X{:x depends on dep, :started nil, :dep
#user.X{:x dependency, :started true}}
clojure.lang.ExceptionInfo: Error in component :sys2 in system
com.stuartsierra.component.SystemMap calling
#'com.stuartsierra.component/start
clojure.lang.ExceptionInfo: Missing dependency :dep of clojure.lang.Keyword
expected in system at :dep
This happens because of the following:
1. Dependency :*dep* of *sys1* is started in *hsys*
2. *sys1* is started (:*dep* is started again, so the start/stop should be
idempotent)
3. Dependency :*sys1* of *sys2* is started in *hsys*
4. :*sys1* cannot be started as it depends on :*dep* which isn't present in
*sys2*
This scenario could be supported by the Component library in several ways:
1. introduce an IdempotentLifecycle protocol which will be respected by the
Component library. Implement the protocol for the SystemMap.
IdempotentLifecycles will not be started or stopped for the second time,
also their dependencies will not be updated if they are already started.
2. do not fail if a component already has a dependency under the specified
key. This is a hack compared to the first solution, but I might go with it
in the short term.
Stuart, what do you think about that? Would you consider a PR implementing
the first proposal?
On Wednesday, March 18, 2015 at 10:18:36 AM UTC+1, Stuart Sierra wrote:
On Tue, Mar 17, 2015 at 5:47 PM, James Gatannah james.g...@gmail.com
javascript: wrote:
FWIW, we've been using something that smells an awful lot like nested
systems for months now. I never realized we weren't supposed to.
It's not that nested systems *never* work, but from what I've seen they
cause more complications than they're worth. The 'component' model doesn't
forbid it, but it does not support dependencies between components in
different subsystems.
I've found it easier to keep system maps flat and use namespaced
keywords to distinguish subsystem groups, even in large systems with 30+
components.
–S
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Composing Stuart Sierra's components
A possible implementation for the idea expressed in the previous post -
https://github.com/stuartsierra/component/pull/25
On Wednesday, March 18, 2015 at 2:41:46 PM UTC+1, platon...@gmail.com wrote:
I've also been investigating the nested system approach/problem.
The primary use case that I have is composing subsystems which are mostly
independent modules using a higher order system to run in one process. The
modules themselves can be easily extracted into separate applications thus
becoming their own top level systems which makes it desirable to keep their
system maps intact.
Components inside modules might depend on the *whole* modules, not their
constituent parts. This allows to have modules call each other through the
API's in-process as well as being easily replaced by remote endpoints when
separated into multiple processes.
This mostly works except for the components depending on other
modules/systems, e.g.:
(require '[com.stuartsierra.component :as cmp])
(defrecord X [x started]
cmp/Lifecycle
(start [this] (if started (println Already started x) (println
Starting x this)) (assoc this :started true))
(stop [this] (println Stopping x this) this))
(def sys1 (cmp/system-map :x (cmp/using (X. depends on dep nil) [:dep])))
(def sys2 (cmp/system-map :y (cmp/using (X. depends on sys1 nil)
[:sys1])))
(def hsys (cmp/system-map :sys1 (cmp/using sys1 [:dep]), :sys2 (cmp/using
sys2 [:sys1]) :dep (X. dependency nil)))
(cmp/start hsys)
Starting dependency #user.X{:x dependency, :started nil}
Already started dependency
Starting depends on dep #user.X{:x depends on dep, :started nil, :dep
#user.X{:x dependency, :started true}}
clojure.lang.ExceptionInfo: Error in component :sys2 in system
com.stuartsierra.component.SystemMap calling
#'com.stuartsierra.component/start
clojure.lang.ExceptionInfo: Missing dependency :dep of
clojure.lang.Keyword expected in system at :dep
This happens because of the following:
1. Dependency :*dep* of *sys1* is started in *hsys*
2. *sys1* is started (:*dep* is started again, so the start/stop should
be idempotent)
3. Dependency :*sys1* of *sys2* is started in *hsys*
4. :*sys1* cannot be started as it depends on :*dep* which isn't present
in *sys2*
This scenario could be supported by the Component library in several ways:
1. introduce an IdempotentLifecycle protocol which will be respected by
the Component library. Implement the protocol for the SystemMap.
IdempotentLifecycles will not be started or stopped for the second time,
also their dependencies will not be updated if they are already started.
2. do not fail if a component already has a dependency under the specified
key. This is a hack compared to the first solution, but I might go with it
in the short term.
Stuart, what do you think about that? Would you consider a PR implementing
the first proposal?
On Wednesday, March 18, 2015 at 10:18:36 AM UTC+1, Stuart Sierra wrote:
On Tue, Mar 17, 2015 at 5:47 PM, James Gatannah james.g...@gmail.com
wrote:
FWIW, we've been using something that smells an awful lot like nested
systems for months now. I never realized we weren't supposed to.
It's not that nested systems *never* work, but from what I've seen they
cause more complications than they're worth. The 'component' model doesn't
forbid it, but it does not support dependencies between components in
different subsystems.
I've found it easier to keep system maps flat and use namespaced
keywords to distinguish subsystem groups, even in large systems with 30+
components.
–S
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Streaming a large file onto a channel
Hi Adrian, What is exactly the issue that you're facing? I did my own version and it seems to be working fine. Please, take a look and I hope it helps. (defn process-file [ch file] (async/thread (with-open [input (io/reader file)] (doseq [line (line-seq input)] (async/!! ch line) (defn parse [line] (str Parsed: line)) ; change it to do whatever you want (defn mapping [ch] (async/map parse [ch])) (defn start [] (let [events (mapping (async/chan))] (process-file events 10_events.json) (async/go-loop [] (let [v (async/! events)] (println v) (recur) About your approach. For me, it seems a legitimate usage for core.async. Please, send us your impressions once you finish. Cheers, Em terça-feira, 17 de março de 2015 09:52:17 UTC-3, Adrian Mowat escreveu: Hi, I've played around with core.async a bit but now I'm trying to use it for a real project and I'm running into a problem getting data off a file and into a channel on the JVM (i.e. as opposed to ClojureScript) I have around 1GB of data sitting in a file. Each line of the file contains a separate JSON document. There are different types of document in the file and I would like use core.async to setup a pipeline of concurrent operations as follows so I can start processing the data before I've finished reading the file. 1. Stream the raw data out of the file one line at a time, parse it as JSON and write each line to channel (1) 2. Read channel (1) and divide the messages up by type and write them to new channels (2..n) 3. Read channels (2..n) and apply business logic as appropriate I'd like the initial read to run in it's own thread because it will be IO blocking. The others can run in core.async's thread pool I'm running into problems getting channels (1) and (2) to talk to one another. Here's my initial spike and I would expect it to write the 10 lines of json from the example file to stdout. (defn file-to-chan [ch file] (do (async/thread (with-open [rdr (io/reader file)] (doseq [line (line-seq rdr)] (!! ch line ch)) (defn parse-line [s] (json/parse-string s (comp keyword str/lower-case))) (def events (chan 1 (map parse-line))) (go (while true (println (! events (file-to-chan events 10_events.json) I have a few questions... * Can anyone help me understand what's going wrong? (I'm sure it's something silly, but I'm going cross eyed looking at it) * It's effectively a batch process. Is this an appropriate use case for core.async? * If so, am I on the right track or is there a better way to approach this? Many Thanks Adrian -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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.
ThreatGRID/Cisco Looking for Clojure Hackers
[ Full disclosure: I am the technical lead on this product and the hiring manager in this case. Feel free to contact me with questions, and to pass this around. We are also looking for Go hackers on another team, if you are of that persuasion. ] Clojure Developer for Malware Analysis Product The ThreatGRID team at Cisco is looking for experienced clojure developers to work on our large scale, malware analysis product. Our entire platform is built on Clojure, from the Clojurescript UI, through the API services, around the event processing subsystem, and down to the core.logic analysis engine. Our system runs as a distributed cluster in the cloud, and shrunk down to a single on-premises appliance. This keeps us focused on simple solutions, clear abstractions between services, composition of services, functional data processing, and minimal state. We are analyzing 300k+ malware files a day, and will be scaling to millions a day as we integrate with the Cisco product line. We need experienced hands in executing this scaling task, while also ensuring our threat intelligence is relevant as the malware market itself changes. Our team is distributed across the U.S. and works from home with occasional office visits and travel -- this requires excellent written communications, self-confidence, trust in your co-workers, and assuming ownership of the problems you encounter. We work with these technologies: * Clojure, core.logic * ClojureScript, Om * ElasticSearch * PostgreSQL * Redis We are looking for experience in some of the following problem domains: * Web Services Scaling -- Ok, but what happens if 2 million devices ask that question? * Cloud Deployment -- A herd of containers, a society of JVMs * DevOps -- Developers and Operators working together to reduce mean-time to discovery and remediation * Applied Machine Learning -- Fancy word for statistics, optimization and linear algebra. * Data Modeling -- Applied JSON epistemology in a world of hostile actors * System Monitoring and Alerting -- Kiries is Kibana, Riemann and Elasticsearch * Micro-Services Architecture -- Towards NetFlix OSS, but in a Clojure way. * Declarative UI Development -- Om + view definitions to deliver the pretty * Continuous Integration/Deployment -- Keep it green, push the button to deploy We offer: * An endless supply of interesting problems, and people to solve them with * Work in one of the fastest growing product lines in Cisco * Competitive salary and benefits to support a stable, high-quality life outside of work * Decades of collective experience with Clojure and Common Lisp * Support in developing your skills and talents, we love to help each other grow * Work from home, or a Cisco office, as you please. # CONTACT Email - j...@threatgrid.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: [GSoC] Source meta information model proposal
Am Mittwoch, 18. März 2015 07:18:30 UTC+1 schrieb Reid McKenzie: Alex, glad to see we're on the same wavelength about this more or less. Christopher, some other deliverables worth considering: Hi all, so I'm the other student Alex mentioned. I'm not participating so much in this discussion, since there will be enough time during the community bonding phase of the GSoC. My proposal is already on Melange, the place where all proposals go in the end. I've made it public now (http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/rmoehn/5629499534213120). It will go through some more revisions, though. But it mainly contains general stuff about the project and process and how I intend to go about things. Getting input from the community and knowledgeable people (i.e. you) will be part of those. Richard -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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: Streaming a large file onto a channel
Hi Erick Thanks for getting back to me. On my system, I wasn't seeing the contents of my file being listed in the REPL. Your code is working fine though and I can't see anything significantly different so I wonder if I had managed to corrupt my session in some way. Anyway, it's good to know I'm on the right path. I'll post my solutions as I get things up and running Cheers Adrian On Wednesday, 18 March 2015 13:45:33 UTC, Erick Pintor wrote: Hi Adrian, What is exactly the issue that you're facing? I did my own version and it seems to be working fine. Please, take a look and I hope it helps. (defn process-file [ch file] (async/thread (with-open [input (io/reader file)] (doseq [line (line-seq input)] (async/!! ch line) (defn parse [line] (str Parsed: line)) ; change it to do whatever you want (defn mapping [ch] (async/map parse [ch])) (defn start [] (let [events (mapping (async/chan))] (process-file events 10_events.json) (async/go-loop [] (let [v (async/! events)] (println v) (recur) About your approach. For me, it seems a legitimate usage for core.async. Please, send us your impressions once you finish. Cheers, Em terça-feira, 17 de março de 2015 09:52:17 UTC-3, Adrian Mowat escreveu: Hi, I've played around with core.async a bit but now I'm trying to use it for a real project and I'm running into a problem getting data off a file and into a channel on the JVM (i.e. as opposed to ClojureScript) I have around 1GB of data sitting in a file. Each line of the file contains a separate JSON document. There are different types of document in the file and I would like use core.async to setup a pipeline of concurrent operations as follows so I can start processing the data before I've finished reading the file. 1. Stream the raw data out of the file one line at a time, parse it as JSON and write each line to channel (1) 2. Read channel (1) and divide the messages up by type and write them to new channels (2..n) 3. Read channels (2..n) and apply business logic as appropriate I'd like the initial read to run in it's own thread because it will be IO blocking. The others can run in core.async's thread pool I'm running into problems getting channels (1) and (2) to talk to one another. Here's my initial spike and I would expect it to write the 10 lines of json from the example file to stdout. (defn file-to-chan [ch file] (do (async/thread (with-open [rdr (io/reader file)] (doseq [line (line-seq rdr)] (!! ch line ch)) (defn parse-line [s] (json/parse-string s (comp keyword str/lower-case))) (def events (chan 1 (map parse-line))) (go (while true (println (! events (file-to-chan events 10_events.json) I have a few questions... * Can anyone help me understand what's going wrong? (I'm sure it's something silly, but I'm going cross eyed looking at it) * It's effectively a batch process. Is this an appropriate use case for core.async? * If so, am I on the right track or is there a better way to approach this? Many Thanks Adrian -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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: [GSoC] Source meta information model proposal
Hello! Alex decided to proceed with Richard. Therefore, I'd like to find some other project. I'm glad to see so much feedback and I'd really like to reply to all your feedback but there is not much time to the end of application period and therefore I will focus exclusively on the another project. I hope that yours feedback will be helpful for Richard (and the entire community). If that's not the case and I've wasted your time, I'm really sorry. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
ANN: ClojureScript 0.0-3126, fix for minor REPL regression
ClojureScript, the Clojure compiler that emits JavaScript source code. README and source code: https://github.com/clojure/clojurescript New release version: 0.0-3126 Leiningen dependency information: [org.clojure/clojurescript 0.0-3126] This release just fixes a minor REPL related regression. ## 0.0-3126 ### Fixes * Need to wrap REPL -setup calls in cljs.compiler/with-core-cljs -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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.
Support for IBM JVM?
Is there an official statement of support (or non-support) for the IBM JVM? I'm finding that when building Clojure from source with the IBM JVM that one of the tests fails. The failure appears to be caused by the IBM implementation of BigInteger.hashCode() being different from Oracle's. Is this something that I should report? -Aaron -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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: Support for IBM JVM?
Clojure is regularly built and tested with the following JVM versions, as you can find out here: http://build.clojure.org/view/Clojure/job/clojure-test-matrix/ Sun JDK 1.6 Oracle JDK 1.7 Oracle JDK 1.8 IBM JDK 1.6 OpenJDK 1.6 I believe a JIRA ticket would be appropriate. The core team can decide what they would like to do about it. Andy On Wed, Mar 18, 2015 at 7:41 PM, Aaron Cummings aa...@aaroncummings.com wrote: Is there an official statement of support (or non-support) for the IBM JVM? I'm finding that when building Clojure from source with the IBM JVM that one of the tests fails. The failure appears to be caused by the IBM implementation of BigInteger.hashCode() being different from Oracle's. Is this something that I should report? -Aaron -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
case-insensitive data structures, contrib fnmap
I found an earlier thread about case-insensitive maps, which pointed to a contrib lib, fnmap. It doesn't appear to have survived. Is there another lib that does this, or a better way of doing case-insensitive data structs? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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: case-insensitive data structures, contrib fnmap
On Thursday, March 19, 2015 at 12:32:02 AM UTC-4, Brian Craft wrote: I found an earlier thread about case-insensitive maps, which pointed to a contrib lib, fnmap. It doesn't appear to have survived. Is there another lib that does this, or a better way of doing case-insensitive data structs? I've been using this little function for similar purposes. I suppose you could use deftype to make a map-like object that delegates to an inner map but first calls this on keys passed to assoc and get: (defn normalize Given a string, normalizes it so that it may be used as a key in a hashmap and compare equal to all strings representing the same word/spelling. There are edge cases that .toLowerCase or .toUpperCase would not handle, so the actual procedure uses java.text.Normalizer as well as both of the above. ; = (= (normalize ß) (normalize sS)) ; true ; = (= (normalize é) (normalize é)) ; true ; ; Note that the latter are two different és, if this file encoding preserved ; ; the difference. One uses a combining diacritic and one is integral. [^String s] (- s (java.text.Normalizer/normalize (java.text.Normalizer$Form/NFKC)) (.toUpperCase) (.toLowerCase))) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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: Streaming a large file onto a channel
It's possible you are simply not seeing the println output from a background thread, depending on how your repl etc is set up. On Wed, 18 Mar 2015 3:19 pm Adrian Mowat adrian.mo...@gmail.com wrote: Hi Erick Thanks for getting back to me. On my system, I wasn't seeing the contents of my file being listed in the REPL. Your code is working fine though and I can't see anything significantly different so I wonder if I had managed to corrupt my session in some way. Anyway, it's good to know I'm on the right path. I'll post my solutions as I get things up and running Cheers Adrian On Wednesday, 18 March 2015 13:45:33 UTC, Erick Pintor wrote: Hi Adrian, What is exactly the issue that you're facing? I did my own version and it seems to be working fine. Please, take a look and I hope it helps. (defn process-file [ch file] (async/thread (with-open [input (io/reader file)] (doseq [line (line-seq input)] (async/!! ch line) (defn parse [line] (str Parsed: line)) ; change it to do whatever you want (defn mapping [ch] (async/map parse [ch])) (defn start [] (let [events (mapping (async/chan))] (process-file events 10_events.json) (async/go-loop [] (let [v (async/! events)] (println v) (recur) About your approach. For me, it seems a legitimate usage for core.async. Please, send us your impressions once you finish. Cheers, Em terça-feira, 17 de março de 2015 09:52:17 UTC-3, Adrian Mowat escreveu: Hi, I've played around with core.async a bit but now I'm trying to use it for a real project and I'm running into a problem getting data off a file and into a channel on the JVM (i.e. as opposed to ClojureScript) I have around 1GB of data sitting in a file. Each line of the file contains a separate JSON document. There are different types of document in the file and I would like use core.async to setup a pipeline of concurrent operations as follows so I can start processing the data before I've finished reading the file. 1. Stream the raw data out of the file one line at a time, parse it as JSON and write each line to channel (1) 2. Read channel (1) and divide the messages up by type and write them to new channels (2..n) 3. Read channels (2..n) and apply business logic as appropriate I'd like the initial read to run in it's own thread because it will be IO blocking. The others can run in core.async's thread pool I'm running into problems getting channels (1) and (2) to talk to one another. Here's my initial spike and I would expect it to write the 10 lines of json from the example file to stdout. (defn file-to-chan [ch file] (do (async/thread (with-open [rdr (io/reader file)] (doseq [line (line-seq rdr)] (!! ch line ch)) (defn parse-line [s] (json/parse-string s (comp keyword str/lower-case))) (def events (chan 1 (map parse-line))) (go (while true (println (! events (file-to-chan events 10_events.json) I have a few questions... * Can anyone help me understand what's going wrong? (I'm sure it's something silly, but I'm going cross eyed looking at it) * It's effectively a batch process. Is this an appropriate use case for core.async? * If so, am I on the right track or is there a better way to approach this? Many Thanks Adrian -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Streaming a large file onto a channel
Hi Adam I'm using the latest version on cider + cider-nrepl but it's a possibility. I suspect it's more of a case that I tried so many different combinations I polluted my repl beyond repair. My fault for not just using components from the outset :-( Thanks Adrian Sent from my iPhone On 18 Mar 2015, at 18:57, Adam Clements adam.cleme...@gmail.com wrote: It's possible you are simply not seeing the println output from a background thread, depending on how your repl etc is set up. On Wed, 18 Mar 2015 3:19 pm Adrian Mowat adrian.mo...@gmail.com wrote: Hi Erick Thanks for getting back to me. On my system, I wasn't seeing the contents of my file being listed in the REPL. Your code is working fine though and I can't see anything significantly different so I wonder if I had managed to corrupt my session in some way. Anyway, it's good to know I'm on the right path. I'll post my solutions as I get things up and running Cheers Adrian On Wednesday, 18 March 2015 13:45:33 UTC, Erick Pintor wrote: Hi Adrian, What is exactly the issue that you're facing? I did my own version and it seems to be working fine. Please, take a look and I hope it helps. (defn process-file [ch file] (async/thread (with-open [input (io/reader file)] (doseq [line (line-seq input)] (async/!! ch line) (defn parse [line] (str Parsed: line)) ; change it to do whatever you want (defn mapping [ch] (async/map parse [ch])) (defn start [] (let [events (mapping (async/chan))] (process-file events 10_events.json) (async/go-loop [] (let [v (async/! events)] (println v) (recur) About your approach. For me, it seems a legitimate usage for core.async. Please, send us your impressions once you finish. Cheers, Em terça-feira, 17 de março de 2015 09:52:17 UTC-3, Adrian Mowat escreveu: Hi, I've played around with core.async a bit but now I'm trying to use it for a real project and I'm running into a problem getting data off a file and into a channel on the JVM (i.e. as opposed to ClojureScript) I have around 1GB of data sitting in a file. Each line of the file contains a separate JSON document. There are different types of document in the file and I would like use core.async to setup a pipeline of concurrent operations as follows so I can start processing the data before I've finished reading the file. 1. Stream the raw data out of the file one line at a time, parse it as JSON and write each line to channel (1) 2. Read channel (1) and divide the messages up by type and write them to new channels (2..n) 3. Read channels (2..n) and apply business logic as appropriate I'd like the initial read to run in it's own thread because it will be IO blocking. The others can run in core.async's thread pool I'm running into problems getting channels (1) and (2) to talk to one another. Here's my initial spike and I would expect it to write the 10 lines of json from the example file to stdout. (defn file-to-chan [ch file] (do (async/thread (with-open [rdr (io/reader file)] (doseq [line (line-seq rdr)] (!! ch line ch)) (defn parse-line [s] (json/parse-string s (comp keyword str/lower-case))) (def events (chan 1 (map parse-line))) (go (while true (println (! events (file-to-chan events 10_events.json) I have a few questions... * Can anyone help me understand what's going wrong? (I'm sure it's something silly, but I'm going cross eyed looking at it) * It's effectively a batch process. Is this an appropriate use case for core.async? * If so, am I on the right track or is there a better way to approach this? Many Thanks Adrian -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at
Re: Streaming a large file onto a channel
It seems like you're generally on the right track here (though Erick Pintor's code has some nice cleanup, like removal of necessary do, etc). The one thing I'd recommend is testing what happens with a larger channel buffer; if the file io isn't the bottleneck, but rather the processing, this could help the concurrency performance by making sure there's always something to be ready to be taken/worked on; It would be cool to see some metrics on that for your use case. Best Chris On Tuesday, March 17, 2015 at 5:52:17 AM UTC-7, Adrian Mowat wrote: Hi, I've played around with core.async a bit but now I'm trying to use it for a real project and I'm running into a problem getting data off a file and into a channel on the JVM (i.e. as opposed to ClojureScript) I have around 1GB of data sitting in a file. Each line of the file contains a separate JSON document. There are different types of document in the file and I would like use core.async to setup a pipeline of concurrent operations as follows so I can start processing the data before I've finished reading the file. 1. Stream the raw data out of the file one line at a time, parse it as JSON and write each line to channel (1) 2. Read channel (1) and divide the messages up by type and write them to new channels (2..n) 3. Read channels (2..n) and apply business logic as appropriate I'd like the initial read to run in it's own thread because it will be IO blocking. The others can run in core.async's thread pool I'm running into problems getting channels (1) and (2) to talk to one another. Here's my initial spike and I would expect it to write the 10 lines of json from the example file to stdout. (defn file-to-chan [ch file] (do (async/thread (with-open [rdr (io/reader file)] (doseq [line (line-seq rdr)] (!! ch line ch)) (defn parse-line [s] (json/parse-string s (comp keyword str/lower-case))) (def events (chan 1 (map parse-line))) (go (while true (println (! events (file-to-chan events 10_events.json) I have a few questions... * Can anyone help me understand what's going wrong? (I'm sure it's something silly, but I'm going cross eyed looking at it) * It's effectively a batch process. Is this an appropriate use case for core.async? * If so, am I on the right track or is there a better way to approach this? Many Thanks Adrian -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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.
`(apply map vector ...)`, and passing `apply` a list vs. a vector
I see that you can pass extra args to `apply` --- between the func and the coll args --- and `apply` will prepend the extras to the coll before proceeding. For example, these all work: (apply + [1 2 3 4]) (apply + 1 2 [3 4]) (apply + 1 2 '(3 4)) While thinking about how the following works: ~~~ (apply map vector [[:a :b :c] [:i :j :k] [:x :y :z]]) ~~~ I found this: ~~~ some-app.core= (apply map [vector [:a :b :c] [:i :j :k] [:x :y :z]]) ([:a :i :x] [:b :j :y] [:c :k :z]) some-app.core= (apply map '(vector [:a :b :c] [:i :j :k] [:x :y :z])) ArityException Wrong number of args (3) passed to: Symbol clojure.lang.AFn.throwArity (AFn.java:429) ~~~ Why does it fail when I pass a list there instead of a vector? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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: `(apply map vector ...)`, and passing `apply` a list vs. a vector
Because symbols can only take one argument:
('vector :a) --- nil
('vector :a :i :x) --- the exception you saw.
On Wed, Mar 18, 2015 at 2:01 PM, John Gabriele jmg3...@gmail.com wrote:
I see that you can pass extra args to `apply` --- between the func and the
coll args --- and `apply` will prepend the extras to the coll before
proceeding. For example, these all work:
(apply + [1 2 3 4])
(apply + 1 2 [3 4])
(apply + 1 2 '(3 4))
While thinking about how the following works:
~~~
(apply map vector [[:a :b :c]
[:i :j :k]
[:x :y :z]])
~~~
I found this:
~~~
some-app.core= (apply map [vector [:a :b :c] [:i :j :k] [:x :y :z]])
([:a :i :x] [:b :j :y] [:c :k :z])
some-app.core= (apply map '(vector [:a :b :c] [:i :j :k] [:x :y :z]))
ArityException Wrong number of args (3) passed to: Symbol
clojure.lang.AFn.throwArity (AFn.java:429)
~~~
Why does it fail when I pass a list there instead of a vector?
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from 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.
--
Ben Wolfson
Human kind has used its intelligence to vary the flavour of drinks, which
may be sweet, aromatic, fermented or spirit-based. ... Family and social
life also offer numerous other occasions to consume drinks for pleasure.
[Larousse, Drink entry]
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from 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: `(apply map vector ...)`, and passing `apply` a list vs. a vector
[vector] is a vector with the vector predicate. '(vector) is a vector with the symbol 'vector. `(~vector) is similar to what [vector] gives you. On Wed, Mar 18, 2015 at 5:01 PM, John Gabriele jmg3...@gmail.com wrote: I see that you can pass extra args to `apply` --- between the func and the coll args --- and `apply` will prepend the extras to the coll before proceeding. For example, these all work: (apply + [1 2 3 4]) (apply + 1 2 [3 4]) (apply + 1 2 '(3 4)) While thinking about how the following works: ~~~ (apply map vector [[:a :b :c] [:i :j :k] [:x :y :z]]) ~~~ I found this: ~~~ some-app.core= (apply map [vector [:a :b :c] [:i :j :k] [:x :y :z]]) ([:a :i :x] [:b :j :y] [:c :k :z]) some-app.core= (apply map '(vector [:a :b :c] [:i :j :k] [:x :y :z])) ArityException Wrong number of args (3) passed to: Symbol clojure.lang.AFn.throwArity (AFn.java:429) ~~~ Why does it fail when I pass a list there instead of a vector? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: `(apply map vector ...)`, and passing `apply` a list vs. a vector
Ah! I was passing `apply` a list who's first element was a symbol, rather than the function itself. Got it. Thanks Ambrose and Ben! On Wednesday, March 18, 2015 at 5:10:45 PM UTC-4, Ambrose Bonnaire-Sergeant wrote: [vector] is a vector with the vector predicate. '(vector) is a vector with the symbol 'vector. `(~vector) is similar to what [vector] gives you. On Wed, Mar 18, 2015 at 5:01 PM, John Gabriele jmg...@gmail.com javascript: wrote: I see that you can pass extra args to `apply` --- between the func and the coll args --- and `apply` will prepend the extras to the coll before proceeding. For example, these all work: (apply + [1 2 3 4]) (apply + 1 2 [3 4]) (apply + 1 2 '(3 4)) While thinking about how the following works: ~~~ (apply map vector [[:a :b :c] [:i :j :k] [:x :y :z]]) ~~~ I found this: ~~~ some-app.core= (apply map [vector [:a :b :c] [:i :j :k] [:x :y :z]]) ([:a :i :x] [:b :j :y] [:c :k :z]) some-app.core= (apply map '(vector [:a :b :c] [:i :j :k] [:x :y :z])) ArityException Wrong number of args (3) passed to: Symbol clojure.lang.AFn.throwArity (AFn.java:429) ~~~ Why does it fail when I pass a list there instead of a vector? -- 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/optout.
Re: Extend java class to participate in sequence operations
In that case, I would suggest writing a minimal wrapper, either in Java or
Clojure.
To get the basic sequence operations, you can simply implement the
interface clojure.lang.ISeq on the wrapper.
On Wednesday, 18 March 2015 09:17:09 UTC+8, juvenn wrote:
Thanks Niels, but what if a java class is not available for rewrite? Say,
it is from an external library.
—
Sent from Mailbox https://www.dropbox.com/mailbox
On Tue, Mar 17, 2015 at 10:01 PM, Niels van Klaveren
niels.va...@gmail.com javascript: wrote:
If a java class implements Iterable, it automatically supports seq.
On Tuesday, March 17, 2015 at 11:34:17 AM UTC+1, juvenn wrote:
Dear all,
Given a node type from singly linked list:
class Node {
int val;
Node next;
}
How do I extend it so `(seq node)` will return a sequence of values? And
generally first, rest, and next will work on node too.
While in Java, we could define the class to implement Iterable to
achieve this. In Clojure we do have `extend-type`, but it seems not
accepting interfaces to extend, nor do I find protocol for seqable.
So generally, given a class defined in Java, assuming it is not
available for rewrite, how shall we extend the class to participate in
sequence operations in Clojure?
Thanks in advance!
—
Sent from Mailbox https://www.dropbox.com/mailbox
--
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/optout.
Re: [GSoC] Source meta information model proposal
Alex, glad to see we're on the same wavelength about this more or less. Christopher, some other deliverables worth considering: - What format is documentation in? As Grimoire is evidence, plain doc text is pretty badly formatted on average certainly in comparison to HTML or even markdown. It'd be awesome if we had a convention for non-plain text documentation and for indicating format to documentation tools accordingly. - Notes. Alex mentioned extended documentation. Clojure has often been criticized for having excessively short docstrings. While I agree that a few well chosen words typically do better than many words, there are cases such as the documentation for defmulti where more than just what passes for the docstring is required. defmulti for instance is just one entry point to the subject of multimethods which while documented well on clojure.org is given sufficient general treatment in no docstrings. Andy F has Thalia, a project which modifies docstrings in place to try and augment some of the docs which are considered most .. terse. It seems that Alex wants whatever format this project produces to support arbitrarily many additional docstrings for a given entity. One arguable defect of the Grimoire representation as it stands is that I implicitly limited myself to a single note (user docstring/extension) per entity. - Examples. Most frequently, example code is presented as REPL sessions. Again, there is no common format for these. Some examples include the prompt string. Others don't. Some include STDOUT and STDERR inline with returned results. Others comment it out. It'd be awesome if we had tooling (including a common format or format indicator) for representing examples. Right now Grimoire and ClojureDocs use plain text which defeats all analysis and linking efforts. Honestly a nREPL session replay could probably be sufficient, but this is a research question. How you deal with deps to run an example is a related question. It'd be awesome for instance if I could share examples with the 4clojure folks or with Devn Walters' project getclojure. - Links. I previously played with a representation which I called var-link for uniquely naming any of [group artifact version platform ns def]. The idea was that you could write a URI of the form ns:org.clojure/clojure/1.6.0/clojure.core or def:org.clojure/clojure/1.6.0/clojure.core/concat etc. This idea predates the existing grimoire.things namespace, and was abandoned in favor of it since grimoire.things does almost this job. However grimoire.things fails entirely to provide or read any reasonable URI or other structured text representation for Things. It'd be great if we had a standard representation as such, so that documentation writers could explicitly link to other entities from docstrings. Again this goes back to the docstring formatting goal. What if I could explicitly link to say nth from first and second's docs? Link to defmethod and prefer-method from defmulti's docs? I think you get the idea. Just some ideas that've been rattling around in my head unimplemented. Reid -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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.
