<headius[m]>
ahorek: sorry we hijacked your PR for a spec debate
ur5us_ has joined #jruby
ur5us has quit [Ping timeout: 260 seconds]
jeremyevans has quit [Ping timeout: 265 seconds]
ur5us_ has quit [Ping timeout: 240 seconds]
jeremyevans has joined #jruby
<ahorek[m]>
<headius[m] "ahorek: sorry we hijacked your P"> no problem at all 🙂
ur5us_ has joined #jruby
<headius[m]>
👍
nakilon has joined #jruby
<nakilon>
hello
<headius[m]>
Greetings
<nakilon>
I'm trying to shrink the .jar file created by the warbler gem -- I'm removing some files one by one to reduce the size from 27 to 17 MB already, but I don't know how to understand what some files are for
<nakilon>
for example, org/jruby/ext/ripper/YyTables.class and org/jruby/parser/YyTables.class -- is it something vital?
ur5us_ has quit [Remote host closed the connection]
ur5us_ has joined #jruby
ur5us_ has quit [Remote host closed the connection]
<headius[m]>
Things under the ext dir can go unused and aren't loaded unless requested... So if app works without it you are probably ok
<headius[m]>
bigdecimal is a notable exception
<headius[m]>
Outside of that it gets muddy
<headius[m]>
I am sure the parser uses the yytables for loading code
<headius[m]>
I do wonder if those could be compiled better to not use so much room
<nakilon>
removed jline with no idea if I need it; seems ok
<nakilon>
there is something about asm: com/kenai/jnr/x86asm/SerializerIntrinsics.class and jnr/x86asm/SerializerIntrinsics.class
kares[m] has quit [Quit: Idle for 30+ days]
<nakilon>
alright, I broke it finally ) ERROR: java.lang.reflect.InvocationTargetException
<nakilon>
seems like org/jruby/ir/IRBuilder.class is vital but from the name I could only suppose it's about IRB
<headius[m]>
Jline is for readline support at console, like in irb
<headius[m]>
Haha
<headius[m]>
Yeah no, Intermediate Representation Builder
<headius[m]>
Turns parsed code into our compiler IR
<nakilon>
I would automatically run the whole test suite of mine after each big file deletion but java -jar starts so slow it would take ages
<nakilon>
removed a bunch of rdoc and even ttf files so the largest files now are these: https://dpaste.org/DwU3
<nakilon>
resulting jar is 15MB but I need 10MB, hope is disappearing
<headius[m]>
Hmmm
<headius[m]>
10 is pretty small
<headius[m]>
There are told you can run to strip debug symbols and such from the jar
<enebo[m]>
Freaky: At arg processing all we really care about is comparing the front as ascii and I was concerned bytes with wide string would not be comparable
<headius[m]>
the error on Travis makes no sense... can't fine ScriptingEngine or somesuch
<headius[m]>
find
<enebo[m]>
Freaky: so I thought using lossy would work well for that but then I still need the bytes after the key
<Freaky>
enebo[m]: yeah, you could use the lossy function to find the index given you know the prefix is all bytes, but then you'd want to go via encode_wide/from_wide if it doesn't convert
<enebo[m]>
UCS2/UTF16-LE is like '\0a\0b\0c' right?
<enebo[m]>
I can make the string I am comparing into a wide one I guess
<enebo[m]>
Freaky: anyways I will look at that code and I know it will help me to better grok how to handle this
<Freaky>
I think os_str_bytes works much the same as my code there
<enebo[m]>
yeah if it just gives back the raw bytes I am sure
<Freaky>
if it can be represented as utf-8, it does that, if it's unix it can convert to raw bytes, and it only has to make an owned wide Vec<u16> on Windows if it's some weird encoding
<enebo[m]>
but I don't think I know if on windows I will see A or W from a console will I?
<enebo[m]>
ah ok
<enebo[m]>
perfect
<enebo[m]>
I just want ascii when it is and not ascii if it isn't and to keep the value part of OsString
<enebo[m]>
Rust is pretty well thought out but I found this initial should I use String or OsString difficult because you cannot just use OsString and get the same level of utility as String
<enebo[m]>
That makes sense but it definitely influenced me down the simpler path at first (realizing in the back of my mind I would end up having to change it)
<Freaky>
yeah, it can certainly be fiddly
<Freaky>
clap was using unsafe code and making assumptions about storage
<Freaky>
transmute to bytes, assume it's WTF-8 on Windows
<Freaky>
dodgy thing for such a big part of the ecosystem to be doing :)
<enebo[m]>
In retrospect I liked my instincts because I got something working with Strings I suspect faster than I would have been yakking on the OsString version
<enebo[m]>
yeah
<enebo[m]>
In Rust's defense it evolves over poor use cases and generally eventually fixes them. Some internal unsafe code perhaps won't always be
<enebo[m]>
Freaky: yeah. It is fun to see how the process plays out
<enebo[m]>
Freaky: I plan on using Xargo for linux build with musl but the RFC side of what that can do is nowhere near it and probably won't be for years :|
<Freaky>
not familiar with xargo or building with musl
<Freaky>
does it not just work with the appropriate target?
<enebo[m]>
Freaky: oh it works but musl means no linking to libc and xargo will generate 100k vs 300k binary
<enebo[m]>
Xargo will conditionally compile in std so it omits things not used
<headius[m]>
We don't want to require that users have rust set up so we want to ship binaries for a number of platforms in the gem
<headius[m]>
The smaller the better
<enebo[m]>
There is some partial support for this in nightly but it does not really make a big difference
<enebo[m]>
headius: although even the stripped 300k binary x 3 (linux/macos) + windows 200k is smaller than our existing jruby.exe (much less jrubyw.exe and jruby.dll) which are all about 900k a piece
<enebo[m]>
err x2
<Freaky>
enebo[m]: significantly more effective than LTO?
<enebo[m]>
yeah the 300k is with LTO and a couple of other options
<enebo[m]>
xargo is doing all of that and grabbing source of std
<enebo[m]>
There are crazier levels to take it but at this point I will have 100k + 300k + 200k as the three platform binaries
<enebo[m]>
later we can add *BSDs but it is a bit of a pain to setup and I got tired of messing with GHA
<enebo[m]>
and archs
<enebo[m]>
It might be 200k * 2 for windows for jrubyw.exe but I think I can do argv0 sort of compare on name and have it just launch as windows config
<enebo[m]>
if it is jrubyw.exe
<headius[m]>
that would be really nice
<headius[m]>
jrubyw.exe and jruby.exe will share code in a dll or what?
<headius[m]>
enebo: ^
<enebo[m]>
headius: they will be the same excutable copied as different named files
<headius[m]>
copied on install
<enebo[m]>
yeah
<headius[m]>
ok cool
<enebo[m]>
I cannot remember what the program was but an ancient unix utility used to work this way
<headius[m]>
well bash does this to switch to sh emulation
<enebo[m]>
thanks this will bug me all day now :)
<headius[m]>
so that's one example
<enebo[m]>
yeah sh does do that too ... it is not what I was thinking of
<enebo[m]>
It was something which sent in one command and recieved in another
<enebo[m]>
my brain cannot remember what I am thinking of uucp?
<headius[m]>
hmm beats me
<enebo[m]>
oh what are some old revision control systems
<enebo[m]>
rcs?
<enebo[m]>
AHA!
<enebo[m]>
ci and co of RCS worked like this
<enebo[m]>
I think that was it
<enebo[m]>
I think I discovered this by accident by cp'ing one to another name and it started doing the other action
<enebo[m]>
It blew my mind when I realized how it worked (mind you this was in the 80s :) )
drbobbeaty has quit [Read error: Connection reset by peer]