Re: Extracting a database schema and using it to synthesize and check SQL queries at compile time

[Shantanu Kumar]

Hi Alex,

On Wednesday, 8 January 2014 13:28:29 UTC+5:30, Alexander Hudek wrote:
>
> Hey everyone,
>
> We've been exploring ways to make working with database code more 
> efficient and less error prone.
> For complex queries, we prefer working directly with SQL. However, like 
> for many others, a lot of our 
> queries are very simple and repetitive. For example, retrieving or 
> updating single rows, or a set of rows 
> based on a foreign key. 
>

I totally agree with this. I have noticed this is the most common scenario 
when working with SQL databases.
 

>
> As an experiment, we wrote a prototype that uses the information_schema 
> standard to automatically 
> extract the schema from a database and represent it as clojure code at 
> compile time. With this, we 
> were able to synthesize some simple SQL queries. The interesting part of 
> this is that the code generator
> automatically picks up primary key constraints and also performs 
> validation on table and column names.
> All of this is done at compile time. Errors are caught early and the 
> compiled code uses clojure.java.jdbc
> prepared statements. You can find the code and demo here:
>
> https://github.com/diligenceengine/edl
>
> I'm personally not a big fan of huge ORM systems, so I don't know where to 
> go with this, if anywhere.
> Though it seems useful for building small macros for common patterns we 
> have. 
>
> Would love to hear if anyone has thoughts on the technique.
>

The approach to read the database to generate code is pretty interesting. 
There is a more portable way to extract the schema information, using 
DatabaseMetadata that you can extract from a Connection.

http://docs.oracle.com/javase/7/docs/api/java/sql/DatabaseMetaData.html
http://docs.oracle.com/javase/7/docs/api/java/sql/Connection.html#getMetaData()

Shantanu

-- 
-- 
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: Extracting a database schema and using it to synthesize and check SQL queries at compile time

[Shantanu Kumar]

>
>
> The approach to read the database to generate code is pretty interesting. 
> There is a more portable way to extract the schema information, using 
> DatabaseMetadata that you can extract from a Connection.
>
> http://docs.oracle.com/javase/7/docs/api/java/sql/DatabaseMetaData.html
>
> http://docs.oracle.com/javase/7/docs/api/java/sql/Connection.html#getMetaData()
>

I did some related work quite a while ago: 
https://github.com/kumarshantanu/clj-jdbcutil/blob/master/src/clj_jdbcutil/core.clj#L535

Sharing just in case somebody finds it useful.

Shantanu

-- 
-- 
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: Extracting a database schema and using it to synthesize and check SQL queries at compile time

[Softaddicts]

Hi,

After struggling with Hibernate, SQL dsl, then bare SQL for a couple of years 
we 
took a radical path away from these approaches.

We do not in our world own the database models we are dealing with,
keeping our heads above water (or mud you might say) has become a
survival issue.

So we took the problem the other way around. How can we make the
relational models compliant with our business model ?

We are in the health industry, a patient is a patient, why do we have to 
struggle with the fine prints of each vendor's relational model ?

We implemented and EDN subset library in several SQL db dialects (Oracle, 
mysql, SqlServer support will come out before spring).
Implementing an EDN library is between 250 to 300 lines of SQL code per 
database type so far. It's purely functional and returns a single column
(entity) and a string EDN representation. We just edn/read-string in the code
and we get our business entity. What remains are semantic issues with
the data itself but this already addressed by a component above this in
our product stack.

To avoid writing the views by hand, we created a viewer generator that creates 
according to the db dialect a view returning an EDN representation of the 
business entity as we manipulate it in
the code, not as it is defined in the database.

One view == one business entity.

The generator is db aware through some protocol magic and can handle
different db brands.

The mapping between the db model and our business model is defined
as data. It contains the fields to extract, their types if not strings,
the joins, the selection criterias, the db dialect, 
This defines our business model vs the relational model.

The generator is less than 300 lines of code, entity definitions can be 
between 50 to 200 lines.

Add to this the yesql library to wrap queries now in a single file.

It shrank our sql queries to a ridiculous number per vendor
while pushing away the complexity of the mapping of the relational model 
away from the code as configurable data.

As for inserts, updates, ... views are of no help here but the generator
can bridge the gap by creating sql statements and small field name
translation wrappers from the same definition as the views.

The parameter names we use remain coherent with the business model the 
code uses.
The sql statements to insert, ... are again wrapped by yesql.

Performançe so far is not an issue, we run our product on small boxes
less powerful than our customer's database servers. Shifting the load
on the side of the database server made sense in this regard.

And away from this relational modeling crap. Give the same business domain
entities to ten different DBAs and you will get ten relational models each with
it's own nit picking subtleties.

Luc P.


> Hey everyone,
> 
> We've been exploring ways to make working with database code more efficient 
> and less error prone.
> For complex queries, we prefer working directly with SQL. However, like for 
> many others, a lot of our 
> queries are very simple and repetitive. For example, retrieving or updating 
> single rows, or a set of rows 
> based on a foreign key. 
> 
> As an experiment, we wrote a prototype that uses the information_schema 
> standard to automatically 
> extract the schema from a database and represent it as clojure code at 
> compile time. With this, we 
> were able to synthesize some simple SQL queries. The interesting part of 
> this is that the code generator
> automatically picks up primary key constraints and also performs validation 
> on table and column names.
> All of this is done at compile time. Errors are caught early and the 
> compiled code uses clojure.java.jdbc
> prepared statements. You can find the code and demo here:
> 
> https://github.com/diligenceengine/edl
> 
> I'm personally not a big fan of huge ORM systems, so I don't know where to 
> go with this, if anywhere.
> Though it seems useful for building small macros for common patterns we 
> have. 
> 
> Would love to hear if anyone has thoughts on the technique.
> 
> Alex
> 
> 
> 
> -- 
> -- 
> 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.
> 
--
Softaddicts sent by ibisMail from my ipad!

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojur

[ANN] data.avl 0.0.11 -- transient-enabled sorted maps and sets with nth

[Michał Marczyk]

Hi,

I am pleased to announce that version 0.0.11 of data.avl, a Clojure
Contrib library implementing drop-in replacements for
Clojure(Script)'s core sorted collections, is now available from Maven
Central. See below for more information.

Changes in this release:

 * two bugs squashed in the ClojureScript version;

 * in Clojure, data.avl maps and sets are now properly
   java.io.Serializable;

 * in Clojure, rank-of now returns primitive longs where appropriate.

data.avl's maps and sets are constructed with the
clojure.data.avl/sorted-{map,set} functions and their *-by variants
and behave like their clojure.core counterparts, with the following
differences:

 * support for the transient API;

 * support for efficient rank queries via clojure.core/nth and
   clojure.data.avl/rank-of;

 * superior lookup performance at some cost in assoc/dissoc
   performance.

My original announcement of data.avl 0.0.10 [0] provides additional
details (including some Criterium benchmarks).

Dependency information:

  [org.clojure/data.avl "0.0.11"]

  
org.clojure
data.avl
0.0.11
  

  compile "org.clojure:data.avl:0.0.11"

Project repository and issue tracker:

  https://github.com/clojure/data.avl

  http://dev.clojure.org/jira/browse/DAVL

Cheers,
Michał


[0] https://groups.google.com/d/msg/clojure/8T-Dorhq6xQ/qne94v7Zot0J

-- 
-- 
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: Contributors needed for Rouge (Clojure on Ruby)

[Max Gonzih]

Al this conversation still gives me hope that there is room for clojure on 
bare metal implementation. There is 
https://github.com/halgari/clojure-metal but I'm not sure about its state.

On Saturday, January 4, 2014 5:43:22 PM UTC+3, g vim wrote:
>
> I have recently moved most of my work to Clojure and Clojurescript but 
> neither of these implementations seem suitable for non-http scripting, 
> for which I currently use Ruby. So, you can imagine my elation when I 
> discovered Rouge which is Clojure implemented on Ruby: 
>
> https://github.com/rouge-lang/rouge 
>
> The project looks fantastic but they seem to be short of contributors. 
> My programming skills are nowhere near advanced enough to work on this 
> myself so, please, if any of you Clojurians have proficiency in Ruby and 
> Clojure please consider contributing. 
>
> I looked at Python's Hy (hylang.org) which is an excellent project in 
> its own right and is heavily influenced by Clojure but its taregt is 
> generic Lisp 1 rather than Clojure. Rouge will enable Clojure to occupy 
> the non-http scripting space without competing directly with Clojure and 
> Clojurescript. 
>
> gvim 
>

-- 
-- 
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: Contributors needed for Rouge (Clojure on Ruby)

[Laurent PETIT]

Is it possible that a lot of these projects are waiting for a stronger
blessing of the clojure contrib efforts for analyzers, etc. that is,
waiting for the JVM Clojure in Clojure.


2014/1/8 Max Gonzih 

> Al this conversation still gives me hope that there is room for clojure on
> bare metal implementation. There is
> https://github.com/halgari/clojure-metal but I'm not sure about its state.
>
>
> On Saturday, January 4, 2014 5:43:22 PM UTC+3, g vim wrote:
>>
>> I have recently moved most of my work to Clojure and Clojurescript but
>> neither of these implementations seem suitable for non-http scripting,
>> for which I currently use Ruby. So, you can imagine my elation when I
>> discovered Rouge which is Clojure implemented on Ruby:
>>
>> https://github.com/rouge-lang/rouge
>>
>> The project looks fantastic but they seem to be short of contributors.
>> My programming skills are nowhere near advanced enough to work on this
>> myself so, please, if any of you Clojurians have proficiency in Ruby and
>> Clojure please consider contributing.
>>
>> I looked at Python's Hy (hylang.org) which is an excellent project in
>> its own right and is heavily influenced by Clojure but its taregt is
>> generic Lisp 1 rather than Clojure. Rouge will enable Clojure to occupy
>> the non-http scripting space without competing directly with Clojure and
>> Clojurescript.
>>
>> gvim
>>
>  --
> --
> 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.
>

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

Re: Clojure deployment questions w.r.t. jars, clojure source files, compiled class files

[Dave Tenny]

Excellent answers and I usually find a use for extra wrenches.

I'm still confused about when anybody actually calls the (compile)
function, any more tips here?  Or is it being done for me by leiningen?


On Wed, Jan 8, 2014 at 1:54 AM, Softaddicts wrote:

