Extend ns macro?

[Gregg Reynolds]

I'm trying to extend ns, to add some functionality, but it's not working.
Is it even possible?  If not, is there a way to implement a custom
version?  I can defmacro my-ns in namespace foo and then start a file with
(foo/my-ns ...), but I can't get it to behave like ns (I copied the ns code
from core.)  Plus I want (my-ns...), without the foo/.

Suggestions?

Gregg

-- 
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: Streamlining dev environment startup

[Linus Ericsson]

You can hardcode the nrepl-server port with :repl-options {:port 4001} as 
seen at [1].

When thinking about it, maybe you could script tmux or similar to show all 
running terminals at once, like shown in [2].

[1] 
https://github.com/technomancy/leiningen/blob/master/sample.project.clj#L354
[2] 
http://stackoverflow.com/questions/5447278/bash-scripts-with-tmux-to-launch-a-4-paned-window

I will try out the tmux thing myself :)

/Linus

On Tuesday, December 1, 2015 at 5:32:06 PM UTC+1, Webdev Tory Anderson 
wrote:
>
> I recently read something hinting at ways of streamlining the startup 
> process for the dev environment, so I'm hoping you good folks can give me 
> some tips. I'm developing a web app in Linux, Clojurescript/Clojure 
> (incidentally using the Luminus architecture). I use emacs (that part's 
> non-negotiable; sorry). The cumbersome startup process I usually have goes 
> like this:
>
> M-x shell
>> mongod # start the mongo daemon
>>
>> M-x shell
>> lein run # start the app and server
>>
>> M-x shell
>> lein figwheel #start CLJS development
>>
>> (open a .clj file)
>> C-c M-c  # (cider-connect)
>> # insert localhost, port num, which proj. to connect to
>>
>>
> This is usually bearable since I only have to do it once or twice a week, 
> but it's definitely the sort of redundancy that would be nice to eliminate. 
> The "lein run" is good to have foregrounded because I can see timbre 
> statements and cleanly reboot when necessary. Figwheel, at the moment, has 
> to be foregrounded because that's where the figwheel prompt ends up (I'd 
> love to have that in Cider somehow, though). 
>
> Any recommendations on how to chop some of these steps off?
>
>
>

-- 
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 metrics-clojure 2.6.0 is released

[Jeff Mad]

Congratulations,  I look forward to using this, upgrading to 3.1 is great 
and the features on the release notes (really nice to have clear, concise 
release notes) will make using it much better. 

On Monday, November 30, 2015 at 10:30:10 AM UTC-8, Michael Klishin wrote:
>
> metrics-clojure is a Clojure interface to the DropWizard Metrics
> library.
>
> Release notes:
>
> https://github.com/sjl/metrics-clojure/blob/master/ChangeLog.md#changes-between-250-and-260
> -- 
> MK
>
> http://github.com/michaelklishin
> http://twitter.com/michaelklishin
>

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

San Diego Clojure Meetup

[Alan Thompson]

Hi,

The San Diego Clojure Users Group meetup is held the 2nd Wednesday of each
month, and our meetup this month is one week from tomorrow on 2015-12-9.
Last month we had a nice overview of a simple Om app.  This month we will
be discussing tupelo.core  and its
relationship to clojure.core functions.

Anyone from San Diego and Orange county (or further?) is welcome!  For
further information, please visit
http://www.meetup.com/San-Diego-Clojure-Users-Group/

Alan

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

Practical ways to deal with 'bag-of-properties' syndrome, AKA dynamic typing?

[jongwon.choi]

Use defrecord. People still can mess by using it as map, but it is a different 
problem.

-- 
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] Quil 2.3.0 Release

[Nikita Beloglazov]

Happy to announce Quil 2.3.0 release.
Quil is a Clojure/ClojureScript library for creating interactive drawings
and animations.

The release available on clojars: https://clojars.org/quil. List of changes:

   - Migrated to Processing 3.0. See relevant Processing page
   .
   - Switch to Clojure 1.6. Makes it incompatible with Clojure 1.5.1.
   - Optimizations in helper seqs functions. See #160
   .
   - Fix #161 : don't draw text
   when no-fill is set.
   - Fix #115 : bind *out* to REPL
   to make errors more visible when using emacs.
   - Removed few hints (due to Processing 3.0): :enable-retina-pixels,
   :disable-retina-pixels, :enable-native-fonts, :disable-native-fonts.

Documentation on http://quil.info has been updated as well.

