<hightower2>
now it would be great if there could be last touch made to it to end the for() when it finds the initialize, and possibly to reduce the first search for initialize and subsequent loop into one...
<FromGitter>
<Blacksmoke16> Nice one
<hightower2>
is there a way to break a for loop on first find?
<hightower2>
(within macros)
<FromGitter>
<Blacksmoke16> not that i know of
<hightower2>
Blacksmoke16 also I had another idea in mind... Didn't try it out but at first glance it seemed it could work... like, currently we rely on a macro which finds the event subclasses and in each of them it creates an aeeay _events_{{e.name}} : Array(Proc(args, Bool)).
<hightower2>
I was thinking, how about if the creation of an event would just push the event and type/args to some ArrayLiteral or HashLiteral inside macros
<hightower2>
and then inside macro finished,
<hightower2>
we created a NamedTuple of { EventName: Array(Proc(args, Bool)) }
snsei has joined #crystal-lang
<hightower2>
this would limit the number of events to 300 (the current max size of tuples?), but it seems it would allow to move most of the event functions outside of macros into regular crystal then
<hightower2>
s/aeeay/array/
<FromGitter>
<tenebrousedge> can't you do like `::EventHandler::Event.all_subclasses.find {|e| e.methods.concat(e.ancestors.map(&.methods)).find(&.name.==("initialize") }`
<hightower2>
mm, I tried it, told be it can't do OpAssign. Let me check again
<hightower2>
It seems to me the behavior is [] + [1] = [[1]] instead of [1]
<hightower2>
(With ArrayLiteral#+)
<FromGitter>
<tenebrousedge> that's weird. That's not what the docs imply
<hightower2>
Let me tyr
<hightower2>
try*
<hightower2>
hmm, seems to work.. what I see is when I use +, then in the loop I get ArrayLiteral instead of TypeNode, that's why I assumed it added the whole array
<FromGitter>
<Blacksmoke16> doesnt look like there are any methods to do that atm
<raz>
i'll also be happy about a more longwinded way to convert that hex string back to an int
<raz>
these conversions are a bit over my hea
<raz>
d
<FromGitter>
<tenebrousedge> well, to be fair, it seems that it's not that `to_i` doesn't work, it's that the resulting number is too large
<FromGitter>
<tenebrousedge> what are you trying to do?
<raz>
generate a postgres lock id which has to be a 64bit number
<FromGitter>
<Blacksmoke16> `to_i64`?
<FromGitter>
<Blacksmoke16> nvm
<FromGitter>
<tenebrousedge> so just any 64 bit number?
<FromGitter>
<tenebrousedge> well, may as well use a hash algo I suppose
<raz>
still getting that argumentError for Digest::MD5.hexdigest(id).to_i64
<raz>
well, that's what i'm trying to do. to use a hash algo :D
<raz>
oh wait... md5 is longer than 64bits
<FromGitter>
<tenebrousedge> right
<FromGitter>
<tenebrousedge> did you try `id.hash` ?
<FromGitter>
<tenebrousedge> because that would seem to produce the result you want
<raz>
Digest::MD5.hexdigest(id)[0..14].to_i64(16)
<raz>
that works!
<FromGitter>
<tenebrousedge> I mean, yes, but Crystal has object hashing built-in
<raz>
would that hash be stable (same output for same input string) till the end of the universe, tho?
<FromGitter>
<tenebrousedge> no, only for the same object
<raz>
i'll stick with md5 then ;)
<FromGitter>
<tenebrousedge> k
duane has joined #crystal-lang
teardown has quit [Ping timeout: 265 seconds]
<FromGitter>
<asterite> also `hash` changes from run to run
dannyAAM has quit [Quit: znc.saru.moe : ZNC 1.6.2 - http://znc.in]
dannyAAM has joined #crystal-lang
snsei has joined #crystal-lang
return0e has joined #crystal-lang
return0e_ has quit [Ping timeout: 246 seconds]
<FromGitter>
<christopherzimmerman> Design question: I'm leaning towards not importing every method by default as part of module, and having additional imports to add functionality to my core class. ⏎ ⏎ So for example: ⏎ ⏎ ```require "bottle/linalg" ⏎ require "bottle/fft"``` ... [https://gitter.im/crystal-lang/crystal?at=5dd98601b010e62276593543]
<FromGitter>
<Blacksmoke16> What's the reasoning for not just including it by default?
<FromGitter>
<j8r> it is intuitive if there are `Bottle::Linalg` and `Bottle::Ftt` modules
snsei has quit [Ping timeout: 240 seconds]
<FromGitter>
<christopherzimmerman> I guess I don't have a great reason. No harm in having them all on the class.
<FromGitter>
<tenebrousedge> I mean, including additional modules doesn't incur much runtime cost if they're not used, right?
<FromGitter>
<christopherzimmerman> I assume the compiler would take care of that yea.
<FromGitter>
<j8r> yes, if not used, not included at all
<FromGitter>
<Daniel-Worrall> It would only *slightly* increase compile time
<FromGitter>
<Daniel-Worrall> probably by an immersurable amount unless you were requiring every shard under the sun
<FromGitter>
<christopherzimmerman> @konovod any plans to continue work on linalg?
<FromGitter>
<lbarasti> I might have stumbled upon a `Channel#select` issue, CC: @bcardiff @waj @firejox ⏎ ⏎ ``` code paste, see link``` ⏎ ⏎ raises `Unhandled exception in spawn: BUG: Fiber was awaken from select but no action was activated (Exception)` ... [https://gitter.im/crystal-lang/crystal?at=5dd99b031bf5192e6691135c]
<FromGitter>
<manveru> @kingsleyh i use nix for that :)
<FromGitter>
<Blacksmoke16> @lbarasti i think thats fixed in master
<FromGitter>
<Blacksmoke16> at least i dont get an exception when running it against master
<FromGitter>
<Blacksmoke16> interestingly enough i dont get an error on `0.31.1` either
<FromGitter>
<kingsleyh> @manveru ball is just a super simple manager with almost no options
<FromGitter>
<lbarasti> I'm on 0.31.1, so is the play snippet shared above
<FromGitter>
<Blacksmoke16> mac?
<FromGitter>
<lbarasti> @Blacksmoke16 yes, mac locally
<FromGitter>
<Blacksmoke16> moment
<FromGitter>
<j8r> I prefer to compile it on my own
<FromGitter>
<lbarasti> BTW, would be great to get this documentation PR in before the release cut https://github.com/crystal-lang/crystal/pull/8356, I don't know if you have the power @Blacksmoke16
<FromGitter>
<Blacksmoke16> i do not
<FromGitter>
<j8r> @kingsleyh we don't need to be root to install Crystal
<FromGitter>
<kingsleyh> @j8r it just uses the official installer which asks for root during install
<FromGitter>
<Blacksmoke16> does it spawn a fiber or?
<hightower2>
yes, it uses channels in the background
<FromGitter>
<Blacksmoke16> neat
<hightower2>
or rather, for fibers - yes or no, if you already have two fibers you can get it going without creating any additional ones
<FromGitter>
<Daniel-Worrall> hightower2 why do you have the procs return a bool? Couldn't you just use nil (or any other return?)
<hightower2>
Well, initially I wanted to use a bool so that, if you execute handlers synchronously, you could look at the return value of emit() and see if all handlers "succeeded" or not
<hightower2>
However, I've been playing with the idea of potentially allowing any return value, and also having a variant of emit() which does not just return a true/false but gathers all return values and returns them in a list or tuple
<hightower2>
However I think bool is not too distracting, because even if it was set to return nil, you'd still have to write "nil" at end of handlers instead of "true"
<hightower2>
One simplification could sure be that any return value is simply converted to a true/false implicitly, so one wouldn't have to pay attention to return a bool if not really interested in return values
<hightower2>
I'll add it to the todo, thanks
<hightower2>
Speaking of which, how do you suggest I approach the idea of returning any (or rather, not having to care about return value)? One idea I have so far is that, since handlers are currently automatically wrapped into wrapper objects, the "call" on the wrapper object could take any return value from the handler and simply !! it before returning
<hightower2>
However, I think this would still require providing some explicit Proc(..., ReturnType) for the inner/actual handler, which could be inconvenient
<FromGitter>
<Blacksmoke16> i think im more in favor of having the listeners mutate the event obj
<hightower2>
This would then mandate the return type on the per-event level?
<FromGitter>
<Blacksmoke16> i mean is there really any use case to return something in the first place?
<hightower2>
well, I thought it'd be nice to have this true/false status in case all handlers execute synchronously, but I'm not hung up on sticking to this
<hightower2>
Is there a way to supress the return value? Or somehow ignore it?
<hightower2>
If the Proc was defined to return NoneType, wouldn't this force ending all procs with 'nil'?
<FromGitter>
<Blacksmoke16> pretty sure if you type the proc to return `Nil`, it'll return nil even if the last value is not nil
<hightower2>
Blacksmoke16 actually this idea of mutating the event for return values is fabulous. It would allow the handlers to return nil always, and if someone cared about return values they could implement them via properties on the event, requiring no special support from the core
<FromGitter>
<Blacksmoke16> indeed
<FromGitter>
<Blacksmoke16> example of that would be how i plan to use it in athena
<FromGitter>
<Blacksmoke16> have a like `HttpEvent` that has references to the request/response
<FromGitter>
<Blacksmoke16> listeners mutate them by adding headers etc
<hightower2>
fabulous, I'm gonna switch to Nil returns right now
<FromGitter>
<Blacksmoke16> like say for CORs, or rendering errors
<FromGitter>
<Blacksmoke16> 👍
<FromGitter>
<Blacksmoke16> is a much better approach than the `HTTP::Handler` setup i have now tbh
<FromGitter>
<j8r> How can I deactivate auto flush for STDOUT in master?
<FromGitter>
<Blacksmoke16> isnt it like `STDOUT.sync = false`?
<hightower2>
But using nils... when dealing with blocks I do/would have to end with nil so that when blocks are converted to Procs the signature matches, right? Or is there any way to force ignore of the return value?
<hightower2>
yes, yes, this is what I meant that I'd have to specify nil in some cases... Or well, I seem to remember I could dump the whole body of blocks within macros with {{block.body}}, so maybe I could just create my own block with dumped body, and just added 'nil' at the end