Re: [clojure.spec] Best practices for programmatically generating specs?

[Aaron Brooks]

An eval requirement will still be an impediment to me but it's good to hear 
that things are still being worked on. I'm happy to do any early testing of 
proposed approaches and give feedback.

Thanks for letting me know -- keep us posted!

-Aaron

On Wednesday, December 13, 2017 at 10:45:56 PM UTC-5, Alex Miller wrote:
>
> Another possible option is using spec specs (CLJ-2112) to unform from a 
> spec data form to a spec (but that would still need to be evaluated) - 
> still very much a wip.
>
> However, we are working on a spec update that will target some of this, so 
> stay tuned for that.
>
>
>
> On Wednesday, December 13, 2017 at 5:14:34 PM UTC-6, Aaron Brooks wrote:
>>
>> I've found in several projects that I want to have families of specs that 
>> have some shared structure but some differing structure.
>>
>> Consider a case where I have some, possibly nested, structure which in 
>> some cases will have some type of  place-holder values which will later be 
>> replaced with actual values. I don't want a spec to have an 's/or at each 
>> position that could have a place-holder since I expect the structure to be 
>> populated with only place-holder values or only resolved values and want to 
>> exclude a mix.
>>
>> Neither do I want to maintain two versions of the spec by hand. Some of 
>> the structure is complex and would be a pain to keep the two in sync.
>>
>> This appears to leave two choices.
>>
>> I'd like to describe the spec and then walk the spec, generating the 
>> other spec instance. Due to the macro-y nature of spec, I think this means 
>> eval which makes this not cljc/cljs friendly for self-hosted ClojureScript.
>>
>> The alternative seems to be to build a set of macros that will generate 
>> both forms of the specs. This is awkward since it requires the full spec to 
>> be defined within the macro form and winds up being much more complex than 
>> a walk-and-transform of one spec into another.
>>
>> What is the best practice for generating specs like this? Am I missing 
>> something?
>>
>> I'm afraid the current macro-y, non-data-y implementation of 
>> clojure.spec.alpha really renders certain usage patterns (say specs that 
>> are derived from meta-specs) very awkward or inaccessible. I know spec 
>> needs to capture symbols and forms but wish that was a ease interface on 
>> top of a data oriented implementation that was first-class.
>>
>> Let me know if I'm missing something in how I'm thinking about this or 
>> what my available options are.
>>
>> Thanks!
>>
>> -Aaron
>>
>

-- 
You 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.spec] Best practices for programmatically generating specs?

[Aaron Brooks]

I've found in several projects that I want to have families of specs that 
have some shared structure but some differing structure.

Consider a case where I have some, possibly nested, structure which in some 
cases will have some type of  place-holder values which will later be 
replaced with actual values. I don't want a spec to have an 's/or at each 
position that could have a place-holder since I expect the structure to be 
populated with only place-holder values or only resolved values and want to 
exclude a mix.

Neither do I want to maintain two versions of the spec by hand. Some of the 
structure is complex and would be a pain to keep the two in sync.

This appears to leave two choices.

I'd like to describe the spec and then walk the spec, generating the other 
spec instance. Due to the macro-y nature of spec, I think this means eval 
which makes this not cljc/cljs friendly for self-hosted ClojureScript.

The alternative seems to be to build a set of macros that will generate 
both forms of the specs. This is awkward since it requires the full spec to 
be defined within the macro form and winds up being much more complex than 
a walk-and-transform of one spec into another.

What is the best practice for generating specs like this? Am I missing 
something?

I'm afraid the current macro-y, non-data-y implementation of 
clojure.spec.alpha really renders certain usage patterns (say specs that 
are derived from meta-specs) very awkward or inaccessible. I know spec 
needs to capture symbols and forms but wish that was a ease interface on 
top of a data oriented implementation that was first-class.

Let me know if I'm missing something in how I'm thinking about this or what 
my available options are.

Thanks!

-Aaron

-- 
You 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: T-shirts?

[Aaron Brooks]

Out of curiosity, who is behind
ClojureAppreciation?
(i.e Who gets the ~21% markup?)

If this is Rich and/or Tom, I'm more than glad to pay $37 for a t-shirt. If
it's a for-profit entity (such as Cognitect), I think the price is a bit
extravagant (personally... which you can ignore :) ). I just want to know
where the money is going.

In any case, thanks for making these available!

-A.

On Mon, Nov 25, 2013 at 11:31 AM, Rich Hickey  wrote:

