<FromGitter>
<dscottboggs_gitlab> There's still a problem with how bindgen interprets macro constant unsigned integers but basically the qt library is usable again as far as I can tell
* FromGitter
* dscottboggs_gitlab is so excited
non-aristotelian has quit [Quit: non-aristotelian]
laaron has quit [Remote host closed the connection]
laaron has joined #crystal-lang
laaron- has joined #crystal-lang
laaron has quit [Remote host closed the connection]
laaron- has quit [Client Quit]
laaron has joined #crystal-lang
<FromGitter>
<girng> @dscottboggs_gitlab wow O_O
<FromGitter>
<girng> @dscottboggs_gitlab so basically, instead of using c++ in qt 5 we use crystal instead?
<FromGitter>
<dscottboggs_gitlab> that's the idea. Bindgen doesn't appear to have a way to pull the docs from the C++ code or to write them in the YAML configs for the bindings, so you'll have to refernce the C++ documentation, but the APIs should be largely similar.
<FromGitter>
<girng> @kingsleyh nice cutscene!
Raimondi has quit [Ping timeout: 240 seconds]
laaron has quit [Remote host closed the connection]
laaron has joined #crystal-lang
laaron- has joined #crystal-lang
laaron has quit [Remote host closed the connection]
laaron- has quit [Remote host closed the connection]
Raimondi has joined #crystal-lang
<FromGitter>
<domgetter> I realize this may be a dumb question, but if I happen to know that every string in an array will match, is there a way to force the match to return type Regex::MatchData and not (Regex::MatchData | Nil) ? If I must do the nil check afterward, that's fine. Just wanted to know if there was a way to do that.
_whitelogger has joined #crystal-lang
laaron has joined #crystal-lang
<FromGitter>
<proyb6> @dscottboggs_gitlab wow, I hope it could be useful for the Crystal community other than using Electron
Raimondi has quit [Ping timeout: 240 seconds]
<FromGitter>
<sam0x17> if I send to a channel that doesn't have a receive set up anywhere yet, the sends will just queue up until receive is called later? yes?
laaron has quit [Remote host closed the connection]
laaron has joined #crystal-lang
ska has quit [Remote host closed the connection]
Renich has joined #crystal-lang
laaron has quit [Remote host closed the connection]
_whitelogger has joined #crystal-lang
Renich has quit [Read error: Connection reset by peer]
laaron has joined #crystal-lang
azuri5 has joined #crystal-lang
return0e_ has joined #crystal-lang
return0e has quit [Ping timeout: 268 seconds]
azuri5 has quit [Quit: azuri5]
<FromGitter>
<bararchy> @CImrie you here?
<FromGitter>
<bararchy> Great work @dscottboggs_gitlab
azuri5 has joined #crystal-lang
<FromGitter>
<bararchy> you should open a PR to the main repo, and, maybe create an issue there saying the working version sits at ..
<FromGitter>
<bew> @sam0x17 yes, or it depends on the type of channel, is it buffered or unbuffered?
laaron has quit [Remote host closed the connection]
laaron- has joined #crystal-lang
<FromGitter>
<domgetter> @woodruffw awesome, thanks for the tip
<woodruffw>
no problem!
<FromGitter>
<bararchy> it seems that every week someone else need more SSL bindings, I think it's time to decide wheter `crystal/openssl` github should be created and the shard be extended via PRs
<FromGitter>
<bararchy> @kingsleyh I know find myself also doing OpenSSL work on adding more X509 features
<FromGitter>
<bararchy> RX14, @bcardiff wtdy?
azuri5 has quit [Quit: azuri5]
azuri5 has joined #crystal-lang
return0e has joined #crystal-lang
azuri5 has quit [Quit: azuri5]
return0e_ has quit [Ping timeout: 272 seconds]
<FromGitter>
<kingsleyh> @bararchy I’m happy to contribute my OpenSSL work to a larger shard
<FromGitter>
<bararchy> So would I, I just don't want antoher `datanoise/openssl.cr` or `randomstate/openssl_ext`, I want the core team to open a `crystal/openssl` so that we can PR to it and make sure it's stay up to date with current releases
azuri5 has joined #crystal-lang
<FromGitter>
<bararchy> for starters so that we won't need to wait for "someone" to extract all of OpenSSL from compiler, I think just adding this repo so we can `extend` uppon the OpenSSL lib is best
<FromGitter>
<kingsleyh> I don’t know how others feel about this but for convenience I switched my bindings to support the lower versions of OpenSSL because those versions are the defaults on all my computers and upgrading all them to 1.1.1 was very inconvenient
<FromGitter>
<bararchy> @kingsleyh they might, it makes sense, I just want to make sure the things I need are included XD and if not, I want a place to push them to because currently STDlib OpenSSL is not being extended because "it will be moved to external shard"
<FromGitter>
<kingsleyh> Yeah I totally agree with you @bararchy - about getting a core tram supported OpenSSL shard that will accept PRs
<FromGitter>
<bararchy> maybe ping @asterite
<FromGitter>
<kingsleyh> I’m right now also extending my ecdsa shard to include ecdh and EC curve encryption and I can see myself adding several more things too - so it definitely makes sense to pool our code
<FromGitter>
<kingsleyh> We could perhaps start a new shard and port over all the existing Crystal ssl code as a start
<FromGitter>
<kingsleyh> And then we can transfer it to the core team if they agree
<FromGitter>
<kingsleyh> And if not - it’s still better to have it all in one shard
<FromGitter>
<kingsleyh> As a side note - It’s far safer to write bindings to a well supported and battle hardened ssl lib than to write our own in Crystal - I’ve come to appreciate this with the blockchain work I’ve been doing
<FromGitter>
<bararchy> that's for sure
<FromGitter>
<bararchy> We can also see if `randomstate/openssl_ext` will accept PRs, this way we can use it as main shard until we get a crystal-lang/openssl repo ready
<FromGitter>
<kingsleyh> Sounds good - but we should create our own if we have to wait months for PRs to be merged
<FromGitter>
<kingsleyh> Also would be nice to have BN bindings in one place
<FromGitter>
<kingsleyh> So some re-organisation of the code would be required
sagax has quit [Ping timeout: 246 seconds]
<FromGitter>
<kingsleyh> Also should we do direct bindings or make something more similar to the Ruby API
<FromGitter>
<kingsleyh> Usually I like to get the structure of the code agreed and build a skeleton into which the details can be built by contributors and us
<FromGitter>
<bararchy> I personally hate `OpenSSL::SSL::SSL::OMFG::WHYSOLONG::Socket::Client` style bindings, but, it's the standard so a ruby like is best I guess
azuri5 has quit [Quit: azuri5]
laaron has quit [Remote host closed the connection]
ashirase has quit [Ping timeout: 246 seconds]
laaron has joined #crystal-lang
ashirase has joined #crystal-lang
azuri5 has joined #crystal-lang
<FromGitter>
<bararchy> @omarroth you did some work also on OpenSSL in Crystal, would you join in?
laaron has quit [Remote host closed the connection]
laaron has joined #crystal-lang
<FromGitter>
<bararchy> wow I hate OpenSSL @kingsleyh I feel your pain
laaron has quit [Remote host closed the connection]
laaron has joined #crystal-lang
<FromGitter>
<bararchy> "Performance" section is gold
<FromGitter>
<asterite> @kingsleyh I haven't heard anything about implementing something like openssl in pure Crystal
<FromGitter>
<bararchy> ( Nither did I, and it's good I didn't hahaha )
<FromGitter>
<bararchy> TBH RX14, would you accept OpenSSL PRs to the STDlib until we "move" to external shard? because right now lot's of code is wasted on litle projects with no maintainrs
<FromGitter>
<proyb6> Crystal 0.27.1 milestone is nearly done, I thought if it could be release on the New Year? Maybe not
<mps>
bararchy: IIRC, RX14 told once he is thinking to add mbed-tls to crystal
_whitelogger has joined #crystal-lang
<FromGitter>
<asterite> why would OpenSSL be moved to an external shard? How would HTTP::Client work then without it?
laaron has quit [Remote host closed the connection]
laaron- has joined #crystal-lang
<FromGitter>
<bararchy> @asterite there has been a LONGGGGGGG discussion about it in multiple threads, it was decided that openssl will remain as minimal as possible in STDlib, and all other functionality will be added via external shard
<FromGitter>
<asterite> Oooh... I see
<FromGitter>
<j8r> The same problem is for all other bindings
<FromGitter>
<asterite> I think it would make sense to have a complete openssl binding instead of a fragmented one
<FromGitter>
<bararchy> I'm with you @asterite
<FromGitter>
<j8r> LibC also
<FromGitter>
<asterite> The only problem is that at least I don't know anything about openssl, so if PRs arrive I won't be able to review them
<FromGitter>
<bararchy> That's the issue with OpenSSL, few actually know what they are doing aside from trial and error
<FromGitter>
<asterite> but you know openssl, right?
<FromGitter>
<bararchy> lol no
<RX14>
@asterite I think the stdlib needs a tls module with an abstract api, and all the openssl raw bindings should go in a shard
<FromGitter>
<bararchy> I fiddle and try a
<FromGitter>
<asterite> you and kingsleyh
<RX14>
So when openssl finally dies we can remove it from crystal
<FromGitter>
<asterite> what's a replacement for openssl? libressl?
<RX14>
Tying crystal's stdlib stability to the api of an external library which is known for making breaking abi changes is pretty bad
<FromGitter>
<bararchy> @asterite no no I think I can talk for both of me and @kingsleyh when I say "we know almost nothing about it, but we play with it alot, so we learn what works"
<FromGitter>
<j8r> But there isn't only OpenSSL in this case: LLVM, LibC, GMP...
<RX14>
Then everyone changed their mind in a different issue
<RX14>
@straight-shoota I'd appreciate an issue being opened on the tls api.
<FromGitter>
<straight-shoota> Okay, so it reflects context outside this issue
<FromGitter>
<straight-shoota> It would probably be worth referencing the discussion
<FromGitter>
<straight-shoota> I'm not sure which issue, though
laaron- has quit [Remote host closed the connection]
laaron has joined #crystal-lang
gangstacat has quit [Quit: Ĝis!]
gangstacat has joined #crystal-lang
<FromGitter>
<asterite> I'm running some kostya's benchmarks using the overflow branch, and so far performance remains the same. LLVM is so good :-) (or processors and predictions? I have no idea :-P)
<FromGitter>
<asterite> Someone should try writing a magic number type that's either an Int64 or BigInt under the hood, depending on the value (like Ruby), and then benchmark it against regular numbers... I wonder if there would be any noticeable performance difference. Because if not, having just one integer type would be sooo cool
<FromGitter>
<j8r> I've noticed too that comparing numbers and booleans are CPU cheap
<FromGitter>
<j8r> some operations like additions too
Raimondi has joined #crystal-lang
gangstacat has quit [Quit: Ĝis!]
laaron has quit [Remote host closed the connection]
laaron has joined #crystal-lang
gangstacat has joined #crystal-lang
Raimondi has quit [Ping timeout: 240 seconds]
laaron has quit [Remote host closed the connection]
laaron has joined #crystal-lang
<FromGitter>
<Sija> @asterite any idea what’s happening in #6997?
laaron has quit [Remote host closed the connection]
Raimondi has joined #crystal-lang
DTZUZO has joined #crystal-lang
<oprypin>
kingsleyh, with all this talk about splitting openssl -- maybe u should mention the problems you ran into with that, about not being able to choose the lib and being careful not to conflict
<FromGitter>
<kingsleyh> Oprypin good idea! I will summarise it and attach it to an issue
<FromGitter>
<kingsleyh> @dscottboggs_gitlab I know you are trying to use QT but I've recently been playing with Nuklear and I'm considering writing a wallet GUI for SushiChain using Nuklear - so in the process creating some Crystal bindings for it: https://github.com/vurtun/nuklear
<FromGitter>
<kingsleyh> if you have a look at the screenshots on the README it's quite nice looking
<FromGitter>
<kingsleyh> yeah - it's just the UI part
non-aristotelian has joined #crystal-lang
Raimondi has quit [Ping timeout: 240 seconds]
Renich has joined #crystal-lang
Renich has quit [Quit: Renich]
<FromGitter>
<Willyboar> there is a nice conversation in both amber and lucky channels about how much gitter
<FromGitter>
<Willyboar> what do you think?
<FromGitter>
<bararchy> I hate discord, I hate Gitter too TBH but discord is not developer friendly at all
<FromGitter>
<Willyboar> personally i find gitter very bad. especially mobile app
<FromGitter>
<bararchy> yeha, totally agree
<FromGitter>
<bararchy> I play D&D with a group on discord, it's perfect because of VOIP and gaming bot integration, but for a dev community? seems meha
<FromGitter>
<Willyboar> well to be honest i didn’t try discord yet.
<FromGitter>
<kingsleyh> None of the chat clients I’ve used are that great
<FromGitter>
<kingsleyh> They each have their own issues
<FromGitter>
<Willyboar> No one is perfect.
Raimondi has joined #crystal-lang
<FromGitter>
<sam0x17> @bew how do I specify buffered vs unbuffered for a channel ?
_whitelogger has joined #crystal-lang
<FromGitter>
<j8r> Gitter has at least GitHub/GitLab integration
<FromGitter>
<j8r> @Willyboar you can use an IRC client for this channel
<FromGitter>
<j8r> Furthermore I found the future of Discord is more uncertain than Gitter, owned by GitLab. Discord isn't
<FromGitter>
<j8r> ...still profitable
<FromGitter>
<j8r> Only solution I can see is Matrix
blassin has quit [Ping timeout: 245 seconds]
<FromGitter>
<anamba> matrix would be interesting. i've been wanting to put together a crystal client for that.
blassin has joined #crystal-lang
<FromGitter>
<Willyboar> @j8r I think you can create webhook for github.
<FromGitter>
<Willyboar> I suppose you can do the same for girls
moei has quit [Quit: Leaving...]
<FromGitter>
<dscottboggs_gitlab> @kingsleyh I'm actually just trying to get any sort of simple desktop graphics system working at all. I don't have any particular desktop project in mind at the moment. That said, Nuklear looks rather nice but equally if not more verbose and hard to use for simple UI elements than Qt.
<FromGitter>
<kingsleyh> Getting QT working with Crystal is very cool and I will certainly use it
<FromGitter>
<j8r> @Willyboar Didn't know, but I doubr the integration goes as far as Gitter (right panel with PR/issues, people's GitHub profile etc). They are not mandatory at all, just a little plus