Re: Dependency management

[Daniel]

acquire enough
knowledge about each tool to make an informed decision (the paradox of
choice). I cannot even imagine how much time has been wasted by
halfbaked (and partially or fully abandoned) projects.

If the miracle would happen and the different, rapidly growing
language communities on the JVM finally could commit themselves to
support and push a shared buildtool, then that tool would have enough
steam to grow into a decent alternative for Maven. It might even
become the preferred way of build at least non-Java projects, who
knows. If everybody is trying to get their own share of followers and
only solves what is immediately visible for the projects used by
themselves and their followers, then we will never get anywhere.

And please note that I'm not asking to start from scratch. Gradle is
there and has momentum already. I'm just hoping that I'm not the only
one that sees a benefit in joining forces with stuff that already
exists. If people in the Clojure community start to throw your weight
behind something that seems to be on the right track, can still be
influenced and made better.

To get started with Gradle, you would have to:
* write a DSL that can talk to Gradle Java API.
* write a ClojurePlugin (probably based on the JavaPlugin) for Gradle,
if you have specialized wishes (such as that src/main/clojure should
be the default convention for Clojure projects, or that you can
specify which version of Clojure should be used for compilation etc.).



Sorry for the long mail/rant, but it's been too painful too many
times. And a sincere apology to Phil, who just scratched an itch for
himself, and was interested in sharing it with the larger Clojure
community. This mail is not an attack on your work, or approach. It
just triggered something that I have stumbled over too many times and
I would love to see it finally resolved. I think that Gradle could be
used to give you all you envisioned for Corkscrew, but in the process,
you will gain so much more.