> Official T shirts are finally available!
>
> http://clojure.org/swag
>
> Thanks for your support,
>
> Rich
>
> On Jul 29, 2013, at 5:27 PM, s...@ummon.com wrote:
>
> > Speaking as the person who "made" the 'Clojure = Simplicity'
> hoody/t-shirt, I am more than happy to assign it to the clojure community
> if wanted. I created it a while back as I couldn't find any. I will also
> gladly donate my zazzle balance (all $8.12 of it) from the sales :)
> >
> > Regards
> > S.
> >
> >  Original Message 
> > Subject: Re: T-shirts?
> > From: James Rothering 
> > Date: Mon, July 29, 2013 5:16 pm
> > To: clojure@googlegroups.com
> >
> > +1 I'll buy, too.
> >
> >
> > On Mon, Jul 29, 2013 at 1:38 PM, Joel Holdbrooks 
> wrote:
> > +1. I'd love this.
> >
> > On Sunday, July 28, 2013 3:22:21 PM UTC-7, Isaac Wagner wrote:
> > There was a discussion a while ago about stickers which led to
> http://clojure.org/swag. Could we get some sanctioned T-shirts as well?
> There are a few Clojure shirts on Zazzle, but what I would be interested in
> is some black, grey, and white shirts with nothing but a big Clojure logo
> on the front and I would love to buy them in a way that supports Clojure.
> >
> > Isaac
> > --
> > --
> > You 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.
> >
> >
> >
> >
> >
> > --
> > Regards,
> >
> > James Rothering
> > 
> > (Msg) 206-888-1776
> > --
> > --
> > You 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.
> >
> >
>
> --
> --
> You 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 clo

ops' macro to tidy +', -', *', /' operations?

[Aaron Brooks]

I'm afraid I have nothing to contribute to the on-going discussions of
what the default numerical behavior should be and what the prime
version operations should do. I did, however, notice that the prime
ops tend to be clustered together in the examples given and seem
likely to be clustered in real usage. It seems that a macro (perhaps
named ops'?) could lexically change the set of core ops
(+,-,*,/,inc,dec,range,etc.) to their prime versions in the given
form. A very weak example just to make usage clear is shown here:

http://gist.github.com/450037

In larger and more complex examples this might make the code more
readable but it also gives the advantage that one can easily test
whole blocks of code, switching back and forth between the prime and
non-prime versions.

Being a macro this would only convert lexically visible operators and
wouldn't affect any operators contained in downstream macros or
functions. It would probably be good to allow users to provide a list
of custom macros and functions which should be toggled to their prime
version.

-Aaron

-- 
You 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: Searching the group archives

[Aaron Brooks]

Rich, Chouser or other Clojure group admin,

It may be helpful to put the search link in the currently unused
welcome message section of the group "Home" page.

-Aaron

On Sat, Aug 29, 2009 at 3:34 PM, Daniel wrote:
>
> On Sun, Aug 30, 2009 at 1:54 AM, Rich Hickey wrote:
>>
>> While the "Search this group" interface seems increasingly anemic, and
>> time-limited in its results, you can get an effective search on the
>> group archives using the advanced search:
>>
>> http://groups.google.com/advanced_search?q=&;
>>
>> Just select google groups and put clojure as the group.
>
> http://groups.google.com/advanced_search?q=&sitesearch=groups.google.com&as_ugroup=clojure
>
> Cheers,
> Daniel
>
> >
>

--~--~-~--~~~---~--~~
You 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: March 20th 2009 Rich Hickey Appreciation Day!

[Aaron Brooks]

Here, here!

+1 +1 +1 ... !!

On Fri, Mar 20, 2009 at 2:26 PM, Rayne  wrote:
>
> I Anthony Simpson, with the support of fellow Clojurists hereby
> declare March 20th, the first day of spring, Rich Hickey appreciation
> day!
>
> Rich Hickey has certainly done a lot for us, making this wonderful
> language and continuing to take his time to work on it. He is
> dedicated and he wants to bring Clojure along with it's users to
> heights that Lisp has never been before. In just some 2 years, Rich
> has gathered together a vibrant and large community of users and
> contributors who believe in Clojure's future immensely . One such
> contributor who believes in Clojure enough to write an entire book on
> it! Clojure gains more attention and support everyday.
>
> I believe in the bright future that Rich Hickey believes exists for
> Clojure. I believe that with this community, and with such a wonderful
> creator as Rich Hickey, Clojure will achieve it's goals and meet the
> destiny that Rich is writing for it.
>
> I thank you Rich Hicky for all your work on Clojure. I thank you for
> all the time you've spent building this community and giving us one of
> the most awesome languages that have existed. Thank you for caring
> about us enough to listen to the community before making big changes,
> I believe in Clojure and I will be here watching it evolve with you!
>
> If you would like to thank Rich Hickey for all he has done for us, you
> can post in this thread, or tell him yourself in the #Clojure IRC
> channel. :)
>
> March 20th 2009 Rich Hickey Appreciation Day
>
> -Rayne
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: "08" and "09" are invalid numbers, but "01" through "07" are fine?

