<FromGitter>
<grkek> here is the link to the shard.
<FromGitter>
<j8r> good, so the `INSTANCE` constant thing is gone?
<FromGitter>
<grkek> YEs
<FromGitter>
<grkek> YES
<FromGitter>
<j8r> noice! 🚀
<FromGitter>
<j8r> the `INSTANCE = new` was not a good pattern
<FromGitter>
<grkek> Thank you mate, I also did some refactoring you suggested and re-based the routers so one can re-use the macros to create their own routers.
<FromGitter>
<grkek> It is a singleton pattern and must be used where needed
<FromGitter>
<grkek> clearly it was not needed here.
<FromGitter>
<Blacksmoke16> breaking changes and still `1.x`?
<FromGitter>
<grkek> Yeah, why not?
<FromGitter>
<Blacksmoke16> if you're following semver, breaking changes should lead to a `2.x.x` version
<FromGitter>
<grkek> for me the versioning doesn't matter, as long as I push out stable builds and people use the shard
<FromGitter>
<grkek> it can be a 0.0.1 or 100.0.0 doesnt really matter to me
<FromGitter>
<grkek> But about that breaking change you are correct but
<FromGitter>
<Blacksmoke16> can matter to the people that are using it but :shrug:
<FromGitter>
<grkek> there is a reason I did this
<FromGitter>
<grkek> I want to move away from the instance cancer that was before 1.1.2
<FromGitter>
<Blacksmoke16> right, so should have did `2.0.0` to show its not BC with `1.x.x`
<FromGitter>
<Blacksmoke16> just something to keep in mind for the future
<FromGitter>
<grkek> will do it now lmao
<FromGitter>
<grkek> no problem ayo
<FromGitter>
<Blacksmoke16> its a good practice. The version of your application is kind of a contract of expectations between you and the user
<FromGitter>
<Blacksmoke16> problem still kinda exists, but :shrug: be kinda hard to fix at this point
<FromGitter>
<Blacksmoke16> prob doesnt matter too much in this context given its not something you frequently update/nor used by like millions of people
<FromGitter>
<Blacksmoke16> deprecate the `1.x` line, have people use `2.x` and have a clean slate
<FromGitter>
<grkek> Ill delete the old releases hehe
<FromGitter>
<Blacksmoke16> 🙈 oh boy
<FromGitter>
<j8r> O.o
<FromGitter>
<j8r> nothing stop you to have 2 releases
<FromGitter>
<j8r> pointing to a same commit
<FromGitter>
<Blacksmoke16> deleting them is arguably worse, breaks installs for people that are currently using it
<FromGitter>
<grkek> So Ill keep them?
<FromGitter>
<grkek> Im confused here, what do I do?
<FromGitter>
<Blacksmoke16> keep them
<FromGitter>
<Blacksmoke16> but tell people to upgrade to `2.x`, that the `1.x` line is no longer maintained
<FromGitter>
<grkek> Great idea, Ill list that in the readme?
<FromGitter>
<Blacksmoke16> sure?
<FromGitter>
<Blacksmoke16> prob would be fine
[gnubie] has quit [Ping timeout: 258 seconds]
<FromGitter>
<grkek> aight
<FromGitter>
<grkek> Done, can you check it out and tell me if its visible enough?
<FromGitter>
<Blacksmoke16> probably fine
f1reflyylmao is now known as f1refly
<FromGitter>
<Blacksmoke16> got a new semi-experimental feature added to validator
<FromGitter>
<Blacksmoke16> PHP changed their annotation syntax to similar to crystal's is like `#[MyAnn]` now
<FromGitter>
<Blacksmoke16> i like that better than what i thought it was, `<<MyAnn>>`
<sorcus>
:-)
<FromGitter>
<grkek> pHp shouldnt exist
<jhass>
next up: 80% of syntax highlighters get broken because they render that as a comment
<FromGitter>
<grkek> pHp introduced a ground breaking feature `#[Annotation]`, keep in mind that comments start with # as well haha good luck :PPPPPP - pHp team
<jhass>
tbf PHP uses C style comments, // and /**/ but syntax highlighters are often sharing rules for stuff like this
<FromGitter>
<grkek> Most of the C is pHp
<FromGitter>
<grkek> the dev of php was a C programmer so he took concepts from it and put it in php
deavmi has joined #crystal-lang
<FromGitter>
<jwoertink> Is there a way to get the line number of where a method is called from?
<jhass>
why would every method in your app need that info
<FromGitter>
<jwoertink> If I wanted a UX where you call a method, but need additional info, I could say "Hey, look at your code on Line X in this one file, you should also do ABC"
<FromGitter>
<jwoertink> but if I wanted many of my methods to have this capability, I'd have to add that default arg on all those methods
<FromGitter>
<jwoertink> Not a huge deal, I just thought it'd be cool
<jhass>
sounds like exceptions
<FromGitter>
<Blacksmoke16> hmm, got an example?
<FromGitter>
<jwoertink> Yeah, pretty much like exceptions but sometimes trying to wade through the stack trace can be super tricky for someone that's brand new to programming
<FromGitter>
<jwoertink> no specific examples yet. Just sort of a planning phase
<FromGitter>
<Blacksmoke16> but is not using something that is a standard thing just because new programmers would have a hard time a valid reason?
<FromGitter>
<Blacksmoke16> to not use them*
<FromGitter>
<jwoertink> yeah, I'd say so
<FromGitter>
<jwoertink> but not a huge deal. I was just curious if there was already a way
<FromGitter>
<Blacksmoke16> but i imagine thats an expensive operation as its essentially stack trace w/o the exception
<jhass>
oh, we got caller! I wasn't sure
<jhass>
note it depends on debug info too, so might go wonky in release builds
<FromGitter>
<jwoertink> oh yeah. I always forget about caller
<FromGitter>
<lbarasti> Hi folks, wanted to confirm something: if I have a bunch of fibers wrapping `TCPSocket`s connected to peers in a P2P application, is using `IO::Evented` a viable way to not have fibers blocking on operations such us `socket.read_byte`?
<jhass>
the point of fibers is that you can have so many that you can just block them
<FromGitter>
<lbarasti> the issue I'm trying to work around: if I am running the app in multi-threaded mode, and I have, say, 4 workers, then 4 peers can "stall" the app by keeping my client waiting
<jhass>
put each socket into its own fiber that read blocking and forward to a channel, then in your workers you can use select among the channels
<FromGitter>
<Blacksmoke16> if they're using fibers wouldnt the fact they're blocked make it switch to other peers
<FromGitter>
<lbarasti> > the point of fibers is that you can have so many that you can just block them ⏎ ⏎ The issue is, AFAI can see, the runtime does not yield to other fibers if the IO on a running fiber is hanging
<jhass>
it should be, that'd be a bug
<oprypin>
@lbarasti: that's wrong, there's no such issue
<FromGitter>
<lbarasti> OK, I'll try to put together a minimal example, and hopefully figure that I'm wrong 👎
<oprypin>
the entire point of fibers is to yield on IO
<FromGitter>
<lbarasti> no, I think that's a misconception. Either the IO mechanism is event based or it isn't. Fibers don't play a part in this, AFAIK
<FromGitter>
<lbarasti> ah! Yes! Great! I was mistaken, thanks for showing me 🙏
<jhass>
gladly :)
<FromGitter>
<lbarasti> A small example I made to convince myself: https://carc.in/#/r/9udt it won't run in carc.in - I think due to the port binding - but you can try it locally