<FromGitter>
<bararchy> Wait, does Hash has a `Hash#[key]?` metohd to check if the key exists without call `.has_key?` mu life was a lie
<FromGitter>
<cevarief> @bararchy That returns all hash content
<FromGitter>
<bararchy> Yeha, played around with it, amazing
<FromGitter>
<bararchy> didn't know about this method before
<FromGitter>
<cevarief> How it works?
<FromGitter>
<cevarief> isn’t that # means comment, so the rest after that char will be ignored
<FromGitter>
<codenoid> is i'm right ? `context.response.status_code = 404` (integer status code), but when i check in the web browser, the browser send `200`
<FromGitter>
<codenoid> lol, i write that after `context.response.print`
<FromGitter>
<bararchy> @cevarief Oh, the `#` symbolizes a method call on an instance of a Class. ⏎ Like here: like `String#gsub`, etc ..
<FromGitter>
<bararchy> it's not a literal `#`
<FromGitter>
<bararchy> The actual code is ofc `String.gsub`
<FromGitter>
<cevarief> Now i’m starting to like exploring crystal api 😄
<FromGitter>
<codenoid> hmm, i want make a simple proxy server, working fine in localhost, but when i deploy with public ip, my app returning bad gateway, etc ⏎ https://github.com/codenoid/kuking
<Papierkorb>
codenoid, just FYI: There are scan bots out there looking for public proxy servers, for people to proxy mostly less-than-legal stuff over it
<FromGitter>
<bararchy> True, you should add user&pass auth before publishing
<Papierkorb>
codenoid, really, just "publish" it in your *private* LAN, or just locally for testing.
<Papierkorb>
Least things that can go wrong that way
<FromGitter>
<bararchy> when you call `file` on it, does it say "dynamicaly linked" ?
<RX14>
and this way people will be using their system libraries
<RX14>
we won't be distributing any libraries other than libgc.a
<RX14>
which is how it should be
<RX14>
@bararchy yes and that's why i'm confused
<FromGitter>
<codenoid> btw, is crystal really need other web server for resource who coming from public ip ? , I do not think so :/
<RX14>
well probably not
<RX14>
but probably isn't good enough
<RX14>
you put a web server in front so you can say definitely
<RX14>
and leave someone else to prove out crystal in production
<FromGitter>
<bararchy> I would put the Crystal server in the front
<FromGitter>
<bararchy> :)
<FromGitter>
<bararchy> But i'm brave
<FromGitter>
<bararchy> I'm the "someone else" hahah
<RX14>
well I need a reverse proxy regardless because I have many vhosts
<RX14>
also SSL termination
<RX14>
so yeah
<FromGitter>
<sdogruyol> nginx is just built for that kind of job
<RX14>
SLL termination is much easier in stuff like nginx if you use LE
<FromGitter>
<sdogruyol> so why not just use it
<FromGitter>
<bararchy> Oh, that's something else then, I built a Reverse proxy with SSL offload and rewrite based routing from scratch in Ruby, might try to do something similar in Crystal as a side project
<RX14>
or just use an existing one?
<RX14>
I don't see the point in rewriting the same thing again and again in different languages
<FromGitter>
<codenoid> then why my crystal server was not able to work with crystal own server :/
<RX14>
we have nginx and we have caddy and they're both fantastic web servers
<FromGitter>
<bararchy> Well, following the same logic, why should we have Crystal if we already have C, C++, Ruby, Python, Go, Rust ...
<FromGitter>
<bararchy> XD
<RX14>
because crystal does something different
<FromGitter>
<codenoid> like ? :shipit:
<RX14>
and whatever you're going to write likely does not
<FromGitter>
<bararchy> Also , the best answer if "for fun and evolution of software" , any new "rewrite" is an upgrade, even just by testing the logic again, Nginx is a re-write of Apache, but better
<RX14>
if you're going to write a HTTP proxy to do something special go ahead
<RX14>
but if you're going to write it just because it's in crystal don't bother
<RX14>
unless it's a learning project
<FromGitter>
<codenoid> for me "Abusing computer (crystal++) for fun and profit"
<FromGitter>
<codenoid> crystal it self is something special, and i use to build something special with something special , :D ✨
<FromGitter>
<bararchy> btw, RX14 you can also say the same thing about Kemal or Amythists, it's just a rewrite of Rails\Sinatra on Crystal
<RX14>
yes but that's a library
<FromGitter>
<bararchy> But I think that those things are important
<RX14>
it's differentiated by being written in crystal
<FromGitter>
<bararchy> Well, I can do a reverse proxy lib
<FromGitter>
<bararchy> as in a shard form
<FromGitter>
<bararchy> that can allow you to use it programiclly
<RX14>
sure that'd be useful
<RX14>
but if nginx fits the bill then i'd always use nginx
<RX14>
the best solution is the one which already exists
<Groogy>
Like Boleite is just my rewriting the backend I wrote ages ago in D in Crystal
<Groogy>
but with more Crystal idioms
gewo has quit [Ping timeout: 240 seconds]
<Groogy>
like I love working with OpenGL objects now
<Groogy>
instead of binding and unbindng manually
<Groogy>
I just do shader.activate { do_stuff }
<FromGitter>
<bararchy> @veelenga Nice work with the Amythist repo
<FromGitter>
<bararchy> it's nice of @Codecore to transfer hes repo to the crystal-comunity
<FromGitter>
<bew> what is this crystal-community GH organization anyway?
<FromGitter>
<krypton97> Good question
<FromGitter>
<jwaldrip> hmm, crystal doesnt currently parse timezone from 8601: Time::Format::ISO_8601_DATE_TIME.parse("2017-08-22T12:56:45-07:00")
<FromGitter>
<jwaldrip> it returns the proper time, just not with the TZ i specified
<FromGitter>
<asterite> it's because Time doesn't have a timezone, it's just UTC or Local
badeball has joined #crystal-lang
<FromGitter>
<bararchy> @ary just have to say it , it's really really awsone seeing you back in the crystal tranches :)
<FromGitter>
<bararchy> @bew @krypton97 , its an open group to support big dead projects that the original maintainer left or stopped maintaining
<FromGitter>
<bararchy> In this way there is no stage where a relevant project sits idle while PRs are getting stacked up
<FromGitter>
<codenoid> greatt ✨ 👏
sz0 has quit [Quit: Connection closed for inactivity]
<FromGitter>
<totakaro> It's useful on VSCode extension by example, I'll write some documentation about.
<watzon>
Well would you look at that. My project is useful 😁
oprypin has quit [Quit: Bye]
oprypin has joined #crystal-lang
rohitpaulk has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 240 seconds]
<crystal-gh>
[crystal] MakeNowJust opened pull request #4871: Allow assignment to class var when fit this class var types of ancestors (master...fix/crystal/allow-assign-class-var-if-fit-ancestors-type) https://git.io/v5kTs
flaviodesousa has quit [Remote host closed the connection]
Excureo has joined #crystal-lang
<FromGitter>
<jwaldrip> @straight-shoota Made some updates the YAML PR, thank you so much for your feedback thus far.
<oprypin>
now that's worthy of a bountysource, unlike that guy wth an empty repo xD
<Papierkorb>
Atom-editor also has a memory leak which is obvious when working with large files.. So yeah, I used Kate to read those, which had none of such issues
<RX14>
oprypin, yeah that was hillarious
<RX14>
>atom
<RX14>
use a real editor
<oprypin>
he used Kate, seems good
<Papierkorb>
Now, this really is a TechPreview: There are things to do, but also, infrastructure questions. I want people be able to just drop in a dependency in their shard.yml, run `crystal deps`, and it just works™. I think this is the biggest hiccup that could turn people away otherwise.
<oprypin>
what's #define fake enumerations again?
<Papierkorb>
Qt has QMake, which is pretty near that for C++ .. as long you stick to Qt lul.
<Papierkorb>
C-style "enums" “I didn't know there's enum in C too”
<oprypin>
that was my main guess but what's the context on it?
<oprypin>
does Qt use it somewhere and you want to bind it or what
<Papierkorb>
When bindgen grows into a solution for C projects, it'll have to support it somehow
<oprypin>
ah whatever
<wmoxam>
0
<Papierkorb>
oprypin: Completely irrelevant to Qt, thankfully
<oprypin>
well it's actually almost never usable out of the box, the defines can be random chunks of code, it's the weirdest problem to solve for sure
<Papierkorb>
And the Clang API for macros is "uargh"
<Papierkorb>
RX14: atom is up till now the least-worst editor I use. QtCreator is only for C++ :(
<RX14>
i heard vscode was pretty good
<Papierkorb>
> Microsoft
<RX14>
i judge projects on their qualities
<RX14>
not who made them
<RX14>
but vim/emacs are the true editors anyway
<oprypin>
RX14, this is not the time :(
<RX14>
it's always the time!
<oprypin>
the most important library binding has been made
<RX14>
and i'm shitposting about editors, yes
<oprypin>
Postinstall (cd clang && make) && crystal deps build -- yeah also dont like this part
<Papierkorb>
Ah man, I forgot to mention in the readme that bindgen does support QFlags
<oprypin>
Papierkorb, how would you feel about Windows support tho
<Papierkorb>
oprypin: How should it be done otherwise? The clang part needs to be there, and if you run bindgen again and again while not dev'ing bindgen itself, the wait time for crystal really adds up
<RX14>
"A class depending on another class should follow *after* its dependency." can't you have circular dependencies in C++?
<oprypin>
well the way I did it was to require manual intervention
<oprypin>
RX14, you can
<Papierkorb>
oprypin: Violates "just works"
<Papierkorb>
RX14: Technically yes, in reality "Really?!"
<oprypin>
class A; class B {}; class A {};
<RX14>
nice
<Papierkorb>
That's not circular
<RX14>
well no because neither class has members
<oprypin>
`class A; class B { A* a}; class A { B* b};`
<oprypin>
happy now
<Papierkorb>
RX14: Or, mh no I don't think so
<Papierkorb>
oprypin: That's not a circular dependency in terms of inheritance
<Papierkorb>
Which I was playing at there. Have to improve it if that's not obvious
<oprypin>
so that's the thing, RX14 probably didnt mean as inheritance
<Papierkorb>
RX14: Well, C++ has virtual inheritance so .. erm .. maybe
<RX14>
oh no
<RX14>
circular inheritance?
<RX14>
that beaks my brain
<oprypin>
that's just nonsense
<Papierkorb>
virtual inheritance doesn't?
<oprypin>
and now i get to sleep and then work all day :>
<Papierkorb>
bindgen_helper.hpp -> ../lib/X - Assumption broken. Come on, I just wanted it to point at the correct version of that file for the normal use case
<oprypin>
but the lib is at the very top level
<oprypin>
postinstall is a huge pain
<oprypin>
like, actually unusable
<oprypin>
as soon as you hit c++ you need a build system to wrap it all
<oprypin>
and you are gonna need it to support Windows anyway
<Papierkorb>
There needs to be a way to build dependencies in shards. What it is I don't care. I just don't wanna do `{{ run ".." }}` hacks in some random crystal source file
<oprypin>
cmake lul
<Papierkorb>
qmake lul
<Papierkorb>
Might actually work, for Qt that is
<RX14>
oprypin, why is is unusable?
<RX14>
libs being weird?
<oprypin>
RX14, not cross-platform by design
<RX14>
s/libs/lib/ ?
<Papierkorb>
Though w.r.t. Windows, really, that shall be the headache of the Windows maintainer, who I don't plan to be. Last thing I want to do is mess with Windows "development" environments
<oprypin>
Papierkorb, it's fiiiine
<RX14>
oprypin, yeah i guess
<oprypin>
as long as you use a cross platform build system and not makefiles
<RX14>
thing is in windows not everything ends up on PATH
<oprypin>
so it forces you to break assumptions that you shouldn't have had in the first place?
<RX14>
and stuff is kinda designed around IDEs using the build tools
<RX14>
mostly the microsoft tools
<Papierkorb>
^
<RX14>
uhh cmake being on the path is a pretty good assumption
<RX14>
how else do you find it?
<oprypin>
you let the user find it
* Papierkorb
thinks of a file open dialog
<Papierkorb>
bwahaha
<RX14>
no
<RX14>
you don't use windows
<RX14>
it's a terrible development platform
<oprypin>
RX14, you dont know me
<RX14>
Papierkorb, that's probably what most windows users want you to do
<RX14>
and thats terrifying
<Papierkorb>
RX14: To be honest, Qt makes it actually quite usable with their online installer setting the whole thing up. Really good.
<RX14>
yeah and it adds itself to path right?
<RX14>
more than can be said for visual C++
<Papierkorb>
Not sure, long time since I had to use it
<RX14>
it generates like 15 random batch files which drop you into a shell with the tools in
<RX14>
because that's infinitely composable
<oprypin>
i liked it :>
<Papierkorb>
No idea if it's true, but it's hilarious in any case
* oprypin
confirms
<RX14>
one shell for each cross-compile target
<RX14>
it's terrible
<oprypin>
"Visual C++ 2015 x64 Native Build Tools Command Prompt"
<Papierkorb>
Oh, that shit?
<RX14>
and good luck getting it to work with a decent terminal emulator
<Papierkorb>
RX14: But muh play button D:
<Papierkorb>
ayy lmao
<FromGitter>
<sdogruyol> lol
<oprypin>
Papierkorb, no the play button is one thing, and it used to be the only thing
<RX14>
play button?
<Papierkorb>
RX14: in IDEs
<RX14>
oh
<RX14>
ye
<oprypin>
but now they're so nice to actually provide usable command line tools that you dont need visual studio project files for
<RX14>
i forgot
<RX14>
ides don't exist on linux
<RX14>
oh wait
<Papierkorb>
They do?
Excureo has quit [Remote host closed the connection]
<RX14>
who knew you can have the best of both worlds
<RX14>
all it takes is sensible design
<oprypin>
for some reason i have an undefeatable urge to get this Qt binding working on Windows
<RX14>
sure get it working
<oprypin>
Papierkorb, in theory, do you think pre-generated c++ code has a chance to work unchanged?
<RX14>
then you write down the 200 step process
<RX14>
and forget all about it
<Papierkorb>
Do it, and involve us in your rants about Windows "development" environments, cause that's helping the project and hilarious at once. Win win
<oprypin>
im not ranting about anything
<Papierkorb>
oprypin: It should
<Papierkorb>
Oh you will
<wmoxam>
^^^
<oprypin>
i don't know what you extrapolate that from
<Papierkorb>
oprypin: The generated sources don't do anything special - Except if Qt does via #ifdef of course. QWidget might be a "candidate" for that
<Papierkorb>
type WId, windowHandle() or what it was called, may break your build
<Papierkorb>
Eh, just throw it out. ¯\_(ツ)_/¯
<oprypin>
I see it only in qt5/qt.yml: WId: { ignore: true }
<oprypin>
so how would it break anything?
<Papierkorb>
See? How nice I was to already include that ignore there?
<oprypin>
what makes QPoint deserving of its own Crystal file?
<Papierkorb>
For types like QPoint, QRect, etc., I didn't think it makes much sense to do a round-trip to C++ all the time. Especially as their APIs are small.
<oprypin>
oh ok
<oprypin>
so basically you have everything stored by pointer but in these few instances you did "composition"
<oprypin>
oh yeah, forgot all about C++ templates - how do they work?
<Papierkorb>
They're normal classes after instantiation
<oprypin>
yeah but you can't instantiate it for all possible parameters
<RX14>
I found out today that LLVM exposes triple normalization
<Papierkorb>
Of course not
<RX14>
so maybe we'll manage to actually get a decent handling of target triples
<oprypin>
that's what im wondering about, how do you provide bindings to template classes
<Papierkorb>
But you know which possible parameters make sense, and those you can instantiate
<oprypin>
or is it on a case by case basis because QList is useless etc
alibby1 has quit [Quit: Leaving.]
<oprypin>
i'm seeing a lot of Enumerable near QList
<Papierkorb>
The templating feature focuses on containers (right now, only sequential ones), and even there the API is the minimum required to do something useful. If a user wants to really work with the data, just turn it into an Array
<Papierkorb>
Yeah it's Enumerable, which is why you probably won't even notice it's not an Array
<Papierkorb>
Enumerable() is just what the user is allowed to pass in
<Papierkorb>
It then tries to upcast, else, does the #each loop.
<oprypin>
I mean the return types. though they probably are ignored by Crystal anyway
<Papierkorb>
Oh that, fair point. Indeed, they are. And that's a current shortcoming, you can only define one type on each "layer" (Wrapper, Binding, C++), and not one for in and out each
<oprypin>
mhm
<Papierkorb>
Question is, have you already tried the amazing image viewer sample program?
<oprypin>
actually i did mere seconds ago
<RX14>
actually i need to try this
<RX14>
i'd rather the repo was named crystal-qt5 or something though
<oprypin>
for sure
<RX14>
i prefer the .cr suffix actually
<RX14>
because it's easier to tab complete
<oprypin>
not worth it
<RX14>
ls -1 /data/programming | wc -l
<RX14>
259
<RX14>
:(
<oprypin>
/data
<oprypin>
:(
<Papierkorb>
:(
<RX14>
/home is an overloaded directory
<wmoxam>
lol
<RX14>
everything shoves it's dotfiles and stuff in there
alibby has joined #crystal-lang
<RX14>
I have control over /data
<RX14>
plus - /home benefits a LOT from being on a SSD
<Papierkorb>
I just have ~/Projekte ("Projects"). Fixed.
<RX14>
whereas your programming projects are likely just wasting space
<wmoxam>
tru
<RX14>
well it's too late to change now lol
<Papierkorb>
Not worth thinking about
<Papierkorb>
It's not like I'm using nodejs which would actually trash my ssds
<oprypin>
> re naming: that's not even my main concern, i'm just saying it's not clear what your repository is about. is it a fork of qt?
<Papierkorb>
`qt5.cr` would be acceptable. I despise the `LANGUAGE-` prefix. Plain ugly. "qt5.cr" is at least what you almost write in the require afterwards
<RX14>
yes i agree with you there Papierkorb
<oprypin>
Papierkorb, sure, that applies to normal projects existing by themselves
<RX14>
i prefer cool names
<oprypin>
your project is crystal qt bindings. you call it qt.
<FromGitter>
<johnjansen> likewise … there should be a standard fir that
<FromGitter>
<johnjansen> fir
<RX14>
but sometimes just slapping .cr on the end does
<RX14>
just unpack to usr/local and you're all set
<Papierkorb>
.. I clicked on it, and Ark opened an embedded man-page reader with formatting. Damn this DE is amazing.
<RX14>
there's 56mb of html docs
<RX14>
which is almost as much as the compiler
<Papierkorb>
Oo
<RX14>
probably should have gzipped it
<RX14>
lol
<RX14>
compiler is 64MiB
<Papierkorb>
As big as a large N64 game
<RX14>
sourcecode is like 6MiB
<Papierkorb>
LLVM though
<RX14>
not llvm
<RX14>
just crystal src dir
<Papierkorb>
the crystal binary
<RX14>
oh yeah
<RX14>
it does have all of llvm in
<Papierkorb>
Which concerns a part of bindgen. I want it to generate a cpp per "section", probably per-class. Will help reduce resulting binary sizes a lot.
<oprypin>
Papierkorb, wouldn't it be better to do a cpp per qt module?
<Papierkorb>
No, there are only (right now) 3
<oprypin>
i dont see the problem
<Papierkorb>
The point is, the linker can leave out object files, if you never access them. It can't "split" them up though. There's reason to believe that most programs will never touch 60-80% of all wrapped classes (when the project reached near 100% coverage), so by leaving all of those out, you save a few megs
<Papierkorb>
binding.a is already quite large
sz0 has quit [Quit: Connection closed for inactivity]
<oprypin>
ok
<oprypin>
-> Stripping unneeded symbols from binaries and libraries...
<oprypin>
(was in my terminal scrollback) hint hint
<oprypin>
but yeah it's not the real solution
<Papierkorb>
the linker can only do so much. It can't throw much out, as it can't know if it's actually used even if it thinks it's not
<oprypin>
you're saying this as if QtWidgets isn't one shared library
<Papierkorb>
No it's not cutting out anything from Qt itself
<Papierkorb>
But the generated code also has size
<oprypin>
my point is why bother splitting object files if it's nothing compared to qt itself
<oprypin>
do you think it can speed up Crystal compilation?
<Papierkorb>
Sometimes I feel old, but I don't like wasting space for nothing. That's probably the C programmer in me lul.
<Papierkorb>
Nah
<Papierkorb>
That's pure linker related
<Papierkorb>
Method overloading deduction (aka, macro code, lots of it) increased compilation times though