Re: Problem with clojure code on .net.

[Michael Wood]

Hi

2009/7/1 mmwaikar :
> 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 

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

[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

[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 :
>
> 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  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?

[Timothy Pratley]

You just didn't
  (flush)

Regards,
Tim.


On Jul 1, 5:43 pm, Raoul Duke  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

[Emeka]

Thanks, more of it.

Emeka

On Mon, Jun 29, 2009 at 12:31 AM, Daniel Jomphe wrote:

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

[Rowdy Rednose]

On Jul 1, 12:02 am, Chouser  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

[Matt Culbreth]

On Jul 1, 8:02 am, Rowdy Rednose  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

[Chouser]

On Fri, Jun 26, 2009 at 5:12 PM, Kai 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

[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  wrote:
> On Jul 1, 8:02 am, Rowdy Rednose  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

[Rich Hickey]

On Wed, Jul 1, 2009 at 1:50 AM, Krukow wrote:
>
>
> On Jun 30, 6:01 pm, Rich Hickey  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

[Krukow]

On Jul 1, 8:43 am, Daniel Lyons  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

[Krukow]

On Jul 1, 3:09 pm, Rich Hickey  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

[igorrumiha]

On Jul 1, 8:55 am, Nicolas Oury  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?

[cridal]

I would definitely be interested...

Marcin.

On Jun 4, 12:09 pm, Eric Thorsen  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

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

[Michał Kwiatkowski]

On Wed, Jul 1, 2009 at 9:43 AM, Raoul Duke  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

[Daniel E. Renfer]

Mark Engelberg  writes:

> On Tue, Jun 30, 2009 at 12:29 AM, Konrad
> Hinsen 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

[Konrad Hinsen]

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

> On Tue, Jun 30, 2009 at 12:29 AM, Konrad
> Hinsen 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????

[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

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

Clojure in Issue 1 of Pragmatic Publishings Magazine

[nrub]

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: Clojure in Issue 1 of Pragmatic Publishings Magazine

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

[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  wrote:

>
> On Jul 1, 8:55 am, Nicolas Oury  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

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

[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 wrote:

>
> 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/fatvat)
> and
> there's a write-up on my blog (http://www.fatvat.co.uk/2009/06/icfp-
> contest-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  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

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

[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

[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

[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  wrote:
> On Fri, Jun 26, 2009 at 5:12 PM, Kai 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

[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

[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 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 :
> >
> > 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????

[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

[fft1976]

On Jun 30, 3:02 pm, igorrumiha  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  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????

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

[Laurent PETIT]

2009/7/1 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.

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

[igorrumiha]

On Jul 1, 8:25 pm, fft1976  wrote:
> On Jun 30, 3:02 pm, igorrumiha  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  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

[igorrumiha]

On Jul 1, 8:55 am, Nicolas Oury  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

[cody]

On Jun 27, 3:16 am, Christophe Grand  wrote:
> Indeed. Fixed.
>
> user=> (html-resource (java.io.StringReader. "th"))
> ({: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

[fft1976]

On Jul 1, 1:10 pm, igorrumiha  wrote:
> On Jul 1, 8:25 pm, fft1976  wrote:
>
> > On Jun 30, 3:02 pm, igorrumiha  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  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

[philip.hazel...@gmail.com]

On Jul 1, 9:52 am, Laurent PETIT  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

[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

[Laurent PETIT]

Hi Tom,

2009/7/1 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.

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 m

Re: pprint

[Laurent PETIT]

Hi Philip,

2009/7/1 philip.hazel...@gmail.com :
>
> On Jul 1, 9:52 am, Laurent PETIT  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

[Mark Engelberg]

On Wed, Jul 1, 2009 at 2:08 PM, Daniel Lyons 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

[igorrumiha]

On Jul 1, 10:24 pm, fft1976  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

[cody]

On Jul 1, 3:45 pm, cody  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

[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 :
>
> 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  wrote:
>> On Fri, Jun 26, 2009 at 5:12 PM, Kai 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?

[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

[Christophe Grand]

On Wed, Jul 1, 2009 at 11:42 PM, cody  wrote:

>
> On Jul 1, 3:45 pm, cody  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?

[Phil Hagelberg]

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

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

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

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

[Phil Hagelberg]

Chris Dean  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?

[Phil Hagelberg]

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

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

[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  wrote:
> Hi
>
> 2009/7/1 mmwaikar :
>
> > 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 
--~--~-~--~~~---~--~~
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

[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

[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

[Eric Willigers]

On Jul 1, 1:02 am, Chouser  wrote:
> On Tue, Jun 30, 2009 at 8:37 AM, Rowdy Rednose 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

[Robert Fischer]

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

~~ Robert.

Laurent PETIT wrote:
> 2009/7/1 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.
> 
> 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 
>> 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 :
 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

[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  wrote:
>  accounting software in Clojure?
> Which area of accounting will it cover?
>
> Emeka
>
> On Thu, Jun 25, 2009 at 3:41 AM, fft1976  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
-~--~~~~--~~--~--~---

how does clojure's reader determine encoding when reading source from file?

[B Smith-Mannschott]

When clojure loads a source file, how does it know what encoding to
use? Does it just assume Latin-1? Does it just use platform encoding
(not the same on all platforms!)? Is there a way to tell it the source
is UTF-8 encoded? If not, perhaps following the Python/Emacs
convention might be sensible:

  ; -*- coding: utf-8 -*-

on the first or second line of the file.

How about at the REPL?

// Ben

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

[Ted Neward]

Be careful with assumptions about the two platforms--extension methods, for
example, are purely a fiction of the C# compiler. No CLR support was added
to provide anything that shipped as part of C# 3.0--just compiler and
libraries.

Ditto (AFAICT) for .NET 4.0. The new "dynamic" keyword is just syntactic
sugar.

To do the comparisons justice, you should look solely at the JVM
Specification and the ECMA CLI Specification documents (at least the first 3
partitions).

Ted Neward | Principal Consultant, ThoughtWorks
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.thoughtworks.com | http://www.tedneward.com

> -Original Message-
> From: clojure@googlegroups.com [mailto:cloj...@googlegroups.com] On
> Behalf Of mmwaikar
> Sent: Wednesday, July 01, 2009 6:01 PM
> To: Clojure
> Subject: Re: Problem with clojure code on .net.
> 
> 
> 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  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 th

Re: loneclojurian at ICFP programming contest

[fft1976]

On Jun 30, 3:02 pm, igorrumiha  wrote:

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

I like your honesty! You can come to my house and * my sister!

I wonder if Jon Harrop is still planning to write Clojure for
Scientists or Scala for Scientists or both?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---