improving as-> macro by adding destructuring support

[Nahuel Greco]

The as-> macro doesn't work with destructuring. This is invalid code:


  (-> [1 2]
(as-> [a & b]
  [a (inc b)]
  [(inc a) b]))

Because it is expanded to:


  (let [[a & b] [1 2]
[a & b] [a (inc b)]
[a & b] [(inc a) b]]
   [a & b])  ;; this last expression will not compile

But with a little redefinition is possible to make as-> work with
destructuring:

  (defmacro as->
"Binds name to expr, evaluates the first form in the lexical context
 of that binding, then binds name to that result, repeating for each
 successive form, returning the result of the last form."
{:added "1.5"}
[expr name & forms]
`(let [~name ~expr
   ~@(interleave (repeat name) (butlast forms))]
   ~(last forms)))

Now the previous example will expand to:

  (let [[a & b] [1 2]
[a & b] [a (inc b)]]
   [(inc a) b])

The following example shows why an as-> destructuring compatible
macro can be useful. This code parses a defmulti like parameter list
by reusing a destructuring form:

  (defmacro defmulti2 [mm-name & opts]
   (-> [{} opts]
(as-> [m [e & r :as o]]
  (if (string? e)
[(assoc m :docstring e) r]
[m  o])
  (if (map? e)
[(assoc m :attr-map e :dispatch-fn (first r)) (next r)]
[(assoc m :dispatch-fn e) r])
  ...

Compare with the original defmulti:

  (defmacro defmulti [mm-name & options]
(let [docstring   (if (string? (first options))
(first options)
nil)

  options (if (string? (first options))
(next options)
options)

  m   (if (map? (first options))
(first options)
{})
  options (if (map? (first options))
(next options)
options)

  dispatch-fn (first options)

  options (next options)

  m   (if docstring

(assoc m :doc docstring)
m)

  ...


I added a JIRA issue to report & track this (I think) enhacement:
 http://dev.clojure.org/jira/browse/CLJ-1418

Saludos,
Nahuel Greco.

-- 
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: Immutable or Effectively Immutable?

[Phillip Lord]

Alexandru Nedelcu  writes:
> On Wed, May 7, 2014 at 5:57 PM, Phillip Lord
> wrote:
>
>> In general, though, if I write some code like
>>
>> (if (instance? Cons x)
>> (pass-to-another-thread-without-synchronisation x))
>>
>> I cannot guarantee the result of this because although I know that
>> the head of x is fixed, I cannot guarantee that for the tail. If I know
>> how x is constructed, of course, then I can make this guarantee.
>>
>
> On the other hand, that's not the concern of the piece of code you
> outlined. Because if "x" wasn't constructed properly and the "latest" data
> in it is not visible, there's absolutely nothing you can do about it ;-)
> Visibility is (or should be) the concern of the producer, not of the
> consumer.


Perhaps I didn't word this well. The problem is with my code is that I
only know about the implementation of the head of x. When I talk about
"construction", I mean, "if I know what else is in x". Not clear, sorry!


>
>
>> You get the a related problem in Java.
>>
>> List l = Collections.unmodifiedableList(l);
>>
>> Is l now unmodifiable? Well maybe, depending on what happened to it
>> before.
>>
>
> What happened to it "before" is not relevant, because again, there's
> nothing you can do about it at this point and actually from this consumer's
> perspective "before" doesn't exist ... there's only "now" with the only
> question being if there are or there will be pending changes that may or
> may not be published in the future (where "future" is kind of thread-local).

Again, not great wording. l is unmodifiable if it's not be let out
anywhere. That's the problem. The reason it's related to the issue in
Clojure is that, List is an interface, while Cons is build in terms of
an interface. You cannot define immutability (or unmodifiability) in
terms of an abstract interface.

Java String are immutable. Concrete and final implementation.



> Concurrency is hard, but it's greatly simplified if you keep the concerns
> for atomicity and visibility on the producer's side.

Not going to disagree with this. I just answered the original question
is all:-)

Phil

-- 
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: Rethinking Literate Programming

[Erlis Vidal]

Guys, you really are into the Literate part, those emails are huge! let me
catch up and then I'll reply...

Interesting discussion!


On Thu, May 8, 2014 at 4:59 PM, Mark Engelberg wrote:

> On Thu, May 8, 2014 at 11:02 AM, Mark Engelberg 
> wrote:
>
>> In fact, Clojure has a number of features that actively hurt its
>> expressiveness relative to other modern languages:
>>
>
> BTW, that list was by no means exhaustive.  In the past couple of hours
> I've thought of a couple more, I'm sure others could easily add to the list:
>
> 7. Use of infix notation means that math formulas look dramatically
> different in Clojure than in math form, and therefore, it is difficult to
> determine at a glance whether a formula as implemented in Clojure matches.
> 8. Arrays in many domains are more naturally expressed as 1-based, but in
> Clojure, they are 0-based.  I've encountered a lot of code that was
> confusing because of lots of increments/decrements to shift back and forth
> between the problem as specified with 1-based implementation and the
> 0-based implementation imposed by Clojure.  Lots of opportunities for
> off-by-one errors and/or later confusion when other readers try to make
> sense out of the code.
> 9. Clojure's ease of functional composition can result in deeply nested
> calls that are far easier to write than they are to read.
> 10. Unlike most other languages, every time you give names to local
> variables with let, you add a level of indentation.  Especially with
> alternations of let and if/cond, you can easily end up with "rightward
> drift" that makes code harder to read.
>
> These are things we learn to live with.  If these were show-stoppers, I'd
> be using another language, but they are not, so on balance I prefer Clojure
> with its other many strengths.  My only point is that by no means is
> Clojure a pinnacle of expressiveness where all code is miraculously obvious.
>
> --
> 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.
>

-- 
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: executing conditional if like iif from other languages

[Don Hill]

The multi-if was a typo it should be iif. I know if I am passing in a even 
pairs :then 'dosomething :else 'dosomethingelse works fine with {:keys}. 
What I think I should be doing is somehow grab whats in :then/:else and 
wrap in a (do). At this point I was just wondering how to solve for this 
maybe by parsing what's in each bucket by using :then/:else as delimiters.

Don


On Thursday, May 8, 2014 11:56:20 PM UTC-5, Atamert Ölçgen wrote:
>
>
>
>
> On Fri, May 9, 2014 at 5:44 AM, Don Hill 
> > wrote:
>
>> I am trying to get a couple of edge cases to past and since I am very new 
>> to clojure/lisp (2 days total) I thought I would ask.
>>
>>
>> I am using defmacro like the following. I have 2 edge case which are 
>> failing. I would like to be able to process these cases where there are 
>> extra bits and as you probably guessed the last 2 entries have keys with 
>> not value. I don't thinks the :keys will work for these cases.
>>
>> Any ideas on how I could destruct this so all the cases would pass?
>>
>> (defmacro iif [expr & {:keys [then, else]}] 
>> `(if ~expr ~then ~else))
>>
>> (println(iif (> 3 1))) ;nil
>> (println(iif (> 3 1) :then 'ok)) ;ok
>> (println(iif (< 5 3) :else 'ok)) ;ok
>> (println(iif (> 3 1) :else 'oops)) ;nil
>>
>> (println(iif (> 3 1) :else 'oops :then 'ok));ok
>> ;;(println(iif (> 3 1) :then )) ;nil
>>
>
> Why do you want to support odd number of params after `expr`?
>
> How would you expect this to work:
>
> (iif expr :then :else) -> ???
>
>  
>
>> ;;(println(iif (> 3 1) :else 'oops :then (println'hi) 'ok)) ;;hi ok
>>
>
> I don't know what the implementation of multi-if looks like but the odd 
> number of args after expr doesn't seem right to me.
>
> One last question; why are the branching code named/as a map? Why not 
> (defmacro iif [expr then else]) which is equal to if or course?
>
> (if (> 3 1) nil nil) -> nil
> (if (< 5 3) nil 'ok) -> 'ok
>
> ...and so on.
>
>
>
>  
>
>>
>>  -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Kind Regards,
> Atamert Ölçgen
>
> -+-
> --+
> +++
>
> www.muhuk.com
>  

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

[Erlis Vidal]

In the past I've used a java tool to write "acceptance tests". Concordion [
http://concordion.org/]. The idea is simple yet effective. You write your
documentation in HTML, and later you can run your code that will interact
with that documentation and generate a new documentation, marking the
portions of the text that are implemented and right (in green) vs the
portion that's not yet implemented or failed (in red).

This was an excellent communication tool. We can design the documentation
in a way that the information flows and anyone could understand. I think
the idea could be used in Clojure also, actually I was thinking about this
for a while, it shouldn't be hard to use from clojure, it's a Java tool in
the end.

After reading this discussion I was wondering if a tool like this could be
use to do LP, if not, I would like to know why.

Thanks!





On Fri, May 9, 2014 at 8:59 AM, Erlis Vidal  wrote:

> Guys, you really are into the Literate part, those emails are huge! let me
> catch up and then I'll reply...
>
> Interesting discussion!
>
>
> On Thu, May 8, 2014 at 4:59 PM, Mark Engelberg 
> wrote:
>
>> On Thu, May 8, 2014 at 11:02 AM, Mark Engelberg > > wrote:
>>
>>> In fact, Clojure has a number of features that actively hurt its
>>> expressiveness relative to other modern languages:
>>>
>>
>> BTW, that list was by no means exhaustive.  In the past couple of hours
>> I've thought of a couple more, I'm sure others could easily add to the list:
>>
>> 7. Use of infix notation means that math formulas look dramatically
>> different in Clojure than in math form, and therefore, it is difficult to
>> determine at a glance whether a formula as implemented in Clojure matches.
>> 8. Arrays in many domains are more naturally expressed as 1-based, but in
>> Clojure, they are 0-based.  I've encountered a lot of code that was
>> confusing because of lots of increments/decrements to shift back and forth
>> between the problem as specified with 1-based implementation and the
>> 0-based implementation imposed by Clojure.  Lots of opportunities for
>> off-by-one errors and/or later confusion when other readers try to make
>> sense out of the code.
>> 9. Clojure's ease of functional composition can result in deeply nested
>> calls that are far easier to write than they are to read.
>> 10. Unlike most other languages, every time you give names to local
>> variables with let, you add a level of indentation.  Especially with
>> alternations of let and if/cond, you can easily end up with "rightward
>> drift" that makes code harder to read.
>>
>> These are things we learn to live with.  If these were show-stoppers, I'd
>> be using another language, but they are not, so on balance I prefer Clojure
>> with its other many strengths.  My only point is that by no means is
>> Clojure a pinnacle of expressiveness where all code is miraculously obvious.
>>
>> --
>> 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.
>>
>
>

-- 
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: Rethinking Literate Programming

[Gregg Reynolds]

On Fri, May 9, 2014 at 8:33 AM, Erlis Vidal  wrote:

> In the past I've used a java tool to write "acceptance tests". Concordion [
> http://concordion.org/]. The idea is simple yet effective. You write your
> documentation in HTML, and later you can run your code that will interact
> with that documentation and generate a new documentation, marking the
> portions of the text that are implemented and right (in green) vs the
> portion that's not yet implemented or failed (in red).
>
> This was an excellent communication tool. We can design the documentation
> in a way that the information flows and anyone could understand. I think
> the idea could be used in Clojure also, actually I was thinking about this
> for a while, it shouldn't be hard to use from clojure, it's a Java tool in
> the end.
>
> After reading this discussion I was wondering if a tool like this could be
> use to do LP, if not, I would like to know why.
>

Hi Erlis,

That looks like an excellent tool, thanks for bringing it up!  Years ago,
when I first started dinking around with LP, I wanted to get the good
documentation of LP but without mixing code and documentation in one file
and without reordering; in other words, a way to reliably attach
documentation to code from the outside, keep it up to date, etc.  Something
akin to the way XSLT relates to XML source docs.  I think something like
that is doable, but it's complicated and my initial enthusiasm eventually
petered out.  But it never occurred to me to use tests in this way.  It
looks like a great way to document APIs (internal and external), and I no
reason why it wouldn't work just fine for Clojure.  If not Concordion, it
probably would not be too tremendously difficult to add similar
capabilities to one of the pure Clojure unit test frameworks.

One thing I might change (having spent no more that a few minutes looking
at Concordion) would be to write Condordion specs in XML instead of HTML.
That would make it easier to repurpose the output to PDF, Eclipse
helpfiles, Windows helpfiles, etc. (see
http://dita-ot.github.io/1.8/readme/AvailableTransforms.html for a list of
output formats in active use by tech documentation specialists).  In fact,
now I think of it, it looks like Concordion specification would be a good
candidate for a DITA specialization.

Personally I would not call this LP, just to avoid confusion.  Knuth's
original notion of LP pretty clearly means, among other things, code and
documentation in the same LP source text, and free ordering.  Most other LP
systems that I've looked at follow those norms, so calling something like
Concordian an LP tool would likely lead to gnashing of teeth, not to
mention theological debates about True LP.  I'm not sure what I would call
it, other than a documentation tool.  Maybe live documentation?  Integrated
external documentation?  Test-based documentation?

Thanks,

Gregg

-Gregg

-- 
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: Immutable or Effectively Immutable?

[Mike Fikes]

Thanks Alexandru! That was insightful. :)

Even the JLS's (non-normative?) text is confusing IMHO. Section 17.5 ends 
with this paragraph:

The usage model for final fields is a simple one. Set the final fields for 
an object in that object's constructor. Do not write a reference to the 
object being constructed in a place where another thread can see it before 
the object's constructor is finished. If this is followed, then when the 
object is seen by another thread, that thread will always see the correctly 
constructed version of that object's final fields. *It will also see 
versions of any object or array referenced by those final fields that are 
at least as up-to-date as the final fields are.*

If you read that paragraph, it would lead you to believe the bit in bold 
would be applicable to the program below. It seems that the key is, as you 
pointed out, simply extending the concept of "this escaping" to cover 
mutable references stored during construction.

import java.util.Arrays;

public class Main {

static class Foo {
final byte[] bytes;
Foo(byte[] bytes) {
this.bytes = bytes;
Arrays.fill(this.bytes, (byte) 2);
}
}

static volatile byte[] bytes;
static volatile Foo foo;

public static void main(String[] args) {

new Thread(new Runnable() {
public void run() {
// Create an array filled with 1s and spin for other thread
bytes = new byte[1024*1024];
Arrays.fill(bytes, (byte) 1);
while (foo == null) {}

// Check to see if we get the array contents set by other thread
byte[] expected = new byte[1024*1024];
Arrays.fill(expected, (byte) 2);
boolean match = Arrays.equals(expected, foo.bytes);
System.out.println(match); // Will print false at times
}
}).start();

new Thread(new Runnable() {
public void run() {
// Spin for first thread
while (bytes == null) {}

// Create an "immutable" object using bytes, while mutating 
bytes prior to construction completion and publication
foo = new Foo(bytes);
}
}).start();
}
}


On Thursday, May 8, 2014 4:43:10 PM UTC-4, Alexandru Nedelcu wrote:
>
> On Wed, May 7, 2014 at 6:31 AM, Alex Miller 
> > 
> wrote:
>
> It does matter with regard to visibility across threads - your example 
>> does not use a synchronization mechanism and there is no guarantee that 
>> other threads will ever see those changes (so don't ever ever do that :). 
>> But if you stick to the normal Clojure apis, all is good. I'd highly 
>> recommend reading JCIP to dive into the details. 
>>
>> Final field freeze is particularly weird and it baked my noodle when I 
>> first encountered it - here's a blog I wrote about it approx 697 years ago 
>> in internet time (and Brian Goetz backs me up in the comments :)
>> http://tech.puredanger.com/2008/11/26/jmm-and-final-field-freeze/
>>
>  I believe that while JCIP is useful, it is also confusing, because it is 
> trying to explain Java’s memory model in layman’s terms. I recently 
> experienced “enlightenment”, by making an effort to understand how things 
> work at a lower level. 
>
> Happens-before relationships / ordering guarantees are given by the 
> compiler, in combination with the CPU, with the rules being implied by 
> usage of memory fences (barriers). Without ordering guarantees, several 
> things can happen - the compiler could optimize the code by reordering or 
> eliminating instructions, the CPU might optimize the code by reordering or 
> eliminating instructions and - what bits beginners the most - today’s 
> multi-core CPUs are tricky, as each CPU has a store buffer that’s local to 
> each core (i.e. other cores cannot see it) and published values only become 
> visible to other cores when the store buffer gets flushed to the L1 cache. 
> And you have no guarantee that this flush will *ever* happen, or even 
> after it happens, you have no guarantee that other processors that already 
> have a cached value will make an effort to read the more up-to-date value … 
> unless ordering semantics are enforced. And actually thinking in terms of 
> flushes to memory is dangerous, as nothing you do guarantees a flush - 
> everything being relative, specified in terms of happens-before 
> relationships, implied by memory barriers.
>
> And memory barriers are tricky beasts, as they come in multiple shapes and 
> sizes. The JSR 133 Cookbookis 
> a useful document for shedding some light on how they work. In 
> particular, for final fields, you get a guarantee for a *StoreStore*memory 
> barrier, like so:
>
> x.finalField = v; *StoreStore*; sharedRef = x;
>
> This guarantee basically says that the finalFields’ value will always be 
> s

Re: Rethinking Literate Programming

[Erlis Vidal]

I've always seen this to document what the system does, as a way to gather
requirements. And the name used is similar to what you propose. Live
Specification or Specification by Example among other names.

It never occurred to me that this could be used for API documentation, and
I'm a completely n00b to LP, that's why I asked if we could use something
like that. I see that the definition of LP involve the word "programming"
so basically we have to bind the code with the "literate" part.

Maybe concordion could be a interesting idea to present in the discussion
we have around a new way of documentation for Clojure. It's nice what you
can do with it. We can even use it to document how the future version of
the language is progressing, we can go to the "live" page and see what's
done and what's pending.

I'll see if I find some time to create something in clojure that's
documented using concordion.

Anyway, thanks for the answer and keep up the great work, everyone!


On Fri, May 9, 2014 at 10:17 AM, Gregg Reynolds  wrote:

> On Fri, May 9, 2014 at 8:33 AM, Erlis Vidal  wrote:
>
>> In the past I've used a java tool to write "acceptance tests". Concordion
>> [http://concordion.org/]. The idea is simple yet effective. You write
>> your documentation in HTML, and later you can run your code that will
>> interact with that documentation and generate a new documentation, marking
>> the portions of the text that are implemented and right (in green) vs the
>> portion that's not yet implemented or failed (in red).
>>
>> This was an excellent communication tool. We can design the documentation
>> in a way that the information flows and anyone could understand. I think
>> the idea could be used in Clojure also, actually I was thinking about this
>> for a while, it shouldn't be hard to use from clojure, it's a Java tool in
>> the end.
>>
>> After reading this discussion I was wondering if a tool like this could
>> be use to do LP, if not, I would like to know why.
>>
>
> Hi Erlis,
>
> That looks like an excellent tool, thanks for bringing it up!  Years ago,
> when I first started dinking around with LP, I wanted to get the good
> documentation of LP but without mixing code and documentation in one file
> and without reordering; in other words, a way to reliably attach
> documentation to code from the outside, keep it up to date, etc.  Something
> akin to the way XSLT relates to XML source docs.  I think something like
> that is doable, but it's complicated and my initial enthusiasm eventually
> petered out.  But it never occurred to me to use tests in this way.  It
> looks like a great way to document APIs (internal and external), and I no
> reason why it wouldn't work just fine for Clojure.  If not Concordion, it
> probably would not be too tremendously difficult to add similar
> capabilities to one of the pure Clojure unit test frameworks.
>
> One thing I might change (having spent no more that a few minutes looking
> at Concordion) would be to write Condordion specs in XML instead of HTML.
> That would make it easier to repurpose the output to PDF, Eclipse
> helpfiles, Windows helpfiles, etc. (see
> http://dita-ot.github.io/1.8/readme/AvailableTransforms.html for a list
> of output formats in active use by tech documentation specialists).  In
> fact, now I think of it, it looks like Concordion specification would be a
> good candidate for a DITA specialization.
>
> Personally I would not call this LP, just to avoid confusion.  Knuth's
> original notion of LP pretty clearly means, among other things, code and
> documentation in the same LP source text, and free ordering.  Most other LP
> systems that I've looked at follow those norms, so calling something like
> Concordian an LP tool would likely lead to gnashing of teeth, not to
> mention theological debates about True LP.  I'm not sure what I would call
> it, other than a documentation tool.  Maybe live documentation?  Integrated
> external documentation?  Test-based documentation?
>
> Thanks,
>
> Gregg
>
> -Gregg
>
> --
> 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.
>

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

Re: Rethinking Literate Programming

[Gary Johnson]

puzzler and Tim,

  Well said, gentlemen. As someone who has been using LP heavily for the 
past two years, I have certainly reaped many if not most of the benefits 
regularly argued in its favor (and of course, I've wrestled with all the 
usual tooling issues as well). While I agree with puzzler that many 
programmers probably don't write sufficiently novel software that would 
benefit from an LP style, quite a few of us do. In my case, much of my 
programming is aimed at environmental research, developing models and 
algorithms for describing and predicting natural processes and human 
interactions with them. In order for my work to be accepted and used for 
decision making (usually around land planning), it is absolutely crucial 
that I can transparently explain all the formulas used, literature cited, 
and conceptual steps taken to get from empirically measured data to 
modelled outputs. A literate programming style not only helps me to 
organize my thoughts better (both hierarchically and sequentially), but it 
provides me with a living (tangled) document that I can share with my 
non-programmer colleagues to get their domain-specific feedback about my 
choice of model assumptions, formulas, etc. This enables a level of 
collaboration that I simply could not achieve if I simply wrote the code 
directly. Finally, as a thoroughly unexpected side effect, some of my most 
complicated programs actually became much, much shorter when I rewrote them 
in an LP style (in terms of lines of code, of course). Part of this had to 
do with the available tooling (Org-mode's polyglot literate programming and 
reproducible research facilities are outstanding) and part of it simply 
came from having to write down my ideas in English first. This kept me from 
rushing into writing code and possibly getting lost in those "collapsing 
tunnels" to which Tim alluded. Instead, the additional "hammock time" that 
I took to think my way through how to present my solutions frequently led 
to "Aha!" moments in which I realized a simpler way to express the problem. 
Cliche, I know, but still results are results.

  Get Literate! (use only as necessary; LP may not be recommended for some 
patients due to increased blood pressure and carpal tunnel risk)
~Gary


On Thursday, May 8, 2014 8:57:51 AM UTC-4, Gregg Reynolds wrote:
>
> The thread on documentation that Val started (
> https://groups.google.com/forum/?hl=en#!topic/clojure/oh_bWL9_jI0) is 
> getting a little long so I'm starting a related one specific to litprog.
>
> I've made a start on rethinking LP at 
> https://github.com/mobileink/codegenres/wiki/Rethinking-Literate-Programming
> .
>
> A few key points:
>
> * Knuth's main early LP tool (WEB) was to a certain extent an attempt to 
> fix deficiencies in Pascal, as Knuth himself explicitly acknowledged.  Some 
> aspects of Knuthian LP (KLP) may make sense for imperative languages with 
> side effects; since it's hard to reason about programs written in such 
> languages, added commentary is needed.  But if you already know that 
> functions are side-effect free and data are immutable, you no longer need 
> that.  
> * Programming language design has not evolved in the direction of LP, as 
> we might have expected from some of Knuth's more grandiose pronouncements; 
> instead they have evolved in the direction of greater expressivity, which 
> obviates the need for many kinds of documentation.  You can argue that LP 
> was a fine thing in its day, but the world has moved on.
> * KLP is largely based on the personal aesthetic and psychological 
> preferences of DE Knuth involving issues such as the proper order and mode 
> of presentation of code.  Those are normative issues, and there is no 
> reason to take Knuth's preferences as gospel.  In particular there is no 
> justification for his claim that using LP "methods" leads to "better" 
> code.  It not only depends on what "better" means, it depends on what other 
> methods are available.  Just because writing Pascal in LP was better (for 
> Knuth et al.) than writing plain Pascal does not mean this will always be 
> the case in all languages.  It doesn't generalize.  (To a hammer, 
> everything looks like a goto.)
> * There is (demonstrably) no reason to think that there is any "natural" 
> or "best" order of presentation for code; there are only preferences, and 
> everybody has one, if you catch my drift.  The point again being that Knuth 
> was not on to some kind of laws of programming.  KLP is all about his 
> preferred style, not about the Way Things Are.  
> * KLP is sometimes contrasted with "self-documenting code" To get a grip 
> on what that is and what we can expect from it we need to examine the 
> notions of function, algorithm, and code.  Then it looks like code does not 
> in fact "self-document", if "documentation" is taken to mean explanation.  
> But it does express meaning, and sometimes expressivity is preferrable to 
> explanation.  Maybe that's t

Re: Rethinking Literate Programming

[u1204]

With respect to "documentation" of open source software...

"You keep using that word. I don't think it means what you think it
means." -- "The Princess Bride"

The notion that "reading the code" is the ultimate truth for
"documentation" is based on a misunderstanding at so many levels it is
hard to explain. In fact, most of the ideas don't begin to cover
"documenting the system". Fortunately, Robert Lefkowitz absolutely
illuminates the scope of the problem in these delightful talks.

For those who have not heard it, this is truly a treat.
For those who "document" this is a must-hear.

Robert Lefkowitz -- The Semasiology of Open Source
http://web.archive.org/web/20130729214526id_/http://itc.conversationsnetwork.org/shows/detail169.html
http://web.archive.org/web/20130729210039id_/http://itc.conversationsnetwork.org/shows/detail662.html

Tim Daly

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

count not supported on this type

[Roelof Wobben]

I try to make this assigment : 

Write the function (contains-duplicates? sequence) that takes a sequence as 
a parameter and returns true if sequence contains some element multiple 
times. Otherwise it returns false.

So I did this : 

(defn contains-duplicates? [a-seq]
  (let [element (fn element [a-seq] (count a-seq) )]
 (= (map element a-seq)1)))

But then I see this message : UnsupportedOperationException count not 
supported on this type: Long  clojure.lang.RT.countFrom (RT.java:556)

When I change map to apply I see this message : ArityException Wrong number 
of args (5) passed to: structured-data$contains-duplicates-QMARK-$element  
clojure.lang.AFn.throwArity (AFn.java:437)

Where did I misunderstood this page : 
http://iloveponies.github.io/120-hour-epic-sax-marathon/structured-data.html

Roelof

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

Headless server, no GUI, no idea

[stiffyrabbit jr]

Hi,

What should my approach be, if I want my headless server to run a client 
program that uses the client GUI?

How can my server provide the same resources as a local client, to use GUI 
objects?

I have a Clojure program that opens a file dialog on the client.  It works 
fine, until I try to run it from the server.

My setup:

A Macbook Pro with VirtualBox and LightTable on it;
VirtualBox running Ubuntu 14.4, Leiningen, Clojure.  Ubuntu has extension 
pack, in response to this problem;

I start VB - VBoxManage startvm 'Core' --type headless;

I login to Core - ssh Core normally, ssh -v -X Core in desparation;

I launch a repl in a Clojure proj.  I use the host:port details as a LT 
nrepl connection.  I get the following error:



*java.awt.HeadlessException: No X11 DISPLAY variable was set, but this 
program performed an operation which requires it.*I have tried so many 
things to resolve this, that I get lost in it all.

What approach will ensure that my server can run a program that requires 
DISPLAY, and use client GUI objects?

-- 
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] Hermod a core.async message passing library

[Timothy Baldridge]

Although still in pre-1.0, I'm happy enough with a library I've been
working on to make an official release.

Hermod is a network-aware message passing library built on core.async. The
details are best explained by the project's README:

https://github.com/halgari/com.tbaldridge.hermod

There are most likely some bugs still left, but give it a whirl and let me
know what you think.

Thanks,

Timothy Baldridge

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

Must hear...

[daly]

There is a 3rd part to this series. Enjoy...

Robert Lefkowitz -- The Semasiology of Open Source (part 3)

http://daviding.wordpress.com/2007/10/22/robert-lefkowitz-the-semasiology-of-open-source-part-iii-oscon-2007-it-conversations-20060726/

Tim

-- 
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: Headless server, no GUI, no idea

[Stuart Sierra]

This sounds more like a problem with remote access to X-Windows (the Unix 
graphical back-end) than a Clojure-specific problem. You might find some 
helpful answers in Ubuntu docs, forums, or chat rooms.
-S


On Friday, May 9, 2014 6:57:26 AM UTC-4, stiffyrabbit jr wrote:
>
> Hi,
>
> What should my approach be, if I want my headless server to run a client 
> program that uses the client GUI?
>
> How can my server provide the same resources as a local client, to use GUI 
> objects?
>
> I have a Clojure program that opens a file dialog on the client.  It works 
> fine, until I try to run it from the server.
>
> My setup:
>
> A Macbook Pro with VirtualBox and LightTable on it;
> VirtualBox running Ubuntu 14.4, Leiningen, Clojure.  Ubuntu has extension 
> pack, in response to this problem;
>
> I start VB - VBoxManage startvm 'Core' --type headless;
>
> I login to Core - ssh Core normally, ssh -v -X Core in desparation;
>
> I launch a repl in a Clojure proj.  I use the host:port details as a LT 
> nrepl connection.  I get the following error:
>
>
>
> *java.awt.HeadlessException: No X11 DISPLAY variable was set, but this 
> program performed an operation which requires it.*I have tried so many 
> things to resolve this, that I get lost in it all.
>
> What approach will ensure that my server can run a program that requires 
> DISPLAY, and use client GUI objects?
>

-- 
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: Headless server, no GUI, no idea

[Dave Ray]

I'm not exactly clear what you're trying to do, but I had similar problems
with running Seesaw tests on Travis CI. Here's the settings I used to work
around it:

  https://github.com/daveray/seesaw/blob/develop/.travis.yml

Hope this helps,

Dave



On Fri, May 9, 2014 at 10:52 AM, Stuart Sierra
wrote:

> This sounds more like a problem with remote access to X-Windows (the Unix
> graphical back-end) than a Clojure-specific problem. You might find some
> helpful answers in Ubuntu docs, forums, or chat rooms.
> -S
>
>
> On Friday, May 9, 2014 6:57:26 AM UTC-4, stiffyrabbit jr wrote:
>>
>> Hi,
>>
>> What should my approach be, if I want my headless server to run a client
>> program that uses the client GUI?
>>
>> How can my server provide the same resources as a local client, to use
>> GUI objects?
>>
>> I have a Clojure program that opens a file dialog on the client.  It
>> works fine, until I try to run it from the server.
>>
>> My setup:
>>
>> A Macbook Pro with VirtualBox and LightTable on it;
>> VirtualBox running Ubuntu 14.4, Leiningen, Clojure.  Ubuntu has extension
>> pack, in response to this problem;
>>
>> I start VB - VBoxManage startvm 'Core' --type headless;
>>
>> I login to Core - ssh Core normally, ssh -v -X Core in desparation;
>>
>> I launch a repl in a Clojure proj.  I use the host:port details as a LT
>> nrepl connection.  I get the following error:
>>
>>
>>
>> *java.awt.HeadlessException: No X11 DISPLAY variable was set, but this
>> program performed an operation which requires it.*I have tried so many
>> things to resolve this, that I get lost in it all.
>>
>> What approach will ensure that my server can run a program that requires
>> DISPLAY, and use client GUI objects?
>>
>  --
> 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.
>

-- 
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: count not supported on this type

[James Reeves]

Your function is essentially:

(= (map count coll) 1)

So you're applying the function "count" to each element in the collection.
Let's say your collection is:

[1 2 3]

Then you're trying to evaluate:

[(count 1) (count 2) (count 3)]

Clojure is raising an exception that says "I can't count a number, I can
only count collections".

- James


On 9 May 2014 17:42, Roelof Wobben  wrote:

> I try to make this assigment :
>
> Write the function (contains-duplicates? sequence) that takes a sequence
> as a parameter and returns true if sequence contains some element
> multiple times. Otherwise it returns false.
>
> So I did this :
>
> (defn contains-duplicates? [a-seq]
>   (let [element (fn element [a-seq] (count a-seq) )]
>  (= (map element a-seq)1)))
>
> But then I see this message : UnsupportedOperationException count not
> supported on this type: Long  clojure.lang.RT.countFrom (RT.java:556)
>
> When I change map to apply I see this message : ArityException Wrong
> number of args (5) passed to:
> structured-data$contains-duplicates-QMARK-$element
> clojure.lang.AFn.throwArity (AFn.java:437)
>
> Where did I misunderstood this page :
> http://iloveponies.github.io/120-hour-epic-sax-marathon/structured-data.html
>
> Roelof
>
>  --
> 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.
>

-- 
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: count not supported on this type

[Roelof Wobben]

oke, 

Then I have to fnd another way to see how many times a number is present in 
a collection.
I thought count  could do that.

Roelof


Op vrijdag 9 mei 2014 20:24:29 UTC+2 schreef James Reeves:

> Your function is essentially:
>
> (= (map count coll) 1)
>
> So you're applying the function "count" to each element in the collection. 
> Let's say your collection is:
>
> [1 2 3]
>
> Then you're trying to evaluate:
>
> [(count 1) (count 2) (count 3)]
>
> Clojure is raising an exception that says "I can't count a number, I can 
> only count collections".
>
> - James
>
>
> On 9 May 2014 17:42, Roelof Wobben >wrote:
>
>> I try to make this assigment : 
>>
>> Write the function (contains-duplicates? sequence) that takes a sequence 
>> as a parameter and returns true if sequence contains some element 
>> multiple times. Otherwise it returns false.
>>
>> So I did this : 
>>
>> (defn contains-duplicates? [a-seq]
>>   (let [element (fn element [a-seq] (count a-seq) )]
>>  (= (map element a-seq)1)))
>>
>> But then I see this message : UnsupportedOperationException count not 
>> supported on this type: Long  clojure.lang.RT.countFrom (RT.java:556)
>>
>> When I change map to apply I see this message : ArityException Wrong 
>> number of args (5) passed to: 
>> structured-data$contains-duplicates-QMARK-$element  
>> clojure.lang.AFn.throwArity (AFn.java:437)
>>
>> Where did I misunderstood this page : 
>> http://iloveponies.github.io/120-hour-epic-sax-marathon/structured-data.html
>>
>> Roelof
>>
>>  -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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] lein-modules 0.3.1

[Jim Crossley]

I just released version 0.3.1 of lein-modules [1]. I've fixed a lot of 
bugs, added one feature, and slightly changed the behavior since the last 
time I announced a release.

What is it?

It's a Leiningen plugin that lets you treat a set of related projects 
stored in a single SCM repository as an aggregate. Features include 
dependency build order, flexible project inheritance, a simple dependency 
management mechanism, and automatic checkout dependencies.

We use it for Immutant's build [2], and this morning I converted two other 
multi-module projects with which I'm somewhat familiar: Pedestal [3] and 
Ring [4]. I did this mainly to harden lein-modules, just as an exercise to 
expose potential bugs. But those three may serve as examples for your own 
projects if you're interested.

Have fun!
Jim

[1] https://github.com/jcrossley3/lein-modules
[2] https://github.com/immutant/immutant
[3] 
https://github.com/jcrossley3/pedestal/commit/3dabf7190a618885e84b32999bbfd7a031c7dcde
[4] 
https://github.com/jcrossley3/ring/commit/e4d23f7a33cc035d090b028982c8e47c367146b6

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

Using Java's XML Digital Signature API -> Clojure

[Timothy Washington]

Hi all,

I've noticed there's no Clojure library for doing XML Digital signatures.
So I'll probably put one out there, if I can completely solve this problem.
Using Java's *XML Digital Signature API
*,
I'm trying to get the source XML (*fig.1*) to look like a certain output (
*fig.2*). However, I'm getting stuck with another output (*fig.3*).

Now, XML Signatures come in 3 forms i) detached, ii) enveloping and iii)
enveloped. But the XML in *fig.2* has the signature in the Header path
[*soapenv:Envelope
/ soapenv:Header / wsse:Security*]. I imagine that's using XML
Signature's XPath
Reference Processing
Model.
So I mainly want to put the xml Signature in the Header. But there are a
lot of other things that need to get ironed out, in order to arrive at the
XML in fig.2.


   - Using the Java
API,
   how would I put the  into the Header [*soapenv:Header
   / wsse:Security*]
   - Using the same API, into [*soapenv:Header / wsse:Security*] how would
   I add
   - [wsse:Security / wsse:BinarySecurityToken] ;; Binary Security Token
  Direct Reference
  - [wsu:Timestamp / ws:Created]
  - [wsu:Timestamp / ws:Expires]


   -  (and child tags) are namespaced. Using the same API,
   how do I add the namespace and prefix (generated tags are not namespaced by
   default).
   - Is the  attribute meaningful? (must it be
   populated).
   - Is it significant, the fact that  has 2 
   tags
   - [*ds:KeyInfo / wsse:SecurityTokenReference*] and [*ds:KeyInfo /
   wsse:SecurityTokenReference / wsse:Reference*] in fig.2 is different
   from [*KeyInfo / KeyValue / DSAKeyValue*] tags in fig.3.



*Materials *



  
 
 


   3XATH
   Genesys.addExceptionForAgent

   

 
  


fig.1 - source XML

http://www.w3.org/TR/REC-xml/>"?>
http://www.hewitt.com/hro/benefits/fndt/hasbro/model";
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";>
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary";
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3";
wsu:Id="CertId-fubar">fubar
http://www.w3.org/2000/09/xmldsig#";
Id="Signature-6">

http://www.w3.org/2001/10/xml-exc-c14n#"/>
http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>


http://www.w3.org/2001/10/xml-exc-c14n#"/>

http://www.w3.org/2000/09/xmldsig#sha1"/>
fubar



http://www.w3.org/2001/10/xml-exc-c14n#"/>

http://www.w3.org/2000/09/xmldsig#sha1"/>
fubar=



fubar


http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
wsu:Id="fubar">
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>


http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
wsu:Id="Timestamp-5">
fubar
fubar


http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
wsu:Id="id-70">

fubar
fubar








fig.2. - The target (signed) XML we want to reach

http://www.w3.org/TR/REC-xml/>" encoding="UTF-8"
standalone="no"?>http://schemas.xmlsoap.org/soap/envelope/";
xmlns:mod="http://www.hewitt.com/hro/benefits/fndt/hasbro/model";>**
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
wsu:Id="id-3">





http://www.w3.org/2000/09/xmldsig#";>

http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"/>
http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>


http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

http://www.w3.org/2000/09/xmldsig#sha1"/>
fubar


fubar



fubar
fubar
fubar
fubar






*fig.3 - Signed XML as it currently exists *



Anyone have expertise with this? Or even if there's a library out there.

Thanks


Tim Washington
Interruptsoftware.com 

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

Re: Managing State Changes, using Component

[Timothy Washington]

Sorry, just reading this now.

I've pivoted on that project, and that code is no longer around. We were
going to store analytics data in that atom, but instead are going to do JVM
and other kinds of profiling.

But if you look at my first message, component *:a* would have had the
atom. The *:updater* and *:reader* components were referencing that. Now,
if there's any duplication like what you describe, it would have to come
where I set up the component system/map. But my code's perspective, I only
created that atom once. Sorry I don't have immediate access to that code. I
can't show it to you either. But if need be, I can go back in git history,
and troubleshoot the codebase as it was on April 30th. But again, my
description abouve fairly captures the situation.


Lemme know

Tim Washington
Interruptsoftware.com 


On Wed, May 7, 2014 at 1:31 PM, Stuart Sierra
wrote:

> Actually, now that I think about it, that's not right. It shouldn't matter
> where or when you create the Atom.
>
> Instead, what I suspect you have is two or more instances of the component
> containing the Atom, thus two different Atoms.
>
> You can tell if the Atoms are the same object by printing them, which
> shows a unique hash of each Atom's identity.
>
> -S
>
>
>
> On Monday, May 5, 2014 6:25:55 PM UTC-4, frye wrote:
>
>> Ahh, so that was it then. Yeah, I definitely created that atom in the
>> start method.
>>
>>
>> On Mon, May 5, 2014 at 3:27 PM, Stuart Sierra <
>> the.stuart.sie...@gmail.com> wrote:
>>
>>> At what point did you **create** the Atom in :a? Any mutable references
>>> which need to be shared among all usages of a component must be created in
>>> the **constructor**, not the `start` or `stop` methods.
>>>
>>

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

Expected inconsistency between set and map w/ ArrayList?

[John D. Hume]

Is this behavioral change in Clojure 1.6.0 expected? Under 1.6.0, a set and
a map seem to treat a java.util.ArrayList differently with respect to its
equivalence to a vector.
https://gist.github.com/duelinmarkers/7c9f84cfc238e5d37a09

user=> (-> {} (assoc [1 2] "vec") (assoc (java.util.ArrayList. [1 2]) "alist"))
{[1 2] "alist"}
user=> (-> #{} (conj [1 2]) (conj (java.util.ArrayList. [1 2])))
*#{[1 2]}*
user=> *clojure-version*
{:major 1, :minor 5, :incremental 1, :qualifier nil}

;

user> (-> {} (assoc [1 2] "vec") (assoc (java.util.ArrayList. [1 2]) "alist"))
{[1 2] "alist"}
user> (-> #{} (conj [1 2]) (conj (java.util.ArrayList. [1 2])))
*#{[1 2] [1 2]}*
user> *clojure-version*
{:major 1, :minor 6, :incremental 0, :qualifier nil}

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

Expected inconsistency between set and map w/ ArrayList?

[Mike Fikes]

Perhaps this is a consequence of the hashing changes in 1.6. 
(http://dev.clojure.org/display/design/Better+hashing)

-- 
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: data.xml namespace aware?

[Timothy Washington]

Thanks Herwig. I take it
test_namespace.cljis
the interesting file. Given the example in my previous message, is
there
a more idiomatic way of defining namespaces with this proposal?


Thanks again

Tim Washington
Interruptsoftware.com 



On Thu, May 8, 2014 at 10:54 AM, Herwig Hochleitner
wrote:

> Hi,
>
> I'm the guy working on the newer proposal, which is almost done (TM). It
> seems you have found the way to emulate namespacing with the current
> data.xml impl: by taking care of xmlns attributes and prefixes yourself. I
> definitely want to keep compatibility with that representation. Feel free
> to check out my proposal branch here https://github.com/bendlas/data.xml
>
> cheers
>
>
> 2014-05-06 21:53 GMT+02:00 Timothy Washington :
>
>> Ok, scratch that. I got it working, lol :)
>>
>> Sorry for the false alarm. For future reference, this:
>>
>> (def e4 (xml/sexp-as-element
>>  [:thing:first {:xmlns:thing "http://thing"}
>>  [:thing:second {}]]))
>>
>>
>> ...gives you this:
>>
>> user> (process/print-esequel process/e4)
>>
>> 
>> http://thing";>
>>   
>> 
>>
>>
>>
>> Tim Washington
>> Interruptsoftware.com 
>>
>>
>> On Tue, May 6, 2014 at 3:45 PM, Timothy Washington wrote:
>>
>>> Got a bit further here. I want to be able to get tag namespaces without
>>> a :root tag (that includes the namespace definition). Assume the below code
>>> has (require '[clojure.data.xml :as xml]).
>>>
>>>
>>> Working with attributes is fine.
>>>
>>> (def e1 (xml/element :use {:xmlns:xlink "http://testing";,
>>>:xlink:href "#whiskers",
>>>:transform "scale(-1 1) translate(-140 0)"}))
>>>
>>>
>>> Namespace prefixes is possible with tags; however, I had to add the
>>> unwanted :root tag (that includes ns definition)
>>>
>>> (def e2 (xml/element :root {:xmlns:thing "http://thing"}
>>>  (xml/element :thing:use {})))
>>>
>>> (def e3 (xml/element :root {:xmlns:thing "http://thing"}
>>>  (xml/sexp-as-element
>>>   [:thing:first {}
>>>[:thing:second {}]])))
>>>
>>> (defn print-esequel [elem]
>>>   (println (xml/indent-str elem)))
>>>
>>>
>>>
>>> The resulting XML is close. But we want the tag namespaces, without the
>>> root node
>>>
>>> user> (print-esequel process/e2)
>>>
>>> 
>>> http://thing";>
>>>   
>>> 
>>>
>>> user> (print-esequel process/e3)
>>>
>>> 
>>> http://thing";>
>>>   
>>> 
>>>   
>>> 
>>>
>>>
>>>
>>> Tim Washington
>>> Interruptsoftware.com 
>>>
>>>
>>> On Tue, May 6, 2014 at 3:24 PM, Timothy Washington 
>>> wrote:
>>>
 Hi there,


 *A)* I'm just writing some SOAP XML, trying to use 
 data.xml.
 This SO 
 thread
  outlines
 how to write out namespace aware XML. But the example is for a namespace on
 an attribute. I'm combing through the code now, but does anyone know how to
 set this up?


 *B)* There's actually this Fuller XML 
 Supportproposal 
 (referring to this
 thread),
 and this Namespaced 
 XMLproposal. But I 
 don't see that namespaces are fully implemented in any of
 the core libs.

 I only see this ArmageDOM lib, 
 which supports namespaces. Anything else out there that I've missed?


 Thanks

 Tim Washington
 Interruptsoftware.com 



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

[Sean Corfield]

Indeed. The OP contacted me offlist and I suggested running a virtual 
framebuffer for X11 and sent them a link.

Sean

On May 9, 2014, at 10:52 AM, Stuart Sierra  wrote:
> This sounds more like a problem with remote access to X-Windows (the Unix 
> graphical back-end) than a Clojure-specific problem. You might find some 
> helpful answers in Ubuntu docs, forums, or chat rooms.
> -S
> 
> 
> On Friday, May 9, 2014 6:57:26 AM UTC-4, stiffyrabbit jr wrote:
> Hi,
> 
> What should my approach be, if I want my headless server to run a client 
> program that uses the client GUI?
> 
> How can my server provide the same resources as a local client, to use GUI 
> objects?
> 
> I have a Clojure program that opens a file dialog on the client.  It works 
> fine, until I try to run it from the server.
> 
> My setup:
> 
> A Macbook Pro with VirtualBox and LightTable on it;
> VirtualBox running Ubuntu 14.4, Leiningen, Clojure.  Ubuntu has extension 
> pack, in response to this problem;
> 
> I start VB - VBoxManage startvm 'Core' --type headless;
> 
> I login to Core - ssh Core normally, ssh -v -X Core in desparation;
> 
> I launch a repl in a Clojure proj.  I use the host:port details as a LT nrepl 
> connection.  I get the following error:
> 
> java.awt.HeadlessException: No X11 DISPLAY variable was set, but this program 
> performed an operation which requires it.
> 
> I have tried so many things to resolve this, that I get lost in it all.
> 
> What approach will ensure that my server can run a program that requires 
> DISPLAY, and use client GUI objects?




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Managing State Changes, using Component

[James Reeves]

If you only created the atom once, the value of the atom would be the same
no matter where you dereferenced it. If you're seeing two different atoms,
then the code that created the atom must have been executed more than once.

Without seeing your code it's impossible to know for sure how that
occurred. There's nothing obvious in the pseudocode you presented that
would indicate where the atom is being created more than once.

- James


On 9 May 2014 22:49, Timothy Washington  wrote:

> Sorry, just reading this now.
>
> I've pivoted on that project, and that code is no longer around. We were
> going to store analytics data in that atom, but instead are going to do JVM
> and other kinds of profiling.
>
> But if you look at my first message, component *:a* would have had the
> atom. The *:updater* and *:reader* components were referencing that. Now,
> if there's any duplication like what you describe, it would have to come
> where I set up the component system/map. But my code's perspective, I only
> created that atom once. Sorry I don't have immediate access to that code. I
> can't show it to you either. But if need be, I can go back in git history,
> and troubleshoot the codebase as it was on April 30th. But again, my
> description abouve fairly captures the situation.
>
>
> Lemme know
>
> Tim Washington
> Interruptsoftware.com 
>
>
> On Wed, May 7, 2014 at 1:31 PM, Stuart Sierra  > wrote:
>
>> Actually, now that I think about it, that's not right. It shouldn't
>> matter where or when you create the Atom.
>>
>> Instead, what I suspect you have is two or more instances of the
>> component containing the Atom, thus two different Atoms.
>>
>> You can tell if the Atoms are the same object by printing them, which
>> shows a unique hash of each Atom's identity.
>>
>> -S
>>
>>
>>
>> On Monday, May 5, 2014 6:25:55 PM UTC-4, frye wrote:
>>
>>> Ahh, so that was it then. Yeah, I definitely created that atom in the
>>> start method.
>>>
>>>
>>> On Mon, May 5, 2014 at 3:27 PM, Stuart Sierra <
>>> the.stuart.sie...@gmail.com> wrote:
>>>
 At what point did you **create** the Atom in :a? Any mutable
 references which need to be shared among all usages of a component must be
 created in the **constructor**, not the `start` or `stop` methods.

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

-- 
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: Expected inconsistency between set and map w/ ArrayList?

[Andy Fingerhut]

Mike is correct.  This change in behavior is due to the hashing changes in
Clojure 1.6.  See the comments on ticket
http://dev.clojure.org/jira/browse/CLJ-1372 for some discussion of whether
this is considered a bug.  It appears that perhaps the hash consistency is
not promised for mutable objects, only immutable ones.

Below are a couple more REPL transcripts that illustrate the change in
behavior:

user=> *clojure-version*
{:major 1, :minor 5, :incremental 1, :qualifier nil}
user=> (= [1 2] (java.util.ArrayList. [1 2]))
true
user=> (map hash [ [1 2] (java.util.ArrayList. [1 2]) ])
(994 994)
user=> (hash-map [1 2] "vec" (java.util.ArrayList. [1 2]) "alist")
{[1 2] "alist"}



user=> *clojure-version*
{:major 1, :minor 6, :incremental 0, :qualifier nil}
user=> (= [1 2] (java.util.ArrayList. [1 2]))
true
user=> (map hash [ [1 2] (java.util.ArrayList. [1 2]) ])
(156247261 994)
user=> (hash-map [1 2] "vec" (java.util.ArrayList. [1 2]) "alist")
{[1 2] "alist", [1 2] "vec"}


Andy


On Fri, May 9, 2014 at 3:18 PM, Mike Fikes  wrote:

> Perhaps this is a consequence of the hashing changes in 1.6. (
> http://dev.clojure.org/display/design/Better+hashing)
>
> --
> 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.
>

-- 
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: Managing State Changes, using Component

[Timothy Washington]

I can see this being the case. Nominally, my component looks like this.

Before I log a bug however, let's see first, if anyone is seeing this
behaviour.


(ns a

  (:require [com.stuartsierra.component :as component]


[taoensso.timbre :as timbre]))

(defrecord A [env]

  component/Lifecycle


  (start [component]

(assoc component :a (atom {*...*})))

  (stop [component]

(dissoc component :a)))


(defn component-a [env]

  (map->A {:env env}))



Tim Washington
Interruptsoftware.com 



On Fri, May 9, 2014 at 6:40 PM, James Reeves  wrote:

> If you only created the atom once, the value of the atom would be the same
> no matter where you dereferenced it. If you're seeing two different atoms,
> then the code that created the atom must have been executed more than once.
>
> Without seeing your code it's impossible to know for sure how that
> occurred. There's nothing obvious in the pseudocode you presented that
> would indicate where the atom is being created more than once.
>
> - James
>
>
> On 9 May 2014 22:49, Timothy Washington  wrote:
>
>> Sorry, just reading this now.
>>
>> I've pivoted on that project, and that code is no longer around. We were
>> going to store analytics data in that atom, but instead are going to do JVM
>> and other kinds of profiling.
>>
>> But if you look at my first message, component *:a* would have had the
>> atom. The *:updater* and *:reader* components were referencing that.
>> Now, if there's any duplication like what you describe, it would have to
>> come where I set up the component system/map. But my code's perspective, I
>> only created that atom once. Sorry I don't have immediate access to that
>> code. I can't show it to you either. But if need be, I can go back in git
>> history, and troubleshoot the codebase as it was on April 30th. But again,
>> my description abouve fairly captures the situation.
>>
>>
>> Lemme know
>>
>> Tim Washington
>> Interruptsoftware.com 
>>
>>
>> On Wed, May 7, 2014 at 1:31 PM, Stuart Sierra <
>> the.stuart.sie...@gmail.com> wrote:
>>
>>> Actually, now that I think about it, that's not right. It shouldn't
>>> matter where or when you create the Atom.
>>>
>>> Instead, what I suspect you have is two or more instances of the
>>> component containing the Atom, thus two different Atoms.
>>>
>>> You can tell if the Atoms are the same object by printing them, which
>>> shows a unique hash of each Atom's identity.
>>>
>>> -S
>>>
>>>
>>>
>>> On Monday, May 5, 2014 6:25:55 PM UTC-4, frye wrote:
>>>
 Ahh, so that was it then. Yeah, I definitely created that atom in the
 start method.


 On Mon, May 5, 2014 at 3:27 PM, Stuart Sierra <
 the.stuart.sie...@gmail.com> wrote:

> At what point did you **create** the Atom in :a? Any mutable
> references which need to be shared among all usages of a component must be
> created in the **constructor**, not the `start` or `stop` methods.
>


-- 
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: Using Java's XML Digital Signature API -> Clojure

[Timothy Washington]

This refheap link  is, so far, the Clojure
code that generates the XML in fig.3.


Tim Washington
Interruptsoftware.com 


On Fri, May 9, 2014 at 5:29 PM, Timothy Washington wrote:

> Hi all,
>
> I've noticed there's no Clojure library for doing XML Digital signatures.
> So I'll probably put one out there, if I can completely solve this problem.
> Using Java's *XML Digital Signature API
> *,
> I'm trying to get the source XML (*fig.1*) to look like a certain output (
> *fig.2*). However, I'm getting stuck with another output (*fig.3*).
>
> Now, XML Signatures come in 3 forms i) detached, ii) enveloping and iii)
> enveloped. But the XML in *fig.2* has the signature in the Header path 
> [*soapenv:Envelope
> / soapenv:Header / wsse:Security*]. I imagine that's using XML
> Signature's XPath Reference Processing 
> Model.
> So I mainly want to put the xml Signature in the Header. But there are a
> lot of other things that need to get ironed out, in order to arrive at the
> XML in fig.2.
>
>
>- Using the Java 
> API,
>how would I put the  into the Header [*soapenv:Header
>/ wsse:Security*]
>- Using the same API, into [*soapenv:Header / wsse:Security*] how
>would I add
>- [wsse:Security / wsse:BinarySecurityToken] ;; Binary Security Token
>   Direct Reference
>   - [wsu:Timestamp / ws:Created]
>   - [wsu:Timestamp / ws:Expires]
>
>
>-  (and child tags) are namespaced. Using the same API,
>how do I add the namespace and prefix (generated tags are not namespaced by
>default).
>- Is the  attribute meaningful? (must it be
>populated).
>- Is it significant, the fact that  has 2
> tags
>- [*ds:KeyInfo / wsse:SecurityTokenReference*] and [*ds:KeyInfo /
>wsse:SecurityTokenReference / wsse:Reference*] in fig.2 is different
>from [*KeyInfo / KeyValue / DSAKeyValue*] tags in fig.3.
>
>
>
> *Materials *
>
>
> 
>xmlns:soapenv='
> http://schemas.xmlsoap.org/soap/envelope/'>
>  
>xmlns:wsu='
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd'>
>
> 
>3XATH
>Genesys.addExceptionForAgent
>
>
> 
>  
>   
>
>
> fig.1 - source XML
>
> http://www.w3.org/TR/REC-xml/>"?>
>  xmlns:mod="http://www.hewitt.com/hro/benefits/fndt/hasbro/model"; 
> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
>  xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";>
>  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
>  
> EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary";
>  
> ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3";
>  wsu:Id="CertId-fubar">fubar
> http://www.w3.org/2000/09/xmldsig#"; 
> Id="Signature-6">
> 
>  Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>  Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
> 
> 
>  Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
> 
>  Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
> fubar
> 
> 
> 
>  Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
> 
>  Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
> fubar=
> 
> 
> 
> fubar
> 
> 
>  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
>  wsu:Id="fubar">
>  ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
> 
> 
>  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
>  wsu:Id="Timestamp-5">
> fubar
> fubar
> 
> 
>  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
>  wsu:Id="id-70">
> 
> fubar
> fubar
>
>
>
> 
> 
> 
> 
> 
> 
>
> fig.2. - The target (signed) XML we want to reach
>
> http://www.w3.org/TR/REC-xml/>" encoding="UTF-8" 
> standalone="no"?> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; 
> xmlns:mod="http://www.hewitt.com/hro/benefits/fndt/hasbro/model";>**
>  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
>  wsu:Id="id-3">
> 
> 
> 
> 
> 
> http://www.w3.org/2000/09/xmldsig#";>
> 
>  Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"/>
> htt

A video on programming

[daly]

"Literacy, Programming, and Open Source" by Robert M Lefkowitz

http://www.youtube.com/watch?v=JxjTsQtxn8A

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

Nominalization

[Mike Fikes]

I am new to functional programming and caught myself reading “reduce” as “the 
reduction of.”

Do you experienced Clojure programmers find yourselves thinking in terms of 
nouns instead of verbs? (Non-temporal expressions as opposed to actions?)

Some of the operations reinforce this way of thinking (“range” and “max”) while 
others don't (“map” and “take”) while some can easily be either (“count” and 
“mod”) and some that resist being either (“if” and “let”).