[Aaron Brooks]

Rather than going to the horrible effort  of looking up to see
if Clojure had support for binary notation, I had a Clojure prompt so
I just tried it and got semi-surprising results:

user=> #b010001
java.lang.Exception: No dispatch macro for: b
4097

I'm not surprised that Clojure complains of not knowing what manner of
macro #b is but I was impressed (?) that it still yielded the correct
value. Somewhere, deep in Clojure's little heart, it wants to do other
bases.

So, here's a request -- can we get macro dispatch for other base
numbers? The CL notation is reasonable, already known and quite
readable. Besides, Clojure tells me it /really/ /wants/ to... ;-)

-Aaron

On Fri, Mar 13, 2009 at 9:19 AM, David Sletten  wrote:
>
>
> On Mar 13, 2009, at 3:07 AM, Michael Wood wrote:
>>
>> This is pretty standard behaviour.
>>
>> On the other hand, it's not universal.
>>
>> sbcl:
>>
>> * 07
>>
>> 7
>> * 08
>>
>> 8
>>
>
> Common Lisp uses a separate syntax for binary/octal/hex literals. Legal:
> #b1011, #o377, #xDEADBEEF, #36rZZZ (Base 36 anyone?)
> Illegal:
> #b2, #o8, #xQUICKSAND
>
> (Of course, #36rCLOJURE => 27432414842 :-) )
>
> Aloha,
> David Sletten
>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: categorizing forms

[Aaron Brooks]

Mark,

I've thought about doing this in the past (partially for my own
reference) but never got around to it. Thanks so much for your effort!

It might be beneficial to make the function names links to the API
reference. I also found it a little hard when scanning the functions
to clearly see them as a list, perhaps commas (or the underlining
provided by linking) or background changes would help to separate the
function names. In any case, you've provided a good reference that I'm
sure will be handy to many people. Thanks!

-Aaron

On Sun, Mar 8, 2009 at 8:30 PM, Mark Volkmann  wrote:
>
> I made an attempt at categorizing all special forms, functions and
> macros in clojure.core, plus some outside that namespace. See
> http://www.ociweb.com/mark/clojure/ClojureCategorized.html. I'd love
> some feedback on the names of the categories and whether I've split
> them up correctly. I think a breakdown like this could be a big help
> to developers that are new to Clojure. For example, if they are
> looking for forms that provide conditional processing, it's hard to
> quickly locate them on the API page because it liss every form
> alphabetically.
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: 12 Days of Christmas in idiomatic(?) clojure

[Aaron Brooks]

