Why is MVCC history managed manually?

[Peter]

Hi Rich,

Still can't reply on that thread, but I was able to start this one.

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

What's the issue with keeping a singly linked list of transactions to
set up object dependencies so that the GC can trim your history list
for you? You only add to the list, it gets GC'd so you don't have to
touch it again. I can get my transaction time-stamp and add to the
list by relying on just 1 AtomicReference CAS. The overhead seems
minimal.

I've had a play with this and the only real issue I've found is that
doing a Thread.sleep(5000) in the middle of a read-only transaction
will cause your histories to become long because values are changed.
But they GC after the transaction finishes. So a badly performing
transaction that blocks may end up using all available memory for
history.
Other than that, letting the GC do the work seems to be a more
efficient and
simpler approach.

I was just curious about the reason you decided to go for the manual
approach, that's all. Maybe there is something I hadn't considered.

Thanks,
Peter

-- 
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: Why is MVCC history managed manually?

[Peter]

Hi Rich,

If you set up your object dependencies correctly then the objects you
want will stay in memory. Your history list would be a list of
WeakReference so it could be GC'd.

This is nothing about read tracking, more about setting the correct
object dependencies so that the GC doesn't remove objects you aren't
quite finished with yet.

I been writing up a description here. It's a simplified version of
what I've been playing with. 
http://creativereality.com.au/notes/concurrency/54-mvcc-stm-gcd-ref-history?start=1

I kept the Transaction objects on the list, but you could consider
keeping a smaller object with just has a collection in it; associated
with the transaction.

-Peter

-- 
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: Why is MVCC history managed manually?

[Peter]

Hi Rich,

maybe this is a better way of looking at it.

When you create a transaction, you get a new UnitOfTime object that
has the sequential timestamp in it. The Transaction object keeps a
reference to the UnitOfTime object for the rest of the Transaction
objects life.

private static final AtomicReference timeLineHead =

new AtomicReference(new UnitOfTime(0));

public static UnitOfTime getNewUnitOfTime() {

UnitOfTime current = timeLineHead.get();

final UnitOfTime future = new UnitOfTime(current.time + 1);

while (!timeLineHead.compareAndSet(current, future)) {

current = timeLineHead.get();

future.time = current.time + 1;

}

current.future = future;

return future;

}

UnitOfTime objects are kept in a singly linked list to make a time
line. The sole purpose of this list is to guarantee garbage collection
order. The first UnitOfTime object created will also be the first one
GC'd. Now we have a guaranteed order objects will be GC'd - great for
a Ref history list.

The UnitOfTime object also has a set of objects you want it to keep
alive. This set is only written to, never read. It exists only to tell
the GC what you don't want GC'd too early. (It probably doesn't have
to be concurrent.)

public class UnitOfTime {

public UnitOfTime future;

public long time;

private final ConcurrentLinkedQueue keepAliveSet = new
ConcurrentLinkedQueue();

public void keepAlive(Object obj) { keepAliveSet.add(obj); }

public UnitOfTime(long time) { this.time = time; }

}

So we now have Transaction objects referencing the UnitOfTime they
were created. This holds that UnitOfTime object in memory (and
consequently all later UnitOfTime objects) until the Transaction
object has been forgotten and GC'd.

I think you are using the using the latest time in your commits, so
your commit would getNewUnitOfTime(). So when you update your Refs
with new Values, you put the old value on the Ref's history list, you
also use the commit's UnitOfTime object and do
commitUnitOfTime.keepAlive(prevValue). This then guarantees the value
your replaced on the Ref will live up to the commit's UnitOfTime. Any
transaction starting before the commit is now guaranteed to be able to
find that old Value as the commitUnitOfTime will not GC until alll
previous UnitOfTime objects have GC'd. Which means all previous
Transaction objects have been GC'd.

You will need to keep a history list in Ref, but that history list
used WeakReference instead of a strong reference.

I hope this is a clearer explaination.

-Peter

-- 
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: Why is MVCC history managed manually?

[Peter]

Hi Rich,

>
> First, and foremost, it creates interaction relationships between
> transactions that otherwise have no overlap. You see this in the
> memory blowup during overlapping transactions. This rubs against a
> design objective in Clojure's STM to absolutely minimize transactional
> overlap and interaction.

Fair enough.

>
> Second, you do a lot of work in createNewTransaction (get a new
> timestamp, modify existing head, make new transaction the head). How
> is that made consistent? You really need a lock, and at that point
> have moved to a much heavier contention point than in the current
> Clojure STM.

I don't think that's right. I can do most of it with CAS. I need to
the list pointer afterwards but only 1 thread ever sets it and it's
never read.
Well, it's been running tests an i7 without showing any issues so
far.

>
> Third, I'm wary of such extensive use of WeakReferences. That may just
> be conservatism on my part.

It's a fair point, you have to be careful with WeakReferences, they
have a habit of disappearing between uses.

>
> I had considered and implemented similar designs in the early stages
> of developing Clojure's STM, and, while they have some appeal, I think
> these 3 points will eventually cause pain in practice.

Thanks, I thought you would have considered it but wasn't sure why you
went the direction you did.

I think it just shows how lazy I am in not wanting to write the code
to manage the lists.

I appreciate your response.

Regards,
Peter

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

picking out a tag from a nested struct-map and xml-seq

[Peter]

Hi-

I'm brand new to Clojure and FP, reading a bunch and working on my
first programming task (reading in values from an xml file and a text
file and then creating a new text file with some lines/sections of the
original text file replaced based on the content of the xml).

I found some helpful info here: 
http://www.chrisumbel.com/article/clojure_xml_parsing_xml-seq
on reading the xml file, but I'm a couple more levels deep than that
article. I don't know much about Clojure yet, but I have a feeling I'm
not doing it the right/idiomatic/best way. I've basically got three
nested calls to doseq, and I think it is mostly due to my own
unfamiliarity with Clojure and the better options I would have to do
this in FP.

I'm getting the ver tag in the xml then checking one of its attribs to
make sure I'm pulling from the version I want, and then I get the
content of the mods tag. I've tried to somewhat simplify this case so
the following isn't tested after being extracted from my sandbox.

TIA!

(defn- dig-through-struct
  "Hides a pair of nested doseq calls from my main function"
  [xml-as-struct]
  (doseq [y (:content xml-as-struct)
  :when (= :type (:tag y))]
(doseq [z (:content y)
:when (= :mods (:tag z))]
(println "The content I want" (:content z)

(defn- get-replacement-values
  "Pulls from xml values we want to replace/update/add"
  [x-file]
  (let [xml-file (File. x-file)]
(xml-seq (parse xml-file))
(for [testing-ver `("1.4" "1.6")]
  (doseq [x (xml-seq (parse xml-file))
  :when (= :ver (:tag x))]
(let [iva (:inner-ver-attrib (:attrs x))]
  (if (= testing-ver iva)
(dig-through-struct x testing-ver iva)
(println "Did not match the ver we want" testing-ver iva)))

And this is my xml:







  

  files
  path_old\foo_old.c
  path_old1\foo_old.h


  files
  path\foo.c
  path1\foo.h


  opts
  -bar=1
  -bar=2

  


-- 
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 Code Analysis Tools

[Peter Wolf]

Thanks, I strongly agree.

I just emailed curious.attempt.bunny to join forces.  Curious, are you 
out there?

P



[EMAIL PROTECTED] wrote:
> On Dec 2, 12:54 pm, Peter Wolf <[EMAIL PROTECTED]> wrote:
>   
>> Since the code doesn't exist yet, I'd have to say no...  Like I said,
>> I'm just getting started.
>>
>> How about I get the basic framework going so that IntelliJ knows about
>> CLJ files, and say paren matching works.  Then we can start a
>> SourceForge project and others can implement the API for references,
>> refactoring, formatting etc.
>>
>> 
> Just found this http://code.google.com/p/clojure-intellij-plugin/ - I
> guess that's another one? Might be worth looking into working on that
> rather than starting up a competitor.
> >
>
>   


--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Clojure Code Analysis Tools

[Peter Wolf]

Since the code doesn't exist yet, I'd have to say no...  Like I said, 
I'm just getting started.

How about I get the basic framework going so that IntelliJ knows about 
CLJ files, and say paren matching works.  Then we can start a 
SourceForge project and others can implement the API for references, 
refactoring, formatting etc.


[EMAIL PROTECTED] wrote:
> On Dec 1, 4:11 pm, Peter Wolf <[EMAIL PROTECTED]> wrote:
>   
>> Since I plan to introduce Clojure into existing large Java projects, I want 
>> to use a decent IDE.  So I am writing a Clojure plugin for my favorite-- 
>> IntelliJ.  When I'm done I hope to offer a nice integrated environment 
>> complete with debugger, profiler and automatic refactoring.  
>>
>> However, this will take me a while as I am new to writing IntelliJ plugins.  
>> All help welcome.
>>
>> Peter
>> 
>
> Hurry up! That would be awesome. Is the plugin code publicly available
> anywhere?
>
> -Darren
> >
>
>   


--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Clojure Code Analysis Tools

[Peter Wolf]

I just pulled the code down.

While it's true that there is no implementation, Curious Bunny (merlyn) 
did an excellent job of making a minimal custom language plugin.  This 
is something that is lacking in IntelliJ's own documentation.

By making a trivial change to Curious's code I was able to change the 
icon for CLJ files.  So I know it is working.

I vote that we take Merlyn's code as a base and put it on SourceForge.  
I'll add my Lexer and Parser and work on formatting, parens matching and 
coloring.  Erik can add his REPL and completion stuff.

However, I think it would be polite to wait 24 hours for Merlyn to give 
his/her OK before I do this.


Randall R Schulz wrote:
> On Tuesday 02 December 2008 06:16, [EMAIL PROTECTED] wrote:
>   
>> ...
>>
>> Just found this http://code.google.com/p/clojure-intellij-plugin/ - I
>> guess that's another one? Might be worth looking into working on that
>> rather than starting up a competitor.
>> 
>
> I retrieved the code. It is at best a skeleton. There appears to be 
> virtually no implementation at all beyond the identification of the 
> language supported and the file suffixes used.
>
> I believe "failure to launch" would characterize that project...
>
>
> Randall Schulz
>
> >
>
>   


--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Elegant but very slow

[Peter Wolf]

I'm a n00b, but isn't the point of this language to be *faster* than 
Java?... at least on a multiprocessor machine.

Shouldn't the number of processors on the test machine make a big 
difference to how fast it runs?  Whereas, the Java version is only 
dependent on the clock rate of the individual processors.

What happens if we run this benchmark on a nice 4 core core machine?


Mark Engelberg wrote:
> Has anyone been able to use type hints to successfully close the last
> bit of difference between the Clojure and Java version on this
> benchmark?
>
> On Sat, Dec 6, 2008 at 6:14 AM, PeterB <[EMAIL PROTECTED]> wrote:
>   
>> Running in Clojure REPL for java 1.6.0_11 with -server option:
>>
>> result: -2
>> Elapsed time: 6080.294283 msecs
>>
>> Wow! Elegant and fast!
>> 
>
> >
>
>   


--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Elegant but very slow

[Peter Wolf]

Hmmm...

Looking at the code I see

(defn sum-trees [iterations depth]
  (let [sum #(+ (check-tree (make-tree % depth))
  (check-tree (make-tree (- %) depth)))]
(reduce + (map sum (range 1 (inc iterations))


Shouldn't expressing the algorithm as a REDUCE and MAP instead of a LOOP 
do the trick?  I would expect that to compile into parallel code.  
Otherwise, why go through all the pain of learning functional 
programming (and convincing management)?

Randall R Schulz wrote:
> On Sunday 07 December 2008 07:11, Peter Wolf wrote:
>   
>> I'm a n00b, but isn't the point of this language to be *faster* than
>> Java?... at least on a multiprocessor machine.
>> 
>
> I don't think performance is a particular criterion for the design of 
> this language. It's not unimportant, but the quality of the code it 
> engenders, especially w.r.t. to concurrency and the difficulty of 
> writing correct code using conventional thread-aware mechanisms,
> _is_ a key design goal.
>
>
>   
>> Shouldn't the number of processors on the test machine make a big
>> difference to how fast it runs?  Whereas, the Java version is only
>> dependent on the clock rate of the individual processors.
>> 
>
> Only for algorithms that are both parallelizable and which have actually 
> been written in parallel form. There is not yet (and may never be) any 
> ability to automatically parallelize arbitrary algorithms or code.
>
>
>   
>> What happens if we run this benchmark on a nice 4 core core machine?
>> 
>
> And nothing else is running? One core will be used for the thread 
> running this code. Another will do any I/O, though in this case there 
> is virtually none, and another will do GC.
>
> This test is a sequential algorithm. I'm not familiar with the Alioth 
> benchmarks / shootout, but maybe there are some parallel tests in 
> there.
>
>
> Randall Schulz
>
> >
>
>   


--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Elegant but very slow

[Peter Wolf]

That's pretty encouraging! :-D

The language does work as advertised, but is still under development.  
One shouldn't expect it to crush Java on speed, nor take full advantage 
of multiple processors... yet.

Clojure is a language for the future, after all.  It can only get 
better.  Whereas Java will always be a slave to clock-rate.

Stephen C. Gilardi wrote:
> On Dec 7, 2008, at 10:11 AM, Peter Wolf wrote:
>
>   
>> Shouldn't the number of processors on the test machine make a big
>> difference to how fast it runs?  Whereas, the Java version is only
>> dependent on the clock rate of the individual processors.
>> 
>
> Replacing the "map" call with "pmap" on a 2 core machine improved my  
> time by about 6% (the code was already keeping both cores pretty busy).
>
> On a 4 core machine it brought the time from 6.8 seconds down to 4.7.
>
> On the same 4 core machine, the Java version posted by the original  
> poster runs in 1.3 seconds including JVM launch time.
>
> I tried use clojure.parallel's preduce as well, but on my 4 core  
> machine it didn't affect the time.
>
> --Steve
>
>
> >
>
>   


--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: slime+clojure problem

[Peter Eddy]

On Dec 3, 7:49 am, Dimitre Liotev <[EMAIL PROTECTED]> wrote:
> For example, my slime-lisp-implementations is:
>
>        (setq slime-lisp-implementations
>              `(
>                (sbcl ("sbcl"))
>                (ccl ("ccl"))
>                (clojure ("clojure") :init swank-clojure-init)
>                (clisp ("clisp"))
>                (abcl ("abcl"))
>                (cmucl ("lisp"))
>                (s48 ("scheme48") :init slime48-init-command)
>
> If I specify (clojure ("clojure")) instead of (clojure (clojure") :init
> swank-clojure-init), I get the same error as you.

The :init param was it, thank you very much!

- Peter
--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Clojure Code Analysis Tools

[Peter Wolf]

Hi Darren,

Work continues.  Merlyn has invited me to take over admin of the code.  
I have taken Merlyn's code as a base, and am fleshing it out.

Currently, I am struggling though the lack of documentation and examples 
for building a custom language plugin.  I have implemented a Lexer, and 
am debugging Brace Matching.  BTW, Rich, I stole the Lexer from the 
Clojure source.  I hope that's OK.

Once I get Brace Matching going, I was going to check it in, and invite 
others to join in the hacking.

Please email me at [EMAIL PROTECTED] if you want to help with the 
IntelliJ plugin.

Peter


[EMAIL PROTECTED] wrote:
> On Dec 2, 4:52 pm, Peter Wolf <[EMAIL PROTECTED]> wrote:
>   
>> I vote that we take Merlyn's code as a base and put it on SourceForge.  
>> I'll add my Lexer and Parser and work on formatting, parens matching and
>> coloring.  Erik can add his REPL and completion stuff.
>>
>> However, I think it would be polite to wait 24 hours for Merlyn to give
>> his/her OK before I do this.
>>
>> 
> Any further word on this? Realistically the only way I'll be able to
> use clojure in anger (ie. at work) is if I can bring all the Intellij
> goodness to bear on it :) Coding without automated refactoring support
> and instant code navigation now feels like chopping down trees with a
> spoon.
> >
>
>   


--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Does ANTS.CLJ still work?

[Peter Wolf]

Hello

I was just following the directions on Ubuntu setup directions on 
http://riddell.us/clojure/

I get the following error when I try ANTS.CLJ.  Has something changed?

Peter

(defn setup
  "places initial food and ants, returns seq of ant agents"
  []
 >>>  (sync nil
(dotimes [i food-places]
  (let [p (place [(rand-int dim) (rand-int dim)])]
(alter p assoc :food (rand-int food-range
(doall
 (for [x home-range y home-range]
   (do
 (alter (place [x y])
assoc :home true)
 (create-ant [x y] (rand-int 8)))

user=> (load-file "ants.clj")
java.lang.IllegalArgumentException: recur arg for primitive local: 
G__2315 must be matching primitive
clojure.lang.Compiler$CompilerException: ants.clj:61: 
java.lang.IllegalArgumentException: recur arg for primitive local: 
G__2315 must be matching primitive
at clojure.lang.Compiler.analyzeSeq(Compiler.java:3865)
at clojure.lang.Compiler.analyze(Compiler.java:3698)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:3848)
at clojure.lang.Compiler.analyze(Compiler.java:3698)
at clojure.lang.Compiler.analyze(Compiler.java:3671)
at clojure.lang.Compiler.access$100(Compiler.java:37)
at clojure.lang.Compiler$HostExpr$Parser.parse(Compiler.java:734)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:3858)
at clojure.lang.Compiler.analyze(Compiler.java:3698)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:3848)
at clojure.lang.Compiler.analyze(Compiler.java:3698)
at clojure.lang.Compiler.analyze(Compiler.java:3671)
at clojure.lang.Compiler.access$100(Compiler.java:37)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:3384)
at clojure.lang.Compiler$FnMethod.parse(Compiler.java:3231)
at clojure.lang.Compiler$FnMethod.access$1200(Compiler.java:3142)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:2766)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:3856)
at clojure.lang.Compiler.analyze(Compiler.java:3698)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:3848)
at clojure.lang.Compiler.analyze(Compiler.java:3698)
at clojure.lang.Compiler.access$200(Compiler.java:37)
at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:343)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:3858)
at clojure.lang.Compiler.analyze(Compiler.java:3698)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:3848)
at clojure.lang.Compiler.analyze(Compiler.java:3698)
at clojure.lang.Compiler.analyze(Compiler.java:3671)
at clojure.lang.Compiler.eval(Compiler.java:3895)
at clojure.lang.Compiler.load(Compiler.java:4196)
at clojure.lang.Compiler.loadFile(Compiler.java:4163)
at clojure.lang.RT$3.invoke(RT.java:289)
at user.eval__2290.invoke(Unknown Source)
at clojure.lang.Compiler.eval(Compiler.java:3891)
at clojure.lang.Repl.main(Repl.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at jline.ConsoleRunner.main(ConsoleRunner.java:69)
Caused by: java.lang.RuntimeException: 
java.lang.IllegalArgumentException: recur arg for primitive local: 
G__2315 must be matching primitive
at clojure.lang.Compiler$RecurExpr.emit(Compiler.java:3598)
at clojure.lang.Compiler$BodyExpr.emit(Compiler.java:3414)
at clojure.lang.Compiler$IfExpr.emit(Compiler.java:2264)
at clojure.lang.Compiler$BodyExpr.emit(Compiler.java:3414)
at clojure.lang.Compiler$LetExpr.emit(Compiler.java:3542)
at clojure.lang.Compiler$BodyExpr.emit(Compiler.java:3414)
at clojure.lang.Compiler$LetExpr.emit(Compiler.java:3534)
at clojure.lang.Compiler$BodyExpr.emit(Compiler.java:3414)
at clojure.lang.Compiler$LetExpr.emit(Compiler.java:3542)
at clojure.lang.Compiler$BodyExpr.emit(Compiler.java:3414)
at clojure.lang.Compiler$LetExpr.emit(Compiler.java:3542)
at clojure.lang.Compiler$BodyExpr.emit(Compiler.java:3411)
at clojure.lang.Compiler$FnMethod.emit(Compiler.java:3255)
at clojure.lang.Compiler$FnExpr.compile(Compiler.java:3013)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:2807)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:3856)
... 39 more
Caused by: java.lang.IllegalArgumentException: recur arg for primitive 
local: G__2315 must be matching primitive
at clojure.lang.Compiler$RecurExpr.emit(Compiler.java:3593)
... 54 more
user=>


--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit 

Re: Does ANTS.CLJ still work?

[Peter Wolf]

Hmmm...  I am also having problems with SLIME (see below)

Perhaps the otherwise-very-nice Ubuntu instructions need to be updated

http://riddell.us/clojure/

Can someone recommend the current best way to get a matching Clojure and 
Swank and Slime

Thanks
Peter


ser=> java.lang.Exception: Unsupported binding form: 
clojure.lang.persistentl...@f50439d
clojure.lang.Compiler$CompilerException: util.clj:76: Unsupported 
binding form: clojure.lang.persistentl...@f50439d
at clojure.lang.Compiler.analyzeSeq(Compiler.java:3865)
at clojure.lang.Compiler.analyze(Compiler.java:3698)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:3848)
at clojure.lang.Compiler.analyze(Compiler.java:3698)
at clojure.lang.Compiler.analyze(Compiler.java:3671)
at clojure.lang.Compiler.access$100(Compiler.java:37)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:3384)
at clojure.lang.Compiler$FnMethod.parse(Compiler.java:3231)
at clojure.lang.Compiler$FnMethod.access$1200(Compiler.java:3142)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:2766)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:3856)
at clojure.lang.Compiler.analyze(Compiler.java:3698)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:3848)
at clojure.lang.Compiler.analyze(Compiler.java:3698)
at clojure.lang.Compiler.access$200(Compiler.java:37)
at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:343)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:3858)
at clojure.lang.Compiler.analyze(Compiler.java:3698)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:3848)
at clojure.lang.Compiler.analyze(Compiler.java:3698)
at clojure.lang.Compiler.analyze(Compiler.java:3671)
at clojure.lang.Compiler.eval(Compiler.java:3895)
at clojure.lang.Compiler.load(Compiler.java:4196)
at clojure.lang.RT.loadResourceScript(RT.java:360)
at clojure.lang.RT.loadResourceScript(RT.java:347)
at clojure.lang.RT.loadResourceScript(RT.java:339)
at clojure.load__1722$fn__1724.invoke(boot.clj:3195)
at clojure.load__1722.doInvoke(boot.clj:3194)
at clojure.lang.RestFn.invoke(RestFn.java:413)
at clojure.load_one__1685.invoke(boot.clj:3041)
at clojure.load_lib__1705.doInvoke(boot.clj:3078)
at clojure.lang.RestFn.applyTo(RestFn.java:147)
at clojure.apply__135.doInvoke(boot.clj:364)
at clojure.lang.RestFn.invoke(RestFn.java:443)
at clojure.load_libs__1709.doInvoke(boot.clj:3108)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.apply__135.doInvoke(boot.clj:364)
at clojure.lang.RestFn.invoke(RestFn.java:460)
at clojure.use__1716.doInvoke(boot.clj:3173)
at clojure.lang.RestFn.invoke(RestFn.java:458)
at swank.eval__2299.invoke(core.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:3891)
at clojure.lang.Compiler.load(Compiler.java:4196)
at clojure.lang.RT.loadResourceScript(RT.java:360)
at clojure.lang.RT.loadResourceScript(RT.java:347)
at clojure.lang.RT.loadResourceScript(RT.java:339)
at clojure.load__1722$fn__1724.invoke(boot.clj:3195)
at clojure.load__1722.doInvoke(boot.clj:3194)
at clojure.lang.RestFn.invoke(RestFn.java:413)
at clojure.load_one__1685.invoke(boot.clj:3041)
at clojure.load_lib__1705.doInvoke(boot.clj:3078)
at clojure.lang.RestFn.applyTo(RestFn.java:147)
at clojure.apply__135.doInvoke(boot.clj:364)
at clojure.lang.RestFn.invoke(RestFn.java:443)
at clojure.load_libs__1709.doInvoke(boot.clj:3108)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.apply__135.doInvoke(boot.clj:364)
at clojure.lang.RestFn.invoke(RestFn.java:460)
at clojure.use__1716.doInvoke(boot.clj:3173)
at clojure.lang.RestFn.invoke(RestFn.java:441)
at user.eval__2296.invoke(swank.clj:11)
at clojure.lang.Compiler.eval(Compiler.java:3891)
at clojure.lang.Compiler.load(Compiler.java:4196)
at clojure.lang.RT.loadResourceScript(RT.java:360)
at clojure.lang.RT.loadResourceScript(RT.java:347)
at clojure.lang.RT.loadResourceScript(RT.java:339)
at clojure.load__1722$fn__1724.invoke(boot.clj:3195)
at clojure.load__1722.doInvoke(boot.clj:3194)
at clojure.lang.RestFn.invoke(RestFn.java:413)
at clojure.load_one__1685.invoke(boot.clj:3041)
at clojure.load_lib__1705.doInvoke(boot.clj:3078)
at clojure.lang.RestFn.applyTo(RestFn.java:147)
at clojure.apply__135.doInvoke(boot.clj:364)
at clojure.lang.RestFn.invoke(RestFn.java:443)
at clojure.load_libs__1709.doInvoke(boot.clj:3104)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.apply__135.doInvoke(boot.clj:364)
at clojure.lang.RestFn.invoke(RestFn.java:443)
at clojure.require__1713.doInvoke(boot.clj:3163)
at clojure.lang.RestFn.invoke(RestFn.java:413)
at user.eval__2293.invoke(Unknown Source)
at clojure.lang.Compiler.eval(Compiler.java:3891)
at clojure.lang.Repl.main(Repl.java:75)
Caused by: java.lang.Except