> To complement my previous post and in relation to this one,
> we use (if-not *compile-file* ...) to wrap expressions that cannot be
> AOT compiied (like loading configuration or connecting to external
> resources which you do not want  to do at compile time but at run time
> only:)
>
> This confused a lot of people in the past trying to use AOT.
> For many the compilation phase and code execution are perceived
> as a single step. When working in the REPL you do not need to be aware of
> this. With AOT it's important to be aware of the difference when writing
> code
> in dev.
>
> Luc P.
>
>
> > On Tue, Jan 7, 2014 at 4:26 PM, Dave Tenny  wrote:
> > > 1) When and under what circumstances projects are compiled in  source
> versus
> > > .class form?
> >
> > Most Clojure projects ship in source form (and are therefore compiled
> > to bytecode on demand as they are loaded).
> >
> > > 2) Why there is no project.clj in the org.clojure jar file?
> >
> > It's built with Maven. As are most of the Clojure contrib libraries
> > too, although some are now starting to sport project.clj files to make
> > local development easier. In the last round of development, I added
> > Leiningen support to clojure.java.jdbc to make it easier to "jack in"
> > with Emacs and test the code. It still uses Maven for primary testing
> > (on build.clojure.org) and packaging - and Clojure plus its contrib
> > libraries are hosted on Maven Central (where they are retrieved
> > primarily by Leiningen into other Clojure projects).
> >
> > > 3) When the clojure 'compile' function comes into play in your typical
> > > clojure project deployments? (vs. :aot targets or other leiningen
> deployment
> > > techniques).
> >
> > At World Singles, we AOT compile very little of our code. We only AOT
> > namespaces that generate Java-compatible classes for situations where
> > we must be natively callable from Java (e.g., we have a log4j appender
> > written in Clojure). Within that AOT-compiled code, we require
> > namespaces and resolve symbols dynamically (at runtime) to bind the
> > Java-called code to the rest of our code base.
> >
> > Part of the reason is for the flexibility that source deployments
> > provide: the ability to REPL into a live, running process and reload
> > code from updated source files without needing to "stop the world",
> > for example.
> >
> > If you're relatively new to Clojure, I'd recommend completely ignoring
> > the whole "compilation" thing unless you specifically need to generate
> > natively callable code for Java to Clojure interop.
> >
> > In case anyone is interested, our pattern for bridging from the
> > AOT-compiled namespace to the rest of the code base tends to look like
> > this:
> >
> > (def the-symbol
> >   (delay
> > (do
> >   (require 'the.namespace)
> >   (resolve (symbol "the.namespace/the-symbol")
> >
> > and then:
> >
> >   ... (@the-symbol arg1 arg2) ...
> >
> > Our AOT-compiled layer is deliberately minimal and serves only to
> > provide the Java-callable API so the rest of our code can be developed
> > and tested in our normal interactive, incremental way.
> > --
> > Sean A Corfield -- (904) 302-SEAN
> > An Architect's View -- http://corfield.org/
> > World Singles, LLC. -- http://worldsingles.com/
> >
> > "Perfection is the enemy of the good."
> > -- Gustave Flaubert, French realist novelist (1821-1880)
> >
> > --
> > --
> > 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.
> >
> --
> Softaddicts sent by ibisMail from my ipad!
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Cl

Re: Contributors needed for Rouge (Clojure on Ruby)

[Max Gonzih]

Probably you are right.

On Wed, Jan 08, 2014 at 11:26:55AM +0100, Laurent PETIT wrote:
> Is it possible that a lot of these projects are waiting for a stronger
> blessing of the clojure contrib efforts for analyzers, etc. that is,
> waiting for the JVM Clojure in Clojure.
>
>
> 2014/1/8 Max Gonzih 
>
> > Al this conversation still gives me hope that there is room for clojure on
> > bare metal implementation. There is
> > https://github.com/halgari/clojure-metal but I'm not sure about its state.
> >
> >
> > On Saturday, January 4, 2014 5:43:22 PM UTC+3, g vim wrote:
> >>
> >> I have recently moved most of my work to Clojure and Clojurescript but
> >> neither of these implementations seem suitable for non-http scripting,
> >> for which I currently use Ruby. So, you can imagine my elation when I
> >> discovered Rouge which is Clojure implemented on Ruby:
> >>
> >> https://github.com/rouge-lang/rouge
> >>
> >> The project looks fantastic but they seem to be short of contributors.
> >> My programming skills are nowhere near advanced enough to work on this
> >> myself so, please, if any of you Clojurians have proficiency in Ruby and
> >> Clojure please consider contributing.
> >>
> >> I looked at Python's Hy (hylang.org) which is an excellent project in
> >> its own right and is heavily influenced by Clojure but its taregt is
> >> generic Lisp 1 rather than Clojure. Rouge will enable Clojure to occupy
> >> the non-http scripting space without competing directly with Clojure and
> >> Clojurescript.
> >>
> >> gvim
> >>
> >  --
> > --
> > 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.
> >
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the Google 
> Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/26X7Bj5_KUQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

--
Best regards,
Max

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

Re: Clojure deployment questions w.r.t. jars, clojure source files, compiled class files

[Softaddicts]

Look at the compile fn at the bottom:

https://github.com/technomancy/leiningen/blob/master/src/leiningen/compile.clj

you will find your answer :)

Luc P.


> Excellent answers and I usually find a use for extra wrenches.
> 
> I'm still confused about when anybody actually calls the (compile)
> function, any more tips here?  Or is it being done for me by leiningen?
> 
> 
> On Wed, Jan 8, 2014 at 1:54 AM, Softaddicts 
> wrote:
> 
> > To complement my previous post and in relation to this one,
> > we use (if-not *compile-file* ...) to wrap expressions that cannot be
> > AOT compiied (like loading configuration or connecting to external
> > resources which you do not want  to do at compile time but at run time
> > only:)
> >
> > This confused a lot of people in the past trying to use AOT.
> > For many the compilation phase and code execution are perceived
> > as a single step. When working in the REPL you do not need to be aware of
> > this. With AOT it's important to be aware of the difference when writing
> > code
> > in dev.
> >
> > Luc P.
> >
> >
> > > On Tue, Jan 7, 2014 at 4:26 PM, Dave Tenny  wrote:
> > > > 1) When and under what circumstances projects are compiled in  source
> > versus
> > > > .class form?
> > >
> > > Most Clojure projects ship in source form (and are therefore compiled
> > > to bytecode on demand as they are loaded).
> > >
> > > > 2) Why there is no project.clj in the org.clojure jar file?
> > >
> > > It's built with Maven. As are most of the Clojure contrib libraries
> > > too, although some are now starting to sport project.clj files to make
> > > local development easier. In the last round of development, I added
> > > Leiningen support to clojure.java.jdbc to make it easier to "jack in"
> > > with Emacs and test the code. It still uses Maven for primary testing
> > > (on build.clojure.org) and packaging - and Clojure plus its contrib
> > > libraries are hosted on Maven Central (where they are retrieved
> > > primarily by Leiningen into other Clojure projects).
> > >
> > > > 3) When the clojure 'compile' function comes into play in your typical
> > > > clojure project deployments? (vs. :aot targets or other leiningen
> > deployment
> > > > techniques).
> > >
> > > At World Singles, we AOT compile very little of our code. We only AOT
> > > namespaces that generate Java-compatible classes for situations where
> > > we must be natively callable from Java (e.g., we have a log4j appender
> > > written in Clojure). Within that AOT-compiled code, we require
> > > namespaces and resolve symbols dynamically (at runtime) to bind the
> > > Java-called code to the rest of our code base.
> > >
> > > Part of the reason is for the flexibility that source deployments
> > > provide: the ability to REPL into a live, running process and reload
> > > code from updated source files without needing to "stop the world",
> > > for example.
> > >
> > > If you're relatively new to Clojure, I'd recommend completely ignoring
> > > the whole "compilation" thing unless you specifically need to generate
> > > natively callable code for Java to Clojure interop.
> > >
> > > In case anyone is interested, our pattern for bridging from the
> > > AOT-compiled namespace to the rest of the code base tends to look like
> > > this:
> > >
> > > (def the-symbol
> > >   (delay
> > > (do
> > >   (require 'the.namespace)
> > >   (resolve (symbol "the.namespace/the-symbol")
> > >
> > > and then:
> > >
> > >   ... (@the-symbol arg1 arg2) ...
> > >
> > > Our AOT-compiled layer is deliberately minimal and serves only to
> > > provide the Java-callable API so the rest of our code can be developed
> > > and tested in our normal interactive, incremental way.
> > > --
> > > Sean A Corfield -- (904) 302-SEAN
> > > An Architect's View -- http://corfield.org/
> > > World Singles, LLC. -- http://worldsingles.com/
> > >
> > > "Perfection is the enemy of the good."
> > > -- Gustave Flaubert, French realist novelist (1821-1880)
> > >
> > > --
> > > --
> > > 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.
> > >
> > --
> > Softaddicts sent by ibisMail from my ipad!
> >
> > --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to

Re: Contributors needed for Rouge (Clojure on Ruby)

[Mikera]

Cool link, thanks! Yet another clever tool.

The JVM isn't really the problem though, at least as far as I can work out. 
In fact I think the whole "JVM startup is slow" thing is a bit of a myth: 
JVM startup including running a simple "hello world" is less than 0.1 secs 
on my machine. Obviously not as quick as native compiled code, but "good 
enough" for typical command line usage.

I'm pretty sure that loading a big dependency graph of clojure.core + 
require'd Clojure libraries is the real startup time culprit for most 
Clojure apps (which gives me hope, since it means there is still potential 
for significant improvements, either via pre-compilation, lazy loading of 
namespaces, concurrent loading or general compiler/reader optimisations)

On Monday, 6 January 2014 04:14:20 UTC, john walker wrote:
>
> If boot time is your primary concern, this can help. The jvm is still 
> there, though :/ 
>
> https://github.com/technomancy/grenchman
>
>
> On Saturday, January 4, 2014 9:43:22 AM UTC-5, g vim wrote:
>>
>> I have recently moved most of my work to Clojure and Clojurescript but 
>> neither of these implementations seem suitable for non-http scripting, 
>> for which I currently use Ruby. So, you can imagine my elation when I 
>> discovered Rouge which is Clojure implemented on Ruby: 
>>
>> https://github.com/rouge-lang/rouge 
>>
>> The project looks fantastic but they seem to be short of contributors. 
>> My programming skills are nowhere near advanced enough to work on this 
>> myself so, please, if any of you Clojurians have proficiency in Ruby and 
>> Clojure please consider contributing. 
>>
>> I looked at Python's Hy (hylang.org) which is an excellent project in 
>> its own right and is heavily influenced by Clojure but its taregt is 
>> generic Lisp 1 rather than Clojure. Rouge will enable Clojure to occupy 
>> the non-http scripting space without competing directly with Clojure and 
>> Clojurescript. 
>>
>> gvim 
>>
>

-- 
-- 
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: Contributors needed for Rouge (Clojure on Ruby)

[Laurent PETIT]

2014/1/8 Mikera 

> Cool link, thanks! Yet another clever tool.
>
> The JVM isn't really the problem though, at least as far as I can work
> out. In fact I think the whole "JVM startup is slow" thing is a bit of a
> myth: JVM startup including running a simple "hello world" is less than 0.1
> secs on my machine. Obviously not as quick as native compiled code, but
> "good enough" for typical command line usage.
>
> I'm pretty sure that loading a big dependency graph of clojure.core +
> require'd Clojure libraries is the real startup time culprit for most
> Clojure apps (which gives me hope, since it means there is still potential
> for significant improvements, either via pre-compilation, lazy loading of
> namespaces, concurrent loading or general compiler/reader optimisations)
>

As far as I can remember, Rich had made some experiments, at some point in
time, wrt lazy compilation of fns. Meaning that you still had the linear
time eagerly skimming all your app's dependency namespaces at startup, but
at least, the work done eagerly was just defining vars, and executing top
level code (including macros).

AFAICT at some point he decided to revert back, but I don't remember the
exact reason (something like : nobody reported feedback, and we were close
to a clojure release, so it was not interesting to pursue this goal at that
time).

One can probably still find relevant commits in Git revisions, as well as
traces of the discussion in the mailing list archives.

Cheers,

-- 
Laurent


>
>
> On Monday, 6 January 2014 04:14:20 UTC, john walker wrote:
>>
>> If boot time is your primary concern, this can help. The jvm is still
>> there, though :/
>>
>> https://github.com/technomancy/grenchman
>>
>>
>> On Saturday, January 4, 2014 9:43:22 AM UTC-5, g vim wrote:
>>>
>>> I have recently moved most of my work to Clojure and Clojurescript but
>>> neither of these implementations seem suitable for non-http scripting,
>>> for which I currently use Ruby. So, you can imagine my elation when I
>>> discovered Rouge which is Clojure implemented on Ruby:
>>>
>>> https://github.com/rouge-lang/rouge
>>>
>>> The project looks fantastic but they seem to be short of contributors.
>>> My programming skills are nowhere near advanced enough to work on this
>>> myself so, please, if any of you Clojurians have proficiency in Ruby and
>>> Clojure please consider contributing.
>>>
>>> I looked at Python's Hy (hylang.org) which is an excellent project in
>>> its own right and is heavily influenced by Clojure but its taregt is
>>> generic Lisp 1 rather than Clojure. Rouge will enable Clojure to occupy
>>> the non-http scripting space without competing directly with Clojure and
>>> Clojurescript.
>>>
>>> gvim
>>>
>>  --
> --
> 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.
>

-- 
-- 
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: Namespace loading upon deftype/defrecord class init?

[Rohit Aggarwal]

I am a clojure newbie. I am using clojure 1.5.1 and I am experiencing the 
issue as described here:

https://groups.google.com/forum/#!msg/clojure-dev/4CtSVWcD15A/shpMuyjMpxsJ

I could not find this issue in jira. So not sure if its been addressed. I 
can put it in jira if its still not there.

cheers

Rohit

-- 
-- 
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: Contributors needed for Rouge (Clojure on Ruby)

[Alex Miller]

I have a task on my infinite todo list to analyze these load times. I know that 
Tim B has done a bit of work on it in the past too. Rich has mentioned it to me 
a couple times so I know it's something he's concerned about.

Alex

-- 
-- 
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: Namespace loading upon deftype/defrecord class init?

[Alex Miller]

Maybe http://dev.clojure.org/jira/browse/CLJ-1208 ?

-- 
-- 
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: Namespace loading upon deftype/defrecord class init?

[Rohit Aggarwal]

Thats it. Thanks Alex!

On Wednesday, 8 January 2014 13:30:11 UTC, Alex Miller wrote:
>
> Maybe http://dev.clojure.org/jira/browse/CLJ-1208 ?

-- 
-- 
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: Contributors needed for Rouge (Clojure on Ruby)

[John Gabriele]

On Wednesday, January 8, 2014 7:17:35 AM UTC-5, Mikera wrote:

>
> The JVM isn't really the problem though, at least as far as I can work 
> out. In fact I think the whole "JVM startup is slow" thing is a bit of a 
> myth: JVM startup including running a simple "hello world" is less than 0.1 
> secs on my machine.
>

For a tiny Java-only command-line program, startup time is very quick.

For a tiny Clojure uberjar, startup time on my desktop is about a second. 
Tolerable.

A `lein run` in a tiny project takes a little over 2 seconds. To start up a 
`lein repl`, it takes around 3 seconds, or 5 seconds if I'm within a 
project (longer for a cold start). Those places, I think, is where most 
complaints lie regarding startup time. (This is all without using 
grenchman.)

Regardless though, I still think there would be value in a small-footprint 
natively-compiled Clojure with easy access to C libraries. Even without a 
JIT and without Java's expansive standard library. But, point taken about 
how much work the rest of the foundation would require.

-- 
-- 
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: Contributors needed for Rouge (Clojure on Ruby)

[Jim - FooBar();]

On 08/01/14 14:38, John Gabriele wrote:
For a tiny Clojure uberjar, startup time on my desktop is about a 
second. Tolerable.


well, a tiny Clojure/Swing uberjar on the raspberry-pi (oracle-java7) 
takes 9-12 seconds to start!!! not so tolerable...
in fact, in the absence of a splash screen, the user has the quite 
convincing illusion that nothing is happening!!!


this of course doesn't mean anything, I just thought it is worth 
mentioning...


Jim


--
--
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: Contributors needed for Rouge (Clojure on Ruby)

[Timothy Baldridge]

That's actually a major issue for those wanting to use Clojure to work on a
RPi or similar low end system. These systems are also so memory
constrained, that last I checked, the CLJS compiler wouldn't run too well
on them either. Now that doesn't stop people from using Node.js to run CLJS
code once it's compiled and copied to the device, but still, not exactly
the ideal solution.

Timothy


On Wed, Jan 8, 2014 at 8:43 AM, Jim - FooBar(); wrote:

> On 08/01/14 14:38, John Gabriele wrote:
>
>> For a tiny Clojure uberjar, startup time on my desktop is about a second.
>> Tolerable.
>>
>
> well, a tiny Clojure/Swing uberjar on the raspberry-pi (oracle-java7)
> takes 9-12 seconds to start!!! not so tolerable...
> in fact, in the absence of a splash screen, the user has the quite
> convincing illusion that nothing is happening!!!
>
> this of course doesn't mean anything, I just thought it is worth
> mentioning...
>
> Jim
>
>
>
> --
> --
> 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

Re: Contributors needed for Rouge (Clojure on Ruby)

[Laurent PETIT]

What Mikera probably wants to demonstrate, and I agree with him, is that
the slow startup time not being due to JVM proper, it's in the current
implementation of Clojure that you must find what to do.

If you port Clojure piece by piece to another technology, you will probably
get the same startup time problems ... minus the 0.1s taken by the JVM to
start.

The good news is that if it's not the JVM startup the problem, then you can
work on a better way of compiling Clojure code on the JVM ... no need to
change your target !


2014/1/8 John Gabriele 

> On Wednesday, January 8, 2014 7:17:35 AM UTC-5, Mikera wrote:
>
>>
>> The JVM isn't really the problem though, at least as far as I can work
>> out. In fact I think the whole "JVM startup is slow" thing is a bit of a
>> myth: JVM startup including running a simple "hello world" is less than 0.1
>> secs on my machine.
>>
>
> For a tiny Java-only command-line program, startup time is very quick.
>
> For a tiny Clojure uberjar, startup time on my desktop is about a second.
> Tolerable.
>
> A `lein run` in a tiny project takes a little over 2 seconds. To start up
> a `lein repl`, it takes around 3 seconds, or 5 seconds if I'm within a
> project (longer for a cold start). Those places, I think, is where most
> complaints lie regarding startup time. (This is all without using
> grenchman.)
>
> Regardless though, I still think there would be value in a small-footprint
> natively-compiled Clojure with easy access to C libraries. Even without a
> JIT and without Java's expansive standard library. But, point taken about
> how much work the rest of the foundation would require.
>
>  --
> --
> 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.
>

-- 
-- 
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: Contributors needed for Rouge (Clojure on Ruby)

[Jim - FooBar();]

Anyone who owns a RPi can go into the Pi-store and download MultiSnake 
to get a feeling of the problem...MultiSnake is basically a polished 
version of Stuart Halloway's snake game first featured in the book 
"Programming Clojure", with the major features you would expect from a 
snake game included and no reflection (well there is one place where I 
cannot get rid of reflection)...


If I remember correctly `lein repl` takes close to 55 seconds to 
show...clojure-py beats everything, hands down with respect to startup 
times...


Jim



On 08/01/14 15:46, Timothy Baldridge wrote:
That's actually a major issue for those wanting to use Clojure to work 
on a RPi or similar low end system. These systems are also so memory 
constrained, that last I checked, the CLJS compiler wouldn't run too 
well on them either. Now that doesn't stop people from using Node.js 
to run CLJS code once it's compiled and copied to the device, but 
still, not exactly the ideal solution.


Timothy


On Wed, Jan 8, 2014 at 8:43 AM, Jim - FooBar(); > wrote:


On 08/01/14 14:38, John Gabriele wrote:

For a tiny Clojure uberjar, startup time on my desktop is
about a second. Tolerable.


well, a tiny Clojure/Swing uberjar on the raspberry-pi
(oracle-java7) takes 9-12 seconds to start!!! not so tolerable...
in fact, in the absence of a splash screen, the user has the quite
convincing illusion that nothing is happening!!!

this of course doesn't mean anything, I just thought it is worth
mentioning...

Jim



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




--
“One of the main causes of the fall of the Roman Empire was 
that–lacking zero–they had no way to indicate successful termination 
of their C programs.”

(Robert Firth)
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to clojure+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/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: how to packge lein project in a maven-style?

[Peter Wu]

根据https://github.com/technomancy/leiningen/wiki/Plugins。lein-libdir和lein-resource就是你要找的lein
 
plugin。
话说，你能看得懂中文么？

在 2014年1月6日星期一UTC+8下午1时33分45秒，Qiu Xiafei写道：
>
>
>
> Using maven, we usually package the project in a directory with sub dirs 
> like: 
> bin/ # bash/python scripts
> lib/  # all jars
> conf/   # resources/configuration files
>
> And, we often use the *maven-dependency-plugin* to copy dependency jars 
> and use the *maven-resources-plugin* to copy scripts and other resource 
> files. But I find no alernertives in lein.
>
> Is there any lein plugin can help me about this?
>
> thanks!
>
>

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

Re: Contributors needed for Rouge (Clojure on Ruby)

[Timothy Baldridge]

And even clojure-py is miles behind stock python.

One of the problems with Clojure as it stands now is that there is just way
too much init work that has to be done on every startup. Just as a
comparison, let's compare how python code and clojure code is loaded:

Python:
1) look for a pyc file (often exists for library code)
2) load pyc code, and "parse". This parsing is basically creating C structs
that line up with the file. That is to say, pyc code is basically a memory
dump of a module. The actual format of this code is interpreter specific.
At this point, all literals are instantiated and ready to go.
4) run the loaded bytecode. Since all literals are loaded and ready, very
little extra work needs to be done.

Clojure:
1) Load the clojure compiler
2) Parse a .clj text file
3) analyze and compile the resulting code
4) generate classes for the code.
5) call the init method for each namespace.
6) sometime in here all the functions you're are going to need are init-ed.
This means all static members need to be fulfilled. This means that every
var in every function has to be resolved and interned. Every constant needs
to be created.
7) Now the code can run.
8) ... somewhere in here JITing happens.