On Dec 24, 4:20 pm, Mibu  wrote:
> I'd write it this way:
> (apply + (mapcat #(range 1 %) (range 2 14)))
>
> I think idiomatically I would have written it with (partial range 1)
> instead of #(range 1 %), but I prefer compact forms.

In Clojure (anybody correct me if I'm wrong) I think it's preferable
for performance reasons to use reduce instead of apply when you can.
Also, for clarity I think it's much cleaner to have the natural range
instead of one that's been pre-mangled to suit (the numbers "two" and
"fourteen" do not immediately pop in to my head when I think of the
"Twelve Days of Christmas" ;-):

(reduce + (mapcat #(range 1 (inc %)) (range 1 (inc 12

With the above usage of range, it's much easier to see the pattern in
the solution. Every once in a while I wish for an "inclusive-
range" (irange, perhaps) so I wouldn't need the increment but it's
fairly natural to read it as "range from 1 INCluding 12".

-A.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: POLL: Domain name for project hosting site.

[Aaron Brooks]

Other options:

 - creatjure?
 - featjure?
 - cultjure?

All three have low Google search hit counts. I think cultjure is
better suited for discussion forums. Creatjure seems a good place for
our Clojure creatures.

On Nov 17, 2:52 pm, Drew Crampsie <[EMAIL PROTECTED]> wrote:
> Hey All,
>
> I've finally found some time to start getting the project hosting site
> together, and i need a name.. so lets put it to a vote.
>
> Here are some suggestions so far, but please feel free to chime in
> with your own as well.
>
>  - projecture
>  - clojr
>  - proj4cloj
>  - clojforge, cloforj,
>  - forj
> - clojects
> - clojury
> - openjure
>
> Thanks for the help Clojurians!
>
> Cheers,
>
> drewc
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Dealing with keyword-keyed maps in Java land

[Aaron Brooks]

Having looked at Keyword.java, I'll amend my example:

import clojure.lang.Keyword;
x map.get(new Keyword("myns","foo"));

The above may well reveal that I remember very little Java from
previous lives so feel free to correct any errors.

-Aaron.

On Oct 13, 9:33 am, Aaron Brooks <[EMAIL PROTECTED]> wrote:
> All,
>
> I would think that changing or wrapping the map would create confusion
> and additional overhead. In my mind the most natural interaction would
> be to provide a way for Java code to create references to keywords:
>
>     x = map.get(clojure.keyword("foo"));    // ... or something along
> these lines
>
> I'll take a look at the Clojure code but I expect that this would be
> easy to do. Any methods that try to mash strings and keywords into the
> same space seems like it would be mostly application specific as it
> would need to resolve cases where identically named keywords and
> strings exist. The only safe cases would be when a map exclusively
> contains strings or keywords.
>
> Naturally, wouldn't want to demand that you don't want to do what, in
> fact, you want to do. I think Clojure would best cater to the safe,
> predictable cases and leave the hairy cases up to individual
> developers.
>
> -Aaron
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Dealing with keyword-keyed maps in Java land

[Aaron Brooks]

All,

I would think that changing or wrapping the map would create confusion
and additional overhead. In my mind the most natural interaction would
be to provide a way for Java code to create references to keywords:

x = map.get(clojure.keyword("foo"));// ... or something along
these lines

I'll take a look at the Clojure code but I expect that this would be
easy to do. Any methods that try to mash strings and keywords into the
same space seems like it would be mostly application specific as it
would need to resolve cases where identically named keywords and
strings exist. The only safe cases would be when a map exclusively
contains strings or keywords.

Naturally, wouldn't want to demand that you don't want to do what, in
fact, you want to do. I think Clojure would best cater to the safe,
predictable cases and leave the hairy cases up to individual
developers.

-Aaron
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Native library calls from Clojure via JNA

[Aaron Brooks]

All,

I've had success using JNA to call system libraries I thought I'd post
an example snippet in case it helps someone else. The below demo
requires a clojure-contrib.jar from http://sf.net/projects/clojure-contrib
and a jna.jar from
https://jna.dev.java.net/ (be sure it's actually, jna.jar not one of
the platform specific jar -- I got stuck for a while trying to get the
platform specific jar working when the generic jna.jar works fine).
The below is *NIX specific and runs fine on my Gentoo Linux x86_64
system with Java 1.6.0.

JNA is slower than a hard coded JNI interface but for the 99% of
system poking that one might want to do (iNotify, ioctls, UDS, etc.)
it should work very nicely. Feel free to ask questions in case the
example isn't clear but be forewarned -- the below encapsulates 100%
of my JNA + Clojure knowledge so far. ;-)

; glibc from Clojure via JNA
(ns jnatest
  (:import (com.sun.jna Library Native))
  (:use (clojure.contrib gen-interface)))

(gen-and-load-interface 'jnatest.CLibrary [Library]
['getppid [] Integer]
['getpid [] Integer]
['sleep [Integer] Void])

(def glibc (Native/loadLibrary "c" jnatest.CLibrary))

(println "Parent's PID: " (.getppid glibc))
(println "My PID: " (.getpid glibc))

(println "Now show that we can sleep:")
(time (.sleep glibc 2))
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Clojure: self hosting and .Net port?

[Aaron Brooks]

On Sep 24, 9:37 am, soyrochus <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I have been playing with Clojure. Impressive indeed. I´ve got two
> questions. Please consider these to be idle speculation (and as such
> worthy of your attention) and no "feature requests".
>
> First, is there any intention to make Clojure self hosting? No
> technical barriers here, I guess, but priorities and intention count
> all the more so.
>
> I know that (presumable before public release) there was a .Net
> version of Clojure. Are there any plans or initiatives under way to
> recreate this, iaw to port Clojure to .Net?
>
> Regards,
>
> Iwan van der Kleijn

Iwan,

A precursor to Clojure started its life on both the JVM and .Net. Rich
saw that Clojure really needed to marry one platform or the other due
the overhead of maintaining the ports and the level of possible
integration with the hosting platform so he chose the JVM. That said,
Clojure can run through a Java/JVM compatibility layer on .Net called
iKVM: http://www.ikvm.net/

-Aaron
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: "Getting Started" is NOT starting for me...

[Aaron Brooks]

Cliff,

This works fine for me with Sun JDK  1.6.0.05 on Gentoo Linux. I
assume this is on Windows for you?

-Aaron

On Sep 19, 1:25 pm, cliffc <[EMAIL PROTECTED]> wrote:
> I downloaded clojure to my pc. I tried the "Getting Started" page:
>
>   user=> (+ 1 2 3)
>   6
>
> Worked great...  next step:
>
>   user=> (. javax.swing.JOptionPane (showMessageDialog nil "Hello
> World"))
>
> This hangs for me; the java process is idle.  No output, no dialog box
> or GUI.  I'm using HotSpot 1.6.0_07 -client.
>
> Thanks,
> Cliff
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---