<FromGitter>
<wyhaines> Hey folks. I've come into Crystal from a Ruby POV, and it's mostly been painless. I have a question that has tripped me up this afternoon, though. ⏎ ⏎ Ruby: foo = Hash.new { |h, k| h[k] = [] } ⏎ Crystal: foo = Hash.new { |h, k| h[k] = [] of String } ⏎ ... [https://gitter.im/crystal-lang/crystal?at=5ed98ef389941d051a436290]
<FromGitter>
<Blacksmoke16> although unless you have a good reason, might be worth looking into not using hashes, they are as useful in Crystal land
<FromGitter>
<Blacksmoke16> depending on the usecase a `struct` might be the better option
<FromGitter>
<wyhaines> Oh. Hah. That's simple. I didn't try that.
<FromGitter>
<wyhaines> In this case, a hash is what is needed. Basically, I need to find a specific value from a big pile of values based on a key. But the program can't know what they keys are ahead of time. That's dynamic.
<FromGitter>
<Blacksmoke16> 👍
<FromGitter>
<wyhaines> FWIW, I am really loving Crystal. Some of the documentation could improve, but as a Rubyist for almost 20 years, Crystal has been really easy to pick up to a productive level.
<FromGitter>
<Blacksmoke16> Which uses crystal at exit stuff?
<FromGitter>
<watzon> Nope, it's just an exit handler for my state machine
<FromGitter>
<Blacksmoke16> Gotcha
<FromGitter>
<watzon> I mean, I know `message` is not going to be nil in this context, so I'm not afraid to use `not_nil!` since it works. Just trying to figure out why the compiler isn't accurately determining that `message` should not be nil due to that `if` statement
<FromGitter>
<Blacksmoke16> > The callback must completely initialize the buffer; as of SDL 2.0, this buffer is not initialized before the callback is called. If there is nothing to play, the callback should fill the buffer with silence.
<FromGitter>
<Blacksmoke16> maybe also relevant
<FromGitter>
<sam0x17> omg just got bitten by `String.hash` hashing differently across different compilations
<FromGitter>
<Blacksmoke16> https://wiki.libsdl.org/SDL_AudioSpec also from what i can tell the current version of `AudioSpec` doesnt have the `padding : UInt16` like the binding does, maybe that's throwing something off?
<FromGitter>
<Blacksmoke16> rip
<FromGitter>
<sam0x17> yeah and blah blah I'll use sha1 or something blah blah
<FromGitter>
<sam0x17> lol
<FromGitter>
<Blacksmoke16> `sha1`, bruh
<FromGitter>
<mattrberry> > https://wiki.libsdl.org/SDL_AudioSpec also from what i can tell the current version of `AudioSpec` doesnt have the `padding : UInt16` like the binding does, maybe that's throwing something off? ⏎ ⏎ Weird. This SDL binding library is missing so much. I might just implement one of my own.... Still, fixing that doesn't seem to help my stack overflow issue :/
<FromGitter>
<Blacksmoke16> i dunno, this is about the extent of my C knowledge
<FromGitter>
<Blacksmoke16> last updates to `audio.cr` was 3 years ago, so is entirely possible its just out of date compared to your version?
<FromGitter>
<wyhaines> Is there a coding standard for lines with long sets of type unions? ⏎ ⏎ `property config : Hash(String | YAML::Any, String | Int32 | Bool | Array(Hash(String, String | Array(String) | Bool)) | YAML::Any)` ⏎ ⏎ All on one line, or is there a convention for making it multiline? [https://gitter.im/crystal-lang/crystal?at=5ed9c80a3ffa6106f1f698c7]
<FromGitter>
<Blacksmoke16> could break it out into an alias
<FromGitter>
<Blacksmoke16> or aliases
<FromGitter>
<Blacksmoke16> not possible to not have such an ugly union in the first place?
<FromGitter>
<wyhaines> It is describing possible values that are coming in from a YAML file, but the values can be a wide variety of things.
<FromGitter>
<Blacksmoke16> and the yaml doesnt have a known structure?
<FromGitter>
<Blacksmoke16> then you could do like `Config.from_yaml File.read "config.yml"` and deal wit types and such
<FromGitter>
<wyhaines> Hmmm. That might be a really clean way to do this. ⏎ ⏎ I'm porting an existing piece of Ruby software, and 95% of everything that I've had to deal with so far have just been getting the type handling right. :)
<FromGitter>
<Blacksmoke16> that would work most of the time, but also realize they *are* diff languages
<FromGitter>
<Blacksmoke16> and as such, IMO, crystal kinda forces you to think more and design better stuff
<FromGitter>
<Blacksmoke16> versus just using a hash for everything for example
<FromGitter>
<wyhaines> Oh yeah. Thinking about the type handling has not been a negative at all. It's all positive.
<FromGitter>
<Blacksmoke16> good to hear
kerframil has quit [Quit: WeeChat 2.8]
cacheerror has joined #crystal-lang
_ht has joined #crystal-lang
alexherbo2 has joined #crystal-lang
<FromGitter>
<naqvis> > I mean, I know `message` is not going to be nil in this context, so I'm not afraid to use `not_nil!` since it works. Just trying to figure out why the compiler isn't accurately determining that `message` should not be nil due to that `if` statement ⏎ ⏎ Variable closured by proc are always of Mix type so in this case its `Message | Nil`. This is because the captured block could have been potentially stored
<FromGitter>
<naqvis> I would have gone with passing the variable to proc to avoid such cases.
Human_G33k has quit [Ping timeout: 260 seconds]
<FromGitter>
<igor-alexandrov> I have some troubles with stubbing gzipped responses with WebMock. ⏎ ⏎ ``` code paste, see link``` ⏎ ⏎ Based on documentation HTTP::Client should automatically decompress GZIP if `Content-Ecoding` header has been provided. ... [https://gitter.im/crystal-lang/crystal?at=5ed9ea9a7da67d06faf281af]
HumanG33k has joined #crystal-lang
<FromGitter>
<naqvis> not sure if you have some typo, but it should be `Content-Encoding`
<FromGitter>
<igor-alexandrov> but, this is what I have. Where do you see any typos?
<FromGitter>
<naqvis> after sending message I realized that you have used correct word in your code, but typo was only in your message content ⏎ ⏎ > Based on documentation HTTP::Client should automatically decompress GZIP if `Content-Ecoding` header has been provided.
HumanG33k has quit [Remote host closed the connection]
HumanG33k has joined #crystal-lang
<FromGitter>
<igor-alexandrov> :)
<FromGitter>
<igor-alexandrov> @bcardiff @asterite maybe you can help
<FromGitter>
<naqvis> I just looked into the webmock code and seems patched `HTTP::Client` doesn't support this
<FromGitter>
<naqvis> its bypassing that compression handling mechanism and directly invoking `consume_body_io`
<Stephie>
though using anything but linux/windows on x86 and arm isn't supported for github actions
<Stephie>
which means I need a seperate solution for the BSDs anyway
<jhass>
I think I'll see if I can get alpine to bootstrap a package from a build like that, then after a release it can bootstrap from its own package of the previous release and that should give us a nice place to bootstrap other distributions from for the platform (probably gonna attempt archliunuxarm then)
<jhass>
you can totally do anything using GH actions and self hosted runners
<jhass>
so we just need to get somebody to sponsor hardware
<jhass>
like, a lot if we want to do all possible targets
alexherbo2 has quit [Ping timeout: 246 seconds]
alexherbo2 has joined #crystal-lang
<FromGitter>
<confact> I got the famous "Invalid memory access" on `build --release` - I just had to restart my computer and it got away. Is that something I should add in an issue? I found like 200 issues mentioning that error. Would love to get rid of this random error.
<FromGitter>
<Blacksmoke16> might just be a bad cache
<jhass>
unless you have a way to reliably trigger it and can share it such that somebody else can reproduce it, there's no point I'm afraid
<jhass>
confact: can you provide some more context? what were you building? Host, LLVM version?
<jhass>
if a reboot helps, this might be a memory corruption issue from an invalid binding for example
<FromGitter>
<confact> Ah, okay. I am coding right now on Arch Linux, and are using llvm 10.0.0
<jhass>
ah wait, you said on build, that nudges it towards LLVM bug...
<jhass>
full trace would be interesting too
<jhass>
(if it's anything more than excluslivly ???)
<FromGitter>
<confact> jhass it usually works fine if I build without the release flag. it is when i use release flag it happens mostly.
<jhass>
it could be that we codegen something the LLVM optimizer hates
<jhass>
(crashes on)
<FromGitter>
<confact> jhass I will try to run my builds with trace flag to be able to get a full trace when it happens.
<jhass>
but if it doesn't realibly trigger it will make bugpoint not work, so it'll be hard to track down :/
<FromGitter>
<confact> Yea, I understand that. I have hard a lot of people get this randomly and that it would be amazing to get rid of it :) - No hard feelings if it will never be fixed, I understand the complexity.
<FromGitter>
<neutrinog> what's the syntax to raise a float64 to an exponent?
<FromGitter>
<neutrinog> e.g. 1.0f64e-8
<FromGitter>
<Blacksmoke16> `val ** -8`?
<FromGitter>
<neutrinog> is that some undocumented exponent magic?
<jhass>
but it's supported in literals, so just use it
<FromGitter>
<neutrinog> > not really https://crystal-lang.org/api/master/Int.html#**(exponent:Float):Float64-instance-method ⏎ ⏎ Ah it's hidden in the Int docs. I was looking in the Float64 docs.
<FromGitter>
<neutrinog> half hidden 😉
<jhass>
gosh, please don't ignore me here
<jhass>
** is runtime, e is compile time
<FromGitter>
<Blacksmoke16> oh wait, `E` is an actual thing?
<FromGitter>
<neutrinog> > *<jhass>* ** is runtime, e is compile time ⏎ ⏎ 👍 wow that's a big difference :)
<repo>
hi, i'm trying to write a tiny DSL for html and i'm struggling a bit with `with self yield`
<repo>
i get an error saying "too many block arguments (given 1, expected maximum 0)
<FromGitter>
<neutrinog> > oh wait, `E` is an actual thing? ⏎ ⏎ the compiler doesn't lie. Thanks @jhass
<jhass>
the new defined by the compiler needs to forward the block
<jhass>
and that messes up with with ... yield
<FromGitter>
<naqvis> repo I played with your code and notice that you would have to `yield self` from the constructor, or just don't mess up with constructor and `yield` from method ⏎ https://carc.in/#/r/97pw
<FromGitter>
<naqvis> jhass was quick :)
<jhass>
just slightly :D
<jhass>
took me some iterations to figure out
<FromGitter>
<naqvis> same is here :D
<FromGitter>
<naqvis> https://carc.in/#/r/97pz ⏎ this was my first iteration which looks ugly though
<FromGitter>
<naqvis> just a dumb question: why not use templates for code-generation?
<jhass>
not flexible enough I think
<jhass>
see the example above
<jhass>
with a template you'd be at before with tons of inline code, joining argument lists together etc
<FromGitter>
<naqvis> true, but by template i mean some templating language like Jinja
<FromGitter>
<naqvis> but again, that goes back to DSL :D
<jhass>
yeah no, my point is that crout has some semantic understanding of what's being defined, it for example could know whether it needs to wrap an expression into () because it's used as a subexpression of something else. With templates you'd be back at a lot of #{x ? "this" : "that"}
<FromGitter>
<naqvis> yeah, that's true
<jhass>
templates are good if the code you generate is very uniform, like the telegram API wrapper we had yesterday
<jhass>
For something like crystal-gobject, it pretty much maps the entire language features since GObject is essentially an OOP language emulated in C
<jhass>
it has closures, all argument types you can imagine and is just a framework for libraries, so you can find any combination of those features and need to generate wrappers for it
<FromGitter>
<naqvis> https://github.com/nsf/gogobject using templates for generation. Though I don't know how this differs from crystal-gobject
<FromGitter>
<asterite> @igor-alexandrov my opinion is that webmock should either: 1. be removed, 2. be maintained by someone else or 3. be merged into the standard library so it doesn't get outdated. But right now I don't think we have time to keep supporting it
<jhass>
so yeah, it uses templates for the simple and uniform, redundant boring stuff
<FromGitter>
<naqvis> DSL approach is definitely good, but seeing the dynamic nature of code generation, i believe you would have to design a kind of full fledged (though not turing complete) language
<jhass>
and then the meat of the code has the samme issues I had, completely mixing logic and presentation
<FromGitter>
<naqvis> yeah, templates are meant for different purpose (the ones which you highly cited)
<jhass>
yeah, my current approach is to have the abstraction be leaky, if something's not covered, just pass a string
rocx has quit [Remote host closed the connection]
rocx has joined #crystal-lang
<jhass>
to the point that I have def var(name); name; end; just so you can mark it as a variable to make the code clearer
<jhass>
Idk, I kept it an internal thing for now for reasons :D
<FromGitter>
<naqvis> necessity is mother of invention
<FromGitter>
<naqvis> i'm sure once you make that public, there will be more use-cases
<FromGitter>
<naqvis> are there any hooks for Compiler?
<jhass>
what do you mean?
<FromGitter>
<naqvis> i mean kind of hook after compilation is done, but before proceeding with generation of artefact
<FromGitter>
<naqvis> i had this thought to kind of utilize such approach to generate some deployment stuff for programs. Idea like using annotation to mark the module with Docker related stuff and once the compilation is done, code to generate docker file, build, tag, publish etc
<FromGitter>
<naqvis> this can only be achieved via kind of compiler extension
<jhass>
well, just invoke with --cross-compile but don't specify another target
<raz>
time to put your pants and ties on, we're in the spotlight!
<oprypin>
oh dang
<oprypin>
i dont like it
<oprypin>
very shallow article
<raz>
good PR tho
<oprypin>
no
<FromGitter>
<igor-alexandrov> > @igor-alexandrov my opinion is that webmock should either: 1. be removed, 2. be maintained by someone else or 3. be merged into the standard library so it doesn't get outdated. But right now I don't think we have time to keep supporting it ⏎ ⏎ Got it.
alexherbo21 has joined #crystal-lang
alexherbo2 has quit [Ping timeout: 265 seconds]
alexherbo21 is now known as alexherbo2
<FromGitter>
<watzon> So is there a way to check environment variables at compile time?
<FromGitter>
<Blacksmoke16> `env("NAME")`
<FromGitter>
<Blacksmoke16> pretty sure `ENV["NAME"]` also works?