Clojure 1.6 API: clojure.lang.IFn and clojure.api.API

[Jörg Winter]

So these APIs are new in 1.6-SNAPSHOT and from what I understand provide an 
integration api between Java and Clojure-Runtime (symbols and their 
invocation).
Apart from limitations which probably exist, what is the mode of execution 
for these API-calls ?

For example if a tool/IDE starts a (REPL) _process_ by calling ClojureUtils.
CLOJURE_MAIN, how am I supposed to call

API.var("clojure.core", "+");
?

How would I get the JVMs class-instance of "API" if I don't add some kind of 
inter-process communication ?

Any known projects using this new API already ?

Joerg



-- 
-- 
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/groups/opt_out.

Re: Clojure 1.6 API: clojure.lang.IFn and clojure.api.API

[Jörg Winter]

Hi Stuart,

ok, so my question is actually more about how to create some clojure Runtime, 
filling it with additional namespaces, i.e. more than just clojure.core.
I just discovered the RT class which could be what I want ( though its not 
official "API" ?)

I need to make clojure runtime avail. for an IDE plugin, thats the background 
here.

What do you think of Using RT like that ?
I mean instantiating a clojure environment by RT.doInit maybe

I really dont need to have a REPL for this, as I just want to query for 
functions and vars via API

Best,
Joerg

-- 
-- 
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/groups/opt_out.

Re: [ANN] Nightcode, an IDE for Clojure and Java

[Jörg Winter]

Hey Zach, great initiative! Keep it going.. much needed toole there!

Just wanted to say that for indenting/reformatting clojure-code, it is 
indeed possible to
use clojure's own "pprint" function.

Unfortunately the official java API.invoke() is only available in clojure 
1.6
But I have used this successfully already, so maybe this can help you 
somewhere.

Best,
Joerg

Am Dienstag, 6. August 2013 05:42:40 UTC+2 schrieb Zach Oakes:
>
> I just pushed 0.0.4 to the website. I received reports that it fixes the 
> nightcode.lein error, but please let me know if anyone experiences 
> otherwise.
>
> On Friday, August 2, 2013 9:03:03 AM UTC-4, Zach Oakes wrote:
>>
>> I’ve been working on a simple IDE for the past few months. It started as 
>> an attempt to add Leiningen integration to Clooj, but eventually I decided 
>> to start a new project from scratch. It is very alpha-quality, so please be 
>> gentle:
>>
>> http://nightcode.info/
>>
>> Here’s what it has:
>>
>> -Written in Clojure (the UI is written with seesaw)
>>
>> -Built-in copy of Leiningen to build Clojure and pure-Java projects
>>
>> -Built-in templates for several common types of Clojure and Java projects
>>
>> -Always-on REPL in the corner to try Clojure commands
>>
>> -Android integration (includes the lein-droid plugin, LogCat output, etc)
>>
>> -ClojureScript integration (includes the lein-cljsbuild plugin)
>>
>> -Cool looking dark theme, because that’s trendy these days
>>
>> Here’s what it’s missing:
>>
>> -Fast build times (it launches Leiningen in a separate process, which is 
>> slw...I plan on fixing this and would love any help)
>>
>> -Important editing features (code completion, text replace, etc)
>>
>> -Quick switching between recent files
>>
>> -Jump to definition, built-in documentation
>>
>> -Integration between editor and REPL (eval form or entire file)
>>
>> -Integration with git
>> -Many other things -- please give me your thoughts!
>>
>

-- 
-- 
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/groups/opt_out.

cgrand's parsley... text offsets ?

[Jörg Winter]

Hi,

Is there any existing option/fn to get the offsets and lengths of parsed 
content ?

For example for this:
> (-> sexpr p/incremental-buffer (p/edit 0 0 "(") (p/edit 1 0 "x)") 
p/parse-tree clojure.pprint/pprint)

...instead of:

{:tag :root,
 :content
 [{:tag :list, :content ["(" {:tag :symbol, :content ["x"]} ")"]}]}

...getting something like this:

{:tag :root,
 :content
 [{:tag :list, :offset 0, :length 3, :content ["(" {:tag :symbol, :offset 
1, :length 1, :content ["x"]} ")"]}]}

?

I guess project "paredit.clj" also does this more or less.. I just don't 
find the simplest fn to do this in its purest form.

Best, 
Joerg

-- 
-- 
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/groups/opt_out.

Re: cgrand's parsley... text offsets ?

[Jörg Winter]

Just what I was looking for, yes, thanks!

>From the tests I can see an example for views:
(deftest path-to
  (is (= (-> (v/path-to ftree 10) peek first v/text) "world")))

But what is the way to access the resulting map(?) of v/offsets ?
what are the keys to the offsets.. the :tag items ?

Joerg

-- 
-- 
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/groups/opt_out.

Re: Interest in a commercial IDE for Clojure?

[Jörg Winter]

Totally agree with Francesco,

Once your used to IntelliJ's comfort you're pretty much hooked.
I would pay a reasonable price for an Intellij-based IDE anytime.
Colin, hope this is underway already and I wish you success with it.

One thing though:
Many Lisp-specific (especially homo-iconicity) properties of Clojure tend 
to point beyond the architecture of IntelliJ, which was desinged with
imperative (OO-)Languages in mind.
I can imagine some not-so-mainstream editor-features, which may not be so 
easy to integrate with the current editor API of IntelliJ.

Best,
Jorg

-- 
-- 
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/groups/opt_out.

Re: cgrand's parsley... text offsets ?

[Jörg Winter]

..so an example of using /iterating a "nonrec-view" would be great!

