<FromGitter>
<jwaldrip> how can I get the scheme on the HTTP request?
<FromGitter>
<bararchy> @jwaldrip you mean http/https?
<FromGitter>
<jwaldrip> ues
<FromGitter>
<bararchy> Well, a request means you got a response, meaning you already know the scheme ? Am I missing something ?
<FromGitter>
<bararchy> Oh, nvm I don't think I really got what you are trying to do, can you explain a little ?
<FromGitter>
<johnjansen> @jwaldrip did you find the scheme in the request
<FromGitter>
<jwaldrip> I did not. If I am load balancing I may not know the scheme in the request... I need a way to tell if it is HTTP or HTTPS so I can tell how to redirect
<FromGitter>
<jwaldrip> there are some headers that clue me in if I am behind a lb, but if not how do I tell if the direct request was https?
<FromGitter>
<johnjansen> oh that old peach … i’ll poke about too
<FromGitter>
<johnjansen> any access to the raw request
<FromGitter>
<johnjansen> im assuming that an https request intercepted by a reverse proxy server and handled as http at our end will be a problem unless the proxy decorates the request
<FromGitter>
<johnjansen> i know ELB does this, but no idea about the *standard*
<FromGitter>
<johnjansen> you also might not have the correct host header
<FromGitter>
<johnjansen> not sure about that either
<Papierkorb_>
That's like closing your eyes and pretending an issue doesn't exist because you now don't see it
<RX14>
I actually agree
<RX14>
before I was going in the direction of runtime
<RX14>
but really people shouldn't touch platform specifics
<RX14>
and so it's best to just error
<Papierkorb_>
luislavena basically says it
<RX14>
at compile time
<RX14>
yeah
<Papierkorb_>
I'm all for stern warnings in docs. A `# @tag:Windows` thing would actually be kinda awesome for various things, which would make the generator emit a "badge"
<RX14>
well you can always just do build --no-codegen --target ,foo>
<Papierkorb_>
Or something like that, like doxygen allowing you to categorize functions.
<RX14>
and that gives you an instant check if you build on target x
<RX14>
for real
<RX14>
but it should be in the docs too of course
<Papierkorb_>
Sure but imagine you want to write a portable lib, look into the docs, and there's no clear mention of that. So you use something specific, and it blows up on windows. You may have chosen otherwise if the docs told you
<Papierkorb_>
Clearly docs don't replace a CI of sorts
Papierkorb_ has quit [Quit: Konversation terminated!]
<RX14>
darn
<RX14>
test.o : fatal error LNK1107: invalid or corrupt file: cannot read at 0x10AE0
<RX14>
which is fantastically helpful
<RX14>
oh why is LLVM giving me an ELF for x86_64-windows-msvc
<RX14>
huh
<RX14>
it NEEDS to be x86_64-pc-windows-msvc
<RX14>
til
<RX14>
so i'm up to the linker stage, yay
Creatornator has joined #crystal-lang
baweaver_away is now known as baweaver
Creatornator has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<RX14>
wohoo, just the pcre_ sumbols left
<RX14>
and all that takes is compiling pcre
<RX14>
I can't wait to watch it segfault
<FromGitter>
<achou11> Hi everyone! I’m new to Crystal and I’ve been going through the docs to understand the types. Can anyone explain why this gives a syntax error? ⏎ ⏎ ``` code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5a1eed1ccc1d527f6bce0e58]
<FromGitter>
<bew> `'Chou'` is definitely not a char
<FromGitter>
<achou11> @bew oh gosh haha that’s silly of me. not used to using a char type haha. Thanks!
<FromGitter>
<faustinoaq> > it prints hello world on windows ⏎ ⏎ Awesome 🎉
<FromGitter>
<faustinoaq> RX14 👍
<FromGitter>
<Rinkana> Awesome!
csk157 has joined #crystal-lang
<RX14>
a very basic windows support in master seems very doable
Creatornator has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<RX14>
possibly by christmas
<Papierkorb>
inb4 awful HO HO HO puns
<Papierkorb>
please someone do them
<RX14>
diff algorithms suck
<RX14>
at sourcecode
<Papierkorb>
oh boy, 0.24.0 breaks bindgen all around through API breakage. And I don't feel like "porting" it over before 0.24.1
<Papierkorb>
Any idea when that's gonna be?
<RX14>
no
<RX14>
manas don't seem to have time to do anything but :tada: my messages in slack lol
<Papierkorb>
🎉
<RX14>
yeah, it'd take me 5 minutes to type that on linux too
<FromGitter>
<bararchy> 🎉
<Papierkorb>
I just googled for the unicode char
<RX14>
lol yes me too
<oprypin>
@bmcginty, FYI Windows convo above
csk157 has quit [Ping timeout: 248 seconds]
<FromGitter>
<Rinkana> Man i hope 0.24.1 come soon tho, i need some things that are in 0.24.0
<RX14>
inb4 windows support in 0.24.1
<RX14>
I should really get the ball rolling on 0.24.1
<FromGitter>
<Rinkana> I'd rather have 0.24.1 now then wait for Windows support :p
<RX14>
yeah I was joking about 0.24.1 taking sooo long we have windows support in master by then
<oprypin>
funny...
<FromGitter>
<Rinkana> And i don't know what's the holdup now. 0.24 seems tested enough as there are nog big bug reports being made. And 0.24 has been released quite some time ago
<FromGitter>
<Rinkana> It will also fix the clusterfuck that is the current release (looking at you Arch)
<oprypin>
whats with arch
<RX14>
dont look at arch
<RX14>
it's us that didn't communicate properly
<oprypin>
make a release @@@ complain that people use a release
<FromGitter>
<Rinkana> But still, it's quite a mess
<oprypin>
is there any conversation to follow on 0.24.0 in arch linux?
<RX14>
no
<RX14>
congrats to windows for calling all of their crypto functions "bcrypt"
<RX14>
bonus points for not implementing bcrypt in bcrypt
<Papierkorb>
yes I saw it when I read the whole thing earlier
<RX14>
cool
<Papierkorb>
> gpg: keyserver timed out
<Papierkorb>
So not only does travis mark bindgen as failing cause the archlinux test fails due to 0.24, but the debians now whine about gpg
csk157 has joined #crystal-lang
csk157 has quit [Ping timeout: 240 seconds]
csk157 has joined #crystal-lang
<RX14>
nah thats just normal
<RX14>
gpg keyservers have less than 50% uptime
<RX14>
i swear
csk157 has quit [Ping timeout: 255 seconds]
<RX14>
i've never had a gpg keyserver work
<RX14>
when i want it to
csk157 has joined #crystal-lang
<FromGitter>
<watzon> Is there a flag to check the crystal version? I'm thinking some of these libraries that want to maintain some backwards compatibility with Crystal 0.23 may need to run a check at compile time to see which version is being used
<RX14>
yes there is but don't try to maintin multiple version compat
<RX14>
there's Crystal::VERSION
<Papierkorb>
watzon, you can also check only specific functions if that's enough
<FromGitter>
<watzon> I agree that trying to maintain backwards compatibility at this point is dumb
<Papierkorb>
I only do it if a future crystal version contains a fix/improvement I care about
faustinoaq has quit [Ping timeout: 248 seconds]
Creatornator has joined #crystal-lang
<RX14>
great, between my windows vm and firefox and goddamn emacs I don't have enough memory to compile crystal
<FromGitter>
<johnjansen> so @literal … @bar can be anything ???
<FromGitter>
<lhz> perhaps `getter bar : Hash(String, Set(Tuple(Int32, Int32)))?` is what you want?
<FromGitter>
<lhz> don't really see the point of setting nil as default parameter value and then overriding though, why not just `def initialize(@bar = Hash(...).new)`
alex`` has quit [Ping timeout: 258 seconds]
<FromGitter>
<lhz> and perhaps a type alias at the top of the class to shorten things.
<literal>
that's another approach, but I find it a bit unwieldy to have the type hints within the parentheses there, especially if there's more than one
<literal>
but yeah, an alias does make it shorter
<FromGitter>
<johnjansen> the question is this, can your code handle any type?
<Papierkorb>
having "nil" there isn't great if you actually meant "The empty thing is the default"
<literal>
I want it to always be non-nil, but the caller can optionally supply an initial value
<Papierkorb>
Then don't allow passing nil in
<FromGitter>
<johnjansen> and right now that could be any type at all
<FromGitter>
<johnjansen> ```Foo.new(Lumberjack.new) # and im ok```