Disclaimer: I'm (currently) not actively developing Gradle itself, but
i was impressed with what's there and where it's going. I also took
the liberty to crosspost this mail to the Gradle dev list (CC'd) to
invite a broader participation.

I'm really hoping that we could find some consensus on the topic.

These are my probably 20$ or so...

Daniel
(probably by now unofficial Gradle Evangelist)

--~--~-~--~~~---~--~~
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: Save current namespace like a Smalltalk image

[Daniel]

sspath.html
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ClassLoader.html

So depending on your approach and what you want to be able to do
(redefine/reload or add), it's a bit of work. The easiest thing is to
unpack your dependencies, but for my taste it's pretty messy.

Cheers,
Daniel

(today seems to be the day of long posts. Sorry guys)

--~--~-~--~~~---~--~~
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: Clojure box - loading book examples from "Programming Clojure"

[Daniel]

On Thu, Jul 9, 2009 at 1:56 AM, Mani wrote:
>
> Thanks Shawn, Robert.
> From Robert's post, I am bit confused here. I also read that .emacs is
> in %appdata% folder (vista), but all I see is .emacs.d folder (which I
> guess is for the emacs server). I tried creating one "C-x C-f
> ~/.emacs" - under my home-directory (C:\emacs). Should i just create
> a .emacs under %appdata%/.emacs.d  OR right under %appdata%?
>

>From the EmacsWiki [1]: "If the init file ~/.emacs does not exist,
Emacs will try ~/.emacs.d/init.el"

Since you usually have more than a couple of things that you want to
configure, emacs.d gives you a directory instead of a file for
configuration. That makes it easier to keep things organized. If you
put what you want into %appdata%/.emacs.d/init.el, you should be fine.

I guess ClojureBox is a good starting point for Emacs with Clojure. A
little bit more general is the Emacs starter kit [2] from Phil
Hagelberg (Clojure regular), and if nothing else, reading the readme
(displayed on the linked page) is recommended because it gives you a
bit of intro on Emacs configuration (ClojureBox might even use the
starter kit, but according to this [3] it doesn't. Didn't check
though).

Hope that helps

Cheers,
Daniel

[1] http://www.emacswiki.org/emacs/DotEmacsDotD
[2] http://github.com/technomancy/emacs-starter-kit/tree/master
[3] http://groups.google.com/group/clojure/browse_thread/thread/6fd17fb97f058192

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

[Daniel]

On Mon, Jul 13, 2009 at 7:55 AM, Mark Volkmann wrote:
>
> On Sun, Jul 12, 2009 at 7:07 PM, Vagif Verdi wrote:
>>
>> Potentially interesting library for clojurians. Java STM
>> implementation: http://www.deucestm.org/
>
> As best I can tell, this is yet another "on your honor" STM
> implementation. What I mean is that as long as you use the library
> correctly in every place where it is needed, everything works fine.
> Forgot to use it somewhere in an application where it was needed and
> all bets are off. That's one thing I really like about Clojure. You
> can't get away with forgetting to update Refs inside a transaction. If
> you do, you'll be reminded with an exception.
>
> Is there another STM implementation that enforces its use like this?
>

Well, I'd say that's a property of the language, not the library. You
could use pretty much any STM library in Java if you can make sure
that the executed bytecode has the appropriate calls in place. Have a
look at Terracotta (http://terracotta.org/). It's not an STM in the
sense of intra-JVM transactions, but inter-JVM transactions (they call
it network attached memory), and it's implemented as a bytecode weaver
(meaning you either transform your compiled class files with an
additional step after compilation to add the library specific
instructions, or you do the same thing at loadtime when loading your
code through a special classloader). Terracotta's approach is also "on
your honor" in the sense that it doesn't force you to declare all
variables in TC terms, but the approach could be extended to throw
(compile time) exceptions on undeclared state variables.

By the way, I would take a good look at Terracotta if I ever wanted to
extend Clojures STM to work across JVMs. You probably would have to
think a bit harder about how you integrate the TC transactions with
the ones from Clojure, since TC transactions are remote calls and
therefore a lot slower, but I reckon it shouldn't be too hard. TC has
enough tools to inspect how your transactions perform.

HTH

Cheers,
Daniel

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

[Daniel]

On Mon, Jul 13, 2009 at 1:36 PM, Daniel wrote:
> On Mon, Jul 13, 2009 at 7:55 AM, Mark Volkmann 
> wrote:
>>
>> On Sun, Jul 12, 2009 at 7:07 PM, Vagif Verdi wrote:
>>>
>>> Potentially interesting library for clojurians. Java STM
>>> implementation: http://www.deucestm.org/
>>
>> As best I can tell, this is yet another "on your honor" STM
>> implementation. What I mean is that as long as you use the library
>> correctly in every place where it is needed, everything works fine.
>> Forgot to use it somewhere in an application where it was needed and
>> all bets are off. That's one thing I really like about Clojure. You
>> can't get away with forgetting to update Refs inside a transaction. If
>> you do, you'll be reminded with an exception.
>>
>> Is there another STM implementation that enforces its use like this?
>>
>
> Well, I'd say that's a property of the language, not the library. You
> could use pretty much any STM library in Java if you can make sure
> that the executed bytecode has the appropriate calls in place. Have a
> look at Terracotta (http://terracotta.org/). It's not an STM in the
> sense of intra-JVM transactions, but inter-JVM transactions (they call
> it network attached memory), and it's implemented as a bytecode weaver
> (meaning you either transform your compiled class files with an
> additional step after compilation to add the library specific
> instructions, or you do the same thing at loadtime when loading your
> code through a special classloader). Terracotta's approach is also "on
> your honor" in the sense that it doesn't force you to declare all
> variables in TC terms, but the approach could be extended to throw
> (compile time) exceptions on undeclared state variables.
>
> By the way, I would take a good look at Terracotta if I ever wanted to
> extend Clojures STM to work across JVMs. You probably would have to
> think a bit harder about how you integrate the TC transactions with
> the ones from Clojure, since TC transactions are remote calls and
> therefore a lot slower, but I reckon it shouldn't be too hard. TC has
> enough tools to inspect how your transactions perform.

Oh, and just to complete the picture for intra-JVM transactions on
shared state (clustering), besides Terracotta there's also Hazelcast
(http://www.hazelcast.com/), and to a lesser degree (different focus)
ZooKeeper (http://hadoop.apache.org/zookeeper/) and Shoal
(https://shoal.dev.java.net/). But you'll have to check what the
libraries are aimed at, since the implementations are designed for
certain usecases. And all of these are implemented and used as
traditional libraries as opposed to Terracotta.

--~--~-~--~~~---~--~~
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: openlg

[Daniel]

On Tue, Jul 14, 2009 at 1:09 AM, Emeka wrote:
> Hello All, ztellman,
>
> I would like to use  git://github.com/ztellman/penumbra.git , however I
> won't mind knowing the owner, too.

If you create an account on github.com you can send him a message directly.

Cheers,
Daniel

--~--~-~--~~~---~--~~
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: classloaders, modularity, packaging

[Daniel]

the discussion. I know at least the state of the JVM regarding the
mentioned technologies reasonably well, so if you have more concrete
questions, just shout.

Hope that the above helps in some way for your talk...

Cheers,
Daniel

[1] 
http://groups.google.com/group/clojure/browse_thread/thread/6198db7d82610293/4735838f330df3d6?hl=en&q=#4735838f330df3d6
[2] 
http://groups.google.com/group/clojure/browse_thread/thread/417ba3d62f5137e4/70a25aa89e1ddfda?hl=en&q=#45a6c00c47483046
[3] 
http://groups.google.com/group/clojure/browse_thread/thread/46a3f30fb3d2807b/895b02b26241305e?hl=en&q=#895b02b26241305e
[4] http://java.sun.com/developer/technicalArticles/J2SE/jvm_ti/

--~--~-~--~~~---~--~~
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: easiest JMX API ever, in Clojure...

[Daniel]

On Wed, Jul 15, 2009 at 3:43 AM, Michael Wood wrote:
>
> 2009/7/14 Stuart Halloway :
>>
>> ...wants your   help to be born! :-)
>>
>> There is a branch in clojure-contrib that includes work so far: 
>> http://github.com/richhickey/clojure-contrib/tree/jmx
>> . I want feedback on ease of use, most important features to add next,
>> code quality, you name it.
>>
>> Here's a teaser:
>
> I like it :)
>
> It doesn't seem to work with Clojure 1.0:
>
> user=> (require '[clojure.contrib.jmx :as jmx])
> java.io.FileNotFoundException: Could not locate
> clojure/stacktrace__init.class or clojure/stacktrace.clj on classpath:
>  (jmx.clj:0)
>
> But seems to work fine in the latest snapshot (at least for the local stuff).
>
> I've never tried this sort of thing before, but I'm trying to connect
> to a JBoss instance with it and not having much luck.  I think I need
> to authenticate somehow, but I have no idea how to do that.  Normally
> you look at these settings through a web interface, so I'm not quite
> sure what's necessary to bypass the web interface.
>

The usual way you can interact with JMX (if there's not dedicated
webconsole running) is either via JConsole (part of the JDK since
1.4.2 IIRC), or VisualVM (part of the Sun and derived (incl. OS X) JDK
since 1.6). jconsole is usually on the PATH, so you should be able to
launch it with 'jconsole' using whatever JDK is configured on the
PATH. I VisualVM is a bit more featureful and flexible and you should
be able to invoke it with 'jvisualvm' on the console, or from wherever
you downloaded a newer version to [1].

If you can connect with either of these tools, then it should be
possible to connect programmatically as well. Beware though that both
these tools have the possibility to connect to applications running on
the same machine through a special domain socket only available in
internal Sun classes (to be able to connect via JMX even if the
original process didn't enable JMX). To enable JMX the 'official' way,
follow the instructions at [2] (or [3] for the JBoss specific
incarnation of if).

Hope that helps

Cheers,
Daniel

[1] https://visualvm.dev.java.net/
[2] http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html
[3] http://www.jboss.org/community/wiki/UseJDK5JConsole

--~--~-~--~~~---~--~~
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: NoClassDef Issue, possibly my fault with the classloaders

[Daniel]

Resurrection
Is this still a problem? If yes, I recommend to look into using an
OSGi framework for your classloading. Classloaders are non-trivial and
it's very easy to trip, to introduce subtle bugs, or fragile things
that break later. Using an established technology for dealing with the
problem is IMHO preferred. And mind you that you don't have to do all
that much to make it work. OSGi is based on Manifest.MF metadata, but
you can use PAX Construct use existing jars that don't have proper
metadata as dependencies in OSGi. In that way you can have the
benefits of OSGi without too much effort to get you started (you can
create the proper versions later).  Have a look at all the PAX
Utilities [1], as they can make your life so much easier.

[1] http://wiki.ops4j.org/display/ops4j/Pax

Cheers,
Daniel

On Wed, Jul 1, 2009 at 5:11 AM, BerlinBrown wrote:
>
> Pre Notes: I put most of the code for my unit testing here:
>
> http://groups.google.com/group/clojure/web/MostCodeIssue.java
> http://groups.google.com/group/clojure/web/NoClassDefIssue.zip
> http://clojure.googlegroups.com/web/MostCodeIssue.java?gsc=XGm71ws6-FUP8n2vUln2lQc9yyLJ
>
> 
>
> This is the strange no classdef not found error. Here is the scenario
> which is a little different by 90% of my code works. Please ignore
> that I am using Clojure, I have also done this with regular java code
> and still get the same error.
>
> Ideally, I was hoping for some help on custom classloader. My initial
> thought was that I could create the classloader, add the filepath/url
> of the jars to the classloader and I could launch my code. But
> apparently there is some strangeness going on.
>
>   1.   I have ONE jar file that dynamically loads 4-5 auxillary jar
> files. It is built on a simple URLClassLoader. I want to do this
> because I can have a user click on one jar file and launch the
> application. So there is one item that the user has to worry about.
>   2. By clicking on this jar file, the application loads jar files
> from the filesystem. E.g. the application loads swt.jar (Eclipse's
> widget toolkit) and some other jars.
>
> 3 (but don't worry about it), my application is built on Clojure (the
> dynamic programming language), the first application to launch is this
> Clojure script. Most of my application is within the clojure script.
> 4. Everything up to 1-3 works fine. The application loads and clojure
> script runs, the SWT GUI application runs, etc.
>
>   1. Here is the part that doesn't work.
>   2. I have an existing java library, call it my-swt-gui.jar. That is
> also a swt application. It is basically another gui application is
> already built. I am trying to load the window from my current clojure/
> swt application. For some reason, the JAVA oriented library won't
> recognize SWT and I get noclassdef errors.
>
> Here is the strangeness. And I will identify where I think there might
> be oddities.
>
> Entitis: A. The java oriented classloader. In the java classloader, I
> launch the clojure application. SWT and other jar files are loaded
> with this classloader. B. The Clojure oriented code that gets invoked
> by section entity a. The clojure code is a swt based GUI application.
> B works fine. C. Java code that contains another GUI window. For some
> reason, this library wont load and I am getting the error, noclassdef.
>
> NOTE: I KNOW FOR A FACT THAT the SWT class is actually in the
> classpath or I would get a NoClassFound exception. I am not getting
> that exception. Something else is going on.
>
> Note: could it also be an issue with the fact that SWT includes win32
> dlls? Maybe accessing the win32 dll jar the first time works but with
> the java code it doesn't work? But that is strange. Why would SWT work
> and then not work?
> I can't show you all the code, I hope I can show you the relevant
> pieces.
>
> Here is the main classloader code:
>
>  public static final String [] JAVA_LIBRARIES = {
>        "lib\\log4j-1.2.15.jar",
>        "lib\\octane_commons.jar",
>        "lib\\clojure.jar",
>        "lib\\swt\\win32\\swt.jar",
>        "lib\\jfreechart\\jcommon-1.0.15.jar",
>        "lib\\jfreechart\\jfreechart-1.0.12.jar",
>        "lib\\jfreechart\\jfreechart-1.0.12-swt.jar",
>        "lib\\pdf\\minium.jar",
>        "lib\\pdf\\tagsoup-1.2.jar",
>        "lib\\pdf\\core-renderer.jar",
>        "lib",
>        "conf",
>        "src"
>    };
>
> My classloader code is based on jetty's classloader and it works OK
> but I keep get ting classnotdef errors.  Strange ones.  I can see a
> clear distinction

Re: Examining performance on the JVM

[Daniel]

On Thu, Jul 16, 2009 at 11:00 AM, Glen Stampoultzis wrote:
> Apparently it's possible to see the assembly instructions if you're running
> a debug VM [1].
>
> -XX:+PrintOptoAssembly dumps to the console a log of all assembly being
> generated for JITed methods. The instructions are basically x86 assembly
> with a few Hotspot-specific instruction names that get replaced with
> hardware-specific instructions during the final assembly phase. In addition
> to the JITed assembly, this flag also shows how registers are being
> allocated, the probability of various branches being followed (along with
> multiple assembly blocks for the different paths), and information about
> calls back into the JVM.
>
> [1] http://blog.headius.com/2009/01/my-favorite-hotspot-jvm-flags.html
>

I don't have any concrete links right now but be sure to check the
slides (and videos) to JavaOne presentation of at least the last 3
years. Most of the time some of topics are presented at JavaOne in
specialized talks by engineers from CPU manufacturers. Not a lot of
Java developers would usually have the knowledge to go that deep down
to the metal, but it's very interesting to have someone from AMD or
Intel show you how to look at the JVM at that level. I remember that
there was an AMD talk one year where they showed an AMD (& Win) tool
to look into the CPU caches and registers, and how they used it to
pinpoint a synchronization problem that you wouldn't be able to find
with JVM level tools. Don't know about a specific talk, but Intel has
similar tools.

Also usually a great source of information are talks from Cliff Click
and other Azul people. Since they take the JVM-hardware combo to a
whole new level, they also have a lot of info on that layer.

Cheers,
Daniel

--~--~-~--~~~---~--~~
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: easiest JMX API ever, in Clojure...

[Daniel]

On Thu, Jul 16, 2009 at 3:18 AM, Michael Wood wrote:
>
> 2009/7/15 Daniel :
>>
>> On Wed, Jul 15, 2009 at 3:43 AM, Michael Wood wrote:
> [...]
>>> I've never tried this sort of thing before, but I'm trying to connect
>>> to a JBoss instance with it and not having much luck.  I think I need
>>> to authenticate somehow, but I have no idea how to do that.  Normally
>>> you look at these settings through a web interface, so I'm not quite
>>> sure what's necessary to bypass the web interface.
>>
>> The usual way you can interact with JMX (if there's not dedicated
>> webconsole running) is either via JConsole (part of the JDK since
>> 1.4.2 IIRC), or VisualVM (part of the Sun and derived (incl. OS X) JDK
>> since 1.6). jconsole is usually on the PATH, so you should be able to
>> launch it with 'jconsole' using whatever JDK is configured on the
>> PATH. I VisualVM is a bit more featureful and flexible and you should
>> be able to invoke it with 'jvisualvm' on the console, or from wherever
>> you downloaded a newer version to [1].
>>
>> If you can connect with either of these tools, then it should be
>> possible to connect programmatically as well. Beware though that both
>> these tools have the possibility to connect to applications running on
>> the same machine through a special domain socket only available in
>> internal Sun classes (to be able to connect via JMX even if the
>> original process didn't enable JMX). To enable JMX the 'official' way,
>> follow the instructions at [2] (or [3] for the JBoss specific
>> incarnation of if).
>>
>> Hope that helps
>
> Yes, thanks.  I am able to connect now.  I was assuming that the
> jmx-console web interface communicated via JMX and therefore that I
> should be able to connect without having to do anything else.
>
> By the way, how does twiddle.sh (which appears to be a command line
> tool for fiddling with JMX stuff in JBoss) work then?  Because it
> works without having to use the
> -Dcom.sun.management.jmxremote.port=12345,
> -Djboss.platform.mbeanserver and
> -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl
> options.
>

A remote process (process not running on the same machine as JMX
client) can usually be accessed through an RMI connection. The used
RMI connector and object server to serve the JMX connection can be the
trivial (and problematic) implementation from Sun (enabled with
-Dcom.sun.management.jmxremote) or it can be a better version by the
vendor usually automatically started on port 1099 (I guess that this
is what JBoss does, but check to be sure). Note on why problematic:
Suns implementation only allows you to specify the connector port, but
not the object server port, which is dynamic and therefore doesn't
play nice with firewalls.

If it's on the same machine, then it's the internal domain socket
mentioned above (same mechanism that's used to figure out what 'jps'
returns.

More info on Twiddle at JBoss
http://www.jboss.org/community/wiki/Twiddle (see: Connecting twiddle
to a Remote Server - default behaviour).

Cheers,
Daniel

--~--~-~--~~~---~--~~
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: Clojure vectors

[Daniel]

On Thu, Jul 16, 2009 at 1:52 AM, John Harrop wrote:
> On Wed, Jul 15, 2009 at 12:58 PM, Mark Engelberg 
> wrote:
>>
>> It looks like stack-rot is going to be the bottleneck in your app
>> since it requires traversing the whole vector to build the new one,
>> but I think the list-based implementation would be a bit worse, so I
>> think your choice to use vectors here is sound.
>>
>> For stack-dropn and stack-rot to both be fast, I think that you really
>> want to use a deque.  Unfortunately, Clojure doesn't have a built-in
>> deque, and I don't see one in contrib, but you could look at
>> clojure.lang.PersistentQueue and read Okasaki's Functional Data
>> Structures to draw some inspiration.
>
> What's needed here is a ring buffer. It shouldn't be hard to implement one
> atop a pair of a clojure vec, a true-count, and a start-offset. Rotation is
> then very cheap: replace v with (assoc v (- (+ start-offset true-count)
> (count v)) (get v start-offset)) and start-offset with (let [s-o (inc
> start-offset)] (if (= (count v) s-o) 0 s-o)). Dropn is similarly: true-count
> becomes (- n true-count) and start-offset (mod (+ start-offset n) (count
> v)). Indexing is cheap: (get v (mod (+ start-offset (mod index true-count))
> (count v))) and peek is even cheaper: (get v start-offset). (Maybe add code
> to handle empty, that is, (= 0 true-count)). The tricky thing is push. If (=
> true-count (count v)) the vector needs to be copied to a larger vector. You
> might want to double the size, leaving the unused elements nil: v becomes
> (vec (concat (drop start-offset v) (take start-offset
> v) [new-element] (repeat true-count nil))), true-count is inc'd as normal
> for a push, and start-offset reset to zero. Doubling the size whenever the
> vector must grow causes the cost of copying the vector to be asymptotically
> constant per push, instead of linear in the average size of the vector at
> the time of a push.
> (Ironically, the vector probably has this behavior under the hood, like
> java.util.ArrayList, but we need it again because  (vec (concat (drop
> start-offset v) (take start-offset v) [new-element] (repeat true-count
> nil))) has linear time-complexity in vector length.)
> You'd actually want to use a structmap for the above if you want to have
> multiple ring buffers, with struct keys :count, :offset, and :vector or
> similarly. Depending on the application, you might want to make the values
> for these keys be refs and have the ring buffer operations use dosync,
> though you could instead use a single ref per instance of the structmap.
>

FWIW since Java 1.6 there's a java.util.Deque (implemented as
RingBuffer) interface with java.util.ArrayDeque implementation, and a
java.util.concurrent.BlockingDeque interface with
java.util.concurrent.LinkedBlockingDeque implementation.

With the Deque interface, you can rotate both directions pretty easily
and the rest of the stack like methods are pretty straightforward:

(import '(java.util ArrayDeque))

(let [deque (ArrayDeque. '(1 2 3 4))]
(println deque)
; rot forward
(.addLast deque (.removeFirst deque))
(println deque)
; rot backward
(.addFirst deque (.removeLast deque))
(println deque))

But then again, it's a Java collection and not a Clojure one.

Cheers,
Daniel

--~--~-~--~~~---~--~~
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: easiest JMX API ever, in Clojure...

[Daniel]

On Thu, Jul 16, 2009 at 10:20 PM, Michael Wood wrote:
>
> 2009/7/16 Daniel :
>>
>> On Thu, Jul 16, 2009 at 3:18 AM, Michael Wood wrote:
> [...]
>>> By the way, how does twiddle.sh (which appears to be a command line
>>> tool for fiddling with JMX stuff in JBoss) work then?  Because it
>>> works without having to use the
>>> -Dcom.sun.management.jmxremote.port=12345,
>>> -Djboss.platform.mbeanserver and
>>> -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl
>>> options.
>>
>> A remote process (process not running on the same machine as JMX
>> client) can usually be accessed through an RMI connection. The used
>> RMI connector and object server to serve the JMX connection can be the
>> trivial (and problematic) implementation from Sun (enabled with
>> -Dcom.sun.management.jmxremote) or it can be a better version by the
>> vendor usually automatically started on port 1099 (I guess that this
>> is what JBoss does, but check to be sure). Note on why problematic:
>
> Yes, I think this is what JBoss does.
>
>> Suns implementation only allows you to specify the connector port, but
>> not the object server port, which is dynamic and therefore doesn't
>> play nice with firewalls.
>
> Ah.  Useful to know.  Thanks.
>
>> If it's on the same machine, then it's the internal domain socket
>> mentioned above (same mechanism that's used to figure out what 'jps'
>> returns.
>>
>> More info on Twiddle at JBoss
>> http://www.jboss.org/community/wiki/Twiddle (see: Connecting twiddle
>> to a Remote Server - default behaviour).
>
> Thanks, I have seen that page already.
>
> What I am wondering now is whether it's possible to use JBoss' RMI
> connector/object server (on port 1099) with Stuart's JMX library.  If
> I just try pointing it at port 1099 I get:
>
> java.io.IOException: Failed to retrieve RMIServer stub:
> javax.naming.CommunicationException [Root exception is
> java.rmi.ConnectIOException: non-JRMP server at remote endpoint]
> (NO_SOURCE_FILE:0)
>

Please try first to connect with JConsole. If you can get it to work
with JConsole, you'll also be able to use Stuart lib. If you don't get
it to work, you'll find more relevant material, because you won't be
the first person that tried that combination and it'll show up in
Google given the proper keywords.

--~--~-~--~~~---~--~~
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: easiest JMX API ever, in Clojure...

[Daniel]

On Fri, Jul 17, 2009 at 7:59 PM, Michael Wood wrote:
>
> 2009/7/16 Daniel :
>>
>> On Thu, Jul 16, 2009 at 10:20 PM, Michael Wood wrote:
> [...]
>>> What I am wondering now is whether it's possible to use JBoss' RMI
>>> connector/object server (on port 1099) with Stuart's JMX library.  If
>>> I just try pointing it at port 1099 I get:
>>>
>>> java.io.IOException: Failed to retrieve RMIServer stub:
>>> javax.naming.CommunicationException [Root exception is
>>> java.rmi.ConnectIOException: non-JRMP server at remote endpoint]
>>> (NO_SOURCE_FILE:0)
>>
>> Please try first to connect with JConsole. If you can get it to work
>> with JConsole, you'll also be able to use Stuart lib. If you don't get
>> it to work, you'll find more relevant material, because you won't be
>> the first person that tried that combination and it'll show up in
>> Google given the proper keywords.
>
> :)
>
> Of course.  Thanks for your patience.
>

Ah, don't worry. It's just that some things are awfully difficult to
diagnose If there's not enough context. But actually seems that for
this specific problem, Google has at least some clues to the solution
[1][2][3].

HTH

[1] http://forums.sun.com/thread.jspa?threadID=5298128 (only posts 1 & 2)
[2] http://www.jboss.org/community/wiki/JBossMBeansInJConsole (not
sure if this helps)
[3] http://www.jboss.org/community/wiki/JMXRemotingserviceconfiguration

--~--~-~--~~~---~--~~
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: Clojure as a CGI language?

[Daniel]

On Tue, Jul 21, 2009 at 10:14 AM, rob wrote:
>
> It sounds like you want to avoid the approach of Apache Tomcat and
> Clojure servelets (why not do it that way by the way?)  CGI allows you
> to operate any program via the web, but it will be alot slower if you
> have load everything every time a request is received by the server.
> My guess is that it will be prohibitively clunky.  I saw a good
> article on using emacs lisp via CGI, which if that is what you want to
> do, makes sense as the way to do it since there is no other more
> integrated way (in contrast with Java which is used for server-side
> web application development all the time).  You could use that article
> to learn about CGI, but there's really not much to it.
>
> There may be some way of keeping Clojure running and thereby avoiding
> that overhead.  This would be similar to if there were a "mod_clojure"
> for Apache, except mod_clojure (or mod_java-- which really does exist)
> should allow you greater access and control at the various stages of
> the request and serving of content.  I have not tried using servelets,
> so I'm not certain what the advantages/ disadvantages are.  Mod_java
> is less developed and has had less people working on it and using it
> than Tomcat/ servelets, but I don't know much about either really, and
> have no personal experiences with either of these approaches.
>

I mostly agree with the above, just to extend it a bit: PHP is an
interpreter which means a new process is fired up on every request.
Java is abysmally slow if you try to use it in the same way since you
have to instantiate the whole VM everytime (besides the fact that you
have to serialize all state incl. caches to disk to survive a
request). What you need is a resident JVM process to answer your
requests. If you're using Apache in front to handle the requests you
can use more than one strategy, there should be enough tutorials
around to help you with that (start at
http://tomcat.apache.org/connectors-doc/webserver_howto/apache.html to
get an idea).

This is quite a bit different from PHP, but also Rails etc. usually
have a resident process that you're talking to (FastCGI etc.). It
makes some other things in the end a lot easier. If you try to just
have something small up and running without a lot of hassle, try to
make it on Google App Engine. There you have a (restricted) managed
JVM and you just have to supply a servlet (standard API for writing
HTTP handler in Java land). Otherwise, there are a few companies that
have JVM hosting in Virtual machines on offer (e.g. Kattare:
http://www.kattare.com/).

Rant: I also find it annoying and unnecessarily complex to have JVM
based webapplications running online. Not many managed JVM
environments are available in comparison to PHP, Python, Perl, Ruby,
et al. The reason is that until now it's still not really possible to
reliably partition applications (code, resources consumption, kill of
only one applicaton) within a single JVM, that means, JVM don't really
mix with shared hosting plans (the solutions are so called MVMs with
true separation of resources inside a JVM). Until these MVMs arrive,
you really need are Hypervisor based solutions, Xen etc. to constrain
ressource usage. I hope that someone is going to tackle that problem
soon, there's a pile of cash waiting to be made if you can pull it off
for the masses.

Hope that helps.

Cheers,
Daniel

--~--~-~--~~~---~--~~
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: sizeof in Clojure

[Daniel]

On Tue, Jul 21, 2009 at 9:07 PM, Stuart
Sierra wrote:
>
> Hi Jan,
>
> Short answer: no, because Java has no sizeof operator.
>
> You can use Java profiling tools to examine the memory usage of your
> app if needed.
>

I would recommend heading down the path that Stuart suggested. But
interestingly, there actually exists a 'solution' that doesn't rely on
a Profiler. The approach is described in a JavaWorld article
(http://www.javaworld.com/javaworld/javaqa/2003-12/02-qa-1226-sizeof.html).
Keep in mind that it's 6 years old, and that it's written for Java,
and that the data structures for Clojure might have intricacies in
them, but with all that in mind, there are some gems in there if
you're set to have a sizeof operator in Clojure.

Have fun.

Daniel

--~--~-~--~~~---~--~~
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: Is it possible to swap in a new classloader?

[Daniel]

2009/7/31 Garth Sheldon-Coulson :
> Dear Clojurians,
>
> Is it possible to dynamically swap in a new classloader or give Clojure's 
> classloader a new parent classloader?
>
> I'm embedding Clojure in a parent app, and the parent app has its own 
> classloader that keeps track of its own classpath. It gives my embedded 
> Clojure a pretty meager classpath such that I can't import anything without 
> add-classpath'ing first.
>
> One option is to shuttle the parent classpath over to Clojure iteratively 
> using add-classpath. It would be better and more elegant, though, if I could 
> just link into the parent classloader directly.

Not exactly sure what you're referring to, or what exactly the layout
of your classloaders are, but classloaders are _in general_
hierarchical, with the parent having precedence. Meaning that if it's
on the parents classpath, then the parent classloader will load an
provide the class (that scheme is part of the security architecture
around the JVM to prevent unwanted code injection/manipulation).

If you're running in a container (appserver/servlet container/osgi
container/etc.), which is doing classloading tricks, then the answer
is going to be dependent on which container it is and how your app
fits in.

Cheers,
Daniel

--~--~-~--~~~---~--~~
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: Package manager proposal

[Daniel]

On Thu, Aug 6, 2009 at 4:12 PM, Lauri Pesonen wrote:
> 2009/8/5 Meikel Brandmeyer :
>> Well, this is independent of whether you have a C or Java
>> library. You can install each C library in its own directory
>> and tell the linker to look there. Then you have basically
>> a .jar like setup: If you don't tell the linker the right directory
>> the library "is not there". Similar you can declare "/usr/java/lib"
>> as your global directory and unzip each and every jar there.
>> Then configure your java launcher to add that directory to
>> the classpath and you have a setup, like the usual one
>> for C libraries. So this could even be system policy.
>
> What I was trying to say is that in the native lib world there are
> standard locations that the linker has been configured to look at and
> as a result the user does not have to do anything. That's not the case
> in the Java world, where the user has to always set the classpath to
> point to libs that the app uses.
>
> My point is that life is easier for languages that use native
> libraries as extensions rather than Java, because things just work.
> Placing all my jar files in /usr/java/lib only solves the problem for
> me if I tell the JVM to look there, plus the JVM will not resolve jars
> unless I name each jar separately on the classpath, and finally
> putting all my jars in one directory will not help the users of my
> package since it's not a universal convention.
>
> In the Ruby world, Gems expect their native dependencies to be
> installed on the platform at Gem install time. The Gem install will
> fail if the native library is missing. It is up to the user to install
> the dependency before trying to install the Gem. The user is free to
> install the dependency in which ever manner he chooses: a source
> install, a binary install, install via another package manager (e.g.
> apt-get or MacPorts) etc.

Yes, but the global approach is extremly unflexible. While I can see
that you probably never want to have two different versions of yor X11
libraries on the system, if you happen to want them, it's probably
going to be a major hassle to manage (unless you use a VM for it).

Scenario:
You have an application as v1.0 in production and it uses a library X
in v2.1 (or whatever). Now you're developing developing the next
version of your application (v2.0) and you're upgrading library X (to
v3.0) in your system since you want the new functionality. The new X
v3.0 is not backwards compatible. You find a critical bug in the
production version v1.0 while you're happily developing for v2.0 of
your app. With your version control system, checking out a parallel
install for the production version (v1.0) is easy. With the proposed
package manager / dependency system, can you have both versions of
said application on your system and launch them without
reconfiguration? If you have the classpath setup as a project local
dependency file, then you can do this (this is what
maven/ivy/virtualenv(python)/zc.buildout(python)/etc. gives you). If
you have a global static dependency resolution (path or whatever),
then it's going to be diffcult.

Whatever approach is chosen (rewrite/wrap/use existing), IMHO this
scenario has to be supported by the final system.


>> All these setups can be done (more or less comfortable)
>> with today existing solutions for Java. Instead of re-inventing
>> those, it would be more useful to abstract away their specifics.
>> Create a meta-package manager which creates JVM, CLR
>> and whatever packages sitting on the existing infrastructure
>> for the respective platform.

Have a look at Buckminster: http://www.eclipse.org/buckminster/
Not sure if it's going to work for non-JVM approaches (you'll probably
have to code up a plugin of some sort), but it's a meta package
manager, and can do more than just dependency resolution. For
instance, you can specify, if you would like to have a dependency as a
published Jar, or if you would like it to be checked from the version
control system, so that you can fix bugs in the dependency.
Note that this is the most under-documented project I have found in a
long time. It's powerful, but unless you use the Eclipse IDE, it's not
easy to have it do your bidding. So it might or might not be of
interest for our problem.


I personally think that the JVM ecosystem became more important
because of the dependency configuration approach, since although it's
painful to manage if you don't have tools, it's powerful for mixing
and matching dependencies in multiple projects on the same machine.
This gives you the possibility to try out without jeopardizing your
existing project configurations.

Just my two cents,
Daniel

--~--~-~--~~~---

Re: Package manager proposal

[Daniel]

On Thu, Aug 6, 2009 at 7:07 PM, Antony Blakey wrote:
> This is the first I've heard of this project, but what about the 255
> page user guide available from: 
> http://mirror.cc.vt.edu/pub/eclipse/tools/buckminster/doc/BuckyBook.pdf
>  ?

Ah, nice one. Hasn't been there last time I checked, thanks for the pointer.

Cheers,
Daniel

--~--~-~--~~~---~--~~
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: Package manager proposal

[Daniel]

On Fri, Aug 7, 2009 at 11:07 AM, Howard Lewis Ship wrote:
>
> Or really work this into core and add :packages to the (ns) macro.

+1

I have been thinking about this recently anyway. Java is too rigid to
work something like this into it's syntax, but Clojure could do it.
The benefits that I see coming from this would be that you actually
could declare OSGi style dependencies in the code. OSGi declares
dependencies not on JARs, but on packages (which are then resolved and
imported), and uses an optional range notation (in addition to a fixed
version). So you could declare something like

(ns example
  (:use clojure.contrib.json.read (1.5 == x))
  (:use compojure.html (1.5 <= x < 2.0)))

For the version 'function' a macro is probably needed, because I don't
know if the OSGi API can resolve versions with a function, it might
need some range datastructure, or even an equivalent string
"[1.5,2.0)".

This approach has the benefit that the code itself expresses, with
which versions it's supposed to run (against which versions it was
tested.

Another benefit is that OSGi tools can actually be used as a resolver
(a la ivy/maven), and they can resolve against OSGi repos, or Maven
repos. Check "Cooking with Maven and OSGi"
http://www.sonatype.com/books/mcookbook/reference/osgi.html

The obvious drawback is that you don't know all future versions which
it actually might run against. For that to work, there would still
have to be a plug into the resolver, so it's possible to override
dependencies (maybe in the first file that's loaded for the
application you can tell the resolver that he should try to coalesce
dependencies if possible, but that for namespace x.y which imports z
in version 1.2, the version is actually 2.0 (and this isn't specified
in the original code).

Whatever module versioning proposal you take that is on the Java
Platform, it needs some kind of annotation for the dependencies. In
this way, the annotation could be where it's actually necessary (in
the code), and not again outside the code, difficult to keep in sync.

And keep in mind that this proposal doesn't mean that you have to run
inside an OSGi container, or even use OSGi tools for dependency
resolution. It just means that it's very compatible if you want to use
OSGi, but you can still have the clojure core resolver use Corkscrew,
Clod, or whatever we want (it would make sense to keep it plugable
though).

I would be interested to hear what people think about something along
those lines. Whether you can see some benefits coming from this, or if
you think that this presents too much of a hassle (I think it can be
simplified to just have a single fixed version in the import
statement, so you have a simpler version and it doesn't change so much
from the status quo).

Cheers,
Daniel

--~--~-~--~~~---~--~~
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: Current API doc (for HEAD)

[Daniel]

On Fri, Aug 7, 2009 at 1:41 PM, Tom Faulhaber wrote:
>
>> Tom, are you amenable?
>
> Yup, happy to. Where should it go?
>
> I'm generating real html now, not wiki-text (for a bunch of reasons,
> among them the ability to download a tree and use your browser
> offline, old version support, etc.), so the current system wouldn't
> post back to clojure.org very efficiently. But I could throw something
> onto the github pages for clojure, for instance.
>

IIRC you can use plain HTML on the github pages. They are only
processed by Jekyll, if you have the YAML front-matter in the file
(http://wiki.github.com/mojombo/jekyll/usage see index.html section).

And I personally like to have offline docs. I figure that this is a
side effect of not ever-present internet connections. Your work style
actually changes quite drastic if you know that you'll be offline if
it happens to be a rainy day ;) DVCS, local VMs (as opposed to remote
servers for testing), offline docs etc. become all of a sudden
extremely attractive.

Cheers,
Daniel

--~--~-~--~~~---~--~~
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: Can Clojure be as fast as Java?

[Daniel]

On Wed, Aug 12, 2009 at 6:02 AM, Luc
Prefontaine wrote:
>
> If your algorithm is single threaded and performance is a must then even
> Java should be tossed away.
> Any native machine code equivalent would be faster than Java...

Pay attention when making assumptions:
http://stackoverflow.com/questions/145110/c-performance-vs-java-c

(I agree with the rest of what you said, though)

Cheers,
Daniel

--~--~-~--~~~---~--~~
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: Can Clojure be as fast as Java?

[Daniel]

On Wed, Aug 12, 2009 at 8:02 AM, Luc
Prefontaine wrote:
> C++ has nothing to do with my previous statement. C++ is object oriented.
> It's plagued with similar
> problems than Java in terms of performance.
>
> I was talking about writing the machine code by hand, not relying on a
> compiler's optimizer to do so.
>
> C is a bit better than C++ but if you use a cross platform compiler (like
> GNU) and you end up
> on a platform for which not all the optimizations have been tweaked into the
> compiler you are lost...
> If you write in C and are concerned by performance, you should at least look
> at the machine code
> generated by the compiler to make sure that it does the job correctly.
>
> Writing machine code directly, you can tune your code for your specific
> needs taking into account the available hardware optimizations
> even on RISC type architectures, you need to read the hardware specs
>
> Of course this alternative is non-portable but it will be faster than Java
> or C#

I assume that you have more knowledge about coding at that level,
since I personally only brushed it, so take it with a grain of salt.
The reference to C++ in the linked question is a bit unfortunate, but
let's have a look at these two about the Colt library:

http://forums.sun.com/thread.jspa?threadID=241797&tstart=120945 (last
comment, and notice the date)
http://acs.lbl.gov/~hoschek/colt/ (same library, different performance
quote, see again the date)

Colt targets a historically performance sensitive area (large scale
number crunching), and Java did exceedingly well compared to the
traditional tools (hand tuned Assembler and optimized Fortran). At the
time the articles were written (8 and 4 years ago), Java didn't do
better than the traditional tools, but came close. And that was 4.5 or
more JVM (incl. JIT) generations ago (1.4.2, 1.5, 1.6, 1.6u10 (1.7 is
the half)).

> If your algorithm is single threaded and performance is a must then even Java 
> should be tossed away.
> Any native machine code equivalent would be faster than Java...

I think your first statement shouldn't have been phrased like an
invariant. The condition is not precise enough to come to the given
conclusion. (I know you used 'should', still..).

I don't really want to get into a fight over the second statement,
because I basically agree with you. But at some point that statement
is only of theoretical value IMHO. And not only because creating that
piece of software might have a prohibitive price tag attached and it
might not be maintainable (your arguments). But also because you're
asking a human to figure out an equivalent or better transformation of
a program based on rules (some of which are implemented in the JIT
compiler). I just doubt that _on average_ the human will perform as
well at the task as the JIT compiler. And the larger your codebase for
the library, the more that ratio is going to change in favor of the
JIT compiler (same argument as for STM, and GC).

But well, I guess we agree about the basic message ;)

Cheers,
Daniel

PS: I didn't find any recent articles about how the Colt library or
similar number crunching tools running on the JVM compare to Assembler
and Fortran. I'd be interested in links...

--~--~-~--~~~---~--~~
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: Clojure performance tests and clojure a little slower than Java

[Daniel]

On Wed, Aug 12, 2009 at 12:00 PM, John Harrop wrote:
> Note: the expressions should be run three or four times. The first two or
> three timings will be longer than the later ones. (JIT?) Run until the times
> are consistent and at least three repetitions have been run in rapid
> succession.

JIT usually needs some time to kick in (especially under -server).
Check if your JVM supports the following flag:
-XX:+PrintCompilation which should print JIT compilation details.

> Note 2: someone with access to disassembly/memory debugger/perf tools might
> be able to learn more by running these loops, Andy's Clojure, and Andy's C
> on their system. Disassemblies of the JIT-generated code for the Clojure
> code and of the compiled C code would be interesting to compare, in
> particular.

There was a good thread on this list some weeks ago which mentioned
another JVM flag:
-XX:+PrintOptoAssembly

The original thread:
http://groups.google.com/group/clojure/browse_thread/thread/314952431ec064b7?fwc=1

Hope this helps.

Cheers,
Daniel

--~--~-~--~~~---~--~~
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: Clojure performance tests and clojure a little slower than Java

[Daniel]

On Thu, Aug 13, 2009 at 10:40 AM, Glen Stampoultzis wrote:
>> There was a good thread on this list some weeks ago which mentioned
>> another JVM flag:
>> -XX:+PrintOptoAssembly
>>
>> The original thread:
>>
>> http://groups.google.com/group/clojure/browse_thread/thread/314952431ec064b7?fwc=1
>>
>
> There's some more information about it at [1].  It looks like you need a
> plugin to get it to work.  I'm on Windows and unfortunately for Windows
> there doesn't seem to be a prebuilt binary for this platform.
>
> [1] http://wikis.sun.com/display/HotSpotInternals/PrintAssembly
>

Bugger, and I just read the instructions for building the thing on
windows [2]. Looks to be doable (I'd try cross-compiling on Linux with
VirtualBox [3]), but it's still non-trivial, and it's not sure whether
it'll work on a stock Sun JVM or if you need an OpenJDK build
(backported JDK 6 or work in progress JDK 7). :(

[2] 
http://hg.openjdk.java.net/jdk7/hotspot/hotspot/file/tip/src/share/tools/hsdis/README
[3] http://www.virtualbox.org/

--~--~-~--~~~---~--~~
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: Is there something special about haskell, or could "verifiability announcements" happen for purely functional Clojure programs too?

[Daniel]

On Sun, Aug 16, 2009 at 6:51 AM, Niels Mayer wrote:
> Executive summary: seems like big announcements of "provably correct
> software" would be easier to achieve in Java+Clojure than for C/Haskell used
> in the current "big news" regarding a provably secure kernel. However, given
> the bugs I enountered in a java-based DVR contract-from-hell that was a
> deadlocking side-effecting nightmare, I think this kind of "provability"
> work would be very useful for real world java and clojure running in
> "embedded java" whether it be a DVR glitching-out due to an improbable
> concurrence, or hospital life-support equipment, or aircraft control,
> military control, etc.
> Seems like this could also be a good potential "marketing opportunity" for
> Clojure, were it to be used as the basis for building provably-correct apps
> that run in a JVM. I think that market is much bigger than the "provable
> microkernel in C" market. E.g.  toolkit for building probably secure and
> reliable cell-phone/multimedia java apps, or toolkit for building embedded
> controller software on which people's lives depend, literally

I'm pretty sure others will answer and elaborate with more background
than I have, but here we go:

What they are talking about is (semi) automated theorem proving [1]
(subfield of automated reasoning). To do that you need to have a
modeling language with very strict semantics, because you can only
prove if you can 'reason' (make a guarantee based on certain
assumptions) in an way about what a 'sentence' of your model language
says. Very strict semantics with possibility to reason about it
without actually running the program translates in the field of
computer programming languages to static type systems. And here be
sure to notice that the Haskell (static) type system is a couple of
orders of magnitude more capable than the (static) type system of
Java.

I don't know where you would want to use Java and/or Clojure, but I
doubt that you can get very far, because Java's static type system is
too limited, and Clojure is dynamically typed. I think a functional
language is easier to reason about compared to an object oriented one
(please someone comment on this), but it's not enough for theorem
proving.

The documentation available in HTML on the site is a bit thin as to
how they actually used Haskell and C together, check the paper: "seL4:
Formal verification of an OS kernel" [2]. The actual implementation
and what they prove (and not prove) can be found in section 2 -
Overview.

Cheers,
Daniel

[1] http://en.wikipedia.org/wiki/Automated_theorem_proving
[2] http://ertos.nicta.com.au/publications/papers/Klein_EHACDEEKNSTW_09.pdf

> http://ertos.nicta.com.au/research/l4.verified/ and http://ertos.nicta.com.au/research/l4.verified/approach.pml
>>
>> The L4.verified project
>>
>>   A Formally Correct Operating System Kernel
>
> In current software practice it is widely accepted that software will always
> have problems and that we will just have to live with the fact that it may
> crash at the worst possible moment: You might be on a deadline. Or, much
> scarier, you might be on a plane and there's a problem with the board
> computer.
>
> Now think what we constantly want from software: more features, better
> performance, cheaper prices. And we want it everywhere: in mobile phones,
> cars, planes, critical infrastructure, defense systems.
>
> What do we get? Mobile phones that can be hacked by SMS. Cars that have more
> software problems than mechanical ones. Planes where computer problems have
> lead to serious incidents. Computer viruses spreading through critical
> infrastructure control systems and defense systems. And we think "See, it
> happens to everybody."
>
> It does not have to be that way. Imagine your company is commissioning a new
> vending software. Imagine you write down in a contract precisely what the
> software is supposed to do. And then — it does. Always. And the developers
> can prove it to you — with an actual mathematical machine-checked proof.
>
> Of course, the issue of software security and reliability is bigger than
> just the software itself and involves more than developers making
> implementation mistakes. In the contract, you might have said something you
> didn't mean (if you are in a relationship, you might have come across that
> problem). Or you might have meant something you didn't say and the proof is
> therefore based on assumptions that don't apply to your situation. Or you
> haven't thought of everything you need (ever went shopping?). In these
> cases, there will still be problems, but at least you know where the problem
> is not: with the developers. Eli

Re: Clojure/EPL and the GPL

[Daniel]

On Sat, Aug 29, 2009 at 3:52 PM, Garth Sheldon-Coulson wrote:
> Another option Rich could consider for Clojure is the Mozilla tri-license
> (GPL/LGPL/MPL).
>
> http://www-archive.mozilla.org/MPL/relicensing-faq.html
>
> The tri-license would remove any lingering ambiguity about building GPLed
> Clojure projects.
>
> But actually I believe the status quo is already quite permissive. The fact
> that Clojure is EPLed doesn't mean you can't write GPLed apps using it.* The
> EPL-GPL incompatibility bites you only when you try to GPL something that is
> a "derivative work" of Clojure. Doing so would be illegal in the status quo.
> Simple apps built with Clojure don't create a derivative work. Libraries
> probably don't either. Packaging Clojure with your application doesn't. A
> modification of Clojure itself does. Anything in between is iffy. The EPL
> FAQ covers most of this stuff. See:
>
> http://www.eclipse.org/legal/eplfaq.php#GPLCOMPATIBLE
> and
> http://www.eclipse.org/legal/eplfaq.php#EXAMPLE
>

I found this link also pretty interesting:

http://www.dwheeler.com/essays/floss-license-slide.html

Doesn't cover the EPL though.

(... but also IANAL, and can't/won't advise on legal matters).

Cheers,
Daniel

--~--~-~--~~~---~--~~
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: Searching the group archives

[Daniel]

On Sun, Aug 30, 2009 at 1:54 AM, Rich Hickey wrote:
>
> While the "Search this group" interface seems increasingly anemic, and
> time-limited in its results, you can get an effective search on the
> group archives using the advanced search:
>
> http://groups.google.com/advanced_search?q=&;
>
> Just select google groups and put clojure as the group.

http://groups.google.com/advanced_search?q=&sitesearch=groups.google.com&as_ugroup=clojure

Cheers,
Daniel

--~--~-~--~~~---~--~~
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: Clojure for game programming?

[Daniel]

On Sun, Aug 30, 2009 at 2:20 PM, ztellman wrote:
>
> You may have already seen this and decided Cloggle was a bit more to
> your liking, but I'm also working on a JOGL wrapper called Penumbra
> ( http://github.com/ztellman/penumbra/tree/master ).  Documentation is
> thin, but here are some demos in the src/examples subdirectory to
> illustrate usage.  At the very least, it may give you some ideas.
>

I don't know if this is relevant for you game developers or not, but I
used a LWJGL some time way back. I think it's a procedural API
(semi-automatic translation of the C API IIRC, only static methods in
Java), compared to the more objectified one from JOGL (GL context).
But I haven't done anything 3D in recent years, so I don't know how
they stack up, or if it's even relevant for you.

On a related note there's also the jMonkeyEngine, a 3D scene graph
implementation on top of either LWJGL or JOGL (I think LWJGL support
was first and maybe still better). Might be interesting to you, but it
will not use Clojure's approach to mutability (obviously), so this as
well might be a fit or not.

Hope that helps, otherwise ignore ;)

Cheers,
Daniel

[1] http://www.lwjgl.org/
[2] http://www.jmonkeyengine.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
-~--~~~~--~~--~--~---

Re: Interactive heuristic

[Daniel]

On Mon, Sep 7, 2009 at 3:10 AM, Phil Hagelberg wrote:
>
> Stuart Sierra  writes:
>
>> The problem is, I think, that everyone will have a slightly different
>> definition of "interactive environment."  If I run
>>     java ... clojure.main path/to/file.clj
>> does that count?  What about
>>     java ... my.compiled.namespace
>> ?  Or what about a REPL thread inside another application?  Or a
>> Clojure function invoked from Java code?
>
>> I think the solution is to define your own *environment* var and bind
>> it where you see fit, wrapping clojure.main if necessary.
>
> That's not really helpful for my purposes; I want by code to behave the
> same way whether started from slime, an IDE, or the REPL; to do that I'd
> have to either maintain my own list of heuristics for each possible
> environment or get some sort of buy-in from the developers of each
> environment. But now that I think about it, I don't suppose it's likely
> to get enough consensus/buy-in for such a thing to actually be a
> reliable heuristic, so I'll just code it against SLIME and let users of
> the other environments patch it themselves. =)

Mmh, I don't know why you have the requirement (see Meikels answer
about whether you really need it or not), but if you really have it
then I'm not sure whether you actually need all the patching. Your
approach is that the calling side is setting a global var (probably
only going to happen for the dynamic environments, as the other ones
are clojure agnostic). What you can always do (non-portable and
confined to your code) is to rely on a environment variable (JVM -D
cmdline, java.lang.System.getProperty(String)) which can be set for
your different scenarios.

