Re: no source file
>From where or how did you start you REPL? I copied you source into c: \sqrs.clj and started a REPL: C:\>clojure Clojure 1.1.0 user=> (load-file "sqrs.clj") #'user/square-of-sum user=> (square-of-sum (range 10)) 2025 user=> Clojure can't find your file in the classpath. Matt -- You 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
1.1.0-new-SNAPSHOT / java.lang.ExceptionInInitializerError / JRE 1.6.0 IBM Linux build pxi3260sr7-20091215_02 (SR7)
I have a Hudson Matrix build of some Clojure that I am writing. I just checked in a new piece of code - A trivial implementation of junit.framework TestCase. http://github.com/JulesGosnell/dada/blob/master/src/test/clojure/org/dada/CoreTestCase.clj I'm using Maven 2.2.1 and the clojure plugin to compile down to bytecode and then the surefire plugin to run the tests. The bytecode is instrumented with Cobertura - but this has never caused a problem before. http://github.com/JulesGosnell/dada/blob/master/pom.xml My matrix builds on several linux JVMs http://ouroboros.dnsalias.net/hudson/job/dada-matrix/ The IBM Jvm is the only one that spat out this new code. Running org.dada.CoreTestCase org.apache.maven.surefire.booter.SurefireExecutionException: org.dada.CoreTestCase; nested exception is java.lang.ExceptionInInitializerError: null; nested exception is org.apache.maven.surefire.testset.TestSetFailedException: org.dada.CoreTestCase; nested exception is java.lang.ExceptionInInitializerError: null org.apache.maven.surefire.testset.TestSetFailedException: org.dada.CoreTestCase; nested exception is java.lang.ExceptionInInitializerError: null java.lang.ExceptionInInitializerError at java.lang.J9VMInternals.initialize(J9VMInternals.java:222) at java.lang.Class.forNameImpl(Native Method) at java.lang.Class.forName(Class.java:169) at clojure.lang.RT.loadClassForName(RT.java:1516) at clojure.lang.RT.load(RT.java:389) at clojure.lang.RT.load(RT.java:371) at clojure.core$load__5634$fn__5642.invoke(core.clj:4178) at clojure.core$load__5634.doInvoke(core.clj:4177) at clojure.lang.RestFn.invoke(RestFn.java:409) at clojure.lang.Var.invoke(Var.java:365) at org.dada.CoreTestCase.(Unknown Source) at java.lang.J9VMInternals.initializeImpl(Native Method) at java.lang.J9VMInternals.initialize(J9VMInternals.java:200) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java: 44) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java: 39) at java.lang.reflect.Constructor.newInstance(Constructor.java:516) at junit.framework.TestSuite.createTest(TestSuite.java:135) at junit.framework.TestSuite.addTestMethod(TestSuite.java:114) at junit.framework.TestSuite.(TestSuite.java:75) at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java: 39) at java.lang.reflect.Constructor.newInstance(Constructor.java:516) at org.apache.maven.surefire.junit.JUnitTestSet.constructTestObject(JUnitTestSet.java: 151) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java: 197) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java: 140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java: 127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 37) at java.lang.reflect.Method.invoke(Method.java:600) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java: 345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java: 1009) Caused by: java.lang.NullPointerException at clojure.lang.APersistentSet.contains(APersistentSet.java:33) at clojure.lang.RT.contains(RT.java:675) at clojure.core$contains_QMARK___4278.invoke(core.clj:972) at clojure.core$load_lib__5590.doInvoke(core.clj:4042) at clojure.lang.RestFn.applyTo(RestFn.java:143) at clojure.core$apply__4051.invoke(core.clj:439) at clojure.core$load_libs__5606.doInvoke(core.clj:4077) at clojure.lang.RestFn.applyTo(RestFn.java:138) at clojure.core$apply__4051.invoke(core.clj:441) at clojure.core$use__5630.doInvoke(core.clj:4155) at clojure.lang.RestFn.invoke(RestFn.java:409) at org.dada.CoreTestCase $loading__5510__auto1.invoke(CoreTestCase.clj:4) at org.dada.CoreTestCase__init.load(Unknown Source) at org.dada.CoreTestCase__init.(Unknown Source) at java.lang.J9VMInternals.initializeImpl(Native Method) at java.lang.J9VMInternals.initialize(J9VMInternals.java:200) ... 33 more I should probably not be using 1.1.0-new-SNAPSHOT, but thought that I should report the issue. thanks Jules -- You received this message because you are s
Re: 1.1.0-new-SNAPSHOT / java.lang.ExceptionInInitializerError / JRE 1.6.0 IBM Linux build pxi3260sr7-20091215_02 (SR7)
Hi, On Feb 26, 10:32 am, Jules wrote: > I just checked in a new piece of code - A trivial implementation of > junit.framework TestCase. > > http://github.com/JulesGosnell/dada/blob/master/src/test/clojure/org/... + > at clojure.core$use__5630.doInvoke(core.clj:4155) > at clojure.lang.RestFn.invoke(RestFn.java:409) > at org.dada.CoreTestCase > $loading__5510__auto1.invoke(CoreTestCase.clj:4) = (ns org.dada.CoreTestCase (:gen-class :extends junit.framework.TestCase :methods [[testCore [] void]]) (:use [org.dada.core]) (:import [junit.framework TestCase])) Try (:use org.data.core) instead of (:use [org.dada.core]). But I don't think, that his is really the problem. It seems that the sorted-set of *loaded-libs* does not get initialised correctly. Caused by: java.lang.NullPointerException at clojure.lang.APersistentSet.contains(APersistentSet.java: 33) At this position the contains method of the underlying map is called and here the exceptions is thrown. So for some reason the underlying map is not really a map but nil. Sincerely Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: 1.1.0-new-SNAPSHOT / java.lang.ExceptionInInitializerError / JRE 1.6.0 IBM Linux build pxi3260sr7-20091215_02 (SR7)
Thanks, Meikel I'll see if that helps. Strangely, although I can replicate the problem in Hudson every time, I am having trouble reproducing it as myself. I'm using the same JVM on the same machine with the same version of the code. I've just scrubbed the Hudson Maven repository and rebuilt - problem persists. Now I have scrubbed my own repo and am rebuilding. I'll post what I find later. Thanks again, Jules On Feb 26, 9:54 am, Meikel Brandmeyer wrote: > Hi, > > On Feb 26, 10:32 am, Jules wrote: > > > I just checked in a new piece of code - A trivial implementation of > > junit.framework TestCase. > > >http://github.com/JulesGosnell/dada/blob/master/src/test/clojure/org/... > > + > > > at clojure.core$use__5630.doInvoke(core.clj:4155) > > at clojure.lang.RestFn.invoke(RestFn.java:409) > > at org.dada.CoreTestCase > > $loading__5510__auto1.invoke(CoreTestCase.clj:4) > > = > > (ns org.dada.CoreTestCase > (:gen-class > :extends junit.framework.TestCase > :methods [[testCore [] void]]) > (:use [org.dada.core]) > (:import [junit.framework TestCase])) > > Try (:use org.data.core) instead of (:use [org.dada.core]). > > But I don't think, that his is really the problem. It seems that the > sorted-set of *loaded-libs* does not get initialised correctly. > > Caused by: java.lang.NullPointerException > at clojure.lang.APersistentSet.contains(APersistentSet.java: > 33) > > At this position the contains method of the underlying map is called > and here the exceptions is thrown. So for some reason the underlying > map is not really a map but nil. > > Sincerely > Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 status?
Two factors: (1) I'm working on deftype/protocols/reify and related things. This requires some non-trivial re-engineering of the compiler (based on non- trivial reverse-engineering of all the changes made to Clojure JVM). (2) I'm up to my nostrils on a little pro bono web site development I foolishly agreed to do. Say the phrases "crunch time" and "flop sweat" over and over again, and you'll have an idea where I am on that. It's definitely slowed me down. I'm trying to keep a small flow of work going on ClojureCLR during this time. Unfortunately, since I'm working on such big chunks, it looks like nothing is happening. Reify is about 90% done, and I've already made a few changes in support of deftype. If I get a little ahead on the other project, I should be able to get reify done in the next week. After that, deftype and protocols. Right after I commit the reify changes, I may take a day to run through all the small commits on the 1.2 branch. That usually doesn't take long. Should I make heartbeat commits once a week so people will know there's still life in the body? :) David On Feb 25, 10:26 pm, Mike K wrote: > I notice there have been no checkins to ClojureCLR in the last month > and a half. Is something big in the works? Is absolutely nothing in > the works? :-) > > If I check out and build the latest sources, how will it compare in > terms of functionality to the Clojure main branch? In particular, > does it have cutting edge things like protocols, reify, etc? > > Thanks, > Mike -- You 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: Vimclojure Performance on Windows
Thanks for quick response. I will use vimclojure google group in the future. Since I am the first to report the problem it is likely that it might be machine/vim setup specific. I will repeat on different machine then. On Feb 26, 1:22 am, Meikel Brandmeyer wrote: > Hi, > > On Feb 25, 4:46 pm, Vitaly Peressada wrote: > > > Installed vimclojure-2.1.2 on Windows XP SP3. Have dual-core machine > > and 4GB of RAM. In VimRepl > > (println "Hello World") takes about 10 seconds. Is this expected? > > No. Vim shells out to another process. This is the only real portable > and stable way to talk to other process with Vim. This is slow. > However on my MacBook (dual-core, 1G RAM) the delay is not noticeable. > On my crappy Windows Laptop (single-core, 1.7Gh, 2G RAM) at work, the > delay is noticeable but well below a second. > > The only exception is the first command, which (as a side effect) sets > up the whole clojure machinery in the background. But subsequent > commands should be much faster. > > > Any suggestions how to speed this up? > > No clue. You are the first to report such a problem. > > Sincerely > Meikel > > PS: there is also the vimclojure google group for such support issues. -- You 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
Rails-like database migrations for use with clojure.contrib.sql
I've made a stab at implementing rails-like database migrations for use with clojure.contrib.sql. The codes currently very crude, but I'd appreciate any comments on style/utility: http://gist.github.com/315787 Currently the hariest bit is in testing whether or not we need to construct the schemaversion table. It does this via exceptions right now which is very ugly (especially because of nested exceptions etc..), but I couldn't figure out how to get derby to test for the presence of the table. Anyway, I'd appreciate any feedback and criticism. Also I noticed that clojure.contrib.sql doesn't have support for creating views. Is this a deliberate design choice, or just an omission? -- Rick Moynihan http://twitter.com/RickMoynihan http://delicious.com/InkyHarmonics http://sourcesmouth.co.uk/ -- You 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: 1.1.0-new-SNAPSHOT / java.lang.ExceptionInInitializerError / JRE 1.6.0 IBM Linux build pxi3260sr7-20091215_02 (SR7)
OK, So, I have had every variable between the automated (Hudson) build and the manual build out on the bench and fiddled with each one in turn... Of course, it turns out to be something to do with very last variable that i expected it to be. It seems to be something to do with the Hudson Matrix Plugin... I now have two test builds running in Hudson - one is a simple build, using the IBM JVM etc - works fine. http://ouroboros.dnsalias.net/hudson/job/dada-ibm/1/console The other is a Matrix build - all the same variables - it fails with the problem that I reported. http://ouroboros.dnsalias.net/hudson/job/dada-ibm-matrix/jdk=java-ibm-6,label=linux/1/console How on earth it can be affecting just the IBM JVM I can't imagine, since I ask Surefire to fork it. Perhaps the matrix plugin is quietly setting some environmental variable and exporting it Or - I am going mad ? Now that this looks like a Hudson thing and not a Clojure one, I'll go offline with it. Thanks for all your help, Jules On Feb 26, 11:20 am, Jules wrote: > Thanks, Meikel > > I'll see if that helps. > > Strangely, although I can replicate the problem in Hudson every time, > I am having trouble reproducing it as myself. > > I'm using the same JVM on the same machine with the same version of > the code. > > I've just scrubbed the Hudson Maven repository and rebuilt - problem > persists. Now I have scrubbed my own repo and am rebuilding. I'll post > what I find later. > > Thanks again, > > Jules > > On Feb 26, 9:54 am, Meikel Brandmeyer wrote: > > > Hi, > > > On Feb 26, 10:32 am, Jules wrote: > > > > I just checked in a new piece of code - A trivial implementation of > > > junit.framework TestCase. > > > >http://github.com/JulesGosnell/dada/blob/master/src/test/clojure/org/... > > > + > > > > at clojure.core$use__5630.doInvoke(core.clj:4155) > > > at clojure.lang.RestFn.invoke(RestFn.java:409) > > > at org.dada.CoreTestCase > > > $loading__5510__auto1.invoke(CoreTestCase.clj:4) > > > = > > > (ns org.dada.CoreTestCase > > (:gen-class > > :extends junit.framework.TestCase > > :methods [[testCore [] void]]) > > (:use [org.dada.core]) > > (:import [junit.framework TestCase])) > > > Try (:use org.data.core) instead of (:use [org.dada.core]). > > > But I don't think, that his is really the problem. It seems that the > > sorted-set of *loaded-libs* does not get initialised correctly. > > > Caused by: java.lang.NullPointerException > > at clojure.lang.APersistentSet.contains(APersistentSet.java: > > 33) > > > At this position the contains method of the underlying map is called > > and here the exceptions is thrown. So for some reason the underlying > > map is not really a map but nil. > > > Sincerely > > Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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?
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 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 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 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 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 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” means a rule that can parse strings representing
vectors.
Could everyone give me their opinion? Whi
Re: Prefixed or suffixed symbols?
Hello,
2010/2/26 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.
>
Maybe ideally, but to do so an editor would have not only to read the source
code, but also to execute it, as soon as the meta-information on the symbol
is added by a macro call. Not all editors can do that currently.
(I know of ccw for coloring differently words with the same name as core
symbols of macro nature from the others. Not sure for other editors).
>
> -- Terje Norderhaug
>
> On Feb 25, 10:50 pm, joshua-choi 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 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 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 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 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
clojure-contrib on build.clojure.org
Hi, Does build.clojure.org have the release version of the clojure-contrib? I only see the release version of clojure itself at http://build.clojure.org/snapshots/org/clojure/clojure/1.1.0/ but for clojure-contrib I only see snapshots at http://build.clojure.org/snapshots/org/clojure/clojure-contrib/ -- Omnem crede diem tibi diluxisse supremum. -- You 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-contrib on build.clojure.org
On Feb 26, 2010, at 19:34 , Wilson MacGyver wrote: > Hi, > > Does build.clojure.org have the release version of the > clojure-contrib? On a related note, it'd be great if there were something like a short note on what the names of the current clojure jars on mvn/lein are on clojure.org. Like a note somewhere like: Stable: [org.clojure/clojure "1.1.0"] [org.clojure/clojure-contrib "1.1.0"] Development: [org.clojure/clojure "1.2.0-SNAPSHOT"] [org.clojure/clojure-contrib "1.2.0-SNAPSHOT"] Note: Those are examples and I'm not sure if they are truely stable or even exist :P -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Rails-like database migrations for use with clojure.contrib.sql
I've had rails like migrations working in Conjure (0.4 coming soon) for a while. You may want to look at it for some help. To deal with the table schema problem, I had to create flavors for each database Conjure supports. I don't think there's much you can do to avoid flavors when you're trying to reflect on tables in a database. Files of interest in Conjure: http://github.com/macourtney/Conjure/blob/master/file_structure/default/script/migrate.clj Everything in: http://github.com/macourtney/Conjure/tree/master/file_structure/default/vendor/conjure/migration/ Database flavors: http://github.com/macourtney/Conjure/tree/master/file_structure/default/db/flavors/ I hope that helps. -Matt Courtney On Feb 26, 10:35 am, Rick Moynihan wrote: > I've made a stab at implementing rails-like database migrations for > use with clojure.contrib.sql. > > The codes currently very crude, but I'd appreciate any comments on > style/utility: > > http://gist.github.com/315787 > > Currently the hariest bit is in testing whether or not we need to > construct the schemaversion table. It does this via exceptions right > now which is very ugly (especially because of nested exceptions > etc..), but I couldn't figure out how to get derby to test for the > presence of the table. > > Anyway, I'd appreciate any feedback and criticism. > > Also I noticed that clojure.contrib.sql doesn't have support for > creating views. Is this a deliberate design choice, or just an > omission? > > -- > Rick > Moynihanhttp://twitter.com/RickMoynihanhttp://delicious.com/InkyHarmonicshttp://sourcesmouth.co.uk/ -- You 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
classpath problem while invoking Clojure from Java?
I have a NetBeans project where my REPL shows the following path in
the classpath:
# , and I can execute a script with
clojure.lang.RT.loadResourceScript("foo/bar/baz.clj"), which is
located in /home/my-proj/src/clj/foo/bar/baz.clj with no problems.
On another project which is the same as the preceding but with a
Maven2 structure, I have the following in the classpath # but the same
clojure.lang.RT.loadResourceScript("foo/bar/baz.clj") fails with
'Clojure source not found in classpath', although the file is in /home/
my-proj/src/main/java/foo/bar/baz.clj.
Since the directory structures are similar I don't understand what
might me causing this problem.
Thanks
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: ClojureCLR status?
On Fri, Feb 26, 2010 at 6:44 AM, dmiller wrote: > Two factors: > > (1) I'm working on deftype/protocols/reify and related things. This > requires some non-trivial re-engineering of the compiler (based on non- > trivial reverse-engineering of all the changes made to Clojure JVM). > (2) I'm up to my nostrils on a little pro bono web site development I > foolishly agreed to do. Say the phrases "crunch time" and "flop > sweat" over and over again, and you'll have an idea where I am on > that. It's definitely slowed me down. > > I'm trying to keep a small flow of work going on ClojureCLR during > this time. Unfortunately, since I'm working on such big chunks, it > looks like nothing is happening. > > Reify is about 90% done, and I've already made a few changes in > support of deftype. If I get a little ahead on the other project, I > should be able to get reify done in the next week. After that, > deftype and protocols. Right after I commit the reify changes, I may > take a day to run through all the small commits on the 1.2 branch. > That usually doesn't take long. > > Should I make heartbeat commits once a week so people will know > there's still life in the body? :) > I vote for checking in once in a while, perhaps on a separate development branch. -- Cosmin Stejerean http://offbytwo.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-contrib on build.clojure.org
On Fri, Feb 26, 2010 at 12:34 PM, Wilson MacGyver wrote: > Hi, > > Does build.clojure.org have the release version of the > clojure-contrib? > > I only see the release version of clojure itself > at http://build.clojure.org/snapshots/org/clojure/clojure/1.1.0/ > > but for clojure-contrib I only see snapshots at > http://build.clojure.org/snapshots/org/clojure/clojure-contrib/ > The release jars are at http://build.clojure.org/releases/org/clojure/clojure-contrib/ -- Cosmin Stejerean http://offbytwo.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
