Re: [ANN] Intro tutorial

2013-12-29 Thread Ronan BARZIC 
Am I the only one to have problem scrolling through the page or trying to 
go up and down after  clicking on the scroll bar ? I've tried with Firefox 
and Chrome and it is very frustating
Otherwise, nice work - I'm waiting for the next chapters

Ronan

On Saturday, December 28, 2013 11:30:17 PM UTC+1, Karsten Schmidt wrote:
>
> Dear all, 
>
> just wanted to briefly announce a new Clojure introduction tutorial 
> series with its first part (15k+ words) just been published: 
>
>
> http://www.creativeapplications.net/tutorials/introduction-to-clojure-part-1/ 
>
> Whereas this intro is purely focused on basics, the following ones 
> will deal with more aspects around data visualisation & generative 
> design, integration with Quil, OpenGL/CL... 
>
> Any feedback/constructive criticism is highly appreciated! 
>
> Best, K. 
> -- 
> Karsten Schmidt 
> http://thi.ng | http://postspectacular.com | http://toxiclibs.org 
>

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

Re: [ANN] Intro tutorial

2013-12-29 Thread Karsten Schmidt 
Hey, thanks & yes, there seems to be an issue with their syntax
highlighter taking quite a while to process the dozens of code blocks
on that page. Just give it a few seconds until the page has finished
loading before you start scrolling... Will check with the site owners
what can be done.

On 29 December 2013 08:35, Ronan BARZIC  wrote:
> Am I the only one to have problem scrolling through the page or trying to go
> up and down after  clicking on the scroll bar ? I've tried with Firefox and
> Chrome and it is very frustating
> Otherwise, nice work - I'm waiting for the next chapters
>
> Ronan
>
>
> On Saturday, December 28, 2013 11:30:17 PM UTC+1, Karsten Schmidt wrote:
>>
>> Dear all,
>>
>> just wanted to briefly announce a new Clojure introduction tutorial
>> series with its first part (15k+ words) just been published:
>>
>>
>> http://www.creativeapplications.net/tutorials/introduction-to-clojure-part-1/
>>
>> Whereas this intro is purely focused on basics, the following ones
>> will deal with more aspects around data visualisation & generative
>> design, integration with Quil, OpenGL/CL...
>>
>> Any feedback/constructive criticism is highly appreciated!
>>
>> Best, K.
>> --
>> Karsten Schmidt
>> http://thi.ng | http://postspectacular.com | http://toxiclibs.org



-- 
Karsten Schmidt
http://postspectacular.com | http://toxiclibs.org | http://toxi.co.uk

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

Re: [ANN] Intro tutorial

2013-12-29 Thread Zeynel 
I like it very much. Is there a pdf version?

On Saturday, December 28, 2013 6:30:17 PM UTC-4, Karsten Schmidt wrote:
>
> Dear all, 
>
> just wanted to briefly announce a new Clojure introduction tutorial 
> series with its first part (15k+ words) just been published: 
>
>
> http://www.creativeapplications.net/tutorials/introduction-to-clojure-part-1/ 
>
> Whereas this intro is purely focused on basics, the following ones 
> will deal with more aspects around data visualisation & generative 
> design, integration with Quil, OpenGL/CL... 
>
> Any feedback/constructive criticism is highly appreciated! 
>
> Best, K. 
> -- 
> Karsten Schmidt 
> http://thi.ng | http://postspectacular.com | http://toxiclibs.org 
>

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

How to debug this trace involving Korma

2013-12-29 Thread Zeynel 
The first lines of the trace says:

Failure to execute query with SQL:

SELECT "GUESTBOOK" .* FROM "GUESTBOOK" :: []
JdbcSQLException:
Message: Table "GUESTBOOK" not found; SQL statement

SELECT "GUESTBOOK".* FROM "GUESTBOOK" ...

I see that there is a "create-guestbook-table" in schema.clj

(defn create-guestbook-table []
  (sql/with-connection
db-spec
(sql/create-table
  :guestbook
  [:id "INTEGER PRIMARY KEY AUTO_INCREMENT"]
  [:timestamp :timestamp]
  [:name "varchar(30)"]
  [:message "varchar(200)"])
(sql/do-commands
  "CREATE INDEX timestamp_index ON guestbook (timestamp)")))

which is called by create-tables function underneath it

(defn create-tables
  "creates the database tables used by the application"
  []
  (create-guestbook-table))
  
  How can I find out why this table is not created?
  
  I copied the code from this tutorial 
http://www.luminusweb.net/docs/guestbook.md
  
  I am looking for help about how to read these traces and good practice to 
debug. This is just my first clojure project.

And these are the references and line numbers to .clj files in the trace 
that I could find:

db.clj line #21 

20 (defn get-messages []
21  (select guestbook))
  
home.clj line #34

