Re: Confused about "=", native java arrays and seqs...
Sorry, I copied the wrong snippet from my repl - the correct one is: ... user> (= (.getBytes "a")(.getBytes "a")) false user> (= (seq (.getBytes "a")) (seq (.getBytes "a"))) true ... although the previous extra "(bytes...)" doesn't change the example, it may add to the confusion ;-) -FS/ On Mar 23, 2010, at 10:24 AM, Frank Siebenlist wrote: > My REPL shows: > ... > user> (= (bytes (.getBytes "a"))(bytes (.getBytes "a"))) > false > user> (= (seq (bytes (.getBytes "a"))) (seq (bytes (.getBytes "a" > true > ... > > in other words, "equality" for java byte arrays is defined differently than > their seq'ed version. > > It seems that the native arrays are compared on their reference while the > seq'ed version on their value (as it should...). > > Sometimes the seq'ing seems implied, however, like in: > > ... > user> (first (bytes (.getBytes "a"))) > 97 > ... > > but for the "=" function it is not. > > This doesn't feel right and is confusing to say the least. > > Could anyone shed some light on this behaviour? > > Thanks, Frank. > -- 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.
Confused about "=", native java arrays and seqs...
My REPL shows: ... user> (= (bytes (.getBytes "a"))(bytes (.getBytes "a"))) false user> (= (seq (bytes (.getBytes "a"))) (seq (bytes (.getBytes "a" true ... in other words, "equality" for java byte arrays is defined differently than their seq'ed version. It seems that the native arrays are compared on their reference while the seq'ed version on their value (as it should...). Sometimes the seq'ing seems implied, however, like in: ... user> (first (bytes (.getBytes "a"))) 97 ... but for the "=" function it is not. This doesn't feel right and is confusing to say the least. Could anyone shed some light on this behaviour? Thanks, Frank. -- 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.
How to "name" a byte array class/type for multi-method dispatch?
The following repl session shows my attempt to dispatch a multimethod on "type": ... user> (defmulti mm type) #'user/mm user> (type "a") java.lang.String user> (defmethod mm java.lang.String [s] (println "string")) # user> (mm "a") string nil user> (type (.getBytes "a")) [B user> (defmethod mm [B [b] (println "bytes")) ; Evaluation aborted. user> (def ba-type (type (.getBytes "a"))) #'user/ba-type user> (defmethod mm ba-type [b] (println "bytes")) # user> (mm (.getBytes "a")) bytes nil user> ... It works easily for the string, but for a native java byte array, type (or class) gives me back this "[B", which I'm unable to use as a dispatch value for the defmethod. I can, however, assign the value to a reference and us that to dispatch on successfully - but that feels like a hack. Is there a way to express the byte array type in a different way than "[B" that would work? Thanks, Frank. -- 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: Confused about "=", native java arrays and seqs...
Thanks for the response - guess it is the best one can do living in this mixed mutable/immutable world. Has the seq'ed version of the java byte array become immutable or do we have to pray that nobody changes the underlying array values? -FS. On Mar 24, 2010, at 12:40 PM, André Ferreira wrote: > Arrays are mutable, seqs immutable. Clojure ='s compares immutable > structures by value, and mutable structures by reference (for the > objects that it is aware of, for others it just prays that they have a > resoanable equals method). This behaviour is described in the very > interisting Henry Baker's egal Paper, and yields the cleanest equality > semantics that I know of. > > On 23 mar, 14:24, Frank Siebenlist wrote: >> My REPL shows: >> ... >> user> (= (bytes (.getBytes "a"))(bytes (.getBytes "a"))) >> false >> user> (= (seq (bytes (.getBytes "a"))) (seq (bytes (.getBytes "a" >> true >> ... >> >> in other words, "equality" for java byte arrays is defined differently than >> their seq'ed version. >> >> It seems that the native arrays are compared on their reference while the >> seq'ed version on their value (as it should...). >> >> Sometimes the seq'ing seems implied, however, like in: >> >> ... >> user> (first (bytes (.getBytes "a"))) >> 97 >> ... >> >> but for the "=" function it is not. >> >> This doesn't feel right and is confusing to say the least. >> >> Could anyone shed some light on this behaviour? >> >> Thanks, Frank. > > -- > 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. -- 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: How to "name" a byte array class/type for multi-method dispatch?
Right - not very different from the (class (byte-array 1)) that I came up with in the mean time... all not very clojuresque. -FS. On Mar 24, 2010, at 3:03 PM, ataggart wrote: > For type-hinting #^"[B" works, but for obtaining and passing the class > to defmethod, the best I can come up with is (Class/forName "[B"). > > > > On Mar 24, 11:02 am, Frank Siebenlist > wrote: >> The following repl session shows my attempt to dispatch a multimethod on >> "type": >> >> ... >> user> (defmulti mm type) >> #'user/mm >> user> (type "a") >> java.lang.String >> user> (defmethod mm java.lang.String [s] (println "string")) >> # >> user> (mm "a") >> string >> nil >> user> (type (.getBytes "a")) >> [B >> user> (defmethod mm [B [b] (println "bytes")) >> ; Evaluation aborted. >> user> (def ba-type (type (.getBytes "a"))) >> #'user/ba-type >> user> (defmethod mm ba-type [b] (println "bytes")) >> # >> user> (mm (.getBytes "a")) >> bytes >> nil >> user> >> ... >> >> It works easily for the string, but for a native java byte array, type (or >> class) gives me back this "[B", which I'm unable to use as a dispatch value >> for the defmethod. >> I can, however, assign the value to a reference and us that to dispatch on >> successfully - but that feels like a hack. >> >> Is there a way to express the byte array type in a different way than "[B" >> that would work? >> >> Thanks, Frank. > > -- > 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. -- 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: How to "name" a byte array class/type for multi-method dispatch?
Nice research - so is it then the reader that doesn't allow us to escape the "[B" such that we can write it such that it can be interpreted as a symbol [B ? -Frank. On Mar 24, 2010, at 7:27 PM, ataggart wrote: > Ok, after looking into how clojure resolves class literal symbols, it > turns out it is already smart enough to recognize symbol names that > start with "["; the problem is it's a pain to type such symbols into > code. > > Your code can work this way: > user=> (defmethod mm (resolve (symbol "[B")) [b] (println "bytes")) > # > user=> (mm (.getBytes "a")) > bytes > nil > > In the end though, it turns out to be just another way to call (Class/ > forName "[B"). > > > On Mar 24, 6:54 pm, ataggart wrote: >> The java version would look like: >> Class c = byte[].class; >> >> But since the clojure way to obtain a class is simply to use its name >> literal, e.g.: >> user=> (type String) >> java.lang.Class >> the only way to get the class of an array would involve either a >> function call or a change to the reader. And java doesn't make it >> easy since all array-class stuff, such as Class.isArray(), is native >> code. The best I've come up with is: >> user=> >> (defn #^Class array-class >> "Returns the Class of an array of component type c" >> [#^Class c] >> (when c (class (java.lang.reflect.Array/newInstance c 0 >> user=> (array-class String) >> [Ljava.lang.String; >> which appears faster than using Class/forName with a created string. >> But since one *can* type a literal byte array class in java, I'd >> imagine there's some way to implement this with bytecode magic, rather >> than going through java.lang.reflect.Array. >> >> On Mar 24, 3:39 pm, Frank Siebenlist >> wrote: >> >> >> >>> Right - not very different from the (class (byte-array 1)) that I came up >>> with in the mean time... all not very clojuresque. >> >>> -FS. >> >>> On Mar 24, 2010, at 3:03 PM, ataggart wrote: >> >>>> For type-hinting #^"[B" works, but for obtaining and passing the class >>>> to defmethod, the best I can come up with is (Class/forName "[B"). >> >>>> On Mar 24, 11:02 am, Frank Siebenlist >>>> wrote: >>>>> The following repl session shows my attempt to dispatch a multimethod on >>>>> "type": >> >>>>> ... >>>>> user> (defmulti mm type) >>>>> #'user/mm >>>>> user> (type "a") >>>>> java.lang.String >>>>> user> (defmethod mm java.lang.String [s] (println "string")) >>>>> # >>>>> user> (mm "a") >>>>> string >>>>> nil >>>>> user> (type (.getBytes "a")) >>>>> [B >>>>> user> (defmethod mm [B [b] (println "bytes")) >>>>> ; Evaluation aborted. >>>>> user> (def ba-type (type (.getBytes "a"))) >>>>> #'user/ba-type >>>>> user> (defmethod mm ba-type [b] (println "bytes")) >>>>> # >>>>> user> (mm (.getBytes "a")) >>>>> bytes >>>>> nil >>>>> user> >>>>> ... >> >>>>> It works easily for the string, but for a native java byte array, type >>>>> (or class) gives me back this "[B", which I'm unable to use as a dispatch >>>>> value for the defmethod. >>>>> I can, however, assign the value to a reference and us that to dispatch >>>>> on successfully - but that feels like a hack. >> >>>>> Is there a way to express the byte array type in a different way than >>>>> "[B" that would work? >> >>>>> Thanks, Frank. >> >>>> -- >>>> 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/clojur
"," is REAL whitespace...
Even though the specs clearly say that commas are whitespace, the following repl session doesn't feel "intuitively" right: ... user> (list 1 2 3) (1 2 3) user> (list 1, 2, 3) (1 2 3) user> (list 1, 2, , 3) (1 2 3) user> (list 1, 2, nil , 3) (1 2 nil 3) ... "," is same as ", ," is same as " "... big gotcha for beginning clojurians... Enjoy, Frank. -- 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: "," is REAL whitespace...
I did not want to argue for or against the "," as whitespace feature, but just
wanted to point out the possible gotchas that we probably should warn novice
clojure programmers for. I actually hit my head when I was trying to initialize
a map with some nil value for :b, like:
user> {:a, "a", :b,, :c, "c"}
; Evaluation aborted.
user>
which yields some ArrayIndexOutOfBoundsException that I guess somehow tries to
tell you that there is an odd number of entries for the map... and indirectly
made me remember about those commas & whitespace.
It would have been a nasty bug if I would have tried to initialize an even
number of nil values, like:
user> {:a,, :b,, :c, "c"}
{:a :b, :c "c"}
instead of
user> {:a, nil,:b, nil, :c, "c"}
{:a nil, :b nil, :c "c"}
as the former expression doesn't barf but simply yields the wrong result...
So, it's all some form of RTFM... but one could argue that this novel use of
commas in the syntax results in adding a little "incidental complexity" to the
language ;-)
-Frank.
On Apr 2, 2010, at 7:39 AM, Per Vognsen wrote:
> Well, for the comma to be useful, it cannot require whitespace
> separation on either side. It would be weird if you had to write [1 ,
> 2 , 3]. So, it shouldn't be surprising that 'list,' is read as 'list'
> when '123,' is read as '123'.
>
> Regarding the strangeness of comma-as-whitespace if you're coming from
> a Lisp background, I admit I initially disliked it but have grown
> fonder of it over time. That was a little surprising to me. I
> generally don't favor syntactic distinctions without a difference,
> e.g. case-insensitive symbol reading in Common Lisp, PLT Scheme's [
> and ] as synonyms for ( and ), etc.
>
> -Per
>
> On Fri, Apr 2, 2010 at 6:10 PM, Mark J. Reed wrote:
>> try this one:
>> (list,1,2,3)
>> :)
>> Per: I'd say it's also weird if you're coming from a Lisp background - just
>> weird in the opposite direction. But not so weird that it's not useful,
>> mostly for separating key/value pairs from other key/value pairs in a map.
>> It's like Perl's "fat comma" arrow operator in that sense - syntactically
>> no different from comma, but stylistically helpful.
>>
>> On Fri, Apr 2, 2010 at 1:52 AM, Per Vognsen wrote:
>>>
>>> It doesn't feel right only if you still think you are programming in
>>> an Algol-style language where , is a separator token.
>>>
>>> I can't imagine this is going to change.
>>>
>>> -Per
>>>
>>> On Fri, Apr 2, 2010 at 12:37 PM, Frank Siebenlist
>>> wrote:
>>>> Even though the specs clearly say that commas are whitespace, the
>>>> following repl session doesn't feel "intuitively" right:
>>>>
>>>> ...
>>>> user> (list 1 2 3)
>>>> (1 2 3)
>>>> user> (list 1, 2, 3)
>>>> (1 2 3)
>>>> user> (list 1, 2, , 3)
>>>> (1 2 3)
>>>> user> (list 1, 2, nil , 3)
>>>> (1 2 nil 3)
>>>> ...
>>>>
>>>> "," is same as ", ," is same as " "... big gotcha for beginning
>>>> clojurians...
>>>>
>>>> Enjoy, Frank.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Clojure" group.
>>>> To post to this group, send email to clojure@googlegroups.com
>>>> Note that posts from new members are moderated - please be patient with
>>>> your first post.
>>>> To unsubscribe from this group, send email to
>>>> clojure+unsubscr...@googlegroups.com
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/clojure?hl=en
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>>
>>> To unsubscribe, reply using "remove me" as the subject.
>>
>>
>>
>> --
>> Mark J. Reed
>>
>> --
>&g
Re: "," is REAL whitespace...
On Apr 2, 2010, at 7:14 PM, Armando Blancas wrote: >> So, it's all some form of RTFM... but one could argue that this novel use of >> commas in the syntax results in adding a little "incidental complexity" to >> the language ;-) > My wrong assumption was: "whitespace and commas are separators" instead of "comma is whitespace and whitespace is separator" right assumption is "nil for no-value": (first ()) => nil and I got the wrong result not because you get what you put in, but because I had a bug in my program - my bad... ...but if I'm the only one who ever got bitten by clojure's commas that would be fantastic (and I guarantee you that it won't happen to me again ;-) ) -Frank. > You put some pretty specific assumptions into your code: commas as > separators, commas with a "proper" place in Clojure syntax, optional > values in lists, nil for no-value, keys gotta be keywords (you don't > get a wrong result, you get what you put in). No wonder it gets > complex. A comma is whitespace and maps take pairs, that's the > contrary of incidental complexity. BTW, I don't use commas and I make > the odd count error often enough. > > -- > 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. -- 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: build.clojure.org update: clojure-contrib 1.2 repo path no longer includes "-master"
I just built the netbean+labrepl from start according the getting-started webpage, and the build barfed because labrepl's pom.xml included the "1.2.0-master-SNAPSHOT" instead of "1.2.0-SNAPSHOT" for clojure-contrib. After correction, all build without errors and seems to work fine. -Frank. On May 6, 2010, at 2:22 PM, Stephen C. Gilardi wrote: > This change was made to some months ago, but some builds that followed the > obsolete convention have been hanging around. I removed them today. > > On Apr 30, 2010, at 9:50 AM, Stuart Halloway wrote: > >> There are plenty of recent SNAPSHOT builds: >> http://build.clojure.org/snapshots/org/clojure/clojure-contrib/1.2.0-SNAPSHOT/ >> >> But no recent master-SNAPSHOT builds: >> http://build.clojure.org/snapshots/org/clojure/clojure-contrib/1.2.0-master-SNAPSHOT/ >> >> This is causing me a problem [...] >> >> Options >> >> [...] > >> (b) we can delete the master artifacts so only the snapshots are found (I >> would need to poke around Hudson to figure this out. > > Hi Stu, > > In response to your email request, I've removed this directory: > >> http://build.clojure.org/snapshots/org/clojure/clojure-contrib/1.2.0-master-SNAPSHOT/ > > Anyone who now gets a 404 for that path should update their config to point > to the current location: > >> http://build.clojure.org/snapshots/org/clojure/clojure-contrib/1.2.0-SNAPSHOT/ > > to start using nice fresh builds of clojure-contrib. > > Cheers, > > --Steve > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Is contributing to clojurescript is intentionally made hard ?
One process that could be made a little easier is the contribution of code documentation and suggested improvements of doc-strings. New or improved doc-strings do not change any functionality, impact any tests, require peer review… If we could simply suggest new doc-strings for example in the JIRA-issue, have enough eyeballs stare at it, improvements, amendments…, then after sign-off, a committer could simply copy&paste this approved enhancement in the official code. Low-impact and it could make it easier to get community involvement and contributions for clojure & clojurescript's documentation, which arguably could use a little patch here and there. Having to go thru the whole official patch process to suggest an improved docstring is a bit much… and god forbid that you have to thru that multiple time before all the , and . are approved. -FrankS. On Jan 18, 2013, at 1:33 PM, Andy Fingerhut wrote: > The issue that Clojure, its contrib libraries, and ClojureScript do not > accept github pull requests has been brought up several times before on this > email list in the past. Feel free to search the Google group for terms like > "pull request". Short answer: Rich Hickey prefers a workflow of evaluating > patches, not pull requests. It is easier for him. You aren't likely to > change his preference on this issue. That choice wasn't made in order to > make it harder on contributors. > > Instructions on creating patches for Clojure are under the heading > "Developing and submitting patches to Clojure and Clojure Contrib" on this > web page: > >http://dev.clojure.org/display/design/JIRA+workflow > > I suspect they are quite similar for ClojureScript, but I haven't submitted a > ClojureScript patch before to know for sure. > > Andy > > On Jan 18, 2013, at 1:01 PM, Irakli Gozalishvili wrote: > >> I have being trying to engage community and to contribute to clojurescript >> for a while already, >> but so far it's being mostly frustrating and difficult. I hope to start >> discussion here and maybe >> get some constructive outcome. >> >> ## Rationale >> >> I'm primarily interested in clojurescript and not at all in clojure, because >> of specific reasons (that >> I'll skip since their irrelevant for this discussion) dependency on JVM is a >> problem. Removing >> that's dependency is also my primary motivation to contribute. >> >> ## Problems >> >> - I do understand that most of the clojurescript audience is probably also >> interested in clojure, >> but please don't enforce that. Have a separate mailing list so that people >> interested in >> clojurescript and not clojure could follow relevant discussions without >> manually filtering out >> threads. >> >> - What is the point of being on github if you don't accept pull requests and >> require I do understand >> that there maybe specific reasons why jira flow was chosen, but seriously >> that's another ball >> thrown at potential contributor to joggle. Not to mention that there are >> several options how >> jira and github could be integrated. >> >> - My latest attempt was to configure travis.ci for integration tests >> https://github.com/clojure/clojurescript/pull/21 >> >> Integration tests are great specially because they run on every pull >> request and post details back >> into pull requests. This also means that lot of local test run time can be >> saved. Not to mention that >> for clojurescript tests you need JVM, v8, spidermonkey and more… >> >> If these things are intentionally made hard to stop new people with more >> clojurescipt interests then please >> make it more clear, cause otherwise it just a motivation killer. >> >> Thanks >> -- >> Irakli Gozalishvili >> Web: http://www.jeditoolkit.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 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: Call for volunteers to help moderate a ClojureScript Google group
Happy to help - FrankS. On Jan 23, 2013, at 10:53 AM, Andy Fingerhut wrote: > An interest was expressed by a few in having a separate ClojureScript mailing > list. > > If it is a Google group, that requires moderating messages sent to the group, > via manual approval. I suspect early on there will be many people posting to > the group for the first time that have long worked with ClojureScript, and > you'll know them, and you can approve that and all future messages from them, > but every time a new sender sends their first few messages to the group, a > person needs to receive an email, click a link, read the message to verify it > is on topic, and click a couple of buttons to approve it or reject it. > > Anyone interested in helping out with that? It is easier if the load can be > spread across multiple people. If someone else approves a message, you still > might get an email about a message needing approval, but the last couple of > steps above are then unnecessary. > > Andy > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: Tawny-OWL 0.9
There is one more important difference between EPL and GPL/LGPL that we should be aware off: You cannot copy snippets out of Philip's LGPL'ed code and use them in your own EPL'ed code. For me, one of the great benefits of all the EPL'ed clojure libraries out there is, that I've freely borrowed and stolen many functions and snippets from libraries of coders much smarter than me… This is just an observation and warning, and I do not want to engage in any religious open source licensing argument… … however, from a personal benefit point of view, if you want to publish your code as open source for the clojure community, and you do not care too much about whether it should be EPL or GPL/LGPL, then please choose EPL. If you care strongly about GPL/LGPL, more power to you and thanks for sharing the library also! Thanks, Frank. On Feb 6, 2013, at 12:06 AM, Phillip Lord wrote: > > This should be fine. Both EPL and LGPL are weak copyleft. Clojure code > does not need to be EPL because EPL does not force it. Likewise, Clojure > can call back to this LGPL library because, the LGPL doesn't enforce > derivative works as a whole to be LGPL (although modifications to the > tawny *would* have to be LGPL, likewise, modified versions of Clojure). > > The uber jar is a red herring, I think. It's an aggregation, not a > derivative work. The same problem would exist even if I EPL'd the > library; it uses the OWL API underneath, and this is LGPL also. > > If code written in Clojure were affected by the EPL, then it would have > been a fairly poor choice of license, I feel. > > Phil > > > AtKaaZ writes: > >> you can release that on LGPL License ? >> does that work with the EPL of clojure ? or is it only an issue when lein >> uberjar-ed ? >> >> >> >> On Tue, Feb 5, 2013 at 5:57 PM, Phillip Lord >> wrote: >> >>> >>> >>> Tawny-OWL is a clojure library which provides a DSL for the construction >>> of OWL Ontologies (http://www.w3.org/2004/OWL/). The practical upshot of >>> this, is that allows a form of logic reasoning over sets of facts about >>> the world, with strong computational guarantees about decidability. >>> >>> At it's simplest it looks rather like the Manchester Syntax, but is >>> fully programmatic language, which allows for arbitrary templating of >>> expressions. Where possible, it uses clojure facilities directly, so >>> things like autocomplete, and documentation look up work out-of-the-box, >>> in what ever IDE is your poison. >>> >>> It comes complete with reasoner support using HermiT >>> (http://www.hermit-reasoner.com/) or ELK >>> (http://code.google.com/p/elk-reasoner/). Tawny-OWL current implements >>> all of the object and annotation side of OWL; expression of datatype >>> properties will follow shortly. >>> >>> Although, it's been available for a while, this is the first release >>> that I have announced here. I'd welcome feedback. The Clojure is a bit >>> nasty at places--I learnt the language at the same time. >>> >>> https://github.com/phillord/tawny-owl >>> >>> and on clojars. >>> >>> Phil >>> >>> >>> -- >>> Phillip Lord, Phone: +44 (0) 191 222 7827 >>> Lecturer in Bioinformatics, Email: >>> phillip.l...@newcastle.ac.uk >>> School of Computing Science, >>> http://homepages.cs.ncl.ac.uk/phillip.lord >>> Room 914 Claremont Tower, skype: russet_apples >>> Newcastle University, msn: m...@russet.org.uk >>> NE1 7RU twitter: phillord >>> >>> -- >>> -- >>> 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. >>> >>> >>> >> >> >> -- >> Please correct me if I'm wrong or incomplete, >> even if you think I'll subconsciously hate it. >> >> -- > > -- > Phillip Lord, Phone: +44 (0) 191 222 7827 > Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk > School of Computing Science, > http://homepages.cs.ncl.ac.uk/phillip.lord > Room 914 Claremont Tower, skype: russet_apples > Newcastle University, msn: m...@russet.org.uk > NE1 7RU twitter: phillord > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post t
Re: Wrong clojure version depending on lein dependencies (was: ANN: Clojure 1.5)
> ... > The chain causing problems for you is: > > [clj-ns-browser "1.3.0"] -> [seesaw "1.4.2"] -> [j18n "1.0.1"] -> > [org.clojure/clojure "[1.2,1.5)"] > > The last one there allows clojure below 1.5, which includes -RC17. As > soon as you bump to to 1.5 it ignores the "soft" version in your > :dependencies, and chooses one in the range based on your other > dependencies. > > You should just need the :exclusion in clj-ns-browser. > > - > Nelson Morris As i'm responsible for the clj-ns-browser release... And although the dependency issue seems another 2 levels down, can i specify anything differently in my project file to prevent this? Or is this a bug in leiningen's dependency resolution? Or both... Regards, Frank. -- -- 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: byte-array woes
I just ran into that issue while I was constructing byte-arrays for secure-hash test cases. Ended-up using (byte-array (vector-of :byte 1 2 3 4)) to avoid writing the (byte-array [(byte 1)(byte 2)(byte 3)(byte 4)]). Transparently adding valid byte-number values to a byte-array makes sense and would be helpful. Thanks, FrankS. On Mar 2, 2013, at 2:49 PM, Karsten Schmidt wrote: > Thanks, Marko! I'd count this as a sort of bug though... at least in > terms of consistency, since it breaks expected behaviour as > established by other common array c'tor functions: > > (int-array [1 2 3]) => ok > (long-array [1 2 3]) => ok > (float-array [1 2 3]) => ok > (double-array [1 2 3]) => ok > (byte-array [1 2 3]) => fail > (short-array [1 2 3]) => fail > (char-array [1 2 3]) => fail, but bearable since you'd use shorts > anyway if you specify chars as numbers > > I had a look at clojure.lang.Numbers.java and found a fix for both > bytes & shorts: > > Whereas all the working array c'tors functions are using this pattern: > > array[i] = ((Number)s.first()).intValue(); > > ... the byte-array & short-array versions attempt to cast the sequence > items directly, i.e. > > array[i] = (Byte)s.first(); > > Changing this to the first pattern (via Number) fixes the issue and > I'll submit a patch for this... > > Hth! K. > -- > Karsten Schmidt > http://postspectacular.com | http://toxiclibs.org | http://toxi.co.uk > > On 2 March 2013 18:43, Marko Topolnik wrote: >> On Saturday, March 2, 2013 6:22:51 PM UTC+1, Karsten Schmidt wrote: >>> >>> >>> Is that a bug or can someone please explain why bytes seem to require >>> special treatment in Clojure? >> >> >> Calling it a bug wouldn't be entirely fair since it's a missing feature. I'd >> say this is filable as an enhancement request. >> >> -Marko >> >> -- >> -- >> 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. >> >> > > -- > -- > 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. > > -- -- 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.
ANN: Clojure Namespace Browser: clj-ns-browser 1.3.1 release
Small maintenance release that upgrades project's dependencies to Clojure 1.5
and Seesaw 1.4.3, but works fine with Clojure 1.4 also.
As Seesaw's Dave Ray stated it: "The one good reason to upgrade is if you're
planning on using Clojure 1.5 and don't feel like being confused by the horrors
of Maven dependency resolution."
For docs and code, see:
https://github.com/franks42/clj-ns-browser
Enjoy, Frank and Andy.
---
Clojure Namespace Browser (clj-ns-browser)
Clj-ns-browser is a graphical namespace/class/var browser for Clojure's doc
strings, source code, ClojureDocs.org examples & comments, and values. The
browser's GUI is inspired by Smalltalk class library browsers, and is based on
the Seesaw library.
Install & Start-up
For any project where you want to add the ability to browse your currently
loaded/unloaded namespaces for the available classes/vars/functions/macros/etc.
with their docs/source/values, you should add clj-ns-browser to your
:dev-dependencies list by adding to your project.clj:
;; Leiningen version 1
:dev-dependencies [[clj-ns-browser "1.3.1"]]
;; Leiningen version 2
:profiles {:dev {:dependencies [[clj-ns-browser "1.3.1"]]}}
Then fire-up your repl, refer to the sdoc macro in clj-ns-browser.sdoc, and
start the browser with (sdoc):
$ lein deps
$ lein repl
user=> (require 'clj-ns-browser.sdoc)
user=> (clj-ns-browser.sdoc/sdoc)
... and the browser window should popup on your screen - very easy!
--
--
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: Wrong clojure version depending on lein dependencies (was: ANN: Clojure 1.5)
clj-ns-browser 1.3.1 is released and addresses this issue by upgrading the project's dependencies to seesaw 1.4.3. For docs and code, please see "https://github.com/franks42/clj-ns-browser";. Enjoy, Frank. On Mar 2, 2013, at 10:57 PM, Dave Ray wrote: >>> As i'm responsible for the clj-ns-browser release... >>> And although the dependency issue seems another 2 levels down, can i >>> specify anything differently in my project file to prevent this? >> >> You could add the a similar exclusion for org.clojure/clojure in the >> seesaw dependency declaration, but I'd just wait for the next seesaw >> release which will handle it. > > Seesaw 1.4.3 is released and addresses this issue. Release notes here: > https://github.com/daveray/seesaw/wiki/Release-Notes > > Dave > > -- > -- > 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. > > -- -- 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: Wrong clojure version depending on lein dependencies
Excellent - thanks for letting me know - Frank. On Mar 3, 2013, at 11:37 PM, Tassilo Horn wrote: > Frank Siebenlist writes: > > Hi Frank, > >> clj-ns-browser 1.3.1 is released and addresses this issue by upgrading >> the project's dependencies to seesaw 1.4.3. > > With 1.3.1 I could remove all the :excusions again and it still picked > the right clojure version (1.5.0). > > Thanks, > Tassilo -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To 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: how to get SHA1 of a string?
Not sure if it's helpful in this context, but I've been playing with a more functional message-digest/secure-hashing interface recently. Please take a look at: https://github.com/franks42/clj.security.message-digest It's still a little raw, and probably more "educational" than practical right now, but my hope was that if could clarify some of the message-digesting workings. Would love to get some feedback... Enjoy, Frank. On Mar 4, 2013, at 10:09 AM, larry google groups wrote: >>> nonce (DigestUtils/md5Hex (random-string 32)) >>> nonce-encoded-base64 (Base64/encodeBase64 (.getBytes nonce)) >> >> Is this used somewhere? > > Yes, at the end, everything gets pulled together in a big string, > which is added as a header to the POST request: > > header (apply str " UsernameToken Username=\"" username "\" > PasswordDigest=\"" digest "\" Nonce=\"" nonce-encoded-base64 "\" > Created=\"" created "\"") > > As the developer from Omniture told me: > > "The nonce is transmitted in the header as base64 encoded. However, > the digest is formed with the raw binary version (aka decoded) version > of the string. The concept you have to understand is that the > authorization server is re-performing these critical steps on the back > end. If a step isn't done exactly in the client, the digest will > mismatch and cause an auth failure." > > > > On Mar 4, 12:49 pm, Aaron Cohen wrote: >> On Mon, Mar 4, 2013 at 11:12 AM, larry google groups < >> >> lawrencecloj...@gmail.com> wrote: expects its argument to be a byte array: >>> http://docs.oracle.com/javase/6/docs/api/java/security/MessageDigest >> which can be obtained from a string using String#getBytes. >> >>> I appreciate your suggestion. For most of the attempts that I have >>> made, I have used this code: >> >>> nonce (DigestUtils/md5Hex (random-string 32)) >>> nonce-encoded-base64 (Base64/encodeBase64 (.getBytes nonce)) >> >> Is this used somewhere? >> >>> date-formatter (new SimpleDateFormat "-MM-dd'T'HH:mm:ss'Z'") >>> created (.format date-formatter (new Date)) >>> digest-as-string (apply str nonce created secret) >> >> (str binary-array) returns the toString of the array, which is something >> like "[B@5d5d0293". That has nothing to do with the contents of the array. >> I think you want the base64 encoded string here. >> >> --Aaron > > -- > -- > 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. > > -- -- 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: byte-array woes
I gave it my vote - thanks for trying to fix this issue - FrankS. FrankS (from mobile) On Mar 4, 2013, at 6:30 AM, Karsten Schmidt wrote: > Hi Frank, I've added a patch to CLJ-766 with a potential fix. Also, > Andy F. kindly pointed out that interested parties should vote on that > issue to help increase its visibility... > > Add your 2 cents here (provided you've a CA): > http://dev.clojure.org/jira/browse/CLJ-766 > > Best, K. > -- > Karsten Schmidt > http://postspectacular.com | http://toxiclibs.org | http://toxi.co.uk > > > On 3 March 2013 00:01, Frank Siebenlist wrote: >> I just ran into that issue while I was constructing byte-arrays for >> secure-hash test cases. >> >> Ended-up using (byte-array (vector-of :byte 1 2 3 4)) to avoid writing the >> (byte-array [(byte 1)(byte 2)(byte 3)(byte 4)]). >> >> Transparently adding valid byte-number values to a byte-array makes sense >> and would be helpful. >> >> Thanks, FrankS. >> >> >> On Mar 2, 2013, at 2:49 PM, Karsten Schmidt wrote: >> >>> Thanks, Marko! I'd count this as a sort of bug though... at least in >>> terms of consistency, since it breaks expected behaviour as >>> established by other common array c'tor functions: >>> >>> (int-array [1 2 3]) => ok >>> (long-array [1 2 3]) => ok >>> (float-array [1 2 3]) => ok >>> (double-array [1 2 3]) => ok >>> (byte-array [1 2 3]) => fail >>> (short-array [1 2 3]) => fail >>> (char-array [1 2 3]) => fail, but bearable since you'd use shorts >>> anyway if you specify chars as numbers >>> >>> I had a look at clojure.lang.Numbers.java and found a fix for both >>> bytes & shorts: >>> >>> Whereas all the working array c'tors functions are using this pattern: >>> >>> array[i] = ((Number)s.first()).intValue(); >>> >>> ... the byte-array & short-array versions attempt to cast the sequence >>> items directly, i.e. >>> >>> array[i] = (Byte)s.first(); >>> >>> Changing this to the first pattern (via Number) fixes the issue and >>> I'll submit a patch for this... >>> >>> Hth! K. >>> -- >>> Karsten Schmidt >>> http://postspectacular.com | http://toxiclibs.org | http://toxi.co.uk >>> >>> On 2 March 2013 18:43, Marko Topolnik wrote: >>>> On Saturday, March 2, 2013 6:22:51 PM UTC+1, Karsten Schmidt wrote: >>>>> >>>>> >>>>> Is that a bug or can someone please explain why bytes seem to require >>>>> special treatment in Clojure? >>>> >>>> >>>> Calling it a bug wouldn't be entirely fair since it's a missing feature. >>>> I'd >>>> say this is filable as an enhancement request. >>>> >>>> -Marko >>>> >>>> -- >>>> -- >>>> 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. >>> >>> -- >>> -- >>> 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. >>>
Re: how to get SHA1 of a string?
> digest (-> (java.security.MessageDigest/getInstance "sha1") > .reset > (.update nonce-bytes) > (.update create-bytes) > (.update secret-bytes) > .digest) There may be an issue with this snippet of code as ".update" does not return anything… i.e. nil. -FS. On Mar 4, 2013, at 11:06 AM, larry google groups wrote: >> >> ;; Should "UsernameToken Username" really be unquoted in the following line? >> ;; All the other variable names are quoted > > Apparently, yes. The developer at Omniture reviewed it and said my > only problem was the way the passwordDigest was created. > > > > On Mar 4, 2:02 pm, Aaron Cohen wrote: >> I think you should try to avoid the string concatenation games. I'm not >> sure what your current code is, but I suspect you're still ending up with >> array toString's slipping in. >> >> How about the following? >> >> On Mon, Mar 4, 2013 at 1:31 PM, larry google groups < >> >> lawrencecloj...@gmail.com> wrote: >>> So, right now I am using this code: >> >>> (let [username (get-in @um/interactions [:omniture-api- >>> credentials :username]) >>> secret (get-in @um/interactions [:omniture-api-credentials :shared- >>> secret]) >>> nonce (DigestUtils/md5Hex (str (math/round (* (rand 1 ) 100 >>> nonce-encoded-base64 (Base64/encodeBase64 (.getBytes nonce)) >>> date-formatter (new SimpleDateFormat "-MM-dd'T'HH:mm:ss") >>> formatter gmt-timezone) >>> created (.format date-formatter (new Date)) >> >>nonce-bytes (.getBytes nonce) >>created-bytes (.getBytes created) >>secret-bytes (.getBytes secret) >>digest (-> (java.security.MessageDigest/getInstance "sha1") >> .reset >> (.update nonce-bytes) >> (.update create-bytes) >> (.update secret-bytes) >> .digest) >> digest-base64 (Base64/encodeBase64 digest) >> >> ;; Should "UsernameToken Username" really be unquoted in the following line? >> ;; All the other variable names are quoted >> header (apply str " UsernameToken Username=\"" username >> >> ;; You may want digest-base64 here? >> "\"PasswordDigest=\"" digest >> >> "\" Nonce=\"" nonce-encoded-base64 >> "\"Created=\"" created "\"")] >> header) > > -- > -- > 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. > > -- -- 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: how to get SHA1 of a string?
That should work. No need for .reset though as the initially constructed MessageDigest is already in its initial state. Be careful with .digest as it implicitly resets the MessageDigest, and calling it a second time gives you the digest of the initial state which is not what you want. (all that "incidental complexity" is why I started to write that functional interface ;-) ) -FS. On Mar 4, 2013, at 11:32 AM, Aaron Cohen wrote: > Ah darn, thanks for the catch. The following is uglier but should work I > guess. :\ > > digest (.digest >(doto (java.security.MessageDigest/getInstance "sha1") > .reset > (.update nonce-bytes) > (.update created-bytes) > (.update secret-bytes))) > > > On Mon, Mar 4, 2013 at 2:25 PM, Frank Siebenlist > wrote: > > digest (-> (java.security.MessageDigest/getInstance "sha1") > > .reset > > (.update nonce-bytes) > > (.update create-bytes) > > (.update secret-bytes) > > .digest) > > > There may be an issue with this snippet of code as ".update" does not return > anything… i.e. nil. > > -FS. > > > > On Mar 4, 2013, at 11:06 AM, larry google groups > wrote: > > >> > >> ;; Should "UsernameToken Username" really be unquoted in the following > >> line? > >> ;; All the other variable names are quoted > > > > Apparently, yes. The developer at Omniture reviewed it and said my > > only problem was the way the passwordDigest was created. > > > > > > > > On Mar 4, 2:02 pm, Aaron Cohen wrote: > >> I think you should try to avoid the string concatenation games. I'm not > >> sure what your current code is, but I suspect you're still ending up with > >> array toString's slipping in. > >> > >> How about the following? > >> > >> On Mon, Mar 4, 2013 at 1:31 PM, larry google groups < > >> > >> lawrencecloj...@gmail.com> wrote: > >>> So, right now I am using this code: > >> > >>> (let [username (get-in @um/interactions [:omniture-api- > >>> credentials :username]) > >>> secret (get-in @um/interactions [:omniture-api-credentials :shared- > >>> secret]) > >>> nonce (DigestUtils/md5Hex (str (math/round (* (rand 1 ) 100 > >>> nonce-encoded-base64 (Base64/encodeBase64 (.getBytes nonce)) > >>> date-formatter (new SimpleDateFormat "-MM-dd'T'HH:mm:ss") > >>> formatter gmt-timezone) > >>> created (.format date-formatter (new Date)) > >> > >>nonce-bytes (.getBytes nonce) > >>created-bytes (.getBytes created) > >>secret-bytes (.getBytes secret) > >>digest (-> (java.security.MessageDigest/getInstance "sha1") > >> .reset > >> (.update nonce-bytes) > >> (.update create-bytes) > >> (.update secret-bytes) > >> .digest) > >> digest-base64 (Base64/encodeBase64 digest) > >> > >> ;; Should "UsernameToken Username" really be unquoted in the following > >> line? > >> ;; All the other variable names are quoted > >> header (apply str " UsernameToken Username=\"" username > >> > >> ;; You may want digest-base64 here? > >> "\"PasswordDigest=\"" digest > >> > >> "\" Nonce=\"" nonce-encoded-base64 > >> "\"Created=\"" created "\"")] > >> header) > > > > -- > > -- > > 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 a
Re: how to get SHA1 of a string?
You should get a new, separate instance for every digest you would like to generate "concurrently". Nothing, i.e. no mutable state, is shared between different MessageDigest instances in the subsequent digesting/secure-hashing. The .reset is only used if you want to give up you current effort without generating the final digest with .digest as the latter already does the reset implicitly. After the reset you can reuse that same MessageDigest object for a new digest. You can optionally .clone a MessageDigest object is you want to have a final digest value for a partial byte-list. For example, if you want the digest for both "a" and "abc", you could take a new MessageDigest object, .update it for "a"'s bytes, .clone that MessageDigest, use one copy to generate the final .digest for "a", and use the other copy to add the digest of "bc"'s bytes and .digest that. Ough… hope that's clear... -FS. On Mar 4, 2013, at 12:15 PM, Aaron Cohen wrote: > I'm not familiar with the class, but it seems that MessageDigest/getInstance > might retrieve some shared instance that could theoretically need to be > reset, no? > > > On Mon, Mar 4, 2013 at 2:43 PM, Frank Siebenlist > wrote: > That should work. > > No need for .reset though as the initially constructed MessageDigest is > already in its initial state. > > Be careful with .digest as it implicitly resets the MessageDigest, and > calling it a second time gives you the digest of the initial state which is > not what you want. > > (all that "incidental complexity" is why I started to write that functional > interface ;-) ) > > -FS. > > > On Mar 4, 2013, at 11:32 AM, Aaron Cohen wrote: > > > Ah darn, thanks for the catch. The following is uglier but should work I > > guess. :\ > > > > digest (.digest > >(doto (java.security.MessageDigest/getInstance "sha1") > > .reset > > (.update nonce-bytes) > > (.update created-bytes) > > (.update secret-bytes))) > > > > > > On Mon, Mar 4, 2013 at 2:25 PM, Frank Siebenlist > > wrote: > > > digest (-> (java.security.MessageDigest/getInstance "sha1") > > > .reset > > > (.update nonce-bytes) > > > (.update create-bytes) > > > (.update secret-bytes) > > > .digest) > > > > > > There may be an issue with this snippet of code as ".update" does not > > return anything… i.e. nil. > > > > -FS. > > > > > > > > On Mar 4, 2013, at 11:06 AM, larry google groups > > wrote: > > > > >> > > >> ;; Should "UsernameToken Username" really be unquoted in the following > > >> line? > > >> ;; All the other variable names are quoted > > > > > > Apparently, yes. The developer at Omniture reviewed it and said my > > > only problem was the way the passwordDigest was created. > > > > > > > > > > > > On Mar 4, 2:02 pm, Aaron Cohen wrote: > > >> I think you should try to avoid the string concatenation games. I'm not > > >> sure what your current code is, but I suspect you're still ending up with > > >> array toString's slipping in. > > >> > > >> How about the following? > > >> > > >> On Mon, Mar 4, 2013 at 1:31 PM, larry google groups < > > >> > > >> lawrencecloj...@gmail.com> wrote: > > >>> So, right now I am using this code: > > >> > > >>> (let [username (get-in @um/interactions [:omniture-api- > > >>> credentials :username]) > > >>> secret (get-in @um/interactions [:omniture-api-credentials :shared- > > >>> secret]) > > >>> nonce (DigestUtils/md5Hex (str (math/round (* (rand 1 ) 100 > > >>> nonce-encoded-base64 (Base64/encodeBase64 (.getBytes nonce)) > > >>> date-formatter (new SimpleDateFormat "-MM-dd'T'HH:mm:ss") > > >>> formatter gmt-timezone) > > >>> created (.format date-formatter (new Date)) > > >> > > >>nonce-bytes (.getBytes nonce) > > >>created-bytes (.getBytes created) > > >>secret-bytes (.getBytes secret) > > >>digest (-> (java.security.MessageDigest/getInstance "sha1") > > >>
Re: how to get SHA1 of a string?
Hi Larry,
One approach that helps a lot when trying to figure out where the issue is with
all that message digesting, is by using well-known test cases. If you look at:
http://en.wikipedia.org/wiki/SHA-1
you will find the test cases:
SHA1("The quick brown fox jumps over the lazy dog") =
2fd4e1c6 7a2d28fc ed849ee1 bb76e739 1b93eb12
and
SHA1("") =
da39a3ee 5e6b4b0d 3255bfef 95601890 afd80709
If you split up your "nonce created secret" as partial strings of "The quick
brown fox jumps over the lazy dog", then you know what hex'ified digest to
expect, and helps you to track-down/eliminate errors.
The empty string digest is also important to have, because the initial
MessageDigest object, or any reset one, or after a call to .digest, will
generate that particular digest value. In other words, if you see that digest
then you're probably working with a (accidentally?) reset MessageDigest object.
Hope that helps.
-FrankS.
On Mar 4, 2013, at 12:38 PM, larry google groups
wrote:
> To be clear about an earlier point, if I do this:
>
>digest-as-string (apply str nonce created secret)
>
> and then print this to the terminal, I can see it really is just a
> string made of these 3 items. Just a plain string, exactly what I
> assumed.
>
>
> On Mar 4, 2:25 pm, Frank Siebenlist
> wrote:
>>> digest (-> (java.security.MessageDigest/getInstance "sha1")
>>> .reset
>>> (.update nonce-bytes)
>>> (.update create-bytes)
>>> (.update secret-bytes)
>>> .digest)
>>
>> There may be an issue with this snippet of code as ".update" does not return
>> anything… i.e. nil.
>>
>> -FS.
>>
>> On Mar 4, 2013, at 11:06 AM, larry google groups
>> wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>> ;; Should "UsernameToken Username" really be unquoted in the following
>>>> line?
>>>> ;; All the other variable names are quoted
>>
>>> Apparently, yes. The developer at Omniture reviewed it and said my
>>> only problem was the way the passwordDigest was created.
>>
>>> On Mar 4, 2:02 pm, Aaron Cohen wrote:
>>>> I think you should try to avoid the string concatenation games. I'm not
>>>> sure what your current code is, but I suspect you're still ending up with
>>>> array toString's slipping in.
>>
>>>> How about the following?
>>
>>>> On Mon, Mar 4, 2013 at 1:31 PM, larry google groups <
>>
>>>> lawrencecloj...@gmail.com> wrote:
>>>>> So, right now I am using this code:
>>
>>>>> (let [username (get-in @um/interactions [:omniture-api-
>>>>> credentials :username])
>>>>> secret (get-in @um/interactions [:omniture-api-credentials :shared-
>>>>> secret])
>>>>> nonce (DigestUtils/md5Hex (str (math/round (* (rand 1 ) 100
>>>>> nonce-encoded-base64 (Base64/encodeBase64 (.getBytes nonce))
>>>>> date-formatter (new SimpleDateFormat "-MM-dd'T'HH:mm:ss")
>>>>> formatter gmt-timezone)
>>>>> created (.format date-formatter (new Date))
>>
>>>>nonce-bytes (.getBytes nonce)
>>>>created-bytes (.getBytes created)
>>>>secret-bytes (.getBytes secret)
>>>>digest (-> (java.security.MessageDigest/getInstance "sha1")
>>>> .reset
>>>> (.update nonce-bytes)
>>>> (.update create-bytes)
>>>> (.update secret-bytes)
>>>> .digest)
>>>> digest-base64 (Base64/encodeBase64 digest)
>>
>>>> ;; Should "UsernameToken Username" really be unquoted in the following
>>>> line?
>>>> ;; All the other variable names are quoted
>>>> header (apply str " UsernameToken Username=\"" username
>>
>>>> ;; You may want digest-base64 here?
>>>> "\"PasswordDigest=\"" digest
>>
>>>> "\" Nonce=\"" nonce-encoded-base64
>>>> "\"Created=\"" created "\"")]
>>>> header)
>>
>>> --
>>> --
>>>
Re: how to get SHA1 of a string?
.digest returns a byte array - so your PasswordDigest value is unprintable and is not fit for any header/URL. Not sure what this base64-encode function does exactly, but normally base64 encoding takes a bunch of bytes already, so the (commented-out) "digest-base64 (base64-encode (.getBytes digest))" does not need the (.getBytes …) transformation as your digest consists already of bytes. Note that base64 encoded stuff is not url/html safe and has to be encoded also before sending it over the http-wire. -FS. On Mar 4, 2013, at 1:00 PM, larry google groups wrote: > Thank you for the suggestions. If I do this: > > (let [username (get-in @um/interactions [:omniture-api- > credentials :username]) >secret (get-in @um/interactions [:omniture-api- > credentials :shared-secret]) >random-number (math/round (* (rand 1 ) 100)) >nonce (DigestUtils/md5Hex (str random-number)) >nonce-encoded-base64 (base64-encode (.getBytes > nonce)) >date-formatter (new SimpleDateFormat "-MM- > dd'T'HH:mm:ss") >created (.format date-formatter (new Date)) >nonce-as-bytes (.getBytes nonce) >created-as-bytes (.getBytes created) >secret-as-bytes (.getBytes secret) >digest (.digest >(doto (java.security.MessageDigest/ > getInstance "sha1") > .reset > (.update nonce-as-bytes) > (.update created-as-bytes) > (.update secret-as- > bytes))) > ;; ;;digest-base64 (base64-encode (.getBytes > digest)) >header (apply str " UsernameToken Username=\"" > username "\" PasswordDigest=\"" digest "\" Nonce=\"" nonce-encoded- > base64 "\" Created=\"" created "\"")] >header) > > > I end up with, in part: > > PasswordDigest="[B@26f7b2f4" > Nonce="Y2MwN2JiYzA5MDlmZjE2ZjExMGYzMjRhODA2Yjc5ODc=" > Created="2013-03-04T15:57:52" > > Which I think is still incorrect. > > I also tried this with the PasswordDigest base64 encoded, and that did > not work either. > > > > > > > > On Mar 4, 2:43 pm, Frank Siebenlist > wrote: >> That should work. >> >> No need for .reset though as the initially constructed MessageDigest is >> already in its initial state. >> >> Be careful with .digest as it implicitly resets the MessageDigest, and >> calling it a second time gives you the digest of the initial state which is >> not what you want. >> >> (all that "incidental complexity" is why I started to write that functional >> interface ;-) ) >> >> -FS. >> >> On Mar 4, 2013, at 11:32 AM, Aaron Cohen wrote: >> >> >> >> >> >> >> >>> Ah darn, thanks for the catch. The following is uglier but should work I >>> guess. :\ >> >>> digest (.digest >>>(doto (java.security.MessageDigest/getInstance "sha1") >>> .reset >>> (.update nonce-bytes) >>> (.update created-bytes) >>> (.update secret-bytes))) >> >>> On Mon, Mar 4, 2013 at 2:25 PM, Frank Siebenlist >>> wrote: >>>> digest (-> (java.security.MessageDigest/getInstance "sha1") >>>> .reset >>>> (.update nonce-bytes) >>>> (.update create-bytes) >>>> (.update secret-bytes) >>>> .digest) >> >>> There may be an issue with this snippet of code as ".update" does not >>> return anything… i.e. nil. >> >>> -FS. >> >>> On Mar 4, 2013, at 11:06 AM, larry google groups >>> wrote: >> >>>>> ;; Should "UsernameToken Username" really be unquoted in the following >>>>> line? >>>>> ;; All the other variable names are quoted >> >>>> Apparently, yes. The developer at Omniture reviewed it and said my >>>> only problem was the way the passwordDigest was created. >> >>>> On Mar 4, 2:02 pm, Aaron Cohen wrote: >>>>> I think you should try to avoid the string concatenation games
Re: how to get SHA1 of a string?
Yup, in your case, with: >> digest (.digest >>(doto (java.security.MessageDigest/getInstance "sha1") >> .reset >> (.update nonce-bytes) >> (.update created-bytes) >> (.update secret-bytes))) you do not have to worry about calling .digest twice on the same instance. -FS. On Mar 4, 2013, at 1:22 PM, larry google groups wrote: > >> Be careful with .digest as it implicitly resets the MessageDigest, and >> calling it a second time gives you the digest of the initial state >> which is not what you want. > > I am somewhat ignorant of how mutable Java variables behave inside of > Clojure. Can I assume that the instance of MessageDigest disappears as > soon as the function returns? If I call the function again, I am > creating a new instance MessageDigest, and so I don't have to worry > about calling .digest()? > > > > On Mar 4, 2:43 pm, Frank Siebenlist > wrote: >> That should work. >> >> No need for .reset though as the initially constructed MessageDigest is >> already in its initial state. >> >> Be careful with .digest as it implicitly resets the MessageDigest, and >> calling it a second time gives you the digest of the initial state which is >> not what you want. >> >> (all that "incidental complexity" is why I started to write that functional >> interface ;-) ) >> >> -FS. >> >> On Mar 4, 2013, at 11:32 AM, Aaron Cohen wrote: >> >> >> >> >> >> >> >>> Ah darn, thanks for the catch. The following is uglier but should work I >>> guess. :\ >> >>> digest (.digest >>> (doto (java.security.MessageDigest/getInstance "sha1") >>> .reset >>> (.update nonce-bytes) >>> (.update created-bytes) >>> (.update secret-bytes))) >> >>> On Mon, Mar 4, 2013 at 2:25 PM, Frank Siebenlist >>> wrote: >>>> digest (-> (java.security.MessageDigest/getInstance "sha1") >>>> .reset >>>> (.update nonce-bytes) >>>> (.update create-bytes) >>>> (.update secret-bytes) >>>> .digest) >> >>> There may be an issue with this snippet of code as ".update" does not >>> return anything… i.e. nil. >> >>> -FS. >> >>> On Mar 4, 2013, at 11:06 AM, larry google groups >>> wrote: >> >>>>> ;; Should "UsernameToken Username" really be unquoted in the following >>>>> line? >>>>> ;; All the other variable names are quoted >> >>>> Apparently, yes. The developer at Omniture reviewed it and said my >>>> only problem was the way the passwordDigest was created. >> >>>> On Mar 4, 2:02 pm, Aaron Cohen wrote: >>>>> I think you should try to avoid the string concatenation games. I'm not >>>>> sure what your current code is, but I suspect you're still ending up with >>>>> array toString's slipping in. >> >>>>> How about the following? >> >>>>> On Mon, Mar 4, 2013 at 1:31 PM, larry google groups < >> >>>>> lawrencecloj...@gmail.com> wrote: >>>>>> So, right now I am using this code: >> >>>>>> (let [username (get-in @um/interactions [:omniture-api- >>>>>> credentials :username]) >>>>>> secret (get-in @um/interactions [:omniture-api-credentials :shared- >>>>>> secret]) >>>>>> nonce (DigestUtils/md5Hex (str (math/round (* (rand 1 ) 100 >>>>>> nonce-encoded-base64 (Base64/encodeBase64 (.getBytes nonce)) >>>>>> date-formatter (new SimpleDateFormat "-MM-dd'T'HH:mm:ss") >>>>>> formatter gmt-timezone) >>>>>> created (.format date-formatter (new Date)) >> >>>>>nonce-bytes (.getBytes nonce) >>>>>created-bytes (.getBytes created) >>>>>secret-bytes (.getBytes secret) >>>>>digest (-> (java.security.MessageDigest/getInstance "sha1") >>>>> .reset >>>>> (.update nonce-bytes) >>>>>
Re: how to get SHA1 of a string?
Glad Larry has working code now... As I mentioned before in this thread, I'm working on this functional interface for the message-digesting/secure-hashing, and this whole discussion reads like a use case for the "why?" ;-) It "proofs" to me that there may be real value in a more user-friendly approach than the one offered by java.security.MessageDigest. So instead of writing: (let [... nonce-as-bytes (.getBytes nonce) created-as-bytes (.getBytes created) secret-as-bytes (.getBytes secret) digest (.digest (doto (java.security.MessageDigest/getInstance "sha1") .reset (.update nonce-as-bytes) (.update created-as-bytes) (.update secret-as-bytes))) …] my library lets you write: (let [… digest (md/digest :sha-1 :utf-8 nonce created secret) …] and the advantages of the more functional approach is much more than just saving a few lines of code! Although it still needs some more work, any feedback on "https://github.com/franks42/clj.security.message-digest"; is much appreciated. Regards, FrankS. On Mar 4, 2013, at 1:31 PM, larry google groups wrote: > I finally got this to work. Many thanks for all of the help that I was > given here. > > The final, winning combination was: > > (let [username (get-in @um/interactions [:omniture-api- > credentials :username]) >secret (get-in @um/interactions [:omniture-api-credentials :shared- > secret]) >random-number (math/round (* (rand 1 ) 100)) >nonce (DigestUtils/md5Hex (str random-number)) >nonce-encoded-base64 (base64-encode (.getBytes nonce)) >date-formatter (new SimpleDateFormat "-MM-dd'T'HH:mm:ss") >created (.format date-formatter (new Date)) >nonce-as-bytes (.getBytes nonce) >created-as-bytes (.getBytes created) >secret-as-bytes (.getBytes secret) >digest (.digest >(doto (java.security.MessageDigest/getInstance > "sha1") > .reset > (.update nonce-as-bytes) > (.update created-as-bytes) > (.update secret-as-bytes))) >digest-base64 (base64-encode digest) >header (apply str " UsernameToken Username=\"" username "\" > PasswordDigest=\"" digest-base64 "\" Nonce=\"" nonce-encoded-base64 > "\" Created=\"" created "\"")] > header) > > > > On Mar 4, 10:47 am, larry google groups > wrote: >> I have been having problems making an API call to Omniture. I have >> exchanged a dozen emails with a developer at Omniture, and he gave me >> the impression that I was constructing my security codes incorrectly. >> So now I am confronting my ignorance over how Java handles certain >> conversions. >> >> The developer at Omniture sent me this explanation in an email: >> >> " The security digest is formed from a sha1 hash of the following >> string concatenation: >> digest = sha1( Binary Nonce + Created Time String + API Secret Hex >> String (32 bytes) ) " >> >> I have been struggling with this for several days and I have tried at >> least (literally) 200 variations on this bit of code: >> >> (let [username (get-in @um/interactions [:omniture-api- >> credentials :username]) >> secret (get-in @um/interactions [:omniture-api- >> credentials :shared-secret]) >> nonce (DigestUtils/md5Hex (random-string 32)) >> nonce-encoded-base64 (Base64/encodeBase64 (.getBytes nonce)) >> date-formatter (new SimpleDateFormat "-MM- >> dd'T'HH:mm:ss'Z'") >> created (.format date-formatter (new Date)) >> digest-as-string (apply str (.getBytes nonce) created secret) >> digest (.digest (java.security.MessageDigest/getInstance "sha1") >> digest-as-string) >> header (apply str " UsernameToken Username=\"" username "\" >> PasswordDigest=\"" digest "\" Nonce=\"" nonce-encoded-base64 "\" >> Created=\"" created "\"")] >> header) >> >> This version gives me: >> >> "Exception in the main function: " #> java.lang.ClassCastException: java.lang.String cannot be cast to [B> >> >> For a long time I was using this for the last 3 lines: >> >> digest-as-string (apply str nonce created secret) >> digest (.digest (java.security.MessageDigest/getInstance "sha1") >> (.getByes digest-as-string)) >> header (apply str " UsernameToken Username=\"" username "\" >> PasswordDigest=\"" digest "\" Nonce=\"" nonce-encoded-base64 "\" >> Created=\"" created "\"") >> >> Here I wrapped the whole digest-as-string in (.getBytes) so there was >> no Java error, but this simply did not work when I pinged Omniture. >> >> In his email, he seems to suggest that the nonce should be binary but >> that the date and the secret should be strings: >> >> digest = sha1( Binary Nonce + Created Time String + API Secret Hex >> String (32 bytes) ) " >> >> But, as I said, when I tried this I got the ClassCastExce
Re: how to get SHA1 of a string?
If your code is for production… do not use my code! It's pretty much written over the weekend and it's "security code", meaning that it deserves much more scrutiny than "ordinary" code. As mentioned in the readme, it's more an "educational exercise", although it was good to see you struggling as it validated my concerns about the java library's approach ;-) Don't even know if I'm willing to maintain it either… Sorry for the bad news - I was just trying to sollicit feedback about alternative interfaces for the secure hashing. Regards, FrankS. On Mar 4, 2013, at 3:09 PM, larry google groups wrote: > Frank, > > Any idea when you might release your code in a stable form? I am using > this code at work so I am nervous about using code that is still > marked SNAPSHOT. Lein reminds me not to use a SNAPSHOT: > > Could not find metadata org.clojars.franks42:clj.security.message- > digest:0.1.0-SNAPSHOT/maven-metadata.xml in central (http:// > repo1.maven.org/maven2) > Could not find metadata org.clojars.franks42:clj.security.message- > digest:0.1.0-SNAPSHOT/maven-metadata.xml in central-proxy (https:// > repository.sonatype.org/content/repositories/centralm1/) > Retrieving org/clojars/franks42/clj.security.message-digest/0.1.0- > SNAPSHOT/maven-metadata.xml (1k) >from https://clojars.org/repo/ > Could not find artifact org.clojars.franks42:clj.security.message- > digest:pom:0.1.0-20130304.220822-1 in central (http://repo1.maven.org/ > maven2) > Retrieving org/clojars/franks42/clj.security.message-digest/0.1.0- > SNAPSHOT/clj.security.message-digest-0.1.0-20130304.220822-1.pom (3k) >from https://clojars.org/repo/ > Retrieving org/clojure/clojure/1.5.0/clojure-1.5.0.pom (6k) >from http://repo1.maven.org/maven2/ > Retrieving org/clojars/franks42/clj.security.message-digest/0.1.0- > SNAPSHOT/clj.security.message-digest-0.1.0-20130304.220822-1.jar (6k) >from https://clojars.org/repo/ > Compiling 1 source files to /Users/lkrubner/projects/multi-platform- > data-visualization/mpdv-clojure/target/classes > Release versions may not depend upon snapshots. > Freeze snapshots to dated versions or set the > LEIN_SNAPSHOTS_IN_RELEASE environment variable to override. > > > > > > > On Mar 4, 4:55 pm, Frank Siebenlist > wrote: >> Glad Larry has working code now... >> >> As I mentioned before in this thread, I'm working on this functional >> interface for the message-digesting/secure-hashing, and this whole >> discussion reads like a use case for the "why?" ;-) >> >> It "proofs" to me that there may be real value in a more user-friendly >> approach than the one offered by java.security.MessageDigest. >> >> So instead of writing: >> >> (let [... >> nonce-as-bytes (.getBytes nonce) >> created-as-bytes (.getBytes created) >> secret-as-bytes (.getBytes secret) >> digest (.digest >> (doto (java.security.MessageDigest/getInstance "sha1") >> .reset >>(.update nonce-as-bytes) >>(.update created-as-bytes) >> (.update secret-as-bytes))) >> …] >> >> my library lets you write: >> >> (let [… >> digest (md/digest :sha-1 :utf-8 nonce created secret) >> …] >> >> and the advantages of the more functional approach is much more than just >> saving a few lines of code! >> >> Although it still needs some more work, any feedback on >> "https://github.com/franks42/clj.security.message-digest"; >> is much appreciated. >> >> Regards, FrankS. >> >> On Mar 4, 2013, at 1:31 PM, larry google groups >> wrote: >> >> >> >> >> >> >> >>> I finally got this to work. Many thanks for all of the help that I was >>> given here. >> >>> The final, winning combination was: >> >>> (let [username (get-in @um/interactions [:omniture-api- >>> credentials :username]) >>>secret (get-in @um/interactions [:omniture-api-credentials :shared- >>> secret]) >>>random-number (math/round (* (rand 1 ) 100)) >>>nonce (DigestUtils/md5Hex (str random-number)) >>>nonce-encoded-base64 (base64-encode (.getBytes nonce)) >>>date-formatter (new SimpleDateFormat "-MM-dd'T'HH:mm:ss") >>>created (.format date-formatter (new Date)) >>>nonce-as-bytes (.getBytes nonce) >>>created-
Re: how to get SHA1 of a string?
Larry, What I can advise though, is to look at my library code and it may give you different perspectives. Furthermore, copy, borrow, and steal what you like and make it your own. -FS. On Mar 4, 2013, at 3:17 PM, Frank Siebenlist wrote: > If your code is for production… do not use my code! > > It's pretty much written over the weekend and it's "security code", meaning > that it deserves much more scrutiny than "ordinary" code. > > As mentioned in the readme, it's more an "educational exercise", although it > was good to see you struggling as it validated my concerns about the java > library's approach ;-) > > Don't even know if I'm willing to maintain it either… > > Sorry for the bad news - I was just trying to sollicit feedback about > alternative interfaces for the secure hashing. > > Regards, FrankS. > > > On Mar 4, 2013, at 3:09 PM, larry google groups > wrote: > >> Frank, >> >> Any idea when you might release your code in a stable form? I am using >> this code at work so I am nervous about using code that is still >> marked SNAPSHOT. Lein reminds me not to use a SNAPSHOT: >> >> Could not find metadata org.clojars.franks42:clj.security.message- >> digest:0.1.0-SNAPSHOT/maven-metadata.xml in central (http:// >> repo1.maven.org/maven2) >> Could not find metadata org.clojars.franks42:clj.security.message- >> digest:0.1.0-SNAPSHOT/maven-metadata.xml in central-proxy (https:// >> repository.sonatype.org/content/repositories/centralm1/) >> Retrieving org/clojars/franks42/clj.security.message-digest/0.1.0- >> SNAPSHOT/maven-metadata.xml (1k) >> from https://clojars.org/repo/ >> Could not find artifact org.clojars.franks42:clj.security.message- >> digest:pom:0.1.0-20130304.220822-1 in central (http://repo1.maven.org/ >> maven2) >> Retrieving org/clojars/franks42/clj.security.message-digest/0.1.0- >> SNAPSHOT/clj.security.message-digest-0.1.0-20130304.220822-1.pom (3k) >> from https://clojars.org/repo/ >> Retrieving org/clojure/clojure/1.5.0/clojure-1.5.0.pom (6k) >> from http://repo1.maven.org/maven2/ >> Retrieving org/clojars/franks42/clj.security.message-digest/0.1.0- >> SNAPSHOT/clj.security.message-digest-0.1.0-20130304.220822-1.jar (6k) >> from https://clojars.org/repo/ >> Compiling 1 source files to /Users/lkrubner/projects/multi-platform- >> data-visualization/mpdv-clojure/target/classes >> Release versions may not depend upon snapshots. >> Freeze snapshots to dated versions or set the >> LEIN_SNAPSHOTS_IN_RELEASE environment variable to override. >> >> >> >> >> >> >> On Mar 4, 4:55 pm, Frank Siebenlist >> wrote: >>> Glad Larry has working code now... >>> >>> As I mentioned before in this thread, I'm working on this functional >>> interface for the message-digesting/secure-hashing, and this whole >>> discussion reads like a use case for the "why?" ;-) >>> >>> It "proofs" to me that there may be real value in a more user-friendly >>> approach than the one offered by java.security.MessageDigest. >>> >>> So instead of writing: >>> >>> (let [... >>>nonce-as-bytes (.getBytes nonce) >>>created-as-bytes (.getBytes created) >>>secret-as-bytes (.getBytes secret) >>>digest (.digest >>> (doto (java.security.MessageDigest/getInstance "sha1") >>> .reset >>> (.update nonce-as-bytes) >>> (.update created-as-bytes) >>>(.update secret-as-bytes))) >>> …] >>> >>> my library lets you write: >>> >>> (let [… >>>digest (md/digest :sha-1 :utf-8 nonce created secret) >>> …] >>> >>> and the advantages of the more functional approach is much more than just >>> saving a few lines of code! >>> >>> Although it still needs some more work, any feedback on >>> "https://github.com/franks42/clj.security.message-digest"; >>> is much appreciated. >>> >>> Regards, FrankS. >>> >>> On Mar 4, 2013, at 1:31 PM, larry google groups >>> wrote: >>> >>> >>> >>> >>> >>> >>> >>>> I finally got this to work. Many thanks for all of the help that I was >>>> given here. >>> >>>>
Re: how to get SHA1 of a string?
Hi Mark, Thanks for sharing! I like the approach of hiding all the interaction with the java.security.MessageDigest library, and returning the pair of matching digest&verify functions - it will avoid many mistakes. As far as the presented algorithm is concerned, it may be more prudent to stick with bcrypt and friends though… Regards, Frank. On Mar 4, 2013, at 7:32 PM, Mark C wrote: > For another cut at a hashing interface, you may want to look at one I made > specifically for passwords. You make a password hasher by passing in > algorithm, salt length, and iterations, and you get back a map containing a > pair of complementary functions: one that digests, the other that verifies. > https://gist.github.com/mchampine/868342 > > Example: Digester/verifier pair using SHA-256 with 16 bytes salt and 10k > iterations > > (def strongPWHasher (pwfuncs "SHA-256" 16 1)) ; make the > digester/verifier pair > (def hashed-pw ((strongPWHasher :digest) "mysecret")) ; hash the password > ((strongPWHasher :verify) "mysecret" hashed-pw); verify it > > M. > > On Monday, March 4, 2013 6:46:07 PM UTC-5, FrankS wrote: > Larry, > > What I can advise though, is to look at my library code and it may give you > different perspectives. > > Furthermore, copy, borrow, and steal what you like and make it your own. > > -FS. > > > On Mar 4, 2013, at 3:17 PM, Frank Siebenlist wrote: > > > If your code is for production… do not use my code! > > > > It's pretty much written over the weekend and it's "security code", meaning > > that it deserves much more scrutiny than "ordinary" code. > > > > As mentioned in the readme, it's more an "educational exercise", although > > it was good to see you struggling as it validated my concerns about the > > java library's approach ;-) > > > > Don't even know if I'm willing to maintain it either… > > > > Sorry for the bad news - I was just trying to sollicit feedback about > > alternative interfaces for the secure hashing. > > > > Regards, FrankS. > > > > > > On Mar 4, 2013, at 3:09 PM, larry google groups > > wrote: > > > >> Frank, > >> > >> Any idea when you might release your code in a stable form? I am using > >> this code at work so I am nervous about using code that is still > >> marked SNAPSHOT. Lein reminds me not to use a SNAPSHOT: > >> > >> Could not find metadata org.clojars.franks42:clj.security.message- > >> digest:0.1.0-SNAPSHOT/maven-metadata.xml in central (http:// > >> repo1.maven.org/maven2) > >> Could not find metadata org.clojars.franks42:clj.security.message- > >> digest:0.1.0-SNAPSHOT/maven-metadata.xml in central-proxy (https:// > >> repository.sonatype.org/content/repositories/centralm1/) > >> Retrieving org/clojars/franks42/clj.security.message-digest/0.1.0- > >> SNAPSHOT/maven-metadata.xml (1k) > >> from https://clojars.org/repo/ > >> Could not find artifact org.clojars.franks42:clj.security.message- > >> digest:pom:0.1.0-20130304.220822-1 in central (http://repo1.maven.org/ > >> maven2) > >> Retrieving org/clojars/franks42/clj.security.message-digest/0.1.0- > >> SNAPSHOT/clj.security.message-digest-0.1.0-20130304.220822-1.pom (3k) > >> from https://clojars.org/repo/ > >> Retrieving org/clojure/clojure/1.5.0/clojure-1.5.0.pom (6k) > >> from http://repo1.maven.org/maven2/ > >> Retrieving org/clojars/franks42/clj.security.message-digest/0.1.0- > >> SNAPSHOT/clj.security.message-digest-0.1.0-20130304.220822-1.jar (6k) > >> from https://clojars.org/repo/ > >> Compiling 1 source files to /Users/lkrubner/projects/multi-platform- > >> data-visualization/mpdv-clojure/target/classes > >> Release versions may not depend upon snapshots. > >> Freeze snapshots to dated versions or set the > >> LEIN_SNAPSHOTS_IN_RELEASE environment variable to override. > >> > >> > >> > >> > >> > >> > >> On Mar 4, 4:55 pm, Frank Siebenlist > >> wrote: > >>> Glad Larry has working code now... > >>> > >>> As I mentioned before in this thread, I'm working on this functional > >>> interface for the message-digesting/secure-hashing, and this whole > >>> discussion reads like a use case for the "why?" ;-) > >>> > >>> It "proofs" to me th
Re: how to get SHA1 of a string?
I just became aware of this crypto-password clojure-library by compojure/hiccup/codox's James Reeve: https://github.com/weavejester/crypto-password Supports bcrypt, script and pbkdf2. Very well designed and easy to use! This should be your goto-library for secure hashing of passwords!!! -Frank. On Mar 4, 2013, at 10:52 PM, Frank Siebenlist wrote: > Hi Mark, > > Thanks for sharing! > > I like the approach of hiding all the interaction with the > java.security.MessageDigest library, > and returning the pair of matching digest&verify functions - it will avoid > many mistakes. > > As far as the presented algorithm is concerned, it may be more prudent to > stick with bcrypt and friends though… > > Regards, Frank. > > > On Mar 4, 2013, at 7:32 PM, Mark C wrote: > >> For another cut at a hashing interface, you may want to look at one I made >> specifically for passwords. You make a password hasher by passing in >> algorithm, salt length, and iterations, and you get back a map containing a >> pair of complementary functions: one that digests, the other that verifies. >> https://gist.github.com/mchampine/868342 >> >> Example: Digester/verifier pair using SHA-256 with 16 bytes salt and 10k >> iterations >> >> (def strongPWHasher (pwfuncs "SHA-256" 16 1)) ; make the >> digester/verifier pair >> (def hashed-pw ((strongPWHasher :digest) "mysecret")) ; hash the password >> ((strongPWHasher :verify) "mysecret" hashed-pw); verify it >> >> M. >> >> On Monday, March 4, 2013 6:46:07 PM UTC-5, FrankS wrote: >> Larry, >> >> What I can advise though, is to look at my library code and it may give you >> different perspectives. >> >> Furthermore, copy, borrow, and steal what you like and make it your own. >> >> -FS. >> >> >> On Mar 4, 2013, at 3:17 PM, Frank Siebenlist wrote: >> >>> If your code is for production… do not use my code! >>> >>> It's pretty much written over the weekend and it's "security code", meaning >>> that it deserves much more scrutiny than "ordinary" code. >>> >>> As mentioned in the readme, it's more an "educational exercise", although >>> it was good to see you struggling as it validated my concerns about the >>> java library's approach ;-) >>> >>> Don't even know if I'm willing to maintain it either… >>> >>> Sorry for the bad news - I was just trying to sollicit feedback about >>> alternative interfaces for the secure hashing. >>> >>> Regards, FrankS. >>> >>> >>> On Mar 4, 2013, at 3:09 PM, larry google groups >>> wrote: >>> >>>> Frank, >>>> >>>> Any idea when you might release your code in a stable form? I am using >>>> this code at work so I am nervous about using code that is still >>>> marked SNAPSHOT. Lein reminds me not to use a SNAPSHOT: >>>> >>>> Could not find metadata org.clojars.franks42:clj.security.message- >>>> digest:0.1.0-SNAPSHOT/maven-metadata.xml in central (http:// >>>> repo1.maven.org/maven2) >>>> Could not find metadata org.clojars.franks42:clj.security.message- >>>> digest:0.1.0-SNAPSHOT/maven-metadata.xml in central-proxy (https:// >>>> repository.sonatype.org/content/repositories/centralm1/) >>>> Retrieving org/clojars/franks42/clj.security.message-digest/0.1.0- >>>> SNAPSHOT/maven-metadata.xml (1k) >>>> from https://clojars.org/repo/ >>>> Could not find artifact org.clojars.franks42:clj.security.message- >>>> digest:pom:0.1.0-20130304.220822-1 in central (http://repo1.maven.org/ >>>> maven2) >>>> Retrieving org/clojars/franks42/clj.security.message-digest/0.1.0- >>>> SNAPSHOT/clj.security.message-digest-0.1.0-20130304.220822-1.pom (3k) >>>> from https://clojars.org/repo/ >>>> Retrieving org/clojure/clojure/1.5.0/clojure-1.5.0.pom (6k) >>>> from http://repo1.maven.org/maven2/ >>>> Retrieving org/clojars/franks42/clj.security.message-digest/0.1.0- >>>> SNAPSHOT/clj.security.message-digest-0.1.0-20130304.220822-1.jar (6k) >>>> from https://clojars.org/repo/ >>>> Compiling 1 source files to /Users/lkrubner/projects/multi-platform- >>>> data-visualization/mpdv-clojure/target/classes >>>> Release versions may not depend upon snaps
Re: confused about getting started with compojure on google app engine
Now that would be a fantastic topic for one of Sean Devlin's Full Disclojure videocasts!!! (just a subtle hint from a Full Disclojure fan...;-) ) -Frank. On May 31, 2010, at 12:33 PM, Zitterbewegung wrote: > I was wondering which tutorial I should use to get started with > compojure on google app engine. There seem to be a bunch of them but > they target old versions or slightly old versions. Which one should I > use? > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
[ANN]: cljsh & repls 1.9.5
CLJSH & REPLS: "cljsh" is a lightweight client that sends clojure
statements/files to a persistent repl-server "repls" for evaluation.
Release notes
Cljsh (>= 1.9.5) and repls (>= 1.9.5) have the following new features:
• cljsh automatically finds the repls-server that is started for the project,
so no need to keep track of port numbers and such. Note that cljsh and repls
both should be started from within the project's directory tree for this to
work. A single project can also be designated as "global" with cljsh (-G), such
that any subsequent cljsh invocation can indicate (-g) that it wants to
interact with that global-project's repls-server no matter from which directory
cljsh is started. In that way, a single project can be used as the scripting
environment for all general clojure scripts os-wide.
• self-update feature in cljsh (-U) that allows you to automagically
download&install the latest stable cljsh version from github. (provided you
installed cljsh in a place where cljsh can r&w).
• update feature in cljsh for the lein plugin "repls" (-u) that automagically
shows the available version for the lein plugin at clojars and will
subsequently uninstall the current one and install the chosen one. (you may
want to stay away from the old and the SNAPSHOT versions...)
• automatic starting from cljsh (-l) of the repls-server + console in a
separate terminal session (when it's not running yet) - no more need to start
the repls-server with "lein repls" in a new terminal session by hand.
• Stopping of the repls-server thru cljsh (-L). (stopping and restarting (-Ll)
gives you essentially a restart of your project's jvm)
• The cljsh & repls combination are tested to install and run the cljsh-test.sh
script successfully on both MacOSX 10.7.3 and LUbuntu 11.10 (log of the MacOSX
install session is at "https://gist.github.com/1854631";, and the Lubuntu
install log is at "https://gist.github.com/1842625"; - for Ubuntu, don't forget
to set the XTERM environment variable to enable the auto-start of the
repls-server.)
• started to look at nrepl as a possible repl-server for cljsh - the tty
transport-module looks promising - seems to work out-of-the-box with cljsh's
interactive repl ("cljsh -s nrepl-port-number -r") - for non-interactive use,
however, quite a few changes are needed (prompt printing, eval-result printing,
stderr console-redirection, auto port config,...).
• See "cljsh -h" and "https://github.com/franks42/lein-repls"; for details and
source code.
Enjoy, FrankS.
--
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
bug in clojure.repl/doc to print namespace docs (?)
When I request the doc for a namespace, an exception gets thrown (clojure 1.3): user=> (doc clojure.core) ClassNotFoundException clojure.core java.net.URLClassLoader$1.run (URLClassLoader.java:202) I was looking at the source code, and noticed that in the (cond... first the symbol resolved to a var, and if that doesn't work find-ns is tried next. However, trying to resolve a namespace symbol to a var throws an exception. When you reverse the sequence, like in gist: https://gist.github.com/1872000, and eval that gist, you get: user=> (doc clojure.core) - clojure.core Fundamental library of the Clojure language nil user=> which is what you want to see. Smells like a bug… maybe change order in (cond… as in the gist-code, or catch exception in (resolve… -FrankS. -- 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: bug in clojure.repl/doc to print namespace docs (?)
Excellent - Thanks for the confirmation & pointer - FrankS. On Feb 20, 2012, at 4:18 PM, Andy Fingerhut wrote: > Yep, and there is a patch ready to go in JIRA: > > http://dev.clojure.org/jira/browse/CLJ-902 > > Andy > > On Feb 20, 2012, at 3:17 PM, Frank Siebenlist wrote: > >> When I request the doc for a namespace, an exception gets thrown (clojure >> 1.3): >> >> >> user=> (doc clojure.core) >> ClassNotFoundException clojure.core java.net.URLClassLoader$1.run >> (URLClassLoader.java:202) >> >> >> I was looking at the source code, and noticed that in the (cond... first the >> symbol resolved to a var, and if that doesn't work find-ns is tried next. >> However, trying to resolve a namespace symbol to a var throws an exception. >> >> When you reverse the sequence, like in gist: >> https://gist.github.com/1872000, and eval that gist, you get: >> >> >> user=> (doc clojure.core) >> - >> clojure.core >> Fundamental library of the Clojure language >> nil >> user=> >> >> >> which is what you want to see. >> >> Smells like a bug… maybe change order in (cond… as in the gist-code, or >> catch exception in (resolve… >> >> -FrankS. >> >> >> >> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with your >> first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
use & require of repl-created namespace throws exception (?)
If you create a namespace with associated vars interactively in the repl, and subsequently try to use that functionality in other namspaces with clojure.core/use, an exception is thrown: FileNotFoundException Could not locate cljsh/docs__init.class or cljsh/docs.clj on classpath: clojure.lang.RT.load (RT.java:430) I can understand that no file can be located as there is none… clojure.core/require throws the same exception (as it seems to use the same clojure.core/load-libs under the cover). Stand-alone, clojure.core/refer does work, however. If I read the docs for clojure.core/require, it is clear that it has to do with loading of code in files. However, from a usability point of view, wouldn't it make more sense to let clojure.core/require just return nil and do nothing if the namespace is already loaded (unless the :reload option is give). Not sure why require actually checks without any :reload directive… if the namespace is already loaded, and the associated lib-files can be found, it's not supposed to do anything anyway, if I understand it well. Or maybe I miss some of the subtleties between a lib and a namespace as concepts and implementations (?). -Confusingly yours, FrankS. -- 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
Strings, Symbols, Keywords, Vars, NS, Type/Class…
It is my experience that the way how these fundamental Clojure entities, like Strings, Symbols, Keywords, Vars, NS, and Type/Class, are related, is not so easy to figure out. This is not so much about programming Clojure, but more about getting a better feel how the language is held together one level below. I've created this graph that visually shows what core-functions will give you a var from a symb, a str from a ns, etc.: "https://github.com/franks42/kitjensink/wiki/Symbs,-Vars,-NSs,-and-such"; It's still work in progress, but compiling the info for this picture was already very therapeutic and enlightning. Any comments or suggestions how to improve are most welcome. --- One part that added to my confusion about how these different types are related, is the fact that the function signature and documentation is sometimes unclear and feels inconsistent. For example, different functions/macros let you pass a namespace as a string, a symbol-name, a quoted-symbol or a ns-instance, or some (arbitrary) combination. Sometimes a "name" refers to a symbol, sometimes a string, both in docs and in implementation… I often find myself getting exceptions thrown because I know a ns is expected, but I "guessed" wrongly about which type of ns-identifier that particular function demanded. Is that a common experience? Is that "by design"? (not being facetious - sometimes you want to throw exceptions if the wrong type is presented, or implementing all possible function signatures that would support an ns passed as string/symbol/instance simply adds too much additional testing). Regards, FrankS. -- 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: Strings, Symbols, Keywords, Vars, NS, Type/Class…
That clojureatlas is not only useful/interesting, but also very cool!!! Thanks for the pointer, and I hope you will find time to finish the 1.3 ontology "soon". Wonder if you could enhance your ontology with enough info to generate a graph similar to mine automagically… that could be a nice add-on - kind of an alternative, different view into the clojure space: given a set of entities/types, show graphically the functions that take an instance of one to return another, or create/change another as a side-effect. (if only I could have that special live-moving-turning-bouncy effect in my graph… which looks incredibaly dull now ;-) ) -Frank. On Mar 1, 2012, at 6:04 PM, Chas Emerick wrote: > This looks good. I can sympathize with the concern, and with the process of > developing a way to visualize these relationships. I created this last year, > an experimental interactive visualization of Clojure and its standard library: > > http://www.clojureatlas.com > > Here's a direct guest link focused on `name`, which is a relevant jumping-off > point given your interest here: > > http://www.clojureatlas.com/org.clojure:clojure:1.2.0?guest=Y#clojure.core/name > > (Hint: hold down option/alt while hovering over nodes to get their info > bubbles to show up without clicking on them or their `i` icons.) > > FYI, the Atlas is Clojure 1.2-only still. Now that the book is done, I'm > (finally) getting back to it and am in the process of building out the 1.3 > ontology and reworking the visualization itself a fair bit. > > I hope you find this useful / interesting. > > Cheers, > > - Chas > > On Mar 1, 2012, at 7:14 PM, Frank Siebenlist wrote: > >> It is my experience that the way how these fundamental Clojure entities, >> like Strings, Symbols, Keywords, Vars, NS, and Type/Class, are related, is >> not so easy to figure out. This is not so much about programming Clojure, >> but more about getting a better feel how the language is held together one >> level below. >> >> I've created this graph that visually shows what core-functions will give >> you a var from a symb, a str from a ns, etc.: >> >> "https://github.com/franks42/kitjensink/wiki/Symbs,-Vars,-NSs,-and-such"; >> >> It's still work in progress, but compiling the info for this picture was >> already very therapeutic and enlightning. >> >> Any comments or suggestions how to improve are most welcome. >> >> --- >> >> One part that added to my confusion about how these different types are >> related, is the fact that the function signature and documentation is >> sometimes unclear and feels inconsistent. For example, different >> functions/macros let you pass a namespace as a string, a symbol-name, a >> quoted-symbol or a ns-instance, or some (arbitrary) combination. Sometimes a >> "name" refers to a symbol, sometimes a string, both in docs and in >> implementation… I often find myself getting exceptions thrown because I know >> a ns is expected, but I "guessed" wrongly about which type of ns-identifier >> that particular function demanded. >> Is that a common experience? >> Is that "by design"? (not being facetious - sometimes you want to throw >> exceptions if the wrong type is presented, or implementing all possible >> function signatures that would support an ns passed as >> string/symbol/instance simply adds too much additional testing). >> >> Regards, FrankS. >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with your >> first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
inconsistency in (keyword…) constructor
The keyword constructor has two signatures: [name] and [ns name] The keyword doc reads: "Returns a Keyword with the given namespace and name. Do not use : in the keyword strings, it will be added automatically." Looking at the implementation and testing in the repl, for [name] the following works: user=> (keyword "abc") :abc user=> (keyword 'abc) :abc user=> (keyword :abc) :abc user=> However, for the second signature [ns name], only the arguments as string work: user=> (keyword "my-ns" "abc") :my-ns/abc user=> (keyword "my-ns" 'abc) ClassCastException clojure.lang.Symbol cannot be cast to java.lang.String clojure.core/keyword (core.clj:558) user=> (keyword "my-ns" :abc) ClassCastException clojure.lang.Keyword cannot be cast to java.lang.String clojure.core/keyword (core.clj:558) user=> (keyword 'my-ns "abc") ClassCastException clojure.lang.Symbol cannot be cast to java.lang.String clojure.core/keyword (core.clj:558) user=> (keyword *ns* "abc") ClassCastException clojure.lang.Namespace cannot be cast to java.lang.String clojure.core/keyword (core.clj:558) user=> The java implementation of clojure.lang.Keyword/intern shows that only a function signature of (String, String) is supported for the call made in [ns name]. The fairly small patch at: "https://gist.github.com/1956218"; for clojure.core/keyword would add some conversions-to-string in the [ns name] code to allow for different data types on par with [name], and would also allow you to specify the ns as string/symbol/namespace. In Assembla I couldn't find any bug report related to this (?). Would this be considered a (usability) bug or just too much perfectionism? Regards, Frank. PS. same issue with (symbol name) and (symbol ns name)… -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: inconsistency in (keyword…) constructor
Just found your CLJ-891 and added a comment there that keyword has similar issues with a link to this thread. See that you tried to solve it in java… while I tried to stay up in clj … but any protocol-based solution seems to be up in the air still (?). Hopefully both interfaces can be enhanced in silmilar ways. -FrankS. On Mar 2, 2012, at 9:32 AM, joegallo wrote: > > PS. same issue with (symbol name) and (symbol ns name)… > > > Huh, somehow I noticed this issue with symbol, but didn't see it with > keyword. I guess I've need the two arg version of symbol, but never needed > the two arg version of keyword. > > See some related discussion here: > https://groups.google.com/d/topic/clojure/n25aZ5HA7hc/discussion -- 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
How to escape a space in a keyword?
I kind of accidently discovered that you can create keywords with an embedded space… not sure if that's a good idea, but you can: user=> (def k (keyword "jaja nee")) #'user/k user=> (str k) ":jaja nee" user=> (name k) "jaja nee" user=> (keyword? k) true user=> (keyword? :jaja nee) CompilerException java.lang.RuntimeException: Unable to resolve symbol: nee in this context, compiling:(NO_SOURCE_PATH:15) user=> (keyword? :jaja\ nee) RuntimeException Unsupported character: \ nee clojure.lang.Util.runtimeException (Util.java:156) RuntimeException Unmatched delimiter: ) clojure.lang.Util.runtimeException (Util.java:156) user=> (keyword? :jaja\\ nee) CompilerException java.lang.RuntimeException: Unable to resolve symbol: nee in this context, compiling:(NO_SOURCE_PATH:17) user=> The Q is how do you escape such an embedded space such that the reader will interpret it as a keyword? -FrankS. -- 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: How to escape a space in a keyword?
One other option I should have tried before: user=> (pr-str k) ":jaja nee" user=> (read-string (pr-str k)) :jaja user=> but unfortunately that doesn't help either. -FrankS On Mar 6, 2012, at 10:44 AM, Frank Siebenlist wrote: > I kind of accidently discovered that you can create keywords with an embedded > space… not sure if that's a good idea, but you can: > > user=> (def k (keyword "jaja nee")) > #'user/k > user=> (str k) > ":jaja nee" > user=> (name k) > "jaja nee" > user=> (keyword? k) > true > user=> (keyword? :jaja nee) > CompilerException java.lang.RuntimeException: Unable to resolve symbol: nee > in this context, compiling:(NO_SOURCE_PATH:15) > user=> (keyword? :jaja\ nee) > RuntimeException Unsupported character: \ nee > clojure.lang.Util.runtimeException (Util.java:156) > RuntimeException Unmatched delimiter: ) clojure.lang.Util.runtimeException > (Util.java:156) > user=> (keyword? :jaja\\ nee) > CompilerException java.lang.RuntimeException: Unable to resolve symbol: nee > in this context, compiling:(NO_SOURCE_PATH:17) > user=> > > The Q is how do you escape such an embedded space such that the reader will > interpret it as a keyword? > > -FrankS. -- 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: How to escape a space in a keyword?
Those are convincing arguments/examples that spaces should be allowed in
keywords.
Your solution to enhance "pr":
(pr-str k) ; as in your example
"(keyword "jaja nee")"
should work.
Btw., symbols seem to have the exact same issue:
user=> (def s (symbol "with space"))
#'user/s
user=> s
with space
user=> (pr-str s)
"with space"
user=> (read-string (pr-str s))
with
user=>
Is this a bug?
-FrankS.
On Mar 6, 2012, at 11:56 AM, Timothy Baldridge wrote:
>> I don't think you're supposed to use spaces in keywords.
>
>
> Using spaces in keywords is completely valid, as is using spaces in
> symbols. You just have to be aware that there may be times when you
> can't represent them in a literal form. pr-str could be extended to do
> this though:
>
> (pr-str :foo)
> ":foo"
>
> (pr-str k) ; as in your example
> "(keyword "jaja nee")"
>
> There are many times when you may actually want to have spaces as
> keywords. Consider the following json:
>
> {"first name" : "John"
> "last name" : "Doe"
> "age" : 42}
>
> If we convert this json to clojure, it would be nice to be able to do:
>
> user=> (:age data)
> 42
>
> And we can still do this:
>
> user=> ((keyword "first name") data)
> "John"
>
> Why restrict the user needlessly?
>
>
> Timothy
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: How to escape a space in a keyword?
So… spaces are not allowed in symbol and keyword identifiers according to the "spec"… although Stu doesn't quote the phrase following the allowed chars, which reads: (other characters will be allowed eventually…) which seems to keep the door open for allowing spaces in the future (?). If space are not allowed, then it seems we have a bug in (keyword …) and (symbol …), if they will be allowed in the future, then (pr …) could/should be enhanced. -FrankS. On Mar 6, 2012, at 12:13 PM, Stuart Halloway wrote: >>> I don't think you're supposed to use spaces in keywords. >> >> >> Using spaces in keywords is completely valid, as is using spaces in >> symbols. > > Legal characters in keywords and symbols are documented at > http://clojure.org/reader : > > "Symbols begin with a non-numeric character and can contain alphanumeric > characters and *, +, !, -, _, and ? ... Keywords are like symbols ..." > > Stu > > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How to escape a space in a keyword?
Thanks for the explanation - I tried to search for previous discussions and bug
reports about this issue before I posted, but it's clear I didn't look hard
enough...
I could still argue that there is a bug in the documentation that should spell
this out - especially when it has been discussed several times in the past… it
could save a lot of time, confusion and rehashing.
Maybe the keyword/symbol doc string should add something like: "Note that the
identifier-string is not checked for correctness, which implies that function
will return an invalid value for an invalid identifier.".
Personally I think it really helps if the doc-string specifies the contract,
especially when it has been decided to leave it somewhat ambigeous on purpose.
Thanks, FrankS.
PS Guess we can see the consequences of silently returning invalid values:
possibly creating legacy that depends on those, like the json examples.
On Mar 6, 2012, at 3:23 PM, Meikel Brandmeyer wrote:
> Hi,
>
> Am 06.03.2012 um 21:28 schrieb Frank Siebenlist:
>
>> So… spaces are not allowed in symbol and keyword identifiers according to
>> the "spec"…
>>
>> although Stu doesn't quote the phrase following the allowed chars, which
>> reads:
>>
>> (other characters will be allowed eventually…)
>>
>> which seems to keep the door open for allowing spaces in the future (?).
>>
>> If space are not allowed, then it seems we have a bug in (keyword …) and
>> (symbol …),
>> if they will be allowed in the future, then (pr …) could/should be enhanced.
>
> I think this has been discussed several times in the past.
>
> This is *not* a bug in keyword or symbol. A string with spaces is simply not
> in the domain of these functions. So by definition it cannot be a bug. What
> happens is a pure decision by the implementer. The functions could throw an
> exception. Or they could return an invalid value. symbol and keyword do the
> latter. (Whether this is good or bad might be a matter of discussion, but it
> is not a bug.)
>
> And of course vice versa: the behaviour of symbol or keyword is *not* the
> definition of valid keywords/symbols. That is what Stu cited.
>
> I doubt that spaces will be officially allowed until there is – say – #|foo
> bar| for symbols and #:foo bar: for keywords.
>
> Until then a translation of {"Foo Bar" 35} to {:foo-bar 35} is a quite
> feasible workaround.
>
> BTW: Similarly you can use non-ASCII characters for symbols in your clojure
> code. This code would then be broken. The reader doesn't complain, but the
> “spec” says: only ASCII characters are allowed. Same situation as above.
>
> BTW2: There are a lot of things which might be desirable for various reasons.
> Spaces in symbols or keywords might be one of these things. But that doesn't
> mean it's a good idea to implement it. In Clojure's past there were several
> things which were requested with a lot of pressure (often combined with “sky
> is falling” comparisons), which were not implemented in the language. Only
> after long considerations changes went into the language (often) providing a
> superior solution to the previously requested versions. Patience is a
> required skill of a clojurian. ;)
>
> Sincerely
> Meikel
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: How to escape a space in a keyword?
Clojure is a young language, and I believe there is little argument that some of the interfaces/implementations and associated docs could be improved. You can find plenty of examples where functions would throw exceptions for invalid input, others return nil in that case, and a number return garbage for garbage. Some of this perceived inconsistency could be improved upon, either by changing/adding validation code or by adding clarifications to the documentation of the functions. The symbol function doc consists of only: "Returns a Symbol with the given namespace and name." Unless you suggest that we all look at the symbol code itself before we start using those parameters, it may help to add a little bit more text to guide the novice user of the interface such that one knows that this particular function doesn't throw exceptions or return nil, but returns invalid output for invalid input… for that suggestion I'm rewarded with a condescending "…WTF…" gender-neutral (?) rant - guess you're truly encouraging people on this list to ask questions and suggest solutions/improvements ;-). My suggestion still stands: add more text to the doc-string of some of the functions such that the user has a better understanding of what to expect: no validation, nil, exception, expected parameter type, ???. I'd be happy to suggest wording. Another option that may help us to use valid identifiers in our code is to have a function like: (clojure.core/valid-name? a-str), which is maintained by core (and not by us all writing some regex based on the current specs on a web page). We can use it in our code and tests to ensure we're following the current specs. If the valid characters are extended in the next clojure version, so is the function, and we can automatically conform. I'd be happy to provide code. "Sincerely", FrankS. On Mar 7, 2012, at 2:00 PM, Meikel Brandmeyer wrote: > Hi, > > Am 07.03.2012 um 01:11 schrieb Leif: > >> Unfortunately, the reader does not actually follow this spec, e.g. it will >> happily accept :div#id.cla$$ as a valid keyword. Some web programming >> clojure[script] libraries use this pseudo-CSS syntax in keywords, so if the >> reader was changed to strictly follow these rules, a lot of web code would >> probably break. > > It's the other way around: the reader *does* follow the spec. Feed it a valid > sequence of characters and you will get a valid keyword. Feed it an invalid > sequence of characters and you will get an invalid keyword. This is not in > conflict with the spec. A bad decision to do so instead of bailing out? > Maybe. Maybe not. > > However documenting everywhere that feeding garbage in might result in shit > coming out has this “things in the mirror might be closer than they appear” > taste. WTF? The mirror is not the problem. Nor is the car manufacturer to be > held responsible. If the driver of a car causes an accident, it's her fault. > *She* is responsible. No one else. > > The developers of said libraries obviously didn't live up to their > responsibility. Either they did not research how the reader works and what > valid keyword characters are. Then they did not do their job correctly. Or > they knew how the reader works but knowingly decided to operate it outside > defined limits. Then they basically gambled that things keep working and that > the characters will be eventually allowed in future versions of the reader. > > In this particular case I would expect the bet to pay off. But if suddenly > the reader is changed to handle # differently, then all these libraries will > break. And now guess who is responsible. The reader? No. > > Don't pass the buck. > > Sincerely > Meikel > > PS: I hope Clojure's development mode is not switched to “fait accompli > driven.” > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How to escape a space in a keyword?
This is my last reply for this thread as the support for "improved" doc strings for symbol and keyword has been kind of underwhelming - which is fine - time to move on. (besides, now I personally know more than enough about the implementation of those functions to use them conformantly ;-) ) > Surely undocumented behavior is undefined behavior by definition? True - but that kind of assumes that there is documented behavior… the one-liner for (symbol ns name) doesn't say anything about input parameter value types, and leaves the valid characters set upto the user knowing where to find it on the "http://clojure.org/reader"; page. Note that I had to find the valid types for [name] and [ns name] by looking thru the clojure.core clj&java code. > ...unless explicitly documented to the > contrary (e.g., when given invalid input, this function shall throw an > exception). It took me about 3 minutes to scan thru the API list and testing at the repl to find alias, bases and bound? - all throwing exceptions while it is not mentioned in their docs. I'm sure you could have found many more in the same time before you wrote your reply - not sure what that tells you (?). Also not sure what the big issue is to help the (novice) users out by being explicit in the doc-string about the contract and behaviour of a function. As far as I can tell, you have functions that validate and barf, validate and return some well-known value like nil for invalid input, and you have the garbage-in, garbage-out type. Unless you can guarantee that the first two types are always clearly identified in their docs, you can leave the last one open… however, why not mention it also explicitly? Especially for symbol, which is a pretty key entity for the clojure language. We have a one-liner, low on content for symbol/keyword and a page-long doc for deftype/defprotocol. So one last time… instead of having the current docs: clojure.core/symbol ([name] [ns name]) Returns a Symbol with the given namespace and name. clojure.core/keyword ([name] [ns name]) Returns a Keyword with the given namespace and name. Do not use : in the keyword strings, it will be added automatically. My suggested docs are: clojure.core/symbol ([name] [ns name]) Returns a Symbol with the given namespace and name. (symbol name): name can be string or symbol. (symbol ns name): ns and name must both be string. A symbol string, begins with a non-numeric character and can contain alphanumeric characters and *, +, !, -, _, and ?. (see "http://clojure.org/reader"; for details). Note that function does not validate input strings for ns and name, and may return improper symbols with undefined behavior for non-conformant ns and name. clojure.core/keyword ([name] [ns name]) Returns a Keyword with the given namespace and name. Do not use : in the keyword strings, it will be added automatically. (keyword name): name can be string, symbol or keyword. (keyword ns name): ns and name must both be string. A keyword string, like a symbol, begins with a non-numeric character and can contain alphanumeric characters and *, +, !, -, _, and ?. (see "http://clojure.org/reader"; for details). Note that function does not validate input strings for ns and name, and may return improper keywords with undefined behavior for non-conformant ns and name. Take it or leave it. Regards, FrankS. On Mar 12, 2012, at 4:56 PM, Sean Corfield wrote: > On Mon, Mar 12, 2012 at 10:39 AM, Armando Blancas wrote: >>> If invalid input will not throw an error >>> immediately, then it DOES need to be documented that invalid input >>> will result in undefined output. >>> >>> ~Justin >> >> Documented by whom? By you and FrankS? Maybe the push back is for lotta >> suggestin' but little doin'. > > Surely undocumented behavior is undefined behavior by definition? > That's certainly the approach taken by many programming language > standards. In which case, giving any function invalid input is > immediately in undefined behavior territory and the output is > "guaranteed" to be undefined - unless explicitly documented to the > contrary (e.g., when given invalid input, this function shall throw an > exception). > -- > Sean A Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > World Singles, LLC. -- http://worldsingles.com/ > > "Perfection is the enemy of the good." > -- Gustave Flaubert, French realist novelist (1821-1880) > > -- > 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 Gro
why do we need a (require…)?
I can see the need for refer and alias, but why can the compiler not infer from the use of a fully qualified name that a namespace (or class) that is not loaded yet, has to be "required"? Or did I miss anything? -FrankS. -- 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: New(er) Clojure cheatsheet hot off the presses
> (3) tooltips using a modified TipTip jQuery plugin tool, for people like me > who like its look & feel better than (2). > > http://homepage.mac.com/jafingerhut/files/cheatsheet-clj-1.3.0-v1.4-tooltips/cheatsheet-full.html I like that one - looks cool - very helpful!! Thanks, Frank. On Mar 26, 2012, at 2:25 PM, Andy Fingerhut wrote: > Welcome, Pierre. > > Thanks for the info. My current thinking is to start publishing on > clojure.org two, or maybe even three versions of the cheatsheet: > > (1) no tooltips, just like the one published now, in case people find them > annoying: > http://clojure.org/cheatsheet > > (2) tooltips with the title attribute, for those that prefer > web-standards-compliant pages, such as this one: > > http://homepage.mac.com/jafingerhut/files/cheatsheet-clj-1.3.0-v1.4-tooltips/cheatsheet-title-attribute.html > > (3) tooltips using a modified TipTip jQuery plugin tool, for people like me > who like its look & feel better than (2). > > http://homepage.mac.com/jafingerhut/files/cheatsheet-clj-1.3.0-v1.4-tooltips/cheatsheet-full.html > > The nice thing is that all three of these are currently generated from the > same program. Not only are those three pages generated, but also several > variations of A4-size and US letter-size PDF files, with links (but no > tooltips in the PDF -- I don't know how to do that if it is even possible). > So far, it is still pretty straightforward for me to add a new symbol or > category to the cheatsheet, and regenerate all of these things in a minute. > > There shouldn't need to be any argument over which of these should be "the > one". I say publish them all, with an easy way to get from one version to > another in case you change your mind which one you want to use. > > And if I am stretching what a tooltip is meant to be, and thereby join the > ranks of web-standards-heathens who stretch the original intent of these > mechanisms, I do so proudly :-) > > Andy > > On Mar 25, 2012, at 10:36 PM, Pierre Mariani wrote: > >> >> >> On Saturday, March 24, 2012 11:59:49 PM UTC-7, Andy Fingerhut wrote: >> I've tried again using links with doc strings as the values of the title >> attribute, but when the text in Firefox 11.0 it does not honor the line >> breaks in my text, but reflows it. Try it out yourself at [1]: >> [1] >> http://homepage.mac.com/jafingerhut/files/cheatsheet-clj-1.3.0-v1.4-tooltips/cheatsheet-title-attribute.html >> >> Is there a way that Firefox will let me specify where line breaks should go? >> If I put or tags in the text of a title attribute, those just >> show up literally in the text that the browser displays in the tool tip. I >> have line breaks in the title attribute value in my HTML, but Firefox seems >> to be ignoring those. >> >> Safari and Chrome seem to honor the line breaks in the title attribute, but >> they make the popup windows so narrow that the lines break in the middle, in >> addition to where I put my line breaks, which is better but not great. Is >> there a way to tell the browser to make the popup windows wider? >> >> Andy >> >> This is my first post to the list, so hi everybody! >> >> Andy, >> >> Tooltips are being rendered by the browser itself and you cannot control >> their aspect with HTML or CSS. >> This bug https://bugzilla.mozilla.org/show_bug.cgi?id=358452 seems to be >> related to your issue, and it indicates that the behavior you are looking >> for should be implemented in FF12. Unfortunately, that doesn't fix it for >> other browsers, or older versions of FF. >> >> Sorry if it sounds critical and isn't very helpful at this stage, but I >> think the concept of tooltip is being stretched a little here. The 'title' >> attribute is not meant to contain one or several paragraphs of formatted >> text, and as such I would expect that you may run into more issues like this >> in the future. >> I would personally use DL lists, have each function name in a DT and the >> corresponding docstring in a DD. I would then have a CSS sheet targeted at >> screen and handheld media hide the docstrings, and I would have javascript >> code show them on mouse hover and hide them on mouse out. I think that would >> ensure best semantical fit of content to HTML tags, best accessibility for >> visually impaired people, and reliable cross-browser behavior. >> >> http://htmlhelp.com/reference/html40/lists/dl.html >> http://htmlhelp.com/reference/html40/lists/dt.html >> http://htmlhelp.com/reference/html40/lists/dd.html >> http://www.w3schools.com/css/css_mediatypes.asp >> >> Pierre > > -- > 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 o
Re: New(er) Clojure cheatsheet hot off the presses
Forgot to add that we only need one cheatsheet, and I vote for (3). On Mar 27, 2012, at 7:55 AM, Frank Siebenlist wrote: >> (3) tooltips using a modified TipTip jQuery plugin tool, for people like me >> who like its look & feel better than (2). >> >> http://homepage.mac.com/jafingerhut/files/cheatsheet-clj-1.3.0-v1.4-tooltips/cheatsheet-full.html > > > I like that one - looks cool - very helpful!! > > Thanks, Frank. > > > > On Mar 26, 2012, at 2:25 PM, Andy Fingerhut wrote: > >> Welcome, Pierre. >> >> Thanks for the info. My current thinking is to start publishing on >> clojure.org two, or maybe even three versions of the cheatsheet: >> >> (1) no tooltips, just like the one published now, in case people find them >> annoying: >>http://clojure.org/cheatsheet >> >> (2) tooltips with the title attribute, for those that prefer >> web-standards-compliant pages, such as this one: >> >> http://homepage.mac.com/jafingerhut/files/cheatsheet-clj-1.3.0-v1.4-tooltips/cheatsheet-title-attribute.html >> >> (3) tooltips using a modified TipTip jQuery plugin tool, for people like me >> who like its look & feel better than (2). >> >> http://homepage.mac.com/jafingerhut/files/cheatsheet-clj-1.3.0-v1.4-tooltips/cheatsheet-full.html >> >> The nice thing is that all three of these are currently generated from the >> same program. Not only are those three pages generated, but also several >> variations of A4-size and US letter-size PDF files, with links (but no >> tooltips in the PDF -- I don't know how to do that if it is even possible). >> So far, it is still pretty straightforward for me to add a new symbol or >> category to the cheatsheet, and regenerate all of these things in a minute. >> >> There shouldn't need to be any argument over which of these should be "the >> one". I say publish them all, with an easy way to get from one version to >> another in case you change your mind which one you want to use. >> >> And if I am stretching what a tooltip is meant to be, and thereby join the >> ranks of web-standards-heathens who stretch the original intent of these >> mechanisms, I do so proudly :-) >> >> Andy >> >> On Mar 25, 2012, at 10:36 PM, Pierre Mariani wrote: >> >>> >>> >>> On Saturday, March 24, 2012 11:59:49 PM UTC-7, Andy Fingerhut wrote: >>> I've tried again using links with doc strings as the values of the title >>> attribute, but when the text in Firefox 11.0 it does not honor the line >>> breaks in my text, but reflows it. Try it out yourself at [1]: >>> [1] >>> http://homepage.mac.com/jafingerhut/files/cheatsheet-clj-1.3.0-v1.4-tooltips/cheatsheet-title-attribute.html >>> >>> Is there a way that Firefox will let me specify where line breaks should >>> go? If I put or tags in the text of a title attribute, those >>> just show up literally in the text that the browser displays in the tool >>> tip. I have line breaks in the title attribute value in my HTML, but >>> Firefox seems to be ignoring those. >>> >>> Safari and Chrome seem to honor the line breaks in the title attribute, but >>> they make the popup windows so narrow that the lines break in the middle, >>> in addition to where I put my line breaks, which is better but not great. >>> Is there a way to tell the browser to make the popup windows wider? >>> >>> Andy >>> >>> This is my first post to the list, so hi everybody! >>> >>> Andy, >>> >>> Tooltips are being rendered by the browser itself and you cannot control >>> their aspect with HTML or CSS. >>> This bug https://bugzilla.mozilla.org/show_bug.cgi?id=358452 seems to be >>> related to your issue, and it indicates that the behavior you are looking >>> for should be implemented in FF12. Unfortunately, that doesn't fix it for >>> other browsers, or older versions of FF. >>> >>> Sorry if it sounds critical and isn't very helpful at this stage, but I >>> think the concept of tooltip is being stretched a little here. The 'title' >>> attribute is not meant to contain one or several paragraphs of formatted >>> text, and as such I would expect that you may run into more issues like >>> this in the future. >>> I would personally use DL lists, have each function name in a DT and the >>> corresponding docstring in a DD. I would then have a CS
Forgetting (require…) => nasty bug
I've been bitten a couple of times now by the following scenario: - Use fully qualified names in the code - Forget to add (require…) for the associated namspace - But one other file already require'ed the same namespace, and the compiler&runtime is happy - all works fine. - Then you include that file in an other app… - no other module require's that namespace before this clj-module - boom, crash… confusion as all seem to have worked before… and now it doesn't… Is there a way to capture those kind of bugs earlier? Thanks, FrankS. -- 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: Forgetting (require…) => nasty bug
On Mar 28, 2012, at 3:15 PM, Phil Hagelberg wrote: > ... > In general though I recommend simply using :require :as for > everything; if your code won't compile without the :as alias in place > then you'll be safe. I realize that's a pragmatic way to force compilation errors. However, I thought of using FQNs as a best practice as it's always clear which entity you're refering to as it's… fully qualified. Then only use require…:as if it becomes too tedious to write the full fqn, and only use "refer/use" if even that becomes too much of a pain. Wouldn't it be better to have the compiler or (load-file) generate an error/warning, as it should be able to detect a missing require? -FrankS. -- 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: Forgetting (require…) => nasty bug
Not sure if that would work for all cases… For example, if you have a lein plugin that require's clojure.set, and you use any fqn in that ns without require'ing it in your file, then your fresh repl will not catch that (… if I understand your setup). However, if you then run it outside of the dev-environment, i.e. without any plugins or with other plugins, you will feel the pain. But even when your trick works for many cases, it would be preferable if the compiler would simply catch that bug for you if possible. -FrankS. On Mar 28, 2012, at 7:26 PM, Armando Blancas wrote: > Is there a way to capture those kind of bugs earlier? > > For each namespace I get a fresh repl and (use) the one in turn, then try the > whole program. -- 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: Forgetting (require…) => nasty bug
"slow mode"… Is that a setup where you would bring-up a new jvm-instance for each file such that you can truly compile/test in isolation? Or is it possible to create a sandbox in an existing jvm that would give you similar isolation? (which would be far less slow) -FrankS. On Mar 28, 2012, at 8:20 PM, Phil Hagelberg wrote: > On Wed, Mar 28, 2012 at 8:03 PM, Frank Siebenlist > wrote: >> For example, if you have a lein plugin that require's clojure.set, and you >> use any fqn in that ns without require'ing it in your file, then your fresh >> repl will not catch that (… if I understand your setup). > > The lein check task currently ensures that each namespace is > compilable, but it does all the namespaces in a single process. You > could add a "slow mode" to it that would ensure that each worked in > isolation. > > -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 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: Forgetting (require…) => nasty bug
leiningen v3.0 ? ;-) On Mar 28, 2012, at 8:48 PM, Phil Hagelberg wrote: > On Wed, Mar 28, 2012 at 8:30 PM, Frank Siebenlist > wrote: >> Or is it possible to create a sandbox in an existing jvm that would give you >> similar isolation? (which would be far less slow) > > You could probably do this with isolated classloaders in most cases. > > -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 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] Clojure Namespace Browser (clj-ns-browser "1.0.0")
I still remember the first time I was introduced to Smalltalk, when my colleague demonstrated the class-browser - it was one of those jaw-dropping moments: all that information at your finger-tips of a live- and living system… Guess nowadays it's more nostalgia than anything else, but in many ways that Smalltalk development environment is still a hard act to follow. Hopefully this Clojure Namespace Browser will get us one small step closer to our ultimate development environment (… although I'm sure that some of you emacs-gurus believe you're already there ;-) ). The graphical browser should give you easier access to the documentation strings of all the vars in your live clojure project, as well as the source code, and clojuredocs' examples&comments. You can get all that info from the repl, but hopefully this browser should make it easier to … browse, explore, and find stuff in Clojure's vast collection of libraries. The installation is dead-simple - just add: :dev-development [[clj-ns-browser "1.0.0"]] to your project.clj file, start your repl, evaluate (use 'clj-ns-browser.sdoc), and then (sdoc), and your up and running with this namespace browser always one click or (sdoc…) away… Caveat… it all works well on my MacOSX, but I have seen some issues with Lubuntu and missing "unloaded namespaces" - also I haven't tested it on windoze or other OS-flavors. So you mileage may vary… The code and some more info with some screenshots are available at: https://github.com/franks42/clj-ns-browser Finally, kudos to Dave Ray and his Seesaw - fantastic tool and near real-time support on the mailing list. (this has essentially been a 2 week project after Clojure-Conj/West - an "after the kids are asleep" project - no experience with Swing… a testament of how good seesaw is as an abstraction tool…) Please let me know if it works for you, and suggestions and feedback are more than welcome. Enjoy, FrankS. -- 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: [ANN] Clojure Namespace Browser (clj-ns-browser "1.0.0")
Correct - thanks for catching that - should have c&p'ed ;-) -FrankS. On Apr 5, 2012, at 4:06 PM, Changa Damany Imara wrote: > I believe there's a typo in your announcement: > > :dev-development [[clj-ns-browser "1.0.0"]] > > should be > > :dev-dependencies [[clj-ns-browser "1.0.0"] > > Great stuff especially for someone with no Swing experience! > > > On Wednesday, April 4, 2012 10:56:51 PM UTC-7, FrankS wrote: > I still remember the first time I was introduced to Smalltalk, when my > colleague demonstrated the class-browser - it was one of those jaw-dropping > moments: all that information at your finger-tips of a live- and living > system… > Guess nowadays it's more nostalgia than anything else, but in many ways that > Smalltalk development environment is still a hard act to follow. > > Hopefully this Clojure Namespace Browser will get us one small step closer to > our ultimate development environment (… although I'm sure that some of you > emacs-gurus believe you're already there ;-) ). > > The graphical browser should give you easier access to the documentation > strings of all the vars in your live clojure project, as well as the source > code, and clojuredocs' examples&comments. You can get all that info from the > repl, but hopefully this browser should make it easier to … browse, explore, > and find stuff in Clojure's vast collection of libraries. > > The installation is dead-simple - just add: > > :dev-development [[clj-ns-browser "1.0.0"]] > > to your project.clj file, start your repl, evaluate (use > 'clj-ns-browser.sdoc), and then (sdoc), and your up and running with this > namespace browser always one click or (sdoc…) away… > > Caveat… it all works well on my MacOSX, but I have seen some issues with > Lubuntu and missing "unloaded namespaces" - also I haven't tested it on > windoze or other OS-flavors. So you mileage may vary… > > The code and some more info with some screenshots are available at: > > https://github.com/franks42/clj-ns-browser > > Finally, kudos to Dave Ray and his Seesaw - fantastic tool and near real-time > support on the mailing list. > (this has essentially been a 2 week project after Clojure-Conj/West - an > "after the kids are asleep" project - no experience with Swing… a testament > of how good seesaw is as an abstraction tool…) > > Please let me know if it works for you, and suggestions and feedback are more > than welcome. > > Enjoy, FrankS. > > > > > > > > > > > > > > -- 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: [ANN] Clojure Namespace Browser (clj-ns-browser "1.0.0")
Interesting "feature" on windoze… ;-) One thing that may cause that is the Inconsolata font that I used as a fixed-width font to display most text. (not sure what happens if it's not installed… should just substitute an other font…) Could you please try to install that font on your windows machine and try again? (I don't have any windows box available for testing) -FrankS. On Apr 6, 2012, at 9:01 AM, Lars Nilsson wrote: > On Thu, Apr 5, 2012 at 1:56 AM, Frank Siebenlist > wrote: >> Caveat… it all works well on my MacOSX, but I have seen some issues with >> Lubuntu and missing "unloaded namespaces" - also I haven't tested it on >> windoze or other OS-flavors. So you mileage may vary… > > Got it working fine on Linux. Looks really nice. :) On Windows, my > primary platform, the text is garbled in all text boxes and lists > (drop-down menus and static strings are ok). Even the text that I type > into, say, the namespace text field gets garbled. If I try typing > "clojure", I end up with "clnjtqe". Copying the text help doc text and > pasting into a text editor shows it correctly, so there's possibly > some kind of character encoding mismatch somewhere. Not sure what else > I can add.. > > Sample problem: > > [Expected display] > clojure.core - Namespace > > Fundamental library of the Clojure language > > [Actual display] > clnjtqe.cnqe - Na'eroace > > Ftmda'emsal libqaqx nf she Clnjtqe lamgtage > > Lars Nilsson > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: [ANN] Clojure Namespace Browser (clj-ns-browser "1.0.0")
Interesting - you did the opposite of what I asked and still we found the issue ;-) … which also confirms that there is something wrong with that Inconsolata font definition as it also garbles my readable text in Aquamacs to gibberish much worse than you showed - was blaming Aquamacs, but now the font may be the culprit - too bad because I love the design. -FrankS. On Apr 6, 2012, at 9:37 AM, Lars Nilsson wrote: > Well, as it turns out, I installed Inconsolata just yesterday, along > with a couple of others, exploring alternatives to Courier New. > Uninstalling Inconsolata results in sdoc displaying the text > correctly. > > Thanks for a very nifty tool. :) > > Lars Nilsson > > On Fri, Apr 6, 2012 at 12:29 PM, Frank Siebenlist > wrote: >> Interesting "feature" on windoze… ;-) >> >> One thing that may cause that is the Inconsolata font that I used as a >> fixed-width font to display most text. (not sure what happens if it's not >> installed… should just substitute an other font…) >> >> Could you please try to install that font on your windows machine and try >> again? >> (I don't have any windows box available for testing) >> >> -FrankS. >> >> >> >> On Apr 6, 2012, at 9:01 AM, Lars Nilsson wrote: >> >>> On Thu, Apr 5, 2012 at 1:56 AM, Frank Siebenlist >>> wrote: >>>> Caveat… it all works well on my MacOSX, but I have seen some issues with >>>> Lubuntu and missing "unloaded namespaces" - also I haven't tested it on >>>> windoze or other OS-flavors. So you mileage may vary… >>> >>> Got it working fine on Linux. Looks really nice. :) On Windows, my >>> primary platform, the text is garbled in all text boxes and lists >>> (drop-down menus and static strings are ok). Even the text that I type >>> into, say, the namespace text field gets garbled. If I try typing >>> "clojure", I end up with "clnjtqe". Copying the text help doc text and >>> pasting into a text editor shows it correctly, so there's possibly >>> some kind of character encoding mismatch somewhere. Not sure what else >>> I can add.. >>> >>> Sample problem: >>> >>> [Expected display] >>> clojure.core - Namespace >>> >>> Fundamental library of the Clojure language >>> >>> [Actual display] >>> clnjtqe.cnqe - Na'eroace >>> >>> Ftmda'emsal libqaqx nf she Clnjtqe lamgtage >>> >>> Lars Nilsson >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clojure@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with your >> first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- 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
where do you put the docstring in a deftype declaration?
Confusingly yours, FrankS. -- 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: where do you put the docstring in a deftype declaration?
Thanks - I kind of expected this - the previous implementation in contrib for 1.2 was based on vars and still shows docstrings in the signature on clojuredocs. There is CLJ-304 "contrib get-source no longer works with deftype" which seems related. Too bad that we cannot annotate deftypes (and classes) with docstrings - no online docs - no source code retrieval… Those who care about this should maybe vote this issue up and show it some love to get a protocol-based solution for meta-data. -FrankS. On Apr 12, 2012, at 10:12 PM, Alan Malloy wrote: > A deftype creates a java class, not a clojure var. Classes have no > slots to store a docstring. Just put a comment somewhere. > > On Apr 12, 9:52 pm, Frank Siebenlist > wrote: >> Confusingly yours, FrankS. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
weird pprint behaviour ?
I'm using the following function to have pprint write into a string and limit the output: (defn pprint-str "Return string with pprint of v, and limit output to prevent blowup." [v] (with-out-str (binding [*print-length* 32 *print-level* 6] (pprint v Everything seems to work as expected, except when trying to print a var value of nil: user=> (pprint #'clojure.core/*print-length*) # nil user=> (clj-ns-browser.utils/pprint-str #'clojure.core/*print-length*) "#\n" user=> (with-out-str (binding [*print-length* 32 *print-level* 6] (pprint #'clojure.core/*print-length*))) "#\n" user=> (binding [*print-length* 32 *print-level* 6] (pprint #'clojure.core/*print-length*))# nil user=> (binding [*print-length* 33 *print-level* 6] (pprint #'clojure.core/*print-length*)) # nil user=> It seems that the *print-length* binding-value is printed out when the var-value is nil. Bug? Feature? Should I have used binding in a different way? Thanks, FrankS. -- 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: weird pprint behaviour ?
Thanks for catching that - I didn't even notice that I was printing the binding var itself… need coffee… -FS. On May 3, 2012, at 9:59 AM, Meikel Brandmeyer wrote: > Hi, > > Am 03.05.2012 um 18:43 schrieb Frank Siebenlist: > >> user=> (pprint #'clojure.core/*print-length*) >> # >> nil >> user=> (clj-ns-browser.utils/pprint-str #'clojure.core/*print-length*) >> "#\n" >> user=> (with-out-str (binding [*print-length* 32 *print-level* 6] (pprint >> #'clojure.core/*print-length*))) >> "#\n" >> user=> (binding [*print-length* 32 *print-level* 6] (pprint >> #'clojure.core/*print-length*))# >> nil >> user=> (binding [*print-length* 33 *print-level* 6] (pprint >> #'clojure.core/*print-length*)) >> # >> nil >> user=> >> >> >> It seems that the *print-length* binding-value is printed out when the >> var-value is nil. > > Oeh. You always print *print-length* in your examples. And that is never nil, > because you set to 32 in your function. Did you check also other vars? > > For me it seems to work. > > user=> (def f nil) > #'user/f > user=> (binding [*print-length* 32] (clojure.pprint/pprint f)) > nil > > Kind regards > Meikel > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
[ANN] The "It starts to look like a real App", 1.2.0 release of the Clojure Namespace Browser (clj-ns-browser)
Dear fellow Clojurians, We're happy to announce the new release 1.2.0 of the "Clojure Namespace Browser". Clj-ns-browser is a namespace/class/var browser for Clojure's doc strings, source code, ClojureDocs.org examples & comments, and values. The browser's GUI is inspired by Smalltalk class library browsers, and is based on the Seesaw library. The "It starts to look like a real App" release, "1.2.0", adds a long list of new features to clj-ns-browser compared to the ancient, legacy "1.1.0" release that is already a few weeks old. One important distinction between the new and the old version, is the use of menus, popup-menus, keyboard short-cuts, copy&paste, drag&drop... all thanks to seesaw of course. A few of the highlights of the browser's feature set are: • seeing the loaded and unloaded namespaces with a one-click (require ...) option • see the doc-string of a selected var/namespace plus optionally the clojuredocs' examples, comments and see alsos, as well as the source code. • seeing the list of vars/classes either as local names or as fully qualified ones. • the ability to select more than one namespace and to use a regex filter to display the var-list... even with optional searching/matching of the associated doc-strings. • Predefined var/class-filters to see only macros/functions/protocols/multimethods/dynamic or deftypes/defrecords, or refers with and w/o clojure.core. - of course you can still use a regex-filter in addition on those results • adding a trace to a function with a simple button click and seeing the invocation information in your repl as the function is called - tools.trace is an underused gem of a tool! • (optional) color-coding based on the var-type: macros are red... functions are green. • optional download of the most recent clojuredocs-repo copy with on/off-line clojuredocs-info retrieval through simple menu commands • see basic info about (java-)classes like their class-inheritance list and the set of implemented interfaces • see the type and values of vars and the type and value of the @var... with their associated meta-maps. • see live-updates in realtime of new namespaces, new vars, and changed values... as they are defined by you at the repl or by your running program. • instructional, professional looking videos where Andy walks you thru the browser's features one-by-one (see the github page for links) • too many other features to list all here… Go over to github for install instructions, a wiki with documentation, and links to instructional videos: "https://github.com/franks42/clj-ns-browser";. Feedback, suggestions, and pull requests with yet more cool features, are very much appreciated! Enjoy, Frank Siebenlist Andy Fingerhut -- 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: [ANN] The "It starts to look like a real App", 1.2.0 release of the Clojure Namespace Browser (clj-ns-browser)
Can you please share your project.clj when you ask a Q like this? Thanks, FrankS. On May 5, 2012, at 5:01 PM, Rostislav Svoboda wrote: > I put > :dev-dependencies [[clj-ns-browser "1.2.0"]] > > to my project.clj and did: > > $ lein deps > Copying 46 files to /home/bost/dev/webcli/lib > [WARNING] Overriding profile: 'null' (source: pom) with new instance > from source: pom > [WARNING] Overriding profile: 'null' (source: pom) with new instance > from source: pom > [WARNING] Overriding profile: 'null' (source: pom) with new instance > from source: pom > Copying 29 files to /home/bost/dev/webcli/lib/dev > > $ lein repl > REPL started; server listening on localhost port 27581 > IllegalStateException escape-html already refers to: > #'hiccup.core/escape-html in namespace: hiccup.page > clojure.lang.Namespace.warnOrFailOnReplace (Namespace.java:88) > clojure.core=> > > when I comment out the > ; :dev-dependencies [[clj-ns-browser "1.2.0"]] > then everything works as before > > Bost -- 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: [ANN] Exploding Fish: A URI Library for Clojure
… but dolphins are no fish… On May 6, 2012, at 5:25 PM, Sean Neilan wrote: > Perhaps a reference to PHP's explode function which is the java equivalent of > String.split? > http://php.net/manual/en/function.explode.php > And then URI is the fish. > > Or it could be a reference to an unwritten sequel to Hitchhiker's Guide To > The Galaxy where the Dolphins blew up Earth instead of the Vogons. > > On Sun, May 6, 2012 at 4:49 PM, Jeffrey Straszheim > wrote: > > But why "Exploding Fish", Walter? > > Why? Why? > > Poor fish. > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Getting a Custom JFrame up and Running
You may want to check-out Dave Ray's seesaw .
"Seesaw turns the Horror of Swing into a friendly, well-documented, Clojure
library"
https://github.com/daveray/seesaw
-FS.
On May 10, 2012, at 3:03 PM, JvJ wrote:
> Hi,
>
> I'm new to Clojure, but a longtime Java programmer. I'm trying to get
> the hang of gen-class, and I'd like to write a custom JFrame that
> extends the paint method so I can get some ***aw3xX0m3 gr4f-X***.
>
> Anyways, I'm having some trouble understanding gen-class, inheritance,
> etc.
>
> Here's what I have so far:
>
> (import '(javax.swing JFrame)
>'(java.awt Graphics)
>'(java.awt.event WindowAdapter))
>
> (ns LifeFrame)
>
> (gen-class
> :name LFrame
> :extends javax.swing.JFrame
> :constructors {[String] [String]}
> :state state
> :prefix lFrame-)
>
> ;;; Draw a black rectangle
> (defn lFrame-paint [this gfx]
> (.fillRect gfx 0 0 100 100))
>
> (defn mainRun []
> (let [f (LifeFrame/LFrame.)]
>(.setVisible f true)));; Run the constructor
>
> When I call mainRun from the REPL, I get the following error:
>
> CompilerException java.lang.IllegalArgumentException: Unable to
> resolve classname: LFrame, compiling:(LifeFrame.clj:24)
>
>
> Any knowledge about this would be greatly appreciated.
>
> Thanks.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: defstruct defrecord metadata
Is this thread related to http://dev.clojure.org/jira/browse/CLJ-304 ? Would be nice to address that issue. -FrankS. On May 16, 2012, at 6:54 AM, Tim Visher wrote: > On Tue, May 15, 2012 at 12:11 PM, JDuPreez wrote: >> Maybe I should post my solution to this problem here? > > Sounds like a plan. :) > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: docstrings of if-let and when-let incorrect
Christophe Grand was "experimenting" with some extensions to if-let and when-let that had implicit ANDs for the let-forms: https://github.com/cgrand/parsley/blob/master/src/net/cgrand/parsley/util.clj It feels intuitive to me to allow multiple if-let-forms like cgrand implements, and I can certainly remember situations where I could have used such a feature. -FrankS. On May 16, 2012, at 11:26 AM, dgrnbrg wrote: > I too assumed that if/when-let would support multiple bindings, short- > circuiting if one failed, when I started learning Clojure. It seems > that short-circuiting multiple bindings isn't surprising. > > On May 16, 10:56 am, Jay Fields wrote: >> I've also attempted to use if/when-let with multiple bindings in the past. >> I assumed that it would behave as 'AND' and that no bindings would be >> available in 'else' >> >> Cheers, Jay >> >> >> >> >> >> >> >> On Wed, May 16, 2012 at 10:29 AM, Dan Cross wrote: >>> On Wed, May 16, 2012 at 9:16 AM, Aaron Cohen wrote: On Wed, May 16, 2012 at 9:10 AM, Walter Tetzner < >>> robot.ninja.saus...@gmail.com> wrote: > To make the bindings work like let, where later bindings can see >>> previous > bindings, I think the most natural way to do it is to have the bindings > behave like the maybe monad. > [...] >> Saying something is obvious and then using the word monad a paragraph >>> later is contradictory. ;) >> >>> Hypothetically, "this is obvious, unlike most monads." Zing! >> What should happen on the else branch of the if-let; which bindings are >>> in scope and what would be their values? >> >>> None of the bindings should be in scope. >> >>>- Dan C. >> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clojure@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Explaining the thrush -> operator.
Just nitpicking, but for me those thread-first/last operators beg for "proper" formatting with newlines and indentation to emphasize the "threading", like not: (-> 2 (* 5) (+ 3)) but: (-> 2 (* 5) (+ 3)) also as mentioned before, using thread-first and thread-last to name those macro-operators would help to remember what they do. -FS. On Jun 11, 2012, at 11:22 AM, Jacek Laskowski wrote: > On Sat, Jun 9, 2012 at 11:41 AM, Lucas Marinho wrote: > >> ((comp #(+ % 1) #(+ % 2)) 0) > > I couldn't resist. > > #(+ % 1) == inc > > #(+ % 2) == (partial + 2) > > They give much better-looking functional program. Hope you forgive me :-) > > Jacek > > -- > Jacek Laskowski > Functional languages (Clojure), Java EE, and IBM WebSphere - > http://blog.japila.pl > "Never discourage anyone who continually makes progress, no matter how > slow." Plato > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: [ANN] Nippy, a fast Clojure serializer and drop-in reader replacement
Just trying to understand the issues/solutions for the (de-)serializing of clojure data structures… With the tag literal support of 1.4+, is that kind of the idiomatic way of the future to structure protocols for serialized clojure data/code? When you say that Nippy is much faster than the reader, are there ways to improve on or optimize the reader? (guess the speed improvement is only achieved for true data (?)) Thanks, Frank. On Jul 7, 2012, at 11:24 PM, Peter Taoussanis wrote: > Hi Sun, > > Can't wait to test it out. > > Great- thank you! Let me know how it goes and if you run into any problems. > > By the way, do you have a performance comparison between Nippy and > carbonite(the one wraps kryo) ? > > Not yet, but plan to. I should probably also compare to JSON and a few > others. I would expect Carbonite to be faster since Kryo is faster than > standard Java serialization (which is basically what Nippy uses). > > The goal for Nippy isn't outright speed but a particular balance of speed, > simplicity, and usability that I was looking for for some of my own > applications. Actually, come to think of it, I will add links to some > alternatives like Kryo. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: [ANN] Nippy, a fast Clojure serializer and drop-in reader replacement
On Jul 10, 2012, at 1:51 AM, Peter Taoussanis wrote: > With the tag literal support of 1.4+, is that kind of the idiomatic way of > the future to structure protocols for serialized clojure data/code? > > Sorry, could you clarify what you're asking here - I'm not sure if I follow > what you mean by "structure protocols"? I'm not familiar with the > implementation details of the tagged literal support btw, so someone else > should probably chime in if that's the domain. Sorry for being a little terse with my initial Q… The idea is that you could use tagged literals for the serialized data format (not "protocol" as I mentioned). In your example: > (def my-uuid (java.util.UUID/randomUUID)) > => #uuid "c463d8d3-49f4-4e40-9937-8a9699b1af1d" > > (thaw-from-bytes (freeze-to-bytes my-uuid)) > => #uuid "c463d8d3-49f4-4e40-9937-8a9699b1af1d" You can see that the tag #uuid is taken by the reader as kind of a constructor that takes the string as an argument and returns/substitutes it by the uuid object/instance. You could extend it such that your custom contructor function could take a stringified, compressed binary representation of the object. Alex mentions that "marshalling data to/from strings is neither fast nor small compared to other binary alternatives", which is true in general, but because those tag-contructors are yours to write, you could optimize the data format and encodings based on the datatype, and possibly overcome some of those speed/size limitations. The advantage is that it's all clojure and doesn't rely on java serialization, while the disadvantage is that it will probably always be slower/bigger than pure binary formats... but maybe not that much. (disclaimer: I have no experience writing those kind of encoders/decoders - just interested in how they work/could-work with pros&cons) -FrankS. -- 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 on an Erlang-vm-os on Xen?
Just became aware of this effort: "http://erlangonxen.org/"; which shows off some impressive properties: * Startup time of a new instance is 100ms * Instances are provisioned after the request arrival - all requests get handled * No instances are running waiting for requests - the cloud footprint is zero * the size of infrastructure is proportional to the maximum load - 8 servers may be enough * … All that begs the Q: would Clojure on an Elang-VM be feasible and make sense? -FrankS. -- 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: seesaw's beautiful docstrings
We have an smalltalk-like clojure namespace/var/type-browser for docstrings/clojuredocs/source at "https://github.com/franks42/clj-ns-browser"; that may be of use… which happens to be built on top of seesaw. -FrankS. On Jul 25, 2012, at 7:25 PM, Mark Derricutt wrote: > On 25/07/12 9:17 PM, Laurent PETIT wrote: >> Third option : use an editor/IDE which allows you to "fold" docs (one by one >> / fold all / unfold all), and / or to navigate in your source code via "code >> outlines" > I was just musing on wanting a Hopscotch style IDE for clojure: > > http://theoryinpractise.tumblr.com/post/28023552869/everytime-i-tinker-with-newspeak-i-keep-thinking > > The IDE gives a nice code browser, navigating between namespaces and > functions in a collapsible manner along with a REPL. > > Mark > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: [viewing clojure datastructures] Is there something better than clojure.inspector?
Check out clj-ns-browser ("https://github.com/franks42/clj-ns-browser";).
When a var is defined, you can look at it's value, which is presented with
pprint, which means that most data structures are nicely displayed.
When the value is a list/tree-like data structure, you can bring up Rich's
original tree browser with the click of a button to look at the values. (that
widget should really be rewritten as it's look and feel good be improved… but
it works!)
Furthermore, there is a menu button that turns on an auto-refresh for the var's
displayed value such that you can follow the var's value near real-time.
This may help with your requirements...
Enjoy, Frank.
On Aug 22, 2012, at 1:58 PM, Denis Labaye wrote:
> Hi everyone,
>
> The clojure.inspector functions are ... mmm ... a bit "rough on the edge" =)
>
> Is there any lib that provide better support for exploring Clojure
> data-structures?
>
> I am surprised I didn't found anything on Google, GitHub, ...
> Data-structures are at the core of Clojure, so being able to view / explore
> them seems a basic need to me.
>
> For example:
>
> ;; this works fine
> (clojure.inspector/inspect-tree (range 10))
>
> ;; this breaks
> (clojure.inspector/inspect-tree (range))
>
> It seems to me that it would be trivial™ to implement a viewer that would be
> able to display (possibly infinite) lazy nested data structures.
>
> Any ideas?
>
> Cheers,
>
> Denis
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Joxa (Re: Clojure on an Erlang-vm-os on Xen?)
Just got this link "http://joxa.org"; about a new lisp-like language thru prismatic: Joxa is a small semantically clean, functional lisp. It is a general-purpose language encouraging interactive development and a functional programming style. Joxa runs on the Erlang Virtual Machine. Like other Lisps, Joxa treats code as data and has a full (unhygienic) macro system. Joxa (pronounced 'jocksah') isn't Erlang, though its very compatible. Its not Clojure though there is plenty of shared syntax. It's not Common Lisp though that is the source of the macro system. While Joxa shares elements of many languages, it is its own specific language. of all these languages, and knowing these languages will help you get up to speed with Joxa, but it is its own unique language. Just skimming the example shows a syntax that resembles clojure a little bit… Wonder if that implementation as an example would make it easier to have a clojure-on-erlang-vm implementation. Enjoy, Frank. On Jul 13, 2012, at 10:15 AM, Frank Siebenlist wrote: > Just became aware of this effort: "http://erlangonxen.org/"; > > which shows off some impressive properties: > > * Startup time of a new instance is 100ms > * Instances are provisioned after the request arrival - all requests get > handled > * No instances are running waiting for requests - the cloud footprint is zero > * the size of infrastructure is proportional to the maximum load - 8 servers > may be enough > * … > > All that begs the Q: would Clojure on an Elang-VM be feasible and make sense? > > -FrankS. > > -- 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] clj-ns-browser 1.3.0 - the "cool button-row widget" release
We're happy to announce the new clj-ns-browser 1.3.0 - the "cool button-row
widget" - release.
The Clojure Namespace Browser is a GUI-based, Smalltalk-like development tool
that makes it easy to see, inspect, search, and browse the different
namespaces, classes/types, and vars of your live Clojure environment. It allows
you to see the online docs, the source code, the associated clojuredocs
comments/examples/see-alsos, as well as the var's meta-data and values.
Installation is achieved by adding a single line to your project.clj:
;; Leiningen version 1
:dev-dependencies [[clj-ns-browser "1.3.0"]]
;; Leiningen version 2
:profiles {:dev {:dependencies [[clj-ns-browser "1.3.0"]]}}
After (use 'clj-ns-browser.sdoc), the browser can be invoked at the REPL with
for example: (sdoc map)
where "sdoc" is a macro equivalent to and compatible with the venerable
"clojure.repl/doc" one, but give you just a "little" more info. After the
browser's GUI is invoked, you can point&click to your heart's content.
A few of the highlights of the new release are:
• upgraded dependencies to latest&greatest (clojure 1.4, seesaw 1.4.2, etc.)
• Andy concocted a cool, new, button-row widget that allows for a more flexible
display of var/class/namespace information.
• syntax highlighting of source code thru use of rsyntaxtextarea
• improved invocation of external web-browser
• many invisible improvements...
There are too many other great features to mention here - please take a look at:
"https://github.com/franks42/clj-ns-browser";
Enjoy,
Frank Siebenlist
Andy Fingerhut
--
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: Calling Clojurescript code from Clojure
I have the same requirement to have a clojurescript-form in my
clojure-environment that I want to evaluate in the browser…
To make the following code-snippet work, you're supposed to have a browser-repl
session running, and start a new repl-session on that same JVM from where you
invoke the following forms to execute either javascript-code or
clojurescript-forms in the browser.
---
user=> (require 'cljs.repl)
nil
user=> (require 'cljs.repl.browser)
nil
user=> (cljs.repl.browser/browser-eval "alert('No Way!')")
{:status :success, :value ""}
user=> (def my-repl-env {:port 9000, :optimizations :simple, :working-dir
".lein-cljsbuild-repl", :serve-static true, :static-dir ["." "out/"],
:preloaded-libs []})
#'user/my-repl-env
user=> (def my-env {:context :statement :locals {}})
#'user/my-env
user=> (#'cljs.repl/eval-and-print my-repl-env my-env '(js/alert "Yes Way!"))
nil
nil
user=>
---
The public function "cljs.repl.browser/browser-eval" seems to allow you to send
javascript code as a string to the browser to execute over the existing
browser-repl connection.
The private function "cljs.repl/eval-and-print" will take a clojurescript form,
compile it to javascript and send it to the browser for execution. The
"my-repl-env" and "my-env" values are artifacts needed that are normally only
available within the context of the function.
My apology for this huge&ugly hack… please see it as a proof of principle.
There may be much more elegant solutions available… I've only scratch the
surface of understanding how this clojurescript repl works in detail.
-Enjoy, FrankS
On Sep 17, 2012, at 9:03 PM, Brent Millare wrote:
> And yes by eval I mean compile and run on the target (browser)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Q about eval-and-print function in clojurescript's cljs.repl (repl.clj)
I'm trying to understand the clojurescript-code of the repl functionality, and I'm confused… The following cljs.repl/eval-and-print function takes a cljs-form, compiles it, sends it to the browser as javascript, and then receives the result, and the… try's to use "read-string" on that return value: --- (defn- eval-and-print [repl-env env form] (let [ret (evaluate-form repl-env (assoc env :ns (ana/get-namespace ana/*cljs-ns*)) "" form (wrap-fn form))] (try (prn (read-string ret)) (catch Exception e (if (string? ret) (println ret) (prn nil)) --- Why does it call read-string on the returned result from the js-eval? The eval'ed compiled javascript could result in a clojure-form that would be eval'ed on the return (???), and the result of the latter is then printed. Confusingly yours, FrankS. -- 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: Q about eval-and-print function in clojurescript's cljs.repl (repl.clj)
Sorry - I've answered part of my own Q by reading the read-string doc… nothing is eval'ed of the result - just the first "object" is read. Still unclear why read-string is used - why would a second "object" be discarded? Like: user=> (read-string "(+ 1 2) (- 3 2)") (+ 1 2) Still confused... -FS. On Sep 18, 2012, at 11:51 PM, Frank Siebenlist wrote: > I'm trying to understand the clojurescript-code of the repl functionality, > and I'm confused… > > The following cljs.repl/eval-and-print function takes a cljs-form, compiles > it, sends it to the browser as javascript, and then receives the result, and > the… try's to use "read-string" on that return value: > > --- > (defn- eval-and-print [repl-env env form] > (let [ret (evaluate-form repl-env > (assoc env :ns (ana/get-namespace ana/*cljs-ns*)) > "" > form > (wrap-fn form))] >(try (prn (read-string ret)) > (catch Exception e > (if (string? ret) > (println ret) > (prn nil)) > --- > > Why does it call read-string on the returned result from the js-eval? > > The eval'ed compiled javascript could result in a clojure-form that would be > eval'ed on the return (???), and the result of the latter is then printed. > > Confusingly yours, FrankS. > -- 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: Q about eval-and-print function in clojurescript's cljs.repl (repl.clj)
Thanks for investigating. It seems that inside evaluate-form that map returned by -evaluate, but then the :value's value of that map is returned to the eval-and-print function where that is "read-string" again… Anyway, got it to work now - thanks. On Sep 19, 2012, at 6:47 AM, Hubert Iwaniuk wrote: > If you look at cljs counterpart of it you'll see that maps are send as > responses, that is why read-string is used. > > HTH > > Frank Siebenlist wrote: >> >> Sorry - I've answered part of my own Q by reading the read-string doc… >> nothing is eval'ed of the result - just the first "object" is read. >> >> Still unclear why read-string is used - why would a second "object" be >> discarded? Like: >> >> user=> (read-string "(+ 1 2) (- 3 2)") >> (+ 1 2) >> >> Still confused... >> >> -FS. >> >> >> On Sep 18, 2012, at 11:51 PM, Frank Siebenlist >> wrote: >> >>> >>> I'm trying to understand the clojurescript-code of the repl functionality, >>> and I'm confused… >>> >>> The following cljs.repl/eval-and-print function takes a cljs-form, compiles >>> it, sends it to the browser as javascript, and then receives the result, >>> and the… try's to use "read-string" on that return value: >>> >>> --- >>> (defn- eval-and-print [repl-env env form] >>> (let [ret (evaluate-form repl-env >>>(assoc env :ns (ana/get-namespace ana/*cljs-ns*)) >>>"" >>>form >>>(wrap-fn form))] >>> (try (prn (read-string ret)) >>> (catch Exception e >>>(if (string? ret) >>> (println ret) >>> (prn nil)) >>> --- >>> >>> Why does it call read-string on the returned result from the js-eval? >>> >>> The eval'ed compiled javascript could result in a clojure-form that would >>> be eval'ed on the return (???), and the result of the latter is then >>> printed. >>> >>> Confusingly yours, FrankS. >>> >> > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Redirect *out* of the cljs-repl?
To be more precise, if you do a (print "something") in a cljs-script, that gets
compiled and evaluated in the browser's js-vm, then the result is sent back
thru a separate http-post and dispatched to the multimethod "handle-post"
implementation for :print in clojurescript's cljs.repl.browser:
--
(defmethod handle-post :print [{:keys [content order]} conn _ ]
(do (constrain-order order (fn [] (do (print (read-string content))
(.flush *out*
(server/send-and-close conn 200 "ignore__"
--
If you evaluate a cljs-form thru a direct call of cljs.repl/evaluate-form from
a different thread than the cljs-repl, then any output from (print "something")
will be printed in the cljs-repl terminal session and not the terminal where
you invoked the cljs.repl/evaluate-form from.
That the "defmethod handle-post :print" cannot use the terminal's *out* where
cljs.repl/evaluate-form is invoked, is understandable because it runs in a
different thread.
The issue is that it's not just another thread, it seems a completely different
context as the http-post handlers run asynchronous from any sent js-code.
This seems the reason that using any (binding [*out* terminal-out]
(cljs.repl/evaluate-form …)) doesn't work - or I cannot make it work…
Right now I can make it work by saving the terminal's *out* in an atom and
using it's value directly in the handle-post code, like:
--
(def context-out (atom nil))
(defmethod handle-post :print [{:keys [content order]} conn _ ]
(if @context-out
(do (constrain-order order (fn [] (binding [*out* @context-out]
(do (print (read-string content))
(.flush *out*)
(server/send-and-close conn 200 "ignore__"))
(do (constrain-order order (fn [] (do (print (read-string content))
(.flush *out*
(server/send-and-close conn 200 "ignore__"
--
If I do (reset! cljs.repl.browser/context-out *out*) in the clj-repl, then the
stdout of the cljs-repl gets redirected to my terminal… as I want.
However, it feels like a hack and I was hoping that I missed a better
alternative… any suggestions or comments are most welcome.
Thanks, FrankS.
--
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
clojurescript: how to use clojure.reflect/doc in the cljs-repl?
Trying to use the clojure.reflect/doc function in the cljs-repl, but I only errors" --- ClojureScript:cljs.user> (clojure.reflect/doc "clojure.reflect/doc") nil Reflection query failed. ClojureScript:cljs.user> (clojure.reflect/doc clojure.reflect.doc) nil Reflection query failed. ClojureScript:cljs.user> (clojure.reflect/doc 'clojure.reflect.doc) nil Reflection query failed. ClojureScript:cljs.user> (clojure.reflect/doc 'doc) nil Reflection query failed. --- Do I have to configure something on the server side maybe? Any suggestions? Thanks, FrankS. -- 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
clojurescript: *ns*, all-ns, ns-map, ns-publics, ns-* ?
Understand that there are no implementations (yet) of *ns*, all-ns, ns-map, ns-publics, ns-* for cljs, but was wondering how some of that associated info could be found at the repl or in your cljs-code… Could I introspect the java object hierarchy to find some of that information? Thanks, Frank. -- 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
clojurescript: var names with "-" and "_" are rendered to the same internal name (?)
The following cljs-repl session shows the issue: ClojureScript:cljs.user> (def my-var "YES") "YES" ClojureScript:cljs.user> my-var "YES" ClojureScript:cljs.user> (def my_var "NO") "NO" ClojureScript:cljs.user> my_var "NO" ClojureScript:cljs.user> my-var "NO" ClojureScript:cljs.user> (set! my-var "MAYBE") "MAYBE" ClojureScript:cljs.user> my_var "MAYBE" ClojureScript:cljs.user> The official clojure spec allows both "-" and "_" in the symbol names (http://clojure.org/reader), and the clojurescript docs don't mention anything about this as far as I could tell. Not sure if this has been reported before - I searched JIRA and the mailing list, but couldn't find anything, but it's difficult to search for "_"… Bug? Mapping limitation? -FrankS. -- 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: clojurescript: var names with "-" and "_" are rendered to the same internal name (?)
That CLJS-336 feels like a different issue that doesn't map to what I'm seeing... On Sep 24, 2012, at 1:45 AM, Raju Bitter wrote: > Identifiers in JavaScript cannot contain a hyphen/minus character: > https://developer.mozilla.org/en-US/docs/JavaScript/Guide/Values,_variables,_and_literals >> A JavaScript identifier must start with a letter, underscore (_), or dollar >> sign ($); >> subsequent characters can also be digits (0-9). Because JavaScript is case >> sensitive, letters include the characters "A" through "Z" (uppercase) and the >> characters "a" through "z" (lowercase). >> Starting with JavaScript 1.5, you can use ISO 8859-1 or Unicode letters such >> as å and ü in identifiers. You can also use the \u Unicode escape >> sequences as characters in identifiers." > > ClojureScript maps all hyphens in identifiers to underscores. > > This has been reported as a bug for protocols before: > http://dev.clojure.org/jira/browse/CLJS-336 > > - Raju -- 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: clojurescript: var names with "-" and "_" are rendered to the same internal name (?)
Thanks for digging.
The mapping of "-" to "_" comes indeed from clojure.lang.Compile/munge which is
called by cljsh.compiler/munge:
user=> (#'cljs.compiler/munge "-")
"_"
user => (clojure.lang.Compiler/munge "-")
"_"
user => (clojure.lang.Compiler/munge "_")
"_"
user =>
Looking at the java-source, the reason can be found in the CHAR_MAP mapping
table in Compiler.java:
static final public IPersistentMap CHAR_MAP =
PersistentHashMap.create('-', "_",
// '.', "_DOT_",
':', "_COLON_",
'+', "_PLUS_",
'>', "_GT_",
'<', "_LT_",
'=', "_EQ_",
'~', "_TILDE_",
'!', "_BANG_",
'@', "_CIRCA_",
'#', "_SHARP_",
'\'', "_SINGLEQUOTE_",
'"', "_DOUBLEQUOTE_",
'%', "_PERCENT_",
'^', "_CARET_",
'&', "_AMPERSAND_",
'*', "_STAR_",
'|', "_BAR_",
'{', "_LBRACE_",
'}', "_RBRACE_",
'[', "_LBRACK_",
']', "_RBRACK_",
'/', "_SLASH_",
'\\', "_BSLASH_",
'?', "_QMARK_");
static public String munge(String name){
StringBuilder sb = new StringBuilder();
for(char c : name.toCharArray())
{
String sub = (String) CHAR_MAP.valAt(c);
if(sub != null)
sb.append(sub);
else
sb.append(c);
}
return sb.toString();
}
Note that it's in the first entry of CHAR_MAP - a little obscured by the
(original) formatting.
What's puzzling is that all mappings use a convention to map the char to a
_WORD_ , except the "-" which gets mapped to "_" directly.
What's further puzzling is that in the clj-repl this mapping deosn't seemed to
be used:
user=> (def my-var "YES")
#'user/my-var
user => (def my_var "NO")
#'user/my_var
user => my-var
"YES"
swimtimer=>
Guess the AOT compiler uses it but the REPL-one doesn't (???).
Confused - FrankS.
On Sep 24, 2012, at 6:53 AM, Herwig Hochleitner wrote:
>
> Not sure if this has been reported before - I searched JIRA and the mailing
> list, but couldn't find anything, but it's difficult to search for "_"…
>
> Bug?
> Mapping limitation?
>
> This behavior comes from cljs.compiler/munge, I'd say it's a mapping
> limitation that should be considered a bug.
> A possible fix would be to replace _ with _UNDERSCORE_ in munge.
>
> Notice that clojure.core/munge has the same limitation and should probably
> fixed aswell:
>
> (defn foo-bar []
> "DASH")
>
> (defn foo_bar []
> "UNDERSCORE")
>
> (defn -main []
> (println "Dash version: " (foo-bar))
> (println "Underscore version: " (foo_bar)))
>
>
> When AOT compiling this example and running it, it prints:
>
> Dash version: UNDERSCORE
> Underscore version: UNDERSCORE
>
> as opposed to the expected
>
> Dash version: DASH
> Underscore version: UNDERSCORE
>
> when running from source.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: clojurescript: *ns*, all-ns, ns-map, ns-publics, ns-* ?
Thanks Stuart - especially @namespaces is very helpful for understanding more about the resolution process. On Sep 26, 2012, at 12:00 PM, Stuart Sierra wrote: > Some of this information exists in the CLJS compiler, although it's not > documented. > > For example, the cljs.analyzer namespace has *cljs-ns* and `namespaces`. You > could examine these Vars at the Clojure (not ClojureScript) REPL. > > Vars and namespaces do not exist at all in compiled CLJS code, so you can't > access them from CLJS. This is unlikely to change. > -S > -- 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: clojurescript: how to use clojure.reflect/doc in the cljs-repl?
…bumb… Is this maybe related to the use of lein-cljsbuild and having a separate server from which the js is downloaded? In other words, the reflect handler seems to be listening on the repl server on port 9000, while the web server from which the js is initially downloaded is listening on port 3000. The cljs-reflect code seems to get a conn from (net/xhr-connection), but I can not see any port number specified… I've reached the end of my javascript and goog knowledge… please. Did anyone get this to work with the lein-cljsbuild setup? -FrankS. On Sep 23, 2012, at 2:10 PM, Frank Siebenlist wrote: > Trying to use the clojure.reflect/doc function in the cljs-repl, > but I only errors" > > --- > > ClojureScript:cljs.user> (clojure.reflect/doc "clojure.reflect/doc") > nil > Reflection query failed. > ClojureScript:cljs.user> (clojure.reflect/doc clojure.reflect.doc) > nil > Reflection query failed. > ClojureScript:cljs.user> (clojure.reflect/doc 'clojure.reflect.doc) > nil > Reflection query failed. > ClojureScript:cljs.user> (clojure.reflect/doc 'doc) > nil > Reflection query failed. > > --- > > Do I have to configure something on the server side maybe? > Any suggestions? > > Thanks, FrankS. > -- 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: clojurescript: how to use clojure.reflect/doc in the cljs-repl?
Forgot to mention that the issue is most probably on the browser side,
because pointing a webbrowser at
"http://localhost:9000/reflect?var=example.hello/say-hello"; by hand,
yields in the browser window:
cljs.core.ObjMap.fromObject(["\uFDD0'method-params","\uFDD0'name","\uFDD0'doc","\uFDD0'line","\uFDD0'file"],{"\uFDD0'method-params":"[[]]","\uFDD0'name":"example.hello/say-hello","\uFDD0'doc":"say-hello
doc","\uFDD0'line":10,"\uFDD0'file":"/Users/franks/Development/ClojureScript/swimtimer/src-cljs/example/hello.cljs"});
which is what one expects.
-FS.
On Oct 5, 2012, at 9:13 PM, Frank Siebenlist wrote:
> …bumb…
>
> Is this maybe related to the use of lein-cljsbuild and having a separate
> server from which the js is downloaded?
>
> In other words, the reflect handler seems to be listening on the repl server
> on port 9000,
> while the web server from which the js is initially downloaded is listening
> on port 3000.
>
> The cljs-reflect code seems to get a conn from (net/xhr-connection), but I
> can not see any port number specified…
>
> I've reached the end of my javascript and goog knowledge… please.
>
> Did anyone get this to work with the lein-cljsbuild setup?
>
> -FrankS.
>
>
>
> On Sep 23, 2012, at 2:10 PM, Frank Siebenlist
> wrote:
>
>> Trying to use the clojure.reflect/doc function in the cljs-repl,
>> but I only errors"
>>
>> ---
>>
>> ClojureScript:cljs.user> (clojure.reflect/doc "clojure.reflect/doc")
>> nil
>> Reflection query failed.
>> ClojureScript:cljs.user> (clojure.reflect/doc clojure.reflect.doc)
>> nil
>> Reflection query failed.
>> ClojureScript:cljs.user> (clojure.reflect/doc 'clojure.reflect.doc)
>> nil
>> Reflection query failed.
>> ClojureScript:cljs.user> (clojure.reflect/doc 'doc)
>> nil
>> Reflection query failed.
>>
>> ---
>>
>> Do I have to configure something on the server side maybe?
>> Any suggestions?
>>
>> Thanks, FrankS.
>>
>
--
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: clojurescript: how to use clojure.reflect/doc in the cljs-repl?
Ok - I managed to get clojure.reflect/doc to work if the browser loads the
javascript from the repl-server instead of the separate webserver…
When the reason for this issue is that the repl- & web-servers are listening on
different ports, where the js is downloaded from the webserver while the
reflect-handler is associaed with the repl-server…
then you will not be able to use the clojure.reflect/doc with the standard
lein-cljsbuild setup.
Unless you can somehow specify the port number for the clojure.reflect/doc GET
request (?).
Ough.
-FS.
On Oct 5, 2012, at 9:28 PM, Frank Siebenlist wrote:
> Forgot to mention that the issue is most probably on the browser side,
> because pointing a webbrowser at
> "http://localhost:9000/reflect?var=example.hello/say-hello"; by hand,
> yields in the browser window:
>
> cljs.core.ObjMap.fromObject(["\uFDD0'method-params","\uFDD0'name","\uFDD0'doc","\uFDD0'line","\uFDD0'file"],{"\uFDD0'method-params":"[[]]","\uFDD0'name":"example.hello/say-hello","\uFDD0'doc":"say-hello
>
> doc","\uFDD0'line":10,"\uFDD0'file":"/Users/franks/Development/ClojureScript/swimtimer/src-cljs/example/hello.cljs"});
>
> which is what one expects.
>
> -FS.
>
>
> On Oct 5, 2012, at 9:13 PM, Frank Siebenlist
> wrote:
>
>> …bumb…
>>
>> Is this maybe related to the use of lein-cljsbuild and having a separate
>> server from which the js is downloaded?
>>
>> In other words, the reflect handler seems to be listening on the repl server
>> on port 9000,
>> while the web server from which the js is initially downloaded is listening
>> on port 3000.
>>
>> The cljs-reflect code seems to get a conn from (net/xhr-connection), but I
>> can not see any port number specified…
>>
>> I've reached the end of my javascript and goog knowledge… please.
>>
>> Did anyone get this to work with the lein-cljsbuild setup?
>>
>> -FrankS.
>>
>>
>>
>> On Sep 23, 2012, at 2:10 PM, Frank Siebenlist
>> wrote:
>>
>>> Trying to use the clojure.reflect/doc function in the cljs-repl,
>>> but I only errors"
>>>
>>> ---
>>>
>>> ClojureScript:cljs.user> (clojure.reflect/doc "clojure.reflect/doc")
>>> nil
>>> Reflection query failed.
>>> ClojureScript:cljs.user> (clojure.reflect/doc clojure.reflect.doc)
>>> nil
>>> Reflection query failed.
>>> ClojureScript:cljs.user> (clojure.reflect/doc 'clojure.reflect.doc)
>>> nil
>>> Reflection query failed.
>>> ClojureScript:cljs.user> (clojure.reflect/doc 'doc)
>>> nil
>>> Reflection query failed.
>>>
>>> ---
>>>
>>> Do I have to configure something on the server side maybe?
>>> Any suggestions?
>>>
>>> Thanks, FrankS.
>>>
>>
>
--
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: clojurescript: how to use clojure.reflect/doc in the cljs-repl?
David, please do not apologize… your contributions to clojurescript have been
invaluable, and the last time I checked you still have a full-time job with
that village-newspaper somewhere on the East coast...
My current efforts are to help improve the clojurescript help facilities. I
have working versions of the apropos, ns-resolve, find-ns, source-fn,
ns-map&friends, and managed to make our clj-ns-browser work with that
clojurescript metadata such that you can browse the cljs-namespaces (see
https://gist.github.com/3803119 and
https://raw.github.com/franks42/clj-ns-browser/cljs/Cljs%20Browser%202012-10-05.png
for some "proof of progress").
All those facilities run on the clj-jvm and make use of the meta-data in the
cljs.analyzer/@namespaces map. You can invoke them from any clj-repl that
connects to the same jvm while you interact with the cljs-repl.
To make them available to the cljs-repl, you ideally need some form of rpc-like
calls to get that info from the clj-jvm, like the clojure.reflect/doc
implementation (the repl-prompting is a little awkward, though - with all the
asynchronous processing it may be better to drive the promp-printing from the
js-side… but that's a different discussion)
As I didn't get clojure.reflect/doc to work, I've used the "special-fns"
interface that you pass into the "cljs.repl/repl" function. However, and I
don't think I will offend anyone, the way how those "special-fns" are
implemented is one huge ugly hack…;-), and I do not really want to share my
project while it depends on that.
So… that's why I was trying so hard to make that clojure.reflect/doc work with
lein-cljsbuild.
Regards, FrankS.
On Oct 6, 2012, at 7:56 AM, David Nolen wrote:
> Sorry about the reflect stuff is quite new and in need of work. The reflect
> support should work through whatever port browser REPL was setup on.
>
> On Saturday, October 6, 2012, Frank Siebenlist wrote:
> Ok - I managed to get clojure.reflect/doc to work if the browser loads the
> javascript from the repl-server instead of the separate webserver…
>
> When the reason for this issue is that the repl- & web-servers are listening
> on different ports, where the js is downloaded from the webserver while the
> reflect-handler is associaed with the repl-server…
> then you will not be able to use the clojure.reflect/doc with the standard
> lein-cljsbuild setup.
>
> Unless you can somehow specify the port number for the clojure.reflect/doc
> GET request (?).
>
> Ough.
>
> -FS.
>
>
> On Oct 5, 2012, at 9:28 PM, Frank Siebenlist
> wrote:
>
> > Forgot to mention that the issue is most probably on the browser side,
> > because pointing a webbrowser at
> > "http://localhost:9000/reflect?var=example.hello/say-hello"; by hand,
> > yields in the browser window:
> >
> > cljs.core.ObjMap.fromObject(["\uFDD0'method-params","\uFDD0'name","\uFDD0'doc","\uFDD0'line","\uFDD0'file"],{"\uFDD0'method-params":"[[]]","\uFDD0'name":"example.hello/say-hello","\uFDD0'doc":"say-hello
> >
> > doc","\uFDD0'line":10,"\uFDD0'file":"/Users/franks/Development/ClojureScript/swimtimer/src-cljs/example/hello.cljs"});
> >
> > which is what one expects.
> >
> > -FS.
> >
> >
> > On Oct 5, 2012, at 9:13 PM, Frank Siebenlist
> > wrote:
> >
> >> …bumb…
> >>
> >> Is this maybe related to the use of lein-cljsbuild and having a separate
> >> server from which the js is downloaded?
> >>
> >> In other words, the reflect handler seems to be listening on the repl
> >> server on port 9000,
> >> while the web server from which the js is initially downloaded is
> >> listening on port 3000.
> >>
> >> The cljs-reflect code seems to get a conn from (net/xhr-connection), but I
> >> can not see any port number specified…
> >>
> >> I've reached the end of my javascript and goog knowledge… please.
> >>
> >> Did anyone get this to work with the lein-cljsbuild setup?
> >>
> >> -FrankS.
> >>
> >>
> >>
> >> On Sep 23, 2012, at 2:10 PM, Frank Siebenlist
> >> wrote:
> >>
> >>> Trying to use the clojure.reflect/doc function in the cljs-repl,
> >>> but I only errors"
> >>>
> >>> ---
> >>>
> >>> ClojureScript:cljs.user> (clojure.reflect/doc "clojure.reflect/doc")
> >>> nil
> >>> R
Cljs-repl server as ring middleware?
I've been digging through the clojurescript code lately, and making some changes to the repl-related code. This is quite difficult as clojurescript seems to have its own "proprietary" implementation of a webserver that serves the repl-communication as well as other possible handlers, like the reflection-based stuff. Having a repl-server based on ring-middleware would give you more modularity, and easier pluggability with the ring-based webserver code that in many/most cases will coexist with the repl-session. I've searched for any discussiond or efforts in this space, but couldn't find any… Would such a ring-based alternative make sense? Any existing efforts in this space? Any reasons why the current "hardcoded" web server would be better/preferable? -FrankS. -- 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: Cljs-repl server as ring middleware?
I understand the idea of minimizing the dependencies of a basic clojurescript development deployment with a working repl. However, I find the basic deployment that is prescribed by lein-cljsbuild not very "basic" when it starts-up 3 different jvm's while the repl-server and webserver do not share the live clojurescript metadata, and where we have issues with cross-site hurdles that complicates using the repl-server as a conventional webserver, which is needed to get a help/reflection facility going… it's a complicated beast… hopefully we get that all working more smoothly soon. You're right that this ring-repl implementation coud be an alternative project, which could have the advantage that you would be able to add a repl-service and/or reflection/service through standard ring-middleware modules - with could potentially benefit from other modules to provide ssl, authN&authZ, websockets/aleph, etc. Just wanting to here the pros&cons. -FrankS. On Oct 8, 2012, at 9:57 AM, David Nolen wrote: > On Mon, Oct 8, 2012 at 12:51 PM, Frank Siebenlist > wrote: >> I've been digging through the clojurescript code lately, and making some >> changes to the repl-related code. This is quite difficult as clojurescript >> seems to have its own "proprietary" implementation of a webserver that >> serves the repl-communication as well as other possible handlers, like the >> reflection-based stuff. >> >> Having a repl-server based on ring-middleware would give you more >> modularity, and easier pluggability with the ring-based webserver code that >> in many/most cases will coexist with the repl-session. >> >> I've searched for any discussiond or efforts in this space, but couldn't >> find any… >> >> Would such a ring-based alternative make sense? >> Any existing efforts in this space? >> Any reasons why the current "hardcoded" web server would be >> better/preferable? >> >> -FrankS. > > The hard coded web server is not meant to be general solution at all. > It just gets you a usable browser REPL with minimal hassle. Making > ClojureScript depend on Ring makes little sense to me, but seems fine > for an alternative browser REPL implementations. > > Though of course I think it's preferable that people simple fix the > one that ships w/ ClojureScript since then a much larger group of > people benefit out of the box. > > David > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Cljs-repl server as ring middleware?
Kevin - thanks for the pointers. I looked at those projects before, and they do make it easier to use the clojurescript-repl thru nrepl&friends, but unless I missed the features, it doesn't help with moving the repl-server in the same execution context as the web server, and to make the reflection-interface easier accessible over http (?). -FrankS. On Oct 8, 2012, at 10:04 AM, Kevin Downey wrote: > I'd checkout nrepl and nrepl middlewares, which can be exposed over > http (via ring middleware) or other transports. > > https://github.com/hiredman/drawbridge-cljs is an nrepl http client > for clojurescript > > https://github.com/hiredman/nrepl-cljs-middleware is an example of a > nrepl middleware, which exposes clojurescript compilation as an nrepl > command > > On Mon, Oct 8, 2012 at 9:51 AM, Frank Siebenlist > wrote: >> I've been digging through the clojurescript code lately, and making some >> changes to the repl-related code. This is quite difficult as clojurescript >> seems to have its own "proprietary" implementation of a webserver that >> serves the repl-communication as well as other possible handlers, like the >> reflection-based stuff. >> >> Having a repl-server based on ring-middleware would give you more >> modularity, and easier pluggability with the ring-based webserver code that >> in many/most cases will coexist with the repl-session. >> >> I've searched for any discussiond or efforts in this space, but couldn't >> find any… >> >> Would such a ring-based alternative make sense? >> Any existing efforts in this space? >> Any reasons why the current "hardcoded" web server would be >> better/preferable? >> >> -FrankS. >> >> >> >> -- >> 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 > > > > -- > And what is good, Phaedrus, > And what is not good— > Need we ask anyone to tell us these things? -- 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: Cljs-repl server as ring middleware?
Understood that was the initial reason, but how about the reflection interface? Should that be rerendered to use the same CrossPageChannel connection? -FrankS. On Oct 8, 2012, at 12:03 PM, David Nolen wrote: > On Mon, Oct 8, 2012 at 2:38 PM, Frank Siebenlist > wrote: >> However, I find the basic deployment that is prescribed by lein-cljsbuild >> not very "basic" when it starts-up 3 different jvm's while the repl-server >> and webserver do not share the live clojurescript metadata, and where we >> have issues with cross-site hurdles that complicates using the repl-server >> as a conventional webserver, which is needed to get a help/reflection >> facility going… it's a complicated beast… hopefully we get that all working >> more smoothly soon. > > I don't think ClojureScript should try to solve this problem. > > The only reason we have a webserver at all in ClojureScript is because > Google's CrossPageChannel (which is what browser REPL is built on) > stopped working when developing against a single page with the file:// > protocol in browsers. The webserver in ClojureScript was only intended > to address this and nothing more. > > David > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Cljs-repl server as ring middleware?
Ok - thanks - slowly start to see the path ;-) I cannot find an explicit JIRA entry for that "reflection interface over CrossPageChannel" - should I add one for this, or did I miss the issue#? -FS. On Oct 8, 2012, at 12:47 PM, David Nolen wrote: > On Mon, Oct 8, 2012 at 3:45 PM, Frank Siebenlist > wrote: >> Understood that was the initial reason, but how about the reflection >> interface? >> >> Should that be rerendered to use the same CrossPageChannel connection? >> >> -FrankS. > > Yes, that is what I was suggesting earlier :) > > David > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Cljs-repl server as ring middleware?
You're cheating !!! You just added the "(should use CrossPageChannel)" to the subject header ;-) Not sure if I can help here as I just learnt about the existence of a "CrossPageChannel" a day or so ago… … I do agree with the JIRA-priority that this is a "Major" issue, as the help/reflection facilities when you use lein-cljsbuild are… non-existing, which raises the barrier to entry for new clojurescript coders and having a repl without any online doc&friends doesn't feel very lispy. -FS. On Oct 8, 2012, at 1:15 PM, David Nolen wrote: > On Mon, Oct 8, 2012 at 4:13 PM, Frank Siebenlist > wrote: >> Ok - thanks - slowly start to see the path ;-) >> >> I cannot find an explicit JIRA entry for that "reflection interface over >> CrossPageChannel" - should I add one for this, or did I miss the issue#? >> >> -FS. > > http://dev.clojure.org/jira/browse/CLJS-344. Patch most welcome for this :) > > David > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: polyfn
Interesting project, although I'm still a little unclear about the "convincing" use cases where you would choose polyfn over protocols... Also, how does the polyfn implementation compare to the clojurescript protocol implementation? -FrankS. On Oct 8, 2012, at 7:17 PM, Paul Stadig wrote: > On Monday, October 8, 2012 1:55:50 PM UTC-4, Tassilo Horn wrote: > Paul Stadig writes: > > Hi Paul, > > > I created a library for Clojure to do open, single dispatch > > polymorphism. What does this mean? > > > > * A polyfn dispatches on the type of its first argument. > > * You can add an implementation for a new type to an existing polyfn. > > * You can define a new polyfn on an existing type. > > > > Polyfns are exactly as fast as protocol functions (I am using the same > > caching and dispatch code), but they do not generate a Java interface, > > and they are slightly simpler to define. > > Sounds cool. > > I have a bunch of mostly one-method-protocols that I extend upon > existing (95% java) types. I don't rely on the existence of the > protocol interfaces, and neither do I use extends?, satisfies?, or > extenders. > > Would it make sense to switch to polyfns? Are there more advantages > except from the definitions being slightly more concise? > > I can't say that you should necessarily switch to polyfns, but this was the > kind of situation I was imagining. polyfns are the fast and open type based > dispatch decomplected from protocols, and I think that's the main advantage, > simplicity. > > A drawback with polyfns is there's no Java interface that can be extended in > Java code to participate in the dispatch. The Java interface is nice, but as > you mention below, the generation of interfaces can cause staleness issues > especially when paired with defrecord. defprotocol and defrecord both > generate a new class each time you compile them, because of the way classes, > class loaders, and class identity work. > > Another difference between protocols and polyfns is that everytime you > compile a defprotocol form it regenerates the protocol functions, whereas a > polyfn is generated once and never changes (only the dispatch table changes). > This has implications though I'm not sure how much they matter. YMMV > > One minor problem I have with the protocol approach is that if you > recompile a protocol during interactive development, then calling the > protocol methods on already existing instances in your repl session of > types on which the protocol has been extended won't work anymore. Do > polyfns help there? > > defrecord will behave differently depending on how you extend the protocol. > If you extend the protocol inline in the defrecord form, then the class that > defrecord generates will implement the protocol interface. In this case > nothing gets added to the protocol dispatch table, and instead dispatch > happens through the Java interface. When you recompile the defprotocol form, > it regenerates the Java interface and the protocol functions. The new > functions it generates know only about the new interface, so they complain > when you give it an instance of your defrecord that you had stashed away > before you recompiled. > > If you define a defrecord and extend a protocol to it using extend-protocol > or extend-type it adds an entry to the dispatch table for the protocol. Since > dispatch happens through the dispatch table instead of the interface, then > when you recompile your defprotocol and defrecord your old instances continue > to work, but because of the way class identity works they continue to > dispatch to the implementation of the protocol that was defined when you > created your instance. In order to invoke the new implementation of the > protocol, you need to create a new instance of your defrecord. Every time you > recompile your defrecord it adds a new entry to the protocol's dispatch > table, so the table will contain a number of entries on the order of the > number of times you have recompiled your defrecord. > > Since polyfns do not generate a Java interface through which they dispatch, > they will behave like this second case. Your old instances will continue to > work, but with the polyfn implementation that was associated with the > instance's class, and your dispatch table size will be on the order of the > number of times you have recompiled the polyfn forms. > > I'm not sure if this is better or worse than what happens in the first case, > but I do know that in 100% of the cases where I've used protocols I have not > really needed the Java interface. Though it also doesn't really hurt anything > to have the interface around if you're not using it. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > f
Re: ANN: Clojure 1.3 and 1.4 Cheat Sheet v7
Hi Andy,
Really believe you should replace the current
http://clojure.org/cheatsheet
with
http://jafingerhut.github.com/cheatsheet-clj-1.3/cheatsheet-tiptip-no-cdocs-summary.html
as the tooltips will help people to navigate the clojure ecosystem, and that's
the version everyone, especially newcomers, will hit first… and it's maybe the
only version that many will ever see because your enhanced versions are not
easily found… so why deprive new clojurians of your wonderful tooltips ?
-FrankS.
On Oct 14, 2012, at 7:17 PM, Andy Fingerhut wrote:
> My recent updates prompted me to go through my to do list of enhancement
> ideas for the Clojure cheat sheet, and I did some of them.
>
> It is now up in the usual places:
>
> http://clojure.org/cheatsheet
>
> Several other versions, including ones with tooltips containing doc strings:
>
> http://jafingerhut.github.com
>
>
> Things changed since the previous version:
>
> Added example literals for long ints in hex, octal, binary, and base 36.
> Also scientific notation for doubles.
>
> Changed category of with-decimal from BigInt to BigDecimal
>
> Added most clojure.walk functions to Collections/Generic ops section.
>
> Added more clojure.java.io functions to IO/Misc section.
>
> Created new section Macros/Debug for all macroexpand functions (formerly in
> Macros/Create).
>
> Added clojure.java.browse/browse-url and clojure.java.shell/{sh, with-sh-dir,
> with-sh-env} to new section Other/Browser/Shell.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
