SLIME REPL broken

[Stefan Kamphausen]

Hi,

a short discussion on the SLIME mailinglist lead to the result that
the arglist of a backend function in swank did change.

Current checkouts of SLIME do not work with Clojure, at least if you
use autodoc.

http://common-lisp.net/pipermail/slime-devel/2009-November/016919.html

I took a quick look at the relevant function (src/main/clojure/swank/
commands/contrib/swank_arglists.clj) in swank-clojure but it would
need some diving into the code for me to help with this.  Maybe
someone more experienced than me can step in?

Kind regards,
Stefan Kamphausen

-- 
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: SLIME REPL broken

[Stefan Kamphausen]

Hi,

Phil Hagelberg wrote:
> Unless there are some really great features added upstream in slime,
> fixing swank-clojure to work with their latest changes is a low priority.

this is a pity, at least for those of us, who also use Slime to do
some CL hacking.  For that setup it is quite common to always update
to CVS head because that may be the only version working with current
releases of, e.g., SBCL.  Well, currently I don't really do CL stuff,
it's just that I set up another machine doing lots of VC-checkouts...
I could just copy an older version of Slime there.

I'll take a look at it the next few days (er, evenings that is), if I
find the time.  No promises ;-)

Over there at Slime's people are thinking, the Clojure family forked
Slime, maybe that's not the worst idea.  Things would probably get
easier if there were only one backend to support.

Best regards,
Stefan

-- 
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: SLIME REPL broken

[Stefan Kamphausen]

Hi,

Stefan Kamphausen wrote:
> I'll take a look at it the next few days (er, evenings that is), if I
> find the time.  No promises ;-)

Not that I'm close to a solution, but at least I have stacktrace...
After some digging in the clojure-swank code I came across this piece
in swank.clj:

(defn- connection-serve [conn]
  (let [control
(dothread-swank
  (thread-set-name "Swank Control Thread")
  (try
   (control-loop conn)
   (catch Exception e
 ;; fail silently
 nil)))


and I didn't like that comment.  So I changed that to

(defn- connection-serve [conn]
  (let [control
(dothread-swank
  (thread-set-name "Swank Control Thread")
  (try
   (control-loop conn)
   (catch Exception e
 ;; fail silently
 (.printStackTrace e)
 (.printStackTrace (.getCause e))
 nil)))


Then after typing just "(+" into the SLIME-REPL-Buffer (obviously
without the quotes) I see a stacktrace in the *inferior-lisp*-Buffer:

user=> user=> Connection opened on local port  37693
#
user=> user=> java.lang.InterruptedException
at java.util.concurrent.locks.AbstractQueuedSynchronizer
$ConditionObject.reportInterruptAfterWait
(AbstractQueuedSynchronizer.java:1899)
at java.util.concurrent.locks.AbstractQueuedSynchronizer
$ConditionObject.await(AbstractQueuedSynchronizer.java:1934)
at java.util.concurrent.LinkedBlockingQueue.take
(LinkedBlockingQueue.java:358)
at swank.util.concurrent.mbox$receive__214.invoke(mbox.clj:28)
at swank.core$control_loop__249.invoke(core.clj:258)
at swank.swank$connection_serve__365$fn__397$fn__399.invoke(swank.clj:
29)
at clojure.lang.AFn.applyToHelper(AFn.java:171)
at clojure.lang.AFn.applyTo(AFn.java:164)
at clojure.core$apply__4305.invoke(core.clj:420)
at swank.swank$connection_serve__365$fn__397.doInvoke(swank.clj:26)
at clojure.lang.RestFn.invoke(RestFn.java:402)
at clojure.lang.AFn.run(AFn.java:37)
at java.lang.Thread.run(Thread.java:619)
Exception in thread "Swank Control Thread" java.lang.RuntimeException:
java.lang.NullPointerException
at clojure.lang.AFn.run(AFn.java:41)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.NullPointerException
at swank.swank$connection_serve__365$fn__397$fn__399.invoke(swank.clj:
33)
at clojure.lang.AFn.applyToHelper(AFn.java:171)
at clojure.lang.AFn.applyTo(AFn.java:164)
at clojure.core$apply__4305.invoke(core.clj:420)
at swank.swank$connection_serve__365$fn__397.doInvoke(swank.clj:26)
at clojure.lang.RestFn.invoke(RestFn.java:402)
at clojure.lang.AFn.run(AFn.java:37)
... 1 more

(I hope, google-group-posting will not mess with the pasted code, I
can see no preview-button on the posting-page)

And sending a SIGQUIT to the java-process shows that at least the
"Swank Control Thread" died (I think some other swank-threads, too).

What's most annoying is that I have not yet found a way to debug this
without restarting the JVM every few minutes.  Still working on
this...

If anyone can give me a pointer where to look next, the help will be
highly appreciated.

Kind regards,
Stefan

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

No names with trailing % allowed but with a leading one?

[Stefan Kamphausen]

Hi,

during some examinations about the broken REPL with current Slime I
found that I can't create names with a trailing %:

Clojure 1.1.0-alpha-SNAPSHOT
user=> (def %thisworks 11)
#'user/%thisworks
user=> %thisworks
11
user=> (def %thisdoesnt% 22)
java.lang.Exception: Too many arguments to def (NO_SOURCE_FILE:3)
user=>

According to http://clojure.org/reader : "Symbols begin with a non-
numeric character and can contain alphanumeric characters and *, +, !,
-, _, and ? (other characters will be allowed eventually, but not all
macro characters have been determined)"

So, am I right, that "non-numeric character" for the first char
includes the percent-sign whereas the explicit list for all following
characters doesn't.

Rather peculiar, I think.  Not?

Kind regards,
Stefan

PS: The background of this is, that Slime is sending a "%CURSOR-MARKER
%" down the line.

-- 
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: No names with trailing % allowed but with a leading one?

[Stefan Kamphausen]

Hi,

On Nov 17, 8:12 pm, John Harrop  wrote:
> On Tue, Nov 17, 2009 at 1:46 PM, Sean Devlin wrote:
>
> > I *THINK* what is meant by the "non-numeric" is anything that matches
>
> > #"[a-zA-z]"
>
> Nah, it'll be anything that's allowed elsewhere AND is not a digit.

Does that mean, the % as the first char should not be allowed, whereas
at it is in the Version I use (did that change in branch new, BTW?).

And, wouldn't it be nice to get a clearer error-message? :-)

Best regards,
Stefan

-- 
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: SLIME REPL broken

[Stefan Kamphausen]

Hi,

On Nov 17, 1:47 pm, Stefan Kamphausen  wrote:

[...]
> user=> user=> Connection opened on local port  37693
> # [addr=0.0.0.0/0.0.0.0,port=0,localport=37693]>
> user=> user=> java.lang.InterruptedException
> [...]
>        at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.NullPointerException
> [...]

> And sending a SIGQUIT to the java-process shows that at least the
> "Swank Control Thread" died (I think some other swank-threads, too).

By now, I think the NPE is the thread that was killed.  Actually I
have made some progress in gettings things into a working state again,
but that would need some changes on the Slime-side.  So I asked over
there:

http://article.gmane.org/gmane.lisp.slime.devel/9197

Kind regards,
Stefan

-- 
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: No names with trailing % allowed but with a leading one?

[Stefan Kamphausen]

Hi John,

On Nov 17, 8:40 pm, John Harrop  wrote:
> The docs say that letters and *, +, !, -, _, and ? should work anywhere,

do you read it that way?  I think the doc (if you are referring to
http://clojure.org/reader) are a little vague here: "Symbols begin
with a non-numeric character".

> and
> letters, numbers, and  *, +, !, -, _, and ? elsewhere than the first
> character, while making no guarantees about most other characters

I understood that other characters weren't allowed at all.  So I
wondered that I could create a variable-name starting with a %.  But
the vagueness about the first char jumped right in, since it allows
the % there.

But then, it just feels like an accident and not like purpose, so I
thought, I'd better ask.

>> And, wouldn't it be nice to get a clearer error-message? :-)
>
> Wouldn't it always?

Sure, that's the reason for that :-) up there.

Best regards,
Stefan

-- 
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: roll call of production use?

[Stefan Kamphausen]

Hi,

we replaced a command line interface for an internal, mission-critical
application with a custom Clojure-REPL.  It is used for administrative
tasks as well as testing.

Cheers,
Stefan

-- 
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: Functions and vars and meta-data

[Stefan Kamphausen]

Hi Alex,

first of all thank your this exhaustive explanation.

I still don't get some things, though, and kindly ask for more
enlightenment.

On Nov 8, 3:46 am, Alex Osborne  wrote:
> So after resolving, it then has a Var object.  A Var, is as it's
> name suggests, a variable.  It consist of a name (symbol+ 
> namespace),metadatamap and a value (called the binding).

As far as the documentation says, Vars can't have metadata:

"Symbols and collections support metadata," -- http://clojure.org/metadata

"Symbols, Lists, Vector, Sets and Maps can have metadata" --
http://clojure.org/reader

I tried to understand the Java implementation underneath which seems
to be in line with the documentation.  E.g. a symbol extends AFn,
which extents Obj which implements IObj, which in turn extends IMeta
which seems to be the relevant implementation of the metadata
interface.

However, there is some metadata code in Var.java which indicates that
Vars *can* have metadata, but according to documentation they can't.

An example also seems to indicate that Vars can have metadata:

user=> (def #^{:hasmeta "yes"} my-var [1 2 3])
#'user/my-var
user=> (meta my-var)
nil
user=> (meta (var my-var))
{:ns #, :name my-var,
  :file "NO_SOURCE_PATH", :line 63, :hasmeta "yes"}


> Now formetadata"on" functoins.  When you write this:
>
> (defn #^{:xxx 1} greet [] "hello")
>
> The #^{...} syntax means that Clojure creates a list of two symbols
> (defn and greet), and empty vector and a string "hello".  The second symbol 
> greet has
> the metadata{:xxx 1} associated with it.

Really? Then why the metadata of the symbol empty?
user=> (meta 'greet)
nil

Or am I not accessing the symbol's metadata that way?

This question is also related to the following part of your
explanation.

> The greet symbol still keeps it's metadata.  Now the def special form:
>
> 1. Creates a var.
> 2. Copies the metadata{:xxx 1} from the symbol greet to the var.
> 3. Binds the var to the function (fn ([] "hello")).
> 4. Creates a mapping in the current namespace ("user") from the symbol
> greet to the var.

All items agreed, except for 2. which I don't grok yet.


I think for me it boils down to

* Is the documentation wrong or my understanding of it?
* What part of the (Java)-code should I read to understand the
implementation of metadata (if I assume that my understanding of how
the classes extent/implement is not correct).

The reason for asking this is, that I *really* want to understand what
I am talking about.

Kind regards,
Stefan

-- 
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: Functions and vars and meta-data

[Stefan Kamphausen]

Hi,

that have been some really embarrassing typos in my post (typing too
fast in too stupid an interface, I think).

On Nov 27, 12:52 pm, "Alex Osborne"  wrote:
> Stefan Kamphausen  writes:
> > On Nov 8, 3:46 am, Alex Osborne  wrote:
> > As far as the documentation says, Vars can't have metadata:
>
> > "Symbols and collections support metadata," --http://clojure.org/metadata
>
> > "Symbols, Lists, Vector, Sets and Maps can have metadata" --
> >http://clojure.org/reader
>
> I don't think the documentation is *wrong* per se, it just only seems to
> cover the immutable types.

Which is kind of wrong, isn't it?  I strongly believe that this should
be changed.

>  Vars, refs, atoms, agents and namespaces can
> all have metadata as well, but it works a little differently for them as they
> are mutable.  You change their metadata using the alter-meta!
> function.  The with-meta function will not work on them.

While I understand that the mutating functions will not apply to
immutable types, I don't get why I can't create the metadata using the
same interface.

> > Really? Then why the metadata of the symbol empty?
> > user=> (meta 'greet)
> > nil
>
> > Or am I not accessing the symbol's metadata that way?
>
> You are creating a new symbol 'greet,

A *new* symbol?   I would have thought I'm getting the original symbol
again.
OK, but I see:

user=> (resolve 'greet)
#'user/greet
user=> (meta (resolve 'greet))
{:ns #, :name greet,
  :file "NO_SOURCE_PATH", :line 66, :arglists ([]), :xxx 1}

Sometimes the 'E' in 'REPL' stands for Enlightenment, and the 'P' must
be Pleasure then.  Don't ask me about 'R' and 'L', though. ;-)

> It might make more sense if we consider the case of metadata on
> collections.

I think I already understood them.  At least I can align things I read
in documentation and implementation with what I find in experiments on
the REPL.

> Note that (perhaps suprisingly) this doesn't work:
>
>   (meta #^{:a 1} 'greet) ; => {:a 1}
>
> Why?  Well because #^ attaches the metadata to the next read form.
> What's the next read form?  It's 'greet.  But in fact 'greet is just
> sugar for (quote greet).  So we're actually affixing the metadata to a
> list containing two symbols (quote and greet).  When the compiler
> evaluates (quote greet) it turns it into just the symbol greet and then
> throws the list (and thus our metadata) away.

This is subtle!  It really feels like one of those things that will
still feel creepy another 50 years from now.
I'll have to meditate on this a bit.

> > * What part of the (Java)-code should I read to understand the
> > implementation of metadata (if I assume that my understanding of how
> > the classes extent/implement is not correct).
>
> I think you are just being confused by the differences in how metadata
> works with mutable and immutable types.

Definitely, and I don't like the distinction too much either.

> There are three interfaces to do with metadata:
>
> IMeta.java       meta -- reading metadata
> IObj.java        with-meta -- "changing" metadata on immutables
> IReference.java  alter-meta! reset-meta! -- changing metadata on mutables

OK, I see.  I missed the last one.

> I hope that helps clarify things a bit.

It does.  I get a growing feeling of understanding how things work
under the hood here.

Your help is highly appreciated, thank you very much.

Regards,
Stefan

-- 
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: Functions and vars and meta-data

[Stefan Kamphausen]

Hi,

On Nov 27, 11:06 pm, "Alex Osborne"  wrote:
> > A *new* symbol?   I would have thought I'm getting the original symbol
> > again.
>
> Yes, one of the differences between symbols and keywords is that symbols
> are created fresh each time while keywords are interned:
>
> (identical? 'foo 'foo) ; => false
> (identical? :foo :foo) ; => true

Whoa!  Cool example.  This is rather an important point, I think.  I
mean it's not important, when your "only" programming with Clojure,
which will usally work, and you always have the REPL...  But it
becomes more important for those, trying to understand.  It's about
grokking a language's design vs. experimenting with the code long
enough so that it seems to work.

> >> Note that (perhaps suprisingly) this doesn't work:
>
> >> (meta #^{:a 1} 'greet)
>
> Perhaps I should also note that this *does* work:
>
>   (meta '#^{a 1} greet)

To be honest, I think it looks even worse.  There is some reader macro
which by happy accident works in a certain way together with the other
read syntax.  No, I don't think it should work.

> Clojure is a very opinionated language and one of those opinions is that
> Rich tries very hard to avoid incidental complexity.

Which is a Good Idea(tm).

> At times this
> means things may at first appear more complex on the surface than in
> other languages, but this is because Clojure isn't trying to hide what's
> going on under the hood from you. It's one of the things I really enjoy
> about it: there's no "magic".  Clojure simplicity is real simplicity,
> not apparent simplicity created by hiding the complexity under the bed.

Hm, is it possible you're coming from Java here?  For me, coming more
from CL than Java, some things in Clojure feel very --let's say--
Perlish: there is so much syntax there.  Don't get me wrong, I think
Clojure delivers what arc promised, it does a hell of a job
revolutionizing Lisp.  I hardly can disagree with many of the design
principles, I just like the documentation to tell the whole story so
not everyone new to Clojure will have to figure it out for him/
herself.

> It's possible and perhaps should even be expected for most Clojure
> programmers to have a good understanding of how things work underneath.

Agreed.  The docs should say so, agreed?  I'd very much like to
volunteer on docs, but I just don't know how I could keep up with
development, since I am doing almost all my Clojure stuff after work
when the children are in bed.

> With other languages, even if I've been using them for years I still
> have little clue about how things actually get evaluated.

That may be related to the lesser importance of order of evaluation in
other languages.  I mean, Perl has a *lot* of syntax, but usually it
all takes place at the same time, or at least, you as a developer
won't have to care.  Anyway, not worth a discussion.

> As Meikel suggested, watch Rich's talks.

I do, and I really like them.  One can hear, that Rich's got a story
to tell.  They are very valuable for understanding the philosophy
behind many of Clojure's design decisions.  The screencast/
presentation/video-thing helps learning a new language nowadays.

>  I think it's important to try to understand the philosophy behind Clojure's 
> design.

Wait, I've heard that before... Deja vu?

> Rich has some
> very strong messages and even if you don't agree with them, they're
> definitely worth listening to and thinking about.

There, another Deja vu. ;-)


Alex, John, Meikel, Richard,
thanks for taking your time.

Kind regards,
Stefan

-- 
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: One benefit of having a REPL

[Stefan Kamphausen]

Hi,

On Nov 28, 2:20 pm, John Harrop  wrote:
> One benefit of having a REPL: it makes regular expressions usable. So easy
> to test and tweak your RE compared to the traditional compile/test/debug
> cycle! I never even bothered with the java.util.regex package before Clojure
> as it was too painful to use.

I wonder how hard it would be in Clojure to implement something like
Edi Weitz' RegexpCoach
http://weitz.de/regex-coach/.  I know Perl programmer who regularly
create their (un)regular expressions with the help of that
software. ;-)

Cheers,
Stefan

-- 
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: One benefit of having a REPL

[Stefan Kamphausen]

Hi,

On 28 Nov., 17:32, Nathan Hawkins  wrote:
> Stefan Kamphausen wrote:
> > I wonder how hard it would be in Clojure to implement something like
> > Edi Weitz' RegexpCoach
> >http://weitz.de/regex-coach/.  I know Perl programmer who regularly
> > create their (un)regular expressions with the help of that
> > software. ;-)
>
> Really? Why would they need to do that? I always just used the perl
> REPL, perl -d.

Because the RECoach works with immediate feedback while your typing
the regexp. (At least I seem to remember it like that; I didn't really
use it.)

Anyway, a little off-topic, probably.

Regards,
Stefan

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

What about contains? for lists

[Stefan Kamphausen]

Hi,

while studying the collection types and trying to find out which
functions work on all collection types (i.e. lists, vectors, maps,
sets) I was flabbergasted by the following

user> (contains? (list 1 2 3) 3)
false

OK, the doc of contains? told me that for indexed collection-types it
will only check, whether the index is within the valid range.  So
maybe:

user> (contains? (list 1 2 3) 1)
false

At that point I dived into the implementation and found that in
RT.java checks for the type of collection passed but leaves out
PersistenList.

I'd like to understand the (probably well-grounded) reason for that.
As far as I can see PersistentList extends Counted, so the check for
the index-range should at least be possible.  However, I think people
would expect an equality check in the background, which OTOH would be O
(N), probably.

Kind regards,
Stefan

-- 
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: What about contains? for lists

[Stefan Kamphausen]

Hi,

On Dec 2, 9:06 pm, ataggart  wrote:
> > I'd like to understand the (probably well-grounded) reason for that.
> > As far as I can see PersistentList extends Counted, so the check for
> > the index-range should at least be possible.  However, I think people
> > would expect an equality check in the background, which OTOH would be O
> > (N), probably.
>
> > Kind regards,
> > Stefan
>
> That's because contains? checks for keys not values.  Since a list
> isn't associative (unlike vectors and maps), it doesn't have keys,

but at least the position within the list could be interpreted as the
key, although I personally would prefer if the
items themselves would count as keys.

> thus contains? doesn't apply.

But the implementation takes special care even of strings and arrays.
>From the website I got the impression that lists would be a collection-
type ("Lists are collections."), and the arglist of contains? says it
expects a coll.

>  I too was first thrown off by assuming
> contains? worked on the values of a collection;

So, that makes two already ;-)


Please don't get me wrong.  No criticism here about doc-code-
differences or about the decision to not support lists in contains?.
I'm just asking for the reason.

Kind regards,
Stefan

-- 
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: What about contains? for lists

[Stefan Kamphausen]

Hi,


On Dec 2, 10:24 pm, ataggart  wrote:
> My guess is that String and array, while not implementing the
> IAssociative interface, all have the O(1) lookup performance
> guarantees of associative data structures,

um, no?  According to the bit-partition implementation of vector and
the slightly more complex implementation of maps they are O(log_{32}
(N)), which of course given the size of Integer doesn't get too
large.  So I wouldn't think, the Big-O was the reason.

But lists, as others, have O(1) lookup for count, so at least the
index-based contains? which is used for vectors, Strings and arrays
should be usable.  Actually it may be usable for every class extending
Counted.

Best regards,
Stefan

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

Article in German Linux Magazin

[Stefan Kamphausen]

Hi,

having received the blessings of #clojure (kind of) I'll be bold
enough to post a link to an article on Clojure that was published
today.

http://www.linux-magazin.de/Heft-Abo/Ausgaben/2010/01/Nebenlaeufig

Please note, that as of today you can also buy that fine magazine in
print.  ;-)

Hopefully I got everything correct and the article provides a useful
introduction to the language (whatever is possible on just four
pages).  Uhm, I think, I should add that I wrote it.  Criticism
welcome.

Kind regards,
Stefan

-- 
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: Minimum value in a vector

[Stefan Kamphausen]

Hi,

On Dec 2, 11:43 pm, Don  wrote:
> I am having difficulty approaching this problem.  I'm not sure if it
> can be done in one swoop, or requires a few steps.
>
> I have 5 vectors as such:
>
> a [2 4 6 7]
> b [1 3 9 2]
> c [2 4 5 6]
> d [6 1 3 8]
> e [4 8 2 1]
> And I want to take the minimum value at a given index between the
> vectors.  Therefore, minimum value at index 0 would yield the value 1
> from vector b.
>

a quick shot would be

(reduce min (map #(get % 0) (list a b c d e)))

It would be nicer to have a vector of vectors or a list of vectors at
the beginning, probably.

Cheers,
Stefan

-- 
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: Parenthesis Inference

[Stefan Kamphausen]

Hi,

On 18 Dez., 20:07, Martin Coxall  wrote:
> One of the things that always puts people off of Lisp, as we all know, are 
> the parentheses.

one of the things that always put Lispers off is this same question.

I have three arguments to make.  Love, reason and trust.

* Love. Parentheses are an advantage, you will learn to love them if
you start some serious hacking.
* Reason. They could have been taken away in more than 50 years of
history.  Guess what, they are still there.  If I came to lisp as a
newbie, I would think that there must be some reason.
* Trust. Just trust all the people telling you over and over again for
ages, just trust all the fine software engineers who kept them in
place for a very long time.


Stefan

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

let-binding overrides binding-binding

[Stefan Kamphausen]

Hi,

just found that a binding-form within a let-form does still use the
outer value.

user> (def *val* "root binding")
#'user/*val*
user> (defn print-val [] (println "*val* is: " *val*))
#'user/print-val
user> (defn let-vs-binding []
(println "beginning: " *val*)
(let [*val* "bound by let"]
  (println "in LET: " *val*)
  (print-val)
  (binding [*val* "bound by BINDING"]
(println "in BINDING: " *val*)
(print-val
#'user/let-vs-binding
user> (let-vs-binding)
beginning:  root binding
in LET:  bound by let
*val* is:  root binding
in BINDING:  bound by let
*val* is:  bound by BINDING

As far as I can see this is the documented behavior.  The rules for
resolving a symbol described in http://clojure.org/evaluation seem to
be the relevant part.

Two questions

1. Is my explanation correct?
2. Is this the desired behavior or will it change in the near future?

Kind regards,
Stefan

-- 
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: Parenthesis Inference

[Stefan Kamphausen]

Hi,

On 20 Dez., 18:41, Martin Coxall  wrote:
> On 20/12/2009 5:39 PM, Richard Newman wrote:
>
> >> It's better if we can support both. It's never one size fits all.
>
> > Who is "we"?
>
> > If you're talking about something *you* want, you can go build it
>
> I see Clojure is well on the way to building a community at least as
> repellingly exclusionary as all the other Lisps nobody uses.

can't you understand the reactions?  The Lisp-people have been through
this discussion for what? 20 years, 30 years, 40 years?  And it comes
up in intervalls which feel like once a month (don't nail me down on
the numbers).  Go to comp.lang.lisp and do a search for it.  Really.
There is nothing new to this discussion in this thread compared to all
the others.

There are many other things to criticize in Common Lisp with good
cause, and Clojure does a hell of a job cleaning many of those.  Let's
just be happy with that.

This is my second and definetely my last post to this thread and
hopefully to this topic in general.  I only participated because I
thought we need to go this once for Clojure, too.

Kind regards,
Stefan

-- 
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: Recommendation for Clojure Indentation tool

[Stefan Kamphausen]

Hi,

On Dec 22, 11:48 am, Gabi  wrote:
> I need a simple command-line tool to indent Clojure source files.
> Any recommendation ?

there was a post to a ruby script for some OSX editor which provided
the Clojure indentation by calling emacs in batch-mode.  Unfortunately
I can't find it anymore.  Sorry.  Anyone else remember?

Regards,
Stefan

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

Re: Clojure/SLIME/Emacs questions

[Stefan Kamphausen]

Hi,

do you use a rather recent checkout of SLIME?  If so, you may want to
read the thread 
http://groups.google.com/group/clojure/browse_frm/thread/3e5f416e3f2a1884/337057edae5dcdc3

Can't say whether that's related to your problem, though.

Cheers,
Stefan

-- 
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: Proposal: clojure.io

[Stefan Kamphausen]

Hi,


On Jan 1, 3:58 am, Phil Hagelberg  wrote:
> I've been looking over our use of contrib in our large-ish project
> at work. About 90% of the invocations of contrib functions are
> I/O-related.

evil mutable little bastards, these files ;-)

> I wonder if it would be a good idea to include a clojure.io
> namespace in Clojure itself.

inc

> I've prototyped this in the attached file. Most of the functions come
> from contrib's duck-streams library. I've taken everything from
> duck-streams except read-lines, file-str, make-parents, and pwd.
>
> read-lines was left out since ...

Sounds reasonable.

> I welcome discussion about this proposal. Do you think it's
> necessary? Are there any functions we should leave out?
> Any others we should promote from contrib?

I don't know whether it's in contrib already but I'd very much
appreciate a few macros lifting the burden of Java's io-lib with
Reader, BufferedReader, File, PushbackReader, WhateverReader
and ...Writers. Coming from the Lisp world this feels rather ugly to
my fingers.

Kind regards,
Stefan

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

Re: Clojure/SLIME/Emacs questions

[Stefan Kamphausen]

FWIW I have never touched ELPA but got a setup with SLIME from CVS
plus SBCL and Clojure.  A rudimentary description can be found at
http://www.skamphausen.de/cgi-bin/ska/My_Clojure_Setup

The only part that feels tricky is compiling swank for which I needed
a Maven setup, IIRC.

Regards,
Stefan

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

Re: Clojure/SLIME/Emacs questions

[Stefan Kamphausen]

Hi,

On Jan 1, 4:35 pm, Konrad Hinsen  wrote:
> On 01.01.2010, at 12:30, Stefan Kamphausen wrote:
> > The only part that feels tricky is compiling swank for which I needed
> > a Maven setup, IIRC.
>
> I just run swank from source code, uncompiled. No Maven, no worry :-)

I had some errors before compiling and putting the resulting JAR on
the CP.  But I'm not much of a Java-hero.  What is your classpath?  I
have swank-clojure/target/swank-clojure-1.0-SNAPSHOT.jar on it.

Cheers,
Stefan

-- 
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: Release Candidates for clojure-contrib 1.0 and 1.1

[Stefan Kamphausen]

Hi,

On Jan 5, 5:22 pm, Stuart Sierra  wrote:

> For 
> 1.1.0:http://clojure-contrib.googlecode.com/files/clojure-contrib-1.1.0-RC1...

works for me.  Will use it in the following days.  If I stay quiet, it
continues to work :-)

Thanks for providing this.

Regards,
Stefan
-- 
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: Debugging in Clojure

[Stefan Kamphausen]

Hi,

On Jan 22, 2:14 am, ajay gopalakrishnan  wrote:
> I usually debug by adding println statements.

if you use Emacs is this statement is true for other programming
languages, too, you might be interested in using lldebug.  I'm pretty
sure, that when you ask the author to add support for Clojure he will.

See
http://www.cbrunzema.de/download/ll-debug/ll-debug.el

> How can I achieve the same
> effect in Clojure. I don't think I can introduce println at arbitrary places
> to figure out at which step is the algorithm failing.

I'm with you here.  I'm almost sure, I've come across situations in
which *out* must have been bound to something else, if you are using
Emacs/Slime make sure to search the buffer *inferior-lisp* for missing
output.

Coming from Common Lisp and Slime I'm rather used to do all my
debugging in Emacs and Slime, too.  Really.  That stacktrace-explorer
is really good.  However, I think that Rich Hickey thinks the Java
debugging tools should be used with Clojure, too.  No need to code
something like that, right now, Clojure is just too young.  I haven't
tried them yet, but will in the near future.  Probably YourKit.  Maybe
you want to go that way, too?

Kind regards,
Stefan

-- 
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: Suggest slime-redirect-inferior-output be default for Swank clojure

[Stefan Kamphausen]

I haven't checked whether your suggested solution would work, but I'd
be *very* happy to find all stddout-like output from the backend in
the REPL-buffer.

If I may add this: having different threads' output somehow
highlighted, e.g. with colors, would be a killer.  But then the
wishing time has just closed and the next xmas is a good way to go.

Kind regards,
Stefan

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

[ANN] German Clojure Book

[Stefan Kamphausen]

Fellow Clojurians,

please let me announce the writing of another book on Clojure, this
time in German.

So, if you're familiar with that language you might want to read the
tiny webpage at http://www.clojure-buch.de where I'll announce
whatever little news I may have, or the publisher's page at
http://www.dpunkt.de/buecher/3372.html.

With regards to funding Clojure (http://clojure.org/funding) I'm
rather happy to announce that for each copy sold 0.50EUR will go to
Rich Hickey.  I really hope that this will help funding Clojure 2011.

Kind regards,
Stefan Kamphausen

-- 
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: German Clojure Book

[Stefan Kamphausen]

Hi,

> Congratulations! I hope there will be an English translation one day.

probably not.  There is good English material available and even
better coming up.  I don't see how I could produce something better
than Chouser or Stu.

> The book cover is awesome; really like the design and the main font.

You don't know how proud you made me with that remark! It was painted
in 2008 by my daughter who at that time was 5 years old.  The original
is approx 1m in height.  Thank you very much, indeed!

Cheers,
Stefan

-- 
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: German Clojure Book

[Stefan Kamphausen]

Hi,

On Mar 12, 11:11 am, Michael Kohl  wrote:
> Congratulations! If you ever need any German language proof-reading
> let me know,

heh, thanks for the offer.  I think I did things in the wrong order: I
first recruited a team of friendly proof readers and then made the
public announcement later.

However, feel free to contact me via email.

> I worked as a freelance IT journalist for German and
> Austrian publications for 4 years. :-)

OK, I only have three years for the German Linux Magazin up my
sleeve.  You win :-)

Cheers,
Stefan

-- 
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: German Clojure Book

[Stefan Kamphausen]

Stu,

On 12 Mrz., 17:16, Stuart Halloway  wrote:
> Stefan,
>
> That's great news about the book, and kudos on tying it back to  
> funding.

thank you.  I sincerely hope this will really matter.  And I am very
happy that the publishers immediately agreed on this.  Actually I only
pointed them to the article in the group and they came up with the
0,50EUR per book, themselves.

> I hope that everyone who finds commercial success with Clojure will  
> make a small, sustainable funding commitment to help Clojure thrive.

While I don't think that "everyone" will be possible, I really find it
a very *pleasing* thought that my work on what I currently do, will
help this great programming project/language.  If this may serve as a
good example, even better!  Nobody *has* to do this, the license
allows commercial use, and I don't think that this community will
frown upon small businesses making money of Clojure by using it as a
tool or a topic.  But we may make it a success this way.


Kind regards,
Stefan

PS: Hopefully I can some close to the quality, you've done already...

-- 
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: Named arguments in HEAD and prettier default arguments for :keys destructuring

[Stefan Kamphausen]

Hi,

I've no idea whether this is reasonable but when I read your post
suddenly the following thought appeared...

What if defn would accept either a vector for the parameters or a map?

(defn foo {:dont "know" :what "for"}
  ;; ...
 )

I did no deeper thinking on this at all, er, skip the "deeper", I
guess. :-)


Cheers,
Stefan

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

To unsubscribe from this group, send email to 
clojure+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: Can I GPL my Clojure project?

[Stefan Kamphausen]

Hi,

On 28 Mrz., 06:55, Mike Meyer  wrote:

> And to answer the critical question you didn't ask:
>
> 5) Can I distribute a jar file for my Clojure project under the GPL?
>
> No. When you compile your code, code from clojure (and clojure-contrib
> if you use it) will be included in the resulting jar file. In
> particular, any macros you use will expand in place

this is an important hint at how the GPL was crafted with compiled
languages, esp. C, in mind.  The lisp-world has had it's problem with
that.

See, e.g. http://opensource.franz.com/preamble.html and 
http://www.cliki.net/LGPL

It will be interesting how the licenses will be interpreted in Clojure
where Java and Lisp bump together.  The Java-world probably had it's
discussion, too, no?


Cheers,
Stefan

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

To unsubscribe from this group, send email to 
clojure+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: Trying to set emacs for some clojure coding

[Stefan Kamphausen]

Hi,

On 31 Mrz., 13:52, Pelayo Ramón  wrote:

just to add one more to the list...  Note however, that this is what
worked *for me* and it means going against the grain.  So if there is
anything wrong with that setup don't ask the authors of the fine
software used, go and blame me ;-)
Uh, and Clojure 1.1 only.

With that being said, here goes.
http://www.skamphausen.de/cgi-bin/ska/My_Clojure_Setup

> Btw: im using ubuntu 9.10 and emacs23

Same for me...

Cheers,
Stefan

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

To unsubscribe, reply using "remove me" as the subject.

Re: Clojure Added to "Casting SPELs" Site

[Stefan Kamphausen]

Hi,

> http://www.lisperati.com/clojure-spels/casting.html

by sheer accident I found that version just last night.  You should
probably refactor those defs of global vars.  Other than that there
are references to cddr and remove-if-not in the text which do not show
up in the code.

Cheers,
Stefan

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

To unsubscribe, reply using "remove me" as the subject.

Re: Trying to set emacs for some clojure coding

[Stefan Kamphausen]

Hi,

On 31 Mrz., 18:29, Stefan Kamphausen  wrote:
> Hi,
>
> On 31 Mrz., 13:52, Pelayo Ramón  wrote:
>
> just to add one more to the list...  Note however, that this is what
> worked *for me* and it means going against the grain.  So if there is
> anything wrong with that setup don't ask the authors of the fine
> software used, go and blame me ;-)
> Uh, and Clojure 1.1 only.
>
> With that being said, here 
> goes.http://www.skamphausen.de/cgi-bin/ska/My_Clojure_Setup

just for the record: I found today that the docs on my site are not
valid anymore, since the clojure-1.1-branch of swank-clojure is not
available anymore.  The page now says so and I will see whether I can
fix it in due time.

Of course it contains a link to the Getting Started page :-)

Cheers,
Stefan

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

To unsubscribe, reply using "remove me" as the subject.

Re: Error when tried to compile with C-c C-k in emacs.

[Stefan Kamphausen]

Hi,

you're using a rather recent checkout of CVS SLIME.  They added
keyword args to compile-file-for-emacs which is currently not
understood on the clojure swank side.  The quickest way to fix that
would be changing that part of SLIME.  Yes, this is ugly.

It's really a pity that SLIME and clojure/mode/swank move forward so
independently.

In the long run the Clojure community should either create an
"official" fork of SLIME (and try to port the good stuff, that happens
in SLIME) or try to work closer together with the fine SLIME folks.  I
don't think that we should risk losing the Emacs users, because they
may be very happy to find a usable way of leveraging Java's wealth
without having to type Java ;-)  And the frequency of Emacs-setup-
related posts in the near past should tell us that things are not too
well right now.  Ho-humm (or what did the Ents say?)

However, I digress...

Cheers,
Stefan

-- 
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: Error when tried to compile with C-c C-k in emacs.

[Stefan Kamphausen]

Hi,

On Apr 9, 4:56 am, Phil Hagelberg  wrote:
> On Thu, Apr 8, 2010 at 3:32 PM, Stefan Kamphausen
>
>  wrote:
> > In the long run the Clojure community should either create an
> > "official" fork of SLIME (and try to port the good stuff, that happens
> > in SLIME) or try to work closer together with the fine SLIME folks.  I
> > don't think that we should risk losing the Emacs users, because they
> > may be very happy to find a usable way of leveraging Java's wealth
> > without having to type Java ;-)  And the frequency of Emacs-setup-
> > related posts in the near past should tell us that things are not too
> > well right now.
>
> You'll notice 90% of the "I'm having trouble with Emacs" posts have
> one thing in common: they all start with "I'm trying to install
> without ELPA".

I plead guilty.  As Tassilo wrote just recently in one of the other
threads, I am very suspicious towards such magic.  For more than 15
years I either had my distribution take care of libraries or did it
myself.  When XEmacs started creating packages it was one of my
reasons for switching to GNU Emacs.

Using automagic tools is always a nice option for beginners, though.

But then, this is just how I like to handle things.

> I would like to keep swank in line with upstream slime, but it is a
> lot of work. There are just so many more valuable things to work on
> right now... when using an older version of slime is such a
> low-friction solution, it's hard to justify the amount of work it
> would take to bring everything up to date with the latest, especially
> given the fact that slime "doesn't do stable releases". Though Hugo
> has done a fair bit of this work, and I'm grateful for that. If anyone
> else is keen on the latest slime then I'd be glad to get contributions
> from them too.


Of course I see the amount of work, esp. since I am following Slime
development and I know how fast it moves from time to time.

However, since many people like to use HEAD CVS SLIME for developing
Common Lisp (HEAD is often considered the only version working with
latest SBCL) there is a big problem for all people who want to use
Clojure AND CL.  For that scenario a fork of SLIME seems to be the
only usable way, so that you can still use HEAD SLIME for SBCL and
CLOJIME (or whatever ;-) for Clojure.

Or am I mistaken?

Kind regards,
Stefan

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

To unsubscribe, reply using "remove me" as the subject.

Re: Error when tried to compile with C-c C-k in emacs.

[Stefan Kamphausen]

Hi,

> Understood. But I'm not one of those people. I'm lucky if I have a
> couple hours each week to work on this, and that time must be split
> between reviewing incoming contributions *and* writing new code. I
> hope you'll forgive me

whoa, nothing to forgive here.  I am very thankful for the work you
did!

Cheers,
Stefan

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

To unsubscribe, reply using "remove me" as the subject.

Re: seq-contains? in practice

[Stefan Kamphausen]

Hi,

On 29 Apr., 14:10, Stuart Halloway  wrote:
> "In theory, you may be right about 'contains?.' In practice, Rich  
> Hickey is right." - Stu Halloway. :-)

probably a little off-topic, but to me the most irritating thing about
contains? is, that it just returns nil (RT/F, that is) for lists.  The
implementation is full of special cases (Associative, IPersistentSet,
Map, String, Array), but choses to ignore lists.

Cheers,
:ska

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

Clojure 1.2: Readsyntax for meta information

[Stefan Kamphausen]

Hi,

is it correct to assume that the usual read-syntax for 1.2 will be ^
instead of #^?  Will all printers emit that? Will #^ become
deprecated?

Unfortunately I didn't find a enlightening ticket on assembla and no
information on the devel list, just the commit message ("^ does what
#^ does, reader metadata").

Regards,
Stefan

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

Re: Clojure 1.2: Readsyntax for meta information

[Stefan Kamphausen]

Salut,

On 17 Mai, 18:12, Laurent PETIT  wrote:
> 2010/5/17 Meikel Brandmeyer :
>
> > Hi,
>
> > On Mon, May 17, 2010 at 08:21:39AM -0700, Stefan Kamphausen wrote:
>
> >> is it correct to assume that the usual read-syntax for 1.2 will be ^
> >> instead of #^?  Will all printers emit that? Will #^ become
> >> deprecated?
>
> > No. They are not equivalent and ^ is deprecated. #^ will remain doing
> > what it did up to now. ^ will go away w/o replacement.
>
> Sorry to disagree, but the most recent changes I know about it (less
> than one month ago) are (in 1.2):
>
>   * the old behaviour of ^ will not be supported anymore (and users
> will just have to use calls to meta)
>   * and will be replaced by the current behaviour of #^
>   * #^ remains but becomes deprecated

that sounds like a citation.  Is it?  If so, what's the source?  Will
#^ become deprecated in 1.2 or in the following release? And, are
there any plans for the future beyond 1.2++?

Ah, so many questions...

Regards,
Stefan

-- 
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: a default value for get-in?

[Stefan Kamphausen]

Hi,

On May 17, 9:34 pm, braver  wrote:
> If get-in is to be consistent with get, it better allow to specify a
> default value:
>
> (get-in nested-structure [k1 k2 ... kN] :default something)
>
> -- would it make sense to add that to the standard get-in?

while I certainly agree from the users point of view, as an
implementer, I'd hate to break the very nice implementation of get-
in.  One would have to change reduce first. ;-)

Cheers,
stefan

-- 
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: a default value for get-in?

[Stefan Kamphausen]

Hi.

On 19 Mai, 16:20, Meikel Brandmeyer  wrote:
> Hi again,
>
> Oerk. This time hopefully a working version...
>
> (defn get-in
>   ([m ks]
>    (get-in m ks nil))
>   ([m ks not-found]
>    (if-let [[k & ks] (seq ks)]
>      (let [candidate (get m k not-found)]
>        (cond
>          (identical? candidate not-found) not-found
>          ks                               (recur candidate ks not-
> found)
>          :else                            candidate))
>      (throw (Exception. "Empty key sequence")

See?  This is exactly what I meant in my first post :-)

Cheers,
Stefan

-- 
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: promoting contrib.string to clojure, feedback requested

[Stefan Kamphausen]

Hi,

On May 26, 11:00 pm, Stuart Halloway 
wrote:
> The people have spoken! The trims have it!

sorry, I'm a little late.  However, to me it is not clear what the
trim functions shall do.  If they become a replacement for chomp they
are clearly misnamed.  In many applications and languages (like Excel,
several SQL variants, oh, and Java, ...) "trim" means stripping of
whitespace characters, including but not limited to \n and \r.  In
contrast to that chomp stands for the removal of the system-specific
linebreak.

Usually trim-functions accept an optional list of chars to trim.  So
if a trim function would be implemented as a char-remover, defaulting
to whitespace, and chomp would then be equivalent to (trim "foo\n" "\r
\n") -- the second arg should probably something seqable -- everything
seems fine to me.

Just my 2ct
Stefan

-- 
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: promoting contrib.string to clojure, feedback requested

[Stefan Kamphausen]

Hi,

On 27 Mai, 15:35, Michael Gardner  wrote:
> On May 27, 2010, at 2:45 AM, Stefan Kamphausen wrote:
>
> > Hi,
>
> > On May 26, 11:00 pm, Stuart Halloway 
> > wrote:
> >> The people have spoken! The trims have it!
>
> > sorry, I'm a little late.  However, to me it is not clear what the
> > trim functions shall do.  If they become a replacement for chomp they
> > are clearly misnamed.  In many applications and languages (like Excel,
> > several SQL variants, oh, and Java, ...) "trim" means stripping of
> > whitespace characters, including but not limited to \n and \r.  In
> > contrast to that chomp stands for the removal of the system-specific
> > linebreak.
>
> I disagree that "trim" is a misnomer for this function. It may be used as 
> shorthand for "trim whitespace" in some programming languages, but it's not 
> universal even within CS, and it's not what "trim" by itself means in 
> English. And Clojure has already shown that it is willing to break with 
> established terminology in order to Get Things Right.

just a few links

http://en.wikipedia.org/wiki/Trim_%28programming%29
http://en.wikipedia.org/wiki/String_functions_%28programming%29#trim
http://java.sun.com/javase/7/docs/api/java/lang/String.html#trim%28%29
http://php.net/manual/en/function.trim.php

According to the first link in that list, a lot of languages have this
understanding of "trimming" a string.  However, that doesn't have to
be a valid argument.

Oh, and, Clojure: (.trim "   Trim me   ")
(which is really just Java, of course, but I couldn't withstand)

:-)

Cheers,
Stefan

-- 
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: Getting highlighted clojure code into a presentation

[Stefan Kamphausen]

Besides the obvious org-mode which exports with colors to HTML when you use 
"#+BEGIN_SRC clojure ... #+END_SRC" I also had some fun presenting with 
marginalia or impress.js, both using Alex Gorbatchev's Syntax Highlighter. 
(FWIW)

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

Re: ref-history-count always return 0?

[Stefan Kamphausen]

You may want to use the code from https://gist.github.com/Chouser/456326 to 
study how the history in refs works.  See the accompanying discussion at 
http://clojure-log.n01se.net/date/2010-06-28.html.  I've been using 
variants of that stress test to explain the ref history behavior since then 
and people seem to be happy with it.  

Kudos to chouser obviously!

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

Re: parsing xml with zip, xml and clojure.data.zip

[Stefan Kamphausen]

AFAIK your var myxml already refers to the root node of your XML document.  

So your first example searches for a tag called "level1" inside the root 
tag (which is "level1").  Obviously, there is no such node and the text is 
empty.

Your second example extracts a textual representation of the child nodes 
(plural) of tag "level2".

The third example references the tag "level3a" inside the tag "level2" and 
extracts the text, which contains no more child nodes but just the text.

Hope that helps
Stefan

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

Is there an approved way for testing if something is a zipper?

[Stefan Kamphausen]

Hi,


while working on some XML data extraction I got an NPE which boiled down to 
calling some zipper related functions on an empty vector or nil.  

I didn't find a function in clojure.zip, clojure.data.zip or 
clojure.data.zip.xml to test if an object passed to a function is actually 
a zipper.  Am I missing something obvious?  How would you test this?  I 
could try to call clojure.zip/node and catch the exception, but maybe there 
is a better aproach.


Kind regards,
stefan

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

Re: Is there an approved way for testing if something is a zipper?

[Stefan Kamphausen]

Thanks for all your suggestions.  Seems like a useful addition to 
clojure.zip to me.

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

Re: license of Javascript files generated by Clojurescript?

[Stefan Kamphausen]

Hi,

On Wednesday, June 12, 2013 2:29:42 PM UTC+2, David Pollak wrote:
>
> The license of the JavaScript generated by the ClojureScript compiler is 
> the license of the source code that was compiled. And that license may be 
> "my company owns it and it's proprietary and we're not licensing it to 
> anyone else."
>
> Even the FSF does not assert a GPL over code compiled by GCC even though 
> GCC is GPL.
>
>
>
Note, that e.g. code generated by the program wsdl2h which is part of gSOAP 
*is* placed under the GPL and that the FSF wants to allow creation of 
proprietary programs with GCC (see e.g. 
http://www.gnu.org/licenses/gcc-exception-3.1.en.html).

Thus, a word of clarification regarding the intent of the creators of 
ClojureScript might help with the adoption, particularly in larger 
companies.


Kind regards,
Stefan

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

Loosing a space from an XML document

[Stefan Kamphausen]

Hi,


Recently I found myself searching for a white space which got lost 
somewhere between reading an XML file and presenting some results from that 
via a little webapp.  

I think, I could track it down to the following example:

user> (clojure.pprint/pprint 
   (clojure.zip/xml-zip
(clojure.xml/parse 
 (java.io.ByteArrayInputStream. 
  (.getBytes
   "
  
Hello  World
  
  
Hello  dear World
  
  
Hello World
  
")

[{:tag :root,
  :attrs nil,
  :content
  [{:tag :ok,
:attrs nil,
:content
[{:tag :span, :attrs nil, :content ["Hello "]}
 {:tag :span, :attrs nil, :content ["World"]}]}
   {:tag :ok,
:attrs nil,
:content
[{:tag :span, :attrs nil, :content ["Hello "]}
 " dear "
 {:tag :span, :attrs nil, :content ["World"]}]}
   {:tag :wheredidmyspacego,
:attrs nil,
:content
[{:tag :span, :attrs nil, :content ["Hello"]}
 {:tag :span, :attrs nil, :content ["World"]}]}]}
 nil]

Take a look at the last tag "wheredidmyspacego".  The whitespace between 
the span tags gets lost whereas the " dear " in the second example is 
preserved including surrounding spaces.

Is this on purpose and/or expected behavior?


Regards,
Stefan

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

Re: Help deciphering ArityException message

[Stefan Kamphausen]

Just a little hint which may help you in the future.

First, note the trailing $fn in reformat-headers$fn which tells you, that 
your problem is with an anonymous function.

Second, you know that there is a second form for anonymous functions which 
uses fn instead of the reader macro.

Third, fn can take a name for the anonymous function.  That way you get a 
better pointer in your exception, where the problem originated.


Recently, I find myself using the reader macros less, only for functions 
which are basically just one form which are totally self-explanatory.  The 
usage of fn has two advantages: it can be nested and the parameters help 
documenting the expected input.  Using fn with a name yields better 
exceptions plus serves a documentation purpose by naming what should happen.

Just my ct.


Kind regards,
Stefan


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

Re: Clojure: Elegance vs. Performance?

[Stefan Kamphausen]

> The Clojure philosophy is that it is rather irritating to think your 
> recursive call is going to be cleverly optimized into a loop, and then if 
> you're wrong, you have no good way to know that.  So the idea is that you 
> use the word "recur" to indicate that *you* think it can be optimized into 
> a loop, and then the compiler tells you if you are right or wrong.
>

inc 

I like it that way, even if you use the word "recur" and some accumulator. 

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

Re: easier way to write "not not"?

[Stefan Kamphausen]

Just for the record:  I stumbled across the same question just a week ago.

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

Re: Can we please deprecate the :use directive ?

[Stefan Kamphausen]

On Tuesday, July 23, 2013 9:42:39 PM UTC+2, Shantanu Kumar wrote:
>
> One of the main issues I have faced with :use is, understanding a 
> non-trivial codebase becomes very difficult and almost always requires 
> Emacs Meta-dot.


which is particularly annoying when you read code on a blog (as mentioned 
by the OP) or on paper 
 

>
> I'd vote for deprecating :use.
>
> inc

It complects require and refer ;-)

stefan 

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

Re: Can we please deprecate the :use directive ?

[Stefan Kamphausen]

On Tuesday, July 23, 2013 11:13:11 PM UTC+2, Ben wrote:
>
> On Tue, Jul 23, 2013 at 1:55 PM, Sean Corfield 
> 
> > wrote:
>
>> On Tue, Jul 23, 2013 at 1:53 PM, Ben Wolfson > 
>> wrote:
>> > On Tue, Jul 23, 2013 at 1:50 PM, Stefan Kamphausen 
>> > 
>> >
>> > wrote:
>> >> It complects require and refer ;-)
>> > How so?
>>
>> Because use = require + refer (essentially).
>>
>
> If that's all that's required for one thing to complect two others, 
> clojure's rife with the stuff. if-let complects if and let. Destructuring 
> assignment complects assignment and getting values from a data structure 
> (as the macroexpansion of (let [[a b] x]) demonstrates. split-with 
> complects take-while and drop-while. let complects lambda abstraction and 
> function application. Etc. I had assumed that "a complects b and c" on the 
> one hand meant more than "a can be expressed using b and c" and on the 
> other was a criticism.
>


you're right.  I did not think a lot before writing the above.  Please, 
don't take it too seriously.


Kind regards,
Stefan

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

Re: help actually changing :use to :require :refer :all?

[Stefan Kamphausen]

> Would it still bother you if the IDE helped maintain the ns declaration? 
>
>
IMHO, having to rely on my editor or an IDE to manage my code would be a 
language design smell. 

Not that I would mind a little help here and there, though -- e.g. 
indentation, completion and a message if there seem to be imports that are 
not required by the code. :-)

Kind regards,
Stefan

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

Re: Can we please deprecate the :use directive ?

[Stefan Kamphausen]

On Monday, August 5, 2013 2:13:02 PM UTC+2, Mikera wrote:
>
>
> To me the things that make Clojure namespace handling a nightmare for 
> beginners are:
> - Bad error messages (no.1 problem!)
> - Confusion with keywords vs. symbols (why ":use" in ns declarations vs 
> "use" at the repl?)
> - Confusion about quoting and when / where it is needed (again compared 
> with "use" at the REPL)
> - Confusion about when you should use lists vs. vectors vs symbols etc., 
> and how this interacts with the extra magic syntax like ":as"
> - Problems with circular loading of namespaces (and how this affects your 
> code structure)
>

well summarized. 

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

Re: IDE feature

[Stefan Kamphausen]

Just for the record:

I've been coding in Lisp for close to 30 years 
>
>
make that 20 years in my case and I agree with Lee. 

Can't live without C-M-q, TAB, M-left/right, C-M-SPC but paredit is 
interfering too much for /my/ taste.

stefan

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

Re: function creation, partial or #()

[Stefan Kamphausen]

>   (let [params (map (fn [_] (gensym "fnp-")) (range n))]
>


 (repeatedly n #(gensym "fnp-"))

Best,
Stefan

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

Re: function creation, partial or #()

[Stefan Kamphausen]

On Friday, August 16, 2013 9:45:53 AM UTC+2, Antonio Terreno wrote:
>
>
> I much prefer the #(), (fn[]) is longer so it's a no-go ;) 
>
>
>
fn has the huge advantage of taking an (optional) name, which will show up 
in stack traces.

Just my 2ct
Stefan 

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

Re: Can you explain the result of a expression?

[Stefan Kamphausen]

http://stackoverflow.com/questions/12412038/in-clojure-are-lazy-seqs-always-chunked


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

Re: Why STM read are not cached?

[Stefan Kamphausen]

Hi,


It's been quite a while since I last looked into the impl of STM but I seem 
to remember that the committing transaction actively notifies other running 
transactions (see method barge) to restart and thus the restart is not 
triggered by the second deref at all.  

You could also find out by examining the history after your experiment with 
(.getHistoryCount a)


Hope that helps,
stefan

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

Re: calling functions that accepts keyword arguments with a map

[Stefan Kamphausen]

Hi,

On Friday, February 13, 2015 at 8:04:20 PM UTC+1, James Reeves wrote:
>
> A lot of utility libraries, such as my own Medley 
> , have "mapply" functions for this 
> exact use-case.
>
> Generally, however, I find that keyword arguments are more trouble than 
> they're worth. You only save two characters, and give up a lot on terms of 
> being able to easily compose and extend functions.
>

That is correct.

It may be worth noting, that keyword args add some documentation by showing 
in the destructuring expression which keys are to be expected.  Pure maps 
don't give this and the access to the map may be scattered over the 
function body and other functions if you pass the map on.

Of course, you can destructure your map, too.  I just find, that I tend to 
not do this by default when passing maps around.

So maybe my point is: I agree with James, but please destructure your maps 
for the documentation effect. :)


Cheers,
stefan

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

Re: [ANN] CIDER 0.9

[Stefan Kamphausen]

Dear CIDER Devs,


On Tuesday, June 16, 2015 at 4:33:48 PM UTC+2, Bozhidar Batsov wrote:
>
>
> CIDER 0.9 is finally out! You can read more about the release here 
> http://batsov.com/articles/2015/06/16/cider-0-dot-9/
>
>
thanks for the time and effort you've put into this!  Works fine for me.  
Update issues were totally minor so far.  Fixing them probably took less 
time than Eclipse needs to download the update information, let alone 
calculating dependencies. :-P


Cheers,
stefan

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

Re: restarts

[Stefan Kamphausen]

On Thursday, June 19, 2014 11:05:07 PM UTC+2, Thomas Heller wrote:
>
> Excuse my ignorance of not knowing anything about CL and restarts but I 
> needed something like retry a while back.
>
 
Restarts in CL are a different beast.  Take a look at e.g. 
http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html

Best,
stefan

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

Instaparse: Dynamic Grammar With Declarations

[Stefan Kamphausen]

Hi,


first of all, please excuse this cross-post.  I tried to get an answer on 
the instaparse list first, but it does not seem to reach so many instaparse 
users.


Unfortunately I do not know the correct name for the problem I face, hence 
the rather vague subject.

I am trying to parse a file format with Instaparse in which the early parts 
define the stuff allowed later in the file.

E.g. here is a declaration of allowed symbols:

# single chars or strings
symbols: a b c "str"

Later, the file contains declarations of enumerations of the form

enum-name: list of allowed values separated by whitespace

Further down in the file, I will find strings which are comprised of the 
symbols declared above, e.g.

"aabcbc&str;a"

and I will see structures that use the enumerations

StructName(enum-name=separated)

How would you approach this?

* Write a very loose grammar which accepts basically all unicode chars in 
the symbol strings and validate in a separate step?  Similarly accept all 
values in the structures and later validate against the enumerations?
* Two pass parsing which first reads the declarative stuff and then builds 
a second grammar programmatically to parse the rest?
* Is there a way to fill tables of allowed symbols during the parsing?
* Something completely different?

With that question out of the way, thanks for instaparse which is a 
pleasure to use while I am converting my 1400 LOClojureCode hand-rolled 
parser.


Kind regards,
Stefan

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

Re: Instaparse: Dynamic Grammar With Declarations

[Stefan Kamphausen]

For future reference: There was a short discussion on the instaparse list.  

Summary:

* The two approaches outlined earlier are the two possibilities to solve 
the problem at hand.
* Instaparse can take a data structure representation of a grammar 
(combinators) which could be used for the two pass approach (while I 
thought I'd have to create the second grammar with string operations).
* I'll stick to separating parsing and validation for now.

Question answered, case closed, thanks!

Cheers,
stefan

On Wednesday, June 25, 2014 11:31:21 PM UTC+2, Stefan Kamphausen wrote:
>
> Hi,
>
>
> first of all, please excuse this cross-post.  I tried to get an answer on 
> the instaparse list first, but it does not seem to reach so many instaparse 
> users.
>
>
> Unfortunately I do not know the correct name for the problem I face, hence 
> the rather vague subject.
>
> I am trying to parse a file format with Instaparse in which the early 
> parts define the stuff allowed later in the file.
>
> E.g. here is a declaration of allowed symbols:
>
> # single chars or strings
> symbols: a b c "str"
>
> Later, the file contains declarations of enumerations of the form
>
> enum-name: list of allowed values separated by whitespace
>
> Further down in the file, I will find strings which are comprised of the 
> symbols declared above, e.g.
>
> "aabcbc&str;a"
>
> and I will see structures that use the enumerations
>
> StructName(enum-name=separated)
>
> How would you approach this?
>
> * Write a very loose grammar which accepts basically all unicode chars in 
> the symbol strings and validate in a separate step?  Similarly accept all 
> values in the structures and later validate against the enumerations?
> * Two pass parsing which first reads the declarative stuff and then builds 
> a second grammar programmatically to parse the rest?
> * Is there a way to fill tables of allowed symbols during the parsing?
> * Something completely different?
>
> With that question out of the way, thanks for instaparse which is a 
> pleasure to use while I am converting my 1400 LOClojureCode hand-rolled 
> parser.
>
>
> Kind regards,
> Stefan
>

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

Re: When to use ! in function name

[Stefan Kamphausen]

On Thursday, July 10, 2014 5:28:26 PM UTC+2, Cecil Westerhof wrote:
>
> When a function returns a true/false value you should end it with a '?'.
>
> Clojure Programming says that with side effects you should end the 
> function name with a '!'.
>

"Use the bang! only for things not safe in an STM transaction."
-- http://dev.clojure.org/display/community/Library+Coding+Standards

Side-effects are usually a good candidate for this, but not necessarily so.

Best,
stefan

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

Re: When to use ! in function name

[Stefan Kamphausen]

Hi,

On Friday, July 11, 2014 11:10:53 AM UTC+2, Cecil Westerhof wrote:
>
> 2014-07-10 18:34 GMT+02:00 Plínio Balduino  >:
>
>> IMO, ! is used when change any global state. A side effect like print on 
>> screen is not enough to cause a ! in the name. I think that's why the 
>> functions print/println don't have ! =)
>>
>
> ​Than I did it in the 'right' way. In the book the where talking about 
> side-effects, but only a change in global​
>  
> ​ state is more reasonable.​
>

IMHO,  there is a slight difference between "chaning global state" and "can 
not be used in STM".  The STM machinery might call your function several 
times.  If the changes to make to some global state do not matter if being 
called several times, don't use the bang.  One trivial example would be 
counting the collisions in STM which can be a global state change inc'ing 
an atom.  Logging the same action several times could also be desired in an 
STM scenario.

All this is of course only relevant if you stick to the "official" 
guideline I cited earlier.


Best,
stefan

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

Re: When to use ! in function name

[Stefan Kamphausen]

Hi,

On Friday, July 11, 2014 11:33:34 AM UTC+2, Cecil Westerhof wrote:
>
> 2014-07-10 19:10 GMT+02:00 Softaddicts  >:
> ​but as I understood from others it is not about side-effects, but global 
> state. 
>
 
as James and I already pointed out, that is not what it is about.  The bang 
is about interaction with the STM system.  At least this is the library 
coding standard maintained by the Clojure community.


Cheers,
stefan

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

Re: futures and atoms and bears, oh my!

[Stefan Kamphausen]

>
> (defn foo
>   "I don't do a whole lot."
>   [a b]
>   ((let [y (bar(a b))]
> (println a b "Hello, World!"
>
>
Now, *there* are some very suspicious parens around...

1. You're trying to call a as a function
2. Yes, you're calling bar with too few parameters, but how many? One.
3. Finally, after fixing that, you'd try to call nil as a function.  Can 
you see, why?  The '(('.


... just to be nitpicking and slightly off-topic, I know.  Sorry.

Note, that it may be a reasonable fix to your situation to change bar 
instead of foo.  This is possible by evaluating the new definition of bar 
/later/; bar could also be a dynamically bindable Var, so that when 
compiling foo, we do not know how to call bar correctly.  That's the way 
the compiler works.  A linter like eastwood[1] might report this, though.


Kind regards,
stefan

[1] https://github.com/jonase/eastwood

>  

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

Re: CLISP books any good to learn Clojure

[Stefan Kamphausen]

Practical Common Lisp will definitely help understanding Clojure, too.  For 
example, the way, Macros are introduced and used, and understanding generic 
functions.

http://www.gigamonkeys.com/book/

stefan

On Sunday, August 24, 2014 12:49:07 PM UTC+2, Cecil Westerhof wrote:
>
> There are a lot of good (or so I am told) CLISP books. For example: 
> “Paradigms Of Artificial Intelligence Programming Case Studies In Common 
> Lisp”.
>
> Would they be useful for learning Clojure, or is the difference to big?
> I should at least have http://clojure.org/lisps handy. ;-)
>
> -- 
> Cecil Westerhof 
>

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

Re: [ANN] Clojure 1.7.0-alpha2

[Stefan Kamphausen]

On Wednesday, September 10, 2014 10:53:27 PM UTC+2, Alex Miller wrote:
>
> On Wednesday, September 10, 2014 11:05:36 AM UTC-5, puzzler wrote:
>>
>> When I explain to new Clojurists what the ! means, I explain that it 
>> calls attention to a mutation function that is unsafe to call inside a 
>> transaction.  Many programmers coming from Scheme are used to thinking of ! 
>> as meaning *anything* involving mutation, but that's not the case in the 
>> Clojure.  This more subtle distinction (that it needs to be unsafe in a 
>> transaction) clarifies why swap! has an exclamation point, but ref-set does 
>> not, even though both involve mutation.
>>
>
> I do not think there is a hard definition of what ! means as a suffix. 
>

" Use the bang! only for things not safe in an STM transaction."
 -- http://dev.clojure.org/display/community/Library+Coding+Standards

AFAICT, that definition was consistently used in the past in core and I 
used it in workshops, too.

And yes, the same page says "Rules are made to be broken. Know the 
standards, but do not treat them as absolutes."  


Just wanted to add this to the discussion
stefan

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

Re: atom swap! versus ref dosync+alter?

[Stefan Kamphausen]

Hi,

On Tuesday, September 30, 2014 12:01:33 PM UTC+2, Joachim De Beule wrote:
>
> Dear list,
>
> I've got two threads that update the same location. One of them takes a 
> lot of time. Given this, my question is if there is a reason to prefer an 
> atom or a ref? 
>
>
is it really just two threads?  Then the duration does not really matter 
and the slower will obviously commit later.  

I see no reason to use Refs in your example, because you do not change more 
than one in a transaction which is the main difference between Refs and 
Atoms.

Should you have lots of fast threads and one or a few slow threads, you may 
run into problems.  Refs try to adapt to the situation by storing a history 
of values which may lead to the slow transaction finally committing.  You 
can still get an exception from dosync when the transaction tried 10.000 
times to commit and failed (number from the top of my head; may be 
different).

FWIW, I have some code for demonstrating the issues at 
http://clojure-buch.de/listings/concurrency.txt (search for history stress 
test; comments in German because they are from my German clojure book).


Best,
stefan


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

Re: [ANN] Clojure 1.7.0-alpha3 now available

[Stefan Kamphausen]

Hi,

have there been any changes how fns with a name and recursion are 
compiled?  One of my projects has a function which does not compile with 
1.7.0-alpha3 anymore, but did fine with 1.6.0.

I tried to create a minimal example at 
https://github.com/ska2342/nested-fn-breaks-clojure-17

(I know the function itself is probably stupid, I just wanted to 
demonstrate the case.  I don't know if it even runs.)

Compilation breaks with a java.io.IOException: File name too long


The problem seems to be the combination of

* using a long function name (not a bad thing per se),
* using a rather long name for a local binding (not common in Clojure-land, 
used in my case for documentation of the intent of the anon fn),
* and using a name for the anonymous function (needed for recursion and 
usually a good idea because it improves stacktraces, but maybe you added 
the local binding to the name for exactly that reason).

Regarding the second (long var binding name), my original function uses 
shorter names, but has some nested constructs (for, cond, ...) which seem 
to make the name larger, too.  There is really nothing unusually long there.

Of course, I can work around this by using different names, factoring an 
inner anon function out to a defn and probably in other ways.  I just 
wanted to make sure, that you are aware that problems like this may show up 
and made the change on purpose.


Thanks,
stefan

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

Re: Java Listener on Textfield

[Stefan Kamphausen]

Hi,

not directly an answer to your question, but you may be interested in 
Seesaw and it binding facilities.

Unless you are looking for pure Java solutions in which case your posting 
in the wrong group.

Kind regards,
stefan

On Monday, November 3, 2014 1:52:46 PM UTC+1, Azzoug Youcef wrote:
>
>
> Hellow everybody,
>
> Somebody please tell me how to trigger the right Event listener to a text 
> field in java
>
> In the example below all components modify their corresponding panel's 
> background color including the text field
>
> the latter do this streatement by writing the color among five colors,my 
> issue is what is the right listener or adapter to use for it
>
> Thanks in advance
>

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

Re: [ANN] Clojure 1.7.0-alpha4 now available

[Stefan Kamphausen]

Hi,


Thumbs up from my side.  The compilation issues with too long filenames in 
my projects on my system are gone now (CLJ-1330).  No perf degradation 
either :-).


Thanks
Stefan

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

[ANN] Registration and Program For :clojureD

[Stefan Kamphausen]

Hi,


With great pleasure, I'd like to announce the finalization of the program 
and opening of registration for the :clojureD, Germany's Clojure conference 
in Berlin.


The conference:
http://www.clojured.de/
24th Jan 2015 in Berlin
https://twitter.com/clojuredconf  @clojuredconf


The program:
http://www.clojured.de/schedule/


Tickets:
http://www.clojured.de/registration/


Thanks to Stefan Edlich and Nils Blume-Oeste for making all this happen.


Kind regards,
(yet another) Stefan 

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

Creating Hiccup From Code Keeping Formatting and Comments

[Stefan Kamphausen]

Hi,


Currently, I am trying to write a presentation using ring and reveal.js.  
For the code samples, I'd like to write "real" clojure code, i.e. no 
strings or the like.  

Then, I want to turn that into a suitable hiccup vector which will create 
the correct reveal.js/highlight.js syntax.  

I wrote a trvial macro:

(defmacro example [& body]
  `[:pre
[:code ~(apply str body)]])

The problem is, that it looses all formatting, because the Clojure reader 
already had its fun with the code. So,

(example
 "A string literal"
 (defn a-function [x y]
   ;; concat x and y as strings
   (str x y)))

macro-expands to

[:pre [:code "A string literal(defn a-function [x y] (str x y))"]]

which is pretty useless.

I already thought about using &form but this too has been read already.


Any ideas?


Kind regards,
stefan

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

Re: Creating Hiccup From Code Keeping Formatting and Comments

[Stefan Kamphausen]

Hi,


Thanks for your pointers.  That is something to dive into.


Cheers,
stefan

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

[CfP] :clojureD 2017

[Stefan Kamphausen]

Dear Clojure-community,


Please let me bring the current call for proposals for the next iteration 
of the German clojure conference in Berlin, the :clojureD, to your 
attention: 


http://www.clojured.de/call-for-proposals/

We call to send us talks for the upcoming :clojureD conference 2017.

The conference is open for all topics. Our main purpose is to learn more 
about Clojure with basic and advanced topics. All talks will be held in 
English.

We will have two types of talks:

   - Standard Talks (ca. 30 min)
   - Lightning Talks (ca. 6 min)

It would be great if you can activate speakers with many topics! Good 
lightning talks are not much of an effort. Do you know a keynote speaker?

*The CfP ends 31.10.2016!*



The team behind the conference is looking forward to receiving your 
proposals.


Regards,
Stefan

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

Re: [CfP] :clojureD 2017

[Stefan Kamphausen]

Hi,

On Friday, September 16, 2016 at 6:16:14 AM UTC+2, Mars0i wrote:
>
> Glad that this is happening.
> You might want to add the date to the CFP and Schedule pages.  I only 
> found it on the Press page.
>
 
Thanks for your feedback.  I've added the date to the CfP page.  Did you 
look for it on the front page, btw? ;-)

Cheers,
stefan

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

Re: [ANN] permissions - role & permission based access control

[Stefan Kamphausen]

Hi,

Doesn't that feel like premature optimization to you, too?  Bitmasks are 
much harder to read than sets with spelled out roles and I wonder if the 
performance gain is really worth that. And it poses a limit of 64 roles.  I 
have seen several enterprise applications that had far more than 64 roles 
and/or permissions.

Or am I missing something here?

Just my 2ct.

Kind regards,
Stefan

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

[CfP] :clojureD 2018

[Stefan Kamphausen]

Dear Clojure-Community,


The call for proposal for the next :clojureD is open:

http://clojured.de/call-for-proposals/

We'd love to drown in your submissions so that we can deliver a conference 
programme just as excellent as 2017. :-)


Oh, and ticket sale has started, too:

https://www.eventbrite.de/e/clojured-berlin-conference-2018-tickets-37276243247?aff=es2

I heard the early bird tickets are almost sold out.


Kind regards,
Stefan

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

[ANN] clj-queue-by 0.1.1

[Stefan Kamphausen]

Dear Clojurians,


We've released a small queuing library which fills a gap that core.async 
didn't really fill for us.

https://github.com/acrolinx/clj-queue-by

* A central, easy to use, thread-safe, in-memory working queue.
* Easy to inspect to allow monitoring.
* Stateful, not persistent, uses clojure.lang.PersistentQueue internally.
* With a scheduling algorithm that schedules fairly with respect to a key.

Think of several users adding items to the queue where each item has a :user 
field. Using the :user key-fn, *clj-queue-by *allows fair processing of 
events so that each user gets their own queue under the hood. When one user 
floods the system, the others don't have to wait for the bulk of items to 
be processed completely but move forward (almost) to the head of the queue.


Interface is somewhat unusual: The queue is a callable thing (implements 
IFn). With zero args it reads from the queue with one arg, it queues the 
argument.

(require '[com.acrolinx.clj-queue-by :as q]))
;; Create queue
(def queue (q/queue-by :name))

;; Queue an item
(queue {:data "whatever" :name "Alice"})

;; Inspect
(count queue) ;=> 1
@queue ;=> [#<<() {"Alice" #<<({:data "whatever", :name "Alice"})}]

;; Pop an item from the queue
(queue) ;=> {:data "whatever" :name "Alice"}


Also, the name queue-by was still available. :-)


Hope this makes sense and maybe is useful for others, too.


Kind regards,
stefan

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

Re: add-watch and writing data into a core.async channel

[Stefan Kamphausen]

On Friday, July 31, 2015 at 8:21:18 AM UTC+2, Raymond Huang wrote:
>
> I'd like to use `add-watch` on an atom which writes the data to a 
> core.async channel. So far, I've come up with this, but it seems bad 
> because I create a new go-routine everytime something happens.
>
>
Makes me think, one might want to have an add-channel function on ARef in 
general.


stefan
 

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

[ANN] :clojureD Registration Now Open

[Stefan Kamphausen]

Fellow Clojurians,


The team organizing the German Clojure conference :clojureD would like you 
to know, that the registration is now open:

http://www.clojured.de/registration/


Kind regards,
stefan

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

Encapsulating Local Mutable State

[Stefan Kamphausen]

Hi,


Currently, I am in the process of writing a client to server API which is 
not trivial to consume.  In particular it needs a 3-step authentication 
process: login with user name and password, get an authentication token, 
open a session with the token and finally consume the API with the 
session.  Sessions and tokens can expire and the client should handle that 
transparently: if it has a token, create a new session, if the token 
expired and it has username and password, create a new token...  So, 
sessions and tokens would have to be local, mutable, encapsulated state, as 
far as I can see.

Now; I wonder how to best model this in Clojure.

My favorite right now is, creating a closure over a local atom and return 
it to the user.  The downside to this is that it feels unnatural to consume 
different parts of the API, e.g. (client :do-something &args) vs (client 
:do-something-else & other-args).  It would be nice to defined a protocol 
with function do-something and do-something-else but then I would have to 
pass the atom as an argument to the record which feels even worse.

Am I missing an obvious other solution? Have you done something similar, 
how?

Any pointers welcome.


Best regards,
stefan

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

Re: Encapsulating Local Mutable State

[Stefan Kamphausen]

Hi Francis,


Thanks for taking the time to thoroughly explain your approach.  I find it 
interesting and was not yet aware of it.  Need to wrap my head around it a 
bit.


Best,
Stefan

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

Re: Encapsulating Local Mutable State

[Stefan Kamphausen]

Good point, Paul.  Thanks.



Best,
stefan

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

Re: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[Stefan Kamphausen]

hi,

RC1 works well with our largest project.  See a 5-8% slow-down but no other 
problems.

Regards,
Stefan

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

Re: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[Stefan Kamphausen]

Hi Alex,


the runtime of the program changed from 19 to 20 seconds for one set of 
data and from approx 6minutes to 6:30 for another set.  To me that is 
acceptable. 

We are reading a few MB of files into memory, create lots of intermediate 
vectors, maps and sets and output up to a few hundred MB of data later.  
All this with pure Clojure, almost no Interop, no protocols, no records or 
types, just one multimethod which is only used during the first second.

Comparison was done by changing the project.clj to point to the desired 
Clojure version, followed by lein clean && lein uberjar and the running the 
uberjar with a fresh JVM.  All this on a QuadCore with 16GB RAM and OpenJDK 
1.7 on Linux.  We use tools.logging, tools.cli, core.async and log4j and 
AOT compile :all in the uberjar.

If you still consider this a possible breaker (I humbly don't) please let 
me know, what I should test for you.

Kind regards,
stefan


On Wednesday, March 19, 2014 3:21:54 PM UTC+1, Alex Miller wrote:
>
> That is the only set of changes that I know of that negatively affect 
> performance in 1.6.0. However, the absolute differences are quite small and 
> codes are cached. It's hard for me to conjure a scenario where the 
> resulting effect is an overall 5-8% slowdown. If this is one, I'd like to 
> understand it better. 
>
>
> On Wednesday, March 19, 2014 8:28:18 AM UTC-5, Nicola Mometto wrote:
>>
>>
>> I'm guessing it's because of the minor overhead on hashing added with 
>> the move to Murmur3? 
>>
>> Alex Miller writes: 
>>
>> >  what's that about performance now? 
>> > 
>> > Is that something definitive and reproducible? And if so, is there any 
>> way to track down a cause? 
>>
>

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

Re: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[Stefan Kamphausen]

Hi,

On Wednesday, March 19, 2014 3:55:22 PM UTC+1, Michał Marczyk wrote:
>
> Hashes are cached for Clojure collections, keywords and symbols, but 
> not for strings. 
>
> I wonder if people who report these perf regressions use long string 
> keys in their maps... 


As far as I can see, we have /lots/ of strings in sets and lots of strings 
as keys, but they are not particularly /long/ (usually less than 10-15 
Characters).  We have one hot spot in the code, where we create lots 
(hundreds of thousands up to millions) of sets, each containing one to five 
strings.  I will run a few tests and see whether that makes a difference.

Best,
stefan

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

Re: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[Stefan Kamphausen]

On Wednesday, March 19, 2014 4:34:45 PM UTC+1, Alex Miller wrote:
>
> Thanks, this is all really useful. I would appreciate any more detailed 
> info. 
>>
>>
>>
* No atoms, agents, refs
* Almost purely functional plus logging and I/O
* Multi-threaded using latest core.async with thread, no go
* JVisualVM reports top methods in CPU sampling c.l.LazySeq.sval, 
c.c$promise$reify_6310.deref, c.l.LazySeq.seq no notable difference for me 
to see.

A few experiments on two data-sets (dat1 and dat2) using either a call to 
set or to doall:

   Clojure Op Time (dat1) Time (dat1) Average dat1 Time (dat2)  1.5.1 set 
19,1 19 19,05 323  1.5.1 doall 19 19,4 19,2 330  1.6.0-RC1 set 19,5 19,8 
19,65 350  1.6.0-RC1 doall 20,2 19,8 20 351




 

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

Re: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[Stefan Kamphausen]

Hi,


after two days of git bisecting and running my tests over and over again, I 
give up.  While I can repeatedly identify the commit which causes the 
biggest slowdown for me between the 1.5.1 tag and 1.6.0 RC1 I simply refuse 
to believe that the result of my analysis is correct.

On 5045ac124e24ed1fe02be86a10f7f212a4dc everything is fine, on 
96f5b5bdcae44ccc69e33d701e6188dc2570dadf things are slow.  And no, I am not 
running into the exception.

I can only guess that there is some error on my side.  I do not think, the 
slowdown I reported based upon this program should be no reason to delay 
1.6.0. (Even though I'd still like to understand what's going on.)


Best,
stefan

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