ChanServ changed the topic of #crystal-lang to: The Crystal programming language | | Crystal 0.23.1 | Fund Crystal's development: | GH: | Docs: | API: | Gitter:
wes[phi] has joined #crystal-lang
wes[phi] has quit [Ping timeout: 240 seconds]
danielpclark has quit [Quit: Leaving]
<FromGitter> <georgeu2000> I got this error: ⏎ ⏎ ```code paste, see link``` []
<FromGitter> <georgeu2000> I checked `` but it is not clear to me how to apply the return type.
<FromGitter> <georgeu2000> ```code paste, see link``` []
<FromGitter> <ezrast> @georgeu2000 `sort_by` only takes one argument, or your last try would work.
<FromGitter> <ezrast> I think you just want `sort` with a block.
<FromGitter> <georgeu2000> Oh, that was easy. Thanks.
<FromGitter> <georgeu2000> What's the difference between `sort` and `sort_by`?
wes[phi] has joined #crystal-lang
andrewzah has quit [Quit: ZNC 1.6.5 -]
andrewzah has joined #crystal-lang
andrewzah has quit [Client Quit]
andrewzah has joined #crystal-lang
andrewzah has quit [Client Quit]
andrewzah has joined #crystal-lang
andrewzah has quit [Client Quit]
andrewzah has joined #crystal-lang
andrewzah has quit [Client Quit]
andrewzah has joined #crystal-lang
<FromGitter> <opensas> Sort recibes to ítems AND compares them
<FromGitter> <opensas> Sort_by receives one item and should return the expression to order items by
andrewzah has quit [Quit: ZNC 1.6.5 -]
wes[phi] has quit [Ping timeout: 246 seconds]
<FromGitter> <opensas> if you don't specify any block with sort, it will just use a <=> b
Guest34371 has quit [Ping timeout: 246 seconds]
pduncan has joined #crystal-lang
Guest34371 has joined #crystal-lang
rohitpaulk has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 248 seconds]
rohitpaulk has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 248 seconds]
andrewzah has joined #crystal-lang
snsei has joined #crystal-lang
<crystal-gh> [crystal] maiha opened pull request #4957: HTTP: respect gzip in serialization (master...http-gzip-serialization)
rohitpaulk has joined #crystal-lang
<crystal-gh> [crystal] splattael opened pull request #4958: Add CircleCI badge to README (master...badge/circleci)
Papierkorb_ has joined #crystal-lang
<FromGitter> <Qwerp-Derp> Is it possible to create something like CrSFML (i.e. a library that allows you to draw items on a window) in vanilla Crystal, without bindings to C files?
<Papierkorb_> You mean, a gui toolkit?
<FromGitter> <Qwerp-Derp> Pretty much
<FromGitter> <Qwerp-Derp> I'm just wondering if it's possible, because I might try to make something like that if it is possible
<Papierkorb_> Sure. You just need to implement the protocol of and connect to the server, and as Wayland is on the horizon, that too. Same for Windows and Mac OS.
<Papierkorb_> In theory possible, in practice, yeah no.
<FromGitter> <Qwerp-Derp> I wish Crystal had OpenGL bindings by default... :(
<Papierkorb_> For research purposes, sure go for it. But don't expect to "quickly" build a competitive (as if there aren't already enough) multi-platform gui toolkit from scratch by yourself in a span of under two years. Connecting to the display system of your platform isn't even the hard part (Though, for this, everyone uses `xcb` anyways - But you explicitly stated without C bindings)
<Papierkorb_> By default? For what? It's crazy enough there's an OAuth lib in the stdlib
<Papierkorb_> Groogy may know more on OpenGL
<FromGitter> <Qwerp-Derp> I really don't like dealing with C IMO, it's a pain to set up compared to Crystal
<FromGitter> <Qwerp-Derp> But I guess that's inevitable if you want to do GUI stuff
<Papierkorb_> Dealing with C isn't that much of a big deal
<FromGitter> <Qwerp-Derp> :(
<Papierkorb_> Bindings aren't the big deal. There are tons of binding generators already out there
<FromGitter> <Qwerp-Derp> It's just... I've only really dealt with languages with a package management system, such as Python, Crystal, Rust etc.
<FromGitter> <Qwerp-Derp> CMake is just awful
<Papierkorb_> C has one too. it's the one of your system.
<Papierkorb_> CMake ain't awful either. C/C++ projects tend to get big and seriously complex over time. Your build system has to be able to cope with that, while doing everything else too. And that with a configuration language that is powerful enough to describe all of this, while being maintainable.
<Papierkorb_> And it even does it cross-platform, which is both a necessity and a god-send
<Papierkorb_> There have been many projects which tried to put a "modern language" dependency manager into C++. Like, really, a ton. You may have never heard about any of those, as none reached critical mass, as none even got close to be able to support all the features necessary to build such big projects.
claudiuinberlin has joined #crystal-lang
mark_66 has joined #crystal-lang
Tuxified has joined #crystal-lang
<Groogy> Morning!
<Groogy> and I was mentioned
<Groogy> @Qwerp-Derp here is a OpenGL binding though not really maintaned (though the OpenGL interface is not gonna change within the next century)
HTTP_____GK1wmSU has joined #crystal-lang
<Groogy> I'll probably replace it with my own GL bindings eventually when Papierkorb_ gets further ahead with bindgen
rohitpaulk has quit [Ping timeout: 248 seconds]
<Groogy> and because of a quirk, if you just create the opengl context before you access any of the functions it will all be bound correctly and you don't need things like GLEW etc.
HTTP_____GK1wmSU has left #crystal-lang [#crystal-lang]
alex`` has joined #crystal-lang
<Groogy> or well you will need to implement some stuff GLEW does itself, but the quirk is that it is resolved on first invocation by the ld (so might work differently when we get to Windows)
A124 has quit [Read error: Connection reset by peer]
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Papierkorb_> Groogy: Ohhh for OpenGL I have an accidential feature in the next revamp you may enjoy.
<Papierkorb_> Bindgen: Complete only with accidential plugin support. Oh well.
<Groogy> lol
<FromGitter> <bew> Accidental? x) what kind of plugins?
<Groogy> also Papierkorb to reclaim your name, if it is a registered one you can use GHOST on nickserv
<Groogy> it will kick the user using the name so you can rename your current session
<Papierkorb_> Groogy: Oh I'm at work and don't have my credentials to the bouncer here
<Papierkorb_> And don't wanna kick the bnc as I don't know how it'll cope >_> ... Yeah I probably should just login here heh.
<Groogy> also what is the accidental feature?
A124 has joined #crystal-lang
rohitpaulk has joined #crystal-lang
<Papierkorb_> Well I'm copying more architectural ideas from compilers (I'm sure you could make the point bindgen is a really specialized compiler of sorts). It now has something near what compilers call AST, though I call it the Graph - It's still a recursive structure to represent the to be generated tree of classes and methods. A core part is (will be) "processors", which are basically visitors for this tree and are there to augment it. Besides the
<Papierkorb_> already known features like wrapper generation (which are also done by them). For things like opengl, you could use it to unmangle the OpenGL function name in the wrapper.
claudiuinberlin has joined #crystal-lang
<Papierkorb_> Before that, there wasn't really a unbounded recursive representation structure. This allows stuff like defining inner classes in the wrapper, which the currently public version doesn't support.
<Groogy> well the thing is that if the function is not supported on your hardware, you'll get linkage error. Which you won't get in Crystal atm because it resolves the linkage on first usage from what I can gather
<Groogy> are there a global processor?
<Papierkorb_> Crystal only instances methods you use. *all* methods are instanced, even if you set all types explicitly
<Groogy> i.e I could add a step run at start which does a lookup on what features are supported?
<Papierkorb_> In theory, you totally could do that
<Groogy> No it is not Crystal itself, it is the ld
<Groogy> crystal links to the so library lazily meaning it only resolves upon first use of a function
<Papierkorb_> There's already `Processor::FilterMethods` which throws out methods that it can't wrap (or the user doesn't want). Your processor would do something really similar, as far bindgen is concerned
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Papierkorb_> All of this also allows for auto-generating a smoke test to make sure the bindings at least link at all, a feature I'm much looking forward to. (Not part of the first release)
<Papierkorb_> Hopefully someone feels like fixing crystals ABI issue in the near future..
<Groogy> so the bindgen what it does is generate a C library for you to link against and the Crystal lib module?
rohitpaulk has quit [Ping timeout: 246 seconds]
<Papierkorb_> You mean how it operates in general to bind to C++?
<Groogy> or C (like OpenGL)
<Groogy> like I want to bind to C but with some extra stuff added to it
<Groogy> what GLEW does is just set function pointers in a header that overrides the OpenGL ones based on if you support something or not at runtime. Then those function pointers is what I would want to expose
<Papierkorb_> Right now, it's C++ centric. So, yes it basically generates a giant `extern "C"` library wrapping all of the methods. C doesn't require this. But it may still use it for some things, as bindgen allows you to define custom converters for Crystal <-> C++ - In both Crystal and C++. I don't know yet exactly how I'll do this for C.
<Groogy> oh actually how about adding processor for the Crystal side of the generation?
<Groogy> then I can put that logic in Crystal and throw an exception if the feature is not supported
<Papierkorb_> Function pointer support isn't there yet. Haven't thought about it much yet how to wrap them. It's possible though.
<Papierkorb_> You can totally do that. You control the graph, and you can (but don't have to) even control how each part will "look" in the output file(s). So even custom logic is possible. In fact, it's basically how it'll operate :)
<Groogy> because what GLEW avoids is the linkage error, but as long as we don't access the function it's fine. so all I need to do is check for support and throw exception if used function is not supported
<Groogy> which I think woould be me Crystal-esque
<Groogy> just make each OpenGL call a Proc on Crystal that you call which by default will throw an exception. Then those proc's are replaced based on if command is supported or not
claudiuinberlin has joined #crystal-lang
<Papierkorb_> Groogy: I'm really interested in general to get good GL bindings in Crystal. I think we'll get something to work in the future.
<Groogy> yeah I just want this to be automatic because there's SO MANY CONSTANTS and SO MANY FUNCTIONS
<Papierkorb_> #define constants I guess?
<Groogy> yepp
<Papierkorb_> Those will be "fun" to teach the clang tool. I mean one needs it for C libs, but oh god why do they suck so much to work with
<Groogy> *sigh*
<Groogy> also speaking of graphics, I had an argument with a person on the internet and you know that is the most important thing to prove him that he is wrong
<Groogy> so I made a software renderer in Lua
<Groogy> (Was on a game forum, an MMO that will let you script things in Lua and we got into an argument if 3d rendering is possible without direct access to OpenGL)
<Groogy> pasted that in our internal chat at work and got bunch of the old timers talk about the "good ol' days" when they wrote a software renderer in assembly
<Papierkorb_> lawl
<Groogy> since that was the only way to render stuff at all back in the days
<Papierkorb_> have you tried that with luajit?
<Papierkorb_> Wondering how it'd keep up lol
<Groogy> no I haven't ubt I really should
<Groogy> that is running on Lua 5.1 and is going really fast
<Papierkorb_> Well, Lua does use a really fast bytecode vm :)
<Groogy> but I am aiming on 5.1 because my suspiscion is that is what the game will be implementing
<Groogy> and I am gonna record a video of 3D in the game and post on the forum as a "Hey devs look what I did! Can you add support for this thing so I can make this better?"
<Groogy> I'm gonna be alpha tester in the game so gonna try and push as much as I can
<Groogy> also that forum is filled with people that just go "want want want want" without any context so I hope I'll stand out a bit
Tuxified has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Papierkorb_> Oh the art of trolling
<Groogy> also they said you can't make autonomous drones that fight space battles for you, so I am gonna "put that to the test" as well
<Papierkorb_> a good old school technological shutdown
Tuxified has joined #crystal-lang
<Papierkorb_> Never really got into game dev :|
alex`` has quit [Quit: WeeChat 1.9]
<Groogy> I wanted to be a game dev since I got my first computer :P That's why I am quite young and yet a senior
<Groogy> I just gunned for it and took every shortcut I could to land a job as quickly as possible
<Papierkorb_> Well I got into coding cause I wanted to write games. Of course, what else is there?
<Papierkorb_> Irony is, I never built a (full, playable) game. But a SNES emulator is fun too.
<Papierkorb_> So .. close enough
<Groogy> Oh actually one of the people here learned programming by reverse engineering I think it was Everquest servers?
<Groogy> and made his own pirate everquest server
<Groogy> he told this horror story of that there was a debug output that would put out something occasionally and it was **essential** for the stability of the server
<Groogy> and they had no idea why, but something with it slowing down the server was needed to not make the clients crash or something
<Groogy> If you started because of games, where did you end up Papierkorb?
alex`` has joined #crystal-lang
<Papierkorb_> Groogy: Studying right now. I like Networking, Databases, Low level stuff, and Architecture.
<Groogy> Oh I thought you were out on a workplace
<Papierkorb_> Hope I'll snatch a systems programmer job.
<Papierkorb_> Yeah I am, requirement for the uni program
<Papierkorb_> three month internship
<Groogy> I don't know how to translate this but the new "Engineer/Doctor/High Profile" education in Sweden right now is "Systemvetare", Direct TL: System Knower
<FromGitter> <Qwerp-Derp> I want to go into a job in game design or development :P something like that
<Groogy> also studying Qwerp?
<FromGitter> <Qwerp-Derp> I'm actually not even in uni yet, still in school
<Groogy> oh then you have plenty of time
<FromGitter> <Qwerp-Derp> Yeah :P
<Groogy> my advice is the only one that can make you really good at programming is yourself, not a teacher
<FromGitter> <Qwerp-Derp> Does Crystal count as a low-level language?
<FromGitter> <Qwerp-Derp> Yeah
<Groogy> Teachers can help you in the right direction, but they can't get you to the goalline
<Papierkorb_> No
<Papierkorb_> Qwerp-Derp, ^
<FromGitter> <Qwerp-Derp> Groogy: yeah
<Groogy> what I look at when I am intervewing candidates for Paradox is the persons drive, their willingness to teach themself
<Papierkorb_> ^
<FromGitter> <Qwerp-Derp> Papierkorb_: I mean, it interacts with C, it's certainly less abstracted than something like Ruby... would it count as "middle-level" if that exists?
<Groogy> I've recommended to hire people that were just barely junior but are now really good because you saw that spark in them
<Papierkorb_> You *can* do anything. You just have to put your mind to it, and actually invest the time.
<FromGitter> <Qwerp-Derp> Yeah
<FromGitter> <Qwerp-Derp> ^ to both
<Groogy> anywayt lunch time!
<Papierkorb_> Qwerp-Derp, it's not about how far away the generated binary is, but if the language offers useful primitives for doing low- or high level stuff
<FromGitter> <Qwerp-Derp> Ah
<Papierkorb_> Qwerp-Derp, And as Crystals primitives are lacking in that regard, it's just not that good for system dev. You can use it for it, I wrote a x64 kernel in it. But it's just not good for *that*. But everything outside kernel dev should be fine.
<FromGitter> <Qwerp-Derp> How does something like OpenGL even work?
<FromGitter> <Qwerp-Derp> How does it make stuff on a window?
<FromGitter> <Qwerp-Derp> Does it use X and that Wayward thing?
<Papierkorb_> OpenGL is just a standarized API to interact with the graphics driver to do 3D things
<Papierkorb_> Yes, you have to open your own window first (using X or whatever), and then you tell OGL that when you tell it where to draw stuff
<Groogy> Yeah you create a OpenGL context first
<Groogy> which is essentially creating a window with a graphics context owned by the driver attached kind of ish
<Groogy> and that is what the opengl functions operate on which are just wrappers for the drivers own functions
<Groogy> just very simply described
<Papierkorb_> Fun part is, that standards are there to be ignored and so some manufacturers/drivers are awful lul
<Groogy> *cough* intel *cough*
<Papierkorb_> It's astounding how games actually even work considering the amount of bugs
<Papierkorb_> Groogy: Have you seen the Dolphin emulator blog post where they talked about OpenGL support in drivers?
<Groogy> we have specific code that detects a specific model because we had a graphical glitch on that model
<Groogy> nope link?
<Papierkorb_> intel was bad, but ARMs MALI was awful
<Groogy> will read after my lunch
<FromGitter> <Qwerp-Derp> CMake is cancerous :( it just seems so complex compared to a package managing system that e.g. Crystal has
<Papierkorb_> Qwerp-Derp, trust me: Try to write a Makefile that works on Windows, Linux and Mac without changes. I'm sure you'll change your view of cmake rather quickly
<Papierkorb_> writing Makefiles is bad enough already, but doing multi-platform with em? Someone have mercy.
<FromGitter> <Qwerp-Derp> But there's still a higher learning curve to master than a language with a built-in package manager
<Papierkorb_> As I said, yes, because C/C++ projects tend to be much more complex
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<FromGitter> <Fanna1119> How would i check what the current directory is
claudiuinberlin has joined #crystal-lang
<Papierkorb_> Fanna1119, `Dir.current`
<FromGitter> <Fanna1119> Thank You!
<FromGitter> <codenoid> hi, can i make `JSON::Any` to become a crystal Hash ?
<FromGitter> <codenoid> wont receive hash from JSON.parse :"
<Papierkorb_> codenoid
<RX14> oprypin, everyone on github seems to be in the past for me
<RX14> IDK whats going on
<FromGitter> <sdogruyol> in the past?
<FromGitter> <codenoid> thanks @papierkorb_ ✨
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<RX14> looks like somehow suspending my laptop put the clock 1h in the future lol
<RX14> hardwar bugs :/
rohitpaulk has joined #crystal-lang
<Groogy> @Qwerp-Derp as reference, we use Cmake and we use it for a TON of stuff besides like just compiling C++ files
<Groogy> we generate files, build tools that generate more files etc. before you even get to compiling the actual game
<Groogy> all by me pressing F5 in Visual Studio
<FromGitter> <sdogruyol> haha
<FromGitter> <sdogruyol> how long does it take to compile?
<Groogy> Without multicore compilation in release mode? Like about an hour
claudiuinberlin has joined #crystal-lang
<Groogy> except if your using Clang, then it takes even longer
rohitpaulk has quit [Ping timeout: 260 seconds]
<RX14> hmm, i heard that clang was faster than gcc, i must have been mistaken
<RX14> oh wow that has changed
<Papierkorb_> Link?
<RX14> there are no recent benchmarks of this
<RX14> it's anoying
<txdv> "clang is faster" -> does it produce faster code?
<txdv> does it run faster?
<Groogy> no RX14 what is slower is the optimization pass
<Groogy> Clang is optimizing the shit out of the executable
<RX14> well so is gcc, i'm surew
<Groogy> and theres a specific file that is the culprit and I think Clang inlines the values in there to EVERYWHERE in the source
<Groogy> so when compiling in Debug and our Half release mode the optimizations are disabled for that file
<Papierkorb_> didn't gcc produce faster binaries?
<Groogy> txdv we are talking about speed of the compilation
<txdv> my guess would be gcc
<txdv> because clang is fat
<Papierkorb_> ...huh
<txdv> huh what?
<RX14> gcc generally still produces faster code but if it's half the compile time...
<RX14> Groogy, have you compared gcc vs clang in -O1 or something relatively unoptimized
<Groogy> nope
<Groogy> because I have the worlds largest backlog so I can't afford spending time on doing that
<RX14> maybe you shouldn't be around on irc then :)
thews has joined #crystal-lang
ShalokShalom_ has joined #crystal-lang
hightower4 has joined #crystal-lang
<FromGitter> <codenoid> can i extract gzip (.gz) file using crystal ?
<FromGitter> <codenoid> o
ShalokShalom has quit [Ping timeout: 248 seconds]
<FromGitter> <bararchy> If youre file is big, you might want to do a `each_line` or `read(16_000)` loop and append to file, so that you wont block all memory on the machine
<Groogy> I write on IRC when compiling, thinking or anything else that actively prevents me from writing code
ShalokShalom_ is now known as ShalokShalom
hightower3 has quit [Ping timeout: 264 seconds]
<FromGitter> <codenoid> @bararchy the average extracted file is 15mb in size, is it "big"?
<FromGitter> <bararchy> Nha
<FromGitter> <jose-rodrigues> @codenoid well id this a text file?
<FromGitter> <bararchy> it should be fine
<FromGitter> <bararchy> @codenoid I was talking about 8+ GB files
<FromGitter> <codenoid> @jose-rodrigues a sitemap file, (.xml)
<FromGitter> <sdogruyol> if you're using an ssd or so 15mb is probably not a burden
<FromGitter> <codenoid> @bararchy oh, ok thanks ^^, it's work
<Papierkorb_> codenoid, 15MiB of gzip'd data can easily fill up your memory when uncompressed.
<FromGitter> <codenoid> @sdogruyol will run using ssd, but while development i use hdd
<Papierkorb_> You once could (still can?) use that to DoS browsers lul
<FromGitter> <Qwerp-Derp> @faustinoaq New feature request: Keyboard shortcut for various Crystal functions (e.g. `crystal play`, `crystal build {file}`)?
<FromGitter> <faustinoaq> You can do it in VSCode very easy with `tasks.json` and `keybindings.json` just set a task and assign a shortcut.
<FromGitter> <faustinoaq> In fact, My TODO list for vscode-crystal-lang shows a Task provider,
<FromGitter> <Qwerp-Derp> Oh, cool beans :D
<Groogy> yeah I can give you my tasks.json
<Groogy> when I get home Qwerp
rohitpaulk has joined #crystal-lang
flaviodesousa has joined #crystal-lang
sz0 has joined #crystal-lang
<FromGitter> <ansarizafar> I am using crystal-pg with kemal to create an api endpoint but I am unable to convert result set returned by db.query to json. Can someone help?
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<FromGitter> <sdogruyol> @ansarizafar are you using crystal-db
<FromGitter> <sdogruyol> if so you can use DB::Mapping
rohitpaulk has quit [Ping timeout: 248 seconds]
<FromGitter> <ansarizafar> @sdogruyol I am only using crystal-pg. \
<FromGitter> <sdogruyol> you shouldnt do that
<FromGitter> <sdogruyol> instead use crystal-db with crystal-g
claudiuinberlin has joined #crystal-lang
claudiuinberlin has quit [Client Quit]
claudiuinberlin has joined #crystal-lang
<FromGitter> <ansarizafar> I have read documentation. Coming from Nodejs where query result returned as json without any extra processing required, finding it difficult to figure out how to perfon this simple task. Why it is required to create DB:Mapping for each query?
<FromGitter> <ansarizafar> Is there any other simple way?
<FromGitter> <sdogruyol> you don't have to necessarily have a DB::Mapping for each resultset
<FromGitter> <sdogruyol> however I don't know what's your query
<FromGitter> <ansarizafar> Here is my query Db.query "select * from restock.users order by name desc" Could you please point me to any rest api sample code?
<FromGitter> <sdogruyol> you're using "*" and it'd be hard to convert those without knowing the types
<FromGitter> <ansarizafar> I have seen that video, its just basics. I am looking for a complete example with JWT authentication
<FromGitter> <ansarizafar> Like Nodejs crystal-db or crystal-pg should have this functionality built-in.
<FromGitter> <ansarizafar> I think I have found sample code
<FromGitter> <ansarizafar> It seems outdated. Can someone point me to sample rest api project
rohitpaulk has joined #crystal-lang
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
claudiuinberlin has joined #crystal-lang
<crystal-gh> [crystal] asterite closed pull request #4958: Add CircleCI badge to README (master...badge/circleci)
<fnux> If I use Kemal.render("path1", "path2") everything's fine.
<fnux> But if I put those values in variables and call Kemal.render(var1, var2), everything blows up.
<FromGitter> <Rinkana> Macro's will be compiled to crystal code
<FromGitter> <sdogruyol> because render is a macro
<FromGitter> <sdogruyol> try render {{var1}}, {{var2}}
<fnux> Humm, If I call Kemal.render I get wrong number of arguments for macro 'render' (given 2, expected 2, 1)
<fnux> ANd If I cal with ::render, I get undefined macro method 'Var#split'.
<fnux> the {{var1}} gives undefined macro variable 'var1'
<FromGitter> <sdogruyol> ah sure my bad
<FromGitter> <Rinkana> What code are you trying to run then
<FromGitter> <sdogruyol> var1 is not a macro variable so that won't work
<FromGitter> <Rinkana> It seems that the #render method just renders a file
<fnux> I want to create a helper in order to avoid full paths everytime I render a template.
<fnux> I suppose I can directly call kilt ?
<FromGitter> <Rinkana> try: ⏎ ⏎ ```code paste, see link``` []
rohitpaulk has quit [Ping timeout: 248 seconds]
<fnux> still yelling about "undefined macro variable 'partial_path'"
rohitpaulk has joined #crystal-lang
<Papierkorb_> Put a {%begin%} before and {%end%} after those lines
<Papierkorb_> And possibly, use "" instead of ''
<FromGitter> <Rinkana> Ah, i see what you are trying to do.
<FromGitter> <Rinkana> But i don't think you can. You are trying to call the macro inside a method definition. But macro's are compiled beforehand
<FromGitter> <crisward> I think you can wrap render in a macro, pass in the template name as a string literal.
<fnux> Papierkorb_: it works ! thanks
* fnux is going to check those {% %} things
<FromGitter> <Rinkana> Hmm
<FromGitter> <Rinkana> It's odd that this does work
<FromGitter> <crisward> think something like this works too? ⏎ ⏎ ```macro my_render(path) ⏎ render("/home/my_location/"+path) ⏎ end``` []
<FromGitter> <sdogruyol> Anyone willing to answer
<Papierkorb_> Rinkana, why shouldn't that work?
<fnux> well, it works with manually set values
<FromGitter> <Rinkana> Well it's basicly the thing that @fnux has issues over
<FromGitter> <Rinkana> But only simplified
<FromGitter> <Rinkana> So if it works here is should work there
<Papierkorb_> Oh now I see
<Papierkorb_> Not possible.
<Papierkorb_> `render` reads the file at compile time and throws it into the program
<fnux> I don't get why 'render' is a macro ? Why is it better than a method ?
<Papierkorb_> You'd require a time machine to use variables there
sz0 has quit [Quit: Connection closed for inactivity]
<Papierkorb_> fnux: most (?) templating engines in crystal 'compile' to crystal code, which is then embedded right there into your program
<FromGitter> <Rinkana> Yeah i was looking into what happens in the macro call
<fnux> Oh okay
<fnux> It makes sense :)
<fnux> Well, I'm going to dig in crystal's macros.
<fnux> thank you !
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<FromGitter> <bararchy> @sdogruyol did he answered himself ?
<FromGitter> <bararchy> lol
claudiuinberlin has joined #crystal-lang
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<FromGitter> <install-gentooo> why is the developing so slow?
<FromGitter> <install-gentooo> if it's keeps going this way, it won't ever be actually usable w/o encountering glitches...
claudiuinberlin has joined #crystal-lang
<FromGitter> <mverzilli> because this "doesn't develop", there's people who have to develop it
<FromGitter> <sdogruyol> @mverzilli 👍
Papierkorb_ has quit [Quit: Konversation terminated!]
bmcginty has joined #crystal-lang
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
claudiuinberlin has joined #crystal-lang
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mark_66 has quit [Remote host closed the connection]
Tuxified has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
claudiuinberlin has joined #crystal-lang
bmcginty has quit [Remote host closed the connection]
bmcginty has joined #crystal-lang
snsei has quit [Remote host closed the connection]
claudiuinberlin has quit [Quit: Textual IRC Client:]
snsei has joined #crystal-lang
snsei has quit [Ping timeout: 246 seconds]
<FromGitter> <bararchy> @mverzilli yap , @install-gentooo Crystal is OpenSource , if you want it better please give a hand and help out ;)
claudiuinberlin has joined #crystal-lang
alex`` has quit [Quit: WeeChat 1.9]
alex`` has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 248 seconds]
<Papierkorb> bararchy, do you have a second for a private chat?
<FromGitter> <bararchy> ofc
<FromGitter> <bararchy> I'll boot IRC
<FromGitter> <bararchy> give me a sec
unshadow has joined #crystal-lang
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
claudiuinberlin has joined #crystal-lang
claudiuinberlin has quit [Client Quit]
claudiuinberlin has joined #crystal-lang
unshadow has quit [Quit: leaving]
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
claudiuinberlin has joined #crystal-lang
elbuki has joined #crystal-lang
<FromGitter> <faustinoaq> I'm learning Elixir now. It's a bit hard to me because the change of paradigm but is a cool language too, syntax similar to ruby and crystal 😄
<elbuki> Is there a Slack channel for Crystal?
<Papierkorb> There's already a channel
<Papierkorb> (Please not the .. fourth channel if you count matrix)
<elbuki> Yes, I'm ok with that, I was just curious.
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<fnux> Hum, I have an 'user' object and I want to tell the compiler that is indeed and integer. It actually thinks it's 'Nil'. How can I do that ?
<Papierkorb> Can you gist the class?
<fnux> Papierkorb: it's a class build for granite (
<fnux> so that's where the id field is defined :/
<Papierkorb> I guess a useful answer would require someone who knows granite
claudiuinberlin has joined #crystal-lang
<FromGitter> <ricardobeat> shouldn't `crystal build` build everything listed under `targets:` in shards.yml?
<Papierkorb> Nope, that'd be `crystal deps build`
<Papierkorb> (Although that may change over time to allow both..?)
<FromGitter> <ricardobeat> hmmm
<FromGitter> <ricardobeat> thanks
<fnux> Papierkorb: probably, thank you anyway!
<fnux> I actually have (Int32 | Nil) but I want Int32
<Papierkorb> If you're sure it can't be nil (And if it is, it's a severe bug somewhere), you can use `#not_nil!`
<Papierkorb> Like this: `user_id =!`
<RX14> Papierkorb, were actually talking of removing crystal deps
<RX14> as an alias
<Papierkorb> What do you mean? Remove 'shards' from the omnibus?
<RX14> no, remove the crystal deps command
<RX14> and you use shards
<RX14> ive never used crystal deps willingly in my life
<Papierkorb> Well I don't care either way, as long only one way of building/managing shards remains after that
<Papierkorb> it's just confusing right now
<RX14> ...why?
<Papierkorb> `crystal deps` or `shards`?
<crystal-gh> [crystal] asterite opened pull request #4960: Fix malloc and realloc for 64 bits platforms (master...bug/malloc-realloc-64-bits)
<RX14> Papierkorb, oh yeah ok
<RX14> thats why we're (thinking of) removing crystal deps as a command
<Papierkorb> I mean you could make the point that having it in the crystal binary as command is nice so it can list it in its help page for newbies to find
<Papierkorb> But apart from that, eh
<RX14> did you see the discussion about splitting the doc and play tools into seperate commands too
<RX14> crystal-doc and crystal-play
<Papierkorb> ..Where?
<RX14> so that they could be developed seperately from the compiler
<RX14> Papierkorb, github?
<Papierkorb> No
<Papierkorb> `crystal-doc` etc. is great for the separate development, but bad as now tabbing `crystal` in the shell won't add a space after the command anymore
<Papierkorb> Life's hard
<RX14> damn
<RX14> i didn't think about that
<RX14> i dont actually tend to write crystal commands often tbh
<RX14> 90% of the time it's just up arrow and enter
<Papierkorb> Oh I just noticed, The star count of `crystal-lang/crystal` is OVER NINE THOUSAND
<RX14> oh
<RX14> so it is
<oprypin> RX14, the separation thing was just a quickly passing idea in both cases, immediately followed by compelling arguments against
<RX14> uhh, really?
<RX14> me and asterite are still for it, i don't think it's been decided
<oprypin> ... followed by arguments why those arguments against aren't blockers (which i haven't seen)
<oprypin> making crystal doc separate is nice but it's unnecessary work and may introduce subconscious limitations on the ways the tool could be improved
<oprypin> crystal itself having external dependencies is just a nightmare
<RX14> it's really not - if they're vendored in
<RX14> I can understand that using shards makes the build process harder
<oprypin> that's the worst of both worlds
<RX14> but once the code is vendored in theres no problem
<RX14> or at least I dont see it
<oprypin> well yesterday i did suggest vendoring but most of the problems are still there
<RX14> such as?
<oprypin> linux distros and enterprise users don't work like that
<RX14> i still don't see the problem
<RX14> plenty of projects do vendoring
<RX14> and i never heard of the problems with it you're suggesting myself
<oprypin> RX14, tell me, how is vendoring better than properly integrating this code?
<RX14> what do you define as "properly integrating"
<FromGitter> <straight-shoota> @Papierkorb #4613 (the discussion has diverged quite a bit from the initial topic...)
<DeBot_> (Improve Markdown implementation)
<Papierkorb> Oh DeBot_ <3
<oprypin> RX14, well the current markdown code is properly integrated
<oprypin> so integrated with the directory structure, having the same repository as source of truth, same license
<Papierkorb> straight-shoota, that sure went different-topic
<FromGitter> <straight-shoota> he's alive! :D
<RX14> oprypin, does the licensing really matter? plenty of projects are dual-licensed
<oprypin> RX14, that's beside the point
<RX14> directory structure matters very little I think
<oprypin> that's beside the point also. i just provided a definition that you asked
<oprypin> RX14, tell me, how is vendoring better than properly integrating this code?
<Papierkorb> straight-shoota, meh I can't "react" on github issue title changes :(
<RX14> because we don't have to deal with relicensing
<RX14> we don't have to deal with fiddling with it
<RX14> we just drop it right in
<RX14> require it
<RX14> boom
<oprypin> RX14, you have to deal with licensing once
<RX14> i don't want to take this guy's project and go
<RX14> "fuck you its ours now"
<oprypin> doing that is not a requirement
snsei has joined #crystal-lang
<RX14> i want a sane way to integrate community code which doesn't require them to make otherwise unneeded changes to their code
<FromGitter> <straight-shoota> regarding the current topic, licensing could be a no brainer if @icyleaf would be willing republish under apache2
<oprypin> certainly
<oprypin> goes both ways, too
<oprypin> RX14, community code that depends on the compiler has no place being a dependency of that same compiler. that's all.
claudiuinberlin has quit [Quit: Textual IRC Client:]
<RX14> i want doing this to be easy
<RX14> as a pathway to future splitting things out from the compiler
<RX14> or future bringing in community work
<RX14> i see your suggection as a lot more work for little if any benefit
<oprypin> best suggestion is no work at all
<RX14> circular dependencies are not a problem
<RX14> it's no more of a circular dependency than the stdlib is with the compiler
<oprypin> not from your point of view
<RX14> we refactor both at the same time all the time
<RX14> vendoring it in allows us to treat it as compiler code
<RX14> and allows us to make changes which make it format, or make it undeprecated
<oprypin> i'm not saying that vendoring can't work. i did suggest it initially
<RX14> without upstreaming the patches right away
<oprypin> that's not vendoring then lol
<RX14> ...why?
<RX14> it's copying in a project at a state
<oprypin> it's forking and integrating, which is basically what i suggest
snsei has quit [Ping timeout: 255 seconds]
<RX14> and then making minimal changes to it
<RX14> then we can replace the entire thing with a new version later down the line
<RX14> it's vendoring because we're not the source of trusth
<oprypin> vendoring implies 0 modifications
<RX14> we make very minimal changes if at all to it
<RX14> vendoring to me isn't this rigid thing which imples 0 mods to me
<RX14> so i guess this is just a definition incompatibility between us>
<RX14> and we actually agree?
<oprypin> there are some more technicalities that we disagree on
<RX14> yeah but we agree enough to worm them out
<oprypin> you must understand that vendoring is exact and reproducible. it's not about how you define it, it's just how it is - copying the code of a project unmodified to ensure its availability
<oprypin> even if you argue that "ok then we do this thing that's not vendoring but is similar"
<RX14> to me its just making a copy of a 3rd part dep
<oprypin> it doesn't solve anything, because then you just end up with a fork of a different repository
<RX14> we'd only make changes require to make it keep up with the formatter and be warningless
<RX14> not major refactorings most likelyt
<oprypin> who are you trying to convince with this? yourself?
<oprypin> then it's a foreign FORK in a repository that it does not belong in
<oprypin> which is just as much, if not more, of a maintenance burden, and having gone through that, you insist to not allow it to be in standard library
<RX14> i dont understand what you're arguing about, just because we disagree about what vendoring is doesn't mean either of us are right and it doesn't make any difference to the plan going forwards
<RX14> i have heard minimal to no arguments from you about what actually technically is the problem here
<oprypin> i'm not arguing about the definition of vendoring
<oprypin> ‎[23:28:25] ‎<‎oprypin‎>‎ even if you argue that "ok then we do this thing that's not vendoring but is similar"
<RX14> <oprypin> you must understand that vendoring is exact and reproducible.
<oprypin> RX14, there is no technical problem. it's just a step backwards
<RX14> and your alternative?
<oprypin> 1) integrating it as part of standard library; 2) depending as a shard in a separate docs project
<RX14> i don't see it as a step backwards - we remove the terrible markdown implementation and replace it with an existing one which passes the commonmark specs
<RX14> thats the goal
<RX14> and we largely agree that markdown shouldnt be part of the stdlib
<RX14> and if we were to merge that shard, i'll be honest, it's not up to stdlib code standards
<oprypin> ok so don't merge it
<RX14> it works and its great and im sure its maintainable to him
<RX14> thats why i, suggesting we dont maintain it
<RX14> i'm*
<oprypin> ‎[23:29:19] ‎<‎RX14‎>‎ we'd only make changes require to make it keep up with the formatter and be warningless
<RX14> yes
<oprypin> that's maintaining
<RX14> ok, but the absolute minimal of possible maintaining
<RX14> we extremely rarely make breaking changes which are much more than regex replacements these days oprypin
<oprypin> so a fork
<RX14> whatever we call it
<oprypin> no matter how you phrase it, it's equivalent to maintaining a fork
<RX14> im sure you understand the actual practicality of whatn im suggested
<oprypin> i also understand the numerous downsides though. *maintaining* a *fork*
<RX14> but we're not adding features
<oprypin> that's what they all say
<RX14> we're not doing large refactors
<oprypin> im just curious what the Arch Linux maintainer would say about this
<oprypin> or otherwise, i'm curious about other examples of such a practie
<RX14> i'm way more curious what the debian maintainers would say
<RX14> they seem to be much stricter
<oprypin> well whatever the Arch maintainer would say but worse
<FromGitter> <krypton97> Hey, I've a bunch of data that will server an web api, currently stocked on disk. Is is worth it to server the wev api from the db or directly from the disk. I only need to read the data and make it available for the client, no update, delete, insert etc..
<RX14> well debian packages go
<RX14> it cant be worse than that
<oprypin> RX14, what's so bad about it?
<RX14> every project vendors
<RX14> every major go project
<RX14> because go has no sane dependency system
<RX14> you just require the master branch of random github repositories
<RX14> because go
<oprypin> are there many go-based projects in debian?
<RX14> yes
<RX14> they package each library as source
<RX14> and the application as a single static binary containing all the libraries code
<oprypin> krypton97, db is just a bunch of data on the disk anyway. you don't get anything by adding such an indirection
<RX14> but only the app's source
<RX14> which is what cryatal would have to be like kinda anyway
<RX14> but regarding vendoring i havent a clue what they do
<RX14> but they deal with it
<oprypin> RX14, yeah but you imagine how much they'd like to introduce a package "crystal-markd" and also ignore the vendored part of "crystal" and have a circular dependency
<RX14> they'd either package out the source and then patch the crystal to make a symlink
<oprypin> krypton97, for real performance u just keep it in RAM :>
<RX14> oprypin, ah but crystal-markd doesnt depend on crystal
<RX14> it depends on crystal at build time
<oprypin> RX14, it's literally useless without crystal
<oprypin> there's nothing to build. just a source library
<RX14> its a source package
<RX14> no binary installable anything
<RX14> its useless without crystal
<RX14> but it doesn't depend on it to actually build the crystal-markd package
<RX14> plus they deal with this stuff all the time
<RX14> it cant be hard
<RX14> rust must have it
<RX14> go must have it
<FromGitter> <krypton97> Well, I can keep it in memory directly but seems a bit hardcoded tbh:)
<RX14> they have packages
<RX14> and those packages are useless without go/rustc
<oprypin> krypton97, read it once on application load. how is that hardcoded
<RX14> and im pretty sure rust has some external or vendored deps
<FromGitter> <krypton97> Yeah, that's what I'll do. I was thinking something else
<FromGitter> <krypton97> no need to mess with sql as long as I don't need its features
<RX14> it just uses cargo
<RX14> and depends on external libs
<RX14> just fine
<RX14> no problem
<RX14> rust does it
<RX14> owning_ref isn't even part of the rust org
<FromGitter> <krypton97> golang guys are making nice performance improvements
<RX14> they don't care oprypin
<RX14> they just made it easy to use the packages they want in the compiler
<RX14> why don't we do the same
<oprypin> RX14, this is Cargo, not the compiler
<RX14> no thats librustc
<RX14> the core create of the compiler
<oprypin> ok
<oprypin> huh this is unbelieveable
<RX14> perhaps it's you that's wrong?
<RX14> not a major project backed by may commercial companies
<RX14> which is used in production
<RX14> and well packaged
<oprypin> it's not vendored tho
<RX14> yes, isn't that in your eyes worse?
<RX14> wouldn't the distro packagers just unvendor it anyway as you sugegsted
<oprypin> yeah they'll do that while cursing
<RX14> ok so my original PR is fine to merge?
<oprypin> nope
<oprypin> what about breaking changes though?
<oprypin> you want to change the compiler in a way that breaks that shard. so you leave the compiler in a broken state, fix the shard, update the commit
<RX14> yeah thats a problem
<RX14> wed need to vendor because of that
<oprypin> or force the shard to be updated even though the change isnt there yet
<oprypin> that's assuming that you can force it
<RX14> but i dont think vendoring is an issue at all
<oprypin> vendoring does not change things
<RX14> if rust can get away without vendoring im sure they can get away with vendoring
<RX14> theres nothing special that happens as soon as source is brought in-tree instead of downloaded from the internet
<oprypin> > you want to change the compiler in a way that breaks that vendored shard. so you leave the compiler in a broken state, fix the shard, pull in new vendored code
<RX14> its just that rust isn't breaking so we can get away without
<RX14> oprypin, or just fix the code in-tree
<RX14> which brings us back to this pointless discussion about what exactly vendoring is
<oprypin> so you maintain a fork
<RX14> ok
<RX14> in your eyes we do
<RX14> and im arguing thats not a big deal
<oprypin> ok then back to debian maintainers or whatever
<oprypin> you say they can un-vendor it, how exactly?
<RX14> ln -s
<oprypin> but the shard has different, possibly broken code
<RX14> to wherever yhey unpack the source when you install the source package
<RX14> oprypin, i really strongly highly doubt the maintainers would be willing to split that package out then
<RX14> they would just leave it
<RX14> and make 0 changes to their normal packaging routine
<oprypin> right. they would just leave it and not include it in the distro
<RX14> no
<RX14> i dont think maintainers are these stingy people that you think they are
<RX14> actually why dont we ask them
<oprypin> cuz they're stingy, i dunno
<RX14> and actually get an answer instead of guessing
<RX14> because if packaging is the only argument against i doubt that will persuade many people either
<RX14> most of the core team develop on mac after all
<RX14> ok here's a package using vendoring:
<RX14> packaged despite it's vendoring
<oprypin> OK, but I have just shown that vendoring is, in fact, nottechnically possible in Crystal's case
<RX14> why?
<oprypin> you can't introduce breaking changes
<RX14> can you just assume
<RX14> for once
<RX14> that i mean my definition of vendoring
<oprypin> RX14, so you mean your definition of vendoring, but showing an example of everyone else's definition of vendoring in that github link
<RX14> fair point
<RX14> to a certain point i think we should do what's easier for us
<RX14> and let the packagers do their thing
<oprypin> i still see just those options - 1) integrating it as part of standard library; 2) depending as a shard in a separate docs project (preferably while also having some control of the repo)
<RX14> oprypin, for arch they dont bother
<RX14> it just uses the vendors in the repo
<oprypin> gotta see that
<RX14> check the makedeps
<RX14> just git and go
<RX14> i doubt the arch dev will care
<RX14> and debian packagers dont care in that we're unlikely to even get packaged before 1.0 anyway
<oprypin> ok, i'm fine to dismiss my packaging concerns
<oprypin> that wasn't all of them though
Tuxified has joined #crystal-lang
Tuxified has quit [Read error: Connection reset by peer]
alex`` has quit [Quit: WeeChat 1.9]
snsei has joined #crystal-lang
snsei has quit [Ping timeout: 246 seconds]
elbuki has quit [Quit: - A hand crafted IRC client]
SuperChickeNES has quit [Ping timeout: 240 seconds]
ChickeNES has joined #crystal-lang