Re: Startup time of standalone .jar executable

[Didier]

To answer your question, yes, ClojureScript startup times would be as fast 
as booting a shell command, a python script, etc.

To this end, you can use Planck like previously suggested, but I would 
recommend Lumo over it: https://github.com/anmonteiro/lumo

Lumo is a standalone ClojureScript interpreter, think of it as CPython for 
ClojureScript. It runs on Windows, Linux and MacOSX. The difference with 
Planck is that Lumo runs on Node.JS, while Planck runs on JavaScriptCore.

With lumo, you can use Node libraries from ClojureScript. It boots in 0.12 
second on average.

With all self-hosted ClojureScript, you will be limited to pure 
ClojureScript, so even a macro which uses java dependencies to transform 
code will not work in self-hosted ClojureScript, which mean some 
ClojureScript library don't work.

Alternatively, just compile your code to javascript with the Java 
ClojureScript compiler, and have them call into the JavaScript itself.

On Tuesday, 21 March 2017 11:31:33 UTC-7, Mark wrote:
>
> Depending what the processing is, ClojureScript could be a viable option.
> As I mentioned earlier, "planck" has fast start times.
>
> https://github.com/mfikes/planck
>
>
> On Tue, Mar 21, 2017 at 11:42 AM, Duncan McGreggor  > wrote:
>
>> 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 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 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"

The major upgrade to Neanderthal (the matrix library) will be released soon, with lots of new functionality.

[Dragan Djuric]

More details 
at: http://dragan.rocks/articles/17/Neanderthal-090-is-around-the-corner

-- 
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: java interop, `(.instanceMember Classname)`

[Colin Fleming]

I commented over there too - I'm still confused.

On 22 March 2017 at 10:59, Alex Miller  wrote:

>
>
> On Tuesday, March 21, 2017 at 11:43:25 AM UTC-5, John Gabriele wrote:
>>
>>
>> Erf. Sorry. I don't think I understand that after all, and as well may
>> have confused java.lang.String and java.lang.Class in my above reply.
>>
>> I also notice now that:
>>
>> user=> (class String)
>> java.lang.Class
>>
>> but
>>
>> user=> (. java.lang.Class getName)
>> CompilerException java.lang.NoSuchFieldException: getName,
>> compiling:(/tmp/form-init2724986764275224936.clj:1:1)
>>
>>
> This is exactly the reason that it's actually a different case. As the
> reference doc says, the equivalent expansion is:
>
> user=> (. (identity Class) getName)
> "java.lang.Class"
>
>
> --
> 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: java interop, `(.instanceMember Classname)`

[Alex Miller]

On Tuesday, March 21, 2017 at 11:43:25 AM UTC-5, John Gabriele wrote:
>
>
> Erf. Sorry. I don't think I understand that after all, and as well may 
> have confused java.lang.String and java.lang.Class in my above reply.
>
> I also notice now that:
>
> user=> (class String)
> java.lang.Class
>
> but
>
> user=> (. java.lang.Class getName)
> CompilerException java.lang.NoSuchFieldException: getName, 
> compiling:(/tmp/form-init2724986764275224936.clj:1:1) 
>
>
This is exactly the reason that it's actually a different case. As the 
reference doc says, the equivalent expansion is:

user=> (. (identity Class) getName)
"java.lang.Class"


-- 
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: java interop, `(.instanceMember Classname)`

[Alex Miller]

On further reflection, I've decided not to change this. My comment 
here: https://github.com/clojure/clojure-site/issues/171#issuecomment-288230603 
- further discussion related to this is probably best there on the issue 
for posterity.

On Tuesday, March 21, 2017 at 11:22:33 AM UTC-5, John Gabriele wrote:
>
>
>
> On Monday, March 20, 2017 at 7:47:46 PM UTC-4, Alex Miller wrote:
>>
>> If someone could file an issue on the clojure-site repo, I would be happy 
>> to improve the example. 
>
>
> Thanks. Filed: , 
> though I don't have alternative wording/prose for it.
>
>

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

Lisping for iOS, by Felwig

[Philip Markgraf]

Does anyone have any experience with "Lisping for iOS, by 
Felwig" http://slidetocode.com/lisping ? I would be interested to hear some 
feedback before shelling out money for the tool.

Thanks!

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

Re: Startup time of standalone .jar executable

[Mark Stang]

Depending what the processing is, ClojureScript could be a viable option.
As I mentioned earlier, "planck" has fast start times.

https://github.com/mfikes/planck


On Tue, Mar 21, 2017 at 11:42 AM, Duncan McGreggor 
wrote:

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

