Re: [ANN] Dunaj project, an alternative core API for Clojure

[Jozef Wagner]

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`

[James Henderson]

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 the Google Groups 
"Clojure" group.
To unsubscribe from this group 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

[Stuart Sierra]

On Tue, Mar 17, 2015 at 5:47 PM, James Gatannah 
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: Announcing oolong: a config-based glue for `component`

[James Laver]

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  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

[Di Xu]

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 :

> 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 :
>>
>>> 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: [GSoC] core.typed Annotations and Macros Proposal

[ZhanLin Shang]

Thanks for the information :)

On Wed, Mar 18, 2015 at 2:35 AM Di Xu  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 :
>
>> 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 :
>>>
 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 ema

Re: Announcing oolong: a config-based glue for `component`

[James Henderson]

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  > 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 
>  
> > 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 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 grou

Re: Announcing oolong: a config-based glue for `component`

[James Laver]

Responses inline :)

> On 18 Mar 2015, at 09:49, James Henderson  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

[Juvenn Woo]

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 
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  
>>
>>
>> On Tue, Mar 17, 2015 at 10:01 PM, Niels van Klaveren <
>> niels.va...@gmail.com > 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  
  
>>>  -- 
>>> 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

[Henrik Eneroth]

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: Composing Stuart Sierra's components

[platonovadim]

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  > 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

[Erick Pintor]

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/
> 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 (
> (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: Composing Stuart Sierra's components

[platonovadim]

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  
>> 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.

ThreatGRID/Cisco Looking for Clojure Hackers

[Craig Brozefsky]

[ 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

[richard . moehn]

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

[Adrian Mowat]

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/  (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 (>
>> (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: Streaming a large file onto a channel

[Adam Clements]

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  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/>  (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 (>>
>>> (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 ema

ANN: ClojureScript 0.0-3126, fix for minor REPL regression

[David Nolen]

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.

Re: Streaming a large file onto a channel

[Adrian Mowat]

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  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  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/>>  (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 (>>> 
 (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 Goo

Re: [GSoC] Source meta information model proposal

[Christopher Medrela]

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.

`(apply map vector ...)`, and passing `apply` a list vs. a vector

[John Gabriele]

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

[Ben Wolfson]

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  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

[Ambrose Bonnaire-Sergeant]

[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  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

[John Gabriele]

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  > 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 
>> 
>> 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: Streaming a large file onto a channel

[Christopher Small]

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 (
> (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.

Support for IBM JVM?

[Aaron Cummings]

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?

[Andy Fingerhut]

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 
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

[Brian Craft]

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

[Fluid Dynamics]

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.