Re: Clojure 1.0.0 has been uploaded to Maven Central - Finally

[Jason Sankey]

Hi there,

AlamedaMike wrote:
> Stefan, Meikel,
> 
> Thanks much for this. It looks very interesting.
> 
> Forgive a newb question but I just downloaded Maven for the first time
> 30 minutes ago. I read the "Maven in 5 minutes" doc, and executed:
> 
> mvn archetype:create -DgroupId=org.clojure  -DartifactId=clojure

This step doesn't actually specify that you are creating a Clojure 
project.  The groupId and artifactId here are names used in the project 
you are creating (typically they would be your own package namespace and 
the name of your project respectively).  As you have not specified the 
type of archetype, Maven has used the default 
"maven-archetype-quickstart", which creates a trivial Java project.  I'm 
not aware of any archetype for creating a Clojure project.

> followed by:
> 
> mvn package
> 
> All the tests passed. I then ran:
> 
> java -cp clojure-1.0-SNAPSHOT.jar  org.clojure.App
> 
> and got "Hello World" as the output.
> 
> My expectation is that one of the first two commands would go to a
> central repository and download a POM file based on the id parameter,
> which would in turn supply the data necessary to download the other
> dependencies necessary to build a complete set of clojure files.
> However, I'm just getting the 2,092 byte clojure jar file. What am I
> missing?

The clojure.jar file you have built here contains the trivial "Hello, 
World" Maven quickstart Java application.  It does not relate to Clojure 
at all, that is just the name you have given it.

Out of the box, Maven actually has no support for Clojure.  However, at 
this point, where you are just starting out with Maven (and when you 
might not actually need to explicitly compile your Clojure), it might be 
better to just leverage the dependency management by using the Maven Ant 
tasks from an Ant build, or use Ivy+Ant to grab the dependencies from 
the Maven repository.  That is, just use Maven or Ivy to grab the latest 
Clojure jar files and use the default on the fly compilation for your 
Clojure code.

If you do need to compile your Clojure code ahead-of-time (AOT), you 
will need a Maven plugin like:

http://github.com/talios/clojure-maven-plugin/tree/master

I've not used this plugin but it appears to be in the early stages. 
There is also:

http://github.com/dysinger/clojure-pom/tree/master

which appears to use the Maven antrun plugin to call the Clojure 
compiler, rather than implementing a full-blown Maven plugin.

Hope that helps,
Jason

-- 
Pulse - Continuous Integration made easy.
Does your project have a pulse?
Try it free at: http://zutubi.com

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

Re: ATTN contrib authors: Automatic documentation for clojure.contib

[Jason Sankey]

Hi Tom,

Tom Faulhaber wrote:

> The next stage of my plan is to build a robot that watches the
> subversion repository and updates the doc on every checkin. Therefore
> the doc will typically correspond to the tip of the tree.


I'd be happy to add generation/upload of documentation as a build step 
or even separate project on the server at http://pulse.zutubi.com/.  It 
already has the ability to trigger on every change, so there would be no 
need to create a separate robot to check for changes.  Just let me know 
if you think this would be helpful.

Cheers,
Jason


--~--~-~--~~~---~--~~
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: DISCUSS: clojure.contrib.java-utils/file

[Jason Sankey]

James Reeves wrote:
> On Apr 6, 11:29 am, Jason Sankey  wrote:
>> I think there may be a misunderstanding over "combining" here - I read
>> Stuart's mail to mean there was no obvious way to combine
>> duck-streams/file and java-utils/file, whereas this implementation shows
>> java-utils/file style behaviour only?
> 
> As far as I'm aware, it has most of both behaviours.

I guess the confusion is mine :).  I saw the primary difference as 
joining args with or without separators in between.

>> IMO even if the two functions could be combined, it would be confusing
>> to understand how the arguments passed in would be joined.  Better not
>> to try.
> 
> That's true. Conceptually, I prefer the java-utils/file method, which
> is basically the same as an identically named function I wrote for
> Compojure.

I also feel the java-utils version is more generally-applicable - it 
makes composing files easier without any assumptions about its input. 
The duck-streams version does other handy things like separator 
normalisation and tilde expansion, but that means it can't be used for 
all cases.  It feels like the latter is convenient for composing 
filenames from literals or at the repl, but not so good for handling 
arbitrary files/paths.

> The problem with having java-utils/file and duck-streams/file is that
> you lose the ability to load both namespaces at the same time without
> defining an exception for the file function. This does not seem like
> an ideal solution. I think we should choose one or the other, give
> them different names, or attempt to merge their functionality.

