<Stephie>
well you can ask sure but i'm pretty sure you'll get the same answer from him
<FromGitter>
<stronny> does crenv support a precompiled binaries or will it build from source each time?
<Stephie>
im pretty sure it downloads them
<FromGitter>
<deiv> I forgot , add snapshot.debian.org to repos
<Stephie>
@stronny even rust dowsn't have per-version packages
<FromGitter>
<stronny> didn't know about it thanks
<FromGitter>
<deiv> Yw
<Stephie>
why would crystal have this like python?
<Stephie>
python is like this because people want multiple python versions installed at once
<FromGitter>
<stronny> not only python, it's common
<Stephie>
and honestly people want multiple versions of rust installed at once
<Stephie>
thats why rustup exists
<FromGitter>
<stronny> the kernel itself
<FromGitter>
<stronny> ruby afaik as well
<Stephie>
it's only very important packages like kernels and python that get per-version packages
<FromGitter>
<stronny> postgres
<Stephie>
yes
<FromGitter>
<stronny> like I say, it's common
<Stephie>
so important things
<Stephie>
not crystal
<FromGitter>
<stronny> gcc
<Stephie>
we got the point
<FromGitter>
<stronny> I don't think importance is the criteria
<FromGitter>
<deiv> @stronny for minor versions, could be a lot of packages
<FromGitter>
<stronny> it's whether you want multiple versions installed at the same time or not
<FromGitter>
<stronny> I would want that is all
<Stephie>
the reality is thst getting a debian package maintainer to have the time to maintain one crystal package is an achievement
<Stephie>
dont push your luck
<FromGitter>
<stronny> if there's one there's n
<Stephie>
it'll be @deiv which has to do the extra work
<FromGitter>
<stronny> what work?
<FromGitter>
<deiv> In the future, when crystal has mayor versions releases ( with api incompatibilities) maybe packaginn with the version name
<Stephie>
maintaining multiple packages to install in parallel
<FromGitter>
<stronny> anyway snapshots is good enough I guess
<Stephie>
well it'll be all you get
<FromGitter>
<stronny> so all right, I retract my point
<Stephie>
i guess the reason why i'm a little annoyed by your suggestion is that you're just demanding things from other people without consideration for their workload
<FromGitter>
<stronny> I do packaging, I can estimate the work required
<FromGitter>
<stronny> if I'm wrong please correct me
<FromGitter>
<mavu> The source is there, on the github releases. why don't you just package the version you need yourself?
<FromGitter>
<stronny> I optimize for users
<FromGitter>
<mavu> what does that even mean?
<FromGitter>
<stronny> asking the user to package the version herself is not entirely reasonable imo
<FromGitter>
<mavu> "The user" does not want old versions.
<FromGitter>
<ArtLinkov> @stronny it works, thanks! :D ⏎ And yeah, in my case defining the generic methods in the module actually works great
<FromGitter>
<stronny> cool
<Stephie>
found another bitrot in the bootstrap script caused by libevent 2.1.11
<Stephie>
and fixed
<repo>
Blacksmoke16: hey! i noticed athena-dependency_injection has some issues with the release version. A shard build always causes a fetch of dependencies where athena-dependency_injection is installed with v0.1.3. The shard.yml in athena-dependency_injection shows v0.1.1 however
<repo>
defining it as an explicit dependency and setting the version to 0.1.1 in shard.yml fixes the problem for me
<FromGitter>
<Blacksmoke16> ahh, good catch, i just need to update the version in shard.yml i think
<FromGitter>
<Blacksmoke16> let me do that now
<repo>
yeah
<FromGitter>
<Blacksmoke16> thanks
<repo>
np
<FromGitter>
<mavu> This is a Questionaire from an australian and US Professor about influences of the pandemic and working from home on (specifically) software development. They also said to donate 500$ to some Opensource project if enough people participate. in the last question you can suggest Crystal :P ⏎ https://docs.google.com/forms/d/e/1FAIpQLSc-jj7RPz6gI3m-rNF4TDgJ-dogBrQsdheJ38LSelFFgtgrQg/viewform
<FromGitter>
<Blacksmoke16> @repo try now
<repo>
Blacksmoke16: hm nope
<repo>
shard still shows 0.1.1 for me
<repo>
did you update the tag as well?
<FromGitter>
<Blacksmoke16> tag was already at 0.1.3
<repo>
yeah but after the changes
<repo>
after you fixed shard.yml
<FromGitter>
<Blacksmoke16> ooo
<FromGitter>
<Blacksmoke16> moment
<repo>
you'll need to point it to that commit
<FromGitter>
<Blacksmoke16> alright, try now
<repo>
Blacksmoke16: it's a bit annoying.. i've run into this multiple times, i think there should be some kind of shards publish command or so which would let you set the version and then it would also set the git tag
<repo>
very easy to make mistakes the way it is now
<FromGitter>
<Blacksmoke16> at least when doing testing
<FromGitter>
<Blacksmoke16> 👍 np
<FromGitter>
<Blacksmoke16> really want that custom macro method PR so i can merge that draft DI PR
<FromGitter>
<Blacksmoke16> will make everything much much better
<FromGitter>
<Blacksmoke16> adds more features and makes the whole implementation simpler *magic*
<FromGitter>
<Blacksmoke16> mainly removing the need to add the module, and just adding `@[ADI::Register]` would register it as a service and resolve dependencies based on type restrictions
<repo>
yeah. situation is pretty bad corona wise here in germany but otherwise fine :)
<FromGitter>
<Blacksmoke16> ah, meant more so related to Athena since you seem to be using it 😉 but thats also good to hear
<Stephie>
@deiv pushed my changes - could you give it a try from a clean repo (git clean -ffdx)
<repo>
Blacksmoke16: oh :) well i _just_ set up the project, so i don't know yet. Will let you know though :)
<FromGitter>
<Blacksmoke16> 👍 ill be around if you need anything. Happy to help on the design/architecture of things as well
<repo>
cool thanks!
<repo>
maybe you could give me some pointers on how to implement auth with single sign on (e.g. github/twitter etc)
<FromGitter>
<deiv> @RX14 ill try and give you a response as soon as i can ;)
<FromGitter>
<Blacksmoke16> np, hmm im sure we could come up with something
<Stephie>
np at all
<Stephie>
please, take as long as you want
<repo>
Blacksmoke16: assuming with an event handler?
<FromGitter>
<Blacksmoke16> well id imagine there would have to be a route for each SSO provider
<FromGitter>
<Blacksmoke16> that you would set the redirect to
<FromGitter>
<Blacksmoke16> then use that endpoint to check for/create a user record, then return a token/set a cookie for that user so they are "logged in"
<FromGitter>
<Blacksmoke16> then auth itself would just be a request listener validating their JWT/token?
<repo>
yeah i guess
<FromGitter>
<Blacksmoke16> How many providers are there going to be?
<repo>
just a hand full
<repo>
maybe 3
<repo>
less than 5
<FromGitter>
<Blacksmoke16> Could also use a more generic approach. Like reuse same route with an argument that represents the provider name. Then could create a hash if name to provider interface where the logic specific to each provider is handled in there
<FromGitter>
<Blacksmoke16> hash of*
<repo>
yeah
<FromGitter>
<Blacksmoke16> That would be a bit more complex but definitely the more future proof solution
<FromGitter>
<Blacksmoke16> Depending on the type of project you're working on
<FromGitter>
<Blacksmoke16> Stdlib has an oauth2 module as well, probably would help
<repo>
yeah
<FromGitter>
<Blacksmoke16> If you wanted to do the latter, defining a module as an interface, then creating types implementing the interface for each provider, tagging each of those, then injecting those tagged services is what I would do
rohitpaulk has quit [Remote host closed the connection]
rohitpaulk has joined #crystal-lang
rohitpaulk has quit [Remote host closed the connection]
deavmi has quit [Quit: Going into the wilderness...]
<FromGitter>
<naqvis> Just published crystal-odbc (https://github.com/naqvis/crystal-odbc) an ODBC Driver/Connector for Crystal. With the hope that it will make Crystal accessible to people who want to connect to databases like DB2, Oracle, MS SQL Server and so on 😆
deavmi has joined #crystal-lang
jetpack_joe_ has joined #crystal-lang
blueberrypie7 has joined #crystal-lang
jetpack_joe has quit [Ping timeout: 246 seconds]
blueberrypie has quit [Quit: Ping timeout (120 seconds)]
jetpack_joe_ is now known as jetpack_joe
davic has quit [Ping timeout: 240 seconds]
<repo>
Blacksmoke16: about param converters. it seems a bit redundant and inefficient to write a param converter for each param given in a post request body. because this would mean the body is read again for each param
<repo>
i guess i could wrap the whole thing in a class though
<repo>
and just convert to that
<FromGitter>
<Blacksmoke16> is the body just JSON?
<FromGitter>
<Blacksmoke16> where you have a generic converter to convert a request body into T
davic has joined #crystal-lang
<FromGitter>
<Blacksmoke16> where `T` could be your ORM model
deavmi has quit [Quit: Going into the wilderness...]
<repo>
not json, www-form-uri-encoded
<FromGitter>
<Blacksmoke16> gotcha
<FromGitter>
<Blacksmoke16> i would do something similar, but instead of calling `.from_json`, maybe have each type define `.from_form_data(param : HTTP::Params) : self`?
<FromGitter>
<Blacksmoke16> could really even have a module that could define that based on ivars of that type, similar to `JSON::Serializable`
deavmi has joined #crystal-lang
<FromGitter>
<Blacksmoke16> although prob not required if you're not doing a lot or is simple
<FromGitter>
<Blacksmoke16> but thats what i would do, then would be easy to write tests for each type etc
<repo>
yeah
flips has quit [Ping timeout: 256 seconds]
flips has joined #crystal-lang
<FromGitter>
<deiv> @RX14 done "==> Bootstrapping Crystal 0.33.0 (160/160)" -- thank you again !!!
<oprypin>
boy am i tired of merging 6+ month old branches
deavmi has quit [Quit: Going into the wilderness...]
deavmi has joined #crystal-lang
<Stephie>
@deiv wow!
<Stephie>
@deiv if you have any issues with packaging crystal please just ask
<FromGitter>
<deiv> @RX14 Im compiling from crystal sources using the generated on last round (0.33.0) and I get: Error: execution of command failed with code: 1: `cc "${@}" -o '/home/deiv/dev-dinamic/debian/pkgs/crystal/crystal-lang/.build/crystal' -Wl,-z,relro -rdynamic /home/deiv/dev-dinamic/debian/pkgs/crystal/crystal-lang/src/llvm/ext/llvm_ext.o `/usr/bin/llvm-config-9 --libs --system-libs --ldflags 2> /dev/null` -lstdc++
<FromGitter>
<deiv> its normal to see " 2> /dev/null"
<FromGitter>
<deiv> in the cmd ?
<Stephie>
yes
<Stephie>
in that subshell
<FromGitter>
<deiv> ah sorry lol
<Stephie>
it uses shell backticks
<FromGitter>
<deiv> im nervous to get the thing compiled xD
<Stephie>
well, was there another error?
<FromGitter>
<deiv> nope but I guess what failed
<Stephie>
how does cc error and not emit an error??
<FromGitter>
<deiv> the error was on linking, no more
<Stephie>
yeah
<Stephie>
but like, it printed the linker error right?
<FromGitter>
<deiv> ups, sorry
<FromGitter>
<deiv> lots of them
<FromGitter>
<deiv> /usr/bin/ld: /home/deiv/dev-dinamic/debian/pkgs/crystal/crystal-lang/.build/crystal: no symbol version section for versioned symbol `*Array(String)@Enumerable(T)#includes?<String>:Bool'
<FromGitter>
<deiv> how I could put another library path from the make command ?
<Stephie>
@deiv thats a really weird linker error...
<Stephie>
@deiv what do you mean another library path? LDFLAGS?
<Stephie>
if you package it does the package guidelines require any weird stuff for bootstrapped compilers? like compiling from scratch for every build?
<Stephie>
or can you just make a package that builddeps on itself?
deavmi has quit [Read error: Connection reset by peer]
deavmi has joined #crystal-lang
<FromGitter>
<deiv> testing the build
<FromGitter>
<deiv> Ill do a package that depends on itself
<FromGitter>
<deiv> better to compile from scratch all the time, but see the llvm3.3 on the boostrap ... hehe
<FromGitter>
<deiv> @RX14 If I undertand the codegen part of compiler generates an *.o file and later links with the system linker (correct me if Im wrong)
<FromGitter>
<deiv> so I have all the libraries path fine ?
<Stephie>
well it generates many .o files pretty often
<Stephie>
but yes
<Stephie>
basically
<FromGitter>
<deiv> Im seeing:
<FromGitter>
<deiv> src/compiler/crystal/codegen/link.cr- # Append the default paths as -L flags in case the linker doesn't know ⏎ src/compiler/crystal/codegen/link.cr- # about them (eg: FreeBSD won't search /usr/local/lib by default): ⏎ src/compiler/crystal/codegen/link.cr: library_path.each do |path| ⏎ src/compiler/crystal/codegen/link.cr- flags << " -L#{path}" ⏎
<oprypin>
Blacksmoke16, i think there's no change in final behavior for now, only the warning added. > Note that right now if you cover all cases the compiler won't issue a warning but there will still be an implicit else nil, but eventually that will change to else unreachable of some sort. - https://github.com/crystal-lang/crystal/pull/8424
<FromGitter>
<Blacksmoke16> ohh
<FromGitter>
<Blacksmoke16> yea, the implicit else is still there since its just a warning
<FromGitter>
<Blacksmoke16> my bad
<FromGitter>
<Blacksmoke16> *next*version it would work
<oprypin>
dang it, first link is broken until you manually expand "large diffs"
<Stephie>
yeah
<Stephie>
github web for large diffs sucks
<Stephie>
yeah oprypin
<Stephie>
you dont merge them
<Stephie>
not with like
<Stephie>
git merge/rebase
<Stephie>
what you do is you checkout master, understand the diff, and re-apply it by hand
<Stephie>
with some gratuitous copy-pasting
<Stephie>
which is hell
<Stephie>
but less hell than the merge conflict you end up in
<oprypin>
Stephie, oh i know my diffs, i'll be fine
<Stephie>
well
<Stephie>
i've always done it that way
<oprypin>
your approach is a bit more reliable in the end but hm
<Stephie>
oprypin, fork is gonna like, go
<Stephie>
anyway
<Stephie>
it might be cleaner to, uhh, push it off the cliff
<Stephie>
at least deprecate it
<oprypin>
anyway the most fun part is always `git diff -w -U99 base:src/process.cr src/crystal/system/unix/process.cr`
<Stephie>
well thats actually a long cycle
<Stephie>
mmh
<FromGitter>
<sam0x17> so random suggestion, I wonder if there is a way to hint to google search that the canonical version of each page in the API docs is the one from the latest version
<oprypin>
> my other pain point for me is figuring out when something was deprecated/changed/renamed
<oprypin>
find a commit that contains `Deprecated.+\n.+method_name` and find the first release with it
<FromGitter>
<straight-shoota> We can do a lot more with `@[Deprecated]` annotations than is currently implemented. IMO the release when it became deprecated should be attached to each annotation, so it shows up in the docs. Maybe also the release when it's scheduled to be removed.
<FromGitter>
<straight-shoota> Then it would also be easy to compile a list of deprecated features based on the release when they became deprecated.
<FromGitter>
<paulcsmith> Does anyone know if it is possible to use a macro like `{% if Crystal.version > 0.33 %}` or something along those lines? I'd like to do a release that works in both 0.33 and 0.34 since it is just a one line change, but I'd need something like this to do it