Re: [Clojure Book WIP] Deep Learning for Programmers: an Interactive Tutorial with CUDA, OpenCL, MKL-DNN, Java and Clojure, New Release 0.4.0

[Duncan McGreggor]

Hey! This looks *nice* ...

d

On Tue, Jun 18, 2019 at 4:49 AM Dragan Djuric  wrote:

> basically…
>
>1. the only DL book for programmers
>2. interactive & dynamic
>3. step-by-step implementation
>4. incredible speed
>5. yet, No C++ hell (!)
>6. Nvidia GPU (CUDA and cuDNN)
>7. AMD GPU (yes, OpenCL too!)
>8. Intel & AMD CPU (MKL-DNN)
>9. Clojure (magic!)
>10. Java Virtual Machine (without Java boilerplate!)
>11. complete source code
>12. beautiful typesetting (see sample chapters)
>
>
> https://aiprobook.com/deep-learning-for-programmers/?release=0.4.0
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/f1dcbd74-1302-4e01-94ee-6453fa7ae3be%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CALMHxspmH8JdN-CgxiJAh%3D-AFGcjHovLRPfgA-n3wHEWQwKRpw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] metasoarous/oz 1.5.1 - clojure dataviz updates (jupyter notebooks, markdown extensions, and static export, oh my!)

[Duncan McGreggor]

Yeah, I've been using CL+Maxima+Jupyter for my maths, etc.; will be really
nice to start doing some of that in Clojure ... thanks!

d

On Wed, Jan 23, 2019 at 11:37 AM Christopher Small 
wrote:

