ChanServ changed the topic of #crystal-lang to: The Crystal programming language | https://crystal-lang.org | Crystal 0.35.0 | Fund Crystal's development: https://crystal-lang.org/sponsors/ | GH: https://github.com/crystal-lang/crystal | Docs: https://crystal-lang.org/docs/ | Gitter: https://gitter.im/crystal-lang/crystal
<postmodern> i noticed they deprecated hexdigest in favor of Bytes#hexstring. While I can kind of understand that change, it does make porting ruby code to crystal just slightly more work, than if crystal tried to maintain compatibility. Also not sure why they wouldn't leave hexstring in, but mark it @[AlwaysInline] or such.
deavmi has quit [Read error: Connection reset by peer]
deavmi has joined #crystal-lang
<FromGitter> <didactic-drunk> You mean `#hexfinal`? The name change comes with behavioural differences. It's not safe to call `anyfinal` more than once. Ruby's `digest` dups the underlying digest object incuring significant overhead. See #9292.
<DeBot> https://github.com/crystal-lang/crystal/pull/9292 (Add faster Digest#hexfinal, Digest#hexfinal(dst))
<FromGitter> <didactic-drunk> I suppose the name change may not be necessary. It was meant to let developers know it's different and don't call it twice.
rocx has quit [Quit: 👏 developers 👏 developers 👏 developers 👏 developers 👏 developers]
zorp_ has joined #crystal-lang
rocx has joined #crystal-lang
<FromGitter> <asterite> Bar Hofesh: I'm curious what the bug was, maybe infinite tuple creation?
<FromGitter> <didactic-drunk> Oh. fck. #9292 didn't get merged.
<DeBot> https://github.com/crystal-lang/crystal/pull/9292 (Add faster Digest#hexfinal, Digest#hexfinal(dst))
zorp_ has quit [Ping timeout: 246 seconds]
_ht has joined #crystal-lang
renich has joined #crystal-lang
<FromGitter> <naqvis> what's up with HomeBrew PR https://github.com/Homebrew/homebrew-core/pull/56013 . I've seen tons of others PR got merged, but it still pending
_whitelogger has joined #crystal-lang
<FromGitter> <bararchy> @asterite well, hopefully @bcardiff will be able to explain better then I, but it seems the compiler has an issue with the way we referenced an Ivar being an array of class inside that class.
renich has quit [Quit: renich]
renich has joined #crystal-lang
renich has quit [Quit: renich]
tuurev has quit [Ping timeout: 240 seconds]
sarmonsiill has joined #crystal-lang
<sarmonsiill> Hi! In Go there's something called workgroups when doing concurrency-stuff. Is there something similar in Crystal?
<sarmonsiill> Something to limit how many spawns can run at the same time?
<FromGitter> <bararchy> Channels usually
<raz> ^ perhaps something along those lines?
<FromGitter> <bararchy> ```code paste, see link``` ⏎ ⏎ ^ this will only handle 4 at a time [https://gitter.im/crystal-lang/crystal?at=5ee1eb6e5dcbb760b6e2305a]
<FromGitter> <bararchy> where x is 4
<FromGitter> <bararchy> etc..
<jhass> there's thoughts about implementing structured concurrency but i haven't seen any fruits yet
<oprypin> removing parallel macro is the fruit 😂
<yxhuvud> I plan to do some doodling with related concepts during my vacation. perhaps it will land in something, perhaps not.
<FromGitter> <evvo> @Blacksmoke16 , I have example code for amqp with RabbitMQ - I was testing it as well. You can also get a free RabbitMQ account at Cloud AMQP (they created the library).
<sarmonsiill> that fiberpool looks interesting
<raz> hm, we need a mature aws shard. someone should call bezos, he could also fund crystal
<raz> actually i wonder if they have a funding program for language SDKs, hmm
sagax has joined #crystal-lang
<FromGitter> <igor-alexandrov> FastImage 1.0 is out! https://github.com/jetrockets/fastimage.cr. Next steps: integrate it to Shrine, integrate Shrine to Avram
kradnoel has joined #crystal-lang
kradnoel has quit [Read error: Connection reset by peer]
kradnoel has joined #crystal-lang
kradnoel has quit [Remote host closed the connection]
postmodern has quit [Quit: Leaving]
lvmbdv has joined #crystal-lang
lvmbdv has quit [Client Quit]
jetpack_joe has quit [Ping timeout: 240 seconds]
jetpack_joe has joined #crystal-lang
<FromGitter> <ArtLinkov> Hey all, ⏎ I need some help with `Log` in the specs, I can't get them to print anything inside a `it`for some reason (since last update) ⏎ Here is the flow of the specs: ⏎ ⏎ 1) Log is defined in the top level of my main module ... [https://gitter.im/crystal-lang/crystal?at=5ee2264624a3382d5d5e33b2]
<FromGitter> <Blacksmoke16> does the it block actually run when running the specs
<FromGitter> <ArtLinkov> Yeah, it does
<FromGitter> <ArtLinkov> Print and other things work
<FromGitter> <Blacksmoke16> hrm
<FromGitter> <ArtLinkov> (and sorry for the messy code blocks haha XD)
zorp has joined #crystal-lang
<FromGitter> <bararchy> Reproduced in: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5ee229717a7f8d2d632b947c]
<FromGitter> <Blacksmoke16> what happens if you do like `::Log.error { "inside it" }`
<FromGitter> <bararchy> same issue, as per my example above even with `::Log`
<FromGitter> <bararchy> seems like a bug, I'll open it
<FromGitter> <Blacksmoke16> 👍
<FromGitter> <naqvis> are you setting the env var `LOG_LEVEL=DEBUG` ?
<FromGitter> <naqvis> `LOG_LEVEL=DEBUG crystal spec .......`
<FromGitter> <Blacksmoke16> pretty sure you dont have to do all that now
<FromGitter> <Blacksmoke16> `Log.setup` should do it
<FromGitter> <naqvis> interesting enough, I had to do that to get the output on console
<FromGitter> <naqvis> or else no output
<FromGitter> <Blacksmoke16> sorry, i mean when you just use `Log.setup` you dont have to
<FromGitter> <Blacksmoke16> idk about the block version
<FromGitter> <naqvis> true
<FromGitter> <naqvis> document does states as you said
<FromGitter> <naqvis> but for some unknown reason, I couldn't get that working
<FromGitter> <naqvis> i might be doing sth silly though :P
<FromGitter> <bararchy> It's a bug
<FromGitter> <naqvis> 👍
<FromGitter> <bararchy> #9462
<DeBot> https://github.com/crystal-lang/crystal/issues/9462 (Log inside spec don't work in some cases)
<FromGitter> <bararchy> I'm trying to create a macro and ofc I'm failing, what am I doing wrong? ⏎ ⏎ ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5ee235187a7f8d2d632bb3a4]
<FromGitter> <Blacksmoke16> whats the error?
<FromGitter> <bararchy> end but expecting EOF etc..
<FromGitter> <bararchy> I think my syntax is wrong
<FromGitter> <Blacksmoke16> try wrapping some stuff in `{% begin %} {% end %}`
<FromGitter> <bararchy> thanks @Blacksmoke16 that did it 😁
<FromGitter> <Blacksmoke16> 👍
travis-ci has joined #crystal-lang
travis-ci has left #crystal-lang [#crystal-lang]
<travis-ci> crystal-lang/crystal#3a4be65 (master - Parser: fix parsing of proc in hash `of` key type (#9458)): The build passed. https://travis-ci.org/crystal-lang/crystal/builds/697239590
<DeBot> https://github.com/crystal-lang/crystal/pull/9458 (Parser: fix parsing of proc in hash `of` key type)
<FromGitter> <bararchy> Does the Crystal HTTP::Client handles chunked response?
<FromGitter> <naqvis> I would say yes, as `Response` does have method called `supports_chunked?` https://crystal-lang.org/api/0.35.0/HTTP/Client/Response.html#supports_chunked?(version):Bool-class-method
<straight-shoota> yeah
<FromGitter> <bararchy> Ok found it, it's just hiding in :nodoc: land
<FromGitter> <bararchy> Seems that reading from a Chunked IO is extremely slow
<FromGitter> <bararchy> I might be missing something ⏎ ⏎ ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5ee252017c64f31f11550fc2]
<FromGitter> <bararchy> logo.png is 12kb, and it seems this example raise `End of file reached (IO::EOFError)` from the client
<FromGitter> <didactic-drunk> @sarmonsiill From concurrent.cr (https://github.com/didactic-drunk/concurrent.cr) ```[1, 2, 3].parallel(fibers: 4).map { |n| n.to_s }```
underhood has joined #crystal-lang
<underhood> hi guys, trying out the crystal for first time today made project by `crystal-init` and then added
<underhood> dependencies:
<underhood> kemal:
<underhood> github: sdogruyol/kemal
<underhood> then `shards-install` which seems to have worked without issue
<underhood> but when i try to run it i get:
<underhood> In lib/kemal/src/kemal/helpers/helpers.cr:143:7
<underhood> 143 | Gzip::Writer.open(env.response) do |deflate|
<underhood> ^
<underhood> Error: undefined constant Gzip::Writer
<underhood> anyone willing to help newbie with probably obvious problem?
<FromGitter> <Blacksmoke16> fwiw there shouldnt be a `-` in either of those commands
<FromGitter> <Blacksmoke16> until a new release is tagged, just specify master branch, or use a commit from it
<FromGitter> <Blacksmoke16> w/o a version, branch, or commit, shards uses the latest release
<underhood> oh sorry, i actually ran with space (verified in zsh history)
<underhood> I understand then the issue is i need to use latest git version of `kemal` due to crystal release `0.35.0` being fresh?
<FromGitter> <Blacksmoke16> correct
<FromGitter> <Blacksmoke16> latest release of kemal doesnt support `0.35.0`, however the fix has been merged into master, but not yet tagged/released
<underhood> thanks a lot for the help and BTW crystal looks as awesome idea... i was dreaming of language that i can fit between C&Ruby (i have ~15 years of C/C++ and around ~8years with ruby)
<FromGitter> <Blacksmoke16> well there you go :p
<FromGitter> <Blacksmoke16> working on an API or something?
<underhood> well i am trying to use it as a backend language for some web API, i have personal project now that is not too urgent and not too big so that i can try new language on it
<FromGitter> <Blacksmoke16> sounds like a plan
<FromGitter> <Blacksmoke16> went with kemal for the simplicity?
<underhood> + it was described as sinatra like
<FromGitter> <Blacksmoke16> gotcha
<underhood> which i used with ruby
<FromGitter> <Blacksmoke16> each framework has their pros and cons
<underhood> what is your prefered pill?
<underhood> thx BTW runs as expected with master branch of kemal
<FromGitter> <Blacksmoke16> Athena (https://athena-framework.github.io/athena/Athena/Routing.html) ⏎ ⏎ *Disclaimer: I'm a bit biased as its mine* :P
<underhood> thx, will take a look
<underhood> :)
<jhass> what happend to sdogruyol btw? seems a lot less active
<FromGitter> <Blacksmoke16> 👍
<FromGitter> <Blacksmoke16> :shrug:
ht_ has joined #crystal-lang
_ht has quit [Ping timeout: 258 seconds]
ht_ is now known as _ht
<FromGitter> <j8r> I think he has a child, may explain this
<FromGitter> <j8r> If I remember correctly
<FromGitter> <j8r> underhood: you can also take a look at https://github.com/grip-framework/gripen 😉
<FromGitter> <j8r> Useful if you want API docs, otherwise Kemal is fine
erdnaxeli has joined #crystal-lang
<underhood> lot of stuff to learn... but same time very interesting (was not so excited about new language for long time), i am trying now to check if and how hard it is to compile for RPi...
<FromGitter> <Blacksmoke16> :grimm
<FromGitter> <Blacksmoke16> 😬
<FromGitter> <Blacksmoke16> would have to cross compile, was a guide for it somewhere...
<erdnaxeli> Hi, is there a way to run a specific crystal test? I mean on the crystal repo. make spec eats a lot of memory.
<FromGitter> <Blacksmoke16> `./bin/crystal spec spec/path/to/file`
<FromGitter> <j8r> underhood I suggest to use qemu
<FromGitter> <Blacksmoke16> er also seems that gist is for the compiler itself, same ide atho
<FromGitter> <Blacksmoke16> idea tho
<FromGitter> <j8r> cross compilation is sometimes unpractical because you need the exact same OS on both sides
<erdnaxeli> thanks Blacksmoke16
<jhass> underhood: which RPi/architecture?
<underhood> well i have RPi4 which is also main target where my backend is supposed to run
<jhass> so running aarch64?
<underhood> Raspberry Pi 4 Model B Rev 1.2
<underhood> 32 bit
<jhass> mh, you'll run into #9297
<DeBot> https://github.com/crystal-lang/crystal/issues/9297 (Use LFS definitions and symbols on 32 bit Linux platforms)
<FromGitter> <Blacksmoke16> dont they support 64bit os now?
<jhass> and #9401
<DeBot> https://github.com/crystal-lang/crystal/pull/9401 (Disable LLVM Global Isel)
<jhass> rpi4 is armv8, so can do aarch64, yeah
<FromGitter> <Blacksmoke16> the 8gb one has it ofc
<FromGitter> <j8r> armhf still not supported :(
<underhood> i think i noticed somewhere there is also 64bit version of raspbian now, but afaik is recent and i have it running some time already
<jhass> for aarch64 you'll need #9401, #9430 and possibly #9422
<DeBot> https://github.com/crystal-lang/crystal/pull/9401 (Disable LLVM Global Isel) | https://github.com/crystal-lang/crystal/pull/9430 (Fix C ABI for AArch64) | https://github.com/crystal-lang/crystal/pull/9422 (Fix VaList and disable va_arg for AArch64)
<jhass> that makes it work for me on aarch64-linux-musl, didn't test -gnu yet but I don't really expect more to crop up there.
<FromGitter> <j8r> But he is using armhf, which will require https://github.com/crystal-lang/crystal/pull/7859
<jhass> that seems incomplete, it doesn't deal with the LFS issue at all
<FromGitter> <j8r> Maybe, not very experienced on this. ⏎ At least, this can be considered initial work
<jhass> it probably is better to fix up the existing arm-linux-gnueabihf first and then taking that as a base for arm-linux-muslabihf rather than having to fix both then
<jhass> please don't pretend arm-linux-gnueabihf does not exist
<FromGitter> <j8r> It does sure
<FromGitter> <j8r> But you can't use it for static linking
<jhass> "armhf still not supported" sounds very different :)
<jhass> of course it could, it's just more painful with glibc
<jhass> but you could link glibc dynamically and everything else static for example
<FromGitter> <j8r> I meant for musl, sorry
<FromGitter> <j8r> I don't consider compiling crystal directly on armhf devices viable
<FromGitter> <j8r> unless it is a aarch64 with a armhf OS
<jhass> you mean armv8 in armhf mode
<FromGitter> <j8r> yes
<underhood> that is most of RPi4s now I guess
<underhood> cat /proc/cpuinfo
<underhood> model name: ARMv7 Processor rev 3 (v7l)
<underhood> processor: 0
<underhood> BogoMIPS: 108.00
<underhood> Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
<underhood> CPU implementer: 0x41
<underhood> CPU architecture: 7
<underhood> CPU part: 0xd08
<underhood> CPU variant: 0x0
<underhood> CPU revision: 3
<underhood> > dpkg --print-architecture
<underhood> armhf
<jhass> most? all, no?
<jhass> I guees it pretends to be an armv7 in armhf mode?
<FromGitter> <j8r> anyway, we can't really consider an OS/architecture supported if there is no CI - as you pointed out jhass there are still issues on ARM
<jhass> I'm working on obtaining and setting up an ARM box for CI :)
<jhass> aarch64 first
<FromGitter> <j8r> I would say partially supported is more correct, or not guaranteed to work
<FromGitter> <j8r> Sure, would be great :D
<FromGitter> <j8r> Talking about this, have you figured out how?
<jhass> with my PRs the compiler specs completely pass on aarch64
<underhood> jhass: you can get cheap hosting for RPi, and RPi v4 has some power already, it's quite nice to have it running 24/7 with public IP
<jhass> underhood: unfortunately it's too underpowered for CI, full run takes 3-4 hours. For a reasonble CI running on every PR it needs to run < 60 minutes
<FromGitter> <j8r> compiling the compiler needs performance
<jhass> even an AWS EC2 a1.xlarge is too slow on that criteria
<underhood> yep that is true
<FromGitter> <j8r> running specs can be parallelized though
<FromGitter> <j8r> and that's what taking the most time
<jhass> as I understand it worksonarm hands out these little beauties https://www.packet.com/cloud/servers/c2-large-arm/
<FromGitter> <j8r> what about multi-threading the specs :p?
<jhass> should be enough :)
<jhass> they're not even randomized, I don't want to know what would happen
<underhood> well that is way overpowered for what I need :D
<FromGitter> <j8r> 32 cores, OK, but It doesn't tell the single threaded perf
<jhass> 128G RAM, worst case I split them on 4 workers
<FromGitter> <j8r> 1) 3GHz doesn't tell much too
<FromGitter> <j8r> wow lots of room
<jhass> looks like RPi3 is ARMv8 too already? wonder why raspbian goes aarch64 only now
<jhass> even RPi2 1.2 already
<FromGitter> <j8r> that's right
<FromGitter> <j8r> because of the OS
<FromGitter> <j8r> I guess for them it was not a high priority to convert all the custom-made Raspbian packages to aarch64
<FromGitter> <j8r> I suspect on the following years we will have aarch64-darwin
<underhood> hmm don't really follow it that much, it's there it's doing things i need it to do :D forgotten until something stops working
<FromGitter> <j8r> It seems like they plan to have aarch64 macOS laptops
<underhood> seems to still offer only 32 bit OS
<FromGitter> <j8r> Raspbian is so bloated for servers, do you need the GUI?
<FromGitter> <j8r> the minimal image may be better
<underhood> well the hosting provider I have offers 2 options: a) send your own machine preinstalled to us, b) we install raspbian for you
<underhood> i didn't really have a need to fiddle with it
<FromGitter> <j8r> ok
<FromGitter> <j8r> I have looked a bit at https://downloads.raspberrypi.org/
<underhood> however, there is some performance advantage of using aarch64 from what I just googled
<underhood> but doesn't look like worth poking into something that is working well :D
erdnaxeli has left #crystal-lang ["User left"]
<underhood> it basicaly replaced need to have some VPSs for me at fraction of the cost + benefits of dedicated machine + actually it has more punch
<underhood> ok guys I will play with this more tomorrow. Thanks a lot, GLHF
<FromGitter> <Afront> I can't install crystal on a Debian machine (because of issues with gpg), so I tried using Linuxbrew ⏎ but I'm getting this ⏎ ⏎ ```code paste, see link``` ⏎ ... [https://gitter.im/crystal-lang/crystal?at=5ee273545dcbb760b6e3a6ba]
<jhass> maybe better to fix the gpg issues?
<jhass> how much memory do you have then?
<FromGitter> <Afront> I increased it to ~1.6GB since I thought it was enough, but it still said I didn't have enough memory ⏎ Then I increased it to 3.75 GB, but it's giving me this error
<jhass> some swap? It can still be a little tight for compiling the compiler :/
<jhass> hence maybe better to fix the gpg issues and use the prebuilt one
<FromGitter> <Afront> okay, thanks! I managed to fix the gpg issues.
hightower2 has joined #crystal-lang
underhood has quit [Remote host closed the connection]
<FromGitter> <watzon> In which cases does `with {class} yield` not work? Because it seems to be hit and miss for me.
<FromGitter> <tenebrousedge> `with builder yield builder`? huh
<FromGitter> <watzon> I've had it work elsewhere. You can then do `section do |md|` or just `section do` and have the `with builder yield` part take care of the scoping.
<FromGitter> <watzon> It doesn't work just doing `with builder yield` though either
<FromGitter> <Blacksmoke16> `section` do isnt the same method you're doing `.build` tho?
<FromGitter> <watzon> Well `section` has its own block which also yields a builder
<FromGitter> <watzon> But the `section` method itself exists on the `MarkdownBuilder` class
deavmi has quit [Quit: No Ping reply in 180 seconds.]
deavmi has joined #crystal-lang
<FromGitter> <asterite> remove the block type restriction
<FromGitter> <watzon> Ahhhh that's the reason?
<FromGitter> <watzon> Well sure enough that works
postmodern has joined #crystal-lang
_ht has quit [Quit: _ht]
oprypin has quit [Quit: Bye]
oprypin has joined #crystal-lang
oprypin has quit [Client Quit]
oprypin has joined #crystal-lang
<raz> tldr: when referencing github actions, use the commit hash. not a branch or version number.
<jhass> this is true for most CI systems these days tbf
<raz> well, no one seems to do it. unsurprisingly as github doesn't seem to encourage (much less enforce it) anywhere
<raz> predictably there will be a major hack in a few months, lots of pikachu faces
<travis-ci> crystal-lang/crystal#011add5 (ci/update - Forward flags in compile_and_run_file): The build passed. https://travis-ci.org/crystal-lang/crystal/builds/697399271
travis-ci has left #crystal-lang [#crystal-lang]
travis-ci has joined #crystal-lang
<jhass> how it didn't happen for the years gitlab CI exists? I can retag docker images too
<raz> umm
<raz> docker is (very slowly) learning it the hard way
<jhass> well it did happen, I'm not surprised. My point is it's nothing unique to github actions
<jhass> next up: some shard retags and steals your secrets in your next CI run
* raz shrugs
HumanGeek has joined #crystal-lang
<raz> just sayin', might be wise to replace those versions in the crystal-lang actions with hashes ;)
<raz> minimizing avoidable risks and all that
<jhass> there's no secrets in your GHA workflows as far as I can tell?
<jhass> *our
<raz> ah, the release binaries are built elsewhere? (haven't checked)
<raz> i only saw there was a windows workflow
Human_G33k has quit [Ping timeout: 260 seconds]
<jhass> yeah, on circle
<raz> kk
cloaked1 has joined #crystal-lang
* raz turns pillow to the cold side nervously
<oprypin> raz: if u don't trust GitHub you're screwed already
<oprypin> good meme tho. "lots of pikachu faces"
<raz> oprypin: well, if i wanted to something naughty with actions, those would be the repos i'd go after first ;)
<oprypin> raz: i don't understand
<raz> do you know who has push access there and what they opsec looks like ¯\_(ツ)_/¯
<oprypin> well then i guess everyone will be screwed so it's ok
<oprypin> i don't know why but somehow that's part of my threat model
<raz> that will be an interesting day for github for sure :D
<raz> yea, i can actually agree with that
<jhass> it's a consideration for when we actually need secrets in there because we do the release flows from there
<raz> if someone pulls it off then our crystal builds will probably the least of anyones worries
<jhass> until then it's completely irrelevant
<jhass> and even then it's only relevant for the one or two actions that get passed those secrets
<jhass> well maybe the one that builds the binary and anything between repo checkout and that, but then we already have a targeted attack at us
<jhass> as threat model that is
<raz> yeh, i think the only real risk would be if release bins fall out of it
<raz> but that doesn't seem to be the case
<jhass> I see no reason to give up convenience for "ooh somebody might retag this some day" if your only threat vector is a red cross instead of green check mark
<jhass> this article just reads like somebody found out they can apply the old random libraries are random trope to GHA and make some cheap publicity from it, sorry
<oprypin> jhass: uhhhh i
<oprypin> im pretty sure one can do something with this
<oprypin> actions can push to the repo
<jhass> yes, and wasn't that entirely obvious from the concept?
<oprypin> so why are you saying "red cross"
<jhass> like it's entirely obvious for shards, gem, npm, pip, pear, composer, apt, yum, ....?
<jhass> docker, idk what else
<oprypin> yes and those have lockfiles
<oprypin> or like.. don't allow force pushing tags
<jhass> a lot of them do
<oprypin> like wtf is that, i hoped publishing a release to marketplace would freeze it somehow
<oprypin> shard.lock is useless anyway
<jhass> my point exactly
<oprypin> no it's not
<oprypin> i mean shard.lock is useless in general just the way it's made
<oprypin> even when other langs have satisfactory solutions
<oprypin> oh there's been some activity there.i should've subscribed to the issue
<jhass> the point is, this is a reality for basically any modern software development environment. If you need to secure something it's the number one consideration to apply. Blasting this as a unique mistake in GHA is doing it for publicity
<oprypin> no
<oprypin> come on, they can make it right but they don't
<oprypin> why is adding another misbehaving tool to the mix ok when more and more tools are getting it right
<jhass> I claim there's no real right way, just very slightly less worse. Nobody reads through all their dependencies, that's just reality
<oprypin> you're also forgetting how trivial it is to get an action widespread
<oprypin> that wouldn't be the case for python packages
<oprypin> you don't need to read, you just see that for other people nothing bad happened yet
<jhass> see where?
<oprypin> (yes i know it's not reliable. it's not like reading the code is reliable)
zorp has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
<oprypin> number of downloads of a version
<jhass> as if that's not the easiest thing to fake
<oprypin> then everyone is screwed
<jhass> welcome to modern software development :) We are.
<raz> jhass has resignated ;)
<raz> but i agree with opry, there are ways to make it better. and it's annoying that github deliberately ignores them.
<raz> that green button on their market page links to a version tag. that's just dumb, it could just as well link to the sha ¯\_(ツ)_/¯
<raz> they could also invent a fancy signed sha-format with a human readable portion, so people can still see what version they have in the yaml
<raz> i predict that will happen, but only after someone has done something funky with a popular action...
<raz> you're of course right that knowing who to trust remains a hard problem. but my choices shouldn't change under my feet without notice. that's a much smaller problem to solve.
travis-ci has joined #crystal-lang
travis-ci has left #crystal-lang [#crystal-lang]
<travis-ci> crystal-lang/crystal#0926a12 (ci/update - Restore compiler flags used in specs as before #9294): The build passed. https://travis-ci.org/crystal-lang/crystal/builds/697416526
<DeBot> https://github.com/crystal-lang/crystal/pull/9294 (Avoid requiring non std-lib spec spec_helper in hooks_spec)
travis-ci has joined #crystal-lang
travis-ci has left #crystal-lang [#crystal-lang]
<travis-ci> crystal-lang/crystal#9eb85bd (ci/update - Avoid emitting full debug info on call_stack_spec): The build passed. https://travis-ci.org/crystal-lang/crystal/builds/697418994