Re: Entwined STM V1.0

[Ivan Koblik]

I have done the benchmarks and optimized the implementation. On my PC with 
the new changes TransactionalMap is up to 5 times slower than 
ConcurrentHashMap. You can find the benchmarks here:

https://github.com/CERN-BE/Entwined-STM/blob/master/src/test/java/cern/entwined/demo/clojure_benchmarks.clj

Just require the namespace and run either (time (run-concurrent-map)) 
or (time (run-transactional-map)).

Please note while ConcurrentHashMap is faster in this test it does not give 
same guarantees as the TransactionalMap. For example in the benchmarks I 
created 1 thread per key that is being incremented if there was more than 1 
thread updating the same key than ConcurrentHashMap wouldn't be suitable 
any more.

I will release the improved new version 1.0.1 later this week.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Entwined STM V1.0

[Ivan Koblik]

I'll come back to you with the benchmarks, so far I haven't done any. I 
have an impression that ConcurrentHashMap will outperform TransactionalMap 
in most cases, but there may be cases when different keys end up in the 
same bucket in the ConcurrentHashMap and that is where TransactionalMap may 
be faster.

To answering your second question: I would use STM only when there's a need 
to perform a series of coordinated actions. To read a key/value pair and 
depending on the value update some other transactional entity.

For example if I expand on the example posted here:
https://github.com/CERN-BE/Entwined-STM/blob/master/src/test/java/cern/entwined/demo/clojure_examples.clj

I can write a function that would access map and the queue in the same 
transaction:

