Re: ants.clj and render thread starvation

2009-07-01 Thread Daniel Lyons


On Jun 30, 2009, at 11:50 PM, Krukow wrote:
 I like the pragmatics of :min-history, and I believe it would be
 sufficient for many scenarios. However, I suspect we are now moving
 closer to the situation that Cliff Click was predicting [1] where as a
 programmer you need more precise knowledge about the STM
 implementation to understand the behavior and tune its performance.


While that may be true for the time being I think that Rich's original  
response still holds water: that usually, correctness is more  
important than performance and correctness is the real win with STM.  
It's a nascent technology but that doesn't mean it's useless. Most  
people would probably rather utilize all four or eight of their cores  
at half the theoretical efficiency with no loss of correctness than  
have to create an old fashioned threading model with all the bugs and  
headaches that they entail, trying to get closer to that dream of 100%  
utilization. This is fast food parallelism. It isn't as optimal or as  
hard won but from a cost vs. benefit perspective the choice is  
obvious, especially when comparing to single threaded programming.

STM might be new, but I think an analogy to garbage collection is  
valid. We don't have all the best STM implementation algorithms down  
yet; certainly this is an active research area. But even back when GC  
was extremely new it was already a win for LOC and correctness. Over  
time the technologies got better and the performance question has  
mostly faded away, and it's going to be the same with STM. But only if  
the focus is on correctness first and performance second.

I say mostly faded away because there will always be applications  
where GC cannot be used simply because it makes the system less  
predictable or because it incurs its own cost, such as realtime  
systems and extremely small-scale embedded devices. But most systems  
are not realtime and GC is quite prevalent, even though realtime  
performance characteristics seem generally desirable. It just isn't  
worth the tradeoff in desktop software. Lots of software will benefit  
from STM, even if the performance gains are minimal, even if it turns  
out to be provably impossible to push performance past half that of  
classically threaded programs.

Often there is a sound theoretical reason for throwing out an idea  
which turns out to occur so infrequently in the wild working on it is  
a net win anyway. Ethernet is a good example of a technology that  
shouldn't work well in the wild but which does. A stronger example  
would be Microsoft's Terminator project, which, in attempting to  
create termination proofs for programs through static analysis, flies  
in the face of CS's most famous mathematical proof. It turns out the  
problem is important enough that even the partial, imperfect solutions  
we are damned to would be useful in practice (as long as you don't try  
and run it through itself, of course ;)

http://research.microsoft.com/en-us/um/cambridge/projects/terminator/

The rest of that original thread is a great read, by the way, and  
thanks for bringing it up!

—
Daniel Lyons


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

2009-07-01 Thread Nicolas Oury
Hello,
That is an interesting blog post. I am not a clojure specialist, but if I
was to try to change your program to get towards C-like speed (or better), I
would :

- Use java arrays for memory. You don't seem to use the vectors in a
persistent way, and there does not seem to be easy parallelization of the
vm. That's less elegant but probably quicker. I wouldn't say the same thing
if there were possible ways of using persistency later on in the problem.

- Most criticaly, try to use JVM's very good JIT. If it is possible. I
haven't looked to the OVM code precisely.
  If you replace :

