<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 `x.to(y)`
[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> 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
<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>
<jwaldrip:matrix.org> 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``` [https://gitter.im/crystal-lang/crystal?at=61afcc0ab5ba9e5a11f6eac3]
<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: https://github.com/morecontainers/docker-state
<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>
<jwaldrip:matrix.org> 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>
<jrei:matrix.org> I concur: static linking on glibc will return a not fully statically linked binary
<FromGitter>
<jwaldrip:matrix.org> 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>
<jrei:matrix.org> 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>
<jrei:matrix.org> Yes. If libc6 got updated, chances are thr binary will no longer work
<FromGitter>
<jrei:matrix.org> 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>
<jrei:matrix.org> holst: if it's inside a `from scratch` container and it works, then why not
<FromGitter>
<jrei:matrix.org> 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>
<jrei:matrix.org> 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.