Re: ANN: ClojureScript 1.9.456, Externs Inference & Comprehensive JS Modules Support

[Francesco Bellomi]

Found, thanks!

Francesco

-- 
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: ClojureScript 1.9.456, Externs Inference & Comprehensive JS Modules Support

[Francesco Bellomi]

Hi,

first of all, congratulations on this release, it's a huge step ahead.

I'm having an issue compiling a program with advanced optimizations, which 
worked fine with .293

I get the following exception, any ideas on how can i narrow down the problem 
within my source? 

Exception in thread "main" java.lang.NoSuchMethodError: 
com.google.common.base.Preconditions.checkState(ZLjava/lang/String;Ljava/lang/Object;)V,
 compiling:(/tmp/form-init5778645093287298904.clj:1:73)
at clojure.lang.Compiler.load(Compiler.java:7442)
at clojure.lang.Compiler.loadFile(Compiler.java:7368)
at clojure.main$load_script.invokeStatic(main.clj:277)
at clojure.main$init_opt.invokeStatic(main.clj:279)
at clojure.main$init_opt.invoke(main.clj:279)
at clojure.main$initialize.invokeStatic(main.clj:310)
at clojure.main$null_opt.invokeStatic(main.clj:344)
at clojure.main$null_opt.invoke(main.clj:341)
at clojure.main$main.invokeStatic(main.clj:423)
at clojure.main$main.doInvoke(main.clj:386)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.main.main(main.java:37)
Caused by: java.lang.NoSuchMethodError: 
com.google.common.base.Preconditions.checkState(ZLjava/lang/String;Ljava/lang/Object;)V
at com.google.javascript.rhino.IR.name(IR.java:363)
at 
com.google.javascript.jscomp.ClosureCodingConvention.(ClosureCodingConvention.java:474)
at com.google.javascript.jscomp.Compiler.(Compiler.java:202)
at com.google.javascript.jscomp.Compiler.(Compiler.java:264)
at cljs.closure$make_closure_compiler.invokeStatic(closure.clj:293)
at cljs.closure$optimize.invokeStatic(closure.clj:1255)
at cljs.closure$optimize.doInvoke(closure.clj:1251)
at clojure.lang.RestFn.applyTo(RestFn.java:139)
at clojure.core$apply.invokeStatic(core.clj:659)
at cljs.closure$build.invokeStatic(closure.clj:2113)
at cljs.build.api$build.invokeStatic(api.clj:205)
at cljs.build.api$build.invoke(api.clj:193)
at cljs.build.api$build.invokeStatic(api.clj:196)
at cljsbuild.compiler$compile_cljs$fn__6997.invoke(compiler.clj:59)
at cljsbuild.compiler$compile_cljs.invokeStatic(compiler.clj:59)
at cljsbuild.compiler$run_compiler.invokeStatic(compiler.clj:167)
at 
user$eval7152$iter__7200__7204$fn__7205$fn__7231.invoke(form-init5778645093287298904.clj:1)
at 
user$eval7152$iter__7200__7204$fn__7205.invoke(form-init5778645093287298904.clj:1)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.RT.seq(RT.java:525)
at clojure.core$seq__6422.invokeStatic(core.clj:137)
at clojure.core$dorun.invokeStatic(core.clj:3106)
at clojure.core$doall.invokeStatic(core.clj:3121)
at user$eval7152.invokeStatic(form-init5778645093287298904.clj:1)
at user$eval7152.invoke(form-init5778645093287298904.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6978)
at clojure.lang.Compiler.eval(Compiler.java:6968)
at clojure.lang.Compiler.load(Compiler.java:7430)
... 12 more

thanks in advance 

Francesco

-- 
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: instrumenting clojure.core

[Francesco Bellomi]

I think map is a good example where the different arities have very 
different semantics, and maybe it would be practical to specify a separate 
spec for each arity.

In the unified spec, both :args and :ret have to resort to (more or less 
explicit) unions in order to express the sum of the separate cases, and :fn 
is complicated in order to disallow the undesired combinations.

Francesco 

