gt; Happy new year, folks.
>>
>> (Might not be the best place to post this, but I failed to find a better
>> one, please advise if there is. I've also tried to look for previous
>> comments about this. If there are, then my Google-fu was simply too weak.)
>
>>
>> (Might not be the best place to post this, but I failed to find a better
>> one, please advise if there is. I've also tried to look for previous
>> comments about this. If there are, then my Google-fu was simply too weak.)
>>
>> https://clojuredocs.o
is, but I failed to find a better
> one, please advise if there is. I've also tried to look for previous
> comments about this. If there are, then my Google-fu was simply too weak.)
>
> https://clojuredocs.org/clojure.string/split says:
> --
> Usage:
> (split s re)
> (sp
Happy new year, folks.
(Might not be the best place to post this, but I failed to find a better
one, please advise if there is. I've also tried to look for previous
comments about this. If there are, then my Google-fu was simply too weak.)
https://clojuredocs.org/clojure.string/split
gt; A nil is not a string and should be distinguishable from an empty string
> in many cases.
>
> We disagree on the degree of punning here ☺ I’m not asking for the change.
> I understand why it is the way it is (I just don’t like it ☺).
>
> > blank? follows the rules
decade of ANSI Standards Committee work does to
someone!)
> A nil is not a string and should be distinguishable from an empty string in
> many cases.
We disagree on the degree of punning here ☺ I’m not asking for the change. I
understand why it is the way it is (I just don’t like it ☺).
puts.
>
I'm not a fan of the word "garbage" in this case or "garbage in / garbage
out". I think that implies a value judgement about both input and output
that is incorrect here.
"specified"/"unspecified" is much better. The clojure.string functions
” input (not sets). This is the
classic computer science “undefined” behavior that we see in many other
languages, where the behavior is only defined for the specific types of inputs.
I would _love_ all the clojure.string functions to be defined for nil as an
input – since we have (str nil
There are some comments at the top of clojure.string
(http://clojure.github.io/clojure/#clojure.string) about expected usage. In
particular, you should expect all clojure.string functions to accept
CharSequence (a parent interface of String, StringBuffer, and StringBuilder
and return the same
Greetings,
I was looking at clojure.string functions, and noticed that some have
unexpected (especially for less experienced programmers) behavior on
non-string arguments. For instance, 'capitalize' applies toString to its
argument, effectively making it possible to pass any type
e:
>
> Or even more simply, since the thing you want to replace is a single
> character, you do not need a regex to match it, but can match a string that
> is not a regex at all, e.g.:
>
> (st/replace "**username" "*" "$")
>
> The doc string
Or even more simply, since the thing you want to replace is a single
character, you do not need a regex to match it, but can match a string that
is not a regex at all, e.g.:
(st/replace "**username" "*" "$")
The doc string for clojure.string/replace is fairly ex
; => (f [:!!username "michael"])
>
> StringIndexOutOfBoundsException String index out of range: 1
> java.lang.String.charAt (String.java:695)
>
> or:
>
> => (def f (fn [%] (st/replace (name (first %)) #"\*" "$")))
>
> => (f [:**
I'm working on a website with a frontender who asked to be able to save
JSON maps that contain field names such as:
"$$hashKey" : "00C"
The dollar signs are a violation of MongoDB limits on field names, so i
need to convert to something else and then convert back. So I thought I
would convert
> On Thursday, September 12, 2013 7:47:02 PM UTC-7, Cedric Greevey wrote:
> On Thu, Sep 12, 2013 at 3:33 PM, Andy Fingerhut wrote:
> I have just added some discussion of this on ClojureDocs.org for the function
> clojure.core/subs, and references to that discussion for several other
&
gt;> wrote:
>>>>
>>>>> I have just added some discussion of this on ClojureDocs.org for the
>>>>> function clojure.core/subs, and references to that discussion for several
>>>>> other Clojure functions that I am pretty sure are affected, e
I have just added some discussion of this on ClojureDocs.org for the
>>>> function clojure.core/subs, and references to that discussion for several
>>>> other Clojure functions that I am pretty sure are affected, e.g. re-find,
>>>> re-seq, re-matches, clojure.str
gest in articles they write on the topic.
>>>>
>>>> Andy
>>>>
>>>>
>>>> On Tue, Sep 17, 2013 at 8:07 AM, Brian Craft wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thursday, September 12, 2013 7:47:02
aft wrote:
>>>
>>>>
>>>>
>>>> On Thursday, September 12, 2013 7:47:02 PM UTC-7, Cedric Greevey wrote:
>>>>
>>>>> On Thu, Sep 12, 2013 at 3:33 PM, Andy Fingerhut
>>>>> wrote:
>>>>>
>>>>&g
gt;>>> I have just added some discussion of this on ClojureDocs.org for the
>>>>> function clojure.core/subs, and references to that discussion for several
>>>>> other Clojure functions that I am pretty sure are affected, e.g. re-find,
>>>&g
to that discussion for several
>> other Clojure functions that I am pretty sure are affected, e.g. re-find,
>> re-seq, re-matches, clojure.string/split, replace, replace-first
>>
>
> We know with certainty that clojure.string/split is affected. Also, the
> OP's questi
y Fingerhut wrote:
>>
>>> I have just added some discussion of this on ClojureDocs.org for the
>>> function clojure.core/subs, and references to that discussion for several
>>> other Clojure functions that I am pretty sure are affected, e.g. re-find,
>>> re
12, 2013 at 3:33 PM, Andy Fingerhut
>>
>> > wrote:
>>
>>> I have just added some discussion of this on ClojureDocs.org for the
>>> function clojure.core/subs, and references to that discussion for several
>>> other Clojure functions that I am pr
ences to that discussion for several
>> other Clojure functions that I am pretty sure are affected, e.g. re-find,
>> re-seq, re-matches, clojure.string/split, replace, replace-first
>>
>
> We know with certainty that clojure.string/split is affected. Also, the
> OP's
>
> On Thu, Sep 12, 2013 at 9:08 AM, Brian Craft
> > wrote:
>
>> After working around the seq + closure = death problem, I still had a
>> severe memory leak in my code, which took many hours to find.
>>
>> Holding a reference to a string returned by clojure.stri
; re-seq, re-matches, clojure.string/split, replace, replace-first
>
We know with certainty that clojure.string/split is affected. Also, the
OP's question about how to use tooling to track down similar leaks in the
future does not appear to have been satisfactorily answered as of yet.
--
-
I have just added some discussion of this on ClojureDocs.org for the
function clojure.core/subs, and references to that discussion for several
other Clojure functions that I am pretty sure are affected, e.g. re-find,
re-seq, re-matches, clojure.string/split, replace, replace-first
http
that interests
you.
Andy
On Thu, Sep 12, 2013 at 9:08 AM, Brian Craft wrote:
> After working around the seq + closure = death problem, I still had a
> severe memory leak in my code, which took many hours to find.
>
> Holding a reference to a string returned by clojure.string/spl
After working around the seq + closure = death problem, I still had a
severe memory leak in my code, which took many hours to find.
Holding a reference to a string returned by clojure.string/split is somehow
retaining a reference to the original string. In my case I needed to hold
the first
Hi Andy,
On Mon, Aug 12, 2013 at 12:17 AM, Andy Fingerhut
wrote:
> Clojure's clojure.string/trim uses Java's String/trim, but
> clojure.string/triml and trimr use Java's Character/isWhitespace to
> determine which characters are white space to remove. CLJ-935 has a
&
Clojure's clojure.string/trim uses Java's String/trim, but
clojure.string/triml and trimr use Java's Character/isWhitespace to
determine which characters are white space to remove. CLJ-935 has a
suggested patch to make them all use Character/isWhitespace:
http://dev.clojure.
Sorry, I should have been more clear. In the following the space at
the end of the string is a no break space and the first execution is
under clojurescript, the second under clojure.
user> (clojure.string/trim "54 ")
"54"
bible-plan.mcheyne> :cljs/qui
22:55, "Tim Visher" > a
> écrit :
>
>> Should ` ` be trimmed using `clojure.string/trim`? EOM
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this g
is closer an expression than a single character. A regexp replace
should be more suitable.
Le 11 août 2013 22:55, "Tim Visher" a écrit :
> Should ` ` be trimmed using `clojure.string/trim`? EOM
>
> --
> --
> You received this message because you are subscribed to the
On Monday, 12 August 2013 02:24:30 UTC+5:30, Tim Visher wrote:
>
> Should ` ` be trimmed using `clojure.string/trim`? EOM
>
` ` is the representation of an HTML entity, which is technically not
whitespace. I guess `trim` should not remove it.
Shantanu
--
--
You received thi
Should ` ` be trimmed using `clojure.string/trim`? EOM
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient
> I agree that with regards to 'least astonishment' the core fn should
> capitalize all characters. This is what I'd expect from a fn called
> 'capitalize'.
>
There is already an upper-case function, thus capitalize should either
capitalize the first character or all characters who begin a se
On Wed, 12 Dec 2012 09:44:28 -0600
Grant Rettke wrote:
> Fro that principle, who is the least astonished who is it based on?
I jsut wanted to say, people coming e.g. from Python. But then I
realized it does the same thing and afterwards I was enlightened that
it doesn't matter since I never use
above to
"capitalize" which only capitalises the 1st charater...
I agree that with regards to 'least astonishment' the core fn should
capitalize all characters. This is what I'd expect from a fn called
'capitalize'.
Jim
On 12/12/12 14:12, Pierre Allix
On Wed, Dec 12, 2012 at 8:12 AM, Pierre Allix
wrote:
> I think it does not follow principle of least astonishment. I would have
> expected to convert only the first character. Moreover converting the other
> characters make the function almost useless, I for instance had this string
> to capita
> The clojure.string/capitalize function is defined as follow:
>
> Converts first character of the string to upper-case, all other
>
> characters to lower-case.
>
>
> I think it does not follow principle of least astonishment. I would have
> expected to convert only the first charact
Hello,
The clojure.string/capitalize function is defined as follow:
Converts first character of the string to upper-case, all other
characters to lower-case.
I think it does not follow principle of least astonishment. I would have
expected to convert only the first character. Moreover
Known bug, fix forthcoming.
http://dev.clojure.org/jira/browse/CLJ-753
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient wit
Clojure> (require '(clojure [string :as string]))
nil
Clojure> (string/replace-first "a" #"b" "c")
"a"
Clojure> (string/replace-first "a" #"b" (comp str last))
nil
when pass a pattern and a function to the replace-first function, and
the pattern doesn't match the string (first argument), replace-f
Thanks, I think I was trying to wrong thing (don't know why I was trying to
use import rather than require).
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new member
Here's an example from the REPL that should get you going:
user => (require '[clojure.string :as str])
nil
user=> (str/split-lines "foo\nbar\r\nbaz\n")
["foo" "bar" "baz"]
Cheers,
Aaron Bedra
--
Clojure/core
http://clojure.com
On 10/18
If you do a
(require 'clojure.string)
then all vars will be accessible as clojure.string/...
e.g.clojure.string/split-lines
.
You can use "use" to import the vars into the current namespane:
(use 'clojure.string)
This wil make available all vars from clojure.s
Hi all,
I've started to teach myself clojure recently, so apologies for a
potentially stupid question.
I'm using clojure-1.3.0.jar, downloaded very recently. I would like to
use clojure.string/split-lines, but I cannot access the namespace.
I've tried:
(import 'clojure.str
Hi,
Please bump up my JIRA membership level to make edits and I will fix
this bug.
I have an account named Takahiro Hozumi on dev.clojure.org already.
CA is also already sent.
Thanks.
On 3月11日, 午後10:55, Stuart Sierra wrote:
> > (require '[clojure.string :as str])
> > (str/repla
>
> (require '[clojure.string :as str])
> (str/replace-first "abc def" #"ghi" (fn [a] (str a a)))
> => nil
>
That's a bug. Created http://dev.clojure.org/jira/browse/CLJ-753
<http://dev.clojure.org/jira/browse/CLJ-753>Thanks for the
e-groups m))]
(.appendReplacement m buffer rep)
(.appendTail m buffer)
(str buffer))
On Mar 10, 4:39 pm, Takahiro Hozumi wrote:
> Hi,
> I have two questions about clojure.string/replace-first.
>
> 1.
> Is this expected behavior of re
Hi,
I have two questions about clojure.string/replace-first.
1.
Is this expected behavior of replace-first?
(require '[clojure.string :as str])
(str/replace-first "abc def" #"ghi" (fn [a] (str a a)))
=> nil
I don't think so, because string / string argument ver
On 09/24/2010 01:45 PM, Rasmus Svensson wrote:
> 2010/9/24 cej38 :
>> I noticed that clojure.string is not showing up on the API webpage,
>> http://clojure.github.com/clojure/, is that an oversight?
>>
>
> All the clojure.java.* namespaces and clojure.test are gone too
2010/9/24 cej38 :
> I noticed that clojure.string is not showing up on the API webpage,
> http://clojure.github.com/clojure/, is that an oversight?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to th
I noticed that clojure.string is not showing up on the API webpage,
http://clojure.github.com/clojure/, is that an oversight?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
well.
>>> They are now at:
>>>
>>> http://clojure.github.com/clojure/
>>>
>>> and
>>>
>>> http://clojure.github.com/clojure-contrib/
>>>
>>> I have not got them completely up-to-date with the 1.2 beta split,
p://clojure.github.com/clojure-contrib/
>>
>> I have not got them completely up-to-date with the 1.2 beta split, so
>> for the moment just look at the master branch. I expect to have that
>> fixed in the next few days.
>>
>> You are correct, clojure.string is no
hem completely up-to-date with the 1.2 beta split, so
> for the moment just look at the master branch. I expect to have that
> fixed in the next few days.
>
> You are correct, clojure.string is not there. I'll get that added
> today. Thanks for catching it!
>
> Tom
>
--
clojure.string is now in for the master branch doc at
http://clojure.github.com/clojure/
Separate 1.2 doc coming RSN.
Tom
On Jul 18, 11:10 am, Tom Faulhaber wrote:
> The official doc for clojure and clojure-contrib have moved as well.
> They are now at:
>
> http://clojure.github
to have that
fixed in the next few days.
You are correct, clojure.string is not there. I'll get that added
today. Thanks for catching it!
Tom
On Jul 17, 10:13 pm, Adrian Cuthbertson
wrote:
> Yes, sorry, my post referred to the source, not the online doc API.
> Perhaps someone else
unable to find an
> online API there. http://richhickey.github.com/clojure/ is the only
> online API I have seen. And again, the other new 1.2 namespaces like
> clojure.java.io show up just fine there, which is why I'm confounded
> why clojure.string is not there.
>
&g
show up just fine there, which is why I'm confounded
why clojure.string is not there.
On Jul 17, 8:57 am, Adrian Cuthbertson
wrote:
> Hi Benny,
>
> The 1.2 release source site has moved tohttp://github.com/clojure/
>
> -Regards, Adrian
>
>
>
> On Sat, Jul 17, 2010
w namespaces. I was
> able to find most of them (clojure.java.io, etc.) on the API site
> (http://richhickey.github.com/clojure/). However, I could not find
> the clojure.string namespace. Did I miss something? Any help would
> be greatly appreciated.
>
> -Benny
>
&g
clojure.string namespace. Did I miss something? Any help would
be greatly appreciated.
-Benny
P.S. My apologies for the repeat question (I asked this question in
the 1.2 beta release announcement thread as well), but I am leaning
quite a bit on the API site as I continue to learn the functions built
Whoops should have said:
upper-case-ay
ower-case-lay
eft-trim-lay
ight-trim-ray
Or something like that.
Steve
On Thu, Jun 3, 2010 at 9:16 AM, Steve Molitor wrote:
> How about:
>
> pper-case-uay
> ower-case-ay
> eft-trim-lay
> ight-trim-lay
>
>and so on...
>
> Steve
>
>
> On
How about:
pper-case-uay
ower-case-ay
eft-trim-lay
ight-trim-lay
and so on...
Steve
On Wed, Jun 2, 2010 at 10:49 AM, Tom Hickey wrote:
> Including a space is correct when changing a string "to upper
> case" (hence Java's toUpperCase), though no space would be fine there
> as well.
On Thu, Jun 3, 2010 at 11:03, Laurent PETIT wrote:
> 2010/6/3 B Smith-Mannschott
>>
>> On Thu, Jun 3, 2010 at 09:31, Laurent PETIT
>> wrote:
>> > Hello,
>> >
>> > 2 quick remarks concerning the patch:
>> >
>> > * type hints are written like #^String and not ^String
>>
>> not anymore:
>>
>>
>>
2010/6/3 B Smith-Mannschott
> On Thu, Jun 3, 2010 at 09:31, Laurent PETIT
> wrote:
> > Hello,
> >
> > 2 quick remarks concerning the patch:
> >
> > * type hints are written like #^String and not ^String
>
> not anymore:
>
>
> http://github.com/richhickey/clojure/commit/787938361128c2bc21ed896d
On Thu, Jun 3, 2010 at 09:31, Laurent PETIT wrote:
> Hello,
>
> 2 quick remarks concerning the patch:
>
> * type hints are written like #^String and not ^String
not anymore:
http://github.com/richhickey/clojure/commit/787938361128c2bc21ed896dd4523651b59cb420
http://github.com/richhickey/cloju
On Jun 3, 2010, at 2:31 AM, Laurent PETIT wrote:
> * why ltrim / rtrim , but upper-case / lower-case ? Why not ltrim / rtrim +
> ucase / lcase , or left-trim right-trim + upper-case / lower-case ? Will
> left-trim/right-trim be so often used that they must be shortened to
> ltrim/rtrim (espec
Hello,
2 quick remarks concerning the patch:
* type hints are written like #^String and not ^String
* why ltrim / rtrim , but upper-case / lower-case ? Why not ltrim / rtrim
+ ucase / lcase , or left-trim right-trim + upper-case / lower-case ? Will
left-trim/right-trim be so often used that t
+1 on uppercase / lowercase
On Jun 2, 8:49 am, Tom Hickey wrote:
> Including a space is correct when changing a string "to upper
> case" (hence Java's toUpperCase), though no space would be fine there
> as well.
>
> As a verb, "uppercase" (no space) is correct. So the function should
> either mat
Including a space is correct when changing a string "to upper
case" (hence Java's toUpperCase), though no space would be fine there
as well.
As a verb, "uppercase" (no space) is correct. So the function should
either match java and be called to-upper-case or (preferably, IMO)
simply be uppercase.
But they can be separate words, and Java treats them so (.toUpperCase,
.toLowerCase).
Stu
> Also, according to Merriam-Webster, uppercase and lowercase don't have
> hyphens in them.
>
> RJ
>
> On May 30, 3:49 pm, Stuart Halloway wrote:
>> I have been working on a branch [1] and haven't updat
Steven, thanks for the detailed feedback! Responses inline:
> Why do some of the functions use StringBuilder (no internal
> synchronization) and some use StringBuffer (provides internal
> synchronization). Using the latter is probably a mistake.
Stuck with this thanks to the Java API: .appendRepl
r as calling .toString() is likely to be useful (which is
> precisely what StringBuilder's constructor does anyway). Further, any
> purported performance benefit from getting the mutable object back is
> lost if/when it is passed to another clojure.string function since the
> v
Also, according to Merriam-Webster, uppercase and lowercase don't have
hyphens in them.
RJ
On May 30, 3:49 pm, Stuart Halloway wrote:
> I have been working on a branch [1] and haven't updated the ticket yet [2].
> Given the number of diverse (and sometimes opposite!) opinions already
> express
ssed to another clojure.string function since the
very first usage of a CharSequence is always to call .toString() on
it.
I'd go the other way and document functions as returning a String, and
type-hinting them as such. This also has practical effects:
user=> (defn ^CharSequence rev
Why do some of the functions use StringBuilder (no internal
synchronization) and some use StringBuffer (provides internal
synchronization). Using the latter is probably a mistake.
The first function -- reverse -- uses StringBuilder#reverse() to reverse
the character sequence in place, and then cal
I have been working on a branch [1] and haven't updated the ticket yet [2].
Given the number of diverse (and sometimes opposite!) opinions already
expressed on this topic, I thought a little extra community review would be in
order. David and I organized the work into several fairly small commit
80 matches
Mail list logo
