postmodern has quit [Read error: Connection reset by peer]
postmodern has joined #crystal-lang
<oprypin>
damn I've been thinking. perhaps Crystal should try to satisfy the story of having multiple separately compiled components of one application. likely by interprocess communication. or maybe C ABI. this is just to help with compilation times during development.
postmodern has quit [Ping timeout: 246 seconds]
<FromGitter>
<naqvis> i would say looking into Zig build cache implementation might be a fruitful journey
deavmi has joined #crystal-lang
deavmi has quit [Client Quit]
deavmi has joined #crystal-lang
<oprypin>
@naqvis: no
<FromGitter>
<naqvis> why no?
<oprypin>
Crystal's problem is well known and well avoided
<oprypin>
everything is compiled from one merged source file basically
<oprypin>
obviously Zig doesn't do that in the first place
<FromGitter>
<naqvis> true, but sooner or later Crystal would have to follow different approach
<oprypin>
its cache is not a difficult problem by any stretch, u just do it
<FromGitter>
<naqvis> as code-base start growing, this problem will become the main bottle-neck
<oprypin>
@naqvis: 1.0 will be released in a way that precludes a different approach fyi
<FromGitter>
<naqvis> great to hear that
<FromGitter>
<naqvis> and we aren't that far away from 1.0
<oprypin>
precludes = disallows
<FromGitter>
<naqvis> rofl
<FromGitter>
<naqvis> might be core team has some more better idea than following the norm of split-n-conquer :P
<oprypin>
no they don't
<FromGitter>
<naqvis> huh
<oprypin>
[11:53:26] <ffffffoprypin> its cache is not a difficult problem by any stretch, u just do it
<oprypin>
to clarify i mean Zig's cache. Crystal's cache is indeed very difficult
<oprypin>
the cache that already is there in Crystal is not on the big bottleneck
<FromGitter>
<naqvis> what role does crystal cache plays then?
<FromGitter>
<naqvis> doesn't it re-compile each and every bit from scratch on each build?
<oprypin>
it does but it can split stuff into some logical chunks and if they 100% match then some early compile stages can be skipped
<oprypin>
no actually that's wrong. it does the early expensive compile stages and if their outcome 100% matches then some late stages can be skipped
<oprypin>
I'm still not nearly sure what I'm saying is correct tho
<yxhuvud>
oprypin: I wonder how LLVM modules work, splitting the apps into many of those would allow llvm to parallelize work. Perhaps without requiring C ABI or interprocess communication, both whcih has overhead.
<FromGitter>
<asterite> the semantic phase is always done from scratch. converting that to llvm ir is also done every time. then compiling llvm ir to byte code is also done all the time. but then if there's an old byte code file that matches the new one, compiling that to an obj file (kind of expensive) is skipped. that's all
<FromGitter>
<asterite> if semantic takes 30 seconds, it will always take 30 seconds. there are ways to improve it, but it's a hard problem, specially with how generic types are implemented
<FromGitter>
<asterite> and llvm bytecode files are split by crystal types, if I remember correctly
<oprypin>
yxhuvud: changing one module in Crystal can change any or all other modules
<yxhuvud>
oprypin: Sure, but it is a lesser problem than LLVM only using 1 core. (at least for me, with 16 core/32 thread setup :P)
<yxhuvud>
hmm. Looks like release-mode forces using a single module unless thin-lto is used.
<FromGitter>
<naqvis> Thanks Ary
<oprypin>
yxhuvud: yea i wonder if there should be a release mode without singlemodule. if u don't care about binary size
<raz>
i like the idea of encouraging a more modular approach (but i'm a compiler noob). i once thought perhaps there could be a "final"-flag on classes that prevents them from being re-opened, inherited or included (for modules). in my naive mind that could perhaps help the compiler to treat such a class as a separate/linkable object? (did i mention i'm a compiler noob tho :( )
<oprypin>
raz: there are way too many subtleties
<yxhuvud>
orpypin: That is why it is singlemodule? I see.
<oprypin>
final class can have def f(x) and if it's called with a new type of x anywhere at all, that changes it
<raz>
oprypin: hmmm. ah that's what ari meant by generics i suppose
<oprypin>
yxhuvud: I'm pretty sure but maybe there are some small secondary advantages that I'm not aware of
<FromGitter>
<asterite> as far as I know, we parallelize llvm compilation on our side (we fork)
<yxhuvud>
asterite: Then something block that from working, as cpu usage simply doesn't reflect that.
<oprypin>
yxhuvud: codegen is single threaded and not cached
<oprypin>
while the forked part is cached
<oprypin>
so if you're rerunning the same compilation it's expected what you see
<yxhuvud>
ime it is the optimization step that is the slowest, at least in release mode. though it was a while since I actually ran it with the print-stats flag so perhaps I misremember
<jhass>
/quit
<jhass>
:(
<FromGitter>
<naqvis> for time-being I thought you are using Slack slash commands
<FromGitter>
<naqvis> but then I realize, this is gitter
<jhass>
no, this is IRC :P
<FromGitter>
<naqvis> :P
<FromGitter>
<asterite> yxhuvud: in release mode we just dump everything into a single module so LLVM can do its best when inlining. There's no parallelization at all there because it's just a single module
<FromGitter>
<naqvis> @asterite is it possible to have different build modes like zig?
<FromGitter>
<naqvis> oprypin our talk was about caching
<FromGitter>
<naqvis> and these build modes are different
<FromGitter>
<naqvis> i'm neither preaching zig nor claiming its better, but it won't harm to learn from other languages :P
<FromGitter>
<asterite> ali: I think so, it's about configuring llvm. right now we do - o2 but there could be - o1 or similar. But I don't see the point so it will probably never happen
<oprypin>
@naqvis: oh really sorry i read "modules" not "modes"
<FromGitter>
<naqvis> Thanks oprypin and @asterite
woodruffw has quit [Ping timeout: 256 seconds]
<FromGitter>
<AlesLulak> Hey guys, still learning - I am trying to create a game, objects represent in-game objects that can be destroyed. What would you do to destroy an object since there is no delete?
<FromGitter>
<naqvis> objects no longer in scope will be eligible to get garbage collect
<FromGitter>
<naqvis> assuming you close file descriptors (files, network etc) when you no longer require them.
<FromGitter>
<naqvis> @aravindavk why not use constant?
<FromGitter>
<Blacksmoke16> ^ Is common to have a `VERSION` constant in your code namespace
<FromGitter>
<Blacksmoke16> like `MyApp::VERSION`
<FromGitter>
<Blacksmoke16> would ofc have to remember to bump that + the one in `shard.yml` tho
<FromGitter>
<evvo> @aravindavk, you might want to check if that VERSION is set as well, or set a default - `{{ env("VERSION") || "UNKNOWN_VERSION" }}`, as if it is not, it will not compile
<FromGitter>
<Blacksmoke16> using a constant here would be the most idomatic way
<FromGitter>
<aravindavk> @Blacksmoke16 constant value set in code? or it picks from shard.yml
<FromGitter>
<Blacksmoke16> the former
<FromGitter>
<Blacksmoke16> its a constant so you can use it at compile time for like BC stuff
<FromGitter>
<aravindavk> but code change is required for every version or I am missing something
<FromGitter>
<Blacksmoke16> right
<FromGitter>
<Blacksmoke16> but it would anyway since you need to bump `shard.yml`
<FromGitter>
<aravindavk> I am actually using git hash as version, if git tag is available then it uses that version otherwise it uses commit hash as version. `VERSION=$(git describe --tags --always --match "[0-9]*") crystal build cli.cr`
<FromGitter>
<Blacksmoke16> 😬 why?
<FromGitter>
<aravindavk> @evvo thanks for the snippet
<FromGitter>
<evvo> No problem. You're welcome!
<FromGitter>
<Blacksmoke16> that would be more suited to `BUILD_COMMIT` constant, than a version IMO
<FromGitter>
<Blacksmoke16> everything is assuming `VERSION` is a semver
<FromGitter>
<aravindavk> @Blacksmoke16 because to publish nightly or after every patch merge in master. This is required to identify the issues reported by others in the non-release builds
<FromGitter>
<Blacksmoke16> version wouldnt change in a nightly version tho
<FromGitter>
<Blacksmoke16> it would be like `0.5.0-dev`
<FromGitter>
<Blacksmoke16> with a `BUILD_COMMIT` of a specific hash
<raz>
`0.5.0-$hash` is a pattern i've seen
<raz>
(not sure if that's valid semver tho)
<FromGitter>
<Blacksmoke16> semver allows metadata, like `0.5.0+buildCommit`
<raz>
oh that would be better syntax then
<FromGitter>
<Blacksmoke16> ofc can also do `0.5.0-dev+buildCommit` and still have valid semver
<raz>
well, at some point the question becomes whether all involved tools still recognize as valid ;)
<FromGitter>
<Blacksmoke16> if they're following spec it should 😉
<raz>
s/tools/tools and obscure helper scripts the intern wrote last year and never checked into version control/
<raz>
;)
<FromGitter>
<Blacksmoke16> @aravindavk anyway, my point is what are you setting `version` to in your `shard.yml`? also the commit hash?
<FromGitter>
<Blacksmoke16> PHP 7.4 has arrow function, but alas we're on 7.3 😢
<FromGitter>
<Blacksmoke16> maybe should make collection first, to prepare for that...
<yxhuvud>
blacksmoke: I think there are some existing libraries for php that implements something similar for php but in a more comprehensive way.
<FromGitter>
<Blacksmoke16> probably
<FromGitter>
<watzon> Here's an interesting question: is there any possible way to invoke the compiler with code that contains the current execution context? For instance, most interpreted languages, like Python and Ruby, have the ability to "eval" code, and when doing so inject the current state into the evaluated code. Even using icr I don't know if that kind of thing is possible with Crystal though.
<FromGitter>
<watzon> And yes, I know eval is typically bad. I do have a good reason 😄
<oprypin>
@watzon: compiler doesn't know anything about execution context, it only produces code that does
<yxhuvud>
watzon: I think you can execute arbitrary executables from macros. Don't abuse it, please.
<FromGitter>
<watzon> And even with that, would it be able to know anything about the current context?
<FromGitter>
<watzon> Seeing as macros are compile time
<FromGitter>
<watzon> I need runtime execution, which is the issue
<yxhuvud>
oh, I just redefined current to be at compile time. *ducks*
<FromGitter>
<watzon> Lol
<FromGitter>
<watzon> I am using icr in my program right now, which is awesome, but it just invokes the compiler and keeps a history of run commands.
<FromGitter>
<watzon> I don't think there's any possible way to run the compiled program in such a way that it shares an execution context with the program running it, right?
<yxhuvud>
no you'd have to use a pipe or something to share data
<FromGitter>
<watzon> That's what I thought
<FromGitter>
<watzon> Or have some kind of communication between processes using RPC or something I imagine
<FromGitter>
<watzon> Which is definitely more effort than its worth
<FromGitter>
<watzon> I suppose I could always use the luajit wrapper and figure out how to make it communicate with the client, but meh
<FromGitter>
<watzon> Lua
alexherbo2 has joined #crystal-lang
rocx has quit [Ping timeout: 260 seconds]
_ht has quit [Remote host closed the connection]
yxhuvud has quit [Quit: No Ping reply in 180 seconds.]