-- 
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: I wrote a beginner datomic tutorial I wanted to share with y'all, constructive feedback welcome

[Gregg Reynolds]

On Mar 21, 2017 12:43 PM, "Fenton Travers"  wrote:


@Gregg Reynolds:

Okay, I'll post to clojurians on slack.  I know somepeople get upset
about cross posting on channels.  I'm really not sure of the
etiquette.  I did post to the datomic channel on slack.  Maybe I
should have posted to the clojure channel?


they're pretty forgiving. you might post an fyi to the clojure channel
referring people to the datomic channel.

g


---



On Sunday, March 19, 2017 at 2:34:16 PM UTC-7, Fenton Travers wrote:
>
> https://www.reddit.com/r/Clojure/comments/5zu1oc/my_datomic_
> tutorial_feedback_sought/

-- 
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: 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: Startup time of standalone .jar executable

[Luke Burton]

There isn't enough information here to really recommend a fix. But here are 
some general thoughts:

* If you're wondering whether there's a magic --fast-mode flag to make this 
problem go away, no, there is not. 

* Can you make this a whole lot faster? Probably, yes, but it will involve a 
lot of work. It would involve profiling where the startup time is being spent, 
picking appropriate GC and runtime parameters that prefer startup time over 
other considerations, etc.

* Is this an architectural smell? Absolutely. Executing any external binary "a 
great many times" is always going to be inefficient compared to letting the 
binary stay resident in memory. If performance is a concern you need to 
understand what the constraints are and design something that specifically 
addresses that.

Luke.


> On Mar 21, 2017, at 8:24 AM, 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?
> 
> -- 
> 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: I wrote a beginner datomic tutorial I wanted to share with y'all, constructive feedback welcome

[Fenton Travers]

@Alan Thompson:

Yes I can see tupelo does indeed remove unnecessary
boilerplate.  That is good to know!

---

@Luke Burton:

Thank you so much for your encouragement, I did indeed
work many days on that.  I guess it matches my learning style.  I find
much of the documentation out there, quite difficult to learn from.
Its a never ending source of frustration for me.