Alternatively, if you want something which doesn't require the
commandline to change but also doesn't involve a change in the actual
code of the containers, you can try to 'query' your environment. E.g.
try to load a signature class for Swank, and if it succeeds you figure
you're running inside an Emacs session. Or for the servlet containers,
they all publish stuff in JMX, so you can find out whether it's
Tomcat, JBoss, etc. That deducing is going to be brittle to a certain
extent, but it's also less intrusive, as you don't require anyone else
to change their code. And you have more control over what is actually
going to be the 'real' user agent when you're running multiple
strategies at once (REPL inside Tomcat etc.) by inspecting results
from different calls.

HTH
-D

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

Re: Is knowing Java a prerequisite for using Clojure?

[Daniel]

On Thu, Sep 17, 2009 at 9:59 PM, Terrance Davis
 wrote:
>
> I'll add my two cents.
>
> You sound like you already program, so basic Java knowledge is useful
> with Clojure, but not necessary. You can pick up what you need to know
> as you learn Clojure. You will find hooks into Java are a lot more
> pleasant than interfacing with C and C++. I'm saying that one from
> experience.
>
> As for first books on Java,  Look for Bruce Eckel's "Thinking in
> Java" That is absolutely the best book currently available for Java. It
> is more written for beginner programmers, but would likely work for a
> more experienced programmer, too.