Hope I'm putting this question right

Joerg

-- 
-- 
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/groups/opt_out.

Use of volatile! in stateful transducers

[Jörg Winter]

Hi,

As seen in this example of a stateful transducer...
http://crossclj.info/ns/org.clojure/clojure/latest/clojure.core.html#_partition-by

... I am wondering what is the concrete motivation behind using 'volatile!' 
instead of say a simple (mutable) Java-Object wrapper ?
In the partition-all example, an ArrayList is used for aggregating the 
'temporary' results for the step-function, so this mutable state is not 
concerned with threading at all.
Why then is there a threading-concern with pv (the volatile!) ?

As far as I understand, the step-function of a transducer is never(?) 
accessed concurrently by more than 1 thread.

Is volatile! necessary because transducers should be usable with core.async 
?
Or is it just an easy way to get a mutable object in Clojure ?


Best,
Joerg

-- 
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: Use of volatile! in stateful transducers

[Jörg Winter]

So if I'd need that extra performance, say in a private library of
transducers not intended to be shared with other Clojure developers, it is
perfectly Ok to use a java.lang.Object instead of a volatile, right ?

J

2015-01-02 15:59 GMT+01:00 Timothy Baldridge :

> "As far as I understand, the step-function of a transducer is never(?)
> accessed concurrently by more than 1 thread."
>
> It's actually "one thread at a time". And you're right, stuff like
> Core.async may bounce a transducer between several different threads, but
> only 1 thread "owns" it at a given time.
>
> Timothy
>
> On Fri, Jan 2, 2015 at 7:11 AM, Jörg Winter  wrote:
>
>> Hi,
>>
>> As seen in this example of a stateful transducer...
>>
>> http://crossclj.info/ns/org.clojure/clojure/latest/clojure.core.html#_partition-by
>>
>> ... I am wondering what is the concrete motivation behind using
>> 'volatile!' instead of say a simple (mutable) Java-Object wrapper ?
>> In the partition-all example, an ArrayList is used for aggregating the
>> 'temporary' results for the step-function, so this mutable state is not
>> concerned with threading at all.
>> Why then is there a threading-concern with pv (the volatile!) ?
>>
>> As far as I understand, the step-function of a transducer is never(?)
>> accessed concurrently by more than 1 thread.
>>
>> Is volatile! necessary because transducers should be usable with
>> core.async ?
>> Or is it just an easy way to get a mutable object in Clojure ?
>>
>>
>> Best,
>> Joerg
>>
>> --
>> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/CjxK7xEsOKQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Use of volatile! in stateful transducers

[Jörg Winter]

So if I'd need that extra performance, say in a private library of 
transducers not intended to be shared with other Clojure developers, it is 
perfectly Ok to use a java.lang.Object instead of a volatile, right ?


Am Freitag, 2. Januar 2015 15:59:36 UTC+1 schrieb tbc++:
>
> "As far as I understand, the step-function of a transducer is never(?) 
> accessed concurrently by more than 1 thread." 
>
> It's actually "one thread at a time". And you're right, stuff like 
> Core.async may bounce a transducer between several different threads, but 
> only 1 thread "owns" it at a given time. 
>
> Timothy
>
> On Fri, Jan 2, 2015 at 7:11 AM, Jörg Winter  > wrote:
>
>> Hi,
>>
>> As seen in this example of a stateful transducer...
>>
>> http://crossclj.info/ns/org.clojure/clojure/latest/clojure.core.html#_partition-by
>>
>> ... I am wondering what is the concrete motivation behind using 
>> 'volatile!' instead of say a simple (mutable) Java-Object wrapper ?
>> In the partition-all example, an ArrayList is used for aggregating the 
>> 'temporary' results for the step-function, so this mutable state is not 
>> concerned with threading at all.
>> Why then is there a threading-concern with pv (the volatile!) ?
>>
>> As far as I understand, the step-function of a transducer is never(?) 
>> accessed concurrently by more than 1 thread.
>>
>> Is volatile! necessary because transducers should be usable with 
>> core.async ?
>> Or is it just an easy way to get a mutable object in Clojure ?
>>
>>
>> Best,
>> Joerg
>>
>> -- 
>> 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.
>>
>
>
>
> -- 
> “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.

Re: core.async is very slow for some cases, what to do?

[Jörg Winter]

You could also try out:
http://docs.paralleluniverse.co/pulsar/


Am Dienstag, 11. März 2014 18:39:54 UTC+1 schrieb Эльдар Габдуллин:
>
> Each go block is executed via thread pool. On a channel side, producers 
> and consumers are also decoupled.
> Such decoupling costs around 10-20 us per async operation. For the cases 
> when your async
> values are immediately available (e.g. from cache), or when you designed 
> an async
> API just because your operations may block for a long but not necessary 
> do, those are huge numbers.
>
> For example, I recently worked on a dependency injection 
> container which 
> supports async computations.
> Asynchrony in one place means that all you API will be async everywhere. 
> Natural way to go with implementation is to just
> wrap everything in a go block. However, after doing that I found that 
> container became 50 times slower. 5 us overhead for a
> typical task turned into 250 us.
>
> As a solution I forked  core.async 
> and replaced channels with lightweight promises and removed thread pool 
> dispatch from
> everywhere. Now async container implementation is only 5 times slower than 
> its sync version, which is probably acceptable.
>
> I'd like to hear what others think about this issue, especially members of 
> the core team. 
>
>

-- 
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] www.core-async.info: a new web resource for core.async

[Jörg Winter]

Same problem with iOS 7 and 8 on iPad
Safari and Chrome

Does not finish loading

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