What makes this worse is that parts of Clojure may not be properly profiled
by the JIT. In one benchmark I ran I saw a 2x speed-up loading files after
the compiler was properly warmed up.

What we see here is the difference between a VM designed for a language,
and one designed for a different language. In Python constants are just
dumped to/from disk during compilation and loading. In Clojure these
constants have to be recreated each time. In order to avoid cross platform
issues, many people avoid AOT compilation at all costs (and rightfully so,
it's a ugly beast), but this then adds parse/analyzer/compiler costs to the
entire process.

All this results in the following:

time python -c "1"

real 0m0.019s
user 0m0.011s
sys 0m0.007s

time java -jar clojure-1.6.0-alpha3.jar -e "1"
1

real 0m1.135s
user 0m1.525s
sys 0m0.086s

Now most of the time I really don't care, I have a beefy dev machine, and
so I simply load up a repl and keep it up all day. But I understand that
these limitations also keep Clojure from reaching into other more
constrained environments.

Anyway, that's my personal take on the subject. It's a trade-off. The JVM
is nice, but it's dang hard to get fast startup times with it.

Timothy


On Wed, Jan 8, 2014 at 8:56 AM, Jim - FooBar(); wrote:

>  Anyone who owns a RPi can go into the Pi-store and download MultiSnake
> to get a feeling of the problem...MultiSnake is basically a polished
> version of Stuart Halloway's snake game first featured in the book
> "Programming Clojure", with the major features you would expect from a
> snake game included and no reflection (well there is one place where I
> cannot get rid of reflection)...
>
> If I remember correctly `lein repl` takes close to 55 seconds to
> show...clojure-py beats everything, hands down with respect to startup
> times...
>
> Jim
>
>
>
>
> On 08/01/14 15:46, Timothy Baldridge wrote:
>
> That's actually a major issue for those wanting to use Clojure to work on
> a RPi or similar low end system. These systems are also so memory
> constrained, that last I checked, the CLJS compiler wouldn't run too well
> on them either. Now that doesn't stop people from using Node.js to run CLJS
> code once it's compiled and copied to the device, but still, not exactly
> the ideal solution.
>
> Timothy
>
>
> On Wed, Jan 8, 2014 at 8:43 AM, Jim - FooBar(); wrote:
>
>> On 08/01/14 14:38, John Gabriele wrote:
>>
>>> For a tiny Clojure uberjar, startup time on my desktop is about a
>>> second. Tolerable.
>>>
>>
>>  well, a tiny Clojure/Swing uberjar on the raspberry-pi (oracle-java7)
>> takes 9-12 seconds to start!!! not so tolerable...
>> in fact, in the absence of a splash screen, the user has the quite
>> convincing illusion that nothing is happening!!!
>>
>> this of course doesn't mean anything, I just thought it is worth
>> mentioning...
>>
>> Jim
>>
>>
>>
>> --
>> --
>> 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.
>>
>
>
>
>  --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”

Re: Contributors needed for Rouge (Clojure on Ruby)

[Max Gonzih]

I do lot of hacking on embed devices like Pi and BeagleBone for fun, I
run clojure mostly on ejre and it is much faster and memory efficient than 
openjdk
compiled for ARM, but still suffers from startup time (in Pi case it actually 
much worse).
Also ejre in development right now, so sometimes it crashes.
Things like drip are helpful, but still clojure.jar takes some time to load.
Also cached jvm can give you unexpected errors in rare cases.
I tried node.js but wasn't very satisfied with results.
Basically node.js can be much slower in some
cases, memory usage isn't ideal but startup time is good. I'm not big
fan of node.js as a platform, so I still looking forward to something
closer to metal (like yours clojure-metal project).

On Wed, Jan 08, 2014 at 08:46:46AM -0700, Timothy Baldridge wrote:
> That's actually a major issue for those wanting to use Clojure to work on a
> RPi or similar low end system. These systems are also so memory
> constrained, that last I checked, the CLJS compiler wouldn't run too well
> on them either. Now that doesn't stop people from using Node.js to run CLJS
> code once it's compiled and copied to the device, but still, not exactly
> the ideal solution.
>
> Timothy
>
>
> On Wed, Jan 8, 2014 at 8:43 AM, Jim - FooBar(); wrote:
>
> > On 08/01/14 14:38, John Gabriele wrote:
> >
> >> For a tiny Clojure uberjar, startup time on my desktop is about a second.
> >> Tolerable.
> >>
> >
> > well, a tiny Clojure/Swing uberjar on the raspberry-pi (oracle-java7)
> > takes 9-12 seconds to start!!! not so tolerable...
> > in fact, in the absence of a splash screen, the user has the quite
> > convincing illusion that nothing is happening!!!
> >
> > this of course doesn't mean anything, I just thought it is worth
> > mentioning...
> >
> > Jim
> >
> >
> >
> > --
> > --
> > 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.
> >
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the Google 
> Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/26X7Bj5_KUQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

--
Best regards,
Max

-- 
-- 
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: Contributors needed for Rouge (Clojure on Ruby)

[Jim - FooBar();]

I would recommend the newly available through official Pi channels, 
oracle-java7-jdk...It is a full distribution of JIT'ed Java (including 
Swing) with hardware-floating point arithmetic. I think the jdk8-ea 
(early access) is a tiny bit faster but not complete (no Swing). I think 
openJDK has not JIT.


