<FromGitter>
<rishavs> the password which is returned from db is a string. and I cannot use a string with the new verify method
<FromGitter>
<rishavs> am I supposed to use the new verify methos or use `Crypto::Bcrypt::Password.new(user["enteeredpassword"].try &.to_s) != rawpassword`
<FromGitter>
<naqvis> no
<FromGitter>
<naqvis> you can load the bcrypt hash stored in your database via `Crypto::Bcrypt::Password.new(db_stored_hash)` then perform a `password.verify(user_supplied_password)`
<FromGitter>
<rishavs> Thanks @naqvis . that helps a lot!
<FromGitter>
<naqvis> iirc modules doesn't have inheritance, so what would that `super` should be referring to?
<FromGitter>
<naqvis> what is actual use-case?
<postmodern>
it allows extending ClassMethods into the including Class, but if another module is including the module, it sets up another included hook to include it's ClassMethods once the including module is finally included into a Class
<postmodern>
in ruby you can extend multiple modules with included instance methods and call super from the top `self.included` to call th other `includes` in the ancestors list.
<postmodern>
here is a simplified example: https://carc.in/#/r/b42o note that Mixin2 can include Mixin1 and not care about it's ClassMethods, and when Base includes Mixin2 it get's Mixin1::ClassMethods extended into it automatically.
<straight-shoota>
seems like a lot of meta magic
<straight-shoota>
what do you actually want to do with this?
<postmodern>
port it to crystal
<postmodern>
it allows me to write a bunch of modules, include those modules into other modules, but only have their ClassMethods injected when it's a Class that finally includes them
<straight-shoota>
but why?
<straight-shoota>
what's the reason for such double use modules?
<postmodern>
to decompose the functionality into small modules that can be cherry-picked if the developer only wants certain features. Then they can include only the modules they want into their Command class
<postmodern>
this way i can have my Usage module also include CommandName and Help, but CommandName::ClassMethods and Help::ClassMethods will end up being extended into whichever Class includes Usage, not into Usage itself
<postmodern>
can `macro included` define other `macro included` hooks?
<postmodern>
naqvis, i assume i could also check {% if @type.is_a?(Class) %} or something similar to control when `extend ClassMethods` is called vs when another `macro included` is emitted?
<FromGitter>
<naqvis> you can use `@type.module?` to verify if includer is a `Module` or else it should be Class/Struct
<postmodern>
that way the `macro included` hook could be replicated infinitely no matter how many times the modules are included into other modules https://play.crystal-lang.org/#/r/b42v
<FromGitter>
<naqvis> i'm guessing that we might have to use nested macros as well
<FromGitter>
<naqvis> i'm experimenting as well
<FromGitter>
<naqvis> let's see if my limited knowledge of macros can help me here :P
<postmodern>
if there's a cleaner way of somehow deferring `extend ClassMethods` until a Class finally includes one of the including modules, i'm open to using that as well
<straight-shoota>
when nesting macro hooks, you need to escape the nested macro expressions
<FromGitter>
<allie_signet:matrix.org> is this some weird caching bug or?
<FromGitter>
<Blacksmoke16> there hasnt been a release with the `1.0.0` version
<FromGitter>
<Blacksmoke16> might want to do like `commit: 33db38393d4e75cbaa62ecd187f21cbcbbc5121a`
<FromGitter>
<allie_signet:matrix.org> oh, are github fetches based on releases?
<FromGitter>
<allie_signet:matrix.org> i see
<FromGitter>
<Blacksmoke16> versions are 1:1 to GH tags
dbohdan has joined #crystal-lang
<FromGitter>
<kevinsjoberg> I'm looking into https://github.com/crystal-lang/crystal/issues/5994. Not sure what the "correct" fix is here. The binary on macOS expects the user to have installed libyaml via Homebrew. So downloading the macOS binary from GitHub will cause `shards` to fail if `libyaml` isn't currently installed via Homebrew. I assume we don't want to statically link libyaml?
<FromGitter>
<allie_signet:matrix.org> yeah, that fixes it. thank you!
<FromGitter>
<Blacksmoke16> `0.1.0` relates to the `0.1.0` release/tag in GH
<FromGitter>
<Blacksmoke16> er git tag, not specific to GH ofc
<FromGitter>
<Blacksmoke16> cant just add `libyaml` as a dep to the asdf stuff?
<FromGitter>
<kevinsjoberg> @Blacksmoke16 I guess we could. It's just a shame the macOS binaries on GitHub have indirect dependencies. It's not obvious for anyone downloading that binary it relies on libyaml being installed via Homebrew.
<FromGitter>
<kevinsjoberg> I guess, the best solution as of now, would be to build crystal from source, configuring libyaml explicitly.
<FromGitter>
<Blacksmoke16> is it actually that you need to install it from homebrew, or that you just need to have libyaml installed in path
<FromGitter>
<Blacksmoke16> in library path or something*
<FromGitter>
<kevinsjoberg> The path is hardcoded to look for the path where Homebrew installs it.
<FromGitter>
<kevinsjoberg> Even better, I closed the original pull request in favor of updating the path dylib path to libyaml when installing Crystal via asdf. See https://github.com/asdf-community/asdf-crystal/pull/40.
<FromGitter>
<kevinsjoberg> Would it be possible to fix the dylib path for macOS binaries to at least use @rpath for finding the libyaml dylib? Right now, it's hardcoded to /opt/crystal/embedded/lib/libyaml-0.2.dylib?
<FromGitter>
<kevinsjoberg> Perhaps the best thing would be to set the dylib path to @executable_path..//lib/libyaml-0.2.dylib. This would solve the issue permanently.
<FromGitter>
<oprypin:matrix.org> i'm just wondering how I never ran into this in the context of https://github.com/oprypin/install-crystal ⏎ because it just downloads those same binaries and just runs them, and yaml just works. i wonder if it's because github's env already has yaml at the matching path
_ht has quit [Remote host closed the connection]
<FromGitter>
<kevinsjoberg> Yeah, I think that's the case. If libyaml is found in the library_path its not going to be a problem I guess. That's why install libyaml via Homebrew also solves the problem.
chachasmooth has quit [*.net *.split]
yxhuvud has quit [*.net *.split]
FromGitter has quit [*.net *.split]
oprypin has quit [*.net *.split]
bougyman has quit [*.net *.split]
Renich[m] has quit [*.net *.split]
<straight-shoota>
TIL: In Ruby `puts "foo" "bar"` prints `foobar`
oprypin has joined #crystal-lang
chachasmooth has joined #crystal-lang
FromGitter has joined #crystal-lang
yxhuvud has joined #crystal-lang
Renich[m] has joined #crystal-lang
bougyman has joined #crystal-lang
Renich[m] has quit [Ping timeout: 276 seconds]
<FromGitter>
<allie_signet:matrix.org> is there anyway to do named interpolation for SQL?
<FromGitter>
<allie_signet:matrix.org> trying to figure out what a good way of dynamically building a query would be
<FromGitter>
<oprypin:matrix.org> actually i have no idea why they didnt implement full-on interpolation
<straight-shoota>
usually you can just use the interpolation mechanism in SQL
<FromGitter>
<allie_signet:matrix.org> yeah i'm gonna use TREN instead, i think. since ordering arguments when dynamically building could get messy quick
<straight-shoota>
managing SQL queries in separate files might get even more messy
<FromGitter>
<allie_signet:matrix.org> i mean, how should i do it otherwis - we don't know how many arguments are going to be needed at the start, so figuring out how
<FromGitter>
<allie_signet:matrix.org> to properly feed them in order, while possible, is going to be p messy
<straight-shoota>
I don't follow
<straight-shoota>
if you want to interpolate arguments, you need to know which ones and how many, no?
<FromGitter>
<allie_signet:matrix.org> you can dynamically build a query like "SELECT FROM table WHERE " += ("name = $student_name" if 'student_name' in parameters) += ("class = $student_class" if 'student_class' in parameters)
<FromGitter>
<allie_signet:matrix.org> (bad pseudo-code, but i hope it's enough)
<straight-shoota>
ah okay, so the query itself changes
<FromGitter>
<allie_signet:matrix.org> yea
<FromGitter>
<Blacksmoke16> store the where clauses in a hash or something
<FromGitter>
<Blacksmoke16> then use it to build the resulting string
<straight-shoota>
you might consider a query builder for that
<straight-shoota>
that's likely keep you more sane than handling raw SQL composition by yourself