date:20100421

Re: clojure.contrib.sql insert id

2010-04-21 Thread Saul Hazledine

On Apr 20, 8:51 pm, Remco van 't Veer  wrote:
> I am doing the following after an insert for a Derby database:
>
>   (sql/with-query-results res
>     ["VALUES IDENTITY_VAL_LOCAL()"]
>     (first (vals (first res
>
> For MySQL it would be something like:
>
>   (sql/with-query-results res
>     ["SELECT LAST_INSERT_ID()"]
>     (first (vals (first res
>

Thanks Remco. I'm using H2 and its seems possible to do something
similar by accessing the INFORMATION_SCHEMA. However, this also feels
wrong to me so I'm trying the JDBC route which should be more
consistent across databases. My first working attempt is at:

http://gist.github.com/373564#file_sql.clj

It contains a alternative to insert-records called 'insert-record'
which returns a database id and a macro that wraps up multiple inserts
in a transaction. The macro doesn't feel very idiomatic so I'd welcome
any feedback on how to change it.

-
extended.sql/insert-record
([table record])
  Equivalent of clojure.contrib.sql/insert-records that only inserts a
single
   record but returns the autogenerated id of that record if
available.

-
extended.sql/insert-with-id
([db & table-records])
Macro
  Insert records within a single transaction into the database
described by
   the given db spec. The record format is :table  { record-hash }.
   The record hashes can optionally access a hashmap 'id' which holds
the
   autogenerated ids of previous inserts keyed by the table name. e.g.

  (insert-with-id db-spec
  :department {:name "xfiles"
   :location "secret"}
  :employee   {:department (id :department)
   :name "Mr X"})

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

Re: clojure.contrib.sql insert id

2010-04-21 Thread Remco van 't Veer

Nice!  That's a lot better than depending on some quirky sql construct.

Thanks,
Remco


Saul Hazledine  writes:

> On Apr 20, 8:51 pm, Remco van 't Veer  wrote:
>> I am doing the following after an insert for a Derby database:
>>
>>   (sql/with-query-results res
>>     ["VALUES IDENTITY_VAL_LOCAL()"]
>>     (first (vals (first res
>>
>> For MySQL it would be something like:
>>
>>   (sql/with-query-results res
>>     ["SELECT LAST_INSERT_ID()"]
>>     (first (vals (first res
>>
>
> Thanks Remco. I'm using H2 and its seems possible to do something
> similar by accessing the INFORMATION_SCHEMA. However, this also feels
> wrong to me so I'm trying the JDBC route which should be more
> consistent across databases. My first working attempt is at:
>
> http://gist.github.com/373564#file_sql.clj
>
> It contains a alternative to insert-records called 'insert-record'
> which returns a database id and a macro that wraps up multiple inserts
> in a transaction. The macro doesn't feel very idiomatic so I'd welcome
> any feedback on how to change it.
>
> -
> extended.sql/insert-record
> ([table record])
>   Equivalent of clojure.contrib.sql/insert-records that only inserts a
> single
>record but returns the autogenerated id of that record if
> available.
>
> -
> extended.sql/insert-with-id
> ([db & table-records])
> Macro
>   Insert records within a single transaction into the database
> described by
>the given db spec. The record format is :table  { record-hash }.
>The record hashes can optionally access a hashmap 'id' which holds
> the
>autogenerated ids of previous inserts keyed by the table name. e.g.
>
>   (insert-with-id db-spec
>   :department {:name "xfiles"
>:location "secret"}
>   :employee   {:department (id :department)
>:name "Mr X"})

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

Re: clojure.contrib.sql insert id

2010-04-21 Thread Joost

On Apr 21, 11:48 am, Remco van 't Veer  wrote:
> Nice!  That's a lot better than depending on some quirky sql construct.

Agreed. There's just one potential issue (which is the same issue I
have with
clojure.contrib.sql): it doesn't quote the column or table names,
meaning you
can't use such nice column keys as :user-id

I smashed all of it into my modified version of clojure.contrib.sql:

http://gist.github.com/373677

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
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

Try + finally question

2010-04-21 Thread ka

Hi,

I'm using an API to connect to a server which does not provide
constructors, just static methods to get & close connections.

How can I do something like ...

(try
  (let [conn (API/getConnection ..)]
())
  (catch ..)
  (finally (if conn (API/closeConnection conn

Problem is that conn is unavailable in the finally context.

Is there any easy workaround which doesn't involve defing a global
conn.

- 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

duck-streams missing from clojure-contrib.jar file

2010-04-21 Thread Neal

Hi,

I'm new to Clojure.  I've been trying to go through the Programming
Clojure book and have run into a problem that I hope someone can fix.

I'm trying to use duck-streams, but it is missing from the clojure-
contrib JAR file (at least in build #81).  I have listed the contents
of the JAR file and confirmed that it is not in there.

All the documentation that I read seems to indicate that duck-streams
is not deprecated.

Thanks for any help,

Neal

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
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

Arguments for < and > et al

2010-04-21 Thread Bill Allen

I've been writing a program that requires the use of java.util.Calendar and
its descendent java.util.GregorianCalendar. One thing I'd hoped to do was
compare two Calendar objects with <, but the compiler complained that the
arguments to < didn't inherit from Number which was a surprise to me because
Calendar does inherit from java.lang.Comparable which in java land would be
sufficient to enable it to be compared with other members of its class using
the built in java comparison operators. Since I know that clojure has other
operations that deal with comparable, I assume this is a conscious decision,
but I question why it should be so.

Regards,
Bill

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

Re: Interesting Facebook blog post on Concurrency (mentions Clojure)

2010-04-21 Thread Carlos Bueno

H! :D -- Clojure uses MVCC, which may help with this.
http://en.wikipedia.org/wiki/Multiversion_concurrency_control

But as Hickey points out, no one really knows yet because there aren't
enough high-core machines doing real work in the field.
http://groups.google.com/group/clojure/msg/cd3e77afb75441d8

I put that second sentence in more as a joke than a Deep Insight; it's
a reference to a silly song I like called "The Sweater Song":
"If you want to destroy my sweater / Hold this thread as I walk away."

Cheers,
  Carlos

On Apr 13, 12:02 am, Baishampayan Ghose  wrote:
> Hi,
>
> This is an interesting article on the problems associated with
> concurrency and some of the current solutions.
>
> http://www.facebook.com/notes/facebook-engineering/a-dismal-guide-to-...
>
> It mentions Clojure for a bit and says this about the general idea
> behind STMs -
>
> "... STM has its own special problems, like how to perform those
> commit/abort/retry cycles efficiently on thousands of threads. It's fun
> to imagine pathological conflict scenarios in which long chains of
> transactions unravel like a cheap sweater."
>
> Would anyone like to comment on how that affects the Clojure STM (if at
> all)?
>
> Regards,
> BG
>
> --
> Baishampayan Ghose 

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

Re: Try + finally question

2010-04-21 Thread Alex Osborne

ka  writes:

> How can I do something like ...
>
> (try
>   (let [conn (API/getConnection ..)]
> ())
>   (catch ..)
>   (finally (if conn (API/closeConnection conn
>
> Problem is that conn is unavailable in the finally context.

Why not just have two try blocks?

(try
 (let [conn (API/getConnection ..)]
   (try
()
(finally (API/closeConnection conn
 (catch ...))

For these sorts of things I usually try to use with-open, or if
with-open is not applicable do my own similar macro:

(defmacro with-api-connection [conn-sym arg1 arg2 & body]
  `(let [~conn-sym (API/getConnection ~arg1 ~arg2)]
 (try
  ~...@body
  (finally (API/closeConnection ~conn-sym)

So then you never forget to close the connection:

(try
 (with-api-connection conn ...
   (... do something with conn ...))
 (catch ...))

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

Re: duck-streams missing from clojure-contrib.jar file

2010-04-21 Thread Meikel Brandmeyer

Hi,

On 21 Apr., 01:37, Neal  wrote:

> All the documentation that I read seems to indicate that duck-streams
> is not deprecated.

c.c.ducks-streams is now named c.c.io.

Sincerely
Meikel

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

Re: duck-streams missing from clojure-contrib.jar file

2010-04-21 Thread Alex Osborne

Hi Neal,

Neal  writes:

> I'm trying to use duck-streams, but it is missing from the clojure-
> contrib JAR file (at least in build #81).  I have listed the contents
> of the JAR file and confirmed that it is not in there.

It sounds like you're using a 1.2 pre-release snapshot build of
clojure-contrib.  There's currently some refactoring going on to better
organize contrib, now that it's a little more mature.  Most of
clojure.contrib.duck-streams has now become clojure.contrib.io.

I suggest you use the stable 1.1 releases of both Clojure and contrib
for your initial learning as it will better match the book.  When 1.2 is
released stable I'm sure there will be a document written that explains
the differences.

I really wish the 1.1.0 release builds were more prominently linked on
the clojure.org website, but you can download them here: 

http://build.clojure.org/releases/org/clojure/clojure/1.1.0/clojure-1.1.0.jar
http://build.clojure.org/releases/org/clojure/clojure-contrib/1.1.0/clojure-contrib-1.1.0.jar

Hope that helps,

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

Slides for short (45 minutes) presentation of clojure for java devs

2010-04-21 Thread Laurent PETIT

Hello,

I've consulted a lot of already made presentations of clojure.
They are great, but I guess they may not suit my needs because it
seems to me that either:
  * they are more 1 1/2 to 2 hours talks than 45 minutes
  * they assume the "public" will not be relunctant to some terms like
"Lisp", "Functional Programming" and directly present these as
advantages

My goal is to raise interest into clojure in the mind of a public of
people having used java for a long time. They may have Scala already
in their "radar", but not clojure, or may have seen it and immediately
dismissed it for what seemed to them good reasons (mainly aversion for
lisp syntax), though we all know this is not true after the "normal"
adaptation period.

Say this presentation could be the presentation that leads people, at
its end, asking you for giving all those great other presentations
already available that I mentioned before ...

Any references I missed that already solve my problem ? :-)

Thanks in advance,

-- 
Laurent

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

Re: Arguments for < and > et al

2010-04-21 Thread Stuart Halloway

The built-in Java comparison operators don't honor Comparable either.   
In Clojure, it's about keeping (pure number) math fast.


If you are doing any nontrivial date work, I recommend you look at clj- 
time (http://github.com/clj-sys/clj-time), a Clojure wrapper for Joda  
Time. Then, if you really want "<" and ">" to work, you can define  
them in your own namespace to wrap clj-time's "after?" and "before?".


Stu

I've been writing a program that requires the use of  
java.util.Calendar and its descendent java.util.GregorianCalendar.  
One thing I'd hoped to do was compare two Calendar objects with <,  
but the compiler complained that the arguments to < didn't inherit  
from Number which was a surprise to me because Calendar does inherit  
from java.lang.Comparable which in java land would be sufficient to  
enable it to be compared with other members of its class using the  
built in java comparison operators. Since I know that clojure has  
other operations that deal with comparable, I assume this is a  
conscious decision, but I question why it should be so.


Regards,
Bill

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

Re: Try + finally question

2010-04-21 Thread ka

Thanks for the reply Alex,

I thought of 2 try blocks, but seems over engineering doesn't it ?  I
actually need to open 2 connections simultaneously, which would amount
to 3 nested try blocks. The whole code gets cluttered with all these
try finally (and one catch) statements.

  (try
(let [conn1 (API1/getConnection ..)]
  (try
(let [conn2 (API2/getConnection ..)]
  (try
( ... Do something with conn1 conn2 )
(finally
  (API2/closeConnection conn2
(finally
  (API1/closeConnection conn1
(catch Exception ex (.printStackTrace ex)))

The macro solution looks good.  But with 2 different APIs for 2
connections, I would need to write 2 macros right?

(defmacro with-api1-connection [conn-sym arg1 arg2 & body]
  `(let [~conn-sym (API1/getConnection ~arg1 ~arg2)]
 (try
  ~...@body
  (finally (API1/closeConnection ~conn-sym)

(defmacro with-api2-connection [conn-sym arg1 arg2 arg3 & body]
  `(let [~conn-sym (API2/getConnection ~arg1 ~arg2 ~arg3)]
 (try
  ~...@body
  (finally (API2/closeConnection ~conn-sym)

Also coming back to the original requirement, wanted to know what are
the problems with providing support (somehow) for something like -

(try
  (let [conn1 (API1/getConnection ..)
 conn2 (API2/getConnection ..)]
())
  (catch ..)
  (finally
(if conn1 (API1/closeConnection conn1))
(if conn2 (API2/closeConnection conn2


Coming from Java, this would be implemented as -

Connection1 conn1 = null;
Connection2 conn2 = null;
try {
  conn1 = API1.getConnection ..;
  conn2 = API2.getConnection ..;
  ...
}
catch (){}
finally {
  if (conn1 != null)
API1.closeConnection(conn1);
  if (conn2 != null)
API2.closeConnection(conn2);
}

I agree that this code doesn't look good from a purist pov, but any
issues besides that?

- Thanks!

On Apr 21, 4:58 pm, Alex Osborne  wrote:
> ka  writes:
> > How can I do something like ...
>
> > (try
> >   (let [conn (API/getConnection ..)]
> >     ())
> >   (catch ..)
> >   (finally (if conn (API/closeConnection conn
>
> > Problem is that conn is unavailable in the finally context.
>
> Why not just have two try blocks?
>
> (try
>  (let [conn (API/getConnection ..)]
>    (try
>     ()
>     (finally (API/closeConnection conn
>  (catch ...))
>
> For these sorts of things I usually try to use with-open, or if
> with-open is not applicable do my own similar macro:
>
> (defmacro with-api-connection [conn-sym arg1 arg2 & body]
>   `(let [~conn-sym (API/getConnection ~arg1 ~arg2)]
>      (try
>       ~...@body
>       (finally (API/closeConnection ~conn-sym)
>
> So then you never forget to close the connection:
>
> (try
>  (with-api-connection conn ...
>    (... do something with conn ...))
>  (catch ...))
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group 
> athttp://groups.google.com/group/clojure?hl=en

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

Re: duck-streams missing from clojure-contrib.jar file

2010-04-21 Thread Douglas Philips


On 2010 Apr 21, at 8:11 AM, Alex Osborne wrote:

I suggest you use the stable 1.1 releases of both Clojure and contrib
for your initial learning as it will better match the book.  When  
1.2 is
released stable I'm sure there will be a document written that  
explains

the differences.


That isn't as helpful as you might think.

(I'm using 1.1, as conveniently provided by macports.)

Nothing that I can find on either clojure.org or the contrib site http://richhickey.github.com/clojure-contrib/ 
 says what version it is/applies-to.


How would I know if I'm using the stable 1.1 release that I need to  
replace clojure.contrib.seq with clojure.contrib.seq-utils, or  
clojure.contrib.io with clojure.contrib.duck-stream?


http://richhickey.github.com/clojure-contrib/io-api.html doesn't say:
   This document applies to 1.2 (pending), for 1.1 or older see: 
nor:
   This document applies to 1.2 (pending), it was renamed from  
clojure.contrib.duck-stream



--Doug

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

Re: Try + finally question

2010-04-21 Thread Mark J. Reed

On Wed, Apr 21, 2010 at 9:06 AM, ka  wrote:

> Connection1 conn1 = null;
> Connection2 conn2 = null;
> try {
>  conn1 = API1.getConnection ..;
>  conn2 = API2.getConnection ..;
>  ...
> }

You can't do that without using atoms or something, because you're assigning
to conn1 and conn2 twice.  That's not legal in Clojure because what "let"
gives you aren't variables, but local constants.

One solution would be to add a new construct to the language:

(try-let [bindings] (body) (catch...) (finally...))

where any exception during evaluation of the [bindings] would be caught just
as if it happened inside the body, and of course the bound variables would
be visible to both the catch blocks and the finally block.

It could be implemented as a macro that duplicated the catch/finally blocks
within and outside a let...

-- 
Mark J. Reed 

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

Re: duck-streams missing from clojure-contrib.jar file

2010-04-21 Thread Stuart Halloway

The second level header tells you the branch (e.g. master). On the
left hand side is a list of branches (so you can click on e.g. 1.1.x).

Some ways I see this might be better:

(1) make clear what master currently equals (right now it is 1.2 alpha)
(2) highlight the branch info more with css
(3) push the branch info into the top-level header (and page title)
(4) The overview section for c.c.io could tell about the lineage back
to 1.1.

Which of these (or what else?) would have helped you the most?

Stu

On 2010 Apr 21, at 8:11 AM, Alex Osborne wrote:

I suggest you use the stable 1.1 releases of both Clojure and contrib
for your initial learning as it will better match the book. When
1.2 is
released stable I'm sure there will be a document written that
explains

the differences.

That isn't as helpful as you might think.

(I'm using 1.1, as conveniently provided by macports.)

Nothing that I can find on either clojure.org or the contrib site http://richhickey.github.com/clojure-contrib/
says what version it is/applies-to.

How would I know if I'm using the stable 1.1 release that I need to
replace clojure.contrib.seq with clojure.contrib.seq-utils, or
clojure.contrib.io with clojure.contrib.duck-stream?

http://richhickey.github.com/clojure-contrib/io-api.html doesn't say:
This document applies to 1.2 (pending), for 1.1 or older see:
nor:
This document applies to 1.2 (pending), it was renamed from
clojure.contrib.duck-stream

--Doug

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

Re: Try + finally question

2010-04-21 Thread Laurent PETIT

Hi,

Something I don't understand: if the call to (API/getConnection ...)
fails, there is nothing to close, right ?

So for the problem of ensuring that any open connection is always
closed, the following pattern seems enough:

(try
  (let [conn (API/getConnection ..)]
 XXX)
  (finally (API/closeConnection conn)))

In XXX you can do your business job, maybe catching exceptions, etc.,
but that is not the same intent as ensuring pairs of open/close calls
in any case.

Smart java frameworks such as SpringFramework do the exact same thing
by using Interface callbacks encapsulating the XXX "real interesting
code".

The less verbose way of doing this is clojure's with-open macro.
Though you would have, as Alex pointed out, to create your own variant
of with-open to accomodate your particular API for closing the
connection.

Or, if you use master, you could write the protocol-aware version of
with-open :-)


2010/4/21 ka :
> Hi,
>
> I'm using an API to connect to a server which does not provide
> constructors, just static methods to get & close connections.
>
> How can I do something like ...
>
> (try
>  (let [conn (API/getConnection ..)]
>    ())
>  (catch ..)
>  (finally (if conn (API/closeConnection conn
>
> Problem is that conn is unavailable in the finally context.
>
> Is there any easy workaround which doesn't involve defing a global
> conn.
>
> - 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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Try + finally question

2010-04-21 Thread Laurent PETIT

Oh, also see the source code for with-open :
http://github.com/richhickey/clojure/blob/master/src/clj/clojure/core.clj#L2542

and also note that it allows you to declare bindings for opening
connections in sequence, and will take care of closing them in the
reverse order.

And to answer your question about writing 2 macros if you have
different APIs, no no :

  * either use protocols if you work on the master branch
  * either use multimethods

that is, use polymorphism :-)

2010/4/21 Laurent PETIT :
> Hi,
>
> Something I don't understand: if the call to (API/getConnection ...)
> fails, there is nothing to close, right ?
>
> So for the problem of ensuring that any open connection is always
> closed, the following pattern seems enough:
>
> (try
>  (let [conn (API/getConnection ..)]
>     XXX)
>  (finally (API/closeConnection conn)))
>
> In XXX you can do your business job, maybe catching exceptions, etc.,
> but that is not the same intent as ensuring pairs of open/close calls
> in any case.
>
> Smart java frameworks such as SpringFramework do the exact same thing
> by using Interface callbacks encapsulating the XXX "real interesting
> code".
>
> The less verbose way of doing this is clojure's with-open macro.
> Though you would have, as Alex pointed out, to create your own variant
> of with-open to accomodate your particular API for closing the
> connection.
>
> Or, if you use master, you could write the protocol-aware version of
> with-open :-)
>
>
> 2010/4/21 ka :
>> Hi,
>>
>> I'm using an API to connect to a server which does not provide
>> constructors, just static methods to get & close connections.
>>
>> How can I do something like ...
>>
>> (try
>>  (let [conn (API/getConnection ..)]
>>    ())
>>  (catch ..)
>>  (finally (if conn (API/closeConnection conn
>>
>> Problem is that conn is unavailable in the finally context.
>>
>> Is there any easy workaround which doesn't involve defing a global
>> conn.
>>
>> - 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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Try + finally question

2010-04-21 Thread Mark J. Reed

On Wed, Apr 21, 2010 at 9:37 AM, Laurent PETIT wrote:

> Hi,
>
> Something I don't understand: if the call to (API/getConnection ...)
> fails, there is nothing to close, right ?
>
> So for the problem of ensuring that any open connection is always
> closed, the following pattern seems enough:
>
> (try
>  (let [conn (API/getConnection ..)]
>  XXX)
>  (finally (API/closeConnection conn)))
>

That would be great, but it doesn't work, because "conn" doesn't exist any
more by the time you get to the finally block. That's the problem being
addressed in this thread.

So you can do this:

(let [conn (API/getConnection ...)]
   (try
  XXX
   (finally (API/closeConnection conn

But then any exception thrown by API/getConnection is not caught.

So you have to do this:

(try
(let [conn (API/getConnection ...)]
  (try
XXX
  (finally (API/closeConnection conn
   (catch ...))

But that still won't work if the catch block also needs access to "conn".
 So you wind up with something like this:

(try
(let [conn (API/getConnection ...)]
  (try
XXX
  (catch ExceptionAfterConnect x (do-something-with conn))
  (finally (API/closeConnection conn
   (catch .ExceptionDuringConnect x (do-something-without-conn

-- 
Mark J. Reed 

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

Re: Try + finally question

2010-04-21 Thread Laurent PETIT

2010/4/21 Mark J. Reed :
> On Wed, Apr 21, 2010 at 9:37 AM, Laurent PETIT 
> wrote:
>>
>> Hi,
>>
>> Something I don't understand: if the call to (API/getConnection ...)
>> fails, there is nothing to close, right ?
>>
>> So for the problem of ensuring that any open connection is always
>> closed, the following pattern seems enough:
>>
>> (try
>>  (let [conn (API/getConnection ..)]
>>     XXX)
>>  (finally (API/closeConnection conn)))

Of course, My code was wrong, and I meant


  (let [conn (API/getConnection ..)]
(try
  XXX
  (finally (API/closeConnection conn)))

And really, catching exceptions thrown by API/getConnection is not in
the problem domain of ensuring balanced pairs of opened/closed
connections, e.g. should be outside the abstraction you put in place
for handling this (e.g. with-open).

Ensuring that opened connections are closed is a resource (I/O)
management problem.
Handling the case where you were not able to open a connection is an
application problem. You might place the try/catch right around the
let, have a global handling very high in the call stack, or even have
no try/catch at all.

HTH,

-- 
Laurent

>
> That would be great, but it doesn't work, because "conn" doesn't exist any
> more by the time you get to the finally block. That's the problem being
> addressed in this thread.
> So you can do this:
> (let [conn (API/getConnection ...)]
>    (try
>       XXX
>    (finally (API/closeConnection conn
> But then any exception thrown by API/getConnection is not caught.
>
> So you have to do this:
> (try
>     (let [conn (API/getConnection ...)]
>       (try
>         XXX
>       (finally (API/closeConnection conn
>    (catch ...))
> But that still won't work if the catch block also needs access to "conn".
>  So you wind up with something like this:
> (try
>     (let [conn (API/getConnection ...)]
>       (try
>         XXX
>       (catch ExceptionAfterConnect x (do-something-with conn))
>       (finally (API/closeConnection conn
>    (catch .ExceptionDuringConnect x (do-something-without-conn
> --
> Mark J. Reed 
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> 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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Try + finally question

2010-04-21 Thread Alex Osborne

ka  writes:

> The whole code gets cluttered with all these try finally (and one
> catch) statements.
>
>   (try
> (let [conn1 (API1/getConnection ..)]
>   (try
> (let [conn2 (API2/getConnection ..)]
>   (try
> ( ... Do something with conn1 conn2 )
> (finally
>   (API2/closeConnection conn2
> (finally
>   (API1/closeConnection conn1
> (catch Exception ex (.printStackTrace ex)))

I guess the main difference in this compared to your java example is the
levels of nesting.  This may look messy but it's semantically exactly
what you're trying to express.

> The macro solution looks good.  But with 2 different APIs for 2
> connections, I would need to write 2 macros right?
>
> (defmacro with-api1-connection [conn-sym arg1 arg2 & body]
>   `(let [~conn-sym (API1/getConnection ~arg1 ~arg2)]
>  (try
>   ~...@body
>   (finally (API1/closeConnection ~conn-sym)
>
> (defmacro with-api2-connection [conn-sym arg1 arg2 arg3 & body]
>   `(let [~conn-sym (API2/getConnection ~arg1 ~arg2 ~arg3)]
>  (try
>   ~...@body
>   (finally (API2/closeConnection ~conn-sym)

You could make things more general:

(with-cleanup [conn1 (API1/getConnection ...) API1/closeConnection
   conn2 (API2/openConnection ...) #(.disconnect %)]
 ...)

I'll leave implementation as an exercise, it's not much more complicated
than the previous ones, the main trick would just be to make the macro
recursive, have it expand into:

(let [conn1 (API1/getConnection ...)]
  (try
(with-cleanup [conn2 (API2/openConnection ...) #(.disconnect %)]
  ...)
(finally
  (API1/closeConnection conn1

I'd probably start with a signature like this:

(defmacro with-cleanup [[sym create cleanup & more] & body]
  ...)

Take a look at the source for with-open if you get stuck.

> Coming from Java, this would be implemented as -
>
> Connection1 conn1 = null;
> Connection2 conn2 = null;
> try {
>   conn1 = API1.getConnection ..;
>   conn2 = API2.getConnection ..;
>   ...
> }
> catch (){}
> finally {
>   if (conn1 != null)
> API1.closeConnection(conn1);
>   if (conn2 != null)
> API2.closeConnection(conn2);
> }
>
> I agree that this code doesn't look good from a purist pov, but any
> issues besides that?

The problem here is that this breaks lexical scope, conn1 and
conn2 aren't defined outside their let block.  The Java example dodges
this with mutation.  Python/Ruby/JavaScript etc dodge it by having
special scoping rules: variables are scoped to functions rather than the
enclosing block.

Clojure's opinion, as I understand it, is that it's not worthwhile
introducing mutation or special scoping rules simply to avoid some
nesting, when we have perfectly good tools (macros) for doing purely
syntactic transformations and removing boilerplate.

There's nothing semantically wrong with nesting, it's just harder
to read.  The Clojure idiom for reducing nesting is usually to use a
macro like ->, ->> or with-open to flatten it.  In this case those
aren't applicable, so I suggest defining your own.

I'm not sure I phrased that clearly, please let me know if I'm not
making sense. :-)

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

Re: Try + finally question

2010-04-21 Thread Tassilo Horn

On Wednesday 21 April 2010 15:06:40 ka wrote:

Hi!

> The macro solution looks good.  But with 2 different APIs for 2
> connections, I would need to write 2 macros right?

No, not really.  You could also make the symbols for the API class an
additional arg to the macro, like:

 (defmacro with-api-connection [conn-sym api arg1 arg2 & body]
   `(let [~conn-sym (. ~api getConnection ~arg1 ~arg2)]
  (try
   ~...@body
   (finally (. ~api closeConnection ~conn-sym)

but then the macre application would be longer.

  (with-api-connection [c API1 "localhost" 12345]
(with-api-connection [c2 API2 "141.55.22.1" 13321]
  (do-stuff-with c c2))
(do-stuff-with c))

Bye,
Tassilo

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

Re: duck-streams missing from clojure-contrib.jar file

2010-04-21 Thread Alex Osborne

Stuart Halloway  writes:

> The second level header tells you the branch (e.g. master). On the
> left hand side is a list of branches (so you can click on e.g. 1.1.x).
>
> Some ways I see this might be better:
>
> (1) make clear what master currently equals (right now it is 1.2 alpha)
> (2) highlight the branch info more with css
> (3) push the branch info into the top-level header (and page title)
> (4) The overview section for c.c.io could tell about the lineage back
> to 1.1.

I think it might also help to make the stable versions the default
view.  I think people new to the language should really be guided to
using the stable releases and documentation rather than snapshots, as
the snapshots may well be in flux and cause lots of confusion.
People choosing to use the bleeding edge git snapshots will know what
the branches are and can specify the one they want.

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

Re: duck-streams missing from clojure-contrib.jar file

2010-04-21 Thread Laurent PETIT

2010/4/21 Alex Osborne :
> Stuart Halloway  writes:
>
>> The second level header tells you the branch (e.g. master). On the
>> left hand side is a list of branches (so you can click on e.g. 1.1.x).
>>
>> Some ways I see this might be better:
>>
>> (1) make clear what master currently equals (right now it is 1.2 alpha)
>> (2) highlight the branch info more with css
>> (3) push the branch info into the top-level header (and page title)
>> (4) The overview section for c.c.io could tell about the lineage back
>> to 1.1.
>
> I think it might also help to make the stable versions the default
> view.  I think people new to the language should really be guided to
> using the stable releases and documentation rather than snapshots, as
> the snapshots may well be in flux and cause lots of confusion.
> People choosing to use the bleeding edge git snapshots will know what
> the branches are and can specify the one they want.


#(swap! % inc)

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

Re: Try + finally question

2010-04-21 Thread ka

Thanks all for replies.

Laurent, Alex you guys are right, the problem is only with aesthetics
of nesting / boilerplate.  The nesting implementation semantically
expresses exactly what is required.

The with-cleanup macro seems really neat.  Guess I'll learn macros
first and try to implement one.

One more interesting perspective to exceptional handling is the way
Perl 6 is doing it - http://feather.perl6.nl/syn/S04.html#Exception_handlers

See this -

{
my $s = '';
die 3;
CATCH {
when 1 {$s ~= 'a';}
when 2 {$s ~= 'b';}
when 3 {$s ~= 'c';}
when 4 {$s ~= 'd';}
default {$s ~= 'z';}
}

is $s, 'c', 'Caught number';
};

Thanks!

On Apr 21, 7:05 pm, Alex Osborne  wrote:
> ka  writes:
> > The whole code gets cluttered with all these try finally (and one
> > catch) statements.
>
> >   (try
> >     (let [conn1 (API1/getConnection ..)]
> >       (try
> >         (let [conn2 (API2/getConnection ..)]
> >           (try
> >             ( ... Do something with conn1 conn2 )
> >             (finally
> >               (API2/closeConnection conn2
> >         (finally
> >           (API1/closeConnection conn1
> >     (catch Exception ex (.printStackTrace ex)))
>
> I guess the main difference in this compared to your java example is the
> levels of nesting.  This may look messy but it's semantically exactly
> what you're trying to express.
>
> > The macro solution looks good.  But with 2 different APIs for 2
> > connections, I would need to write 2 macros right?
>
> > (defmacro with-api1-connection [conn-sym arg1 arg2 & body]
> >   `(let [~conn-sym (API1/getConnection ~arg1 ~arg2)]
> >      (try
> >       ~...@body
> >       (finally (API1/closeConnection ~conn-sym)
>
> > (defmacro with-api2-connection [conn-sym arg1 arg2 arg3 & body]
> >   `(let [~conn-sym (API2/getConnection ~arg1 ~arg2 ~arg3)]
> >      (try
> >       ~...@body
> >       (finally (API2/closeConnection ~conn-sym)
>
> You could make things more general:
>
> (with-cleanup [conn1 (API1/getConnection ...) API1/closeConnection
>                conn2 (API2/openConnection ...) #(.disconnect %)]
>  ...)
>
> I'll leave implementation as an exercise, it's not much more complicated
> than the previous ones, the main trick would just be to make the macro
> recursive, have it expand into:
>
> (let [conn1 (API1/getConnection ...)]
>   (try
>     (with-cleanup [conn2 (API2/openConnection ...) #(.disconnect %)]
>       ...)
>     (finally
>       (API1/closeConnection conn1
>
> I'd probably start with a signature like this:
>
> (defmacro with-cleanup [[sym create cleanup & more] & body]
>   ...)
>
> Take a look at the source for with-open if you get stuck.
>
>
>
> > Coming from Java, this would be implemented as -
>
> > Connection1 conn1 = null;
> > Connection2 conn2 = null;
> > try {
> >   conn1 = API1.getConnection ..;
> >   conn2 = API2.getConnection ..;
> >   ...
> > }
> > catch (){}
> > finally {
> >   if (conn1 != null)
> >     API1.closeConnection(conn1);
> >   if (conn2 != null)
> >     API2.closeConnection(conn2);
> > }
>
> > I agree that this code doesn't look good from a purist pov, but any
> > issues besides that?
>
> The problem here is that this breaks lexical scope, conn1 and
> conn2 aren't defined outside their let block.  The Java example dodges
> this with mutation.  Python/Ruby/JavaScript etc dodge it by having
> special scoping rules: variables are scoped to functions rather than the
> enclosing block.
>
> Clojure's opinion, as I understand it, is that it's not worthwhile
> introducing mutation or special scoping rules simply to avoid some
> nesting, when we have perfectly good tools (macros) for doing purely
> syntactic transformations and removing boilerplate.
>
> There's nothing semantically wrong with nesting, it's just harder
> to read.  The Clojure idiom for reducing nesting is usually to use a
> macro like ->, ->> or with-open to flatten it.  In this case those
> aren't applicable, so I suggest defining your own.
>
> I'm not sure I phrased that clearly, please let me know if I'm not
> making sense. :-)
>
> 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 
> athttp://groups.google.com/group/clojure?hl=en

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

Re: Try + finally question

2010-04-21 Thread Laurent PETIT

Hi,

I don't know for sure, but it seems to me that perl 6 way of "writing"
exception handling is just a syntactic difference.

For an interesting shift in the possibilities of exception
handling/recovery, have a look at how Common Lisp does this with
conditions/restart :
http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html

Which has been ported to clojure by chouser:
http://richhickey.github.com/clojure-contrib/error-kit-api.html

In a nutshell, with this you can simulate handlers placed higher in
the call stack, but those handlers could compute a "recovery value"
that would replace the value returned by the innermost from which the
exception originated (though this is totally off topic with your
original post :-) ).

2010/4/21 ka :
> Thanks all for replies.
>
> Laurent, Alex you guys are right, the problem is only with aesthetics
> of nesting / boilerplate.  The nesting implementation semantically
> expresses exactly what is required.
>
> The with-cleanup macro seems really neat.  Guess I'll learn macros
> first and try to implement one.
>
> One more interesting perspective to exceptional handling is the way
> Perl 6 is doing it - http://feather.perl6.nl/syn/S04.html#Exception_handlers
>
> See this -
>
> {
>    my $s = '';
>    die 3;
>    CATCH {
>        when 1 {$s ~= 'a';}
>        when 2 {$s ~= 'b';}
>        when 3 {$s ~= 'c';}
>        when 4 {$s ~= 'd';}
>        default {$s ~= 'z';}
>    }
>
>    is $s, 'c', 'Caught number';
> };
>
> Thanks!
>
> On Apr 21, 7:05 pm, Alex Osborne  wrote:
>> ka  writes:
>> > The whole code gets cluttered with all these try finally (and one
>> > catch) statements.
>>
>> >   (try
>> >     (let [conn1 (API1/getConnection ..)]
>> >       (try
>> >         (let [conn2 (API2/getConnection ..)]
>> >           (try
>> >             ( ... Do something with conn1 conn2 )
>> >             (finally
>> >               (API2/closeConnection conn2
>> >         (finally
>> >           (API1/closeConnection conn1
>> >     (catch Exception ex (.printStackTrace ex)))
>>
>> I guess the main difference in this compared to your java example is the
>> levels of nesting.  This may look messy but it's semantically exactly
>> what you're trying to express.
>>
>> > The macro solution looks good.  But with 2 different APIs for 2
>> > connections, I would need to write 2 macros right?
>>
>> > (defmacro with-api1-connection [conn-sym arg1 arg2 & body]
>> >   `(let [~conn-sym (API1/getConnection ~arg1 ~arg2)]
>> >      (try
>> >       ~...@body
>> >       (finally (API1/closeConnection ~conn-sym)
>>
>> > (defmacro with-api2-connection [conn-sym arg1 arg2 arg3 & body]
>> >   `(let [~conn-sym (API2/getConnection ~arg1 ~arg2 ~arg3)]
>> >      (try
>> >       ~...@body
>> >       (finally (API2/closeConnection ~conn-sym)
>>
>> You could make things more general:
>>
>> (with-cleanup [conn1 (API1/getConnection ...) API1/closeConnection
>>                conn2 (API2/openConnection ...) #(.disconnect %)]
>>  ...)
>>
>> I'll leave implementation as an exercise, it's not much more complicated
>> than the previous ones, the main trick would just be to make the macro
>> recursive, have it expand into:
>>
>> (let [conn1 (API1/getConnection ...)]
>>   (try
>>     (with-cleanup [conn2 (API2/openConnection ...) #(.disconnect %)]
>>       ...)
>>     (finally
>>       (API1/closeConnection conn1
>>
>> I'd probably start with a signature like this:
>>
>> (defmacro with-cleanup [[sym create cleanup & more] & body]
>>   ...)
>>
>> Take a look at the source for with-open if you get stuck.
>>
>>
>>
>> > Coming from Java, this would be implemented as -
>>
>> > Connection1 conn1 = null;
>> > Connection2 conn2 = null;
>> > try {
>> >   conn1 = API1.getConnection ..;
>> >   conn2 = API2.getConnection ..;
>> >   ...
>> > }
>> > catch (){}
>> > finally {
>> >   if (conn1 != null)
>> >     API1.closeConnection(conn1);
>> >   if (conn2 != null)
>> >     API2.closeConnection(conn2);
>> > }
>>
>> > I agree that this code doesn't look good from a purist pov, but any
>> > issues besides that?
>>
>> The problem here is that this breaks lexical scope, conn1 and
>> conn2 aren't defined outside their let block.  The Java example dodges
>> this with mutation.  Python/Ruby/JavaScript etc dodge it by having
>> special scoping rules: variables are scoped to functions rather than the
>> enclosing block.
>>
>> Clojure's opinion, as I understand it, is that it's not worthwhile
>> introducing mutation or special scoping rules simply to avoid some
>> nesting, when we have perfectly good tools (macros) for doing purely
>> syntactic transformations and removing boilerplate.
>>
>> There's nothing semantically wrong with nesting, it's just harder
>> to read.  The Clojure idiom for reducing nesting is usually to use a
>> macro like ->, ->> or with-open to flatten it.  In this case those
>> aren't applicable, so I suggest defining your own.
>>
>> I'm not sure I phrased that

Re: Try + finally question

2010-04-21 Thread Mark J. Reed

The main thing about Perl6 in this case is that the catch/finally blocks are
inside the same scope as the try.   But that's true in Clojure as well!
The difference is that Clojure's try is not itself a lexical binding scope;
you have to wrap one around it or within it via let.  That's why I thought a
combination of try and let would be useful, if only as syntactic sugar.

On Wed, Apr 21, 2010 at 10:43 AM, ka  wrote:

> Thanks all for replies.
>
> Laurent, Alex you guys are right, the problem is only with aesthetics
> of nesting / boilerplate.  The nesting implementation semantically
> expresses exactly what is required.
>
> The with-cleanup macro seems really neat.  Guess I'll learn macros
> first and try to implement one.
>
> One more interesting perspective to exceptional handling is the way
> Perl 6 is doing it -
> http://feather.perl6.nl/syn/S04.html#Exception_handlers
>
> See this -
>
> {
>my $s = '';
>die 3;
>CATCH {
>when 1 {$s ~= 'a';}
>when 2 {$s ~= 'b';}
>when 3 {$s ~= 'c';}
>when 4 {$s ~= 'd';}
>default {$s ~= 'z';}
>}
>
>is $s, 'c', 'Caught number';
> };
>
> Thanks!
>
> On Apr 21, 7:05 pm, Alex Osborne  wrote:
> > ka  writes:
> > > The whole code gets cluttered with all these try finally (and one
> > > catch) statements.
> >
> > >   (try
> > > (let [conn1 (API1/getConnection ..)]
> > >   (try
> > > (let [conn2 (API2/getConnection ..)]
> > >   (try
> > > ( ... Do something with conn1 conn2 )
> > > (finally
> > >   (API2/closeConnection conn2
> > > (finally
> > >   (API1/closeConnection conn1
> > > (catch Exception ex (.printStackTrace ex)))
> >
> > I guess the main difference in this compared to your java example is the
> > levels of nesting.  This may look messy but it's semantically exactly
> > what you're trying to express.
> >
> > > The macro solution looks good.  But with 2 different APIs for 2
> > > connections, I would need to write 2 macros right?
> >
> > > (defmacro with-api1-connection [conn-sym arg1 arg2 & body]
> > >   `(let [~conn-sym (API1/getConnection ~arg1 ~arg2)]
> > >  (try
> > >   ~...@body
> > >   (finally (API1/closeConnection ~conn-sym)
> >
> > > (defmacro with-api2-connection [conn-sym arg1 arg2 arg3 & body]
> > >   `(let [~conn-sym (API2/getConnection ~arg1 ~arg2 ~arg3)]
> > >  (try
> > >   ~...@body
> > >   (finally (API2/closeConnection ~conn-sym)
> >
> > You could make things more general:
> >
> > (with-cleanup [conn1 (API1/getConnection ...) API1/closeConnection
> >conn2 (API2/openConnection ...) #(.disconnect %)]
> >  ...)
> >
> > I'll leave implementation as an exercise, it's not much more complicated
> > than the previous ones, the main trick would just be to make the macro
> > recursive, have it expand into:
> >
> > (let [conn1 (API1/getConnection ...)]
> >   (try
> > (with-cleanup [conn2 (API2/openConnection ...) #(.disconnect %)]
> >   ...)
> > (finally
> >   (API1/closeConnection conn1
> >
> > I'd probably start with a signature like this:
> >
> > (defmacro with-cleanup [[sym create cleanup & more] & body]
> >   ...)
> >
> > Take a look at the source for with-open if you get stuck.
> >
> >
> >
> > > Coming from Java, this would be implemented as -
> >
> > > Connection1 conn1 = null;
> > > Connection2 conn2 = null;
> > > try {
> > >   conn1 = API1.getConnection ..;
> > >   conn2 = API2.getConnection ..;
> > >   ...
> > > }
> > > catch (){}
> > > finally {
> > >   if (conn1 != null)
> > > API1.closeConnection(conn1);
> > >   if (conn2 != null)
> > > API2.closeConnection(conn2);
> > > }
> >
> > > I agree that this code doesn't look good from a purist pov, but any
> > > issues besides that?
> >
> > The problem here is that this breaks lexical scope, conn1 and
> > conn2 aren't defined outside their let block.  The Java example dodges
> > this with mutation.  Python/Ruby/JavaScript etc dodge it by having
> > special scoping rules: variables are scoped to functions rather than the
> > enclosing block.
> >
> > Clojure's opinion, as I understand it, is that it's not worthwhile
> > introducing mutation or special scoping rules simply to avoid some
> > nesting, when we have perfectly good tools (macros) for doing purely
> > syntactic transformations and removing boilerplate.
> >
> > There's nothing semantically wrong with nesting, it's just harder
> > to read.  The Clojure idiom for reducing nesting is usually to use a
> > macro like ->, ->> or with-open to flatten it.  In this case those
> > aren't applicable, so I suggest defining your own.
> >
> > I'm not sure I phrased that clearly, please let me know if I'm not
> > making sense. :-)
> >
> > 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

Missing fns: rotate & rotate-while

2010-04-21 Thread Sean Devlin

Hey everyone,

I've had to code these guys up a few times:

(defn rotate
  "Take a collection and left rotates it n steps. If n is negative,
the
collection is rotated right. Executes in O(n) time."
  [n coll]
  (let [c (count coll)]
(take c (drop (mod n c) (cycle coll)

(defn rotate-while
  "Rotates a collection left while (pred item) is true. Will return a
unrotated
sequence if (pred item) is never true. Executes in O(n) time."
  [pred coll]
  (let [head (drop-while pred coll)]
(take (count coll) (concat head coll

Have other people had this problem?

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

Coordinated, asynchronous modification of state?

2010-04-21 Thread Garth Sheldon-Coulson

Hi All,

This e-mail is the product of some musing about refs, agents, and atoms. I
would like to offer some thoughts on a possible fourth reference type that
allows coordinated, asynchronous modification of state.

I would greatly appreciate comments from the community. Maybe some of these
ideas have already been discussed on the list or incorporated into
development, in which case I'm sorry for repeating what is already
known---and please point me in the right direction so I can read more. I
hope the ideas are not too far off base, but please let me know if you think
they are.

Let me start at the beginning. In Clojure, we have standard reference types
for:

* uncoordinated, synchronous state change,
* coordinated, synchronous state change,
* uncoordinated, asynchronous state change.

Most Clojure users are familiar with the following diagram expressing the
reference type taxonomy. (The ASCII diagrams in this e-mail are best viewed
in a fixed-width font.)

  | Synchronous  | Asynchronous
--+--+-
Uncoordinated | Atoms| Agents
Coordinated   | Refs |

It occurred to me recently that there is no built-in reference type for the
final quadrant: coordinated, asynchronous change. There is no reference
type, in other words, allowing one to write a "doasync" block similar to a
dosync block:

(doasync   ;short for do asynchronously
  (send a inc)
  (send b inc))

causing a and b to change together atomically in the background. I thought
to myself that it would be nice to have this ability in some applications,
especially simulation, artificial life, and agent-based modeling. It allows
one thread to effect coordinated change in other threads while getting on
with its own work.

I pondered more and realized that, although there is no built-in reference
type for this purpose, one can make a first stab at the same effect using a
combination of futures and refs:

(future
  (dosync
(alter a inc)
(alter b inc)))

The future wraps the atomic transaction and causes it to take place in a
background thread.

This solution satisfied me for a day or two. Upon some more thought,
however, I realized that combining refs with futures is a recipe for
livelock disaster. Here is why. In a massively concurrent program with heavy
asynchronous state change, it is unlikely that any one ref will stay the
same for very long. The kind of coordinated change offered by a ref
transaction is unlikely to be successful in this kind of constantly-changing
environment, because the values of the refs are constantly being changed out
from under the transaction attempts. Consider the following illustration, in
which I try to modify a ref at the same time that it is being changed
continually from another thread:

 begin example 
(def a (ref 1))

; the code for start-frequent-changes is at
; http://gist.github.com/373143
(start-frequent-changes a)

; this code will never print its message
(let [done? (agent nil)]
  (future
(dosync
  (alter a (fn negate [val] (Thread/sleep 300) (- val)))
; negate is a long-running function of its argument
  (send done? (fn [_] (println "Done!"))
 end example 

The principle illustrated by this example is the following: when one or more
other threads are changing a ref, a computationally expensive transaction on
that ref is likely to encounter livelock. The more expensive the transaction
and the more frequent the changes, the less likely it is that the
transaction will ever go through. It will retry over and over, consuming
resources and potentially retrying forever.

Rich introduced ensure in part to try to mitigate this problem. Livelock can
be avoided in the example above by placing a simple "(ensure a)" call at the
beginning of the dosync block. Ensure ensures that the transaction holds
"write permissions" on the ref during the transaction, so that other threads
cannot modify it.

However, the combination of futures, refs, and ensure is not a terribly good
solution to coordinated asynchronicity, either, because it has a problem of
its own: The order in which futures are executed is not deterministic. Race
conditions will occur, and this is a big problem when dealing with state.

To illustrate this, suppose one has three refs, a, b, and c. (In a real
scenario, instead of just three refs one might have three groups of 20 refs,
but three refs is enough to illustrate.) One wants to complete three
asynchronous transactions on these refs in the following order: first,
modify a, then modify both a and b, then modify both a and c.

The problem is this: There is no way, using futures, refs, and ensure, to
guarantee that the three asynchronous transactions will happen in the order
one intends. Running the following code will usually print 3, but sometimes
it will print 2, because there is a race condition affecting the second and
third futures.

 begin example ;;;

70 matches

Mail list logo