IntelliJ Plugin now on Google Code

[Peter Wolf]

For those who are following or helping my efforts (thank you), the 
IntelliJ Clojure plugin code is now on GoogleCode.  Enjoy!

http://code.google.com/p/clojure-intellij-plugin/source/browse/#svn/trunk/src/org/clojure/intellij

Please note that this code is nowhere near ready for use.  Syntax 
coloring is barely working, but only if you scroll to the top of a file, 
and CLJ files have an icon.  That it so far.

After coloring is debugged, I will add folding, references, indenting, 
refactoring support and all the other goodies one expects from an IDE.

However, I need help, especially with the REPL.  Please email me if you 
want to join this project.

Peter

--~--~-~--~~~---~--~~
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
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: IntelliJ Plugin now on Google Code

[Peter Wolf]

Hi Randall,

I'd like to get it to the point where some set of features completely 
work before I release a plugin.  I'd like to see at least coloring, 
parens matching and a REPL.

For the moment you need to install the IntelliJ plugin development kit 
if you just want to try it.  Of course, having done that, you could help 
me fix the bugs ;-)

P



Randall R Schulz wrote:
> Peter,
>
> Great news!
>
> On Friday 19 December 2008 05:36, Peter Wolf wrote:
>   
>> For those who are following or helping my efforts (thank you), the
>> IntelliJ Clojure plugin code is now on GoogleCode.  Enjoy!
>>
>> http://code.google.com/p/clojure-intellij-plugin/source/browse/#svn/t
>> runk/src/org/clojure/intellij
>> 
>
> At what point will it be available for installation via the IDEA plug-in 
> manager?
>
>
>   
>> ...
>>
>> Peter
>> 
>
>
> Randall Schulz
>
> >
>
>   


--~--~-~--~~~---~--~~
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
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: IntelliJ Plugin

[Peter Wolf]

Hi Justin,
This is the right place.  Thanks for trying the plugin.

It would absolutely be helpful to document use of the plugin.  However, I am
sure you can tell that it is nowhere near ready.

I would like to get a basic set of features going and then recruit you and
Randall to test and document it.  Once it is banged on, we can post the
plugin to IntelliJ so it can be installed with a mouse click.

I am currently working on the Parser, which will give us parens matching and
folding, and Compile/Run/Debug/Profile.

The one big piece I am missing is the REPL.  Any help would be appreciated.

Peter


On Wed, Dec 24, 2008 at 4:25 PM, Justin Johnson wrote:

> Hi,
>
> Is this the appropriate mailing list to talk about the Clojure IntelliJ
> plugin?  The Google Code site didn't list any other mailing list.
>
> http://code.google.com/p/clojure-intellij-plugin/
>
> I went through the process of building and installing the plugin on Windows
> XP with IntelliJ IDEA 8.0.1 and thought it might be helpful if I document
> what I did on the wiki.  I also have a small suggestion that the build.xml
> file use environment variables instead of hard coded paths to java.home and
> idea.home.
>
> Thanks,
> Justin
>
> >
>

--~--~-~--~~~---~--~~
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
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: Dubious generated bytecode

[Peter Collingbourne]

On Thu, Jul 31, 2008 at 02:01:08PM -0700, Rich Hickey wrote:
> 
> 
> On Jul 31, 11:43 am, Stefan Ring  wrote:
> > Thanks a lot. Your change makes the CACAO verifier happy but I think
> > you should revert it.
> >
> > The instruction in question is actually invokeinterface, not
> > invokevirtual. After reading the specification for invokeinterface
> > (esp. "Runtime Exceptions"), I have the strong impression that clojure
> > is right and CACAO is wrong.
> >
> 
> Yes, invokeinterface, sorry.
> 
> Ok, I've backed it out.

Although the current version of clojure does generate technically
valid bytecode with respect to invokeinterface, I would like to
recommend that it be modified to emit a checkcast.

The ability of invokeinterface to accept a target of type Object is
the result of a relaxation in the strictness of the verifier which was
presumed to be necessary in certain special cases, as described further
in [1].  The paper also explains why this relaxation is unnecessary,
and proposes a stricter verifier.

Even with the specification's (and hotspot's) less strict verifier,
the use of invokeinterface without a checkcast means that runtime type
errors in interface calls result in an IncompatibleClassChangeError
rather than the more conventional ClassCastException, which may lead
to confusion.

Background: I am packaging clojure for Debian, which uses gij as its
default JVM.  gij uses the stricter verifier, and rejects clojure
generated code with a stack trace similar to that shown in [2].

I am attaching a patch which modifies clojure to emit a checkcast
wherever it is required by a strict verifier.

Thanks,
-- 
Peter

[1] 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.22.1261&rep=rep1&type=pdf
[2] http://server.complang.tuwien.ac.at/cgi-bin/bugzilla/show_bug.cgi?id=82#c1
From 9c991e251cbc27947737445847a4103b371737ae Mon Sep 17 00:00:00 2001
From: Peter Collingbourne 
Date: Mon, 29 Dec 2008 01:40:19 +
Subject: [PATCH] Generate bytecode compatible with stricter JVMs (e.g. gij)

---
 src/clj/clojure/core_proxy.clj |2 ++
 src/clj/clojure/genclass.clj   |3 +++
 src/jvm/clojure/lang/Compiler.java |6 ++
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/src/clj/clojure/core_proxy.clj b/src/clj/clojure/core_proxy.clj
index 8a77734..fc20cf7 100644
--- a/src/clj/clojure/core_proxy.clj
+++ b/src/clj/clojure/core_proxy.clj
@@ -62,6 +62,7 @@
   (. gen (dup))
   (. gen (ifNull else-label))
 ;if found
