Re: javadoc.clj

[Christophe Grand]

pc a écrit :
> This is very useful. Thanks for doing it.
>   
You're welcome.

> On windows xp find-javadoc-url would not work for local javadocs,
> maybe because of window's "c:\xx" syntax. Using (.toURL file) seemed
> to fix it. Maybe that will work for the other systems also.
>   
Fixed, thanks!

Christophe

--~--~-~--~~~---~--~~
You 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: A quasiquote for Clojure?

[Meikel Brandmeyer]

Hi Jason,

Am 16.01.2009 um 00:36 schrieb Jason Wolfe:


I like this a lot.  Any chance of getting the same treatment for
unquote-splicing?

user> '~x
(clojure.core/unquote x)
user> '~...@x
; Exception: can't embed object in code
; Desired output: (clojure.core/unquote-splicing x)


That's a good idea. It would nicely complement the other
functions so far. Please find attached a patch.

1:1 user=> '~x
(clojure.core/unquote x)
1:2 user=> '~...@x
(clojure.core/unquote-splicing x)

Sincerely
Meikel



unquote-splice.diff
Description: Binary data




smime.p7s
Description: S/MIME cryptographic signature

Re: Macros in interaction with Functions

[Stuart Sierra]

Hi Daniel,

On Jan 16, 6:54 pm, Daniel Jomphe  wrote:
> I'll tell you my current understanding of how Clojure works, so you
> can correct me where I may be wrong:
>
> - The compiler has for target a living environment; thus, it's
> dynamic.
> - There's no interpreter; thus, the following points will be easier to
> reason about.
> - When code is sent for evaluation, it's first read.
> - The reader performs a few substitutions, then gives the resulting
> code to the compiler.
> - The compiler starts by expanding macros into their substitution.
> --- Thus, for functions, there's no such thing as macros.
> --- Thus, all that functions see of macros is what came out of macros'
> complete expansion.
> --- Therefore, like Timothy Pratley wrote so well, a function can have
> for parameter a macro call, but not a macro itself.

All correct up to this point.

> - After macro expansion, the compiler starts compiling all functions
> in need of being compiled, including the functions modified during
> macro expansion.

Sort of.  What's really getting compiled are just the function calls.
The functions themselves were compiled back when they were defined.

> - Then, code is ready for evaluation.

Yes, and at this point, Clojure has done its job and the Java Virtual
Machine takes over.

> Ok, so although it's a live system, when a new bunch of code is sent
> for evaluation, all macros inside it must be expanded before runtime
> evaluation can occur. Thus, functions can't act on macros. I thought
> that somehow my code could still work because what would have happened
> is 'reduce' would have acted on 'and's expansion, but I see and's
> expansion couldn't be done because it would have to wait for reduce's
> evaluation.
>
> If we were speaking of concurrency, wouldn't this be a deadlock issue?

 Not really, because macro expansion is not happening concurrently
with compilation or evaluation.

> ...I also thought it could be possible that 'and' expands to a partial
> application that waits for 'reduce' to provide it its arguments.
> Wouldn't this make sense?

 No, because "and" doesn't know how many arguments it's going to get.
If you look at the definition of "and", you'll see that it takes a
variable number of arguments and it is recursive. So if you tried to
expand it before knowing the length of the argument list, you would
get an infinite loop.

> Konrad Hinsen said:
>
> > The universal workaround is to define a
> > function that contains nothing but the macro, such as
>
> >         (fn [x y] (and x y))
>
> > which can also be written in Clojure using the shorthand notation
>
> >         #(and %1 %2)
>
> > Here the macro gets expanded inside the function *body*, but what you
> > pass around is the function *object*.
>
> Wouldn't this defeat the purpose of having 'and's arguments short-
> circuited when false is found?

 Yes, but there is no alternative if you want a function.

>
> Now, why is this workaround possible? For sure, the wrapper function
> is ok as a parameter of a function call. And in the called function's
> body, when it's going to call the wrapper function, the arguments for
> the macro wrapped in the wrapper function will be ready. And the
> wrapper function contains the macro's substitution anyways. So if
> we're willing to sacrifice macros' lazy parameters evaluation, we can
> wrap them inside functions to achieve this effect. We could also say
> that as long as macros are either called or wrapped in any function,
> they can go anywhere. In other words, the only limitation seems to be
> that runtime code can't use the symbol to which a macro is binded.

 Again, sort of. Some macros examine their arguments to decide what
kind of code to produce, and some depend on lazy evaluation, like
"and" or "cond".  These macros cannot simply be wrapped in functions.

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

[Stuart Sierra]

Hi Peter,

On Jan 16, 5:37 pm, Peter Wolf  wrote:
> 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

SLIME doesn't handle it at all; it just sends strings to the Lisp
process (Clojure, in this case) and gets strings back.

> 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

Try it!   To answer your question, the Lisp process just evaluates
forms in order as it encounters them.  So first "foo" is defined to be
1, then it's redefined to be 2.

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]

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: Reading non-printing characters in the reader?

[Stephen C. Gilardi]

On Jan 17, 2009, at 2:37 AM, Tom Faulhaber wrote:


Question: How do I read non-printing characters in the reader?


From reading src/jvm/clojure/lang/LispReader.java and experimenting,  
I see that there are at least 3 ways to read such an arbitrary  
character code with the reader:


- Octal character codes from 0 to 255 (octal 0 to 377) can be entered  
using a literal of the form "\oddd" (that's a lower case oh followed  
by up to 3 digits). You can represent the ^C character as \o3 in  
Clojure source.


