<crystal-gh>
[crystal] RX14 opened pull request #5539: Implement Crystal::System::Random for win32 (master...feature/windows-system-random) https://git.io/vNfjW
<FromGitter>
<elorest> I like windows if all I need to do is click on Overwatch. For programming I feel really lost. I spent 2 weeks getting a python machine learning program that someone wrote in windows to run in linux a few weeks ago.
<FromGitter>
<elorest> Windows is getting better but it still seems that that it's really hard to port between the two where as linux/osx/bsd seem to work fairly easily with the same code bases.
<RX14>
well yeah
<RX14>
thats because linux/osx/bsd have PISIX
<RX14>
POSIX*
<RX14>
windows doesn't support posix
<FromGitter>
<elorest> Good to know. I just got rid of my mac and have been using arch for the last month. I sort of planned on just using windows with docker, but ended up just installing linux.
<FromGitter>
<elorest> It's been a since 2009 since my dev box was linux. It's really improved. A lot of things work way better than in OSX.
<RX14>
i've been using arch since maybe 2014
<RX14>
and it's been great all this time
<RX14>
never failed me
faustinoaq has joined #crystal-lang
<RX14>
my setup is fairly customized
<RX14>
it's cool
<FromGitter>
<elorest> I have an LG thunderbolt monitor and with my mac I can't change the volume or mute it but in arch it works perfectly with no configuration.
<FromGitter>
<bew> "with no configuration" are we talking about arch here?
<FromGitter>
<bew> ah no ok sry I mis-read your msg
<RX14>
lol @bew I assume @elorest installed a desktop environment
<RX14>
in that case a lot lot of things just work out of the box
<FromGitter>
<elorest> No configuration other than installing gnome etc.
<RX14>
heh
<FromGitter>
<bew> yeah probably, I'm not used to it ^^
<RX14>
gnome *is* a lot of configuration
<RX14>
it's just not yours
<FromGitter>
<elorest> No configuration related to the monitor.
<FromGitter>
<elorest> I have configured gnome to work and look how I want.
<RX14>
yeah I play it much more raw
<FromGitter>
<bew> how does it look like?
<RX14>
with just i3-wm
<RX14>
and custom scripts
<FromGitter>
<bew> <3
<RX14>
just bothered to make the volume buttons on my laptop work
<FromGitter>
<asterite> But is utf-16 needed for that and that's blocking it, or just lack of time?
<RX14>
I think UTF-16 would be a great help
<RX14>
windows defines A and W variants for all functions that take strings
<RX14>
the A variant is traditional codepages, which suck
<RX14>
and W variant deals with wchar, which is utf-16
<RX14>
I don't want to spend the time later converting everything to wchar for unicode support
<RX14>
so I want to do it right first time, which means UTF-16 whcar support
<FromGitter>
<asterite> So we need UTF8 <-> UTF16 conversion, right?
<RX14>
that basically means being able to create a String from a WCHAR* and concert Strign to WHAR*
<RX14>
WCHAR*
<RX14>
@asterite essentially
<RX14>
but we have UTF8->codepoint
<FromGitter>
<asterite> I can work on that. Should be fun.
<RX14>
so we need codepoint<->UTF-16 more accurately
<RX14>
don't worry about endianness for now
<RX14>
because we just need a WCHAR*, not to actually write the UTF-16 to a file or disk
<RX14>
thanks @asterite
<FromGitter>
<asterite> Too bad we'll need to allocate memory for that. Maybe we can try to use part if the stack if a string is small, but probably an optimization for later
<FromGitter>
<asterite> of the stack
<Groogy>
RX14 yesterday we briefly talked about incremental compilation. Just so we are nto talking past each other, you mean you can compile compilation units?
<Groogy>
just curious because we have distributed compilation now at work and cut down our compilation times from half an hour to ~3 minutes
<RX14>
Groogy, just so we're clear, these are compilation units to LLVM only
<Groogy>
you still need the entire context of the source right to actually compile? :/
<RX14>
the majority of time you spend when compiling a non-release build is spent in the crystal compiler, not LLVM
<RX14>
this bit needs the entire sourcecode
<RX14>
there's no parallelism
<RX14>
and everything's one big unit
<RX14>
it's *only* when we get to actual codegen that we can split things up
<RX14>
and cache things
<RX14>
for the compiler, it's 20s to even get to the codegen stage
<RX14>
so all you're doing is making codegen take 4s instead of 20s
<RX14>
which is great
<RX14>
you've shaved off 40%
<RX14>
but no amount of parallelism is going to shave off more than 50%
<FromGitter>
<asterite> RX14: could we use the A version of functions if the string is ascii only?
<RX14>
yes @asterite
<RX14>
but thats an optimization i'd like to leave until later
<FromGitter>
<straight-shoota> @RX14 I'm not sure I understand how your windows compile script works. You run it on WSL and connect to a local sshd? And how are these windows commands executed from within bash?
<RX14>
@straight-shoota you run sshd on WSL
<RX14>
and SSH into WSL running on Win10
<RX14>
from there, you can execute any windows process as if it was a linux one
<RX14>
just need to alter the path to include system32
<RX14>
and youc an run cmd.exe
<RX14>
and with cmd.exe you can source the compiler env batch script
<FromGitter>
<straight-shoota> and you need ssh for this?
<RX14>
and then you can compile
<RX14>
yes
<RX14>
you need to be able to SSH from your host into the VM WSL
<RX14>
it's not hard to set up actually
<FromGitter>
<straight-shoota> ah okay
<FromGitter>
<straight-shoota> I'm already working directly in WSL
<RX14>
just need to apt purge openssh-server; apt install openssh-server; edit /etc/ssh/sshd_config to change port and that
<RX14>
@straight-shoota then it's even easier for you
<RX14>
strip out all the stuff to do with ssh
<livcd>
i am kinda worried that TruffleRuby on SubstrateVM will kill Crystal :S
<RX14>
and just run the cmd.exe snippet
<RX14>
livcd, don't be
<FromGitter>
<sdogruyol> no livcd
<RX14>
if speed was all crystal was then it'd already be dead
<livcd>
then again i have the feeling we wont see a widely adopted TruffleRuby in 2 years
<Vexatos>
isn't trufflerb not compiled?
<Yxhuvud>
it is JITed.
<RX14>
it gets you speed but not so much portability
<RX14>
plus it's not "cool" lol
<Yxhuvud>
I'm not worried about truffle, because I feel the type system in crystal is so helpful. I wouldn't mind truffle delivering though, as it could conceivably make the decade old rails-app at work more palatable
<livcd>
"...not so much portability"..are you sure ?
<RX14>
well program portability
<RX14>
not platform portability
<FromGitter>
<straight-shoota> seems like I have to upgrade WSL for that interoperability
<livcd>
cuz the project metropolis sounds impressive
<RX14>
@straight-shoota hmm
<RX14>
@straight-shoota you don't get cmd.exe in your path by default...
<FromGitter>
<straight-shoota> I know
<RX14>
try just doing /mnt/c/Windows/System32/cmd.exe
justicefries has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<FromGitter>
<asterite> RX14: here's String <-> UTF-16 : https://gist.github.com/asterite/2ac6aeb59413e891d3f406072cd5e071 . If you can use it to map some window functions, you could include it in a next PR. I don't know whether to make it generally available, though. We'll probably use it just to interface with Windows. There's also `String#encode` and `String.decode` which already work with UTF-16 but don't do quite what we need
<FromGitter>
... (we need WCHAR*, not UInt8*)
<RX14>
plus String#encode and String#decode are probably going to be slow
<RX14>
since they use C bindings to iconv
<FromGitter>
<asterite> actually, maybe faster since iconv might be super optimized
<FromGitter>
<asterite> though there's no magic in utf-16
<RX14>
@asterite I doubt it
<RX14>
maybe on longer strings
<RX14>
but I think iconv's startup overhead and conversion overhead will wipe that out for any reasonable string
<RX14>
but it doesn't matter since iconv is a pain to cross-compile to windows
<RX14>
so i'd live to avoid it for as long as possible
<FromGitter>
<asterite> So... can't we have an internal stuff for converting to UTF-16 just for windows
<RX14>
not the order of the WChars, how the WChars are represented in memory
<FromGitter>
<asterite> we didn't have it before and it was fine
<wmoxam>
^^ thread
<FromGitter>
<asterite> we just need it for windows
<RX14>
@asterite but I don't see why we should hide it
<RX14>
wchar exists on linux too
<FromGitter>
<asterite> i need some use cases other than windows
<FromGitter>
<asterite> where you pass wchar*
<livcd>
go has this in syscall_windows i think :)
<Papierkorb>
Qt
<Papierkorb>
Which uses UTF-16 strings internally for historic reasons
<FromGitter>
<asterite> but externally?
<FromGitter>
<asterite> or how are you doing Qt now in crystal without this UTF16 module?
<Papierkorb>
Whatever you want. If I have reliable, fast UTF16 conversions in Crystal, I can fast-path some codepaths to avoid copying data two times (not kidding)
<Papierkorb>
QString -> reencoded to UTF8 by Qt (First copy) -> Crystal String (Second copy)
<Papierkorb>
QString will happily give me its wchar* though, and with some guarantees I can check, I could drop the immediate UTF8 copy
<RX14>
@asterite but I still don't see the downside of just making it available universally
<FromGitter>
<asterite> Well, I have experience in this
<FromGitter>
<asterite> The compiler needed Markdown so I made it public
<FromGitter>
<asterite> but it's super complex and incomplete and a huge discussion spawned
<RX14>
Markdown is super complex
<RX14>
UTF-16 is not
<RX14>
that's why
<FromGitter>
<asterite> there's Levenshtein too but the interface is ugly, so it's considered for removal
<FromGitter>
<asterite> and many other things
<FromGitter>
<asterite> well, with UTF-16 you could get uint8* or uint16*
<Yxhuvud>
levenstein is used for those lovely error messages though, right?
<RX14>
Yxhuvud, yes but it should be internal to the compiler
<RX14>
not in the stdlib
<FromGitter>
<asterite> well, this utf-16 thing could be internal to the stdlib
<RX14>
@asterite UTF-16 is always wchar*
<RX14>
UTF-16LE is always char*
<RX14>
UTF-16BE is always char*
<FromGitter>
<asterite> well, I guess we can leave it then as to_utf16
<FromGitter>
<asterite> in any case it's obvious from the signature that it's different from `encode`
<FromGitter>
<asterite> I'll make the change
<RX14>
if String#encode("UTF-16") with no endianness specified works
<RX14>
then *that's* the problem
<RX14>
that's confusing
<RX14>
(imo)
<Papierkorb>
My biggest gripe is it using a string over an enum constant or something
<RX14>
yep Papierkorb
<Papierkorb>
If it was, the user would type Encoding::UTF16, and the compiler would did you mean the LE and BE variant. How cool's that?
<RX14>
indeed
<Yxhuvud>
It is nice to be able to automatically output the platform default too, but perhaps it isn't a good default?
<FromGitter>
<asterite> done
<FromGitter>
<asterite> well, we can always implement all those encodings in crystal
<FromGitter>
<asterite> instead of using iconv
mark_66 has quit [Remote host closed the connection]
<RX14>
yeah
<RX14>
I was considering doing that
<RX14>
or putting it on my roadmap
<RX14>
but somehow the thought of implementing 40 encoding schemes doesn't exite me
<Papierkorb>
Should go through a #convert esque method in that case taking the encoding type as argument, to not spam String with billions of #to_kjs methods
<RX14>
well #convert is to get a Slice of bytes back
<RX14>
or idk
<RX14>
not all encodings are to bytes Papierkorb
<RX14>
so there would have to be some kind of utility to deal with that if we did that
<Papierkorb>
But that's what you usually end up wanting
<RX14>
not for UTF16
<RX14>
in this case
<FromGitter>
<bew> Maybe we should go the enum road, do our implementation of some encoding, and fallback to iconv for the others?
<RX14>
@bew yup
<RX14>
and make iconv optional
<RX14>
manually required
<RX14>
all it does is add more encodings
snsei has joined #crystal-lang
<Papierkorb>
Most people, if they even need it, probably will only need utf8/16, maybe ascii and latin1. windows devs may be interested in the gazillion codepages.
<Papierkorb>
everything beyond that can happily live in iconv. Or has anyone here used kjs at some point?
<FromGitter>
<asterite> i think in japan they have an encoding they use all the time
<FromGitter>
<asterite> well, in china it might be the same (not the same encoding, though :-P)
<Papierkorb>
For legacy applications, yes. No idea about Japan, but the German codepage is basically dead in Germany
<Papierkorb>
Other EU countries are probably similar
snsei has quit [Remote host closed the connection]
<crystal-gh>
[crystal] RX14 closed pull request #5486: Add explanatory message to linker command output on link failure (master...feature/linker-errors) https://git.io/vbAJo
<FromGitter>
<marksiemers> Just spend 10 minutes figuring out why `brew upgrade crystal` wasn't working... ⏎ For those of you who don't use brew - the `crystal` formula is something totally different.
<jokke>
can i somehow get the pointer of an object?
<RX14>
pointerof(obj)
<jokke>
ah
<RX14>
but thats very unsafe
<jokke>
yeah
<RX14>
make sure you know what you're doing
<jokke>
i need it for a c lib
<RX14>
hmm
<jokke>
i can't pass clojures as c callbacks but there's a "user_data" i can set. I'll set that as the pointer to the instance which i'll then dereference in the callback
<RX14>
cool
<jokke>
oh
<jokke>
can't take pointerof(self)
<jokke>
:(
<RX14>
this = self
<RX14>
pointerof(this)
<RX14>
lel
<jokke>
oh!
<jokke>
lol
<jokke>
hmm
<jokke>
still no
<jokke>
can't take address of this
<RX14>
huh
<RX14>
weird
<RX14>
jokke, what is `self`
<RX14>
is it a struct?
<jokke>
a class
<jokke>
or a class instance
<jokke>
another thing: i know i can turn methods into procs by prepending with ->. This doesn't seem to work for methods of other classes like ->foo.bar.baz
<FromGitter>
<asterite> you can: x = foo.bar; ->x.baz
<FromGitter>
<asterite> just one single dot allowed there
<FromGitter>
<asterite> just a silly limitation
<jokke>
oh
<jokke>
wmoxam: box is very cool! much cleaner!
<wmoxam>
👍🏻
<crystal-gh>
[crystal] asterite pushed 1 new commit to master: https://git.io/vNUwf
<crystal-gh>
crystal/master 2b60437 Serdar Dogruyol: Remove LLVM update comments
<FromGitter>
<paulcsmith> Hmm, a few people are running into an issue that I can figure out: https://github.com/luckyframework/lucky_cli/issues/147 I've tried uninstalling and reinstall both lucky and crystal and both work for me on macOS. Has anyone seen that error before or have any ideas where to start?
<FromGitter>
<asterite> I saw that error yesterday while working on something
<FromGitter>
<asterite> I have no idea why it happened, though
<FromGitter>
<asterite> and I'm on mac
<RX14>
needs to get ex.backtrace printed
<RX14>
so it can be tracked down
<RX14>
i'm guessing it's some constant initialization
<FromGitter>
<asterite> it happens if you do something like `Process.run("foo qux", ["bar", "baz"], shell: true)`
<FromGitter>
<asterite> so there's a space in the command, plus commands, plus shell: true
<FromGitter>
<asterite> maybe it happens if there's a space in the path
<FromGitter>
<asterite> and you run a macro run
<FromGitter>
<asterite> or in the cache path... i don't know
<FromGitter>
<asterite> so it probably happens if the compiler/standard-library are installed in a path that has spaces
<RX14>
should be easy enough to find given a backtrace
<FromGitter>
<asterite> and you use stuff like ECR
<RX14>
and then we fix it
<FromGitter>
<asterite> which uses macro run with a file in that path, which will have spaces
<RX14>
hmm
<RX14>
shouldn't we just be quoting/escaping then?
<FromGitter>
<asterite> the ' ' check is probably wrong... the full executable...
<FromGitter>
<asterite> yes, that's what I was going to say
<RX14>
well actually
<FromGitter>
<tommyschaefer> Hi there! I decided to try Lucky out today and ran into this issue when running Lucky's `bin/setup` script in `/Users/tommyschaefer/Dropbox (Work)/code`, when I run it in `/Users/tommyschaefer` it works though
<RX14>
we need both
<FromGitter>
<asterite> we should put the full executable in double quotes, I guess
<FromGitter>
<asterite> well, there's a space in that path :)
<RX14>
if it's an executable you want quoting behaviour with shell: true
<RX14>
if it's a command sequence you don't
<FromGitter>
<tommyschaefer> Seems like the space in the path caused the issue for me, anyway :)
<RX14>
you actually want a Process.shell_escape
<RX14>
and then piece the command together yourself
<FromGitter>
<jwaldrip> @paulcsmith Did you ever get a change to see if Oak would work with lucky?
<FromGitter>
<bcardiff> @asterite did you already got the present from @jwaldrip ? Or I shall intercede ;-) I am at the office for a little longer. Not too much thou. Thanks @jwaldrip :-) !
<FromGitter>
<jwaldrip> @bcardiff I am asking Facundo now... he dropped offline.
<FromGitter>
<paulcsmith> @jwaldrip I did not. I've got a few other things I need to do first, but I'm definitely going to try it out when I get around to supporting globs in routes 👍
cyberarm has joined #crystal-lang
<FromGitter>
<jwaldrip> Cool. I have started on the next piece of Obsidian... probably going to be in the depths for a few more weeks on it.
<FromGitter>
<paulcsmith> Nice! I didn't notice you were creating a framework. What are your goals for it?
<FromGitter>
<jwaldrip> Good question... rails inspired but as modular as possible.
<FromGitter>
<jwaldrip> I couldnt find a router that I was pleased with, so I wrote Orion.
<FromGitter>
<jwaldrip> I like what I am seeing the the various ORM's but want to take a stab at one for obsidian as well.
<FromGitter>
<jwaldrip> like rails, a pluggable generators framework.
<livcd>
guys these names :-)...googlin crystal orion gave me pictures of tractor
<FromGitter>
<jwaldrip> Ditto, feel free to contribute. :-)
<RX14>
hah
<FromGitter>
<jwaldrip> I hope people will find it to be something worth using.
<RX14>
i have enough on my hands...
<FromGitter>
<jwaldrip> True
<RX14>
with crystal and university and loads of other stuff
<FromGitter>
<jwaldrip> Well one day you will graduate. :-)
<RX14>
hopefully
<FromGitter>
<jwaldrip> certainly
<RX14>
i could drop out if I get a really good job offer :)
<RX14>
unlikely though
<Vexatos>
ALERT ALERT
<Vexatos>
@jwaldrip I am compelled to notify you that obsidian is not a crystal but a glass
<FromGitter>
<jwaldrip> I know
<FromGitter>
<jwaldrip> it cools to quickly to crystalize
<FromGitter>
<jwaldrip> I just really like the name.
<FromGitter>
<jwaldrip> amber is also not a crystal
<Vexatos>
indeed
<livcd>
i like "nuumite"
<Vexatos>
It feels wrong
<Vexatos>
Nuummite looks really pretty
<Vexatos>
black minerals generally do
<livcd>
what about marmite Vexatos ?
<Vexatos>
That's not a mineral, and subjectively tastes worse than most
<Vexatos>
Although I haven't eaten many rocks lately
<FromGitter>
<jwaldrip> Does crystal have a defacto BDFL?
<RX14>
no
cyberarm has quit [Ping timeout: 264 seconds]
cyberarm has joined #crystal-lang
<FromGitter>
<bew> Ary was for a long time, by not anymore
rohitpaulk has joined #crystal-lang
<livcd>
nim c -r "/Users/mscasny/Documents/Test/hello.nim"
<livcd>
oops wrong copy paste
rohitpaulk has quit [Ping timeout: 248 seconds]
<ua_>
ban for shilling
cptaffe is now known as cptaffe1
<crystal-gh>
[crystal] asterite opened pull request #5543: Compiler: remove extra `shell` argument when executing macro run (master...bug/macro-run-extra-shell) https://git.io/vNU9N
<crystal-gh>
[crystal] asterite closed pull request #5542: Include UUID in docs (master...bug/5478-uuid-docs) https://git.io/vNUsp
<crystal-gh>
[crystal] Sija opened pull request #5545: Use (U)Int128 literals if possible (master...int-128-followup) https://git.io/vNUND
<FromGitter>
<marksiemers> @Vexatos - Amber and Obsidan aren't scientifically or molecularly crystals. They are crystals in the hippie world of "healing crystals" : http://www.universalonehealing.com/healing-resource/crystal-healing/crystal-list/ ⏎ Just like tomatoes are considered a fruit botanically, but considered a vegetable both legally (in the US) and culinarily.
rohitpaulk has joined #crystal-lang
<RX14>
mythology is hardly the spirit of crystal or computer science
<Vexatos>
That's like comparing astrology to astonomy :P
<Vexatos>
astronomy*
<jwaldrip>
lol
rohitpaulk has quit [Ping timeout: 260 seconds]
<FromGitter>
<marksiemers> Sure, I just think with shard names, if people stick to the strictest definition of crystals, we'll run out too quickly.
<RX14>
or just
<RX14>
be more creative than naming after a limited pool of "crystals"?
<crystal-gh>
[crystal] Sija opened pull request #5546: Remove TODOs related to Crystal 0.22 (master...remove-todos-after-crystal-0.22) https://git.io/vNUpm
<FromGitter>
<marksiemers> Starting with a list of names helps with one of the two hardest things in software development. ⏎ And sometimes it works out - "garnet-spec" was picked cause garnet is usually red but sometimes green. ⏎ That said, I agree, a little more creativity in naming would help a lot.
<FromGitter>
<jwaldrip> I named one of my Crystal project's Oak.
<FromGitter>
<jwaldrip> Because it's and implementation of a Radix Tree...
<FromGitter>
<marksiemers> @jwaldrip - Maybe people are afraid of the high expectations.
<FromGitter>
<marksiemers> It would be funny if you had a shard that hoarded lots of information (for some reason) and called it `diamond` or `debeers`
<FromGitter>
<jwaldrip> ;p;
<FromGitter>
<marksiemers> Have it allocate enough memory that your program has to use swap, so the cost of any processing is always artificially high.