Generally speaking I'm happy to use (require [ ... :as ...]) to solve 
this problem (I expect as contrib grows name clashes will become 
inevitable).  In any case your point still stands from a conceptual 
point of view - having two functions named "file" in contrib with 
similar goals but different semantics is a recipe for confusion.

Cheers,
Jason

-- 
Pulse - Continuous Integration made easy.
Does your project have a pulse?
Try it free at: http://zutubi.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: DISCUSS: clojure.contrib.java-utils/file

[Jason Sankey]

James Reeves wrote:
> On Apr 6, 4:10 am, Stuart Sierra  wrote:
>> I don't see an obvious way of combining them.
> 
> What about something like:
> 
> (defn- normalize-separator
>   [filepath]
>   (.. (str filepath)
> (replace \\ File/separatorChar)
> (replace \/ File/separatorChar)))
> 
> (defn file
>   [filepath & more]
>   (reduce
> (fn [parent path] (File. parent path))
> (File. (normalize-separator filepath))
> (map normalize-separator more)))

I think there may be a misunderstanding over "combining" here - I read 
Stuart's mail to mean there was no obvious way to combine 
duck-streams/file and java-utils/file, whereas this implementation shows 
java-utils/file style behaviour only?

IMO even if the two functions could be combined, it would be confusing 
to understand how the arguments passed in would be joined.  Better not 
to try.

FWIW, the java-utils version is similar to a utility method that I use 
pretty heavily in Java code -- so I will find it useful.

Cheers,
Jason

-- 
Pulse - Continuous Integration made easy.
Does your project have a pulse?
Try it free at: http://zutubi.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: ant + ivy IMO is not simpler than POMs

[Jason Sankey]

