<FromGitter>
<bew> it's just that assigning a var to itself is completely useless
faustinoaq has quit [Ping timeout: 255 seconds]
<FromGitter>
<exts> that's a named parameter no?
<FromGitter>
<bew> = is for assignation
<FromGitter>
<exts> so how do name parameters work in crystal?
<FromGitter>
<bew> did you see the fixed example from @elorest ?
<FromGitter>
<bew> or simply, did you read the docs about it?
<FromGitter>
<exts> ah I missed that link
<FromGitter>
<exts> thanks
<FromGitter>
<elorest> 👍
<FromGitter>
<exts> ah I know why I wrote it like that, was messing with nim earlier this week :)
<FromGitter>
<exts> sorry about the confusion, sometimes my brain gets stuck in another language
faustinoaq has joined #crystal-lang
<FromGitter>
<Qwerp-Derp> What does this mean? `GC Warning: Finalization cycle involving 0x106f8db80`
<FromGitter>
<Qwerp-Derp> I'm pretty sure there's a problem with the garbage collection removing objects from the heap, but I have no idea what the object is so I can't get rid of the warning
<FromGitter>
<Qwerp-Derp> Has anyone else received a `GC Warning: Finalization cycle involving XX` in their Crystal programs? I'm not sure what exactly my issue is, I can't seem to minimise it or track it down.
<FromGitter>
<Qwerp-Derp> I'm fairly certain it's to do with a class with itself as a variable, but I'm not 100% sure.
<crystal-gh>
crystal/master 7f276fd Johannes Müller: fix typo (#5300)
hightower2 has joined #crystal-lang
<oprypin>
Papierkorb, let me ask this: you see 1000 thumbs up on a facebook message. if all those were comments saying "i like this" instead, would it improve the situation in any way?
faustinoaq has quit [Read error: Connection reset by peer]
faustinoaq has joined #crystal-lang
faustinoaq has quit [Quit: Konversation terminated!]
faustinoaq has joined #crystal-lang
faustinoaq has quit [Read error: Connection reset by peer]
faustinoaq has joined #crystal-lang
faustinoaq has quit [Client Quit]
faustinoaq has joined #crystal-lang
faustinoaq has quit [Client Quit]
faustinoaq has joined #crystal-lang
faustinoaq has quit [Client Quit]
faustinoaq has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 240 seconds]
badeball has joined #crystal-lang
badeball has quit [Client Quit]
badeball has joined #crystal-lang
badeball has quit [Client Quit]
badeball has joined #crystal-lang
hightower3 has joined #crystal-lang
hightower4 has quit [Ping timeout: 240 seconds]
sz0 has joined #crystal-lang
rohitpaulk has joined #crystal-lang
<Papierkorb>
oprypin: The system is fucked. People put way too much emphasis on a random number on their screen. Spamming "thanks" doesn't help for sure, but that system does no good psychologically either.
<robacarp>
I'm running into a weird situation where my crystal will not run in a docker container, but runs fine on my mac. I've simplified the code greatly in an effort to isolate the example here: https://github.com/robacarp/minimal_socket
<robacarp>
the failure in docker is : failed to create socket:: Permission denied (Errno)
<robacarp>
I'm first curious if this is a mac v ubuntu problem, because I believe the docker machine runs ubuntu on mac
<RX14>
lol
<RX14>
so you need to run it as root
<Papierkorb>
`ping` has a capability allowing it to
<RX14>
if you strace `ping` it does the same thing
<RX14>
looks like ping is setuid basically
<Papierkorb>
> /usr/bin/ping = cap_net_raw+ep
<Papierkorb>
That capability is required for a non-root process to open raw IP packets, what is what robacarp is basically doing
<Papierkorb>
robacarp: You'll want to give that capability to your docker container. There's something for it
<Papierkorb>
No, the process doesn't need root
<Papierkorb>
That's the point of capabilities
<RX14>
yes you don't need to
<RX14>
but i'm too lazy to give other advice
<robacarp>
the socket isn't a raw socket, which does require root. it's dgram, so the program runs fine without root outside of docker
<Papierkorb>
> Socket::Protocol::ICMP
<Papierkorb>
May be a restricted type
<RX14>
it is
<Papierkorb>
docker has had an option to tune container capabilities for some time now, but I don't have docker here, so no idea how it goes
<RX14>
well ping inside docker works
<Papierkorb>
it has the capa there too
<RX14>
so the container root gains the cap_net_raw cap
<RX14>
yes
<RX14>
you can just run as root or use setap on the binary
<RX14>
setcap*
<robacarp>
okay, I'm not familiar enough with setcap to know what you're saying yet, but I'll read up and see where it takes me. thanks
<Papierkorb>
as I said, docker has options for that.
<robacarp>
in that I need to set it for the running container? or for the binary within it?
<Papierkorb>
the docker command.
<Papierkorb>
I already said I don't have docker here.
<Papierkorb>
RX14: don't see any monkeypatches in there
<RX14>
yeah but looking at the repo name...
<RX14>
they're surely coming
<RX14>
if it's a big enoguh method to make a shard then make it a shard, it doesn't belong in a misc collection of methods anyway
<Papierkorb>
I'd actually like refinements (or a better solution if someone knows of one) lul
<Papierkorb>
The ease of use of monkey patches, without messing everything up. keeps code clean and OOP-y.
<RX14>
perhaps
<RX14>
i wouldn't mind them
faustinoaq has quit [Quit: IRC client terminated!]
faustinoaq has joined #crystal-lang
<FromGitter>
<paulcsmith> @RX14 and @Papierkorb Just because it's called support doesn't mean it is ActiveSupport
<FromGitter>
<paulcsmith> It does not monkey patch any classes
<RX14>
yeah I saw
<FromGitter>
<paulcsmith> It is an inflector now, but I'm planning to add a few more things to it, like NumberHelpers and TimeHelpers for doing things like number_to_currency
<FromGitter>
<paulcsmith> I may split it up later
<RX14>
hmm
<RX14>
whats the downbside of just making those shards when the come up
<Papierkorb>
temporary solutions are for eternity
<RX14>
and then depending on them all
<RX14>
Papierkorb, +1
<RX14>
do it right as well as you can first try
<FromGitter>
<paulcsmith> You two may like that, which is fine. I prefer splitting things up later. Those things often go together in tandem and I don't want to create a new shard for every helper Lucky ever needs
<FromGitter>
<paulcsmith> Then it leads to node zone where you have tiny packages for everything
<FromGitter>
<paulcsmith> LuckySupport will eventually have NumberHelpers, CurrencyHelpers, etc. I *might* split them up *if* people want those individual packages, but until then it would just add unnecessary overhead.
<RX14>
I never really understood the downsides of tiny packages for everything
<FromGitter>
<paulcsmith> It's not hard to split things up later. I've already done it with various parts of Lucky when they warranted it
<FromGitter>
<paulcsmith> For me I just don't like that I have to hop between lots of different API docs, and it's also easier to maintain (sometimes)
<FromGitter>
<paulcsmith> Depends on a lot of things though, and personal preference I think
<FromGitter>
<paulcsmith> Basically I don't think one approach is clearly better/worse. I think it depends on personal preference, how one likes to manage projects, and whether people even want to use individual parts. Maybe that's just me
<Papierkorb>
the issue to me isn't that the shard could get big. it's that it implies to be a dump for things that didn't fit somewhere else.
<Papierkorb>
E.g., having a `helpers` and a `inflector` shard wouldn't create a billion shards (no one needs a leftpad.cr), but it would be a reasonable split of concerns
saadq has quit [Ping timeout: 240 seconds]
<FromGitter>
<paulcsmith> Yeah that might be true. I could see inflector and helpers being separate
<FromGitter>
<paulcsmith> That's probably a good idea
saadq has joined #crystal-lang
<RX14>
I feel you about the API docs
<RX14>
we have an official API doc tool
<RX14>
I think we should have a mode which opens the API docs of literally everything that's in the require path
<Papierkorb>
The server feature of yard, where it serves all api docs of all gems of a project is glorious
<RX14>
basically that Papierkorb
<FromGitter>
<paulcsmith> I do like the helpers/support split. I just didn't want to have time_helpers and number_helpers, and...etc.
<Papierkorb>
Helper::Time.foo() sounds reasonable to me in terms of usage and programmer convenience
<FromGitter>
<paulcsmith> And yeah that would be cool. It's on of the issues I had with Elixir/Phoenix. I often wouldn't know in which package a method was defined so it got to be frustrating
<RX14>
but really
<RX14>
it's an inflector
<RX14>
thats really generic
<RX14>
lots of people want an inflector that's not part of lucky
<RX14>
or who wants to use all the other crap
<FromGitter>
<paulcsmith> Yeah. I just renamed it
<Papierkorb>
paulcsmith, is that thing to stay english-only?
<FromGitter>
<paulcsmith> I agree on the helpers/inflector split
<Papierkorb>
maybe EnglishInflector is better in that case
<FromGitter>
<paulcsmith> @Papierkorb Right now yeah
<Papierkorb>
I mean it's fine for it to be english-only, just that in the future, I may want to add a German inflector too, but don't want to stop using the english one
<Papierkorb>
in a project I mean
<FromGitter>
<paulcsmith> Ah I see what you mean. I'll have to think about that
saadq has quit [Ping timeout: 268 seconds]
<FromGitter>
<paulcsmith> Well you can add additional inflectors at runtime so it already can support other languages. But yeah I'll have to think about that a bit more
saadq has joined #crystal-lang
<robacarp>
bah, even disabling apparmor and seccomp I still get permission denied
astronavt has joined #crystal-lang
<FromGitter>
<unreadable> is sdl2 better in terms of cpu usage than sdl2?
<FromGitter>
<unreadable> than sfml***
DTZUZO has quit [Ping timeout: 248 seconds]
faustinoaq has quit [Quit: IRC client terminated!]
astronavt has quit [Quit: Leaving...]
faustinoaq has joined #crystal-lang
<FromGitter>
<bew> no idea, iirc one is a C library (sdl2) the other is originally a C++ library (sfml)
claudiuinberlin has quit [Ping timeout: 248 seconds]