Re: file io
Hmm - both literal clojure structures, and JSON, are tempting.
JSON is probably my preferred option - but a lot depends on the audience.
If the audience is lisp programmers, then literal structures is probably
ideal.
If the audience is other programmers, I'd probably go for JSON.
If the audience is the geniuses who run our systems where I work, I think
i'd stick to properties files :-}
- Korny (who has spent most the last 6 hours struggling with deployment
pain)
On Thu, Mar 26, 2009 at 1:06 PM, e wrote:
> clojure file sounds good to me, but who am I? now, a JSON file that
> would sound good to a whole LOT of people . . . .and is compatible with many
> many languages ... even looks lispy. JSON is a good thing to get behind
> because it has a chance of killing xml.
>
>
> On Wed, Mar 25, 2009 at 6:19 PM, Mark McGranaghan wrote:
>
>>
>> + 1 for literal using literal Clojure data structures for configuration.
>>
>> On Wed, Mar 25, 2009 at 5:50 PM, Laurent PETIT
>> wrote:
>> > And why not just use clojure source code literal datastructures as the
>> > persistence format ?
>> >
>> > With the pretty print function released by Tom Faulhaber, it's even
>> possible
>> > to painlessly write configuration back while keeping it clear (though
>> not
>> > currently possible to maintain things such as comments, I fear),
>> >
>> > --
>> > Laurent
>> >
>> > 2009/3/25 Korny Sietsma
>> >>
>> >> ooh - that's precisely why I was looking into duck-streams myself;
>> thanks
>> >> for that!
>> >>
>> >> Mind you, after a while in the Ruby world, I'd highly recommend looking
>> at
>> >> YAML for config files - it's human readable and fairly easily
>> writeable, and
>> >> lets you add arrays, nested structures, etc. fairly easily.
>> >> For simple config, and for Java friendliness, I can also see the value
>> of
>> >> properties files - I just keep working on java projects that have 200
>> line
>> >> property files with hacks to handle nested structures and lists - it
>> gets
>> >> ugly real soon!
>> >>
>> >> - Korny
>> >>
>> >> On Thu, Mar 26, 2009 at 5:57 AM, Rayne
>> wrote:
>> >>>
>> >>> I wrote a simple, small configuration file parser and reader that uses
>> >>> the duck-streams library. You might find some of the examples
>> >>> interesting.
>> >>>
>> >>> http://paste.pocoo.org/show/109498/
>> >>>
>> >>> On Mar 24, 11:20 am, e wrote:
>> >>> > is there something as simple as this in clojure?
>> >>> >
>> >>> > whole python program:
>> >>> >
>> >>> > of = open(filename,"w")
>> >>> > of.write("hello")
>> >>> > of.close()
>> >>> >
>> >>> > I checked the api and looked around the wiki and google quickly and
>> saw
>> >>> > how
>> >>> > to use java's stuff to do it ... but, welll...
>> >>> >
>> >>> > I noticed "slurp" in the api for reading ... but only the whole file
>> at
>> >>> > once
>> >>> > (read() but no readline()). Is there something symmetrical for
>> writing
>> >>> > (outputting)? Is there a web page called "File IO" somewhere?
>> >>> >
>> >>> > Thanks.
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Kornelis Sietsma korny at my surname dot com
>> >> "Every jumbled pile of person has a thinking part
>> >> that wonders what the part that isn't thinking
>> >> isn't thinking of"
>> >>
>> >>
>> >
>> >
>> >
>> > >
>> >
>>
>>
>>
>
> >
>
--
Kornelis Sietsma korny at my surname dot com
"Every jumbled pile of person has a thinking part
that wonders what the part that isn't thinking
isn't thinking of"
--~--~-~--~~~---~--~~
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: Proposed Change to str-utils
Having great string and regex manipulation is a must for anything that will be used as a scripting language and I think this should be conveniently available in Clojure. So, yes, I agree that these functions are ones that it makes sense to wrap. I'm not (yet, at least) commenting specifically on Sean's proposal, because I haven't had time to look at it in depth, Tom --~--~-~--~~~---~--~~ 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: Is Clojure's lack of support for forward referencing a feature or a bug?
:) I like that description! :) On Mar 26, 4:47 pm, David Nolen wrote: > For what it's worth I'm a big fan of the wishful thinking programming style. > I write some functions how I think they should look, declare the functions I > haven't defined yet. Then I implement the lower level functions, write some > tests- then usually the higher level stuff works without too much tweaking. > In a non-functional programming language this doesn't work so well, but it's > a good fit for something like Clojure. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Is Clojure's lack of support for forward referencing a feature or a bug?
For what it's worth I'm a big fan of the wishful thinking programming style. I write some functions how I think they should look, declare the functions I haven't defined yet. Then I implement the lower level functions, write some tests- then usually the higher level stuff works without too much tweaking. In a non-functional programming language this doesn't work so well, but it's a good fit for something like Clojure. On Thu, Mar 26, 2009 at 1:42 AM, Timothy Pratley wrote: > > Hi Mark, > > A fuller discussion can be found here: > > http://groups.google.com/group/clojure/browse_thread/thread/a99b420d5ee0aa40/47f8c2ab6845e9ae > Which has links to the simple patch I tried, and discusses the more > advanced technique Laurent experimented with. > Elena subsequently developed an emacs plugin which looks interesting > (I'm a VI ninja though so haven't used it) > > http://groups.google.com/group/clojure/browse_thread/thread/ca7076f4c6591fdd/cda5cf10b89a3679 > > My own experience FWIW was that it was great for two weeks coding with > autodef, then for about a week I became frustrated with my typos and > disabled it. More promising solutions might come from an external tool > (such as Knuth's literate programming noweb) or IDE support like Elena > described. > > For now my work flow is write the code backwards (ie: manually move > the cursor up) and/or chopping and pasting. Then when I'm happy with > it, I re-chop it all in my 'preferred' order and put a declare at the > top. That sounds quite inefficient, but VI is really great for re- > organizing text blocks so it is not too strenuous. That said, I'm > really interested in ways that "literate programming" style can be > followed with the least external support. > > > Regards, > Tim. > > > On Mar 26, 4:15 pm, Mark Engelberg wrote: > > On Wed, Mar 11, 2009 at 5:18 PM, Timothy Pratley > > > > wrote: > > > It is also quite trivial to patch the compiler to auto-def symbols as > > > it finds them instead of throwing an error. > > > > I would be interested in knowing how to do such a patch. When I work > > on code, I like to organize my functions in a way that makes it easy > > to read and understand what is going on. As I work on longer chunks > > of Clojure code, I'm finding that shuffling around the functions to > > avoid a lot of forward declarations is destroying the readability of > > my code. > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Is Clojure's lack of support for forward referencing a feature or a bug?
Hi Mark, A fuller discussion can be found here: http://groups.google.com/group/clojure/browse_thread/thread/a99b420d5ee0aa40/47f8c2ab6845e9ae Which has links to the simple patch I tried, and discusses the more advanced technique Laurent experimented with. Elena subsequently developed an emacs plugin which looks interesting (I'm a VI ninja though so haven't used it) http://groups.google.com/group/clojure/browse_thread/thread/ca7076f4c6591fdd/cda5cf10b89a3679 My own experience FWIW was that it was great for two weeks coding with autodef, then for about a week I became frustrated with my typos and disabled it. More promising solutions might come from an external tool (such as Knuth's literate programming noweb) or IDE support like Elena described. For now my work flow is write the code backwards (ie: manually move the cursor up) and/or chopping and pasting. Then when I'm happy with it, I re-chop it all in my 'preferred' order and put a declare at the top. That sounds quite inefficient, but VI is really great for re- organizing text blocks so it is not too strenuous. That said, I'm really interested in ways that "literate programming" style can be followed with the least external support. Regards, Tim. On Mar 26, 4:15 pm, Mark Engelberg wrote: > On Wed, Mar 11, 2009 at 5:18 PM, Timothy Pratley > > wrote: > > It is also quite trivial to patch the compiler to auto-def symbols as > > it finds them instead of throwing an error. > > I would be interested in knowing how to do such a patch. When I work > on code, I like to organize my functions in a way that makes it easy > to read and understand what is going on. As I work on longer chunks > of Clojure code, I'm finding that shuffling around the functions to > avoid a lot of forward declarations is destroying the readability of > my code. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 + Java compilation and IntelliJ IDEA plugin
>> It's very good question, and to be honest I don't know exact question for it. I may imagine both cases from Clojure to Java and vise versa. Making first variant default I was followed by one letter I had received. It was about some project written in IDEA, where Clojure is used for core funcationality whereas al UI is written in Java via UI designer. That may have been my email. Given that there is currently no solid GUI forms designer for Clojure, IDEA will have a strong market niche by developing one. The idea (no pun intended) is that each language should do what it does best. At some point Clojure may have the tools to be best at GUI forms, but not right now. In this scenario, Clojure will presumably need to be compiled first, unless there is some way to invoke the GUI from Clojure (my Java skills are very rusty). --~--~-~--~~~---~--~~ 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: Is Clojure's lack of support for forward referencing a feature or a bug?
On Wed, Mar 11, 2009 at 5:18 PM, Timothy Pratley wrote: > It is also quite trivial to patch the compiler to auto-def symbols as > it finds them instead of throwing an error. I would be interested in knowing how to do such a patch. When I work on code, I like to organize my functions in a way that makes it easy to read and understand what is going on. As I work on longer chunks of Clojure code, I'm finding that shuffling around the functions to avoid a lot of forward declarations is destroying the readability of my code. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Running multiple scripts from the Java realm
On Mar 25, 3:16 am, Berlin Brown wrote:
> On Mar 25, 3:12 am, BerlinBrown wrote:
>
>
>
> > I know it isn't advised but I have my various reasons.
>
> > What are some of the best ways to invoke clojure scripts from Java but
> > still maintain the state of the current session.
>
> > For example, if I run a script from Java, is there a way to ensure
> > that script has already been run...say if I run another script.
> > I was doing the following.
>
> > --
>
> > package test.toolkit.clojure;
>
> > import clojure.lang.Namespace;
> > import clojure.lang.RT;
> > import clojure.lang.Symbol;
> > import clojure.lang.Var;
>
> > public class TestSpringLoadClojure {
>
> > final static private Symbol CLOJURE_MAIN = Symbol.create
> > ("clojure.main");
> > final static private Namespace CLOJURE_MAIN_NS =
> > Namespace.findOrCreate(CLOJURE_MAIN);
> > final static private Var REQUIRE = Var.intern(RT.CLOJURE_NS,
> > Symbol.create("require"));
> > final static private Var LEGACY_REPL = Var.intern(CLOJURE_MAIN_NS,
> > Symbol.create("legacy-repl"));
> > final static private Var LEGACY_SCRIPT = Var.intern(CLOJURE_MAIN_NS,
> > Symbol.create("legacy-script"));
> > final static private Var MAIN = Var.intern(CLOJURE_MAIN_NS,
> > Symbol.create("main"));
>
> > private static void legacy_script(String[] args) throws Exception {
> > REQUIRE.invoke(CLOJURE_MAIN);
> > LEGACY_SCRIPT.invoke(RT.seq(args));
> > }
>
> > private static void invoke_script(String[] args) throws Exception {
> > LEGACY_SCRIPT.invoke(RT.seq(args));
> > }
>
> > public static void main(final String [] args) throws Exception {
>
> > final String [] scripts = { };
> > final String [] scripts2 = { "clj/utils/test_use_utils.clj"
> > };
> > legacy_script(scripts);
> > Var.intern(Namespace.findOrCreate(Symbol.create("clojure")),
> > Symbol.create("*console*"), "abc");
> > invoke_script(scripts2);
>
> > }
>
> > }
>
> > But I get an error message:
>
> > [java] java.lang.Exception: Unable to resolve symbol: *console*
> > in this context (test_use_utils.clj:45)
> > [java] at org.apache.tools.ant.taskdefs.ExecuteJava.execute
> > (ExecuteJava.java:194)
>
> Nevermind.
>
> (println "-->" clojure/*console*)
>
> if I do this, I get it
Anyone? Use the Java clojure code directly at all, ever?
--~--~-~--~~~---~--~~
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: exposing specific functions via namespace
On Wed, Mar 25, 2009 at 12:05 PM, Parth wrote: > I have split up the foo namespace across multiple files. So, > I have the following now: > > src/org/ppm/foo.clj -> org.ppm.foo > src/org/ppm/bar.clj -> org.ppm.foo > src/org/ppm/baz.clj -> org.ppm.foo > > With foo.clj using the ns :load for loading bar and baz. > > (ns org.ppm.foo > (:load "bar" "baz")) > > This meets my needs well as the code is split in > logical units while exposing the same namespace > to the end user. You may want to take a look at compojure.ns-utils/immigrate. http://github.com/weavejester/compojure/tree/master It just creates public vars pointing at all the public vars in the source namespace. -hume. -- http://elhumidor.blogspot.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 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 -~--~~~~--~~--~--~---
Yet another trace library.
While searching usable trace libray in clojure, I found 3 pieces of codes. - Stuart Sierra's clojure.contrib.trace - Rich Hickey's posting http://groups.google.com/group/clojure/browse_thread/thread/fd315d9dfdb8c32c/7479682cdf3a1b97?lnk=gst&q=trace#7479682cdf3a1b97 - Craig McDaniel's trace2.clj http://groups.google.com/group/clojure/browse_thread/thread/3ea8777880231e18/6fd1b352ac1a6744?lnk=gst&q=trace#6fd1b352ac1a6744 1st can be used to trace any expression. but it's not for general function tracing. 2nd version works well. 3rd version provide trace-ns, untrace-ns. but no indentation on trace output. So I combined indented output part of the 2nd codes to the 3rd codes. And provided some control vars on output contents. http://groups.google.com/group/clojure/web/trace_fn.clj Any comment? --~--~-~--~~~---~--~~ 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: file io
clojure file sounds good to me, but who am I? now, a JSON file that
would sound good to a whole LOT of people . . . .and is compatible with many
many languages ... even looks lispy. JSON is a good thing to get behind
because it has a chance of killing xml.
On Wed, Mar 25, 2009 at 6:19 PM, Mark McGranaghan wrote:
>
> + 1 for literal using literal Clojure data structures for configuration.
>
> On Wed, Mar 25, 2009 at 5:50 PM, Laurent PETIT
> wrote:
> > And why not just use clojure source code literal datastructures as the
> > persistence format ?
> >
> > With the pretty print function released by Tom Faulhaber, it's even
> possible
> > to painlessly write configuration back while keeping it clear (though not
> > currently possible to maintain things such as comments, I fear),
> >
> > --
> > Laurent
> >
> > 2009/3/25 Korny Sietsma
> >>
> >> ooh - that's precisely why I was looking into duck-streams myself;
> thanks
> >> for that!
> >>
> >> Mind you, after a while in the Ruby world, I'd highly recommend looking
> at
> >> YAML for config files - it's human readable and fairly easily writeable,
> and
> >> lets you add arrays, nested structures, etc. fairly easily.
> >> For simple config, and for Java friendliness, I can also see the value
> of
> >> properties files - I just keep working on java projects that have 200
> line
> >> property files with hacks to handle nested structures and lists - it
> gets
> >> ugly real soon!
> >>
> >> - Korny
> >>
> >> On Thu, Mar 26, 2009 at 5:57 AM, Rayne wrote:
> >>>
> >>> I wrote a simple, small configuration file parser and reader that uses
> >>> the duck-streams library. You might find some of the examples
> >>> interesting.
> >>>
> >>> http://paste.pocoo.org/show/109498/
> >>>
> >>> On Mar 24, 11:20 am, e wrote:
> >>> > is there something as simple as this in clojure?
> >>> >
> >>> > whole python program:
> >>> >
> >>> > of = open(filename,"w")
> >>> > of.write("hello")
> >>> > of.close()
> >>> >
> >>> > I checked the api and looked around the wiki and google quickly and
> saw
> >>> > how
> >>> > to use java's stuff to do it ... but, welll...
> >>> >
> >>> > I noticed "slurp" in the api for reading ... but only the whole file
> at
> >>> > once
> >>> > (read() but no readline()). Is there something symmetrical for
> writing
> >>> > (outputting)? Is there a web page called "File IO" somewhere?
> >>> >
> >>> > Thanks.
> >>>
> >>
> >>
> >>
> >> --
> >> Kornelis Sietsma korny at my surname dot com
> >> "Every jumbled pile of person has a thinking part
> >> that wonders what the part that isn't thinking
> >> isn't thinking of"
> >>
> >>
> >
> >
> >
> > >
> >
>
> >
>
--~--~-~--~~~---~--~~
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: O-R mapping
On Mar 25, 11:35 pm, Raoul Duke wrote: > if one doesn't have to convert the db into objects, then is there less > impedance mismatch? what is a nice setup in a functional language for > working with a db schema? what is your experience/thought? Somewhat less, at least in my experience. In FP, you can basically view a relation (table) as a function of its key(s) and build your logic from there. Yet, traditional O-R mappers are still giving me a productivity boost because of the low-level mapping of primitive types to DB field types, and because they handle aggregate and composite- structures for me. I'm currently unaware of a mature functional O-R mapper (even a non-clojure or non-lisp one). Most relational systems in the FP world (like the Datalog work going on for Clojure) seem to operate on memory-based databases, not on persistent ones (and seem to focus completely on querying and inference, ignoring the aspect of persistence). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure + Java compilation and IntelliJ IDEA plugin
Hi, Stuart. I would like to be able to demo the sample code from the book in IDEA That's great, I'm really happy to hear it. As for all three issues you've mentioned, all of them have same origin and related to so-called evaluator API. What you can see now using debugger is nothing but vanilla Java stack, some of whose variable may coincide with appropriate Clojure variables. Implmentation of watches, evaluate expression or some specific cases like dealing with lazy structures is _very_ non-trivial problem, cause all clojure constructs, written, say, in 'watches' section should be translated to correct Java code to capture appropriate stack and environment from JVM and being evaluated. For now, we solved this problem partially for Groovy, because Groovy is not so hard to translate to Java and we're working on the same problem for Scala, which is much more dificult because of presence of string typeing. As for Clojure, I don't see an easy way for now to implement such feature. For me such tasks as smart completion and resolve have greater priority. BTW, I'm not sure, that thiss issue was already mentioned in errata for book, but I failed to compile tasklist.clj example from last book version (27 feb), because some function (sort of `lazy-eval') from clojure-contrib raised an error during compilation. Same result was obtained by compilation from command line, so I'm afraid some-thing wrong either with current clojure-contrib version or this example. Kind regards, Ilya 2009/3/25 Stuart Halloway > > Hi Ilya, > > I would like to be able to demo the sample code from the book in IDEA. > Here are a few things I am seeing so far: > > (1) When I set a breakpoint, I get a warning icon that says "no > executable code found at..." but the breakpoint does in fact seem to > work. > > (2) The variable window correctly displays collections, but not large/ > infinite sequences. If you try to open a variable view on an infinite > sequence, it will use all of memory. Can the plugin be modified to > respect the *print-length* and *print-depth* variables? > > (3) I am unable to set a watch on the special variable *print-length*. > The entry UI goes wonky when I reach the hyphen character in the name. > > It's exciting to see the plugin moving forward, thanks for your efforts! > > Best, > Stu > > > Hello, all. > > > > I've just uploaded new version of La Clojure plugin for IntelliJ > > IDEA. Among several bugfixes and minor changes I have to note > > several essential moments. > > > > 1. Now Clojure support is added as so-called `facet', which may be > > attached to every module. Creating new module, just choose Clojure > > among desired technologies. In this case necessary clojure jar will > > be downloaded automatically and adjusted as a project library unless > > you point to it manually. > > > > 2. If you open existing project, clojure facet will be detected > > automatically. For now facet serves as a label for clojure-aware > > modules. In that modules you may invoke "create new clojure file" > > action and their clojure files will be compiled. > > > > 3. From now IntelliJ IDEA provides support for batch compilation of > > Clojure files, whose namespace is marked by :gen-calss tag. Compiled > > classes will be places to the appropriate output directory of a > > module. One may choose, which sources should be compiled first - > > Java or Clojure to resolve one-way dependencies. By default Clojure > > is compiled first. Moreoverm you may to choose whether to copy *.clj > > files to output path or not (this might be useful if you're going to > > invoke some functions from *.clj files dynamically). And, of course, > > automatic detection and compilation of class-labeled clojure files > > may be switched off. For more details see File -> Settings -> > > Compiler -> Clojure. > > > > For someone these settings might seem not sufficiently flexible. So, > > all comments and proposals are appreciated. :) > > > > With best regards, > > Ilya Sergey > > > > > > > > > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure + Java compilation and IntelliJ IDEA plugin
Hello, Christian Could you explain the reasoning behind compiling the Clojure code > before the Java code? It's very good question, and to be honest I don't know exact question for it. I may imagine both cases from Clojure to Java and vise versa. Making first variant default I was followed by one letter I had received. It was about some project written in IDEA, where Clojure is used for core funcationality whereas al UI is written in Java via UI designer. Untill we have no stub-generation (as it was done in Groovy) or Java code analysis like in Scala only one consistent solution will be to define compilation order explicitly. Tricky project decomposion into modules may help to resolve cross-languge dependencies. With best regards, Ilya 2009/3/25 Christian Vest Hansen > > Sounds great :) > > On Wed, Mar 25, 2009 at 4:42 PM, Ilya Sergey wrote: > > Hello, all. > > > > I've just uploaded new version of La Clojure plugin for IntelliJ IDEA. > Among > > several bugfixes and minor changes I have to note several essential > moments. > > > > 1. Now Clojure support is added as so-called `facet', which may be > attached > > to every module. Creating new module, just choose Clojure among desired > > technologies. In this case necessary clojure jar will be downloaded > > automatically and adjusted as a project library unless you point to it > > manually. > > > > 2. If you open existing project, clojure facet will be detected > > automatically. For now facet serves as a label for clojure-aware modules. > In > > that modules you may invoke "create new clojure file" action and their > > clojure files will be compiled. > > > > 3. From now IntelliJ IDEA provides support for batch compilation of > Clojure > > files, whose namespace is marked by :gen-calss tag. Compiled classes will > be > > places to the appropriate output directory of a module. One may choose, > > which sources should be compiled first - Java or Clojure to resolve > one-way > > dependencies. By default Clojure is compiled first. > > Could you explain the reasoning behind compiling the Clojure code > before the Java code? > > While trying out Daniel Spiewaks Clojure enabled Buildr, which also > compiles the Clojure code first, I noticed that I could not access > static methods of the classes that were defined in Java code. I have > not tested this, but I would assume that type hinting using these > classes don't work either. On the other hand, Java works with Clojure > through the classes and interfaces defined in clojure.jar, and > resolves their Vars at run time. The 'gen-class case stands as an > example where you might have to compile Clojure first, but I wonder if > this is the typical case? > > > Moreoverm you may to > > choose whether to copy *.clj files to output path or not (this might be > > useful if you're going to invoke some functions from *.clj files > > dynamically). And, of course, automatic detection and compilation of > > class-labeled clojure files may be switched off. For more details see > File > > -> Settings -> Compiler -> Clojure. > > > > For someone these settings might seem not sufficiently flexible. So, all > > comments and proposals are appreciated. :) > > > > With best regards, > > Ilya Sergey > > > > > > > > > > > > > > > -- > Venlig hilsen / Kind regards, > Christian Vest Hansen. > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Why not "sorted-set-by"?
Thank you, hoeck. Thank you Chouser, your code taught me about "proxy". When I saw the patch 1st time, I missed java parts. before I saw your code, I thought if I need that again then I could use the code without affecting core. (What a wrong conclusion ^^; ) ps. I was embarrassed when my 4 posts with 3 threads appeared. I didn't know about 1st posting moderation. (I think google group ui must notify about moderation, anyway that's another story.) So I was reluctant to post just thank you reply. Thank you Frantisek Sodomka, for reply on another thread. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure + Java compilation and IntelliJ IDEA plugin
Hello, Mark. The easiest way to updae plugin from within the idea is to use plugin manager (see File -> Settings -> Plugins), find Clojure plugin in the list, right-click on it and hit "update". AFAIK, you also must see kind of blinking gear in the bottom right corener of IDEA main screen, which assumes, that you have some plugins to update. With best regards, Ilya 2009/3/26 Mark Engelberg > > If we've already downloaded the first plugin, what's the best way to > upgrade? Do you have to delete the first one, or just install the > second on top? Is there a way to update the plugin from within the > IDE? > > 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 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: Turning a non-standard iterator into a seq
> Calling > > (def input (BufferedReader. (FileReader. "data/dm4p1/dm4p1.dEID"))) > (def data (RichSequence$IOTools/readFastaDNA input nil)) > (doseq [d (bio-iterator-seq data)] (prn 'Sequence (show d))) > > Printed all the sequences from the file, as required. > > Just to be sure, is `doseq` the correct way to pull items from a lazy > sequence like this? > doseq is a good way to pull items from a seq if you want side effects. If your computation does not have side effects or you want to evaluate it lazily, you can use 'map' or 'for'. Allen --~--~-~--~~~---~--~~ 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: Turning a non-standard iterator into a seq
On Mar 26, 1:10 am, Stuart Sierra wrote: > Hi Mark, > You'll need to work at a lower level using cons and lazy-seq. > Something like this (untested): > > (defn bio-iterator-seq [iterator] > (lazy-seq > (when (.hasNextiterator) > (cons (.nextSequenceiterator) (bio-iterator-seqiterator) Hi Stuart, Thanks for that. Once I upgraded my clojure.jar to the latest release that code worked perfectly. Calling (def input (BufferedReader. (FileReader. "data/dm4p1/dm4p1.dEID"))) (def data (RichSequence$IOTools/readFastaDNA input nil)) (doseq [d (bio-iterator-seq data)] (prn 'Sequence (show d))) Printed all the sequences from the file, as required. Just to be sure, is `doseq` the correct way to pull items from a lazy sequence like this? Thanks again for your help, Mark -- http://mark.reid.name --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure + Java compilation and IntelliJ IDEA plugin
If we've already downloaded the first plugin, what's the best way to upgrade? Do you have to delete the first one, or just install the second on top? Is there a way to update the plugin from within the IDE? 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 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: Slime integration
Just responding to myself, the issue seems to have been fixed by itself. OTOH compiler errors don't popup like before. I can see them in the *SLIME Compilation* buffer but clicking on them doesn't lead to the source code. The faulty lines are also not highlighted in anyway way now. Is this correct behaviour or is my Slime installation borked beyond recovery? V. Segui --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
O-R mapping
hi, if one doesn't have to convert the db into objects, then is there less impedance mismatch? what is a nice setup in a functional language for working with a db schema? what is your experience/thought? 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 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: file io
+ 1 for literal using literal Clojure data structures for configuration.
On Wed, Mar 25, 2009 at 5:50 PM, Laurent PETIT wrote:
> And why not just use clojure source code literal datastructures as the
> persistence format ?
>
> With the pretty print function released by Tom Faulhaber, it's even possible
> to painlessly write configuration back while keeping it clear (though not
> currently possible to maintain things such as comments, I fear),
>
> --
> Laurent
>
> 2009/3/25 Korny Sietsma
>>
>> ooh - that's precisely why I was looking into duck-streams myself; thanks
>> for that!
>>
>> Mind you, after a while in the Ruby world, I'd highly recommend looking at
>> YAML for config files - it's human readable and fairly easily writeable, and
>> lets you add arrays, nested structures, etc. fairly easily.
>> For simple config, and for Java friendliness, I can also see the value of
>> properties files - I just keep working on java projects that have 200 line
>> property files with hacks to handle nested structures and lists - it gets
>> ugly real soon!
>>
>> - Korny
>>
>> On Thu, Mar 26, 2009 at 5:57 AM, Rayne wrote:
>>>
>>> I wrote a simple, small configuration file parser and reader that uses
>>> the duck-streams library. You might find some of the examples
>>> interesting.
>>>
>>> http://paste.pocoo.org/show/109498/
>>>
>>> On Mar 24, 11:20 am, e wrote:
>>> > is there something as simple as this in clojure?
>>> >
>>> > whole python program:
>>> >
>>> > of = open(filename,"w")
>>> > of.write("hello")
>>> > of.close()
>>> >
>>> > I checked the api and looked around the wiki and google quickly and saw
>>> > how
>>> > to use java's stuff to do it ... but, welll...
>>> >
>>> > I noticed "slurp" in the api for reading ... but only the whole file at
>>> > once
>>> > (read() but no readline()). Is there something symmetrical for writing
>>> > (outputting)? Is there a web page called "File IO" somewhere?
>>> >
>>> > Thanks.
>>>
>>
>>
>>
>> --
>> Kornelis Sietsma korny at my surname dot com
>> "Every jumbled pile of person has a thinking part
>> that wonders what the part that isn't thinking
>> isn't thinking of"
>>
>>
>
>
>
> >
>
--~--~-~--~~~---~--~~
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: Proposed Change to str-utils
> Hi, > > I would generally agree with Stuart that wrapping Java functions is > not a good idea. > > However, string functions come up so often that I think that this is > one area where the rule should be broken, if only for readablility. > I agree, I use these string functions frequently. Maybe these String wrapper functions can be in their own namespace to make it explicit that these are wrapper functions. --~--~-~--~~~---~--~~ 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: Slime integration
On 24 mar, 05:29, Phil Hagelberg wrote: > Vagif Verdi writes: > > When i use slime with lisp, it shows me function parameters, when > > cursor is on a function name. But with clojure it only shows me > > Evaluation Aborted. Is this because that feature not implemented, or i > > setup something wrong ? > > Works for me. Would need more details to diagnose what's wrong with > yours though. Generally the simplest way to get going with SLIME and > Clojure is to load a recent copy of clojure-mode.el, hit M-x > clojure-install, and follow the instructions it gives you. > > -Phil For me it's showing parameters fine but it breaks when trying to autocomplete on the REPL with TAB (this is fixed by changing namespaces) or in a file pressing C-TAB. The backtrace is the following: Backtrace: 0: java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java: 796) 1: clojure.lang.Namespace.find(Namespace.java:129) 2: clojure.core$find_ns__4309.invoke(core.clj:2373) 3: clojure.core$the_ns__4321.invoke(core.clj:2397) 4: clojure.core$ns_map__4328.invoke(core.clj:2407) 5: swank.commands.contrib.swank_c_p_c $completion_list_var__1189$fn__1191.invoke(swank_c_p_c.clj:64) 6: clojure.lang.Delay.deref(Delay.java:33) 7: clojure.lang.Delay.force(Delay.java:25) 8: clojure.core$force__3266.invoke(core.clj:468) 9: swank.commands.contrib.swank_c_p_c $completion_list_var__1189$fn__1195.invoke(swank_c_p_c.clj:71) 10: clojure.lang.Delay.deref(Delay.java:33) 11: clojure.lang.Delay.force(Delay.java:25) 12: clojure.core$force__3266.invoke(core.clj:468) 13: swank.commands.contrib.swank_c_p_c $completion_list_var__1189.invoke(swank_c_p_c.clj:79) 14: swank.commands.contrib.swank_c_p_c$compound_complete__1202.invoke (swank_c_p_c.clj:88) 15: swank.commands.contrib.swank_c_p_c$completions__1210.invoke (swank_c_p_c.clj:93) 16: clojure.lang.Var.invoke(Var.java:350) 17: user$eval__1430.invoke(Unknown Source) 18: clojure.lang.Compiler.eval(Compiler.java:4522) 19: clojure.core$eval__3969.invoke(core.clj:1738) 20: swank.core$eval_in_emacs_package__310.invoke(core.clj:55) 21: swank.core$eval_for_emacs__385.invoke(core.clj:123) 22: clojure.lang.Var.invoke(Var.java:354) 23: clojure.lang.AFn.applyToHelper(AFn.java:179) 24: clojure.lang.Var.applyTo(Var.java:463) 25: clojure.core$apply__3228.doInvoke(core.clj:408) 26: clojure.lang.RestFn.invoke(RestFn.java:428) 27: swank.core$eval_from_control__313.invoke(core.clj:62) 28: swank.core$spawn_worker_thread__408$fn__437$fn__439.invoke (core.clj:157) 29: clojure.lang.AFn.applyToHelper(AFn.java:171) 30: clojure.lang.AFn.applyTo(AFn.java:164) 31: clojure.core$apply__3228.doInvoke(core.clj:408) 32: clojure.lang.RestFn.invoke(RestFn.java:428) 33: swank.core$spawn_worker_thread__408$fn__437.doInvoke(core.clj: 153) 34: clojure.lang.RestFn.invoke(RestFn.java:402) 35: clojure.lang.AFn.run(AFn.java:37) 36: java.lang.Thread.run(Thread.java:636) I tried the clojure-install but still get the same errors. Using Ubuntu 8.10 with Emacs 22 OpenJDK 6. Cheers, V. Segui --~--~-~--~~~---~--~~ 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: file io
And why not just use clojure source code literal datastructures as the
persistence format ?
With the pretty print function released by Tom Faulhaber, it's even possible
to painlessly write configuration back while keeping it clear (though not
currently possible to maintain things such as comments, I fear),
--
Laurent
2009/3/25 Korny Sietsma
> ooh - that's precisely why I was looking into duck-streams myself; thanks
> for that!
>
> Mind you, after a while in the Ruby world, I'd highly recommend looking at
> YAML for config files - it's human readable and fairly easily writeable, and
> lets you add arrays, nested structures, etc. fairly easily.
> For simple config, and for Java friendliness, I can also see the value of
> properties files - I just keep working on java projects that have 200 line
> property files with hacks to handle nested structures and lists - it gets
> ugly real soon!
>
> - Korny
>
> On Thu, Mar 26, 2009 at 5:57 AM, Rayne wrote:
>
>>
>> I wrote a simple, small configuration file parser and reader that uses
>> the duck-streams library. You might find some of the examples
>> interesting.
>>
>> http://paste.pocoo.org/show/109498/
>>
>> On Mar 24, 11:20 am, e wrote:
>> > is there something as simple as this in clojure?
>> >
>> > whole python program:
>> >
>> > of = open(filename,"w")
>> > of.write("hello")
>> > of.close()
>> >
>> > I checked the api and looked around the wiki and google quickly and saw
>> how
>> > to use java's stuff to do it ... but, welll...
>> >
>> > I noticed "slurp" in the api for reading ... but only the whole file at
>> once
>> > (read() but no readline()). Is there something symmetrical for writing
>> > (outputting)? Is there a web page called "File IO" somewhere?
>> >
>> > Thanks.
>>
>>
>
>
> --
> Kornelis Sietsma korny at my surname dot com
> "Every jumbled pile of person has a thinking part
> that wonders what the part that isn't thinking
> isn't thinking of"
>
> >
>
--~--~-~--~~~---~--~~
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: file io
ooh - that's precisely why I was looking into duck-streams myself; thanks
for that!
Mind you, after a while in the Ruby world, I'd highly recommend looking at
YAML for config files - it's human readable and fairly easily writeable, and
lets you add arrays, nested structures, etc. fairly easily.
For simple config, and for Java friendliness, I can also see the value of
properties files - I just keep working on java projects that have 200 line
property files with hacks to handle nested structures and lists - it gets
ugly real soon!
- Korny
On Thu, Mar 26, 2009 at 5:57 AM, Rayne wrote:
>
> I wrote a simple, small configuration file parser and reader that uses
> the duck-streams library. You might find some of the examples
> interesting.
>
> http://paste.pocoo.org/show/109498/
>
> On Mar 24, 11:20 am, e wrote:
> > is there something as simple as this in clojure?
> >
> > whole python program:
> >
> > of = open(filename,"w")
> > of.write("hello")
> > of.close()
> >
> > I checked the api and looked around the wiki and google quickly and saw
> how
> > to use java's stuff to do it ... but, welll...
> >
> > I noticed "slurp" in the api for reading ... but only the whole file at
> once
> > (read() but no readline()). Is there something symmetrical for writing
> > (outputting)? Is there a web page called "File IO" somewhere?
> >
> > Thanks.
> >
>
--
Kornelis Sietsma korny at my surname dot com
"Every jumbled pile of person has a thinking part
that wonders what the part that isn't thinking
isn't thinking of"
--~--~-~--~~~---~--~~
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: Proposed Change to str-utils
Perry, 1. Thanks for the tip on using type hints! I just added them to my code and pushed it to github 2. If you take a close look at my re- * methods, I actually tried to enforce an arity of 2 on as many methods as I could. This way the methods would read like so (re-split input-sting work-instructions) (re-partition input-sting work-instructions) (re-gsub input-sting work-instructions) (re-sub input-sting work-instructions) However, this didn't quite work with the lowest levels of re-gsub and re-sub, and forcing a map at the lowest level didn't feel right. 3. Library location is a slight issue. I agree these methods are in a completely different category than downcase, upcase, etc. The current str-utils.clj file has these methods in it. That is why they started there. There may be a case for creating a separate regex- utils library, and I know I have a few more parsing methods I'd like to propose in the near future. At the current moment, I personally prefer to have everything in one file. We'll see how big things get, though. To Everyone, I'd like to add Perry's type-hinting argument to the list of reasons these changes should be in contrib. Pooling our efforts to create a high performance version of the code does add value beyond a simple wrapper. A *fast*, tested and slick string library is even better than a tested and slick string library. Sean On Mar 25, 3:08 pm, Perry Trolard wrote: > Whatever it's worth as a datum, my experience is that I usually find > myself writing upcase, downcase, titlecase functions in most > applications, because > > (1) they're prettier & more succinct when passed as first-class > (downcase vs. #(.toLowerCase %)) > (2) I can add type hints once, in the downcase, upcase, etc. > functions, instead of doing so at each invocation (#(.toLowerCase > #^String %)) > > I think (2)'s the most compelling reason. The type-hinting situation > in Clojure is currently pretty impressive, I've found; a relatively > small number of hints strategically placed usually eliminate most or > all of the reflection that occurs in my first draft of functions. But > many string-processing operations -- for whatever reason -- usually > need a manual hint. > > I agree that it's not desirable to balloon the Clojure API with thin > wrappers on the Java APIs, but, like pc, think this might be an > exception. > > I'm less sure about the other proposed changes to str-utils -- the > variable-arity versions of re-split, -partition, -sub, -gsub. Maybe a > regex-parse lib in contrib would be a better place? > > Perry --~--~-~--~~~---~--~~ 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: Why not "sorted-set-by"?
On Wed, Mar 25, 2009 at 7:21 AM, hoeck wrote:
>
> there is already a filed issue and a patch from Timothy Pratley which
> adds sorted-set-by to clojure:
> http://code.google.com/p/clojure/issues/detail?id=76&colspec=ID%20Type%20Status%20Priority%20Reporter%20Owner%20Summary
>
> But its priority is set tow "low".
Until the patch is included, you could use this:
(import '(clojure.lang PersistentTreeMap APersistentSet Reversible Sorted))
(defn sorted-set-by [cmp & items]
((fn mkset [m #^PersistentTreeMap impl]
(proxy [APersistentSet Reversible Sorted] [m impl]
(disjoin [k] (if (contains? impl k) (mkset m (dissoc impl k)) this))
(cons [k] (if (contains? impl k) this (mkset m (assoc impl k k
(empty [] (mkset m (empty impl)))
(rseq [] (.seq this false))
(withMeta [m2] (mkset m2 impl))
(comparator [] (.comparator impl))
(entryKey [e] e)
(seq ([] (keys impl))
([asc] (keys (.seq impl asc
(seqFrom [k asc] (keys (.seqFrom impl k asc)
nil (apply sorted-map-by cmp (interleave items items
user=> (sorted-set-by > 1 2 3 4 5)
#{5 4 3 2 1}
--Chouser
--~--~-~--~~~---~--~~
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: oo
On Mar 25, 2:51 pm, Marko Kocić wrote: > Does anybody know of some minimal clos implementation that is easily > portable? > > I suppose that it contain base functions that are implemented in CL, > and the rest of clos built on top of that. > It might be interesting to try to adapt such a library to clojure. > > I remember people mentioning PCL and closette as clos implementations, > but actualy never looked at them. Tinyclos is decent, and lots of people have made good use of it. For example, it's a "standard" extension to Chicken Scheme (insofar as anything to do with Chicken Scheme can be called "standard") and has lots of enhancements provided by Felix. The reason I didn't port Tinyclos to Clojure is that CLOS assumes a specific model of classes, and I wanted to concentrate specifically on generic functions, not add yet another typesystem to Clojure. You could make a counterargument that the CLOS typesystem is specifically designed to interoperate seamlessly with legacy typesystems, and you would have a point. --~--~-~--~~~---~--~~ 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: oo
On Mar 25, 12:35 pm, Konrad Hinsen wrote: > On 25.03.2009, at 10:13, Mark Engelberg wrote: > > > 1. Structs don't inherently have a type. If you want to dispatch on > > type (a common use-case), you have to make a constructor that inserts > > the type information as part of the struct. Some have expressed > > And/or in the metadata. > > > concern that it may be too easy for this "type information" to be > > altered, or worse, the data could be "changed" or "removed" in a way > > that makes the struct inconsistent with the type label it carries > > around. > > I am one of those who have expressed concerns, but I must also say > that until now I have not encountered such a problem in real life. I > have come to the conclusion that interfaces and types work > differently in Clojure than in other languages that most of us are > more familiar with. So perhaps we are expecting problems that really > aren't there once you figure out how to do it "right". > > > 2. No way to call "next-method" or "super", which limits the ability > > to reuse related methods. > > Again, I'd like to see a real-life situation where this is an issue. > > > 3. The dispatch mechanism requires a lot of explicit prefer-methods, > > or else it may be hard to guarantee you won't get a run-time error > > from a situation the dispatch system considers ambiguous. This also > > And there as well. > > > makes code less extensible because to add a method, you must know > > about all the other methods that have been implemented in order to > > insert all the appropriate preferences. > > This would only be an issue in complex hierarchies. As long as each > library just adds its types to a hierarchy and implements methods for > them, there is no problem. That's why I'd like to see the real-life > situation where there is one. I repeatedly ran into all the problems Mark mentioned when trying to write an extensible set of codecs for serializing and deserializing game data, and for building a extensible set of data structures for representing game state. The game in question is a relatively large multiplayer RPG-style game whose data library needs to describe a large number of different kinds of objects, support transfer of those objects over networks and storage and retrieval on various kinds of repositories, and which needs to be extended by a number of people on an ongoing basis. I need to be able to clearly say what the protocols are for creating existing objects, and for defining new kinds of objects, and for serializing and deserializing them. With a large number of types of objects, name collisions in field- names becomes an issue. I can solve it by providing a mechanism to define the names allowed in a particular kind of object, and a way to declare requirements about the values allowed on those names. Storing type tags in metadata is handy in that the type function then returns the tag you want, and it's easy to make MultFns dispatch on those values. On the other hand, not all objects that one might want to dispatch on support metadata. That leaves storing type tags in the object itself, which is fairly convenient, but as the disadvantages Mark mentions. A partial workaround is to implement a feature for decalring the fields allowed and required in maps, and to implement consistency checking to ensure (to the extent that one can) that no one uses the type-tag field for anything other than type-tags. It's possible to provide a polymorphic API that covers each of the various defined kinds of objects, but building that API involves a lot of prefer-method calls. The inconvenience of that necessity increases, seemingly without bound, as people add new kinds of objects and methods to handle them. Each addition potentially requires its implementor to examine an ever-increasing set of previously-defined data descriptions and methods to determine what the correct prefer- method calls are. There may not always be a correct set. When there isn't, finding the data description and method definition that cause the unsolvable problem isn't necessarily easy. I'm extremely uncomfortable with any library that requires its user to be familiar with all of its internals and all its dependencies; that's exactly what libraries are meant to avoid. Therefore I am even more uncomfortable with library-building tools that guarantee that's the sort of library I'll be building. The set of game data objects describes features of an imaginary world. Those features (creatures, crafted items, factions, and so on) naturally cluster into related taxonomies of shared and specialized features. If you can say "this is just like those things except for these features", you save a lot of duplicated code. Type extension is one part of that ability; next-method is the other. This is one "real-world" situation where all the issues Mark raised are real and pressing issues for development, but it's not a special situation. I've run into these issues many many t
Re: Clojure + Java compilation and IntelliJ IDEA plugin
Hi Ilya, I would like to be able to demo the sample code from the book in IDEA. Here are a few things I am seeing so far: (1) When I set a breakpoint, I get a warning icon that says "no executable code found at..." but the breakpoint does in fact seem to work. (2) The variable window correctly displays collections, but not large/ infinite sequences. If you try to open a variable view on an infinite sequence, it will use all of memory. Can the plugin be modified to respect the *print-length* and *print-depth* variables? (3) I am unable to set a watch on the special variable *print-length*. The entry UI goes wonky when I reach the hyphen character in the name. It's exciting to see the plugin moving forward, thanks for your efforts! Best, Stu > Hello, all. > > I've just uploaded new version of La Clojure plugin for IntelliJ > IDEA. Among several bugfixes and minor changes I have to note > several essential moments. > > 1. Now Clojure support is added as so-called `facet', which may be > attached to every module. Creating new module, just choose Clojure > among desired technologies. In this case necessary clojure jar will > be downloaded automatically and adjusted as a project library unless > you point to it manually. > > 2. If you open existing project, clojure facet will be detected > automatically. For now facet serves as a label for clojure-aware > modules. In that modules you may invoke "create new clojure file" > action and their clojure files will be compiled. > > 3. From now IntelliJ IDEA provides support for batch compilation of > Clojure files, whose namespace is marked by :gen-calss tag. Compiled > classes will be places to the appropriate output directory of a > module. One may choose, which sources should be compiled first - > Java or Clojure to resolve one-way dependencies. By default Clojure > is compiled first. Moreoverm you may to choose whether to copy *.clj > files to output path or not (this might be useful if you're going to > invoke some functions from *.clj files dynamically). And, of course, > automatic detection and compilation of class-labeled clojure files > may be switched off. For more details see File -> Settings -> > Compiler -> Clojure. > > For someone these settings might seem not sufficiently flexible. So, > all comments and proposals are appreciated. :) > > With best regards, > Ilya Sergey > > > > > --~--~-~--~~~---~--~~ 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: oo
Does anybody know of some minimal clos implementation that is easily portable? I suppose that it contain base functions that are implemented in CL, and the rest of clos built on top of that. It might be interesting to try to adapt such a library to clojure. I remember people mentioning PCL and closette as clos implementations, but actualy never looked at them. Regards, Marko Kocić --~--~-~--~~~---~--~~ 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: Proposed Change to str-utils
Whatever it's worth as a datum, my experience is that I usually find myself writing upcase, downcase, titlecase functions in most applications, because (1) they're prettier & more succinct when passed as first-class (downcase vs. #(.toLowerCase %)) (2) I can add type hints once, in the downcase, upcase, etc. functions, instead of doing so at each invocation (#(.toLowerCase #^String %)) I think (2)'s the most compelling reason. The type-hinting situation in Clojure is currently pretty impressive, I've found; a relatively small number of hints strategically placed usually eliminate most or all of the reflection that occurs in my first draft of functions. But many string-processing operations -- for whatever reason -- usually need a manual hint. I agree that it's not desirable to balloon the Clojure API with thin wrappers on the Java APIs, but, like pc, think this might be an exception. I'm less sure about the other proposed changes to str-utils -- the variable-arity versions of re-split, -partition, -sub, -gsub. Maybe a regex-parse lib in contrib would be a better place? Perry --~--~-~--~~~---~--~~ 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: file io
I wrote a simple, small configuration file parser and reader that uses
the duck-streams library. You might find some of the examples
interesting.
http://paste.pocoo.org/show/109498/
On Mar 24, 11:20 am, e wrote:
> is there something as simple as this in clojure?
>
> whole python program:
>
> of = open(filename,"w")
> of.write("hello")
> of.close()
>
> I checked the api and looked around the wiki and google quickly and saw how
> to use java's stuff to do it ... but, welll...
>
> I noticed "slurp" in the api for reading ... but only the whole file at once
> (read() but no readline()). Is there something symmetrical for writing
> (outputting)? Is there a web page called "File IO" somewhere?
>
> 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
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: oo
On 25.03.2009, at 10:13, Mark Engelberg wrote: > 1. Structs don't inherently have a type. If you want to dispatch on > type (a common use-case), you have to make a constructor that inserts > the type information as part of the struct. Some have expressed And/or in the metadata. > concern that it may be too easy for this "type information" to be > altered, or worse, the data could be "changed" or "removed" in a way > that makes the struct inconsistent with the type label it carries > around. I am one of those who have expressed concerns, but I must also say that until now I have not encountered such a problem in real life. I have come to the conclusion that interfaces and types work differently in Clojure than in other languages that most of us are more familiar with. So perhaps we are expecting problems that really aren't there once you figure out how to do it "right". > 2. No way to call "next-method" or "super", which limits the ability > to reuse related methods. Again, I'd like to see a real-life situation where this is an issue. > 3. The dispatch mechanism requires a lot of explicit prefer-methods, > or else it may be hard to guarantee you won't get a run-time error > from a situation the dispatch system considers ambiguous. This also And there as well. > makes code less extensible because to add a method, you must know > about all the other methods that have been implemented in order to > insert all the appropriate preferences. This would only be an issue in complex hierarchies. As long as each library just adds its types to a hierarchy and implements methods for them, there is no problem. That's why I'd like to see the real-life situation where there is one. Konrad. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: exposing specific functions via namespace
On Mar 25, 7:04 pm, Parth Malwankar wrote: > Hello, > > I am trying to organise my code in namespaces and needed a > little help. > > Basically I have created the following namespaces similar to > the following: > > src/org/ppm/foo.clj -> org.ppm.foo > src/org/ppm/foo/ > src/org/ppm/foo/bar.clj -> org.ppm.foo.bar > src/org/ppm/foo/baz.clj -> org.ppm.foo.baz > > foo.clj is an empty file which does nothing but > combines bar and baz: > > == foo.clj == > (ns org.ppm.foo > (:use [org.ppm.foo bar baz])) > > After having the jar in classpath, I create a simple > test.clj script that I load. > > == test.clj == > (use 'org.ppm.foo) > (bar-func) > (baz-func) > > At this point, test.clj does not see the functions > defined in bar and baz. > Doing a (in-ns 'org.ppm.foo) before function calls > makes it work fine. > > Is there a way to have foo.clj selectively (or all) expose > functions from bar and baz to the end user via foo namespace? > > Do I need to put all exposed functions into foo.clj? I would > prefer to keep them in bar and baz if possible as those > are logical blocks for me. Sorry for replying to my own post. I think I figured out one way of meeting my needs. I have split up the foo namespace across multiple files. So, I have the following now: src/org/ppm/foo.clj -> org.ppm.foo src/org/ppm/bar.clj -> org.ppm.foo src/org/ppm/baz.clj -> org.ppm.foo With foo.clj using the ns :load for loading bar and baz. (ns org.ppm.foo (:load "bar" "baz")) This meets my needs well as the code is split in logical units while exposing the same namespace to the end user. Parth > > Thanks. > Parth --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure + Java compilation and IntelliJ IDEA plugin
Sounds great :) On Wed, Mar 25, 2009 at 4:42 PM, Ilya Sergey wrote: > Hello, all. > > I've just uploaded new version of La Clojure plugin for IntelliJ IDEA. Among > several bugfixes and minor changes I have to note several essential moments. > > 1. Now Clojure support is added as so-called `facet', which may be attached > to every module. Creating new module, just choose Clojure among desired > technologies. In this case necessary clojure jar will be downloaded > automatically and adjusted as a project library unless you point to it > manually. > > 2. If you open existing project, clojure facet will be detected > automatically. For now facet serves as a label for clojure-aware modules. In > that modules you may invoke "create new clojure file" action and their > clojure files will be compiled. > > 3. From now IntelliJ IDEA provides support for batch compilation of Clojure > files, whose namespace is marked by :gen-calss tag. Compiled classes will be > places to the appropriate output directory of a module. One may choose, > which sources should be compiled first - Java or Clojure to resolve one-way > dependencies. By default Clojure is compiled first. Could you explain the reasoning behind compiling the Clojure code before the Java code? While trying out Daniel Spiewaks Clojure enabled Buildr, which also compiles the Clojure code first, I noticed that I could not access static methods of the classes that were defined in Java code. I have not tested this, but I would assume that type hinting using these classes don't work either. On the other hand, Java works with Clojure through the classes and interfaces defined in clojure.jar, and resolves their Vars at run time. The 'gen-class case stands as an example where you might have to compile Clojure first, but I wonder if this is the typical case? > Moreoverm you may to > choose whether to copy *.clj files to output path or not (this might be > useful if you're going to invoke some functions from *.clj files > dynamically). And, of course, automatic detection and compilation of > class-labeled clojure files may be switched off. For more details see File > -> Settings -> Compiler -> Clojure. > > For someone these settings might seem not sufficiently flexible. So, all > comments and proposals are appreciated. :) > > With best regards, > Ilya Sergey > > > > > > -- Venlig hilsen / Kind regards, Christian Vest Hansen. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Clojure + Java compilation and IntelliJ IDEA plugin
Hello, all. I've just uploaded new version of La Clojure plugin for IntelliJ IDEA. Among several bugfixes and minor changes I have to note several essential moments. 1. Now Clojure support is added as so-called `facet', which may be attached to every module. Creating new module, just choose Clojure among desired technologies. In this case necessary clojure jar will be downloaded automatically and adjusted as a project library unless you point to it manually. 2. If you open existing project, clojure facet will be detected automatically. For now facet serves as a label for clojure-aware modules. In that modules you may invoke "create new clojure file" action and their clojure files will be compiled. 3. From now IntelliJ IDEA provides support for batch compilation of Clojure files, whose namespace is marked by :gen-calss tag. Compiled classes will be places to the appropriate output directory of a module. One may choose, which sources should be compiled first - Java or Clojure to resolve one-way dependencies. By default Clojure is compiled first. Moreoverm you may to choose whether to copy *.clj files to output path or not (this might be useful if you're going to invoke some functions from *.clj files dynamically). And, of course, automatic detection and compilation of class-labeled clojure files may be switched off. For more details see File -> Settings -> Compiler -> Clojure. For someone these settings might seem not sufficiently flexible. So, all comments and proposals are appreciated. :) With best regards, Ilya Sergey --~--~-~--~~~---~--~~ 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: Trying to get a list of random numbers using repeat
2009/3/25 David Plumpton :
> I think this explains your problem:
> http://xkcd.com/221/
There is something to be said for that function. At least it has no
side-effects ;)
--
Iode Software Ltd, registered in England No. 6299803.
Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
& Wear, DH5 8NE.
This message is intended only for the use of the person(s) ("the
intended recipient(s)") to whom it is addressed. It may contain
information which is privileged and confidential within the meaning of
applicable law. If you are not the intended recipient, please contact
the sender as soon as possible. The views expressed in this
communication may not necessarily be the views held by The Company.
--~--~-~--~~~---~--~~
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: STM and useful concurrency
A bunch of separate real concerns here: --- On the issue of STM Slowdown: - Clojure is typically slower than Java by an interesting amount when doing Plain Olde Java Stuff, unless great care is taken (it's possible to take great care). Such a slowdown matters less than the ability to quickly produce functioning code in many cases. - STM'd C/C++ code is *typically* slower than normal code by 3x to 10x (depends on the STM) because of the need to track *all* variables. - Clojure does not need to track all variables, just REFs - so it's "STM slowdown" factor is probably 10x reduced from the typical C/C++ slowdown. This coupled with a typically lower base speed means Clojure XTNs don't slow down Clojure programs just for existing. --- On the issue of 99.9% retry: Clojure's STM suffers from being "obstruction free" and not "lock free" (I think; I haven't paid real close attention to the details). This means that conflicting XTN's can obstruct one another when making committing. This problem is typical of STM's, BTW. Basically, I wrote a tiny microbenchmark with endless conflicting transactions. As I add *real CPUs* (not just threads), total throughput *drops*. With a locking implementation, total throughput would drop some, then hit some lower bound and stay there. Note that this is *total* throughput, not just throughput-per-CPU or throughput- per-thread. It's a performance inversion problem: adding more CPUs hurts! Until this is fixed, multi-threaded performance on Clojure will remain fragile. The problem is generic to STMs - so really I'm saying that STMs, in general, have a more fragile performance profile than locks and this is one of the reasons that STMs have had problems getting traction in the Real World. Now, just to be a pessimist I'll point out that the java.util.concurrent Locks are *also* using obstruction-free algorithms and when an Azul box cuts loose with a few hundred threads there's *always* a CPU spare to "obstruct" somebody, so we hit live- lock real quick. Given 32-way and 64-way X86 boxes rapidly approaching I'm hopeful Doug Lea will finally have to do something about this. 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 clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Clojure Talk @ Philly ETE
"Clojure and The Robot Apocalypse" Also, I posed those to hackernews in the hope of increasing advocacy for both that event (which it turns out I can't make) and for Clojure. The main site is: http://www.phillyemergingtech.com/ The hackernews posts are: http://news.ycombinator.com/item?id=531855 http://news.ycombinator.com/item?id=531853 Promoting Clojure in Philly, Kyle -- -- kyle.bur...@gmail.comhttp://asymmetrical-view.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 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: Using proxy with new method being added
> > > (def #^Object bar (proxy [Object] [ ] (foo [number] (* 3 number > (def fooFn ((proxy-mappings bar) "foo")) ;; kludge > > ;; succeeds > (def bar4 (fooFn bar 4)) > > ;; fails with "No matching method found: foo for class > clojure.proxy.java.lang.Object" > (def bar7 (.foo bar 7)) > > > Is there a way to do this simply? Try: (gen-interface :name org.bar.IFoo :methods [[foo [Integer] void]]) (def bar (proxy [IFoo] (foo [n] (* 3 n Or you can use gen-class instead of gen-interface and implement Foo as concrete class. Proxy will accept any method name you give him, but it will expose only methods in class and interfaces it extends. -- Krešimir Šojat --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Using proxy with new method being added
I want to use proxy to add a new method to a Java class rather than just overriding an existing method in the Java class. Here is what I have: (def #^Object bar (proxy [Object] [ ] (foo [number] (* 3 number (def fooFn ((proxy-mappings bar) "foo")) ;; kludge ;; succeeds (def bar4 (fooFn bar 4)) ;; fails with "No matching method found: foo for class clojure.proxy.java.lang.Object" (def bar7 (.foo bar 7)) Is there a way to do this simply? 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 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: Turning a non-standard iterator into a seq
On Mar 25, 1:55 am, Mark Reid wrote: > I am very new to Clojure and I am trying to turn a href="http://www.biojava.org/docs/api/org/biojava/bio/seq/SequenceIterator.html";>SequenceIterator > from the BioJava library into a lazy Clojure seq. > > The interface has two methods `hasNext()` and `nextSequence()` which > have very similar semantics to `hasNext()` and `next()` for the > standard Java Iterator interface. Hi Mark, You'll need to work at a lower level using cons and lazy-seq. Something like this (untested): (defn bio-iterator-seq [iterator] (lazy-seq (when (.hasNext iterator) (cons (.nextSequence iterator) (bio-iterator-seq iterator) -Stuart Sierra --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
exposing specific functions via namespace
Hello, I am trying to organise my code in namespaces and needed a little help. Basically I have created the following namespaces similar to the following: src/org/ppm/foo.clj -> org.ppm.foo src/org/ppm/foo/ src/org/ppm/foo/bar.clj -> org.ppm.foo.bar src/org/ppm/foo/baz.clj -> org.ppm.foo.baz foo.clj is an empty file which does nothing but combines bar and baz: == foo.clj == (ns org.ppm.foo (:use [org.ppm.foo bar baz])) After having the jar in classpath, I create a simple test.clj script that I load. == test.clj == (use 'org.ppm.foo) (bar-func) (baz-func) At this point, test.clj does not see the functions defined in bar and baz. Doing a (in-ns 'org.ppm.foo) before function calls makes it work fine. Is there a way to have foo.clj selectively (or all) expose functions from bar and baz to the end user via foo namespace? Do I need to put all exposed functions into foo.clj? I would prefer to keep them in bar and baz if possible as those are logical blocks for me. Thanks. Parth --~--~-~--~~~---~--~~ 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: dynamic member-symbol in (.) form
On Mar 24, 8:48 pm, ninix wrote: > Is there any way to get a "dynamic" member-symbol for use in the (.) > special form? Nope. Your options are 1) use the Java reflection API; or 2) use Clojure's internal reflection methods. I recommend (1), because that's a well-defined API. It wouldn't be too hard to wrap that up in a macro. -Stuart Sierra --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Generic functions again
Could possibly clojure multimethods be enhanced to support more general use cases (enabling to e.g. define generic functions on top of it), while still be fast for the current behavior ? It seems to me that being able to redefine the function that matches the computed dispatch-value of the call to the multifn to the declared dispatch-values, plus the possibility to customize the algorithm used for disambuiating candidate methods could be enough ? (maybe not for the next-method .. stuff, but a basis for finding the next-method could be based on the disambiguaiting algorithm if it is implemented like a comparator ?) Then defmulti could accept two additional arguments (maybe forcing that the default value be also present in this case, for backward compatibility) : (defn clos-like-dispatcher [computed checked] (every? identity (map isa? computed checked))) (defn clos-like-disambiguier [val-1 val-2] (if (every? identity (map isa? val-1 val-2)) val-1 val2)) (defmulti add (partial map type) :default clos-like-dispatcher clos-like-disambiguier) ... Or something more performant by being able to override the global disambiguing function given the list of all candidate values at once ... Could something this be added to multi-methods, with as an optimized default the current behavior ? It seems that it then could be the basis for clos-like generic functions, and a lot more cases (because it then becomes more general) than it is currently (it seems very harcoded currently). -- Laurent 2009/3/25 mikel > > > > On Mar 24, 10:51 pm, mikel wrote: > > On Mar 24, 5:37 pm, Meikel Brandmeyer wrote: > > [...snip...] > > I wanted to call out a point that I made before, but that is maybe > buried in a little too much verbiage. The point is that there is maybe > a way for me to implement an automated and predictable answer to the > question you raised: > > === > > Suppose the following situation: > > (define-method foo [x some.inter.Face] ...) > (define-method foo [x some.other.Interface] ...) > > Now suppose you call this function foo with something like > (proxy [some.inter.Face some.other.Interface] [] ...). Which > magic decides which method to use? > > > > The answer I propose is that dispatch chooses some.inter.Face first, > because it appears leftmost in the sequence of interfaces you provided > to proxy. > > That's not currently implemented because I'm not sure yet if the order > of interfaces reported by a proxy object is reliably stable, and > whether it reliably reflects their order in the original proxy > 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 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: Trying to get a list of random numbers using repeat
On Mar 24, 12:43 pm, Paul Drummond wrote: > Hi all, > > user=> (repeat 10 (rand-int 49)) > (4 4 4 4 4 4 4 4 4 4) > > Can someone please tell me why this doesn't work? I think this explains your problem: http://xkcd.com/221/ ;-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Turning a non-standard iterator into a seq
Hi, I am very new to Clojure and I am trying to turn a SequenceIterator from the BioJava library into a lazy Clojure seq. The interface has two methods `hasNext()` and `nextSequence()` which have very similar semantics to `hasNext()` and `next()` for the standard Java Iterator interface. I have looked into various seq related commands like `while`, `doseq`, `for` but cannot seem to find the right combination to wrap SequenceIterator so that it will lazily return the next item in a sequence until `hasNext()` is false. The closest I've got is: (repeatedly #(.nextSequence sequenceiterator)) which unfortunately throws when `hasNext()` is false. Any help would be greatly appreciated. Regards, Mark PS. Just so there is no confusion, the word Sequence in Sequence iterator has nothing to do with Clojure's seqs - read "SequenceIterator" as "ThingIterator" if it will make it easier. --~--~-~--~~~---~--~~ 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: Why not "sorted-set-by"?
Hi hjlee, there is already a filed issue and a patch from Timothy Pratley which adds sorted-set-by to clojure: http://code.google.com/p/clojure/issues/detail?id=76&colspec=ID%20Type%20Status%20Priority%20Reporter%20Owner%20Summary But its priority is set tow "low". erik --~--~-~--~~~---~--~~ 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: Generic functions again
On Mar 24, 10:51 pm, mikel wrote: > On Mar 24, 5:37 pm, Meikel Brandmeyer wrote: [...snip...] I wanted to call out a point that I made before, but that is maybe buried in a little too much verbiage. The point is that there is maybe a way for me to implement an automated and predictable answer to the question you raised: === Suppose the following situation: (define-method foo [x some.inter.Face] ...) (define-method foo [x some.other.Interface] ...) Now suppose you call this function foo with something like (proxy [some.inter.Face some.other.Interface] [] ...). Which magic decides which method to use? The answer I propose is that dispatch chooses some.inter.Face first, because it appears leftmost in the sequence of interfaces you provided to proxy. That's not currently implemented because I'm not sure yet if the order of interfaces reported by a proxy object is reliably stable, and whether it reliably reflects their order in the original proxy 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 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: file io
On Mar 25, 2009, at 5:52 AM, Paul Drummond wrote: Anyone else hate the names 'slurp' and 'spit' as much as me? You're not alone there. http://groups.google.com/group/clojure/browse_frm/thread/d8064dbb94c5cd2c/bce36a47121d6faf?lnk=gst&q=slurp+name#bce36a47121d6faf IMO changing these names would be a great idea whether these functions are moved up to core or not. I agree. --Steve smime.p7s Description: S/MIME cryptographic signature
Re: oo
On Mar 25, 4:13 am, Mark Engelberg wrote: > On Wed, Mar 25, 2009 at 1:44 AM, Konrad Hinsen > > wrote: > > Could you elaborate a bit on this? I haven't met any major obstacles > > with multimethods yet. The dispatch functions give quite a lot of > > flexibility in practice. In what situation did you find them > > inconvenient? [... good points snipped...] I agree with all the points you raise here. > 3. The dispatch mechanism requires a lot of explicit prefer-methods, > or else it may be hard to guarantee you won't get a run-time error > from a situation the dispatch system considers ambiguous. This also > makes code less extensible because to add a method, you must know > about all the other methods that have been implemented in order to > insert all the appropriate preferences. [...] > it seems like Clojure's multimethods are less > sophisticated than their CLOS/Dylan counterparts I dunno if I'd go that far. What I can say is that you don't need anything like prefer-method to prevent dispatching ambiguities in either CLOS or Dylan. The requirement to hand-tweak dispatching strikes me as particularly ugly. How can I design an extensible API on MutiFns? I have no idea. Defining a new method can introduce an ambiguity in dispatching that requires a prefer-method call to fix. When I'm implementing the library, that's just a minor annoyance, but when I contemplate delivering it to someone else for use and extension, it suddenly turns into a major headache. Users of that library can break existing code by defining new methods, because new methods may introduce dispatching ambiguities. In order to fix the breakage, they need to know the right prefer-method calls to make. That means they need to understand esoteric details of the library implementation for no good reason--for no reason at all, except that if they don't know them, they won't be able to make the right prefer- method calls. Yuck. --~--~-~--~~~---~--~~ 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: file io
2009/3/25 e :
> For example, "slurp" is, perhaps, marginally better than "read" because it
> may help express that it reads the whole file.
Anyone else hate the names 'slurp' and 'spit' as much as me? IMO
changing these names would be a great idea whether these functions are
moved up to core or not.
--
Iode Software Ltd, registered in England No. 6299803.
Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
& Wear, DH5 8NE.
This message is intended only for the use of the person(s) ("the
intended recipient(s)") to whom it is addressed. It may contain
information which is privileged and confidential within the meaning of
applicable law. If you are not the intended recipient, please contact
the sender as soon as possible. The views expressed in this
communication may not necessarily be the views held by The Company.
--~--~-~--~~~---~--~~
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: dynamic member-symbol in (.) form
Hi, 2009/3/25 ninix > > Thanks. > > 1) The returned exception is misleading. For example, in the following > (contrived) case: > user=> (. obj (toString "")) > java.lang.IllegalArgumentException: No matching method found: toString > for class java.lang.Object > Since the member-symbol is not evaluated, shouldn't the exception be > (at least): ... method found: (toString ... ? Indeed. > 2) For runtime method resolution - Instead of calling the Clojure > reflector methods directly (as was suggested > in the discussion you mentioned) perhaps the dot form should attempt > to evaluate the member-symbol; it will use > the value if the evaluation succeeds and can still use the symbol name > (as it currently does) if the evalution fails > (e.g. the symbol is not bound). I think the special operator manipulates the symbol at compile time, where no runtime (as the evaluation of a complex expression) is possible. That's certainly as is for a performance reason. Maybe a more dynamic version of it (not requiring one to make calls to internal clojure java code) could have its place in clojure-contrib ? > > > > On Mar 25, 10:06 am, Laurent PETIT wrote: > > Hello, > > > > No, it's not possible, dot (.) is a special form and disallows this. > > > > Search this mailing list for the subject "Help with the dot operator > special > > form" for a similar discussion on the ways to achieve more dynamic > (runtime) > > method resolution. > > > > HTH, > > > > -- > > Laurent > > > > 2009/3/25 ninix > > > > > > > > > > > > > Hi, > > > > > Is there any way to get a "dynamic" member-symbol for use in the (.) > > > special form? > > > > > For example, I get the following exception: > > > user=> (def obj (Object.)) > > > #'user/obj > > > user=> (. obj (symbol "f")) > > > java.lang.IllegalArgumentException: No matching method found: symbol > > > for class java.lang.Object > > > > > I expected this to behave like: (. obj f), so I can change the > > > accessed member by changing the argument in (symbol ...), but was > > > surprised by the result... > > > > > 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 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: dynamic member-symbol in (.) form
Thanks. 1) The returned exception is misleading. For example, in the following (contrived) case: user=> (. obj (toString "")) java.lang.IllegalArgumentException: No matching method found: toString for class java.lang.Object Since the member-symbol is not evaluated, shouldn't the exception be (at least): ... method found: (toString ... ? 2) For runtime method resolution - Instead of calling the Clojure reflector methods directly (as was suggested in the discussion you mentioned) perhaps the dot form should attempt to evaluate the member-symbol; it will use the value if the evaluation succeeds and can still use the symbol name (as it currently does) if the evalution fails (e.g. the symbol is not bound). On Mar 25, 10:06 am, Laurent PETIT wrote: > Hello, > > No, it's not possible, dot (.) is a special form and disallows this. > > Search this mailing list for the subject "Help with the dot operator special > form" for a similar discussion on the ways to achieve more dynamic (runtime) > method resolution. > > HTH, > > -- > Laurent > > 2009/3/25 ninix > > > > > > > Hi, > > > Is there any way to get a "dynamic" member-symbol for use in the (.) > > special form? > > > For example, I get the following exception: > > user=> (def obj (Object.)) > > #'user/obj > > user=> (. obj (symbol "f")) > > java.lang.IllegalArgumentException: No matching method found: symbol > > for class java.lang.Object > > > I expected this to behave like: (. obj f), so I can change the > > accessed member by changing the argument in (symbol ...), but was > > surprised by the result... > > > 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 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: oo
On Wed, Mar 25, 2009 at 1:44 AM, Konrad Hinsen wrote: > Could you elaborate a bit on this? I haven't met any major obstacles > with multimethods yet. The dispatch functions give quite a lot of > flexibility in practice. In what situation did you find them > inconvenient? To summarize, I think the points that have been raised here and on related threads are that: 1. Structs don't inherently have a type. If you want to dispatch on type (a common use-case), you have to make a constructor that inserts the type information as part of the struct. Some have expressed concern that it may be too easy for this "type information" to be altered, or worse, the data could be "changed" or "removed" in a way that makes the struct inconsistent with the type label it carries around. 2. No way to call "next-method" or "super", which limits the ability to reuse related methods. 3. The dispatch mechanism requires a lot of explicit prefer-methods, or else it may be hard to guarantee you won't get a run-time error from a situation the dispatch system considers ambiguous. This also makes code less extensible because to add a method, you must know about all the other methods that have been implemented in order to insert all the appropriate preferences. Honestly, the one time I used Clojure's multimethods (contrib.math), they suited my needs perfectly, but I definitely see where these concerns are coming from. The existing mechanism is very flexible in one respect: you can dispatch on anything you want, not just type. In other respects, it seems like Clojure's multimethods are less sophisticated than their CLOS/Dylan counterparts. If there is a way to achieve the same things in Clojure, it's not readily apparent (see recent thread about the next-method/super issue, for example). --~--~-~--~~~---~--~~ 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: oo
On 24.03.2009, at 19:29, mikel wrote: > I personally like Haskell's philosophy in this area: there is a > facility for defining data layouts, and there is a facility for > defining protocols, and they are completely separate. You can define a I like that as well, and I have been trying to do something similar in Clojure with my types module (clojure.contrib.types) and my collection of generic interfaces (clojure.contrib.generic). It's too early to say if these will work out well, but I do think they are as close to Haskell's philosophy as possible in a dynamically typed language. I haven't thought much about extending types yet. It could mean opening the can of worms associated with inheritance and all that. I am waiting for a concrete situation where extension would be useful to think about how best to do it. > Clojure's built-in defstruct provides a way to specify record types, > but not to extend them. It is not really meant to define types, the documentation clearly says that struct maps are just an implementation of maps optimized for a specific frequent use case. > (I have found Clojure MultiFns awkward to use thus far, especially > when trying to design extensible APIs around them; client code has to > know too much about the implementation details of MultiFns--e.g. you > have to know when and how to hand-tweak dispatching for the particular > MultiFns you are given). Could you elaborate a bit on this? I haven't met any major obstacles with multimethods yet. The dispatch functions give quite a lot of flexibility in practice. In what situation did you find them inconvenient? Konrad. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: dynamic member-symbol in (.) form
Hello, No, it's not possible, dot (.) is a special form and disallows this. Search this mailing list for the subject "Help with the dot operator special form" for a similar discussion on the ways to achieve more dynamic (runtime) method resolution. HTH, -- Laurent 2009/3/25 ninix > > Hi, > > Is there any way to get a "dynamic" member-symbol for use in the (.) > special form? > > For example, I get the following exception: > user=> (def obj (Object.)) > #'user/obj > user=> (. obj (symbol "f")) > java.lang.IllegalArgumentException: No matching method found: symbol > for class java.lang.Object > > I expected this to behave like: (. obj f), so I can change the > accessed member by changing the argument in (symbol ...), but was > surprised by the result... > > 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 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: Running multiple scripts from the Java realm
On Mar 25, 3:12 am, BerlinBrown wrote:
> I know it isn't advised but I have my various reasons.
>
> What are some of the best ways to invoke clojure scripts from Java but
> still maintain the state of the current session.
>
> For example, if I run a script from Java, is there a way to ensure
> that script has already been run...say if I run another script.
> I was doing the following.
>
> --
>
> package test.toolkit.clojure;
>
> import clojure.lang.Namespace;
> import clojure.lang.RT;
> import clojure.lang.Symbol;
> import clojure.lang.Var;
>
> public class TestSpringLoadClojure {
>
> final static private Symbol CLOJURE_MAIN = Symbol.create
> ("clojure.main");
> final static private Namespace CLOJURE_MAIN_NS =
> Namespace.findOrCreate(CLOJURE_MAIN);
> final static private Var REQUIRE = Var.intern(RT.CLOJURE_NS,
> Symbol.create("require"));
> final static private Var LEGACY_REPL = Var.intern(CLOJURE_MAIN_NS,
> Symbol.create("legacy-repl"));
> final static private Var LEGACY_SCRIPT = Var.intern(CLOJURE_MAIN_NS,
> Symbol.create("legacy-script"));
> final static private Var MAIN = Var.intern(CLOJURE_MAIN_NS,
> Symbol.create("main"));
>
> private static void legacy_script(String[] args) throws Exception {
> REQUIRE.invoke(CLOJURE_MAIN);
> LEGACY_SCRIPT.invoke(RT.seq(args));
> }
>
> private static void invoke_script(String[] args) throws Exception {
> LEGACY_SCRIPT.invoke(RT.seq(args));
> }
>
> public static void main(final String [] args) throws Exception {
>
> final String [] scripts = { };
> final String [] scripts2 = { "clj/utils/test_use_utils.clj" };
> legacy_script(scripts);
> Var.intern(Namespace.findOrCreate(Symbol.create("clojure")),
> Symbol.create("*console*"), "abc");
> invoke_script(scripts2);
>
> }
>
> }
>
> But I get an error message:
>
> [java] java.lang.Exception: Unable to resolve symbol: *console*
> in this context (test_use_utils.clj:45)
> [java] at org.apache.tools.ant.taskdefs.ExecuteJava.execute
> (ExecuteJava.java:194)
Nevermind.
(println "-->" clojure/*console*)
if I do this, I get it
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Running multiple scripts from the Java realm
I know it isn't advised but I have my various reasons.
What are some of the best ways to invoke clojure scripts from Java but
still maintain the state of the current session.
For example, if I run a script from Java, is there a way to ensure
that script has already been run...say if I run another script.
I was doing the following.
--
package test.toolkit.clojure;
import clojure.lang.Namespace;
import clojure.lang.RT;
import clojure.lang.Symbol;
import clojure.lang.Var;
public class TestSpringLoadClojure {
final static private Symbol CLOJURE_MAIN = Symbol.create
("clojure.main");
final static private Namespace CLOJURE_MAIN_NS =
Namespace.findOrCreate(CLOJURE_MAIN);
final static private Var REQUIRE = Var.intern(RT.CLOJURE_NS,
Symbol.create("require"));
final static private Var LEGACY_REPL = Var.intern(CLOJURE_MAIN_NS,
Symbol.create("legacy-repl"));
final static private Var LEGACY_SCRIPT = Var.intern(CLOJURE_MAIN_NS,
Symbol.create("legacy-script"));
final static private Var MAIN = Var.intern(CLOJURE_MAIN_NS,
Symbol.create("main"));
private static void legacy_script(String[] args) throws Exception {
REQUIRE.invoke(CLOJURE_MAIN);
LEGACY_SCRIPT.invoke(RT.seq(args));
}
private static void invoke_script(String[] args) throws Exception {
LEGACY_SCRIPT.invoke(RT.seq(args));
}
public static void main(final String [] args) throws Exception {
final String [] scripts = { };
final String [] scripts2 = { "clj/utils/test_use_utils.clj" };
legacy_script(scripts);
Var.intern(Namespace.findOrCreate(Symbol.create("clojure")),
Symbol.create("*console*"), "abc");
invoke_script(scripts2);
}
}
But I get an error message:
[java] java.lang.Exception: Unable to resolve symbol: *console*
in this context (test_use_utils.clj:45)
[java] at org.apache.tools.ant.taskdefs.ExecuteJava.execute
(ExecuteJava.java:194)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