dysinger wrote:
> It's good to see other examples of dep management for other setups.
> 
> However, IMO working on 20 modules would be a PITA with ant+ivy. Can
> you show an example with multi-module? (I tried checking out the
> latest release of IVY and it wouldn't compile on my Mac w/ JDK 1.6 so
> I didn't get far.)

Looks like Krešimir already obliged.

>>From what I read briefly, multi-module ivy is alpha and even more
> complex than your example with even more XML. (
> http://ant.apache.org/ivy/history/2.0.0-alpha2/tutorial/multiproject.html
> )

Multi-module Ivy is not alpha, it has been possible for several versions 
(and for several years).  The documentation could obviously use an 
update there.

> Also since there is no POM with ivy, you cannot inherit from a parent
> you would have to include common xml. Am I wrong?  Maven multi-module
> also works well with git submodules/hg forest/svn externals. I can't
> see how that works with Ant/Ivy

You are right - the normal way you would achieve sharing is just as you 
would in Ant -- via includes/custom tasks.  I am not sure what you mean 
you can't achieve with submodules etc, so can't speak to that.

> Ant build.xml also just feels one-off to me.
> Every_single_ant_project_I_have_ever_worked_on has a different flavor/
> structure of build.xml.  This is my biggest irritation.  Trying to
> build a even modestly (6 modules) complex releases with different
> flavored ant build files is a PITA.

This is the weakness and strength of ant+ivy.  There is no enforced 
structure - so you need to define one.  Once you've defined it, though, 
you just share the common XML.  And if you can't or don't want to use 
the Maven structure, Ivy gives you this flexibility.

> I loved Ant when it came out 10 years ago but that was 10 years ago.
> I think I'll stick with simple short poms for now.  It's working
> awesome for me. It standardizes the project layout/deps/repl-script
> for all my clojure modules.

I'm also not a huge Ant fan, but it works for me and needs very little 
care/feeding after you have your common XML.  Most crucially, if I want 
to make a small change/customisation it is easy with Ant -- but not 
always so with Maven (not least, I'm sure, as I am not a Maven expert).

Of course, there is no arguing that when Maven works -- as it is for you 
-- that it works very well and with less initial setup.  I'd never argue 
someone should switch away from something that's working for them.

> Everybody loves to bash Maven. As long as you keep POMs simple, I have
> yet to see anything simpler for dealing with dep. management and multi-
> language & multi-module (java & clojure together) real-world component-
> based projects (real world needs).

Agreed, at its simple best it doesn't get any easier than Maven.

The reason I personally prefer Ivy is that it takes care of one thing 
(dependencies) and does it well, and that just fits better with the way 
I like to put things together.

> *
> My hope is in the not too distant future we have declarative
> (Metadata?) dependency management declared in clojure than can pull
> libs from maven repos and we can all ditch any XML -- Something like
> "Ties".
> *

I personally would be delighted to see Ivy paired with something more 
declarative than Ant -- one promising project from the Groovy world is 
Gradle but it's pretty raw at the moment.

In the end, though, the key point you make is that Maven-style 
repositories are the de-facto standard for Java.  So if clojure 
libraries are made available in this way then people can build tools and 
projects around the repositories using Maven/Ivy/etc, however they prefer.

Cheers,
Jason



-- 
Pulse - Continuous Integration made easy.
Does your project have a pulse?
Try it free at: http://zutubi.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: Ironicly Maven2 is the lightest I could come up with

[Jason Sankey]

Laurent PETIT wrote:
> Hi,
> 
> 2009/4/2 Jason Sankey mailto:ja...@zutubi.com>>
> 
> Ivy [ ... ] also supports pluggable resolvers, so
> you can host your Jars/dependency information in multiple ways.
> 
> 
> Does that mean one could write resolvers to automagically get libraries 
> from "source" repositories such as github, bitbucket, ... (as long as a 
> minimal standard convention for the repositories layout is followed) ?
> 
> Clearly identified versions could be directly mapped to tagged branches, 
> and SNAPSHOT versions to the HEAD  branch ?
> 
> This could be really cool ! :-)

I certainly think this is possible.  Are you talking about building from 
the source on demand, or having jars stored in the repositories?  It 
sounds like the former, in which case I'm not sure if this would be an 
efficient way to do it.

Instead, you can just have a build server that builds the projects on 
every change, and publishes the jars to a repository.  Apart from the 
efficiency of building only once, the jars would only be published on a 
successful build/test.  This is what I have set up now for clojure and 
clojure-contrib on http://pulse.zutubi.com/, where the jars go to an 
internal Ivy repository.  I believe Howard Lewis Ship also has a build 
server that builds clojure only and publishes it to a Maven repository.

I'm happy to expand pulse.zutubi.com if people find it useful to other 
clojure projects, and work on the features of the internal repository.

Cheers,
Jason

-- 
Pulse - Continuous Integration made easy.
Does your project have a pulse?
Try it free at: http://zutubi.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: Ironicly Maven2 is the lightest I could come up with

[Jason Sankey]

Paul Stadig wrote:
> This works great for Java libraries, but only libraries that are in a 
> maven repo. How hard is it to get code into a repo? What about java 
> libraries not in a maven repo, or clojure code like clojure-json on GitHub?

I don't think it is terribly hard to get in the repo, but there can be lag.

> 1. You could set up your own repo. Ok. Cool, but not the easiest to 
> setup and maintain, plus you need a server.

Actually, many Maven projects end up having to do exactly that, and 
indeed lots of people recommend doing so.  The main reasons are:

1) Having an external dependency for your build is bad news: e.g. you 
don't want your builds to fail because the Maven repo is down.
2) Historically at least the Maven central repository contains projects 
with incorrect dependency information, so you need to correct that 
yourself anyway.
3) Just depending on the latest version of a module (or latest of a 
release stream) on the central repository means your build can break due 
to an unforseen external change.  So while it might seem nice to keep 
magically up to date (without changing your own repository/poms) at 
first this is not something that works in practice.

Maintaining your own repository takes work but makes these problems go 
away.  On the flipside you have to ask if this work is yielding enough 
benefit over just getting the jars you need and dropping them in a 
directory.  I think for small projects/companies it won't be, but for 
larger efforts and particularly where you have multiple modules of your 
own with their own interdepencies the balance tips.

> 2. You could install dependencies in your local repo. Cool, if the 
> project happens to be using maven and you can to "mvn install". Uncool, 
> if you have to manually "install" it into your local repo. Also uncool, 
> because I see my local repo more as a cache that can sometimes get 
> crufty and can be cleared out if I need the disk space. Maven *should* 
> be able to re-download my dependencies and put them in my local repo, 
> but not so for these manual workarounds.

In my experience for these other dependencies the trickiest part can be 
figuring out what they in turn depend on, which you have to do either 
way.  Once you know that dropping them into a simple repository is not 
that hard.

If you want to maintain this information that you derived manually, then 
you just can't expect to treat it like a cache.  Keep One True copy 
somewhere, possibly in version control.