Jim


On 08/01/14 16:30, Max Gonzih wrote:

I do lot of hacking on embed devices like Pi and BeagleBone for fun, I
run clojure mostly on ejre and it is much faster and memory efficient than 
openjdk
compiled for ARM, but still suffers from startup time (in Pi case it actually 
much worse).
Also ejre in development right now, so sometimes it crashes.
Things like drip are helpful, but still clojure.jar takes some time to load.
Also cached jvm can give you unexpected errors in rare cases.
I tried node.js but wasn't very satisfied with results.
Basically node.js can be much slower in some
cases, memory usage isn't ideal but startup time is good. I'm not big
fan of node.js as a platform, so I still looking forward to something
closer to metal (like yours clojure-metal project).

On Wed, Jan 08, 2014 at 08:46:46AM -0700, Timothy Baldridge wrote:

That's actually a major issue for those wanting to use Clojure to work on a
RPi or similar low end system. These systems are also so memory
constrained, that last I checked, the CLJS compiler wouldn't run too well
on them either. Now that doesn't stop people from using Node.js to run CLJS
code once it's compiled and copied to the device, but still, not exactly
the ideal solution.

Timothy


On Wed, Jan 8, 2014 at 8:43 AM, Jim - FooBar(); wrote:


On 08/01/14 14:38, John Gabriele wrote:


For a tiny Clojure uberjar, startup time on my desktop is about a second.
Tolerable.


well, a tiny Clojure/Swing uberjar on the raspberry-pi (oracle-java7)
takes 9-12 seconds to start!!! not so tolerable...
in fact, in the absence of a splash screen, the user has the quite
convincing illusion that nothing is happening!!!

this of course doesn't mean anything, I just thought it is worth
mentioning...

Jim



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




--
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

--
Best regards,
Max



--
--
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: Contributors needed for Rouge (Clojure on Ruby)

[Max Gonzih]

How is it different from 
http://www.oracle.com/technetwork/java/embedded/downloads/javase/index.html ?

On Wed, Jan 08, 2014 at 04:36:02PM +, Jim - FooBar(); wrote:
> I would recommend the newly available through official Pi channels,
> oracle-java7-jdk...It is a full distribution of JIT'ed Java
> (including Swing) with hardware-floating point arithmetic. I think
> the jdk8-ea (early access) is a tiny bit faster but not complete (no
> Swing). I think openJDK has not JIT.
>
> Jim
>
>
> On 08/01/14 16:30, Max Gonzih wrote:
> >I do lot of hacking on embed devices like Pi and BeagleBone for fun, I
> >run clojure mostly on ejre and it is much faster and memory efficient than 
> >openjdk
> >compiled for ARM, but still suffers from startup time (in Pi case it 
> >actually much worse).
> >Also ejre in development right now, so sometimes it crashes.
> >Things like drip are helpful, but still clojure.jar takes some time to load.
> >Also cached jvm can give you unexpected errors in rare cases.
> >I tried node.js but wasn't very satisfied with results.
> >Basically node.js can be much slower in some
> >cases, memory usage isn't ideal but startup time is good. I'm not big
> >fan of node.js as a platform, so I still looking forward to something
> >closer to metal (like yours clojure-metal project).
> >
> >On Wed, Jan 08, 2014 at 08:46:46AM -0700, Timothy Baldridge wrote:
> >>That's actually a major issue for those wanting to use Clojure to work on a
> >>RPi or similar low end system. These systems are also so memory
> >>constrained, that last I checked, the CLJS compiler wouldn't run too well
> >>on them either. Now that doesn't stop people from using Node.js to run CLJS
> >>code once it's compiled and copied to the device, but still, not exactly
> >>the ideal solution.
> >>
> >>Timothy
> >>
> >>
> >>On Wed, Jan 8, 2014 at 8:43 AM, Jim - FooBar(); wrote:
> >>
> >>>On 08/01/14 14:38, John Gabriele wrote:
> >>>
> For a tiny Clojure uberjar, startup time on my desktop is about a second.
> Tolerable.
> 
> >>>well, a tiny Clojure/Swing uberjar on the raspberry-pi (oracle-java7)
> >>>takes 9-12 seconds to start!!! not so tolerable...
> >>>in fact, in the absence of a splash screen, the user has the quite
> >>>convincing illusion that nothing is happening!!!
> >>>
> >>>this of course doesn't mean anything, I just thought it is worth
> >>>mentioning...
> >>>
> >>>Jim
> >>>
> >>>
> >>>
> >>>--
> >>>--
> >>>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.
> >>>
> >>
> >>
> >>--
> >>“One of the main causes of the fall of the Roman Empire was that–lacking
> >>zero–they had no way to indicate successful termination of their C
> >>programs.”
> >>(Robert Firth)
> >>
> >>--
> >>--
> >>You received this message because you are subscribed to the Google
> >>Groups "Clojure" group.
> >>To post to this group, send email to clojure@googlegroups.com
> >>Note that posts from new members are moderated - please be patient with 
> >>your first post.
> >>To unsubscribe from this group, send email to
> >>clojure+unsubscr...@googlegroups.com
> >>For more options, visit this group at
> >>http://groups.google.com/group/clojure?hl=en
> >>---
> >>You received this message because you are subscribed to a topic in the 
> >>Google Groups "Clojure" group.
> >>To unsubscribe from this topic, visit 
> >>https://groups.google.com/d/topic/clojure/26X7Bj5_KUQ/unsubscribe.
> >>To unsubscribe from this group and all its topics, send an email to 
> >>clojure+unsubscr...@googlegroups.com.
> >>For more options, visit https://groups.google.com/groups/opt_out.
> >--
> >Best regards,
> >Max
> >
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- You received this message because you are subscribed to a topic
> in the Google Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/26X7Bj5_KUQ/unsubscribe.
> To unsubscribe fro

Re: Contributors needed for Rouge (Clojure on Ruby)

[Softaddicts]

We run on small nodes with g540 cpus 4gig Ram and raid 1 SSDs.
Not very powerful machines. Startup times are around 3/4 seconds

AOT cuts the startup issue of our code significantly, we are thinking about
doing the same for all clojure source dependencies (shipping both
the code and the source).

Hard for us to qualify AOT as being an ugly beast,
unsuitable for development certainly but for deployment ?

Please clarify :)

Luc P.

