<crystal-gh>
[crystal] maiha opened pull request #4957: HTTP: respect gzip in serialization (master...http-gzip-serialization) https://git.io/v515t
rohitpaulk has joined #crystal-lang
<crystal-gh>
[crystal] splattael opened pull request #4958: Add CircleCI badge to README (master...badge/circleci) https://git.io/v51bc
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 X.org 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)
<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>
(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
<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> mongo.cr wont receive hash from JSON.parse :"
<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
<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
<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>
<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 😄
<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 user.id is indeed and integer. It actually thinks it's 'Nil'. How can I do that ?
<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 = user.id.not_nil!`
<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) https://git.io/v5DoY
<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...)
<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>
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
<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)