Re: [ANN] core.rrb-vector 0.1.0 -- bug fixes

[Terje Dahl]

Thanks.  Yes, I already do that.

And then implementing java.lang.CharSequence (for regex searches) or a 
reader is dead easy.

Also, because altered states of the rrb-vector share structure, maintaining 
a history (for UNDO/REDO) in a memory-efficient manner is simply a matter 
of holding on to references to the rrb-vector.  

:-)

Terje

On Wednesday, October 2, 2019 at 3:53:13 PM UTC+2, Andy Fingerhut wrote:
>
> Also, maybe you are doing this already, but note that you can save 
> significant memory in Clojure and core.rrb-vector by using (vector-of :char 
> ...) to create vectors that are restricted to contain only char's, if that 
> is all you want to hold inside of them.  It is about a 3x more memory if 
> you use a normal Clojure vector of arbitrary Object's because of the boxing 
> of Character objects.  Same for :long and other vectors of primitives.
>
> Andy
>
> On Wed, Oct 2, 2019 at 6:31 AM Andy Fingerhut  > wrote:
>
>> Excellent!  Please do file additional reports if you find any issues with 
>> the latest version.
>>
>> Andy
>>
>> On Wed, Oct 2, 2019 at 2:27 AM Terje Dahl > > wrote:
>>
>>> Nice list of fixes. Great work!
>>>
>>> I use Vector as my text editor's char-buffer. 
>>> I believe I have seen one or more of the fixed bugs surface, so I am 
>>> upgrading immediately. :-D
>>>
>>>
>>> Terje 
>>>
>>>
>>> On Monday, September 30, 2019 at 10:21:05 PM UTC+2, Andy Fingerhut wrote:
>>>>
>>>> I am pleased to announce the 0.1.0 release of core.rrb-vector, a 
>>>> Clojure Contrib library extending the Clojure vector API with 
>>>> logarithmic-time concatenation and slicing:
>>>>
>>>>   https://github.com/clojure/core.rrb-vector
>>>>
>>>>   [org.clojure/core.rrb-vector "0.1.0"]
>>>>
>>>>   
>>>> org.clojure
>>>> core.rrb-vector
>>>> 0.1.0
>>>>   
>>>>
>>>> This release fixes several bugs that were found in previous releases of 
>>>> the library.  More details can be found in the change log:
>>>>
>>>>   https://github.com/clojure/core.rrb-vector/blob/master/CHANGES.md
>>>>
>>>> Cheers,
>>>> Michał Marczyk and Andy Fingerhut
>>>>
>>> -- 
>>> 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
>>> clo...@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 clo...@googlegroups.com .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/clojure/cfed16b8-e941-45f3-95c1-3261e19e8340%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/clojure/cfed16b8-e941-45f3-95c1-3261e19e8340%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
You 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/f7e24ab6-a9b1-4759-a7a3-b30a7da0ddef%40googlegroups.com.

Re: [ANN] core.rrb-vector 0.1.0 -- bug fixes

[Terje Dahl]

Nice list of fixes. Great work!

I use Vector as my text editor's char-buffer. 
I believe I have seen one or more of the fixed bugs surface, so I am 
upgrading immediately. :-D


Terje 


On Monday, September 30, 2019 at 10:21:05 PM UTC+2, Andy Fingerhut wrote:
>
> I am pleased to announce the 0.1.0 release of core.rrb-vector, a Clojure 
> Contrib library extending the Clojure vector API with logarithmic-time 
> concatenation and slicing:
>
>   https://github.com/clojure/core.rrb-vector
>
>   [org.clojure/core.rrb-vector "0.1.0"]
>
>   
> org.clojure
> core.rrb-vector
> 0.1.0
>   
>
> This release fixes several bugs that were found in previous releases of 
> the library.  More details can be found in the change log:
>
>   https://github.com/clojure/core.rrb-vector/blob/master/CHANGES.md
>
> Cheers,
> Michał Marczyk and Andy Fingerhut
>

-- 
You 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/cfed16b8-e941-45f3-95c1-3261e19e8340%40googlegroups.com.

Re: Validate XSD 1.1

[Terje Sten Bjerkseth]

For Leiningen, you can install the jar into your local 
Maven: 
https://stackoverflow.com/questions/20819060/xml-validation-against-xsd-1-1-with-xerces-in-java

For the new deps and CLI tools, you can directly use a local 
jar: https://clojure.org/guides/deps_and_cli#local_jar.

torsdag 31. mai 2018 13.26.32 UTC+2 skrev Stephen Feyrer følgende:
>
> Interesting read...  Prompts the question is there an alternative way to 
> pull the library raw into a Leiningen project?
>
> I have tested and this library works.
>
>
>
> On Thursday, 31 May 2018 02:20:58 UTC+1, Matching Socks wrote:
>>
>> (A fun and enlightening discussion is here: 
>> https://issues.apache.org/jira/browse/XERCESJ-1454 --- about whether to 
>> post Xerces on Maven Central.)
>>
>>

-- 
You 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/d/optout.

Re: hello world question !!!

[terje]

Damien: A good starting point for a simple web server might be to use

lein new pedestal-service

Then you can do lein uberjar to get a jar ready to run. Or check the README 
for running local dev with a local REPL.

If instead you want a WAR, you can switch from pedestal.jetty to 
pedestal.immutant in project.clj and add the Immutant plugin:

:plugins [[lein-immutant "2.1.0"]]

Then do a lein immutant war to get your WAR for deployment to e.g. WildFly 
10.

If you also want a nREPL to repl directly into the running server, have in 
project.clj e.g.:

:plugins [[lein-immutant "2.1.0"] [cider/cider-nrepl "0.15.1"]]
:immutant {:war {:nrepl {:port }}}

and do a lein immutant war --nrepl-start when making your WAR (check your 
security on the nREPL port).

Cheers,
Terje

(Haven't looked at WildFly 11 RC yet and don't know if Immutant works with 
it. Considering moving some of our services from WildFly to separate Jetty 
services instead, but WildFly 10 has worked very well.)



søndag 15. oktober 2017 10.43.36 UTC+2 skrev Damien Mattei følgende:
>
> thanks for the answers and comments of John, James and others,
> the discussion has opened many aspect of web application development and 
> it is is positive.
>
> about the IDE, i'm not using Netbeans with Scheme or LisP exclusively, in 
> fact Netbeans was used in the office just to create web service in Java,
> this thing can be done by hand in command line too, Kawa Scheme also can 
> do it itself :
>  https://www.gnu.org/software/kawa/Servlets.html
>
> from the discussion i see now many solution to test ,I will install 
> Leiningen, also i see in the doc of Immutant that it is possible to 
> generate some war files :
> http://immutant.org/documentation/current/apidoc/guide-wildfly.html#h3386
>
> i hope i could use Clojure for that because it seems a really fun and 
> solid LisP dialect.
> I will post updates when i have a concrete usable solution.
>
> Regards,
>
> Damien
>
> On Saturday, October 14, 2017 at 5:07:08 PM UTC+2, John M. Switlik wrote:
>>
>> James, 
>>
>> Thanks. I saw a writeup mentioning Leiningen that I will go back to. 
>>
>> It is not the 'toy' issue that concerns me. It is that all sorts of 
>> browsers exist as well as a whole slew of different types of users. And, if 
>> I am going to push something down to a remote device, I want to expect that 
>> it would be handled in a nice manner. 
>>
>> As for example projects, these are prime; but, they are supported by 
>> working professionals. So, Clojure does have a lot to offer. 
>>
>>http://base2s.com/work/ 
>>
>> I am sure that I'll look back and see that it was easy. But, this seems 
>> like an opportunity to step through the thing (that is, the hugely 
>> complicated world of the muddy cloud) and see how things evolved. Those 
>> little interpreters are up there as a lure in the meantime. 
>>
>> Cheers, 
>> John
>>
>

-- 
You 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/d/optout.

Re: No :out in my nREPL responses

[Terje Dahl]

Hey, Collin.

By "standard" REPL I mean "clojure.main REPL in JVM" - which worked fine.
I don't think my issue has anything to do with Cursive's way of connecting 
to nREPL, but rather with nREPL itself, seeing as had the same problem in a 
terminal window running `lein repl`.

Terje 


On Friday, March 17, 2017 at 2:11:11 AM UTC+1, Colin Fleming wrote:
>
> Hi Terje,
>
> When you say the "standard" REPL in Cursive, are you referring to the "Use 
> nREPL in normal JVM process" option, or the "Use clojure.main in normal JVM 
> process" option? Obviously the first does use nREPL, but doesn't go through 
> lein - Cursive just runs a JVM process, starts a bare-bones nREPL server in 
> it and connects to it. If you haven't tried that option, it might be worth 
> trying to see if the issue is in nREPL or in lein.
>
> Cheers,
> Colin
>
> On 17 March 2017 at 11:05, Terje Dahl <te...@terjedahl.no > 
> wrote:
>
>> UPDATE:
>> I only just discovered: 
>> It *does* work as expected when I run it from the "standard" REPL in JVM 
>> (in IntelliJ/Cursive),
>> And it *does* work as expected when I run it in my own "home grown" REPL 
>> stack.
>> It does *not* work as expected when running it in any variant of nREPL - 
>> including:
>>  - Through IntelliJ/Cursive
>>  - In command-line via `lein repl` (which is simply nREPL)
>>
>> So I have a potential solution, (and a possible nREPL bug), but it would 
>> be valuable to understand the cause of the issue.
>>
>>
>>
>> On Thursday, March 16, 2017 at 10:24:21 PM UTC+1, Terje Dahl wrote:
>>>
>>> I am attempting to embed an nREPL server in my application (version 
>>> 0.2.12).  Everything seems to work nicely, except I am not able to get any 
>>> out from print statements et al.  Even the basic example on the README 
>>> "(time (reduce + (range 1e6)))" doesn't work for me: I do not get back the 
>>> map containing the :out, but I get the two remaining.
>>>
>>> After two days of studying the source code of tools.nrepl (including the 
>>> testing code),  leiningen.repl, reply, and a myriad of things online, I am 
>>> getting rather frustrated.
>>>
>>> It seems to maybe have something to do with *out*, but I can't figure it 
>>> out. Any hints at debugging it will be much appreciated.
>>>
>>> Also, any resources for "tool makers" would be of interest.
>>>
>> -- 
>> 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/d/optout.
>>
>
>