> And even clojure-py is miles behind stock python.
> 
> One of the problems with Clojure as it stands now is that there is just way
> too much init work that has to be done on every startup. Just as a
> comparison, let's compare how python code and clojure code is loaded:
> 
> Python:
> 1) look for a pyc file (often exists for library code)
> 2) load pyc code, and "parse". This parsing is basically creating C structs
> that line up with the file. That is to say, pyc code is basically a memory
> dump of a module. The actual format of this code is interpreter specific.
> At this point, all literals are instantiated and ready to go.
> 4) run the loaded bytecode. Since all literals are loaded and ready, very
> little extra work needs to be done.
> 
> Clojure:
> 1) Load the clojure compiler
> 2) Parse a .clj text file
> 3) analyze and compile the resulting code
> 4) generate classes for the code.
> 5) call the init method for each namespace.
> 6) sometime in here all the functions you're are going to need are init-ed.
> This means all static members need to be fulfilled. This means that every
> var in every function has to be resolved and interned. Every constant needs
> to be created.
> 7) Now the code can run.
> 8) ... somewhere in here JITing happens.
> 
> What makes this worse is that parts of Clojure may not be properly profiled
> by the JIT. In one benchmark I ran I saw a 2x speed-up loading files after
> the compiler was properly warmed up.
> 
> What we see here is the difference between a VM designed for a language,
> and one designed for a different language. In Python constants are just
> dumped to/from disk during compilation and loading. In Clojure these
> constants have to be recreated each time. In order to avoid cross platform
> issues, many people avoid AOT compilation at all costs (and rightfully so,
> it's a ugly beast), but this then adds parse/analyzer/compiler costs to the
> entire process.
> 
> All this results in the following:
> 
> time python -c "1"
> 
> real 0m0.019s
> user 0m0.011s
> sys 0m0.007s
> 
> time java -jar clojure-1.6.0-alpha3.jar -e "1"
> 1
> 
> real 0m1.135s
> user 0m1.525s
> sys 0m0.086s
> 
> Now most of the time I really don't care, I have a beefy dev machine, and
> so I simply load up a repl and keep it up all day. But I understand that
> these limitations also keep Clojure from reaching into other more
> constrained environments.
> 
> Anyway, that's my personal take on the subject. It's a trade-off. The JVM
> is nice, but it's dang hard to get fast startup times with it.
> 
> Timothy
> 
> 
> On Wed, Jan 8, 2014 at 8:56 AM, Jim - FooBar(); wrote:
> 
> >  Anyone who owns a RPi can go into the Pi-store and download MultiSnake
> > to get a feeling of the problem...MultiSnake is basically a polished
> > version of Stuart Halloway's snake game first featured in the book
> > "Programming Clojure", with the major features you would expect from a
> > snake game included and no reflection (well there is one place where I
> > cannot get rid of reflection)...
> >
> > If I remember correctly `lein repl` takes close to 55 seconds to
> > show...clojure-py beats everything, hands down with respect to startup
> > times...
> >
> > Jim
> >
> >
> >
> >
> > On 08/01/14 15:46, Timothy Baldridge wrote:
> >
> > That's actually a major issue for those wanting to use Clojure to work on
> > a RPi or similar low end system. These systems are also so memory
> > constrained, that last I checked, the CLJS compiler wouldn't run too well
> > on them either. Now that doesn't stop people from using Node.js to run CLJS
> > code once it's compiled and copied to the device, but still, not exactly
> > the ideal solution.
> >
> > Timothy
> >
> >
> > On Wed, Jan 8, 2014 at 8:43 AM, Jim - FooBar(); wrote:
> >
> >> On 08/01/14 14:38, John Gabriele wrote:
> >>
> >>> For a tiny Clojure uberjar, startup time on my desktop is about a
> >>> second. Tolerable.
> >>>
> >>
> >>  well, a tiny Clojure/Swing uberjar on the raspberry-pi (oracle-java7)
> >> takes 9-12 seconds to start!!! not so tolerable...
> >> in fact, in the absence of a splash screen, the user has the quite
> >> convincing illusion that nothing is happening!!!
> >>
> >> this of course doesn't mean anything, I just thought it is worth
> >> mentioning...
> >>
> >> Jim
> >>
> >>
> >>
> >> --
> >> --
> >> 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 p

Re: Contributors needed for Rouge (Clojure on Ruby)

[Jim - FooBar();]

I think that is the one in the repos, but update 40 instead of 45...I 
had no idea it was called `ejre` as I used to use jdk-ea and switched to 
7 a couple of months ago through the official rasbian channels .


Jim


On 08/01/14 16:58, Max Gonzih wrote:

How is it different from 
http://www.oracle.com/technetwork/java/embedded/downloads/javase/index.html ?

On Wed, Jan 08, 2014 at 04:36:02PM +, Jim - FooBar(); wrote:

I would recommend the newly available through official Pi channels,
oracle-java7-jdk...It is a full distribution of JIT'ed Java
(including Swing) with hardware-floating point arithmetic. I think
the jdk8-ea (early access) is a tiny bit faster but not complete (no
Swing). I think openJDK has not JIT.

Jim


On 08/01/14 16:30, Max Gonzih wrote:

I do lot of hacking on embed devices like Pi and BeagleBone for fun, I
run clojure mostly on ejre and it is much faster and memory efficient than 
openjdk
compiled for ARM, but still suffers from startup time (in Pi case it actually 
much worse).
Also ejre in development right now, so sometimes it crashes.
Things like drip are helpful, but still clojure.jar takes some time to load.
Also cached jvm can give you unexpected errors in rare cases.
I tried node.js but wasn't very satisfied with results.
Basically node.js can be much slower in some
cases, memory usage isn't ideal but startup time is good. I'm not big
fan of node.js as a platform, so I still looking forward to something
closer to metal (like yours clojure-metal project).

On Wed, Jan 08, 2014 at 08:46:46AM -0700, Timothy Baldridge wrote:

That's actually a major issue for those wanting to use Clojure to work on a
RPi or similar low end system. These systems are also so memory
constrained, that last I checked, the CLJS compiler wouldn't run too well
on them either. Now that doesn't stop people from using Node.js to run CLJS
code once it's compiled and copied to the device, but still, not exactly
the ideal solution.

Timothy


On Wed, Jan 8, 2014 at 8:43 AM, Jim - FooBar(); wrote:


On 08/01/14 14:38, John Gabriele wrote:


For a tiny Clojure uberjar, startup time on my desktop is about a second.
Tolerable.


well, a tiny Clojure/Swing uberjar on the raspberry-pi (oracle-java7)
takes 9-12 seconds to start!!! not so tolerable...
in fact, in the absence of a splash screen, the user has the quite
convincing illusion that nothing is happening!!!

this of course doesn't mean anything, I just thought it is worth
mentioning...

Jim



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



--
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

--
Best regards,
Max


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

--
Best regards,

Re: Debugging with Cider

[boz]

I'd like to see Ritz with cider too. :)

Just for reference...
there is already an issue on the Ritz 
repo: https://github.com/pallet/ritz/issues/112
and there are a number of Ritz related issues on the Cider repo: 
https://github.com/clojure-emacs/cider/search?q=ritz&ref=cmdform&type=Issues 

On Thursday, October 31, 2013 12:17:52 PM UTC-7, Matthew O. Smith wrote:
>
>
> Hi all,
>
> Has anyone gotten debugging in emacs working with cider (was nrepl).  I 
> did fork and update cljdb but it is pretty old school. 
> https://github.com/m0smith/cljdb
> Is there any work on ritz or cdt?
>
> Thanks.
>

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

Re: Contributors needed for Rouge (Clojure on Ruby)

[Max Gonzih]

Well it's actually cool that this is inside Raspbian channels.

On Wed, Jan 08, 2014 at 05:21:31PM +, Jim - FooBar(); wrote:
> I think that is the one in the repos, but update 40 instead of
> 45...I had no idea it was called `ejre` as I used to use jdk-ea and
> switched to 7 a couple of months ago through the official rasbian
> channels .
>
> Jim
>
>
> On 08/01/14 16:58, Max Gonzih wrote:
> >How is it different from 
> >http://www.oracle.com/technetwork/java/embedded/downloads/javase/index.html ?
> >
> >On Wed, Jan 08, 2014 at 04:36:02PM +, Jim - FooBar(); wrote:
> >>I would recommend the newly available through official Pi channels,
> >>oracle-java7-jdk...It is a full distribution of JIT'ed Java
> >>(including Swing) with hardware-floating point arithmetic. I think
> >>the jdk8-ea (early access) is a tiny bit faster but not complete (no
> >>Swing). I think openJDK has not JIT.
> >>
> >>Jim
> >>
> >>
> >>On 08/01/14 16:30, Max Gonzih wrote:
> >>>I do lot of hacking on embed devices like Pi and BeagleBone for fun, I
> >>>run clojure mostly on ejre and it is much faster and memory efficient than 
> >>>openjdk
> >>>compiled for ARM, but still suffers from startup time (in Pi case it 
> >>>actually much worse).
> >>>Also ejre in development right now, so sometimes it crashes.
> >>>Things like drip are helpful, but still clojure.jar takes some time to 
> >>>load.
> >>>Also cached jvm can give you unexpected errors in rare cases.
> >>>I tried node.js but wasn't very satisfied with results.
> >>>Basically node.js can be much slower in some
> >>>cases, memory usage isn't ideal but startup time is good. I'm not big
> >>>fan of node.js as a platform, so I still looking forward to something
> >>>closer to metal (like yours clojure-metal project).
> >>>
> >>>On Wed, Jan 08, 2014 at 08:46:46AM -0700, Timothy Baldridge wrote:
> That's actually a major issue for those wanting to use Clojure to work on 
> a
> RPi or similar low end system. These systems are also so memory
> constrained, that last I checked, the CLJS compiler wouldn't run too well
> on them either. Now that doesn't stop people from using Node.js to run 
> CLJS
> code once it's compiled and copied to the device, but still, not exactly
> the ideal solution.
> 
> Timothy
> 
> 
> On Wed, Jan 8, 2014 at 8:43 AM, Jim - FooBar(); 
> wrote:
> 
> >On 08/01/14 14:38, John Gabriele wrote:
> >
> >>For a tiny Clojure uberjar, startup time on my desktop is about a 
> >>second.
> >>Tolerable.
> >>
> >well, a tiny Clojure/Swing uberjar on the raspberry-pi (oracle-java7)
> >takes 9-12 seconds to start!!! not so tolerable...
> >in fact, in the absence of a splash screen, the user has the quite
> >convincing illusion that nothing is happening!!!
> >
> >this of course doesn't mean anything, I just thought it is worth
> >mentioning...
> >
> >Jim
> >
> >
> >
> >--
> >--
> >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.
> >
> 
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
> 
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with 
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the 
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/26X7Bj5_KUQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> >>>--
> >>>Best regards,
> >>>Max
> >>>
> >>--
> >>--
> >>You received this

Re: Contributors needed for Rouge (Clojure on Ruby)

[Jim - FooBar();]

indeed :)

On 08/01/14 17:32, Max Gonzih wrote:

Well it's actually cool that this is inside Raspbian channels.


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

New release of Light Table (which is now open source!)

[Chris Granger]

Hey Folks,

We did a big release today which includes a lot of love for Clojure! We 
also released all the source to Light Table, which has to be one of the 
largest full ClojureScript applications out there. To read more about all 
the goodness check out my blog 
post: http://www.chris-granger.com/2014/01/07/light-table-is-open-source/

And take a look at the source here: https://github.com/lighttable

Cheers,
Chris.

-- 
-- 
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: New release of Light Table (which is now open source!)

[David Nolen]

Congrats!


On Wed, Jan 8, 2014 at 1:19 PM, Chris Granger  wrote:

> Hey Folks,
>
> We did a big release today which includes a lot of love for Clojure! We
> also released all the source to Light Table, which has to be one of the
> largest full ClojureScript applications out there. To read more about all
> the goodness check out my blog post:
> http://www.chris-granger.com/2014/01/07/light-table-is-open-source/
>
> And take a look at the source here: https://github.com/lighttable
>
> Cheers,
> Chris.
>
> --
> --
> 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.
>

-- 
-- 
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: New release of Light Table (which is now open source!)

[Baishampayan Ghose]

LightTable is indeed, a remarkable piece of software. Really shows
what ClojureScript is capable of. The code is very beautiful too.
Congratulations, Chris! ~BG

On Wed, Jan 8, 2014 at 11:49 PM, Chris Granger  wrote:
> Hey Folks,
>
> We did a big release today which includes a lot of love for Clojure! We also
> released all the source to Light Table, which has to be one of the largest
> full ClojureScript applications out there. To read more about all the
> goodness check out my blog post:
> http://www.chris-granger.com/2014/01/07/light-table-is-open-source/
>
> And take a look at the source here: https://github.com/lighttable
>
> Cheers,
> Chris.
>
> --
> --
> 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.



-- 
Baishampayan Ghose
b.ghose at gmail.com

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

Re: New release of Light Table (which is now open source!)

[Mark Engelberg]

As one of the initial kickstarter supporters for LightTable, every time a
new release comes out, I eagerly download and check out the Clojure support
in the latest version.

I'm always surprised to see there still isn't a decent REPL.  There's still
the same "instarepl" proof-of-concept that came with the earliest alphas,
which doesn't really connect with projects or have any particularly
usefulness for real development, but simply is there as an intro to people
trying Clojure.

There's also some inline evaluation for writing code, but again, that's not
the same thing as a REPL.

So for those of you who are actually using LightTable for development, how
do you function without a REPL?  What am I missing?

-- 
-- 
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: New release of Light Table (which is now open source!)

[Chris Granger]

> There's still the same "instarepl" proof-of-concept that came with the
earliest alphas, which doesn't really connect with projects

That's not true at all :) The instarepl will work with any nrepl client
you're connected to. By default if you don't have a connection to a
project, it will just open a plain repl for you to play with, but you can
disconnect from that one and connect to your project, or you can eval in a
file before you open an instarepl to create a connection, or you can...

> There's also some inline evaluation for writing code, but again, that's
not the same thing as a REPL.

If you open an empty file and set it's syntax to Clojure, what's the
difference between it and the REPL?

Cheers,
Chris.


On Wed, Jan 8, 2014 at 11:01 AM, Mark Engelberg wrote:

> As one of the initial kickstarter supporters for LightTable, every time a
> new release comes out, I eagerly download and check out the Clojure support
> in the latest version.
>
> I'm always surprised to see there still isn't a decent REPL.  There's
> still the same "instarepl" proof-of-concept that came with the earliest
> alphas, which doesn't really connect with projects or have any particularly
> usefulness for real development, but simply is there as an intro to people
> trying Clojure.
>
> There's also some inline evaluation for writing code, but again, that's
> not the same thing as a REPL.
>
> So for those of you who are actually using LightTable for development, how
> do you function without a REPL?  What am I missing?
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/dvnX09qOZJU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/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: New release of Light Table (which is now open source!)

[Peter Mancini]

I'm using regular editing windows as a repl. I turn off live most of the 
time as I don't think it's useful - I don't type fast enough before an 
unlimited take goes to work on an unlimited lazy collection... Everything 
else about it is great - a console is available to test println messages. 
The results are in a format that is easy to interpret. For me it works fine.

Full disclojure: I absolutely hate EMACS so anything is better. I just 
happen to like Light Table. I'm still hoping some of the original demo 
stuff will show up. For now it's pretty darn useful and getting more useful 
with each release.

Thanks Chris - another great release.

-- 
      

    

-- 
-- 
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: New release of Light Table (which is now open source!)

[Benjamin Yu]

Grats! I love the pain points that light table solves for me.


On Wed, Jan 8, 2014 at 12:36 PM, Peter Mancini  wrote:

> I'm using regular editing windows as a repl. I turn off live most of the
> time as I don't think it's useful - I don't type fast enough before an
> unlimited take goes to work on an unlimited lazy collection... Everything
> else about it is great - a console is available to test println messages.
> The results are in a format that is easy to interpret. For me it works fine.
>
> Full disclojure: I absolutely hate EMACS so anything is better. I just
> happen to like Light Table. I'm still hoping some of the original demo
> stuff will show up. For now it's pretty darn useful and getting more useful
> with each release.
>
> Thanks Chris - another great release.
>
>     
>   
>
> --
> --
> 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.
>

-- 
-- 
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: Extracting a database schema and using it to synthesize and check SQL queries at compile time

[Alexander Hudek]

This looks interesting. Hopefully it's a more consistent interface than 
information_schema. I'll try it out, thanks!

