Newify java class dynamically
Hi all, I am writing a function that'll take a java class name as an arg, wherein I'll make instance of the class. Several approaches did I try: (let [klass Integer] (new klass 42)) ; this raises exception unable to resolve symbol: klass (let [klass Integer] (.new klass 42)) ; raises no matching method found: new for class java.lang. Class I'm running out of ideas currently. How do you deal the use case like this? And what's the idiomatic way to do this? Thanks! — Sent from Mailbox -- 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: Newify java class dynamically
On 03/09/2015 15:45, Juvenn Woo wrote: Hi all, I am writing a function that'll take a java class name as an arg, wherein I'll make instance of the class. Several approaches did I try: (let [klass Integer] (new klass 42)) ; this raises exception unable to resolve symbol: klass (let [klass Integer] (.new klass 42)) ; raises no matching method found: new for class java.lang. Class I'm running out of ideas currently. How do you deal the use case like this? And what's the idiomatic way to do this? You can use Java reflection for this or use the Reflector from Clojure: (let [klass Integer] (clojure.lang.Reflector/invokeConstructor klass (into-array [42]))) -- 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.
New Functional Programming Job Opportunities
Here are some functional programming job opportunities that were posted recently: Software Developer at Democracy Works, Inc. http://functionaljobs.com/jobs/8794-software-developer-at-democracy-works-inc Hacker (Node.js, NOSQL, Data Science) at Mobitrans http://functionaljobs.com/jobs/8793-hacker-nodejs-nosql-data-science-at-mobitrans Full-Stack Senior Functional Web Engineer at Front Row Education http://functionaljobs.com/jobs/8792-full-stack-senior-functional-web-engineer-at-front-row-education Software Engineer at nToggle http://functionaljobs.com/jobs/8791-software-engineer-at-ntoggle Cheers, Sean Murphy FunctionalJobs.com -- 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: Newify java class dynamically
Juvenn Woo mach...@gmail.com writes:
I am writing a function that'll take a java class name as an arg,
wherein I'll make instance of the class. Several approaches did I try:
(let [klass Integer] (new klass 42)) ; this raises exception unable to
resolve
symbol: klass
(let [klass Integer] (.new klass 42)) ; raises no matching method found: new
for class java.lang. Class
I'm running out of ideas currently. How do you deal the use case like
this? And what's the idiomatic way to do this?
I think there's no generic predefined way to do this and you have to do
the same as what you would need to do in Java, too. I.e., use
reflection to enumerate the given class' constructors in order to find
the one you want to call (correct number and types of its arguments).
But maybe you can use something less generic in your scenario, e.g.:
--8---cut here---start-8---
(let [constructors {Integer #(Integer. %)
Long#(Long. %)
java.awt.Dimension #(java.awt.Dimension. % %)}
make (fn [type args]
(apply (constructors type) args))]
(for [cls [Integer Long java.awt.Dimension]]
(make cls 1)))
;;= (1 1 #Dimension java.awt.Dimension[width=1,height=1])
--8---cut here---end---8---
Bye,
Tassilo
--
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] full.async - core.async add-on
Hi Everyone, I would like to announce full.async, a core.async add-on that simplifies exception handling and working with collections. It also implements pmap for go channels as well as go block with retry logic. We have been using core.async for building production backend services extensively for the last 6 months. Even in alpha it has been very solid and joy to work with. There were couple areas where we felt we could make it a bit more convenient. For example we had to use bunch of Java libraries that love to throw. This is where full.async was born - a convenience layer on top of core.async for common use cases. More information on Github repo: https://github.com/fullcontact/full.async - Kaspars (@k7d) -- 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: [OT?] Best DB/architecture for n-gram corpus?
One thing you can do is index 1, 2, 3...n-grams and use a simple fast key-value store (like leveldb etc.) e.g., you could have entries like aunt rhodie - song-9, song-44 woman - song-12, song-65, song-96 That's basically how I made the Metafilter N-gram Viewer http://mefingram.appspot.com/, a clone of Google Books Ngram Viewer https://books.google.com/ngrams. Another possibility is using Lucene. Just be aware that Lucene calls n-grams of characters (au, un, nt) n-grams but it calls n-grams of words (that the, the old, old gray) shingles. So you would end up using (I think, I haven't done this) the ShingleFilter https://lucene.apache.org/core/4_2_0/analyzers-common/org/apache/lucene/analysis/shingle/ShingleFilter.html . You might also find this article by Russ Cox interesting, where he describes building and using an inverted trigram index: http://swtch.com/~rsc/regexp/regexp4.html John Three things that you might find interesting: Russ Cox' explanation of doing indexing and retrieval with an inverted trigram index: http://swtch.com/~rsc/regexp/regexp4.html On Sat, Mar 7, 2015 at 3:22 AM, Matching Socks phill.w...@gmail.com wrote: A lot of guys would use Lucene. Lucene calls n-grams of words shingles. [1] As for architecture, here is a suggestion to use Lucene to find keys to records in your real database. [2] [1] https://lucidworks.com/blog/whats-a-shingle-in-lucene-parlance/ [2] https://groups.google.com/d/msg/datomic/8yrCYxcQq34/GIomGaarX5QJ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] from-scala 0.2.0: An experimental Scala interop library for Clojure
Hi, I would like to announce from-scala, an experimental Scala interop library for Clojure. Its main feature is the $-macro, a version of Clojure's .-form. The $-macro uses Java reflection and a series of heuristics, so that you will be able to write code like ($ ($ scala.collection.immutable.List/empty) :: 1) instead of the equivalent but ugly (.$colon$colon (.empty scala.collection.immutable.List$/MODULE$) 1) Additionally there are some utility functions for working with case classes, tuples, options, Scala functions, and Scala collections. The source code can be found at https://github.com/t6/from-scala and there are more examples in the guide at https://t6.github.io/from-scala To use from Leiningen: [t6/from-scala 0.2.0] [org.scala-lang/scala-library 2.11.5] You need to provide your own Scala library. from-scala has been tested with Scala 2.10 and 2.11. If you encounter any bugs or road blocks, have a feature request, or want to discuss if this is a good or a bad idea, please open an issue on GitHub. Thanks, Tobias -- 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: Conditional dependency question
That did the trick, thanks! On Friday, March 6, 2015 at 11:30:42 AM UTC-5, Moritz Ulrich wrote: You need to use `ns-resolve' to resolve the actual vars you want to use. Here's a snippet from one of our projects which shows the approach: ```clojure (defn ws-repl [] (require 'cemerick.piggieback 'weasel.repl.websocket) (let [cljs-repl (ns-resolve 'cemerick.piggieback 'cljs-repl) repl-env (ns-resolve 'weasel.repl.websocket 'repl-env)] (cljs-repl :repl-env (repl-env :ip 0.0.0.0 :port 9009 :working-dir resources/public/out ``` Jonathon McKitrick jmcki...@gmail.com javascript: writes: I'm using environ and lein-environ to pick up dev settings, such as enabling weasel/piggieback in development. In my server module, I'm running this code in -main: (when (env :dev?) (println DEV) (require 'pts.dev) (pts.dev/browser-repl)) But pts.dev still throws a class not found exception. However, after the project has loaded and begins execution, I'm able to run that snippet successfully. What's the trick to getting pts.dev into the namespace conditionally? -- 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.
Re: [GSoC] Mentors contact information
My contact information is on the project page. On Mon, Mar 9, 2015 at 3:21 PM, Christopher Medrela chris.medr...@gmail.com wrote: Hello! My name is Christopher Medrela. I'm interested in participating in GSoC this year. I've looked at the ideas page and I think that I'd like to work at: * source metadata information model (mentored by Alex Miller) * or one of typed clojure projects (mentored by Ambrose Bonnaire-Sergeant). Could you share with me contact information to these mentors? Best regards! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[GSoC] Mentors contact information
Hello! My name is Christopher Medrela. I'm interested in participating in GSoC this year. I've looked at the ideas page and I think that I'd like to work at: * source metadata information model (mentored by Alex Miller) * or one of typed clojure projects (mentored by Ambrose Bonnaire-Sergeant). Could you share with me contact information to these mentors? Best regards! -- 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] Pink 0.1.0, Score 0.2.0
So the whole thing, including the engine is written in clojure/java? If so, how is the efficiency compared to supercollider or csound? -- 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] Pink 0.1.0, Score 0.2.0
Yes, Pink is written mostly in Clojure, with two Java classes there. In terms of efficiency, Pink is slower than SC and Csound. I found it a little hard to benchmark, as the systems aren't quite apples to apples (e.g., SuperCollider use a 32-bit signal processing chain, while Csound and Pink use 64-bit; I'm not sure what compiler flags were used for SC vs. Csound; etc.). I tried to come up with reasonable benchmark and what I did was use a simple SynthDef in SuperCollider, using a SinOsc with default 8192 table. That's a linear interpolating table oscillator. I did the same with Csound (oscili + gen10 sine), and Pink (oscili + gen-sine). So in that regards, all three systems were run using interpolating oscillators and 8192 sized tables. All three were run with 64-length internal block size, and 512 external block size (buffer size sent to the audio driver). With Csound, I started get buffer underruns at around 2000 oscillators. With Pink I got underruns at about 340 oscillators. With SC, I ran into an server limit on node instances once I got to 1030 (I'm guessing there is a 1024 limit). When I hit that limit, my cpu was at about 25% (2011 Macbook Pro, Core i7). Comparing Csound and Pink, Pink looks to be about 6.5-7x slower. While I'm still searching for ways to optimize Pink, I'm okay with the current performance as it is today, weighing it against the expressiveness of the system, ease of development, and other factors. On Mon, Mar 9, 2015 at 3:39 PM, aoeuyi qjkxbmwvz askwaz...@gmail.com wrote: So the whole thing, including the engine is written in clojure/java? If so, how is the efficiency compared to supercollider or csound? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/VC-Vk8o09CM/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Risk of unsafe publishing of LazyTransformer?
Hello,
I noticed that LazyTransformer [1] implements mutable state without any
volatile or final modifier to guard its fields (it might not be an isolated
case in the core library e.g. SeqIterator.java).
Isn't such class subject to unsafe publication?
For example, considering only this part of the implementation:
public final class LazyTransformer extends ... {
IStepper stepper;
Object first = null;
LazyTransformer rest = null;
public LazyTransformer(IStepper stepper){
this.stepper = stepper;
}
public static LazyTransformer create(IFn xform, Object coll){
return new LazyTransformer(new Stepper(xform, RT.iter(coll)));
}
...
public Object first(){
if(stepper != null)
seq();
if(rest == null)
return null;
return first;
}
public ISeq next(){
if(stepper != null)
seq();
if(rest == null)
return null;
return rest.seq();
}
..
}
If LazyTransformer/create is called in in one thread and then another
thread calls 'first' or 'next' on the new object then I would say there's a
chance the second thread sees stepper == null. A real use case could be one
thread calling (dedup) [2], which creates lazy sequence with (sequence
http://crossclj.info/ns/org.clojure/clojure/1.7.0-alpha5/clojure.core.html#_sequence
(dedupe
http://crossclj.info/ns/org.clojure/clojure/1.7.0-alpha5/clojure.core.html#_dedupe)
coll), and then another thread iterates through the sequence, which I
suppose relies on 'first' and 'next'.
To me it looks like the exact same situation as the one discussed on the
Java concurrency-interest here:
http://jsr166-concurrency.10961.n7.nabble.com/Safe-publishing-strategy-tt12126.html
I can't believe I'm the first to be worried by this so maybe I overlooked
something. But if I'm not wrong or if there is any doubt, next to
refactoring the code to use immutable classes with only final fields (my
preferred approach), wouldn't it be safer to declare at least 'stepper' as
volatile to prevent any of risk of nasty concurrency issue?
Thanks,
Sébastien
[1]
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazyTransformer.java
[2] http://crossclj.info/fun/clojure.core/dedupe.html
--
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] Chestnut 0.7.0
I've commented chestnut/lein-template from the ~/.lein/projects.clj as
follows, then it worked.
It worked using 0.6.0 if there was the chestnut/lein-template definition.
Was my usage wrong ?
{:user {:plugins [
[lein-try 0.4.3]
;[lein-pprint 1.1.1]
[lein-ancient 0.6.4 :exclusions
[org.clojure/core.cache]]
[lein-bikeshed 0.2.0]
[lein-ritz 0.7.0]
[lein-marginalia 0.8.0]
[http-kit/lein-template 1.0.0-SNAPSHOT]
[cider/cider-nrepl 0.9.0-SNAPSHOT]
[cljs-complete 0.1.1]
;;[chestnut/lein-template 0.7.0]
;;[chestnut/lein-template 0.6.0]
]
:dependencies [;;[nrepl-inspect 0.4.1]
[compliment 0.2.0]
[ritz/ritz-nrepl-middleware 0.7.0]
[cider/cider-nrepl 0.9.0-SNAPSHOT]
[alembic 0.2.1]
[org.clojure/tools.nrepl 0.2.7]
]
:repl-options {:nrepl-middleware
[cider.nrepl.middleware.classpath/wrap-classpath
cider.nrepl.middleware.complete/wrap-complete
cider.nrepl.middleware.info/wrap-info
cider.nrepl.middleware.inspect/wrap-inspect
cider.nrepl.middleware.stacktrace/wrap-stacktrace
cider.nrepl.middleware.trace/wrap-trace
]}
}}
Makoto
I ran into this same behavior, and then I realized it only happened if I
run the lein new command if I'm *already in* a previously-created
project created with lein new chestnut. I'm guessing that something in
the generated project.clj interferes some of the lein new behavior somehow.
At any rate, running lein new in a directory without a project.clj file in
it is working fine for me.
Tim
On Saturday, March 7, 2015 at 5:38:41 AM UTC-5, webber wrote:
I tested the v 0.7.0 of chestnut and I encountered the following error.
The v 0.6.0 works fine.
$ lein new chestnut test-app
Retrieving chestnut/lein-template/0.7.0/lein-template-0.7.0.pom from
clojars
Retrieving chestnut/lein-template/0.7.0/lein-template-0.7.0.jar from
clojars
Exception in thread main java.lang.ExceptionInInitializerError
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)
at clojure.lang.RT.loadClassForName(RT.java:2093)
at clojure.lang.RT.load(RT.java:430)
at clojure.lang.RT.load(RT.java:411)
at clojure.core$load$fn__5066.invoke(core.clj:5641)
at clojure.core$load.doInvoke(core.clj:5640)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5446)
at clojure.core$load_lib$fn__5015.invoke(core.clj:5486)
at clojure.core$load_lib.doInvoke(core.clj:5485)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:626)
at clojure.core$load_libs.doInvoke(core.clj:5524)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:626)
at clojure.core$require.doInvoke(core.clj:5607)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at stencil.core$loading__4958__auto__.invoke(core.clj:1)
at stencil.core__init.load(Unknown Source)
at stencil.core__init.clinit(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)
at clojure.lang.RT.loadClassForName(RT.java:2093)
at clojure.lang.RT.load(RT.java:430)
at clojure.lang.RT.load(RT.java:411)
at clojure.core$load$fn__5066.invoke(core.clj:5641)
at clojure.core$load.doInvoke(core.clj:5640)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5446)
at clojure.core$load_lib$fn__5015.invoke(core.clj:5486)
at clojure.core$load_lib.doInvoke(core.clj:5485)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:626)
at clojure.core$load_libs.doInvoke(core.clj:5524)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:626)
at clojure.core$require.doInvoke(core.clj:5607)
at clojure.lang.RestFn.invoke(RestFn.java:512)
at leiningen.new.templates$loading__4958__auto__.invoke(templates.clj:11)
at leiningen.new.templates__init.load(Unknown Source)
at leiningen.new.templates__init.clinit(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)
at clojure.lang.RT.loadClassForName(RT.java:2093)
at clojure.lang.RT.load(RT.java:430)
at clojure.lang.RT.load(RT.java:411)
at clojure.core$load$fn__5066.invoke(core.clj:5641)
at clojure.core$load.doInvoke(core.clj:5640)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5446)
at clojure.core$load_lib$fn__5015.invoke(core.clj:5486)
at clojure.core$load_lib.doInvoke(core.clj:5485)
at
ANN: ClojureScript 0.0-3058, Enhanced REPLs, faster compile times
ClojureScript, the Clojure compiler that emits JavaScript source code. README and source code: https://github.com/clojure/clojurescript New release version: 0.0-3058 Leiningen dependency information: [org.clojure/clojurescript 0.0-3058] This is a significant enhancement release around REPLs and compile times. All builtin REPLs (Nashorn, Node.js, Rhino and the browser REPL) now support the helper functions normally available via clojure.repl, these include: doc, find-doc, apropos, dir, source, and pst. All of the builtins REPL now also support source mapped stacktraces. This release also includes many enhancements around compile times. ClojureScript now ships with a default :optimizations setting of :none. Implicit now when using :none is source map generation and analysis caching. Analysis caching significantly speeds up compile times. The standard library (cljs.core) is now AOTed compiled to JavaScript along with an AOTed analysis dump and an AOTed source map. This dramatically cuts down on cold start compile times. The standard library is never actually ever analyzed or compiled in your own builds. The result is particularly dramatic for REPLs. ClojureScript is also now available for the first time as a standalone AOTed JAR. The Quick Start introduction has been rewritten in terms of the standalone JAR: https://github.com/clojure/clojurescript/wiki/Quick-Start The new Quick Start is essential reading even if you are a relatively experienced ClojureScript developer. As usual feedback welcome! ## 0.0-3058 ### Enhancements * browser REPL source mapping for Firefox, Safari, Chrome * macro support in REPL special functions * CLJS-897: AOT core.cljs CLJS-899: AOT cache core.cljs analysis * CLJS-1078: Nashorn REPL should use persistent code cache * CLJS-1079: add way to execute arbitrary fn upon watch build completion * CLJS-1034: Support REPL-defined functions in stacktrace infrastructure * source mapping for Rhino * CLJS-1071: support symbol keys in :closure-defines * CLJS-1014: Support Closure Defines under :none * CLJS-1068: node target define * CLJS-1069: Generic :jsdoc support * CLJS-1030: add `cljs.repl/pst` * add `cljs.repl/apropos`, `cljs.repl/find-doc`, `cljs.repl/dir` * fix `cljs.analyzer.api/all-ns` docstring * add `cljs.analyzer.api/ns-publics` * CLJS-1055: cljs.repl/doc should support namespaces and special forms * Add ClojureScript special form doc map * CLJS-1054: add clojure.repl/source functionality to cljs.repl * CLJS-1053: REPLs need import special fn ### Changes * move :init up in cljs.repl/repl * CLJS-1087: with-out-str unexpectedly affected by *print-newline* * CLJS-1093: Better compiler defaults * Bump deps latest Closure Compiler, Rhino 1.7R5, data.json 0.2.6, tool.reader 0.8.16 * more sensible error if cljs.repl/repl arguments after the first incorrectly supplied * default REPLs to :cache-analysis true * default :output-dir for Nashorn and Node REPLs * change ES6 Map `get` support to take additional `not-found` parameter * deprecate clojure.reflect namespace now that REPLs are significantly enhanced, static vars, etc. ### Fixes * stop blowing away cljs.user in browser REPL so REPL fns/macros remain available * CLJS-1098: Browser REPL needs to support :reload and :reload-all * CLJS-1097: source map url for AOTed cljs.core is wrong * CLJS-1094: read option not used by cljs.repl/repl* * CLJS-1089: AOT analysis cache has bad :file paths * CLJS-1057: Nashorn REPL should not use EDN rep for errors * CLJS-1086: Keyword constants should have stable names * CLJS-964: Redefining exists? does not emit a warning like redefining array? does. * CLJS-937: local fn name should be lexically munged * CLJS-1082: analysis memoization bug * CLJS-978: Analysis caching doesn't account for constants table * CLJS-865: remove `cljs.js-deps/goog-resource` hack * CLJS-1077: analyze-deps infinite recursive loop * manually set *e in Rhino on JS exception * REPL options merging needs to be more disciplined * CLJS-1072: Calling .hasOwnProperty(source) in Clojurescript's string/replace will break with ES6 * CLJS-1064: ex-info is not printable * Fix REPLs emitting code into .repl directory * CLJS-1066: Rhino REPL regression * be more disciplined about ints in murmur3 code * Node.js REPL should work even if :output-dir not supplied * Nashorn environment doesn't supply console, setup printing correctly -- 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
Re: ANN: ClojureScript 0.0-3058, Enhanced REPLs, faster compile times
Just wow! Thank you. On Tuesday, March 10, 2015 at 12:41:45 AM UTC+1, David Nolen wrote: ClojureScript, the Clojure compiler that emits JavaScript source code. README and source code: https://github.com/clojure/clojurescript New release version: 0.0-3058 Leiningen dependency information: [org.clojure/clojurescript 0.0-3058] This is a significant enhancement release around REPLs and compile times. All builtin REPLs (Nashorn, Node.js, Rhino and the browser REPL) now support the helper functions normally available via clojure.repl, these include: doc, find-doc, apropos, dir, source, and pst. All of the builtins REPL now also support source mapped stacktraces. This release also includes many enhancements around compile times. ClojureScript now ships with a default :optimizations setting of :none. Implicit now when using :none is source map generation and analysis caching. Analysis caching significantly speeds up compile times. The standard library (cljs.core) is now AOTed compiled to JavaScript along with an AOTed analysis dump and an AOTed source map. This dramatically cuts down on cold start compile times. The standard library is never actually ever analyzed or compiled in your own builds. The result is particularly dramatic for REPLs. ClojureScript is also now available for the first time as a standalone AOTed JAR. The Quick Start introduction has been rewritten in terms of the standalone JAR: https://github.com/clojure/clojurescript/wiki/Quick-Start The new Quick Start is essential reading even if you are a relatively experienced ClojureScript developer. As usual feedback welcome! ## 0.0-3058 ### Enhancements * browser REPL source mapping for Firefox, Safari, Chrome * macro support in REPL special functions * CLJS-897: AOT core.cljs CLJS-899: AOT cache core.cljs analysis * CLJS-1078: Nashorn REPL should use persistent code cache * CLJS-1079: add way to execute arbitrary fn upon watch build completion * CLJS-1034: Support REPL-defined functions in stacktrace infrastructure * source mapping for Rhino * CLJS-1071: support symbol keys in :closure-defines * CLJS-1014: Support Closure Defines under :none * CLJS-1068: node target define * CLJS-1069: Generic :jsdoc support * CLJS-1030: add `cljs.repl/pst` * add `cljs.repl/apropos`, `cljs.repl/find-doc`, `cljs.repl/dir` * fix `cljs.analyzer.api/all-ns` docstring * add `cljs.analyzer.api/ns-publics` * CLJS-1055: cljs.repl/doc should support namespaces and special forms * Add ClojureScript special form doc map * CLJS-1054: add clojure.repl/source functionality to cljs.repl * CLJS-1053: REPLs need import special fn ### Changes * move :init up in cljs.repl/repl * CLJS-1087: with-out-str unexpectedly affected by *print-newline* * CLJS-1093: Better compiler defaults * Bump deps latest Closure Compiler, Rhino 1.7R5, data.json 0.2.6, tool.reader 0.8.16 * more sensible error if cljs.repl/repl arguments after the first incorrectly supplied * default REPLs to :cache-analysis true * default :output-dir for Nashorn and Node REPLs * change ES6 Map `get` support to take additional `not-found` parameter * deprecate clojure.reflect namespace now that REPLs are significantly enhanced, static vars, etc. ### Fixes * stop blowing away cljs.user in browser REPL so REPL fns/macros remain available * CLJS-1098: Browser REPL needs to support :reload and :reload-all * CLJS-1097: source map url for AOTed cljs.core is wrong * CLJS-1094: read option not used by cljs.repl/repl* * CLJS-1089: AOT analysis cache has bad :file paths * CLJS-1057: Nashorn REPL should not use EDN rep for errors * CLJS-1086: Keyword constants should have stable names * CLJS-964: Redefining exists? does not emit a warning like redefining array? does. * CLJS-937: local fn name should be lexically munged * CLJS-1082: analysis memoization bug * CLJS-978: Analysis caching doesn't account for constants table * CLJS-865: remove `cljs.js-deps/goog-resource` hack * CLJS-1077: analyze-deps infinite recursive loop * manually set *e in Rhino on JS exception * REPL options merging needs to be more disciplined * CLJS-1072: Calling .hasOwnProperty(source) in Clojurescript's string/replace will break with ES6 * CLJS-1064: ex-info is not printable * Fix REPLs emitting code into .repl directory * CLJS-1066: Rhino REPL regression * be more disciplined about ints in murmur3 code * Node.js REPL should work even if :output-dir not supplied * Nashorn environment doesn't supply console, setup printing correctly -- 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
Re: Risk of unsafe publishing of LazyTransformer?
No worries then. Thanks!
2015-03-10 2:23 GMT+01:00 Alex Miller a...@puredanger.com:
Hi Sébastien,
Most publication in LazyTransformer is handled via the synchronized seq()
method. However, LazyTransformer is being replaced as part of
http://dev.clojure.org/jira/browse/CLJ-1669 so probably moot.
Alex
On Monday, March 9, 2015 at 5:40:11 PM UTC-5, Sébastien Bocq wrote:
Hello,
I noticed that LazyTransformer [1] implements mutable state without any
volatile or final modifier to guard its fields (it might not be an isolated
case in the core library e.g. SeqIterator.java).
Isn't such class subject to unsafe publication?
For example, considering only this part of the implementation:
public final class LazyTransformer extends ... {
IStepper stepper;
Object first = null;
LazyTransformer rest = null;
public LazyTransformer(IStepper stepper){
this.stepper = stepper;
}
public static LazyTransformer create(IFn xform, Object coll){
return new LazyTransformer(new Stepper(xform, RT.iter(coll)));
}
...
public Object first(){
if(stepper != null)
seq();
if(rest == null)
return null;
return first;
}
public ISeq next(){
if(stepper != null)
seq();
if(rest == null)
return null;
return rest.seq();
}
..
}
If LazyTransformer/create is called in in one thread and then another
thread calls 'first' or 'next' on the new object then I would say there's a
chance the second thread sees stepper == null. A real use case could be one
thread calling (dedup) [2], which creates lazy sequence with (sequence
http://crossclj.info/ns/org.clojure/clojure/1.7.0-alpha5/clojure.core.html#_sequence
(dedupe
http://crossclj.info/ns/org.clojure/clojure/1.7.0-alpha5/clojure.core.html#_dedupe)
coll), and then another thread iterates through the sequence, which I
suppose relies on 'first' and 'next'.
To me it looks like the exact same situation as the one discussed on the
Java concurrency-interest here:
http://jsr166-concurrency.10961.n7.nabble.com/Safe-
publishing-strategy-tt12126.html
I can't believe I'm the first to be worried by this so maybe I overlooked
something. But if I'm not wrong or if there is any doubt, next to
refactoring the code to use immutable classes with only final fields (my
preferred approach), wouldn't it be safer to declare at least 'stepper' as
volatile to prevent any of risk of nasty concurrency issue?
Thanks,
Sébastien
[1] https://github.com/clojure/clojure/blob/master/src/jvm/
clojure/lang/LazyTransformer.java
[2] http://crossclj.info/fun/clojure.core/dedupe.html
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to a topic in the
Google Groups Clojure group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/clojure/rJiR_Dz9hX8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Sébastien
--
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.
[GSoC Idea] Typed CLJS JavaScript Interop with Facebook Flow
Hi, TypeScript does not play well with Facebook React.js, but Facebook created Flow http://flowtype.org/which adds static typing to JavaScript to improve developer productivity and code quality. Cheers, Michal -- 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: [OT?] Best DB/architecture for n-gram corpus?
That's interesting. I've been really reluctant to hard code n-grams, but it's probably the best way to go. On Monday, March 9, 2015 at 6:12:43 PM UTC-4, John Wiseman wrote: One thing you can do is index 1, 2, 3...n-grams and use a simple fast key-value store (like leveldb etc.) e.g., you could have entries like aunt rhodie - song-9, song-44 woman - song-12, song-65, song-96 That's basically how I made the Metafilter N-gram Viewer http://mefingram.appspot.com/, a clone of Google Books Ngram Viewer https://books.google.com/ngrams. Another possibility is using Lucene. Just be aware that Lucene calls n-grams of characters (au, un, nt) n-grams but it calls n-grams of words (that the, the old, old gray) shingles. So you would end up using (I think, I haven't done this) the ShingleFilter https://lucene.apache.org/core/4_2_0/analyzers-common/org/apache/lucene/analysis/shingle/ShingleFilter.html . You might also find this article by Russ Cox interesting, where he describes building and using an inverted trigram index: http://swtch.com/~rsc/regexp/regexp4.html John Three things that you might find interesting: Russ Cox' explanation of doing indexing and retrieval with an inverted trigram index: http://swtch.com/~rsc/regexp/regexp4.html On Sat, Mar 7, 2015 at 3:22 AM, Matching Socks phill...@gmail.com javascript: wrote: A lot of guys would use Lucene. Lucene calls n-grams of words shingles. [1] As for architecture, here is a suggestion to use Lucene to find keys to records in your real database. [2] [1] https://lucidworks.com/blog/whats-a-shingle-in-lucene-parlance/ [2] https://groups.google.com/d/msg/datomic/8yrCYxcQq34/GIomGaarX5QJ -- 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.
Re: [GSoC] Mentors contact information
On Monday, March 9, 2015 at 2:25:56 PM UTC-5, Christopher Medrela wrote: Hello! My name is Christopher Medrela. I'm interested in participating in GSoC this year. I've looked at the ideas page and I think that I'd like to work at: * source metadata information model (mentored by Alex Miller) a...@puredanger.com * or one of typed clojure projects (mentored by Ambrose Bonnaire-Sergeant). Could you share with me contact information to these mentors? Best regards! -- 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: Risk of unsafe publishing of LazyTransformer?
Hi Sébastien,
Most publication in LazyTransformer is handled via the synchronized seq()
method. However, LazyTransformer is being replaced as part
of http://dev.clojure.org/jira/browse/CLJ-1669 so probably moot.
Alex
On Monday, March 9, 2015 at 5:40:11 PM UTC-5, Sébastien Bocq wrote:
Hello,
I noticed that LazyTransformer [1] implements mutable state without any
volatile or final modifier to guard its fields (it might not be an isolated
case in the core library e.g. SeqIterator.java).
Isn't such class subject to unsafe publication?
For example, considering only this part of the implementation:
public final class LazyTransformer extends ... {
IStepper stepper;
Object first = null;
LazyTransformer rest = null;
public LazyTransformer(IStepper stepper){
this.stepper = stepper;
}
public static LazyTransformer create(IFn xform, Object coll){
return new LazyTransformer(new Stepper(xform, RT.iter(coll)));
}
...
public Object first(){
if(stepper != null)
seq();
if(rest == null)
return null;
return first;
}
public ISeq next(){
if(stepper != null)
seq();
if(rest == null)
return null;
return rest.seq();
}
..
}
If LazyTransformer/create is called in in one thread and then another
thread calls 'first' or 'next' on the new object then I would say there's a
chance the second thread sees stepper == null. A real use case could be one
thread calling (dedup) [2], which creates lazy sequence with (sequence
http://crossclj.info/ns/org.clojure/clojure/1.7.0-alpha5/clojure.core.html#_sequence
(dedupe
http://crossclj.info/ns/org.clojure/clojure/1.7.0-alpha5/clojure.core.html#_dedupe)
coll), and then another thread iterates through the sequence, which I
suppose relies on 'first' and 'next'.
To me it looks like the exact same situation as the one discussed on the
Java concurrency-interest here:
http://jsr166-concurrency.10961.n7.nabble.com/Safe-publishing-strategy-tt12126.html
I can't believe I'm the first to be worried by this so maybe I overlooked
something. But if I'm not wrong or if there is any doubt, next to
refactoring the code to use immutable classes with only final fields (my
preferred approach), wouldn't it be safer to declare at least 'stepper' as
volatile to prevent any of risk of nasty concurrency issue?
Thanks,
Sébastien
[1]
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazyTransformer.java
[2] http://crossclj.info/fun/clojure.core/dedupe.html
--
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.