-- 
You 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/d/optout.

Re: No :out in my nREPL responses

[Terje Dahl]

UPDATE:
I only just discovered: 
It *does* work as expected when I run it from the "standard" REPL in JVM 
(in IntelliJ/Cursive),
And it *does* work as expected when I run it in my own "home grown" REPL 
stack.
It does *not* work as expected when running it in any variant of nREPL - 
including:
 - Through IntelliJ/Cursive
 - In command-line via `lein repl` (which is simply nREPL)

So I have a potential solution, (and a possible nREPL bug), but it would be 
valuable to understand the cause of the issue.



On Thursday, March 16, 2017 at 10:24:21 PM UTC+1, Terje Dahl wrote:
>
> I am attempting to embed an nREPL server in my application (version 
> 0.2.12).  Everything seems to work nicely, except I am not able to get any 
> out from print statements et al.  Even the basic example on the README 
> "(time (reduce + (range 1e6)))" doesn't work for me: I do not get back the 
> map containing the :out, but I get the two remaining.
>
> After two days of studying the source code of tools.nrepl (including the 
> testing code),  leiningen.repl, reply, and a myriad of things online, I am 
> getting rather frustrated.
>
> It seems to maybe have something to do with *out*, but I can't figure it 
> out. Any hints at debugging it will be much appreciated.
>
> Also, any resources for "tool makers" would be of interest.
>

-- 
You 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/d/optout.

No :out in my nREPL responses

[Terje Dahl]

I am attempting to embed an nREPL server in my application (version 
0.2.12).  Everything seems to work nicely, except I am not able to get any 
out from print statements et al.  Even the basic example on the README 
"(time (reduce + (range 1e6)))" doesn't work for me: I do not get back the 
map containing the :out, but I get the two remaining.

After two days of studying the source code of tools.nrepl (including the 
testing code),  leiningen.repl, reply, and a myriad of things online, I am 
getting rather frustrated.

It seems to maybe have something to do with *out*, but I can't figure it 
out. Any hints at debugging it will be much appreciated.

Also, any resources for "tool makers" would be of interest.

-- 
You 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/d/optout.

Version control at the function level - a la Rich

[Terje Dahl]

I recall Rich Hickey talking about this a few years back, but can't find 
anything about it.  
Am I just imaging it?
Or could someone point me in the right direction

-- 
You 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/d/optout.

Re: [ANN] 2016 State of Clojure Community Survey

[Terje Norderhaug]

Should've been a separate question for choice of rank order... :-)

On Tue, Dec 13, 2016 at 7:49 AM, Colin Yates  wrote:

> Oh the joys of a lack of a ubiquitous language :-). I was only
> surprised it didn't start at 0 ;-).
>
> On 13 December 2016 at 15:46, Jose Figueroa Martinez 
> wrote:
> > Me too :-|
> >
> >
> > El martes, 13 de diciembre de 2016, 2:44:08 (UTC-6), Patrick Kristiansen
> > escribió:
> >>
> >> On Tuesday, December 13, 2016 at 2:00:10 AM UTC+1, Mike Rodriguez wrote:
> >>>
> >>> Uh oh. I should have asked. I ranked my priorities in the exact
> opposite
> >>> order since I thought 1 was lowest.
> >>
> >>
> >> I did too.
> >
> > --
> > You 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/d/optout.
>
> --
> You 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/d/optout.
>

-- 
You 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/d/optout.

Re: [ANN] New Clojure Podcast: defn

[Terje Dahl]

Loved it.  Very good start.
Looking forwards to your discussion on Reader.



On Thursday, May 19, 2016 at 7:43:44 AM UTC+2, Vijay Kiran wrote:
>
> Hello Everyone,
>
> Just wanted to let you know that we started a new podcast about Clojure: 
> https://defn.audio
>
> We published our first episode and plan to release a new one every two 
> weeks. It is available on iTunes 
> https://itunes.apple.com/podcast/defn/id1114899563 and SoundCloud: 
> https://soundcloud.com/defn-771544745
>
> You can also get the RSS feed via 
> http://feeds.soundcloud.com/users/soundcloud:users:220484243/sounds.rss
>
> We'd appreciate if you can tune in and give us some feedback!
>
> Thanks for listening,
> Vijay & Ray
>

-- 
You 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/d/optout.

Re: [ANN] ClojureCL now supports Linux, Windows and OS X (GPGPU and high performance parallel computing)

[Terje Dahl]

YESS!  
Just what I wanted to try.  Now to figure out how to use this to do lots of 
FFT (on audio) in parallel.


On Wednesday, May 18, 2016 at 1:37:50 AM UTC+2, Dragan Djuric wrote:
>
> http://clojurecl.uncomplicate.org
>
>
> https://www.reddit.com/r/Clojure/comments/4jtqhm/clojurecl_gpu_programming_now_works_on_linux/
>
> ClojureCL is a library for OpenCL high-performance numerical computing 
> that supports GPU and CPU optimizations.
>
> ClojureCL supports OpenCL 2.0 and 1.2 standards.
>
> Major news is that now it works out of the box on all major operating 
> systems (if you have installed the drivers for your GPU, of course).
>
>

-- 
You 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/d/optout.

Listening to changes of/in namespaces

[Terje Dahl]

Stuart Halloway asks:  Clojure namespace change watcher [..]? 


Any ideas/suggestions on how one might listen for changes to namespaces in 
the runtime itself?
(Similar to add-watch for atoms.)

I am working on a solution for dumping/storing, and reloading the state of 
a Clojure runtime, and I would like some way of being notified if:
1. A namespace has been added or removed.
2. If something has been interned, referred, aliased, imported in a 
namespace (or removed).
3. If a Var has been changed.

A partial solution is better than nothing.



-- 
You 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/d/optout.

Re: Clojure as first language

[Terje Dahl]

Thank you all for your wonderful feedback.
It is both insightful, varied, deep.

I intend to consolidate your feedback and more into some sort of report or 
paper which I will then publish.
I will post back when I have something ready.


Terje

-- 
You 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/d/optout.

Re: Clojure as first language

[Terje Dahl]

Lee.

About the confusion with parens - do you mean that an output-ed list/seq 
looks exactly like a callable s-expression?
Please elaborate.

Terje


On Sunday, February 21, 2016 at 5:23:42 PM UTC+1, Lee wrote:
>
>
> One little feature of the core language itself that I find to be difficult 
> for beginners is the way that regular parentheses () are used in printed 
> values for different data types... But I know this can't change, and I 
> don't know if anything can be done to make that less confusing.
>
>

-- 
You 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/d/optout.

Re: Clojure as first language

[Terje Dahl]

Val.

You (and others) mention Clojure Bridge.
I am familiar with the concept.
But do you know where I might find one or more compendiums or course 
curriculums used as part of Clojure Bridge?

Terje


On Sunday, February 21, 2016 at 12:45:52 PM UTC+1, Val Waeselynck wrote:
 

> And of course, let's not forget about Clojure Bridge 
> <http://www.clojurebridge.org/>!
>

-- 
You 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/d/optout.

Re: Clojure as first language

[Terje Dahl]

Elango.


The turtle graphics concept is often used as a basic teaching tool.  Logo, 
Scratch, etc.
It seems easy to understand for children, and is a good way to get started.

I have some additional questions to that, though:
How long before children get tired (bored) with the concept?
How would one move on from Turtle graphics?
What other concepts or paradigms might also be used?
Are there other different approaches that might work equally well (or 
better)?
Any personal ideas/suggestions?

Terje


On Sunday, February 21, 2016 at 10:31:27 PM UTC+1, Elango wrote:
 

> You should also look at clojure-turtle, which is a port of Logo into 
> Clojure:
> https://github.com/google/clojure-turtle
>
> We often use Logo to teach kids how to program for the first time, and 
> Logo is a Lisp (!).  Logo has reinforced its relevance with Scratch, which 
> is a GUI-based, less-textual version of Logo.  So we should be able to 
> connect Logo to Clojure without too much contortion, and we should also be 
> able to use the turtle graphics paradigm to teach kids & beginners Clojure. 
>  
>
> Those are the motivations for the clojure-turtle project.  
>

-- 
You 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/d/optout.

Re: Clojure as first language

[Terje Dahl]

Michael.

I what ways do the teaching languages in Racket differ from Clojure?
What would *you* "hide" or change in Clojure to make a more suitable 
teaching language?
Based on the Racket languages...
Based on your experiences and/or opinions...


Terje


On Monday, February 22, 2016 at 8:55:13 AM UTC+1, Michael Sperber wrote:
 

