appy 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.org/clojure.stri
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 says
t 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 of clojure.string you st
understand why it is the way it is (I just don’t like it ☺).
> blank? follows the rules of clojure.string you stated above (other than it's
> stated extension to also cover nil).
Good point. Yes, I’m persuaded.
Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
&q
s of inputs.
>
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
spec
” 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
%)) #\* $)))
= (f [:**username michael])
StringIndexOutOfBoundsException String index out of range: 1
java.lang.String.charAt (String.java:695)
What am I doing wrong?
If you use a regex as the second parameter of clojure.string/replace, then
a $ character followed by a number in the third argument
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 explicit on this.
Andy
On Mon, Aug 4
:
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 explicit on this.
Andy
On Mon
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 to
:
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
We know
...@gmail.comwrote:
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
We
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 question about how to use tooling to track down similar
, 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.
cricket, cricket, cricket
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 question about how to use tooling to track down similar leaks in
the future does not appear
-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.
cricket
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 question about how to use tooling to track down similar leaks
, 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 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
, 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
We know with certainty that clojure.string/split is affected. Also, the
OP's question about how to use tooling to track
...@gmail.comjavascript:
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-seq, re-matches, clojure.string/split, replace, replace
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
you.
Andy
On Thu, Sep 12, 2013 at 9:08 AM, Brian Craft craft.br...@gmail.com 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/split
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
,
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.
--
--
You
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 column of each row in a tsv file that was 4G
Hi Andy,
On Mon, Aug 12, 2013 at 12:17 AM, Andy Fingerhut
andy.finger...@gmail.com 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
Should `nbsp;` 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 with your
On Monday, 12 August 2013 02:24:30 UTC+5:30, Tim Visher wrote:
Should `nbsp;` be trimmed using `clojure.string/trim`? EOM
`nbsp;` is the representation of an HTML entity, which is technically not
whitespace. I guess `trim` should not remove it.
Shantanu
--
--
You received this message
nbsp; is closer an expression than a single character. A regexp replace
should be more suitable.
Le 11 août 2013 22:55, Tim Visher tim.vis...@gmail.com a écrit :
Should `nbsp;` be trimmed using `clojure.string/trim`? EOM
--
--
You received this message because you are subscribed
Visher tim.v...@gmail.com javascript: a
écrit :
Should `nbsp;` 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 clo...@googlegroups.comjavascript:
Note that posts
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/quit
:cljs/quit
bible
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.org/jira/browse
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
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
:
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
On Wed, Dec 12, 2012 at 8:12 AM, Pierre Allix
pierre.allix.w...@gmail.comwrote:
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
the 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 wrote:
Hello,
The clojure.string
On Wed, 12 Dec 2012 09:44:28 -0600
Grant Rettke gret...@acm.org 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
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-first
will
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 with
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.string)
(import 'string
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.string in you current
namespace
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/2011 05:52 AM, Omer Kudat wrote:
Hi all,
I've started to teach
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 members
(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-753Thanks for the report.
-Stuart Sierra
clojure.com
--
You received this message
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 version returns
original string when
))]
(.appendReplacement m buffer rep)
(.appendTail m buffer)
(str buffer))
On Mar 10, 4:39 pm, Takahiro Hozumi fat...@googlemail.com wrote:
Hi,
I have two questions about clojure.string/replace-first.
1.
Is this expected behavior of replace-first?
(require
On 09/24/2010 01:45 PM, Rasmus Svensson wrote:
2010/9/24 cej38 junkerme...@gmail.com:
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... I
don't
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
Note that posts
2010/9/24 cej38 junkerme...@gmail.com:
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
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
--
You received this message because you
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 not there. I'll get that added
today. Thanks for catching it!
Tom
--
You received this message
-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
--
You received this message because you are subscribed
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 adrian.cuthbert...@gmail.com
wrote:
Yes, sorry, my post referred to the source, not the online doc API.
Perhaps
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 tomfaulha...@gmail.com wrote:
The official doc for clojure and clojure-contrib have moved as well.
They are now at:
http
the 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
of new 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
P.S. My apologies for the repeat
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 adrian.cuthbert...@gmail.com
wrote:
Hi Benny,
The 1.2 release source site has moved tohttp://github.com/clojure/
-Regards, Adrian
On Sat, Jul 17, 2010 at 8:00 AM, Btsai
. However, I was 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.
On Jul 17, 8:57 am
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
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
On Thu, Jun 3, 2010 at 09:31, Laurent PETIT laurent.pe...@gmail.com 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
On Thu, Jun 3, 2010 at 11:03, Laurent PETIT laurent.pe...@gmail.com wrote:
2010/6/3 B Smith-Mannschott bsmith.o...@gmail.com
On Thu, Jun 3, 2010 at 09:31, Laurent PETIT laurent.pe...@gmail.com
wrote:
Hello,
2 quick remarks concerning the patch:
* type hints are written like
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 thic...@gmail.com wrote:
Including a space is correct when changing a string to upper
case (hence Java's toUpperCase), though no space would be fine
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 stevemoli...@gmail.comwrote:
How about:
pper-case-uay
ower-case-ay
eft-trim-lay
ight-trim-lay
and so on...
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.
+1 on uppercase / lowercase
On Jun 2, 8:49 am, Tom Hickey thic...@gmail.com 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
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
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
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 reverse
[^CharSequence s
Also, according to Merriam-Webster, uppercase and lowercase don't have
hyphens in them.
RJ
On May 30, 3:49 pm, Stuart Halloway stuart.hallo...@gmail.com 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!)
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
very first usage of a CharSequence is always to call .toString
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:
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 stuart.hallo...@gmail.com wrote:
I have been working on a branch [1]
78 matches
Mail list logo
