<FromGitter>
<Blacksmoke16> but would have to `extend M` not include it
<hightower2>
aha ok
<hightower2>
hm in macros, if I have argument String.class , how get from that to having String ?
<FromGitter>
<Blacksmoke16> `.gsub /\.class/, ""`
<FromGitter>
<Blacksmoke16> but to be clear, those arent the same thing
<hightower2>
yes, right, I would need to change the type, not do the string substitution
<FromGitter>
<Blacksmoke16> what are you trying to do exactly?
<hightower2>
Playing with code where I changed SomeClass.all_subclasses into SomeModule.includers . So now the arguments I get are different (where previously I'd get "SomeSubclass" from a call to all_subclasses, now with .includers I get SomeSubclass.class
<FromGitter>
<Blacksmoke16> mm you should get the same thing
<hightower2>
tested, with .all_includers, I get elements like SubClass1, SubClass2, etc. While with .includers I get SubClass.class
<hightower2>
I mean I do: {% for e in ::EventHandler::EventImpl.includers %}{% puts e %}{% end %}... and if I use Mod.includers, this gives me e.g. String.class, whereas if I do Cls.all_subclasses I get just String
<FromGitter>
<Blacksmoke16> :shrug:
<hightower2>
(in the actual code... not sure why it's not directly reproducible on carc)
<hightower2>
ah
<hightower2>
this happened after changing include to extend
<FromGitter>
<Blacksmoke16> makes sense i guess, prob a but that `.includers` returns types that were `extend`ed
<hightower2>
but if that's so, the question is still the same... how to get rid of .class
<FromGitter>
<Blacksmoke16> bug*
<FromGitter>
<Blacksmoke16> try `.instance`
<hightower2>
that seems to have worked for the immediate issue, thanks
<FromGitter>
<Blacksmoke16> id file a bug for that
<hightower2>
done, but somehow I think the answer will be that it was intentionally made so
<FromGitter>
<Blacksmoke16> naw, i added that feature, it wasnt intentional :P
<hightower2>
;-))
<hightower2>
Blacksmoke16 but then macros need another method to get the list of classes using 'extend'? At the moment .all_subclasses does not seem to include it, and them being included in .includers you say is an error
<FromGitter>
<Blacksmoke16> probably, i remember seeing an issue about it but cant find it atm
<FromGitter>
<HertzDevil> there shouldn't be any differences between a type extending a module or the type's metaclass including the module, so i'd say that's intended behaviour
<FromGitter>
<Blacksmoke16> the name isnt entirely accurate now tho
<FromGitter>
<Blacksmoke16> i.e. if i extend a module i wouldnt expect it to show up when calling `.includers`
<FromGitter>
<HertzDevil> i do
<FromGitter>
<Blacksmoke16> mmm, but you're not including it
<FromGitter>
<Blacksmoke16> id be fine with a diff name that covers both, but is a bit unexpected atm
deavmi has quit [Ping timeout: 258 seconds]
deavmi has joined #crystal-lang
_ht has joined #crystal-lang
yxhuvud has quit [Read error: Connection reset by peer]
<FromGitter>
<error256> IDK about language features, but in terms of functionality recursive anonymous functions can be done like this in many languages: https://carc.in/#/r/a6ap
<hightower2>
nice, thanks
Dreamer3 has quit [Quit: Leaving...]
entel is now known as to0n
<oprypin>
wait, if `super` and `previous_def` are special in a very special manner, why is `super` widely considered a keyword, and `previous_def` definitely isn't?
to0n is now known as entel
<straight-shoota>
oprypin, who doesn't consider previous_def a keyword?
<oprypin>
straight-shoota, lexer.cr
<oprypin>
also highlighter.cr
<straight-shoota>
I suppose there's no reason for that because to the lexer it's just an identifier/call
<oprypin>
i'm trying to find what difference it makes the fact that lexer.cr has :super but doesnt have :previous_def
<straight-shoota>
yeah, probably not much
<oprypin>
i dont even know what `forall` is
<oprypin>
never mentioned in lexer.cr
<oprypin>
what's lexer.cr even used for? lol
<straight-shoota>
all work done by parser
<straight-shoota>
=)
ua has quit [Ping timeout: 264 seconds]
ua has joined #crystal-lang
MasterdonX has quit [Ping timeout: 264 seconds]
willamin has joined #crystal-lang
<FromGitter>
<drum445> I've found a potential problem with the DB driver, I'm hosting a kemal app and the connection is handled using the standard DB.open. The problem is if the app is unused for many hours (overnight) the first request will throw a connection lost error so I've had to add a manual retry
<FromGitter>
<drum445> has anyone else experienced this? Not a big deal to add a manual retry, but shouldn't the driver deal with long open connections
<straight-shoota>
@drum445 I'd figure this behaviour depends on the exact driver you're using
<FromGitter>
<drum445> mysql
<FromGitter>
<drum445> am I right in thinking my kemal app should have a global db connection which uses DB.open, instead of calling DB.open per request?
<straight-shoota>
yes, totally
<straight-shoota>
DB manages connections for you
<FromGitter>
<drum445> perfect, so I have a static class that looks like this (I think you may have suggested this a long time ago)
<FromGitter>
<drum445> Then my controllers that need a DB, simple use DBHelper.maria - does that sound correct?
<straight-shoota>
yeah
<straight-shoota>
from what I understand, this works correctly for you in general?
<FromGitter>
<drum445> It works great, the only problem I've seen is when the app is unused for a while, then the first request after a long time will throw a connection error
<FromGitter>
<drum445> the ones after that work, but the first one fails - to fix this I added a test query before returning the DB.open instance
<straight-shoota>
so it appears the pools gives you timed out connections after long time of no use
<FromGitter>
<drum445> correct
<FromGitter>
<drum445> so my DBHelper class runs this `@@maria_con.not_nil!.query "select 'a' 'a' from dual" { |rs| }` and if it fails it reauths before returning the DB.open instance
<straight-shoota>
so you do an entire new `DB.open` on failure?
<FromGitter>
<drum445> Yeah, I can't see any way round it
<straight-shoota>
yeah, there probably isn't
<FromGitter>
<drum445> cool, for now running my test query before returning the instance seems reasonable then?
<straight-shoota>
hm, actually DB::Pool has some retry logic that should automatically fall back to making a new connection
<straight-shoota>
not sure, why that doesn't work four you