> tl;dr: No, Clojure is not an ideal language for teaching beginners.  For 
> teaching beginners, you should use a language specifically engineered 
> for beginners, such as the teaching languages that come with Racket. 
> (The transition to Clojure from these languages should be quite easy, 
> though.) 
>

-- 
You 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/d/optout.

Re: Clojure as first language

[Terje Dahl]

Blake.

Would you elaborate on this last comment about Smalltalk?
What did you do?
What was the outcome relative to expectations?
What were some good and bad aspects of Smalltalk?
And how might this compare to Clojure?
Any links/references?

Terje


On Thursday, February 25, 2016 at 9:29:10 PM UTC+1, blake watson wrote:
 

> I've had good luck with Smalltalk.
>

-- 
You 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/d/optout.

Clojure as first language

[Terje Dahl]

I believe that the simplicity of Clojure's syntax in combination with its 
clean functional nature and prefix notation makes it ideal as a "first 
language" for anyone who wants to start programming - including, and 
perhaps especially kids.

Is there anything written about this? 
Arguments ... experiences ... perhaps even research ...?

-- 
You 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/d/optout.

Re: defrecord == premature optimization?

[Terje Dahl]

To comment my own question some years and a bit of experience later:
I would say that, just like with type-hinting: hold of as long as possible.
Only when you find yourself adding to a map something like: {:type Person} 
is it time to consider using a Record in stead. And of course also if you 
would like to dispatch on type (defprotocol / defmethod).



On Monday, September 5, 2011 at 3:46:37 PM UTC+2, Terje Dahl wrote:
>
> Ref:  Stuart Halloway's talk: "Simplicity": 
>
> http://blip.tv/clojure/stuart-halloway-simplicity-ain-t-easy-4842694 
>
> Found via reading list: http://clojure.com/reading.html ) 
>
> At one point in his talk he states that defrecord is in fact basically 
> "documented, named [typed] structure". 
> (as opposed to a standard map). 
> This I thought was quite genius. 
>
> But on further reflection I wonder if: 
>
> A: Doesn't this contradict another Clojure rationale: 
> "It is better to have 100 functions operate on one data structure than 
> to have 10 functions operate on 10 data structures." - Alan J. 
> Perlis   http://clojure.org/rationale 
>
> B: Is this not a form of optimization - (which may be premature)? 
>
> C: Is it best to use records only within an aplication, but to export 
> to generic maps when "serializing" data to a string og stream for 
> communication or storage ... 
> Is this the best way to "serialize" a record?: 
>(into {} intance-of-my-record) 
> Would you "desiralize" it with a custom function like this? 
>   (fn [{key1 :key1, key2 :key2}] (MyRecord. key1 key2))  (calling it 
> like this: (my-fn map-to-be-destructure-and-recordfied) 
>
>
>
>

-- 
You 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/d/optout.

Splitting Read into 2 steps?

[Terje Dahl]

I have been studying and and implementing my own version of LispReader / 
tool.reader - for the purpose of syntax highlighting and visual token 
manipulation.
My question is this:
Why not split this into 2 steps?

   1. Reads the input (from PushbackReader et al) and emits a stream of 
   tokens, preserving information about location in source, and applying 
   typing to tokens, if possible.
   2. Consumes the stream from step one, descending recursively, applying 
   reader-macros, resolving symbols in name-spaces, etc.
   
This would allow for easier configuration of each step, such as:

   - turning exceptions on/off (useful for syntax highlighting)
   - custom reader-macros and custom classes of reader-macros
   - static analysis of code by controlling the namespacing/context

Is there any reason not to do this?
(Other than: This is the way it has always been done. This is the way 
lisp-readers are aways implemented.)

Perhaps such a development is already underway?

Finally, if I wanted to implement such a solution, would it be to do it in 
Java or Clojure?  Why? 

-- 
You 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/d/optout.

Re: core.async mult "damaged" on reload

[Terje Dahl]

Forgive me for taking so long to reply to your very informative feedback.
Only this evening have I had time to experiment and study. These are my 
findings so far:

'defprotocol' is a macro with side-effects, so any attempt at holding on to 
a copy and then re-inserting it into the var in the other namespace are 
futile.
Even worse, 'reify' is also a macro with side-effects.  
The side-effects seem to be that they emit (byte-)code, and then one builds 
on the current instance of the others emitted code.
A fun hack would have been to insert a reader-macro which would prevent 
specific macros to run a second time by simply removing them at read-time.  
But alas, Clojure does not (yet) support insertion of reader-macros.  

But, it seems that if your call the instance-method stead of the 
protocol-method by the same name on your defonce-ed object, then everything 
works fine:
(.protocol-function object)  ;; do
(protocol-function object)  ;; don't.



However, since these calls are often wrapped in a second layer of 
functions, then either calling the protocol-method directly (as an 
instance-emthod), using your own copy of the calling function will have to 
be the work-around.  In the case of core.async/mult:
(.untap-all* saved-mult-instance)  ;; do
(defn my-untap-all [mult] (.untap-all* mult)) (my-untap-all* saved-mult-
instance)  ;; do
(untap-all saved-mult-instance)  ;; don't





On Saturday, November 14, 2015 at 11:01:20 PM UTC+1, James Elliott wrote:
>
> If I understand what you’re saying, then it sounds like you are reloading 
> a protocol definition, which creates a new protocol with the same name as 
> the old protocol, but they are different things. Old objects which 
> implement the old protocol do not implement the new protocol, even though 
> it looks identical and has the same name. This kind of issue has bit me 
> when working in iterative development on files, so I tend to protect my 
> protocol definitions inside defonce forms, so they do not get redefined 
> when I reload the file. It looks awkward, but helps. The example which 
> inspired me to do this was in Overtone:
>
> https://github.com/overtone/overtone/blob/master/src/overtone/music/rhythm.clj#L7-L28
>
>   -James
>
> On Friday, November 13, 2015 at 2:50:10 PM UTC-6, Terje Dahl wrote:
>>
>> I put a core.async/mult instance in a map structure in a map.
>> When i do load-file ... (from La Clojure in IntelliJ) the structure with 
>> the object instance is still there, but it isn't possible to use.
>> I get:
>>
>>> CompilerException java.lang.IllegalArgumentException: No implementation 
>>> of method: :tap* of protocol: #'clojure.core.async/Mult found for class: 
>>> clojure.core.async$mult$reify__7262
>>>
>>
>> Is this something to do with core.async itself, or perhaps a more general 
>> issue with protocol?
>> Any thoughts? 
>>
>

-- 
You 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/d/optout.

core.async - count mult

[Terje Dahl]

In addition to the function tap, untap, and untap-all I would like to 
propose a fourth function which returns a count of the number of target 
channels for a mult.
I would call it "cnt" (or perhaps "cnt-taps" or "count-taps"), but probably 
not "count", as that would step on clojure.core/count.

My use case is as follows:
I need one or more channels to recieve data from an audio input stream.  I 
have to continuously read from the stream and write the data to a mult. But 
I don't want to run this reader-loop if nothing is tapped to the mult.  So 
I would like to check the count and start or stop the loop based on the 
number of taps.

I have a patch ready to be submitted.  ;-) 

-- 
You 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/d/optout.

core.async mult "damaged" on reload

[Terje Dahl]

I put a core.async/mult instance in a map structure in a map.
When i do load-file ... (from La Clojure in IntelliJ) the structure with 
the object instance is still there, but it isn't possible to use.
I get:

> CompilerException java.lang.IllegalArgumentException: No implementation of 
> method: :tap* of protocol: #'clojure.core.async/Mult found for class: 
> clojure.core.async$mult$reify__7262
>

Is this something to do with core.async itself, or perhaps a more general 
issue with protocol?
Any thoughts? 

-- 
You 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/d/optout.

Re: clojure.repl/doc - change request - print vs return-value

[Terje Dahl]

Done.

http://dev.clojure.org/jira/browse/CLJ-1836



On Monday, October 19, 2015 at 9:27:34 PM UTC+2, Alex Miller wrote:
>
> Please file a jira with a patch and we will consider it for the next 
> release (it is too late to consider for Clojure 1.8 at this point). Include 
> the info below as the problem in the jira description.
>
> Thanks,
> Alex
>
> On Monday, October 19, 2015 at 11:23:43 AM UTC-5, Terje Dahl wrote:
>>
>> I am making a namespace inspector (using JavaFX) (somewhat like the 
>> Swing-based tree-inspector in Clojure), and when getting a function, I 
>> would like to diplay the same meta-information as "doc" prints in the REPL 
>> - including the special forms data coded in a private var/map in Clojure.
>>
>>
>> On Friday, October 2, 2015 at 3:40:20 PM UTC+2, Alex Miller wrote:
>>>
>>> What would you do with doc-fn?
>>>
>>> I think this is a reasonable enhancement request but backing it up with 
>>> a use case would help a lot (presuming you wanted to file a jira).
>>>
>>>
>>>

-- 
You 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/d/optout.

Re: clojure.repl/doc - change request - print vs return-value

[Terje Dahl]

I am making a namespace inspector (using JavaFX) (somewhat like the 
Swing-based tree-inspector in Clojure), and when getting a function, I 
would like to diplay the same meta-information as "doc" prints in the REPL 
- including the special forms data coded in a private var/map in Clojure.