> Thank you both for the feedback! I'm really happy to be able to empower
> our budding Clojure Data Science community.
>
>
>
> On Wednesday, January 23, 2019 at 7:38:04 AM UTC-8, Chris Nuernberger
> wrote:
>>
>> Great improvements Christopher!  The markdown and Jupyter support are
>> exactly the direction I was hoping for and we really appreciate the work.
>>
>> On Wed, Jan 23, 2019 at 1:26 AM Christopher Small 
>> wrote:
>>
>>>
>>> Greetings
>>>
>>>
>>> I'm excited to announce the release of oz 1.5.1.
>>>
>>> https://github.com/metasoarous/oz
>>>
>>> Oz is a simple data visualization library built around Vega & Vega-Lite.
>>>
>>> In Vega & Vega-Lite, data visualizations are specified as pure data
>>> descriptions about how to map properties of your data and interactions to
>>> aesthetics of a visualization.  To find out more about Vega & Oz please
>>> visit https://github.com/metasoarous/oz.
>>>
>>> This release specifically adds some major new features:
>>>
>>> * Jupyter notebook support via the Clojupyter & IClojure kernels
>>> * Export of visualizations and scientific documents to live/interactive
>>> html files via the `export!` function
>>> * Load markdown files, with a notation for embedding visualizations as
>>> code blocks
>>> * Cljdoc API documentation (https://cljdoc.org/d/metasoarous/oz)
>>>
>>> These features, together with those already built into oz (REPL based
>>> workflow, hiccup support, Reagent components & publishing/sharing API),
>>> make oz a powerful tool for working with data visualizations and scientific
>>> documents from within Clojure, no matter the workflow.  I hope you find it
>>> useful.
>>>
>>>
>>> *## Markdown support*
>>>
>>> I'd like to specifically illustrate the markdown support feature, as its
>>> the one I'm most excited to start using myself, as well as the one which
>>> demands the most explanation.
>>>
>>> How many times have you been working on a simple markdown document, and
>>> realized you wanted to add a data visualization to illustrate a point?
>>> What did you have to do to get it done?  My guess is you had fire up
>>> another tool, like R's `ggplot`, or Python's `matplotlib`, export a static
>>> figure, and awkwardly embed it into your markdown document, hoping to God
>>> you don't have to update it, and go through the ordeal again.
>>>
>>> With oz, you can simply embed vega-lite or vega visualizations like this:
>>>
>>> # Some markown file
>>>
>>> A data visualization:
>>>
>>> ```edn vega-lite
>>> {:data {:values [{:a 2 :b 3 :c "T"} {:a 5 :b 2 :c "T"} {:a 7 :b 4 :c
>>> "Q"} {:a 3 :b 3 :c "Q"}]}
>>>  :mark :point
>>>  :width 400
>>>  :encoding {:x {:field "a"}
>>> :y {:field "b"}
>>> :color {:field "c"}}}
>>> ```
>>>
>>> The `load` function parses the markdown file, and uses the `edn
>>> vega-lite` code block class to determine that the block should be
>>> interpreted as a Vega-Lite visualization.  The fact that `edn` is one of
>>> the classes here means that your text editor and other markdown processors
>>> (if you push to GitHub or whatever) will recognize what kind of data it is
>>> and highlight it appropriately.  (Thanks to GH users mpcarolin and yogthos
>>> for promptly updating their markdown processing libraries to allow for the
>>> specification of multiple code classes.)
>>>
>>> Once loaded, the corresponding document can be immediately viewed with
>>> the `view!` function, exported to a self-contained html file via `export!`,
>>> or published online with a shareable link via `publish!`.
>>>
>>> This notation allows you to embed as either `json` or `yaml` in lieu of
>>> `edn`, or `vega` in lieu of `vega-lite`.  Moreover, `hiccup` can be
>>> embedded (possibly with `[:vega ...]` or `[:vega-lite ...]` nodes), for
>>> when you want more power than Markdown affords, but don't want to resort to
>>> manually writing html in your beautiful Markdown.
>>>
>>>
>>> *## Jupyter notebook support*
>>>
>>> While I personally prefer creating scientific documents from the comfort
>>> of my favorite text editor & REPL setup, I understand the value of the
>>> notebook environment.  In fact, my first programming language was
>>> Mathematica, and there's a part of me that holds warm reverie for the
>>> model.  Thus, it is with great pleasure that I announce that Oz can now be
>>> used as a go-to for those who enjoy using these environments and wish to be
>>> able to create powerful and interactive data visualizations therein.
>>>
>>> This feature would not have been possible without GH users mikeyford,
>>> keesterbrugge, jtcbrule, cgrand.
>>> Thank you all for your help initiating and piecing together a solution
>>> to the problem(s)!
>>>
>>> For usage details can be found in the README.
>>>
>>>
>>> *## In closi

Re: Who Uses import-vars?

[Duncan McGreggor]

On 7 November 2017 at 13:11, Timothy Baldridge  wrote:

> I structure my code very explicitly. Normally the most common constructs
> are put in a single file named after the library itself (not in core.clj,
> do that half your files will be named core).
>
> https://github.com/halgari/odin/blob/master/src/com/tbaldridge/odin.clj
>
> Anything not in the API that should be unpublished to users is in other
> namespaces that are imported and wrapped by vars in the main namespace.
> This does several things:
>
> * Keeps the public interface in one place
> * Allows for a different public interface than the private one. Notice how
> Odin has its own version of `when`, pulling that off require a bit of
> careful macro usage, so I'd rather write that once under a different name,
> then rename it to `when`.
> * It's now simple to say "anything in this namespace is public and will
> not change"
>
> Core.async uses a pattern much like this, the API is in
> clojure.core.async, most of the logic is under *.async.impl.*.
>

This is a great practice; it's how I do all my protocols/implementations
now.


> I don't recommend potemkin's import-vars at all. Clojure vars were not
> meant to exist in more than one namespace at a time, so potemkin pulls of
> its magic by linking two vars via watchers. This means that changes to one
> var can cause side-effects in the other. In addition, bindings don't convey
> properly (AFAIK), so if you using bindings on one var, the changes won't be
> seen in the other var. Remember: import-vars doesn't actually import
> anything, it simply creates a new var in the current namespace and links
> the two via a two-way binding. It's quite the hack, imo.
>

Huh. Good to know. Will have to ponder ...

d


> So I have to agree with Potemkin's tagline on github: it's an idea that's
> "almost good".
>
> Timothy
>
> On Tue, Nov 7, 2017 at 11:13 AM, Nick Mudge 
> wrote:
>
>> I am interested to know if people/you use import-vars to decouple the
>> structure of code from its API.
>>
>> import-vars is from the potemkin library: https://github.com/ztellman/po
>> temkin
>>
>> If you don't use import-vars how do you structure your code and provide
>> an API?
>>
>>
>> --
>> 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.
>>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/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: Who Uses import-vars?

[Duncan McGreggor]

I use it in some large fraction of my Clojure projects (25-50%?). The
primary driver is to balance an "internal" organization (e.g., that allows
me to keep file line counts low) that would be cumbersome as an API vs. an
ideal "developer experience" (e.g., less hierarchy and easier access to
functions).

I've also used it more recently in a large, legacy project (7+ years) to
support old users of a non-versioned API while reorganizing the codebase to
be more consistent (i.e., harmonizing a half-decade's worth of changes).
potemkin made the end result very clean with no breaking changes and really
opened up the future for the project.

d


On 7 November 2017 at 12:13, Nick Mudge 
wrote:

> I am interested to know if people/you use import-vars to decouple the
> structure of code from its API.
>
> import-vars is from the potemkin library: https://github.com/ztellman/
> potemkin
>
> If you don't use import-vars how do you structure your code and provide an
> API?
>
>
> --
> 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: How to try/catch Let bindings?

[Duncan McGreggor]

Didier, I've done something similar a few times just using core.async -- no
extra deps required ;-)

d


On 1 October 2017 at 23:21, Didier  wrote:

> I can't emphasize enough the utility of the interceptor chain pattern, as
>> employed heavily in pedestal.
>>
>
> Interesting... Its almost like a workflow framework, but for simpler in
> code workflows. I'm reluctant to have a dependency on pedestal just for
> this though.
>
> On Sunday, 1 October 2017 21:00:31 UTC-7, Luke Burton wrote:
>
>>
>> On Sep 30, 2017, at 3:14 PM, Didier  wrote:
>>
>> Is there another way to execute a set of complex steps which does not
>> rely on let and can be try/catched in the manner I describe?
>>
>>
>> I can't emphasize enough the utility of the interceptor chain pattern, as
>> employed heavily in pedestal.
>>
>> I use this *everywhere* now. I have code that interleaves interceptors
>> into a chain to augment them with timing information, audit logs, and more.
>> I have written code that maps a subset of an interceptor chain over a
>> cluster of machines, then reduces the results back down locally. Most
>> importantly, they are fantastically useful when it comes time to debug a
>> complex business process … you can swap interceptors in and out easily,
>> isolate stateful interceptors to enable better mocking during tests, and
>> more.
>>
>> Here's a basic application of interceptors. It's really not much code
>> considering what you get. This doesn't even scratch the surface of what
>> they can do.
>>
>> (ns interceptor.test
>>   (:require
>> [io.pedestal.interceptor.chain :as chain]))
>>
>> (def step1
>>   {:name  :step1
>>:enter (fn [ctx]
>> (let [x "sheep"]
>>   (assoc ctx :result x)))})
>>
>> (def step2
>>   {:name  :step2
>>:error (fn [ctx ex-info]
>> (println "so much for step2:" (:exception-type (ex-data
>> ex-info
>>:enter (fn [{:keys [result] :as ctx}]
>>
>> (println "time to transform" result "into a number")
>> (update ctx :result #(Long/parseLong %)))})
>>
>> (defn run []
>>   (chain/execute {} [step1 step2]))
>>
>>
>> --
> 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.

Clojure/conj hotel reservations

[Duncan McGreggor]

Hey all,

If anyone else is registering late for conj, the website is showing rooms
as sold out, but there are still a few available -- you have to call the
hotel. Let them now the discount is under "Cognitect, Inc." I as of a few
minutes ago there about 8 rooms still available ...

See you there!

d

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Eastwood, the Clojure lint tool, version 0.2.4 released

[Duncan McGreggor]

I use both all the time (part of the gating in the build process); they are
nicely complementary.

d

On 23 May 2017 at 11:16, Travis Daudelin  wrote:

>  Hi, thanks for posting this looks great!
>
> Is there any overlap in functionality between Eastwood and Kibit
> ? It's not clear to me which tool I
> should prefer nor when.
>
> --
> 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: Monorepos with separate artifacts?

[Duncan McGreggor]

The NASA project I'm working on right now does something similar, though
with lein:
 * https://github.com/nasa/Common-Metadata-Repository

The project was started a few years back, before the Components library
(among others) were ready for use, so you'll see some bespoke bits in there.

Similarly, we generate individual uberjars for each sub-project in the
monorepo.

d


On 30 April 2017 at 19:51, Sean Corfield  wrote:

> FWIW, at World Singles, we have a monorepo for all our backend code and we
> use Boot to manage dependencies and the build process.
>
>
>
> We have divided the code into subprojects, each with its own
> src/resources/test folders and a deps.edn file specifying the external
> dependencies.
>
>
>
> We have Boot tasks that, given a target subproject, perform a namespace
> dependency analysis across all the subprojects and identify the minimal set
> of artifacts needed to test / run / build that subproject. We build an
> uberjar from each of six of those subprojects. They’re mostly about 20MB
> each (we don’t AOT – that would definitely bloat things).
>
>
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>
>
> On 4/30/17, 3:40 PM, "Laurens Van Houtven"  behalf of _...@lvh.cc> wrote:
>
>
>
> I have a project with several components. Parts are a pretty standard
> Clojure programs with logically separate but related functionality, parts
> are ClojureScript intended for web browsers, and in the future parts might
> be React Native ClojureScript. There are good code-sharing reasons for
> keeping them in one codebase, but that also comes with a lot of downsides.
>
>
>
> Uberjar size is one. There are lots of reasons to want to reduce jar size,
> including performance, but in my case it's also a design constraint. AWS
> Lambda only gives you a 50MB budget. The jars for all AWS APIs add up to
> something just north of that already, and for reasons beyond my
> comprehension AWS doesn't make them available on the classpath the same way
> they do for non-JVM runtimes. A part of my code just talks to AWS services,
> but in the simplest possible project.clj, it'll also be lugging e.g.
> ClojureScript around. Parts use datascript, but others don't.
>
>
>
> Unfortunately in my experience using minimizers like ProGuard with
> uberjars turns out to be a great way to get a tiny jar that doesn't work.
> (I know some folks are experimenting with that to make that better.)
>
>
>
> It seems that the most popular approach to an application that has a lot
> of components is a cluster of separate repos, or at least independent
> directories within a single repository. Does anyone have any experience
> with a single codebase that produces a few different artifacts; say, a few
> different uberjars, some static JS files and maybe an Android/iOS
> deployable? Was it a giant pain in the neck? Is boot helpful at all here?
> Doing this with lein profiles feels a little gauche.
>
>
>
>
>
> lvh
>
> --
> 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.
>

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

Re: Startup time of standalone .jar executable

[Duncan McGreggor]

Has the application owner defined an interface for long-running components?
If not, maybe convince them to. Then they could just (.start yourCode) and
then make whatever API calls you have defined, with zero start-up costs
per-call from their side.

(This is what I do when integrating non-Clojure .jar files into Clojure
applications -- I make them follow the Component[1] model and provide
access to whatever connections, config, etc., they need via the Component
library definitions.)

For your particular case, there are some fun ways in which you can manage
state and respond to API calls in a long-running, in-memory Clojure app (in
particular, core.async), so this could be a real treat for you :-)

Hth,

d


[1] https://github.com/stuartsierra/component

On 21 March 2017 at 12:29, John Gabriele  wrote:

> On Tuesday, March 21, 2017 at 11:24:20 AM UTC-4, Michael Lindon wrote:
>>
>> I wrote a collaborator some clojure code which I distributed to them as a
>> standalone jar file which they are executing with
>>
>> java -jar mystandalone.jar
>>
>> The problem is that this executable is called a great many times in their 
>> application and every time the
>> executable is called there is a java/clojure startup cost. In fact the 
>> startup cost heavily domiantes the
>> run time, whereas executing the code in a repl is almost instantaneous.
>>
>> How can I get around this? Would it be better to make a clojurescript 
>> executable?
>>
>>
>
> One way around it might be to write your program as a separate service,
> running on the same machine, with it listening for connections on a network
> port.
>
> --
> 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: defpromise?

[Duncan McGreggor]

On Tue, Nov 20, 2012 at 9:12 AM, Jim foo.bar  wrote:

> I was just wondering...we have a 'defsomething' macro for almost
> everything...
>
> How come there is no 'defpromise'? It is very easy to write one and since
> we always initialize promises like this: (def x (promise)), I don't see any
> reason why not...
>
> (defmacro defpromise [name]
>   `(def ~name (promise)))
>
> Jim
>

You might want to check this out:
  https://github.com/ztellman/lamina/wiki/Introduction

Promises and Futures are implemented differently pretty much everywhere you
look, so his approach may or may not meet your needs/expectations.

Regardless, Zach's been doing some brilliant work that some of us from the
Twisted (Python) community have been keeping an eye on. Good stuff.

d

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: defpromise?

[Duncan McGreggor]

On Tuesday, November 20, 2012 9:13:03 AM UTC-8, Jim foo.bar wrote:
>
> I was just wondering...we have a 'defsomething' macro for almost 
> everything... 
>
> How come there is no 'defpromise'? It is very easy to write one and 
> since we always initialize promises like this: (def x (promise)), I 
> don't see any reason why not... 
>
> (defmacro defpromise [name] 
>`(def ~name (promise))) 
>
> Jim 
>

You might want to check this out:
  https://github.com/ztellman/lamina/wiki/Introduction

Promises and Futures are implemented differently pretty much everywhere you 
look, so his approach may or may not meet your needs/expectations.

Regardless, Zach's been doing some brilliant work that some of us from the 
Twisted (Python) community have been keeping an eye on. Good stuff.  

d

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en