<FromGitter>
<Blacksmoke16> care to share what you plan on doing with this tho?
<FromGitter>
<Blacksmoke16> might be a better way...
<andremedeiros>
looks better than what I have, so I'll take it :-)
<andremedeiros>
absolutely
<FromGitter>
<wyhaines> Yeah. You are comparing the experimental pattern matching in current rubies to....not having that. ⏎ ⏎ The pattern matching is doing multiple things for you at the same time. You can get close using method overloading, and tuples.
<andremedeiros>
I'm trying to match one of "name", "owner/name", "host/owner/name" into an instance of Repository
<andremedeiros>
let me share the whole file with you
<andremedeiros>
i was compiling with shards, which was picking up an older compiler
<FromGitter>
<Blacksmoke16> Hm? Using shards build?
<andremedeiros>
yeah "shards build"
<FromGitter>
<Blacksmoke16> Gotcha
chachasmooth has quit [Ping timeout: 246 seconds]
chachasmooth has joined #crystal-lang
DTZUZU has quit [Quit: WeeChat 2.8]
DTZUZU has joined #crystal-lang
ghanima has joined #crystal-lang
alexherbo2 has joined #crystal-lang
svipal has quit [Ping timeout: 245 seconds]
<FromGitter>
<jwaldrip> With GitHub actions, GitLab CI, and all the other alternatives... should crystal init still generate a travis.yml file?
<FromGitter>
<aravindavk> @jwaldrip may be good for reference or reminder to use one CI. I felt similar when the default license file it created is MIT
<FromGitter>
<jwaldrip> ooh, thats another one that can actually get you in trouble. Would hate to work for a private company and accidentally leave the MIT license
<FromGitter>
<bararchy> Is Deque MT safe?
<FromGitter>
<Daniel-Worrall> There's an open issue regarding the future of crystal initiative
<FromGitter>
<Daniel-Worrall> Init*
Flipez has joined #crystal-lang
<FromGitter>
<gdotdesign> anyone here run into an issue where the type checker didn't find the overloaded function although it has been defined?
HumanGeek has quit [Ping timeout: 256 seconds]
<yxhuvud>
bararchy: no, it is not.
<yxhuvud>
same as array.
oddp has joined #crystal-lang
HumanGeek has joined #crystal-lang
<FromGitter>
<kingsleyh> how do I parse a unix epoch in ms to a Time? e.g. I have a string `1593163897.160700`
<FromGitter>
<asterite> @bararchy nothing is MT safe in the standard library except Channel
<FromGitter>
<asterite> andremedeiros: `case array.size; when 1; ...; when 2; ...; when 3; end`. Pattern matching is a nice to have but not necessary at all
oddp has joined #crystal-lang
<sorcus>
Hi everyone :-)
<FromGitter>
<Blacksmoke16> o/
<raz>
o/
<sorcus>
Little question. If i write `foo = BigInt.new "12345"` - it's converted to BigInt once? Even if i use `foo` many times?
<FromGitter>
<Blacksmoke16> yea, `foo` would be an instance of `BigInt`, just like any other struct/class
<sorcus>
Thanks Blacksmoke16 :-)
HumanGeek has quit [Ping timeout: 246 seconds]
HumanGeek has joined #crystal-lang
HumanGeek has quit [Remote host closed the connection]
HumanG33k has joined #crystal-lang
HumanG33k has quit [Remote host closed the connection]
HumanG33k has joined #crystal-lang
HumanG33k has quit [Remote host closed the connection]
twosecslater has left #crystal-lang [#crystal-lang]
<FromGitter>
<watzon> Seems like the problem is that no one can agree on the right action to take @oprypin
<FromGitter>
<watzon> It would be nice to have fixed though. I've had that issue several times.
HumanG33k has joined #crystal-lang
twosecslater has joined #crystal-lang
<FromGitter>
<kazzkiq> Hello
<FromGitter>
<kazzkiq> Is there any impact on using a single `require "../etc/*"` instead of multiple `require "../etc/1"`, etc?
<FromGitter>
<Blacksmoke16> can run into issues using the former, as they're required in abc order
<FromGitter>
<Blacksmoke16> depends on the context of which I use
<FromGitter>
<kazzkiq> Say I have a `helpers` folder with 20 files. But for sake of productivity just want to `require "../helpers/*"` on every file and be done with it
<FromGitter>
<Blacksmoke16> assuming they're all independent files prob would be fine
<FromGitter>
<tenebrousedge> ^
<FromGitter>
<Blacksmoke16> mainly run into issues when some depend on others and arent required first, i.e. one defines an abstract class the other inherit from
<FromGitter>
<tenebrousedge> or you could explicitly define the order in some file and require that
<FromGitter>
<kazzkiq> But wouldn't it impact performance? I'm guessing Crystal already does the job of ignoring required files which are not used, etc.
<FromGitter>
<tenebrousedge> it has a 0% chance of impacting performance
<FromGitter>
<tenebrousedge> Crystal is a compiled language
<FromGitter>
<tenebrousedge> require happens at compile time, not runtime
<FromGitter>
<kazzkiq> I'm more about compiling time performance. By requiring `*` on every file, perhaps my project would take longer to compile
<FromGitter>
<kazzkiq> I have no idea tho, just guessing if it could bite me in the long run
<FromGitter>
<tenebrousedge> generally I ignore performance until I'm forced to do otherwise, and it's difficult to envision the circumstances under which I would care about compilation performance
<FromGitter>
<tenebrousedge> Crystal itself is a fairly large and complex project, it compiles in a reasonable time frame, and probably your project will not be worse than Crystal
<FromGitter>
<tenebrousedge> if at some point that becomes not true, it's probably worth congratulations
<FromGitter>
<watzon> It can and will impact compile time performance, but there's really no way around that. You won't get around it by requiring files manually,
<FromGitter>
<watzon> What affects the compile time performance is just the fact that you're requiring those files in the first place
<oprypin>
watzon, regarding earlier, no nobody knows what the problem is and hence definitely not the solution. the disagreement is on what level of blind workarounds is applicable
<oprypin>
kazzkiq, require what you use, then order will never be important
<oprypin>
if each file directly requires only files that it needs
<oprypin>
with asterisks you very easily add circular dependencies and those can randomly stop working
<FromGitter>
<watzon> Truth. I've had this happen in larger projects.
<oprypin>
kazzkiq, regarding performance, a file is required only once. you can imagine a crystal program as a huge single file, and when a particular file is `require`d *for the first time*, it gets pasted in there
<oprypin>
so unless you otherwise would've never required that file at all, this should be totally fine. just that the other reason to not use `*` is already more than enough
<FromGitter>
<asterite> oprypin: with the cache issue, I feel like catching those errors, cleaning the cache and trying again is a good workaround for now. Unfortunately the rest of the core team prefers to let it crash until we have time to figure out why it crashes. Meanwhile it affects a lot of developers and it makes them unhappy. So even if I sent a PR to "fix" it it won't be accepted.
<FromGitter>
<j8r> There is a legit case of crash with an invalid cache: aborting in a middle of a compilation
<oprypin>
put up a full step by step repro then
<oprypin>
never happened to me
<FromGitter>
<asterite> the thing is that it's a race condition so it's hard to reproduce
<oprypin>
is it really? it's always connected to upgrades of crystal and such, doess it need to *also* have a race condition?
<FromGitter>
<j8r> Maybe I cancel when there is a linking, or during the generation of .o files
<FromGitter>
<asterite> oprypin: the root cause is stopping compilation and having an `.o` file with half of the contents it supposed to have. This is hard to reproduce because you have to `ctrl+c` in the right moment, but it's the same as just putting garbage inside an existing `.o` file
<FromGitter>
<asterite> That is, we can't prevent users from messing around with the cached object files. But we can clear those things and try again because it's harmless to do so.
<FromGitter>
<z64> hey all - ⏎ we just upgraded our whole stack to 0.35.1 and are seeing *exponentially* longer compile times when building in the official docker images vs host, with on various scales of code examples ⏎ the following are traces from building an empty web scaffold with `--release` ⏎ https://paste.sr.ht/~z64/738cd51d07894bb7a97597f0a6464f9c8fece518 ⏎ ... [https://gitte
<FromGitter>
<z64> it happens in bc+obj codegen phase, i had wondered if it was maybe some odd interaction with llvm 8 in 0.35, but our other dev who is using llvm 8 doesn't have the issue on his host
<oprypin>
z64, care to bisect it? or is it just docker images
<FromGitter>
<z64> i can build our prod app in release just fine on my host in reasonable time - the codegen overhead is only observed in the official docker images
<FromGitter>
<z64> in the container, the compiler is continuing to run at 100% cpu util the whole time
<straight-shoota>
so what's the difference between host and docker image?
<straight-shoota>
target triple, llvm version?
<FromGitter>
<z64> read the paste; crystal -v of the containers i've tried and my host are shown ⏎ coworker who has llvm 8 is on the same target triple
ghanima has quit [Ping timeout: 240 seconds]
<FromGitter>
<asterite> maybe memory issue so there's a lot of swap