(defn make-add
 [#^Integer r1 #^Integer r2 #^Integer pc]
 (fn [machine-state]
 (update-in machine-state [:data] ...)

by :

(defmacro make-add
 [r1 r2 pc-var]

 `(let [pc# (+ 1 pc-var)  (update-in machine-state ...)...)

And instead of reading the instruction and storing them in a vector
you create a term:

program-term =

   `(fn [input-array output-array memory]

  (do ~...@list-of-instructions)

Then you (eval program-term) (once only) at run time, or macro expand
it at compile time (if you have the right to use the binary at compile
time.)

This way, the code should be very fast, once the JIT starts. You can
hope better speed than C, because once compiled, you remove the
decoding phase of the opcode the C program has to do on each run.
Somehow you used clojure to translate OVM bytecode to - hopefully good
- JVM bytecode, that the JVM is very good at executing.

Can a clojure expert confirms wether it would work or not?

Best regards,

Nicolas.

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

2009-07-01 Thread Michael Wood

Hi

2009/7/1 mmwaikar mmwai...@gmail.com:
 Hi,

 I am learning clojure these days, but on .Net. I have the following
 code -

I only have a tiny bit to add to what Daniel's already said.

[...]
 (defn GetSubfolderName [filename]
        ((def name-wo-extn (Path/GetFileNameWithoutExtension filename))

First, def creates basically global variables (or something similar).
You want let instead.
Second, you can't just add parentheses as you see fit. :)

(def name-wo-extn something)

is defining name-wo-extn as the string something.

((def name-wo-extn something))

is trying to define name-wo-extn as the string something and then
call it as a function.  Since something is a String and not a
function (or something that acts as a function), this will fail.

So, for ((def name-wo-extn (Path/GetFileNameWithoutExtension
filename)) ...) implies that (Path/GetFileNameWithoutExtension
filename) returns a Clojure function (or something that can be used as
one, like a map/set/etc.).  I suppose Path/GetFileNameWithoutExtension
is a .Net method, in which case it is unlikely to work as a Clojure
function.  Java methods can't be used in place of Clojure functions
and I assume it's the same for the .Net port.

         (def first-char (aget (.ToCharArray (.ToString name-wo-extn)) 0))
         (if (Char/IsDigit first-char) (Convert/ToInt32 first-char) (if
 (starts-with-hmorx first-char) (.ToLower (.ToString first-char))
 other

 But when I call (GetSubfolderName D:\\CsEx\\Manoj.cs), I get this
 exception -

 System.InvalidCastException: Unable to cast object of type
 'System.String' to type 'clojure.lang.IDeref'.

I think the extra parentheses are the reason for this exception.

   at lambda_method(Closure , Object )
   at AFunction_impl.invoke(Object )
   at lambda_method(Closure , Object )
   at AFunction_impl.invoke(Object )
   at lambda_method(Closure )
   at AFunction_impl.invoke()
   at REPLCall(Closure )
[...]

-- 
Michael Wood esiot...@gmail.com

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



agents + repl?

2009-07-01 Thread Raoul Duke

(i googled but didn't find anything about this yet...)

while trying to understand the graphics animation code from ants.clj,
i tried this simpler code, but when i run the code below in the repl,
i don't see the .s until i evaluate something afterwards; then they
get flushed to the console. is this something about agents+repl? or
something else i'm not grokking? many thanks for edification.

(defn new-animator []
  (agent 0))
(def running true)
(def animation-sleep-ms 250)
(defn animation [i]
  (when running
(send-off *agent* #'animation))
  (print .)
  (. Thread (sleep animation-sleep-ms))
  nil)
(send-off (new-animator) animation)

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

2009-07-01 Thread Laurent PETIT

Hi Tom,

Thanks for the answer. I already have some embryonic antlr grammar for
clojure, but I'm willing to give pprint a thourough try.

I'll play with your code. Do you have a first pass over the clojure
reader to attach other meta information as you go, or do you directly
consume the clojure data structures the reader passes to you ? If so,
then certainly there would be the need to have an intermediate
structure that would be the output of both clojure reader parsed
code and source code preserving reader parsed code ? So that the
rest of the formatting code is decoupled from that ? (But that will
certainly be lots of changes, and in all parts I guess).

As far as IDE integration is concerned, i would not bother (at first)
about incremental thing. I rather intend to always parse the entire
edited file content (of course if this causes a performance problem, I
might rethink about it). For performance testing, I've found that
clojure/core.clj is a good candidate :-)

Regards,

-- 
Laurent

2009/6/30 Tom Faulhaber tomfaulha...@gmail.com:

 Hi Laurent,

 I think that pprint might be a good foundation for what you are doing,
 but there are a couple of issues that need to be dealt with first.

 First, pprint works directly on Clojure objects and not strings, so
 the code will need to be read first.

 Second, the Clojure reader is lossy - it strips comments, metadata
 tags (#^{}) and expands forms like backquote and reader time
 evaluation before passing you the result.

 The first thing I would do is look at making a modified reader that
 could read chunks of s-expression and pass back raw data. In a perfect
 world, this reader would be much more resistant to syntax problems
 (for example by assuming extra opening or closing brackets of
 various types).

 Then I would look at how I was going to attach the pprint to the
 editor. In practice, I think you want the reformatting to be very
 incremental, working on small chunks of code at a time, but you know
 better than I.

 Using the code dispatch in pretty printing should be pretty easy once
 you have this infrastructure. You'll probably want to customize it a
 little, but that's fairly straightforward. You'll also probably want
 to clean up any syntax corrections you made. I might think about
 adding metadata to the read structure and then using that in the
 dispatch to skip writing open parens that weren't really there, for
 instance.

 I've been thinking about doing all this, but it's not at the top of my
 list right now (working on a new contrib autodoc tool and making
 pprint cleaner and faster plus my real job!). But I'm happy to discuss/
 help in the short term.

 HTH,

 Tom

 On Jun 30, 7:08 am, Laurent PETIT laurent.pe...@gmail.com wrote:
 Hi all,

 I want to add source code formatting / auto-indenting to the clojure
 plugin for eclipse.

 I had asked other IDE plugin creators, and it seems that they
 leveraged the specifics of their respective platforms to do so. So I
 have nothing substantial to steal from them not requiring a fair
 amount of rework :-)

 I'm now facing the following two paths :

  * try to leverage Eclipse's way of doing clojure source code
 formatting / auto-indenting and create yet another lib for doing that
 very specifically

  * try to do it in clojure so that it can also be used as a standalone
 command-line / whatever utility for mass source code reformatting ...

 So what is my question ? :-)

 Do you know if pprint lib now is (or will in a near future) be able to
 handle this use case : that is not only formatting clojure code
 returned by the reader, but also clojure code as string, and
 potentially broken code (and so it would have to preserve comments,
 literal metadata in the exact form they were written, etc.)

 Do you know whether there is another existing effort to do this in
 plain clojure, or at least sufficiently independtly from an existing
 IDE framework so that I can painlessly reuse it ?

 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: agents + repl?

2009-07-01 Thread Timothy Pratley

You just didn't
  (flush)

Regards,
Tim.


On Jul 1, 5:43 pm, Raoul Duke rao...@gmail.com wrote:
 (i googled but didn't find anything about this yet...)

 while trying to understand the graphics animation code from ants.clj,
 i tried this simpler code, but when i run the code below in the repl,
 i don't see the .s until i evaluate something afterwards; then they
 get flushed to the console. is this something about agents+repl? or
 something else i'm not grokking? many thanks for edification.

 (defn new-animator []
   (agent 0))
 (def running true)
 (def animation-sleep-ms 250)
 (defn animation [i]
   (when running
     (send-off *agent* #'animation))
   (print .)
   (. Thread (sleep animation-sleep-ms))
   nil)
 (send-off (new-animator) animation)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Article on Dispatch

2009-07-01 Thread Emeka
Thanks, more of it.

Emeka

On Mon, Jun 29, 2009 at 12:31 AM, Daniel Jomphe danieljom...@gmail.comwrote:


 I think the following article I wrote may help properly understanding
 dispatch. I submit here for your pleasure/review.

 First paragraph:

 I believe multiple dispatch is known to be hard to understand. When I
 first read about it, for some reason, it took me quite a lot of
 thinking before I really understood it all. Now that I understand it
 very well, I find it odd that it felt so challenging at the time. For
 this reason, I wanted to try putting an end to this nonsense. There’s
 probably other articles out there that explain it very well today. In
 any case, here’s my take. As usual with me, it’s pretty wordy: I like
 to surround that kind of knowledge with lots of useful observations.


 http://danieljomphe.github.com/2009/06/18/understanding-function-dispatch.html
 


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

2009-07-01 Thread Rowdy Rednose

On Jul 1, 12:02 am, Chouser chou...@gmail.com wrote:
 You could wrap a Ref around every value, if you chose, to
 allow independent changes to different rows at the same
 time -- though this would not help when inserting rows.

I guess having millions of Refs would not perform too well. Plus you
don't need that level of concurrency any time soon, I guess (and
hope).

 You could partition your key space somehow (perhaps by hash)
 to allow n groups of rows, and protect each of those with
 a Ref.  This would allow insertions and deletions
 independently as long as the operations were being applied
 to different groups.

Sounds feasible and reminds me of the lock striping done in
ConcurrentHashMap. It would allow me to use a number of refs that
depends on the number of available processors.
One thing that I wonder is whether this data structure should be
written in Java or in Clojure.

Is there any other database implemented in clojure besides
contrib.datalog? contrib.datalog doesn't have (write) concurrency and
it looks like that is something that cannot be added without changing
the interface.

I'm basically looking for a database that allows the (clojure) user to
listen on database updates that match certain criteria, just like the
observers in the Functional Relational Model paper by Moseley and
Marks.

But it looks like I have to implement that myself - which is not a
complaint, but I'm trying to estimate the amount of work necessary.
But I guess I could just start with one Ref per relation and then make
it more concurrent later - if I choose an interface that allows it.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 only (in-memory) database / locking granularity

2009-07-01 Thread Matt Culbreth


On Jul 1, 8:02 am, Rowdy Rednose rowdy.redn...@gmx.net wrote:


 But it looks like I have to implement that myself - which is not a
 complaint, but I'm trying to estimate the amount of work necessary.
 But I guess I could just start with one Ref per relation and then make
 it more concurrent later - if I choose an interface that allows it.

This looks like a cool project--please keep us updated if you actually
begin it.  I'm sure others wouldn't mind helping.

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

2009-07-01 Thread Chouser

On Fri, Jun 26, 2009 at 5:12 PM, Kaipoki...@gmail.com wrote:

 I'm new to this discussion group and Clojure.

Welcome!

 I'm sharing the first
 bigger-than-REPL script that I've written because I haven't seen
 anything else like it for Clojure. It's a script that takes Clojure
 code as input and generates a pretty HTML version. You can view it
 here (I ran the script through itself):

 http://kai.myownsiteonline.com/clojure/html.clj.html

The results are attractive, thanks for sharing!

I see you've copied 'spit' from clojure.contrib.duck-streams.
While of course it's perfectly acceptable to re-use
open-source code, it is important that when you copy an
author's code, that you follow the rules laid out by that
author.  In this case there are implications for the license of
your own code.  At the very least it would be polite to give
credit.  Anyway, I assume this was an innocent oversight and
that you'll fix it soon.

 I'd appreciate comments on the coding style

Well, since you ask... :-)

Your use of sets in 'whitespace?', 'starting?', etc. is
excellent.  You could similarly use maps for 'html-entity'
and 'html-whitespace' -- 'get' accepts a default value,
which might be useful here.   ...and now that I'm looking at
it, I think even 'whitespace?' could be just:

  (def whitespace? #{\, \newline \tab \space})

Also, you might be interested in 'condp' -- it'd be useful
in several places in that file.

Thanks again for sharing your code,
--Chouser

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

2009-07-01 Thread Rowdy Rednose

I'm just trying to once and for all find or implement a clojure
solution for the simple problem that most companies (that make heaps
of money developing super boring software) have: There's relational
data like Persons and Companies, that needs to be accessed and
manipulated by multiple client programs concurrently.

But even today, where everyone working on that kind of problem should
have seen frameworks like Ruby on Rails, there exist (especially in my
current job) horrible homegrown frameworks, where adding a simple
new business object or making changes to an existing one is a
serious pain in the neck.
I've implemented different solutions to that problem myself for
different companies using standard sql databases and languages like
Java. None of these solutions was as bad as what I currently have to
put up with, but none was perfect either and each one had their
downside.

Think about (de)serialization, caching, high availability (failover
primary/backup) and so forth - all of these layers are hand-written
with custom code for every single business object in my current
company. And if this is the core of the system, you can imagine how
all the code that uses it looks like. It's inconsistent and very
brittle (concurrency).

That said, I have already implemented an in-memory database system in
clojure which is consistent (constraints) and allows to you to listen
for modifications, but it's my first attempt of something like this in
Clojure and therefore highly un-idiomatic, not clean and well-
structured (namespaces) and for all those reasons hard to maintain.

But now that I have something that actually works, I plan to
completely rewrite it from scratch in a cleaner way. But I want to get
some things clear first to see whether I'm going the right way.

One other thing that I want to do in that rewrite is define (or reuse)
languages for querying, manipulating and defining the schema and
constraints. Currently for example I accept any clojure function with
one argument for the check constraints. I want to restrict that to a
well-defined set of functions/operations that can be arbitrarily
combined.
One reason I want to this is so that I can persist all modifications
to disk (and thus make it durable), in a descriptive format that is
clojure-independent.
If these function can be arbitrary clojure code god knows what
problems I'm inviting - non-pure code, making the persistence files
depend on a certain version of clojure and so forth.

But if in the meantime someone pops up in the group saying that they
implemented a system similar to the one described in Functional
Relational Programming, I'll probably immediately dump my code and
just use that... :)

On Jul 1, 9:18 pm, Matt Culbreth mattculbr...@gmail.com wrote:
 On Jul 1, 8:02 am, Rowdy Rednose rowdy.redn...@gmx.net wrote:



  But it looks like I have to implement that myself - which is not a
  complaint, but I'm trying to estimate the amount of work necessary.
  But I guess I could just start with one Ref per relation and then make
  it more concurrent later - if I choose an interface that allows it.

 This looks like a cool project--please keep us updated if you actually
 begin it.  I'm sure others wouldn't mind helping.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: ants.clj and render thread starvation

2009-07-01 Thread Rich Hickey

On Wed, Jul 1, 2009 at 1:50 AM, Krukowkarl.kru...@gmail.com wrote:


 On Jun 30, 6:01 pm, Rich Hickey richhic...@gmail.com wrote:
 MVCC history in Clojure's STM is dynamic, created by need. There is no
 read tracking, and more important for this case, no transaction
 tracking. So, if a read transaction is unable to satisfy its snapshot
 view from history, it will flag the offending ref with a fault and
 retry. When a writer sees a ref with a read fault it will grow history
 for that ref. In this way only as much history is created as is needed
 to satisfy the dynamic contention patterns, and
 tracking/synchronization is minimized.

 Ok - I understand better now. I guess I had an idealized system in
 mind where each ref (in principle) had a complete history associated
 with it so reads would never need to be retried (of course, unneeded
 entries would somehow be discarded when the system decides it can
 never be read.) Certainly that would imply tracking transactions. I
 guess you don't do this because of the overhead.

 I like the pragmatics of :min-history, and I believe it would be
 sufficient for many scenarios. However, I suspect we are now moving
 closer to the situation that Cliff Click was predicting [1] where as a
 programmer you need more precise knowledge about the STM
 implementation to understand the behavior and tune its performance.


Yes, ok, but the key questions are, how complex is it really, and,
compared to what?

Any large lock-based application will have an ad hoc lock policy
approaching the complexity of Clojure's STM. Each programmer will have
to learn the lock strategy of each program. And what happens when
requirements or the hardware capabilities change? I'd much rather have
knobs like :min-history than to have to go through an app and change a
lock architecture that is woven throughout. In fact, I think the
possibility for knobs is a key strength of an STM. Furthermore, such
knobs can be dynamic, allowing for applications that analyze their own
runtime situation and adapt, in this case trading off memory for
concurrency. Try doing that with a lock policy. (I know you are not
advocating for locks, but Cliff was).

As usual, comparisons to GC hold. There are many flavors of GC, each
with different characteristics. An app will have to choose the right
flags, understanding the tradeoffs involved. It is still a lot better
than manual memory management for most apps.

At JavaOne I did a demo showing how an app could put its own runtime
'knob' on transaction granularity, to useful effect. A point I tried
to make was that this was the level at which one wants to think about
their concurrency issues. (Ok, fine, one would like magic that makes
it all go away :) Thinking about what constitutes a unit of work, what
are the contended resources etc. Being able to deal with that using
'knobs' on a system that is ensuring correctness seems like a huge win
to me.

So, certainly many of the things Cliff said are true, but are they
negatives? You will have to understand the fundamental characteristics
of your STM, and any knobs it provides. You will have to choose
transaction boundaries. You will have to choose ref granularity. Ok.
But absolutely nothing is going to make the fundamental issues of
concurrency go away. The real question is, what facilities are
provided for dealing with them, and how closely do they map to the
nature of the problem? How much effort do you have to spend on
correctness?

What render is getting there is really a huge thing - a consistent
snapshot of the world, that spans multiple entities, without holding
up everyone else. I have yet to see a non-STM solution (that isn't an
ad hoc STM or MVCC) that can provide the same.

I'll try to expand upon adaptive history queues, and the new knobs,
in the docs so people can better understand what they imply.

Rich

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



Re: ants.clj and render thread starvation

2009-07-01 Thread Krukow



On Jul 1, 8:43 am, Daniel Lyons fus...@storytotell.org wrote:
 While that may be true for the time being I think that Rich's original  
 response still holds water: that usually, correctness is more  
 important than performance and correctness is the real win with STM.  
[snip...]

Agreed - happy Clojure user here. Just thought it was interesting to
note.

 The rest of that original thread is a great read, by the way, and  
 thanks for bringing it up!

You're welcome - one of the problems with newsgroups is that lots of
lots of very useful information is out there, but not always to easy
to find  - so referring back once in a while is good ;-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: ants.clj and render thread starvation

2009-07-01 Thread Krukow



On Jul 1, 3:09 pm, Rich Hickey richhic...@gmail.com wrote:
[snip]
 lock architecture that is woven throughout. In fact, I think the
 possibility for knobs is a key strength of an STM. Furthermore, such
 knobs can be dynamic, allowing for applications that analyze their own
 runtime situation and adapt, in this case trading off memory for
 concurrency. Try doing that with a lock policy. (I know you are not
 advocating for locks, but Cliff was).

That sounds very interesting. Can you share the JavaOne program?
(perhaps with some text explaining the points you made :-)

[snip]
 So, certainly many of the things Cliff said are true, but are they
 negatives? You will have to understand the fundamental characteristics
 of your STM, and any knobs it provides. You will have to choose
 transaction boundaries. You will have to choose ref granularity. Ok.
 But absolutely nothing is going to make the fundamental issues of
 concurrency go away. The real question is, what facilities are
 provided for dealing with them, and how closely do they map to the
 nature of the problem? How much effort do you have to spend on
 correctness?

Yes, perhaps this is a good way of looking at it. Also I like the
analogy with GC tuning: by default it does pretty well, and in
addition you have various knobs to tune performance and other
characteristics (e.g. stop-the-world or concurrent) - and of course
you have to understand the GC to use these knobs.

[snip]
 I'll try to expand upon adaptive history queues, and the new knobs,
 in the docs so people can better understand what they imply.

This would be really useful. In order to turn the knobs correctly we
need a more detailed understanding about the design/implementation.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Re: loneclojurian at ICFP programming contest

2009-07-01 Thread igorrumiha

On Jul 1, 8:55 am, Nicolas Oury nicolas.o...@gmail.com wrote:
 - Use java arrays for memory. You don't seem to use the vectors in a
 persistent way, and there does not seem to be easy parallelization of the
 vm. That's less elegant but probably quicker. I wouldn't say the same thing
 if there were possible ways of using persistency later on in the problem.

I have already started on that path, I have created an experimental
version of the VM that stores machine state in Java arrays. That gives
me around 100% speed increase (from 600 to approx. 1200 program
executions / second).

[SNIP interesting advice]

This looks like an interesting approach. I will try it out. I have
been avoiding the use of macros for some time now, maybe this is an
ideal opportunity to learn how to use them :)

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

2009-07-01 Thread cridal

I would definitely be interested...

Marcin.

On Jun 4, 12:09 pm, Eric Thorsen ethor...@enclojure.org wrote:
 I went to the Bay Area Clojure group meeting last night which was
 great.  People demoed some very interesting stuff and it was great
 having face time with more people using Clojure.   I wanted to see
 what kind of interest there might be in creating a Clojure user group
 in the NY metro area to meet up in Manhattan once a month to discuss
 all things Clojure. My company is in Westchester but I can _probably_
 get some space (depending on how many of us there are) to meet.

 Eric

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



Penumbra, a new set of OpenGL bindings

2009-07-01 Thread ztellman

Most of the OpenGL code I've seen has been a fairly literal
translation of the corresponding Java, so as a way of getting my feet
wet in Clojure I've written something that tries to be a little more
idiomatic.  It can be found at http://github.com/ztellman/penumbra/tree/master

The only really novel thing it brings to the table is intra-primitive
transformations, which means that you can update the transformation
matrix while defining a shape.  It's always bothered me that OpenGL
doesn't allow this, so I added an additional transform step before
passing the coords to glVertex.  This can be bypassed, but if you use
call lists it doesn't affect your performance at all.

If anyone has any questions or thoughts, I'd be happy to hear them.


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

2009-07-01 Thread Michał Kwiatkowski

On Wed, Jul 1, 2009 at 9:43 AM, Raoul Duke rao...@gmail.com wrote:
 while trying to understand the graphics animation code from ants.clj,
 i tried this simpler code, but when i run the code below in the repl,
 i don't see the .s until i evaluate something afterwards; then they
 get flushed to the console. is this something about agents+repl? or
 something else i'm not grokking? many thanks for edification.

Try adding (flush) after your print. By default only newline
characters flush the output, so if you don't end your message with a
newline you have to flush manually.

Cheers,
mk

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



Re: Clojure for Scientific and other CPU-intensive Computing

2009-07-01 Thread Daniel E. Renfer

Mark Engelberg mark.engelb...@gmail.com writes:

 On Tue, Jun 30, 2009 at 12:29 AM, Konrad
 Hinsenkonrad.hin...@laposte.net wrote:
 What is particularly nice about Clojure is that in most situations
 you don't need to switch to Java for speed. You can optimize your
 code by adding type hints and switching to low-level data structures
 (unboxed ints and floats, arrays, ...) and get performance equal to
 Java.

 I have heard this claim about Clojure's speed a number of times, and I
 am curious what the evidence for this claim is.  As far as I know, no
 one has written a suite of meaningful benchmarks to compare the
 performance of Clojure versus Java.

 On the other hand, every month or so, someone posts here saying they
 tried to do a single benchmark, and it runs quite a bit slower than
 Java.  People help out, and usually some ways to improve the code are
 found, but I don't think I've ever seen the code actually get to the
 point where it has performance equal to Java.


I think a problem with a lot of these micro-benchmarks is someone will
find a small function in java and then try to write a clojure function
that does the same thing the same way. 

I think a lot of the times you don't really see the speed increase until
you take into account that you will do things differently in the larger
picture with clojure than you would with java.

When you take into account that clojure offers up algorithms that would
be downright unwieldy to attempt in java do you really see the speeds
even out.

Daniel E. Renfer

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



Re: Clojure for Scientific and other CPU-intensive Computing

2009-07-01 Thread Konrad Hinsen

On Jun 30, 2009, at 19:07, Mark Engelberg wrote:

 On Tue, Jun 30, 2009 at 12:29 AM, Konrad
 Hinsenkonrad.hin...@laposte.net wrote:
 What is particularly nice about Clojure is that in most situations
 you don't need to switch to Java for speed. You can optimize your
 code by adding type hints and switching to low-level data structures
 (unboxed ints and floats, arrays, ...) and get performance equal to
 Java.

 I have heard this claim about Clojure's speed a number of times, and I
 am curious what the evidence for this claim is.  As far as I know, no
 one has written a suite of meaningful benchmarks to compare the
 performance of Clojure versus Java.

Right. The claim (at least when coming from me) is based entirely on  
micro-benchmarks that are probably of little practical importance.

 On the other hand, every month or so, someone posts here saying they
 tried to do a single benchmark, and it runs quite a bit slower than
 Java.  People help out, and usually some ways to improve the code are
 found, but I don't think I've ever seen the code actually get to the
 point where it has performance equal to Java.

I suspect that the fundamental problem is the enormous difference  
between Clojure and Java. Translating idiomatic Java into Clojure is  
not likely to result in efficient code, and translating idiomatic  
Clojure into Java is likely to be a major headache.

For a practically valid comparison, you'd have to give the  
specification of a meaningful application to a few teams of competent  
Clojure programmers and a few teams of competent Java programmers,  
and compare the programs that all these teams produce. They might  
well be very different starting from the choice of algorithms and  
data structures.

My current approach is to work with Clojure as much as I can, knowing  
that in the worst case, there are other JVM languages, including Java  
itself, that I can turn to if I ever run into a serious performance  
problem.

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



Apache POI wrapper????

2009-07-01 Thread Sean Devlin

Hey,
Has anyone out there written an Apache POI wrapper yet?

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



Re: send versus send-off

2009-07-01 Thread Kai

Thanks Meikel and Steve it is quite clear now! I will redirect
questions here should anybody ask.

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

2009-07-01 Thread richard claxton
Thanks for the heads up.
Michael Swaine used to be the editor of dr dobbs journal which I enjoyed
reading for years.
so it should be a good read.

On Wed, Jul 1, 2009 at 3:40 PM, nrub p...@typosfrompaul.com wrote:


 For anyone that's interested check out http://www.pragprog.com/magazines

 It looks like pragmatic publishing is going to start pushing out
 monthly magazines. I just checked out issue #1 which seems to have
 some good stuff, including an interview with Rich Hickey  An article
 by Stuart Halloway on Error-kit.

 The interview seems like a great article to pass to friends who might
 be intrigued by clojure, but haven't quite made the jump. So far
 that's all I've read, but I'll check out the article by Stuart tonight
 I'm sure.

 


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

2009-07-01 Thread Maurice Codik
I did icfp09 on my own using a mix of clojure+java. I'd sitll call myself a
clojure newbie, but have been writting java for a few years now. my code is
here:

http://github.com/mcodik/icfp2009-momo/tree/master

I wrote the vm in java since I figured that most of the code would be really
imperative with lots of writing/reading arrays and bit twiddling, both of
which I was more comfortable doing in java. My vm's main run method takes
in an IFn which it calls after every iteration.. this let me write all of
the physics code in clojure. I didnt really benchmark my vm at all until
just now, but looks like I get around 75k iterations/s on my thinkpad t60
with visualization disabled, and around 22k iters/s with visualization on.
the visualization is a simple swing ui that draws points and circles
representing orbits and sattelite positions (also written in java).

the only actually interesting part about the clojure code was the state
machine I ended up using: I had a ref set to a function of vm inputs -
velocity change and on every vm tick I would call the function currently
assigned to the ref. I created a few of these functions that would do
specific things: I had one that would wait N vm ticks then ref-set another
function as the active one. Another would execute a burn for N ticks then
ref-set another active function when complete. The function that executed a
hohmann orbit transfer would compose these two and then set another active
function, etc. I was having a tough time getting things to happen when I
wanted to before I got the state machine going.

the code in that git repo solves 100x, 2001, 2003 and 2004. I never got 2002
to work due to some rounding error.. I'd always end up slightly outside the
1km range of the target sattelite.

overall, pretty fun contest... learned quite a bit doing it.

Maurice

On Wed, Jul 1, 2009 at 6:45 AM, igorrumiha igorrum...@gmail.com wrote:


 On Jul 1, 8:55 am, Nicolas Oury nicolas.o...@gmail.com wrote:
  - Use java arrays for memory. You don't seem to use the vectors in a
  persistent way, and there does not seem to be easy parallelization of the
  vm. That's less elegant but probably quicker. I wouldn't say the same
 thing
  if there were possible ways of using persistency later on in the problem.

 I have already started on that path, I have created an experimental
 version of the VM that stores machine state in Java arrays. That gives
 me around 100% speed increase (from 600 to approx. 1200 program
 executions / second).

 [SNIP interesting advice]

 This looks like an interesting approach. I will try it out. I have
 been avoiding the use of macros for some time now, maybe this is an
 ideal opportunity to learn how to use them :)

 --
 Igor.
 


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

2009-07-01 Thread Laurent PETIT

Hi, thanks for the pointer !

By the way, I was wondering whether error-kit can be leveraged
seamlessly with concurrent programming ?

For example I guess that using (vec (pmap ...) instead of (vec (map
...) will not work because the binding of the handlers will be lost.

I have always been ashamed by this consideration, and frustrated that
I can't think about a way to free the developer from having to keep
this in a corner of his mind ... (if I'm right, of course).

Do you think it is a problem that  has no good theoretical solution,
or just a current implementation feature that could be enhanced in
the future ?

I see this as if the application context were lost when a technical
machinery reinitialized the application context with a new empty
application context. Thinking about it this way implies that the new
context could be totally overriden by the application context, but
I'm not sure I can say that for the general case ? (Though I guess it
is).


What do you think about this ?

2009/7/1 nrub p...@typosfrompaul.com:

 For anyone that's interested check out http://www.pragprog.com/magazines

 It looks like pragmatic publishing is going to start pushing out
 monthly magazines. I just checked out issue #1 which seems to have
 some good stuff, including an interview with Rich Hickey  An article
 by Stuart Halloway on Error-kit.

 The interview seems like a great article to pass to friends who might
 be intrigued by clojure, but haven't quite made the jump. So far
 that's all I've read, but I'll check out the article by Stuart tonight
 I'm sure.

 


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

2009-07-01 Thread Shawn Hoover
Another one: http://bitbucket.org/shoover/icfp. Like Jeff we had fun on the
VM but didn't get to post a solution :)

On Wed, Jul 1, 2009 at 1:34 AM, Jeff Foster dr.jeff.fos...@gmail.comwrote:


 I looked at the ICFP Contest too.  I didn't even get as far as solving
 the first problem, but I did implement a virtual machine that appeared
 to work.  I really enjoyed the coding, though I didn't get very far
 with the physics!  I tried a couple of approaches but settling on the
 functional side.  Performance was not bad (from what I've seen it was
 vaguely comparable to the Python implementations, but was completely
 blown away by C/C++ implementations).  I really wish I'd had the time
 to do a visualizer!

 My code is on github too (http://github.com/fffej/ClojureProjects/tree/
 1494815e83febebe9af28b0cb08b812a63df9e96/icfp/uk/co/fatvathttp://github.com/fffej/ClojureProjects/tree/%0A1494815e83febebe9af28b0cb08b812a63df9e96/icfp/uk/co/fatvat)
 and
 there's a write-up on my blog (http://www.fatvat.co.uk/2009/06/icfp-
 contest-this-time-its-functional.htmlhttp://www.fatvat.co.uk/2009/06/icfp-%0Acontest-this-time-its-functional.html
 ).

 Again, I'd appreciate any guidance on anything that I could improve!

 Cheers

 jeff

 On Jun 30, 11:02 pm, igorrumiha igorrum...@gmail.com wrote:
  Greetings everyone,
 
  I didn't actually plan it but I ended up participating in the ICFP
  programming contest (http://www.icfpcontest.org). This year the task
  was to move satellites from one orbit to another, to meet with other
  satellites etc. Quite interesting, and to start it all you need to
  implement a virtual machine for the physics simulator.
 
  I used Clojure and managed to solve the first of the four problems,
  which means I didn't get really far. I was simply too slow to get to
  the really interesting stuff. I have written a rather long article
  describing my solution so I hope some of you may find it interesting:
 
  http://igor.rumiha.net/tag/icfp/
 
  I have also put the code on github:
 http://github.com/irumiha/icfp-loneclojurian/tree/master
 
  I hope someone has the interest and the time to take a look at the
  code. I consider myself a Clojure beginner and any suggestions are
  welcome, especially considering possible speed improvements to the
  virtual machine. According to some of the people on the #icfp-contest
  channel my VM implementation is 500x to 1000x slower than a typical
  implementation written in C. It is, on the other hand, in the same
  performance range as some VMs written in Python. Some people claim
  that the JVM can give you C-like performance, but I would be more than
  happy if I got my VM to be 10x slower than the C ones :)
 
  Igor.
 


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

2009-07-01 Thread Tom Faulhaber

Laurent,

Sounds like a good plan.

To answer your questions:

 I'll play with your code. Do you have a first pass over the clojure
 reader to attach other meta information as you go, or do you directly
 consume the clojure data structures the reader passes to you ?

pprint operates on clojure objects directly and doesn't really
consider where they came from. It has no concept of parsing input at
all.  However, output is very flexible, being driven by user-definable
dispatch functions. The architecture is based on the standard Lisp
pretty print architecture called XP. (This is the pretty printer
that's included in Common Lisp, for instance). You might want to look
at the paper XP. A Common Lisp Pretty Printing System which is
available at http://dspace.mit.edu/handle/1721.1/6504. The Clojure
implementation is more clojure-y but the algorithms and concepts are
substantially the same.

The pretty printer includes two dispatch functions, simple and code.
These are defined in clojure.contrib.pprint.dispatch.clj. You probably
want to skim over those to see the structure of the Clojure
implementation of this stuff.

I've begun to do more complete documentation of the pretty printer and
how to do dispatch here: 
http://code.google.com/p/clojure-contrib/wiki/PrettyPrinting
but I've gotten distracted with getting all the doc moved from google
code to github. I should be back to fleshing out that documentation
soon.


 If so,
 then certainly there would be the need to have an intermediate
 structure that would be the output of both clojure reader parsed
 code and source code preserving reader parsed code ? So that the
 rest of the formatting code is decoupled from that ? (But that will
 certainly be lots of changes, and in all parts I guess).

Not clear to me that you would need the clojure reader parsed code
in your implementation since you wouldn't be using that directly and
you could extract relevant information from the source code preserving
reader (like func names, etc.), but obviously you know more about how
you're using the results.

But yes, you will want to work in terms of an intermediate form that
you can pprint and work on as well.

Then you would have a modified version of the code-dispatch that
understood the enhanced data structures that were in that version (I
don't think that should be too hard).

One experiment I've been doing is to build an Object Explorer based
on pprint. The thing I added (but that's not totally integrated back
into pprint yet), is callbacks to let you map structure to output
location. I use it there for allowing the user to click on parts of
the object displayed to expand and contract its subobjects.

I can imagine that in a IDE this could be used to support structural
motion, paredit type things, etc.

I did a little talk on this here: http://blip.tv/file/2286313 and the
current state of the explorer is on github: 
http://github.com/tomfaulhaber/clj-explorer


 As far as IDE integration is concerned, i would not bother (at first)
 about incremental thing. I rather intend to always parse the entire
 edited file content (of course if this causes a performance problem, I
 might rethink about it). For performance testing, I've found that
 clojure/core.clj is a good candidate :-)


Yeah, I use core.clj a lot too. I *do* worry about performance here.
pprint currently renders 300-400 lines per second on my machine. It's
getting faster, but I doubt it will ever exceed 10x where it is now
(though I might surprise myself).

Keep me up to date on how it's going and feel free to bother me about
whatever. (You can often find me in #clojure as replaca, also.)

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

2009-07-01 Thread Raoul Duke

 i don't see the .s until i evaluate something afterwards; then they

many thanks to all for the help!

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



Videos from the Rich Hickey special Bay Area Clojure Group meeting now online

2009-07-01 Thread Tom Faulhaber

Hi all,

I've posted the videos we took at the Bay Area Clojure Group meeting
at http://tomfaulhaber.blip.tv.

The  production values leave a great deal to be desired and we didn't
have enough tape to catch everything, but most of the stuff is there
and we edited out most of the long projector delays, but Rich's
presentation still comes out pink.

Here are the individual segments:
1) Amit Rathore's introduction to the meeting: http://blip.tv/file/2281504
2) George Jahad shows how do to jdb in emacs and reverse engineers
some of the Clojure compiler: http://blip.tv/file/2286176
3) Amit Rathore discusses his Swarmiji distributed programming
framework (soon to be open source!): http://blip.tv/file/2301166
4) Tom Faulhaber on the Clojure Object Explorer: http://blip.tv/file/2286313
(this one got cut off before I finished, but we got most of it).
5) Rich Hickey talking about chunked seqs and answering wide ranging
questions about Clojure, the Universe and Everything: 
http://blip.tv/file/2301367
(also cut off near the end when we ran out of tape)

Unfortunately, we didn't have enough tape to catch Bradford Cross's
excellent presentation of his work on machine learning in Clojure.

I hope you all enjoy these videos despite the various production
problems we had. The content is really pretty cool and shows the
evolving state of a language with real applications beginning to
happen. We had 60 people show up (in a room that comfortably seats
about 40 :-)) and (apparently happily) sit through 3 hours of
presentations plagued with technical difficulties. The friendly
Clojure culture was obvious throughout. (Thanks to all for being good
sports about it!)

Thanks to Derrick Low, Zach Tellman, and Chris Allocco at 3VR for
creating these videos.

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

2009-07-01 Thread Kai

Hey Chouser,

I  did copy from clojure.contrib.duck-streams and originally had a
comment in there as regards to that. It got removed over clean-up
iterations, I'll put it back on there. I must learn to be more formal
when I publicly release code :)

Thanks for the tips on sets! Originally those functions did more but
you're right that I could now change them to a simple def. I'm still
not too sure if I like the idiom of sets being functions but I suppose
it's here to stay.

~ Kai


On Jul 1, 8:50 am, Chouser chou...@gmail.com wrote:
 On Fri, Jun 26, 2009 at 5:12 PM, Kaipoki...@gmail.com wrote:

  I'm new to this discussion group and Clojure.

 Welcome!

  I'm sharing the first
  bigger-than-REPL script that I've written because I haven't seen
  anything else like it for Clojure. It's a script that takes Clojure
  code as input and generates a pretty HTML version. You can view it
  here (I ran the script through itself):

 http://kai.myownsiteonline.com/clojure/html.clj.html

 The results are attractive, thanks for sharing!

 I see you've copied 'spit' from clojure.contrib.duck-streams.
 While of course it's perfectly acceptable to re-use
 open-source code, it is important that when you copy an
 author's code, that you follow the rules laid out by that
 author.  In this case there are implications for the license of
 your own code.  At the very least it would be polite to give
 credit.  Anyway, I assume this was an innocent oversight and
 that you'll fix it soon.

  I'd appreciate comments on the coding style

 Well, since you ask... :-)

 Your use of sets in 'whitespace?', 'starting?', etc. is
 excellent.  You could similarly use maps for 'html-entity'
 and 'html-whitespace' -- 'get' accepts a default value,
 which might be useful here.   ...and now that I'm looking at
 it, I think even 'whitespace?' could be just:

   (def whitespace? #{\, \newline \tab \space})

 Also, you might be interested in 'condp' -- it'd be useful
 in several places in that file.

 Thanks again for sharing your code,
 --Chouser
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Videos from the Rich Hickey special Bay Area Clojure Group meeting now online

2009-07-01 Thread Raoul Duke

that is terrific. many 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
-~--~~~~--~~--~--~---



Re: Clojure in Issue 1 of Pragmatic Publishings Magazine

2009-07-01 Thread Howard Lewis Ship
I wonder if there's a solution based on some universal meta-data to identify
what is lazily evaluated, and provide hooks (functions in the meta-data) to
insert handlers, such as error-kit, into the lazy evaluation.

On Wed, Jul 1, 2009 at 9:29 AM, Laurent PETIT laurent.pe...@gmail.comwrote:


 Hi, thanks for the pointer !

 By the way, I was wondering whether error-kit can be leveraged
 seamlessly with concurrent programming ?

 For example I guess that using (vec (pmap ...) instead of (vec (map
 ...) will not work because the binding of the handlers will be lost.

 I have always been ashamed by this consideration, and frustrated that
 I can't think about a way to free the developer from having to keep
 this in a corner of his mind ... (if I'm right, of course).

 Do you think it is a problem that  has no good theoretical solution,
 or just a current implementation feature that could be enhanced in
 the future ?

 I see this as if the application context were lost when a technical
 machinery reinitialized the application context with a new empty
 application context. Thinking about it this way implies that the new
 context could be totally overriden by the application context, but
 I'm not sure I can say that for the general case ? (Though I guess it
 is).


 What do you think about this ?

 2009/7/1 nrub p...@typosfrompaul.com:
 
  For anyone that's interested check out http://www.pragprog.com/magazines
 
  It looks like pragmatic publishing is going to start pushing out
  monthly magazines. I just checked out issue #1 which seems to have
  some good stuff, including an interview with Rich Hickey  An article
  by Stuart Halloway on Error-kit.
 
  The interview seems like a great article to pass to friends who might
  be intrigued by clojure, but haven't quite made the jump. So far
  that's all I've read, but I'll check out the article by Stuart tonight
  I'm sure.
 
  
 

 



-- 
Howard M. Lewis Ship

Creator of Apache Tapestry
Director of Open Source Technology at Formos

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

2009-07-01 Thread Richard Newman

 Has anyone out there written an Apache POI wrapper yet?

I started to (for Excel processing), only to abandon it in disgust.  
POI is just too incomplete: I have to choose between loading  
everything into memory (impossible), or essentially parsing XLSX  
myself (so what's the point of using POI?) in a different fashion to  
XLS. There's no streaming API for XLSX.

I switched to JavaCSV, simply requiring that the input be pre- 
converted. Fine for my situation.

For writing Excel, it's probably worth the time investment. For small  
worksheets it's fine. For non-trivial data, particularly in XLSX -- I  
was dealing with a 230,000-row table -- it's more trouble than it's  
worth.

Sorry to be a downer :/

Some scratch code from me -- sorry it's neither tidy nor complete, but  
I don't have the time right now. Hope it helps.



;; Lots of redundancy here from experimentation.
(ns com.foo.xls
   (:refer-clojure)
   (:use clojure.contrib.duck-streams)
   (:use clojure.contrib.pprint)
   (:use clojure.contrib.seq-utils)

   (:require [clojure.zip :as zip])
   (:require [clojure.xml :as xml])
   (:require [clojure.contrib.lazy-xml :as lazy-xml])
   (:require [clojure.contrib.zip-filter :as zf])
   (:require [clojure.contrib.zip-filter.xml :as zfx])
   (:import (com.csvreader CsvReader))
   (:import
  (org.apache.poi.poifs.filesystem POIFSFileSystem)
  (org.apache.poi.hssf.usermodel HSSFWorkbook)
  (org.apache.poi.hssf.eventusermodel HSSFRequest
  HSSFListener
  HSSFEventFactory)
  (org.apache.poi.ss.usermodel Workbook
   WorkbookFactory
   Row
   Cell)
  (org.apache.poi.hslf.model Sheet)
  (java.io FileInputStream
   FileOutputStream
   InputStream
   IOException)))

(defn sheets
   Returns a lazy sequence of sheets in the workbook.
   ([#^Workbook wb]
(sheets wb (.getNumberOfSheets wb) 0))
   ([#^Workbook wb c i]
(lazy-seq
  (when ( i c)
(cons (.getSheetAt wb i)
  (sheets wb c (inc i)))

(defmacro with-workbook [[wb path]  body]
   `(with-open [in# (new FileInputStream ~path)]
 (let [~wb (WorkbookFactory/create in#)]
   ~...@body)))

;; Another approach:
(defmacro do-xls-rows [[path]  process-record]
   `(let [pr#
  (proxy [HSSFListener] []
(processRecord [#^Record ~'record]
  ~...@process-record))]
  (with-open [in# (new FileInputStream ~path)]
(let [poifs# (new POIFSFileSystem in#)]
  (with-open [din# (.createDocumentInputStream poifs#  
Workbook)]
(let [req# (new HSSFRequest)
   factory# (new HSSFEventFactory)]
  (.addListenerForAllRecords req# pr#)
  (.processEvents factory# req# din#)))

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

2009-07-01 Thread fft1976

On Jun 30, 3:02 pm, igorrumiha igorrum...@gmail.com wrote:

 According to some of the people on the #icfp-contest channel my
 VM implementation is 500x to 1000x slower than a typical
 implementation written in C. It is, on the other hand, in the same
 performance range as some VMs written in Python.


On Jun 30, 10:34 pm, Jeff Foster dr.jeff.fos...@gmail.com wrote:

 Performance was not bad (from what I've seen it was
 vaguely comparable to the Python implementations, but was completely
 blown away by C/C++ implementations).


Has either one of you tried adding type declarations?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Apache POI wrapper????

2009-07-01 Thread Sean Devlin

Hmmm... good to know POI still needs work.  I guess I'll just stick
with CSV  tab delimited for now.  Thanks!

On Jul 1, 1:56 pm, Richard Newman holyg...@gmail.com wrote:
  Has anyone out there written an Apache POI wrapper yet?

 I started to (for Excel processing), only to abandon it in disgust.  
 POI is just too incomplete: I have to choose between loading  
 everything into memory (impossible), or essentially parsing XLSX  
 myself (so what's the point of using POI?) in a different fashion to  
 XLS. There's no streaming API for XLSX.

 I switched to JavaCSV, simply requiring that the input be pre-
 converted. Fine for my situation.

 For writing Excel, it's probably worth the time investment. For small  
 worksheets it's fine. For non-trivial data, particularly in XLSX -- I  
 was dealing with a 230,000-row table -- it's more trouble than it's  
 worth.

 Sorry to be a downer :/

 Some scratch code from me -- sorry it's neither tidy nor complete, but  
 I don't have the time right now. Hope it helps.

 ;; Lots of redundancy here from experimentation.
 (ns com.foo.xls
    (:refer-clojure)
    (:use clojure.contrib.duck-streams)
    (:use clojure.contrib.pprint)
    (:use clojure.contrib.seq-utils)

    (:require [clojure.zip :as zip])
    (:require [clojure.xml :as xml])
    (:require [clojure.contrib.lazy-xml :as lazy-xml])
    (:require [clojure.contrib.zip-filter :as zf])
    (:require [clojure.contrib.zip-filter.xml :as zfx])
    (:import (com.csvreader CsvReader))
    (:import
       (org.apache.poi.poifs.filesystem POIFSFileSystem)
       (org.apache.poi.hssf.usermodel HSSFWorkbook)
       (org.apache.poi.hssf.eventusermodel HSSFRequest
                                           HSSFListener
                                           HSSFEventFactory)
       (org.apache.poi.ss.usermodel Workbook
                                    WorkbookFactory
                                    Row
                                    Cell)
       (org.apache.poi.hslf.model Sheet)
       (java.io FileInputStream
                FileOutputStream
                InputStream
                IOException)))

 (defn sheets
    Returns a lazy sequence of sheets in the workbook.
    ([#^Workbook wb]
     (sheets wb (.getNumberOfSheets wb) 0))
    ([#^Workbook wb c i]
     (lazy-seq
       (when ( i c)
         (cons (.getSheetAt wb i)
               (sheets wb c (inc i)))

 (defmacro with-workbook [[wb path]  body]
    `(with-open [in# (new FileInputStream ~path)]
      (let [~wb (WorkbookFactory/create in#)]
       �...@body)))

 ;; Another approach:
 (defmacro do-xls-rows [[path]  process-record]
    `(let [pr#
           (proxy [HSSFListener] []
             (processRecord [#^Record ~'record]
               ~...@process-record))]
       (with-open [in# (new FileInputStream ~path)]
         (let [poifs# (new POIFSFileSystem in#)]
           (with-open [din# (.createDocumentInputStream poifs#  
 Workbook)]
             (let [req# (new HSSFRequest)
                        factory# (new HSSFEventFactory)]
               (.addListenerForAllRecords req# pr#)
               (.processEvents factory# req# din#)))
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 in Issue 1 of Pragmatic Publishings Magazine

2009-07-01 Thread Laurent PETIT

2009/7/1 Howard Lewis Ship hls...@gmail.com:
 I wonder if there's a solution based on some universal meta-data to identify
 what is lazily evaluated, and provide hooks (functions in the meta-data) to
 insert handlers, such as error-kit, into the lazy evaluation.

One general solution could be to have a hidden argument (managed by
clojure) which holds the context, in some sort of map. Though, the map
could not just be persistent, if one still wants to allow dynamic
scope to be set!, and it could be broken when passing a Callable
explictly to jav framework ... still need to think about it more ;-)



 On Wed, Jul 1, 2009 at 9:29 AM, Laurent PETIT laurent.pe...@gmail.com
 wrote:

 Hi, thanks for the pointer !

 By the way, I was wondering whether error-kit can be leveraged
 seamlessly with concurrent programming ?

 For example I guess that using (vec (pmap ...) instead of (vec (map
 ...) will not work because the binding of the handlers will be lost.

 I have always been ashamed by this consideration, and frustrated that
 I can't think about a way to free the developer from having to keep
 this in a corner of his mind ... (if I'm right, of course).

 Do you think it is a problem that  has no good theoretical solution,
 or just a current implementation feature that could be enhanced in
 the future ?

 I see this as if the application context were lost when a technical
 machinery reinitialized the application context with a new empty
 application context. Thinking about it this way implies that the new
 context could be totally overriden by the application context, but
 I'm not sure I can say that for the general case ? (Though I guess it
 is).


 What do you think about this ?

 2009/7/1 nrub p...@typosfrompaul.com:
 
  For anyone that's interested check out http://www.pragprog.com/magazines
 
  It looks like pragmatic publishing is going to start pushing out
  monthly magazines. I just checked out issue #1 which seems to have
  some good stuff, including an interview with Rich Hickey  An article
  by Stuart Halloway on Error-kit.
 
  The interview seems like a great article to pass to friends who might
  be intrigued by clojure, but haven't quite made the jump. So far
  that's all I've read, but I'll check out the article by Stuart tonight
  I'm sure.
 
  
 





 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry
 Director of Open Source Technology at Formos


 


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

2009-07-01 Thread igorrumiha

On Jul 1, 8:25 pm, fft1976 fft1...@gmail.com wrote:
 On Jun 30, 3:02 pm, igorrumiha igorrum...@gmail.com wrote:

  According to some of the people on the #icfp-contest channel my
  VM implementation is 500x to 1000x slower than a typical
  implementation written in C. It is, on the other hand, in the same
  performance range as some VMs written in Python.

 On Jun 30, 10:34 pm, Jeff Foster dr.jeff.fos...@gmail.com wrote:

  Performance was not bad (from what I've seen it was
  vaguely comparable to the Python implementations, but was completely
  blown away by C/C++ implementations).

 Has either one of you tried adding type declarations?

Yes, I had them from the start.

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

2009-07-01 Thread igorrumiha

On Jul 1, 8:55 am, Nicolas Oury nicolas.o...@gmail.com wrote:
[SNIP]
 And instead of reading the instruction and storing them in a vector
 you create a term:

 program-term =

    `(fn [input-array output-array memory]

           (do ~...@list-of-instructions)

 Then you (eval program-term) (once only) at run time, or macro expand
 it at compile time (if you have the right to use the binary at compile
 time.)

Looks like your suggestion is a definitive move in the right
direction. As you suggested, now I'm using native arrays and I'm
generating only one big function to run the whole program. The git
repo has the latest changes. The performance has jumped from 1200
(native array only, one function per VM instruction) to 3400
executions/second on my machine. Woohoo! :) Still there's room for
improvement, so the search continues...


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

2009-07-01 Thread cody


On Jun 27, 3:16 am, Christophe Grand christo...@cgrand.net wrote:
 Indeed. Fixed.

 user= (html-resource (java.io.StringReader. !-- o noes a comment
 --htmlheadtitlet/title/headbodyh1h/h1/body/html))
 ({:type :comment, :data  o noes a comment } {:tag :html, :attrs nil,
 :content [{:tag :head, :attrs nil, :content [{:tag :title, :attrs nil,
 :content [t]}]} {:tag :body, :attrs nil, :content [{:tag :h1, :attrs nil,
 :content [h]}]}]})

 Thanks for the report

 Christophe


Thanks for the quick fix, seems to work on my pages that brought up
the issue.

Do you have any plans to support HTML fragments?  Just as a quick
hack, I modified enlive to use the cyberneko parser with the document-
fragment feature on, and it will parse fragments, although selectors
stop working.  I haven't had time to look more closely at the code,
but I'd assume this is because html fragments may not necessarily have
a single root.

The use case for this is inserting sub-templates, e.g. site-wide
common sidebars, footer, etc.  Or do you see an alternate way to
accomplish that goal?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: loneclojurian at ICFP programming contest

2009-07-01 Thread fft1976



On Jul 1, 1:10 pm, igorrumiha igorrum...@gmail.com wrote:
 On Jul 1, 8:25 pm, fft1976 fft1...@gmail.com wrote:

  On Jun 30, 3:02 pm, igorrumiha igorrum...@gmail.com wrote:

   According to some of the people on the #icfp-contest channel my
   VM implementation is 500x to 1000x slower than a typical
   implementation written in C. It is, on the other hand, in the same
   performance range as some VMs written in Python.

  On Jun 30, 10:34 pm, Jeff Foster dr.jeff.fos...@gmail.com wrote:

   Performance was not bad (from what I've seen it was
   vaguely comparable to the Python implementations, but was completely
   blown away by C/C++ implementations).

  Has either one of you tried adding type declarations?

 Yes, I had them from the start.


Isn't it strange that Clojure with type declarations (that some people
say should be as fast as Java) was only as fast as Python (which does
not allow type declarations and does not exactly have a reputation for
speed)?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: pprint

2009-07-01 Thread philip.hazel...@gmail.com

On Jul 1, 9:52 am, Laurent PETIT laurent.pe...@gmail.com wrote:
 As far as IDE integration is concerned, i would not bother (at first)
 about incremental thing. I rather intend to always parse the entire
 edited file content (of course if this causes a performance problem, I
 might rethink about it). For performance testing, I've found that
 clojure/core.clj is a good candidate :-)

You may have considered this already, but always reparsing the whole
file will make things interesting when the code is in an invalid state
during editing. Top-level forms will look like they're several levels
deep, potentially in places they really shouldn't be.

Depending on what you do with the information, that might not be a
problem. And there's certainly something to be said for starting with
the simplest possible implementation. But for a more powerful
approach, it's possible to use information from the user's typing to
work out this ( is probably unmatched, and the next ) is closing the
preceeding (.

Source: 
http://www.codekana.com/blog/2009/04/02/on-the-speed-of-light-innovation-and-the-future-of-parsing/
(You can probably scroll down to on a whim.)

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

2009-07-01 Thread Daniel Lyons


On Jul 1, 2009, at 2:24 PM, fft1976 wrote:

 Isn't it strange that Clojure with type declarations (that some people
 say should be as fast as Java) was only as fast as Python (which does
 not allow type declarations and does not exactly have a reputation for
 speed)?


Unless the two implementations share the same general design and  
algorithms, we're comparing apples and oranges. Quicksort in Python  
will always dominate bubble sort in Clojure.

—
Daniel Lyons


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

2009-07-01 Thread Laurent PETIT

Hi Tom,

2009/7/1 Tom Faulhaber tomfaulha...@gmail.com:

 Laurent,

 Sounds like a good plan.

 To answer your questions:

 I'll play with your code. Do you have a first pass over the clojure
 reader to attach other meta information as you go, or do you directly
 consume the clojure data structures the reader passes to you ?

 pprint operates on clojure objects directly and doesn't really
 consider where they came from. It has no concept of parsing input at
 all.  However, output is very flexible, being driven by user-definable
 dispatch functions. The architecture is based on the standard Lisp
 pretty print architecture called XP. (This is the pretty printer
 that's included in Common Lisp, for instance). You might want to look
 at the paper XP. A Common Lisp Pretty Printing System which is
 available at http://dspace.mit.edu/handle/1721.1/6504. The Clojure
 implementation is more clojure-y but the algorithms and concepts are
 substantially the same.

I'll definitely look at it, thanks for the pointer !

 The pretty printer includes two dispatch functions, simple and code.
 These are defined in clojure.contrib.pprint.dispatch.clj. You probably
 want to skim over those to see the structure of the Clojure
 implementation of this stuff.

 I've begun to do more complete documentation of the pretty printer and
 how to do dispatch here: 
 http://code.google.com/p/clojure-contrib/wiki/PrettyPrinting
 but I've gotten distracted with getting all the doc moved from google
 code to github. I should be back to fleshing out that documentation
 soon.


Good to know, thanks!


 If so,
 then certainly there would be the need to have an intermediate
 structure that would be the output of both clojure reader parsed
 code and source code preserving reader parsed code ? So that the
 rest of the formatting code is decoupled from that ? (But that will
 certainly be lots of changes, and in all parts I guess).

 Not clear to me that you would need the clojure reader parsed code
 in your implementation since you wouldn't be using that directly and
 you could extract relevant information from the source code preserving
 reader (like func names, etc.), but obviously you know more about how
 you're using the results.

Are you suggesting that clojure reader parsed code could be first
translated back to String and reinjected to the source code reader ?
Indeed that could simplify final implementation. I don't know what the
impact on performance would be, though.


 But yes, you will want to work in terms of an intermediate form that
 you can pprint and work on as well.

 Then you would have a modified version of the code-dispatch that
 understood the enhanced data structures that were in that version (I
 don't think that should be too hard).

 One experiment I've been doing is to build an Object Explorer based
 on pprint. The thing I added (but that's not totally integrated back
 into pprint yet), is callbacks to let you map structure to output
 location. I use it there for allowing the user to click on parts of
 the object displayed to expand and contract its subobjects.

I must look at the code, but is this some sort of implementation of
the Builder design pattern ?

 I can imagine that in a IDE this could be used to support structural
 motion, paredit type things, etc.

 I did a little talk on this here: http://blip.tv/file/2286313 and the
 current state of the explorer is on github: 
 http://github.com/tomfaulhaber/clj-explorer

Wow, you gave me a lot of homework ;-)


 As far as IDE integration is concerned, i would not bother (at first)
 about incremental thing. I rather intend to always parse the entire
 edited file content (of course if this causes a performance problem, I
 might rethink about it). For performance testing, I've found that
 clojure/core.clj is a good candidate :-)


 Yeah, I use core.clj a lot too. I *do* worry about performance here.
 pprint currently renders 300-400 lines per second on my machine. It's
 getting faster, but I doubt it will ever exceed 10x where it is now
 (though I might surprise myself).

Well, honestly, 300 to 400 lines per second does not seem very
performant. This implies that the reformating of clojure.core would
take 10 seconds  I indeed expected something around very fast
for a medium size file (300 - 400 lines), and 1 to 2 seconds for
something big as clojure.core (but maybe I'm just dreaming). Do you
already know where to look for better perf ?


 Keep me up to date on how it's going and feel free to bother me about
 whatever. (You can often find me in #clojure as replaca, also.)


Thank you very much, I'll keep you informed.

Regards,

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

Re: pprint

2009-07-01 Thread Laurent PETIT

Hi Philip,

2009/7/1 philip.hazel...@gmail.com philip.hazel...@gmail.com:

 On Jul 1, 9:52 am, Laurent PETIT laurent.pe...@gmail.com wrote:
 As far as IDE integration is concerned, i would not bother (at first)
 about incremental thing. I rather intend to always parse the entire
 edited file content (of course if this causes a performance problem, I
 might rethink about it). For performance testing, I've found that
 clojure/core.clj is a good candidate :-)

 You may have considered this already, but always reparsing the whole
 file will make things interesting when the code is in an invalid state
 during editing. Top-level forms will look like they're several levels
 deep, potentially in places they really shouldn't be.

Not sure whether it is ironic or not when you write will make things
interesting ? :-)
The already existing syntax coloring of clojuredev (with rainbow
parens enabled) does just that, reparsing the whole file everytime.
And I've found it useful to see that what I really know is a top level
form does not have the right color. It helps identify where the
problem begins ...

 Depending on what you do with the information, that might not be a
 problem. And there's certainly something to be said for starting with
 the simplest possible implementation. But for a more powerful
 approach, it's possible to use information from the user's typing to
 work out this ( is probably unmatched, and the next ) is closing the
 preceeding (.

 Source: 
 http://www.codekana.com/blog/2009/04/02/on-the-speed-of-light-innovation-and-the-future-of-parsing/
 (You can probably scroll down to on a whim.)

More homework ! :-) Thanks for the pointer,

Regards,

-- 
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: loneclojurian at ICFP programming contest

2009-07-01 Thread Mark Engelberg

On Wed, Jul 1, 2009 at 2:08 PM, Daniel Lyonsfus...@storytotell.org wrote:


 On Jul 1, 2009, at 2:24 PM, fft1976 wrote:

 Isn't it strange that Clojure with type declarations (that some people
 say should be as fast as Java) was only as fast as Python (which does
 not allow type declarations and does not exactly have a reputation for
 speed)?


 Unless the two implementations share the same general design and
 algorithms, we're comparing apples and oranges. Quicksort in Python
 will always dominate bubble sort in Clojure.

But each language encourages a certain style of design and algorithm,
so it IS fair to compare the way that the language encourages a
certain approach.  For example, Clojure encourages you to use a more
functional approach and persistent data structures.  If this ends up
being way slower than the mutable approach that Python encourages,
that is worth knowing.

I remember one year, my ICFP VM in Python ran ridiculously slow in
part because Python doesn't have a switch statement, whereas other
languages do.   So it is useful to look at what a language does and
does not allow you to do, and how that impacts speed.

My point is: no comparison is going to be exactly apples to apples,
but the comparison can still be useful.

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



Re: loneclojurian at ICFP programming contest

2009-07-01 Thread igorrumiha

On Jul 1, 10:24 pm, fft1976 fft1...@gmail.com wrote:

   Has either one of you tried adding type declarations?

  Yes, I had them from the start.

 Isn't it strange that Clojure with type declarations (that some people
 say should be as fast as Java) was only as fast as Python (which does
 not allow type declarations and does not exactly have a reputation for
 speed)?

I don't think type declarations help much in this case. For instance,
I have run java with -Xrunhprof option, with my functional
implementation the top list looks like this:

CPU SAMPLES BEGIN (total = 2241) Wed Jul  1 22:57:01 2009
rank   self  accum   count trace method
   1 20.30% 20.30% 455 301116 clojure.lang.RT.next
   2 14.73% 35.03% 330 301122 clojure.lang.RT.first
   3  9.37% 44.40% 210 301121 clojure.lang.Var.deref
   4  5.85% 50.25% 131 301134 clojure.lang.Var.deref
   5  4.73% 54.98% 106 301123 clojure.lang.Var.deref
   6  3.53% 58.50%  79 301138 clojure.core
$reduce__267$fn__270.invoke

etc...

And when I run my latest code:

CPU SAMPLES BEGIN (total = 4257) Wed Jul  1 23:05:17 2009
rank   self  accum   count trace method
   1  0.42%  0.42%  18 301156 java.lang.reflect.Array.getDouble
   2  0.38%  0.80%  16 301192 java.lang.reflect.Array.getDouble
   3  0.38%  1.17%  16 301238 java.lang.reflect.Array.getDouble
   4  0.35%  1.53%  15 301209 java.lang.reflect.Array.getDouble
   5  0.35%  1.88%  15 301235 java.lang.reflect.Array.getDouble
   6  0.33%  2.21%  14 301247 java.lang.reflect.Array.getDouble
   7  0.33%  2.54%  14 301702 java.lang.reflect.Array.getDouble
   8  0.33%  2.87%  14 301164 java.lang.reflect.Array.getDouble
   9  0.33%  3.19%  14 301337 java.lang.reflect.Array.getDouble
 10  0.31%  3.50%  13 301291 java.lang.reflect.Array.getDouble

(with around 400 more lines like this)

Please note the self column on both logs. So, my first approach was
maybe intuitive to me but it was dealing with a lot of hash lookups,
shuffling with vectors, merging hashes and whatnot. Performance was
not my goal, I just wanted to make the VM run correctly. Also, as an
exercise I wanted to use immutable/persistent data structures, to see
how I could implement such a thing as a virtual machine in a
functional language. I became interested in performance when I
discovered that my VM runs at 45 iterations/second. That had to be
improved, so I tweaked it until I got 500 (still using immutable data
structures), and that allowed me to continue with the contest.

Now, thanks to Nicolas's suggestions I get just short of 5000
iterations/s (yes, I improved it a bit more since my last post), of
course, with the help of mutable java arrays. That is nice.

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

2009-07-01 Thread cody



On Jul 1, 3:45 pm, cody c...@koeninger.org wrote:

 The use case for this is inserting sub-templates, e.g. site-wide
 common sidebars, footer, etc.  Or do you see an alternate way to
 accomplish that goal?

Eh, looks like I need to read earlier in the thread, apologies for the
noise, and thanks again for the fix.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Displaying Clojure code on a Website

2009-07-01 Thread Laurent PETIT

Hi,

Did you place the code somewhere in a public repo on github, google
code, svn, bitbucket or whatever ? (so that it is easy to track
changes ?).

Anyhow, is it possible to reuse your code ? I'm evaluating several
ways of starting code for doing formatting for the clojure plugin for
eclipse, and your code seems an interesting existing basis for the
parser part.
(If you were to release it under EPL -de facto standard licence for
clojure code-, that would be perfect !:-)

Thanks in advance,

Regards,

-- 
Laurent

2009/7/1 Kai poki...@gmail.com:

 Hey Chouser,

 I  did copy from clojure.contrib.duck-streams and originally had a
 comment in there as regards to that. It got removed over clean-up
 iterations, I'll put it back on there. I must learn to be more formal
 when I publicly release code :)

 Thanks for the tips on sets! Originally those functions did more but
 you're right that I could now change them to a simple def. I'm still
 not too sure if I like the idiom of sets being functions but I suppose
 it's here to stay.

 ~ Kai


 On Jul 1, 8:50 am, Chouser chou...@gmail.com wrote:
 On Fri, Jun 26, 2009 at 5:12 PM, Kaipoki...@gmail.com wrote:

  I'm new to this discussion group and Clojure.

 Welcome!

  I'm sharing the first
  bigger-than-REPL script that I've written because I haven't seen
  anything else like it for Clojure. It's a script that takes Clojure
  code as input and generates a pretty HTML version. You can view it
  here (I ran the script through itself):

 http://kai.myownsiteonline.com/clojure/html.clj.html

 The results are attractive, thanks for sharing!

 I see you've copied 'spit' from clojure.contrib.duck-streams.
 While of course it's perfectly acceptable to re-use
 open-source code, it is important that when you copy an
 author's code, that you follow the rules laid out by that
 author.  In this case there are implications for the license of
 your own code.  At the very least it would be polite to give
 credit.  Anyway, I assume this was an innocent oversight and
 that you'll fix it soon.

  I'd appreciate comments on the coding style

 Well, since you ask... :-)

 Your use of sets in 'whitespace?', 'starting?', etc. is
 excellent.  You could similarly use maps for 'html-entity'
 and 'html-whitespace' -- 'get' accepts a default value,
 which might be useful here.   ...and now that I'm looking at
 it, I think even 'whitespace?' could be just:

   (def whitespace? #{\, \newline \tab \space})

 Also, you might be interested in 'condp' -- it'd be useful
 in several places in that file.

 Thanks again for sharing your code,
 --Chouser
 


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



Emacs clojure-mode home?

2009-07-01 Thread Chris Dean


Where's the current home for the Emacs clojure-mode source? I have a one
line patch I'd like to make, but don't know where to send it!

Is it http://github.com/technomancy/clojure-mode/tree/master  ?

Anyway I'll include the patch to add a local-abbrev-table here since it
is so small.

Cheers,
Chris Dean

diff --git a/clojure-mode.el b/clojure-mode.el
index b7b2de0..f9fa8ec 100644
--- a/clojure-mode.el
+++ b/clojure-mode.el
@@ -192,6 +192,8 @@ if that value is non-nil.
   (lisp-mode-variables nil)
   (set-syntax-table clojure-mode-syntax-table)
   
+  (setq local-abbrev-table clojure-mode-abbrev-table)
+
   (set (make-local-variable 'comment-start-skip)
\\(\\(^\\|[^\n]\\)\\(\\)*\\)\\(;+\\|#|\\) *)
   (set (make-local-variable 'lisp-indent-function)


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

2009-07-01 Thread Christophe Grand
On Wed, Jul 1, 2009 at 11:42 PM, cody c...@koeninger.org wrote:


 On Jul 1, 3:45 pm, cody c...@koeninger.org wrote:

  The use case for this is inserting sub-templates, e.g. site-wide
  common sidebars, footer, etc.  Or do you see an alternate way to
  accomplish that goal?

 Eh, looks like I need to read earlier in the thread, apologies for the
 noise, and thanks again for the fix.



I'm the one to blame for the lack of documentation.
I think snippet and defsnippet are whate you are looking for.

-- 
Professional: http://cgrand.net/ (fr)
On Clojure: http://clj-me.blogspot.com/ (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: Emacs clojure-mode home?

2009-07-01 Thread Phil Hagelberg

Chris Dean ctd...@sokitomi.com writes:

 Where's the current home for the Emacs clojure-mode source? I have a one
 line patch I'd like to make, but don't know where to send it!

 Is it http://github.com/technomancy/clojure-mode/tree/master  ?

That's my repository. Technically the canonical one is at
http://github.com/jochu/clojure-mode/ but I have commit access there, so
I can take care of it. Patches here on the mailing list are welcome.

 Anyway I'll include the patch to add a local-abbrev-table here since it
 is so small.

It looks like your patch might be incomplete; I get a void-variable:
clojure-mode-abbrev-table when I run that.

-Phil

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

2009-07-01 Thread Tom Faulhaber



 Are you suggesting that clojure reader parsed code could be first
 translated back to String and reinjected to the source code reader ?
 Indeed that could simplify final implementation. I don't know what the
 impact on performance would be, though.

No, that wouldn't work because the clojure reader is lossy.

What I have in mind is simply not having a clojure reader version, but
only your own enhanced version.

One thing that I was thinking is that this might be identical to the
Clojure-produced version but with extra metadata attached to the
structure to indicate source extras (like comments and metadata
annotations) and syntax variations (unclosed parens and the like).
This would be nice for you if you're using the reader produced data
for other stuff.

On the other hand, it might be more useful to wrap the structure the
you read in a container (or set of containers) that annotates it. A
simple transform could then extract reader compatible version if you
needed it.


  One experiment I've been doing is to build an Object Explorer based
  on pprint. The thing I added (but that's not totally integrated back
  into pprint yet), is callbacks to let you map structure to output
  location. I use it there for allowing the user to click on parts of
  the object displayed to expand and contract its subobjects.

 I must look at the code, but is this some sort of implementation of
 the Builder design pattern ?

Not really.

What you have is a Clojure object that you want to explore, but it's
huge, so you don't just want to print it and look at it.

Instead you use the control variables *print-length* and *print-level*
to only print a high-level view of it (into a text control in a swing
app).

Then when you want to go deeper into some part of the structure, you
just click on it and it expands (i.e., *print-level* is incremented,
but only for that part of the structure). Clicking again contracts it.

This is accomplished via callbacks in the pretty printer that allow us
to track where on the screen each part of the logical structure is.
(Simplistically, remember where I enter a particular level of list and
where I exit it.)

 Wow, you gave me a lot of homework ;-)

Just trying to keep you busy :-)

 Well, honestly, 300 to 400 lines per second does not seem very
 performant.

Agreed. Which is why I mentioned the incremental thing.

 This implies that the reformating of clojure.core would
 take 10 seconds  I indeed expected something around very fast
 for a medium size file (300 - 400 lines), and 1 to 2 seconds for
 something big as clojure.core (but maybe I'm just dreaming). Do you
 already know where to look for better perf ?

Those speeds may be achievable, but even 1-2 seconds will seem slow if
you're doing it all the time. I believe that most systems that do this
use incremental algorithms so as to be O(1) and not O(n) on the file
size.

I do have some places to look for more performance, but I have no idea
how much faster I can make it go before I have to make hard choices.
It seems like every few weeks I take a whack at performance and know
it up an order of magnitude, but who knows how many of those rabbits
(if any) are left in the hat :-).

If you really think about all the cases, pretty printing is reasonably
complex. Add to that my desire to have a pretty printer with flexible
dispatch (which is what would make it work at all for apps like this)
and there's more overhead still. But you can assume that I'll get you
a bunch more performance over time.

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

2009-07-01 Thread Chris Dean


 It looks like your patch might be incomplete; I get a void-variable:
 clojure-mode-abbrev-table when I run that.

So it is.  Looks like I had the defs in my private startup file for some
reason.  Here's a corrected patch.

Cheers,
Chris Dean

diff --git a/clojure-mode.el b/clojure-mode.el
index b7b2de0..62d236a 100644
--- a/clojure-mode.el
+++ b/clojure-mode.el
@@ -163,6 +163,10 @@ All commands in `lisp-mode-shared-map' are inherited by 
this map.)
 (modify-syntax-entry ?^ ' table)
 table))
 
+(defvar clojure-mode-abbrev-table nil
+  Abbrev table used in clojure-mode buffers.)
+
+(define-abbrev-table 'clojure-mode-abbrev-table ())
 
 (defvar clojure-prev-l/c-dir/file nil
   Record last directory and file used in loading or compiling.
@@ -192,6 +196,8 @@ if that value is non-nil.
   (lisp-mode-variables nil)
   (set-syntax-table clojure-mode-syntax-table)
   
+  (setq local-abbrev-table clojure-mode-abbrev-table)
+
   (set (make-local-variable 'comment-start-skip)
\\(\\(^\\|[^\n]\\)\\(\\)*\\)\\(;+\\|#|\\) *)
   (set (make-local-variable 'lisp-indent-function)

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

2009-07-01 Thread Jeff Valk

As a side note on the topic of clojure-mode, I noticed the function 
clojure-install still clones Kevin O'Neill's svn mirror 
(git://github.com/kevinoneill/clojure.git). Shouldn't this point to Rich's 
repository (git://github.com/richhickey/clojure.git), now that clojure has 
moved to github?

- Jeff

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

2009-07-01 Thread Phil Hagelberg

Chris Dean ctd...@sokitomi.com writes:

 It looks like your patch might be incomplete; I get a void-variable:
 clojure-mode-abbrev-table when I run that.

 So it is.  Looks like I had the defs in my private startup file for some
 reason.  Here's a corrected patch.

Thanks; I've committed this.

-Phil

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

2009-07-01 Thread Phil Hagelberg

Jeff Valk jv-li...@tx.rr.com writes:

 As a side note on the topic of clojure-mode, I noticed the function
 clojure-install still clones Kevin O'Neill's svn mirror
 (git://github.com/kevinoneill/clojure.git). Shouldn't this point to
 Rich's repository (git://github.com/richhickey/clojure.git), now that
 clojure has moved to github?

Yep; good catch. I've pushed this out too.

-Phil

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

2009-07-01 Thread mmwaikar

Thanks a lot Daniel for your suggestions. As per my understanding
Clojure for Java and .Net are two implementations of the same
language, but they have to support different things because the
underlying platforms support different things - e.g. extension methods
(are in C# but most likely not in Java).

I realized the naming convention of methods. Similarly, what should be
the convention for naming method parameters? Is it pascalCase?

Also, I'll have to check when-let and re-find, I am still not familiar
with it.

As for the program, I had to write a simple cmd line tool a few days
back at my work, which converts images from one format to other (by
using an external tool) and copies the converted images to specific
folders (based on the file names), hence the subfolder name fn.

On Jul 1, 1:58 am, Daniel Lyons fus...@storytotell.org wrote:
 Manoj,

 In case this helps, I've had a bit longer to dwell on this problem and  
 I have a couple of ideas. I do think this raises the general question  
 of, are Clojure .NET and Clojure Java two different languages or two  
 implementations of the same language? Normally in a situation like  
 this (say, Jython and Python) I would say that they should be two  
 implementations of the same language but the situation is complicated  
 by the fact that Clojure code relies heavily on Java objects since the  
 policy is not to wrap everything. I'm not sure how the subject of  
 Clojure .NET / Java portability has been approached but my naïve guess  
 is that it would revolve around separating Java dependencies and .NET  
 dependencies from pure Clojure code. Is anyone else addressing these  
 issues in their own code at this time?

 Back to your code. First of all, to simplify things, it's probably a  
 good idea to decouple your I/O from your parsing, since the parsing  
 can be functional. First I rewrote starts-with-hmorx into this:

 (defn starts-with-hm-or-x [name]
    (#{\H \M \X} (.charAt name 0)))

 Which I think is simpler, building on the fact that sets can be used  
 as functions, but then I thought it would probably be better to  
 rewrite the functions into one that gets the information from the  
 filesystem and another one that gets the information you want out:

 (defn parse-subfolder-name
    [name]
    (or
     (when-let [[_ digit] (re-find #(\d).* name)]
       (Integer/parseInt digit))
     (when-let [[_ hmx] (re-find #([hHmMxX]).* name)]
       (.toLowerCase hmx))
     other))

 Unfortunately I'm still dependent on some Java API stuff in there, but  
 I think you can probably translate to the .NET equivalents. This is  
 easier to test at the REPL:

 user (parse-subfolder-name 0stuf)
 0
 user (parse-subfolder-name Hstuf)
 h
 user (parse-subfolder-name stuf)
 other

 Then I'd set about handling the loading of the filename and  
 dispatching it:

 (defn get-subfolder-name
    [filename]
    (parse-subfolder-name
     (.ToString (Path/GetFileNameWithoutExtensions filename

 Now it should be easier to determine where the problem is, either in  
 the I/O code or in the functional code which is easier to test at the  
 REPL.

 As an aside, I'd recommend that you follow the naming convention of  
 using lowercase function names with words separated by hypens (get-
 subfolder-name) rather than CamelCase (GetSubfolderName). Also, it  
 doesn't look to me like GetSubfolderName is really returning a  
 subfolder's name but I'm not quite sure what it is doing either. Are  
 you working on an app with specific meaning tied to the first  
 character of a path name or is this a .NET filesystem thing? Just  
 curious.

 Thanks and hope this helps,

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

2009-07-01 Thread mmwaikar

Thanks Michael, and you are spot on about your observation on
parentheses :) but when I wasn't putting (def name-wo-extn
something) in another (), I was getting some error like - too many
arguments to def, hence I put one more. I am still getting used to
this syntax.

On Jul 1, 3:03 am, Michael Wood esiot...@gmail.com wrote:
 Hi

 2009/7/1 mmwaikar mmwai...@gmail.com:

  Hi,

  I am learning clojure these days, but on .Net. I have the following
  code -

 I only have a tiny bit to add to what Daniel's already said.

 [...]

  (defn GetSubfolderName [filename]
         ((def name-wo-extn (Path/GetFileNameWithoutExtension filename))

 First, def creates basically global variables (or something similar).
 You want let instead.
 Second, you can't just add parentheses as you see fit. :)

 (def name-wo-extn something)

 is defining name-wo-extn as the string something.

 ((def name-wo-extn something))

 is trying to define name-wo-extn as the string something and then
 call it as a function.  Since something is a String and not a
 function (or something that acts as a function), this will fail.

 So, for ((def name-wo-extn (Path/GetFileNameWithoutExtension
 filename)) ...) implies that (Path/GetFileNameWithoutExtension
 filename) returns a Clojure function (or something that can be used as
 one, like a map/set/etc.).  I suppose Path/GetFileNameWithoutExtension
 is a .Net method, in which case it is unlikely to work as a Clojure
 function.  Java methods can't be used in place of Clojure functions
 and I assume it's the same for the .Net port.

          (def first-char (aget (.ToCharArray (.ToString name-wo-extn)) 0))
          (if (Char/IsDigit first-char) (Convert/ToInt32 first-char) (if
  (starts-with-hmorx first-char) (.ToLower (.ToString first-char))
  other

  But when I call (GetSubfolderName D:\\CsEx\\Manoj.cs), I get this
  exception -

  System.InvalidCastException: Unable to cast object of type
  'System.String' to type 'clojure.lang.IDeref'.

 I think the extra parentheses are the reason for this exception.

    at lambda_method(Closure , Object )
    at AFunction_impl.invoke(Object )
    at lambda_method(Closure , Object )
    at AFunction_impl.invoke(Object )
    at lambda_method(Closure )
    at AFunction_impl.invoke()
    at REPLCall(Closure )

 [...]

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



Awkward Booleans from contrib.sql

2009-07-01 Thread Vagif Verdi

Here's some warts, when working with boolean fields from sql
databases.

(if (with-db (sql-val [select convert(bit, 0)])) Yes, no)

will return Yes. This is because contrib.sql returns java Booleans,
not clojure tru/false.

(if (= false (with-db (sql-val [select null]))) Yes, no)

will return no. This is because null is not false in clojure.

So the only way to correctly deal with booleans from sql databases is
to explicitly test for true:

(if (= true (with-db (sql-val [select null]))) Yes, no)

or
(if (not (= true (with-db (sql-val [select null] Yes, no)

That's awkward, especially for those of us, coming from Common Lisp.


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

2009-07-01 Thread Vagif Verdi

I just got an advise from IRC to use (boolean x).
Problem solved :)

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

2009-07-01 Thread Eric Willigers



On Jul 1, 1:02 am, Chouser chou...@gmail.com wrote:
 On Tue, Jun 30, 2009 at 8:37 AM, Rowdy Rednoserowdy.redn...@gmx.net wrote:

  Would it be easy to implement an in-memory database in clojure that
  allows concurrent access?

  It sounds pretty easy, as most of the features are already provided by
  Clojure. I'm not sure though about the locking granularity.
  Of course you don't pessimistically lock in Clojure, but if you have a
  relation that is protected by a Ref, then concurrently adding two
  rows to that relation will make one of the two transaction replay,
  although the added rows could be completely independent (unless there
  are unique constraints, for example, which, now that I think about it,
  are present in every real-world table in the form of primary keys).

 You could wrap a Ref around every value, if you chose, to
 allow independent changes to different rows at the same
 time -- though this would not help when inserting rows.

 You could partition your key space somehow (perhaps by hash)
 to allow n groups of rows, and protect each of those with
 a Ref.  This would allow insertions and deletions
 independently as long as the operations were being applied
 to different groups.

 I imagine there are other possible solutions as well...

  Furthermore, if you have constraints that involve other relations, say
  foreign key constraints, then the locking granularity gets even
  coarser, spanning all relations involved, and thus affecting every
  mutating access to any one of those relations.

 With either of the layouts I mentioned, this kind of
 multi-relation transaction ought to allow Clojure STM to
 really shine when compared to a more naive locking scheme.


I think the implementation of ensure will need to change for this
use case to shine -
http://www.mail-archive.com/clojure@googlegroups.com/msg14915.html

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

2009-07-01 Thread Robert Fischer

You're now reinventing JavaScript's object system, BTW.

~~ Robert.

Laurent PETIT wrote:
 2009/7/1 Howard Lewis Ship hls...@gmail.com:
 I wonder if there's a solution based on some universal meta-data to identify
 what is lazily evaluated, and provide hooks (functions in the meta-data) to
 insert handlers, such as error-kit, into the lazy evaluation.
 
 One general solution could be to have a hidden argument (managed by
 clojure) which holds the context, in some sort of map. Though, the map
 could not just be persistent, if one still wants to allow dynamic
 scope to be set!, and it could be broken when passing a Callable
 explictly to jav framework ... still need to think about it more ;-)
 
 
 On Wed, Jul 1, 2009 at 9:29 AM, Laurent PETIT laurent.pe...@gmail.com
 wrote:
 Hi, thanks for the pointer !

 By the way, I was wondering whether error-kit can be leveraged
 seamlessly with concurrent programming ?

 For example I guess that using (vec (pmap ...) instead of (vec (map
 ...) will not work because the binding of the handlers will be lost.

 I have always been ashamed by this consideration, and frustrated that
 I can't think about a way to free the developer from having to keep
 this in a corner of his mind ... (if I'm right, of course).

 Do you think it is a problem that  has no good theoretical solution,
 or just a current implementation feature that could be enhanced in
 the future ?

 I see this as if the application context were lost when a technical
 machinery reinitialized the application context with a new empty
 application context. Thinking about it this way implies that the new
 context could be totally overriden by the application context, but
 I'm not sure I can say that for the general case ? (Though I guess it
 is).


 What do you think about this ?

 2009/7/1 nrub p...@typosfrompaul.com:
 For anyone that's interested check out http://www.pragprog.com/magazines

 It looks like pragmatic publishing is going to start pushing out
 monthly magazines. I just checked out issue #1 which seems to have
 some good stuff, including an interview with Rich Hickey  An article
 by Stuart Halloway on Error-kit.

 The interview seems like a great article to pass to friends who might
 be intrigued by clojure, but haven't quite made the jump. So far
 that's all I've read, but I'll check out the article by Stuart tonight
 I'm sure.




 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry
 Director of Open Source Technology at Formos


 
  
 

-- 
~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, Grails Persistence with GORM and GSQL!
http://www.smokejumperit.com/redirect.html

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

2009-07-01 Thread fft1976

I just changed my mind about releasing this. If anyone wants to use
the name, it's yours!

On Jun 25, 12:17 am, Emeka emekami...@gmail.com wrote:
  accounting software in Clojure?
 Which area of accounting will it cover?

 Emeka

 On Thu, Jun 25, 2009 at 3:41 AM, fft1976 fft1...@gmail.com wrote:

  I know some of you are searching for names for your projects. I just
  wanted to say that Foreclojure is taken! This will be an open-source
  (but not GPL) accounting software in Clojure. Stay tuned.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---