string(bytestring(...)) seems to do it. would appreciate any more
efficient solutions (and confirmation the analysis is correct - is this
worth filing as an issue?)
On Tuesday, 21 July 2015 19:33:05 UTC-3, andrew cooke wrote:
>
>
> well, this was fun... the following code rapidly triggers the
does `copy` work? although `bytestring` also seems like a good method for
this also. it seems wrong to me also that `match` is making a copy of the
original string (if that is indeed what it is doing)
On Tue, Jul 21, 2015 at 6:57 PM andrew cooke wrote:
>
> string(bytestring(...)) seems to do it.
deepcopy didn't. i haven't actually tried copy. hang on... [computer
hangs; oom killer steps in]. nope!
On Tuesday, 21 July 2015 20:08:33 UTC-3, Jameson wrote:
>
> does `copy` work? although `bytestring` also seems like a good method for
> this also. it seems wrong to me also that `match` i
(i was quite impressed that reverse(reverse(...)) didn't help either).
On Tuesday, 21 July 2015 20:11:35 UTC-3, andrew cooke wrote:
>
>
> deepcopy didn't. i haven't actually tried copy. hang on... [computer
> hangs; oom killer steps in]. nope!
>
> On Tuesday, 21 July 2015 20:08:33 UTC-3, Jam
On Tue, Jul 21, 2015 at 7:08 PM, Jameson Nash wrote:
> does `copy` work? although `bytestring` also seems like a good method for
> this also. it seems wrong to me also that `match` is making a copy of the
> original string (if that is indeed what it is doing)
Isn't it `s[i:end]` that is doing the
i think that returns a substring (ir a view onto the backing string). but
i am not sure. i did read a discussion somewhere saying that because of
this you should use bytestring(...) before passing a string to c. which is
all the evidence i have for my guess.
incidentally, match(...) has a me
hmm. ignore that last statement (same problem). still checking /
confused. sorry.
On Tuesday, 21 July 2015 20:20:46 UTC-3, andrew cooke wrote:
>
>
> i think that returns a substring (ir a view onto the backing string). but
> i am not sure. i did read a discussion somewhere saying that beca
ok, so match(regex, string, index) solves the problem. presumably it
exists exactly for this reason?
andrew
On Tuesday, 21 July 2015 20:23:57 UTC-3, andrew cooke wrote:
>
>
> hmm. ignore that last statement (same problem). still checking /
> confused. sorry.
>
> On Tuesday, 21 July 201
On Tue, Jul 21, 2015 at 7:26 PM, andrew cooke wrote:
>
> ok, so match(regex, string, index) solves the problem. presumably it exists
> exactly for this reason?
At least I think this is a valid usecase.
>
> andrew
>
>
> On Tuesday, 21 July 2015 20:23:57 UTC-3, andrew cooke wrote:
>>
>>
>> hm
ah. for some reason i was thinking they were invisible (somewhere below
julia).
ok, thanks. so that explains things more clearly
...except that(!) using SubString(s, i, endof(s)) and passing *that* to
match still gives the memory issue.
so there's still something odd that i don't unders
I've been using ascii().
On Tuesday, July 21, 2015 at 7:38:28 PM UTC-4, andrew cooke wrote:
>
>
> ah. for some reason i was thinking they were invisible (somewhere below
> julia).
>
> ok, thanks. so that explains things more clearly
>
> ...except that(!) using SubString(s, i, endof(s)) and
On Tue, Jul 21, 2015 at 7:38 PM, andrew cooke wrote:
>
> ah. for some reason i was thinking they were invisible (somewhere below
> julia).
>
> ok, thanks. so that explains things more clearly
>
> ...except that(!) using SubString(s, i, endof(s)) and passing *that* to
> match still gives the
maybe it should check to see if the end matches?
@glen - i think that will construct an ascii string, which isn't what you
want if the underlying data are unicode. i've always assumed string() does
something smart and returns the "right thing", but haven't checked...
andrew
On Tuesday, 21 J
On Tue, Jul 21, 2015 at 8:19 PM, andrew cooke wrote:
>
> maybe it should check to see if the end matches?
My guess, is that this is an optimization that won't have too much
benefit because in most cases you can just call `match` with a start
idx.
>
> @glen - i think that will construct an ascii
unfortunately, the semantics for the match don't seem to be the same.
if you use a substring then "^" binds to the start of the substring.
if you use match(...) with an offset then "^" binds to the start of the
underlying string.
at least, that's how i understand the following:
julia> match(r
yeah, i guess in this case that's what the lib wants, so you need to force
conversion if you don't have utf8.
On Tuesday, 21 July 2015 21:25:09 UTC-3, Yichao Yu wrote:
>
> And from the code I pasted, `utf` should probably do the copy you want.
>
fwiw, https://github.com/JuliaLang/julia/issues/12262 now contains a
summary of this thread.
On Tuesday, 21 July 2015 22:03:39 UTC-3, andrew cooke wrote:
>
>
> unfortunately, the semantics for the match don't seem to be the same.
>
> if you use a substring then "^" binds to the start of the sub
17 matches
Mail list logo