I'll second that. Introductions to (mainstream) programming languages
are IMHO very often quite boring because they assume you're a bit
dense and you don't know anything about programming beforehand (or
abstract thinking for that matter). If you want an intro to Java that
is not dry and treats you as a reasonably intelligent being, try
'Thinking in Java'.

Dead tree version is nice, but the full text of the 3rd edition is
also available online [1], so you can sample the style and decide for
yourself. The current edition is 4th, which includes Java 5 (I think
there's a link provided to download the first seven chapters of the
4th edition so that might also help).

HTH

Cheers,
-D

[1] http://www.mindview.net/Books/TIJ/

--~--~-~--~~~---~--~~
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: API pages

[Daniel]

Looks fine in 3.5.4.

On Dec 2, 11:24 pm, Sean Devlin  wrote:
> Hey, the API page doesn't look right in Firefox 3.5
>
> The cut off around halfway through the page.
>
> I think this also happens in Safari, but I'm not sure right now.
>
> Oh, and IE 6... YUCK! (But that's expected :))
>
> Sean

-- 
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: another concurrency question: could there be contention for allocation (consing etc.)?

[Daniel]

Not sure if this is going to help, but I recently tried to optimize
performance of my long running IDE process, and crawled through a lot
of JVM flags and benchmarks. I give you the more or less raw list
below (stripped of UI related stuff), which you might find useful.
Machine specs are Macbook 2Ghz Core 2 Duo, 4Gb RAM

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-9M3125)
Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01-101, mixed mode)

Especially the Parallel GC option below need at least 1.6.0_10,
preferably _16+ It was a bit flaky before, and it's still an
experimental feature, so don't complain if you're computer turns into
marshmallows or something :)

Also be aware that the following setup is going to make your startup
slower, but your subsequent execution faster.

-server
-Xms256m
-Xmx1024m (Note: give your process enough memory, but not too much,
otherwise you're competing with other processes on you're machine, and
the OS will start to page out, and subsequently thrash.)
-Djava.net.preferIPv4Stack=true
-XX:CompileThreshold=1500 (makes the server VM compile faster. server
compiles after 10k calls with better results, so if you're running in
a tight loop and/or have a server duration of uptime (ie. multiple
days and longer), then it might make sense to omit this one, also
don't go lower than 1500 (the setting for -client, performance
deteriorates, because compilation is adapts to runtime statistics.
More statistics -> faster code)
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC (not sure if this flag is redundant with the one above)
-XX:+ExplicitGCInvokesConcurrent
-XX:+CMSClassUnloadingEnabled
-XX:MaxPermSize=250m
-XX:+UseAdaptiveSizePolicy
-XX:+AggressiveOpts
-XX:+UseFastAccessorMethods
-XX:+UseFastEmptyMethods
-XX:+UseFastJNIAccessors
-Xverify:none (very important flag, if you trust all executed code.
This will disable bytecode verification, speeding up loading of new
code. On further thought, this might be one of your bottlenecks, if
you're not only generating lists, but actually compiling them with
Clojure (-> new bytecode))
-XX:+UseCompressedOOPS


For the sake of completeness: UI related
-Dsun.java2d.opengl=true
-Dsun.awt.keepWorkingSetOnMinimize=true (I think this is only relevant
on Win32, not sure. Deals with OS not swapping out the working set on
window minimize)
-Dawt.useSystemAAFontSettings=lcd

I didn't explain every single flag, Google is your friend. There are
also quite a few interesting benchmarks around on the influence of the
flags depending on machine architecture (4 or more cores for
instance), and on OS (Win, Mac, *nix, 32/64bit). Be sure to constrain
your search to the last 2 years or so, a lot is old stuff and
irrelevant. 1.6.0_10 was the equivalent of a new JVM, because the JDK
process was (is) delayed.

Note: I just skimmed the messages and didn't see any discussion
before, so if this has already been discussed or if there are more
specific details on your process around, sorry for not reading them.

On my machine the above settings seemed to help keeping things sane. I
would be interested to know whether you had any success with the
settings.

If I missed anything that anyone found worthwhile, I'd be interested
to hear as well.

Hope that helps

Cheers,
Daniel


On Sat, Mar 27, 2010 at 5:21 PM, Chas Emerick  wrote:
> If you're not using a parallel garbage collector (which is the case by
> default), then generating significant garbage will result in
> not-insignificant GC pauses.  Allocation itself isn't a synchronous
> operation, but the default GC is.
>
> Most java profilers have thread-related tools that allow you to see on what,
> when, and for how long threads are blocking.  It'd be worth it to enable
> parallel GC just to see what happens, but beyond that, it sounds like some
> data would help in determining specifically what code is tripping you up.
>
> If you can post/paste code, that might help, too.
>
> - Chas
>
> On Mar 27, 2010, at 12:13 AM, Lee Spector wrote:
>
>>
>> Is it possible that multiple threads all furiously generating list
>> structure would have some sort of contention for the memory allocation
>> state?
>>
>> My losses of multicore utilization seem to be correlated with the
>> generation of lots of random expressions in concurrent threads. I'd been
>> worrying about contention for the random states, which I think I've now made
>> thread local, but now I wonder if the contention might be in the allocation.
>> Possible? If so, then is there a way around it?
>>
>> Thanks,
>>
>> -Lee
>>
>> --
>> Lee Spector, Professor of Computer Science
>> School of Cognitive Science, Hampshire College
>> 893 West Street, Amherst, MA 01002-3359
>> lspec...@hampshire.edu, h

Getting started with open source Clojure projects

[Daniel]

If this is a dumb question, let me apologize in advance. The thing is,
I've been trying to learn Clojure in my spare time, and, following the
advice of several Clojure blogs, started by reading Halloway's book
and playing around a bit at the REPL, which is all well and good, but
now I'm ready to tackle something a little bigger. The project that
interests me most is James Reeve's Compojure, so I cloned the
repository with the intention of loading the source files into the
REPL and testing out some of the functions to get an idea of how it
works internally. The first hurdle was getting all the dependent
classes on the classpath, which I did by adding them one by one to
the .clojure file (I'm using a script that concatenates the contents
of .clojure to the classpath before launching the REPL). So far, so
good. However, when I try to load core.clj from the REPL, it complains
about not being able to find "compojure/response.clj" or its
equivalent class. And it does this even if I load response.clj first,
then try to load core.clj.

So here are my questions:

Am I going about this the wrong way? Is there an easier way to explore
existing open-source projects? I
Is there a less cumbersome way to get a load of files on the classpath
than manually editing the .clojure file?
How do I tell the REPL where to find response.clj so that core.clj
will load?

Any other advice will be much appreciated as well.

Thanks,

Daniel

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

To unsubscribe from this group, send email to 
clojure+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: Getting started with open source Clojure projects

[Daniel]

Thanks for all the quick replies. I should've mentioned that I'm
already using leiningen, so the problem isn't so much getting the
dependencies and building the application as it is figuring out a way
to get inside the code and play with it a bit. I'd like to be able to
load the source files, execute member functions, and just get a feel
for what's going on internally. What sort of method do you all use for
exploring open source projects? Do you just read the source code, or
do you load it and test it out?

Thanks,

Daniel

On Mar 30, 6:50 pm, Matt  wrote:
> If you're not stuck on using Compojure, you can try Conjure which will
> includes all of the dependencies in the jar.
>
> To start a hello world app:
>
> 1. Download conjure.jar from:http://github.com/macourtney/Conjure/downloads
> 2. java -jar conjure.jar hello_world
> 3. cd hello_world
> 4. ./run.sh script/server.clj
> 5. Point your browser athttp://localhost:8080/
> 6. Profit!
>
> There is a tutorial for Conjure 
> at:http://wiki.github.com/macourtney/Conjure/hello-world-tutorial-2
>
> -Matt Courtney

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

To unsubscribe, reply using "remove me" as the subject.

Re: My First Clojure Program -- Can Someone Critique It?

[Daniel]

I made a few minor adjustments to get it to work on Mac OS X 10.6 and
posted it to: http://gist.github.com/398122

Daniel

On May 9, 7:42 am, Tim Morgan  wrote:
> I picked up Programming Clojure by Stuart Halloway last week and am
> working through the book. I'm coming from a Perl/Python/Ruby
> background, so Java + Lisp + functional programming is all new to me.
>
> I thought a good exercise would be to write a script that pings all
> ips on a subnet looking for existing hosts, since I've written the
> same thing in Ruby before.
>
> The script I came up with is here:http://gist.github.com/395153
>
> It works (and it's considerably faster than my Ruby equivalent!), but
> I'm not certain it's idiomatic Clojure, and would love if someone
> could critique me a bit. Tear it apart.
>
> Thanks!
>
> -Tim Morgan
>
> --
> 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 
> athttp://groups.google.com/group/clojure?hl=en

-- 
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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Daniel]

You could be really odd and write a wrapper for Edje.

http://trac.enlightenment.org/e/wiki/Edje

Not a serious recommendation, really.  I just don't have any strong
positive opinions regarding any of the others except for QT, and as
you say

On May 27, 10:18 am, Luke VanderHart 
wrote:
> My side project is a fairly complex GUI application written in
> Clojure. Recently, I've become irritated with using Java interop for
> everything. It's not that Clojure doesn't have nice java interop - it
> does. It's just that when interacting with a GUI framework, which is a
> large part of my app, I have to be back in mutable object-oriented
> land, worrying about class hierarchies, mutable state, locks, etc.
> Yucky.
>
> So, with a perhaps dangerous lack of sanity and without any guarantee
> of success, I've decided to try my hand at writing an idiomatic
> Clojure GUI library. If I have success (which I doubt) I will of
> course make it available as open source.
>
> I intend for it to be mostly declarative, with a nice DSL for defining
> GUI elements. Each component will also implement map, and use one of
> Clojure's reference types as an interface for inspecting / updating
> its state. I may also implement some aspects of Functional Reactive
> Programming wherever it's convenient to do so.
>
> What you all must help me decide is what GUI framework to use as the
> underpinnings of it. It's genuinely hard to decide. I have at least
> some experience with all of them, so I have no strong preference, but
> I'd like to get your input. I did consider trying to make it abstract
> enough that you could plug in *any* of them under the hood, but
> there's enough differences between the frameworks that that would get
> very ugly very fast.
>
> Possibilities are:
>
> AWT
> Pros: native widgets, bundled with Java, low-level
> Cons: few widgets, considered somewhat obselete
>
> Swing
> Pros: bundled with Java, good widget selection
> Cons: non-native widgets
>
> SWT
> Pros: native widgets, widely used
> Cons: requires platform-specific libs
>
> QT Jambi
> Pros: native widgets, huge widget selection, highly-regarded framework
> Cons: requires platform-specific libs, writing custom widgets is
> hairy, momentum and support seem to be lagging since Nokia dropped
> official support.
>
> Remember, the actual API won't matter - that will be completely
> abstracted away. So try to focus on the framework's look and feel.
> Also let me know if I've missed any of the framework's key
> characteristics.
>
> Thanks!
>
> -Luke

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