On Wednesday, January 8, 2014 3:32:49 AM UTC-5, Shantanu Kumar wrote:
>
>
>> The approach to read the database to generate code is pretty interesting. 
>> There is a more portable way to extract the schema information, using 
>> DatabaseMetadata that you can extract from a Connection.
>>
>> http://docs.oracle.com/javase/7/docs/api/java/sql/DatabaseMetaData.html
>>
>> http://docs.oracle.com/javase/7/docs/api/java/sql/Connection.html#getMetaData()
>>
>
> I did some related work quite a while ago: 
> https://github.com/kumarshantanu/clj-jdbcutil/blob/master/src/clj_jdbcutil/core.clj#L535
>
> Sharing just in case somebody finds it useful.
>
> Shantanu
>

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

Granularity in Leiningen profile loading

[gvim]

In ~/.lein/profiles.clj I have:

{:user {:plugins [[lein-ritz "0.7.0"] [lein-ancient "0.5.4"]]
:dependencies [[org.clojure/core.typed "0.2.21"]
   [org.clojure/core.match "0.2.0"]
   [co.paralleluniverse/pulsar "0.3.0"]]}}

... and I ~/.lein/projfiles.d/cljs.clj I have:

{:plugins [[lein-cljsbuild "1.0.1"]]
 :dependencies [[org.clojure/clojurescript "0.0-2138"]
[om "0.1.5"]]}

After `line new cljs1` I added a profiles entry and now have:

(defproject yes "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.5.1"]]
  :profiles {:clj {}})

... but after `lein deps` the cljs profile still isn't loaded.

Any suggestions?

gvim

--
--
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: New release of Light Table (which is now open source!)

[Lee Spector]

On Jan 8, 2014, at 3:49 PM, Benjamin Yu wrote:

> Grats! I love the pain points that light table solves for me.

The inline documentation is pretty great once I discovered how to invoke it 
(which took a while... and while I really love a lot of the ideas in LightTable 
I have to say that it always takes me a while to figure out how to do basic 
things in the interface, which I find cryptically minimal...).

Does anyone know if there's a hidden way to turn off automatic bracket 
insertion or to get console output without namespace prefixes?

 -Lee



-- 
-- 
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: New release of Light Table (which is now open source!)

[Lee Spector]

On Jan 8, 2014, at 3:58 PM, Lee Spector wrote:
> The inline documentation is pretty great once I discovered how to invoke it 
> (which took a while... and while I really love a lot of the ideas in 
> LightTable I have to say that it always takes me a while to figure out how to 
> do basic things in the interface, which I find cryptically minimal...).
> 
> Does anyone know if there's a hidden way to turn off automatic bracket 
> insertion or to get console output without namespace prefixes?


Also, any way to see a stack trace after an exception? 

(.printStackTrace *e) doesn't do it.

Thanks,

 -Lee

-- 
-- 
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: New release of Light Table (which is now open source!)

[Lee Spector]

On Jan 8, 2014, at 4:04 PM, Lee Spector wrote:
> 
> Also, any way to see a stack trace after an exception? 
> 
> (.printStackTrace *e) doesn't do it.

Ah -- sorry to be writing so quickly. I've discovered that clicking on the 
exception appears to give a stack trace. Nice! (But again, wasn't obvious to me 
at first.)

It'd be super sweet if this showed arguments and locals :-)

 -Lee

-- 
-- 
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: Extracting a database schema and using it to synthesize and check SQL queries at compile time

[Alexander Hudek]

Hey Luc,

Our use case is quite a bit different. We treat our database schema as part 
of our applications data model. 
In contrast, it seems that your problem is one of data integration. That's 
a much more difficult
problem to solve.

If I understand correctly, you have a code that generates a database 
specific view (e.g. oracle, sql server)
that maps a vendors schema to your own schema based on a manually specified 
mapping? Seems like
a reasonable solution. 

Unrelated to this demo, I've actually been involved in a research project 
creating a 
similar technique where we describe schemas and their mappings in formal 
logic, then have a compiler that 
can create high performance plans based on logic proofs. Thus you can write 
queries against your common
logical schema and automatically generate plans over a different physical 
schema. Sadly, the project is not
at a state that we can release quite yet. Hopefully one day though.


On Wednesday, January 8, 2014 4:07:01 AM UTC-5, Luc wrote:
>
> Hi, 
>
> After struggling with Hibernate, SQL dsl, then bare SQL for a couple of 
> years we 
> took a radical path away from these approaches. 
>
> We do not in our world own the database models we are dealing with, 
> keeping our heads above water (or mud you might say) has become a 
> survival issue. 
>
> So we took the problem the other way around. How can we make the 
> relational models compliant with our business model ? 
>
> We are in the health industry, a patient is a patient, why do we have to 
> struggle with the fine prints of each vendor's relational model ? 
>
> We implemented and EDN subset library in several SQL db dialects (Oracle, 
> mysql, SqlServer support will come out before spring). 
> Implementing an EDN library is between 250 to 300 lines of SQL code per 
> database type so far. It's purely functional and returns a single column 
> (entity) and a string EDN representation. We just edn/read-string in the 
> code 
> and we get our business entity. What remains are semantic issues with 
> the data itself but this already addressed by a component above this in 
> our product stack. 
>
> To avoid writing the views by hand, we created a viewer generator that 
> creates 
> according to the db dialect a view returning an EDN representation of the 
> business entity as we manipulate it in 
> the code, not as it is defined in the database. 
>
> One view == one business entity. 
>
> The generator is db aware through some protocol magic and can handle 
> different db brands. 
>
> The mapping between the db model and our business model is defined 
> as data. It contains the fields to extract, their types if not strings, 
> the joins, the selection criterias, the db dialect,  
> This defines our business model vs the relational model. 
>
> The generator is less than 300 lines of code, entity definitions can be 
> between 50 to 200 lines. 
>
> Add to this the yesql library to wrap queries now in a single file. 
>
> It shrank our sql queries to a ridiculous number per vendor 
> while pushing away the complexity of the mapping of the relational model 
> away from the code as configurable data. 
>
> As for inserts, updates, ... views are of no help here but the generator 
> can bridge the gap by creating sql statements and small field name 
> translation wrappers from the same definition as the views. 
>
> The parameter names we use remain coherent with the business model the 
> code uses. 
> The sql statements to insert, ... are again wrapped by yesql. 
>
> Performançe so far is not an issue, we run our product on small boxes 
> less powerful than our customer's database servers. Shifting the load 
> on the side of the database server made sense in this regard. 
>
> And away from this relational modeling crap. Give the same business domain 
> entities to ten different DBAs and you will get ten relational models each 
> with 
> it's own nit picking subtleties. 
>
> Luc P. 
>
>
> > Hey everyone, 
> > 
> > We've been exploring ways to make working with database code more 
> efficient 
> > and less error prone. 
> > For complex queries, we prefer working directly with SQL. However, like 
> for 
> > many others, a lot of our 
> > queries are very simple and repetitive. For example, retrieving or 
> updating 
> > single rows, or a set of rows 
> > based on a foreign key. 
> > 
> > As an experiment, we wrote a prototype that uses the information_schema 
> > standard to automatically 
> > extract the schema from a database and represent it as clojure code at 
> > compile time. With this, we 
> > were able to synthesize some simple SQL queries. The interesting part of 
> > this is that the code generator 
> > automatically picks up primary key constraints and also performs 
> validation 
> > on table and column names. 
> > All of this is done at compile time. Errors are caught early and the 
> > compiled code uses clojure.java.jdbc 
> > prepared statements. You can find the code and demo here: 
> > 
> > https:/

Re: New release of Light Table (which is now open source!)

[Mark Engelberg]

Ok, I appreciate the suggestions and I'll give it another try with these
comments in mind.  You still need to create and manage projects from a
command line with lein, right?

-- 
-- 
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: Contributors needed for Rouge (Clojure on Ruby)

[gvim]

On 08/01/2014 15:56, Jim - FooBar(); wrote:

If I remember correctly `lein repl` takes close to 55 seconds to
show...clojure-py beats everything, hands down with respect to startup
times...


However, Clojure-Py is now a dead parrot :)

gvim

--
--
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: New release of Light Table (which is now open source!)

[Jamie Brandon]

You can disable the bracket insertion by disabling the keys that
trigger it. Add this to your user.keymap:

:- {:editor.keys.normal {"\"" [(:editor.repeat-pair "\"")]
  "(" [(:editor.open-pair "(")]
  ")" [(:editor.close-pair ")")]
  "[" [(:editor.open-pair "[")]
  "{" [(:editor.open-pair "{")]
  "]" [(:editor.close-pair "]")]
  "}" [(:editor.close-pair "}")]
  "backspace" [:editor.backspace-pair]}}

On 8 January 2014 20:58, Lee Spector  wrote:
>
> On Jan 8, 2014, at 3:49 PM, Benjamin Yu wrote:
>
>> Grats! I love the pain points that light table solves for me.
>
> The inline documentation is pretty great once I discovered how to invoke it 
> (which took a while... and while I really love a lot of the ideas in 
> LightTable I have to say that it always takes me a while to figure out how to 
> do basic things in the interface, which I find cryptically minimal...).
>
> Does anyone know if there's a hidden way to turn off automatic bracket 
> insertion or to get console output without namespace prefixes?
>
>  -Lee
>
>
>
> --
> --
> 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.

-- 
-- 
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: New release of Light Table (which is now open source!)

[gvim]

Chris

Thanks for a great product. Can you help me out? I just installed the 
latest 0.5.21/binary 0.8.0-rc1 on OS X Mountain Lion and every time it 
starts I get the same message - "There's been a binary update!". Can't 
get rid of it.


gvim



On 08/01/2014 18:19, Chris Granger wrote:

Hey Folks,

We did a big release today which includes a lot of love for Clojure! We
also released all the source to Light Table, which has to be one of the
largest full ClojureScript applications out there. To read more about
all the goodness check out my blog
post: http://www.chris-granger.com/2014/01/07/light-table-is-open-source/

And take a look at the source here: https://github.com/lighttable

Cheers,
Chris.

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


--
--
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: New release of Light Table (which is now open source!)

[Chris Granger]

you have to do what the popup says :) Because this is a binary update you
have to download the latest Light Table from www.lighttable.com

Cheers,
Chris.


On Wed, Jan 8, 2014 at 2:59 PM, gvim  wrote:

> Chris
>
> Thanks for a great product. Can you help me out? I just installed the
> latest 0.5.21/binary 0.8.0-rc1 on OS X Mountain Lion and every time it
> starts I get the same message - "There's been a binary update!". Can't get
> rid of it.
>
> gvim
>
>
>
>
> On 08/01/2014 18:19, Chris Granger wrote:
>
>> Hey Folks,
>>
>> We did a big release today which includes a lot of love for Clojure! We
>> also released all the source to Light Table, which has to be one of the
>> largest full ClojureScript applications out there. To read more about
>> all the goodness check out my blog
>> post: http://www.chris-granger.com/2014/01/07/light-table-is-open-source/
>>
>> And take a look at the source here: https://github.com/lighttable
>>
>> Cheers,
>> Chris.
>>
>> --
>> --
>> 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.
>>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/clojure/dvnX09qOZJU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/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: New release of Light Table (which is now open source!)

[Sean Corfield]

On Jan 8, 2014, at 11:01 AM, Mark Engelberg  wrote:
> So for those of you who are actually using LightTable for development, how do 
> you function without a REPL?  What am I missing?

It has a perfectly good REPL and the ability to evaluate live code anywhere on 
the REPL "canvas" is very useful since you can sketch out multiple pieces of 
related code side-by-side.

I guess I don't understand why your view of what LT provides is so negative?

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: New release of Light Table (which is now open source!)

[gvim]

Chris

I did that. I had 0.5.20 installed earlier.

gvim


On 08/01/2014 23:03, Chris Granger wrote:

you have to do what the popup says :) Because this is a binary update
you have to download the latest Light Table from www.lighttable.com


Cheers,
Chris.


On Wed, Jan 8, 2014 at 2:59 PM, gvim mailto:gvi...@gmail.com>> wrote:

Chris

Thanks for a great product. Can you help me out? I just installed
the latest 0.5.21/binary 0.8.0-rc1 on OS X Mountain Lion and every
time it starts I get the same message - "There's been a binary
update!". Can't get rid of it.

gvim




On 08/01/2014 18:19, Chris Granger wrote:

Hey Folks,

