Re: Too many arguments to if
Either this, or use the "when" form. http://clojuredocs.org/clojure_core/clojure.core/when 2011/7/11 Tassilo Horn : > Antonio Recio writes: > > Hi Antonio, > >> I get the error "Too many arguments to if" with this. Do you have any >> suggestion? > > `if' expects exacly one test, one then-form, and one else-form. Your > first and second `if' contain two forms in else. You have to wrap them > in a `do'. > > --8<---cut here---start->8--- > (defn make-tree [tree [n1 n2 n3 n4]] > (.addItem tree n1) > (if (empty? n2) > (.setChildrenAllowed tree n1 false) > (do > (doto tree > (.addItem n2) > (.setParent n2 n1) > (.expandItemsRecursively n1)) > (if (empty? n3) > (.setChildrenAllowed tree n2 false) > (do > (doto tree > (.addItem n3) > (.setParent n3 n2) > (.expandItemsRecursively n2)) > (if (empty? n4) > (.setChildrenAllowed tree n3 false) > (do > (doto tree > (.addItem n4) > (.setParent n4 n3) > (.expandItemsRecursively n3) > (.setChildrenAllowed n4 false) > tree > --8<---cut here---end--->8--- > > Bye, > Tassilo > > -- > 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
Re: REST library
Shantanu Kumar wrote: > On Feb 17, 3:05 pm, Roman Roelofsen > wrote: > >> Hi, >> >> does someone knows a good Clojure REST framework? It should help with >> URL destructuring and maybe creating JSON return data etc. >> > > You can take a look at Taimen (in Alpha now) - > http://code.google.com/p/bitumenframework/ > > Taimen doesn't do serialization for you, but you can use clojure.json > for that. > > This is also worth taking a look at: > http://code.google.com/p/implementing-rest/wiki/ByLanguage > > Regards, > Shantanu > > Thanks! Roman -- 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
REST library
Hi, does someone knows a good Clojure REST framework? It should help with URL destructuring and maybe creating JSON return data etc. Cheers, Roman -- 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: Removing (gensym) in macro
> It doesn't work because the scope of lname# is limited to the `(). > However lname is used in a ~@() which leaves the `() and enters the > enclosing environment (in this case the macros). There the lname# is > not valid. Ah, that makes sense, thanks! Is using (gensym) the common solution here? So far I thought that (gensym) is more a internal function that I normally never need to call directly. -- 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: Removing (gensym) in macro
> I don't see a compelling reason for such a macro. At least not in this > simple case. I agree. As I said, the purpose of this macro was purely for learning and understanding macros ;-) -- 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
Removing (gensym) in macro
Hi, just for practicing Clojure's macros I wrote the following create-java-list macro. (defmacro create-java-list [& forms] (let [prefixfn (fn [obj form] (cons (symbol ".") (cons obj form))) lname (gensym)] `(let [~lname (java.util.ArrayList.)] ~@(map (partial prefixfn lname) forms) ~lname))) The idea is that you can write (let [javalist (create-java-list (add "1") (add "2"))] (prn javalist)) instead of (let [javalist (java.util.ArrayList.)] (.add javalist "1") (.add javalist "2") (prn javalist)) Is it possible to create the macro without the (gensym) call? I wasn't able to use something like lname#. Cheers, Roman -- 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
ClojureQL insert data from map
Hi,
when querying data in clojureql, the result is a list of maps. I often
directly return this list (or a map) from my "db-logic" functions
because my domain logic operates on these maps. However, I am not able
to go the other way around, e.g. take the map and tell clojureql to
insert/update a table row. Currently I have to do this:
(sql/insert-into Person
[firstname "Roman"
lastname "Roelofsen"]))
What I would like to do is something like this:
(def person {:firstname "Roman" :lastname "Roelofsen"})
(sql/insert-into Person person))
Is this possible?
Cheers,
Roman
--
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: Full Disclojure - I Need Topics!
2010/1/25 Mark Engelberg : > Debugging techniques, including: > * How to make sense of Clojure's stack traces. > * How to use Java debugging and profiling tools with Clojure. +1 -- 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: Semantic Versioning
> Talking of semantics, do you think the one I enumerated would work? > I'll certainly try to implement this concept, but I have many other > projects on the table right now, so it might take a while before I > start working on it. Yes, it looks good. The key thing is that all users/developers agree on this. IMHO this is much harder than defining/choosing a good version scheme ;-) >> However, the problem in Java is dealing with versions at runtime, not >> at build time! > > It's sure would be a nice addition, but dealing with versioning at > build time would at least give library users some assurance. IMHO, no. This is the whole problem. Library users will mostly care about the runtime. It doesn't help at all if your code compiles, maybe in isolated pieces, but everything blows up at runtime. For example, I never had problems compiling against the correct Log4j version. Maven will set up the classpath for each "compiliation unit" (here Maven module) individually. But I stopped counting how often the runtime screw up because several libraries were using log4j, all expecting different version, and the whole classpath was a total mess of different jar files, redundancy and shadowed classes. Solving this problem at runtime implies a solution for build time but not the other way around. > My knowledge of Java's classloader is pretty limited, I'll look at > OSGi and Clojure's classloader to see what I can do, but don't expect > miracles ;-) I am looking at this constantly :-) I am working on an intergration layer (http://wiki.github.com/romanroe/ogee) but I haven't had much time in the last weeks. Ogee also has a small context-oriented programming module and I am focusing on this anyway currently. -- 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: Semantic Versioning
Dealing with version numbers at build time is quite easy with tool like Maven. The important thing is that everyone agrees on the same version semantics (great summary [1]). Putting some more tooling around this should be a good idea, yes. However, the problem in Java is dealing with versions at runtime, not at build time! Java's classloader design has not knowledge about versions, etc and makes it impossible to deal with versions without a new layer on top of it. The default system for dealing with this in Java is OSGi. Unfortunately, Clojure's classloader design seems to be completely incompatible with OSGi. If we could solve this, Clojure would instantly get multi version support. Cheers, Roman [1] http://www.osgi.org/blog/2009/12/versions.html 2009/12/16 Nicolas Buduroi : > Hi, on the CommonJS Google Group there was a discussion on semantic > versioning, a formalization of the concept of properly using a common > version number scheme (Major.Minor.Patch) for libraries. > > http://semver.org/ > > I think it would be especially easy to enforce a simple version of > this system in a Clojure project. A program could inspect code and > decide what version number to use during build time. The major version > could be changed automatically once a public function, multi-method or > macro arguments list change in a non-backward compatible way and also > when some of them are removed. The patch version number could be > incremented when code change (but not the API) and existing tests > don't change or new tests have been added. The minor version could be > incremented in other cases. This implementation have it's quirks, like > not being able to check for return types. Doing it for real would > certainly uncover a more lot subtle details. > > What do you thinking about this idea? How would you improve it? > > - budu > > -- > 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
Disabling ContextClassLoader
It seems that Clojure heavily uses the ContextClassLoader to load classes and compile clj files. Is there a way to disable this behaviour and tell the Clojure runtime to always use the ClassLoader where the .clj or .class file originally came from? I found some flags in the RT class but I am not sure how they can be used or if this is even possible. Thanks, Roman -- 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: Generalizing -> & ->>
Are there any plans to add -$> to core or contrib? 2009/11/13 Laurent PETIT : > Oh yes, thanks for refreshing my memory. > And indeed it makes sense to place the question mark in the "questioned" side > :) > > 2009/11/13 Wilson MacGyver : >> Yes, it's groovy, and it's "?." It's called safe navigation operator >> >> http://groovy.codehaus.org/Operators#Operators-SafeNavigationOperator%28%3F.%29 >> >> On Thu, Nov 12, 2009 at 6:03 PM, Laurent PETIT >> wrote: >>> 2009/11/3 Alex Osborne : Sean Devlin wrote: > This is slightly unrealted, but how does one pronounce ->, ->> and the > like? Is this documented? The doc-strings usually give you a nice hint. I usually use "thread" for -> and "thread last" for ->>. The actual symbols I think of as "arrow" and "double arrow". Then -?> in contrib is "short-circuiting thread". Not sure about the symbol, perhaps "questionable arrow"? ;-) >>> >>> The question mark ? is there to "mimic" (somewhat) what one can find >>> in OO languages such as groovy (I think it's groovy, is it ?) : >>> >>> someObject.?propA.?prop2 >>> >>> where .? will check if the object is null before trying to get a >>> property (or method) on it. If null : returns null, if not null, >>> returns the property etc. >>> >>> Initially i wanted to name it ->? but the final ? is by convention >>> reserved for predicates, so Rich suggested -?> (and also .?. for the >>> .. equivalent). >>> >>> -- >>> 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 >> >> >> >> -- >> 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 > > -- > 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
Re: 'sync' call in writeClassFile
I am a Linux user as well and this indeed sounds a bit alarming (but I haven't tested it on my machine yet, though...) Does somebody has a bit more information about the reason, current state, etc.? Thanks! 2009/11/28 David Brown : > This commit: > > commit 5577a47a390782d7ab911c2e3c4c8be1b0341aa8 > Author: Rich Hickey > Date: Sat Feb 7 14:46:56 2009 + > > added sync to writeClassFile > > Adds a 'sync()' call to the class file write. On systems where the > underlying fsync() call causes a flush all the way to disk (Linux) > this makes AOT compilation about an order of magnitude slower, > especially given the large number of functions in typical clojure > code. > > Anyone know the history behind this? It makes AOT compilation on > Linux about 5x slower than on OSX. > > The call to sync() takes longer than the compilation did. It would be > a win to just clean all of the class files and rebuild after a crash. > > The current behavior makes working off of battery on a laptop > unworkable, since it keeps the harddisk from spinning down. > > These are just the output of the compiler, easily regenerated. > > David > > -- > 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
Re: Continuous Integration Server & Maven/Ivy Repo
His second post referred to https://www.assembla.com/spaces/clojure/tickets/208-pom-uses-old-artifactId So until this ticket is closed we need to use clojure-lang instead of clojure. Roman 2009/11/4 Stuart Sierra : > > Dysinger's post implies it should be "clojure" instead of "clojure- > lang", i.e. http://build.clojure.org/org/clojure/clojure/maven-metadata.xml > > That URL doesn't work. > -SS > > > On Nov 4, 10:50 am, Roman Roelofsen > wrote: >> It seems that only directory listings are disabled since >> >> http://build.clojure.org/org/clojure/clojure-lang/maven-metadata.xml >> >> is accessible. >> >> Roman >> >> 2009/11/4 Stuart Sierra : >> >> >> >> > I don't think that URL works as a Maven/Ivy repository, because >> >http://build.clojure.org/org/clojuredoesn't exist. >> > -SS >> >> > On Nov 3, 10:10 pm, dysinger wrote: >> >> Hello, >> >> >> Today Phil Hagelberg, Rich Hickey and myself setup a CI server for >> >> clojure & contrib ->http://build.clojure.org(hudson-> github) >> >> >> If you use maven-ant-tasks (+1) or maven 2.x (or ivy too) you can do >> >> something like this in your settings.xml or pom.xml >> >> >> >> >> clojure-snapshot >> >> http://build.clojure.org >> >> >> >> false >> >> >> >> >> >> true >> >> >> >> >> >> >> Then you can add clojure snapshot as a project dependency >> >> >> >> >> org.clojure >> >> clojure >> >> 1.1.0-alpha-SNAPSHOT >> >> >> >> >> :) #l8r >> >> > > > --~--~-~--~~~---~--~~ 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: Continuous Integration Server & Maven/Ivy Repo
It seems that only directory listings are disabled since http://build.clojure.org/org/clojure/clojure-lang/maven-metadata.xml is accessible. Roman 2009/11/4 Stuart Sierra : > > I don't think that URL works as a Maven/Ivy repository, because > http://build.clojure.org/org/clojure doesn't exist. > -SS > > On Nov 3, 10:10 pm, dysinger wrote: >> Hello, >> >> Today Phil Hagelberg, Rich Hickey and myself setup a CI server for >> clojure & contrib ->http://build.clojure.org(hudson -> github) >> >> If you use maven-ant-tasks (+1) or maven 2.x (or ivy too) you can do >> something like this in your settings.xml or pom.xml >> >> >> clojure-snapshot >> http://build.clojure.org >> >> false >> >> >> true >> >> >> >> Then you can add clojure snapshot as a project dependency >> >> >> org.clojure >> clojure >> 1.1.0-alpha-SNAPSHOT >> >> >> :) #l8r > > > --~--~-~--~~~---~--~~ 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: Embedding Clojure in NetKernel
Do you mind sharing the links? I am interested in it as well. Thanks! Roman 2009/10/28 Tony Butterfield : > > Tom Hicks has just pointed me to an old thread which answers > questions about namespaces and isolation. Let me read and > absorb all that work first - I suspect it answers a lot of my > questions. > > Cheers, Tony > > On Oct 28, 11:43 am, Tony Butterfield wrote: >> Hi Everybody >> >> this is my first post to this group so please tell me If I'm posting >> in the wrong place. I've been looking at integrating Clojure into >> NetKernel as language runtime library but I'm struggling a bit for a >> lack of examples. There are two things I'm trying to achieve: >> >> 1) start and stop the Clojure runtime on demand. I need to do this so >> that new versions can be deployed whilst the server is live. Looking >> at the latest version (1.0.0) I see that I no longer need to call >> RT.init() and that startup is done statically. That's fine but is >> there a way to cleanly shutdown. I.e. stop threads, and enable a full >> garbage collection of the Clojure libraries? >> >> 2) is there a way to ensure isolation of functionality in one runtime? >> I can see how I can use namespaces to avoid naming collisions but is >> it possible to enforce tighter security across namespaces or is there >> another technique? I'm quite new to closure so sorry if that is a >> stupid question - the trouble is I want to get it running inside >> NetKernel as good environment to explore the language - horse before >> the cart! When Clojure scripts execute inside NetKernel environment it >> is important that they act like pure functions with no side-effects on >> others. >> >> Thanks in advance for you advice, >> >> Tony > > > > --~--~-~--~~~---~--~~ 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: Statics in clojure.lang.RT
2009/10/12 Christophe Grand : > On Mon, Oct 12, 2009 at 12:00 PM, Roman Roelofsen > wrote: >> >> > Plus, if you use a shared loader for most interfaces, clojure instances >> > will >> > be able to share persistent data and closures. >> >> Nope, I tried this and it didn't work. The classloader explicitly >> complained that e.g. Var and RT have not been loaded by the same >> classloader :-/ > > Sadly I know and that's why I said "most interfaces" (eg all interfaces > starting with "I" and Associative, Counted, Seqable, Reversible and > Sequential are safe) -- at least last time I tried. Good point. And since most clojure data types are based on java types (e.g. Map, Callable) the shared parent classloader is already there. --~--~-~--~~~---~--~~ 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: Statics in clojure.lang.RT
> Plus, if you use a shared loader for most interfaces, clojure instances will > be able to share persistent data and closures. Nope, I tried this and it didn't work. The classloader explicitly complained that e.g. Var and RT have not been loaded by the same classloader :-/ --~--~-~--~~~---~--~~ 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: Does OSGi make sense for Clojure?
@Mark: I doubt that this will work. Unloading a namespace would mean to remove a class from a classloader and this does not work in Java. OSGi handles this by removing the bundle's classloader completely. @All: The huge added value that OSGi still has is multi-version support. Lets say I want to use clojure.contrib version 1.1 and and one of my other libraries wants to use clojure.contrib version 1.0. This clearly does not work in Clojure currently since all Clojure-based classes/namespaces live in one classloader. So currently Clojure suffers from the same JAR-hell issues that are already solved by OSGi :-/ Also, OSGi's service layer could be a nice way to decouple some parts of the application. Additionally, several projects exist that provide "infrastructure features" (e.g. remoting, web server) and they all use the service registry for this. I tried several integration approaches in Ogee but non of them really worked out well: * Full Isolation* We can fully isolate different Clojure Modules (== logical group of jar file(s)) by giving each of them their own classloader that contains the clojure runtime. The problem is that Clojure's startup time is approx. 1 sec so if we install 50 modules it would take way too long to start the application. * Isolation with fine-grained sharing * I tried to extract common not-runtime specific Clojure classes into a shared classloader to allow the modules to interact with each other. E.g. classes like Var, IFn, ... However, there is a circular dependency between Var -> something -> RT -> something -> Var and the RT clearly has to stay isolated. Trying to split this cycle gave me a LinkageError or something like that. Also, Clojure seems to rely on the ContextClassLoader and I worry that one module could accidentally pollute a "foreign" Clojure runtime. I am currently not sure if OSGi's module layer makes sense at all in a dynamic language. In a statically-typed language like Java, the use of classes is baked into the bytecode. Therefore, when class A uses class B, the resolver has to link A's classloader to B's classloader even before A is loaded. That makes it impossible for A to use B in different version. However, this constraint does not apply for a dynamic language like Clojure at all! I think a more idiomatic way for Clojure would be something like this: A namespace could optionally declare a version number: (ns package.fancylib :version 2) This would generate a class like "fancylib__init__$version2.class" or so. When other namespaces require/use the fancylib namespace _without_ a version a number, the Clojure runtime could easily find the latest version: 1) find all "package/fancylib__init__$version*.class" files 2) order them 3) return first entry When other namespaces require/use the fancylib _with_ a version number (require 'package.fancylib :version 2), the Clojure runtime could easily infer the correct classname. I guess it is important that each module has its own class loader and that there is one chaining parent clojure classloader. The module classloader could transparently do the namespace mangling. Ogee is currently based on OSGi but all Clojure modules live in the same classloader. Whenever the Clojure setup changes, Ogee automatically restarts the whole Clojure runtime so at least you get a bit more dynamic feeling. The focus is currently on good idiomatic service layer integration and support for servlets, remoting, configuration management, etc. Maybe Ogee can later implement something like what I described above but for performance reason it's obviously preferable that the Clojure runtime itself provides something in the future. Cheers, Roman 2009/10/6 Mark Derricutt : > I do have a novel idea to work around this but I've yet to put my theory to > code and publish it. > The problems I had when loading clojure based bundles into OSGi was that > after unloading, the classes remained loaded by the bundle providing RT. > The basic idea was to add a bundle listener to the OSGi bundle, that when > uninstalled, unloads the namespace from RT (unfortunately I can't seem to > spot that API anywhere anymore). > mark > On Tue, Oct 6, 2009 at 8:54 AM, Stuart Sierra > wrote: >> >> It's possible to modify Clojure to run under OSGi (search the list >> archives) but fundamentally they don't fit. OSGi assumes that it has >> sole control of class loading. But Clojure needs its own >> classloader. To make them cooperate, I think you would need to >> integrate Clojure with the OSGi container itself. >> >> -SS >> >> >> On Oct 5, 9:54 am, Todor Boev wrote: >> > Hi, >> > I am an OSGi enthusiast. Lately I have been looking at scheme and >> > clojure. I can't help but wonder if there are any genuine benefits >> > clojure can get from being a full OSGi citizen. It seems to me that >> > OSGi is to statically compiled Java what the REPL is for Clojure. >> > Except the REPL is more powerful. Currently OSGi seems like a nice >> > interoperation enviro
Re: Adding Classpaths On The Fly
Hi, I am currently working on a Clojure / OSGi integration: www.ogeesource.org The goal is to extend Clojure with a module-like runtime, not to fully convert Clojure and Clojure-based applications to OSGi (which would be quite hard anyway). So far you can add new modules at runtime and therefore dynamically extend the classpath (removing/updates are not working yet). The project is currently in proof-of-concept state and I can not recommend to start using it! But at least you might want to watch the github repo to stay informed. Cheers, Roman 2009/9/27 Volkan YAZICI : > > For the record, I'm forwarding below reply from Stuart Sierra. > > On Fri, 25 Sep 2009, Stuart Sierra writes: >> On Sep 25, 3:02 am, Volkan YAZICI wrote: >>> - (System/setProperty >>> "java.class.path" >>> (str (System/getProperty "java.class.path") >>> ":/tmp/code")) >> >> The "java.class.path" system property is read-only. And in the >> context of dynamic ClassLoaders (like Clojure's) it's largely >> meaningless. >> >>> - (add-classpath "file:///tmp/code") >> >> add-classpath does not work in some environments and may be removed in >> future versions of Clojure. >> >> Bottom line: you can't dynamically change the Java classpath. > > > > --~--~-~--~~~---~--~~ 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: -> with anonymous functions
Thanks for the explanation!
So the solution is much simpler:
user=> (-> person :childs first (select-keys [:name]))
{:name "Son"}
Cool :-)
On Sep 22, 3:26 pm, Jarkko Oranen wrote:
> On Sep 22, 3:58 pm, Roman Roelofsen
> wrote:
>
>
>
> > Hi there!
>
> > Lets assume I have this map:
>
> > user=> (def person {:name "Father" :childs [{:name "Son" :age 10}]})
>
> > Testing:
>
> > user=> (-> person :childs first)
> > {:name "Son", :age 10}
>
> > Now lets filter the child map:
>
> > user=> (def only-name (fn [m] (select-keys m [:name])))
> > user=> (-> person :childs first only-name)
> > {:name "Son"}
>
> > So why does this not work?:
>
> > user=> (-> person :childs first (fn [m] (select-keys m [:name])))
> > java.lang.RuntimeException: java.lang.IllegalArgumentException: Don't
> > know how to create ISeq from: Symbol (NO_SOURCE_FILE:59)
>
> > Or this?:
>
> > user=> (-> person :childs first #(select-keys % [:name]))
> > java.lang.ClassCastException: clojure.lang.Symbol cannot be cast to
> > clojure.lang.IPersistentVector (NO_SOURCE_FILE:60)
>
> You assume more of -> than you should :)
> -> does not take functions as parameters. It only sees a bunch of
> symbols, as it is a macro, which means it does a code transformation.
> It puts the first form (the symbol person) in the second position of
> the following form (the keyword :childs), which must be a sequence, or
> if it is not, is wrapped in a list first. This repeats recursively
> until there are no more forms left.
> Now, the anonymous function example fails because (-> person :childs
> first (fn [] whatever)) transforms into (fn (first (:childs person)) x
> [] y). which is not what you intended, but nonetheless a correct
> result.
>
> If you look at the examples that work and macroexpand them, you would
> see that (-> person :childs first) transforms first into (-> (:childs
> person) first) and from there to (first (:childs person)) which
> happens to be a valid Clojure expression
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
-> with anonymous functions
Hi there!
Lets assume I have this map:
user=> (def person {:name "Father" :childs [{:name "Son" :age 10}]})
Testing:
user=> (-> person :childs first)
{:name "Son", :age 10}
Now lets filter the child map:
user=> (def only-name (fn [m] (select-keys m [:name])))
user=> (-> person :childs first only-name)
{:name "Son"}
So why does this not work?:
user=> (-> person :childs first (fn [m] (select-keys m [:name])))
java.lang.RuntimeException: java.lang.IllegalArgumentException: Don't
know how to create ISeq from: Symbol (NO_SOURCE_FILE:59)
Or this?:
user=> (-> person :childs first #(select-keys % [:name]))
java.lang.ClassCastException: clojure.lang.Symbol cannot be cast to
clojure.lang.IPersistentVector (NO_SOURCE_FILE:60)
--~--~-~--~~~---~--~~
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: Questions / guidelines for adopting Clojure
Thanks a lot to everbody for the great responses! They certainly helped a lot! Cheers, Roman --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Questions / guidelines for adopting Clojure
Hi all! I've been playing around with Clojure in the last couple of days. Very interesting! However, I have never used a non-OO, lispy, pure functional language before and several questions popped up while digging deeper into the Clojure world. I hope you don't mind if I post them together in one mail. Even though I will use some scala snippets for comparison, this mail is not meant to be a scala vs. clojure flamewar ;-) I think clojure is a great language and I simply want to improve my adoption path with your help ;-) * Syntax * I never used a LISP-like language before and I can't read the clojure code as fluent as code from different languages. Take for example this scala snippet: (0 until 100) map (_ * 2) filter (_ % 3 == 0) I can easily read this line from left to right (just like english) and instantly see whats going on. By contrast, I have to read the clojure version a couple of times to understand it: (filter #(= 0 (rem % 3)) (map #(* 2 %) (range 100))) Is this just a matter of pratice? Do you find it easy to read the clojure version? Also, would it make sense to have a function like this: (apply-chain (range 100) (map #(* 2 %)) (filter #(= 0 (rem % 3 apply-chain could evaluate each parameter and pass the results from left to right. Each parameter (except the first one) would be a partially applied function (if this works in clojure). I know that I could write a macro and adopt clojure to how I would like it to be. But this seems to be more a design question and I don't think that different clojure apps should use different approaches on this level. * Parametrization of "function groups" * Lets say I have a bunch of functions that provide database operations (read, write, delete, ...). They all share information about the database the operate on. In an OO language, I would define these methods in the same class and an instance variable would define the database. The advantage is, that the caller side does not need to be aware of the database name. I can create an instance somewhere and pass around the object. I can also create several objects with different database configurations. Currently I can think of 2 approaches to implement this in clojure: a) Each function also defines a database parameter The downside is that the caller needs to fill in the value every time. b) The function invocation needs be part of something else, e.g. (do- with-db "mydbname" (db-write) (db-read) ... ). Here, the caller still needs to be aware of this setting. What is the clojure way of dealing with this? Do I overvalue this problem because of my OO background? I am not asking for OO features like inheritance. My goal is simply to avoid repetition and scattering. * Dynamic typing * How would you compare the dynamic typing of clojure to e.g. Python or Ruby? I am wondering if it may be easier in clojure since the logic is not based so much on types (less structures to deal with?). I could imagine that macros help as well to minimize the typical errors people make in dynamic languages. What's your opinion? * Real-world macros * Correct me if I am wrong, but it seems that people often use macros for lazy evaluation of parameters. In Scala, it is quite easy to accomplish the same via by-name parameters. E.g. def maybe(lazyarg: => Unit) = if (...) lazyarg lazyarg will be evaluated in the if clause, not when the method 'maybe' gets invoked. I know that macros in clojure are much more powerful. But what are selling points in pratice? What is a unique feature of clojure's macro that you don't want to miss? Sorry for the long posting and thanks a lot for reading it ;-) Cheers, Roman --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