Macro question from a clojure newbie

[Daniel]

Hi all,

I'm running into a problem where I need to define several functions
and/or vars inside another function, but the function has multiple
definitions and they all need to have access to the inner things.
This could be solved by making private functions and using partial,
but this sounds like a good problem to tackle with a macro.  I'm not
sure how to do it, though, being so new to the language.  Here's a
useful example, where defwithinner is the macro name:


(defwithinner primitives
  "Generates pythagorean primitives.  Will filter them against pred if
given."
  (let [U (gen-matrix [1 2 2 -2 -1 -2 2 2 3] 3 3)
A (gen-matrix [1 2 2 2 1 2 2 2 3] 3 3)
D (gen-matrix [-1 -2 -2 2 1 2 2 2 3] 3 3)
S (gen-vector [3 4 5])]
(letfn [(prims-from [m] [(mult m U) (mult m A) (mult m D)])
(next-prims [l] (flatten (map prims-from l)))]))
  ([] (iterate next-prims [S]))
  ([pred] (iterate #(filter pred (next-prims %)) [S])))

--->

(defn primitives
  "Generates pythagorean primitives.  Will filter them against pred if
given."
  ([]
  (let [U (gen-matrix [1 2 2 -2 -1 -2 2 2 3] 3 3)
A (gen-matrix [1 2 2 2 1 2 2 2 3] 3 3)
D (gen-matrix [-1 -2 -2 2 1 2 2 2 3] 3 3)
S (gen-vector [3 4 5])]
(letfn [(prims-from [m] [(mult m U) (mult m A) (mult m D)])
(next-prims [l] (flatten (map prims-from l)))]
  (iterate next-prims [S]
  ([pred]
  (let [U (gen-matrix [1 2 2 -2 -1 -2 2 2 3] 3 3)
A (gen-matrix [1 2 2 2 1 2 2 2 3] 3 3)
D (gen-matrix [-1 -2 -2 2 1 2 2 2 3] 3 3)
S (gen-vector [3 4 5])]
(letfn [(prims-from [m] [(mult m U) (mult m A) (mult m D)])
(next-prims [l] (flatten (map prims-from l)))]
  (iterate #(filter pred (next-prims %)) [S])


OTOH, being so new to clojure I've probably missed some mechanism
which already takes care of this problem.

-- 
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: Macro question from a clojure newbie

[Daniel]

The first solution looks good.  I had no idea that wrapping a defn
inside of let's would leave the function exposed.  Interesting.  Is it
considered idiomatic though?

On May 30, 2:16 pm, Erik Söhnel  wrote:
> Hi,
>
> Not really mechanisms, but two Idioms will help you with your problem:
> Either wrap the defn in a let:
>
> (let [U (gen-matrix [1 2 2 -2 -1 -2 2 2 3] 3 3)
>       A (gen-matrix [1 2 2 2 1 2 2 2 3] 3 3)
>       D (gen-matrix [-1 -2 -2 2 1 2 2 2 3] 3 3)
>       S (gen-vector [3 4 5])]
>   (letfn [(prims-from [m] [(mult m U) (mult m A) (mult m D)])
>             (next-prims [l] (flatten (map prims-from l)))]
>     (defn primitives
>       "Generates pythagorean primitives.  Will filter them against
> pred if
>   given."
>       ([] (iterate next-prims [S]))
>       ([pred] (iterate #(filter pred (next-prims %)) [S])
>
> or use a default value for pred: (constantly true)
>
> (defn primitives
>   "Generates pythagorean primitives.  Will filter them against pred if
> given."
>   ([] (primitives (constantly true)))
>   ([pred]
>      (let [U (gen-matrix [1 2 2 -2 -1 -2 2 2 3] 3 3)
>            A (gen-matrix [1 2 2 2 1 2 2 2 3] 3 3)
>            D (gen-matrix [-1 -2 -2 2 1 2 2 2 3] 3 3)
>            S (gen-vector [3 4 5])]
>        (letfn [(prims-from [m] [(mult m U) (mult m A) (mult m D)])
>                (next-prims [l] (flatten (map prims-from l)))]))
>      (iterate #(filter pred (next-prims %)) [S])))
>
> The former will evaluate the values only once when the file is loaded
> and keep them around until your program dies and do not impose any
> runtime overhead when you call the function, because all variables are
> already initialized.
> The latter one uses a default argument to pred. (constantly true)
> returns a n-argument function wich returns true on every invokation.
>
> Erik

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

[ANN] core.rrb-vector -- RRB-Tree-based confluently persistent vectors

[Daniel]

Apologies for my lack of knowledge. My understanding was that a finger tree 
implementation has been in development for some time and was to provide the 
same benefits. Can you explain the differences between RRB trees and finger 
trees? Any hope of getting this project into core?

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

Future of clojure.contrib.core/-?> macro

[Daniel]

you should also check out https://github.com/rplevy/swiss-arrows

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

[ANN] Pedestal 0.1.9 has been released

[Daniel]

Awesome, thanks for the hard work. I imagine this will require some updates to 
the getting started page.

I'm in the process of learning how to use pedestal right now.  Besides the 
website and sample projects on github, are there any other good resources for 
learning?

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

Re: [ANN] Vertigo: fast, idiomatic C-style structs

[Daniel]

How did this affect performance in your Go AI?

On Tuesday, July 9, 2013 10:56:03 PM UTC-5, Zach Tellman wrote:
>
> Last year, I gave a talk at the Conj on my attempt to write an AI for the 
> board game Go.  Two things I discovered is that it was hard to get 
> predictable performance, but even once I made sure I had all the right type 
> hints, there was still a lot of room at the bottom for performance 
> improvements.  Towards the end [1], I mentioned a few ideas for 
> improvements, one of which was simply using ByteBuffers rather than objects 
> to host the data.  This would remove all the levels of indirection, giving 
> much better cache coherency, and also allow for fast unsynchronized 
> mutability when the situation called for it.
>
> So, ten months and several supporting libraries [2] [3] later, here it is: 
> https://github.com/ztellman/vertigo
>
> At a high level, this library is useful whenever your datatype has a fixed 
> layout and is used more than once.  Depending on your type, it will give 
> you moderate to large memory savings, and if you're willing to forgo some 
> of core library in favor of Vertigo's operators, you can get significant 
> performance gains on batch operations.  And, in the cases where performance 
> doesn't matter, it will behave exactly like any other Clojure data 
> structure.
>
> I want to point out that something like this would be more or less 
> impossible in Java; reading from an offset in a ByteBuffer without the 
> compile-time inference and validation provided by this library would be 
> pointlessly risky.  There's not a lot of low-level Clojure libraries, but 
> there's an increasing amount of production usage where people are using 
> Clojure for performance-sensitive work.  I'm looking forward to seeing what 
> people do with Vertigo and libraries like it.
>
> Zach
>
> [1] 
> http://www.youtube.com/watch?feature=player_detailpage&v=v5dYE0CMmHQ#t=1828s
> [2] https://github.com/ztellman/primitive-math
> [3] https://github.com/ztellman/byte-streams
>

-- 
-- 
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: the snake game with core.async and swing

[Daniel]

Or quil, a processing wrapper, would be well suited to this application.

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

Re: [ANN] core.typed 0.2.0 - Production Ready

[Daniel]

Excellent work. I noticed that function parameter types default to Any when 
not Annotated.  What was the reasoning behind not mirroring this behavior 
for vars, and instead requiring an annotation?


On Wednesday, August 28, 2013 5:28:35 PM UTC-5, Ambrose Bonnaire-Sergeant 
wrote:
>
> Hi,
>
> After 10 months and 26 0.1.x releases of transitioning core.typed from an 
> ambitious student project, I am finally comfortable recommending core.typed 
> for production use.
>
> Production Ready
>
> My interpretation of "production ready" in this context is:
> - core.typed can *find bugs* in real code
> - core.typed will *not slow down* your existing code by loading
>   a large library at production. (core.typed does introduce an extra 
> "identity-like"
>   function call at type annotations, I assume this is a candidate for 
> optimisation via
>   HotSpot)
> - A basic *tutorial*, API docs and example project exist
> - core.typed is *currently used in production* with success (at CircleCI 
> for several months)
> - The core type checking API is mostly *stable*, with only very
>   minor removals/breaking changes in the last few months.
>
> There are several outstanding issues, but I am satisfied that core.typed 
> can bring real utility to real programs *today* and with *no 
> production-time drawbacks*, thus this release.
>
> How to get started
>
> Leiningen dep:
>
> [org.clojure/core.typed "0.2.0"]
> ...; for very recent releases:repositories {"sonatype-oss-public" 
> "https://oss.sonatype.org/content/groups/public/"}
>
> If you like following tutorials try the user/types guide. If you just want 
> to get your hands on some typed code, see the Example project.
>
> core.typed User Guide
> core.typed Types Guide 
> Example project 
> API Reference 
>
> core.typed Github Home 
> core.typed Wiki 
>
> Please report bugs, ask questions or discuss things on the mailing 
> list
> .
>
> (FWIW I'm ambrosebs on #clojure.)
>
> Thanks,
> Ambrose
>

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

Re: [ANN] core.typed 0.2.0 - Production Ready

[Daniel]

Couldn't occurrence typing catch the error in that example, since 
evil-atom-reset! can only return an atom wrapping a keyword?

I guess the problem I had is that the "optional typing" moniker seems 
misleading since it forces you to annotate vars.  I had visions of gradually 
assigning types to vars as it became evident that typing was needed as a 
pre-runtime guardrail based on how other developers were using my functions.  
If I'm publishing a library then that's backward thinking, but in a team using 
core.typed it sounds useful... Only type what you need when you need to.

Don't mind me... Clearly I need to actually use the library before developing 
an opinion.

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

Re: [ANN] core.typed 0.2.0 - Production Ready

[Daniel]

If you can do that, why not return the literal representation of the type 
hinted function?

For the repl you could provide a function that interns the type-hinted 
function into the namespace by evaluating the literal representation first.

>From there it's easy to provide something like slamhound.  Once you're 
certain types have been provided to your namespace correctly at the repl, 
run 'lein type ' to type hint everything in the namespace by 
literally restructuring the file.

Things type hinted with expressions would be tricky, but this could work 
(or you could just leave it alone):

myfn (original)
myfn-int
myfn-long
myfn-float
etc



On Thursday, August 29, 2013 6:40:16 AM UTC-5, Ambrose Bonnaire-Sergeant 
wrote:
>
> With Clojure the lines blur between compile time and runtime.
>
> The clearest way to put it is that type checking is explicitly called at 
> the REPL or in a unit test. Usually this is done during development 
> iterations or testing time.
>
> Re: performance improvements: Michael is correct. Interestingly Typed 
> Racket offers numeric optimisations, but leans heavily on Racket's 
> metaprogramming facilities to insert them automatically. There's potential 
> in Typed Clojure for *identification* of speed improvements, but not 
> actually inserting them. Typed Racket's "optimisation coach" comes to mind 
> in ways we can present this information ("put a type hint at line 10, col 
> 20 to get full speed...").
>
> Thanks,
> Ambrose
>
>
> On Thu, Aug 29, 2013 at 6:03 PM, Christian Sperandio <
> christian...@gmail.com > wrote:
>
>> Ok...
>>
>> Another question, the checking is done only once (while compiling) ? Or, 
>> it's done while the runtime?
>>
>>
>>
>> 2013/8/29 Michael Klishin >
>>
>>> 2013/8/29 Christian Sperandio >
>>>
 Is there any perf improvement to use static typing in Clojure?
>>>
>>>
>>> core.typed is not a compiler, it's a type annotation/checker implemented
>>> as a library.
>>>
>>> If you are familiar with Erlang, it is to Clojure what Dialyzer is to 
>>> Erlang.
>>> -- 
>>> MK
>>>
>>> http://github.com/michaelklishin
>>> http://twitter.com/michaelklishin
>>>  
>>> -- 
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com 
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com .
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>  -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

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

Re: [ANN] core.typed 0.2.0 - Production Ready

[Daniel]

Those forms won't be in the namespace you're evaluating?

Yeah, it's probably a lot of work, but it sounds neat.  :-)


On Thursday, August 29, 2013 9:07:26 AM UTC-5, Ambrose Bonnaire-Sergeant 
wrote:
>
> I don't think it would be possible to reconstruct the original forms in 
> general, you would need to reverse macroexpansion to provide a form that 
> has at least a passing familiarity with the original form. Otherwise you 
> would get fully macroexpanded forms.
>
> That's a lot of work!
>
>
> On Thu, Aug 29, 2013 at 9:56 PM, Daniel 
> > wrote:
>
>> If you can do that, why not return the literal representation of the type 
>> hinted function?
>>
>> For the repl you could provide a function that interns the type-hinted 
>> function into the namespace by evaluating the literal representation first.
>>
>> From there it's easy to provide something like slamhound.  Once you're 
>> certain types have been provided to your namespace correctly at the repl, 
>> run 'lein type ' to type hint everything in the namespace by 
>> literally restructuring the file.
>>
>> Things type hinted with expressions would be tricky, but this could work 
>> (or you could just leave it alone):
>>
>> myfn (original)
>> myfn-int
>> myfn-long
>> myfn-float
>> etc
>>
>>
>>
>> On Thursday, August 29, 2013 6:40:16 AM UTC-5, Ambrose Bonnaire-Sergeant 
>> wrote:
>>
>>> With Clojure the lines blur between compile time and runtime.
>>>
>>> The clearest way to put it is that type checking is explicitly called at 
>>> the REPL or in a unit test. Usually this is done during development 
>>> iterations or testing time.
>>>
>>> Re: performance improvements: Michael is correct. Interestingly Typed 
>>> Racket offers numeric optimisations, but leans heavily on Racket's 
>>> metaprogramming facilities to insert them automatically. There's potential 
>>> in Typed Clojure for *identification* of speed improvements, but not 
>>> actually inserting them. Typed Racket's "optimisation coach" comes to mind 
>>> in ways we can present this information ("put a type hint at line 10, col 
>>> 20 to get full speed...").
>>>
>>> Thanks,
>>> Ambrose
>>>
>>>
>>> On Thu, Aug 29, 2013 at 6:03 PM, Christian Sperandio <
>>> christian...@gmail.com**> wrote:
>>>
>>>> Ok...
>>>>
>>>> Another question, the checking is done only once (while compiling) ? 
>>>> Or, it's done while the runtime?
>>>>
>>>>
>>>>
>>>> 2013/8/29 Michael Klishin 
>>>>
>>>>> 2013/8/29 Christian Sperandio 
>>>>>
>>>>> Is there any perf improvement to use static typing in Clojure?
>>>>>
>>>>>
>>>>>  core.typed is not a compiler, it's a type annotation/checker 
>>>>> implemented
>>>>> as a library.
>>>>>
>>>>> If you are familiar with Erlang, it is to Clojure what Dialyzer is to 
>>>>> Erlang.
>>>>> -- 
>>>>> MK
>>>>>
>>>>> http://github.com/**michaelklishin <http://github.com/michaelklishin>
>>>>> http://twitter.com/**michaelklishin<http://twitter.com/michaelklishin>
>>>>>  
>>>>> -- 
>>>>> -- 
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Clojure" group.
>>>>> To post to this group, send email to clo...@googlegroups.com
>>>>>
>>>>> Note that posts from new members are moderated - please be patient 
>>>>> with your first post.
>>>>> To unsubscribe from this group, send email to
>>>>> clojure+u...@**googlegroups.com
>>>>>
>>>>> For more options, visit this group at
>>>>> http://groups.google.com/**group/clojure?hl=en<http://groups.google.com/group/clojure?hl=en>
>>>>> --- 
>>>>> You received this message because you are subscribed to the Google 
>>>>> Groups "Clojure" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>>> an email to clojure+u...@**googlegroups.com.
>>>>>
>>>>> For more options, visit 
>>>>> https://groups.google.com/**groups/opt_out<

Re: [ANN] core.typed 0.2.0 - Production Ready

[Daniel]

Yeah, it's pretty much impossible unless you limit yourself to a manageable 
subset of Clojure.  The "easy" part I was referring to was the Leiningen 
plugin, not the whole kit n' caboodle.

On Thursday, August 29, 2013 11:02:17 AM UTC-5, Alex Baranosky wrote:
>
> Imo, there's nothing "easy" about writing something like Slamhound. Even 
> after many iterations it can't handle macros, because ultimately they're 
> impossible, without some kind of hints specifically added for Slamhound (or 
> for Typed Clojure) :)
>

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

clojure.java.jdbc connection pool example

[Daniel]

I believe Korma uses c3p0 for connection pooling right out of the box.

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

Re: ANN: ClojureScript 0.0-2719, JavaScript Dependencies

[Daniel]

Extremely happy to see you promoting cljsjs as a community solution for 
something equivalent to clojars.

On Sunday, January 25, 2015 at 1:42:54 PM UTC-6, David Nolen wrote:
>
> I strongly recommend the Clojure(Script) community join forces when 
> packaging libraries to avoid duplicated effort and dependency conflicts.
>
> CLJSJS seems like a good initiative to me along these lines: 
> http://cljsjs.github.io
>
> David
>
> On Sun, Jan 25, 2015 at 1:49 PM, Vladimir Bokov  > wrote:
>
>> Thanks David!
>>
>> I also already packaged https://github.com/razum2um/jquery-cljs using 
>> your react repo as example
>>
>> суббота, 24 января 2015 г., 21:10:29 UTC+6 пользователь David Nolen 
>> написал:
>>
>>> ClojureScript, the Clojure compiler that emits JavaScript source code.
>>>
>>> README and source code: https://github.com/clojure/clojurescript
>>>
>>> New release version: 0.0-2719
>>>
>>> Leiningen dependency information:
>>>
>>> [org.clojure/clojurescript "0.0-2719"]
>>>
>>> ClojureScript is not an island, like Clojure on the JVM, ClojureScript
>>> embraces the many benefits provided by the host. However this goal
>>> has been hampered by another goal - the compilation stragey. Google
>>> Closure Compiler offers superior optimization and minification for
>>> ClojureScript while simultaneously making it considerably more
>>> difficult to integrate non-Closure compatible libraries. Using popular
>>> libraries like jQuery, React or D3 is an error prone process: "which
>>> extern did I forget?", "which script tag did I miss for development?",
>>> "are these script tags in dependency order?".
>>>
>>> No more. 0.0-2719 delivers full support for non-Closure compatible
>>> libraries through some less known features that have been lurking
>>> around for almost three years - `deps.cljs` and the :foreign-libs
>>> compiler option.
>>>
>>> `deps.cljs` is a simple EDN file provided at the root of a JAR that
>>> describes additional build information for the ClojureScript
>>> compiler. For example here is the `deps.cljs` for the React JAR I
>>> maintain:
>>>
>>> {
>>>  :foreign-libs [{:file "react/react.js"
>>>  :file-min "react/react.min.js"
>>>  :provides ["com.facebook.React"]}
>>> {:file "react/react_with_addons.js"
>>>  :file-min "react/react_with_addons.min.js"
>>>  :provides ["com.facebook.ReactWithAddons"]}]
>>>  :externs ["react/externs/react.js"]
>>> }
>>>
>>> This file provides all the information ClojureScript needs to
>>> correctly manage the foreign dependency for you under all compilation
>>> modes and REPLs.
>>>
>>> In a REPL:
>>>
>>>cljs.user> (require 'com.facebook.React)
>>>cljs.user> (. js/React 
>>> (renderToString 
>>>   (. js/React (DOM.div nil "Hello!"
>>>
>>> In your project:
>>>
>>>(ns foo.bar
>>>  (:require com.facebook.React))
>>>
>>>(enable-console-print!)
>>>
>>>(println
>>>  (. js/React
>>>(renderToString
>>>  (. js/React (DOM.div nil "Hello!")
>>>
>>> The above works under all compilation modes. There is no need to
>>> include React as a script tag under development, there is no need to put
>>> script tags in dependency order, there is no need to add React to
>>> :preamble under :advanced, and there is no need to explicitly provide
>>> :externs.
>>>
>>> All that is required is that JavaScript libraries be packaged in JARs
>>> with a `deps.cljs`.
>>>
>>> Some of you might reasonably ask why not a tool like Bower for this
>>> instead?  Bower requires an additional dependency on Node.js. While
>>> ClojureScript embraces Node.js as a useful target it is not a
>>> requirement to be productive. Bower manages dependencies, but in the
>>> Clojure world we have already embraced Maven for this task and have
>>> done the same for ClojureScript. Finally Bower does not address the
>>> problem of loading libraries at runtime. This is challenging to do -
>>> some JavaScript libraries adopt CommonJS, some AMD, and the most
>>> popular ones make no assumptions at all allowing users to simply use
>>> script tags as they have done for nearly two decades. The above
>>> solution addresses the issue for all ClojureScript users by
>>> eliminating paralysis of choice. Finally none of the above
>>> precludes Bower usage in any way whatsoever.
>>>
>>> This new feature addresses a long outstanding pain point with
>>> ClojureScript development. All that is required is that we take the
>>> time to properly package up the most popular JavaScript libraries that
>>> fill gaps not currently served by exising ClojureScript and Google
>>> Closure Library functionality.
>>>
>>> Please kick the tires and feedback is most welcome. This feature
>>> touched many bits of code so there are likely to be wrinkles and we want
>>> to get these ironed out as quickly as possible.
>>>
>>> ## 0.0-2719
>>>
>>> ### Changes
>>> * Full support for foreign dependencies
>>> *

[ANN] thi.ng collection update (CLJ/CLJS)

[Daniel]

This is incredible work. Thanks for sharing!

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

clojure map to java instance of pojo class

[Daniel]

bean?

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

Preferred way to connect to embedded Immutant Message Queuing service from eg C# application?

[Daniel]

With straight HornetQ I would just use StompConnect to expose the service 
to the outside world and that would allow .NET clients to connect pretty 
easily. There's also the possibility of websockets and REST now.

What is the preferred method?


SO question 
here: 
http://stackoverflow.com/questions/29149610/preferred-way-to-connect-to-immutant-message-queuing-service-from-eg-c-sharp-app

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

A more flexible versio of -> ?

[Daniel]

https://github.com/rplevy/swiss-arrows

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

Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Daniel]

Actually, I'm more than a little curious about performance optimizations to my 
solution as well[0]. Running Yourkit shows that most of the execution time is 
spent in reduce, so I've tried switching to group-by instead. Also tried 
replacing with iterate. Neither of these improved overall execution time.  
Using 1.6.

[0] 
https://www.reddit.com/r/dailyprogrammer/comments/35s2ds/20150513_challenge_214_intermediate_pile_of_paper/crbs3co?context=3

-- 
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] Demo of the Holy Grail workflow

[Daniel]

"this video is not available"

I am attempting to view on a mobile.

-- 
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] Clojure 1.7.0-RC1 now available

[Daniel]

Marshall, I'm unable to test at the moment, but if you replace

(java.util.EnumSet/allOf java.util.concurrent.TimeUnit)

with

(iterator-seq (.iterator (java.util.EnumSet/allOf 
java.util.concurrent.TimeUnit)))

will it work then?

On Tuesday, May 26, 2015 at 6:25:04 PM UTC-5, Marshall Bockrath-Vandegrift 
wrote:
>
> The difference is that the original behavior allowed room to transform the 
> mutated object into an object which *could* be safely cached in a 
> "downstream" seq, while the new behavior pumps the iterator through 32 
> mutations before user-level code has a chance to see it.  Contrived example 
> using the Java standard libary:
>
> Clojure 1.6.0:
> (->> (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit) 
> (range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
> #=> ["NANOSECONDS=0" "MICROSECONDS=1" "MILLISECONDS=2" "SECONDS=3" 
> "MINUTES=4" "HOURS=5" "DAYS=6"]
>
> Clojure 1.7.0-RC1:
> (->> (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit) 
> (range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
> #=> ["DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6"]
>
> IMHO the latter behavior demonstrates a mismatch where chunked seqs and 
> iterators are simple incompatible.
>
> On Tue, May 26, 2015 at 5:33 PM Alex Miller  > wrote:
>
>> In what way is it broken? Both before and after wrapped a mutable 
>> iterator into a caching seq. The new one is different in that it chunks so 
>> reads 32 at a time instead of 1. However combining either with other 
>> chunking sequence operations would have the same effect which is to say 
>> that using that mutable iterator with anything else, or having expectations 
>> about its rate of consumption was as dubious before as it is now.
>>
>> Unless of course I misunderstand your intent, which possible because I am 
>> on a phone without easy access to look further at the commit and am going 
>> by memory.
>>
>>
>>
>> On May 26, 2015, at 2:17 PM, Marshall Bockrath-Vandegrift <
>> lla...@gmail.com > wrote:
>>
>> Some of my code is broken by 
>> commit c47e1bbcfa227723df28d1c9e0a6df2bcb0fecc1, which landed in 
>> 1.7.0-alpha6 (I lasted tested with -alpha5 and have been unfortunately busy 
>> since).  The culprit is the switch to producing seqs over iterators as 
>> chunked iterators.  This would appear to break seq-based traversal of any 
>> iterator implementing the not-uncommon Java pattern of mutating and 
>> re-yielding the same object on each `next()` invocation.
>>
>> I'm unable to find an existing ticket for this apparent-regression.  
>> Should I create one, or did I miss the existing ticket, or is there some 
>> mitigating issue which makes this a non-problem?
>>
>> Thanks.
>>
>> -Marshall
>>
>> On Thu, May 21, 2015 at 12:31 PM Alex Miller > > wrote:
>>
>>> Clojure 1.7.0-RC1 is now available.
>>>
>>> Try it via
>>> - Download: 
>>> https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC1/
>>> - Leiningen: [org.clojure/clojure "1.7.0-RC1"]
>>>
>>> The only change since 1.7.0-beta3 is CLJ-1706, which makes reader 
>>> conditional splicing an error at the top level (previously it would 
>>> silently drop all but the first spliced element).
>>>
>>> For a full list of changes since 1.6.0, see:
>>> https://github.com/clojure/clojure/blob/master/changes.md
>>>
>>> Please give it a try and let us know if things are working (or not). The 
>>> more and quicker feedback we get, the sooner we can release 1.7.0 final!
>>>
>>> - Alex
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure Dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure-dev...@googlegroups.com .
>>> To post to this group, send email to cloju...@googlegroups.com 
>>> .
>>> Visit this group at http://groups.google.com/group/clojure-dev.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure Dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure-dev...@googlegroups.com .
>> To post to this group, send email to cloju...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/clojure-dev.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure Dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure-dev...@googlegroups.com .
>> To post to this group, send email to cloju...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/clojure-dev.
>> 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@googleg

Re: [ANN] Clojure 1.7.0-RC1 now available

[Daniel]

Got where I could try it and instantly became very confused.

Just...take a look.  http://imgur.com/4LgBdCY

On Tuesday, May 26, 2015 at 6:25:04 PM UTC-5, Marshall Bockrath-Vandegrift 
wrote:
>
> The difference is that the original behavior allowed room to transform the 
> mutated object into an object which *could* be safely cached in a 
> "downstream" seq, while the new behavior pumps the iterator through 32 
> mutations before user-level code has a chance to see it.  Contrived example 
> using the Java standard libary:
>
> Clojure 1.6.0:
> (->> (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit) 
> (range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
> #=> ["NANOSECONDS=0" "MICROSECONDS=1" "MILLISECONDS=2" "SECONDS=3" 
> "MINUTES=4" "HOURS=5" "DAYS=6"]
>
> Clojure 1.7.0-RC1:
> (->> (map vector (java.util.EnumSet/allOf java.util.concurrent.TimeUnit) 
> (range)) (into {}) (java.util.EnumMap.) (.entrySet) (map str) (into []))
> #=> ["DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6" "DAYS=6"]
>
> IMHO the latter behavior demonstrates a mismatch where chunked seqs and 
> iterators are simple incompatible.
>
> On Tue, May 26, 2015 at 5:33 PM Alex Miller  > wrote:
>
>> In what way is it broken? Both before and after wrapped a mutable 
>> iterator into a caching seq. The new one is different in that it chunks so 
>> reads 32 at a time instead of 1. However combining either with other 
>> chunking sequence operations would have the same effect which is to say 
>> that using that mutable iterator with anything else, or having expectations 
>> about its rate of consumption was as dubious before as it is now.
>>
>> Unless of course I misunderstand your intent, which possible because I am 
>> on a phone without easy access to look further at the commit and am going 
>> by memory.
>>
>>
>>
>> On May 26, 2015, at 2:17 PM, Marshall Bockrath-Vandegrift <
>> lla...@gmail.com > wrote:
>>
>> Some of my code is broken by 
>> commit c47e1bbcfa227723df28d1c9e0a6df2bcb0fecc1, which landed in 
>> 1.7.0-alpha6 (I lasted tested with -alpha5 and have been unfortunately busy 
>> since).  The culprit is the switch to producing seqs over iterators as 
>> chunked iterators.  This would appear to break seq-based traversal of any 
>> iterator implementing the not-uncommon Java pattern of mutating and 
>> re-yielding the same object on each `next()` invocation.
>>
>> I'm unable to find an existing ticket for this apparent-regression.  
>> Should I create one, or did I miss the existing ticket, or is there some 
>> mitigating issue which makes this a non-problem?
>>
>> Thanks.
>>
>> -Marshall
>>
>> On Thu, May 21, 2015 at 12:31 PM Alex Miller > > wrote:
>>
>>> Clojure 1.7.0-RC1 is now available.
>>>
>>> Try it via
>>> - Download: 
>>> https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC1/
>>> - Leiningen: [org.clojure/clojure "1.7.0-RC1"]
>>>
>>> The only change since 1.7.0-beta3 is CLJ-1706, which makes reader 
>>> conditional splicing an error at the top level (previously it would 
>>> silently drop all but the first spliced element).
>>>
>>> For a full list of changes since 1.6.0, see:
>>> https://github.com/clojure/clojure/blob/master/changes.md
>>>
>>> Please give it a try and let us know if things are working (or not). The 
>>> more and quicker feedback we get, the sooner we can release 1.7.0 final!
>>>
>>> - Alex
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure Dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure-dev...@googlegroups.com .
>>> To post to this group, send email to cloju...@googlegroups.com 
>>> .
>>> Visit this group at http://groups.google.com/group/clojure-dev.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure Dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure-dev...@googlegroups.com .
>> To post to this group, send email to cloju...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/clojure-dev.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure Dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure-dev...@googlegroups.com .
>> To post to this group, send email to cloju...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/clojure-dev.
>> 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 thi

complex number library

[Daniel]

Criterium should probably be just a Dev dependency.

-- 
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] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help

[Daniel]

Just another +1 to include a core.matrix implementation

-- 
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: I want to get sha1 of a string

[Daniel]

+1 for Pandect.  It's an excellent library which leverages bouncy castle and 
has had tons of top notch work put into it.  Fast, well documented, and super 
easy to use.

-- 
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: Using an atom for a caching map

[Daniel]

If the values in the map don't change then why not just drop the map? 
 Implement the map as a function and memoize it eg (def f (memoize (fn [k] 
(calc-value k

On Saturday, August 30, 2014 12:27:05 AM UTC-5, Colin Fleming wrote:
>
> Hi all,
>
> I want to use a map to cache values based on a key. I'm planning to use an 
> atom for this. My basic operation is "give me the value for this key" - if 
> the value exists in the map then that value should be returned, otherwise a 
> new value should be calculated, inserted in the map and then returned. My 
> plan is to implement something like the following:
>
>
> (defn ensure [cache key]  (if (contains? cache key)cache(assoc cache 
> key (calc-value key(let [value (get (swap! cache ensure key) key)]  ... 
> do my thing with value ...)
>
>
> So 'ensure' ensures that the cache contains the value for key, the swap! 
> operation returns the cache with the value and then I get it out. This 
> works but feels a little clumsy, is there a better way to do this?
>
> Also, looking at the Atom source code, I see that this will cause a CAS 
> operation even if the value returned from swap! is identical to the 
> original value. It seems like a reasonable optimisation would be to check 
> if the values are identical and not update if so - is there a reason this 
> might not be a good idea?
>
> Thanks,
> 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/d/optout.

[ANN] aprint (awesome print) released

[Daniel]

Looks useful.

-- 
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] om-bootstrap 0.2.6 released

[Daniel]

Good work.  Although I hate to say it, It's of little use for most projects 
without more out-of-the-box table options eg searchable, sortable, 
paginated, never-ending.

On Wednesday, August 27, 2014 2:05:27 PM UTC-5, Sam Ritchie wrote:
>
>  This release adds a bunch of new active components - notably, dropdown 
> buttons, split dropdown buttons and a navbar. The navbar allowed me to beef 
> up the doc site with a proper navbar, more pages and client-side javascript 
> navigation using Secretary and Html5 pushState:
>
> http://om-bootstrap.herokuapp.com 
>
> Code:
>
> https://github.com/racehub/om-bootstrap
>
> Leiningen:
>
> [racehub/om-bootstrap "0.2.6"]
>
>  
>
> RELEASE NOTES:
>
> - Upgraded Clojurescript dependency on the doc site to get around this 
> bug: http://dev.clojure.org/jira/browse/CLJS-839. Added a note.
>
> This hash code bug was causing `bs-class-set`'s internal lookup in 
> `class-map` to sporadically fail in Safari 7.0.x.
>
> >From https://github.com/racehub/om-bootstrap/pull/13:
> - `om-bootstrap.util/clone-with-props` can now "clone" proper om 
> components by injecting extra attributes into the om cursor.
> - `:on-select` handlers on top level nav elements now get called if set, 
> along with the current nav-item `:on-select` handlers
>
> ### New Components
>
> - `dropdown-mixin` (mixins.cljs)
> - `menu-item`, `dropdown-menu`, `dropdown` (button.cljs)
> - `split` (ie, SplitButton) (button.cljs)
> - `navbar` (ie, SplitButton) (button.cljs)
>  
> -- 
> Sam Ritchie (@sritchie)
> Paddleguru Co-Founder
> 703.863.8561
> www.paddleguru.com
> Twitter  // Facebook 
> 
>  

-- 
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] finagle-clojure: Finagle with Clojure!

[Daniel]

Very happy about this!

On Tuesday, September 16, 2014 3:32:16 PM UTC-5, Sam Neubardt wrote:
>
> Announcing finagle-clojure, a Clojure wrapper for Finagle [1]. 
>
> https://github.com/finagle/finagle-clojure 
>
> Finagle is a library open sourced by Twitter for building highly 
> concurrent RPC services on the JVM. With finagle-clojure no explicit 
> interop is required to the underlying Scala implementation of Finagle, 
> though a similar interface is provided. There’s a quick start guide 
> describing how to create a new finagle-clojure project using Thrift as 
> the transport protocol [2]. 
>
> I’ll be speaking about finagle-clojure at Strange Loop on Thursday [3]. 
> A recording of the talk should be posted a few days later. 
>
> I’ve had finagle-clojure services running in production since January 
> with great success. Finagle itself is fast and reliable, I’m excited 
> to offer it’s power to Clojure programmers as well. 
>
> Let me know if you have any questions or want to get involved! 
>
> sam 
> @samn 
>
> [1] https://twitter.github.io/finagle/ 
> [2] 
> https://github.com/finagle/finagle-clojure/blob/master/doc/quick-start.md 
> [3] 
> https://thestrangeloop.com/sessions/highly-concurrent-services-with-finagle-clojure
>  
>

-- 
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] om-bootstrap 0.2.6 released

[Daniel]

I could have said that in a slightly less vitriolic way.  Apologies.

On Tuesday, September 16, 2014 8:45:37 AM UTC-5, Sam Ritchie wrote:
>
> I fully agree that with more features, the library would be useful to a 
> larger range of folks :) Pull requests welcome, as always.
>
> I'm developing each component as needed as I convert paddleguru.com over 
> to Om. The input components and basic tables, panels, buttons and navbars 
> came first; the rest are on their way.
>
> My thought on open source is, document well and release early. There's no 
> reason to keep all the existing stuff closed because the tables module 
> isn't fully sexed out.
>
>   Daniel 
>  September 16, 2014 at 7:17 AM
> Good work.  Although I hate to say it, It's of little use for most 
> projects without more out-of-the-box table options eg searchable, sortable, 
> paginated, never-ending.
>
> On Wednesday, August 27, 2014 2:05:27 PM UTC-5, Sam Ritchie wrote:
> -- 
> 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.
>   Sam Ritchie 
>  August 27, 2014 at 1:05 PM
>  This release adds a bunch of new active components - notably, dropdown 
> buttons, split dropdown buttons and a navbar. The navbar allowed me to beef 
> up the doc site with a proper navbar, more pages and client-side javascript 
> navigation using Secretary and Html5 pushState:
>
> http://om-bootstrap.herokuapp.com 
>
> Code:
>
> https://github.com/racehub/om-bootstrap
>
> Leiningen:
>
> [racehub/om-bootstrap "0.2.6"]
>  
>
> RELEASE NOTES:
>
> - Upgraded Clojurescript dependency on the doc site to get around this 
> bug: http://dev.clojure.org/jira/browse/CLJS-839. Added a note.
>
> This hash code bug was causing `bs-class-set`'s internal lookup in 
> `class-map` to sporadically fail in Safari 7.0.x.
>
> >From https://github.com/racehub/om-bootstrap/pull/13:
> - `om-bootstrap.util/clone-with-props` can now "clone" proper om 
> components by injecting extra attributes into the om cursor.
> - `:on-select` handlers on top level nav elements now get called if set, 
> along with the current nav-item `:on-select` handlers
>
> ### New Components
>
> - `dropdown-mixin` (mixins.cljs)
> - `menu-item`, `dropdown-menu`, `dropdown` (button.cljs)
> - `split` (ie, SplitButton) (button.cljs)
> - `navbar` (ie, SplitButton) (button.cljs)
>  
>  
>
> -- 
> Sam Ritchie (@sritchie)
> Paddleguru Co-Founder
> 703.863.8561
> www.paddleguru.com
> Twitter <http://twitter.com/paddleguru> // Facebook 
> <http://facebook.com/paddleguru>
>  

-- 
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]: clojure.jdbc 0.3.0 - A jdbc library for clojure (previously clj.jdbc)

[Daniel]

+1 for changing the name to something which people won't confuse with the 
"blessed" library.

On Saturday, October 11, 2014 3:39:43 PM UTC-5, James Reeves wrote:
>
> The name of this library is *really* close to the "clojure.java.jdbc" 
> contrib library. You may want to consider changing the name so people don't 
> get confused.
>
> - James
>
> On 11 October 2014 21:01, Andrey Antukh > 
> wrote:
>
>> A JDBC library for clojure.
>>
>> Previously: clj.jdbc
>>
>> Summary of changes from 0.2.2 to 0.3.0:
>>
>> - Minor code reorganization (split protocols from implementation)
>> - Normalize connection pool parameters make them more plugable.
>> - Type hints for almost all code.
>> - Documentation improvements.
>>
>> Summary of changes from clj.jdbc 0.1.1 to clojure.jdbc 0.2.2:
>>
>> - Human readable dbspec format.
>> - Read only connections.
>> - Allow specify schema to connection.
>> - Add `query-first` helper.
>> - Bug fixes.
>>
>> Changelog: 
>> https://raw.githubusercontent.com/niwibe/clojure.jdbc/master/CHANGES.txt
>> Github project: https://github.com/niwibe/clojure.jdbc
>> Documentation: http://niwibe.github.io/clojure.jdbc/
>>
>> Greetings
>> Andrey
>>
>> -- 
>> Andrey Antukh - Андрей Антух - > 
>> / >
>> http://www.niwi.be 
>> https://github.com/niwibe
>>  
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

[Daniel]

To their a wrench in the works, "keywords are functions that look themselves up 
in a map".  Therefore, a traditional map is just as much api as data, and map 
values can be functions too, blurring the lines between static and computed 
values. So, you know, have fun with that.

-- 
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: extending custom data types to clojure core abstractions

[Daniel]

Brian, this may help: https://github.com/ztellman/collection-check

On Tuesday, October 28, 2014 2:24:48 PM UTC-5, Brian Craft wrote:
>
> Following up on the thread about the massive overhead of String, I tried 
> writing a string collection type that stores strings as bytes, converting 
> to String on-demand. It seems to work. Memory footprint and performance are 
> good for the application.
>
> The hard part was trying to track down the correct interfaces and 
> invocations. I note that "Clojure Programming" makes the same observation 
> in the section about clojure abstractions: "such things are largely 
> undocumented". I guess this situation hasn't improved? I had to proceed 
> mostly by experimentation, and am still unclear on, for example, why I 
> needed to use an interop call in some places (like cons), but should not in 
> others.
>
> Would be happy for any feedback on this attempt:
>
> (deftype StringVec [pv]
>   clojure.lang.IPersistentVector
>   (seq [self] (map #(String. ^bytes %) pv))
>   (nth [self i] (String. ^bytes (.nth ^clojure.lang.IPersistentVector pv 
> i)))
>   (nth [self i notfound] (String. ^bytes (.nth 
> ^clojure.lang.IPersistentVector pv i (.getBytes ^String notfound
>   clojure.lang.ILookup
>   (valAt [self i] (when-let [res (.valAt ^clojure.lang.IPersistentVector 
> pv i)]
> (String. ^bytes res)))
>   (valAt [self i notfound] (String. ^bytes (.valAt 
> ^clojure.lang.IPersistentVector pv i (.getBytes ^String notfound
>   clojure.lang.ISeq
>   (first [self] (String. ^bytes (first pv)))
>   (next [self] (->StringVec (next pv)))
>   (more [self] (->StringVec (rest pv)))
>   (cons [self s] (->StringVec (.cons ^clojure.lang.IPersistentVector pv 
> (.getBytes ^String s
>   (count [self] (count pv))
>   Object
>   (toString [self] (str (into [] self
>
> (defn stringvec [coll]
>   (into (->StringVec []) coll))
>
> (defmethod print-method StringVec [v, ^java.io.Writer w]
>   (.write w (.toString ^StringVec v)))
>
> Speak of cons, I gather ISeq cons is unrelated to cons, the function, but 
> rather is required for conj?
>
>

-- 
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: lazy-seq performance

[Daniel]

The first thing that jumps out at me are the boxed numbers: 0N and 1N.  I'm 
guessing the Clojure implementation can produce a much larger result than 
the python implementation can - so, apples to oranges.  Probably unbox the 
numbers and you get much more comparable speed.

Also, you should definitely do two things when running speed comparisons:

1. Make sure the JVM flag -server is configured.
2. Test with Criterium.  (https://github.com/hugoduncan/criterium)

On Wednesday, December 31, 2014 2:03:03 PM UTC-6, Sakis K wrote:
>
> Hi,
>
> Clojure newbie here :) I'm reading "Programming Clojure" by Halloway and 
> Bedra. In the book there is a lazy-seq example of the Fibonacci sequence:
>
> (defn lazy-seq-fibo
>   ([]
>  (concat [0 1] (lazy-seq-fibo 0N 1N)))
>   ([a b]
>  (let [n (+ a b)]  
>(lazy-seq   
> (cons n (lazy-seq-fibo b n))
>
>
> I like the flexibility of this implementation but I am a bit sceptical 
> about its performance:
>
> user=> (time (rem (nth (lazy-seq-fibo) 100) 1000))
> "Elapsed time: 53552.014713 msecs"
> 875N
>
>
>
> Here's a Python implementation taken from 
> http://en.literateprograms.org/Fibonacci_numbers_%28Python%29
>
> def fib(n):
> a, b = 0, 1
> for i in range(n):
> a, b = b, a + b
> return a
>
> if __name__ == '__main__':
> print(fib(100) % 1000)
>
>
> time python fib.py 
> 875
>
> real0m16.609s
> user0m16.475s
> sys 0m0.115s
>
>
> 53 vs 17 seconds is a big gap. Is there a way to achieve better 
> performance in Clojure? Maybe the fact that I executed the code in the REPL 
> or the Java version that I'm using matters:
> java -version
> java version "1.7.0_65"
> OpenJDK Runtime Environment (IcedTea 2.5.3) (7u71-2.5.3-0ubuntu1)
> OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
>
>

-- 
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: clojure.spec

[Daniel]

I'd love to see a blog which shows an example app leveraging core.typed, 
clojure.spec, and core.contracts to gradually provide greater confidence in 
a codebase.  Sort of a step-by-step.

On Monday, May 23, 2016 at 9:12:29 AM UTC-5, Rich Hickey wrote:
>
> Introducing clojure.spec 
>
> I'm happy to introduce today clojure.spec, a new core library and support 
> for data and function specifications in Clojure. 
>
> Better communication 
>
> Clojure is a dynamic language, and thus far we have relied on 
> documentation or external libraries to explain the use and behavior of 
> functions and libraries. But documentation is difficult to produce, is 
> frequently not maintained, cannot be automatically checked and varies 
> greatly in quality. Specs are expressive and precise. Including spec in 
> Clojure creates a lingua franca with which we can state how our programs 
> work and how to use them. 
>
> More leverage and power 
>
> A key advantage of specifications over documentation is the leverage they 
> provide. In particular, specs can be utilized by programs in ways that docs 
> cannot. Defining specs takes effort, and spec aims to maximize the return 
> you get from making that effort. spec gives you tools for leveraging specs 
> in documentation, validation, error reporting, destructuring, 
> instrumentation, test-data generation and generative testing. 
>
> Improved developer experience 
>
> Error messages from macros are a perennial challenge for new (and 
> experienced) users of Clojure. specs can be used to conform data in macros 
> instead of using a custom parser. And Clojure's macro expansion will 
> automatically use specs, when present, to explain errors to users. This 
> should result in a greatly improved experience for users when errors occur. 
>
> More robust software 
>
> Clojure has always been about simplifying the development of robust 
> software. In all languages, dynamic or not, tests are essential to quality 
> - too many critical properties are not captured by common type systems. 
> spec has been designed from the ground up to directly support generative 
> testing via test.check https://github.com/clojure/test.check. When you 
> use spec you get generative tests for free. 
>
> Taken together, I think the features of spec demonstrate the ongoing 
> advantages of a powerful dynamic language like Clojure for building robust 
> software - superior expressivity, instrumentation-enhanced REPL-driven 
> development, sophisticated testing and more flexible systems. I encourage 
> you to read the spec rationale and overview  http://clojure.org/about/spec. 
> Look for spec's inclusion in the next alpha release of Clojure, within a 
> day or so. 
>
> Note that spec is still alpha, and some details are likely to change. 
> Feedback welcome. 
>
> I hope you find spec useful and powerful! 
>
> Rich 
>
>

-- 
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: clojure.spec

[Daniel]

I'd love to see a blog which shows an example app leveraging core.typed, 
clojure.spec, and core.contracts to gradually provide greater confidence in 
a codebase.  Sort of a step-by-step with best practices.

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

spec performance comparison

[Daniel]

Awesome! Would be interesting to see other metrics charted eg loc, memory.

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

spec performance comparison

[Daniel]

Awesome! Would be interesting to see other metrics charted eg loc, memory.

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

spec performance comparison

[Daniel]

Awesome! Would be interesting to see other metrics charted eg loc, memory.

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

Re: Java like static typing for Clojure?

[Daniel]

Just curious... What do you think the primary contributing factor is for 
Cursive's NPEs? Java interop?

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

Re: Java like static typing for Clojure?

[Daniel]

> In this sort of situation, a static type system which provides universal 
> guarantees (this value can never be null) is more useful than a contract 
> system (no null values have been seen yet for the test inputs you've tried). 
> There's simply no way I can test all combinations, or reproduce all 
> combinations that users might have running.

Isn't a major selling point of generative testing was that it creates loads of 
unique cases you can't invent on your own?

You don't trust it to do that? Is that from personal experience?  Genuinely 
curious because I am a little excited about using it in a project at work but 
this is disheartening.

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

Re: Java like static typing for Clojure?

[Daniel]

> In this sort of situation, a static type system which provides universal 
> guarantees (this value can never be null) is more useful than a contract 
> system (no null values have been seen yet for the test inputs you've tried). 
> There's simply no way I can test all combinations, or reproduce all 
> combinations that users might have running.

Isn't a major selling point of generative testing to create loads of unique 
cases you can't invent on your own?

You don't trust it to do that? Is that from personal experience?  Genuinely 
curious because I am a little excited about using it in a project at work but 
this is disheartening.

-- 
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] lein-codeindex 0.1.0 - Easy code indexing and referencing for Emacs, Vim and other editors

[Daniel]

What is the benefit of tags over cider's go to definition functionality or docs 
functionality?

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

[Daniel]

For someone who is new to clojurescript and pretty confused by 
clojurescript dependency management in general, does this release obsolete 
cljsjs for new projects and what is the new method?

On Friday, July 28, 2017 at 4:55:04 PM UTC-5, David Nolen wrote:
>
> ClojureScript, the Clojure compiler that emits JavaScript source code.
>
> README and source code: https://github.com/clojure/clojurescript
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "1.9.854"]
>
> This is a significant feature release. Notable new features include
> comprehensive NPM dependency support, overhauled code splitting,
> enhanced JavaScript module preprocessing, declared global exports for
> foreign libs, and checked array operations. There are also a large
> number of fixes, changes, and minor enhancementes. For more detailed
> descriptions of the major enhancements, please refer to the last month
> of posts https://clojurescript.org/news/news.
>
> As always, feedback welcome!
>
> ## 1.9.854
>
> ### Enhancements
> * CLJS-2280: Provide process.env :preload and auto-configure
> * CLJS-2279: Infer `:module-type ` for provided `node_modules`
> * CLJS-2250: Support :foreign-libs overrides via :provides
> * CLJS-2243: Self-host: Add support for :global-exports
> * CLJS-2232: Self-host: Add support for string-based requires
> * add *print-fn-bodies* knob, set to false
> * CLJS-2198: Safe array operations
> * CLJS-2217: Support `:rename` for JS modules
> * CLJS-2214: Support :global-exports for foreign libraries
> * CLJS-1428: Add a cljs.core/*command-line-args* var
> * CLJS-2061: Support ns :require for JS libs, allow strings along with 
> symbol
> * CLJS-2148: Add warnings for invalid use of aget and aset
> * CLJS-2143: Add support for symbol preprocess values
>
> ### Changes
> * CLJS-2273: Bump tools.reader to 1.0.3 and development dependencies
> * CLJS-2235: Allow passing extra maven opts to build scripts
> * CLJS-2267: Allow ^:const inlined vars to affect if emission
> * CLJS-2245: Add support for using a local `node_modules` installation 
> through a new `:node-modules` compiler flag
> * CLJS-2002: Don't throw when no *print-fn* is set
> * support Clojure primitive array type hints, core.async no longer
>   gives warnings
> * CLJS-2213: Node.js target should use node_modules index to emit platform 
> specific require
> * CLJS-2200: bump to tools.reader 1.0.2
> * CLJS-2135: require macro prints last result of loaded-libs
> * CLJS-2192: Add ChakraCore testing facilities
> * CLJS-1800: Defer to tools.reader for cljs.reader functionality
> * CLJS-2163: Clean up uses of aget / aset on objects
> * CLJS-2184: Add `ns-publics` and `ns-imports`
> * CLJS-2183: Assert arguments are quoted symbols in some core macros
> * CLJS-2182: Assert argument to resolve is a quoted symbol
> * CLJS-2186: Update docstrings for aget/aset to be consistent with Clojure
> * CLJS-2180: Allow compiling `:modules` with whitespace optimizations
> * CLJS-1822: Use `:file-min` when processing JS modules with advanced 
> optimizations
> * CLJS-2169: Error when compiling with :source-map and advanced 
> optimizations
> * CLJS-2037: Throw if overwriting alias in current namespace
> * CLJS-2160: Add loaded? and prefetch functions to cljs.loader
> * CLJS-2148: Add unsafe-get and use goog.object
> * CLJS-2161: Bump Closure Compiler to June 2017 release
>
> ### Fixes
> * CLJS-1854: Self-host: Reload ns with const
> * CLJS-2278: JavaScript object literals are printed wth keys that cannot 
> be read
> * CLJS-2276: Self-host: Need test.check dep for CLJS-2275
> * CLJS-2275: cljs.spec.alpha/fdef resolves eagerly
> * CLJS-2259: Extra .cljs_node_repl directory containing cljs.core output
> * CLJS-2274: Update CI script to install deps
> * CLJS-2269: Warn on top level code split loads
> * CLJS-2272: Tests that depended on default install deps behavior failing
> * CLJS-2255: Clean up :npm-deps
> * CLJS-2263: Docstring for neg-int? backwards
> * CLJS-2262: Correct comment that *warn-on-infer* is file-scope
> * CLJS-2258: Stack overflow regression for sequence xform applied to 
> eduction
> * CLJS-2256: Generated code doesn't add newline after sourceMappingURL 
> comment
> * CLJS-2254: Module Indexing: Provide relative paths for a package's main 
> module
> * CLJS-2248: Build API tests rely on Yarn
> * CLJS-2239: Self-host: Add `:target :nodejs` to the docstrings in cljs.js
> * CLJS-2251: Follow-up fix to CLJS-2249 and related commit
> * CLJS-2249: Provide a test for d4b871cce73
> * CLJS-2246: Revert CLJS-2245 and CLJS-2240 and fix `lein test`
> * CLJS-2244: Orphaned processed JS modules breaks :modules
> * CLJS-2242: Lots of undeclared Var warns in cljs.spec.gen.alpha
> * CLJS-2241: Multiple requires of Node.js modules in non :nodejs target 
> are not idempotent at the REPL
> * CLJS-2229: Ensure that new modules work works correctly with REPLs
> * CLJS-2238: Perf regression with node module indexing
> * CLJS-2240: don't shell out to module_deps.js if `:npm-deps` n

Couplet 0.1.0 – Unicode code points support for Clojure

[Daniel]

Nice!

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

Code behaves differently when evaluated

[Daniel]

Apologies for the poor subject header.  Link to the Github Issue here. 


I'm running this code at the repl (pulse.core is my project ns)
pulse.core=> ((-> db/queries :fns :orders-test :fn) db/*conn*)

db/queries
is a map defined by HugSQL & *conn* is a database connection.  The code is 
querying a database using HugSQL.


If I run the code normally it will throw a NullPointerException, but if I 
first evaluate the HugSQL core namespace (for debugging in Cider) it works 
fine.

I've never seen anything like this before.  Does anyone have any ideas 
about how to proceed troubleshooting this issue, because right now I am out 
of ideas.

My project.clj (for versions and such)j:

(defproject pulse "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :url "http://example.com/FIXME";
  :license {:name "Eclipse Public License"
:url "http://www.eclipse.org/legal/epl-v10.html"}
  :dependencies [[org.clojure/clojure "1.8.0"]
 [com.layerware/hugsql "0.4.8"]
 [conman "0.6.9" :exclusions [com.layerware/hugsql]]
 ;; [net.sourceforge.jtds/jtds "1.3.1"]
 [com.microsoft.sqlserver/mssql-jdbc "6.2.2.jre8"]
 [mount "0.1.11"]
 [clj-time "0.14.0"]
 [cprop "0.1.11"]
 [camel-snake-kebab "0.4.0"]
 [org.clojure/data.xml "0.0.8"]
 [org.clojure/data.zip "0.1.2"]
 ;; logging
 [ch.qos.logback/logback-classic "1.2.3"]
 [ch.qos.logback/logback-core "1.2.3"]
 [org.clojure/tools.logging "0.4.0"]
 [org.slf4j/slf4j-api "1.7.25"]]
  :main ^:skip-aot pulse.core
  :target-path "target/%s"
  :profiles {:uberjar {:aot :all}})



-- 
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: Code behaves differently when evaluated

[Daniel]

Resolved this particular issue.  It seems that evaluating the Hugsql core 
namespace 'overwrote' some multimethods I had defined which were somehow 
causing the real issue.

On Wednesday, October 25, 2017 at 4:09:02 PM UTC-5, Daniel wrote:
>
> Apologies for the poor subject header.  Link to the Github Issue here. 
> <https://github.com/layerware/hugsql/issues/74#issuecomment-339373610>
>
> I'm running this code at the repl (pulse.core is my project ns)
> pulse.core=> ((-> db/queries :fns :orders-test :fn) db/*conn*)
>
> db/queries
> is a map defined by HugSQL & *conn* is a database connection.  The code is 
> querying a database using HugSQL.
>
>
> If I run the code normally it will throw a NullPointerException, but if I 
> first evaluate the HugSQL core namespace (for debugging in Cider) it works 
> fine.
>
> I've never seen anything like this before.  Does anyone have any ideas 
> about how to proceed troubleshooting this issue, because right now I am out 
> of ideas.
>
> My project.clj (for versions and such)j:
>
> (defproject pulse "0.1.0-SNAPSHOT"
>   :description "FIXME: write description"
>   :url "http://example.com/FIXME";
>   :license {:name "Eclipse Public License"
> :url "http://www.eclipse.org/legal/epl-v10.html"}
>   :dependencies [[org.clojure/clojure "1.8.0"]
>  [com.layerware/hugsql "0.4.8"]
>  [conman "0.6.9" :exclusions [com.layerware/hugsql]]
>  ;; [net.sourceforge.jtds/jtds "1.3.1"]
>  [com.microsoft.sqlserver/mssql-jdbc "6.2.2.jre8"]
>  [mount "0.1.11"]
>  [clj-time "0.14.0"]
>  [cprop "0.1.11"]
>  [camel-snake-kebab "0.4.0"]
>  [org.clojure/data.xml "0.0.8"]
>  [org.clojure/data.zip "0.1.2"]
>  ;; logging
>  [ch.qos.logback/logback-classic "1.2.3"]
>  [ch.qos.logback/logback-core "1.2.3"]
>  [org.clojure/tools.logging "0.4.0"]
>  [org.slf4j/slf4j-api "1.7.25"]]
>   :main ^:skip-aot pulse.core
>   :target-path "target/%s"
>   :profiles {:uberjar {:aot :all}})
>
>
>
>

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

Loop causing OutOfMemoryError: GC overhead limit exceeded ?

[Daniel]

This code looks fine. You don't need the atoms, but I don't think that's your 
trouble.

How do you know this code is causing the error? Unless this is all your code 
does, descriptions of the error suggest the memory leak might be coming from 
anywhere. This tight loop might trigger too many successive GCs though: have 
you observed if the error only occurs under load, or under large time 
intervals? Some combination?

Maybe running without -server so the GC will behave less aggressively?

-- 
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: Why does the `def-` not exist?

[Daniel]

"University me" is yelling incredulously in my ear for saying this, but ... I 
have no use for private vars and private functions anymore. When that voice 
persuades me to evaluate a namespace for visibility I always feel like I'm 
over-engineering.

-- 
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: Why does the `def-` not exist?

[Daniel]

I'm not advocating for it's removal though. That would be silly.

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

Re: How to visualise relations, bahavior and so on in functional programming ?

[Daniel]

system-vis  is a start - it will 
inform you about the order of _state_ setup and teardown, and by virtue of 
that, dependencies.

On Sunday, March 4, 2018 at 10:28:41 AM UTC-6, Dmitry Fomin wrote:
>
> Hello from future! :)
>
> I just wonder have you managed to find good tooling for this?
>
> Imho for FP there is still only suitable diagram notation is good old 
> IDEF0  
>
> On Tuesday, 11 May 2010 11:18:18 UTC+3, Donell Jones wrote:
>>
>> Hi Team, 
>> I am really interested in functional programming. But I am asking 
>> myself, what if the project get bigger, like the software Runa realise 
>> with Clojure. In OOP we got diagrams like UML to visualise this. But 
>> what can we do in FP ? Are there any diagrams that can be used to 
>> explain things ? 
>>
>> I think this is very important when it comes to documentation. 
>>
>> Thanks for your help! 
>>
>> -- 
>> You received this message because you are subscribed to the Google 
>> Groups "Clojure" group. 
>> To post to this group, send email to clo...@googlegroups.com 
>> Note that posts from new members are moderated - please be patient with 
>> your first post. 
>> To unsubscribe from this group, send email to 
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at 
>> http://groups.google.com/group/clojure?hl=en
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To 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: Comparing and selecting web API libraries

[Daniel]

Yogthos has done an excellent job with luminus-template 
(https://github.com/luminus-framework/luminus-template).

Sets everything up how I would. Usually just need + +jetty +reagent (if 
writing a SPA) +auth (if doing user accounts).

So far it's been a good diving board. I'm on my second in-house project and 
have been able to incorporate everything so far ... I think because it's fairly 
unopinionated.

-- 
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: What is the minimal Emacs config for practical Clojure development?

[Daniel]

Luminus has a leiningen template which works out-of-the-box with Cider and 
figwheel. Just (start-fw) and (cljs) inside the repl.

It would be nice if we could have both repls open simultaneously within emacs, 
but everything was super unreliable the last time I tried that.

-- 
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: Clojure(Script) web apps in 2018

[Daniel]

Having built a couple of apps with Luminus (including a SPA), my vote 
definitely goes there.  I've even been able to cherry-pick functions and 
project organization from the leiningen template and inject them into a cli 
app which had a server component.  Extremely well organized and 
documented.  Easy to get started.  You'll get a tour of the entire 
ecosystem too - it's the only option IMO which gives you experience with 
all the popular ring-based libraries.

-- 
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] Clojure 1.10.0-RC1 (please test!)

[Daniel]

Congrats!

Small suggestion.  Under dependency updates it would be helpful to see the 
previous version eg

"spec.alpha dependency to 0.2.176" -> "spec.alpha dependency from X.X.XXX 
to 0.2.176"


On Thursday, October 11, 2018 at 10:11:45 AM UTC-5, Alex Miller wrote:
>
> 1.10.0-RC1 is now available. You can try it with clj using:
>
>   clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version 
> "1.10.0-RC1"}}}'
>
> 1.10.0-RC1 is the same code as beta2 (only change are some changelog 
> fixes). 
> You can read the full 1.10 changelog here: 
> https://github.com/clojure/clojure/blob/master/changes.md
>
> *Note: This is a release candidate! Please try this release candidate with 
> your project and provide feedback (both whether it works as expected and 
> any issues).* If there are issues we will assess, otherwise we intend to 
> move towards a final release of 1.10. 
>
>
>

-- 
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: (float 0.819869321599107) = 0.81986934 ?

[Daniel]

If you want more precise rounding to the 8th decimal then with-precision is 
available for BigDecimals. The literal representation will look just like the 
float you wanted.

-- 
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: Silly ns question

[Daniel]

Weird. Also I thought your file name would need an underscore.

-- 
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] gooff, A KISS scheduling library inspired by Snooze

[Daniel]

gooff is a scheduling library focused on simplicity and based on Snooze. 


It's been in development for only 5 days, boasts a single namespace and 
just 600 lines.  It's in need of some some tests and I'll accept 
contributions the usual way.  Hope someone finds it useful!

https://clojars.org/gooff

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/f01a2844-7bc5-480c-8af0-4c7990afe9d3%40googlegroups.com.

Re: Scripting with Clojure / "slow" boot time

[Daniel]

Aside from the survey results, is it fair to say that more developers would be 
interested in Clojure on Android if they could use the blessed compiler? Are 
there any plans to look into the changes in project Skummet or breaking up the 
core namespace (like dunaj experimented with)?

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

conditional logic implemented as pattern-matching and restructuring in the signature of the function

[Daniel]

Check out defun. I believe it does exactly what you want. Admittedly I'm not 
aware of its current state. https://github.com/killme2008/defun

-- 
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: Clojure as first language

[Daniel]

> I heard feedback about a guy who learned to program in Clojure and found 
> Python pretty messed up afterwards.

If love to read this if you can dig up a link.

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

find shorter clojure code automatically

[Daniel]

You might want to check out this blog. 
http://blog.mattgauger.com/blog/2014/09/15/clojure-code-quality-tools/

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

changes in logging in 1.8?

[Daniel]

Something in profiles.clj causing the application to be evaluated?

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