You are quite talented in communicating, and I would grateful for you
to review any future work if you have time.  My next target is om-next
in combination with datomic.  Unfortunately, I find om-next to be even
more impenetrable than datomic! :(  So it may take quite a bit more
time before I'm able to produce anything of value.

Thanks again for your encouragement, it actually makes a big
motivational difference!

---

@Gregg Reynolds:

Okay, I'll post to clojurians on slack.  I know somepeople get upset
about cross posting on channels.  I'm really not sure of the
etiquette.  I did post to the datomic channel on slack.  Maybe I
should have posted to the clojure channel?

---


On Sunday, March 19, 2017 at 2:34:16 PM UTC-7, Fenton Travers wrote:
>
>
> https://www.reddit.com/r/Clojure/comments/5zu1oc/my_datomic_tutorial_feedback_sought/

-- 
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: Startup time of standalone .jar executable

[John Gabriele]

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.

Re: java interop, `(.instanceMember Classname)`

[John Gabriele]

On Tuesday, March 21, 2017 at 12:35:05 PM UTC-4, John Gabriele wrote:
>
> On Monday, March 20, 2017 at 4:59:33 PM UTC-4, Colin Fleming wrote:
>>
>> Object doesn't have a getName() method.
>>
>> This doc is confusing - as Phill comments above, this is calling the 
>> getName() method on an instance of Class. In Clojure, a bare classname 
>> (String, ArrayList or whatever) resolves to the class itself if it has been 
>> imported (i.e. what would be String.class in Java). The doc is confusing 
>> because (.instanceMember Classname args*) is really just a special case 
>> of (.instanceMember instance args*), where "instance" refers to an instance 
>> of a Class object. I'm not sure why that doc makes that distinction, it 
>> doesn't seem useful to me.
>>
>
> Oh. I see. `SomeClass` is an instance of java.lang.Class.
>
> user=> (. (class String) getName)
> "java.lang.Class"
>
>
Erf. Sorry. I don't think I understand that after all, and as well may have 
confused java.lang.String and java.lang.Class in my above reply.

I also notice now that:

user=> (class String)
java.lang.Class

but

user=> (. java.lang.Class getName)
CompilerException java.lang.NoSuchFieldException: getName, 
compiling:(/tmp/form-init2724986764275224936.clj:1:1) 

-- 
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: [JOB] Clojure Developer at World Singles (remote)

[Sean Corfield]

To clarify:

 

This particular role is only open to folks who are authorized to work in the 
US, but they will be working with people who hail from Europe and the Middle 
East, amongst other places.

 

I’m happy to field any other questions about this role off-list.

 

Sean Corfield – Senior Software Architect

World Singles - http://worldsingles.com/

 

 

On 3/21/17, 9:02 AM, "'Andy Chambers' via Clojure"  
wrote:

 

> globally diverse team

> Please note we will not be able to consider your application unless you are 
> authorized to work in the United States.

US only counts as globally diverse these days?

-- 
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: java interop, `(.instanceMember Classname)`

[John Gabriele]

On Monday, March 20, 2017 at 4:59:33 PM UTC-4, Colin Fleming wrote:
>
> Object doesn't have a getName() method.
>
> This doc is confusing - as Phill comments above, this is calling the 
> getName() method on an instance of Class. In Clojure, a bare classname 
> (String, ArrayList or whatever) resolves to the class itself if it has been 
> imported (i.e. what would be String.class in Java). The doc is confusing 
> because (.instanceMember Classname args*) is really just a special case 
> of (.instanceMember instance args*), where "instance" refers to an instance 
> of a Class object. I'm not sure why that doc makes that distinction, it 
> doesn't seem useful to me.
>

Oh. I see. `SomeClass` is an instance of java.lang.Class.

user=> (. (class String) getName)
"java.lang.Class"

Though, the second code block down at 
 says:

(.instanceMember Classname args*) ==> 

(. (identity Classname) instanceMember args*)


However, I don't understand why this works:

user=> (. (identity String) getName)
"java.lang.String"

since

user=> (= String (identity String))
true

and this fails:

user=> (. String getName)
CompilerException java.lang.NoSuchFieldException: getName, 
compiling:(/tmp/form-init2724986764275224936.clj:1:1) 


-- 
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: java interop, `(.instanceMember Classname)`

[John Gabriele]

On Monday, March 20, 2017 at 7:47:46 PM UTC-4, Alex Miller wrote:
>
> If someone could file an issue on the clojure-site repo, I would be happy 
> to improve the example. 


Thanks. Filed: , though 
I don't have alternative wording/prose for it.

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

Re: [JOB] Clojure Developer at World Singles (remote)

['Andy Chambers' via Clojure]

> globally diverse team

> Please note we will not be able to consider your application unless you 
are authorized to work in the United States.

US only counts as globally diverse these days?

-- 
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: Startup time of standalone .jar executable

[Mark Stang]

Planck?

On Tue, Mar 21, 2017 at 9:24 AM, 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?
>
> --
> 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.

Startup time of standalone .jar executable

[Michael Lindon]

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?

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

[JOB] Clojure Developer at World Singles (remote)

[Brave Clojure Jobs]

World Singles is looking for a Clojure developer - remote possible!

"We are looking for an enthusiastic developer with very strong Clojure-fu 
and a true dedication to writing clean and testable code. You'll be working 
with our globally diverse team to help our members find love. By creating 
new APIs and services you'll be helping to make the process of finding love 
a little easier for our millions of members across over 100 niche dating 
properties."

Find out 
more: 
https://jobs.braveclojure.com/jobs/17592186046179/clojure-developer-world-singles

-- 
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: Vars as global thread-locals?

[Didier]

Right, except each thread gets its own binding. So it's not necessarily that 
you'll get the value of the last binding up the call stack. This will only be 
true if you are in the same thread also.

I'm not sure if we agree on the rest, but explain it differently or not. 
ThreadLocal is an object, and so is a Clojure Var. When I say Clojure Var, I 
don't mean a variable, but an instance of the class clojure.lang.Var.

So you have two classes, ThreadLocal and Var. Each one gives you variable like 
behaviour. You'll need a true variable to point to the instance of each, in 
Clojure you can attach a local symbol to it, or a global symbol, same in java. 
In both, you'll probably want to store the instance through a globally 
accessible name, like with def in Clojure or a static in Java. You don't have 
too, but I don't see the use case for a local reference to the ThreadLocal or 
the Var.

So up to now, there's no difference between the two. Now, where the difference 
appears, is in their specific features, when working with the instances 
themselves. The ThreadLocal scope values by thread, and so does the Var. The 
only difference is that in Clojure, you can not set and get as you like, you 
must do it through a binding block, which will set on entry and unset on exit. 
In Java, you have to manually unset, and most probably should, as you exit.

Then there's the details, like Vars have a default global scope value, while 
ThreadLocal has a default init method if you get before a set.

The access scope to the Var instance or the ThreadLocal instance is up to you, 
put it in a local or a global variable, neither prevents you from doing either. 
The scope of the values returned by Var and ThreadLocal are both Thread scope, 
with Clojure adding an extra binding scope to Var on top of it.

I think we're saying the same thing at this point. In practice, you can think 
of ThreadLocal as thread scoped variables, and Vars as binding block scoped 
variables per thread.

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

introspecting execution of run in core.logic

[Lambder]

Hello All,


Would it be possible to have the result contain, 'a execution 
explanation' so I can see which subgoals contributed to which particular 
result and when no result to see which goals has failed and therefore 
prevented from success?

--
Lambder

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

Call for Papers & Demos: International Workshop on Functional Art, Music, Modelling and Design (FARM)

[Michael Sperber]

5th ACM SIGPLAN International Workshop on Functional Art, Music, Modelling 
and Design
Oxford, UK, September, 9th 2017

Key Dates:

Submission deadlineJune 1, 2017
Author Notification July 1, 2017
Camera Ready July 13, 2017

Call for Papers and Demos:

The ACM SIGPLAN International Workshop on Functional Art, Music,
Modelling and Design (FARM) gathers together people who are harnessing
functional techniques in the pursuit of creativity and expression.  It
is co-located with ICFP 2017, the 22nd ACM SIGPLAN International
Conference on Functional Programming.

Functional Programming has emerged as a mainstream software
development paradigm, and its artistic and creative use is booming. A
growing number of software toolkits, frameworks and environments for
art, music and design now employ functional programming languages and
techniques. FARM is a forum for exploration and critical evaluation of
these developments, for example to consider potential benefits of
greater consistency, tersity, and closer mapping to a problem domain.

FARM encourages submissions from across art, craft and design,
including textiles, visual art, music, 3D sculpture, animation, GUIs,
video games, 3D printing and architectural models, choreography,
poetry, and even VLSI layouts, GPU configurations, or mechanical
engineering designs. Theoretical foundations, language design,
implementation issues, and applications in industry or the arts are
all within the scope of the workshop. The language used need not be
purely functional (“mostly functional” is fine), and may be manifested
as a domain specific language or tool. Moreover, submissions focusing
on questions or issues about the use of functional programming are
within the scope.

FARM 2017 website : http://functional-art.org/2017/

Submissions

We welcome submissions from academic, professional, and independent
programmers and artists.

Submissions are invited in three categories:

1) Original papers