-- 
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: Headless server, no GUI, no idea

[stiffyrabbit jr]

And I thank you both.  I was advised to set the display:



*export DISPLAY=:99.0*I'm just wrestling with the line 

*sh -e /etc/init.d/xvfb start*


which returns:

sh: 0: Can't open /etc/init.d/xvfb

My machine reports that *xvfb is already the newest version but, *I get the 
same response.  I see that other posters have the same experience.  

You mightn't be surprised but, without xvfb, LT gives the response:

java.lang.InternalError: Can't connect to X11 window server using ':99.0' as 
the value of the DISPLAY variable.


How do I get xvfb to start?


-- 
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: Headless server, no GUI, no idea

[Atamert Ölçgen]

Are you running this as a superuser? (su or sudo)


On Sat, May 10, 2014 at 1:03 AM, stiffyrabbit jr <
deliverebay...@googlemail.com> wrote:

> And I thank you both.  I was advised to set the display:
>
>
>
> *export DISPLAY=:99.0*I'm just wrestling with the line
>
> *sh -e /etc/init.d/xvfb start*
>
>
> which returns:
>
> sh: 0: Can't open /etc/init.d/xvfb
>
> My machine reports that *xvfb is already the newest version but, *I get
> the same response.  I see that other posters have the same experience.
>
> You mightn't be surprised but, without xvfb, LT gives the response:
>
> java.lang.InternalError: Can't connect to X11 window server using ':99.0' as 
> the value of the DISPLAY variable.
>
>
> How do I get xvfb to start?
>
>
>  --
> 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.
>



-- 
Kind Regards,
Atamert Ölçgen

-+-
--+
+++

www.muhuk.com

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

[Gary Trakhman]

Never thought of it that way, I always verb the noun.

Did you learn about reductions, yet? It's clear that the name corresponds
to the intended output at least in that case.

On Friday, May 9, 2014, Mike Fikes  wrote:

> I am new to functional programming and caught myself reading “reduce” as
> “the reduction of.”
>
> Do you experienced Clojure programmers find yourselves thinking in terms
> of nouns instead of verbs? (Non-temporal expressions as opposed to actions?)
>
> Some of the operations reinforce this way of thinking (“range” and “max”)
> while others don't (“map” and “take”) while some can easily be either
> (“count” and “mod”) and some that resist being either (“if” and “let”).
>
> --
> 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.
>

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