On Tuesday, June 14, 2016 at 1:22:23 PM UTC+2, Alex Miller wrote:
>
> I was suggesting that you could do something like this (although I'm 
> pretty sure this doesn't work right now):
>
> (s/fdef map
>   :args (s/cat :f (s/fspec :args (s/+ ::s/any))
>:colls (s/* seqable?))
>   :ret (s/or :seq seqable? :transducer ifn?)
>   :fn #(if (zero? (count (-> % :args :colls)))
>  ;; transducer
>  (ifn? (-> % :ret))
>  ;; lazy seq
>  (and (seqable? (-> % :ret))
>   (= (count (-> % :args :f :args))
>  (count (-> % :args :colls))
>
>
>
> In the map :args, spec the mapping function as well, then use :fn which 
> can either relate the args and ret of the main function OR relationships 
> between the args, as I'm doing at the very end. The input to :fn is the 
> conformed output of the :args and :ret specs. 
>
> But like I said, there are several problems with this right now and I need 
> to discuss more with Rich whether something like this should be possible 
> (mostly the args fspec is where I'm seeing issues.
>
>
> On Monday, June 13, 2016 at 7:57:16 PM UTC-5, Alistair Roche wrote:
>>
>> Oh, I see what you mean now, Leon. Apologies for not reading more 
>> closely! Yours is a much more interesting puzzle.
>>
>> Here's an attempt I made 
>> , 
>> groping towards it using reflection, but I couldn't even get that to work. 
>> Would be curious to see what the solution is there, and even more so (like 
>> you) to see if it can be done without reflection.
>>
>> On 13 June 2016 at 17:21, Leon Grapenthin > > wrote:
>>
>>> Thank Alistair, but that does not really address my question. Alex 
>>> suggested using :fn of fspec to check arity of a higher-order argument.
>>>
>>> But I could not find a tool to check function arity. Also I doubt :fn is 
>>> going to work since I'd expect it to be invoked /after/ the call - i. e. 
>>> the call would fail before the arity check.
>>>
>>> Note that in your example you can only use spec/generic testing to check 
>>> arity because you know the argument types. You can't test a generic higher 
>>> order fn for just arity like this because the generator won't know the 
>>> correct types to generate.
>>>
>>>
>>> On Monday, June 13, 2016 at 4:00:30 AM UTC+2, Alistair Roche wrote:

 Hi Leon,

 I think you're looking for fspec 
 ,
  
 unless I'm misunderstanding something. I wrote up an example 
  
 that might be helpful.

 @Ryan thanks for starting this thread, and @Alex thanks for responding. 
 It's been an interesting discussion!

 Cheers,


>>

-- 
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] Specter book approach: please evaluate

[Francesco Bellomi]

Brian,

I bought the current version of book.
I really liked both the content and the approach.

best,
Francesco




On Sunday, November 22, 2015 at 7:18:02 PM UTC+1, Brian Marick wrote:
>
> I announced a while back that I'd be writing a short book on Specter 
> https://github.com/nathanmarz/specter After some thrashing and the usual 
> interruptions, I have the first chapter written. I've taken an unusual 
> approach: teaching Specter by having you implement parts of it. I'm 
> curious to hear people's opinions. 
>
> Here: https://leanpub.com/specter 
>
> 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: [ANN] Release of pulley.cps 0.2.0

[Francesco Bellomi]

Thanks for taking the time to write such a detailed answer, I really
appreciated it.

Delimited continuations are useful since they return a value, and thus may
be reused and composed, and used to build complex control mechanisms.

In my opinion the coolest use of delimited continuations are Effects

http://math.andrej.com/wp-content/uploads/2012/03/eff.pdf

a way to separate pure computations and side effects that is more intuitive
and more composable than monads.

Brandon Bloom has written a (prototype) implementation of effect handlers
for clojure, based on the core.async CPS machinery

https://github.com/brandonbloom/cleff

Francesco




On Tue, Sep 22, 2015 at 10:19 PM, Nathan Davis <
nda...@positronic-solutions.com> wrote:

> On Tuesday, September 22, 2015 at 6:37:13 AM UTC-5, Francesco Bellomi
> wrote:
>>
>> Hi Nathan,
>>
>> I think it's an awesome project, thanks for sharing this.
>>
>>
> Thanks.  I appreciate the feedback.
>
>
>> I see that currently only full continuations are supported. Would it be
>> possible/feasible/easy to support delimited continuations? (ie. with ranges
>> different from the outermost CPS context)
>>
>>
> I haven't done much research into delimited continuations yet, so my
> understanding may be wrong.  However, here's my analysis of the current
> situation.
>
> As currently implemented, pulley.cps uses "sort of" full continuations.  I
> say "sort of" because continuations are implicitly limited by the
> trampoline.  So anytime a new trampoline is introduced (i.e., you call CPS
> code from a non-CPS function), the continuation is limited to that
> trampoline.  However, there is currently no way to explicitly delimit the
> continuation.
>
> In light of the above, it seems to me that *reset(f)* could be
> implemented as simply as a non-CPS function that invokes the (presumably
> CPS'd) function *f*.  I don't think this would be the ideal
> implementation, but it does seem to suggest it is at least possible.
>
> I'd be interested in hearing from you (and others) what use-cases you see
> for delimited continuations.  The overviews of the topic I've seen so far
> seem to neglect this entirely or only address it abstractly.  A few
> concrete examples would be a useful "jump-start".
>
> Also, it would be interesting to have a comparison with core.async's CPS
>> machinery: is pulley.cps expected to be more efficient performance-wise? Is
>> it implemented using similar or comparable techniques?
>>
>>
> core.async handles continuations as a state machine.  On the other hand,
> pulley.cps implements continuations via closures.  The two representations
> are isomorphic, so theoretically anything you can express in one you can
> express in the other.  However, state machines (at least as implemented in
> core.async) must be constructed with complete knowledge of all the possible
> states involved.  Since *go*-blocks are implemented via macro, and macros
> are limited to local transformations (and analysis), continuations (state
> transitions) within core.async are limited to the same *go*-block.
>
> In contrast, closures can come from different functions or even
> namespaces.  So continuations in pulley.cps can cross local boundaries.
> That is, even though pulley.cps transforms code blocks in isolation,
> closures allow these blocks to coordinate and participate in the CPS
> protocol.
>
> This has  some practical ramifications.  For example, you can't compose
> *go*-blocks the same way you compose regular functions.  In fact, you
> can't call a function in a *go*-block and, within that function, suspend
> the *go*-block.  You can of course compose core.async processes, but it
> has a distinct look and feel from function composition.
>
> On the other hand, functions transformed by pulley.cps compose just like
> regular functions — because they are functions.  In the examples directory,
> there is an implementation of a cooperative multitasking engine.  Unlike
> core.async, you can suspend tasks from pretty much any function.  There are
> still some limitations, but these are dynamic as opposed to static, and
> have to do with what I said previously about continuations being implicitly
> delimited.
>
> As far as performance goes, I haven't directly compared core.async to
> pulley.cps code yet, but I fully expect core.async to be a hands-down
> winner at this point.  core.async is more mature and has had more
> performance tuning than pulley.cps.  I have done some limited benchmarking
> against regular clojure code.  All I can say is that for compute-intensive
> code with tight loops in CPS code, pulley.cps performs pretty poorly.  You
> can expect a CPS version of such code t

Re: [ANN] Release of pulley.cps 0.2.0

[Francesco Bellomi]

Hi Nathan,

I think it's an awesome project, thanks for sharing this.

I see that currently only full continuations are supported. Would it be 
possible/feasible/easy to support delimited continuations? (ie. with ranges 
different from the outermost CPS context)

Also, it would be interesting to have a comparison with core.async's CPS 
machinery: is pulley.cps expected to be more efficient performance-wise? Is 
it implemented using similar or comparable techniques?

thanks,
Francesco




On Monday, September 21, 2015 at 9:24:20 PM UTC+2, Nathan Davis wrote:
>
> I'm pleased to annouce the release of verion 0.2.0 of pulley.cps 
> . pulley.cps is a 
> macro-based source-to-source transforming compiler that transforms Clojure 
> code into Continuation Passing Style (CPS), as well as a supporting 
> run-time library. 
>
>
> The main feature of this release is the addition of exception support — 
> you can now use try, throw, and catch just like you would in regular 
> Clojure code. There are various other enhancements as well, mostly to 
> support the exception code, as documented in the changelog.
>
>
> Nathan Davis
>
>

-- 
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] Grenada 1.0.0-rc.2

[Francesco Bellomi]

Hi Chris,

CrossClj is similar in spirit to Hoogle, although it is more focused on 
cross-project browsing

https://crossclj.info/

However, you cannot search by type signature, being Clojure not statically 
typed ;-)

Francesco



On Wednesday, August 26, 2015 at 7:52:31 AM UTC+2, zcaudate wrote:

 Hey Richard,

 Yep, it’s exactly how you’ve described. The main emphasis is on writing 
 documentation that can be verified through tests and so if the api changes, 
 then the documentation can be fixed accordingly.

 The grenada project looks to be very ambitious in it’s scope and yeah, 
 it’ll be amazing to have a hoogle-like search engine for clojure.

 btw… is datadoc a grenada thing or a java thing?

 Chris

 Hi Chris,

 you can download a Datadoc JAR from 
 https://clojars.org/repo/org/clojars/rmoehn/clojure/1.7.0+003/clojure-1.7.0+003-datadoc.jar
  
 and have a look at its contents. It's pretty bare-bones right now.

 Hydrox looks good! (As do your other libraries. – I hadn't had them on my 
 radar at all until now.) It appears to be a cool new tack on documentation 
 for me. A more expressive alternative to Codox, Autodoc  co. Correct me if 
 I oversimplify. What I've developed is a universal container for data about 
 Clojure code. You could store Hydrox data in it for distribution and 
 digestion by other tools. After the end of the GSoC my schedule is in a 
 state confusion, but as soon as this has abated I will have a closer look 
 at Hydrox and also include it in my comparison (
 https://github.com/clj-grenada/grenada-spec#comparison).

 Regarding the documentation problem (as I see it): Hydrox and Grenada 
 could be parts of the solution. Still lacking are conventions for the 
 structure of Clojure libraries and documentation, a unified approach to API 
 documentation (as opposed to people putting Codox or Autodoc on github.io 
 or private pages or nothing at all) and a dedicated search engine for 
 Clojure libraries.

 I would love to continue working on those things (and Grenada), but first 
 I have to wait for feedback from Alex Miller, who was my GSoC mentor, and 
 then I need to find some funding.

 Richard

 -- 
 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 javascript:
 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 javascript:
 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/TTO5AfqXXf4/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 clojure+u...@googlegroups.com javascript:.
 For more options, visit https://groups.google.com/d/optout.




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

Re: [GSoC] Source meta information model proposal

[Francesco Bellomi]

Hi Christopher,

I'm Francesco, the maintainer of crossclj.info

I think it's a very interesting project. Some comments on your proposal:

1) I think the information model is by far most important deliverable. I 
agree with Reid that a sound coordinate system is very important

2) The toolchain you want to implement is in part already there. 
Almost all the metadata you list in your current model are already 
extracted by codox; codox already separates the extraction phase from the 
output phase, so you could simply implement the indexing library by 
providing a different output module, in order to generate your model 
instead of HTML; the internal representation used by codox is already 
(somehow) a list of namespaces, each one with a list of vars; codox has a 
rich set of tools (lein plugin, etc.) which would be immediately reusable. 
Outputting JSON instead of EDN is a one-liner with Cheshire.

3) I'm not sure about the choice of storing artifact coordinates as part 
of a namespace's metadata. Currently it's not the case, the publishing 
recipe is kept separated (say, in project.clj or in a POM file), and a 
namespace at runtime has no notion of its coordinates. I think it's the 
same for all JVM languages. Are we providing extra flexibility, or are we 
simply complecting two different kind of information?

4) One relevant use case is IDE integration: IDEs cannot evaluate source 
code at runtime in order to generate the relevant metadata (it's not safe), 
so having this kind of static info would be really useful, ie. for 
providing users hints on vars generated by macros

Francesco


 


On Monday, March 16, 2015 at 7:53:53 PM UTC+1, Christopher Medrela wrote:

 Hello! My name is Christopher Medrela and I'd like to work at source 
 metadata
 information model project mentored by Alex Miller at Google Summer of 
 Code. I
 hope that this mailing list is the right place to discuss such projects 
 (if I'm
 wrong, correct me).



-- 
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: Finding ClojureScript Libraries

[Francesco Bellomi]

Hi,

FWIW I just put on a Clojurescript-specific subsite of CrossClj [1], that lists 
and searches both cljs tools and projects (published on clojars/github) with at 
least a .cljs source file (that includes projects developed with cljx)

http://crossclj.info/cljs

The auto-completing search field only looks into cljs projects for vars, fns 
and namespaces.

Of course this is much less curated than the wiki, being auto-genrated, but 
it's always fresh.

I also put on a cljs-specific page for documentation search:

http://crossclj.info/docsjs

which searches on the whole corpus of auto-generated docs of ClojureScript 
related projects,

Both these features are still buggy: CrossClj still has some problems 
cross-referencing some cljs projects. Also the docs search shows some 
unnecessary redundancy. I hope to fix these issues soon.

Francesco

[1] http://crossclj,info 

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

help with tools.emitter.jvm

[Francesco Bellomi]

Hi all,

I'm a newbie with tools.emitter.jvm, so there must be something obvious I'm 
missing, but I can't make this simple example work:

(in-ns 'user)
= #Namespace user

(require '[clojure.tools.emitter.jvm :as e])
= nil

(e/eval '(println a) {:debug? true})
// class version 50.0 (50)
// access flags 0x31
public final class user$ extends clojure/lang/AFunction  {

  // compiled from: user$

  // access flags 0x9
  public static clinit()V
RETURN
MAXSTACK = 0
MAXLOCALS = 0

  // access flags 0x1
  public init()V
ALOAD 0
INVOKESPECIAL clojure/lang/AFunction.init ()V
RETURN
MAXSTACK = 1
MAXLOCALS = 1

  // access flags 0x1
  public invoke()Ljava/lang/Object;
   L0
GETSTATIC user$.const__ : Lclojure/lang/Var;
INVOKEVIRTUAL clojure/lang/Var.getRawRoot ()Ljava/lang/Object;
CHECKCAST clojure/lang/IFn
LDC a
INVOKEINTERFACE clojure/lang/IFn.invoke 
(Ljava/lang/Object;)Ljava/lang/Object;
ARETURN
LOCALVARIABLE this Lclojure/lang/AFunction; L0 L0 0
MAXSTACK = 2
MAXLOCALS = 1
}

NoSuchFieldError const__  user$.invoke (user$:-1)

The example in
https://github.com/clojure/tools.emitter.jvm#example-usage

(e/eval '(+ 1 2) {:debug? true})

works correctly in my REPL, so the problem does not seem to be related to 
var resolution; 
also, the generated bytecode seems to be inconsistent (no field const__ is 
generated).

I'm using the last published version (0.1.0-beta5)

thanks in advance for any help.

Francesco 

-- 
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: help with tools.emitter.jvm

[Francesco Bellomi]

Of course you're right, I was using t.emitter with the last t.analyzer 
(0.6.1)

thanks, Francesco

On Friday, October 17, 2014 3:41:05 PM UTC+2, Nicola Mometto wrote:


 Hi Francesco, 
 I just tried evaluating `(println a)` with c.t.e.jvm using both -beta5 
 and -SNAPSHOT and it works as expected for me. 

 Are you by any chance using a different tools.analyzer.jvm version than 
 the one -beta5 requires? (0.5.2) 
 If so, that's why it's failing for you. 

 If you need to use t.a.jvm 0.6.x, I'll release a -beta6 shortly, in the 
 meantime -SNAPSHOT should work fine. 

 Let me know if this isn't the case, and if you find any bug please 
 report them in JIRA http://dev.clojure.org/jira/browse/TEMJVM or just 
 email me directly if you prefer. 

 Thanks, 
 Nicola 

 Francesco Bellomi writes: 

  Hi all, 
  
  I'm a newbie with tools.emitter.jvm, so there must be something obvious 
 I'm 
  missing, but I can't make this simple example work: 
  
  (in-ns 'user) 
  = #Namespace user 
  
  (require '[clojure.tools.emitter.jvm :as e]) 
  = nil 
  
  (e/eval '(println a) {:debug? true}) 
  // class version 50.0 (50) 
  // access flags 0x31 
  public final class user$ extends clojure/lang/AFunction  { 
  
// compiled from: user$ 
  
// access flags 0x9 
public static clinit()V 
  RETURN 
  MAXSTACK = 0 
  MAXLOCALS = 0 
  
// access flags 0x1 
public init()V 
  ALOAD 0 
  INVOKESPECIAL clojure/lang/AFunction.init ()V 
  RETURN 
  MAXSTACK = 1 
  MAXLOCALS = 1 
  
// access flags 0x1 
public invoke()Ljava/lang/Object; 
 L0 
  GETSTATIC user$.const__ : Lclojure/lang/Var; 
  INVOKEVIRTUAL clojure/lang/Var.getRawRoot ()Ljava/lang/Object; 
  CHECKCAST clojure/lang/IFn 
  LDC a 
  INVOKEINTERFACE clojure/lang/IFn.invoke 
  (Ljava/lang/Object;)Ljava/lang/Object; 
  ARETURN 
  LOCALVARIABLE this Lclojure/lang/AFunction; L0 L0 0 
  MAXSTACK = 2 
  MAXLOCALS = 1 
  } 
  
  NoSuchFieldError const__  user$.invoke (user$:-1) 
  
  The example in 
  https://github.com/clojure/tools.emitter.jvm#example-usage 
  
  (e/eval '(+ 1 2) {:debug? true}) 
  
  works correctly in my REPL, so the problem does not seem to be related 
 to 
  var resolution; 
  also, the generated bytecode seems to be inconsistent (no field const__ 
 is 
  generated). 
  
  I'm using the last published version (0.1.0-beta5) 
  
  thanks in advance for any help. 
  
  Francesco 

 -- 


-- 
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: tools.analyzer[.js/.jvm], tools.emitter.jvm, status report

[Francesco Bellomi]

Nicola,

of course you're right.

I recently switched to the 3-ary analyze in order to 
use :validate/wrong-tag-handler and I was wrongly passing {} as the env, 
instead of (empty-env).
When I saw the Invalid token: ::a/b errors I was fooled into thinking 
they were purely syntactical errors (but still -- that would be the reader, 
as you said), and didn't check the environment.

(btw, I'm using my own analyze-ns because I'm interested in trying to go 
ahead even if the evaluation of some top-level form fails)

Sorry for the noise, and thanks again for your work

Francesco




On Tuesday, August 19, 2014 10:18:56 PM UTC+2, Nicola Mometto wrote:


 Francesco, 
 that doesn't seem to be the case in my tests: 

 [~/src/tools.analyzer.jvm/src/main/clojure] cat test.clj 
 (ns test (:require [clojure.string :as s])) 
 ::s/foo 

 clojure.tools.analyzer.jvm (- (analyze-ns 'test) last :form) 
 :clojure.string/foo 

 Note that to analyze keywords in the form ::foo/bar, *ns* has to be set 
 and all the aliases need to be setup, this can only happen if the ns 
 form is evaluated after being analyzed, using analyze+eval or analyze-ns 
 directly, there's an explaination on the tools.analyzer.jvm README 
 regarding why `analyze` shouldn't be used to analyze whole namespaces 
 and why you whould use analyze+eval or analyze-ns instead. 

 In any case, keywords in the form ::foo/bar are resolved by the reader, 
 not the analyzer. 

 Nicola 

 Francesco Bellomi writes: 

  Nicola, 
  
  thank you for your work, and for :validate/wrong-tag-handler 
 specifically, 
  which is very useful to me. 
  
  It seems that analyzer refuses keywords in the form ::a/b, which are 
 used 
  in some projects 
  (e.g. [org.clojure/core.typed] clojure.core.typed.check.fn contains 
  ::t/cmethods at line 21). 
  
  Francesco 
  
  
  On Wednesday, August 13, 2014 6:54:54 PM UTC+2, Nicola Mometto wrote: 
  
  
  As some of you might know, I've been working contiuously on my various 
  tools.* contrib libraries for the past months and I've recently added 
  tools.analyzer.js to the list of contrib libraries I maintain. 
  
  Since I don't blog/tweet much about those libraries, I thought I'd 
 write 
  a report to let the community aware of the status of those libraries. 
  
  ## tools.analyzer https://github.com/clojure/tools.analyzer 
  
  tools.analyzer is a host-agnostic pluggable analyzer and collection of 
  passes producing an AST in clojure data structures for clojure and 
  other languages in the clojure language family, like clojurescript. 
  
  The current release is 0.5.1, here's a list of notable changes that 
 have 
  made in in the last few months: 
  
  * The analyzer now uses different environments for lexical state (like 
the locals map) and for global state (like namespaces mappings); the 
former is just a regular map passed to an analyze call, the latter is 
a dynamic var holding an atom and lives in the tools.analyzer.env 
namespace along with functions to setup/manipulate it. 
  
  * The metadata elision mechanism has been vastly improved, allowing to 
specify different keys to elide based on the node :op, aswell as 
 based 
on a predicate rather than simple key matching. 
  
  * The env context now partecipates in a keyword hierarchy, the default 
contexts are :ctx/statement, :ctx/return and :ctx/expr and other 
contexts can be derived from those, as an example tools.analyzer 
utilizes :ctx.invoke/target and :ctx.invoke/params for nodes in 
 invoke 
position. 
  
  * Dispatch on clojure expressions types has been opened with the 
-analyze-form multimethod, allowing to provide custom evaluation 
strategies for custom types (this was needed for tools.analyzer.js 
because of clojurescript's #js syntax) 
  
  * Documentation has been vastly improved with docstrings for every 
public function and pass, and the addition of an official AST 
quickref http://clojure.github.io/tools.analyzer/spec/quickref.html 
  
  For a complete list of changes, refer to the CHANGELOG: 
  https://github.com/clojure/tools.analyzer/blob/master/CHANGELOG.md 
  
  For more informations and examples, refer to the README: 
  https://github.com/clojure/tools.analyzer/blob/master/README.md 
  
  ## tools.analyzer.jvm https://github.com/clojure/tools.analyzer.jvm 
  
  tools.analyzer.jvm is a jvm-specific tools.analyzer extension, 
  collection of passes and useful functions to deal with analysis of 
  clojure on the JVM code. 
  
  The current release is 0.5.2, here's a list of notable changes that 
 have 
  made in the last few months: 
  
  * Added an analyze-ns function that returns a vector of AST nodes for 
every top-level form in that namespace; evaluates each form. 
  
  * Added a configurable handler for wrong tags: while Clojure is 
permissive of type hints that don't resolve to a Class which it 
simply ignores in most cases, tools.analyzer.jvm's default behaviour 
has

Re: tools.analyzer[.js/.jvm], tools.emitter.jvm, status report

[Francesco Bellomi]

Nicola,

thank you for your work, and for :validate/wrong-tag-handler specifically, 
which is very useful to me.

It seems that analyzer refuses keywords in the form ::a/b, which are used 
in some projects
(e.g. [org.clojure/core.typed] clojure.core.typed.check.fn contains 
::t/cmethods at line 21).

Francesco


org.clojure/core.typed clojure.core.typed.check.fnorg.clojure/core.typed 
clojure.core.typed.check.fn
On Wednesday, August 13, 2014 6:54:54 PM UTC+2, Nicola Mometto wrote:


 As some of you might know, I've been working contiuously on my various 
 tools.* contrib libraries for the past months and I've recently added 
 tools.analyzer.js to the list of contrib libraries I maintain. 

 Since I don't blog/tweet much about those libraries, I thought I'd write 
 a report to let the community aware of the status of those libraries. 

 ## tools.analyzer https://github.com/clojure/tools.analyzer 

 tools.analyzer is a host-agnostic pluggable analyzer and collection of 
 passes producing an AST in clojure data structures for clojure and 
 other languages in the clojure language family, like clojurescript. 

 The current release is 0.5.1, here's a list of notable changes that have 
 made in in the last few months: 

 * The analyzer now uses different environments for lexical state (like 
   the locals map) and for global state (like namespaces mappings); the 
   former is just a regular map passed to an analyze call, the latter is 
   a dynamic var holding an atom and lives in the tools.analyzer.env 
   namespace along with functions to setup/manipulate it. 

 * The metadata elision mechanism has been vastly improved, allowing to 
   specify different keys to elide based on the node :op, aswell as based 
   on a predicate rather than simple key matching. 

 * The env context now partecipates in a keyword hierarchy, the default 
   contexts are :ctx/statement, :ctx/return and :ctx/expr and other 
   contexts can be derived from those, as an example tools.analyzer 
   utilizes :ctx.invoke/target and :ctx.invoke/params for nodes in invoke 
   position. 

 * Dispatch on clojure expressions types has been opened with the 
   -analyze-form multimethod, allowing to provide custom evaluation 
   strategies for custom types (this was needed for tools.analyzer.js 
   because of clojurescript's #js syntax) 

 * Documentation has been vastly improved with docstrings for every 
   public function and pass, and the addition of an official AST 
   quickref http://clojure.github.io/tools.analyzer/spec/quickref.html 

 For a complete list of changes, refer to the CHANGELOG: 
 https://github.com/clojure/tools.analyzer/blob/master/CHANGELOG.md 

 For more informations and examples, refer to the README: 
 https://github.com/clojure/tools.analyzer/blob/master/README.md 

 ## tools.analyzer.jvm https://github.com/clojure/tools.analyzer.jvm 

 tools.analyzer.jvm is a jvm-specific tools.analyzer extension, 
 collection of passes and useful functions to deal with analysis of 
 clojure on the JVM code. 

 The current release is 0.5.2, here's a list of notable changes that have 
 made in the last few months: 

 * Added an analyze-ns function that returns a vector of AST nodes for 
   every top-level form in that namespace; evaluates each form. 

 * Added a configurable handler for wrong tags: while Clojure is 
   permissive of type hints that don't resolve to a Class which it 
   simply ignores in most cases, tools.analyzer.jvm's default behaviour 
   has always been to throw an exception in those cases. This has been a 
   longstanding issue for tools like eastwood that want to simply emit a 
   warning on those cases rather than stopping analysis and error out. 
   With the addition of this handlers, users can now control what happens 
   when t.a.jvm hits a tag that can't be resolved to a Class. 

 * Added optional Var-level tag inference 

 * Improved analyze+eval to attach the result of the evaluation of the 
   node to the AST, wrapping potential exceptions at evaluation time in 
   an ExceptionThrown record. 

 * Documentation has been vastly improved with docstrings for every 
   public function and pass, and the addition of an official AST 
   quickref http://clojure.github.io/tools.analyzer.jvm/spec/quickref.html 

 For a complete list of changes, refer to the CHANGELOG: 
 https://github.com/clojure/tools.analyzer.jvm/blob/master/CHANGELOG.md 

 For more informations and examples, refer to the README: 
 https://github.com/clojure/tools.analyzer.jvm/blob/master/README.md 

 ## tools.analyzer.js https://github.com/clojure/tools.analyzer.js 

 tools.analyzer.js is a js-specific tools.analyzer extension, collection 
 of passes and useful functions to deal with analysis of clojurescript 
 code. 

 The current release is 0.1.0-beta4. 

 The produced AST is not compatible with the one produced by 
 cljs.analyzer even though they are similar as the cljs analyzer heavily 
 influenced the AST format of tools.analyzer. 
 

Re: tools.analyzer[.js/.jvm], tools.emitter.jvm, status report

[Francesco Bellomi]

Nicola,

thank you for your work, and for :validate/wrong-tag-handler specifically, 
which is very useful to me.

It seems that analyzer refuses keywords in the form ::a/b, which are used 
in some projects
(e.g. [org.clojure/core.typed] clojure.core.typed.check.fn contains 
::t/cmethods at line 21).

Francesco


On Wednesday, August 13, 2014 6:54:54 PM UTC+2, Nicola Mometto wrote:


 As some of you might know, I've been working contiuously on my various 
 tools.* contrib libraries for the past months and I've recently added 
 tools.analyzer.js to the list of contrib libraries I maintain. 

 Since I don't blog/tweet much about those libraries, I thought I'd write 
 a report to let the community aware of the status of those libraries. 

 ## tools.analyzer https://github.com/clojure/tools.analyzer 

 tools.analyzer is a host-agnostic pluggable analyzer and collection of 
 passes producing an AST in clojure data structures for clojure and 
 other languages in the clojure language family, like clojurescript. 

 The current release is 0.5.1, here's a list of notable changes that have 
 made in in the last few months: 

 * The analyzer now uses different environments for lexical state (like 
   the locals map) and for global state (like namespaces mappings); the 
   former is just a regular map passed to an analyze call, the latter is 
   a dynamic var holding an atom and lives in the tools.analyzer.env 
   namespace along with functions to setup/manipulate it. 

 * The metadata elision mechanism has been vastly improved, allowing to 
   specify different keys to elide based on the node :op, aswell as based 
   on a predicate rather than simple key matching. 

 * The env context now partecipates in a keyword hierarchy, the default 
   contexts are :ctx/statement, :ctx/return and :ctx/expr and other 
   contexts can be derived from those, as an example tools.analyzer 
   utilizes :ctx.invoke/target and :ctx.invoke/params for nodes in invoke 
   position. 

 * Dispatch on clojure expressions types has been opened with the 
   -analyze-form multimethod, allowing to provide custom evaluation 
   strategies for custom types (this was needed for tools.analyzer.js 
   because of clojurescript's #js syntax) 

 * Documentation has been vastly improved with docstrings for every 
   public function and pass, and the addition of an official AST 
   quickref http://clojure.github.io/tools.analyzer/spec/quickref.html 

 For a complete list of changes, refer to the CHANGELOG: 
 https://github.com/clojure/tools.analyzer/blob/master/CHANGELOG.md 

 For more informations and examples, refer to the README: 
 https://github.com/clojure/tools.analyzer/blob/master/README.md 

 ## tools.analyzer.jvm https://github.com/clojure/tools.analyzer.jvm 

 tools.analyzer.jvm is a jvm-specific tools.analyzer extension, 
 collection of passes and useful functions to deal with analysis of 
 clojure on the JVM code. 

 The current release is 0.5.2, here's a list of notable changes that have 
 made in the last few months: 

 * Added an analyze-ns function that returns a vector of AST nodes for 
   every top-level form in that namespace; evaluates each form. 

 * Added a configurable handler for wrong tags: while Clojure is 
   permissive of type hints that don't resolve to a Class which it 
   simply ignores in most cases, tools.analyzer.jvm's default behaviour 
   has always been to throw an exception in those cases. This has been a 
   longstanding issue for tools like eastwood that want to simply emit a 
   warning on those cases rather than stopping analysis and error out. 
   With the addition of this handlers, users can now control what happens 
   when t.a.jvm hits a tag that can't be resolved to a Class. 

 * Added optional Var-level tag inference 

 * Improved analyze+eval to attach the result of the evaluation of the 
   node to the AST, wrapping potential exceptions at evaluation time in 
   an ExceptionThrown record. 

 * Documentation has been vastly improved with docstrings for every 
   public function and pass, and the addition of an official AST 
   quickref http://clojure.github.io/tools.analyzer.jvm/spec/quickref.html 

 For a complete list of changes, refer to the CHANGELOG: 
 https://github.com/clojure/tools.analyzer.jvm/blob/master/CHANGELOG.md 

 For more informations and examples, refer to the README: 
 https://github.com/clojure/tools.analyzer.jvm/blob/master/README.md 

 ## tools.analyzer.js https://github.com/clojure/tools.analyzer.js 

 tools.analyzer.js is a js-specific tools.analyzer extension, collection 
 of passes and useful functions to deal with analysis of clojurescript 
 code. 

 The current release is 0.1.0-beta4. 

 The produced AST is not compatible with the one produced by 
 cljs.analyzer even though they are similar as the cljs analyzer heavily 
 influenced the AST format of tools.analyzer. 
 tools.analyzer.js has several advantages over cljs.analyzer: 

 * Heavily modular implementation, thanks to the 

Re: [ClojureScript] Re: ANN: ClojureScript 0.0-2301, Transducers!

[Francesco Bellomi]

Maybe is a geographical problem.
Currently if i run

lein try org.clojure/clojurescript 0.0-2307

it fails in Italy (where I live), but it succeeds on a DigitalOcean 
instance in their US (SF1) datacenter.

Francesco



On Saturday, August 9, 2014 1:01:06 PM UTC+2, Nicola Mometto wrote:


 I can confirm, there seem to be problem fetching clojurescript versions 
 0.0-2301 and 0.0-2307. 

 Browsing the Central repo the files are there: 
 http://repo1.maven.org/maven2/org/clojure/clojurescript/0.0-2301/ 
 http://repo1.maven.org/maven2/org/clojure/clojurescript/0.0-2307/ 

 But the maven-metadata.xml file hasn't indexed them: 
 http://repo1.maven.org/maven2/org/clojure/clojurescript/maven-metadata.xml 


 Frank Versnel writes: 
  
  Hi David, 
  
  Leiningen couldn't find this version on clojars/maven central. Any other 
 repository I might need to add to get access to super early clojurescript 
 builds? 
  
  Cheers, 
  Frank 


-- 
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] Grimoire: up to date Clojure web docs

[Francesco Bellomi]

Very nice work.

I've recently done something similar, by adding to http://crossclj.info the 
ability to navigate auto-generated docs from docstrings and metadata.

The user interface balance is a bit different, the navigation is by 
namespace or by project, for example:

http://crossclj.info/doc/org.clojure/clojure/1.6.0/clojure.string.html

you see all the docs for the whole namespace, and you can jump to the 
source of a function (within the whole namespace source).

you can navigate the namespace hierarchy and switch from source to docs 
view using the control on the top left 

There is no way to add examples, but you can search for usages from all the 
indexed open source projects, which is usually pretty effective (you can 
try by clicking on one of the Usages link in the page above).

The auto generated doc is available and cross-referenced not only for the 
clojure standard lib, but also for all the indexed open-source projects 
(you can search them from the home page, or by navigating the references in 
the sources), although with different quality and coverage levels, due to 
some practical issues in working with arbitrary sources.

Other examples:
http://crossclj.info/doc/instaparse/1.3.2/instaparse.core.html
http://crossclj.info/doc/clj-time/0.7.0/clj-time.core.html

Overall, I think it's useful and enriching to see different UI approaches 
at work.

Francesco




On Wednesday, July 2, 2014 1:34:38 AM UTC+2, Reid McKenzie wrote:

 Hey guys, 

 If you're like me while using clojure.repl/doc works for the most part 
 there are just times that you need to send someone a link to the 
 official docs and navigating the docstrings in the core Clojure 
 repository is a pain. 

 After several months of being frustrated that clojuredocs is out of 
 date, I finally sat down and built an alternative which I'm pleased to 
 present here: http://www.arrdem.com/grimoire/ 

 Grimoire is still alpha and subject to change, especially with regards 
 to the example contribution process which needs streamlining beyond the 
 current click a link, edit on github and submit a PR. 

 I'd like to give a shout out to César for porting clojure.repl/source 
 into the doc generation script and to Nicola for his random usability 
 criticisms. 

 Reid McKenzie 


-- 
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] CrossClj, a tool for cross-referencing the clojure ecosystem

[Francesco Bellomi]

Hi Devin,

I'm a strong believer in contributing to the community. CrossClj is my 
first attempt to contribute to the clojure community, and I hope to do more 
in the future, even in source code form. 

At the moment, I don't feel like it's the right time to release the source 
code: it's a sort of personal playground on a series of themes I'm 
interested in (like static code analysis), and I'd like to figure out where 
it's headed, with the freedom to steer it into opinionated directions, 
whereas starting a community effort around it (like you suggest) would 
require a different *kind* of engagement

The sites you mentioned are all fantastic contributions (the way I hope 
CrossClj will be), but I'm not sure whether they need (or would be better) 
to be unified. They have, so to speak, different editorial voices, and I 
think this diversity is a value. For sure, I am favourable to integrate 
them (where appropriate) by linking their content and using their APIs, and 
I welcome them if they feel to do the same with CrossClj.
I think it's the same for all other language communities.

I really value all feedback, but I have my rationales.

I hope I don't sound arrogant: as a contemporary IT practitioner, I'm 
totally aware that I'm a dwarf standing on the shoulders of open-sourced 
giants, and that there are a lot of positive network effects; still, I 
don't feel I have a moral obligation to rush into releasing everything I 
do. 

thanks for your ideas, and I hope we will do something together in the 
future.

Francesco




On Thursday, June 12, 2014 3:23:31 AM UTC+2, Devin Walters (devn) wrote:

 Thanks for the reply Francesco. I know you said the code needs clean up 
 and all, but FWIW I haven't seen any project where that wasn't the case. 
 I'd encourage you to put it up on github. I for one would be interested in 
 contributing. I want to merge GetClojure, crossclj, clojuredocs, 
 clojuresphere, Clojars, and Clojure-doc into a one stop shop for all things 
 Clojure. All of the pieces have been worked out separately. With a little 
 bit of collaboration I think those of us interested in these sorts of 
 projects could build something really fantastic for the community.

 @Francesco  @All: Drop me a private email if you'd be interested in 
 discussing working on something like this. I'll set up a google hangout and 
 we can get together and talk about it. Think of the songs they'll write 
 about us if we succeed! :)

 Cheers,
 '(Devin Walters)

 On Jun 11, 2014, at 18:05, Francesco Bellomi francesc...@gmail.com 
 javascript: wrote:

 Devin,

 On Wednesday, June 11, 2014 6:25:13 PM UTC+2, Devin Walters (devn) wrote:

 A few nitpicks:


 Thanks for your feedback; I really appreciate any opinion or suggestion, 
 especially related to the UI
  

  
 - I find the usability to be a bit difficult in some places. For 
 instance, search results and specific function pages feel kind of cluttered.


 I understand that. I was trying to cram as much info as possible, and I 
 was too lazy to write some basic pagination facility. I think that the 
 problem is especially relevant when you have a lot of results. 
  

 - What does Some other projects... mean? Are they related to the 
 function I'm viewing, or are they just random projects?


 Totally random. I was trying to enable/facilitate some serendipitous 
 exploration.
  

 - It's not clear what kind of interaction is being encouraged by adding 
 the Google+ comments box. Maybe a slightly longer up-front explanation 
 about how you envision people using the site would be useful to people 
 trying it out?


 I agree with you, comments are not well-integrated and not really usable 
 right now, and it's not clear if (or how) they fit in the current iteration 
 of the project.
 I was inspired by clojuredocs.org commenting system, which I think is 
 really useful, but I don't have a clear answer right now on how it's 
 possible to bootstrap some kind of community activity around CrossClj. 
 Maybe it's a viable and good idea, maybe not.
  


 Finally, maybe you already explained this somewhere, so forgive me if I'm 
 adding noise, but are you using tools.analyze, codeq, etc. to do this? If 
 not, I'd be interested in hearing more about how you built it.


 It's not much complicated: for each namespace in each project, 
 tools.analyzer.* produces an AST that resolves var occurrences (definitions 
 and applications) in the source code into their fully namespace-qualified 
 vars; pomegranate resolves namespaces into their fully qualified artifacts 
 (in terms of maven coordinates). The combination of the two generates a 
 coherent addressing space that is used to generate the hyperlinks. Actual 
 links are positioned in the source code using the metadata in the AST.
 Lucene is used to maintain the inverse index (ie. var definition - var 
 application).
 Of course namespaces need to be macroexpanded and fully evaluated, which 
 causes a lot of funny side effects ;-) 

 Hope

Re: [ANN] CrossClj, a tool for cross-referencing the clojure ecosystem

[Francesco Bellomi]

Hi Mike,

On Wednesday, June 11, 2014 5:53:47 PM UTC+2, Mike Haney wrote:

 Very cool.  Is there a public REST api?


Not at the moment, but I'm open to suggestions from the community
 

 I ask because I'm thinking a lighttable plugin that uses this to search 
 for dependencies and automatically add them to project.clj would be pretty 
 easy to write and quite useful.  Yes, I could use clojars directly, but 
 this would allow more options in the future.

If you want to work with dependencies, Pomegranate [1] is a very good 
interface to Aether [2], for working with all JVM artifact repositories. 
CrossClj does not add more reasoning on top of what is provided by 
Pomegranate. However, I understand that Pomegranate is not usable from 
ClojureScript.

IMO, searching function definitions and function applications across the 
whole ecosystem would not be very usable from an IDE, since you don't have 
all artifacts locally installed; as far as you have them installed, an 
intelligent IDE such as Cursive can perform all kinds of magic, otherwise 
the next best solution is to use a site like CrossClj which enables 
exploratory browsing on libraries you don't have (yet) installed.

But still, I'm open to the discussion, and I will keep in mind your 
suggestion.

[1] https://github.com/cemerick/pomegranate
[2] https://eclipse.org/aether/

Francesco
 

-- 
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] CrossClj, a tool for cross-referencing the clojure ecosystem

[Francesco Bellomi]

Hi Gabriel,

On Wednesday, June 11, 2014 6:15:14 PM UTC+2, cldwalker wrote:


 Any plans on open sourcing some of this? I'd be interested to make this 
 (or an offshoot) that is a canonical site for clojar documentation much 
 like http://rdoc.info/ is for ruby gems.


I have some ideas for CrossClj's future, but I'm interested in hearing from 
the community as well.

My original goals were:

1) to enable some kind of exploratory browsing of source code (I spent a 
lot of time reading Clojure code on GitHub, but GitHub's UI does not make 
very easy to follow the logic flow through different namespaces or 
different projects)

2) to make it easy to search for examples of usages of library functions

Some ideas for the future:

3) to integrate some documentation generation tools (maybe Codox? or 
Marginalia?)

4) I'm interested in static analysis tools. Eastwood [1], as an example, is 
an excellent tool has lots of potential, even if I'm not sure if it's ready 
for a really massive usage on the whole repository

5) Also core.typed is really interesting to me, even if it's not yet clear 
to me how it could be integrated. As an example, type annotations could be 
propagated across dependencies and type inferences could be visualized. 
However, I'm not sure if core.typed is ready for casual use.

I'm not closed to the possibility of open sourcing the code, but at the 
moment it's not very polished, and I want to better understand where the 
project is headed.

thanks for your suggestions, they are very appreciated.

Francesco 

[1] https://github.com/jonase/eastwood
 


 Gabriel
  


-- 
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] CrossClj, a tool for cross-referencing the clojure ecosystem

[Francesco Bellomi]

Devin,

On Wednesday, June 11, 2014 6:25:13 PM UTC+2, Devin Walters (devn) wrote:

 A few nitpicks:


Thanks for your feedback; I really appreciate any opinion or suggestion, 
especially related to the UI
 

  
 - I find the usability to be a bit difficult in some places. For instance, 
 search results and specific function pages feel kind of cluttered.


I understand that. I was trying to cram as much info as possible, and I was 
too lazy to write some basic pagination facility. I think that the problem 
is especially relevant when you have a lot of results. 
 

 - What does Some other projects... mean? Are they related to the 
 function I'm viewing, or are they just random projects?


Totally random. I was trying to enable/facilitate some serendipitous 
exploration.
 

 - It's not clear what kind of interaction is being encouraged by adding 
 the Google+ comments box. Maybe a slightly longer up-front explanation 
 about how you envision people using the site would be useful to people 
 trying it out?


I agree with you, comments are not well-integrated and not really usable 
right now, and it's not clear if (or how) they fit in the current iteration 
of the project.
I was inspired by clojuredocs.org commenting system, which I think is 
really useful, but I don't have a clear answer right now on how it's 
possible to bootstrap some kind of community activity around CrossClj. 
Maybe it's a viable and good idea, maybe not.
 


 Finally, maybe you already explained this somewhere, so forgive me if I'm 
 adding noise, but are you using tools.analyze, codeq, etc. to do this? If 
 not, I'd be interested in hearing more about how you built it.


It's not much complicated: for each namespace in each project, 
tools.analyzer.* produces an AST that resolves var occurrences (definitions 
and applications) in the source code into their fully namespace-qualified 
vars; pomegranate resolves namespaces into their fully qualified artifacts 
(in terms of maven coordinates). The combination of the two generates a 
coherent addressing space that is used to generate the hyperlinks. Actual 
links are positioned in the source code using the metadata in the AST.
Lucene is used to maintain the inverse index (ie. var definition - var 
application).
Of course namespaces need to be macroexpanded and fully evaluated, which 
causes a lot of funny side effects ;-) 

Hope this helps, feel free to ask for more details

Francesco



 


 Thanks for building this. I look forward to playing around with it.

 Cheers,
 -- 
 Devin Walters

 On Wednesday, June 11, 2014 at 10:53 AM, Mike Haney wrote:

 Very cool. Is there a public REST api?

 I ask because I'm thinking a lighttable plugin that uses this to search 
 for dependencies and automatically add them to project.clj would be pretty 
 easy to write and quite useful. Yes, I could use clojars directly, but this 
 would allow more options in the future.

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

[ANN] CrossClj, a tool for cross-referencing the clojure ecosystem

[Francesco Bellomi]

Hello everyone,

http://crossclj.info

I've been working on CrossClj for some time now, and I feel it has grown 
usable (and useful) enough to make a public announcement.

CrossClj is a tool to explore the whole Clojure(-script) open-source 
ecosystem as an interconnected codebase.

The source code of Leiningen projects published as Clojars artifacts is 
rendered as a hypertext; each var occurrence is linked to its definition 
(namespaces belonging to different artifacts are resolved using maven 
coordinates), and each reference to a method/class of the standard Java JDK 
lib is linked to the Oracle documentation.

Starting from a var definition, it is possible to list all the qualified 
occurrences of the var across all the indexed projects; or it is possible 
to search all namespaces in all projects for vars with a given name.

A project should be automatically listed, provided that the following 
conditions are met:
- The project is deployed on Clojars under a public group (not a 
org.clojars.* user group)
- The project uses Leiningen and provides a project.clj with a description.
- The project has at least one non-SHAPSHOT release.
- Source code is incuded into project's artifact, and hosted publicly on 
GitHub (i.e. there is a github reference on the project's POM under the url 
or scm/connection fields). This almost ensures that the source code license 
is compatible with CrossClj's usage.

Some examples illustrating various features:

http://crossclj.info/ns/org.clojure/tools.analyzer/0.2.1/clojure.tools.analyzer.html#_macroexpand
http://crossclj.info/fun/clojure.core/reduce.html
http://crossclj.info/search?q=map
http://crossclj.info/ns/ring/ring-core/1.3.0/project.clj.html
http://crossclj.info/ns/org.clojure/clojure/1.6.0/clojure.core.html
http://crossclj.info/ns/garden/1.1.7/garden.stylesheet.cljs.html

The cross-reference index and the website content is updated daily, by 
looking at Clojars' feed (http://clojars.org/repo/feed.clj.gz), and by 
fetching the new artifacts that match the above constraints. The impact in 
terms of bandwidth is negligible.
The update process is designed to be fully automated, but as of today it is 
still initiated manually because there are some quality issues that needs 
to be worked out.

There are some scattered defects in the code analysis, due to my not yet 
perfect use of the tools.analyzer.* toolchain. 
Clojurescript macros definitions aren't yet cross-references.

The fact that the open source Clojure ecosystem still has a manageable size 
(about 3500 projects are indexed now) makes this kind of tools very cheap 
to operate, and opens up many possibilities for the future, like 
batch-executing other static analysis tools.

Francesco Bellomi
@fbellomi
@crossclojure

-- 
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: Interest in a commercial IDE for Clojure?

[Francesco Bellomi]

I agree with Matt that a commercial plugin for IntelliJ would be mainly 
targeted at people already using and preferring IntellJ, but this could be 
an interesting market.

As a personal note, I have tried CCW and found it a beautiful piece of 
software, but the fact is that I simply prefer IntelliJ over Eclipse for 
many big and small reasons.
It would be very difficult for me to leave IntelliJ, even if the current 
version of La Clojure has a lot of problems.
I suspect that there is a sort of rigid demand for plugins for each of 
the major IDEs, simply because of the investments people have put into them.

I would be willing to pay a price in the suggested range even to access the 
current alpha/beta version of the plugin, if it's better than the current 
La Clojure build. Colin, if you are open and interested to this kind of 
proposal you may contact me privately at francesco.bellomi(at)gmail.

In any case, I wish you good luck with this project

Francesco 

On Sunday, July 28, 2013 11:07:18 PM UTC+2, matt hoffman wrote:

 I've been watching your fork on Github for a while -- I've been excited to 
 see that someone is actively working on La Clojure. I would pay for an 
 IntelliJ plugin that was significantly better than La Clojure, but I'm also 
 aware that I'd be paying just for my preference of IntelliJ over Eclipse 
 for mixed Java/Clojure development. For pure Clojure development, Emacs 
 would also be a contender. So that would be a really tough market. 
 It would be a tough sell for my company, as well. They pay for IntelliJ 
 Ultimate licenses, and if we told them we wanted to add in $200 more for a 
 Clojure plugin, I'd have to be prepared to re-open the just use Eclipse 
 argument. 

 I'd also contribute to a Kickstarter, if you decided to go that route. I 
 don't imagine you could make a living off of it that way, but you might be 
 able to recoup some of your time.  A couple of developers in my company 
 have talked about funding a bounty for nrepl integration alone. 



 On Sat, Jul 27, 2013 at 3:20 PM, kovas boguta 
 kovas@gmail.comjavascript:
  wrote:

 My suggestion: release as open source, and then try a kickstarter to see 
 if there is interest in extending/continuing the project.

 IDE is a tough business. It has broken many. After all there is a reason 
 intellij open-sourced the core in the first place.

 Frankly I think there is a bigger market in using clojure to develop 
 better tools for other languages. If you have a nice intellij wrapper, then 
 you have a huge advantage in developing tooling in general. 

 On a side note, I would love to see intellij's widget library broken out 
 in a more stand-alone way, so we can develop sexy clojure apps with pure 
 jvm technology. Any thoughts on if that is technically doable?







 On Sat, Jul 27, 2013 at 4:54 AM, Colin Fleming 
 colin.ma...@gmail.comjavascript:
  wrote:

 Hi all,

 I was planning to wait a little longer before going public, but since 
 it's pretty relevant to the other IntelliJ thread going on at the moment I 
 thought I'd jump in. For the last couple of months of happy unemployment 
 I've been working on a fork of La Clojure which is now about 70% migrated 
 to Clojure and significantly improved. It's a lot of work to develop a tool 
 like this, and one of the options I'm considering is starting a company to 
 develop it as a commercial product - JetBrains have never maintained 
 development of La Clojure very actively. I've been doing a little market 
 research but there's really not much data around about whether there are 
 enough people working with Clojure to sustain a product like that, and also 
 the community is currently very focused on open source.

 One problem is that the IDE space is already fairly fractured - there's 
 Emacs and CCW, Clooj, Sublime Text and the promise of Light Table at some 
 point, and of course the current public version of La Clojure. But there's 
 still not a great option for something that's powerful but easy to use - 
 CCW is probably the closest thing to this right now. However I think it's 
 telling that a large fraction of people in the State of Clojure 2012 survey 
 still identified development tools as a major pain point.

 I think that the IntelliJ platform is a fantastic base to build 
 something like this on. Clojure as a language makes it pretty challenging 
 to develop a lot of the great functionality that JetBrains are famous for, 
 but I think there's scope to do a lot of great things. Certainly for mixed 
 Clojure/Java projects it would be difficult to beat, but even for Clojure 
 only projects I can imagine a lot of fantastic functionality built on their 
 infrastructure. My plan would be to release a standalone IDE and a plugin 
 for people using IntelliJ Ultimate for web dev, Ruby/Python or whatever. 
 Since it's mostly Clojure now (and I'm migrating what's left as I get to 
 it) there's a real possibility of a Clojure plugin/extension API. I 
 envision 

Re: Interest in a commercial IDE for Clojure?

[Francesco Bellomi]

Hi Colin,

I'm a long time IntelliJ user and I would gladly pay for a serious Clojure 
plugin.

Francesco

On Saturday, July 27, 2013 1:54:58 PM UTC+2, Colin Fleming wrote:

 Hi all,

 I was planning to wait a little longer before going public, but since it's 
 pretty relevant to the other IntelliJ thread going on at the moment I 
 thought I'd jump in. For the last couple of months of happy unemployment 
 I've been working on a fork of La Clojure which is now about 70% migrated 
 to Clojure and significantly improved. It's a lot of work to develop a tool 
 like this, and one of the options I'm considering is starting a company to 
 develop it as a commercial product - JetBrains have never maintained 
 development of La Clojure very actively. I've been doing a little market 
 research but there's really not much data around about whether there are 
 enough people working with Clojure to sustain a product like that, and also 
 the community is currently very focused on open source.

 One problem is that the IDE space is already fairly fractured - there's 
 Emacs and CCW, Clooj, Sublime Text and the promise of Light Table at some 
 point, and of course the current public version of La Clojure. But there's 
 still not a great option for something that's powerful but easy to use - 
 CCW is probably the closest thing to this right now. However I think it's 
 telling that a large fraction of people in the State of Clojure 2012 survey 
 still identified development tools as a major pain point.

 I think that the IntelliJ platform is a fantastic base to build something 
 like this on. Clojure as a language makes it pretty challenging to develop 
 a lot of the great functionality that JetBrains are famous for, but I think 
 there's scope to do a lot of great things. Certainly for mixed Clojure/Java 
 projects it would be difficult to beat, but even for Clojure only projects 
 I can imagine a lot of fantastic functionality built on their 
 infrastructure. My plan would be to release a standalone IDE and a plugin 
 for people using IntelliJ Ultimate for web dev, Ruby/Python or whatever. 
 Since it's mostly Clojure now (and I'm migrating what's left as I get to 
 it) there's a real possibility of a Clojure plugin/extension API. I 
 envision charging PyCharm/RubyMine type prices, say $200 for company 
 licenses or $100 for individual developers.

 So, I'd love to hear what people think. I'd appreciate it if we could stay 
 away from the politics of open source vs proprietary - several people have 
 told me privately that they'd rather use OSS and that's fine, proprietary 
 isn't for everyone. What I'd like to know is if the idea is appealing to 
 many people here?

 In case it's a concern for anyone, I've discussed this with JetBrains.

 Thanks for any feedback,

 Cheers,
 Colin


-- 
-- 
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 runtime fails to initialize in some contexts

[Francesco Bellomi]

I've solved my specific instance of this problem, I post here the details 
in the hope that the solution has a more general validity.

It seems that clojure.lang.RT gets confused when it is initialized (ie. 
clinit is called) and the classloader used to load the class itself is 
different from the current thread's context classloader.

If I do:

Thread.currentThread().setContextClassLoader(this.getClass.getClassLoader)

just before making the call that cause Clojure runtime to be loaded and 
initialized, the error disappears.

Francesco




On Thursday, January 24, 2013 2:44:21 PM UTC+1, Francesco Bellomi wrote:

 (I repost this message because the original post I made yesterday seems to 
 have been rejected by googlegroups -- I have not received it and it is not 
 available online.
 Sorry if this will result in a double post for some users.)

 Hi all,

 I'm writing a Scala library (currently alpha) to simplify the use of 
 Datomic (http://www.datomic.com) from Scala:
 https://github.com/fbellomi/**datomic-scalahttps://github.com/fbellomi/datomic-scala

 I would like to make use of Scala compile-time macros in order to 
 statically type-check Datomic queries against a live database schema.
 I need to call Datomic API from within the Scala compiler's macro 
 expansion stage, but it turns out that Clojure runtime fails to initialize 
 within that stage.

 A simple evaluation such as:

 clojure.lang.RT.T

 works fine from Scala's REPL, but fails from within Scala compiler, with 
 the following exception

 error: exception during macro expansion: 
 java.lang.**IllegalStateException: Attempting to call unbound fn: 
 #'clojure.core/refer
 at clojure.lang.Var$Unbound.**throwArity(Var.java:43)
 at clojure.lang.AFn.invoke(AFn.**java:39)
 at clojure.lang.Var.invoke(Var.**java:415)
 at clojure.lang.RT.doInit(RT.**java:449)
 at clojure.lang.RT.clinit(RT.**java:318)
 at .foo_impl(console:8)

 Not only the classpath, but also the thread context ClassLoader is the 
 same in both cases.

 I posted the details here:

 https://groups.google.com/forum/?hl=enfromgroups=#!topic/scala-user/Bh_YmI6e-wY

 One could argue that this seems to be more of a Scala issue, but I did a 
 search and it turns out that there are other similar situations where the 
 Clojure runtime fails to initialize with the same error:

 - from within a Nutch plugin:

 https://groups.google.com/forum/?hl=enfromgroups=#!searchin/clojure/nutch$20plugin/clojure/Fbqrk1T8SRg/CbQDd1yBvjYJ

 - trying to deploy an EJB

 https://groups.google.com/forum/?hl=enfromgroups=#!searchin/clojure/ejb/clojure/FFe7Pf9TfXc/rxmYq6IoIjMJ

 - naming your project clojure in lein
 http://osdir.com/ml/java-clojure-user/2012-04/msg00913.html


 To further investigate my case, I tried to force the startup from core.clj 
 rather than from the precompiled classes.
 Also in this case, the same call from the Scala repl works fine, whereas 
 the call from within the Scala macro expansion fails, with this:

 ava.lang.ClassCastException: clojure.core$fn cannot be cast to 
 clojure.lang.IFn, compiling:(clojure/core.clj:55)
 at clojure.lang.Compiler.analyzeSeq(Compiler.java:6462)
 at clojure.lang.Compiler.analyze(Compiler.java:6262)
 at clojure.lang.Compiler.access$100(Compiler.java:37)
 at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:518)
 at clojure.lang.Compiler.analyzeSeq(Compiler.java:6455)
 at clojure.lang.Compiler.analyze(Compiler.java:6262)
 at clojure.lang.Compiler.analyze(Compiler.java:6223)
 at clojure.lang.Compiler.eval(Compiler.java:6515)
 at clojure.lang.Compiler.load(Compiler.java:6952)
 at clojure.lang.RT.loadResourceScript(RT.java:359)
 at clojure.lang.RT.loadResourceScript(RT.java:350)
 at clojure.lang.RT.load(RT.java:429)
 at clojure.lang.RT.load(RT.java:400)
 at clojure.lang.RT.doInit(RT.java:436)
 at clojure.lang.RT.clinit(RT.java:318)
 at .foo_impl(console:8)
 Caused by: java.lang.ClassCastException: clojure.core$fn cannot be cast to 
 clojure.lang.IFn
 at clojure.lang.Var.fn(Var.java:392)
 at clojure.lang.Var.invoke(Var.java:431)
 at clojure.lang.AFn.applyToHelper(AFn.java:178)
 at clojure.lang.Var.applyTo(Var.java:532)
 at clojure.lang.Compiler.macroexpand1(Compiler.java:6366)
 at clojure.lang.Compiler.analyzeSeq(Compiler.java:6441)
 at clojure.lang.Compiler.analyze(Compiler.java:6262)
 at clojure.lang.Compiler.access$100(Compiler.java:37)
 at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:518)
 at clojure.lang.Compiler.analyzeSeq(Compiler.java:6455)
 at clojure.lang.Compiler.analyze(Compiler.java:6262)
 at clojure.lang.Compiler.analyze(Compiler.java:6223)
 at clojure.lang.Compiler.eval(Compiler.java:6515)
 at clojure.lang.Compiler.load(Compiler.java:6952)
 at clojure.lang.RT.loadResourceScript(RT.java:359)
 at clojure.lang.RT.loadResourceScript(RT.java:350)
 at clojure.lang.RT.load(RT.java:429)
 at clojure.lang.RT.load(RT.java:400)
 at clojure.lang.RT.doInit(RT.java:436)
 at clojure.lang.RT.clinit(RT.java:318)

 Thanks in advance for any help

Clojure runtime fails to initialize in some contexts

[Francesco Bellomi]

(I repost this message because the original post I made yesterday seems to 
have been rejected by googlegroups -- I have not received it and it is not 
available online.
Sorry if this will result in a double post for some users.)

Hi all,

I'm writing a Scala library (currently alpha) to simplify the use of 
Datomic (http://www.datomic.com) from Scala:
https://github.com/fbellomi/**datomic-scalahttps://github.com/fbellomi/datomic-scala

I would like to make use of Scala compile-time macros in order to 
statically type-check Datomic queries against a live database schema.
I need to call Datomic API from within the Scala compiler's macro expansion 
stage, but it turns out that Clojure runtime fails to initialize within 
that stage.

A simple evaluation such as:

clojure.lang.RT.T

works fine from Scala's REPL, but fails from within Scala compiler, with 
the following exception

error: exception during macro expansion: 
java.lang.**IllegalStateException: Attempting to call unbound fn: 
#'clojure.core/refer
at clojure.lang.Var$Unbound.**throwArity(Var.java:43)
at clojure.lang.AFn.invoke(AFn.**java:39)
at clojure.lang.Var.invoke(Var.**java:415)
at clojure.lang.RT.doInit(RT.**java:449)
at clojure.lang.RT.clinit(RT.**java:318)
at .foo_impl(console:8)

Not only the classpath, but also the thread context ClassLoader is the same 
in both cases.

I posted the details here:
https://groups.google.com/forum/?hl=enfromgroups=#!topic/scala-user/Bh_YmI6e-wY

One could argue that this seems to be more of a Scala issue, but I did a 
search and it turns out that there are other similar situations where the 
Clojure runtime fails to initialize with the same error:

- from within a Nutch plugin:
https://groups.google.com/forum/?hl=enfromgroups=#!searchin/clojure/nutch$20plugin/clojure/Fbqrk1T8SRg/CbQDd1yBvjYJ

- trying to deploy an EJB
https://groups.google.com/forum/?hl=enfromgroups=#!searchin/clojure/ejb/clojure/FFe7Pf9TfXc/rxmYq6IoIjMJ

- naming your project clojure in lein
http://osdir.com/ml/java-clojure-user/2012-04/msg00913.html


To further investigate my case, I tried to force the startup from core.clj 
rather than from the precompiled classes.
Also in this case, the same call from the Scala repl works fine, whereas 
the call from within the Scala macro expansion fails, with this:

ava.lang.ClassCastException: clojure.core$fn cannot be cast to 
clojure.lang.IFn, compiling:(clojure/core.clj:55)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6462)
at clojure.lang.Compiler.analyze(Compiler.java:6262)
at clojure.lang.Compiler.access$100(Compiler.java:37)
at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:518)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6455)
at clojure.lang.Compiler.analyze(Compiler.java:6262)
at clojure.lang.Compiler.analyze(Compiler.java:6223)
at clojure.lang.Compiler.eval(Compiler.java:6515)
at clojure.lang.Compiler.load(Compiler.java:6952)
at clojure.lang.RT.loadResourceScript(RT.java:359)
at clojure.lang.RT.loadResourceScript(RT.java:350)
at clojure.lang.RT.load(RT.java:429)
at clojure.lang.RT.load(RT.java:400)
at clojure.lang.RT.doInit(RT.java:436)
at clojure.lang.RT.clinit(RT.java:318)
at .foo_impl(console:8)
Caused by: java.lang.ClassCastException: clojure.core$fn cannot be cast to 
clojure.lang.IFn
at clojure.lang.Var.fn(Var.java:392)
at clojure.lang.Var.invoke(Var.java:431)
at clojure.lang.AFn.applyToHelper(AFn.java:178)
at clojure.lang.Var.applyTo(Var.java:532)
at clojure.lang.Compiler.macroexpand1(Compiler.java:6366)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6441)
at clojure.lang.Compiler.analyze(Compiler.java:6262)
at clojure.lang.Compiler.access$100(Compiler.java:37)
at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:518)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6455)
at clojure.lang.Compiler.analyze(Compiler.java:6262)
at clojure.lang.Compiler.analyze(Compiler.java:6223)
at clojure.lang.Compiler.eval(Compiler.java:6515)
at clojure.lang.Compiler.load(Compiler.java:6952)
at clojure.lang.RT.loadResourceScript(RT.java:359)
at clojure.lang.RT.loadResourceScript(RT.java:350)
at clojure.lang.RT.load(RT.java:429)
at clojure.lang.RT.load(RT.java:400)
at clojure.lang.RT.doInit(RT.java:436)
at clojure.lang.RT.clinit(RT.java:318)

Thanks in advance for any help or pointer.

Francesco

-- 
-- 
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: Reactions to google dart?

[Francesco Bellomi]

I think Dart could be an interesting lower-level target language, if the 
dart VM will prove to be intrinsically better than the JS VM.

Francesco 

On Tuesday, October 11, 2011 10:14:33 AM UTC+2, Sidharth Kshatriya wrote:

 The thing that they are keeping secret is putting the Dart VM in the 
 browser.

 I thinks that is when things might get interesting
 * The Dart VM will allow loading images of a program ala smalltalk. This 
 will solve the startup problems associated with programs like gmail.
 * The Language grammar I think is deliberately simple so that VM can run it 
 fast. How fast is it to interpret Ruby for instance? The more complicated 
 the language ... the more difficult it is to get high performance... 


  

-- 
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: ANN: Indyvon - GUI library

[Francesco Bellomi]

Very interesting concept, thank you for sharing.

Francesco



On Sep 8, 3:39 am, Mikhail Kryshen mikh...@kryshen.net wrote:
 Hi,

 I have recently published Indyvon -- an experimental multithreaded GUI
 library for Clojure. The main idea behind the library is that base UI
 element (called layer) does not define any state (has no location,
 size, parent element). Dynamic layout of layers is captured at the
 rendering time and remembered for event processing until the next
 repaint is complete. Java 2D API is used for rendering.

 Source code:http://bitbucket.org/kryshen/indyvon/src

 See README there for a more detailed description.
 src/net/kryshen/indyvon/demo.clj contains runnable example.

 Currently only some basic layers are implemented (no normal widgets)
 and I have no plan to build a complete GUI toolkit. I am using the
 library in another project for graph visualization.

 Expect bad English style (I am not native speaker) in readme and
 docstrings, corrections are welcome.

 --
 Mikhail

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

Type hints in protocols and records

[Francesco Bellomi]

Hello,

I'm trying to use type hints in protocols and records, but I found
some strange behavior.

As an example, if I use:

(defprotocol test
  (test-fn [a ^String b]))

the type hint in test-fn is parsed correctly (or at least without
raising an error), but then...

(defrecord test-record [x y z]
  test
  (test-fn [a  b] b))

user= (def q (test-record. 1 2 3))
#'user/q
user= (test-fn q 1)
1

...it is not used or even enforced when I implement the protocol
within a record.
If I use a compatible type hint in the record definition, I have an
error

(defrecord test-record [x y z]
  test
  (test-fn [a ^String b] b))

java.lang.IllegalArgumentException: Can't find matching method:
test_fn, leave off hints for auto match.

It is not clear to me if type hints are supported in protocols, and if
so, how I can use them.

thanks in advance, Francesco

-- 
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: Type hints in protocols and records

[Francesco Bellomi]

thanks David,

Is the support for type hints in protocols planned for future
releases?

Francesco

On Aug 28, 5:10 pm, David Nolen dnolen.li...@gmail.com wrote:
 On Sat, Aug 28, 2010 at 9:46 AM, Francesco Bellomi 

 francesco.bell...@gmail.com wrote:
  It is not clear to me if type hints are supported in protocols, and if
  so, how I can use them.

  thanks in advance, Francesco

 Hints are not supported in protocols as far as I can tell. They are
 supported in definterface.

 David

-- 
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: Java 6 dependency in clojure-contrib ok?

[Francesco Bellomi]

Looks like an interesting idea for me; it would also allow for
automated dependency analysis for a given target jvm.

btw, I'd also prefer to have 1.5 compatibility

Francesco

On Apr 9, 2:24 am, Howard Lewis Ship hls...@gmail.com wrote:
 Looks like we need a macro:

 (for-jvm 1.5 ()
              1.6 ())


--~--~-~--~~~---~--~~
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
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: Directed Graphs for Contrib

[Francesco Bellomi]

I agree -- an important goal is to define a suitable common way to
represent graphs in terms of idiomatic Clojure data structures.

Francesco

On Feb 22, 4:11 pm, Jeffrey Straszheim straszheimjeff...@gmail.com
wrote:
 Just as a point of fact, I don't plan to make a complete *every algorithm
 you can think of* package, just the ones I need.  However, it would be easy
 to add others submitted by the community.  I could be a gathering place of
 graph algorithms.


--~--~-~--~~~---~--~~
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
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: Directed Graphs for Contrib

[Francesco Bellomi]

+1

Francesco

On Feb 22, 2:59 am, Jeffrey Straszheim straszheimjeff...@gmail.com
wrote:
 As part of my Datalog work I'm putting together some directed graph
 algorithms, mostly things like finding strongly connected components, and
 building dependency stratifications (think topological sort but with the
 results groups in tiers of non-interdependent nodes).  Anyhow, I'm thinking
 this stuff will be usefull outside of Datalog, and am wondering if I should
 just add it to contrib as a stand-alone library?
--~--~-~--~~~---~--~~
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
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: IntelliJ Plugin Pre-Alpha 0.03 Available

[Francesco Bellomi]

I installed it and it works really well,
-- thanks to the authors for their work.

btw, I installed it directly on my mac, without building it.

Francesco

On Jan 23, 6:08 pm, Peter Wolf opus...@gmail.com wrote:
 For those who like IntelliJ, a new version of the plugin is available.  
 This one has numerous fixes, but is mostly interesting because the
 Debugger and Profiler work (or at least JProfiler).

 The Debugger and Profiler currently treat Clojure as compiled Java, and
 don't know how to go from byte code location to source code.  But there
 is enough information that one can figure out what is going on.

 Note that Mac users still have to build it themselves.  If someone would
 build it, so we can post a Mac jar that would be great.

 http://code.google.com/p/clojure-intellij-plugin/

 Enjoy!
 P
--~--~-~--~~~---~--~~
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
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: IntelliJ Plugin Pre-Alpha 0.03 Available

[Francesco Bellomi]

IntelliJ 8.1 EAP build 9678 (which is the last released build)
Mac Book Pro 10.5.6
java 1.5.0_16

I installed it through Updates / Plugins Host, as explained on the
plugin dev site.

Francesco

On Jan 23, 10:12 pm, Peter Wolf opus...@gmail.com wrote:
 You are more than welcome.  Enjoy!

 I am interested that it works on your Mac.  Others have reported
 problems (but not with this particular JAR).  What version of Mac and
 IntelliJ are you using?

 Peter

 Francesco Bellomi wrote:
  I installed it and it works really well,
  -- thanks to the authors for their work.

  btw, I installed it directly on my mac, without building it.

  Francesco

  On Jan 23, 6:08 pm, Peter Wolf opus...@gmail.com wrote:

  For those who like IntelliJ, a new version of the plugin is available.  
  This one has numerous fixes, but is mostly interesting because the
  Debugger and Profiler work (or at least JProfiler).

  The Debugger and Profiler currently treat Clojure as compiled Java, and
  don't know how to go from byte code location to source code.  But there
  is enough information that one can figure out what is going on.

  Note that Mac users still have to build it themselves.  If someone would
  build it, so we can post a Mac jar that would be great.

 http://code.google.com/p/clojure-intellij-plugin/

  Enjoy!
  P
--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---