On Friday, October 2, 2015 at 3:40:20 PM UTC+2, Alex Miller wrote:
>
> What would you do with doc-fn?
>
> I think this is a reasonable enhancement request but backing it up with a 
> use case would help a lot (presuming you wanted to file a jira).
>
>
>

-- 
You 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/d/optout.

clojure.repl/doc - change request - print vs return-value

[Terje Dahl]

Would it be possible to "break out" the functionality of the function "doc" 
into a second function named i.e. "doc-fn" - much as has been done with dir 
vs dir-fn?

doc prints to *out* just like dir does.
But dir-fn allows me to parse the output and use it as I need.
I would like the same for doc(-fn)

Right now I have simply duplicated special-doc-map, special-doc, and doc 
into my own code, and simply replaced "print-doc" with "identity".

-- 
You 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/d/optout.

Re: Relationship between .clj and .class files?

[Terje Dahl]

Daniel.  Thank you for your response - some 2 years ago, I know.  

So, I upgraded my Java/Clojure applet to use dtjava.embed() and a 
JNLP-file.  And the problem got worse.
Now the loader was hitting the server 10 times(!) for every Clojure-file - 
also the ones that were included in the JAR.

So I actually figured out how to build Clojure from source myself and 
fiddle with your suggestion.  :-)
First off, by setting cljURL to null categorically prevented Clojure from 
not even building.
So I tried some different things, only to find out the problem lay in the 
very first lines of the load-function - in the calls to getResource().  
This caused the JNLP2ClassLoader to first hit the server many times before 
getting the requested resource from the already downloaded JAR-file.

The solution was as simple as to add an index to the JAR!
See here: 
 
http://stackoverflow.com/questions/19187209/jnlp2classloader-findclass-requests-from-server-multiple-times-before-checking-j/19189127#19189127

As for the user.clj, I simply put an empty one into the jar at the top 
level.  



kl. 18:33:33 UTC+1 torsdag 17. november 2011 skrev Daniel Solano Gómez 
følgende:

 On Thu Nov 17 09:06 2011, Terje Dahl wrote:
  What is the relationship between the .clj source-file(s) and its gen-
  class compiled class-files?
  
  The reason I ask is that my app is an applet, written in Clojure
  (obviously), and compiled.
  The resulting class-files are then bundled into a jar-file, but
  without the source clj-file.
  (I don't want to incude my source-code in the deployed applet jar-file
  - for business reasons, obviously).
  
  The applet loads and runs just fine, but not before requesting clj-
  files from the server.
  In my server log files I see failed requests for user.clj and
  applet.clj (the file containing all my source-code).
  The applet doesn't recieve the files from the server, but runs just
  fine all the same, so obviously doesn't need them.
  
  1.  Why are these files requested in the first place, when not needed?

 By default, when loading a namespace, Clojure will try to find both the
 source file and a class that loads the namespace.  For example, given
 the namespace example.core, it will look for both example/core.clj
 and example/core__init.class.  I believe the reasoning goes that if
 the source file is more recent than the AOT-compiled class, it will
 recompile the namespace at runtime.

 The reason why its looking for user.clj is that by default when
 Clojure loads up it will create the user namespace that is used in the
 REPL.

  2. How do I prevent these files from being requested at all?

 I don't think there is a way to do this without modifying Clojure's
 code.  If you're up to making your own custom build of Clojure, the
 changes should be relatively simple to do.

 To prevent the lookup of the Clojure file, I think you might be able to
 just change line 405 of RT.java
 
 https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L405
 
 so that cljURL is simply set to null.  I haven't tested it, but I
 think it should work.

 To prevent the user namespace from being created, you should be able
 to remove lines 436-452 of RT.java
 
 https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L436-452
 .
 I do not remember if this change will keep you from being able to
 compile your applet, but I do think it'd keep the REPL from running.

  
  (When I have 100 kids in the same school, loading my applet at the
  same time, all the extra failed and unneccessary request are unwelcome
  on an already slow school network)
  
  -- 
  You received this message because you are subscribed to the Google
  Groups Clojure group.
  To post to this group, send email to clo...@googlegroups.comjavascript:
  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 javascript:
  For more options, visit this group at
  http://groups.google.com/group/clojure?hl=en



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

Java Web Start (JWS), Clojure, and a security issue

[Terje Dahl]

I struggled for many working days a while back trying to get my 
Clojure-and-JavaFX app to run as JWS. 
The app ran fine when launched as a stand-alone (from the jar).  And code 
signing and JNLP were supposedly done state-of-the-art.  But I kept getting 
a security exception à la accessing a restricted/private member...
I gave up.

But yesterday I recompiled and deployed an already existing application.
Now I suddenly got the same error.  But I figured out what the cause was:
I had upgraded the apps Clojure library from 1.4.0 to 1.5.1
As soon as I switched back to 1.4.0, the problem disappeared!  :-D

Any thoughts on what new magic under the hood is employed in 1.5 that was 
not pressent in 1.4, and which the JWS security sandbox does not accept 
even when code is signed and all-permissions is accepted and works in 
other parts of the code?

-- 
-- 
You 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: Best IDE

[Terje Norderhaug]