We did a big release today which includes a lot of love for
Clojure! We
also released all the source to Light Table, which has to be one
of the
largest full ClojureScript applications out there. To read more
about
all the goodness check out my blog
post:
http://www.chris-granger.com/__2014/01/07/light-table-is-__open-source/


And take a look at the source here: https://github.com/lighttable

Cheers,
Chris.

--
--
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+unsubscribe@__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+unsubscribe@__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+unsubscribe@__googlegroups.com

For more options, visit this group at
http://groups.google.com/__group/clojure?hl=en

--- You received this message because you are subscribed to a topic
in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/__topic/clojure/dvnX09qOZJU/__unsubscribe 
.
To unsubscribe from this group and all its topics, send an email to
clojure+unsubscribe@__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.


--
--
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: New release of Light Table (which is now open source!)

[Chris Granger]

ah try hard refreshing the lighttable.com site, sounds like you're
downloading an older version maybe? This should be the address of the
download for mac:
http://d35ac8ww5dfjyg.cloudfront.net/playground/bins/0.6.0/LightTableMac.zip

Cheers,
Chris.


On Wed, Jan 8, 2014 at 3:21 PM, gvim  wrote:

> Chris
>
> I did that. I had 0.5.20 installed earlier.
>
> gvim
>
>
>
> On 08/01/2014 23:03, Chris Granger wrote:
>
>> you have to do what the popup says :) Because this is a binary update
>> you have to download the latest Light Table from www.lighttable.com
>> 
>>
>>
>> Cheers,
>> Chris.
>>
>>
>> On Wed, Jan 8, 2014 at 2:59 PM, gvim > > wrote:
>>
>> Chris
>>
>> Thanks for a great product. Can you help me out? I just installed
>> the latest 0.5.21/binary 0.8.0-rc1 on OS X Mountain Lion and every
>> time it starts I get the same message - "There's been a binary
>> update!". Can't get rid of it.
>>
>> gvim
>>
>>
>>
>>
>> On 08/01/2014 18:19, Chris Granger wrote:
>>
>> Hey Folks,
>>
>> We did a big release today which includes a lot of love for
>> Clojure! We
>> also released all the source to Light Table, which has to be one
>> of the
>> largest full ClojureScript applications out there. To read more
>> about
>> all the goodness check out my blog
>> post:
>> http://www.chris-granger.com/__2014/01/07/light-table-is-__
>> open-source/
>>
>> > open-source/>
>>
>> And take a look at the source here: https://github.com/lighttable
>>
>> Cheers,
>> Chris.
>>
>> --
>> --
>> 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+unsubscribe@__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+unsubscribe@__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+unsubscribe@__googlegroups.com
>> 
>>
>> For more options, visit this group at
>> http://groups.google.com/__group/clojure?hl=en
>>
>> 
>> --- You received this message because you are subscribed to a topic
>> in the Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/__topic/clojure/dvnX09qOZJU/__unsubscribe<
>> https://groups.google.com/d/topic/clojure/dvnX09qOZJU/unsubscribe>.
>>
>> To unsubscribe from this group and all its topics, send an email to
>> clojure+unsubscribe@__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.
>>
>
> --
> --
> You received this

Re: New release of Light Table (which is now open source!)

[Mimmo Cosenza]

On Jan 8, 2014, at 8:01 PM, Mark Engelberg  wrote:

> So for those of you who are actually using LightTable for development, how do 
> you function without a REPL?  

If you are on the TDD wagon, there is a very good introduction to TDD with LT 
at the following URL:

http://www.youtube.com/watch?v=H_teKHH_Rk0

You can reach a similar workflow by using clojure.test and lein-test-refresh 
plugin. 

The more you TDD the less time you spend in the REPL. I'm not a TDD fanatic at 
all, especially while programming in clojure (thanks to default immutability of 
its data structures), but if you are on that wagon you're going to spend less 
time in the REPL and more in the test files and LT let you make one of those 
file to be your repl too, which is not bad at all. 

mimmo

p.s. I'm addicted to emacs and REPL, but I have to admit that LT (I was a 
kickstarter supporter too) is intriguing me a lot. 


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



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: New release of Light Table (which is now open source!)

[Lee Spector]

On Jan 8, 2014, at 5:45 PM, Jamie Brandon wrote:

> You can disable the bracket insertion by disabling the keys that
> trigger it. Add this to your user.keymap:
> 
> :- {:editor.keys.normal {"\"" [(:editor.repeat-pair "\"")]
>  "(" [(:editor.open-pair "(")]
>  ")" [(:editor.close-pair ")")]
>  "[" [(:editor.open-pair "[")]
>  "{" [(:editor.open-pair "{")]
>  "]" [(:editor.close-pair "]")]
>  "}" [(:editor.close-pair "}")]
>  "backspace" [:editor.backspace-pair]}}

Thanks Jamie. I managed to get this to work, so that's great. 

FWIW my perspective (esp as a teacher of newbies) it'd be nice if there was 
some sort of simple switch for this. It's sort of cumbersome to have to 
discover this, find the file, and add a bunch of code to get the keyboard to 
behave normally

 -Lee

-- 
-- 
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: New release of Light Table (which is now open source!)

[Sean Corfield]

On Jan 8, 2014, at 3:38 PM, Lee Spector  wrote:
> FWIW my perspective (esp as a teacher of newbies) it'd be nice if there was 
> some sort of simple switch for this. It's sort of cumbersome to have to 
> discover this, find the file, and add a bunch of code to get the keyboard to 
> behave normally

I suspect the majority of users think the default behavior is "normal" - and 
desirable :)

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: New release of Light Table (which is now open source!)

[Sean Corfield]

On Jan 8, 2014, at 1:35 PM, Mark Engelberg  wrote:
> You still need to create and manage projects from a command line with lein, 
> right?

Correct. Until someone builds a plugin for that :)

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Granularity in Leiningen profile loading

[Ken Restivo]

On Wed, Jan 08, 2014 at 08:52:34PM +, gvim wrote:
> In ~/.lein/profiles.clj I have:
> 
> {:user {:plugins [[lein-ritz "0.7.0"] [lein-ancient "0.5.4"]]
> :dependencies [[org.clojure/core.typed "0.2.21"]
>[org.clojure/core.match "0.2.0"]
>[co.paralleluniverse/pulsar "0.3.0"]]}}
> 
> ... and I ~/.lein/projfiles.d/cljs.clj I have:
> 
> {:plugins [[lein-cljsbuild "1.0.1"]]
>  :dependencies [[org.clojure/clojurescript "0.0-2138"]
> [om "0.1.5"]]}
> 
> After `line new cljs1` I added a profiles entry and now have:
> 
> (defproject yes "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.5.1"]]
>   :profiles {:clj {}})
> 
> ... but after `lein deps` the cljs profile still isn't loaded.
> 
> Any suggestions?
> 
> gvim
> 

Just a wild guess, but have you tried this patch?

https://github.com/technomancy/leiningen/commit/3d50e8c9baedfcc54c4b21b2bb3fbbc676b9a713

-ken

-- 
-- 
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: New release of Light Table (which is now open source!)

[Mark Engelberg]

On Wed, Jan 8, 2014 at 12:45 PM, Sean Corfield  wrote:

> It has a perfectly good REPL and the ability to evaluate live code
> anywhere on the REPL "canvas" is very useful since you can sketch out
> multiple pieces of related code side-by-side.
>
> I guess I don't understand why your view of what LT provides is so
> negative?
>

That's a good question, and maybe enough has changed that I need to give it
another try.  On the surface, it didn't appear that much had changed so I
haven't really spent significant time with Light Table recently.

When I first played around with Light Table, I was strongly disturbed by
the lack of a REPL.

First, I have absolutely no interest in having executable
test-out-this-code snippets interspersed with the actual program code,
unless it is a formal test that is intended to stick around and uses
something like clojure.test.  This means I have to create a separate file
and pretend that this file-with-live-execution is a REPL.  But it's not.

1.  A REPL puts you "inside" a namespace and interactively move around
between namespaces.  Within a namespace, you have access to all the aliases
and referred names available within that namespace.  If I set up an
independent file, the file itself presumably needs its own namespace
header.  This means to simulate being "in a namespace" I have to use that
namespace *and* clone the entire header from that namespace.  I have to
keep these headers in sync, and the notion of moving between namespaces is
a heavyweight, annoying activity.

2.  A REPL has a notion of a command history, letting you easily redo a
recent command.  Each command and response becomes part of a log that you
can copy or save to a file if you want.  With a file, there's no simple way
to "execute the command I executed two times ago".  You have two options:
copy and paste the command again and re-execute it, or, the more common
option is probably to just go back up to the previous command and hit
ctrl-enter (overwriting the previous answer).  And you don't really end up
with a log of commands and responses, you just end up with a file
containing the sequence of commands.  The assumption is that this can all
be reevaluated in the future.  But if your commands are, for example,
queries to some rapidly changing database, this assumption is false.

A big part of how I use Clojure is that I build a suite of functions that
allow me to interactively explore problems.  I program for a while,
building those functions, and then I switch to the REPL to use what I have
built.  I switch around between namespaces, I make queries to live
databases that are always changing, I call my functions on the results of
those queries.  I hit "Ctrl-Up" to re-execute the query from a few minutes
ago to see if anything has changed.  Sometimes, I copy the whole log of my
interactions off to a file; sometimes I don't.

When I fired up Light Table a while back, I felt completely hamstrung -- I
couldn't do anything the way I ordinarily would do it.  The notion of
executing statements that live in a file didn't feel anything like the
workflow I was used to.  It seemed distinctly weaker.

On top of that, at the time I tried it, Light Table couldn't properly
handle long and lazy outputs from functions.  I also couldn't figure out
how to observe anything that printed to stdout.  Because of that, I
couldn't use most of the REPL tools I was used to using (e.g.,
doc/source/pprint/trace) and the features in Light Table didn't seem to be
a compensation for having those tools.

With each new version of Light Table, I go through this process of
thinking, "Hmmm, I wonder if they have a usable REPL yet."  I pop open
Light Table, read the docs which talk about the Instarepl quick start and
the live-code execution feature, no way to create a project from scratch,
and no discussion of a project repl.  I shrug and say, "Guess they aren't
seriously targeting Clojure development yet; seems like all the focus
lately is on JavaScript and Python and underlying infrastructure code."  I
shut it down and figure I'll try again in a few months.

This time, I got excited because the announcement said there was lots of
"Clojure love" in this release.  Again, I didn't see anything obviously new
relating to Clojure in the docs.  So I'm left wondering, "Does the Light
Table team really think this current state is adequate for Clojure
development?  If so, what am I missing?"  This prompted my earlier question.

I'm willing to accept that I might be underestimating the value of what is
currently there, and will give it an earnest try.  I would also welcome
detailed workflow stories of how other users interact with Light Table.

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

Re: New release of Light Table (which is now open source!)

[Lee Spector]

On Jan 8, 2014, at 8:50 PM, Sean Corfield wrote:
> On Jan 8, 2014, at 3:38 PM, Lee Spector  wrote:
>> FWIW my perspective (esp as a teacher of newbies) it'd be nice if there was 
>> some sort of simple switch for this. It's sort of cumbersome to have to 
>> discover this, find the file, and add a bunch of code to get the keyboard to 
>> behave normally
> 
> I suspect the majority of users think the default behavior is "normal" - and 
> desirable :)