- Unicode character codes can be entered using a literal of the form  
"\u" (that's a lowercase u followed by exactly 4 digits). You can  
represent the ^C character as \u0003 in Clojure source.


- If you can get the character into the input stream with a leading  
backslash, the reader does read it properly. This doesn't work for ^C  
(for me, in an emacs *shell* buffer) because it's interpreted as  
"quit" before Clojure sees it. (I would imagine it's possible to put  
the terminal into some kind of "raw" mode so that doesn't happen.) It  
does work for less consequential characters like ^G.


I don't see these documented on clojure.org/reader which is where I  
would expect to find the info.


It does appear that Clojure can properly read the characters it prints:

user=> (with-in-str (pr-str \u0003) (read))
\^C
user=> (int (with-in-str (pr-str \u0003) (read)))
3
user=>

(which I did in emacs, which shows a literal ascii 3 as ^C)

--Steve



smime.p7s
Description: S/MIME cryptographic signature

Re: How to implement "go to definition" and "find all references"

[Stephen C. Gilardi]

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



smime.p7s
Description: S/MIME cryptographic signature

Re: How to implement "go to definition" and "find all references"

[lpetit]

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

clojure repl quits after calling static java method

[larry]

I'm calling a java static method Play.midi in JMusic from Clojure
REPL.
After it plays the notes and says: "completed MIDI playback",  the
Clojure REPL quits.
How do I keep the Clojure REPL from quitting after making this call to
Java?

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

Newbie problem

[mbrodersen]

Hi

I am having fun learning Clojure but have a problem with the following
code. If you run the code with the ;OK removed then it works. If you
run the code with ;ERROR removed then it doesn't.

The code is my own implementation of splitting a string into
individual words (just a learning exercise). The error message is:

java.lang.IllegalArgumentException: No matching method found:
isWhitespace (error.clj:0)

Which is strange because the ;ERROR line has nothing to do with
isWhitespace?

Any help would be appreciated.

Thanks
Morten
-

(defn line-skip-ws [line]
(cond
(not (first line))  
""
(Character/isWhitespace (first line))   (line-skip-ws (rest 
line))
true
(apply str line)))

(defn line-split-1 [word line]
(let [c (first line)]
(println "line-split-1" "word:" word "line:" line "c:" c
"class:" (class c))
(cond
(not c) [word 
""]
(Character/isWhitespace c)  [word (apply str line)]
true
(line-split-1 (str word c) (rest line)

(defn line-split [line]
(let [split (line-split-1 "" (line-skip-ws line))]
(if (= (first split) "")
[""]
;ERROR  (concat [(first split)] (line-split (rest split))
;OK (concat [(first split)] []

(doseq [x (line-split "  Hello   world!  ")] (println (format "\"%s\""
x)))

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

[Shawn Hoover]

On Sat, Jan 17, 2009 at 9:09 AM, mbrodersen wrote:

>
> Hi
>
> I am having fun learning Clojure but have a problem with the following
> code. If you run the code with the ;OK removed then it works. If you
> run the code with ;ERROR removed then it doesn't.
>
> The code is my own implementation of splitting a string into
> individual words (just a learning exercise). The error message is:
>
> java.lang.IllegalArgumentException: No matching method found:
> isWhitespace (error.clj:0)
>
> Which is strange because the ;ERROR line has nothing to do with
> isWhitespace?
>
> Any help would be appreciated.
>
> Thanks
> Morten
> -
>
> (defn line-skip-ws [line]
>(cond
>(not (first line))
>""
>(Character/isWhitespace (first line))   (line-skip-ws (rest
> line))
>true
>(apply str line)))
>
> (defn line-split-1 [word line]
>(let [c (first line)]
>(println "line-split-1" "word:" word "line:" line "c:" c
> "class:" (class c))
>(cond
>(not c)
> [word ""]
>(Character/isWhitespace c)  [word (apply str
> line)]
>true
>  (line-split-1 (str word c) (rest line)
>
> (defn line-split [line]
>(let [split (line-split-1 "" (line-skip-ws line))]
>(if (= (first split) "")
>[""]
> ;ERROR  (concat [(first split)] (line-split (rest split))
> ;OK (concat [(first split)] []
>
> (doseq [x (line-split "  Hello   world!  ")] (println (format "\"%s\""
> x)))
>

Hi Morten,

When you call line-split with (rest split), you're passing a Clojure
sequence of characters, not a string. Then line-skip-ws calls isWhitespace
with the sequence and Java doesn't know what to do with it. Try converting
(rest split) to a string using (apply str (rest split)).

Shawn

--~--~-~--~~~---~--~~
You 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 repl quits after calling static java method

[Matt Revelle]

On Jan 16, 2009, at 9:40 PM, larry wrote:

>
> I'm calling a java static method Play.midi in JMusic from Clojure
> REPL.
> After it plays the notes and says: "completed MIDI playback",  the
> Clojure REPL quits.
> How do I keep the Clojure REPL from quitting after making this call to
> Java?

JMusic is exiting the JVM at the end of the function you're calling.   
A quick glance at their API shows that jm.util.Play/midi supports a  
boolean parameter named exit.  Set that to false and you should be in  
business.

>
>
> >


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

Common backend project? (was: Re: How to implement "go to definition" and "find all references")

[Meikel Brandmeyer]

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



smime.p7s
Description: S/MIME cryptographic signature

Re: Common backend project? (was: Re: How to implement "go to definition" and "find all references")

[Meikel Brandmeyer]

Hi,

Am 17.01.2009 um 18:12 schrieb Meikel Brandmeyer:


things, like the Parser mentioned above. Or Chouser's or


I'm sorry. I meant Chouser's show.

Sincerely
Meikel



smime.p7s
Description: S/MIME cryptographic signature

Re: QT Jambi and the Repl

[chris]

I started writing some opengl stuff using QT Jambi and I went through
a world of pain.

First off, on the Mac, you can't use java 1.6 and QT because 1.6 is a
64 bit JVM and QT doesn't work with the 64 bit cocoa libraries.

Second off, QT + JOGL consistently hung when run from the repl.  Upon
initialization JOGL would start up some swing or AWT threads and then
some QT event handler either got starved or got called from the wrong
thread; I never figured out which.

Finally, I started using swing and realized that it worked much better
from the repl than QT did and I instantly stopped using QT.  I just
don't think that QT is ready for serious java development on the mac
yet.

On a different note, I just ran a little bit of my app on windows and
it looks absolutely horrible which is quite upsetting.  On the mac, my
swing app looks pretty good.  On windows, things don't show up, the
font looks like shit, and the color scheme of the UI (none of which
did I program) sucks.  The gljpanel never initializes (do you really
have to call show on everything?) and thus my render context tries
(and fails) to create opengl resources every frame at 60 frames a
second which makes the computer act quite weird.

Using a vanillla 1.6 jvm the swing examples run very slowing if you
resize the window to anything like fullscreen.  I imagine this is
because the jogl backend is copying the pbuffer every frame; but even
JGears struggles at fullscreen which is pathetic.  Also, the system
resizes the pbuffer every so often which destroys the entire gl
context forcing me to reload all resources every so often.  Compiling
glsl isn't cheap, nor is uploading images and vbo's to the card.

The fonts really piss me off; I am unsure as to what to do about it.
I was thinking perhaps I could switch to SWT; but swing is very easy
and I am already sick of UI toolkits in java.

Add all this to the myriad of problems you get with the java
development system; ant was loading the wrong xml parser (which took
forever to figure out), I had the usual newb classpath issues, getting
emacs and slime to work together, and I would say that my overall
experience with the JVM system is very mixed.

/rant

Chris

On Jan 16, 7:05 pm, Brian Carper  wrote:
> On Jan 16, 5:38 pm, levand  wrote:
>
>
>
> > Has anyone here had success in using Clojure with QT Jambi?
>
> > I'm currently experimenting with porting my app from Swing to QT, and
> > although Jambi might well be the theoretically superior framework, it
> > seems like Swing is a lot easier to use with Clojure.
>
> > The issue I'm currently running into is that you can't call any
> > methods on QT gui objects unless you're in the same thread they were
> > created in. But that can't be the Repl thread, because
> > QApplication.exec() basically sets up an event loop and takes control
> > of whatever thread you start it in.
>
> > So, it looks like I can't do any of that cool interactive gui
> > development that I fell in love with in Rich's presentations, and have
> > continued to love using myself.
>
> > Am I missing something? I thought I'd give QT a try, since everyone
> > seems to rave about it, but so far, in most ways, Swing seems easier
> > to use and more powerful. But maybe I'm just not familiar enough with
> > Jambi.
>
> > Many thanks,
> > -Luke
>
> I have had some success writing a little app[1] in Qt Jambi in
> Clojure, for what it's worth.  You can use QCoreApplication/
> invokeLater or invokeAndWait to mess with Qt objects from different
> threads.
>
> I have managed to segfault the JVM while poking a running Qt Jambi app
> from a REPL.  I also had some problems with memory leaks [2] for a
> time.  It's not as stable and solid as Swing.  It works though, and Qt
> is a nice framework to work with.
>
> [1]:http://github.com/briancarper/bcc-clojure/tree/master
> [2]: Most likely this issue: 
> http://www.mail-archive.com/qt-jambi-inter...@trolltech.com/msg00592.html
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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
-~--~~~~--~~--~--~---

Re: Common backend project?

[Matt Revelle]

On Jan 17, 2009, at 1:47 PM, Peter Wolf wrote:

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

This is not entirely correct.  SLIME works by communicating with the  
running Lisp process (in this case, Clojure), essentially all the  
integration between Emacs/SLIME and Clojure is written in Clojure.   
The component of SLIME that runs in the Lisp process is called SWANK.

I recall that a Common Lisp plugin for Eclipse, CUSP, used swank so it  
may be useful environments other than Emacs/SLIME.

The main repo for swank-clojure is: 
http://github.com/jochu/swank-clojure/tree/master

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

Re: Newbie problem

[mbrodersen]

Yes that does indeed fix the problem :-)

Thanks Shawn!

Cheers
Morten

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

Eval with local bindings

[Greg Harman]

Meta: This thread is a revival and continuation of last month's
discussion at:
http://groups.google.com/group/clojure/browse_thread/thread/e1226810b6ac7bfc/8e0f53c141c26fcc?lnk=gst&q=eval+binding#8e0f53c141c26fcc

---

Nathan, did you ever come up with a better way to do this than using a
global var?

One solution is to use (binding), which still requires a global var,
but gives each eval it's own binding of that var:

user=> (def x)
#'user/x
user=> (def expr '(+ x 4))
#'user/expr
user=> (binding [x 3] (eval expr))
7
user=> x
java.lang.IllegalStateException: Var user/x is unbound.
(NO_SOURCE_FILE:0)



--~--~-~--~~~---~--~~
You 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: Eval with local bindings

[Nathan Kitchen]

On Sat, Jan 17, 2009 at 11:06 AM, Greg Harman  wrote:
>
> Meta: This thread is a revival and continuation of last month's
> discussion at:
> http://groups.google.com/group/clojure/browse_thread/thread/e1226810b6ac7bfc/8e0f53c141c26fcc?lnk=gst&q=eval+binding#8e0f53c141c26fcc
>
> ---
>
> Nathan, did you ever come up with a better way to do this than using a
> global var?
>
> One solution is to use (binding), which still requires a global var,
> but gives each eval it's own binding of that var:
>
> user=> (def x)
> #'user/x
> user=> (def expr '(+ x 4))
> #'user/expr
> user=> (binding [x 3] (eval expr))
> 7
> user=> x
> java.lang.IllegalStateException: Var user/x is unbound.
> (NO_SOURCE_FILE:0)

I tried this approach with (binding) and I also tried creating
anonymous functions from the expressions:

(eval (list 'fn '[x] expr))

Creating functions didn't work for me because I used up the PermGen
space in the garbage collector with all the
classes created to implement them. As best I remember, I got the same
outcome with (binding), even though I wasn't creating new functions.

The approach that worked for me was to create my own recursive
evaluation function:

(defn eval-expr [expr]
 (cond
   (seq expr)
 (let [[op & args] expr]
   (apply @(resolve op) (map eval-expr args)))
   (= expr 'x) x
   :else expr))

I'm still using the var x, but it's not inherent to the approach; you
could easily add a map of symbols to values as an additional argument.

-- Nathan

--~--~-~--~~~---~--~~
You 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: Reading non-printing characters in the reader?

[Tom Faulhaber]

Thanks, Steve. I was too lazy to UTSL last night and, as you mention,
this isn't in the docs.

(It turns out I ended up writing a 10-line function that just does
what pr would do by itself :-))

I did learn that I could type ^C into the REPL under emacs by quoting
( \ C-Q C-C ) and then the reader digested it fine.

Also, the \u form expects hex digits for its data, e.g. \u0041 =>
A.

-- Tom

On Jan 17, 6:26 am, "Stephen C. Gilardi"  wrote:
> On Jan 17, 2009, at 2:37 AM, Tom Faulhaber wrote:
>
> > Question: How do I read non-printing characters in the reader?
>
>  From reading src/jvm/clojure/lang/LispReader.java and experimenting,  
> I see that there are at least 3 ways to read such an arbitrary  
> character code with the reader:
>
> - Octal character codes from 0 to 255 (octal 0 to 377) can be entered  
> using a literal of the form "\oddd" (that's a lower case oh followed  
> by up to 3 digits). You can represent the ^C character as \o3 in  
> Clojure source.
>
> - Unicode character codes can be entered using a literal of the form  
> "\u" (that's a lowercase u followed by exactly 4 digits). You can  
> represent the ^C character as \u0003 in Clojure source.
>
> - If you can get the character into the input stream with a leading  
> backslash, the reader does read it properly. This doesn't work for ^C  
> (for me, in an emacs *shell* buffer) because it's interpreted as  
> "quit" before Clojure sees it. (I would imagine it's possible to put  
> the terminal into some kind of "raw" mode so that doesn't happen.) It  
> does work for less consequential characters like ^G.
>
> I don't see these documented on clojure.org/reader which is where I  
> would expect to find the info.
>
> It does appear that Clojure can properly read the characters it prints:
>
>         user=> (with-in-str (pr-str \u0003) (read))
>         \^C
>         user=> (int (with-in-str (pr-str \u0003) (read)))
>         3
>         user=>
>
> (which I did in emacs, which shows a literal ascii 3 as ^C)
>
> --Steve
>
>  smime.p7s
> 3KViewDownload
--~--~-~--~~~---~--~~
You 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: Eval with local bindings

[Greg Harman]

Nathan,

Just to confirm two things in eval-expr:

1. Should seq be seq?
2. It looks like you still need to a. have a global x defined to
evaluate eval-expr and b. need to wrap the call to eval-expr with
binding in order to get a non-global binding for x (let doesn't seem
to do the trick).

-Greg

On Jan 17, 2:15 pm, Nathan Kitchen  wrote:
> On Sat, Jan 17, 2009 at 11:06 AM, Greg Harman  wrote:
>
> > Meta: This thread is a revival and continuation of last month's
> > discussion at:
> >http://groups.google.com/group/clojure/browse_thread/thread/e1226810b...
>
> > ---
>
> > Nathan, did you ever come up with a better way to do this than using a
> > global var?
>
> > One solution is to use (binding), which still requires a global var,
> > but gives each eval it's own binding of that var:
>
> > user=> (def x)
> > #'user/x
> > user=> (def expr '(+ x 4))
> > #'user/expr
> > user=> (binding [x 3] (eval expr))
> > 7
> > user=> x
> > java.lang.IllegalStateException: Var user/x is unbound.
> > (NO_SOURCE_FILE:0)
>
> I tried this approach with (binding) and I also tried creating
> anonymous functions from the expressions:
>
> (eval (list 'fn '[x] expr))
>
> Creating functions didn't work for me because I used up the PermGen
> space in the garbage collector with all the
> classes created to implement them. As best I remember, I got the same
> outcome with (binding), even though I wasn't creating new functions.
>
> The approach that worked for me was to create my own recursive
> evaluation function:
>
> (defn eval-expr [expr]
>  (cond
>    (seq expr)
>      (let [[op & args] expr]
>        (apply @(resolve op) (map eval-expr args)))
>    (= expr 'x) x
>    :else expr))
>
> I'm still using the var x, but it's not inherent to the approach; you
> could easily add a map of symbols to values as an additional argument.
>
> -- Nathan
--~--~-~--~~~---~--~~
You 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?

[lpetit]

I downloaded cusp source code and digged into it a little bit once.

The problem is, I couldn't figure out quickly the detail of the swank
client they implemented, nor did I figure out quickly the detail of
the interface between slime and swank.

I wished there were already a client for swank written in clojure, but
I couldn't find one.

So, there is swank/slime to learn, and there is eclipse IDE plugin
writing to learn.
The former can be bypassed by doing something quick and not-so-dirty.
The latter can't be bypassed !

So I made the choice to dot it iteratively, and concentrate on eclipse
integration first.

At the end of the day, I know I may well have finally faced all the
problems the slime/swank protocol faced and solved them differently.
But sometimes, you have to do the trip yourself to really understand
what it is all about ! :-)


On Jan 17, 8:03 pm, Matt Revelle  wrote:
> On Jan 17, 2009, at 1:47 PM, Peter Wolf wrote:
>
>
>
> > 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.
>
> This is not entirely correct.  SLIME works by communicating with the  
> running Lisp process (in this case, Clojure), essentially all the  
> integration between Emacs/SLIME and Clojure is written in Clojure.  
> The component of SLIME that runs in the Lisp process is called SWANK.
>
> I recall that a Common Lisp plugin for Eclipse, CUSP, used swank so it  
> may be useful environments other than Emacs/SLIME.
>
> The main repo for swank-clojure 
> is:http://github.com/jochu/swank-clojure/tree/master
>
>
>
> > 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
-~--~~~~--~~--~--~---

Re: Eval with local bindings

[Christophe Grand]

Greg Harman a écrit :
> One solution is to use (binding), which still requires a global var,
> but gives each eval it's own binding of that var:
>
> user=> (def x)
> #'user/x
> user=> (def expr '(+ x 4))
> #'user/expr
> user=> (binding [x 3] (eval expr))
> 7
> user=> x
> java.lang.IllegalStateException: Var user/x is unbound.
> (NO_SOURCE_FILE:0)
>   

You also can do something like this:

(defmacro let-eval [vars expr]
  (let [bindings (mapcat #(list (list `quote %) %)  vars)]
`(eval (list 'let [...@bindings] ~expr

(let [x 12]
  (let-eval [x] '(+ x 2))); returns 14

Christophe



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

[Meikel Brandmeyer]

Hi,

Am 17.01.2009 um 20:03 schrieb Matt Revelle:


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


This is not entirely correct.  SLIME works by communicating with the
running Lisp process (in this case, Clojure), essentially all the
integration between Emacs/SLIME and Clojure is written in Clojure.
The component of SLIME that runs in the Lisp process is called SWANK.


Yes. Gorilla also consists basically of some part on the Vim side,
which sends stuff to a Clojure server. That part is written in Clojure.
The result is sent back to Vim.

So stuff like function completion etc. can be easily shared.

Sincerely
Meikel



smime.p7s
Description: S/MIME cryptographic signature

Re: Common backend project?

[lpetit]

On Jan 17, 7:47 pm, Peter Wolf  wrote:
> 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.  

For sure !

But alas, I'm not sure I have sufficient free time to be able to
follow the rythm.
And that's also one of the reasons why I did'nt try to spend time with
others code. If I did so, I wouldn't have produced anything myself
yet :-(

I think we could maybe share the code that manipulates text and does
static parsing. It could be very interesting, because it could also
serve later as the basis for command-line tools for static analysis
(simple refactorings such as renaming, formatting/indenting).
These tools deserve to be written in clojure or java so they can be
easily integrated in any java based IDE, tool (maven, ant, cruise
control, ...).

--
Laurent

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

Re: Common backend project?

[Stuart Sierra]

On Jan 17, 2:03 pm, Matt Revelle  wrote:
> > Tools such as SLIME and (I think) Gorilla, on the other hand, are not
> > written in language that makes sharing easy.
>
> This is not entirely correct.  SLIME works by communicating with the  
> running Lisp process (in this case, Clojure), essentially all the  
> integration between Emacs/SLIME and Clojure is written in Clojure.  
> The component of SLIME that runs in the Lisp process is called SWANK.

Yes.  To be clear: SLIME is written in Emacs Lisp, and is Emacs-
specific.  There are multiple implementations of SWANK for different
Lisps, including Clojure.  SLIME communicates with SWANK via a well-
defined socket interface, see 

swank-clojure  is a little
confusing because it includes both an implementation of SWANK in
Clojure and some SLIME extensions in Emacs Lisp.

swank-clojure could be a place to implement shared-backend features.
Then again, you might not even need to modify swank-clojure.  Since
SWANK can send arbitrary expressions to the Clojure process, you could
implement your introspection/reflection/refactoring features in pure
Clojure (like show, source, javadoc) and just call them through SWANK.

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

[Stuart Sierra]

On Jan 17, 10:25 am, Peter Wolf  wrote:
> 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.

The early beginnings of a test suite are in clojure.contrib.test-
clojure

-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: swank-clojure license

[hughw]

On Dec 31 2008, 6:48 am, lpetit  wrote:
> OOps, I'm losing memory, I answered twice to the e-mail ;-)
>
> On 31 déc, 11:16, lpetit  wrote:
>
> > Yes, this is what I remember from LGPL. But anyway, swank-clojure is
> > not LGPL, it's GPL.


I suspect you can't distribute the swank-clojure files with clojure-
dev :(

The GPL also means developers can't deploy their non-GPL programs to
customer sites if they include the swank files. That is, if you want
to be able to connect to your always-running program at the customer
site, using SLIME, you can't do that unless your program is GPL. Maybe
that is Jeffrey's intent. It's unlike the all the other swank
implementations for the different CLs, which are all in the public
domain.


>
> > I re-read my original post, and it seems clear to me : I stated I wish
> > to embed swank-clojure files into clojure-dev plugin.
>
> > Anyway, I'll rephrase my question differently :
>
> > Given that :
> > - Clojure-dev's (an eclipse plugin I'm a contributor of) license is
> > EPL.
> > - swank-clojure's license is GPL
>
> > Can the following be possible without breaking the GPL ? :
> > - Embed swank-clojure source code in clojure-dev's source management
> > system (svn)
> > - Release clojure-dev as an eclipse plugin (that is a jar with clojure-
> > dev classes, swank-clojure files)
> > Precisions :
> > - There will be no compile-time linkage between clojure-dev code and
> > swank-clojure code.
> > - Clojure-dev will have a new functionality given the user the ability
> > to start (from its eclipse environment) a new java/clojure environment
> > (in a fresh JVM) that will load swank-clojure (from the files
> > distributed with clojure-dev plugin) at startup
> > - Then clojure-dev will be able to communicate with the clojure
> > environment running in the fresh JVM via swank-clojure remote calls
>
> > Maybe this is a no problem.
>
> > Thanks in advance to anybody that will demonstrate it's feasible or
> > it's not feasible,
>
> > --
> > Laurent
>
> > On 30 déc, 23:55, "Mark H."  wrote:
>
> > > On Dec 30, 10:26 am, Phil Hagelberg  wrote:
>
> > > > lpetit  writes:
> > > > > I'm not sure. From what I remember, what you describe is more related
> > > > > to LGPL ?
>
> > > > No, the LGPL allows using the code in another program that is Free but
> > > > not GPL-licensed.
>
> > > Actually the LGPL allows linking to the library (somewhat different
> > > than "using the code") from any program, even one which is not under
> > > an open-source license.  "L" used to stand for "library" and the
> > > canonical example of a LGPL library is GNU's libc:  any program can
> > > link to it, and such linkage doesn't make the program have the same
> > > license as libc.
>
> > > mfh
--~--~-~--~~~---~--~~
You 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: A quasiquote for Clojure?

[Jason Wolfe]

> That's a good idea. It would nicely complement the other
> functions so far. Please find attached a patch.
>
> 1:1 user=> '~x
> (clojure.core/unquote x)
> 1:2 user=> '~...@x
> (clojure.core/unquote-splicing x)
>
> Sincerely
> Meikel

Sweet, thanks Meikel!  Rich, what do you think about integrating this
into the trunk?

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

[lpetit]

Now that's interesting. It may be easier to share code because you too
decided to not follow slime/swank which, I guess, imposes as a middle
language something closer to emacs-lisp than to clojure for the
exchanged data structures.

And we could indeed also share the whole code of the server side.

I'm in the process of refactoring the code (client and server) for
clojuredev.

We have currently one single function, that returns a big map with all
the information for the namespace.
This has allowed me to do a namespace browser for clojuredev :
http://code.google.com/p/clojure-dev/wiki/NamespaceBrowser

--
Laurent


On Jan 17, 8:53 pm, Meikel Brandmeyer  wrote:
> Hi,
>
> Am 17.01.2009 um 20:03 schrieb Matt Revelle:
>
> >> Tools such as SLIME and (I think) Gorilla, on the other hand, are not
> >> written in language that makes sharing easy.
>
> > This is not entirely correct.  SLIME works by communicating with the
> > running Lisp process (in this case, Clojure), essentially all the
> > integration between Emacs/SLIME and Clojure is written in Clojure.
> > The component of SLIME that runs in the Lisp process is called SWANK.
>
> Yes. Gorilla also consists basically of some part on the Vim side,
> which sends stuff to a Clojure server. That part is written in Clojure.
> The result is sent back to Vim.
>
> So stuff like function completion etc. can be easily shared.
>
> Sincerely
> Meikel
>
>  smime.p7s
> 5KViewDownload
--~--~-~--~~~---~--~~
You 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?

[Meikel Brandmeyer]

Hi Stuart,

Am 17.01.2009 um 21:16 schrieb Stuart Sierra:


SLIME communicates with SWANK via a well-defined
socket interface, see 


Hmm.. I looked there before, but I couldn't find a definition
of the interface protocol.


swank-clojure could be a place to implement shared-backend features.
Then again, you might not even need to modify swank-clojure.  Since
SWANK can send arbitrary expressions to the Clojure process, you could
implement your introspection/reflection/refactoring features in pure
Clojure (like show, source, javadoc) and just call them through SWANK.


Unfortunately, I can't use swank due to the restrictions
imposed by the GPL.

Sincerely
Meikel



smime.p7s
Description: S/MIME cryptographic signature

Re: Functional way to implement a VM?

[jim]

Just saw this thread.

It's in my mind to do, but I don't know when I'll get to it.  I've got
a ton of code to write before I get to that item on my TODO list.
However, if there'd be a place to put it on the Clojure page, I'd bump
it to the top.

Jim

On Dec 23 2008, 1:07 am, Konrad Hinsen 
wrote:
> On 22.12.2008, at 22:07, Mark Volkmann wrote:
>
> > Are you and or Jim planning to write an article onmonadsin Clojure
> > any time soon? I'd love to see that. I don't understand them well now.
>
> Where would such an article best be published? I agree that there is  
> an interest in explainingmonadsspecifically in the context of Clojure.
>
> Konrad.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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?

[Meikel Brandmeyer]

Salut Laurent,

Am 17.01.2009 um 21:40 schrieb lpetit:


Now that's interesting. It may be easier to share code because you too
decided to not follow slime/swank which, I guess, imposes as a middle
language something closer to emacs-lisp than to clojure for the
exchanged data structures.


Well. I'm not sure I understand you correctly. The current layout
is as follows:

A Ruby interface in Vim, which extracts data etc. and sends
via the Ruby telnet client simple clojure expressions to some
TCP port.

There a Clojure server listens and simply executes the expressions
in Repl and sends back the result.

There is no real protocol defined at the moment and I'm somewhat
limited with the results, since implementing parser in Vim is no
fun But this simple setup already allows gems like a remote
clojure server or a Repl in a Vim buffer.

At the moment I'm investigating nailgun to eliminate the Ruby
stuff...


And we could indeed also share the whole code of the server side.


That would be a tremendous win. I think interfacing to the IDE/editor
is already quite some work.


I'm in the process of refactoring the code (client and server) for
clojuredev.

We have currently one single function, that returns a big map with all
the information for the namespace.
This has allowed me to do a namespace browser for clojuredev :
http://code.google.com/p/clojure-dev/wiki/NamespaceBrowser


Uh. Nice. I'll give that a try. Let's see whether I can interface
to that.

Sincerely
Meikel



smime.p7s
Description: S/MIME cryptographic signature

fit for contribution to clojure.contrib.ns-utils?

[Dan Larkin]

(defn require-resolve
   [id]
   (let [sym (symbol id)
 ns-symbol (symbol (namespace sym))
 var-symbol (symbol (name sym))]
 (require ns-symbol)
 (ns-resolve (find-ns ns-symbol)
 var-symbol)))

The name is terrible, I know.

You can pass a symbol or a string in fully qualified clojure syntax  
and it returns a clojure.lang.Var, which the caller can "resolve" with  
var-get... maybe this function should call var-get itself... that's up  
for debate.


Adobo:~ dan$ clj
Clojure
(defn require-resolve
   [id]
   (let [sym (symbol id)
 ns-symbol (symbol (namespace sym))
 var-symbol (symbol (name sym))]
 (require ns-symbol)
 (ns-resolve (find-ns ns-symbol)
 var-symbol)))
#'user/require-resolve
user=> (require-resolve "clojure.contrib.def/defvar-")
#'clojure.contrib.def/defvar-
user=> (var-get (require-resolve "clojure.contrib.def/defvar-"))
#
user=> ((require-resolve "clojure.contrib.str-utils/str-join") "," [1  
2 3 4 5])
"1,2,3,4,5"

Stephen, if you think this is something suitable for  
clojure.contrib.ns-utils then I'll submit my CA to Rich and you can  
pull it in, otherwise it's here for anyone to use.
--~--~-~--~~~---~--~~
You 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?

[lpetit]

On Jan 17, 10:05 pm, Meikel Brandmeyer  wrote:
> Salut Laurent,
>
> Am 17.01.2009 um 21:40 schrieb lpetit:
>
> > Now that's interesting. It may be easier to share code because you too
> > decided to not follow slime/swank which, I guess, imposes as a middle
> > language something closer to emacs-lisp than to clojure for the
> > exchanged data structures.
>
> Well. I'm not sure I understand you correctly. The current layout
> is as follows:
>
> A Ruby interface in Vim, which extracts data etc. and sends
> via the Ruby telnet client simple clojure expressions to some
> TCP port.
>
> There a Clojure server listens and simply executes the expressions
> in Repl and sends back the result.
>
> There is no real protocol defined at the moment and I'm somewhat
> limited with the results, since implementing parser in Vim is no
> fun But this simple setup already allows gems like a remote
> clojure server or a Repl in a Vim buffer.
>
> At the moment I'm investigating nailgun to eliminate the Ruby
> stuff...
>
> > And we could indeed also share the whole code of the server side.
>
> That would be a tremendous win. I think interfacing to the IDE/editor
> is already quite some work.
>
> > I'm in the process of refactoring the code (client and server) for
> > clojuredev.
>
> > We have currently one single function, that returns a big map with all
> > the information for the namespace.
> > This has allowed me to do a namespace browser for clojuredev :
> >http://code.google.com/p/clojure-dev/wiki/NamespaceBrowser
>
> Uh. Nice. I'll give that a try. Let's see whether I can interface
> to that.

The code that creates data structure for the namespace browser is
really simple, so instead of pointing you in the svn repo, I'll put it
right after the following explanations.

I've made simple yet powerful (I think :-) choices : when I want to
display data as nodes, every node will be represented as a map. One
key of the map gives the name of the node. By convention, always with
key :name. And for allowing different types (for different behaviour
based on different data types), a :type key by convention.
If the node has children, its corresponding map will have a :children
key, which will be a vector of maps, each map will be a subnode  ...
etc...

Ah, and I've made every value but the children vector strings, to be
sure that it is plain clojure data structure for read/pr

for example :
{ :name "namespaces" :type "namespaces" :children [
  { :name "clojure.core" :type "ns" :children [
{ :name "defn" :type "var" ... key/values from (meta )

Now the code :
;
; support code

(defn- meta-info [v]
  (reduce (fn [m e] (merge m { (first e) (str (second e)) })) {} (meta
v)))

(defn- symbol-info [s]
  (merge { :type "symbol" :name (str s) } (meta-info (find-var s

(defn- var-info [v]
  (merge { :type "var" :name (str v) } (meta-info v)))

(defn- ns-info [n]
  { :name ((comp str ns-name) n)
:type "ns"
:children (apply vector (map #(var-info (second %)) (ns-interns
n))) })

(defn namespaces-info []
  { :name "namespaces" :type "namespaces"
:children (apply vector (map ns-info (all-ns))) })

Regards,

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

[Stuart Sierra]

On Dec 31 2008, 5:16 am, lpetit  wrote:
> I re-read my original post, and it seems clear to me : I stated I wish
> to embed swank-clojure files into clojure-dev plugin.

I do not see a conflict here, provided you do not modify swank-clojure
and clearly indicate that it is under a separate license. But if
you're worried, just don't embed it. Require swank-clojure as a
dependency, and tell users where to download it.  You could even
distribute it from your own site, but in a separate file from clojure-
dev.

-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: swank-clojure license

[Matt Revelle]

On Jan 17, 2009, at 5:03 PM, Stuart Sierra wrote:

>
> On Dec 31 2008, 5:16 am, lpetit  wrote:
>> I re-read my original post, and it seems clear to me : I stated I  
>> wish
>> to embed swank-clojure files into clojure-dev plugin.
>
> I do not see a conflict here, provided you do not modify swank-clojure
> and clearly indicate that it is under a separate license.

And you can modify it, but any modifications need to adhere to the  
GPL.  In other words, if you distribute a modified version of swank- 
clojure you must make the source code available and release your  
changes under the GPL.

Since swank-clojure runs as a separate program, there is no problem  
incorporating it in your project as long as you don't have a problem  
with distributing the swank-clojure portion according to the GPL.  In  
other words, you can license your IDE integration code however you  
want and still use swank-clojure.

> But if
> you're worried, just don't embed it. Require swank-clojure as a
> dependency, and tell users where to download it.  You could even
> distribute it from your own site, but in a separate file from clojure-
> dev.
>
> -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: Common backend project?

[Bill Clementson]

Hi Meikel,

On Sat, Jan 17, 2009 at 12:47 PM, Meikel Brandmeyer  wrote:
> Hi Stuart,
>
> Am 17.01.2009 um 21:16 schrieb Stuart Sierra:
>
>> SLIME communicates with SWANK via a well-defined
>> socket interface, see 
>
> Hmm.. I looked there before, but I couldn't find a definition
> of the interface protocol.

To better understand the SLIME/SWANK communications protocol, you can:

1. Read the source code (search for "Communication protocol" in
slime.el and read the code from that point)
2. Look at Tobias Rittweiler's excellent SLIME presentation
(http://trittweiler.blogspot.com/2008/12/last-wednesday-i-gave-talk-to-munich.html)
3. Examine the contents of the *slime-events* buffer in Emacs (it
contains the actual exchanges between the SLIME/SWANK components)

My recent SLIME blog post has a lot of links to other material that
you might find useful: http://bc.tech.coop/blog/081209.html

--
Bill Clementson

--~--~-~--~~~---~--~~
You 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: fit for contribution to clojure.contrib.ns-utils?

[Stephen C. Gilardi]

On Jan 17, 2009, at 4:11 PM, Dan Larkin wrote:


(defn require-resolve
  [id]
  (let [sym (symbol id)
ns-symbol (symbol (namespace sym))
var-symbol (symbol (name sym))]
(require ns-symbol)
(ns-resolve (find-ns ns-symbol)
var-symbol)))

The name is terrible, I know.


Hi Dan,

That's interesting. I've given it some thought and I've come to see it  
as a version of resolve that tries harder than the default. Here's an  
implementation that makes its capabilities purely a superset of those  
of resolve. This version works well even with definitions that don't  
come from libs like those in clojure.core:


(defn resolve*
  [sym]
  (let [ns (namespace sym)
name (name sym)
ns (if ns (symbol ns) (ns-name *ns*))
name (symbol name)]
(or (and (find-ns ns) (ns-resolve ns name))
(do
  (require ns)
  (ns-resolve ns name)

This version takes a symbol just like resolve does. It doesn't support  
passing in a string. I think any string to symbol transformation is  
easy one for a caller to make if it needs to. I had an interim version  
that supported separating the namespace and name into two arguments,  
but that would be more like ns-resolve* and resolve* is every bit as  
capable.


I'm interested in hearing any thoughts you may have on this version as  
it relates to the problem you're trying to solve. I like that in  
Clojure we now have a canonical way to load in a namespace definition:  
require. This idea of yours leverages that. Together with that, we  
also have a canonical way for one namespace to declare and satisfy its  
dependence on another: (ns (:require...)). Given those two facilities,  
I wonder what use case you envision for require-resolve (or resolve*).  
Is this intended to be used at the repl? Does it offer a compelling  
advantage for some kind of work over calling require directly and then  
letting the default symbol resolution mechanism do the work?


Stephen, if you think this is something suitable for  
clojure.contrib.ns-utils then I'll submit my CA to Rich and you can  
pull it in, otherwise it's here for anyone to use.


I think it's interesting experimental code. Please do send in a CA and  
let's get something like this into ns-utils.


--Steve



smime.p7s
Description: S/MIME cryptographic signature

repl-utils show

[pc]

This is very useful. For me it was useful to be able to limit the
output to lines that contained a few selected letters.

(show String "pper")
===  public final java.lang.String  ===
[82] toUpperCase : String ()
[83] toUpperCase : String (Locale)
nil

I could always C-C C-O to flush the long output, but I still
had to look through it. The change is obvious, but I'll copy it in
anyway. If you do change it, I can learn how to do it right. Thanks
again.

(defn show
  "With one arg, lists all static and instance members of the given
  class, or the class of the given object.  Each entry is listed with
  a number.  Use that number as the second argument, and that member
  will be returned which at the REPL can be used to get  more detail
  Use a String as the second argument to limit output to strings
  that contain the second argument.

  Examples: (show Integer)  (show [])  (show String 23) (show String
substr)"
  ([x] (show x nil))
  ([x int-or-str]
  (let [c (if (class? x) x (class x))
items (sort (for [m (concat (.getFields c)
(.getMethods c)
(.getConstructors c))]
  (member-vec m)))]
(if (instance? Number int-or-str)
  (last (nth items int-or-str))
  (do
(println "=== " (Modifier/toString (.getModifiers c)) c "
===")
(doseq [[i e] (indexed items)]
(if (or (nil? int-or-str) (.contains (second e) int-or-str))
  (printf "[%2d] %s\n" i (second e)


--~--~-~--~~~---~--~~
You 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: fit for contribution to clojure.contrib.ns-utils?

[Dan Larkin]

On Jan 17, 2009, at 6:29 PM, Stephen C. Gilardi wrote:
>
> Hi Dan,
>
> That's interesting. I've given it some thought and I've come to see  
> it as a version of resolve that tries harder than the default.  
> Here's an implementation that makes its capabilities purely a  
> superset of those of resolve. This version works well even with  
> definitions that don't come from libs like those in clojure.core:
>
> (defn resolve*
>  [sym]
>  (let [ns (namespace sym)
>name (name sym)
>ns (if ns (symbol ns) (ns-name *ns*))
>name (symbol name)]
>(or (and (find-ns ns) (ns-resolve ns name))
>(do
>  (require ns)
>  (ns-resolve ns name)
>
> This version takes a symbol just like resolve does. It doesn't  
> support passing in a string. I think any string to symbol  
> transformation is easy one for a caller to make if it needs to. I  
> had an interim version that supported separating the namespace and  
> name into two arguments, but that would be more like ns-resolve* and  
> resolve* is every bit as capable.

Hi Stephen,

Yes, you're right, this does make sense as a superset of clojure.core/ 
resolve -- also resolve* is a name that fits much better.

>
>
> I'm interested in hearing any thoughts you may have on this version  
> as it relates to the problem you're trying to solve. I like that in  
> Clojure we now have a canonical way to load in a namespace  
> definition: require. This idea of yours leverages that. Together  
> with that, we also have a canonical way for one namespace to declare  
> and satisfy its dependence on another: (ns (:require...)). Given  
> those two facilities, I wonder what use case you envision for  
> require-resolve (or resolve*). Is this intended to be used at the  
> repl? Does it offer a compelling advantage for some kind of work  
> over calling require directly and then letting the default symbol  
> resolution mechanism do the work?

I like how you phrase that.  Yes, you're correct, for dependencies you  
can identify at coding time (ns (:require ..)) works just fine, but  
for runtime-introduced dependencies a (require ...) is necessary.

My first use case is a "settings file".  The settings file (clojure  
code itself) defines a bunch of settings (duh) which include  
middleware functions, "template loader" functions (and more to come  
for sure).  So without resolve* there are two options:

 1) Import all of the functions to which I need to refer and then  
identify them directly.
 2) Give a two-tuple with namespace and var symbols, which can  
then be (require ..) and (ns-resolve ..)'d later on.

So basically option #1 sucks and #2 is just a more verbose version of  
using resolve*.


My second use case is an url-dispatching system.  It's a port (mostly  
-- java's regex doesn't have named groups and clojure doesn't have  
keyword arguments) of django's url dispatching system.  Basically you  
define a list of regexes and which function you want to be called when  
the url matches that regex.

So it's the same conundrum as with the settings file, really.  Either  
I can require all of the functions I want to call or give two-tuples  
of namespace and var -- or use require*


>
>
>> Stephen, if you think this is something suitable for  
>> clojure.contrib.ns-utils then I'll submit my CA to Rich and you can  
>> pull it in, otherwise it's here for anyone to use.
>
> I think it's interesting experimental code. Please do send in a CA  
> and let's get something like this into ns-utils.
>
> --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: Synchronization Benchmarks

[Stu Hood]

I added a Clojure implementation based on an Atom instead of a Ref,
and re-ran the tests (this time on a quad core machine). I also fixed
the calculation of the percent change in both tests (ugh).

It looks like using an Atom is slightly more performant than a Ref if
you are making a single state change that is commutative/indempotent.
Also, RWDict fell apart on a quad core machine (independent of the
number of writes): I'll try with the alternative fairness setting like
you suggested.

Thanks,
Stu

On 1/16/09, Christian Vest Hansen  wrote:
>
> Another thing you might want to test is the fairness of the rw-lock in
> your RWDict, because even a couple of very active readers can easily
> starve out any number of writers when the rw-lock is non-fair. The
> reason is simple: readers can interleave but writers cannot, and
> writers can only get in when noone is reading :)
>
> On Fri, Jan 16, 2009 at 4:21 AM, Stu Hood  wrote:
>>> Ah! but a mere hash table is not bi-directional :-)
>> Right =)  I got the idea in a Channel 9 video about MS' efforts with STM:
>> http://channel9.msdn.com/shows/Going+Deep/Software-Transactional-Memory-The-Current-State-of-the-Art/
>> (which reminds me, the spin-lock approach they try is probably fairly
>> close
>> to using an Atom in Clojure).
>>
>> I made the changes that Christophe suggested, and added type hints for the
>> HashMaps used in CLJDict, and the speed improvement is very impressive. To
>> see the scalability of the different approaches, I graphed with various
>> numbers of threads and read percentages:
>> http://github.com/stuhood/clojure-conc/tree/master/results
>>
>> Two conclusions:
>>  1. The overhead for STM with low contention is very reasonable,
>>  2. Optimism + MVCC + persistence fall down when faced with a majority of
>> writes. (see the 100% write case in the writes graph.)
>>
>> Thanks,
>> Stu
>>
>>
>> On Thu, Jan 15, 2009 at 2:52 PM, Christian Vest Hansen
>>  wrote:
>>>
>>> On Thu, Jan 15, 2009 at 8:47 PM, Christian Vest Hansen
>>>  wrote:
>>> > On Thu, Jan 15, 2009 at 8:35 PM, Mark H. 
>>> > wrote:
>>> >> On Jan 15, 1:38 am, stuhood  wrote:
>>> >>> The benchmark contains 4 bi-directional dictionary implementations:
>>> ...
>>> >>
>>> >> Doesn't Java already have a more optimized thread-safe hash table that
>>> >> works by locking individual buckets, rather than the whole table?
>>> >> Maybe I'm just confused ;-P
>>>
>>> Ah! but a mere hash table is not bi-directional :-)
>>>
>>>
>>> --
>>> Venlig hilsen / Kind regards,
>>> Christian Vest Hansen.
>>>
>>>
>>
>>
>> >
>>
>
>
>
> --
> 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
To unsubscribe from 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: Macros in interaction with Functions

[Daniel Jomphe]

Stuart Sierra wrote:

> > - The reader performs a few substitutions, then gives the resulting
> > code to the compiler.
> > - The compiler starts by expanding macros into their substitution.
> > --- Thus, for functions, there's no such thing as macros.
> > --- Thus, all that functions see of macros is what came out of macros'
> > complete expansion.
> > --- Therefore, like Timothy Pratley wrote so well, a function can have
> > for parameter a macro call, but not a macro itself.
>
> All correct up to this point.
>
> > - After macro expansion, the compiler starts compiling all functions
> > in need of being compiled, including the functions modified during
> > macro expansion.
>
> Sort of.  What's really getting compiled are just the function calls.
> The functions themselves were compiled back when they were defined.

Ok, so do we have: read => macro-expand => compile-definitions =>
compile-calls? So that when new code is read, if it contains function
definitions, they'll get compiled before their call(s) is compiled?

Stuart and Konrad respectively said:

> [...] "and" doesn't know how many arguments it's going to get.
> If you look at the definition of "and", you'll see that it takes a
> variable number of arguments and it is recursive. So if you tried to
> expand it before knowing the length of the argument list, you would
> get an infinite loop.

> > > The universal workaround is to define a
> > > function that contains nothing but the macro, such as
> > > (fn [x y] (and x y))
> > > which can also be written in Clojure using the shorthand notation
> > > #(and %1 %2)

Ok!! So *that* would explain why wrapping 'and' *this* way enables it
to be an argument to a function call in (reduce #(and % %2): it
becomes clear how many args are going to be given to 'and's call. Wow,
thanks for such clarity!


--~--~-~--~~~---~--~~
You 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: Mysterious performance anomalies

[Mark H.]

On Jan 16, 6:47 am, e  wrote:
> Is it much much easier to make byte code than assembly code?

I'll chime in too to say that x86 is only king of the desktop / laptop
world -- many portable devices are ARM-based (and a lot of Windows
apps run on ARM), and there are other architectures used for
enterprise and HPC servers.  Plus it's not clear to me that x86 will
win, esp. in power-constrained arenas.  (All those legacy instructions
and the translation from x86 ops into reasonable microops eat power
and area.)  I've dealt with at least six different instruction sets in
my HPC work and the JVM runs on at least five of them:  instant
portability!

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