> 3. ???
> 
> I'm not trying to be disparaging. If this works for someone, I think it 
> is pretty slick. I'm still of the mind that there could be something 
> better. Something that can pull from a maven repo as needed, but also 
> pull from other sources like github, sourceforge, google code, etc. I'm 
> just spoiled by rubygems. This is an existence proof that there can be a 
> simple way to download and setup dependencies (not without foibles).

Other tools like apt/dpkg also come to mind as solving this reasonably 
well.  I think a key thing in this case is a lot of effort goes into 
maintaining the packages and testing a full "distribution" of them 
together.  This makes the dependency information and stability more 
reliable than the Maven central repo -- but it requires a lot of resources.

> Perhaps if there was a Clojure Maven Repo (CMR) where people could 
> easily get their code distributed, then I would feel satisfied.

Certainly a standardised way to specify your dependencies would be a 
good thing.  I'm not sure it needs to be Maven based -- although 
interoperability with Maven would be a worthy goal.

I am personally a happy Ivy user -- Ivy essentially does the dependency 
management part of Maven but (IMO):

- with more flexibility; and
- without the rest of the Maven baggage (or features depending on your 
perspective)

Ivy interoperates with Maven, and also supports pluggable resolvers, so 
you can host your Jars/dependency information in multiple ways.

> What happened to the ClojureForge idea from tech.coop 
> ? Did anything come about from that, Drew? Perhaps 
> just hosting CMR with some way to signup for an account to be able to 
> "mvn deploy"?

A central place to at least look for Clojure libraries would be a great 
start.  If it also hosted those libraries and included standardised 
dependency information, I think it would be helpful whether you just 
wanted to stick the jars in a directory or use a full-blown dependency 
management tool.

Cheers,
Jason

> On Thu, Apr 2, 2009 at 1:25 AM, dysinger  > wrote:
> 
> 
> ...for easy dependency management and no-compile project setup.
> https://github.com/dysinger/clojure-pom/tree
> 
> Using maven only for the dependency management and to create a custom
> repl script allows me to still use emacs/slime for dynamic development
> of clojure code.
> 
> My motivation is 3 fold:
> 
> 1) I have lots of small modules

Re: test-is now supports TAP

[Jason Sankey]

Stuart Sierra wrote:
> On Apr 1, 12:21 pm, Jason Sankey  wrote:
>> Out of interest, are you interested in other output formats for test-is?
>>   I chose JUnit compatible as a defacto-standard -- it integrates with
>> the unofficial build server I have been working on as well as many other
>> tools.  I have it working but in need of some tweaks and cleanups.  I am
>> happy to donate the code (contributor agreement is in the mail to Rich)
>> when I clean it up.  It could also easily live outside of test-is as an
>> optional extension, in which case I will probably make it public on GitHub.
> 
> Yes, I would like to have more output formats.  I'd like to keep each
> format in a separate namespace (like I did with the TAP extension) but
> make them all available in clojure-contrib.  Let me know if I can be
> of any help in integrating the JUnit output with test-is.

OK, great.  I will clean up my implementation and make sure it mimics 
the style of the existing one, then I can provide a patch for review. 
My name has hit the contributors page now, so I guess my agreement 
reached Rich intact.

Cheers,
Jason

-- 
Pulse - Continuous Integration made easy.
Does your project have a pulse?
Try it free at: http://zutubi.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: test-is now supports TAP

[Jason Sankey]

Hi Stuart,