Why would you suspect this? Conceivably it could be desirable (although I 
personally think it's awful), but "normal"? We all type all of the time in 
scores of applications and contexts, and in very few of them does the editor 
think it's smarter than us and add characters that we didn't ask for. (I guess 
there's autocorrect, but A: yuck, and B: this is different.) 

On the other hand, I'm a big fan of auto-indentation, so maybe my position 
isn't 100% consistent :-)

Still, when writing Clojure something like half the characters you type will be 
brackets, which means that if your editor does the auto-insert-bracket thing 
then it's constantly doing something different from when you type in any other 
context, either adding a closing bracket that you didn't ask for or, when you 
type a closing bracket, sometimes typing it and sometimes not, depending on the 
context.

For newbies, in particular, the idea that they should have to re-learn how to 
type on top of everything else that they have to learn doesn't strike me as 
particularly friendly.

I do realize that tastes vary. But FWIW I wouldn't voluntarily use an 
environment with automatic bracket insertion, and I wouldn't want to foist it 
on my students either. So even if it's on by default, it would be important to 
me that it be easy to turn off.

 -Lee

-- 
-- 
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: Contributors needed for Rouge (Clojure on Ruby)

[John Gabriele]

On Wednesday, January 8, 2014 11:17:07 AM UTC-5, tbc++ wrote:
>
> And even clojure-py is miles behind stock python. 
>
> One of the problems with Clojure as it stands now is that there is just 
> way too much init work that has to be done on every startup. Just as a 
> comparison, let's compare how python code and clojure code is loaded:
>
 

> {snip}
>
> What makes this worse is that parts of Clojure may not be properly 
> profiled by the JIT. In one benchmark I ran I saw a 2x speed-up loading 
> files after the compiler was properly warmed up. 
>
> What we see here is the difference between a VM designed for a language, 
> and one designed for a different language. In Python constants are just 
> dumped to/from disk during compilation and loading. In Clojure these 
> constants have to be recreated each time.
>
 

> {snip}
>
> Anyway, that's my personal take on the subject. It's a trade-off. The JVM 
> is nice, but it's dang hard to get fast startup times with it. 
>
> Timothy 
>
>
It sounds to me that you're saying there's much less legwork for the VM to 
do when it's written expressly for a single given language.

I don't have a comp sci background, so please excuse my ignorance here, but 
Clojure seems like a pretty simple language, as languages go. How much work 
would be involved in hacking together a completely un-optimized custom VM 
for Clojure --- just for a useful subset of the Clojure language? Say, for 
argument's sake, you were willing to temporarily forego having a JIT and 
multithreading.

-- John

-- 
-- 
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/Luminus memory footprint

[gvim]

On OS X Mountain Lion I just compared the memory footprint of 3 
out-of-the-box web apps in these frameworks:


Clojure/Luminus:  152Mb (JVM) + 186Mb (main) = 338Mb

Ruby/Rails: 62Mb

Elixir (Erlang)/Weber: 32Mb

I was rather shocked, to say the least. Not to troll, it has made me 
think again about deploying Clojure web apps on hosting platforms with 
modest amounts RAM. I'm sure the figures for all 3 would increase 
significantly once the web apps are fleshed out but that probably 
applies equally to all 3 frameworks.


gvim


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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Clojure/Luminus memory footprint

[Gary Trakhman]

you're still missing some basics about java memory management.  In another
thread, I mentioned the java VM will take more memory than it needs, that
is because it prioritizes throughput over footprint.  There are knobs for
all of that.  It's not clear what's taking so much memory, but it's
certainly not luminus or clojure.  Use jvisualVM to find out for sure
instead of comparing apples to oranges.


On Wed, Jan 8, 2014 at 4:24 PM, gvim  wrote:

> On OS X Mountain Lion I just compared the memory footprint of 3
> out-of-the-box web apps in these frameworks:
>
> Clojure/Luminus:  152Mb (JVM) + 186Mb (main) = 338Mb
>
> Ruby/Rails: 62Mb
>
> Elixir (Erlang)/Weber: 32Mb
>
> I was rather shocked, to say the least. Not to troll, it has made me think
> again about deploying Clojure web apps on hosting platforms with modest
> amounts RAM. I'm sure the figures for all 3 would increase significantly
> once the web apps are fleshed out but that probably applies equally to all
> 3 frameworks.
>
> gvim
>
>
> --
> --
> 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.
>

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

Recompiling a Java class

[Jacob Goodson]

I created a Java object which I called from a clojure repl... it works 
great!  As the project progresses I learn that my well thought out and 
amazing object sucks #$%^%$#%^... So I change the object a little then I 
recompile the object, expecting to see the updated changes in my repl of 
automagical powers... oh no, the object appears to be the same piece of 
crap that it was earlier!  Give me interaction or give me death!  

Is there a way for me to update java objects without having to restart my 
repl?  

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

Re: Clojure/Luminus memory footprint

[gvim]

Here's the date from `jvisualvm`:

JVM:
   char[]  19%
   java.lang.object   15.5%
   java.util.TreeMap$Entry  12%
   java.io.ObjectStreamClass$WeakClassKey   11%
   byte[]11%
   int[]   6%

main:
   char[]   24%
   byte[]   17%
   java.lang.object   14%
   java.util.TreeMap$Entry  10%
   java.io.ObjectStreamClass$WeakClassKey   10%
   int[]   6%


Heap size: 366Mb
Used heap: 85Mb

gvim


On 09/01/2014 04:32, Gary Trakhman wrote:

you're still missing some basics about java memory management.  In
another thread, I mentioned the java VM will take more memory than it
needs, that is because it prioritizes throughput over footprint.  There
are knobs for all of that.  It's not clear what's taking so much memory,
but it's certainly not luminus or clojure.  Use jvisualVM to find out
for sure instead of comparing apples to oranges.


On Wed, Jan 8, 2014 at 4:24 PM, gvim mailto:gvi...@gmail.com>> wrote:

On OS X Mountain Lion I just compared the memory footprint of 3
out-of-the-box web apps in these frameworks:

Clojure/Luminus:  152Mb (JVM) + 186Mb (main) = 338Mb

Ruby/Rails: 62Mb

Elixir (Erlang)/Weber: 32Mb

I was rather shocked, to say the least. Not to troll, it has made me
think again about deploying Clojure web apps on hosting platforms
with modest amounts RAM. I'm sure the figures for all 3 would
increase significantly once the web apps are fleshed out but that
probably applies equally to all 3 frameworks.

gvim


--
--
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+unsubscribe@__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+unsubscribe@__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.


--
--
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: New release of Light Table (which is now open source!)

[Tom Brooke]

Looks fantastic  - Thanks

On Wednesday, January 8, 2014 1:19:59 PM UTC-5, Chris Granger wrote:
>
> Hey Folks,
>
> We did a big release today which includes a lot of love for Clojure! We 
> also released all the source to Light Table, which has to be one of the 
> largest full ClojureScript applications out there. To read more about all 
> the goodness check out my blog post: 
> http://www.chris-granger.com/2014/01/07/light-table-is-open-source/
>
> And take a look at the source here: https://github.com/lighttable
>
> Cheers,
> Chris.
>

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

Re: Clojure/Luminus memory footprint

[Gary Trakhman]

what happens to the heap if you manually trigger a GC via the button?


On Thu, Jan 9, 2014 at 12:01 AM, gvim  wrote:

> Here's the date from `jvisualvm`:
>
> JVM:
>char[]  19%
>java.lang.object   15.5%
>java.util.TreeMap$Entry  12%
>java.io.ObjectStreamClass$WeakClassKey   11%
>byte[]11%
>int[]   6%
>
> main:
>char[]   24%
>byte[]   17%
>java.lang.object   14%
>java.util.TreeMap$Entry  10%
>java.io.ObjectStreamClass$WeakClassKey   10%
>int[]   6%
>
>
> Heap size: 366Mb
> Used heap: 85Mb
>
> gvim
>
>
>
> On 09/01/2014 04:32, Gary Trakhman wrote:
>
>> you're still missing some basics about java memory management.  In
>> another thread, I mentioned the java VM will take more memory than it
>> needs, that is because it prioritizes throughput over footprint.  There
>> are knobs for all of that.  It's not clear what's taking so much memory,
>> but it's certainly not luminus or clojure.  Use jvisualVM to find out
>> for sure instead of comparing apples to oranges.
>>
>>
>> On Wed, Jan 8, 2014 at 4:24 PM, gvim > > wrote:
>>
>> On OS X Mountain Lion I just compared the memory footprint of 3
>> out-of-the-box web apps in these frameworks:
>>
>> Clojure/Luminus:  152Mb (JVM) + 186Mb (main) = 338Mb
>>
>> Ruby/Rails: 62Mb
>>
>> Elixir (Erlang)/Weber: 32Mb
>>
>> I was rather shocked, to say the least. Not to troll, it has made me
>> think again about deploying Clojure web apps on hosting platforms
>> with modest amounts RAM. I'm sure the figures for all 3 would
>> increase significantly once the web apps are fleshed out but that
>> probably applies equally to all 3 frameworks.
>>
>> gvim
>>
>>
>> --
>> --
>> 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+unsubscribe@__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+unsubscribe@__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.
>>
>
> --
> --
> 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.
>

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

Re: New release of Light Table (which is now open source!)

[Stan Dyck]

On 01/08/2014 06:10 PM, Mark Engelberg wrote:


When I fired up Light Table a while back, I felt completely hamstrung 
-- I couldn't do anything the way I ordinarily would do it.  The 
notion of executing statements that live in a file didn't feel 
anything like the workflow I was used to.  It seemed distinctly weaker.


On top of that, at the time I tried it, Light Table couldn't properly 
handle long and lazy outputs from functions.  I also couldn't figure 
out how to observe anything that printed to stdout.  Because of that, 
I couldn't use most of the REPL tools I was used to using (e.g., 
doc/source/pprint/trace) and the features in Light Table didn't seem 
to be a compensation for having those tools.


With each new version of Light Table, I go through this process of 
thinking, "Hmmm, I wonder if they have a usable REPL yet."  I pop open 
Light Table, read the docs which talk about the Instarepl quick start 
and the live-code execution feature, no way to create a project from 
scratch, and no discussion of a project repl.  I shrug and say, "Guess 
they aren't seriously targeting Clojure development yet; seems like 
all the focus lately is on JavaScript and Python and underlying 
infrastructure code."  I shut it down and figure I'll try again in a 
few months.


This time, I got excited because the announcement said there was lots 
of "Clojure love" in this release.  Again, I didn't see anything 
obviously new relating to Clojure in the docs.  So I'm left wondering, 
"Does the Light Table team really think this current state is adequate 
for Clojure development?  If so, what am I missing?"  This prompted my 
earlier question.


I'm willing to accept that I might be underestimating the value of 
what is currently there, and will give it an earnest try.  I would 
also welcome detailed workflow stories of how other users interact 
with Light Table.

--


I don't know if I can answer your question, Mark but I think it is an 
interesting one. One suggestion I'd make is that you really shouldn't 
expect to do anything the way you ordinarily would. Maybe, but probably 
not. The point for me is to figure out what its differences are and how 
they might make me more productive.


I should say that, like you, have also played around with LightTable but 
don't use it regularly. I did attempt to use it exclusively for a 
project at work about a year ago. It wasn't easy, largely because this 
was before you could change the key bindings. Hard to undo muscle memory.


That aside, one of the things I liked the most I think was a style of 
workflow that I took to calling "spreadsheet programming." Think of a 
spreadsheet with lots of formulas as an application and the values in 
the various cells as the application state. The attraction of 
spreadsheets is that you can see the whole thing at once and you can 
manipulate state. You change a number here or there and watch as the 
entire thing updates itself. The problem has always been that you can't 
see the formulas unless you click on a cell. And even then only one at a 
time in a tiny window. This is why most spreadsheet applications are 
filled with errors.


With LightTable, I found I could achieve the same sort of thing except 
the formulas were all there in plain view also. Say I had a function 
that needed to do something. Using this style I would write the first 
draft of the function in an instarepl and then a set of calls to that 
function with various inputs below. I could then observe the results of 
all those calls as I modified the function. It was this instant feedback 
that I found productive and not as easy to duplicate with a regular REPL 
environment. Once I felt the function worked the way I wanted, I would 
generally move it into a file with its own namespace. At that point I 
could still get at it from my instarepl via a require as I continued to 
the next function.


As the results of my functions got more complex, I found the inline 
updating broke down. It starts to take up too much real estate and 
creates visual clutter. I think they do a better job with that now but 
I'm still evaluating that. My fix for this problem was put in a 
statement at the bottom of the instarepl that outputted results to a 
file. I then put that file on an emacs buffer on another screen with 
auto-revert-mode on. That really worked well for demos. I could 
demonstrate the DSL-ish code I was developing on an instarepl and the 
audience could see the results in my emacs buffer update as I 
manipulated the inputs. I guess that's similar to the proof of concept 
demos you saw in LightTable's early days but less graphical. In my case 
that was ok since my application was manipulating text.


Some of the other nits you brought up about not being able to create 
projects and the lack of tools are more or less valid, but I think they 
are mostly a function of application immaturity and a developer 
community that is still figuring it out. Steve Yegge wrote a blog post