(defn add-user-and-queue-update!
  "Adds user and schedules initial update only if it's a new user."
  [id user update-fn]
  (intrans memory _
(when-not (get-user id)
  (add-user id name)
  (schedule-task update-fn

Transactions in Entwined are composable and in the example above I create 
outer transaction that uses API from the example namespace to check for a 
condition and only if it is true preform some action. If user is added 
concurrently than this transaction is restarted and no action is performed.

On Sunday, August 18, 2013 1:01:53 PM UTC+2, dennis wrote:

> That's really cool.
> Do you have any performance benchmark between TransactionalMap and 
> java.util.concurrent.ConcurrentHashMap?  When should i use these 
> collections instead of java.util.concurrent.* collections? 
>
>
>
>
> 2013/8/18 Ivan Koblik >
>
>> Hi All,
>>
>> Almost 4 years ago I developed STM with semantic concurrency control for 
>> my project at CERN. Main feature of this STM is the TransactionalMap that 
>> lets you merge concurrent changes. Library is heavily tested and is very 
>> stable. It has been used in production for the past 2 years.
>>
>> Recently I released it on GitHub:
>> http://entwined.koblik.ch (will redirect to 
>> https://github.com/CERN-BE/Entwined-STM)
>>
>> Since Entwined STM was designed to be used from Java I wrote a simple 
>> facade for it in Clojure that you can load with 
>>
>> (require '[cern.entwined.core :as stm])
>>
>> Entwined STM operates on a memory with a fixed structure, meaning that 
>> you have to define what and how many collections you want to have in your 
>> STM and this can't be changed after construction. To construct memory with 
>> 1 transactional map and 1 transactional queue run this:
>>
>> (def memory (stm/create-memory :map (stm/create-map) :queue 
>> (stm/create-queue)))
>>
>> It's impossible to access transactional entities outside of a 
>> transaction, to run a transaction you can use "intrans" macro
>>
>> (stm/intrans memory data (-> data :map (.put :key1 "value1")) true)
>>
>> (stm/intrans memory data (-> data :map (.get :key1))) ;-> "value1"
>>
>> First line puts [:key1 "value1"] pair into the map. True at the end of 
>> the body tells the memory to commit this transaction. intrans will initiate 
>> commit if body returns truthy value. Second line just shows that the change 
>> has been committed.
>>
>> A couple more words on the implementation: I used HashMap to implement 
>> the TransactionalMap, I copy the backing map for every transaction which 
>> may be expensive for some scenarios. Obvious solution would be to use 
>> Clojure's persistent map. Commits are eventually serialized and protected 
>> with a single lock. If you take a look at the Java source you'll see that 
>> Transaction interface has a second method "committed" that is called when 
>> commit is being done. I use this method to write to the hardware knowing 
>> that execution order of committed callbacks is the same as the commit order.
>>
>> I would greatly appreciate any feedback and suggestions. If you have any 
>> questions don't hesitate to ask here or email me directly. Documentation is 
>> still somewhat lacking and I'd be interested to know which parts of it 
>> should be improved first.
>>
>> Cheers,
>> Ivan.
>>  
>> -- 
>> -- 
>> 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 o

Re: Entwined STM V1.0

[Ivan Koblik]

Thank you! Great question.

I couldn't devise a way to merge concurrent changes in a HashMap using 
Clojure's STM. A while ago I discussed it with Christophe Grand and he had 
his own idea about how to fix it: [1] and [2]. IIRC Christophe's solution 
may see a conflict even if there's no real conflict due to stochastic 
nature of the implementation.

I had this use case in my project that functions as a reservation system, I 
needed a way to add a record into the Map saying that a given device has 
been reserved by a given user. Since I didn't know all the devices in 
advance I needed a way to detect conflicts even if Key/Value pair is added 
for the first time or when it is removed completely.

[1] http://clj-me.cgrand.net/2011/10/06/a-world-in-a-ref/
[2] http://clj-me.cgrand.net/2012/09/21/follow-up-a-world-in-a-ref/


On Sunday, August 18, 2013 12:42:23 PM UTC+2, Hussein B. wrote:
>
> Great ! Congratulations!
>
> How it does compare with Clojure's builtin STM?
>
> Thanks.
>
> On Sunday, August 18, 2013 10:24:48 AM UTC+2, Ivan Koblik wrote:
>>
>> Hi All,
>>
>> Almost 4 years ago I developed STM with semantic concurrency control for 
>> my project at CERN. Main feature of this STM is the TransactionalMap that 
>> lets you merge concurrent changes. Library is heavily tested and is very 
>> stable. It has been used in production for the past 2 years.
>>
>> Recently I released it on GitHub:
>> http://entwined.koblik.ch (will redirect to 
>> https://github.com/CERN-BE/Entwined-STM)
>>
>> Since Entwined STM was designed to be used from Java I wrote a simple 
>> facade for it in Clojure that you can load with 
>>
>> (require '[cern.entwined.core :as stm])
>>
>> Entwined STM operates on a memory with a fixed structure, meaning that 
>> you have to define what and how many collections you want to have in your 
>> STM and this can't be changed after construction. To construct memory with 
>> 1 transactional map and 1 transactional queue run this:
>>
>> (def memory (stm/create-memory :map (stm/create-map) :queue 
>> (stm/create-queue)))
>>
>> It's impossible to access transactional entities outside of a 
>> transaction, to run a transaction you can use "intrans" macro
>>
>> (stm/intrans memory data (-> data :map (.put :key1 "value1")) true)
>>
>> (stm/intrans memory data (-> data :map (.get :key1))) ;-> "value1"
>>
>> First line puts [:key1 "value1"] pair into the map. True at the end of 
>> the body tells the memory to commit this transaction. intrans will initiate 
>> commit if body returns truthy value. Second line just shows that the change 
>> has been committed.
>>
>> A couple more words on the implementation: I used HashMap to implement 
>> the TransactionalMap, I copy the backing map for every transaction which 
>> may be expensive for some scenarios. Obvious solution would be to use 
>> Clojure's persistent map. Commits are eventually serialized and protected 
>> with a single lock. If you take a look at the Java source you'll see that 
>> Transaction interface has a second method "committed" that is called when 
>> commit is being done. I use this method to write to the hardware knowing 
>> that execution order of committed callbacks is the same as the commit order.
>>
>> I would greatly appreciate any feedback and suggestions. If you have any 
>> questions don't hesitate to ask here or email me directly. Documentation is 
>> still somewhat lacking and I'd be interested to know which parts of it 
>> should be improved first.
>>
>> Cheers,
>> Ivan.
>>  
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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.

Entwined STM V1.0

[Ivan Koblik]

Hi All,

Almost 4 years ago I developed STM with semantic concurrency control for my
project at CERN. Main feature of this STM is the TransactionalMap that lets
you merge concurrent changes. Library is heavily tested and is very stable.
It has been used in production for the past 2 years.

Recently I released it on GitHub:
http://entwined.koblik.ch (will redirect to
https://github.com/CERN-BE/Entwined-STM)

Since Entwined STM was designed to be used from Java I wrote a simple
facade for it in Clojure that you can load with

(require '[cern.entwined.core :as stm])

Entwined STM operates on a memory with a fixed structure, meaning that you
have to define what and how many collections you want to have in your STM
and this can't be changed after construction. To construct memory with 1
transactional map and 1 transactional queue run this:

(def memory (stm/create-memory :map (stm/create-map) :queue
(stm/create-queue)))

It's impossible to access transactional entities outside of a transaction,
to run a transaction you can use "intrans" macro

(stm/intrans memory data (-> data :map (.put :key1 "value1")) true)

(stm/intrans memory data (-> data :map (.get :key1))) ;-> "value1"

First line puts [:key1 "value1"] pair into the map. True at the end of the
body tells the memory to commit this transaction. intrans will initiate
commit if body returns truthy value. Second line just shows that the change
has been committed.

A couple more words on the implementation: I used HashMap to implement the
TransactionalMap, I copy the backing map for every transaction which may be
expensive for some scenarios. Obvious solution would be to use Clojure's
persistent map. Commits are eventually serialized and protected with a
single lock. If you take a look at the Java source you'll see that
Transaction interface has a second method "committed" that is called when
commit is being done. I use this method to write to the hardware knowing
that execution order of committed callbacks is the same as the commit order.

I would greatly appreciate any feedback and suggestions. If you have any
questions don't hesitate to ask here or email me directly. Documentation is
still somewhat lacking and I'd be interested to know which parts of it
should be improved first.

Cheers,
Ivan.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Experiences developing a crowdfunding site for open source projects in Clojure (from a Python background)

[Ivan Koblik]

Hi Aaron,

Thank you for such an interesting post.

You wrote that you could not setup Emacs on Windows. I decided to show you 
an easy way to do it.
1. Download vanilla Emacs from here:
http://ftp.gnu.org/pub/gnu/emacs/windows/

Latest version at the moment is here:
http://ftp.gnu.org/pub/gnu/emacs/windows/emacs-24.1-bin-i386.zip

2. Unpack it to a directory where you'll run it from.

3. Download this configuration:
https://rapidshare.com/files/1058404111/2011-03-emacs-config-linux.tar.gz

I prepared it on Linux but it works perfectly on Windows. I used it myself 
to 2 windows machines with no issues.

4. Unpack it to %APPDATA% (i.e. c:\Users\YOUR_USER_NAME\AppData\Roaming). 
If you had .emacs or .emacs.d there already, move them somewhere else.

That's it! Your Emacs is now configured. Easiest way to use it as REPL is 
to launch your application with: "lein swank" and then in Emacs M-x 
(Alt-x), slime-connect, enter, press enter 2 more times.

Cheers,
Ivan

On Thursday, July 26, 2012 9:59:46 PM UTC+2, Aaron Lebo wrote:
>
> Hello!
>
> Sometime around 2 and a half months ago, I started to work on a new 
> project using Clojure. I've been using Python heavily for about 6 six years 
> working for a small direct mail company and before that started programming 
> with Ruby on Rails. This new project was something out of left field, so I 
> had different options on what technology to use. I ended up choosing 
> Clojure, and my work on the site has been my first real experience using a 
> lisp, Clojure, and the JVM. I'd like to share my experiences and how that 
> has differed with my previous Python work.
>
> Before that, I'd like to make a little plug for my site. It is called 
> kodefund  (www.kodefund.com). The basic idea is 
> to take the familiar Kickstarter model but to really focus on applying that 
> to open source development. I feel that previous crowdfunding efforts have 
> shown that there is an interest by developers to fund projects that they 
> are enthusiastic about. When this works, everyone wins: the developer 
> working on the project can devote their full time and effort on the actual 
> project and still make a living and others get the benefits of the open 
> source software. I feel like it is preferable over selling licenses to 
> proprietary software or other efforts.
>
> So, every project on kodefund is required to be open source. This 
> differentiates it from other crowdfunding sites, and helps to apply a 
> filter: you know what you are getting when you go there instead of seeing 
> dozens of projects for unrelated stuff. 
>
> One other difference is that you can also start a project which is more or 
> less a "reverse" Kickstarter. This allows you to take an idea for a project 
> or issue you want fixed, raise funding, and find someone who will actually 
> implement the project. Other users get to submit "applications" and you 
> choose from them to find the most capable candidate. Once you chose an 
> application, that person takes over the project.
>
> Finally, one other push I want to make is to open up proprietary software. 
> Maybe your company has written some software in-house, but there's no real 
> incentive to release it. What if you could crowdfund the software, get paid 
> to release it, and the open source community as a whole could benefit from 
> that? 
>
> I feel like crowdfunding and open source software are an ideal fit.
>
> I'm getting off track here. I'll shift to my actual experiences using 
> Clojure. I was more than a little nervous about using the JVM. It always 
> seemed like some huge, scary thing, and digging into Java libraries was not 
> something I wanted to do. Something which resolved this was leiningen. I 
> feel like it is absolutely brilliant, and it really makes adding libraries 
> to your project a non-issue. Things have slowly changed in Python, but it 
> used to be that downloading dependencies was a global process and you ended 
> up with a site-packages that was full of dozens of old libraries that you 
> used for other projects. Being able to specify in my project.clj file 
> exactly which libraries I need and those getting downloaded automatically 
> is a really nice feature that I will look for similar functionality in 
> other languages from now on.
>
> I was also pleasantly surprised by the library availability. The vast 
> majority of things that I needed such as oauth2 support and such already 
> have decent Clojure wrappers. When I did drop down into Java, I found that 
> to be painless. The JVM really does have a wide swath of functionality 
> already available. Some of the things that I ended up using were email 
> libraries, date formatting libraries, and an rss feed generator. There 
> never was a point where I felt like I was going to have to just roll things 
> by hand. Most of the hard work has been done.
>
> Considering the language itself, one of the first things I noticed (or 
> didn't) was the pare

Re: Problem with Korma and clj-soap

[Ivan Koblik]

I'm pretty sure this is because of log4j.xml [1] in src directory of Korma.
I think it's take from here [2]. If you take a look at it, it sets root
debug level to "debug".

Try creating your own configuration and pointing to it with command line
argument:
-Dlog4j.configuration=your_log4j.xml

What are the usual rule for the libraries? Is it OK to create log4j.xml in
default location? If not how should it be done?

[1] https://github.com/ibdknox/Korma/blob/master/src/log4j.xml
[2] http://wiki.apache.org/logging-log4j/Log4jXmlFormat

Cheers,
Ivan.


On 25 November 2011 16:43, Dennis Crenshaw  wrote:

> So I'm trying to create a drop-in implementation of a SOAP webservice with
> Clojure. Naturally I look into libraries that accomplish the different
> bits. I need something to do SQL work with a relational db 
> (Korma,
> check!) and I need to present a SOAP interface 
> (clj-soap,
> check!)
>
> Unfortunately I'm having tooling issues putting the two together.
>
> The first problem, I'm pretty sure, was simply a Clojure version
> mismatch: I and Korma were using Clojure 1.3 and alj-soap was using 1.2--
> so I checked out the clj-soap source and updated the libraries (Clojure to
> 1.3, the Axis2 libraries to their latest) and ran the tests to make sure
> all was still working-- it was. So I pushed the 'new' clj-soap to clojars
> as [org.clojars.crenshawda/clj-soap "0.1.2"] and tried again.
>
> Much to my chagrin I started getting seemingly endless byzantine DEBUG log
> traces spewed out into the repl when I try to start the soap server.
>
> If I comment Korma out of the project.clj, lein deps, and lein repl the
> same thing works like a charm. I also checked out each of Korma's
> dependencies individually and ran the same serve function and it worked
> (the log4j dep made it complin, but it still served just fine.)
>
> I'm not exactly sure WHAT is causing the collision between Korma and
> clj-soap, but it's damaging my calm at this point. :) I have a gut feeling
> that it's somehow logging related, but I don't know why it would cause
> clj-soap to flip out so badly.
>
> To recreate my scenario, start a new project and add these dependencies to
> the project.clj:
>
> [org.clojure/clojure "1.3.0"] ;; if is isn't already there by default, I
> want to use 1.3
> [korma "0.3.0-apha4"]
> [org.clojars.crenshawda/clj-soap "0.1.2"] ;; use [clj-soap "0.1.1"] if you
> want to see what I was talking about with the 1.2/1.3 mismatch
>
> Since Axis2 (what clj-soap is build upon) requires compiled classes to
> serve soap, you'll probably have to define a service in a clj file so 'lein
> repl' will pre-compile it for convenience sake.
>
> You can use this:
>
> (soap/defservice service.Hello
> (hello ^String [^String s]
> (str "Hello Yourself")))
>
> So when you start your repl you should have classes/services/Hello.class
> in your classes/ directory. After you have to invoke clj-soap's serve
> function:
>
> (serve "service.Hello")
>
> ... nd you should have a lovely logging wreck in your repl. I'd be
> happier if I could at least figure out WHY it happens when I put Korma in
> my dependencies. Sorry for the wall of text, but I figure too much info is
> usually better than not enough. :)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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: Clojure 1.3 treatment of integers and longs

[Ivan Koblik]

Hello Luc,

In all fairness I don't see how converting ints to Integers returned by
class methods would break the abstraction. If you start talking about
portability of Clojure code, then Long is as portable as Integer is. (In
general they are not.)

Could you explain your position on the fact that shorts get converted to
Short? Why is it not possible to do the same for ints?

I don't think that there was anyone in this thread that would suggest
keeping 32bit math in Clojure. For what it's worth, Integer can be converted
to Long first time it is used in any computation.

Cheers,
Ivan.


On 23 October 2011 17:16, Luc Prefontaine wrote:

> CON1 - I'm buying your argumentation about consistency in Clojure maps and
> fixing them. Integer OBJECTS (as opposed to int primitive) should be
> handle as objects consistenly, not as primitive values promoted to long.
>
> CON2, CON3 and CON4 - No way, the current design choice is the good one.
>
> So many languages have been plagued with numbers of different sizes/formats
> for ints and floating point values,
> it's not a direction that Clojure should follow.
> These distinct types are source of many problems (overflow handling,
> precision problems, ...).
>
> The need for Clojure to support these things is similar to calling
> assembler
> from C. You matter about bytes, shorts and similar things at the frontier,
> when it's time to call a low level service, you need to be able to pass
> these values.
>
> By no means this implies that you have to support them in your language
> runtime.
> It complects (;) everything including computations and makes your runtime
> much more harder to port.
>
> It's an interop centric thing and interop is by essence not portable.
> It does not belong to the core of Clojure. It's better to rely on cast
> operators
> to call interop than to expect Clojure to box numeric values according to
> some interop
> convention that may vary according to the platform Clojure runs on.
>
> Luc P.
>
> On Sun, 23 Oct 2011 07:19:41 -0400
> Paul Stadig  wrote:
>
> > On Sat, Oct 22, 2011 at 5:51 PM, Stuart Halloway
> > wrote:
> >
> > > I am dropping off this thread now.  At this point I think it would
> > > be more useful for me (or someone) to expand the notes about
> > > numerics into better documentation, rather than continuing this
> > > rambling point-by-point treatment without getting all of the
> > > considerations into play at once. I hope to get that done by conj.
> >
> >
> > So you are still thinking that the current behavior is OK and just
> > needs to be documented better? Or are you saying that we need to
> > collect the various pros and cons to decide whether the current
> > behavior should change or remain the same?
> >
> > Having reviewed the thread there is lots of confusion, but from the
> > points made it seems clear to me that the behavior should change.
> >
> > CON (The "we should box ints as Longs" (or "we should keep things as
> > they are") camp):
> > 1) If we box ints as Integers it will break Clojure's collections (Stu
> > Halloway)
> > 2) Boxing ints as Integers would make Clojure's design inconsistent
> > (David Nolen)
> > 3) Clojure now only has 64-bit primitives (David Nolen/Kevin Downey)
> > 4) If 32-bit ints are allowed to exist, the Clojure's numeric
> > operators would have to handle them (David Nolen)
> >
> > CON1 is a bug in PersistentHashMap, and I opened a Jira bug for it (
> > http://dev.clojure.org/jira/browse/CLJ-861).
> > CON2 is false. The way primitives are boxed for interop doesn't and
> > shouldn't have any effect on Clojure's design as such. This is a
> > discussion about interop consistency, and if you look at the PRO
> > section you will see Clojure is already inconsistent with respect to
> > interop. Nathan and others are arguing that it should be made
> > consistent. CON3 is false. 32-bit primitives do exist in Clojure (at
> > least Java Clojure), they are just not the optimized case. They may
> > get immediately converted to longs or boxed in some way, but we
> > cannot deny their existence, especially around interop.
> > CON4 Again, 32-bit integers do exist, and are already handled by the
> > numeric operators. When you compile a function with primitive args,
> > Clojure also generates a method that takes Objects. If you pass in
> > anything other than a long it gets boxed, cast to a java.lang.Number,
> > has its longValue method called, and that value gets passed to the
> > primitive arg version. This is slow (as expected) because you are not
> > using the optimized case (64-bit primitives). Absolutely none of that
> > would have to change/get slower because ints were boxed as Integers
> > instead of Longs.
> >
> > I think the problem with all of these CONs is that they confuse
> > boxing for interop with either a bug in PersistentHashMap, or fast
> > primitive maths, and neither of those has anything to do with how
> > ints are boxed.
> >
> > PRO (The "we should box ints as Integers" camp):
> > 1) Clojur

Re: Array type hints in 1.3

[Ivan Koblik]

I reread your original post, sorry I saw that you managed to declare type
constrained methods. Then, what was your question about?

Type hinting for arguments works as well:
(definterface Name
(^"[S" method [^"[S" short-arg]))

(def p (proxy [Name] []
(method [^"[S" short-arg] short-arg)))

(.method p
(short-array [(short 10) (short 11)]))

Interesting, I didn't actually check the runtime behavior. Decompiler
> says, the emitted class names are bogus.
>

Do you mean the interface name?


> JVM probably doesn't cast on return, so it slips through. Have you
> tried hinting an argument?
>

I'm not sure what happens in case of arrays, but for simple return types it
definitely does the check.
(def p (proxy [Comparable] []
(^int compareTo [arg] arg) ;;doesn't matter
(^String toString [] 10))) ;;will throw ClassCastException on
invocation.

Cheers,
Ivan.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Array type hints in 1.3

[Ivan Koblik]

Hello Herwig,

I checked the patch you linked to in your original post, and it doesn't seem
that type hinting for native arrays of Objects is supported, that is the [L
type. Native arrays of native types work quite well.

(definterface Name (^"[S" method [])) ;;returns array of shorts
(def p (proxy [Name] []
(method [] (short-array [(short 10) (short 1)] ;;method returns
short[2]
(.method p) ;; returns #

Cheers,
Ivan.



On 21 October 2011 23:02, Herwig Hochleitner  wrote:

> Another annotation bug:
>
> Annotations on gen-class in an ns form, like (ns foo (:gen-class
> ^{Singleton {}} foo.ClassName)) don't seem to work.
>
> --
> __
> Herwig Hochleitner
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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: Spread work onto multiple threads (in pure Clojure)

[Ivan Koblik]

Sorry I meant "Fair enough ..."

Cheers,
Ivan.


On 13 October 2011 12:41, Ivan Koblik  wrote:

> Fail enough. I guess, to allow nested spawning and avoid deadlocks, tasks
> should finish without waiting for the result but spawn a new task similar to
> itself that would check for the completion of the child tasks, repeating the
> cycle if necessary.
>
> Imagine that task t1 is monitored through a future f1, now it spawns child
> task t2 which is monitored through a future f2. t1 doesn't wait for t2 to
> complete, but reschedules a new task t3 that would check f2 for completion,
> and if f2 is done then sets f1 to done, otherwise reschedules itself as t4.
>
> Although I don't know how memory hungry it may get and what would be the
> impact on the length of the task queue. Maybe we could make the queue of
> limited length and if new task t2 gets rejected then it is performed within
> the task t1?
>
> Cheers,
> Ivan.
>
>
>
> On 13 October 2011 00:21, j-g-faustus  wrote:
>
>> On Tuesday, October 11, 2011 8:07:16 PM UTC+2, Andy Fingerhut wrote:
>> > If it were implemented not by creating Java Threads for each task, but
>> submitting a task to an ExecutorService...
>>
>> As far as I understand, that's easy if you're willing to use it
>> asynchronously: Push tasks on the queue, let the worker threads deal with
>> them whenever they get around to it, and never block waiting for results
>> within a task.
>> I.e. a task could submit nested tasks to the queue, but it couldn't use
>> them to compute partial results for its own use.
>>
>> If you want synchronous behavior, there are only two ways that I know of
>> to do that: Either disallow nesting, like (await agent), or use an unbounded
>> thread pool, like pmap.
>>
>> If you allow unbounded nesting of "submit task and wait for the result" on
>> a fixed size thread pool, I'm pretty sure you'll end up with deadlock.
>> (Which is why agents disallow it, I assume.)
>> Imagine a 1-thread ExecutorService where the task running on the single
>> work thread submits a new task to the service and blocks until it receives a
>> result: The only thread that can process that task just went to sleep, and
>> it won't wake up until it receives a result that there are no threads left
>> to compute.
>> The issue is the same with more worker threads; except that it will work,
>> more or less, as long as at least one thread is still awake. But the
>> scenario where every worker thread submits-and-waits simultaneously is bound
>> to happen at some point.
>>
>>
>> With the disclaimer that I might be missing something,
>>
>> jf
>>
>>
>> On Tuesday, October 11, 2011 8:07:16 PM UTC+2, Andy Fingerhut wrote:
>>
>>> One benefit would be convenience of enabling parallelism on nested data
>>> structures.  One function at the top level could use parallelism, and the
>>> pieces, perhaps handled by separate functions, and perhaps nested several
>>> levels deep in function calls, could also use parallelism.
>>>
>>> If it were implemented not by creating Java Threads for each task, but
>>> submitting a task to an ExecutorService, then the actual number of active
>>> Java Threads could be kept reasonably low (e.g. maybe 2 times the number of
>>> physical CPU cores), whereas the number of parallel tasks the work is
>>> divided into could be limited only by memory for storing the tasks scheduled
>>> for future execution.
>>>
>>> Andy
>>>
>>>
>>> On Tue, Oct 11, 2011 at 10:55 AM, j-g-faustus wrote:
>>>
>>>>  On Tuesday, October 11, 2011 3:55:09 AM UTC+2, Lee wrote:
>>>>>
>>>>>
>>>>> Does your pmap-pool permit nesting? (That is, does it permit passing
>>>>> pmap-pool a function which itself calls pmap-pool?). If so then that would
>>>>> be a reason to prefer it over my pmapall.
>>>>>
>>>> I expect it would be possible to nest it (possible as in "no exceptions
>>>> or deadlocks"), but I can't see any scenario where you would want to - you
>>>> would get an exponentially increasing number of threads. If 48 cores each
>>>> start 48 threads, each of those threads start another 48 etc., it doesn't
>>>> take long before you have enough threads to bog down even the most powerful
>>>> server.
>>>>
>>>> But what would be the purpose of a nested "run this on all cores"
>>>> construct? Y

Re: Spread work onto multiple threads (in pure Clojure)

[Ivan Koblik]

Fail enough. I guess, to allow nested spawning and avoid deadlocks, tasks
should finish without waiting for the result but spawn a new task similar to
itself that would check for the completion of the child tasks, repeating the
cycle if necessary.

Imagine that task t1 is monitored through a future f1, now it spawns child
task t2 which is monitored through a future f2. t1 doesn't wait for t2 to
complete, but reschedules a new task t3 that would check f2 for completion,
and if f2 is done then sets f1 to done, otherwise reschedules itself as t4.

Although I don't know how memory hungry it may get and what would be the
impact on the length of the task queue. Maybe we could make the queue of
limited length and if new task t2 gets rejected then it is performed within
the task t1?

Cheers,
Ivan.


On 13 October 2011 00:21, j-g-faustus  wrote:

> On Tuesday, October 11, 2011 8:07:16 PM UTC+2, Andy Fingerhut wrote:
> > If it were implemented not by creating Java Threads for each task, but
> submitting a task to an ExecutorService...
>
> As far as I understand, that's easy if you're willing to use it
> asynchronously: Push tasks on the queue, let the worker threads deal with
> them whenever they get around to it, and never block waiting for results
> within a task.
> I.e. a task could submit nested tasks to the queue, but it couldn't use
> them to compute partial results for its own use.
>
> If you want synchronous behavior, there are only two ways that I know of to
> do that: Either disallow nesting, like (await agent), or use an unbounded
> thread pool, like pmap.
>
> If you allow unbounded nesting of "submit task and wait for the result" on
> a fixed size thread pool, I'm pretty sure you'll end up with deadlock.
> (Which is why agents disallow it, I assume.)
> Imagine a 1-thread ExecutorService where the task running on the single
> work thread submits a new task to the service and blocks until it receives a
> result: The only thread that can process that task just went to sleep, and
> it won't wake up until it receives a result that there are no threads left
> to compute.
> The issue is the same with more worker threads; except that it will work,
> more or less, as long as at least one thread is still awake. But the
> scenario where every worker thread submits-and-waits simultaneously is bound
> to happen at some point.
>
>
> With the disclaimer that I might be missing something,
>
> jf
>
>
> On Tuesday, October 11, 2011 8:07:16 PM UTC+2, Andy Fingerhut wrote:
>
>> One benefit would be convenience of enabling parallelism on nested data
>> structures.  One function at the top level could use parallelism, and the
>> pieces, perhaps handled by separate functions, and perhaps nested several
>> levels deep in function calls, could also use parallelism.
>>
>> If it were implemented not by creating Java Threads for each task, but
>> submitting a task to an ExecutorService, then the actual number of active
>> Java Threads could be kept reasonably low (e.g. maybe 2 times the number of
>> physical CPU cores), whereas the number of parallel tasks the work is
>> divided into could be limited only by memory for storing the tasks scheduled
>> for future execution.
>>
>> Andy
>>
>>
>> On Tue, Oct 11, 2011 at 10:55 AM, j-g-faustus wrote:
>>
>>>  On Tuesday, October 11, 2011 3:55:09 AM UTC+2, Lee wrote:


 Does your pmap-pool permit nesting? (That is, does it permit passing
 pmap-pool a function which itself calls pmap-pool?). If so then that would
 be a reason to prefer it over my pmapall.

>>> I expect it would be possible to nest it (possible as in "no exceptions
>>> or deadlocks"), but I can't see any scenario where you would want to - you
>>> would get an exponentially increasing number of threads. If 48 cores each
>>> start 48 threads, each of those threads start another 48 etc., it doesn't
>>> take long before you have enough threads to bog down even the most powerful
>>> server.
>>>
>>> But what would be the purpose of a nested "run this on all cores"
>>> construct? You are already running on all cores, there are no spare
>>> resources, so in terms of CPU time I can't see how it would differ from
>>> merely having the pmapped function use a plain same-thread map?
>>>
>>> There are no particular advantages to pmap-pool over pmapall that I can
>>> see, except that pmap-pool lets you control the number of threads more
>>> easily. (E.g. for debugging "where does it stop scaling linearly" problems.)
>>> I thought creating thousands of agents (as pmapall does) would be more
>>> expensive, so I tried an alternative, but in practice they seem to be
>>> equally fast; at least on this test and the kind of hardware I have access
>>> to.
>>> So pmapall wins by having fewer lines of code.
>>>
>>>
>>> jf
>>>
>>> --
>>> 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 m

Re: Exception handling changes in Clojure 1.3.0

[Ivan Koblik]

I wonder, would it be possible to throw a custom exception (something like
DoNotUse_InternalRuntimeException) in Reflector.java, and update try/catch
code to always unwrap it?

Cheers,
Ivan.


On 12 October 2011 03:44, pmbauer  wrote:

> I don't know what the right solution is either, but here is a JIRA ticket
> with an attached regression test.  A start.
> http://dev.clojure.org/jira/browse/CLJ-855
>
> On Tuesday, October 11, 2011 3:02:47 PM UTC-7, Stuart Sierra wrote:
>
>> I was a little worried about this when the exception behavior for fns was
>> changed. I think it's solvable, but don't know right now what the solution
>> is.
>>
>> -S
>>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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: Libraries supporting 1.3&1.2 and bignums

[Ivan Koblik]

I feel myself silly, but could you explain how does this work?
(def +M (first [+' 1]))

Is it some kind of reader level trick?

Cheers,
Ivan.


On 11 October 2011 04:25, Alan Malloy  wrote:

> (def +M (first [+' 1])) seems like it should work in both versions?
>
> On Oct 10, 4:28 pm, Brian Marick  wrote:
> > I may be missing something obvious.
> >
> > Midje has a checker that lets users say things like
> >
> >(fact (my-computation) => (roughly 15  2))
> >
> > Where the first number in `roughly` is the target number and the second
> is an acceptable range around that target. Part of what the checker does in
> 1.2 is this:
> >
> >   (<= expected (+ actual delta))
> >
> > Now, Midje is a service. If the 1.3 user has taken care to use
> promoting-to-bignum arithmetic, it would be rude to blow up if `actual`
> happens to be a regular integer but adding `delta` to it causes an overflow.
> I should use promoting-to-bignum addition. In Clojure 1.3, thats +'. In 1.2,
> it's +.
> >
> > I can't use the token +' because it doesn't exist in 1.2:
> >
> > > java.lang.ClassCastException: clojure.lang.Symbol cannot be cast to
> java.lang.Number (NO_SOURCE_FILE:0)
> >
> > I can't use the token + because that blows up in the boundary case under
> 1.3 (but not under 1.2).
> >
> > One thought is variations of code like this:
> >
> > > (if (clojure-1-3?)
> > > (def +M +')
> > > (def +M +)
> >
> > This causes amusing results because of the quote. I haven't found a
> variation that works.
> >
> > So what should a library writer who wants to honor the choices of his
> users do?
> >
> > -
> > Brian Marick, Artisanal Labrador
> > Now working athttp://path11.com
> > Contract programming in Ruby and Clojure
> > Occasional consulting on Agile
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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: ordered map in Clojure?

[Ivan Koblik]

Hi Ken,

Having a mutable stm-map would be awesome. I actually had to implement one
for my project at work. Sorry can't publish it due to licensing issues, but
anyway my implementation is dead simple and won't perform well on big data
sets. I was trying to understand how to implement detection of new/removed
keys with current Clojure's STM, and could find a solution. As you
mentioned, second issue is merging of changes to the same map from two
different transactions.

I know that there is a transactional map somewhere inside Clojure that is
based on references, but its partitioning is too coarse and doesn't depend
on the data set.

I would love to implement stm-map, but I couldn't find a data structure that
would give good performance and small memory usage. I would appreciate if
you could point me to relevant documentation or research.

Cheers,
Ivan.


On 25 June 2011 22:33, Ken Wesson  wrote:

> On Sat, Jun 25, 2011 at 4:18 PM, Laurent PETIT 
> wrote:
> > Beware the devil hidden in the details:
> > "
> > Note that an array map will only maintain sort order when
> > un-'modified'. Subsequent assoc-ing will eventually cause it to
> > 'become' a hash-map.
> > "
>
> Besides a LinkedHashMap-alike, Clojure could probably use at least
> these other map variations:
>
> * WeakHashMap (keys weakly bound)
> * Map with weak values (useful for caching)
> * ConcurrentHashMap
>
> and possibly combinations of the above. Even Java seems to lack
> weak-value maps; you can fudge it though by putting a
> WeakReference(val) in in a wrapper layer and using a ReferenceQueue
> and a thread that drains the queue every so often to prune dead
> Map.Entries from the map.
>
> Note that a map of refs doesn't cut it as a substitute for a
> ConcurrentHashMap if keys will be added/removed by multiple threads,
> and sticking the entire map in an atom doesn't if you want to support
> more concurrency than a plain old Collections.synchronizedMap.
> Sticking the entire map in a ref and using commute doesn't quite work,
> if two concurrent assoces of the same key should force a retry, and
> sticking the entire map in a ref and using alter allows no more
> concurrency than synchronizedMap.
>
> We really could use an STM-map that supports normal Clojure map get
> semantics, but not assoc or dissoc, and supports alter-key and
> remove-key which have to be called in a transaction and act like
> commuted assoc and dissoc except that one transaction retries if there
> are concurrent attempts to change the *same* key.
>
> Perhaps we should also have a way to simply specify, separately and
> combinably, in both stm-map and hash-map, options to make the keys
> weak, the values weak, or the seq/keys/vals views use the insertion
> order. With both weakable keys and weakable vals you can also throw in
> a weak-hash-set which can be used to "intern" or "canonicalize" any
> desired immutable objects, without packratting them and eventually
> blowing the heap, and is implemented under the hood as a weak-keyed,
> weak-valued map of objects to themselves.
>
> --
> Protege: What is this seething mass of parentheses?!
> Master: Your father's Lisp REPL. This is the language of a true
> hacker. Not as clumsy or random as C++; a language for a more
> civilized age.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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: Using slurp to read changing JSON string

[Ivan Koblik]

Hi Thomas,

You need to execute this line:
  (dosync (ref-set location (read-json (slurp url
every time you want to re-query the string.

To do this periodically you could do something like this [1]:

(import '(java.util TimerTask Timer))
(let [task (proxy [TimerTask] []
   (run [] (dosync (ref-set location (read-json (slurp url))]
 (. (new Timer) (schedule task (long 15000

[1]: http://www.mail-archive.com/clojure@googlegroups.com/msg00136.html

Cheers,
Ivan.


On 6 June 2011 14:51, Thomas  wrote:

> Hi All,
>
> I recently started playing with Clojure and loving it... and finding
> of course the usual problem(s). In my little program I am reading a
> JSON string that changes regularly, up to once every 15 seconds or so,
> through HTTP. I know that the string changes, I can see that in my
> browser and I can see things change in another (web)app that consumes
> the string. My current code looks like this:
>
> (def url "http://.x.xx"; )
> (def location (ref nil))
> (dosync (ref-set location (read-json (slurp url
>
> My problem is, that once I have started the program it reads the
> string successfully, but subsequent reads are the same, even though I
> know that the string has changed. What should I do differently?  (I
> loop through the function with a bit of code from Rich Hickeys
> ants.clj)
>
> TIA
> Thomas
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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: Future of clojure.contrib.core/-?> macro

[Ivan Koblik]

Hi Paul,

Thanks, good to know. Sorry for the misleading email.

Cheers,
Ivan.


On 21 April 2011 08:47, pmbauer  wrote:

> Ivan,
> clojure/core use a different workflow than is typical for github
> projects.
> The github readme doesn't indicate, but you may find the process here:
>
> http://clojure.org/contributing
> http://clojure.org/patches
>
> Cheers,
> pm
>
> On Apr 20, 1:44 am, Ivan Koblik  wrote:
> > Hello Konrad,
> >
> > Git workflow is a little bit different. You don't really need commit
> rights
> > to contribute. I found a rather nice explanation of Git workflow here:
> http://www.eqqon.com/index.php/Collaborative_Github_Workflow
> >
> > Hope it helps.
> >
> > Cheers,
> > Ivan.
> >
> > On 19 April 2011 16:40, Konrad Hinsen 
> wrote:
> >
> >
> >
> > > On 19 Apr, 2011, at 13:56 , Stuart Halloway wrote:
> >
> > > >> Concerning my own modules in old contrib, there are three that I use
> > > myself and that I am planning to maintain, independently of where they
> will
> > > end up:
> > > >> - clojure.contrib.monads
> > > >> - clojure.contrib.macro-utils
> > > >> - clojure.contrib.generic
> >
> > > > There is an empty repos already waiting for your macro utils:
> > >https://github.com/clojure/tools.macro
> >
> > > Great, thanks, I'll start with that one. Monads depend on it anyway.
> But I
> > > need commit permissions, which I probably don't have, but I don't even
> know
> > > how to find out without trying to do a commit. Can you please add me in
> the
> > > right place? My github account is khinsen.
> >
> > > > I have put some suggested names for the other new projects at
> > >http://dev.clojure.org/display/design/Contrib+Library+Names. Please
> review
> > > and comment, either there or here on the list.
> >
> > > It seems that for now the top-level namespaces (well, next-to-top) are
> > > - clojure.core
> > > - clojure.data
> > > - clojure.java
> > > - clojure.tools
> >
> > > I would like to suggest a new one, clojure.control, for control
> structures.
> > > This would be the natural home for monads, but also for parallelization
> > > frameworks and even for threading macros. None of this really fits into
> > > "data" or "tools".
> >
> > > If the goal is to keep the number of top-level namespaces as small as
> > > possible, I'd even propose to put clojure.contrib.generic under that
> label.
> > > Otherwise, I'd propose yet another namespace, clojure.interfaces, where
> the
> > > various submodules of generic would find their home next to other
> protocols
> > > and interfaces of general interest.
> >
> > > Konrad.
> >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Clojure" group.
> > > To post to this group, send email to clojure@googlegroups.com
> > > Note that posts from new members are moderated - please be patient with
> > > your first post.
> > > To unsubscribe from 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
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Future of clojure.contrib.core/-?> macro

[Ivan Koblik]

Hello Konrad,

Git workflow is a little bit different. You don't really need commit rights
to contribute. I found a rather nice explanation of Git workflow here:
http://www.eqqon.com/index.php/Collaborative_Github_Workflow

Hope it helps.

Cheers,
Ivan.


On 19 April 2011 16:40, Konrad Hinsen  wrote:

> On 19 Apr, 2011, at 13:56 , Stuart Halloway wrote:
>
> >> Concerning my own modules in old contrib, there are three that I use
> myself and that I am planning to maintain, independently of where they will
> end up:
> >> - clojure.contrib.monads
> >> - clojure.contrib.macro-utils
> >> - clojure.contrib.generic
> >
> > There is an empty repos already waiting for your macro utils:
> https://github.com/clojure/tools.macro
>
> Great, thanks, I'll start with that one. Monads depend on it anyway. But I
> need commit permissions, which I probably don't have, but I don't even know
> how to find out without trying to do a commit. Can you please add me in the
> right place? My github account is khinsen.
>
> > I have put some suggested names for the other new projects at
> http://dev.clojure.org/display/design/Contrib+Library+Names. Please review
> and comment, either there or here on the list.
>
> It seems that for now the top-level namespaces (well, next-to-top) are
> - clojure.core
> - clojure.data
> - clojure.java
> - clojure.tools
>
> I would like to suggest a new one, clojure.control, for control structures.
> This would be the natural home for monads, but also for parallelization
> frameworks and even for threading macros. None of this really fits into
> "data" or "tools".
>
> If the goal is to keep the number of top-level namespaces as small as
> possible, I'd even propose to put clojure.contrib.generic under that label.
> Otherwise, I'd propose yet another namespace, clojure.interfaces, where the
> various submodules of generic would find their home next to other protocols
> and interfaces of general interest.
>
> Konrad.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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: Agent action queuing is asynchronous.

[Ivan Koblik]

Hello André,

Just wanted to mention that Java 7 is feature complete. You can see the list
of approved features here:
http://openjdk.java.net/projects/jdk7/features/

It seems that JSR203 was selected for the release, although I remember
reading that Clojure won't support Java 7 for awhile.

Cheers,
Ivan.


On 15 April 2011 02:13, André Caron  wrote:

> After further analysis, I don't think this is globally a good
> strategy.
>
> I looked into a solution with a "(ref (clojure.lang.PersistentQueue/
> EMPTY))" in the selector agent.  The plan was to have be able to queue
> "updates" to the schedule synchronously.  Half-way through the
> implementation, I realized this is equivalent to by-passing the entire
> agent system and still wouldn't work anyways.
>
> Even *if* send/send-off were forced to queue synchronously, the wakeup
> strategy isn't guaranteed to work.  There is still the possibility
> that "Selector.wakeup()" will be executed after the "dispatch" action
> has started, but before it calls "Selector.select()".  What would be
> necessary is for the agent system to sort-of interrupt calls to
> "dispatch" as soon as something else is sent to the agent.  Apart from
> requiring the most insane hack ever, this solution would be nothing
> close to elegant.
>
> Basically, I can't block on "Selector.select()", so I have to poll.
> Can't wait for JSR203 (http://www.jcp.org/en/jsr/detail?id=203) to be
> approved as part of Java 7.  Maybe that API will be less of a
> hassle...
>
> By the way, this is all for an open source project.  I've got the
> basic parts working, but it's still under heavy architectural
> changes.  As soon as version "0.1" is decent, I'll push the repository
> to GitHub and notify you guys.
>
>
> Regards,
>
> André Caron
>
> On Apr 14, 5:58 pm, André Caron  wrote:
> > I've posted this question on StackOverflow[1], but it might be a bit
> > technical, so I'll ask it on the mailing list where I might get more
> > precise expertise on Clojure.
> >
> > [1]:
> http://stackoverflow.com/questions/5669084/clojures-send-is-asynchronous
> >
> > I'm writing a simple networking framework for Clojure using Java's
> > "New I/O" package. It manages a pool of "selector agents", each of
> > which holds a `java.nio.channels.Selector`.
> >
> > I defined a `dispatch` action to for the selector agent. This action
> > blocks on a call to `Selector.select()`. When that returns, the
> > selector agent iterates over the selected keys and performs I/O. When
> > I/O is completed, the selector agent send's itself the dispatch action
> > using `send-off`, effectively looping on calls to `Selector.select()`.
> >
> > When I want to add a new channel or change a channel's interest ops, I
> > send the selector agent the appropriate action and then unblock the
> > selector (it's blocked on `Selector.select()`). This ensures that
> > `(send-off selector-agent dispatch)` in the selector agent is executed
> > after `(send selector-agent add-channel channel)` in whatever agent
> > changed the `SelectionKey.inrestOps()`.
> >
> > I thought this would be bullet-proof since the call to `send-off` is
> > performed before the selector waking up, and thus, before the selector
> > agent send itself the `dispatch` action.  However, this yields
> > inconsistent behavior.  Sometimes, the `dispatch` action occurs first
> > and sometimes it doesn't.  My understanding is that `send` and `send-
> > off` are themselves asynchronous in that they return before the agent
> > action being sent is actually queued in the agent's action backlog.
> >
> > Is this correct?
> >
> > This is normally not an issue; the action dispatch from different
> > agents/threads to the same agent is usually unpredictable and a non-
> > issue.  In this case, the real culprit is that I need to block on
> > `Selector.select()`.  One obvious workaround is to put a timeout on
> > the sleep operation, so that I don't need to manually unblock the
> > selector.  This puts me in the classic polling lose/lose situation,
> > where I need to decide on the polling frequency: too few polls and
> > suffer latency, too many polls and slow down the whole machinery.
> >
> > Does anyone have any better ideas, or can `send`/`send-off` be made to
> > actually queue the actions synchronously such that they are executed
> > int the *exact* order they are sent?
> >
> > Thanks,
> >
> > André Caron
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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 p

Re: eval'ing records

[Ivan Koblik]

David,

Sorry, I misunderstood your question at first. There was actually a
discussion on it a couple of days ago:
http://groups.google.com/group/clojure/browse_thread/thread/abb87a73330fdc01

Cheers,
Ivan.


On 14 April 2011 22:07, David McNeil  wrote:

> > I remember reading about it in the Joy of Clojure. It may be fixed in the
> > future versions of Clojure.
>
>
> Ivan - Thanks for the response. I checked Joy of Clojure and I see a
> reference at the top of page 191 to the fact that records cannot be
> printed and then eval'd. I was aware of this, however the issue I
> identified in this discussion is that record instances _themselves_ do
> not eval to themselves. This is a bit different than printing them and
> eval'ing them.
>
> -David
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 interest in Zurich

[Ivan Koblik]

Hello,

I'll be the third guy from Switzerland :) I live in Geneva... Any Clojurians
from Suisse romande?

Cheers,
Ivan.


On 14 April 2011 18:39, Nick Zbinden  wrote:

> Hi im not from zurich but I life near enough. There is no clojure user
> group (sadly). I acctualy don't know of anybody else using clojure in
> Switzerland.
>
> There is however a new "Lisp and Stuff"-Meeting more or less every
> month. It get hosted by a Startup that uses CL. The first to Meetings
> were quite intressting.
> http://zslug.wordpress.com/
>
> Would be great if there were enough people for a actual clojure user
> group.
>
>
>
>
>
>
> On Apr 14, 6:06 pm, Brian Marick  wrote:
> > I'll be working in Zurich from 16 May through 3 June. Anyone interested
> in weekend or evening Clojure hacking? Clojure user's group?
> >
> > -
> > Brian Marick, Artisanal Labrador
> > Contract programming in Ruby and Clojure
> > Occasional consulting on Agilewww.exampler.com,www.twitter.com/marick
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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: Clojure syntax highlight for web sites

[Ivan Koblik]

Hello Saul,

Thank you for the suggestion, I was looking for something that would work on
blogspot (I should had been more specific in my original post.) ... And now
I see that these snippets can be embedded! Thanks it looks great!

Also, yesterday, Mike Meyer recommended me to check how wordpress guys do
that, turns out there is a custom Clojure brush for syntax
highlighter.
Here's the original blog
postby
the author, and it can be downloaded from
here
.

Cheers,
Ivan.


On 1 March 2010 11:29, Saul Hazledine  wrote:

> On Feb 28, 10:57 pm, Ivan  wrote:
> > Do you happen to know of any JavaScript syntax highlighting library,
> > alikehttp://
> code.google.com/p/syntaxhighlighter/orhttp://code.google.com/p/google-code-prettify/,
> supporting Clojure and
> > not just Lisp. I've been trying to find one to no avail.
>
> I don't know if it matches your needs but http://gist.github.com/
> supports clojure.
>
> Saul
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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