Stuart Sierra wrote:
> Not an April Fool's joke!  New lib "clojure.contrib.test-is.tap" adds
> Test Anything Protocol (TAP) support to test-is.  Use it like this:
> 
> ;;   (use 'clojure.contrib.test-is)
> ;;   (use 'clojure.contrib.test-is.tap)
> ;;
> ;;   (with-tap-output
> ;;(run-tests 'my.cool.library))

Cool :).

> Warning: this doesn't work with clojure.contrib.test-clojure/run.  I'm
> not sure why.  I think it has something to do with how test-clojure/
> run loads files.  If anyone can shed some light on that, I'd
> appreciate it.  Loading the files individually and calling
> (with-tap-output (run-all-tests))
> works correctly.

I encountered the same problem when implementing JUnit-compatible XML 
output for test-is, and my guess (without having investigated 
thoroughly) is that it is indeed how test-clojure loads files.  It pulls 
in the namespaces under test using:

(apply require :reload-all namespaces)

I guess that because test-is itself is included in these namespaces, 
your redefinitions of the reporting methods are lost.  I worked around 
this myself for now by writing my own function to take a list of 
namespaces and run the tests in the way test-clojure does, allowing me 
to time the redefinitions to happen after the namespaces under test are 
pulled in.

Out of interest, are you interested in other output formats for test-is? 
  I chose JUnit compatible as a defacto-standard -- it integrates with 
the unofficial build server I have been working on as well as many other 
tools.  I have it working but in need of some tweaks and cleanups.  I am 
happy to donate the code (contributor agreement is in the mail to Rich) 
when I clean it up.  It could also easily live outside of test-is as an 
optional extension, in which case I will probably make it public on GitHub.

Cheers,
Jason

-- 
Pulse - Continuous Integration made easy.
Does your project have a pulse?
Try it free at: http://zutubi.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: Possible Bug In clojure.zip/remove

[Jason Sankey]

Frantisek Sodomka wrote:
> On Mar 19, 12:58 pm, Jason Sankey  wrote:
>> Also, is there somewhere I can contribute test cases for this to
>> prevent a future regression?
> 
> Tests for clojure.zip can from now on go to test-clojure.clojure-zip:
> http://code.google.com/p/clojure-contrib/source/browse/trunk/src/clojure/contrib/test_clojure/clojure_zip.clj

Thanks, I plan on posting my CA today and can then look at adding a few 
cases.

> On Mar 20, 1:24 pm, Jason Sankey  wrote:
>> 3) Test-is reports results for all (is ...) expressions separately, but
>> there is no good way to name them separately.  At the moment I am
>> reporting on each (is ...) as a separate test case by using the test
>> name plus line number, but this is clunky.  I think combining the
>> results so one deftest == one JUnit report test case would be more sensible.
> 
> If there are any troubles with test-is, you can consult Stuart Sierra
> (the author of test-is).

Although it may have sounded that way, I didn't intend to suggest that 
the default test-is behaviour was wrong, I presumed it was intended that 
way, and I'm sure it has advantages.  For reporting the results in a CI 
server, though, and in particular when tracking the state of the same 
test across multiple builds, having each (is ...) as a separate case 
does not make sense.  My own reporting code can handle this be combining 
the results of multiple callbacks to (report ...) into a single "test 
case result", which is what I plan to do.

Cheers,
Jason

--~--~-~--~~~---~--~~
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: Possible Bug In clojure.zip/remove

[Jason Sankey]

Hi Frantisek,

Frantisek Sodomka wrote:
> On Mar 19, 11:37 pm, Jason Sankey  wrote:
>> I pretty much have it working for the test-clojure suite now, although
>> I'm sure the code could use review by a more experienced eye.  I've been
>> looking at adding the other two top-level suites (test-contrib and
>> datalog) too, but their test clojure scripts are structured slightly
>> differently such that requiring them leads them to run their tests
>> immediately.  It would be nice if some convention could be established
>> for a top-level suite to be defined/exposed, and in such a way that I
>> could wrap them with my script which defines special reporting methods
>> to spit out XML.
> 
> Nice!
> I took the liberty and changed the test-contrib and the datalog top-
> level tests to match test-clojure. Let me know if that helps or if
> something is broken :)

Sweet, this is perfect.  I have now cobbled together a proof-of-concept 
on my build server using my code to run the three top-level suites and 
produce JUnit-compatible reports.  I have kept this separate at the 
moment from the primary clojure-contrib project as there are issues I 
need to sort out:

1) At the moment I'm just copying in my extra code and an extra build 
file to Make Things Work.  I need a nicer way to layer this on.

2) A few things are hard coded which need not be.

3) Test-is reports results for all (is ...) expressions separately, but 
there is no good way to name them separately.  At the moment I am 
reporting on each (is ...) as a separate test case by using the test 
name plus line number, but this is clunky.  I think combining the 
results so one deftest == one JUnit report test case would be more sensible.

4) I'm still new to clojure, so I'm sure my code is far from optimal.

In any case, it's nice to have come this far already, and perhaps the 
hackish reports can even start to be useful.  You can take a look at an 
example build here:

http://pulse.zutubi.com/browse/projects/clojure-contrib-reports/builds/5/

ans see that it reports 801 tests, all passed ;).

Cheers,
Jason

--~--~-~--~~~---~--~~
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: Possible Bug In clojure.zip/remove

[Jason Sankey]

Hi Frantisek,

