FromGitter has quit [Read error: Connection reset by peer]
FromGitter has joined #crystal-lang
FromGitter has quit [Remote host closed the connection]
FromGitter has joined #crystal-lang
<FromGitter>
<Blacksmoke16> ah gotcha, i always saw that but wasn't sure what it was for
FromGitter has quit [Read error: Connection reset by peer]
FromGitter has joined #crystal-lang
ur5us has quit [Ping timeout: 260 seconds]
FromGitter has quit [Remote host closed the connection]
FromGitter has joined #crystal-lang
<FromGitter>
<Blacksmoke16> if im serializing an object using `String.build` would this be a worthwhile optimization? `String.build(instance_sizeof(typeof(data)))`
<FromGitter>
<Blacksmoke16> er the size of an object prob doesnt map to the size of the string
<FromGitter>
<nothratal> yesterday evening I asked about extending a struct for learning purposes. I tried everything but I can't figure it out. ⏎ as an example: ⏎ ⏎ ```x = "123" ⏎ y = 44 ⏎ puts x+y ⏎ puts y+x``` ⏎ ... [https://gitter.im/crystal-lang/crystal?at=5e21a5a63ea53f0f663c5791]
ht_ has joined #crystal-lang
<FromGitter>
<straight-shoota> @Nicolab You can just write to `crystal eval`'s stdin if you don't provide any arguments.
<FromGitter>
<straight-shoota> Or no source argument, to be precise
<FromGitter>
<Nicolab> @straight-shoota Ah ok
<FromGitter>
<Nicolab> @straight-shoota how do you end the multi line so that it runs?
<FromGitter>
<straight-shoota> Just close stdin.
<FromGitter>
<straight-shoota> Depends on you terminal, but usually `Ctrl+D`
<repo>
on that note? is it just me or is crystal playground waaaaay slower than it used to be?
<FromGitter>
<nothratal> @tenebrousedge ⏎ I tried nearly everything...after comparing it in my editor with your solution it becomes totally obvious. I wrote it in multiple lines and put it inside a module block, so of course it was out of scope. I'm not sure what my reason was to try it this way, I would like to refer to the late time yesterday :P
<FromGitter>
<tenebrousedge> multiple lines doesn't make a difference, it's just quicker and easier in icr
<FromGitter>
<tenebrousedge> but the module thing is definitely an issue
<FromGitter>
<nothratal> @tenebrousedge thats true, but putting it inside a module block does:
<FromGitter>
<tenebrousedge> you may want to have a saner implementation than just `to_i`
<FromGitter>
<tenebrousedge> it's pretty easy to get bigger than a 32-bit int in a string
<FromGitter>
<nothratal> true, right now my checks are limited to blank strings and strings only containing "0"
woodruffw has quit [Ping timeout: 258 seconds]
<FromGitter>
<Nicolab> @nothratal Beware of spaces
<FromGitter>
<Nicolab> `" 0 "`
<FromGitter>
<Nicolab> `" 0 ".strip`
HumanGeek has joined #crystal-lang
woodruffw has joined #crystal-lang
Human_G33k has quit [Ping timeout: 268 seconds]
duane has joined #crystal-lang
woodruffw has quit [Ping timeout: 258 seconds]
<FromGitter>
<tenebrousedge> probably best to do `delete("^0-9.")`
<FromGitter>
<tenebrousedge> or `,` if you're locale-aware
<FromGitter>
<nothratal> ```" 0 ".to_i ``` is also 0
<FromGitter>
<tenebrousedge> `"1 0".to_i` is splodey
woodruffw has joined #crystal-lang
<FromGitter>
<christopherzimmerman> Is there a way to avoid union types when calling `map` on a tuple? This seems odd to me: ⏎ ⏎ ``` code paste, see link``` ⏎ ⏎ Shouldn't the compiler know what type is present at least element of the tuple? [https://gitter.im/crystal-lang/crystal?at=5e21bfab000f497899118fab]
<FromGitter>
<tenebrousedge> you could probably also write some sort of macro
<FromGitter>
<christopherzimmerman> Yea, I was hoping I could do: `t1.as(typeof(t))`, since the types will always be the same, but still get the union. I don't think there will be a great way to handle this for `*args`, which is the actual use case.
<FromGitter>
<christopherzimmerman> I think a macro is probably the easiest option for now.
<FromGitter>
<tenebrousedge> I wonder...
<FromGitter>
<DRVTiny> Hello everybody! ⏎ Is there simple way to send output and error streams of process forked by Process.new to the same file descriptor? ⏎ I need to read this output line-by-line and send to websocket. I dont know, how to read it properly It it will be 2 file descriptors (1 for output and 1 for error) instead of 1.
<repo>
i have a question about request bodies: there's the Accept: 100-continue header which is correctly used by crystal to determine if it should send a 100 Continue response before reading the body. What is the correct procedure to _not_ send a Continue. e.g. if auth fails or some other reasons without breaking clients that don't send Accept: 100-continue. If i just close the body i will break
<repo>
client's not supporting the continue response (e.g. crystal's built in http client)
<repo>
i'm asking because i'm handling potentially very large file uploads
<repo>
i can do body.skip_to_end, but this will also send a Continue response to clients that support it, thus having them upload the whole body
<repo>
maybe i should just manually check the header and close the body if 100-continue is there and otherwise skip to end
<FromGitter>
<tenebrousedge> hmmm
<repo>
would also be kinda cool if the built in http client would support continue
<FromGitter>
<Blacksmoke16> be nice if the built in http client supported a lot of things :p
<FromGitter>
<straight-shoota> repo, if you don't want to receive a large upload body and the client has not signaled support for continue headers, the best solution is probably to just close the connection.
<FromGitter>
<straight-shoota> Or rather, try sending a response header first and then close the connection
<FromGitter>
<DRVTiny> I have yet-another problem with Process.new ⏎ https://github.com/crystal-lang/crystal/blob/41bd18fbea4aec50aad33aa3beb7a0bf30544186/src/process.cr#L127 ⏎ There is no some code closing all file descriptors except input (0), output (1) and error (2) ⏎ So my process created by Process.new receives TCP/IP socket opened by HTTP::Server. ⏎ Say, if forked/execed process is "bash -c " - bash will listen on
<FromGitter>
<DRVTiny> Problem: process "p" inherits TCP/IP soket
<FromGitter>
<grkek> and what is the problem in that
<FromGitter>
<grkek> How is that even possible ?
<FromGitter>
<grkek> it shouldnt be inheriting anything but the args you give it to inherit or access
<FromGitter>
<grkek> is Process a handler ?
<FromGitter>
<grkek> I am very confused here
<FromGitter>
<grkek> if yes rename it to something like ProcessHandler
<FromGitter>
<DRVTiny> I started bash with long loop and see in lsof -iTCP:3000 -sTCP:LISTEN that bash listens on the socket too ⏎ When i send request to my Kemal application - this request can be sended to bash, but bash cant respond :)
HumanGeek has quit [Quit: Leaving]
<FromGitter>
<grkek> You need to wait for the stdout
<FromGitter>
<grkek> probably that is the problem
<FromGitter>
<grkek> You start a process with commands and just leave it
<FromGitter>
<grkek> and then return a result json
<FromGitter>
<DRVTiny> Yes. Process generates for me some lines of output that i send over websocket to frontend
<FromGitter>
<DRVTiny> My process is tower-cli job monitor JOB_ID :)
<FromGitter>
<grkek> and your process inherits the socket created by kemal ?
<FromGitter>
<DRVTiny> I need to be possible to start ansible/awx task and then control its output in web console
<FromGitter>
<DRVTiny> @grkek Yes!
<FromGitter>
<grkek> How did you find that out ? I mean how did you got to the point where yeah my process inherits kemal socket
<FromGitter>
<grkek> Can you show me the source code of Process class
<FromGitter>
<grkek> is it the stdlib class or is it yours
<FromGitter>
<grkek> @Blacksmoke16 can you help me out here I am a bit confused
<FromGitter>
<grkek> @straight-shoota same goes to you haha
<FromGitter>
<grkek> is this how the process class works I didnt know that it could inherit other classes for no apparent reason
alexherbo24 has joined #crystal-lang
<FromGitter>
<grkek> Okay, what seems to be the error you are up against what does the compiler tell you
<FromGitter>
<grkek> ?
<FromGitter>
<DRVTiny> This is not mechanic of Crystal itself, this is system-level one: forked process uses the same set of file descriptors as its parent process
<FromGitter>
<grkek> Oh yeah the socket is treated as a file descriptor I think
<FromGitter>
<grkek> hm
<FromGitter>
<grkek> this is an interesting issue
<FromGitter>
<DRVTiny> So we have to close unneeded file descriptors when forks - in the child process
alexherbo2 has quit [Ping timeout: 260 seconds]
alexherbo24 is now known as alexherbo2
<FromGitter>
<DRVTiny> But i dont know where Crystal did it?
<FromGitter>
<grkek> That is a question for the core devs
alex`` has quit [Ping timeout: 268 seconds]
<FromGitter>
<grkek> I am relatively new to crystal myself
<FromGitter>
<DRVTiny> Thank you, @grkek ! ⏎ Do you know how to cast core developers here? :)
<FromGitter>
<grkek> @RX14 core dev
alex`` has joined #crystal-lang
<FromGitter>
<grkek> as much as I know there are coredevs in this group
<Stephie>
sorry, i don't have time to read the backlog, but i'd suggest avoiding fork
<Stephie>
it will be removed from crystal entirely before long
<Stephie>
it'll never be supported on windows, and is unlikely to be supported after multithreading is enabled
<FromGitter>
<grkek> Oh rip
<Stephie>
there's plenty of literature online on alternative ways to do things
<Stephie>
if you need help, i think someone else will be around to help
<FromGitter>
<grkek> See the difference between unexperienced crystal dev and an experienced one 😆
<Stephie>
wait, are you using fork or Process.new
<Stephie>
using Process.new shouldn't inherit file descriptors
<FromGitter>
<DRVTiny> But... how to start another process and not wait for that process from Crystal if not using Process.new specialy intended for this? ⏎ For examples, perl emulates fork() on Windows.
<FromGitter>
<grkek> > <Stephie> using Process.new shouldn't inherit file descriptors
<FromGitter>
<grkek> this is what I said and got confused as well
<Stephie>
i mean, really every file descriptor should have close_on_exec set by defaulty
<Stephie>
but i don't think that's the case right now...
<FromGitter>
<DRVTiny> Where in the Process class can i see that unnecessary file desriptors are closing by crystal stdlib somehow?
<Stephie>
hmm, you might be right about shoddy CLOEXEC behaviour here
<Stephie>
@DRVTiny the problem is that the way this should be done is setting fd.close_on_exec = true in the appropriate places
<Stephie>
it's not done in the fork
<FromGitter>
<DRVTiny> > i mean, really every file descriptor should have close_on_exec set by defaulty ⏎ Understood. So it is very strange that my bash process inherits socket created by HTTP::Server ⏎ I see it using lsof, for example
HumanG33k has joined #crystal-lang
<Stephie>
okay, well, shit
<Stephie>
the code which sets SOCK_CLOEXEC has been lost over the years
<Stephie>
this is a bug
<Stephie>
thank you
<Stephie>
please report it to the issue tracker
<FromGitter>
<grkek> Great catch
<FromGitter>
<grkek> thank you
<FromGitter>
<DRVTiny> Thats no no problem :) ⏎ Ok, i'll try to monkey-patch this somewhere in HTTP::Server or around
<Stephie>
so, accept() and socket() need to be fixed to always pass CLOEXEC
HumanG33k has quit [Remote host closed the connection]
woodruffw has joined #crystal-lang
<Stephie>
there's code for setting O_CLOEXEC on the fd when the platform *doesn't* support SOCK_CLOEXEC
HumanG33k has joined #crystal-lang
<Stephie>
but the code which actually passes SOCK_CLOEXEC has been lost
<Stephie>
thanks a lot!
<Stephie>
sorry for starting off with the wrong impression
return0e_ has quit [Ping timeout: 258 seconds]
<Stephie>
you shouldn't use Process.fork manually from crystal code
<Stephie>
but of course the stdlib uses fork to create new processes
<FromGitter>
<DRVTiny> Process.new is very comfortable for me, so i dont need to call fork() directly :))
JuanMiguel has quit [Quit: This computer has gone to sleep]
JuanMiguel has joined #crystal-lang
JuanMiguel has quit [Quit: This computer has gone to sleep]
JuanMiguel has joined #crystal-lang
Nicolab has quit [Quit: Leaving.]
Nicolab has joined #crystal-lang
JuanMiguel has quit [Quit: This computer has gone to sleep]
ht_ has quit [Quit: ht_]
<Stephie>
@DRVTiny thanks
<Stephie>
fuck snapcraft, honestly
<Stephie>
it's literally xkcd 927 but the new standard is worse and more complex
<FromGitter>
<dscottboggs_gitlab> ☝️ ayup
<FromGitter>
<dscottboggs_gitlab> seriously canonical could've thrown their weight behind something flatpak or docker based and it would've made things better for everyone
<FromGitter>
<dscottboggs_gitlab> NIH to the max
<Stephie>
flatpak sucks for the same reason
<Stephie>
at least docker is trying to solve a different problem
<Stephie>
though it does it badly and the messaging is all wrong
<FromGitter>
<dscottboggs_gitlab> yeah I never got why you don't just use docker for all of it
<FromGitter>
<dscottboggs_gitlab> > trying to solve a different problem ⏎ ⏎ what do you mean?
<Stephie>
no you use your distro's package manager for applications and toold
<FromGitter>
<dscottboggs_gitlab> well, I mean, yes, but there's also a few arguments in favor of sandboxing
<FromGitter>
<tenebrousedge> the idea of using docker for all the things turns my stomach. LXC would be one thing
<Stephie>
snaps are just trying to work around the distros
<Stephie>
instead of with them
<FromGitter>
<dscottboggs_gitlab> and licensing!
<FromGitter>
<tenebrousedge> well, there are upteen hundred distros; no one wants to work with them all
<FromGitter>
<dscottboggs_gitlab> True
<Stephie>
you don't work with them though
<Stephie>
you just make your software easy to package
<Stephie>
and the distros do the entire rest of the work
<FromGitter>
<dscottboggs_gitlab> or follow FreeDesktop standards...?
<FromGitter>
<tenebrousedge> unless you don't want to distribute your software on your distro's terms
<Stephie>
it's just "have competent build instructions available" mostly
<FromGitter>
<tenebrousedge> saying "there will be no commercial software on Linux" is nice for some people
<FromGitter>
<tenebrousedge> but I'm a bigger fan of pragmatism than purity
<FromGitter>
<dscottboggs_gitlab> > have competent build instructions available ⏎ ⏎ harder than you might think... haha
<Stephie>
i didnt even think of commercial software
<Stephie>
but i guess it makes sense for them
<FromGitter>
<tenebrousedge> Steam, e.g.
<Stephie>
i'd rather OSS projects avoided that though
<FromGitter>
<tenebrousedge> sure
<FromGitter>
<dscottboggs_gitlab> I don't find limiting collaboration opporunities "pragmatic" but I also get your point, steam and a few stragglers are useful
<Stephie>
i just find the contempt with which some developers treat distro packagers infuriating
<Stephie>
like, refusing to accept bugs unless you're running their snap/flatpak/appimage
<FromGitter>
<dscottboggs_gitlab> oh? I haven't really heard of this
<Stephie>
i saw it once
<Stephie>
i won't say it's common but i'd rather people worked with distro packagers rather than around them
<FromGitter>
<dscottboggs_gitlab> true, but I'd rather we had a standardized way of packaging software
<Stephie>
ELF files?
<FromGitter>
<dscottboggs_gitlab> something along the lines of `Dockerfile`s or arch/alpine pkg configs
<FromGitter>
<tenebrousedge> what about Nix/NixOS ?
Nicolab has quit [Quit: Leaving.]
blueberrypie has quit [Quit: leaving]
blueberrypie has joined #crystal-lang
<FromGitter>
<straight-shoota> Honestly, there doesn't need to be a standard. Different use cases require different measures and you can't have one size fits all.
<FromGitter>
<straight-shoota> It's okay to use different packaging mechanisms, as long as the software is easy enough to package
<FromGitter>
<mavu> One often forgotten thing is that tools exist to convert between or install "alien" packages on most distros.
<FromGitter>
<mavu> i.e. installing rpm on debian
<FromGitter>
<mavu> People often say "but I dont want to provide packages of my software for 100 different distributions"! ⏎ But in fact they could cover 98% of linux installations with 2 different packages and endusers can convert it to install on their system.
<FromGitter>
<mavu> (Yes, I also dislike docker as software installer, and snap & co.)
<FromGitter>
<mavu> But if using those things makes people happy... *shrug*