On Thu, Jun 6, 2013 at 6:02 PM, Lee Spector lspec...@hampshire.edu wrote:


 8) If you want to become a rock star eternal golden coder's hero then
 develop an Emacs-like Clojure coding environment for which the features ARE
 discoverable and for which the learning curve is gentle. This sort of thing
 has been done before! At least FRED (FRED Resembles Emacs Deliberately),
 which was part of the (sadly) long dead Macintosh Common Lisp environment,
 counts in my book. And the MCLIDE project continued this work to some
 extent for a while, for multiple Lisps including Clojure (
 http://mclide.com). All of that was just for Mac, however, and none of it
 appears to be active... but the idea is a superb one: Provide all of the
 power of Emacs but ditch the ancient user interface. E.g., instead of
 hiding buffers invisibly behind each other, just pop up ordinary windows
 that people already know how to use. Use standard menus and dialogs to
 interact with the user for opening files, browsing stack traces, and
 everything else. Set preferences in a standard preferences dialog. Allow
 features to be discovered by browsing menus, and allow key commands to be
 viewed/changed in standard ways. Life would be beautiful if something like
 this arose in the Clojure community.


MCLIDE is alive and well. Although the most recent public build was
released last summer, there are open source on github for those that want
to participate in the development:

   https://github.com/TerjeNorderhaug/mclide

-- 
-- 
You 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: Lisp In Summer Projects

[Terje Norderhaug]

I suggest allowing participants from the listed countries, but give
an eventual prize to a charity of choice to avoid a cash payment.


On Thu, May 9, 2013 at 12:59 PM, u1204 d...@axiom-developer.org wrote:

 I believe that cash payments are forbidden by law in the listed
 countries. The contest will make cash payments. I know that
 Lisp In Summer Projects has no problem with people from Italy,
 Brazil, or other listed countries.

 Tim Daly

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




-- 
-- 
You 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: Proposed change to let- syntax

[Terje Norderhaug]

On Thu, Nov 15, 2012 at 5:17 PM, Alan Malloy a...@malloys.org wrote:
 The primary point of let- is that you can insert it into an existing -
 pipeline.

 (- foo
 (stuff)
 (blah)
 (let- foo-with-stuff
   (for [x foo-with-stuff]
 (inc x)))

This use case of the macro now renamed as- in Clojure 1.5 is already
covered by using fn in a pipeline:

(- foo
(stuff)
(blah)
((fn [foo-with-stuff]
   (for [x foo-with-stuff]
 (inc x)

A benefit of using fn here is that it also works with - just the
same. However, there is a place for a construct to simplify multiple
uses of fn in a pipeline like in:

 (- foo
(stuff)
(blah)
((fn [foo]
   (for [x foo]
 (inc x
((fn [foo]
   (for [x foo]
 (dec x)

I propose fn- as name for a construct similar to as- used like this:

(- foo
(stuff)
(blah)
((fn- [foo]
   (for [x foo]
 (inc x))
   (for [x foo]
 (dec x)

The fn- macro defines an anonymous function using the same syntax as
fn, with its forms threaded like in as- where each evaluated form is
bound to a symbol.

In the example above, the result of the first 'for' form is bound to
the 'foo' used by the second 'for' form. That is, within fn- the
items in the list bound to foo is first incremented and the resulting
list bound to foo, then the items in the list bound to foo is
decremented with the resulting list returned (incidentally leaving the
list as before).

Keeping the syntax and semantics of fn- similar to fn provides an
smooth upgrade path from current uses of fn in pipelines.

-- Terje Norderhaug

 On Thursday, November 15, 2012 10:35:59 AM UTC-8, Alex Nixon wrote:

 Hi all,

 I find the proposed function let- in Clojure 1.5 very useful, but a bit
 ugly.  The arguments are backwards when compared to vanilla let, and it
 doesn't support destructuring where it easily could (which I believe would
 be helpful when threading 'state-like' maps, as I find let- very useful
 for).

 I'd like to float an alternative implementation which improves on both
 these issues.  Thoughts?

 (defmacro new-let-
   Establishes bindings as provided for let, evaluates the first form
in the lexical context of that binding, then re-establishes bindings
to that result, repeating for each successive form
   [bindings  forms]
   (assert (vector? bindings) binding must be a vector)
   (assert (= 2 (count bindings)) binding vector must contain exactly two
 forms)
   `(let [~@bindings
  ~@(interleave (repeat (bindings 0)) (drop-last forms))]
  ~(last forms)))

 (new-let- [{:keys [foo bar] :as state} {:foo 1 :bar 2}]
   (assoc state :foo (inc bar))
   (assoc state :bar (inc foo))) ; = {:foo 3, :bar 4}

 --
 Alex Nixon

 Software Engineer | SwiftKey

 al...@swiftkey.net | http://www.swiftkey.net/

-- 
You 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: Proposed change to let- syntax

[Terje Norderhaug]

Here is the short form of the proposal below:

1. Make as- in Clojure 1.5 have a syntax and semantic matching how fn
is used in pipelines.
2. Rename as- to fn- reflecting its similarity to fn.

-- Terje Norderhaug

On Sun, Dec 2, 2012 at 5:30 PM, Terje Norderhaug te...@in-progress.com wrote:
 On Thu, Nov 15, 2012 at 5:17 PM, Alan Malloy a...@malloys.org wrote:
 The primary point of let- is that you can insert it into an existing -
 pipeline.

 (- foo
 (stuff)
 (blah)
 (let- foo-with-stuff
   (for [x foo-with-stuff]
 (inc x)))

 This use case of the macro now renamed as- in Clojure 1.5 is already
 covered by using fn in a pipeline:

 (- foo
 (stuff)
 (blah)
 ((fn [foo-with-stuff]
(for [x foo-with-stuff]
  (inc x)

 A benefit of using fn here is that it also works with - just the
 same. However, there is a place for a construct to simplify multiple
 uses of fn in a pipeline like in:

  (- foo
 (stuff)
 (blah)
 ((fn [foo]
(for [x foo]
  (inc x
 ((fn [foo]
(for [x foo]
  (dec x)

 I propose fn- as name for a construct similar to as- used like this:

 (- foo
 (stuff)
 (blah)
 ((fn- [foo]
(for [x foo]
  (inc x))
(for [x foo]
  (dec x)

 The fn- macro defines an anonymous function using the same syntax as
 fn, with its forms threaded like in as- where each evaluated form is
 bound to a symbol.

 In the example above, the result of the first 'for' form is bound to
 the 'foo' used by the second 'for' form. That is, within fn- the
 items in the list bound to foo is first incremented and the resulting
 list bound to foo, then the items in the list bound to foo is
 decremented with the resulting list returned (incidentally leaving the
 list as before).

 Keeping the syntax and semantics of fn- similar to fn provides an
 smooth upgrade path from current uses of fn in pipelines.

 -- Terje Norderhaug

 On Thursday, November 15, 2012 10:35:59 AM UTC-8, Alex Nixon wrote:

 Hi all,

 I find the proposed function let- in Clojure 1.5 very useful, but a bit
 ugly.  The arguments are backwards when compared to vanilla let, and it
 doesn't support destructuring where it easily could (which I believe would
 be helpful when threading 'state-like' maps, as I find let- very useful
 for).

 I'd like to float an alternative implementation which improves on both
 these issues.  Thoughts?

 (defmacro new-let-
   Establishes bindings as provided for let, evaluates the first form
in the lexical context of that binding, then re-establishes bindings
to that result, repeating for each successive form
   [bindings  forms]
   (assert (vector? bindings) binding must be a vector)
   (assert (= 2 (count bindings)) binding vector must contain exactly two
 forms)
   `(let [~@bindings
  ~@(interleave (repeat (bindings 0)) (drop-last forms))]
  ~(last forms)))

 (new-let- [{:keys [foo bar] :as state} {:foo 1 :bar 2}]
   (assoc state :foo (inc bar))
   (assoc state :bar (inc foo))) ; = {:foo 3, :bar 4}

 --
 Alex Nixon

 Software Engineer | SwiftKey

 al...@swiftkey.net | http://www.swiftkey.net/

-- 
You 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: [ANN] clj-xpath 1.3.3

[Terje Norderhaug]

On Tue, Nov 20, 2012 at 9:07 AM, Phil Hagelberg p...@hagelb.org wrote:
 However, the likelihood that anyone else will come along in the future
 and name another library clj-xpath is basically nil in this case.

For standards/recommendations like xpath it would be preferable to
avoid that the first Clojure implementation coming along gets to
monopolize the name. In fact, I've been thinking for a while about
implementing an xpath library for Clojure, talking a different
approach than Kyle, as I've implemented XPath in the past in Common
Lisp as part of an XSLT processor/compiler used in my commercial
products. So I second the use of a group-id for clojure libraries that
use the name of a standard/recommendation in their name.

-- Terje Norderhaug

-- 
You 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 on Heroku

[Terje Norderhaug]

On Jul 26, 2011, at 1:50 AM, Tarantoga wrote:
 Does anyone know how to create an autoincrementing ID field for a
 table schema on Heroku?

In the schema for the table, define an id field like this:

 [:id :serial PRIMARY KEY]

 It uses PostgreSQL and a common way for this DB is to create a
 sequence and then take default ID's from this sequence. But I haven't
 found a way to do something like that.
 
 I know that rails migrations do something similar but don't know how.
 Are there any ideas?
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en

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

ns/use/require/import inconsistent an confusing

[Terje Dahl]

Consider the following:

  (ns my.namespace.here)

  (use 'my.namespace.here :reload)

  (require '[my.namespace.here :as something])

  (import [my.package MyClass1 MyClass2])


1.  Why (at least!) 4 different ways of noting namspaces/domains: With
or without the escape-mark (') and with or without square
brackets([])?
Does it have to do with macros vs. functions etc?  Must it be so?
Surely it could be better!


2. Is it stricly necessary to have both use, require, and import
- as well as a host of keywords for the different ones?
Could they perhaps be combined to 2 - or even one?

Dare I say Python seems to have a nice, simple version of a combined
use/require sollution:
  import my.module
  import my.module as m1
  from my.module import MyClass1, MyClass2
  etc.
Cojures require allready allows :as and Clojures use has :only
followed by a list.

And would it be technically possible to:
 I.  Combine a  use/require combined sollution with the import-
function?
 II. Also have a :reload and :reload-all for Java classes?


Is all this a case of that's what me had time for for version 1, but
we are working on something better.?
Or is it technically impossible to improve on or abstract away any of
this?


The  many choices and inconsistencies in the different import-
statements is complicated and confusing.
And as this is the first thing you have to figure out as a new-to-
Clojure programmer (novice or professional) to start programming in
Clojure, it certainly doen't make for a very good first impression!

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

Relationship between .clj and .class files?

[Terje Dahl]

What is the relationship between the .clj source-file(s) and its gen-
class compiled class-files?

The reason I ask is that my app is an applet, written in Clojure
(obviously), and compiled.
The resulting class-files are then bundled into a jar-file, but
without the source clj-file.
(I don't want to incude my source-code in the deployed applet jar-file
- for business reasons, obviously).

The applet loads and runs just fine, but not before requesting clj-
files from the server.
In my server log files I see failed requests for user.clj and
applet.clj (the file containing all my source-code).
The applet doesn't recieve the files from the server, but runs just
fine all the same, so obviously doesn't need them.

1.  Why are these files requested in the first place, when not needed?

2. How do I prevent these files from being requested at all?

(When I have 100 kids in the same school, loading my applet at the
same time, all the extra failed and unneccessary request are unwelcome
on an already slow school network)

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

mutability in the let-form!?

[Terje Dahl]

I was surprised to discover that the following was possible:

(let [
   x 1
   y 2
   x (+ x y) ]
 x )

This runs and returns 3!

This feels an awful lot like variables and procedural programming.
It is left up to the developer to not resetting a variable - by
convention - and if he reset the identifiers, he ends up with hard-to-
debug spagetti-code.

I would have thought that the system would have protested when I
attempted to set 'x' to a new value!
Amit Rathore writes in Clojure In Action about : [...] are locally
named values (they are like variables, but they can’t vary since
Clojure’s data-structures are immutable)

In combination underscore identifiers for throw-away return values,
one can in fact write a whole procedural program within the vector
parens of a let-statement!

Perhaps this is something that should be changed in future versions of
the language?!

-- 
You 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: I/O

[Terje Dahl]

I disagree.

Simply use:  (System/getProperty user.home)

This will give you a useful path to work with, no matter where you
start from.
Works on my Mac. Should work on Windows.

From there I would build a simple library which tests which OS I am
on, and gives me the paths to the conventional locations on each
plattform for applications-support, prefs, caching, documents,
desktop, etc. I.e. (cache-dir my-application-name).





On 26 Aug, 13:35, Lee Spector lspec...@hampshire.edu wrote:
 On Aug 25, 2011, at 11:39 PM, Dave Ray wrote:



  user.dir is the directory from which the JVM was launched, i.e. the
  initial working directory of the process. So, you're probably
  double-clicking the Clooj jar which resides in your Downloads folder
  and thus all further file system operations will be relative to that.

 Ah. Exactly right. That explains why.

 Thanks also for all of the other details and workaround suggestions on the 
 clooj list. Alas, the bottom line does seem to be that there's no simple way 
 to get simple file I/O to work relative to a project's location without 
 launching the JVM in a specific way.

  -Lee

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

Notation conventions

[Terje Dahl]

I find myself making alot of mistakes when dealing with atoms.
I usually remember the datatype and/or structure returned by a
function, or held in a binding or symbol - but not wether it is an
atom or not.

Any naming-conventions for atoms, such as ending with ? for
predicate, or ! for sideeffect?
But at the same time i don't want to end up with some sort of
Hungarian Notation.

-- 
You 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: Notation conventions

[Terje Dahl]

OK.  Thanks.


Regarding why so many atoms:
I have rewritten a GUI-based (Swing) app to Clojure (our company's
product: A Java applet), and where I previously typically had extended
JPanels, adding variables and methods to them, I have (for now)
replaced them with maps in atoms, where the maps contain the same data
(including the actual panel, which I prevously extended), and even som
methods to work on those values, and then I am able to pass around
references to data which can be altered with swap! - basically a
form of mutable state.

Not ideal, and I am certainly intend to refactor the code to make it
more functional, but I am not sure how to better implement a more
complex event-driven GUI application.
I have  your book, but haven't read most of it yet.  Am still reading
Clojure in Action.
Any part of your book I should skip to directly that is specific to my
problem?
Any good articles og code samples you can point me to?


On 26 Aug, 16:42, Fogus mefo...@gmail.com wrote:
 I guess the first question is; why so many atoms?  But regardless,
 there is no standard for naming such things.  If you know you're
 dealing with atoms only (as opposed to a reference in general) then
 something like `foo-atom` would suffice I'd say.

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

mini-version of clojure.jar?

[Terje Dahl]

My company (read: I) develop an web-based educational application (a
language lab) implemented as a Java applet.

I have spendt the summer porting it to Clojure.  I am very happy with
the results.

Except: The download (and therefore the download-time) has increased
dramatically, as I now include the clojure.jar as part of the
download.
(Actually, I repackage the content together with my application.)

This, I fear is going to hit alot of the pupils hard, when 20 pupils
at a time attempt to access the applet for the first time over the
mediocre (at best) web-connections at their schools.

Yes, I do manipulate the java applet cache-params.
But There will always be a need for full downloads - both for first-
time-users, and when I update the applet (frequently).

My question:
Is there anyway to reduce the size of the jar - drastically?
Can I somehow remove most of the class-files generated from core.clj
etc, and still have everything working properly?
Tips/hints/suggestions?


(Plug: See my open-source JS-embed code for Java applets:
http://bitbucket.terjedahl.no/terjedahl/appletjs )





-- 
You 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: mini-version of clojure.jar?

[Terje Dahl]

Yes. My applet is signed.  So that is not a problem.

Any thoughts about difference in performance between slim and
full?
My applet mostly does swing-stuff, http GETS and POSTS - and audio
playback and recording.




On 25 Aug, 10:40, David Powell d...@djpowell.net wrote:
 The slim jar probably won't work in an applet, because it does classloader
 stuff (unless you have a signed applet).

 --
 Dave

-- 
You 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: I/O

[Terje Dahl]

Great question.  And great answer.
Seriously!  I did not know it could be that easy.
So an http GET just needs 1 lines!:

(slurp (reader http://google.com;))

(Don't forget: (use 'clojure.java.io) )


Is there an equally easy way to do an http POST?
And also a multi-part (including one or more files in the POST)?



On 25 Aug, 18:24, Mats Rauhala mats.rauh...@gmail.com wrote:
 I too stumbled upon this a while ago. I might even say that on some
 level it's so simple that there is not much documentation about it, and
 at some point it gets 'complex' enough that you should know about java
 enough.

 The simplest way is to slurp or spit. slurp reads a file into a string,
 and spit writes a string into a file.

 Then there is the with-open macro(?) which opens connections and closes
 them when one. The reader and writer opens a java Reader and Writer
 classes respectively. (They're interfaces, but those functions try to
 figure out what kind of handle you're trying to open). Also the
 output-stream and input-stream handle it a bit.

 (with-open [r (reader http://www.reddit.com;)]
  (.read r))

 And to finish this off with a shameless plug; I wrote a blog post about
 downloading a random wallpaper from reddit, which handles reading http
 content, parsing json and reading/writing binary files.

 http://users.utu.fi/machra/posts/2011-08-24-2-reddit-clojure.html

 --
 Mats Rauhala
 MasseR

  application_pgp-signature_part
  1 KVisLast ned

-- 
You 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: Understanding the Clojure source-code and functionality

[Terje Dahl]

This looks conceptually very interesting. This is the first time I
have ever heard of literate programming.

However, the project is far from complete.  And while I could even
consider contributing to it later, for now, it doesn't give me much.

And also, while converting clojure to a literate programming (LP)
project is a great idea, it is only useful if the main team is part of
that process.  For isn't the idea behind LP that one develop the
concepts, code, and explanations at the same time?  So if Hickey et al
do all there work separately (outside of the of LP), then someone else
has to constantly follow behind and update and alter the LP-version,
constantly struggling to keep the two version syncronized.



On Apr 18, 4:37 pm, Armando Blancas armando_blan...@yahoo.com wrote:
 You may want to follow this thread and look for the latest version of
 Clojure in Small Pieces:

 http://groups.google.com/group/clojure/browse_thread/thread/460417fe4...

 On Apr 17, 12:27 pm,TerjeDahlte...@terjedahl.no wrote:



  I would very much like to study and understand how Clojure works
  under the hood.

  Yes, I have downloaded the source and looked at it.
  Yes, I have all the books about programming in Clojure.

  But what I am looking for is learning and understanding how the
  Clojure JVM-code actually works.
  And how it interacts with with the CLJ-files.
  About underlying principals and functionality in general,
  considerations in relation to Java and the JVM, and where the
  development path goes from here.

  Is anything written on the subject?
  Is there a book under way?

  Perhaps this is an interesting project on its own - and important for
  developing understanding for Clojure, and helping aspiring developers
  (such as myself) to participate in the development of 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
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

Understanding the Clojure source-code and functionality

[Terje Dahl]

I would very much like to study and understand how Clojure works
under the hood.

Yes, I have downloaded the source and looked at it.
Yes, I have all the books about programming in Clojure.

But what I am looking for is learning and understanding how the
Clojure JVM-code actually works.
And how it interacts with with the CLJ-files.
About underlying principals and functionality in general,
considerations in relation to Java and the JVM, and where the
development path goes from here.

Is anything written on the subject?
Is there a book under way?

Perhaps this is an interesting project on its own - and important for
developing understanding for Clojure, and helping aspiring developers
(such as myself) to participate in the development of 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
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: Namespace and file structuring

[Terje Dahl]

On Mar 26, 12:35 am, James Reeves jree...@weavejester.com wrote:
 On 25 March 2011 01:05, Terje Dahl te...@terjedahl.no wrote:

  In Java, the language forces you to have more or less one class pr
  class-file, and you are encouraged to group class-files in packages.
  So, is it as simple as saying that that namespaces are analogous to
  class-files, and clj-files are analogous to packages?

 Typically, each .clj file will have its own namespace. Clojure uses
 the namespace to find where the corresponding .clj file is on the
 classpath.

So, would you say that namespaces are in fact a lot like Python
packages - one pr file - and with the same flexibility of Python's
import-statements:

import foo.bar
from foo import bar
import foo.bar as mything
etc.

What has thrown me, has been the apparent haphazard use of namespaces
in tutorials using REPL ...


  Also, while we are at it, what are the naming conventions?
  The same as in Java packages?
  So I would use:  no.terjedahl.some.namespace.here ?

 Some people use this convention, but the majority of Clojure libraries
 tend to use the following convention:

   library-name.some.namespaces

 For instance, here are some namespaces for the Ring library:

   ring.middleware.params
   ring.util.response

Ah, but as in Java, the big official libraries such as java itself
starts with i.e. java.swing.  But if I was to publish a utilities
library for swing, i would call it no.terjedahl.java.swing, so that it
could be used by me or others as-is, without conflict with java.swing.
So, I tend to agree with Stuart Sierra in his statement: For naming,
the Java package convention is pretty good at avoiding conflicts.

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

Namespace and file structuring

[Terje Dahl]

I would love to know how better to organize my code:
I understand the basics of namespaces and how to use them.
But when and why I should use different namespaces eludes me.

In Java, the language forces you to have more or less one class pr
class-file, and you are encouraged to group class-files in packages.
So, is it as simple as saying that that namespaces are analogous to
class-files, and clj-files are analogous to packages?

But then Java doesn't have anything like rebinding something from one
namespace into another, for one.
What are the best ways to use namespaces?

Also, while we are at it, what are the naming conventions?
The same as in Java packages?
So I would use:  no.terjedahl.some.namespace.here ?


I would love to here thoughts on this.
And any links to web-pages discussing the topic.

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

[ANN] MCLIDE 1.0b3 Mac IDE for Clojure 1.2

[Terje Norderhaug]

I just released a new version of MCLIDE, the free open source Macintosh lisp 
IDE:

   http://mclide.in-progress.com

The new version makes it easier than ever to get going with Clojure. MCLIDE is 
like a clojure-in-a-box, with the only missing ingredient being the Clojure 
distribution. After selecting the clojure.jar file in a dialog, MCLIDE 
automatically starts Clojure with swank and opens a listener to evaluate 
Clojure forms.

MCLIDEs built-in programming editor has paren matching, automatic indentation 
and numerous keyboard shortcuts, as well as optional lisp syntax styling and 
symbol completion. The mature IDE provides rich interactive development, 
debugging and introspection tools in the form of dialogs on Mac OS X:

   http://mclide.in-progress.com/tour

MCLIDE can be used on the same computer as Clojure or remotely as development 
environment for installations on any platform available over the net.

Enjoy!

-- Terje Norderhaug
te...@in-progress.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

Completions and XREFs [Re: Introduction + question re. diff between 'Programming Clojure']

[Terje Norderhaug]

On Mar 24, 2010, at 3:53 AM, Laurent PETIT wrote:

2010/3/24 Konrad Hinsen konrad.hin...@fastmail.net:

The original version (. object method) still could have an interest
where IDEs could guess the method names to propose based on what they
could infer from the object arg.
With the (.methodName object) version, the IDE usually can make
methode name completions based on everything but the object source
code which has not been yet entered by the user, and this is less than
ideal :-(.

So some IDEs (like ccw) try hard doing completion based on the start
of the method name type by the user (and it is currently slow with ccw
because it searches for matches in all available classes in the
project's classpath), some base their search only on classes that are
imported in the current namespace (which is less than ideal given that
generally the objects are not referred to directly in the ns and thus
do not require an import statement for their class/interface).


Clojure IDEs that do completions (like MCLIDE, SLIME and ccw) could  
benefit from having collections of method names and other Clojure  
properties available for efficient access without loading the  
associated code. Such as if jars included a compilation/database  
built from a static analysis of the Clojure code.


Other information of interest includes cross references like the  
callers of a function (see XREF for Common Lisp). The Swank server  
used by SLIME and MCLIDE already provides an interface to support  
such references and completions in these IDEs.


Some require the user to write an intermediate form of source  
code, e.g.

by prefixing the method name with the class name to narrow the search,
e.g. type String.le to have code completion on String.length, and
when you accept the code completion, it is transformed back into
.length in the editor ...


-- Terje Norderhaug
  te...@in-progress.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

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: Why I have chosen not to employ clojure

[Terje Norderhaug]

On Mar 21, 2010, at 3:56 PM, Mark Derricutt wrote:
Thanks for the pointer to MCLIDE!  That looks really nice!  Any  
idea if a 64bit build is in the works?  For some reason I feel  
dirty about having to install Rosetta :)


MCLIDE 2.0 will have that cutting edge you're craving for and  
definitely NOT require Rosetta, but please don't let that hold you  
back from using MCLIDE 1.0. The first version is intended to provide  
fodder for a conversation about what to include in the next  
generation lisp/clojure IDE for Macintosh. I invite you to download  
the upcoming release of MCLIDE for Clojure and join the dialogue  
about where to go from here. Think of Rosetta as just another VM... ;-)


There are good reasons for the initial release to use Rosetta,  
particularly that it allowed MCLIDE to be built rapidly on top of a  
mature, proven lisp IDE. This dramatically cut down the development  
time from conception to usable software, making MCLIDE available now  
instead of at the time of the 2.0 release.


You get the gist: Release early. Release often. And listen to your  
customers.


When MCLIDE for Clojure is out, you will be able to download a  
distribution of MCLIDE and have it work instantly as an IDE for  
Clojure on Mac OSX, and with a little extra effort as a Mac IDE for  
Clojure on any platform.


If you just can't wait any longer, send me an email, and I'll let you  
in on how to make the current version of MCLIDE work with Clojure.


On Mon, Mar 22, 2010 at 11:08 AM, Lee Spector  
lspec...@hampshire.edu wrote:
I'm sure that this can and will be overcome, in part because I  
think that for my main environment (Mac OS X) and for my needs  
(which are more about ease of starting to write and run code than  
about deployment) MCLIDE/Clojure is very close already (three  
cheers for Terje!).


-- Terje Norderhaug
  te...@in-progress.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

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: Long post with some questions about getting started...

[Terje Norderhaug]

On Mar 18, 2010, at 2:04 PM, Nick wrote:

I'm having an interesting (to me) question around a using REPL.  Once
it's shut down, where does this code go?  I feel like I'm in the old
TRS-80 volatile coding days where you write some code, and if you shut
down you've lost it all.  Is this the case?  So how do you save your
code in a REPL?  I understand these could be unique per editor so I
understand if you get irate at me for asking such a silly question...


I mostly use the repl for executing tests, preferring to write and  
evaluate Clojure definitions from a lisp editor. For example, in the  
MCLIDE lisp editor, I evaluate lisp code in the editor by placing the  
cursor at the opening or closing parenthesis of an expression then  
hit the Enter key. Alternatively, I use a menu shortcut to (re) 
evaluate all definitions in the file I am editing.


-- Terje Norderhaug
  te...@in-progress.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

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: Long post with some questions about getting started...

[Terje Norderhaug]

On Mar 19, 2010, at 4:17 PM, Mike Meyer wrote:

On Fri, 19 Mar 2010 07:21:50 -0700 (PDT)
Sean Devlin francoisdev...@gmail.com wrote:
I'm having an interesting (to me) question around a using REPL.   
Once

it's shut down, where does this code go?  I feel like I'm in the old
TRS-80 volatile coding days where you write some code, and if you  
shut

down you've lost it all.  Is this the case?  So how do you save your
code in a REPL?  I understand these could be unique per editor so I
understand if you get irate at me for asking such a silly  
question...


To answer your question about the REPL, yes everything is lost when
you close it.  However, this isn't the whole story.  Once you  
create a

new project w/ Enclojure, you can send code from a file too the REPL
either from a context menu or keyboard shortcut (Alt+E in windows).
It's standard practice to edit your file, and send the code to the
REPL dynamically.  This gets you out of the 1960s and back to 2010.


Most clojure-aware environments will have similar functionality:
SLIME+SWANK, Eclipse, etc. It's not clear this really gets you out of
the 60s, though - it's been standard practice for (file-based *) LISP
development for as long as I can remember. Nuts, it worked with
Scheme2C and mg on the Amiga in the 80s.

*) InterLISP and some others were more like SmallTalk, or MS BASIC, in
   that you edited code at the REPL and saved the entire
   workspace. That did add power - I've never seen a file-based LISP
   whose error handler would let me fix the code on the fly and
   continue execution.


Possibly I am misunderstanding I've never seen a file-based LISP  
whose error handler would let me fix the code on the fly and continue  
execution but that sounds like common practice in the REPL break  
loop for many lisps.


-- Terje Norderhaug
  te...@in-progress.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

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: help with infinite loop: break and examine stack? dynamic tracing? circular lists?

[Terje Norderhaug]

On Mar 17, 2010, at 8:14 AM, Lee Spector wrote:
The root problem is that I think I have an infinite loop somewhere  
in my code and I'm having a hard time tracking it down. [...] In  
Common Lisp I would wait until I think I'm in trouble, break  
execution with a keyboard interrupt, look at the function call  
stack (and local vars, if I'm in a nice CL environment), and  
probably figure it out pretty quickly.[...] Is there is a way to  
break and look around under slime? [...]


I've also been doing some runs under MCLIDE, with help from Terje  
Norderhaug, and there I can indeed issue a break from a menu and  
get a backtrace of sorts... but so far I have not been able to get  
a backtrace that shows me what I need -- that is, I don't see any  
of my own functions, presumably because the break changed the  
context... I'm not sure what's going on there.


MCLIDE gets the same backtrace items from swank-clojure as does emacs  
SLIME. I believe the issue is that the JVM only provides limited  
stacktrace information (at least compared to what Common Lisp  
developers are used to).


A good backtrace is essential for efficient debugging. Are there any  
ways to improve the backtrace provided by swank-clojure?


An alternative: Is there a way to watch my running Clojure program  
without breaking it, that is to observe the recent call history (of  
my own definitions, either all of them or specifically marked ones)  
from outside the process?


You could use a profiler to see which of your Clojure functions  
monopolize the execution.


I can think of some clumsy ways to roll my own version of this,  
e.g. using trace and sending the trace output to a file, but I  
don't think this will be practical because I generally only get  
these errors after long stretches of intensive computation that  
will involve many many calls to the potentially problematic  
functions. So I think there'll be too much trace output to save on  
disk, and the slowdown from tracing all of the calls may prevent me  
from ever reaching a problematic state (although I haven't tried  
this to be sure of the timing).


Consider waiting until you are in the situation then use trace on  
candidate culprits.


And in spite of the problems listed above I'm having a great time  
in the Clojureverse!



-- Terje Norderhaug
  te...@in-progress.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

Re: clojure slides

[Terje Norderhaug]

On Mar 6, 2010, at 5:27 PM, Sophie wrote:

Re: Emacs + Slime + paredit. I did not see Clojure listed as supported
for Slime and paredit. Do you know if:

- Can you do all Slime stuff in Clojure? evaluate, macro-expand,  
docs, etc?


You can do much of the SLIME stuff including the items listed,  
although the Clojure Swank server used with MCLIDE and emacs SLIME  
does not yet support *all* features implemented in the Common Lisp  
version. Inspection is still incomplete, and it lacks xref  
functionality such as listing the callers of a function.


-- Terje Norderhaug
  te...@in-progress.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

Meta for method definitions

[Terje Norderhaug]

What is a good way to get the :file and :line meta information for a  
method?


Getting this meta information for a multi is straight forward:

(meta #'clojure.core/print-method) =
{:ns #Namespace clojure.core, :name print-method, :file clojure/ 
core.clj, :line 2314, :tag clojure.lang.MultiFn}


But what about getting this meta information for a method? Such as  
the result from a call to get-method:


(get-method clojure.core/print-method 1)

Calling meta on the result returns nil, even if this is true:

(instance? clojure.lang.IMeta (get-method clojure.core/print-method 1))

-- Terje Norderhaug
  te...@in-progress.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

Re: newbie code (genetic programming) and questions (dev environments)

[Terje Norderhaug]

On Feb 28, 2010, at 11:38 AM, Lee Spector wrote:
On the development environment front: Is anyone contemplating  
creating a Mac OS X Clojure in a Box? I would be an enthusiastic  
user. If it could have roughly the feature set of the old Macintosh  
Common Lisp IDE then I would be ecstatic.


MCLIDE is on way to provide essentially a Mac OS X Clojure in a Box:

   http://mclide.in-progress.com

MCLIDE does indeed have roughly the feature set of the old Macintosh  
Common Lisp IDE - although modernized. This should come as no  
surprise: MCLIDE is in fact based on the MCL IDE (which Peter Norvig  
a few years ago named in Dr. Dobbs Journal as his favorite IDE on  
the Macintosh platform for any language).


MCLIDE is a free open source Mac IDE for lisp on any platform. It  
implements the swank protocol of emacs SLIME and can potentially be  
used with the same lisps. The essential functionality for Clojure is  
is in place, with the rest to be completed over the coming weeks.  
Follow the progress of MCLIDE at:


   http://twitter.com/MCLIDE

Despite a fair amount of tinkering I don't currently have a  
functional SLIME setup, and despite the nice screencasts for  
Eclipse/Counterclockwise (and very nice features it seems to have  
-- e.g. the namespace browser and integrated documentation... is  
there any environment that has a debugging environment  
approximating a Lisp break loop?) that's not really working for me  
yet either. (A few specifics: In emacs, using a variety of  
configuration instructions and hints from the web, I get syntax  
coloring and indentation but not a functional inferior Lisp mode.  
Eclipse is a bit confusing to me overall, I can't seem to figure  
out how to get Clojure indenting, and it seems to be re-evaluating  
my buffers without me asking it to :-(. And saving an awful lot of  
files to its workspace directory.) I'm not only interested in  
getting one of these environments working on my own machine --  
although that would be nice -- but also in having a simple,  
repeatable sequence of instructions for getting the environment  
running on fresh machines. This is because I teach and I may want  
to use this on classroom machines, student machines, etc., with  
students who have various levels of expertise. Our students use all  
sorts of platforms but our teaching environment is Mac OS X (with a  
linux cluster for compute-intensive stuff).


-- Terje Norderhaug
  te...@in-progress.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

Re: Prefixed or suffixed symbols?

[Terje Norderhaug]

On Feb 25, 2010, at 7:59 PM, Sean Devlin wrote:

As to you question about editors, I know that it's possible to adapt
emacs clojure-mode the change colors based on a regex.  That's how it
knows to color something pink for a fn in clojure.core, and green
for a fn in the standard library (e.g. clojure.walk).  You'll have to
make your own customizations, of course.


Syntax styling is better based on the meta-information of symbols  
rather than on whether the name of a symbols fits a pattern. Hence it  
would be a mistake to institute syntax conventions for symbols and  
clutter the code just to facilitate styling in editors.


-- Terje Norderhaug 


On Feb 25, 10:50 pm, joshua-choi rbysam...@gmail.com wrote:

Ah, yes, it is a. (The only thing that I anticipate a computer would
use this for is different syntax highlighting. Actually, can any
Clojure editors change symbols’ colors based on if they match a
pattern like *a*?)

Because Daniel Warner and Jarkko Oranen both said they think
underscores are undesirable, I suspect that a lot of other Clojure
users feel the same too. Right now, I’m thus leaning toward using -
vector-. I’ve just tried replacing all rule symbols in one of my  
files

with -blah-, and it actually looks a little pretty. If I don’t hear
any other good suggestions, I think I’ll use circumfix hyphens, then.

On Feb 25, 8:31 pm, Sean Devlin francoisdev...@gmail.com wrote:




Hmmm... maybe I misunderstood your point.  Is the intent of your
naming conventions:


a.  Something that is human readable but does not affect the  
execution
of code?  Examples include placing I in front of interface names,  
and

A in front of abstract class names.


b.  Something that other code will use to infer behavior?   
Examples of

this include JUnit 3.8  the get/set Java Bean convention.


If it's a, I made a mistake  my comments don't apply (as a  
matter of
taste I like suffixes).  If it's the behavior version, I think  
that a

special macro is in order (e.g. deftest)



Sean



On Feb 25, 10:22 pm, joshua-choi rbysam...@gmail.com wrote:



Could you explain more what you mean? For instance, how are macros
related to these questions? This just has to do with informal  
naming
conventions, in the same matter as *e or *print-dup*. Are you  
talking

about that it’s possible for naming conventions to interfere with
macros that interpret symbols abnormally if they’re named a certain
way?


Now, I’ve considered just not using any characters to set apart  
rules

completely, but that’ll bring me back to my original problems. The
only disadvantage I can think of to using a convention is that it
might make code that use rules more noisy...but I think that’s
preferable to having to recall what a rule is called if it  
conflicts

with another symbol—which is really common with my rules. What
notation do you all think is the least ugly?



On Feb 25, 7:32 pm, Sean Devlin francoisdev...@gmail.com wrote:


I think using a naming convention isn't a good idea, especially  
when
you have a rich macro system like Clojure.  I'm actually going  
to be
talking about using a reference to handle things like this in  
my next
episode.  For now, you can take a look at my definference macro  
here:


http://github.com/francoisdevlin/devlinsf-clojure-utils/blob/ 
master/s...



Hope this helps,
Sean



On Feb 25, 8:59 pm, joshua-choi rbysam...@gmail.com wrote:


Yeah, I don’t really like the underscores either. But I have  
to work
with the set of currently allowed non-alphanumeric symbol  
characters

(*, +, !, -, _, and ?, according to clojure.org/reader).



There’s actually two different questions here—I’d love for other
people to bring in their input.



I need to set apart “rules”, a certain type of object, from other
kinds of Clojure objects. (Why do you even need to do this?  
people

ask. Because I really want to graphically set them apart in the
programmers mind. And also, rules often shared names with  
objects that
they were representing: it was difficult to remember string- 
char-r vs.
string-char in functions, for instance. It was always a big  
pain. I

think it will be worth it.)



Question 1: Of the allowed characters, which would be best to
distinguish rule symbols from other symbols?


* can be confused with the REPL vars (*1, *e, etc.) and re- 
bindable

vars.
+ may be a better choice, though in the other Lisps it already
indicates constants.
I don’t think ! and ? are good at all, because they really  
stand out

to me to mean destruction and querying respectively.
- is apparently used only once in the standard libraries: in  
defn-.

Maybe it would be a good choice.
_ is ugly, but it’s not used at all, so that’s good. Well,  
except when

used on its own: “_”, for useless bindings.



I’m leaning toward +, -, or _.



Question 2: Prefix, suffix, or circumfix?



+vector, vector+, or +vector+? -vector, vector-, -vector-? Or
whatever. Don’t forget, I’m deciding this for my parser rules  
library.
“vector

Swank Clojure [Re: clojure-dev: #55 ...]

[Terje Norderhaug]

On Feb 13, 2010, at 3:22 PM, Phil Hagelberg wrote:

I should mention that I could use some help co-maintaining
swank-clojure. I don't feel like I have a great grasp on the codebase
right now and have just been keeping it on autopilot after figuring
out packaging issues, but having someone who's familiar with how it
works from CL would be very helpful. Even without CL experience, just
gathering up the various patches into one branch and seeing what works
and what doesn't would be very helpful too. Otherwise I'll get to it
when I have time, but it might not be very prompt.


I am gearing up for considerable involvement in improving swank- 
clojure. I am very familiar with CL swank, having implemented the  
MCLIDE swank client - a Macintosh IDE for Lisp implementations on any  
platform:


   http://mclide.in-progress.com/

I am routinely using swank on various lisp implementations, so I am  
in a good position to help making swank-clojure consistent with the  
normative CL swank server. I'd prefer to work with somebody familiar  
with swank-clojure that could review my contributions and integrate  
them in the codebase.


-- Terje Norderhaug
te...@in-progress.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

Swank Clojure [Re: clojure-dev: #55]

[Terje Norderhaug]

On Feb 13, 2010, at 5:19 PM, wilig wrote:

I'm willing to give maintenance of swank-clojure a shot.  With one
huge caveat: I'm very new to both clojure and CL, so patience will
have to be practiced as I slowly get up to speed on a new code base in
a new language.  Unless anyone with more experience wants to jump in,
I will begin applying patches, and working on open issues.


Your participation is appreciated!

Please consider joining the swank-clojure mailing list:

  http://groups.google.com/group/swank-clojure

-- Terje Norderhaug
  te...@in-progress.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

Re: ClojureCLR under slime / emacs?

[Terje Norderhaug]

On Feb 14, 2010, at 7:43 AM, Shawn Hoover wrote:

On Sat, Feb 13, 2010 at 11:43 PM, Mike K mbk.li...@gmail.com wrote:
Does anyone have ClojureCLR running under emacs via slime?

Failing that, can anyone give me some pointers as to how I might
hacking swank-clojure.el (or whatever) to get this to work?

  Mike

Hi Mike,

I've not heard of anyone doing this. The changes to swank- 
clojure.el would involve changing how it sets up the Clojure  
process. Instead of calling Java with a classpath, it needs to call  
ClojureCLR's executable. The real work would be in the swank- 
clojure clj sources. Every use of a Java standard library class  
would have to be replaced with an appropriate CLR base class  
library class.


Perhaps this could be implemented like CL Swank http://github.com/ 
technomancy/slime, with a portable core and platform specific  
backend modules.


-- Terje Norderhaug
  te...@in-progress.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