ChanServ changed the topic of #crystal-lang to: The Crystal programming language | | Fund Crystal's development: | GH: | Docs: | Gitter:
ur5us has joined #crystal-lang
[R] has quit [Ping timeout: 256 seconds]
ur5us has quit [Ping timeout: 252 seconds]
<riza> since an iterator#next returns (T || Iterator::Stop) -- is there a pretty way to sanitize that Stop type out of the return values type?
<riza> or does it have to be a case statment
<riza> I'm having an awful time attempting to increment two iterators at once
<FromGitter> <Blacksmoke16> Case or if with is_a should do it
<riza> case fails me because I have two iterators I need to mutually advance
<riza> this is what I tried, anyway: case ; when a === stop || b === stop ; else ... end
<riza> I'm also noticing tonight that ranges can't be decreasing and I'm a little twinging at that too
<FromGitter> <Blacksmoke16> I'd just use the latter approach then
<riza> I think I'm just going to abandon iterators entirely and twiddle the bits myself
<riza> I was surprised about the decreasing range but that's what ruby does too so there must be some sort of reason
notzmv has quit [Ping timeout: 265 seconds]
[R] has joined #crystal-lang
ur5us has joined #crystal-lang
[R] has quit [Ping timeout: 265 seconds]
notzmv has joined #crystal-lang
ur5us has quit [Ping timeout: 265 seconds]
<FromGitter> <asterite> riza: maybe zip the iterators? ;-)
<FromGitter> <asterite> And for decreasing Iterator you can do ``
[R] has joined #crystal-lang
<xyhuvud> I have a small idea of what riza may be fiddling with :D
<FromGitter> <asterite> Haha, me too :-)
<xyhuvud> todays exercise was so easy and short the top list server crashed due to load :X
<FromGitter> <asterite> Really? That's great news. I guess I'll be streaming for just a few minutes then. I think Eric puts an easy exercise after a tough one (yesterday wasn't that hard, but you needed to think about a different way to represent things)
<FromGitter> <Dan-Do> I can I tell `crystal build` to use a single "header only" (.h without .c)?
<FromGitter> <Dan-Do> I made a `fake.c` ⏎ ⏎ ```# include "header.h"``` []
<FromGitter> <Dan-Do> But after compiled with `gcc -c ...` the object file removed two functions. Weird!
<riza> @asterite oh, great suggestion, thank you
zohran has joined #crystal-lang
zohran is now known as Fulgurance
Peter0x41 has joined #crystal-lang
Peter0x44 has quit [Ping timeout: 256 seconds]
Fulgurance has quit [Quit: Konversation terminated!]
taupiqueur has joined #crystal-lang
holst has joined #crystal-lang
<holst> I have a couple of observations: Crystal lang needs something that is taggable and searchable; crystal lang is not. crlang vs. #crlang is great ;-)
<holst> Also, I think the Goals of the project are non-orthogonal. In total 6 goals but they can be reduced down to at least 5 or even 4 if we accept the fact that OOP is not a goal in itself
<holst> Have anyone written a good JSON / microservice tutorial for crlang? I think I am struggling a lot with moving from say Python or Javascript to Crlang due to the parsing and typing requirements. I have been looking for some kind of best practice guide for this but I have not found one
<holst> do we really need to define the complete API response univerise in the client application just to "get some job done"? If so it puts a great barrier to writing small client apps that uses a big server API
<holst> case in mind: docker engine API
<holst> and kubernetes API
<straight-shoota> What do you mean with "complete API response univerise"?
<holst> the generated APIs are completely terrible, 100K LOC monsters
<straight-shoota> What generated APIs? Who generated them and why?
<holst> say you do docker inspect <container> there might be a lot of data in there which is mostly useles to the application that did the query.
<holst> straight-shoota: the generated APIs are by the project maintainers (obviously not generated for crystal)
<straight-shoota> I don't follow what your asking about
<straight-shoota> I believe you have assumed some implicit context, but it does not communicate
<holst> thats the complete output for a docker inspect
<straight-shoota> yes, I got that. Still don't know what your problem is
<holst> If I were to implement a complete class description for the entire response I would just not use crlang for that
<straight-shoota> y not?
<holst> Useless work. I do not have any need for the code that talks about the Network parameters say. So why would I write code for it
<FromGitter> <Blacksmoke16> could also just use `JSON.parse` ofc. then you have to deal with typing in a more painful to use way like `data.as_a[0].as_h["Id"].as_s` versus `data[0].id`
<holst> I would prefer if I could work with a dynamic type instead to at least dig myself down to the part that I am interested in
<FromGitter> <Blacksmoke16> fwiw you dont need to add properties and stuff for things you wont need
<straight-shoota> I don't know. But you stated as a premise that you wanted a complete class representation of that JSON data
<holst> I think that is the opposite of what I wanted
<holst> I questioned if that was the way to go in a typed language like crlang; or golang which has a generated API; that is typically what they do
<straight-shoota> You can go completely dynamic with JSON.parse as Blacksmoke16 mentioned. Or you use JSON::Serializable and only add mappings for the fields your interested about.
<holst> So you can have a "view" of a type and have the non-referenced fields just dropped?
<straight-shoota> Yes
<holst> Ok, I will try something out and ask for some feedback if you think its "best practice" style or not
<FromGitter> <Blacksmoke16> E.g. Also could be useful
<straight-shoota> This example is a bit more concise:
szutt has quit [Quit: Client closed]
taupiqueur has quit [Quit: taupiqueur]
ulyssa has quit [Remote host closed the connection]
ulyssa has joined #crystal-lang
ulyssa has quit [K-Lined]
<holst> be brutal ;-) I think the "allOk" logic can be fixed (and it should be "all_ok" I got confused on the coding style recommendation)
<straight-shoota> You need to set headers before writing the response body. As soon as you print something on the response, the headers get sent.
<straight-shoota> Any later response.status_code = ... or response.content_type = ... don't have any effect
ur5us has joined #crystal-lang
<straight-shoota> for allOk you can use states.all? {|_, state| state.running? }
notzmv has quit [Ping timeout: 240 seconds]
<FromGitter> <Blacksmoke16> `states.each_value.all? &.running?`
<straight-shoota> That's neither shorter nor more performant
<FromGitter> <Blacksmoke16> :shrug: reads better
<holst> Good stuff, now HttPie reads te output and pretty-prints it too :)
<FromGitter> <> I am trying to create a web socket proxy, what am i possible doing wrong here? I get an upgrade back from the handler, but then the connection closes and nothing is passed. ⏎ ⏎ ```code paste, see link``` []
<holst> Thanks guys. If anyone of you are using Docker Engine for some workloads, this might be interesting for you to use as uptime probe:
<FromGitter> <Blacksmoke16> It's prob not actually going to be static given its being compiled in ubuntu
<FromGitter> <Blacksmoke16> also prob want `--release` flag
<holst> the static linking worked
<holst> because the production image is empty, just the binary copied in from the build
<holst> (and the resulting image works)
<holst> I will look into the --release flag
<holst> isn't --production implying --release?
<FromGitter> <Blacksmoke16> if you run like `ldd binary` within the container what does it say?
<FromGitter> <Blacksmoke16> > --production same as `--frozen --without-development`
<straight-shoota> shards --production only applies to dependency resolution. It does not affect the build process
<FromGitter> <Blacksmoke16> related:
<holst> not a dynamic executable
<holst> so --static worked
<FromGitter> <Blacksmoke16> interesting
<holst> the binary became somewhat smaller
<holst> -rwxr-xr-x. 1 om om 8594912 7 dec 22.28 /tmp/docker-state
<holst> still 8,5 MB so not tiny by any means :)
<FromGitter> <Blacksmoke16> `--no-debug` might help
<SamantazFox_> do you know how I can diagnose that?
<SamantazFox_> the instance runs fine for hours, until it suddently opens many sockets and fills the log of `ERROR - http.server: Error while connecting a new socket`, `accept: Too many open files (Socket::Error)`
<holst> -rwxr-xr-x. 1 om om 7125936 7 dec 22.47 /tmp/docker-state
<holst> another 1,5 MB shaved thanks
<SamantazFox_> holst: do pass the `-h` flag to `ls`, that makes the filesize human readable!
<holst> SamantazFox_: I actually usually do. I do not know why I did not this time. :)
<FromGitter> <> Re websockets above, it seems as though the response is not being upgraded. Any ideas?
<straight-shoota> Statically linking against glibc is discouraged. Please don't do that. If you want a statically linked binary, try musl instead.
<FromGitter> <Blacksmoke16> oh wait, you *can* statically link against it? i was always under the assumption it just didnt actually statically link versus it does but just isnt advised
<holst> does the crystal-lang container environment ship in alpine? then it would be a trivial thing to change the backend tooling
<holst> I think alpine uses musl my memory isn't great these days though
<holst> it really does not matter which build system I use for the production container as long as the binary itself is statically linked :)
<FromGitter> <> I concur: static linking on glibc will return a not fully statically linked binary
<FromGitter> <Blacksmoke16> `crystal-alpine:1.2.2` iirc
<holst> then maybe crystal-lang/crystal:1.2.2 isn't using ubuntu/glibc tooling?
<FromGitter> <> Yes Alpine uses musl
<holst> becaues I obviously got a statically linked binary. it might be lying to me and do the linking in code?
<straight-shoota> Yeah, it technically works. If you have a libc.a available. But glibc is not meant to be statically linked.
<straight-shoota> holst, you're already using the alpine image for development stage
<holst> thts just because apt is so slow
<FromGitter> <> hoist: take a look at
<FromGitter> <> We use this to build a statically linked binary
<straight-shoota> No, the binary is statically linked. It just does not have everything in it that libc uses, because it loads some parts dynamically at runtime.
<holst> "because it loads some parts dynamically at runtime" .. I vaugely remember that. So bascially its something that will blow up when I discover the code path that trigger the dynamic load?
<FromGitter> <> Yep, I tried it recently and after couples of updates the binary was no longer working
<straight-shoota> Not necessarily immediately. But it may cause latent issues.
<holst> "couple of updates"? of the core OS? @jrei
<straight-shoota> I'm wondering if the compiler should refuse `--static` with a `-gnu` target. Or at least issue warning.
<SamantazFox_> also, using a binary linked for musl on a glibc machine (or vice versa) is looking for trouble
<FromGitter> <> Yes. If libc6 got updated, chances are thr binary will no longer work
<FromGitter> <> Or maybe that's because of another one, not sure
<holst> well then you already had a trigger of the dyamic parts, the app I wrote here would blow up immediately because the container environment does not have any additional files, at all
<straight-shoota> jrei that sounds reasonable. Statically linked libc loads components at runtime, but the shared lib has a different version so it's prone to be incompatible
<SamantazFox_> straight-shoota: or maybe make --static link everything but libc static?
<holst> the executable size went up 2x to 15MB :(
<FromGitter> <> holst: if it's inside a `from scratch` container and it works, then why not
<FromGitter> <> I doubt it will work because the binary is not fully static
<FromGitter> <Blacksmoke16> may have trouble with ssl in scratch container due to missing certs fwiw
<holst> @jrei it does work. I have tested it here all night :)
<holst> but I will stick with the -alpine for prod builds as well
<FromGitter> <> Why not then. I can only see disadvantages over statically linking in Alpinr though
<holst> The compressed image is ~5MB so I find it unlikely that anyone would care these days. Nvidias deep learning images are usually 5+ GB in size and if people find that acceptable.... im sure 5 MB is ok
<straight-shoota> SamantazFox_ but the USP of --static is that you get a completely portable executable with no binary depdendencies
<holst> which is great. Dependency mgmt is a pita. thats why I am using docker to begin with
<straight-shoota> You're kinda doubling up on that, though
<holst> I was using another set of compile options before
<straight-shoota> Docker gives you a controlled environment, so you technically don't need a static build when you can control the dependencies
<holst> RUN shards build --production --static --no-debug --release -s -t
<SamantazFox_> the huge problem of static linking is that you become responsible of updating *all* the libraries your executable depends on.
<holst> ok, -s stats and -t time
<straight-shoota> yeah, that's the trade-off
<holst> I like my changes to have a single point of entry
<holst> the artifacts deployed comes from a git repo at its source. not through git + deployment dependent apt update .. :)
<straight-shoota> But that's also a benefit: you *can* update them easily independently. Updates are not hold back because other components of your environment are incompatible.
<SamantazFox_> true
<holst> which is why enterprises love RHEL they are the only company that will support a Linux 2.6 kernel still ;-)
<holst> (I have no idea if RHEL actually supports 2.6 as of today)
<holst> I think DOS did not have a concept of dynamic runtime libraries. Maybe it was never a good idea to begin with. Just a resource conservation thing. You had so little memory so you had to share code between programs; an argument that does not make sense in DOS (because there is just one application running); and *nix is almost by definition a multi-user/multi process environment
<holst> most things in Unix were hacked together with small single purpose tools as well, so re-using the file I/O malloc etc, all libc features, probably made a lot of sense
<holst> for a micro service app, I think a statically linked app makes much more sense. At least for me
notzmv has joined #crystal-lang
<holst> side note (back on topic): It would be great if the HTTP server library warned in development mode if I am trying to set header fields after they already have been sent out
<holst> if the context itself can keep track of these things. I also do not know how a hook could be inserted easilly to track changes like that. But it would be a good thing to avoid easily made errors
<holst> (I had another one of those bugs; fixed now)
<holst> good idea @repomaa ;)
<SamantazFox_> <holst> "for a micro service app, I think a statically linked app makes much more sense" <- I'd say the opposite. Especially nowadays with openSSL being used everywhere, I'd preferably not end up with security bugs in my app.
ur5us has quit [Ping timeout: 252 seconds]