jensnockert has quit [Remote host closed the connection]
markbrazil has quit [Quit: Leaving]
pawnbox_ has quit [Read error: Connection reset by peer]
pawnbox has joined #jruby
nirvdrum has joined #jruby
pawnbox_ has joined #jruby
pawnbox has quit [Ping timeout: 252 seconds]
pawnbox has joined #jruby
lance|afk is now known as lanceball
pawnbox_ has quit [Ping timeout: 256 seconds]
nateberkopec has joined #jruby
Aethenelle has joined #jruby
nateberkopec has quit [Ping timeout: 255 seconds]
colinsurprenant has quit [Quit: colinsurprenant]
samphippen has joined #jruby
quadz has quit [Ping timeout: 240 seconds]
quadz has joined #jruby
jensnockert has joined #jruby
jensnockert has quit [Remote host closed the connection]
jensnockert has joined #jruby
jensnockert has quit [Remote host closed the connection]
pawnbox_ has joined #jruby
pawnbox has quit [Ping timeout: 264 seconds]
jensnockert has joined #jruby
Guest70188 is now known as mberg
pawnbox_ has quit [Remote host closed the connection]
jensnockert has quit [Ping timeout: 246 seconds]
enebo has joined #jruby
Aethenelle has quit [Quit: Aethenelle]
pawnbox has joined #jruby
thedarkone2 has joined #jruby
rsim1 has joined #jruby
<enebo>
rsim: did you see commits to jnr-posix?
<enebo>
rsim: long paths never worked
rsim has quit [Ping timeout: 248 seconds]
<enebo>
alrighy then :)
nateberkopec has joined #jruby
<rsim1>
enebo: Hi! So as I understand now you have removed //?/ at all as it didn't work for all long path cases anyway?
<enebo>
rsim1:
<enebo>
heh
<enebo>
rsim1: yeah
<enebo>
rsim1: I am not re-impling using windows GetFileAttributesExW which I think just works in all path lengths
<enebo>
rsim1: this also appears to be what MRI is doing too
rsim1 is now known as rsim
<enebo>
rsim: So fun bit is that long paths do not even work on _wstat64
<enebo>
rsim: weird we have not gotten reports on that…I am guessing most people work around it
Aethenelle has joined #jruby
<rsim>
enebo: so it is too hard to implement Windows long path support and therefore you won't do it in the nearest future?
<enebo>
rsim: I am doing it this morning using GetFileAttributesExW
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<enebo>
rsim: I almost had it written last night but I need to write some translation code btween time formats
<rsim>
enebo: ah, so there is a hope that it will work in the next version? :)
<enebo>
rsim: yeah definitely
<rsim>
enebo: great, thanks :)
<enebo>
rsim: not that appveyor is up and green for jnr-posix I think it will be more enjoyable iterating on this
vtunka has quit [Quit: Leaving]
<enebo>
rsim: windows is a platform which is not fun to support but we realize it is a signitficant differentiator for us to support it well
<rsim>
enebo: we need to create a quickfix for the issue with UNC path and mkdir_p - I am thinking that we could patch WindowsHelpers.java and replace compiled WindowsHelpers.class in jruby-complete.jar
<enebo>
rsim: we do not have same native extension issues as MRI so we I think end up being more attractive on windows
<rsim>
enebo: I think that there is no other workaround how to fix it in JRuby 1.7.22, right?
<enebo>
rsim: I noticed MRI will remove //?/ from any path it finds before calling this (seemingly missing the //?/UNC/ one
<enebo>
rsim: yeah I don’t think so. If you need to deploy this against 1.7.22 and 1.7.23 (not out yet) you will probably want some version guard around it
<enebo>
rsim: I will also ask if you can test this before we decide to put out 1.7.23
<enebo>
rsim: but then you can make sure your monkeypatch will work on both versions
<rsim>
enebo: currently we will just remove this path = "//?/" + path; line as for us the critical thing is that some customers have UNC path but not long path
<rsim>
enebo: and we can help to test JRuby 1.7.23 before the release to check that it works with long path names
<enebo>
rsim: ah so that may actually not break anything across versions (although you may not want to monkey patch it forever)
<enebo>
rsim: that method now is just a single return line with no isAbsolute check
samphippen has joined #jruby
<rsim>
enebo: BTW today I got another strange JRuby issue. When I got the NameError in one of the threads in my thread pool then NameError to_s or inspect or message methods fail with NullPointerException and with this very long stack trace https://gist.github.com/rsim/896cd46913ab1422e366
nirvdrum has quit [Ping timeout: 240 seconds]
colinsurprenant has joined #jruby
<rsim>
enebo: didn't manage to reproduce it with a smaller test case
<enebo>
rsim: so some NameError is being thrown and it is inspecting the object and hitting something which is null
<enebo>
rsim: so you know as much as me with this
<enebo>
rsim: -Xreify.classes=true you can try this and see if the stack uncovers more info for you
camlow325 has joined #jruby
rcvalle has joined #jruby
samphippen has quit [Ping timeout: 240 seconds]
donV has joined #jruby
samphippen has joined #jruby
<headius>
rsim: hi there! Going to be at OOW?
denym_ is now known as zz_denym_
havenwood has quit [Ping timeout: 240 seconds]
<pitr-ch>
headius hi, did you get my messages earlier?
<enebo>
some are repeats aged in diff barrels but yeah…
<lopex>
and some retired
<enebo>
they do not drop below 10 until page 4
<headius>
pitr-ch: looking now
<headius>
pitr-ch: wow, seems like everyone has a take on ivar volatility today
<headius>
my position is that it sucks that we have to make them volatile by default but we don't really have another option
<pitr-ch>
headius I am sorry if I am dragging you again into sam conversation
<pitr-ch>
*same
<headius>
no, it's a good conversation to have
<headius>
thedarkone2 is concerned too
<headius>
the fact is, we've had this volatile ivar code in place for a couple years now
<headius>
it doesn't seem to be holding us back in general
<pitr-ch>
headius yeah we already talked, it turned out we are both from Czech republic :)
<headius>
hah good
<pitr-ch>
headius I have to concerns, 1. that it might close door for future optimisation in JRuby but also in Ruby community in generally since people will rely on it more
<pitr-ch>
*to->two
<pitr-ch>
I am trying to put together a ruby memory model common for all implementations where ivars would be non-volatile
<pitr-ch>
volatile fields would be provided by a layer in concurrent-ruby
<headius>
well I did try to make this only a soft guarantee but I know saying it at all means people will rely on it :-(
<pitr-ch>
this is already implemented, documentation is lacking though
<headius>
hmmmm I see
<pitr-ch>
documentation is comming soon though, it has to be in place for this sicussion to continue and for rubyconf
<pitr-ch>
*discussion
<pitr-ch>
did anybody did some testing with removed fences/volatilePut on write path (when the ivar array does not change length)
<pitr-ch>
I guess that I could hurt JRuby's performance in future
<pitr-ch>
*it could
<pitr-ch>
headius what do you think?
<pitr-ch>
regarding concurrent-ruby it does not matter if ivars are volatile or not, I can just change JRuby's implementation of Synchronisation layer to match the behaviour.
<pitr-ch>
2. concern is that the current implementation might not be save in JMM terms, since ivar read is alway just plain memory read. This is most probably fine on x86 but on other platforms it could cause problems. Or even on x86 if JVM manages to move the ivar read from a loop, i do not have a test case for that.
jensnockert has joined #jruby
<headius>
pitr-ch: it would be worth testing...I believe when we added it we didn't see a big performance change though
<headius>
would you like to give it a try?
dinfuehr has quit [Remote host closed the connection]
<pitr-ch>
I could, if it turns out to have impact, would you consider to remove the ivar volatility? or would you rather avoid confusion?
<headius>
well I'd like to know this sooner rather than later and deal with it right now
<headius>
my concern about removing the volatility now is that there's untold amounts of code out there depending on it without realizing it
<headius>
of course, if it's actually needed we should be able to produce a failure case too
<pitr-ch>
yeah definitely, I'll do some testing today
jensnockert has quit [Ping timeout: 244 seconds]
<pitr-ch>
if JRuby drops it in future it will probably have to be done loudly so people know to expect problems
<headius>
right
<headius>
and since it's there in 1.6, 1.7, 9k, it would probably have to remain until 9k+1
<pitr-ch>
and concurrent-ruby should be prepared to help
<headius>
and potentially be something a user can turn back on
<headius>
-Xvolatile.ivars
<headius>
or something
<pitr-ch>
yeah, I would only like to test the performance now if makes sense to remove the guarantee form the wiki page to open the doors for optimisation again
<pitr-ch>
yeah that could help with transition
<pitr-ch>
ok so I am off to do some testing :) and I'll let you know
<headius>
ok thank you!
<headius>
we need to reopen this discussion with matz and ko1 at rubyconf
<pitr-ch>
yeah definitely
<pitr-ch>
I would like to start sooner
<pitr-ch>
though
lanceball is now known as lance|afk
<pitr-ch>
I'll write up a memory model we use in concurrent-ruby as a starting point
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<enebo>
headius: pitr-ch: I don’t think ko1 will be at rubyconf
<headius>
jiggawhat?
drbobbeaty has quit [Read error: Connection reset by peer]
drbobbeaty has joined #jruby
shellac has quit [Ping timeout: 256 seconds]
rsim has quit [Quit: Leaving.]
CustosL1men has quit [Ping timeout: 255 seconds]
havenwood has joined #jruby
rsim has joined #jruby
dinfuehr has joined #jruby
dinfuehr has quit [Remote host closed the connection]
dinfuehr has joined #jruby
lance|afk is now known as lanceball
<rsim>
headius: No, I will not be at OOW. I will be later in San Francisco during Nov 3-6, on that week there will be Atlassian Summit conference
<headius>
ahhh too bad
nirvdrum has joined #jruby
jensnockert has joined #jruby
colinsurprenant has quit [Quit: colinsurprenant]
<nirvdrum>
headius: I grabbed lunch with Pat Shaugnessy today. He wanted me to say "hi."
<headius>
oh cool, haven't chatted with him in a while
<nirvdrum>
I just met him for the first time through a mutual contact.
jensnockert has quit [Ping timeout: 246 seconds]
oblutak has joined #jruby
baroquebobcat has quit [Quit: baroquebobcat]
<pitr-ch>
headius the results indicate difference 15% when writes are not checked
<headius>
ok, so not enormous but not small
<headius>
it may have more impact for contended reads and writes...how did you test?
<headius>
I assume this was on java 8, so fullFence impl
<enebo>
nirvdrum: lopex: we should priobably make a new name in convertbytes which is clear it is for simple case
<lopex>
if thei're still there :)
<enebo>
yeah
<enebo>
as it is if we use any non-19 methods for working with bytes we cannot see that we did it as an opt as a glance
<lopex>
enebo: they were just reused
brauliobo has joined #jruby
<lopex>
hmm, I have an app under torquebox/rack in a docker
<lopex>
and it's visible via apache https with mod_proxy
<lopex>
on host machine
<enebo>
lopex: yeah I get that but we can rename and deprecate plain name
<lopex>
sometimes chrome looses the session
<lopex>
and only chrome only for https
<lopex>
should I be worried ?
<nirvdrum>
headius: It's used. But I have a hard time telling if it's a bug or just some weird backwards-compat behavior.
<nirvdrum>
Some of the StringSupport methods are like that.
<nirvdrum>
Ahh, you guys already covered that. I need to read faster :-)
tcrawley is now known as tcrawley-away
samphippen has joined #jruby
robbyoconnor has quit [Ping timeout: 246 seconds]
<headius>
nirvdrum: what's using it?
<headius>
I have fixed a few places over the years that shouldn't be
<headius>
it would be interesting to see how much e.g. rails does reads versus writes of ivars
<nirvdrum>
RubyNumeric#str2inum and RubyString#stringToInum.
<nirvdrum>
One clear example, back-to-back, is RubyString#oct and RubyString#hex.
<nirvdrum>
The former uses stringToInum while the latter uses stringToInum19.
<nirvdrum>
Wherever we land this time, I'm adding a comment so it's not confusing in the future :-)
brauliobo_ has joined #jruby
brauliobo has quit [Ping timeout: 264 seconds]
yfeldblum has joined #jruby
yfeldblum has quit [Ping timeout: 240 seconds]
<nirvdrum>
headius: It looks like oct shouldn't be using the 1.8 variant.
<nirvdrum>
I guess there isn't a spec for this.
dinfuehr has joined #jruby
baroquebobcat_ has joined #jruby
baroquebobcat has quit [Ping timeout: 240 seconds]
baroquebobcat_ is now known as baroquebobcat
dinfuehr has quit [Ping timeout: 255 seconds]
subbu|lunch is now known as subbu
jensnockert has joined #jruby
pawnbox_ has quit [Remote host closed the connection]
samphippen has quit [Ping timeout: 240 seconds]
samphippen has joined #jruby
jdantonio has joined #jruby
jensnockert has quit [Ping timeout: 250 seconds]
<headius>
colinsurprenant: how inconvenient would it be if you had to use something like attr_volatile to mark an instance variable as volatile?
<headius>
as we discussed, JRuby's had volatile ivars for a long time, but now it sounds like we take a 30% hit on the cost of writing instance vars as a result
<headius>
how much lost app performance that translates to is not clear
<colinsurprenant>
headius: i think it would actually be good and make it explicit
<headius>
you might want to stop into concurrent-ruby gitter
<colinsurprenant>
joining
<colinsurprenant>
ok, bug thread :P
<colinsurprenant>
*big
<headius>
colinsurprenant: yeah, good discussion
<nirvdrum>
Bah. I thought this was happening in #concurrent-ruby :-(
<headius>
you don't need to read all of it but we're talking about the state of the art right now and considering paths forward
<nirvdrum>
I was wondering why everyone was so quiet.
<headius>
nirvdrum: oh hahah
<headius>
sorry
<headius>
I idle in the gitter
<nirvdrum>
I'll just fire up my 6th chat client now.
<nirvdrum>
The future sucks.
<headius>
it sure does
<headius>
this shit was all consolidating too
<headius>
I finally got down to a single IM account, and then group chat fragmented all to hell
jdantonio has quit []
<nirvdrum>
Now I have pidgin, hexchat, skype, hipchat, slack, and gitter.
<nirvdrum>
I need to dedicate like 1.5 GB RAM just to chat clients.
<headius>
I only have IM, IRC, and Gitter clients at this point
samphippen has quit [Ping timeout: 240 seconds]
<headius>
Skype is such a POS I gave up running it
samphippen has joined #jruby
lea has quit [Ping timeout: 264 seconds]
camlow32_ has joined #jruby
CustosL1men has joined #jruby
<lopex>
nirvdrum: but but, Gates said you wouldnt need
camlow325 has quit [Ping timeout: 268 seconds]
jensnockert has joined #jruby
<nirvdrum>
I needed to install Slack because Mac users like it. But each channel takes up 200 MB. HipChat has a native client, but it crashes regularly. Skype has been suprisingly solid, but I would like a way to pay to have the ads removed.
rsim has quit [Quit: Leaving.]
jensnockert has quit [Ping timeout: 252 seconds]
tcrawley-away is now known as tcrawley
<headius>
@lopex I was marveling yesterday that the 512MB in my crappy old Nook Color table is woefully inadequate to even read books on
tcrawley is now known as tcrawley-away
<headius>
what the hell has happened to us
<headius>
table=tablet
<enebo>
OMG I am boiling some ocean
<enebo>
getting close to trying this out though
<headius>
enebo: windows stat?
<headius>
I'm deep into this volatility discussion
<enebo>
yeah it is a lot more code than I thought
<headius>
what do you think of attr_accessor :foo, model: volatile
<enebo>
but I have handle and path stat written
<enebo>
does it work? who knows
<headius>
model used here because there would also be model: atomic in the future probably
<enebo>
headius: yeah I like the idea but we need to lobby for this
<headius>
in this case it may be an easy lobby... volatile ivars on MRI are a no-op
<headius>
since they have memory barriers on thread switch
<enebo>
it is also mildly interesting to see ‘attr_accessor :one, :two, model: volatile
<enebo>
but it works
bbrowning is now known as bbrowning_away
<headius>
yeah
<enebo>
headius: my only caveat is attr_* is detined to be rewritten in Ruby
<enebo>
and hopefully soon
<enebo>
headius: so this may mean IR may need more instrs or at least a flag to generate volatile or not
<enebo>
but that is not a big problem just something which will get run into
<headius>
enebo: actually it would be simpler than that in JRuby proper
<headius>
our current variable accessor is volatile... all model: volatile would do is use it
samphippen has quit [Read error: Connection reset by peer]
<headius>
set up the var table with StampedVariableAccessor (as we have now) and reduce non-volatile ivars to use a simple version
<headius>
probably in a semi-major release of JRuby
<lopex>
headius: instance Num Int where, just says the Int is an instance of Num
<lopex>
on scala side it's the singleton object that's passed as an implicit
<lopex>
containing impls for int ops
<lopex>
in haskell it's just built in, no need for explicit implicits :)
<lopex>
headius: I heard enebo saying IR storing is promising ?
<lopex>
headius: I'd be happy for an aoting flag :)
<enebo>
lopex: as it stads it is somewhat promising for non —dev startup but does not make much difference vs —dev
<headius>
yeah --dev is still the biggest improvement we've had
<headius>
lopex: I did talk with Christian Thalinger at JVMLS...he has a working AOT for OracleJDK and it shows a lot of promise for speeding up JRuby
<enebo>
lopex: an idea subbu (ignore) had was to make a binary interpreter of the persisted IR data which would eliminate parsing and reifying instrs+operands into objects
<headius>
it currently isn't planned to be free or Free but they'd let us use it for free
<enebo>
lopex: so in theory the cost of reading the file would be cost of a filemap. Whether that interp runs ok is another question
<headius>
I haven't heard from him since then but that was just a few weeks ago
<enebo>
lopex: and it would require a lot of work
<lopex>
enebo, headius: I guess my case is a rare one, so just asking
<enebo>
lopex: but the other longer term goal is to also persist more optimzed code which would not help startup but would improve initial cold perf but it is way out in my mind
<lopex>
like rails reloading is one thing, but whole metamodel processing per reloading is another
<headius>
yeah that kind of stuff is sorta out of scope right now
<headius>
and AOT JRuby itself doesn't address cold perf, but it would mean we could hit the ground running faster with precompiled, preoptimized code
<headius>
right now loading precompiled code is much slower than loading source to interpreter
<headius>
oh, the Oracle AOT feature is expected to be like JMC, free for dev use
<enebo>
but saving IR after all safe opts are fun would speed up warmup I think
<headius>
so that's good too
<headius>
yeah probably
<headius>
and knowing if there's anything we want to jit right away
<headius>
our compiler doesn't even AOT anymore of course, so I'd have to write that :-)
<lopex>
headius: is that aot something like excelsior jet, or what what is it called ?
<enebo>
yeah that one is more difficult to know 100% but perhaps that is where we allow people to save profiled data separately
<headius>
it's like jet, yes
<enebo>
headius: well it does make a class :)
m4rCsi has quit [Quit: No Ping reply in 180 seconds.]
<headius>
two modes: tiered (JIT can continue to optimize AOT code) and untiered (what you start with is what you run with forever)
<headius>
the latter would be interesting for startup, the former for improving cold perf
<enebo>
lopex: that cable video is pretty amazing
<enebo>
well fudge I am not sure what is up with this struct
<lopex>
it was pretty cool seeing pointers as java abstractions
<headius>
Bernd went to Yahoo...dunno what he has done since
<headius>
now there's a company that defies explanation
<headius>
time for dinner now, ttfn
camlow325 has quit [Ping timeout: 246 seconds]
shellac has joined #jruby
<lopex>
chrisseaton: from what I recall the biggest selling point of maxine was inlining vm guts with the rest
<lopex>
since now it's all specialized in hotspot
<lopex>
like allocation
<lopex>
inlined subs
<lopex>
*stubs
jensnockert has quit [Ping timeout: 272 seconds]
camlow325 has joined #jruby
camlow325 has quit [Remote host closed the connection]
camlow325 has joined #jruby
enebo has quit [Quit: enebo]
brauliobo_ has joined #jruby
<lopex>
chrisseaton: so nashorn/truffle might be a natural choice now right?
Cu5tosLimen has joined #jruby
m4rCsi has joined #jruby
<chrisseaton>
not sure what you mean by nashorn/truffle? do you mean nashorn using truffle or nashorn or truffle
<lopex>
using
<chrisseaton>
there's already a JS using Truffle, so it wouldn't make sense to retrofit Nashorn
<lopex>
so there will be an overlap wrt indy and truffle for some time ?
shellac has quit [Quit: Computer has gone to sleep.]
<chrisseaton>
my personal opinion is that truffle can cover both use cases, but that's not an Oracle policy
<lopex>
since both jruby/jruby-truffle share lots of core impls, same should be for js
<chrisseaton>
to get the best performance it's hard to share a lot of stuff we've found - I've got a video on that I will share soon
CustosL1men has quit [Quit: Leaving]
<lopex>
yeah, I gues one must adjust to the other model
Cu5tosLimen has quit [Quit: CustosLimen]
Cust0sLimen has joined #jruby
<lopex>
I wonder if truffle could be made an e2e product with full gui with support for syntax designing like antr, whatever default runtime libs etc
<lopex>
that might make a case for dsls in lots of fields
<chrisseaton>
there is a group at King's London working on a graphical editing tool
<chrisseaton>
what you are describing is often called a 'language workbench' - if you google that there are lots of ideas
<lopex>
like starting with antlr ?
<lopex>
hmm, yeah, also different fields require different constraints on the language
<chrisseaton>
i had an idea at one point where nodes would know how to parse themselves, like they know how to execute themselves
<lopex>
so you might end up with a "library" or starter kit for your field
<chrisseaton>
didn't really go anywhere
<lopex>
ast nodes ?
<chrisseaton>
yeah
<lopex>
is the runtime ast changing going anywhere ?
<lopex>
or local grammars ?
camlow325 has quit [Remote host closed the connection]
<chrisseaton>
runtime ast changing? sorry not sure what you mean
<lopex>
er, I meant grammar changing
<chrisseaton>
King's are also looking at that
<lopex>
since ast is often modified for degenerated grammars right
camlow325 has joined #jruby
<lopex>
I was astonished from your last talk about constant propagation/folding wrt ruby in truffle
<chrisseaton>
thanks - I love that demo
<lopex>
thinking how much will have to be deoptimized potentially
<chrisseaton>
trying to come up with some more extreme examples
<lopex>
eval was harsh
<lopex>
and binding
<chrisseaton>
x = 14; p = Proc.new { }; p.binding.local_variable_get(:x)
<chrisseaton>
is my favourite
<chrisseaton>
the infamous Proc#binding
<lopex>
yeah
<chrisseaton>
run the tool yourself - try to come up with some expressions you'd like to be constant folded and aren't and we'll see if we can make them so
<lopex>
but since you can constant fold those things, cant you perform global value numbering on them too ?
<lopex>
or whatever
<lopex>
where's the limit ?
<lopex>
since a constant is a tree element ?
<lopex>
or must it be a leaf ?
<chrisseaton>
gvn deduplicates code, which isn't essential for folding
<chrisseaton>
yeah - the limit is just where we don't know a value in advance
<lopex>
ok
<chrisseaton>
so rand is obviously a limit, unless it's rand < 1 in which case we know the value because it's always true
<lopex>
still impressive
<lopex>
yeah, thinking about something about constraints
<chrisseaton>
not impressive enough for RubyConf apparently (/bitter)
<lopex>
like >0
<chrisseaton>
(this actual demo wan't part of the submission, and I'm sure they get thousands of top quality submissions etc)
<lopex>
if it could be propagated through those boundaries
<lopex>
why it wasnt ?
<lopex>
not enough clapping ?
<chrisseaton>
it wasn't accepted for this year
camlow325 has quit [Remote host closed the connection]
Cust0sLimen has quit [Quit: CustosLimen]
<lopex>
I wonder if truffle could help a regexp engine in a way that it used native java stack to a threshold limit, then fallback to artificial one using heap
camlow325 has joined #jruby
camlow325 has quit [Remote host closed the connection]
<chrisseaton>
there was a Truffle version of JONI, not sure what happened to it
<lopex>
as a perf/robustness limit
<lopex>
er, tradeoff
<lopex>
joni has those pesky subexp calls that make the stacks somewhat different
<lopex>
no idea how to make it efficient
Cust0sLimen has joined #jruby
<lopex>
can truffle use unsafe (or access the heap in non uniform way) in a more efficient ways ?
<nirvdrum>
lopex: I think Chris is gone for the night.
<lopex>
that might be a case to fast utf8 length routines nirvdrum was talking about
<lopex>
lol
<nirvdrum>
I'm not sure if Graal can optimize anything there. Truffle doesn't provide any additional factilities over Unsafe.
<lopex>
I guess I became a bit trying
<lopex>
nirvdrum: but that utf8 length is a big one
<lopex>
mri might be 10x faster here
brauliobo_ has quit [Ping timeout: 244 seconds]
<nirvdrum>
lopex: Heh. I think it was just late for him. We had a 1:1 call at 11:45 PM his time.
<lopex>
he's in uk now ?
dinfuehr has quit [Remote host closed the connection]
rcvalle has quit [Quit: rcvalle]
<nirvdrum>
lopex: He's lived there as long as I've known him.