Upgrade to Processing 3.0 didn't introduce major API changes. The most
noticeable change is that now smooth and no-smooth functions must be called
inside new handler :settings (a cousin of :setup). See settings()
documentation  for
Processing.

Happy hacking!
Nikita

-- 
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: Practical ways to deal with 'bag-of-properties' syndrome, AKA dynamic typing?

[Jony Hudson]

On Monday, 30 November 2015 21:49:09 UTC, Jonathon McKitrick wrote:

 how to go about finding out exactly what those maps contains without 
> slogging through source code.
>

Poke at them in the REPL! I don't think I *ever* write anything that isn't 
immediately ran and inspected at the REPL. I'd say I do almost all of my 
figuring out that way, with the remainder being done by looking at the 
source. I don't find looking at the source such a burden for two reasons: 
Cursive's jump to source is really good (and I think the same is probably 
true for the other development environment's out there); and code if often 
quite self contained, so you can usuallt just read the function you're 
interested in, or maybe it and one or two more up the chain (which, I 
think, is a product of Clojure being oriented around operations on a small 
set of basic data structures, rather than each library having it's own set 
of data structures to comprehend).

Of course, this leaves you vulnerable to a failure of the "worked once, 
will work every time" assumption which is where I'd see many of the tools 
mentioned thus far in the thread being most useful.


Jony

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

Streamlining dev environment startup

[Webdev Tory Anderson]

I recently read something hinting at ways of streamlining the startup 
process for the dev environment, so I'm hoping you good folks can give me 
some tips. I'm developing a web app in Linux, Clojurescript/Clojure 
(incidentally using the Luminus architecture). I use emacs (that part's 
non-negotiable; sorry). The cumbersome startup process I usually have goes 
like this:

M-x shell
> mongod # start the mongo daemon
>
> M-x shell
> lein run # start the app and server
>
> M-x shell
> lein figwheel #start CLJS development
>
> (open a .clj file)
> C-c M-c  # (cider-connect)
> # insert localhost, port num, which proj. to connect to
>
>
This is usually bearable since I only have to do it once or twice a week, 
but it's definitely the sort of redundancy that would be nice to eliminate. 
The "lein run" is good to have foregrounded because I can see timbre 
statements and cleanly reboot when necessary. Figwheel, at the moment, has 
to be foregrounded because that's where the figwheel prompt ends up (I'd 
love to have that in Cider somehow, though). 

Any recommendations on how to chop some of these steps off?


-- 
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: Streamlining dev environment startup

[Colin Yates]

The general idea is to use the ‘reloaded’ pattern, so rather than `lein run` 
you would have a function which starts and stop the system. You still need to 
run figwheel and mongo (yay for document databases) as separate processes, 
although I tend to do those in straight terminals rather than emacs shells as 
they live longer than my emacs does.

You can find more about the reloaded pattern and a prescripted approach to 
structuring your app here: https://github.com/stuartsierra/component 
.

I think it is fairly common to have:
 - your major building blocks as components
 - a specific dev namespace which is only on the :dev profile
 - fns in that namespace to start/stop components or the entire system

There are some libraries which build on the component library: 
https://github.com/danielsz/system  for 
example.

HTH.

> On 1 Dec 2015, at 16:26, Webdev Tory Anderson  wrote:
> 
> I recently read something hinting at ways of streamlining the startup process 
> for the dev environment, so I'm hoping you good folks can give me some tips. 
> I'm developing a web app in Linux, Clojurescript/Clojure (incidentally using 
> the Luminus architecture). I use emacs (that part's non-negotiable; sorry). 
> The cumbersome startup process I usually have goes like this:
> 
> M-x shell
> mongod # start the mongo daemon
> 
> M-x shell
> lein run # start the app and server
> 
> M-x shell
> lein figwheel #start CLJS development
> 
> (open a .clj file)
> C-c M-c  # (cider-connect)
> # insert localhost, port num, which proj. to connect to
> 
> 
> This is usually bearable since I only have to do it once or twice a week, but 
> it's definitely the sort of redundancy that would be nice to eliminate. The 
> "lein run" is good to have foregrounded because I can see timbre statements 
> and cleanly reboot when necessary. Figwheel, at the moment, has to be 
> foregrounded because that's where the figwheel prompt ends up (I'd love to 
> have that in Cider somehow, though). 
> 
> Any recommendations on how to chop some of these steps off?
> 
> 
> 
> -- 
> 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.