<FromGitter>
<watzon> @Blacksmoke16 good question haha
<FromGitter>
<Blacksmoke16> :p
<FromGitter>
<watzon> How are we doing on 128 bit integers btw? It would be nice for the parser to support them at some point...
<FromGitter>
<watzon> Looking like LLVM is the bottleneck. Yay.
<FromGitter>
<tenebrousedge> what do you need them for?
<FromGitter>
<tenebrousedge> do you mean 256 bit integers?
rocx has quit [Ping timeout: 260 seconds]
<FromGitter>
<watzon> No, 128. I don't know that I will need them for sure right now, at least not in a way that the parser needs to handle them, but they've been sitting in a state of only half working for a long time.
<FromGitter>
<tenebrousedge> half working how?
Dreamer3 has joined #crystal-lang
<FromGitter>
<watzon> 128 bit integers work, but don't parse
<FromGitter>
<watzon> And afaik they don't work natively, Crystal uses a C library to deal with them
<FromGitter>
<tenebrousedge> don't parse how?
<FromGitter>
<watzon> Like the parser can't handle them. It can't handle anything above a 64 bit integer.
<FromGitter>
<tenebrousedge> uh
<FromGitter>
<tenebrousedge> `1_i128` works for me?
lanodan has quit [Read error: Connection reset by peer]
<FromGitter>
<watzon> You can cast to a i128, but the parser can't actually read a full 128 bit integer
<FromGitter>
<tenebrousedge> ah
<FromGitter>
<tenebrousedge> okay
<FromGitter>
<tenebrousedge> well poke it until it acts nice
<FromGitter>
<watzon> Of course BigInt exists, but you do take a performance impact. And `BigInt` doesn't have a `#to_io`.
<FromGitter>
<watzon> We should add that btw
<FromGitter>
<watzon> Maybe I'll PR
<FromGitter>
<tenebrousedge> o.o k
lanodan has joined #crystal-lang
hightower3 has quit [Remote host closed the connection]
DTZUZU has quit [Quit: WeeChat 2.8]
Dreamer3 has quit [Ping timeout: 258 seconds]
alexherbo2 has joined #crystal-lang
Mikaela has quit [Ping timeout: 246 seconds]
Dreamer3 has joined #crystal-lang
_ht has joined #crystal-lang
fifr[m] has joined #crystal-lang
<fifr[m]>
Hi, I have a question. In this example https://play.crystal-lang.org/#/r/92tl why doesn't the compiler raise an error if `SubA` implements the (abstract) method `foo` from `Base` but with a different return type? Is this expected?
<raz>
oO that looks wrong to me
<FromGitter>
<naqvis> I'll also vote for this approach
<FromGitter>
<naqvis> mismatching return types are `warnings` not errors yet. So error took precedence in your example code. if you turn off line 22,23, you should see the warning generated by compiler ⏎ ⏎ ``` code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5ebe4dfd20d9bf3057677303]
<FromGitter>
<naqvis> yeah, play doesn't reveal warnings
<raz>
ah ok, makes sense then. (although i think it should! :))
<FromGitter>
<naqvis> it should be though
<FromGitter>
<naqvis> might be a good fit for an issue against play :)
<raz>
yup, altho in the grand scheme of things prob not the most urgent one
<FromGitter>
<naqvis> yeah, so many things on the priority list
<FromGitter>
<naqvis> but technically speaking compiler should be displaying all warnings + errors
<raz>
as long it does that on my local machine i'm happy. :D
<FromGitter>
<naqvis> :cheers:
<raz>
and there it indeed does, like in your pastie above
<raz>
(just verified it, to soothe my paranoia)
<FromGitter>
<naqvis> hahaha
<FromGitter>
<naqvis> lol
<raz>
i just don't understand how/why play even hides them. it looks like warnings are printed in the same way as errors (to stderr)
<raz>
oh well... mysteries
<fifr[m]>
@naqvis: thanks, now I see the warning. For some reason I do not see the warning if I compile my larger project (as a shard), that's why I missed it
<FromGitter>
<naqvis> 👍
<FromGitter>
<naqvis> I just played around and notice `--error-on-warnings` is not working the way it said it will
<FromGitter>
<naqvis> using the same example from fifr[m], using `crystal build --error-on-warnings` compiles fine by spitting out the warning
<FromGitter>
<naqvis> `intersects?` Returns true if the set and the given set have at least one element in common.
<FromGitter>
<naqvis> and that indeed is the case in above example
f1reflyylmao has quit [Quit: bye fags]
f1refly has joined #crystal-lang
zorp has joined #crystal-lang
Mikaela2 has joined #crystal-lang
Mikaela2 is now known as Mikaela
alexherbo2 has quit [Ping timeout: 256 seconds]
Dreamer3 has quit [Quit: Leaving...]
rocx has joined #crystal-lang
<FromGitter>
<Blacksmoke16> actually it wouldnt work since the navigators need to be instantiated with some data in the serializer. So new plan is to have some `NavigatorFactory` thats used within the serializer. Then that type would have the object constructor. Factory would expose like `.get_deserialization_visitor` and return/cache the instance
Human_G33k has quit [Ping timeout: 240 seconds]
<FromGitter>
<naqvis> sounds more Javaish lol
<FromGitter>
<naqvis> though I love Java and have been programming in Java since more than a decade
<FromGitter>
<Blacksmoke16> avg user shouldnt care, and would make DI easier so :shrug: seems like a good solution
<FromGitter>
<Blacksmoke16> imagine most will just use the `ASR.serializer`
<FromGitter>
<tenebrousedge> you can use `subset?` / `superset?`
<FromGitter>
<tenebrousedge> seems like enums might be good for that too
<FromGitter>
<naqvis> yeah sure, as long as encapsulation is in place and you only expose limited workload to-end user, internal details doesn't matter
<FromGitter>
<Blacksmoke16> yup, ill see how it goes
<FromGitter>
<naqvis> can you plz. share the repo link where I can see the existing code?
<FromGitter>
<j8r> hum, the pool can't grow dynamically...
<FromGitter>
<j8r> as an example having `5` by default, then fall back to create new ones out of the pool when the pool is full. Or, having a max than can be reached
<FromGitter>
<j8r> maybe that's not the role of the pool
<FromGitter>
<j8r> I would like to just use the pool for more perf, and fallback to no pool when full
<FromGitter>
<naqvis> pool shouldn't auto-size or else that beats the purpose
<FromGitter>
<naqvis> main intention of pool is to have pre-allocated connections and re-use
<FromGitter>
<naqvis> to avoid the overhead of establishing new connection
<FromGitter>
<j8r> yep I know
<FromGitter>
<j8r> But if I have more traffic
<FromGitter>
<j8r> I would like not to recompile my application, just grow the pool accordingly
<FromGitter>
<naqvis> aahh got your point
<FromGitter>
<naqvis> then i think you need to add another abstraction on top of it
<FromGitter>
<naqvis> kind of pool factory, which you can make configurable via params or so
<FromGitter>
<Blacksmoke16> does the the db shard have something like that
<FromGitter>
<christopherzimmerman> My city has a monthly meetup for software engineers, this months topic is going to be numerical computing in Crystal, really excited!
<hightower2>
Hey folks, just a heads up that in the past week we've worked on updating 'bindgen' to work with latest Crystal, pass specs out of the box, etc. The qt bindings for Crystal are produced using bindgen, so this was a pre-requirement for now starting to bring Qt bindings up to date.
<hightower2>
Even if you do not have interest in writing bindings for C/C++/Qt libs yourself,
<hightower2>
you can contribute a user report by just trying to compile bindgen and run its specs. It should work out of the box and if it doesn't please report a new issue
<hightower2>
on github.
<hightower2>
The only thing you need for this (i.e. to compile bindgen and run its specs) is to clone https://github.com/Papierkorb/bindgen and run `cd clang; cmake .; make -j; cd ..; crystal s`
<oprypin>
wow that's so cool
<oprypin>
i didnt realize there are so many contributors
<oprypin>
hightower2, are you any of those contributors?
<hightower2>
yes
<oprypin>
which one? 👀
<oprypin>
(or more 😂)
<hightower2>
the last commit visible currently is from me
<oprypin>
👍👍
<oprypin>
hightower2, what about that super advanced .travis.yml? doesn't it do it for you?
<hightower2>
although the large majority of work is purely Papierkorb's... it's astonishing what he was able to come up with (i.e. the bindgen and working qt bindings)
<oprypin>
i know right
<oprypin>
i keep saying like this is the single best made crystal project
<hightower2>
my #1 concern is that with crystal reaching 1.0 release, it will be hugely important that there are good/usable shards, and not just half-finished projects that once worked but then went out of date
<oprypin>
1.01.01.01.01.01.01.01.01.01.0 aaaa
<oprypin>
crsfml will always be there for you 😂
<FromGitter>
<bararchy> oprypin: just know that crSFML is my main point of "you're a game dev? you HAVE to checkout crystal"
<FromGitter>
<bararchy> I've pitched it to multiple people
<oprypin>
thanks <3
<hightower2>
oprypin, hehe, that travis.yml is from Stefan's setup... good point though, it needs an update
<oprypin>
hightower2, tried running it on windows lol but running into a weird problem. -- LLVM Tools Dir: C:/code/llvm/$(Configuration)/bin -- Using clang++ exec: clang_bin-NOTFOUND
<hightower2>
mm, windows - interesting target... clang++ and llvm-config are discovered by CMake itself
zorp has quit [Ping timeout: 246 seconds]
<hightower2>
do you have llvm-config and clang++ in PATH? if yes, what are their names, is it just llvm-config or llvm-config-10 etc?
<oprypin>
oh i should add them to path? ok i'll try
<hightower2>
yeah, I'm not sure what effort CMake makes to find them, other than looking in PATH
<hightower2>
oprypin oh btw, you're the right man to ask - is it safe to always add add -fPIC to flags when building bindgen which links LLVM's .a libs? I am trying to determine when to include -fPIC and when not, but it doesn't appear literally in any of the clang++/llvm-config diagnostic commands, so I'm trying to determine what's the right check for that
<oprypin>
hightower2, no sorry i dont know
<oprypin>
never used that flag myself
<hightower2>
It was needed on debian to get it compile; otherwise an error came up
<hightower2>
OK, that's the solution I applied. Hopefully people will submit an issue if it fails in practice
<FromGitter>
<j8r> It may be longer than using a random github action, but that's simpler to setup and more secure
<oprypin>
yea that particular gh action is shit too
<FromGitter>
<j8r> what particular one?
<FromGitter>
<Blacksmoke16> @j8r not sure
<FromGitter>
<j8r> those pushing to`gh-pages` generally?
<oprypin>
j8r, i checked 2 of them, disliked both, but yeah i think the one that Blacksmoke16 is using - i glimpsed that one from the forum
<FromGitter>
<Blacksmoke16> :shrug: it does its job
<FromGitter>
<j8r> haha :) And even more, if compromised
<FromGitter>
<Blacksmoke16> meh
<FromGitter>
<j8r> It won't be able to do much, because of your token permissions?
<FromGitter>
<Blacksmoke16> mhm
<FromGitter>
<j8r> My issue here I am in an organization. Using personal tokens is very not ideal
<FromGitter>
<Blacksmoke16> once that bug is fixed with actions, you wont even need a token, as you can use the one built into actions
<oprypin>
i dont understand how people use github actions not pinned to commit hash, they literally can any time change and overwrite your entire repo if they choose so
<FromGitter>
<j8r> yeah, like with `shards` :(
<oprypin>
lul
<oprypin>
well no, shards has shard.lock with hah
<oprypin>
hash*
<oprypin>
wait it doesnt?
<FromGitter>
<Blacksmoke16> not atm
<FromGitter>
<Blacksmoke16> is an issue for that
<oprypin>
... ok
<FromGitter>
<j8r> no, unless yo use an hash in the `shard.yml`
<FromGitter>
<j8r> I know because I opened the issue :P