<FromGitter>
<mattrberry> Is there a way to tell what everything on the left here is from? I think @asterite gave me some good ideas when working on another emulator, but I'm not sure that that exactly applies here. Could it be related to frequently accessing constants again, at least in part?
<FromGitter>
<mattrberry> My first thought was gc, even though there isn't *really* any work that the gc should need to do. I built with `-Dgc_none` and it seems to be effectively the same result
<FromGitter>
<Blacksmoke16> scheduler?
<FromGitter>
<mattrberry> Hm?
<FromGitter>
<Blacksmoke16> like the thing for starting/resuming fibers
<FromGitter>
<mattrberry> I don't use fibers / threads for anything
<FromGitter>
<Blacksmoke16> right but id imagine it has to be there in case you do?
<FromGitter>
<mattrberry> But would it really cause that much overhead if it's unused? I feel like it has to be something else?
<FromGitter>
<Blacksmoke16> :shrug: prob
<FromGitter>
<mattrberry> I have to run for a few hours, but I'd love to work / talk through this some more when I'm back if people are around :)
f1reflyylmao has joined #crystal-lang
f1refly has quit [Ping timeout: 272 seconds]
<FromGitter>
<Dan-Do> I got this problem but don't where to start
<FromGitter>
<mattrberry> > I have to run for a few hours, but I'd love to work / talk through this some more when I'm back if people are around :) ⏎ ⏎ I'm back :) Anybody have any other ideas where this additional overhead is coming from?
<FromGitter>
<asterite> Matthew: that's accessing constants or class variables. It's making sure they are initialized only once. And it should be a bit optimized on master (unless you also use class variables, which I didn't optimize but I will). Is there any code I can try to run and see the fps? Then I can try it against master and see if there's a difference. Or you can try compiling crystal master (it's not hard)
<FromGitter>
<asterite> I feel that 1.0 is great, but sticking with "the next version is 1.0" was bad. We could have so many fixes and improvements already out there...
<raz>
To the optimist, the glass is half full. To the pessimist, the glass is half empty. To the engineer, the glass is twice as big as it needs to be.
<raz>
for me crystal has felt like an 1.0 for a long time already. i think it's mostly a psychological milestone :) (an important one nonetheless!)
<FromGitter>
<asterite> well, 1.0 will go out with all the bugs in generics and generics inheritance, so for me 1.0 is just to please those that want it to be 1.0 (not my decision, though). And I feel the effort is spent in the wrong things (although every improvement is worth is, and I really like how collaboration happens here, for example how the docs are being currently improved)
<oprypin>
asterite, there are quite a few people dissatisfied with the direction. 1.0 now is a msitake, and also the way it's being done, yes, it's inevitable that everyone will have to scramble to fix something when it comes
<raz>
well, i can only comment from the frog perspective of one user (others may disagree). since i have yet to experience any type of compiler bug (i use generics only sparingly, despite writing a lot of crystal lately) it's been pure bliss for me. just massive improvements and cleanups everywhere. the direction feels plenty solid to me. personally, the only time i care about the version number is when google gave me an old version of the docs again. ;)
<raz>
yea it has gotten lots better already (was not meant as a complaint! :D). i'm sure it will be figured out over time. and in fairness, recently i noticed actually even the venerable postgres does the same thing (google more often sends me to an old docs-version than the most recent one - but they have a great version picker at the top)
<FromGitter>
<asterite> Such a big fuss for a simple one line change
<FromGitter>
<asterite> @mattrberry I replied above, but I also just got the latest code, compiled it and it fails because I need to pass two arguments now to the executable. I figured from the code it needs to be the bios path and rom path, but I don't know what's the bios (I tried several from another emulator and they didn't work). I suggest showing a nice message explaining all of this instead of the user having to figure it out
<FromGitter>
... by looking at the code.
<FromGitter>
<asterite> Oh, actually, I think it works fine, it's just that I have opengl 3.3 and it seems to require 4. I'll see if I can install that on a mac...
<FromGitter>
<asterite> Well, nevermind... I don't have time to spend on this. But if you can compile master and try it with that, it should be faster
<FromGitter>
<j8r> I don't know if all are legits nor fit the "segfaults a program without using C libraries" requirement, but there are surely a few that meet them
<FromGitter>
<j8r> However you are right that they are more edge-cases than our more common issue with generic inheritance
<jhass>
No, structured concurrency is quite orthogonal
<FromGitter>
<j8r> indeed event driven logic is more useful for some programs than others
<FromGitter>
<j8r> like UI and games
<jhass>
indded, it's true that the whole RX concept came to be from an "I want live updating UI" perspective, but I find its applications useful in data processing applications too
<FromGitter>
<j8r> right
<jhass>
in the latter sense it can serve as an alternative to structured concurrency, being a good solution to "fetch multiple data source, combine them as results come in, push the results soemwhere else"
<FromGitter>
<j8r> That's another pattern, there is the infamous Erlang
<FromGitter>
<j8r> AFAIK @Blacksmoke16 like the Observer pattern too :)
<jhass>
maybe the mistake is to discuss concurrency primitives and concurrency abstractions together. While there's a certain set of concurrency primitives a language needs to provide to enable building abstractions upon, and there's some discussion you can have on which ones are to be preferred, there probably just isn't a single concurrency abstraction that fits all usecases
<jhass>
so I'd like stdlib to provide a good primitive and see how many of the abstractions we can support in well maintained shards
<yxhuvud>
don't look at the monkeypatches or your eyes will bleed :)
* straight-shoota
looks at monkeypatch folder first
<oprypin>
it's so explicit which task depends on another task
<jhass>
well, async/await is pretty much just syntax sugar, it doesn't solve the problem of that approach being "infectious", there's a strong tendency for the "asynchronicity" of the code to bubble up your call chains and turn all your code into async code when you just wanted to make some operation concurrent
<jhass>
there was a good article on this but I can't find it anymore right now
<yxhuvud>
jhass: thinking on the colored function article?
<jhass>
Dart and Swift (iirc) support async/await too, if you want to take JS out of the discussion :P
<jhass>
interestingly all three, JS, Dart and Swift are languages used quite a bit for UI heavy code. My theory therefore is that async/await is good for things where you want to fire off an asynchronous callback and ultimately handle the result by pushing something to an event loop of sorts or have the operation itself know how to update some state. It's not good if you depend on the results of the
<jhass>
operations a lot
<oprypin>
Python is the elephant in the room. and c#
<oprypin>
JavaScript is just in a unique position where they rewrite everything so it's ok to just forget the code that isn't async aware
<jhass>
yxhuvud: cool. Anyhow, tying back into my earlier comments, I just don't believe in one concurrency abstraction to rule them all. There's always usecases covered better by one vs the other
<oprypin>
[15:46:15] <b30e0eyxhuvud> jhass: thinking on the colored function article?
<jhass>
and given they're abstractions it even often makes sense to compose them, take the actor pattern which can be good to structure your component but might be overkill to structure a certain operation within it, where structured concurrency could instead take over, or even just plain async/await or channels & coroutines
<oprypin>
wish i hadn't read that one back in the day. there are simple solutions to almost all supposed problems in that article
<jhass>
then maybe write a response article and push it to HN :D
<oprypin>
the response is just "look
<oprypin>
in JavaScript it just works"
<oprypin>
any function that's instant is ok to keep. others just become async. sure, it's infectious, but it makes sense to make non-instant operations cause dependents to be non-instant explicitly
<oprypin>
no actually the unique position of JavaScript is that it never had non-instant functions
<jhass>
but that's the beauty of coroutines, you can just put away the current stack and the callers don't need to be aware of that even happening
<jhass>
everything just looks synchronous from the callers side
<kevinsjoberg>
Anyone interested in doing Advent of Code, together? If you’re on Mac we could use Tuple for pair programming.
<FromGitter>
<tenebrousedge> huh. Thought about doing it. Hadn't thought about pair programming
<kevinsjoberg>
Me neither until now. Thought it be perfect opportunity for pair programming and a great excuse to do some Crystal. 🙂
<FromGitter>
<tenebrousedge> time zone?
<kevinsjoberg>
UTC+1.
<FromGitter>
<tenebrousedge> hmm, UTC-5 here
<kevinsjoberg>
Hmm, not the ideal time zone. Close enough to be inconvenient but not far enough either.
<kevinsjoberg>
Life, huh? 😂
<FromGitter>
<Blacksmoke16> who needs sleep
<FromGitter>
<tenebrousedge> I tend to need sleep D:
<kevinsjoberg>
Same. Having two kids kind of makes you appreciate the hours of sleep you actually manage to scrap together, haha.
<FromGitter>
<mattrberry> Hey @asterite, sorry I should have clarified. This is on the Game Boy (Color) emulator, not the Game Boy Advance emulator: https://github.com/mattrberry/CryBoy ⏎ You don't need a bios to boot it. If you grab any game boy or game boy color rom, you can just run with `bin/cryboy [path to rom]`. If you want to uncap the fps, you can hold down the tab key on your keyboard, or just run it with the `--no-sync`
<FromGitter>
... flag ⏎ I'll try building `opt/class-var-no-init-check` now though to see if that improves things!
ua has quit [Ping timeout: 256 seconds]
<oprypin>
i dont understand, if one declares the types of a block, that necessarily means the block will be captured? and if i dont want that, i can specify type annotations?
<oprypin>
tenebrousedge, do you need it for something?
<FromGitter>
<tenebrousedge> that gives me a sad. I'd like to work on `shards` but all the tests are broken
<oprypin>
tenebrousedge, u mean on windows or on linux? on linux they work
<oprypin>
there *is* a problem with specs, yes, but this pr doesnt fix it
<FromGitter>
<tenebrousedge> huh
<oprypin>
the problem is that `crystal spec` is broken, while `make test` works
<FromGitter>
<tenebrousedge> oh does it?
<FromGitter>
<tenebrousedge> ahhhhhhhhhhh
<oprypin>
cuz it runs `crystal spec ./spec/unit/; crystal spec ./spec/integration/`
<oprypin>
somehow putting those two together blows up
<FromGitter>
<tenebrousedge> huh
<oprypin>
u can look into *that* yourself if u want
<FromGitter>
<tenebrousedge> I may do
<FromGitter>
<tenebrousedge> I mean that sounds interesting tbh
<oprypin>
yea was especially intersting running into it on windows
<oprypin>
😑
<FromGitter>
<tenebrousedge> I haven't used windows in over a decade 😬
<FromGitter>
<tenebrousedge> wall lookie thar
ua has joined #crystal-lang
_whitelogger has joined #crystal-lang
<FromGitter>
<asterite> yeah, the docs for capturing a block are wrong. That's what we want it to work like but that's not how it currently works. I guess we still have time to make it work like the docs...
<oprypin>
current state is better tho 🤷
<FromGitter>
<asterite> why?
<FromGitter>
<asterite> there's just one problem, well maybe two, with the current approach: if you mention the block inside a macro then the compiler can't see it. And just from looking at the signature you can't tell whether a block is captured or not
sagax has quit [Read error: Connection reset by peer]
sagax has joined #crystal-lang
oprypin has quit [Quit: Bye]
oprypin has joined #crystal-lang
<FromGitter>
<j8r> you can't tell even if the method take a block or not, `&` is optional (without looking at the API docs or try compiling).
oprypin has quit [Client Quit]
oprypin has joined #crystal-lang
<FromGitter>
<j8r> knowing if the block is captured or not is the same story: we can't tell, the compiler can by trying to use break :/
<FromGitter>
<asterite> The most useful thing for the compiler would be to know that at the call site, so knowing if something is closured or not would be a matter of syntax, but that's not the case and it will probably never be
<FromGitter>
<j8r> if we use the annotation to not inline, `yield` will be closured?
<FromGitter>
<j8r> I mean, in place of yield there will be a closure
<FromGitter>
<j8r> a similarly sized project is https://github.com/Priv-Page/privpage . ⏎ I thought first to use a framework, DB etc - but at then, for only few routes, I just used the stdlib
<FromGitter>
<Blacksmoke16> isnt that essentially gh-pages?