+  (. gen (checkCast ifn-type))
   (. gen (loadThis))
 ;box args
   (dotimes [i (count ptypes)]
@@ -125,6 +126,7 @@
   (. gen (loadThis))
   (. gen (dup))
   (. gen (getField ctype fmap imap-type))
+  (. gen (checkCast (totype clojure.lang.IPersistentCollection)))
   (. gen (loadArgs))
   (. gen (invokeInterface (totype clojure.lang.IPersistentCollection)
   (. Method (getMethod "clojure.lang.IPersistentCollection cons(Object)"
diff --git a/src/clj/clojure/genclass.clj b/src/clj/clojure/genclass.clj
index e293fe0..e8f55b6 100644
--- a/src/clj/clojure/genclass.clj
+++ b/src/clj/clojure/genclass.clj
@@ -181,6 +181,7 @@
 (when is-overload
   (. gen (mark found-label)))
 ;if found
+(. gen (checkCast ifn-type))
 (when-not as-static
   (. gen (loadThis)))
 ;box args
@@ -274,6 +275,7 @@
 (emit-get-var gen init-name)
 (. gen dup)
 (. gen ifNull no-init-label)
+(. gen (checkCast ifn-type))
 ;box init args
 (dotimes [i (count pclasses)]
   (. gen (loadArg i))
@@ -386,6 +388,7 @@
 (emit-get-var gen main-name)
 (. gen dup)
 (. gen ifNull no-main-label)
+(. gen (checkCast ifn-type))
 (. gen loadArgs)
 (. gen (invokeStatic rt-type (. Method (getMethod "clojure.lang.ISeq seq(Object)"
 (. gen (invokeInterface ifn-type (new Method "applyTo" obj-type 
diff --git a/src/jvm/clojure/lang/Compiler.java b/src/jvm/clojure/lang/Compiler.java
index bb62536..961e16a 100644
--- a/src/jvm/clojure/lang/Compiler.java
+++ b/src/jvm/clojure/lang/Compiler.java
@@ -1155,8 +1155,7 @@ static class InstanceMethodExpr extends MethodExpr{
 			{
 			Type type = Type.getType(method.getDeclaringClass());
 			target.emit(C.EXPRESSION, fn, gen);
-			if(!method.getDeclaringClass().isInterface())
-gen.checkCast(type);
+			gen.checkCast(type);
 			MethodExpr.emitTypedArgs(fn, gen, method.getParameterTypes(), args);
 			if(context == C.RETURN)
 {
@

Debian/Ubuntu clojure package

[Peter Collingbourne]

Hello,

I have recently put together a Debian package for clojure.  The package
may also work on Ubuntu however this is untested.  It may be downloaded
from:

  http://www.pcc.me.uk/~peter/debian/clojure_0.0.20081217-1_all.deb

You may also be interested in the "source package" which is downloadable
using:

  dget http://www.pcc.me.uk/~peter/debian/clojure_0.0.20081217-1.dsc

Comments are much appreciated.

Thanks,
-- 
Peter


signature.asc
Description: Digital signature

Re: when performance matters

[Peter Wolf]

Why is Clojure slower than Java?  And, can it be fixed?  Is it just the 
dynamic lookups?

I also want to use Clojure in my work to implement the inner loops, but 
I was disappointed by a previous discussion looking at the speed of 
Clojure.  As I recall Clojure seems to be about 1/4 the speed of Java at 
the moment.

Until we regularly have 10's of processors, it seems hard to justify 
that kind of hit for code that has to be fast.  So, I use Clojure for 
scripting and high level code currently.

Peter

P.S.  I also find that C++ and Java are now approximately the same 
speed.  And if exceptions are enabled, Java blows C++ out of the water.

cliffc wrote:
> Some comments:
>
> 1- If you think that HotSpot/Java is slower than C++ by any
> interesting amount, I'd love to see the test case.  Being the
> architect of HotSpot "-server" I've a keen interest in where
> performance isn't on par with C.  Except for a handful of specialized
> uses (e.g. high-level interpreters using gnu label vars), I've only
> ever seen equivalent code between C/C++ & Java (not so w/asm+C where
> the asm calls out specialized ops or makes specialized optimizations).
>
> 2- As already mentioned, there's no auto-parallelization tools Out
> There that are ready for prime-time.  (there ARE tools out there that
> can *help* parallelize an algorithm but you need annotations, etc to
> make them work)
>
> 3- Making your algorithm parallel is worth an N-times speedup, where N
> is limited by the algorithm & available CPUs.  Since you can get huge
> CPU counts these days, if you can parallelize your algorithm you'll
> surely win over almost any other hacking.  If you take a 50% slowdown
> in the hacking but get to run well on a 4-way box, then your 2x
> ahead.  I'd love to say that the JVM "will just do it", but hand-
> hacking for parallelism is the current state-of-the-art.
>
> 4- Java/Clojure makes some of this much easier than in C/C++.  Having
> a memory model is a HUGE help in writing parallel code, as is the Java
> concurrency libs, or the above-mentioned Colt libraries.
>
> 5- The debian shootout results generally badly mis-represent Java.
> Most of them have runtimes that are too small (<10sec) to show off the
> JIT, and generally don't use any of the features which commonly appear
> in large Java programs (heavy use of virtuals, deep class hierarchies,
> etc) for which the JIT does a lot of optimization.  I give a public
> talk on the dangers of microbenchmarks and all the harnesses I've
> looked at in the shootout fail basic sanity checks.  Example: the
> fannkuch benchmark runs 5 secs in Java, somewhat faster in C++.  Why
> does anybody care about a program which runs 5sec?  (there's other
> worse problems: e.g. the C++ code gets explicit constant array sizes
> hand-optimized via templates; the equivalent Java optimization isn't
> done but is trivial (declare 'n' as a *final* static var) and doing so
> greatly speeds up Java, etc).
>
> 6- If you need a zillion integer (not FP) parallel Java cycles, look
> at an Azul box.  Azul's got more integer cycles in a flat shared-
> memory config than anybody else by a long shot.
>
> Cliff
>
> >
>
>   


--~--~-~--~~~---~--~~
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
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: IntelliJ Plugin

[Peter Wolf]

Hi Aria,

Actually, I am just in the process of writing up the install 
instructions.  Watch this space!


aria42 wrote:
> Did you ever get around to posting the notes on getting the IntelliJ
> plugin to work? I sorely would love IDE support for Clojure in either
> Eclipse or IntelliJ. Is the IntelliJ one in a usable state, or is it
> not ready for some alpha-level testers?
>
>   Cheers, Aria
>
> On Dec 29 2008, 10:36 am, "Justin Johnson" 
> wrote:
>   
>> On Sat, Dec 27, 2008 at 8:55 AM, Peter Wolf  wrote:
>> 
>>> Hi Justin,
>>> This is the right place.  Thanks for trying the plugin.
>>>   
>>> It would absolutely be helpful to document use of the plugin.  However, I
>>> am sure you can tell that it is nowhere near ready.
>>>   
>> Yes, I noticed there wasn't much there yet.  I still think it would be great
>> if you documented how you build and test.  In particular I found it to be a
>> pain to setup my own update site and updatePlugins.xml file just to install
>> my own plugin.  It wasn't difficult, but certainly not efficient.  My hope
>> was that sharing setup info like this would help me discover more efficient
>> ways of working.
>>
>>
>>
>> 
>>> I would like to get a basic set of features going and then recruit you and
>>> Randall to test and document it.  Once it is banged on, we can post the
>>> plugin to IntelliJ so it can be installed with a mouse click.
>>>   
>>> I am currently working on the Parser, which will give us parens matching
>>> and folding, and Compile/Run/Debug/Profile.
>>>   
>>> The one big piece I am missing is the REPL.  Any help would be appreciated.
>>>   
>>> Peter
>>>   
>>> On Wed, Dec 24, 2008 at 4:25 PM, Justin Johnson 
>>> wrote:
>>>   
>>>> Hi,
>>>> 
>>>> Is this the appropriate mailing list to talk about the Clojure IntelliJ
>>>> plugin?  The Google Code site didn't list any other mailing list.
>>>> 
>>>> http://code.google.com/p/clojure-intellij-plugin/
>>>> 
>>>> I went through the process of building and installing the plugin on
>>>> Windows XP with IntelliJ IDEA 8.0.1 and thought it might be helpful if I
>>>> document what I did on the wiki.  I also have a small suggestion that the
>>>> build.xml file use environment variables instead of hard coded paths to
>>>> java.home and idea.home.
>>>> 
>>>> Thanks,
>>>> Justin
>>>> 
> >
>
>   


--~--~-~--~~~---~--~~
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
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: when performance matters

[Peter Wolf]

Rich, I must apologize-- I worded my question *far* too harshly.  I knew 
it as I pushed the send button.  I am a huge fan of Clojure, and plan to 
use it as often as possible.  My question was really looking for hints, 
so that I can use it in more places.  You gave me a great one, thanks!

Is there any way to avoid the overhead of dynamic lookups in Clojure?  
Can I tell the compiler somehow that the types of each argument is 
constant, and/or that a symbol will always resolve to the same place.

I am assuming, and perhaps I am wrong, that dynamic behavior is a 
significant overhead.

P

Rich Hickey wrote:
> For those interested in numeric performance, Clojure lets you use
> arrays of primitives, has primitive math support, primitive local
> support, and has higher-level macros for dealing with them (amap,
> areduce) which can also serve as models for your own. You can also
> use :inline to wrap arithmetic primitives implemented as Java static
> methods, as Clojure itself does for +/* etc, which HotSpot inlines
> quite nicely.
>
> If people are not exploring and using these things, and are concerned
> about performance not being the same as Java's, I can't help them.
> That's how you get numeric performance the same as Java's in Clojure.
> Cliff Click has already spoken about the performance of Java vs/ C++,
> and I concur.
>
> Where Clojure currently has an unavoidable overhead vs Java is Clojure-
>   
>> Clojure calls involving numbers. Since the fn call/return signature
>> 
> is Object based, those numbers need to be boxed, at least until we get
> something like tagged numbers on the JVM. That means naive fib
> microbenchmarks suffer (boxing in a tight loop), but most real
> performance-critical numeric code is not like naive fib. Most of it is
> inner loops on vectors/matrices, or local iterative calculations
> involving primitives, which, if implemented using the above
> constructs, is as fast as Java.
>
> So, getting the fastest numerics means working with primitive types,
> and lower-level constructs. It's not something you'll want to do
> anywhere other than where it really matters. When you do, you'll find
> Clojure's macros let you write higher-level code than the for loops of
> Java. amap and areduce just hint at the possibilities of a high-
> performance, macro-based math library, and I expect similar macros to
> come from people actually doing number crunching with Clojure.
>
> Rich
>
> On Jan 13, 2:53 pm, Peter Wolf  wrote:
>   
>> Why is Clojure slower than Java?  And, can it be fixed?  Is it just the
>> dynamic lookups?
>>
>> I also want to use Clojure in my work to implement the inner loops, but
>> I was disappointed by a previous discussion looking at the speed of
>> Clojure.  As I recall Clojure seems to be about 1/4 the speed of Java at
>> the moment.
>>
>> Until we regularly have 10's of processors, it seems hard to justify
>> that kind of hit for code that has to be fast.  So, I use Clojure for
>> scripting and high level code currently.
>>
>> Peter
>>
>> P.S.  I also find that C++ and Java are now approximately the same
>> speed.  And if exceptions are enabled, Java blows C++ out of the water.
>>
>> cliffc wrote:
>> 
>>> Some comments:
>>>   
>>> 1- If you think that HotSpot/Java is slower than C++ by any
>>> interesting amount, I'd love to see the test case.  Being the
>>> architect of HotSpot "-server" I've a keen interest in where
>>> performance isn't on par with C.  Except for a handful of specialized
>>> uses (e.g. high-level interpreters using gnu label vars), I've only
>>> ever seen equivalent code between C/C++ & Java (not so w/asm+C where
>>> the asm calls out specialized ops or makes specialized optimizations).
>>>   
>>> 2- As already mentioned, there's no auto-parallelization tools Out
>>> There that are ready for prime-time.  (there ARE tools out there that
>>> can *help* parallelize an algorithm but you need annotations, etc to
>>> make them work)
>>>   
>>> 3- Making your algorithm parallel is worth an N-times speedup, where N
>>> is limited by the algorithm & available CPUs.  Since you can get huge
>>> CPU counts these days, if you can parallelize your algorithm you'll
>>> surely win over almost any other hacking.  If you take a 50% slowdown
>>> in the hacking but get to run well on a 4-way box, then your 2x
>>> ahead.  I'd love to say that the JVM "will just do it", but hand-
>>> hacking for parallelism is the 

Pre-Alpha of IntelliJ plugin for Clojure

[Peter Wolf]

Hey Randall, Justin, Aria, HB, and all other IntelliJ enthusiasts

Pre-Alpha of IntelliJ plugin for the Clojure is open for testing...

Plugin currently provides editing with syntax coloring, syntax error 
high-lighting, folding, and brace matching. Also provides run 
configuration for Clojure scripts with REPL.

Still todo includes goto definition and used by referencing, debugger 
integration, profiler integration and refactoring.

Currently I am particularly interested in bugs with the syntax checking. 
Please look for cases where either a syntax error was not high-lighted, 
or valid code was marked as an error. Please report all cases, with an 
S-Expression to opus...@gmail.com.

To install go to Settings/Updates and add the following to Plugin Hosts

/http://clojure-intellij-plugin.googlecode.com/svn/trunk/plugin/updatePlugins.xml/
 


Then hit "Check Now"

Enjoy! Peter Wolf


--~--~-~--~~~---~--~~
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
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 to implement "go to definition" and "find all references"

[Peter Wolf]

Hello, and thanks for all the help with the IntelliJ plugin.

The next feature I want to implement is "references".  That is, one 
selects a symbol, and then can go to the location where that symbol was 
defined (e.g. def, defn, let, etc.).  One can also get a list of all the 
locations where that symbol is referenced.  This feature is very nice 
for navigating code, and is also the core of many automatic refactorings 
(e.g. "rename").

Implementing references are pretty straightforward in a static language 
like Java, were all the references are resolved at compile time.  
However, in a language like Clojure some references get resolved at run 
time.

How do other IDEs handle this?  Is there a recommended set of rules for 
what references can and can not be resolved by the editor?  How does one 
detect a possible non-static reference, or how does one ensure that a 
reference will always refer to the same location? 

Note that I need a 100% reliable solution, if I am going to implement 
automatic refactoring on top of it.  No one wants refactoring that 
messes up the code 5% of the time.

Thanks
Peter

--~--~-~--~~~---~--~~
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
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: How to implement "go to definition" and "find all references"

[Peter Wolf]

Hi and thanks for all the feedback

How does SLIME handle this case?

user=> (def foo 1)
#'user/foo
user=> (defn bah [] (let [foo 2] foo))
#'user/bah
user=> (bah)
2

If I select the "foo" inside the let, I want the local one

How does the running image figure that out?  What does the API to the 
LISP process look like?

Also what happens if you have the following in a file?  How does the 
image figure out which (def...) maps to which reference?

(def foo 1)
foo

(def foo 2)
foo


Thanks
Peter


lpetit wrote:
> Hello,
>
> While I understand this solution has been long in place for Lips, I
> don't think it looks like the ideal solution, e.g. in a world where
> the "source code" is still in files, and not managed by the "lisp
> image". I'm aware of just smalltalk that does this cleanly (it is even
> managing versions of modifications as they are made !).
>
> This to say, that, as an IDE provider, I feel uneasy to offer text
> source code in an editor, while not being able to say to the user :
> "what you are currently seeing is/is not in sync with what is in the
> running lisp you see in the REPL below".
>
> How does Slime handle that ?
>
> Thanks in advance for your answers, (I'm not an experience emacs/slime
> user, so feedback welcome !)
>
> --
> Laurent
>
> On 16 jan, 19:31, Allen Rohner  wrote:
>   
>> On Jan 16, 9:32 am, Peter Wolf  wrote:
>>
>>
>>
>> 
>>> Hello, and thanks for all the help with the IntelliJ plugin.
>>>   
>>> The next feature I want to implement is "references".  That is, one
>>> selects a symbol, and then can go to the location where that symbol was
>>> defined (e.g. def, defn, let, etc.).  One can also get a list of all the
>>> locations where that symbol is referenced.  This feature is very nice
>>> for navigating code, and is also the core of many automatic refactorings
>>> (e.g. "rename").
>>>   
>>> Implementing references are pretty straightforward in a static language
>>> like Java, were all the references are resolved at compile time.  
>>> However, in a language like Clojure some references get resolved at run
>>> time.
>>>   
>>> How do other IDEs handle this?  Is there a recommended set of rules for
>>> what references can and can not be resolved by the editor?  How does one
>>> detect a possible non-static reference, or how does one ensure that a
>>> reference will always refer to the same location?
>>>   
>>> Note that I need a 100% reliable solution, if I am going to implement
>>> automatic refactoring on top of it.  No one wants refactoring that
>>> messes up the code 5% of the time.
>>>   
>>> Thanks
>>> Peter
>>>   
>> I haven't been following the IntelliJ plugin. Does it use slime? SLIME
>> + Lisp has had a solution for this for years by directly asking the
>> running lisp process. The high level description is that the process
>> keeps track of all of the functions it has loaded/compiled, and the
>> list of functions each of those functions calls. Then to find out who
>> calls foo, you just ask the process. The answer is pretty reliable and
>> doesn't require writing your own parser. Of course, it too can't deal
>> with eval'ing and identifiers in XML, but I'm not sure that anything
>> can.
>>
>> I've been toying with the idea of implementing this in clojure.
>>
>> Allen
>>
>> It would be fairly straightforward to modify the running clojure
>> 
> >
>
>   


--~--~-~--~~~---~--~~
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
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: How to implement "go to definition" and "find all references"

[Peter Wolf]

Actually, the observation below might be really good news.  Does it 
means that all references are resolved at compile time?  Do I ever have 
to run the code to figure out the context of a reference?  Or, does the 
lexical context give me all the information I need?

I have already reimplemented the Clojure parser to do the syntax 
checking, folding and brace matching.  Reimplementing references might 
not be so bad.

In brief, I parse the Clojure program into a tree structure (of 
course).  Defs, defns, lets etc are all nodes on this tree.  Symbols are 
leafs.  The nodes in the tree are sorted by the order the text appeared 
in the file.  Used code from other files is treated as being textually 
inserted.

Can I always resolve a reference by walking back up the tree.  Walk back 
at the current level, if not found, go up a level and walk back, repeat.

Thanks
P
> Remember, Clojure is a compiler, not an interpreter.   The compiler
> doesn't remember syntax.  There is no "running image" in the Smalltalk
> sense.
>
> So the 100% perfect refactoring you have in mind may not be possible
> without reimplementing a large portion of Clojure itself.
>
> -Stuart Sierra
> >
>
>   


--~--~-~--~~~---~--~~
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
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: How to implement "go to definition" and "find all references"

[Peter Wolf]

Hi Laurent

I think much of the parser, such as the JFlex lexer is certainly 
reusable.  The recursive descent parser outputs Intellij objects, but 
with pretty minor changes could be made reuseable. 

Please feel free to take anything you want.

http://code.google.com/p/clojure-intellij-plugin/source/browse/


lpetit wrote:
> Hello Peter,
>
> As I understand, you've made what I also began to make for clojuredev
> (clojure dev environment for eclipse me and other folks are working on
> on our spare time) : a static source code parser. Mine is currently
> not very tested (and maybe not very usefull as is, because it has not
> yet be faced to real-world problem).
>
> Do you think it could be possible to reuse your parser for the needs
> of clojuredev , or is it too tied to the intelliJ framework/
> infrastructure ?
>
> Thanks in advance,
>
> --
> Laurent
>
> On Jan 17, 2:40 pm, Peter Wolf  wrote:
>   
>> Actually, the observation below might be really good news.  Does it
>> means that all references are resolved at compile time?  Do I ever have
>> to run the code to figure out the context of a reference?  Or, does the
>> lexical context give me all the information I need?
>>
>> I have already reimplemented the Clojure parser to do the syntax
>> checking, folding and brace matching.  Reimplementing references might
>> not be so bad.
>>
>> In brief, I parse the Clojure program into a tree structure (of
>> course).  Defs, defns, lets etc are all nodes on this tree.  Symbols are
>> leafs.  The nodes in the tree are sorted by the order the text appeared
>> in the file.  Used code from other files is treated as being textually
>> inserted.
>>
>> Can I always resolve a reference by walking back up the tree.  Walk back
>> at the current level, if not found, go up a level and walk back, repeat.
>>
>> Thanks
>> P
>>
>> 
>>> Remember, Clojure is a compiler, not an interpreter.   The compiler
>>> doesn't remember syntax.  There is no "running image" in the Smalltalk
>>> sense.
>>>   
>>> So the 100% perfect refactoring you have in mind may not be possible
>>> without reimplementing a large portion of Clojure itself.
>>>   
>>> -Stuart Sierra
>>>   
> >
>
>   


--~--~-~--~~~---~--~~
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
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: How to implement "go to definition" and "find all references"

[Peter Wolf]

Excellent!

How is the Clojure compiler tested?  Is there a set Clojure code that 
serves as Unit tests?  I need something with all the corner cases both 
for syntax and references.

Thanks
P

Stephen C. Gilardi wrote:
>
> On Jan 17, 2009, at 8:40 AM, Peter Wolf wrote:
>
>> Actually, the observation below might be really good news.  Does it
>> means that all references are resolved at compile time?  Do I ever have
>> to run the code to figure out the context of a reference?  Or, does the
>> lexical context give me all the information I need?
>
> My understanding is that all references are resolved at compile time. 
> It's one of the design choices that helps make Clojure fast.
>
> --Steve
>


--~--~-~--~~~---~--~~
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
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: Common backend project?

[Peter Wolf]

Sure, good idea.  I'm in!

As a first cut, I think we need to separate those tools written in JVM 
languages (Clojure/Java) and those written in something else.

I certainly think the JVM based projects can, and should, share 
components.  BTW the most important JVM project is Clojure itself.  The 
tools should share as much as possible with the Clojure core sources.

Tools such as SLIME and (I think) Gorilla, on the other hand, are not 
written in language that makes sharing easy.

However, I would be very much in favor of a common test set.  A 
collection of Clojure code that can be used to test tools, and ensure 
common behavior.  These would be useful for all tools written in all 
languages.

My 2 cents
P


Meikel Brandmeyer wrote:
> Hi,
>
> Am 17.01.2009 um 16:22 schrieb Peter Wolf:
>
>> I think much of the parser, such as the JFlex lexer is certainly
>> reusable.  The recursive descent parser outputs Intellij objects, but
>> with pretty minor changes could be made reuseable.
>>
>> Please feel free to take anything you want.
>>
>> http://code.google.com/p/clojure-intellij-plugin/source/browse/
>
> There is lots of such things going at the moment.
>
> - Enclojure
> - Clojuredev
> - the IntelliJ Plugin
> - the swank/SLIME/emacs thingy
> - my Vim Gorilla
>
> Is there some interest to bundle the efforts?
>
> I'm thinking about a project, which provides such common
> things, like the Parser mentioned above. Or Chouser's or
> cgrand's javadoc. Everything in a neutral way, so that the
> specific frontend projects just provide the interface to the
> IDE in question and use the same backend functions.
>
> This would allow a faster development for the different
> platforms, since re-inventing the wheel is not necessary.
>
> I don't know the requirements of the different platforms,
> let alone how to implement all the features like refactoring
> and stuff. So I don't even know, whether this is possible
> or not.
>
> So what do you think?
>
> Sincerely
> Meikel
>


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

File, Line Number and Usage Info

[Peter Wolf]

Here's a dumb question which has been answered before... but I can't 
find it in the docs.

How does one find out the file and line number upon which a symbol was 
defined?  I want to use it for "go-to-defintion" in the IntelliJ plugin.

Also, is there any way to find all the code that is referencing a 
symbol?  I need that to implement "find-usages", "rename" and "move".

Thanks
Peter

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

Calling Clojure from Java (again)

[Peter Wolf]

This is a rejuvenation of the old "calling Java from Clojure" thread

I have been looking at the solutions from Mark
/
   1) From a Java application, read a text file containing Clojure code
   and invoke specific functions it defines from Java code.
   2) Compile Clojure code to bytecode and use it from a Java application
   just like any other Java code.

   An example of the first option is provided at
   
http://markmail.org/message/tx23zaxf77b6widh#query:%22calling%20Clojure%22%20%22from%20Java%22+page:1+mid:tx23zaxf77b6widh+state:results.
 

  /   

and Stuart
/
   Here's how I do it:

   import clojure.lang.RT;
   import clojure.lang.Var;
   ...
   RT.loadResourceScript("source/file/on/classpath/here.clj");
   Var myfunction = RT.var("my-namespace", "my-function");
   myfunction.invoke("arg 1", "arg 2", ...); /


Where is the documentation on this Java API?  In particular, all these 
functions seem to side-effect a single Clojure image.

Can I create several disjoint images?  Can I stop or destroy an image 
that has run amok? 

I want to use this for the IntelliJ plugin, and I don't want bogus user 
code to clobber the IDE.  I also want the defined symbols for a file to 
be a function just of the code in that file, not all the files that 
happen to be loaded by the IDE at the moment.  How does Swank handle this?

Thanks
Peter

--~--~-~--~~~---~--~~
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
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: File, Line Number and Usage Info

[Peter Wolf]

Ooops!  How embarrassing <:-(

Yes, that's exactly what I am doing.  It did not occur to me that there 
is extra information embedded in the reply that marks it as being part 
of a thread.

Sorry, won't happen again
P

lpetit wrote:
> Peter,
>
> A weird thing seems to happen often those days, and I have remarked
> it's related to you.
>
> You start a new post, but it appears to be in the continuation of a
> previous one, with the subject changed.
>
> This does not look good to me. Are you doing something like this to
> start a new post : "open the last e-mail received by the ml, click on
> reply, change the subject, throw the body out and replace it by my
> own ?"
>
> If so, then please consider creating a new e-mail each time you start
> a new subject ?
> If not so, then your mailer may have a problem with googlegroups ?
> Regards,
>
> --
> Laurent
>
> On 22 jan, 19:20, Peter Wolf  wrote:
>   
>> Here's a dumb question which has been answered before... but I can't
>> find it in the docs.
>>
>> How does one find out the file and line number upon which a symbol was
>> defined?  I want to use it for "go-to-defintion" in the IntelliJ plugin.
>>
>> Also, is there any way to find all the code that is referencing a
>> symbol?  I need that to implement "find-usages", "rename" and "move".
>>
>> Thanks
>> Peter
>> 
> >
>
>   


--~--~-~--~~~---~--~~
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
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: Calling Clojure from Java (again)

[Peter Wolf]

Thanks for the lengthy reply Laurent,  Replies in-line

lpetit wrote:
> Peter,
>
> We asked us the same question some weeks ago, on clojuredev.
>
> We took the path to follow how eclipse launches a java application
> when the user requires it to test it.
> So we created a customized "launch configuration" (sorry, eclipse
> jargon), that is just a classical eclipse java launcher with some
> options predefined.
>   
Yes, this is exactly what I do also, and it is even called a 
"configuration" in IntelliJ
> To enable the user work against the clojure version he wants, we
> require him to have clojure library as a standard library dependency
> on the classpath of his eclipse project.
>
> I think you could do quite the same thing for IntelliJ.
>
> We did that because of several reasons :
>
> - we wanted the user to be able use his own version of clojure, not an
> imposed one
> - we wanted the user to be able to have several clojures running at
> the same time
> - we absolutely wanted to prevent the user run his code in the eclipse
> VM !
> - we wanted regular eclipse users to feel at home with clojuredev,
> having in mind that having a smooth migration path from java to
> clojure, first by just incorporating bits of clojure in a (n already
> existing) java project codebase, could be a good thing.
>   
Yep.  Same solution, same reasons.
> So we took the road you described by quoting Stuart. We call a "bridge
> function" that takes strings and returns strings (or core clojure
> datastructures : maps, vectors, strings, keys, java.lang basic types).
>
> This bridge function runs on the eclipse JVM, and calls a server we
> systematically install in the remote JVM when the user launches his
> project.
>
> The code for the client part is here :
> http://code.google.com/p/clojure-dev/source/browse/clojuredev/trunk/src/clojuredev/debug/clientrepl.clj
> The code for the server part is here :
> http://code.google.com/p/clojure-dev/source/browse/clojuredev/trunk/src/clojuredev/debug/serverrepl.clj
> (and yes, it's yet another variation on the repl over socket)
>
>   
Thanks, I shall take a look at this.

However, if there is only one Clojure image used for references and the 
like, what happens if someone calls an infinite loop, or infinite 
recursion, in a file.  Does the Clojure server hang/blow up?  How do you 
detect it/protect from it?

For example, I was using the SmallSnake code for testing, and when that 
file is loaded, it pops up a window and runs a process forever.  I don't 
want that to happen, just because someone included that file in their 
IntelliJ project.

This must be a problem common to all Swank based IDEs.  What is the 
"Clojure way" here?

--~--~-~--~~~---~--~~
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
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: Calling Clojure from Java (again)

[Peter Wolf]

Hi Laurent,

My questions and current beliefs are:

1) Does Eclipse use the server for resolving references?
2) Is the server visible to the user, or hidden inside Eclipse?
3) Does the server call load-file?
4) Can the user break the server with bogus code in a file?
5) What happens if a file has top level code that pops up a 
window/starts a process?
6) How does the user know when the server is broken?

Thanks, this is very helpful to me
P


... skipping the top

>>> This bridge function runs on the eclipse JVM, and calls a server we
>>> systematically install in the remote JVM when the user launches his
>>> project.
>>>   
>>> The code for the client part is here :
>>> http://code.google.com/p/clojure-dev/source/browse/clojuredev/trunk/s...
>>> The code for the server part is here :
>>> http://code.google.com/p/clojure-dev/source/browse/clojuredev/trunk/s...
>>> (and yes, it's yet another variation on the repl over socket)
>>>   
>> Thanks, I shall take a look at this.
>>
>> However, if there is only one Clojure image used for references and the
>> like, what happens if someone calls an infinite loop, or infinite
>> recursion, in a file.  Does the Clojure server hang/blow up?  How do you
>> detect it/protect from it?
>> 
>
> No, currently, clojuredev's dynamism is tied to an existing (and
> visible via its REPL console) launched configuration.
> It is this configuration that is used.
>
> So the user has only access to the launched JVM, and if he breaks it,
> then he just has to click on the "stop VM" button on the classic
> console view.
>
> Was that your question ?
>
>   
>> For example, I was using the SmallSnake code for testing, and when that
>> file is loaded, it pops up a window and runs a process forever.  I don't
>> want that to happen, just because someone included that file in their
>> IntelliJ project.
>>
>> This must be a problem common to all Swank based IDEs.  What is the
>> "Clojure way" here?
>> 
> >
>
>   


--~--~-~--~~~---~--~~
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
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: Calling Clojure from Java (again)

[Peter Wolf]

Thanks for the explanation Stuart,

So it seems that all the Swank Clojure IDEs rely on files only 
containing "safe" code.  I guess that's OK provided everyone understands 
this.

Is is any way to only process the def's?  For example processing the 
following would only define the symbol "foo", but not call it.

(defn foo [message]
(pop-up-window message))

(foo "Hi Mom!")

If so, I could do references safely.

P


Stuart Sierra wrote:
> On Jan 22, 6:51 pm, Peter Wolf  wrote:
>   
>> However, if there is only one Clojure image used for references and the
>> like, what happens if someone calls an infinite loop, or infinite
>> recursion, in a file.  Does the Clojure server hang/blow up?  
>> 
>
> If you code an infinite loop, the SWANK server will run an infinite
> loop. The only solution is to kill off the Java process. If you wanted
> to get clever, you could load the file in a separate thread and just
> kill off that thread.
>
>   
>> For example, I was using the SmallSnake code for testing, and when that
>> file is loaded, it pops up a window and runs a process forever.  
>> 
>
>  That's an unfortunate side effect of using Clojure as a scripting
> language like Perl or Python. Perhaps it would be more proper for the
> distributed file to define a function that will run the application.
>
> -Stuart Sierra
> >
>
>   


--~--~-~--~~~---~--~~
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
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: Basic about setting upp Clojure and editor enviroment

[Peter Wolf]

Or try the IntelliJ plugin, if you like that IDE

http://code.google.com/p/clojure-intellij-plugin/

It works fine on Windows and Linux.  We are currently fixing the Mac.

P


Matt Clark wrote:
> If you're not already an emacs user, I found it can be quite the
> learning curve getting into it.  So I'd recommend you also give the
> eclipse clojure-dev plugin a shot. It now has a REPL, namespace
> browser, syntax highlighting, etc and works fine on windows.
> http://code.google.com/p/clojure-dev/
>
> On Jan 21, 10:05 am, anderspe  wrote:
>   
>> Hello, i am waiting for the book "Programming Clojure" by Stuart
>> Halloway,
>> I have set upp a enviroment that i can run a REPL and
>> load script.
>>
>> But i am looking for som basic info about sett upp interaction
>> to a editor, EMACS or...
>>
>> I have tryed Plugin to Netbeans but it was Alpha and have
>> som problem running Windows.
>>
>> Tutorials, Links, tips would be nice
>>
>> // Anders
>> 
> >
>
>   


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

evalOnlyDefs

[Peter Wolf]

Looking for opinions from Clojure internals Wizards...

I am thinking about "safe loading" for IDEs (see other thread).  IDEs 
need a way to load and resolve code, without calling script code that 
might be in the file.

I was looking the code called by load-file and load.  Here is 
Compiler.eval()



public static Object eval(Object form) throws Exception{
boolean createdLoader = false;
if(!LOADER.isBound())
{
Var.pushThreadBindings(RT.map(LOADER, RT.makeClassLoader()));
createdLoader = true;
}
try
{
if(form instanceof IPersistentCollection
   && !(RT.first(form) instanceof Symbol
&& ((Symbol) RT.first(form)).name.startsWith("def")))
{
FnExpr fexpr = (FnExpr) analyze(C.EXPRESSION,
RT.list(FN, PersistentVector.EMPTY, form), "eval");
IFn fn = (IFn) fexpr.eval();
return fn.invoke();
}
else
{
Expr expr = analyze(C.EVAL, form);
return expr.eval();
}
}
catch(Throwable e)
{
if(!(e instanceof CompilerException))
throw new CompilerException((String) SOURCE.get(),
(Integer) LINE.get(), e);
else
throw (CompilerException) e;
}
finally
{
if(createdLoader)
Var.popThreadBindings();
}
}

I notice that it already checks for def being the first of the form, and 
does something different in that case.  How do Wizards feel about adding 
evalOnlyDefs() like below, to be called by load-file-only-defs to be 
used by IDEs.  Would this do the right thing?

public static Object evalOnlyDefs(Object form) throws Exception{
boolean createdLoader = false;
if(!LOADER.isBound())
{
Var.pushThreadBindings(RT.map(LOADER, RT.makeClassLoader()));
createdLoader = true;
}
try
{
if(form instanceof IPersistentCollection
   && !(RT.first(form) instanceof Symbol
&& ((Symbol) RT.first(form)).name.startsWith("def")))
{
FnExpr fexpr = (FnExpr) analyze(C.EXPRESSION,
RT.list(FN, PersistentVector.EMPTY, form), "eval");
IFn fn = (IFn) fexpr.eval();
return fn.invoke();
}
}
catch(Throwable e)
{
if(!(e instanceof CompilerException))
throw new CompilerException((String) SOURCE.get(),
(Integer) LINE.get(), e);
else
throw (CompilerException) e;
}
finally
{
if(createdLoader)
Var.popThreadBindings();
}
}


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

IntelliJ Plugin Pre-Alpha 0.03 Available

[Peter Wolf]

For those who like IntelliJ, a new version of the plugin is available.  
This one has numerous fixes, but is mostly interesting because the 
Debugger and Profiler work (or at least JProfiler). 

The Debugger and Profiler currently treat Clojure as compiled Java, and 
don't know how to go from byte code location to source code.  But there 
is enough information that one can figure out what is going on.

Note that Mac users still have to build it themselves.  If someone would 
build it, so we can post a Mac jar that would be great.

http://code.google.com/p/clojure-intellij-plugin/

Enjoy!
P



--~--~-~--~~~---~--~~
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
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: IntelliJ Plugin Pre-Alpha 0.03 Available

[Peter Wolf]

You are more than welcome.  Enjoy!

I am interested that it works on your Mac.  Others have reported 
problems (but not with this particular JAR).  What version of Mac and 
IntelliJ are you using?

Peter


Francesco Bellomi wrote:
> I installed it and it works really well,
> -- thanks to the authors for their work.
>
> btw, I installed it directly on my mac, without building it.
>
> Francesco
>
> On Jan 23, 6:08 pm, Peter Wolf  wrote:
>   
>> For those who like IntelliJ, a new version of the plugin is available.  
>> This one has numerous fixes, but is mostly interesting because the
>> Debugger and Profiler work (or at least JProfiler).
>>
>> The Debugger and Profiler currently treat Clojure as compiled Java, and
>> don't know how to go from byte code location to source code.  But there
>> is enough information that one can figure out what is going on.
>>
>> Note that Mac users still have to build it themselves.  If someone would
>> build it, so we can post a Mac jar that would be great.
>>
>> http://code.google.com/p/clojure-intellij-plugin/
>>
>> Enjoy!
>> P
>> 
> >
>
>   


--~--~-~--~~~---~--~~
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
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: IntelliJ Plugin Pre-Alpha 0.03 Available

[Peter Wolf]

By request...

Here some screenshots showing the IntelliJ Plugin in action

http://code.google.com/p/clojure-intellij-plugin/wiki/PageName?ts=1232979185&updated=PageName

Enjoy
Peter


Laurent PETIT wrote:
> Hello,
>
> Could you place some screenshots in a wiki page ?
>
> I'm too lazy to install IntelliJ yet, but maybe with some appealing 
> screenshots I could change my mind ;-)
>
>
> Thanks,
>
> -- 
> Laurent
>
> 2009/1/23 Peter Wolf mailto:opus...@gmail.com>>
>
>
> For those who like IntelliJ, a new version of the plugin is available.
> This one has numerous fixes, but is mostly interesting because the
> Debugger and Profiler work (or at least JProfiler).
>
> The Debugger and Profiler currently treat Clojure as compiled
> Java, and
> don't know how to go from byte code location to source code.  But
> there
> is enough information that one can figure out what is going on.
>
> Note that Mac users still have to build it themselves.  If someone
> would
> build it, so we can post a Mac jar that would be great.
>
> http://code.google.com/p/clojure-intellij-plugin/
>
> Enjoy!
> P
>
>
>
>
>
>
> >


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

Length of Sequence

[Peter Wolf]

Here's a dumb question, but I can't find it in the docs:

How do I get the length of a sequence?  Is there some generic way to 
find the number of elements in something that might be list, map, vector 
or lazy?

There must be some sort of built in function, or an idiom

Thanks
P

--~--~-~--~~~---~--~~
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
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: Length of Sequence

[Peter Wolf]

Thanks guys!  I knew I could 'count' on you ;-)

Chouser wrote:
> On Wed, Jan 28, 2009 at 2:15 PM, Peter Wolf  wrote:
>   
>> How do I get the length of a sequence?  Is there some generic way to
>> find the number of elements in something that might be list, map, vector
>> or lazy?
>> 
>
> user=> (doc count)
> -
> clojure.core/count
> ([coll])
>   Returns the number of items in the collection. (count nil) returns
>   0.  Also works on strings, arrays, and Java Collections and Maps
>
> Note how the name and docs both cleverly avoid use of the words "size"
> or "length", to help the function remain undiscovered by searches
> through the source code and by uses of find-doc.
>
> --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
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: Length of Sequence

[Peter Wolf]

How about this?  Needlessly wordy to make it more search-able...

clojure.core/count
([coll])
  Returns the length of a list or vector, the number of keys in a map, 
the size of a string, or the number of items in a sequence or 
collection.  (count nil) returns 0.  Also works on Java Collections and 
Maps.


Rich Hickey wrote:
>
> On Jan 28, 2:19 pm, Chouser  wrote:
>   
>> On Wed, Jan 28, 2009 at 2:15 PM, Peter Wolf  wrote:
>>
>> 
>>> How do I get the length of a sequence?  Is there some generic way to
>>> find the number of elements in something that might be list, map, vector
>>> or lazy?
>>>   
>> user=> (doc count)
>> -
>> clojure.core/count
>> ([coll])
>>   Returns the number of items in the collection. (count nil) returns
>>   0.  Also works on strings, arrays, and Java Collections and Maps
>>
>> Note how the name and docs both cleverly avoid use of the words "size"
>> or "length", to help the function remain undiscovered by searches
>> through the source code and by uses of find-doc.
>>
>> 
>
> Patch welcome for this - could mention it returns the length of
> strings and arrays and the size of Java collections.
>
> 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
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: What profilers are you using?

[Peter Wolf]

Hi Sergio,

I have been using JProfiler with the IntelliJ Clojure plugin.  The 
combination seems to work fine, except that JProfiler does not know how 
to display Clojure source code associated with a function.  However, 
there is enough information displayed that you can do it trivially.

Peter

Sergio wrote:
> I have been trying out the YourKit profiler and I think it's great.
> However, my evaluation license is going to expire soon and being a
> student I can't purchase (even the academic) license right now.
>
> I have tried profiler4j and it is usable but it isn't working 100%
> right with clojure (in my case). Jrat (http://jrat.sourceforge.net/)
> seems promising as well as JIP (http://jiprof.sourceforge.net/) (the
> fact that it outputs text means that there could be easy integration
> with Emacs with some Elisp code), but I haven't tried them yet.
> Nothing I have checked out seems as nice as YourKit, although those
> two I mentioned appear to get close.
> Again, I haven't tried them. I am going to, and they would probably
> meet my needs perfectly, but still.. If anyone knows of something
> better or has any recommendations/opinions they could share, please
> do. 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
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
-~--~~~~--~~--~--~---

IntelliJ Plugin -- Wonderful News!

[Peter Wolf]

Check out this email!  IntelliJ is going to get a *really* good plugin 
for Clojure :-D

I have gladly turned control of the my plugin over to Ilya, and the code 
has been moved to the JetBrains SVN.  I will remain involved and fix 
bugs as they are found, but Ilya and his team are adding a real test 
suite, Mac support, and implementing things like the debugger that are 
not currently documented. 

I notice that Ilya has already added lots of new stuff, I am trying it now.

There is not an release yet, but here is the new code location if you 
want to build it yourself.

http://svn.jetbrains.org/idea/Trunk/clojure-plugin

Enjoy (Greatly)
Peter


Hello, Peter.

I'm going to develop plugin for IntelliJ IDEA for Clojure language.
Talking with Rich I knew about your plugin, which already has parser
and several nice features, based on it withou Program Structure
Interface. To not duplicate code I would like to suggest you to move
your source into JetBrains source repository and continue working on
plugin together. Of course, Clojure plugin will stay open-source
project. Moreover we already have off-the shelf process to build
such projects and perform continuous integartion using our
buildserver TeamCity.
As you might know, I was developing Groovy plugin (wich you took as
a base for your) for two years and now I lead development of Scala
plugin. Main feature of all of them is full interoperability with
main Java support, so I would like to keep it for Clojure too.
So, what do you think about this cooperation? If you agree I'll
submit existing code to our repository and provide commit rights for
you.

With best regards,
Ilya


--~--~-~--~~~---~--~~
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
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 Maps and Java Maps

[Peter Wolf]

Hello, how do I do this elegantly?

I have a Clojure Map  = {:foo "foo" :bah 3 ... }

and I need to pass it to a Java method that is expecting a 
Map = { "foo" --> "foo" , "bah" --> 3 ...}

How does one convert a Clojure Map to the equivalent Java Map?  I bet I 
could do it in one line if I knew the magic.

Thanks
Peter

--~--~-~--~~~---~--~~
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
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: IntelliJ Plugin -- Wonderful News!

[Peter Wolf]

I am using IDEA 9164.  Make sure idea.jar is on your classpath (it is 
not part of the Development SDK).

BTW to original plugin is still available pre-built.  It works fine on 
Linux and Windows.  See

http://code.google.com/p/clojure-intellij-plugin/




Howard Lewis Ship wrote:
> I'm trying to build this locally; I haven't built an IDEA plugin before.
>
> Anyway, I've downloaded the 8.0.1 dev kit and installed it, but class
> com.intellij.openapi.module.JavaModuleType doesn't exist, although
> this a JAR with other classes from that package.
>
> I must have the wrong version of the dev kit; what's the correct
> version to be using?
>
> Thanks,
>
> Howard
>
>
> On Fri, Feb 6, 2009 at 7:53 AM, Tom Ayerst  wrote:
>   
>> That is excellent news.  Now I just to learn enough Clojure to properly
>> contribute to a pukka open Source project so I can get a free copy ;-)
>>
>> 2009/2/6 Peter Wolf 
>> 
>>> Check out this email!  IntelliJ is going to get a *really* good plugin
>>> for Clojure :-D
>>>
>>> I have gladly turned control of the my plugin over to Ilya, and the code
>>> has been moved to the JetBrains SVN.  I will remain involved and fix
>>> bugs as they are found, but Ilya and his team are adding a real test
>>> suite, Mac support, and implementing things like the debugger that are
>>> not currently documented.
>>>
>>> I notice that Ilya has already added lots of new stuff, I am trying it
>>> now.
>>>
>>> There is not an release yet, but here is the new code location if you
>>> want to build it yourself.
>>>
>>> http://svn.jetbrains.org/idea/Trunk/clojure-plugin
>>>
>>> Enjoy (Greatly)
>>> Peter
>>>
>>>
>>>Hello, Peter.
>>>
>>>I'm going to develop plugin for IntelliJ IDEA for Clojure language.
>>>Talking with Rich I knew about your plugin, which already has parser
>>>and several nice features, based on it withou Program Structure
>>>Interface. To not duplicate code I would like to suggest you to move
>>>your source into JetBrains source repository and continue working on
>>>plugin together. Of course, Clojure plugin will stay open-source
>>>project. Moreover we already have off-the shelf process to build
>>>such projects and perform continuous integartion using our
>>>buildserver TeamCity.
>>>As you might know, I was developing Groovy plugin (wich you took as
>>>a base for your) for two years and now I lead development of Scala
>>>plugin. Main feature of all of them is full interoperability with
>>>main Java support, so I would like to keep it for Clojure too.
>>>So, what do you think about this cooperation? If you agree I'll
>>>submit existing code to our repository and provide commit rights for
>>>you.
>>>
>>>With best regards,
>>>Ilya
>>>
>>>
>>>
>>>   
>> 
>
>
>
>   


--~--~-~--~~~---~--~~
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
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 plugin for IntelliJ IDEA published

[Peter Wolf]

Ah darn, scooped!

Yes.  This is wonderful news!

Thank you so much Ilya for turning the IntelliJ plugin into a real 
product.  You have made many of us very happy, and hopefully brought 
IntelliJ some new customers.

For Mac users, this version should now work :-D Please give it a try and 
report.

Thanks Ilya again,
Peter

Laurent PETIT wrote:
> Congratulations!
>
>
> 2009/2/24 Ilya Sergey mailto:ilyas...@gmail.com>>
>
> Hello, all!
>
> I'm happy to present alpha-version of official Clojure plugin for
> IntelliJ IDEA "La Clojure". It may be downloaded from
> http://plugins.intellij.net/plugin/?id=4050
>  
> List of implemented features for now looks as follows:
>
> 1. Customizable code highlighting
> 2. Code folding
> 3. Brace matching
> 4. Code formatting with customizable indentation
> 5. Structure view for definitions
> 6. Go-to definition feature (as go to symbol)
> 7. Code completion for definitions and special forms
> 8. Run configuration for Clojure scripts (both in REPL or as
> standalone script)
>
> Some hints about installation and usage:
>
> 1. Plugin demands for IntelliJ IDEA build #9100 or later. IDEA 8.1
> is perfect. Last EAPs may be downloaded from
> http://jetbrains.net/confluence/display/IDEADEV/Diana+EAP
> 2. To download plugin use IDEA Plugin Manager (see Settings ->
> Plugins -> Available) or unzip downloaded archive to
> $IDEA_SETTINGS/config/plugins/ folder
> 3. To create new Clojure file, just press Alt-Insret in Project
> View and choose "Clojure Script"
> 4. File template for Clojure scripta may be changed in Settings ->
> File Templates -> Java EE tab -> Clojure
> 5. To run your Clojure script you may create run configuration
> manually or press Ctrl-Shift-F10 (in Linux or Windows layout) on
> appropriate script file opened in editor. In latter case run
> configuration will be created automatically and script will be run
> immediately.
> 6. Structure view window may be invoked on file by pressing
> Ctrl-F12 (in Linux or Windows layout) or by View -> File Structure
> Popup action.
> 7. To navigate to definitions (def, defn, defmacro etc.) use Go-to
> symbol action.
>
> I'm going to describe all these hints and features in simple
> how-to manual.
> Our bugtracker is available at
> http://www.jetbrains.net/jira/browse/CLJ
> Any suggestions are highly appreciated.
>
> Many thanks to Peter Wolf and Kurt Christensen for their initiative.
>
> Kind regards,
> Ilya Sergey
> JetBrains Inc.
>
>
>
>
>
> >


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

"Adding" strings

[Peter Wolf]

Hey all,

What is the idiomatic way to concatenate strings?  Here are some things 
that I expected to work, but didn't

(+ "foo" "bah")
(conj "foo" "bah")
(into "foo" "bah")

For the moment I am doing

(.concat "foo" "bah")

But it seems wrong

Thanks
P



--~--~-~--~~~---~--~~
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
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: "Adding" strings

[Peter Wolf]

Thanks all.

I think appending a bunch of strings is a pretty common operation. 

Is there any reason that str is limited to 2 arguments?  It would be 
nice to do (str "foo" "bar" "baz") --> "foobarbaz".

Is there a good reason that + can't do the right thing as with other 
Java and scripting languages?  I think this would be popular with 
non-LISPers.

P



Laurent PETIT wrote:
> (str "foo" "bah")
>
> and if you have a collection you can (apply str coll)
>
> HTH,
>
> -- 
> Laurent
>
> 2009/2/26 Peter Wolf mailto:opus...@gmail.com>>
>
>
> Hey all,
>
> What is the idiomatic way to concatenate strings?  Here are some
> things
> that I expected to work, but didn't
>
>(+ "foo" "bah")
>(conj "foo" "bah")
>(into "foo" "bah")
>
> For the moment I am doing
>
>(.concat "foo" "bah")
>
> But it seems wrong
>
> Thanks
> P
>
>
>
>
>
>
> >


--~--~-~--~~~---~--~~
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
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: Mathy operations on non-numerics (was "Adding" strings)

[Peter Wolf]

OK had my coffee, and had several thoughts...

1 -- What are Strings?  How should the Clojure programmer think about 
them?  Are they sequences, in which case all the sequence functions 
should work.  Or are they atomic built-in types like Integers and Floats?

2 -- There is already some type checking in + to deal with Integers, 
Floats and infinite precision.  Line 1212 of Numbers.java has the ops() 
method which (I think) implements this

static Ops ops(Object x){
Class xc = x.getClass();

if(xc == Integer.class)
return INTEGER_OPS;
else if(xc == Double.class)
return DOUBLE_OPS;
else if(xc == Float.class)
return FLOAT_OPS;
else if(xc == BigInteger.class)
return BIGINTEGER_OPS;
else if(xc == Long.class)
return BIGINTEGER_OPS;
else if(xc == Ratio.class)
return RATIO_OPS;
else if(xc == BigDecimal.class)
return BIGDECIMAL_OPS;
else
return INTEGER_OPS;
}

3 -- Type hints can take the place of a fast-math library.  The compiler 
could automatically call the appropriate fast math routine when given 
the necessary information.

So my vote is that String are atomic built in objects, and at least +, < 
and > should work with Strings.  The behavior should be just like Java, 
so (+ "foo" 2) --> "foo2"

I don't think this will slow down math because the String case will be 
the last "else if" in ops() and will only happen when the args are not 
some sort of Number.

Finally, if it doesn't already, I would expect type hints to make things 
faster.  So, it should not be necessary to explicitly call a fast-math 
library.

My 2 n00by cents...
P



Phil Hagelberg wrote:
> Peter Wolf  writes:
>
>   
>> Is there a good reason that + can't do the right thing as with other 
>> Java and scripting languages?  I think this would be popular with 
>> non-LISPers.
>> 
>
> Putting a type check in + would slow down basic math, and there is a
> class of user who will complain loudly if basic math slows
> down. However, this also means that > and < also don't work on strings,
> which is pretty lousy.
>
> One approach that's been proposed in #clojure is to make these functions
> more capable by default, but then provide a fast-math library that could
> redefine them in terms of numerics-only. I'm a big fan of functions
> doing the most helpful thing by default but being able to offer better
> speed when you need it.
>
> Convenience vs speed is always a trade-off, but I think convenience
> should win in the default case. What do others think about 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
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: doall, dorun, doseq, for - Debugging as a side effect?

[Peter Wolf]

RE: Side Effects

What about logging?   Without a debugger I use lots of print's to debug 
my code... and that often produces confusing results as things may not 
get evaluated in the order I expect.

For that matter, now that we have integrated Java debuggers, what does 
setting a breakpoint really mean?  And what does it imply about the 
state of all the variables outside the current scope?

How do others think about debugging lazy code?

P

Laurent PETIT wrote:
> 2009/3/3 Mark Volkmann  >
>
>
> On Tue, Mar 3, 2009 at 9:12 AM, Laurent PETIT
> mailto:laurent.pe...@gmail.com>> wrote:
> > Hello Mark,
> >
> > Just one point :
> >
> > 2009/3/3 Mark Volkmann  >
> >>
> >> Does this seem like a good way to choose between doall, dorun,
> doseq
> >> and for to evaluate all the items in sequences?
> >>
> >> Ask these questions:
> >>
> >> Do you already have the lazy sequence in a variable or do you still
> >> need to build it?
> >> If you already have it, use dorun or doall. Otherwise use doseq
> or for.
> >> While code inside a dorun or doall could build the sequence, using
> >> doseq and for are considered more idiomatic/readable.
> >> Also, they provide list comprehension features such as
> processing more
> >> than one sequence and filtering with :when/:while.
> >>
> >> For example, instead of using the following to get a new sequence
> >> where all the items are multiplied by two:
> >> (doall (map #(* % 2) my-coll))
> >> use this:
> >> (for [item my-coll] (* item 2))
> >
> > I don't think it is a good example, since it conveys the idea
> that it could
> > be interesting to use doall or for for mapping a coll to
> multiply its items.
> > This example, in which there is no side effect at all in the
> inner loop, is
> > really typical of the use of map ! And forcing the sequence
> there gives you
> > nothing (?)
> >
> > Maybe a more interesting example could be something that touches
> global
> > vars, or does IO, ... ?
>
> Very good point! With what I'm doing, simply multiplying items by two,
> you'd want the result to be an unevaluated, lazy sequence which is why
> map would be preferred.
>
> But supposing I was doing something like you suggested where I really
> do want to force the evaluation of all the items in the sequence, do
> my rules of thumb make sense?
>
>
> I haven't thought really hard about it, what it written seems correct 
> to me.
>
> But I think the first point is a little bit dangerous without a side 
> note : "if you already have the seq, then call 'doall or 'dorun on it".
> Indeed, if you're dealing with a seq that is passed around, you may 
> end up calling dorun or doall on the seq in several places in the 
> code, which may lead to problems if you have side effects in them !
> So to prevent this risk : either the call to 'doall or 'dorun is 
> factorized, and it will certainly be factorized near the place where 
> the seq is generated (thus almost falling back to your second case 
> "you don't have generated the seq yet"), either you haven't side 
> effects at all, and you fall back to an idiomatic use of 'map or 
> another lazy-seq generating function, without the need to call 'doall 
> or 'dorun on them.
>
> HTH,
>
> -- 
> Laurent
>  
>
>
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
>
>
>
>
>
> >


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

Multimethods & derive

[Peter Salvi]

Hi,

I would like to use multimethods by dispatching on keys of the
variables (maps)
in a way that I sometimes have constraints on only some of the
arguments.

In common lisp I would say

(defgeneric foo (a b))
(defmethod foo ((a bar) b) ...)
(defmethod foo (a (b baz)) ...)
(defmethod foo ((a bar) (b baz)) ...)

This would mean that I have also defined methods for calls when (for
example)
`a' is an instance of `bar' and `b' of anything but `baz'. How can I
achieve
something like this with multimethods?

I could define a relationship like

(derive :bar :anything)
(derive :baz :anything)

and then do

(defmulti foo (fn [a b] [(:somekey1 a) (:somekey2 b)]))

with

(defmethod foo [:bar :anything] [a b] ...)
(defmethod foo [:anything :baz] [a b] ...)
(defmethod foo [:bar :baz] [a b] ...)

This seems to do the trick... but is this really the way to do it?

If it is, it would be very useful to have something that is the
ancestor of
everything (like T in common lisp).

Thanks,

Peter

--~--~-~--~~~---~--~~
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: Multimethods & derive

[Peter Salvi]

On Jun 8, 3:51 pm, Konrad Hinsen  wrote:

> See also my patch that creates such a universal root type [...]

Nice! That's exactly what I was thinking about

Peter

--~--~-~--~~~---~--~~
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: Java STM

[peter veentjer]

Hi Christian,

On Jul 13, 10:37 am, Christian Vest Hansen 
wrote:
> I believe that DeuceSTM i primarily intended as a research platform
> for Java STMs, hence the flexibility with pluggable algorithms.
>
> Another Java STM is multiverse:http://code.google.com/p/multiverse/-
> the focus here is on performance. Multiverse is based on MVCC, like
> the Clojure STM.
>
> Both of these STMs operates with the mindset that objects are mutable
> by default, and tries to control this mutability. Whereas in the world
> of Clojure we have mutable references pointing to immutable values. In
> fact, the correctness of the Clojure STM depends on the objects
> "stored" in the refs be immutable.

Multiverse also provides a ref programming model.

So you could say this:

@AtomicObject
class Person{
   private String name;

   public String getName(){return name;}

   public void setName(String newName){this.name = newName;}
}

Or using the ref programming model:

class Person{
private final Ref name = new Ref();

   public String getName(){return name.get();}

   public void setName(String newName){name.set(newName);}
}

If you have multiple fields and and a static language like Java,
the first approach programs better.

If a mutable reference is stores in the field the following things
could happen:
1) the object is not an atomicobject and you are left on your own. For
example a java.util.LinkedList stored in the ref.
The advantage of allowing 'unsafe' objects to be stored in the stm, is
that they can flow through the stm. Just like
a normal mutable object can flow through a
java.util.concurrent.BlockingQueue. But I'm certain that people are
going
to run into problems because they forget that the object is not
managed. Time will tell :)
2) the object is an atomic object and it will be managed by the stm as
well.

So something like this is no problem:

@AtomicObjec
class Person{Sttring name;...}

Ref parentRef = new Ref();

In this case the parent reference will be managed by the stm, but also
the content of the parent object itself.

A few other questions:

Does Clojure support the stm version of condition variables: retry and
orelse?

And since Clojure is using MVCC, does it also suffer from a broken
serialized isolation level?
http://pveentjer.wordpress.com/2008/10/04/breaking-oracle-serializable/

And what kind of performance do you get with clojure?

PS:
I think that Clojure really did a great job with adding STM to the
language. I have been working on multiverse for almost a year,
and I only have an stm. With Clojure the STM is one of the many
features provided.

> On Mon, Jul 13, 2009 at 2:07 AM, Vagif Verdi wrote:
>
> > Potentially interesting library for clojurians. Java STM
> > implementation:http://www.deucestm.org/
>
> --
> Venlig hilsen / Kind regards,
> Christian Vest Hansen.

--~--~-~--~~~---~--~~
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: Java STM

[peter veentjer]

> No. I don't want to use transactions for workflow. I don't want
> blocking transactions. I don't want read tracking.

With multiverse it depends on the engine being used and the settings
on the transaction. And readonly transactions also don't track reads.

> > And since Clojure is using MVCC, does it also suffer from a broken
> > serialized isolation 
> > level?http://pveentjer.wordpress.com/2008/10/04/breaking-oracle-serializable/
>
> Clojure doesn't promise any "serialized isolation level". It provides
> snapshot isolation, which is subject to write skew, as better
> described here:
>
> http://en.wikipedia.org/wiki/Snapshot_isolation
>
> In order to prevent write skew, Clojure provides the 'ensure'
> operation which can be used for reads to non-written refs that form
> part of the integrity promise of a transaction, without incurring that
> overhead all the time for reads that do not. I much prefer having this
> fine-grained choice.

I'll have a look at it.

>
> > And what kind of performance do you get with clojure?
>
> I'll let other people answer that from their experience, but only say
> that it is probably too general a question to be particularly
> meaningful.

True.

> Clojure's STM is part of a holistic language design where
> people will normally be programming with immutable persistent
> composite data structures. Getting a consistent view of such a data
> structure doesn't require a transaction at all, so that is much faster
> than other strategies. When 'changing' a data structure, you read it
> from the ref once and then structural changes do not involve the STM
> or refs. Store it back in the ref when done. Thus the granularity of
> transactions is coarse and the number of ref interactions involved
> small. These are not things you'll see when timing pounding an integer
> in a transactional ref in a tight loop, but matter greatly in
> practice, IMO.

I partly agree. One of my design guidelines is that one should not
have to pay
for what is not being used.

One of the things I'm focussing on is making the transaction
as fast as possible for any length. I'm working on a system that
advices the
creation of a transaction with the maximum number of attached objects.
I have
 a transaction optimised for a single attachment (5+M transactions/
second on a single core),
for a small number of attachments (so using an array to store attached
items to reduce object creation)
and one for a large number of attachments (so using an expensive
hashmap).
The later one also is going to get a parallel commit (so obtaining
locks/checking for
isolation problems.. and doing the write) to make effective use of the
cores and speed
up the commit of larger transactions.

So I'm working on all levels to make it as fast as possible and
pounding
on an intref is something that helps to find a subset of problem
areas. And if something
is fast enough, people don't try to work around it.. so it also helps
to reduce complexity imho.

But again, I think that clojure is doing a great job. You have a cool
language,
 a cool stm, an active community and a lot of exposure. So you are
where I
want to be :)

> Rich
> > PS:
> > I think that Clojure really did a great job with adding STM to the
> > language. I have been working on multiverse for almost a year,
> > and I only have an stm. With Clojure the STM is one of the many
> > features provided.
>
> > > On Mon, Jul 13, 2009 at 2:07 AM, Vagif Verdi wrote:
>
> > > > Potentially interesting library for clojurians. Java STM
> > > > implementation:http://www.deucestm.org/
>
> > > --
> > > Venlig hilsen / Kind regards,
> > > Christian Vest Hansen.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

N00B Java Question

[Peter Wolf]

Hi all,

Here is a N00B question, but I can not find the answer by Googling, or 
reading Stuart's book.  So, I assume that others will want to find this 
FAQ in the future.

I am calling legacy code, and I need to set the level on the Java Logger.

In Java it would look like this

   import java.util.logging.Logger
   import java.util.logging.Level

   Logger.getLogger("").setLevel(Level.WARNING)

What is the Clojure equivalent?  In particular, what is the equivalent 
of Level.WARNING?

Level.WARNING is a static field of Level, and is an instance of Level.  
There is no getter method.  I can't find anything about accessing static 
fields in the docs.

Thanks in advance
Peter

-- 
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: Question about Responsiveness of Garbage Collection

[Peter Schuller]

> It seems the consensus is that the slow responsiveness of Java apps is
> mostly due to an issue with Swing and how it is used rather than with
> garbage collection. That sounds very encouraging.

Determining whether the GC is responsible is pretty easy. Just runt
with -verbose:gc (or -XX:+PrintGC) and watch the pauses.

Unless your application has a very big heap I highly doubt GC is the problem.

Whenever it is, you also have several options. The default GC
selection in Sun's JVM is basically not at all catered to low-latency,
instead focusing on throughput.

Sun's JVM has the CMS collector which is targetted at limiting pauses
with large heaps, and there is the upcoming G1GC collector. Non-Sun
JVM:s have their own GC:s.

In general, when people make off-hand remarks blaming the GC for
random things, they are usually wrong and do not know what they are
talking about. Until someone shows they have specifically identified
the GC, I would take it with a grain of salt.

If you do have GC problems you can select things other than the
default collector. A potentially good starting point for CMS is:

 -XX:+UseConcMarkSweepGC \
-XX:+CMSIncrementalMode \
-XX:+CMSIncrementalPacing \
-XX:+PrintGCDetails \
-XX:+PrintGCTimeStamps \
-XX:+DisableExplicitGC \
-XX:+CMSParallelRemarkEnabled \
-XX:+TraceClassUnloading

And for G1GC:

 -XX:+UnlockExperimentalVMOptions \
 -XX:+UseG1GC \
 -XX:+DisableExplicitGC \
 -XX:MaxGCPauseMillis=10 \
 -XX:GCPauseIntervalMillis=20 \
 -XX:+G1ParallelRSetUpdatingEnabled \
 -XX:+G1ParallelRSetScanningEnabled \

Often you will also get better behavior by using appropriate -Xms/-Xmx
options. The above are just examples of course and not "the" way to do
it or anything.

The -XX:+DisableExplicitGC is because some software authors try to be
"smart" and insert System.gc() calls at "appropriate" points. They
tend to fail, so if you select a GC that actually does handle your
case with minimal pauses you also want to disable the artificially
induced full GC:s.

-- 
/ Peter Schuller
-- 
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: Exception handling functional style

[Peter Schuller]

> I am trying to figure out some systematic and clear way how to handle
> exceptions in clojure and their bubbling up through the call chain.
> Let me illustrate it on some code examples (not executable, just to show the
> principle).

One response touched on it briefly, but I'm not sure what problem
you're trying to solve. Usually, in the presence of exceptions, each
layer will be responsible for throwing an exception on error, and you
catch it at the level where it is appropriate. Use of exceptions for
error handling does not imply that you need to sprinkle catches all
over the place.

The annoying exception (no pun intended!) is when you want to convert
exceptions of some type to another at an API boundary, but I don't see
how you will avoid the need to convert error information if that is
what you want to do.

If you mean that your problem is one where the lower-level API uses
return codes because it cannot know whether a particular condition is
a failure condition, I suggest defining an API with an API which *can*
make that assumption, and call that. For example, suppose an HTTP
library provides a convenience function (get ...) which returns an
HTTP response of some kind. Suppose it throws exceptions on I/O errors
and the like. Suppose that in my application I am at a point where I
require an HTTP 200 status response back (any 4xx, 5xx or even 3xx is
an error condition for this particular application). If the HTTP
library does not provide some form of convenience method of expressing
this (such as :expect-status 200), I might define a function similar
to:

  (defn get-expecting [uri status-code]
(let [response (get uri)]
  (if )))

Now I can simply write (get-expecting uri 200) and have it be much
more readable.

In short it allows me to (1) only handle errors where I want to handle
them, rather than sprinkle code anywhere (be it catches or return code
checking) only for the purpose of propagating them up the call chain,
and (2) do so even when the underlying API does not throw exceptions
because it does not make sense for that particular API (such as
read-line).

-- 
/ Peter Schuller

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

Prepping clojure for packaging (was: Re: Clojure for system administration)

[Peter Schuller]

> I've been wondering about this.  The classpath issue seems like a
> major thorn in the side of the JVM, especially for Clojure and other

It seems to be that there are two problems here.

One problem is that there needs to be a convention for a clojure
"binary" that works consistently across platforms. I maintain the
clojure port in the FreeBSD port collection, and I install an
appropriate wrapper script such that you can in fact do:

   clojure myscript.clj

And have it "just work" without further ado.

This is something that I think needs to be made more consistent;
probably by having the clojure distribution ship with such a script
that works on all POSIX shells, and making it clear to packagers that
it is intended to be the standard way of invoking clojure.

The other issue is that of picking up libraries. Here scripting
languages like ruby/python/etc have a well-defined convention for
doing this, where you have certain system paths that are intended to
contain modules. The exact path will vary with platform (for example
as a function of whether you use pycentral, are on debian, freebsd,
redhat, etc).

I would suggest that clojure could have a concept of "site library
path" that would be the responsibility of packagers to set
appropriately (just like 'site-packages' for python) where .jar:s
would be automatically picked up. Alternatively there could be two
such paths; one for a path that gets automatically added to CLASSPATH
and one that gets automatically scanned for .jar files.

As a practical example, I envision that what for Python might be:

  /usr/local/python2.5/site-packages/X/Y/Z

Would for clojure be:

  /usr/local/clojure/site-jars

and

  /usr/local/clojure/site-classpath

What do people think about this? I think it's all about providing a
documented default method of finding libraries; packagers for
respective platforms will then follow suit, I think.

This also makes it much easier to start packaging clojure libraries in
respective platform's packaging systems, where they can install .jar:s
in the appropriate place using common infrastructure shared across all
clojure packages.

So in short: Defining some semantics and interfaces that make sense
from the perspective of debian/freebsd/redhat/whatever package
management, I think is likely to result in a  more consistent end-user
experience once package maintainers start picking this up, just like
the case is with Python and Ruby.

I'd be interested in looking into getting some kind of draft
implementation of this, if people think it's a good idea (though I
can't make time commitments - busy busy busy).

-- 
/ Peter Schuller

-- 
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: Prepping clojure for packaging (was: Re: Clojure for system administration)

[Peter Schuller]

> My extremely biased opinion:  Clojure is not a scripting language.

One can spent a lot of time debating the definition of 'scripting
language', but sure. The bigger issue though:

> The "binary" is java.  System-wide classpaths are a bad idea.

In theory I agree with you. The concept of site-local (system wide)
python paths, ruby library paths, and linker paths for C, are horribly
and completely broken. (It is somewhat acceptable in the case of
native libraries since they map to the underlying platform and
performance optimizations such as read-only mmap:ing apply, and there
is a system in place for versioning.)

Unfortunately, because of the practical reality that the vast majority
of the software that needs packaging for a platform are written in
languages and using tools that make prohibitively problematic to try
to coerce this set of arbitrary software into a world view where the
system-wide stuff does not exist, all major packaging systems (debian
packages, rpms AFAIK, freebsd ports, pkgsrc, etc) operate under the
assumption that this is how you package software.

What this means is that there tends to be a pre-existing
infrastructure to handle packages that install files in some
particular system-global location. Coercing a packaging system to
handle a situation where the same software can be installed in
multiple versions and appropriately selected by some particular
version of some software that depends on other software, is
problematic.

I suspect that a key feature of clojure that has contributed to it's
very promising level of popularity and use, is that it is
comparatively easy to get going writing real software with it, and the
fact that things that "should" be available, *are* available (in the
form of Java libraries to some extent, but also largely due to being
based on the JVM).

I submit that adopting something similar to python's/ruby's system of
loading code may be conducive to lowering the barrier of entry and
increasing acceptance of Clojure as a platform to build on.

As a developer, I have no problem with using leinigen for example
(it's great!). But while an executable uberjar is extremely
convenient, it does not tie into the packaging system of a platform
(and there may be licensing issues with e.g. GPL libraries and
re-distribution of uberjars).

As a system administrator, you want to maintain some number of systems
in some consistent fashion. This includes having a set of software
that is supported, upgraded and maintained using a consistent tool
set. Python and Ruby applications are well-behaved from this
perspective. Clojure is not. This is why, even though Ruby has gems
for example, there are still ports of specific ruby gems at specific
versions in the FreeBSD ports tree - because that means they are
suddenly integrated into the platform's packaging system. The fact
that a random user can "gem install XXX" does not obviate the need for
such integration. All forms of change management tend to be difficult,
and software installation is a form of (particularly complicated)
change management, assuming you need to keep stuff up-to-date.

As a user, you want to use some piece of software without spending
time figuring details out that should be left the programmer and the
packagers for your platform.

A project I started a few months ago, I wanted to write in Clojure.
There were two major reasons why I ended up going with Python, and
this is one of them (the other was POSIX Integration issues). I knew
that I wanted something which the user could easily install and use
using the tools that are integrated with his or her platform, without
knowing anything about Java or Clojure or mucking about with things
manually. Something which could just *be there* by default, as part of
the regular experience of the operating system.

In summary, I think one should not underestimate the importance of
making sure users can just "aptitude install your-application"
(substitute for whatever with freebsd//redhat/etc). Making it as easy
as possible for applications writers to in turn make it as easy as
possible for packagers to make that happen, is, I think, important.

Having said that, this does not necessarily mean that one has to adopt
the the Python/Ruby style of system-wide library paths. But I think it
does mean that there needs to be some sensible way for an operating
system's native packaging infrastructure to interface with the
infrastructure of the language. And any random blackbox doesn't cut
it; certain demands are imposed on the blackbox in order for it to
play nice with the packaging infrastructure.

At this time I haven't thought this through enough in the case of
Clojure to offer a practical suggestion that does not involve
system-wide library paths.

-- 
/ Peter Schuller

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To

Re: Prepping clojure for packaging (was: Re: Clojure for system administration)

[Peter Schuller]

> How about having a Clojure application 'package' set up a launcher
> script to launch the app with a minimal classpath, Leiningen style,
> based on some assumption regarding the whereabouts of versioned jars
> on the system? (E.g. jline-0.9.94.jar rather than jline.jar, say.)

Something along those lines was what I had in mind (rather than, as
you say, just drop everything onto the CLASSPATH). It would not be
something you want to fuss with necessarily during development, but
some standard way of "building" your application in a packaging
friendly manner.

> Note that it will never do to have dependencies handled by a system
> which isn't capable of installing several versions of the same jar
> side-by-side... I don't know what apt / rpm / ports do about Java lib
> versioning, so maybe there's no problem here?

As far as I can tell, few Java things are packaged. I suspect because
of this reason, in part. Things that are packaged tend to be those
things that depend only on the JDK itself, or on very simple
dependencies, or else major stuff like 'eclipse' which release
engineering and huge dependency trees are not your concern.

But as far as I have encountered, there is no magic solution to the
multiple-versions-of-the-same-library problem that integrate with
native OS packaging systems (that doesn't mean there are none).

Maybe for Clojure it would indeed be more desirable to have some
well-defined interface for packaging systems to use when dealing with
clojure applications. It may not be entirely trivial though. For
example with FreeBSD ports, the build step is expected to only depend
on downloading certain well-defined and checksum controlled files from
remote locations. You do not want something that arbitrarily downloads
stuff during building. I'm pretty sure similar conventions exist for
e.g. Debian.

It's a difficult problem, and I'm not blaming Clojure. Especially
since I think the Java/Clojure/Maven way of dealing with dependencies
is vastly superior to the traditional way. But the practical issue
remains that if I want to write some software that I want sysadmins in
various situations to want to use effortlessly (in my case, a backup
tool), problems like these do get in the way of choosing Clojure.

Maybe uberjars are the pragmatic approach after all. But then what
about GPL libraries and similar license hassles?

Actually, how is this dealt with in the Maven community?

-- 
/ Peter Schuller

-- 
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: Prepping clojure for packaging (was: Re: Clojure for system administration)

[Peter Schuller]

> That's exactly what Debian does. For every Java package also provide
> the maven xml file and the jar is discoverable from maven. The
> installed packages on the local system acts as a local maven repo.
>
>  <http://wiki.debian.org/Java/MavenRepoSpec>

I see they also solved the problem of not downloading during build.

One should probably look into doing something similar for other
packaging systems then.

Guess I need to bite the bullet and learn Maven ;)

-- 
/ Peter Schuller

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

Why the implicit do in forms like let?

[Peter T]

Hi all,

Disclaimer: absolute beginner here, so probably missing something very
obvious.

I'm just wondering why certain forms, like let, natively allow for
multiple body/expression argument forms. That is, let seems to
natively allow for side effects.

Wouldn't it make sense to limit let to a single body/expression
argument, and otherwise require the explicit use of do?

I realize that'd be rather verbose, but it'd seem to also help make
the presence of side effects more apparent - which is a priority,
isn't it?

Am just curious what the rationale is behind the implicit do.


Kind regards,
Peter

-- 
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: another concurrency question: could there be contention for allocation (consing etc.)?

[Peter Schuller]

> BTW also, someone else previously commented on a different thread that maybe 
> some of my slow-downs were GC related, and at the time I didn't understand 
> the possible interactions between the GC and multithread timing issues... 
> which I'm still not sure I completely understand, but all of this has now 
> been cast in a new light.

Using the -XX:+PrintGC and -XX:+PrintGCDetails JVM options will tell
you more about when and whether GC is happening, and what type of GC
is happening.

Whether or not a GC pause is parallel is relevant to whether or not
the JVM will use all (or several depending on settings) available
cores during said pause. There is also the concept of "concurrent" GC,
which refers to the GC running concurrently (in one or more threads)
with your application.

Depending on your choice of GC you may have non-parallel/parallel GC
during stop-the-world pauses, or parallel/non-parallel GC running
concurrently with your application.

The '-Xincgc' option will turn on the concurrent mark-sweep GC which
makes operation on the old generation concurrent, and I believe the
default will also be for parallel GC in the young generation
(generations refer to classifications of data as young or new; the
distinction exists because GC:s typically perform optimizations based
on the fact that most applications generate a lot of short-lived
data).

If you are interested in how GC:s work I can recommend the following papers:

"Uniprocessor garbage collection techniques", which is now fairly old
but gives a pretty good (IMO) overview of GC algorithms of different
types:

   ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps

Actually if anyone has good suggestions for similar papers I'm all
ears. This was the first paper I ever read about GC and launched my
interest in it; I still think it's good, but then I'm biased.

"Garbage-First Garbage Collection" describes the upcoming GC which is
already available but not yet the default, but intended to be the
default replacement for CMS in JDK 1.7:

   http://research.sun.com/jtech/pubs/04-g1-paper-ismm.pdf

That one in particular will cover several aspects that are relevant to
concurrency as multi-processor scalability was a design goal.

You may also be interested in what I believe to be the original paper
about the CMS collector:

   http://research.sun.com/techrep/2000/smli_tr-2000-88.pdf

Of course both CMS and G1 will have changed since the original
publications of the papers, but they should offer good insight.

-- 
/ Peter Schuller

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

To unsubscribe from this group, send email to 
clojure+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: "wrong number of args" with nested map

[Peter Salvi]

Also the function
  (defn foo [map1 map2] (map map2 (keys map1)))
seems to be a bit more clear.

Peter

-- 
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: code review request: clojure.java.io

[Peter Schuller]

> Assembla Ticket #311 [1] calls for the promotion of clojure.contrib.io into
> clojure (as clojure.java.io). I have attached a patch, and am requesting
> comments and code review from the community.

Should delete-file-recursively recurse down symlinks (on platforms
that support them)? An admittedly Unix biased expected behavior would
be, I believe, to not do that by default, but maybe have an option to
do so.

(Did you want feedback here or on assembla?)

-- 
/ Peter Schuller

-- 
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: Cyclical refs fail on Clojure 1.2?

[Peter Schuller]

> (def a (ref ()))
>
> (def b (ref ()))
>
> (dosync
>  (alter a conj b))
>
> (dosync
>  (alter b conj a))
>
> This last expression fails with an "Evalutation aborted" message on
> Clojure 1.2.0-master-SNAPSHOT (it works on Clojure 1.1.0). Maybe I am
> not using refs correctly, but I did not expect this to fail. Can
> anyone explain this?

It seems to work for me on both. Are you perhaps doing this in a REPL
(other than the default) or IDE where you are susceptible to stack
overflow while the result is auto-printed? I get stack overflows in
the REPL in both 1.1 and 1.2 because of the after-eval printing of the
result, but the alters do succeed. In other words, *printing* a, @a, b
or @b may give you difficulties due to infinite recursion. But is one
of the (dosync ...) blocks really failing?

-- 
/ Peter Schuller

-- 
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: code review request: clojure.java.io

[Peter Schuller]

> Using an option for symlinks raises the possibility of using options to let
> delete-file handle everything, e.g.
>
> (delete-file "foo" :recursive true)
>
> instead of
>
> (delete-file-recursively "foo")

Yes. A potential argument for not conflating them might be that
"delete-file" is a pretty simple operation with hopefully clear
semantics, while a recursive directory tree operation immediately
opens up several questions. On the one hand, 'rm' sets a precedent
that it is okay. On the other hand, I think most API:s I've come
across do make a special distinction between plain unlinking and more
"elaborate" operations like tree walking removal.

Depending on how far one wants to go, the following may be overkill.
But my thoughts quickly stray towards providing a file tree walker
similar to Python's os.walk(), supporting top-down and bottom-up
traversal, following or not following symlinks and some customizable
error handling behavior. Implementing a 'delete-tree' would then be a
bottom-up walk with a delete action, along the lines of:

(defn delete-tree
  [top {:keys [follow-symlinks], :or [false]}]
  (doall (for [path (walk-tree top {:direction :bottom-up,
:follow-symlinks follow-symlinks})]
   (delete-file path

Of course none of this is incompatible with the interface of the
proposed delete-file-recursively (except possibly naming).

If you think it might be suitable for inclusion I'd be interested in
having a stab at it (it's a nicely bite-sized opportunity to write
some clojure).

-- 
/ Peter Schuller

-- 
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: code review request: clojure.java.io

[Peter Schuller]

> Following symlinks in delete-file-recursively sounds like a recipe for
> disaster to me.

Sorry, I should have been more explicit. The (delete-file-recursively
...) in the patch *does* follow symlinks (implicitly, because
isDirectory() returns true for symlinks pointing to diretories).

The simplest "fix" (assuming everyone agrees it's a problem) is to
simply change it not to, but I suggested the option to allow for both
- but the default should presumably be to *not* follow symlinks.

-- 
/ Peter Schuller

-- 
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: code review request: clojure.java.io

[Peter Schuller]

> i.e. I agree with you, but am also against allowing this behaviour as
> an option, unless others feel it's a good option to have.

I can definitely buy that.

-- 
/ Peter Schuller

-- 
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: code review request: clojure.java.io

[Peter Schuller]

> I would like to stop following symlinks, but It doesn't appear that the File
> API has any ability to detect symlinks. How were you thinking about doing
> this?

Argh, you are right of course. I somehow believed that *testing* for
whether a path is a symlink was part of File's API, but I failed to
confirm it.

In that case, I suggest putting a huge warning in the documentation at
least, as to the potential destructiveness of the operation.

(Ant's trick with canonical names feels shaky in the context of
something as general-purpose as delete-file)

-- 
/ Peter Schuller

-- 
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: How do I run a script? This has me stumped.

[Peter Schuller]

> I am running the following command line:
>
> c:\apps\jdk1.6.0\bin\java.exe -server -cp "C:\apps\clojure-1.2.0\\lib
> \clojure-1.2.0-master-SNAPSHOT.jar;C:\apps\clojure-1.2.0\\lib\clojure-
> contrib-1.2.0-SNAPSHOT.jar" clojure.main Blah.clj
>
> If Blah.clj does not exist, I get a FileNotFoundException.  However,
> if Blah.clj exists, I get nothing.  It can contain valid Clojure code,
> invalid text, whatever.  I've tried using various combinations of
> flags too.

I have been starring at the command line and I can't spot what's wrong.

When you specify the invalid file, do you get the error in the form of
a clojure strack trace, or something else? With 1.1 at least you
should be seeing something similar to the below. Just trying to
establish whether strack traces are successfully printing at all. You
should definitely be seeing one if you try to run a clojure script
that doesn't compile.

Exception in thread "main" java.io.FileNotFoundException:
nonexistent.clj (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.(FileInputStream.java:106)
at java.io.FileInputStream.(FileInputStream.java:66)
at clojure.lang.Compiler.loadFile(Compiler.java:4936)
at clojure.main$load_script__7405.invoke(main.clj:213)
at clojure.main$script_opt__7442.invoke(main.clj:265)
at clojure.main$main__7466.doInvoke(main.clj:346)
at clojure.lang.RestFn.invoke(RestFn.java:413)
at clojure.lang.Var.invoke(Var.java:359)
at clojure.lang.AFn.applyToHelper(AFn.java:173)
at clojure.lang.Var.applyTo(Var.java:476)
at clojure.main.main(main.java:37)

-- 
/ Peter Schuller

-- 
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: How do I run a script? This has me stumped.

[Peter Schuller]

> Which leads to the question: what's in Blah.clj? In particular,
> there's nothing in clojure that automatically run things in the script
> file; you have to explicitly invoke the main function at the end of
> the script. If you don't, then invoking it on the command line will
> just load it, and then exit without running anything.

Hmmm? I've been invoking scripts regularly since forever ;)

Back in the 1.0 days there was the clojure.Repl vs. clojure.Script
(IIRC); with 1.1 clojure.main does both things depending on
parameters. For example:

% echo '(println "test")' > test.clj
% java -cp /usr/local/share/java/classes/clojure.jar clojure.main test.clj
test

-- 
/ Peter Schuller

-- 
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: How do I run a script? This has me stumped.

[Peter Schuller]

> I'm thinking the problem - since the command line appears to be
> correct, and starts a repl if no script is provided - is that Blah.clj
> just defines functions, but doesn't invoke one of them. Without
> looking at the script, this is just a WAG, but I recall some
> discussion about this issue earlier.

Ah. Sorry, I mis-interpreted what you meant. You're right of course.

What made me not think this was the problem, was that the OP said he
did not get any output when specifying an existent file that did not
contain valid clojure. But come to think of it, did said file contain
actual data not valid clojure, or was it just an empty file? If the
latter, no output is expected, as you point out.

-- 
/ Peter Schuller

-- 
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: Why is JLine better than just command-line?

[Peter Schuller]

> Okay, so you can actually print password-masked characters.  But I
> can't figure out how to actually do anything I couldn't already do
> with my command-line before JLine, except I can't seem to exit the
> Clojure REPL with CTRL+c.

I presume you've read about JLine at http://jline.sourceforge.net/
given your masked character comment?

I guess it's up to what you think is important. In my case I use jline
because it gives proper line editing functionality with (by default)
emacs key bindings. For example, "ctrl-a, ctrl-k" kills a line.
"ctrl-p" gives me the line I just wrote, etc. For me, being used to
primarily sitting at the zsh command line,I would not be able to use
the plain REPL without it or I'd go nuts ;)

-- 
/ Peter Schuller

-- 
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: Actors not good for concurrency model

[Peter Schuller]

> far as i know..actors share a mutable queue.. so there's good possibility
> for dead-locks

Actors as they work in erlang don't have mutable state (not
intrinsically anyway, though of course you can implement an actor that
does poke on shared data since it's your code). The 'state' in an
erlang actor is that of parameter(s) to an infinitely tail-recursive
function.

Deadlock in a message passing system is still possible if you limit
the mailbox size (unless some other means are used to prevent it). My
understanding is that mailbox size is not limited in erlang, and that
there is no other means to avoid deadlock, meaning that while you will
not deadlock in the message passing system you can cause memory
exhaustion.

Disclaimer: While I've played with erlang I'm not really that into it,
please correct me someone if I've misrepresented anything.

-- 
/ Peter Schuller

-- 
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: Actors not good for concurrency model

[Peter Schuller]

> i don't expect it would be hard to write an Erlang program with 2
> actors that would deadlock. as far as i know, people use timeouts on
> message handling to sweep it under the carpet.
>
> e.g. (just a quick google search turns this up)
> http://mue.tideland.biz/avoiding-erlang-deadlocks

So yes, with a synchronous send+receive you can easily deadlock. The
bounded mailboxes was under the assumption of asynchronous sends, but
I suppose another way to put it is that such asynchronous sends
effectively turn synchronous (or potentially synchronous) again once
you limit mailbox size.

I think the interesting generalization is that regardless of your
underlying primitives, you will always be able to create a system
which has some potential for deadlocks and/or race conditions. Just
because your low-level primitives "guarantee" that you don't, does not
mean that you cannot use them to build something on top that *is*
susceptible to deadlock/races.

-- 
/ Peter Schuller

-- 
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: Actors not good for concurrency model

[Peter Schuller]

> Actors in Erlang DO have mutable state, you're just discouraged from
> using it. ;) No really, erl -man get and set. Sometimes you're forced
> to use this despite the best of intentions.

I don't think anyone is trying to claim that it is impossible to
mutate shared in state in an erlang actor. The claim is rather that
the intended fundamental model implemented by an actor is not one of
shared mutable state.

-- 
/ Peter Schuller

-- 
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: Actors not good for concurrency model

[Peter Schuller]

> I'm not sure why a getValue/setValue is any different from an ='s
> sign. Instability and unpredictability still results. Be they actors
> or threads, neither really solves any sort of problem save perhaps
> atomic updates.

My (unproven) gut feeling is that people are afraid of machine
concurrency, and the removal of machine-level concurrency issues (by
use of appropriate high-level abstractions) cause a belief, which is
in my estimation mistaken, that you are therefor rid of *all*
concurrency issues.

In any case, for the record, I did not mean to imply that i agreed,
overall, with the originally posted article.

-- 
/ Peter Schuller

-- 
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: promoting contrib.string to clojure, feedback requested

[Peter Schuller]

> chomp => rtrim
> (rtrim "foo\n") => "foo" is much more clear to me, plus it leaves the
> door open for trim and ltrim functions should the need arise.

I like this. And in general I often fine the entire trio useful, and
adopting the ltrim/trim/rtrim naming makes it nice and tidy.

While I recognize the perl (or whatever the original is) precedent
from chomp/chop, there is precedent for trim/left trim/right trim too.
What *would* one call trim/ltrim to make them consistent with chomp?

-- 
/ Peter Schuller

-- 
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: promoting contrib.string to clojure, feedback requested

[Peter Schuller]

> Personally, I like the lstrip/strip/rstrip, but that's just because
> I'm used to them.

strip is fine too IMO; I'm neutral between *strip and *trim.

-- 
/ Peter Schuller

-- 
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: question about agent implementation

[Peter Schuller]

> question is about clojure.lang.Agent. In the doRun method, I'm missing
> what prevents a race condition in the updating of the agent's state
> variable.

Unless I am misunderstanding the context in which the code runs, I
believe it is correct because doRun() is guaranteed never to run
concurrently (because agents mutate state by function application in a
serialized fashion).

If I understand it correctly (and someone correct me if I'm wrong),
enqueue() is the initial entry point to execution. It will trigger
execution if the agent was not already running and had nothing queued.

doRun() itself keeps itself running until it manages to empty the
queue, at which point a future enqueue() will once again re-start
execution.

-- 
/ Peter Schuller

-- 
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: question about agent implementation

[Peter Schuller]

> Unless I am misunderstanding the context in which the code runs, I

Which I was. Please ignore my previous post (sorry, think before I
post... think before I post...) and consider me joined in the OP's
question.

-- 
/ Peter Schuller

-- 
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: question about agent implementation

[Peter Schuller]

>> Unless I am misunderstanding the context in which the code runs, I
>
> Which I was. Please ignore my previous post (sorry, think before I
> post... think before I post...) and consider me joined in the OP's
> question.

And every time this happens I wonder if I should just leave it to
avoid flooding with responses further, or follow-up yet again, risking
the realization that I have to take something back *again*.

I think I was confused the second time and right the first. But to
elaborate on my first post to clarify:

As far as I can tell, execute() is only ever called by enqueue() and
enqueue() will only ever call execute() if the queue was non-empty
when the action was enqueued using the compareAndSet(). Further, if it
*was* empty, it always calls execute().

doRun() itself does a similar compareAndSet() loop and *always*
executes itself if the queue is non-empty.

The resulting behavior is that any CAS loop that ends with the
realization that there was something already there to execute, leads
to said action being executed if needed. In the case of doRun() this
is accomplished by calling execute() itself - since doRun() is the one
already being executed, it knows it is done and that scheduling one
more action will lead not lead to a >1 concurrency level. In the case
of enqueue(), it either does nothing (if there was *already* something
there), or schedules the execution if the enqueue() invocation was
responsible for making the queue non-empty.

In either case, the concurrency level can never go above 1.

(I find this to be a very interesting use-case for immutable data
structures btw... it allows a complex data structure, without them in
and of themselves doing careful lock-less operations to support
concurrency, to be used in combination with simple CAS loops to great
effect.)

-- 
/ Peter Schuller

-- 
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: question about agent implementation

[Peter Schuller]

> Where is Action's execute method called in the event the queue is not
> empty?

If the agent's queue was non-empty from the perspective of enqueue(),
that means one of the following is true:

(1) A previous enqueue() has already scheduled the execution of an
action, but it has not yet begun running.
(2) doRun() is running but has not yet completed its CAS loop at the end.

In either case, once doRun() runs and reaches its CAS loop, it will
detect that the queue is non-empty and schedule the next action. This
is the:

if(error == null && next.q.count() > 0)
((Action) next.q.peek()).execute();
}

which appears towards the end of doRun(). Next is the atomically
obtained (through CAS looping) queue, after it popped itself.

Another way to look at it might be that the queue can be in two
relevant states at any point in time:

  * empty
  * non-empty

In the non-empty state, doRun() is continuously responsible for
re-scheduling itself. In the empty state, enqueue() is responsible for
scheduling it. Because of the use of CAS loops, the transition from
"empty" to "non-empty" can be atomically detected by enqueue(),
allowing it to determine whether or not it was responsible for such a
state transition, in which case it schedules the action for execution.

-- 
/ Peter Schuller

-- 
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 to: reduce boolean operations?

[Peter Mancini]

OK long time lurker here. I've been growing in my Clojure strength for a 
while now. For the most part I think I get it and I have no problem getting 
programs to do what I want. However, sometimes I get stumped.

I have one function that produces a list of booleans like '(false false 
true). It seemed to me that this should be legal:

(reduce and '(false false true))

However that is not legal with the complaint being something about "and" 
being a macro. :-/

I did get it to work with:

(eval (conj '(false false true) 'and))

It works but is it "correct"? Is it what you would do? I noticed that '(nil 
nil true) will cause "and" to produce false, so I am aware of that edge 
case. Anything else I should be aware of?

Thanks.

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

Re: How to: reduce boolean operations?

[Peter Mancini]

Thanks everyone for the help. The nil behavior of the 'or' version breaks 
what I wanted, but I may create functions that return just true or false 
though the odd edge case where "and" will return a value will mean I'll 
have to handle that. My preference would be to throw an exception but thats 
another cultural question about the language. What is prefered - throwing 
the last value or failing when not given correct input?

Ok now on to implementation. Thanks!

On Wednesday, May 22, 2013 7:38:17 AM UTC-5, Michał Marczyk wrote:
>
> On 22 May 2013 08:09, Baishampayan Ghose > 
> wrote: 
> > Using a lambda seems to be a sane approach - 
> > 
> > (reduce #(and %1 %2) '(false false true)) 
> > ;=> false 
>
> Note that this will always traverse the entire input collection, 
> whereas every? stops at the first false value. 
>
> Same thing goes for reducing with #(or %1 %2) vs. using some. 
>
> Cheers, 
> Michał 
>
> > 
> > On Wed, May 22, 2013 at 5:36 AM, Peter Mancini 
> > > 
> wrote: 
> >> OK long time lurker here. I've been growing in my Clojure strength for 
> a 
> >> while now. For the most part I think I get it and I have no problem 
> getting 
> >> programs to do what I want. However, sometimes I get stumped. 
> >> 
> >> I have one function that produces a list of booleans like '(false false 
> >> true). It seemed to me that this should be legal: 
> >> 
> >> (reduce and '(false false true)) 
> >> 
> >> However that is not legal with the complaint being something about 
> "and" 
> >> being a macro. :-/ 
> >> 
> >> I did get it to work with: 
> >> 
> >> (eval (conj '(false false true) 'and)) 
> >> 
> >> It works but is it "correct"? Is it what you would do? I noticed that 
> '(nil 
> >> nil true) will cause "and" to produce false, so I am aware of that edge 
> >> case. Anything else I should be aware of? 
> >> 
> >> Thanks. 
> >> 
> >> -- 
> >> -- 
> >> You received this message because you are subscribed to the Google 
> >> Groups "Clojure" group. 
> >> To post to this group, send email to clo...@googlegroups.com 
> >> Note that posts from new members are moderated - please be patient with 
> your 
> >> first post. 
> >> To unsubscribe from this group, send email to 
> >> clojure+u...@googlegroups.com  
> >> For more options, visit this group at 
> >> http://groups.google.com/group/clojure?hl=en 
> >> --- 
> >> You received this message because you are subscribed to the Google 
> Groups 
> >> "Clojure" group. 
> >> To unsubscribe from this group and stop receiving emails from it, send 
> an 
> >> email to clojure+u...@googlegroups.com . 
> >> For more options, visit https://groups.google.com/groups/opt_out. 
> >> 
> >> 
> > 
> > 
> > 
> > -- 
> > Baishampayan Ghose 
> > b.ghose at gmail.com 
> > 
> > -- 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@googlegroups.com 
> > Note that posts from new members are moderated - please be patient with 
> your first post. 
> > To unsubscribe from this group, send email to 
> > clojure+u...@googlegroups.com  
> > For more options, visit this group at 
> > http://groups.google.com/group/clojure?hl=en 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups "Clojure" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to clojure+u...@googlegroups.com . 
> > For more options, visit https://groups.google.com/groups/opt_out. 
> > 
> > 
>

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

Re: How to: reduce boolean operations?

[Peter Mancini]

Well, excepts that it is not correct. It will return false when really 
there was a faulty collection handed to it. I'd rather catch an error like 
that than to pretend it didn't happen and give a result that isn't correct 
while also being hard to detect. If you can guarantee it won't get a bad 
collection then the test and exception aren't needed. Its an interesting 
problem - especially when you are writing "mission critical" code.

On Wednesday, May 22, 2013 9:55:38 AM UTC-5, Jim foo.bar wrote:
>
> On 22/05/13 15:54, Peter Mancini wrote: 
> > The nil behavior of the 'or' version breaks what I wanted, but I may 
> > create functions that return just true or false though the odd edge 
> > case where "and" will return a value will mean I'll have to handle that. 
>
> wrap that call in a 'boolean' call (e.g. (boolean (or ...))) and you got 
> your true/false result :) 
>
> Jim 
>
>

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

Re: How to: reduce boolean operations?

[Peter Mancini]

So I did some coding and came up with this but it is broken;

(= java.lang.Boolean (type false))  ;;evaluates to true

(defn all-true?
  [coll]
  (every? (cond (= java.lang.Boolean (type identity)) identity :else false) 
coll)) ;;compiles

(all-true? '(true true true))  ;; throws java.lang.ClassCastException: 
java.lang.Boolean cannot be cast to clojure.lang.IFn
(all-true? '(true true false))
(all-true? '(true true 3))

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

Re: How to: reduce boolean operations?

[Peter Mancini]

Duh never mind - simplified it and it works like a charm now.

(defn all-true?
  [coll]
  (every? (fn [x] (= x true)) coll))

(all-true? '(true true true))
(all-true? '(true true false))
(all-true? '(true true 3))
(all-true? '(3 \# !))

No exception on bad input data but if I really need to do that I can expand 
that lambda. Thanks to everyone 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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: I18n

[Peter Taoussanis]

Since this thread seems to come up from time to time, just adding a quick 
pointer to Tower: https://github.com/ptaoussanis/tower

This gives (among other things) a translation tool using standard Clojure 
maps for content, Markdown support, translation fallbacks, Ring 
localization middleware, and a dev mode with dictionary auto-reloading.

Cheers!

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

regular expressions how-to: recognize lines?

[Peter Mancini]

(def testcase "Line 1\nLine 2\nTarget Line\nLine 4\nNot a target line")
(println testcase)
(re-seq #"(?i)^target" testcase)
(re-seq #"(?i)target" testcase)

Line 3 finds nothing. It should find the third line, first word. Ultimately 
I'd like #"(?i)^Target.*$" to work in finding the entire line. I am 
confused why this is failing. Where do I find all the switches? I only 
found (?i) because of comments. Where is it in the documentation? Thanks!

P.S. I did read the java documentation and that wasn't much 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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: regular expressions how-to: recognize lines?

[Peter Mancini]

There has to be some way to turn on line recognition. Its a basic function 
of regex. I know the string has lines, I can even use 
clojure.string/split-lines on it. I shouldn't have to do that and map 
against it. It should be built into the regular expression system. I'm 
certain my problem is ignorance and not some oversight in the design of the 
system.

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

Re: regular expressions how-to: recognize lines?

[Peter Mancini]

Winner Winner Chicken Dinner!

Thanks. Where do I find that? Much appreciated!

On Wednesday, May 29, 2013 11:45:55 AM UTC-5, sw1nn wrote:
>
> You need to pass the multiline 'm' flag to the regex. some variant of:
>
> (def testcase "Line 1\nLine 2\nTarget Line\nLine 4\nNot a target line")
> (println testcase)
> (re-seq #"(?im)^target" testcase)
> (re-seq #"(?im)target" testcase)
> #'user/testcase
> Line 1
> Line 2
> Target Line
> Line 4
> Not a target line
> nil
> ("Target")
> ("Target" "target")
>
>
>

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

Core Logic Reference Documentation

[Benjamin Peter]

Hello,

I am currently trying to find my way to using clojure core logic, watching 
some videos, reading tutorials and trying to read the dissertation about 
miniKanren.

While this is quite nice to grasp the concepts I feel the need for a 
complete reference documentation listing all the functions and goals 
available. I feel like I have absolutely no overview about what there is, 
like with every new article I read I discover a new feature.

Maybe something like the clojure.org/cheatsheet with links to 
clojuredocs.org would be cool now that there are so much additions of 
kanren implemented.

Is there such a thing?

I looked into the code but was not sure what is the interface and what is 
implementation since logic.clj is pretty big.

If not I would be willing to help setting it up but since I am asking this 
question I have no clue about this stuff - yet.


Thanks for reading

Benjamin.

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

Re: [ANN] core.rrb-vector -- RRB-Tree-based confluently persistent vectors

[Peter Taoussanis]

That looks great Michał, thanks for your work!

Have use cases for something like this popping up quite regularly - 
definitely looking forward to a production-ready implementation. Cheers! 

- Peter

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

[ANN] Library updates (Redis & DynamoDB clients, logging+profiling, i18n+L10n, serialization, A/B testing)

[Peter Taoussanis]

Hi folks, just a quick update on some libraries - figure I'll do this and 
future updates in batches to keep from spamming the group. Hoping the 
formatting comes through here...

*Carmine* - Redis client & message queue 
(GitHub<https://github.com/ptaoussanis/carmine>
)
Current version: *1.9.1*
Clojure dependency: 1.4+
Recent changes: message queue features, distributed locks, performance 
improvements.
Thanks to Ronen (narkisr) for most of the new features.

*Faraday* - DynamoDB client (GitHub <https://github.com/ptaoussanis/faraday>) 
- NEW LIBRARY
Current version: *0.5.0*
Clojure dependency: 1.5+
Recent changes: full DynamoDB v2 API coverage.
Thanks to James Reaves whose library (Rotary) provided the basis for 
Faraday.

*Nippy* - serialization library (GitHub<https://github.com/ptaoussanis/nippy>
)
Current version: *1.2.1*
Clojure dependency: 1.3+
Recent changes: sorted set+map support, performance improvements.

*Timbre* - logging & profiling library 
(GitHub<https://github.com/ptaoussanis/timbre>
)
Current version: *2.0.0 *- MAJOR RELEASE
Clojure dependency: 1.4+
Recent changes: tools.logging support.

*Touchstone* - A/B testing library 
(GitHub<https://github.com/ptaoussanis/touchstone>
)
Current version: *1.0.0* - MAJOR RELEASE
Clojure dependency: 1.4+
Recent changes: inherited test-config support, marked API as stable.

*Tower* - i18n & L10n library (GitHub <https://github.com/ptaoussanis/tower>
)
Current version: *1.7.0*
Clojure dependency: 1.4+
Recent changes: Nothing major.


I've started to push new releases (like Faraday) to Clojure 1.5+ but will 
maintain backwards-compatibility with 1.4+ where possible. Nippy is an 
exception which I'll keep at Clojure 1.3+  for at least 
the foreseeable future.

For those interested I've now setup a page at 
https://www.taoensso.com/clojure-libraries to keep track of the libraries 
I'm currently maintaining. In any event, will update the group from time to 
time when there's a bunch of significant changes queued like today.

As always, am very happy to take ideas/comments/PRs/whatever - a lot of the 
recent improvements above were a result of direct/indirect input from other 
folks (thank you!).

Have an awesome Monday, cheers!

- Peter Taoussanis (taoensso.com <https://www.taoensso.com>)

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

Looking for Clojure freelancers

[Peter Taoussanis]

Hi all,

>From time to time I have need for one or two extra hands (or, would that be 
pairs of hands?) on larger projects. Specifically, am looking for Clojure 
developers that'd be interested in occasional adhoc/freelance development 
work.

Most of my work is on the web application side, but it can vary.

What I'd like to ask is this: if anyone's interested, drop me an email 
(*ptaoussanis 
at taoensso.com*) with some basic info including:

   - Contact details (would prefer an international telephone number also 
   if possible).
   - Your experience / informal CV (open-source stuff is my preferred 
   reference, especially if it's Clojure-based).
   - Any particular areas of interest/expertise (e.g. you especially want 
   to work with Datomic, backend services, Clojurescript, whatever).
   - Your rate + how negotiable it'd be and/or how it'd scale with 
   longer-term jobs.

I can then keep your details on file and give an occasional shout if 
something comes up that I could potentially use you for.

Whole thing'd be about as informal as it gets: terms will vary based on the 
particular job, but I'll include all of that in the email so you can decide 
if/when something grabs your fancy.

Cheers!

- Peter (taoensso.com <https://www.taoensso.com>)

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