<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.
<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.
<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?
<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
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)
<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>
<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...
<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)
<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
<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>
<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
<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>
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.