<FromGitter>
<jwaldrip> is ScalarStyle::ANY allowed to be any type?
<FromGitter>
<jwaldrip> any type in crystal
<FromGitter>
<jwaldrip> I am fixing some underlying issues with crystal and yaml, would love some guidance on what the behavior of that event style should translate to.
<FromGitter>
<jwaldrip> @johnjansen do you have a perspective perhaps?
<FromGitter>
<jwaldrip> you're a smart guy
rohitpaulk has joined #crystal-lang
snsei has joined #crystal-lang
snsei has quit [Ping timeout: 240 seconds]
snsei has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 255 seconds]
rohitpaulk has joined #crystal-lang
snsei has quit [Remote host closed the connection]
<FromGitter>
<mgarciaisaia> @jwaldrip I really don't know that code, but from the context I would tell it means *any of the other possible `ScalarSytle`s* rather than *any Crystal object you like*.
greenbigfrog has quit [Quit: The server of my BNC just shutdown or got killed!!!]
<FromGitter>
<johnjansen> @jwaldrip i wish i could give you some … i got lost in the whole pull parser mapping yaml::any area yesterday … still havent recovered the mental energy ;-) … plus its friday and i spent the day laughing at the news
snsei has joined #crystal-lang
alex`` has joined #crystal-lang
<FromGitter>
<drujensen> hello crystallites! I have a question and can use some help
<FromGitter>
<drujensen> is there a way to get the index of a match with `gsub`?
<FromGitter>
<sdogruyol> Hey @drujensen
<FromGitter>
<drujensen> in ruby, you can do something like this:
<FromGitter>
<johnjansen> yeah, it was out of view ... anyway
<FromGitter>
<johnjansen> @drujensen can you stick the code in play
<FromGitter>
<johnjansen> im on a new machine and its not set up yet
<FromGitter>
<johnjansen> shite yes @dru ... there is no enum version of gsub
<FromGitter>
<johnjansen> tell me .. in ruby is the `with_index` giving you the char index of the match, or just a number representing `no_of_matches_seen_already + 1` ?
<FromGitter>
<drujensen> aahh, nice! @johnjansen that will work. thanks!
<FromGitter>
<johnjansen> im inclined to think it is too, since i think you are getting enum behaviour
snsei has quit [Remote host closed the connection]
<FromGitter>
<drujensen> Next crystal codecamp I will buy you a beer
<FromGitter>
<drujensen> hopefully at a bar with a better bartender than last time. lol
<FromGitter>
<johnjansen> @drujensen no need my friend ... by the way im hacking on a reverse proxy to stand in front of your kemal (or stdlib) http apps
<FromGitter>
<drujensen> excellent
<FromGitter>
<johnjansen> so you can do rolling updates with no downtime ... without NGINX of HA or whatever
<FromGitter>
<johnjansen> ok bed for me ... catch up soon
<FromGitter>
<drujensen> k
rohitpaulk has quit [Ping timeout: 255 seconds]
<FromGitter>
<LuckyChicken91_twitter> how can I get the bits of an integer? for example if im defining `myint = 56i64` how can I check then which bit it is? maybe with `bit?`/`bits?`
<FromGitter>
<johnjansen> one more thing before bed i suppose
<FromGitter>
<straight-shoota> @bmcginty that's possible but only allows to create values in the range or an int32! Better to use a literal: `1_u64`
<FromGitter>
<LuckyChicken91_twitter> how can I define methods which i can use on some things? i mean methods like `myvariable.upcase` for example. if i would want to define a method like this i could use the method like this: `mymethod(myvariable)`
<FromGitter>
<sdogruyol> Morning everyone
<FromGitter>
<LuckyChicken91_twitter> good morning
<FromGitter>
<krypton97> morning here
<FromGitter>
<krypton97> just found this benchmarking tool
<FromGitter>
<krypton97> This api seems much lighter than the c++ one
<Groogy>
well that's because I am implementing a Crystal abstraction layer or whatever :P framework is done so the backend can be replaced with other hardware interfaces as well
<Groogy>
Vulcan, DirectX etc. without your own code changing
<FromGitter>
<krypton97> Screw Vulkan, that took me like 90 lines only for creating the window x_x
<Groogy>
yeah I tried vulkan before and it was... ugh painful
<Papierkorb>
Wasn't that the intention of vulkan? No pun intended, it's super bare metal, and it probably shows
<Groogy>
yeah it is
<Papierkorb>
Note that I have no idea about graphics APIs, and what makes a good one
<Groogy>
which is also why OpenGL probably will never die as well
<Papierkorb>
Yeah didn't even the Vulkan folks say that in the introduction?
<Papierkorb>
"use OpenGL except if you need Vulkan"
<Groogy>
the Vulkan folks are Khronos they commitee that defines OpenGL as well
<Groogy>
yes :P
<Groogy>
the committe*
<FromGitter>
<krypton97> Doesn
<FromGitter>
<krypton97> Vulkan use the win api?
<Groogy>
no you were probably reading a tutorial on how to get started
<Groogy>
Vulkan is just a standard for how to interact with graphics drivers essentially
<Papierkorb>
Groogy: Though considering the awful OpenGL code in drivers, is there already work done to reimplement the OpenGL API on top of Vulkan? Would that actually give any performance benefit?
<FromGitter>
<krypton97> nvm
<Groogy>
but you still need to create a OpenGL or a Vulkan context through platform specific interfaces (like the Win api to create a window)
<Groogy>
Papierkorb as far as I know, no but I think to save cost that's what the gfx card makers are just gonna do
<Groogy>
because the gfx cards still can't drop DirectX9 or even OpenGL 1.2 support
<Groogy>
keep in mind OpenGL and Vulkan kind of works like the C++ standard, some industry leaders decide on things and then it's up for the companies to implement it
<Papierkorb>
Qt update, it should now be possible to write everything required for Qt integration into libevent (and thus, Crystals "main loop") to be done from pure(-ish) Crystal. The last day I got rid of the last obstacle towards that, so even that part won't need custom C++ code. yay.
<Papierkorb>
Groogy: Yeah standards are meant to be not followed, ugh. Never got into graphics or game dev in general, never knew how to start and do something useful
<Papierkorb>
Though I'm not even interested in building a Game, I'm only interested in the underlying engine partes...
<Groogy>
Huh in more actual working terms what does that mean with Qt integration? That Qt can hook into the fibers?
<Papierkorb>
Yes, that means you'll be able to use the Qt (on the long run) like a library besides normal Crystal code
<Papierkorb>
Won't be possible for the TechPreview, but that's one of the main things to do after the release of that stuff.
<Papierkorb>
Really important to me. QNetworkAccessManager is just no fun to use in a non-C++/Qt-native world (Well, bindings could be made of course). We already have networking code. Etc.
<FromGitter>
<bew> wow, did you integrate Qt into crystal's scheduler? or crystal into qt's main loop?
<Papierkorb>
Intend to, not done yet. That part is more complex. I just made it possible that it can be done using pure Crystal code, and without writing any further C++ code just on that
<Papierkorb>
And it's Qt
<Papierkorb>
And it's Qt's event loop into LibEvent, which provides the event loop for Crystal programs
<Groogy>
noice
<Groogy>
gotta get some coffee so I can start working on the next step
<Papierkorb>
Groogy: I'm actually interested, it's curiosity first and foremost, to build a simple-ish 3D editor in Crystal, using Qt for UI. The missing part would be a usable 3D engine, though you're right now covering that part. Not as competition to Maya or anything, just as demo what can be done with Crystal.
<FromGitter>
<abidon> Hi guys, how can i write a Slice(UInt8) to IO in binary format, actually it writes something like this: `Bytes[130, 170, 108, 97, ...]`
<Papierkorb>
And that it may be a viable candidate for GUI programs in a few years time
<Papierkorb>
abidon, you're probably using IO#print. Use IO#write instead for this.
<Groogy>
Well mine will be a full framework for input, and so on
<Groogy>
so it might be a bit heavy weight but you could probably use only parts of it
<Papierkorb>
I've used Qt for some years, now I'm binding it. I never understood the "muh lighweight" fanatism anyway.
<FromGitter>
<bew> Papierkorb, ok, I'll wait for your first release, it might be clearer to read code.. nice idea to do a simple big-software to showcase possibilities
<Groogy>
actually now that I think of it, could probably write a backend implementation for your Qt binding
<Groogy>
and that way hook in everything to work as Qt expects it
<Papierkorb>
Yo that'd be QGLWidget for OpenGL, or we can also grab a handle to a native widget container, which gives you a window handle to draw in
<Papierkorb>
Which would neatly abstract away the remaining part of the platform-specific code :3
<Groogy>
yeah don't think it would be that hard to integrate stuff into your Qt project
<Groogy>
would just need to implement a QtOpenGL backend compared to the GLFWOpenGL backend I have right now and tell the framework to pick that backend
<Papierkorb>
For OpenGL there's already something in Qt. It'll give you a context and then you go wild
<Groogy>
yeah the backend in my framework is just what handles the low-end magic so you don't have to care like what opengl command to use, etc.
<Papierkorb>
Or one does that manually, which isn't too bad either
<Groogy>
it just needs a opengl context to have been created (Which Qt does)
<FromGitter>
<bew> also, what is the second request for? what do you get from it?
<FromGitter>
<Qwerp-Derp> How do I convert `real_fn` to something that isn't a closure?
<Papierkorb>
Qwerp-Derp, by not catching any variables in the boy
<Papierkorb>
body*
<Papierkorb>
Doesn't `UI` do proper proc wrapping..=
<Papierkorb>
?
<FromGitter>
<Qwerp-Derp> ???
<FromGitter>
<Qwerp-Derp> I'm making objects for the LibUI binding
<FromGitter>
<Qwerp-Derp> Do you need all of the code?
<Papierkorb>
Oh well, that looks "fun". You see that `data` argument passed in?
<FromGitter>
<Qwerp-Derp> Yep
<Groogy>
you could pass in fn there
<Groogy>
guessing it is the nil argument
<Papierkorb>
You have to pass the `fn` through that (that'd be the nil in your call below), but you *need* to Box it. Have a look in the C binding docs, it's documented how
<FromGitter>
<Qwerp-Derp> I'll have a look, I'm a complete noob to C though
<FromGitter>
<Qwerp-Derp> So I would set `data` to a boxed version of `fn`?
<Papierkorb>
yes, and in your real_fn, you unbox it to get the `fn` back, which you then call
<FromGitter>
<Qwerp-Derp> How do I set `data` though? Do I set it through the default argument value?
DTZUZO has quit [Ping timeout: 248 seconds]
<Papierkorb>
See that `nil` you pass to UI below? What pointer you pass there will end up as `data`
<FromGitter>
<abidon> I was using `io << bytes`
Groogy has quit [Quit: WeeChat 1.9]
rohitpaulk has joined #crystal-lang
<crystal-gh>
[crystal] MakeNowJust opened pull request #4852: Correct chained comparison `to_s` to fix #4708 (master...fix/crystal/to-s-comparison-correctly) https://git.io/v5vvl
<Papierkorb>
RX14: Yeah, public TechPreview Monday or Tuesday
<RX14>
could you give an overview of the obstacles you had?
<Papierkorb>
"C++". Hard to tell what'd be an obstacle, I've done C++/Qt for a few years, so I still know most of the ways. Most of it was coming up with a way of mapping that to Crystal. The most annoying part was probably getting Clang (or rather, the clang-based parser) to tell me what's an Qt signal, so I can map them as such.
<RX14>
doesn't qt use a preprocessed C++?
<RX14>
are you talking about extracting what's a signal from that?
<Papierkorb>
In the end, C++ and Crystal are both static languages. Thankfully, C++ is stricter than Crystal, so that's useful. I fought a bit with how I'd realize ownership (GC), but then I figured I could simply use the C++ bindings of Boehm, which works great - for now at least
<RX14>
so i assume you autogenerated most of the bindings?
<Papierkorb>
I auto-generate almost exclusively
<RX14>
thats good
<Papierkorb>
The manual binding part comes down to making some "left overs" nicer. Like getting QApplication to grab the ARGV_UNSAFE automatically, and doing that in a "correct" way.
<Papierkorb>
Well yes and no. C++/Qt is not preprocessed. What it has is the "moc", which generates meta-data for runtime reflection of QObject based classes.
<Papierkorb>
That doesn't interfere at all with the binding generation. We happen to collect similar data in parts of course.
<RX14>
well i'm glad someone who knows QT is doing these bindings
<Papierkorb>
Which gets me to a fun fact: In the future, I'll try to generate this meta-data in Crystal. Then those classes will look completely native to Qt at run-time.
rohitpaulk has joined #crystal-lang
<RX14>
i've always thought of doing it myself but I never did C++ Qt so i'd have to learnt hat first
<Papierkorb>
For that we just have to re-implement the correct virtual methods, and subsequently, the API of that. Nothing out of the ordinary, just fun macro magic
<Papierkorb>
And as virtual method overloading from Crystal already works, that's perfectly possible
<Papierkorb>
Hopefully the bindgen will evolve into something more and more poweful, covering larger sets of C++ features and eventually C. Much of the required features should already be in, it's about 70% work in the crystal-part of the bindgen, and 30% in the C++ part I'd estimate.
<RX14>
and this isn't open source yet?
<Papierkorb>
-> TechPreview
<RX14>
yeah but what exactly does that mean
<Papierkorb>
the technology preview will act as "beta" of sorts. Free software, hosted in github code-wise. It's just a label to say "not done yet, things may crash, etc."
<RX14>
so you're going to open source it monday or tuesday but in an alpha state
<Papierkorb>
Pretty much
<RX14>
i find that much more descriptive than "TechPreview"
<FromGitter>
<bew> there will be a Papierkorb I/O conference in San Francisco ?
<Papierkorb>
But then there's still tons of things to do. With that state though, you'll be able to use most features of Qt (those already bound). The Qt integration into LibEvent can then happen in Crystal code, which is one of the many things not part of the TP
<Papierkorb>
bew, nope
<RX14>
Papierkorb, so there's a general-purpose C++ bindings generator fit for binding Qt to a high level, and Qt bindings as a shard with some custom code to fill the small gaps?
<FromGitter>
<bew> bindgen will be part of that techpreview?
<Papierkorb>
bew, Yes
<FromGitter>
<bew> nice!
<RX14>
what are the implications of Qt not being integrated into LibEvent yet
<Papierkorb>
RX14: Yep. I developed both alongside. Will probably spin off the bindgen into its own project before publishing.
<RX14>
does it mean IO is going to hang the UI thread or something?
<Papierkorb>
RX14: No fibers, the crystal world just "stops" and will only run when called by Qt, e.g., when it sends a signal you're connected to
<RX14>
so fibers will segfault or what?
<RX14>
does Qt spawn it's own UI thread or use the default thread for it?
<Papierkorb>
Fibers just never get run after you start Qts event loop
<Papierkorb>
it uses the thread you start it in
<Papierkorb>
But it can be integrated with libevent, and that is the correct way that'll have to happen. It's one of the goals for the "usable release"
<RX14>
surely if you block on IO in the signal handler you'll get fibers run
<RX14>
obviously it won't be very... deterministic but
<Papierkorb>
RX14: No, Qt uses its own event loop (by default, can be replaced), which does everything libevent does. It never reaches libevent after that line
<RX14>
oh yeah because the main fiber never blocks there will always be something on the scheduler stack
<RX14>
so you never get to libevent
<Papierkorb>
RX14: Will be unavailable for the next 6hrs or so, we can talk tomorrow though when I'm there. If you have questions, best /query them, so I'll actually get them lul.
<RX14>
yeah ok
<RX14>
i'll just wait for the source code lol
<RX14>
would be nice to know exactly how you plan to integrate the 2 event loops though
<FromGitter>
<bew> I'm waiting for that too :P
<FromGitter>
<bew> I hope it'll still work one way or another when multi-threading will be a thing in Crystal
<RX14>
I still havent asked
<Papierkorb>
RX14: though w.r.t challenges, choices etc, I'm planning on documenting tons of it, or if I finally get around starting a blog, write about it there too. Pretty sure many of the solutions can be adapted to other things, or improved otherwise
<RX14>
I still havent asked about how possible it would be to implement threads in crystal before we have a n:m scheduler
<FromGitter>
<codenoid> hi there, anybody know how to setup Dynamic IP for Crystal HTTP Client, & i run in ubuntu 16.04
<RX14>
Papierkorb, really well done high-level Qt bindings that aren't C++ but are compiled and statically typed are something that I think would bring a lot of people to crystal
<FromGitter>
<bew> @RX14 what is a n:m scheduler?
<RX14>
scheddules m fibers onto n OS threads
<RX14>
we currently have a 1:n scheduler
<FromGitter>
<bew> oh I see
<RX14>
which is many fibers on 1 OS thread
<Papierkorb>
RX14: Absolutely, see above for an idea of a showcase program ("small 3D editor") as proof for its viability. I think the language is on to something in the desktop application industry.
<RX14>
"small 3D editor"?
<FromGitter>
<bew> RX14 you mean: m:1 ?
<FromGitter>
<bew> oh no nvm
<RX14>
idk
<RX14>
you get the idea
<FromGitter>
<bew> yep thanks
<RX14>
regardless of the way around it is lol
rohitpaulk has quit [Ping timeout: 240 seconds]
relaxbox has joined #crystal-lang
<FromGitter>
<codenoid> ok,
rohitpaulk has joined #crystal-lang
fenicks has left #crystal-lang [#crystal-lang]
<watzon>
Yeah Papierkorb! Qt is looking good!
<crystal-gh>
[crystal] asterite pushed 1 new commit to master: https://git.io/v5vY7
<RX14>
surely the best dev support is running the same OS as your servers?
<RX14>
plenty of windows apps that don't run on mac too
<FromGitter>
<krypton97> Like?
schovi has quit [Client Quit]
<RX14>
i;d prefer windows at this point since at least you get windows + linux
<FromGitter>
<krypton97> I hate winodows
<RX14>
which is a bigger cross-section of programs than linux + mac
<FromGitter>
<drujensen> @RX14 I can run all three from a mac, so I agree with you completely
<FromGitter>
<schovi> Hello. I am trying to run postgres with crystal and found some unconsistency against documentation. Having simple query ⏎ ⏎ ``` code paste, see link``` ⏎ ⏎ how to resolev this? [https://gitter.im/crystal-lang/crystal?at=59989550162adb6d2e12ace8]
<RX14>
try a Float64
<FromGitter>
<drujensen> yeah, looks like a type mismatch
<RX14>
I think mac is still too opaque to me
<RX14>
not as bad as windows but still
undy1ng has joined #crystal-lang
<FromGitter>
<drujensen> I live in the terminal most of the time
<FromGitter>
<drujensen> vim
<FromGitter>
<schovi> Float64, Int64, Int32 Nothing works
<RX14>
i don't think i'd mind mac but i've been using a highly-customized linux wm as my only desktop OS since i was 14
<RX14>
so i'd find it hard to change at this point
<FromGitter>
<drujensen> haha, I used redhat and ubuntu for 10 years as my only dev platform
<FromGitter>
<drujensen> moved to the mac and never went back.
<RX14>
well i run i3 with customised keybinds so it's probably harder for me
<FromGitter>
<drujensen> plus i wanted to build iOS apps so didn’t really have a choice. :-)
<RX14>
as in, I use capslock + shift + q to close programs
<FromGitter>
<drujensen> gotcha, yup.
<RX14>
i'd just virtualise osx
<FromGitter>
<drujensen> hardest thing was getting used to keyboard changes
<FromGitter>
<krypton97> I couldn't find a free bugs linux distro
<FromGitter>
<johnjansen> like including the same code and the same ... but i need it to be an Int32 for convenience conversation ... which BTW i slightly disagree with
<watzon>
Hmm. I don't remember ever needing something like this before
<FromGitter>
<johnjansen> given you will either have to clamp (https://github.com/johnjansen/clamp) the values to 255 and silently limit the range, or alternatively raise when the value is out of range ... effectively forcing them to trap and test anyway (removing any convenience you gave them)
<FromGitter>
<johnjansen> hmmm maybe it wasnt you ... but someone had RGB values and precisely the same issue ... hmmm
havenwood has left #crystal-lang ["Bye!"]
<watzon>
Ahh I do think I remember a similar conversation now that you bring up clamp
<watzon>
But it's not really necessary for this example. I'm just doing a small code sample using Crystal to create a "Bitmap" which is really just a multi-dimensional array of pixels
<FromGitter>
<johnjansen> just use UInt8 and let the type system do its job
<FromGitter>
<johnjansen> it accurately represents the allowable data after all
<watzon>
That's true
<watzon>
I wish the compiler could perform some automatic casting though
<FromGitter>
<johnjansen> how
<FromGitter>
<johnjansen> you are just moving the problem
<FromGitter>
<johnjansen> i pose you this question; ⏎ if you use Int32 (as you propose), and i give you 400, 600, 800 as values ... what do you do?
<watzon>
It would be nice if you could say `def myfunc(num : Int8) ...` and then call it with `myfunc(12)` rather than `myfunc(12_i8)`
<watzon>
Throw an ArgumentException
<FromGitter>
<johnjansen> so you force them to test their values and / or trap anyway right?
<watzon>
Yeah
<FromGitter>
<bew> @watzon this is an open issue: #2995
<FromGitter>
<johnjansen> so, wouldnt it be easier for them to just make them the correct type and not do those things?
<watzon>
Oh good bew. Thanks
<FromGitter>
<johnjansen> im not sure about that ticket personally
<watzon>
Yeah, but I agree with oprypin in that issue. I don't think number literals should be bound to Int32 and Float64
<FromGitter>
<johnjansen> it also doesnt help your problem
<FromGitter>
<johnjansen> maybe ... its complicated
<FromGitter>
<johnjansen> so one thing you can do right now, is clamp the values into range, discarding higher or lower values, and dont fail
<watzon>
Why not? I feel like it would work in my case. I could then say that the method take an Int8 and if they try and put in a value bigger than 255 it should thow an exception, right?