Frantisek Sodomka wrote:
> On Mar 19, 12:58 pm, Jason Sankey  wrote:
>> Also, is there somewhere I can contribute test cases for this to
>> prevent a future regression?
> 
> In order to contribute, you must fill-in and send The Contributor
> Agreement (CA) to Rich Hickey:
> http://clojure.org/contributing

Thanks, I have one printed out, and hope to mail it off at the start of 
next week.

> Tests for clojure.core are currently in clojure-contrib in test-
> clojure:
> http://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src/clojure/contrib/test_clojure
> 
> There is no place yet where to put clojure.xml tests, but it shouldn't
> be hard to create something for it. After Rich receives your CA, you
> can create an issue and post a patch for it:
> http://code.google.com/p/clojure-contrib/issues/list
> 
> An example issue:
> http://code.google.com/p/clojure-contrib/issues/detail?id=15
> 
> Your help with testing Clojure is very welcome!

I appreciate the information, and will be happy to chip in with some 
tests when I am all CA'd up.

In the mean time, as mentioned on IRC I am setting up another 
(unofficial) build server.  I have it building both clojure and contrib 
already, and in the latter it runs the test suites.  I would like to 
take this to the next step by generating reports from the tests which 
the server can read and thus report on the test results nicely in the 
UI.  I am aiming to generate JUnit-compatible XML output, as this is the 
most widely-supported format by a variety of tools.

I pretty much have it working for the test-clojure suite now, although 
I'm sure the code could use review by a more experienced eye.  I've been 
looking at adding the other two top-level suites (test-contrib and 
datalog) too, but their test clojure scripts are structured slightly 
differently such that requiring them leads them to run their tests 
immediately.  It would be nice if some convention could be established 
for a top-level suite to be defined/exposed, and in such a way that I 
could wrap them with my script which defines special reporting methods 
to spit out XML.

Cheers,
Jason

--~--~-~--~~~---~--~~
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: Possible Bug In clojure.zip/remove

[Jason Sankey]

Hi Christophe,

On Mar 19, 11:22 am, Christophe Grand  wrote:
> Jason Sankey a écrit :
>
> > (if (and (branch? loc) (not (empty? (children loc
> >   (recur (-> loc down rightmost))
> >   loc))
>
> > Being new to both clojure and zip I admit there's still a good chance
> > that I have no idea what I'm talking about :).
>
> No you are right and there's the same bug in prev.
>
> Here is a patch that fixes both bugs. (Rich, can I open an issue?)

Thanks for the reply, and a patch which is (not surprisingly) far more
elegant than my hack.  Maybe this little bit of logic should be
extract to its own function (alarms go off when an identical bug shows
up in two places)?

Also, is there somewhere I can contribute test cases for this to
prevent a future regression?

> Btw, (not (empty? coll)) is not idiomatic, (seq coll) is the clojure way to 
> test for non-emptiness.

Thanks, I appreciate the tip.

> Thanks for the report,

No problem,
Jason
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Possible Bug In clojure.zip/remove

[Jason Sankey]

Hi All,

I've been teaching myself clojure and in the process am working on a
small program to manipulate an XML file.  I figured this was a good
chance to try clojure.zip, but I'm having some difficulty.  Being a
newbie I strongly suspected myself - but when I posed the question on
IRC the conclusion was there appears to be a bug.

I boiled it down to the following:

(require ['clojure.xml :as 'xml]
 ['clojure.zip :as 'zip])

(defn strip [root tag]
  (loop [loc root]
(if (zip/end? loc)
  (zip/root loc)
  (recur (zip/next (if (= (:tag (zip/node loc)) tag)
 (zip/remove loc)
 loc))

(def data "")
(def xml-tree (xml/parse (java.io.ByteArrayInputStream. (.getBytes
data
(def zip-root (zip/xml-zip xml-tree))

(xml/emit (strip zip-root :foo))
(xml/emit (strip zip-root :bar))

The first call to strip :foo works as expected, but the following call
to strip :bar throws an NPE within zip/remove.  On further inspection
we came clojure/zip.clj:234:

(if (branch? loc)
  (recur (-> loc down rightmost))
  loc))

According to the docs, branch? can return true for a loc that does not
currently have any children, so the suspicion is that it is an
insufficient test before moving down as happens in the line below.  I
can fix this for my simple test cases by replacing the above with:

(if (and (branch? loc) (not (empty? (children loc
  (recur (-> loc down rightmost))
  loc))

Being new to both clojure and zip I admit there's still a good chance
that I have no idea what I'm talking about :).

Cheers,
Jason

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