We solicit original papers in the following categories:

- Original research
- Overview / state of the art
- Technology tutorial

All submissions must propose an original contribution to the FARM
theme. FARM is an interdisciplinary conference, so a wide range of
approaches are encouraged.

An original paper should have 5 to 12 pages, be in portable document
format (PDF), using the ACM SIGPLAN style guidelines and use the ACM
SIGPLAN template. [ http://www.sigplan.org/Resources/Author/ ]

Accepted papers will be published in the ACM Digital Library as part
of the FARM 2017 proceedings. See http://authors.acm.org/main.cfm for
information on the options available to authors. Authors are
encouraged to submit auxiliary material for publication along with
their paper (source code, data, videos, images, etc.); authors retain
all rights to the auxiliary material.

2) Demo proposals

Demo proposals should describe a demonstration to be given at the FARM
workshop and its context, connecting it with the themes of FARM. A
demo could be in the form of a short (10-20 minute) tutorial,
presentation of work-in-progress, an exhibition of some work, or even
a performance. Demo proposals should be in plain text, HTML or
Markdown format, and not exceed 2000 words. A demo proposal should be
clearly marked as such, by prepending Demo Proposal: to the title.

Demo proposals will be published on the FARM website. A summary of the
demo performances will also be published as part of the conference
proceedings, to be prepared by the program chair.

3) Calls for collaboration

Calls for collaboration should describe a need for technology or
expertise related to the FARM theme. Examples may include but are not
restricted to:

- art projects in need of realization
- existing software or hardware that may benefit from functional programming
- unfinished projects in need of inspiration

Calls for collaboration should be in plain text, HTML or Markdown
format, and not exceed 5000 words. A call for collaboration should be
clearly marked as such, by prepending Call for Collaboration: to the
title.

Calls for collaboration will be published on the FARM website.

Submission is via EasyChair

https://easychair.org/conferences/?conf=farm2017

Authors take note

The official publication date is the date the proceedings are made
available in the ACM Digital Library. This date may be up to two weeks
prior to the first day of your conference. The official publication
date affects the deadline for any patent filings related to published
work.

Questions

If you have any questions about what type of contributions that might
be suitable, or anything else regarding submission or the workshop
itself, please contact the organisers at:

farm-2...@functional-art.org

All presentations at FARM 2017 will be recorded. Permission to publish
the resulting video (in all probability on YouTube, along with the
videos of ICFP itself and the other ICFP-colocated events) will be
requested on-site.



-- 
You received thi