2017-09-06 15:18 GMT+02:00 Cecil Westerhof :
> 2017-09-06 14:15 GMT+02:00 Gary Trakhman :
>
>> The second to last apply argument doesn't spread args like the last slot.
>>
>
> OK, I changed it to:
> (def digits
> (apply str (map char (inclusive-range (int \0) (int \9)
> (def hex-digits
>
2017-09-06 14:15 GMT+02:00 Gary Trakhman :
> The second to last apply argument doesn't spread args like the last slot.
>
OK, I changed it to:
(def digits
(apply str (map char (inclusive-range (int \0) (int \9)
(def hex-digits
(str digits
(apply str (map char (inclusive-ra
The second to last apply argument doesn't spread args like the last slot.
- terseness from phone
On Sep 6, 2017 8:11 AM, "Cecil Westerhof" wrote:
I have:
(def digits
(apply str
(map char (inclusive-range (int \0) (int \9)
and this gives:
"0123456789"
I also have:
(def
I have:
(def digits
(apply str
(map char (inclusive-range (int \0) (int \9)
and this gives:
"0123456789"
I also have:
(def hex-digits
(apply str
digits
(map char (inclusive-range (int \A) (int \F)
and this gives:
"0123456789ABCDEF"
So
> I thought there would be be many benefits to using records, particularly
> around protocols but I haven't felt the loss.
I like having the constructor ready made, and the extra documentation they
provide on which key it has. Though spec remediates the latter a bit.
Other then that, they're fa
Maps and name spaced keys would be my recommendation for domain entities.
Namespace keys because they help in isolating usages.
I thought there would be be many benefits to using records, particularly
around protocols but I haven't felt the loss.
On Saturday, 29 July 2017, Didier wrote:
> I fee
I feel your pain, but you kinda shot yourself in the foot from the get go.
What you did is the same as if you had decided to use a Java List
to store your Account info.
I'd suggest you read over this:
https://clojure.org/reference/datatypes#_why_have_both_deftype_and_defrecord
It explains the
The attention-span constraint gives this challenge the aspect of a
migration. Consider it that way and solutions emerge. In particular -
attend to the interfaces between functions, and do whatever you like inside
the functions. You could adjust the program incrementally, whenever
convenient.
om>
Sent: Wednesday, July 26, 2017 10:24 PM
To: Clojure<mailto:clojure@googlegroups.com>
Subject: Re: Unnamed Types - What Am I Doing Wrong?
I feel your pain. I don't have an answer, but the basic point convinced me to
write this:
http://gatannahfiles.blogspot.com/2017/07/moving-awa
I feel your pain. I don't have an answer, but the basic point convinced me
to write this:
http://gatannahfiles.blogspot.com/2017/07/moving-away-from-guard-rails.html
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email
On Wednesday, 26 July 2017 03:03:45 UTC+1, Daniel Compton wrote:
> For something like an account, a more idiomatic way to model this in
> Clojure might be with maps:
>
> If I understand Kevin's post correctly, he's already planning to replace
his vectors with maps, and he is asking if there's a
Hi Kevin
For something like an account, a more idiomatic way to model this in
Clojure might be with maps:
{:account-name "John Smith"
:account-number "125-1290"}
or
{:account/name "John Smith"
:account/number "125-1290"}
If you then want to refactor your usage/naming of map keys then you can
Maps with named keys work much better than vectors/lists for heterogenuous
data. I've recently taken up OCaml as a very well-typed language, and it's
basically analogous to records vs tuples tradeoffs there.
Clojure.spec can help at a larger scale.
You can do the same encapsulation as Java by wr
I ran into the 'refactoring an unnamed type' problem. I'd like to know how
experienced Clojurists avoid it.
I've got an account record/structure. It has things like an account name,
account number, etc. I started off storing it in a vector, because it had
just two elements. Account name was
Thank you very much to all!
Now I completely understand the metadata behavior with the reader. I'll try
to adopt eastwood, thanks for the suggestion.
Is clearly that the documentation confuses a little bit.
Cheers!
Andrey
2015-05-05 23:25 GMT+02:00 James Reeves :
> The documentation is rather
In reference to [1]:
I do feel like the metadata loss on many macros is undesirable though and I
wish it were addressed. It certainly feels "unhygienic", just in a new sense
of the term.
[1] https://github.com/jonase/eastwood#unused-meta-on-macro
--
You received this message because you are
+1 to Eastwood. It is great.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from t
The Eastwood [1] Clojure lint tool has a few warnings in it that warn about
unused metadata in your code.
The :unused-meta-on-macro warns about metadata on macro invocations, which
is usually ignored by Clojure [2].
The :wrong-tag warns about unused type tag metadata on Vars, and
non-fully-qualif
What you wanted here was
(meta '^:abc some-symbol)
It's a little weird but the reader attaches the metadata to the symbol. Then
the quote just evaluates directly to the same symbol, so the metadata is
preserved.
I agree that metadata can be confusing though. Especially around where AND HOW
>From your comments, I suspect this may be a source of confusion as well:
When you have something like (defn ^{:doc "Increments"} a-fn [x] (+ x 1))
the metadata is attached to the symbol at read time. However, during the
compilation process, the metadata on the symbol is transferred to the Var
Because ' is a reader macro which expands to the list (quote some-symbol),
so the metadata is applied to the list, and not the symbol. You can verify
this in the REPL - (meta (quote ^:abc 'some-symbol))
On Tuesday, May 5, 2015 at 5:43:19 PM UTC-4, Andy- wrote:
>
> Frankly, I would've (meta ^:abc
I expect because 'some-symbol is shorthand for (quote some-symbol), so
you're attaching the metadata to a list that disappears once it's evaluated.
- James
On 5 May 2015 at 22:43, Andy- wrote:
> Frankly, I would've (meta ^:abc 'some-symbol) expected to work. Maybe
> somebody else can weigh in o
Frankly, I would've (meta ^:abc 'some-symbol) expected to work. Maybe
somebody else can weigh in on why this one is a no-go.
On Tuesday, May 5, 2015 at 5:01:19 PM UTC-4, Andrey Antukh wrote:
>
> Thanks to both for the responses, but I stil not clearly understand.
>
> The documentation says very c
The documentation is rather misleading, as it implies that "obj" can be a
symbol. However, because ^ is a reader macro, it is applied to "obj" before
it is evaluated.
Clojure maps, vectors and sets all evaluate to themselves, so attaching
metadata to the unevaluated expression via the ^ reader mac
Thanks to both for the responses, but I stil not clearly understand.
The documentation says very clearly that:
In addition to with-meta, there are a number of reader macros (The Reader:
Macro Characters) for applying metadata to the expression following it:
^{:doc "How obj works!"} obj - Sets the
In addition to James comment: IMO clojure.org/metadata should be clearer
about this. It's mentioned more clearly on the reader page:
http://clojure.org/reader#The%20Reader--Macro%20characters
"The metadata reader macro first reads the metadata and attaches it to the
next form read (see with-meta
When dealing with metadata, it's important to understand the difference
between these two expressions:
^{:foo :bar} baz
(with-meta baz {:foo :bar})
The first expression attaches metadata to the 'baz' symbol at compile time.
The second expression attaches metadata to the data held in 'baz
Hi!
I have some trouble with clojure metadata / reader and I do not know if I'm
doing something wrong.
I have this code:
(defn some-func [])
(def func ^:abc some-func)
(assert (= (meta func) {:abc true}))
(def data [[:bar (with-meta some-func {:abc true})]
[:baz ^:abc some-func]])
Ah yes, I see that
here:
https://github.com/clojure/clojure/blob/clojure-1.6.0/src/clj/clojure/main.clj#L64-L86
Thanks for the quick response!
On Saturday, August 16, 2014 1:36:11 PM UTC+1, Nicola Mometto wrote:
>
>
> Because in the repl you're using a thread-local value of *data-readers*,
> n
Because in the repl you're using a thread-local value of *data-readers*,
not the var root, this is because the repl is executed under (binding
[*data-readers ..] ..)
If you try to set! *data-readers* instead, you'll see what you expect.
Consider:
user=> (def ^:dynamic x nil)
#'user/x
user=> x
ni
Can someone explain why this is not altering the *data-readers* dynamic
var? Does this work for anyone else? Using 1.6.0
(assert (= {} *data-readers*))
;; nil
(alter-var-root (var *data-readers*) (fn [_] {:test 2}))
;; {:test 2}
(assert (= {:test 2} *data-readers*))
;; AssertionError
(assert (
If ordering isn't important, I'd just dump them all into a set instead of
manually checking whether or or not you already put the url into a set.
On Sunday, January 26, 2014 10:46:46 PM UTC-8, danneu wrote:
>
> I use line-seq, split, and destructuring to parse large CSVs.
>
> Here's how I'd app
I use line-seq, split, and destructuring to parse large CSVs.
Here's how I'd approach what I think you're trying to do:
(with-open [rdr (io/reader (io/resource csv :encoding "UTF-16"))]
(let [extract-url-hash (fn [line]
(let [[_ _ _ url & _] (str/split
Jim,
Thanks for the idioms, I appreciate it!
And thanks everyone for the help!
On Tuesday, January 21, 2014 8:43:40 AM UTC-5, Jim foo.bar wrote:
>
> On 21/01/14 13:11, Chris Perkins wrote:
> > This part: (some #{hashed} already-seen) is doing a linear lookup in
> > `already-seen`. Try (contain
Chris,
Thanks this was in fact it. I had read that sets had a near O[1] lookup,
but apparently I was not achieving this properly with (some). Thank you
the execution time is about 25x faster now!
Jarrod
On Tuesday, January 21, 2014 8:11:09 AM UTC-5, Chris Perkins wrote:
>
> On Monday, Januar
On Jan 21, 2014, at 07:11 , Chris Perkins wrote:
> This part: (some #{hashed} already-seen) is doing a linear lookup in
> `already-seen`. Try (contains? already-seen hashed) instead.
Or just (already-seen hashed), given that OP's not trying to store nil hashes.
To OP: note that if you’re stori
On 21/01/14 13:11, Chris Perkins wrote:
This part: (some #{hashed} already-seen) is doing a linear lookup in
`already-seen`. Try (contains? already-seen hashed) instead.
+1 to that as it will become faster...
I would also add the following not so related to performance:
(drop1 (line-seqf)) =
On Monday, January 20, 2014 11:55:00 PM UTC-7, Jarrod Swart wrote:
>
> I'm processing a large csv with Clojure, honestly not even that big (~18k
> rows, 11mb). I have a list of exported data from a client and I am
> de-duplicating URLs within the list. My final output is a series of
> vectors:
Hi Jarrod
I have had success with the clojure-csv [1] library and processing large files
in a lazy way (as opposed to using slurp).
[1] - clojure-csv - https://github.com/davidsantiago/clojure-csv
Here is a copy of my source code (disclaimer - this is my first Clojure program
- so some things
I'm processing a large csv with Clojure, honestly not even that big (~18k
rows, 11mb). I have a list of exported data from a client and I am
de-duplicating URLs within the list. My final output is a series of
vectors: [url url-hash].
The odd thing is how slow it seems to be going. I have tri
Hi,
Am 08.09.2009 um 15:31 schrieb Michael Aldred:
The NailGun client assumes that the strlen function will handle a null
pointer for the argument.
Under Solaris this is not the case (http://technopark02.blogspot.com/
2006/04/solaris-null-pointer-bugs-usrlib00so1.html)
Fixed with rev 6fc1bf04
Hi,
Am 08.09.2009 um 15:31 schrieb Michael Aldred:
The NailGun client assumes that the strlen function will handle a null
pointer for the argument.
Under Solaris this is not the case (http://technopark02.blogspot.com/
2006/04/solaris-null-pointer-bugs-usrlib00so1.html)
Thank you for the fix.
I've found the problem.
The NailGun client assumes that the strlen function will handle a null
pointer for the argument.
Under Solaris this is not the case (http://technopark02.blogspot.com/
2006/04/solaris-null-pointer-bugs-usrlib00so1.html)
The problem is in sendText.
With Nailgun 0.7.1, this
G'day,
I'm having a bit of trouble getting VimClojure working under
OpenSolaris 2009.06 (I'm currently using the development IPS
repository, however I still got the problem with the release
repository).
I'm compiled and installed vimclojure.jar, and ng.
Vim correctly detects and highlights .clj
44 matches
Mail list logo