33 (defn about-page []
34(GET "/" [] (home-page))

The entirety of the trace is copied below:

Failure to execute query with SQL:
SELECT "GUESTBOOK".* FROM "GUESTBOOK"  ::  []
JdbcSQLException:
 Message: Table "GUESTBOOK" not found; SQL statement:
SELECT "GUESTBOOK".* FROM "GUESTBOOK" [42102-174]
 SQLState: 42S02
 Error Code: 42102
org.h2.jdbc.JdbcSQLException: Table "GUESTBOOK" not found; SQL statement:
SELECT "GUESTBOOK".* FROM "GUESTBOOK" [42102-174]
  DbException.java:332 
org.h2.message.DbException.getJdbcSQLException
  DbException.java:172 org.h2.message.DbException.get
  DbException.java:149 org.h2.message.DbException.get
  Parser.java:4900 org.h2.command.Parser.readTableOrView
  Parser.java:1117 org.h2.command.Parser.readTableFilter
  Parser.java:1724 
org.h2.command.Parser.parseSelectSimpleFromPart
  Parser.java:1832 
org.h2.command.Parser.parseSelectSimple
  Parser.java:1718 org.h2.command.Parser.parseSelectSub
  Parser.java:1560 
org.h2.command.Parser.parseSelectUnion
  Parser.java:1548 org.h2.command.Parser.parseSelect
   Parser.java:415 org.h2.command.Parser.parsePrepared
   Parser.java:289 org.h2.command.Parser.parse
   Parser.java:261 org.h2.command.Parser.parse
   Parser.java:226 org.h2.command.Parser.prepareCommand
  Session.java:437 org.h2.engine.Session.prepareLocal
  Session.java:380 org.h2.engine.Session.prepareCommand
  JdbcConnection.java:1138 
org.h2.jdbc.JdbcConnection.prepareCommand
 JdbcPreparedStatement.java:70 
org.h2.jdbc.JdbcPreparedStatement.
   JdbcConnection.java:267 
org.h2.jdbc.JdbcConnection.prepareStatement
  jdbc.clj:474 clojure.java.jdbc/prepare-statement
   RestFn.java:425 clojure.lang.RestFn.invoke
  AFn.java:163 clojure.lang.AFn.applyToHelper
   RestFn.java:132 clojure.lang.RestFn.applyTo
  core.clj:621 clojure.core/apply
  jdbc.clj:670 clojure.java.jdbc/with-query-results*
db.clj:216 korma.db/exec-sql
db.clj:239 korma.db/do-query[fn]
  jdbc.clj:302 clojure.java.jdbc/with-connection*
db.clj:238 korma.db/do-query
  core.clj:476 korma.core/exec
 db.clj:21 guestbook.models.db/get-messages
   home.clj:12 guestbook.routes.home/home-page
   RestFn.java:397 clojure.lang.RestFn.invoke
   home.clj:34 guestbook.routes.home/fn
   core.clj:94 compojure.core/make-route[fn]
   core.clj:40 compojure.core/if-route[fn]
   core.clj:25 compojure.core/if-method[fn]
  core.clj:107 compojure.core/routing[fn]
 core.clj:2443 clojure.core/some
  core.clj:107 compojure.core/routing
   RestFn.java:139 clojure.lang.RestFn.applyTo
  core.clj:619 clojure.core/apply
  core.clj:112 compojure.core/routes[fn]
  core.clj:107 compojure.core/routing[fn]
 core.clj:2443 clojure.core/some
  core.clj:107 compojure.core/routing
   RestFn.java:139 clojure.lang.RestFn.applyTo

Re: [ANN] Intro tutorial

2013-12-29 Thread Karsten Schmidt 
No PDF version, but in the coming weeks we will put up a Git repo with
the original markdown sources & examples, you can build a PDF from
those. For now, couldn't you just print that page to a PDF file, no?

On 29 December 2013 11:42, Zeynel  wrote:
> I like it very much. Is there a pdf version?
>
>
> On Saturday, December 28, 2013 6:30:17 PM UTC-4, Karsten Schmidt wrote:
>>
>> Dear all,
>>
>> just wanted to briefly announce a new Clojure introduction tutorial
>> series with its first part (15k+ words) just been published:
>>
>>
>> http://www.creativeapplications.net/tutorials/introduction-to-clojure-part-1/
>>
>> Whereas this intro is purely focused on basics, the following ones
>> will deal with more aspects around data visualisation & generative
>> design, integration with Quil, OpenGL/CL...
>>
>> Any feedback/constructive criticism is highly appreciated!
>>
>> Best, K.
>> --
>> Karsten Schmidt
>> http://thi.ng | http://postspectacular.com | http://toxiclibs.org



-- 
Karsten Schmidt
http://postspectacular.com | http://toxiclibs.org | http://toxi.co.uk

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

Re: [ANN] Intro tutorial

2013-12-29 Thread Zeynel 
Oh, yes, true. I will print to PDF.

On Sunday, December 29, 2013 8:07:44 AM UTC-4, Karsten Schmidt wrote:
>
> No PDF version, but in the coming weeks we will put up a Git repo with 
> the original markdown sources & examples, you can build a PDF from 
> those. For now, couldn't you just print that page to a PDF file, no? 
>
> On 29 December 2013 11:42, Zeynel > 
> wrote: 
> > I like it very much. Is there a pdf version? 
> > 
> > 
> > On Saturday, December 28, 2013 6:30:17 PM UTC-4, Karsten Schmidt wrote: 
> >> 
> >> Dear all, 
> >> 
> >> just wanted to briefly announce a new Clojure introduction tutorial 
> >> series with its first part (15k+ words) just been published: 
> >> 
> >> 
> >> 
> http://www.creativeapplications.net/tutorials/introduction-to-clojure-part-1/ 
> >> 
> >> Whereas this intro is purely focused on basics, the following ones 
> >> will deal with more aspects around data visualisation & generative 
> >> design, integration with Quil, OpenGL/CL... 
> >> 
> >> Any feedback/constructive criticism is highly appreciated! 
> >> 
> >> Best, K. 
> >> -- 
> >> Karsten Schmidt 
> >> http://thi.ng | http://postspectacular.com | http://toxiclibs.org 
>
>
>
> -- 
> Karsten Schmidt 
> http://postspectacular.com | http://toxiclibs.org | http://toxi.co.uk 
>

-- 
-- 
You 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: Akka-like framework in Clojure ?

2013-12-29 Thread Joshua Ballanco 
On Saturday, December 28, 2013 at 6:05, kovas boguta wrote:
> The bottom line is that the definitive clojure distributed computing
> solution is yet to be invented, but there are a number of things out
> there including the aforementioned.
>  
> 1. clojure wrappers for Akka, for instance
>  
> https://github.com/jasongustafson/akka-clojure
>  
> (there are several others, of varying quality.. just search github / google)
>  
> 2. solutions implementing the idea of supervisor hierarchies, for instance
>  
> https://github.com/MichaelDrogalis/dire
>  
> (I believe there are other contenders in this category also)
>  
> 3. RPC libraries, like https://github.com/sunng87/slacker
>  
> 4. Batteries-included cluster-aware computing: http://immutant.org/

One more to add to that list:

5. Clojure integration with Vert.X: http://vertx.io 
https://github.com/vert-x/mod-lang-clojure

Vert.X has a lot of really interesting properties (so long as you’re willing to 
stay within the JVM) while remaining nicely lightweight. Clojure support is 
still very new, but it’s being written by one of the main authors of Immutant. 
Essentially, if you’re looking for distributed computing (not so much 
web-based, necessarily) but don’t want to lug around JBoss/WildFly, it’s a good 
alternative to Immutant.

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

[ANN] jvm.tools.analyzer 0.6.0 - *Breaking changes*

2013-12-29 Thread Ambrose Bonnaire-Sergeant 
Hi,

[org.clojure/jvm.tools.analyzer"0.6.0"]

To avoid any problems with the new analyzer contrib libraries,
the namespaces in jvm.tools.analyzer have been renamed.

See the 
CHANGELOG
.

Hopefully jvm.tools.analyzer will be gradually phased out as
tools.analyzer matures; this will probably be the last major release
of jvm.tools.analyzer.

Thanks,
Ambrose

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

protocols and overloading

2013-12-29 Thread Massimiliano Tomassoli 
What's the difference between protocols and simple overloading?
For instance, in C++ I could use structs for Clojure's datatypes and simple 
overloading for protocols.

-- 
-- 
You 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: protocols and overloading

2013-12-29 Thread Cedric Greevey 
On Sun, Dec 29, 2013 at 12:27 PM, Massimiliano Tomassoli  wrote:

> What's the difference between protocols and simple overloading?
>

Dynamic dispatch. Overloading uses just the static type for dispatch, so
this Java code:

aBase = new Base();
aDerived = new Derived();
aBase2 = aDerived;
something.foo(aBase);
something.foo(aBase2);
something.foo(aDerived);

will call the same version of foo the first two times, though the third
time it might call a different overload of foo (if there's a separate
foo(Derived x) method in the class of "something").

Dynamic dispatch uses the runtime type. In Java you get this when you call

aBase.bar();
aBase2.bar();
aDerived.ber();

and (if Derived overrides bar) get the Derived version of bar called for
the second as well as the third calls, because aBase2's runtime type is
Derived.

Clojure protocols dispatch on the runtime type of the first argument, much
like (non-static) Java methods (with "this" considered to be the first
argument).

Clojure multimethods can dispatch on the runtime type (or even other
characteristics) of *all* of the arguments.

I don't think anything Clojure does dispatches on the static type of
anything, only on the number of arguments and sometimes on runtime types or
other information, with the exception of some built-in inline functions
(arithmetic +, for example) on primitive numeric arguments, and possibly
also macros that encounter primitives.

Indeed, primitive locals are just about the only static types to be found
in Clojure (notwithstanding core.typed, whose use AFAIK does not influence
the dispatch semantics of anything).

-- 
-- 
You 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: bug in clojure.zip when calling next on empty list node?

2013-12-29 Thread Lee Spector 

I realize that many people are on holiday, but I'm hoping to get some clarity 
about how to proceed with respect to this issue in the near future.

Can anyone tell if I'm right that this is a bug in clojure.zip? If so, then is 
the right thing to do to post an issue on JIRA?

I've re-included the crux of the issue [slightly edited and recombined] below.

Thanks,

 -Lee


On Dec 21, 2013, at 11:49 AM, Lee Spector wrote:
> When I step through a zipper made from a nested list via seq-zip, I get 
> extraneous nils after processing a nested (). 
> 
> Is this somehow expected behavior, or a bug, or am I misunderstanding 
> something fundamental?
> 
> The problem seems to arise only when an nested empty list is present, not 
> other nested lists [... deleted ...]
> 
> Here's an illustration, stepping through '(() 0) with next and printing the 
> node at each step:
> 
> (loop [z (zip/seq-zip '(() 0))]
>  (if (zip/end? z)
>:done
>(do (println (zip/node z))
>  (recur (zip/next z)
> 
> That produces:
> 
> (() 0)
> ()
> nil
> 0
> :done
> 
> I don't expect the nil to be there.

> [That is,] when traversing '(() 0) with zip/next, one should first visit the 
> root, then (), and then 0. But what actually happens is that between then () 
> and the 0 one lands on a non-existent nil node. So one ends up visiting 4 
> nodes when there are only 3, and the extra one is a nil.

-- 
-- 
You 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: protocols and overloading

2013-12-29 Thread Massimiliano Tomassoli 
On Sunday, December 29, 2013 7:05:28 PM UTC+1, Cedric Greevey wrote:
>
> On Sun, Dec 29, 2013 at 12:27 PM, Massimiliano Tomassoli <
> kiuh...@gmail.com > wrote:
>
>> What's the difference between protocols and simple overloading?
>>
>
> Dynamic dispatch. Overloading uses just the static type for dispatch, so 
> this Java code:
>
> aBase = new Base();
> aDerived = new Derived();
> aBase2 = aDerived;
> something.foo(aBase);
> something.foo(aBase2);
> something.foo(aDerived);
>
> will call the same version of foo the first two times, though the third 
> time it might call a different overload of foo (if there's a separate 
> foo(Derived x) method in the class of "something").
>
> Dynamic dispatch uses the runtime type. In Java you get this when you call
>
> aBase.bar();
> aBase2.bar();
> aDerived.ber();
>
> and (if Derived overrides bar) get the Derived version of bar called for 
> the second as well as the third calls, because aBase2's runtime type is 
> Derived.
>

OK. I was reading about the "Expression Problem" and how it can supposedly 
be easily solved in Clojure. That should mean that Clojure is a very 
powerful language. But I can do the same thing in C++. If I use simple 
structures or classes without methods, I can solve the "Expression Problem" 
the same way as Clojure does. Moreover, I can build dynamic dispatching 
into C++ just by including a property "type" in each structure and by using 
templates and maybe a few macros to add some syntactic sugar. Doesn't this 
prove that C++ is at least as powerful as Clojure w.r.t. the "Expression 
Problem"?

>

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

2013-12-29 Thread Zeynel 
I know this an old thread but here the author says that he deprecated 
Enclojure https://groups.google.com/d/msg/enclojure/TNngOAAoIyE/9cKOk_zEquEJ 
Is this still true?

On Sunday, October 27, 2013 7:51:39 PM UTC-3, James Reeves wrote:
>
> Compojure isn't deprecated. What made you think it was?
>
> - James
>
>
> On 27 October 2013 17:43, Scott M >wrote:
>
>> Ring seems well maintained, but Noir and Compojure are marked deprecated.
>>
>> Can anyone lay out a Clojure Web library "stack" (up to templating) that 
>> is current and maintained?
>>
>> Any and all sagacious wisdom greatly appreciated - thanks! 
>>
>> - Scott
>>
>> -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

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

Re: protocols and overloading

2013-12-29 Thread Timothy Baldridge 
Not mentioned in Cedric's post are two other important things:

Protocols can be extended to existing types. For example:

(defprotocol IType
  (type-as-string [x]))

(extend-protocol IType
  String
  (type-as-string [x] "string")
  Integer
  (type-as-string [x] "integer"))

=> (type-as-string 42)
"integer"

Here we are adding new methods to "sealed" closed classes that already
exist in the JVM. We never modify these classes, we simply extend our
protocol to them.

Secondly, all protocol functions are namespaced. This allows us to extend
classes without fear of overwriting existing methods. This then is more
powerful than monkey patching in Ruby or Python as the resulting method is
more like 42.user_type-as-string(). Clojure's namespace system then allows
you to refer to one method or the other just as you would any normal
functions.

The net result is that protocols completely solves the expression problem,
and in a way that doesn't require tons of boilerplate code (like the
visitor pattern, for example).

Timothy


On Sun, Dec 29, 2013 at 12:38 PM, Massimiliano Tomassoli  wrote:

> On Sunday, December 29, 2013 7:05:28 PM UTC+1, Cedric Greevey wrote:
>
>> On Sun, Dec 29, 2013 at 12:27 PM, Massimiliano Tomassoli <
>> kiuh...@gmail.com> wrote:
>>
>>> What's the difference between protocols and simple overloading?
>>>
>>
>> Dynamic dispatch. Overloading uses just the static type for dispatch, so
>> this Java code:
>>
>> aBase = new Base();
>> aDerived = new Derived();
>> aBase2 = aDerived;
>> something.foo(aBase);
>> something.foo(aBase2);
>> something.foo(aDerived);
>>
>> will call the same version of foo the first two times, though the third
>> time it might call a different overload of foo (if there's a separate
>> foo(Derived x) method in the class of "something").
>>
>> Dynamic dispatch uses the runtime type. In Java you get this when you call
>>
>> aBase.bar();
>> aBase2.bar();
>> aDerived.ber();
>>
>> and (if Derived overrides bar) get the Derived version of bar called for
>> the second as well as the third calls, because aBase2's runtime type is
>> Derived.
>>
>
> OK. I was reading about the "Expression Problem" and how it can supposedly
> be easily solved in Clojure. That should mean that Clojure is a very
> powerful language. But I can do the same thing in C++. If I use simple
> structures or classes without methods, I can solve the "Expression Problem"
> the same way as Clojure does. Moreover, I can build dynamic dispatching
> into C++ just by including a property "type" in each structure and by using
> templates and maybe a few macros to add some syntactic sugar. Doesn't this
> prove that C++ is at least as powerful as Clojure w.r.t. the "Expression
> Problem"?
>
>>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> 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: protocols and overloading

2013-12-29 Thread Mark Engelberg 
The expression problem is about what kinds of additions and extensions you
can easily make *without modifying or recompiling the existing codebase.*

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

Why is "add-watch" still in alpha?

2013-12-29 Thread larry google groups 
add-watch was alpha in Clojure 1.2:

http://clojuredocs.org/clojure_core/1.2.0/clojure.core/add-watch


it is still alpha now, in Clojure 1.5: 

http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/add-watch

I am curious what the plan is for add-watch? 

I was just reading this: 

http://nurkiewicz.blogspot.com/2013/03/promises-and-futures-in-clojure.html

and this struck me: 


And here is where the greatest disappointment arrives: neither 
future
 nor promise  in 
Clojure supports listening for completion/failure asynchronously. ... As 
much as I love Clojure concurrency primitives like STM and agents, futures 
feel a bit underdeveloped. Lack of event-driven, asynchronous callbacks 
that are invoked whenever futures completes (notice that 
add-watch doesn't 
work futures - and is still in alpha) greatly reduces the usefulness of a 
future object. We can no longer:

   - map futures to transform result value asynchronously
   - chain futures
   - translate list of futures to future of list
   - ...and much more, see how Akka does 
it
and Guava to some 
extent

That's a shame and since it's not a technical difficulty but only a missing 
API, I hope to see support for completion listeners soon. 



So, I am curious if we will see support for completion listeners. Or is 
there a feeling that stuff like core.async has addressed some of this and 
nothing more is needed? 


-- 
-- 
You 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: is there a tutorial about working at the REPL?

2013-12-29 Thread larry google groups 
> If it can't find the file, 
> `clojure.java.io/resource` returns 
nil; and (slurp 
> nil) throws an IllegalArgumentException, which doesn't seem to be the 
error 
> you're getting. 


Thanks for that. But the app has no problem reading the schema.edn file 
when I start the app with: 

java -jar admin-1-standalone.jar

So why would it have trouble reading the file when I'm in the repl?



On Sunday, December 29, 2013 12:55:04 AM UTC-5, John Mastro wrote:
>
> Hi Larry, 
>
> > 4.) load whatever file holds the (main-) function that starts the app. 
> So for 
> > me, for instance, it might be: (load-file "src/admin/core.clj") 
>
> I don't think the `load-file` should be necessary. Do things not work if 
> you 
> omit it? 
>
> The code on disk when you jacked in will already have been loaded, so you 
> should only need to re-evaluate it (whether through cider/nrepl.el, 
> `load-file`, or what have you) if you've made subsequent changes. I tend 
> to use 
> `cider-eval-defun-at-point`, `cider-eval-last-sexp`, or 
> `cider-eval-region` to 
> evaluate just the code I've changed rather than reloading the whole file. 
> (Actually, lately I've been using the `tools.namespace`[1] approach a lot, 
> but 
> that's probably a separate topic). 
>
> (Cider[2], by the way, is just nrepl.el's new name). 
>
> > But when I want to work on this app at the REPL, the app seems unable to 
> find 
> > the schema.edn file. You can see my REPL session below. The function 
> > (initiate-forms) has this line: (read-string (slurp (
> clojure.java.io/resource 
> > "config/schema.edn"))) 
>
> I'm not positive, but I don't think the issue is that it can't find 
> "config/schema.edn". What's the result of (clojure.java.io/resource 
> "config/schema.edn")? 
>
> If it can't find the file, 
> `clojure.java.io/resource`returns nil; and 
> (slurp 
> nil) throws an IllegalArgumentException, which doesn't seem to be the 
> error 
> you're getting. 
>
> [1] https://github.com/clojure/tools.namespace 
> [2] https://github.com/clojure-emacs/cider 
>
> - 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.

Re: Why is "add-watch" still in alpha?

2013-12-29 Thread Cedric Greevey 
On Sun, Dec 29, 2013 at 4:24 PM, larry google groups <
lawrencecloj...@gmail.com> wrote:

> And here is where the greatest disappointment arrives: neither 
> future
>  nor promise  in
> Clojure supports listening for completion/failure asynchronously. ... As
> much as I love Clojure concurrency primitives like STM and agents, futures
> feel a bit underdeveloped. Lack of event-driven, asynchronous callbacks
> that are invoked whenever futures completes (notice that 
> add-watch doesn't
> work futures - and is still in alpha) greatly reduces the usefulness of a
> future object. We can no longer:
>
>- map futures to transform result value asynchronously
>- chain futures
>- translate list of futures to future of list
>- ...and much more, see how Akka does 
> it
> and Guava to some 
> extent
>
> That's a shame and since it's not a technical difficulty but only a
> missing API, I hope to see support for completion listeners soon.
>
>
>
> So, I am curious if we will see support for completion listeners. Or is
> there a feeling that stuff like core.async has addressed some of this and
> nothing more is needed?
>

Well, core.async directly subsumes the entire functionality of promises.
And adds watch capability:

(let [c (chan)] ; instead of (promise)
  (go ; prefer thread if the long calculation is REALLY long
(>! c (long calculation here)) ; instead of (future (deliver ...))
(close! c))
  (let [d (go
 (let [x (! c (long calculation here))
(close! c))
  (let [d (promise)]
(go
  (let [x (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: is there a tutorial about working at the REPL?

2013-12-29 Thread Jay Fields 
make the app work with 'lein run' and it'll work in the repl as well.

On Sun, Dec 29, 2013 at 4:30 PM, larry google groups
 wrote:
>> If it can't find the file, `clojure.java.io/resource` returns nil; and
>> (slurp
>> nil) throws an IllegalArgumentException, which doesn't seem to be the
>> error
>> you're getting.
>
>
> Thanks for that. But the app has no problem reading the schema.edn file when
> I start the app with:
>
> java -jar admin-1-standalone.jar
>
> So why would it have trouble reading the file when I'm in the repl?
>
>
>
> On Sunday, December 29, 2013 12:55:04 AM UTC-5, John Mastro wrote:
>>
>> Hi Larry,
>>
>> > 4.) load whatever file holds the (main-) function that starts the app.
>> > So for
>> > me, for instance, it might be: (load-file "src/admin/core.clj")
>>
>> I don't think the `load-file` should be necessary. Do things not work if
>> you
>> omit it?
>>
>> The code on disk when you jacked in will already have been loaded, so you
>> should only need to re-evaluate it (whether through cider/nrepl.el,
>> `load-file`, or what have you) if you've made subsequent changes. I tend
>> to use
>> `cider-eval-defun-at-point`, `cider-eval-last-sexp`, or
>> `cider-eval-region` to
>> evaluate just the code I've changed rather than reloading the whole file.
>> (Actually, lately I've been using the `tools.namespace`[1] approach a lot,
>> but
>> that's probably a separate topic).
>>
>> (Cider[2], by the way, is just nrepl.el's new name).
>>
>> > But when I want to work on this app at the REPL, the app seems unable to
>> > find
>> > the schema.edn file. You can see my REPL session below. The function
>> > (initiate-forms) has this line: (read-string (slurp
>> > (clojure.java.io/resource
>> > "config/schema.edn")))
>>
>> I'm not positive, but I don't think the issue is that it can't find
>> "config/schema.edn". What's the result of (clojure.java.io/resource
>> "config/schema.edn")?
>>
>> If it can't find the file, `clojure.java.io/resource` returns nil; and
>> (slurp
>> nil) throws an IllegalArgumentException, which doesn't seem to be the
>> error
>> you're getting.
>>
>> [1] https://github.com/clojure/tools.namespace
>> [2] https://github.com/clojure-emacs/cider
>>
>> - 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.

-- 
-- 
You 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: Why is "add-watch" still in alpha?

2013-12-29 Thread Cedric Greevey 
Actually, one simple way to use core.async to asynchronously watch a future
or a promise, or *any* other blocking-derefable thingy, for delivery, is
just to throw a (thread (do-something-with @thingy)) in your code
somewhere. The thread will block until the thingy is ready, and then do
whatever. Meanwhile your usual code can just @thingy like it would have
anyway somewhere, without its behavior there being changed.

This can be done anywhere the thingy is visible. What can't be done with
any of these (including core.async used natively) is to catch errors
without being able to put (or amend) a try block into the producer end of
things. This suggests that anything where consumers might want notification
of failure should employ a separate error channel (core.async) or out of
band values (future, promise, core.async) produced in a try block. For
example (future (try (/ a b) (catch ArithmeticException _ :error))) where
the consumer can look for :error instead of a number when derefing (in this
case, this would be caused by the edge case b = 0).



On Sun, Dec 29, 2013 at 5:01 PM, Cedric Greevey  wrote:

> On Sun, Dec 29, 2013 at 4:24 PM, larry google groups <
> lawrencecloj...@gmail.com> wrote:
>
>> And here is where the greatest disappointment arrives: neither 
>> future
>>  nor promise  in
>> Clojure supports listening for completion/failure asynchronously. ... As
>> much as I love Clojure concurrency primitives like STM and agents, futures
>> feel a bit underdeveloped. Lack of event-driven, asynchronous callbacks
>> that are invoked whenever futures completes (notice that 
>> add-watch doesn't
>> work futures - and is still in alpha) greatly reduces the usefulness of a
>> future object. We can no longer:
>>
>>- map futures to transform result value asynchronously
>>- chain futures
>>- translate list of futures to future of list
>>- ...and much more, see how Akka does 
>> it
>> and Guava to some 
>> extent
>>
>> That's a shame and since it's not a technical difficulty but only a
>> missing API, I hope to see support for completion listeners soon.
>>
>>
>>
>> So, I am curious if we will see support for completion listeners. Or is
>> there a feeling that stuff like core.async has addressed some of this and
>> nothing more is needed?
>>
>
> Well, core.async directly subsumes the entire functionality of promises.
> And adds watch capability:
>
> (let [c (chan)] ; instead of (promise)
>   (go ; prefer thread if the long calculation is REALLY long
> (>! c (long calculation here)) ; instead of (future (deliver ...))
> (close! c))
>   (let [d (go
>  (let [x ((println "Special delivery!" x) ; Watch!
>x))]
> (
> The channel here is used just like a promise: the first go asynchronously
> does some calculation and delivers a result to it, then closes it, which
> results in behavior like a delivered promise, i.e. it can't be delivered to
> again. One could just use ( available), like @some-promise. The second go block shows one bit of added
> power: you can add an asynchronous watch for the result to appear. The go
> block takes it from c as soon as it's available, executes the watch (in
> this case a simple println), and then evaluates to the delivered value.
> Letting [d (go ...)] results in d being bound to a channel that will get
> this value pushed onto it (and then get closed) when the go block
> terminates, and ( evaluates to the result.
>
> The one thing "missing" is that whereas you can @some-promise repeatedly
> to retrieve the value once it's delivered, you can't ( without getting the delivered value once and then nils thereafter. But you
> could change it slightly to combine channels *with* promise:
>
> (let [c (chan)]
>   (go
> (>! c (long calculation here))
> (close! c))
>   (let [d (promise)]
> (go
>   (let [x ( (println "Special delivery!" x)
> (deliver d x)))]
> @d))
>
> Now d is a promise, but it's delivered by a go block that can also
> asynchronously watch for completion. But leaving d as a channel might be
> better. You can always put the result in another kind of container once
> it's delivered, and deref that repeatedly, and by leaving d a channel you
> can use alt! and timeout on this channel, for example, to add timeout
> behavior to your checking for delivery.
>
> Futures used locally can be "watched asynchronously" trivially: instead of
> (future (long calculation here)) you have (future (let [x (long calculation
> here)] (hey-x-got-finished! x) x)). The (hey-x-got-finished! x) call will
> take place in the future's thread. If you don't want it blocking th

Re: protocols and overloading

2013-12-29 Thread Cedric Greevey 
On Sun, Dec 29, 2013 at 4:11 PM, Timothy Baldridge wrote:

> Not mentioned in Cedric's post are two other important things:
>
> Protocols can be extended to existing types.
>

These are important for the Expression Problem, but not for the OP's query
as originally stated, which simply asked for the contrast with overloading.
That contrast is dynamic vs. static dispatch. As for C++ being able to
solve the Expression Problem and thus being "equally powerful", well, both
languages are also Turing complete. But which will generally let you be
more expressive, with less ceremony and verbosity? Which has templates and
macros that are unhygienic and a bugbear to work with, and which has macros
that are very safe and clean?

(Incidentally, it was template woes that eventually broke the camel's back
for me with C++. I gave up on C++ when I found that one of the most
widely-used free software C++ compilers would give duplicate definition
errors at link time if the same template was used with the same parameters
in two separate compilation units, and the developers had *no sane fix or
workaround* or even an ETA on a fix...imagine if importing java.util.Map
and using Map in Foo.java and also importing java.util.Map
and using Map in Bar.java and then running something using
both classes Foo and Bar had resulted in linkage errors instead of two
classes coexisting at runtime that both used Maps. Java 1.5
would have never gotten off the ground! But this C++ compiler -- and yes,
it was then-current gcc -- would do exactly that if you #included hash_map
and used hash_map in two
compilation units.)

-- 
-- 
You 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 debug this trace involving Korma

2013-12-29 Thread Sean Corfield 
Reading that tutorial, it looks like it expects you to call
(create-tables) manually via the REPL.

On Sun, Dec 29, 2013 at 3:47 AM, Zeynel  wrote:
> The first lines of the trace says:
>
> Failure to execute query with SQL:
>
> SELECT "GUESTBOOK" .* FROM "GUESTBOOK" :: []
> JdbcSQLException:
> Message: Table "GUESTBOOK" not found; SQL statement
>
> SELECT "GUESTBOOK".* FROM "GUESTBOOK" ...
>
> I see that there is a "create-guestbook-table" in schema.clj
>
> (defn create-guestbook-table []
>   (sql/with-connection
> db-spec
> (sql/create-table
>   :guestbook
>   [:id "INTEGER PRIMARY KEY AUTO_INCREMENT"]
>   [:timestamp :timestamp]
>   [:name "varchar(30)"]
>   [:message "varchar(200)"])
> (sql/do-commands
>   "CREATE INDEX timestamp_index ON guestbook (timestamp)")))
>
> which is called by create-tables function underneath it
>
> (defn create-tables
>   "creates the database tables used by the application"
>   []
>   (create-guestbook-table))
>
>   How can I find out why this table is not created?
>
>   I copied the code from this tutorial
> http://www.luminusweb.net/docs/guestbook.md
>
>   I am looking for help about how to read these traces and good practice to
> debug. This is just my first clojure project.
>
> And these are the references and line numbers to .clj files in the trace
> that I could find:
>
> db.clj line #21
>
> 20 (defn get-messages []
> 21  (select guestbook))
>
> home.clj line #34
>
> 33 (defn about-page []
> 34(GET "/" [] (home-page))
>
> The entirety of the trace is copied below:
>
> Failure to execute query with SQL:
> SELECT "GUESTBOOK".* FROM "GUESTBOOK"  ::  []
> JdbcSQLException:
>  Message: Table "GUESTBOOK" not found; SQL statement:
> SELECT "GUESTBOOK".* FROM "GUESTBOOK" [42102-174]
>  SQLState: 42S02
>  Error Code: 42102
> org.h2.jdbc.JdbcSQLException: Table "GUESTBOOK" not found; SQL statement:
> SELECT "GUESTBOOK".* FROM "GUESTBOOK" [42102-174]
>   DbException.java:332
> org.h2.message.DbException.getJdbcSQLException
>   DbException.java:172 org.h2.message.DbException.get
>   DbException.java:149 org.h2.message.DbException.get
>   Parser.java:4900 org.h2.command.Parser.readTableOrView
>   Parser.java:1117 org.h2.command.Parser.readTableFilter
>   Parser.java:1724
> org.h2.command.Parser.parseSelectSimpleFromPart
>   Parser.java:1832
> org.h2.command.Parser.parseSelectSimple
>   Parser.java:1718 org.h2.command.Parser.parseSelectSub
>   Parser.java:1560
> org.h2.command.Parser.parseSelectUnion
>   Parser.java:1548 org.h2.command.Parser.parseSelect
>Parser.java:415 org.h2.command.Parser.parsePrepared
>Parser.java:289 org.h2.command.Parser.parse
>Parser.java:261 org.h2.command.Parser.parse
>Parser.java:226 org.h2.command.Parser.prepareCommand
>   Session.java:437 org.h2.engine.Session.prepareLocal
>   Session.java:380 org.h2.engine.Session.prepareCommand
>   JdbcConnection.java:1138
> org.h2.jdbc.JdbcConnection.prepareCommand
>  JdbcPreparedStatement.java:70
> org.h2.jdbc.JdbcPreparedStatement.
>JdbcConnection.java:267
> org.h2.jdbc.JdbcConnection.prepareStatement
>   jdbc.clj:474 clojure.java.jdbc/prepare-statement
>RestFn.java:425 clojure.lang.RestFn.invoke
>   AFn.java:163 clojure.lang.AFn.applyToHelper
>RestFn.java:132 clojure.lang.RestFn.applyTo
>   core.clj:621 clojure.core/apply
>   jdbc.clj:670 clojure.java.jdbc/with-query-results*
> db.clj:216 korma.db/exec-sql
> db.clj:239 korma.db/do-query[fn]
>   jdbc.clj:302 clojure.java.jdbc/with-connection*
> db.clj:238 korma.db/do-query
>   core.clj:476 korma.core/exec
>  db.clj:21 guestbook.models.db/get-messages
>home.clj:12 guestbook.routes.home/home-page
>RestFn.java:397 clojure.lang.RestFn.invoke
>home.clj:34 guestbook.routes.home/fn
>core.clj:94 compojure.core/make-route[fn]
>core.clj:40 compojure.core/if-route[fn]
>core.clj:25 compojure.core/if-method[fn]
>   core.clj:107 compojure.core/routing[fn]
>  core.clj:2443 clojure.core/some
>   core.clj:107 compojure.core/routing
>RestFn.java:139 clojure.lang.RestFn.applyTo
>   core.clj:619 clojure.core/ap

Re: protocols and overloading

2013-12-29 Thread Sean Corfield 
That must have been a long time ago? That problem was solved well
before I left the C++ committee in '99 and gcc was normally pretty
good at tracking the emerging standard at the time...

But, yes, the template compilation model and it's impact on linking
modules that specialized the same template had been problematic
earlier on.

On Sun, Dec 29, 2013 at 2:30 PM, Cedric Greevey  wrote:
> (Incidentally, it was template woes that eventually broke the camel's back
> for me with C++. I gave up on C++ when I found that one of the most
> widely-used free software C++ compilers would give duplicate definition
> errors at link time if the same template was used with the same parameters
> in two separate compilation units, and the developers had *no sane fix or
> workaround* or even an ETA on a fix...imagine if importing java.util.Map and
> using Map in Foo.java and also importing java.util.Map and
> using Map in Bar.java and then running something using both
> classes Foo and Bar had resulted in linkage errors instead of two classes
> coexisting at runtime that both used Maps. Java 1.5 would
> have never gotten off the ground! But this C++ compiler -- and yes, it was
> then-current gcc -- would do exactly that if you #included hash_map and used
> hash_map in two compilation
> units.)

-- 
-- 
You 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: protocols and overloading

2013-12-29 Thread Cedric Greevey 
Yeah, it was sometime in the 90s. The only workaround I could think of was
maybe to create a single compilation unit for template use, and there
derive a trivial subclass of each used template specialization, then use
that subclass elsewhere in lieu of the template. Needless to say, not a
solution that scales nicely to any substantial team effort, because of the
coordination problem involved in discovering when two team members are
specializing the same template the same way (hopefully, earlier than when
linkage errors break the build!), then adding it to the central file of
template specialization subclasses, then communicating to *everyone* to use
this new class instead of a particular template with particular parameters
... and once everyone's including the same unit (with these subclasses)
there'd be a giant temptation to start shoving everything else widely
referenced into there as well, including the kitchen sink, until it turned
into a "god object" with all of the headaches *that* entails. And sooner or
later the thing would grow unwieldy, leading to duplications bloating
generated code size; or we'd have one single unit using some template
directly at the end, also causing duplication. And if all went *well* the
end result would contain not tidy vectors and similarly regular and
understandable C++, but vec_of_int and other nonstandard class names
instead, leading to head-scratching among the maintenance programmers.
Doubly so if the names ended up being less than fully self-explanatory,
such as if hash_map was
used to derive a trivial extension that got named person_salary because of
its use in employee_directory.cpp and payroll.cpp ... and then wound up
used also in orderform.cpp for SKU-quantity mapping, and in
storelocator.cpp for store location-number of widgets in stock, and etc.,
later on down the line when other string to integer mappings started being
needed.

On Sun, Dec 29, 2013 at 6:04 PM, Sean Corfield wrote:

> That must have been a long time ago? That problem was solved well
> before I left the C++ committee in '99 and gcc was normally pretty
> good at tracking the emerging standard at the time...
>
> But, yes, the template compilation model and it's impact on linking
> modules that specialized the same template had been problematic
> earlier on.
>
> On Sun, Dec 29, 2013 at 2:30 PM, Cedric Greevey 
> wrote:
> > (Incidentally, it was template woes that eventually broke the camel's
> back
> > for me with C++. I gave up on C++ when I found that one of the most
> > widely-used free software C++ compilers would give duplicate definition
> > errors at link time if the same template was used with the same
> parameters
> > in two separate compilation units, and the developers had *no sane fix or
> > workaround* or even an ETA on a fix...imagine if importing java.util.Map
> and
> > using Map in Foo.java and also importing java.util.Map
> and
> > using Map in Bar.java and then running something using
> both
> > classes Foo and Bar had resulted in linkage errors instead of two classes
> > coexisting at runtime that both used Maps. Java 1.5 would
> > have never gotten off the ground! But this C++ compiler -- and yes, it
> was
> > then-current gcc -- would do exactly that if you #included hash_map and
> used
> > hash_map in two compilation
> > units.)
>
> --
> --
> You 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: Why is "add-watch" still in alpha?

2013-12-29 Thread Juha Syrjälä 
Hi,

According to this thread 
https://groups.google.com/forum/#!topic/clojure/zM6cbhuBNxY add-watch is no 
longer marked alpha in Clojure 1.6-alpha3

On Sunday, December 29, 2013 11:24:07 PM UTC+2, larry google groups wrote:
>
> add-watch was alpha in Clojure 1.2:
>
> http://clojuredocs.org/clojure_core/1.2.0/clojure.core/add-watch
>
>
> it is still alpha now, in Clojure 1.5: 
>
>
> http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/add-watch
>
> I am curious what the plan is for add-watch? 
>
> I was just reading this: 
>
> http://nurkiewicz.blogspot.com/2013/03/promises-and-futures-in-clojure.html
>
> and this struck me: 
>
>
> And here is where the greatest disappointment arrives: neither 
> future
>  nor promise  in 
> Clojure supports listening for completion/failure asynchronously. ... As 
> much as I love Clojure concurrency primitives like STM and agents, futures 
> feel a bit underdeveloped. Lack of event-driven, asynchronous callbacks 
> that are invoked whenever futures completes (notice that 
> add-watch doesn't 
> work futures - and is still in alpha) greatly reduces the usefulness of a 
> future object. We can no longer:
>
>- map futures to transform result value asynchronously
>- chain futures
>- translate list of futures to future of list
>- ...and much more, see how Akka does 
> it
> and Guava to some 
> extent
>
> That's a shame and since it's not a technical difficulty but only a 
> missing API, I hope to see support for completion listeners soon. 
>
>
>
> So, I am curious if we will see support for completion listeners. Or is 
> there a feeling that stuff like core.async has addressed some of this and 
> nothing more is needed? 
>
>
>

-- 
-- 
You 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 debug this trace involving Korma

2013-12-29 Thread Zeynel 
Yes, I was having problems with the emacs 
repl 
http://stackoverflow.com/questions/20828985/compilerexception-java-lang-runtimeexception-unable-to-resolve-symbol-cloju
 
after I created the tables I did not get the error.

On Sunday, December 29, 2013 6:43:59 PM UTC-4, Sean Corfield wrote:
>
> Reading that tutorial, it looks like it expects you to call 
> (create-tables) manually via the REPL. 
>
> On Sun, Dec 29, 2013 at 3:47 AM, Zeynel > 
> wrote: 
> > The first lines of the trace says: 
> > 
> > Failure to execute query with SQL: 
> > 
> > SELECT "GUESTBOOK" .* FROM "GUESTBOOK" :: [] 
> > JdbcSQLException: 
> > Message: Table "GUESTBOOK" not found; SQL statement 
> > 
> > SELECT "GUESTBOOK".* FROM "GUESTBOOK" ... 
> > 
> > I see that there is a "create-guestbook-table" in schema.clj 
> > 
> > (defn create-guestbook-table [] 
> >   (sql/with-connection 
> > db-spec 
> > (sql/create-table 
> >   :guestbook 
> >   [:id "INTEGER PRIMARY KEY AUTO_INCREMENT"] 
> >   [:timestamp :timestamp] 
> >   [:name "varchar(30)"] 
> >   [:message "varchar(200)"]) 
> > (sql/do-commands 
> >   "CREATE INDEX timestamp_index ON guestbook (timestamp)"))) 
> > 
> > which is called by create-tables function underneath it 
> > 
> > (defn create-tables 
> >   "creates the database tables used by the application" 
> >   [] 
> >   (create-guestbook-table)) 
> > 
> >   How can I find out why this table is not created? 
> > 
> >   I copied the code from this tutorial 
> > http://www.luminusweb.net/docs/guestbook.md 
> > 
> >   I am looking for help about how to read these traces and good practice 
> to 
> > debug. This is just my first clojure project. 
> > 
> > And these are the references and line numbers to .clj files in the trace 
> > that I could find: 
> > 
> > db.clj line #21 
> > 
> > 20 (defn get-messages [] 
> > 21  (select guestbook)) 
> > 
> > home.clj line #34 
> > 
> > 33 (defn about-page [] 
> > 34(GET "/" [] (home-page)) 
> > 
> > The entirety of the trace is copied below: 
> > 
> > Failure to execute query with SQL: 
> > SELECT "GUESTBOOK".* FROM "GUESTBOOK"  ::  [] 
> > JdbcSQLException: 
> >  Message: Table "GUESTBOOK" not found; SQL statement: 
> > SELECT "GUESTBOOK".* FROM "GUESTBOOK" [42102-174] 
> >  SQLState: 42S02 
> >  Error Code: 42102 
> > org.h2.jdbc.JdbcSQLException: Table "GUESTBOOK" not found; SQL 
> statement: 
> > SELECT "GUESTBOOK".* FROM "GUESTBOOK" [42102-174] 
> >   DbException.java:332 
> > org.h2.message.DbException.getJdbcSQLException 
> >   DbException.java:172 org.h2.message.DbException.get 
> >   DbException.java:149 org.h2.message.DbException.get 
> >   Parser.java:4900 
> org.h2.command.Parser.readTableOrView 
> >   Parser.java:1117 
> org.h2.command.Parser.readTableFilter 
> >   Parser.java:1724 
> > org.h2.command.Parser.parseSelectSimpleFromPart 
> >   Parser.java:1832 
> > org.h2.command.Parser.parseSelectSimple 
> >   Parser.java:1718 
> org.h2.command.Parser.parseSelectSub 
> >   Parser.java:1560 
> > org.h2.command.Parser.parseSelectUnion 
> >   Parser.java:1548 org.h2.command.Parser.parseSelect 
> >Parser.java:415 
> org.h2.command.Parser.parsePrepared 
> >Parser.java:289 org.h2.command.Parser.parse 
> >Parser.java:261 org.h2.command.Parser.parse 
> >Parser.java:226 
> org.h2.command.Parser.prepareCommand 
> >   Session.java:437 
> org.h2.engine.Session.prepareLocal 
> >   Session.java:380 
> org.h2.engine.Session.prepareCommand 
> >   JdbcConnection.java:1138 
> > org.h2.jdbc.JdbcConnection.prepareCommand 
> >  JdbcPreparedStatement.java:70 
> > org.h2.jdbc.JdbcPreparedStatement. 
> >JdbcConnection.java:267 
> > org.h2.jdbc.JdbcConnection.prepareStatement 
> >   jdbc.clj:474 
> clojure.java.jdbc/prepare-statement 
> >RestFn.java:425 clojure.lang.RestFn.invoke 
> >   AFn.java:163 clojure.lang.AFn.applyToHelper 
> >RestFn.java:132 clojure.lang.RestFn.applyTo 
> >   core.clj:621 clojure.core/apply 
> >   jdbc.clj:670 
> clojure.java.jdbc/with-query-results* 
> > db.clj:216 korma.db/exec-sql 
> > db.clj:239 korma.db/do-query[fn] 
> >   jdbc.clj:302 
> clojure.java.jdbc/with-connection* 
> > db.clj:238 korma.db/do-query 
> >   core.clj:476 korma.core/exec 
> >  db.clj:21 guestbook.models.db/get-messages 
> >home.clj:12 guestbook.routes.home/home-page 
> >

Re: is there a tutorial about working at the REPL?

2013-12-29 Thread gaz jones 
There are at least some keyboard shortcuts you should be familiar with for
loading / compiling namespaces. Look a the "Using the REPL" section of
this: http://clojure-doc.org/articles/tutorials/emacs.html


On Sat, Dec 28, 2013 at 7:38 PM, larry google groups <
lawrencecloj...@gmail.com> wrote:

>
> I have been working with Clojure now some of the time for the last 18
> months, so I am no longer a complete noob. But I still have many questions
> about how to work at the REPL. In particular, I don't understand how the
> REPL interacts with the class path.
>
> I have an app that is working. When I need to make changes to it, my
> workflow goes like this:
>
> 1.) start emacs
>
> 2.) open a file in the project that I want to work in. I usually start by
> opening up the project.clj fie.
>
> 3.) type nrepl-jack-in to launch the repl.
>
> 4.) load whatever file holds the (main-) function that starts the app. So
> for me, for instance, it might be:
>
> (load-file “src/admin/core.clj”)
>
> 5.) switch to that namespace:
> (in-ns ‘admin.core)
>
> 6.) call the function that starts my app: (main-). Give it any arguments
> that it needs.
>
> 7.) do work. Moving around inside of the project tends to consist of a lot
> of loading a file:
>
> (load-file “src/admin/controller.clj”)
>
> and then switching to the namespace:
>
> (in-ns ‘admin.controller)
>
> However, I have a config file at:
>
> /resources/config/schema.edn
>
> If I open a terminal, cd to the top level of the directories where this
> app lives, and then run "lein uberjar" I get an app that works just fine if
> I do:
>
> java -jar admin-1-standalone.jar
>
> But when I want to work on this app at the REPL, the app seems unable to
> find the schema.edn file. You can see my REPL session below. The
> function (initiate-forms) has this line:
>
>  (read-string (slurp (clojure.java.io/resource "config/schema.edn")))
>
> This should run when the app starts and then it is stored in
> secretary/interactions, but below you can see that secretary/interactions
> is empty.
>
> Why does this work when I run the app from the command line? What do I
> need to do to get this work when I'm in the REPL? I am assuming the problem
> here has something to do with the classpath, please tell me if I'm wrong.
>
>
>
> admin.controller> (load-file "src/admin/core.clj")
> #'admin.core/-main
> admin.controller> (in-ns 'admin.core)
> #
> admin.core> (ns-publics 'admin.core)
> {-main #'admin.core/-main}
> admin.core> (-main "35000")
> App 'TMA admin' is starting.
> If no port is specified then we will default to port 34000.
> You can set this app to production mode, where debugging output to the
> terminal is surpressed, by starting it like this:
> java -jar target/admin-1-standalone.jar  30001 production
> #
> admin.core> (load-file "src/admin/secretary.clj")
> {:dire/error-handlers {java.lang.NullPointerException
> #},
> :ns #, :name process-some-fetch-function,
> :arglists ([function-to-call-to-get-data-from-monger map-for-queries]),
> :column 1, :line 124, :file "admin/queries.clj"}
> admin.core> (in-ns 'admin.secretary)
> #
> admin.secretary> interactions
> #
> admin.secretary> @interactions
> {}
> admin.secretary> (load-file "src/admin/startup.clj")
> #'admin.startup/start-channels
> admin.secretary> (in-ns 'admin.startup)
> #
> admin.startup> (ns-publics 'admin.startup)
> {start-channels #'admin.startup/start-channels, initiate-forms
> #'admin.startup/initiate-forms, connect-to-database
> #'admin.startup/connect-to-database, set-the-current-debugging-level
> #'admin.startup/set-the-current-debugging-level}
> admin.startup> (start-channels)
> nil
> admin.startup> (initiate-forms)
> cannot read object
>
> --
> --
> You 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