<FromGitter>
<paulcsmith> @TheOnlyArtz hop on to https://gitter.im/luckyframework/Lobby if you have any questions about lucky. Lots more people there that can help. But yeah I’d say most of the frameworks all have comparable performance. It’s probably not even worth making it into the equation. But yeah Lucky is fast. In release mode with a simple page it will send an html page in a couple hundred microseconds
<FromGitter>
<paulcsmith> Happy to help more in the Lucky room. I don’t follow this one as closely so I might miss it. Or ping me. I created it so can hopefully help answer your questions about it
_whitelogger has joined #crystal-lang
DmitryBochkarev_ has joined #crystal-lang
DTZUZO has joined #crystal-lang
laaron- has joined #crystal-lang
laaron has quit [Remote host closed the connection]
<FromGitter>
<vladfaust> Hello, little help here, please. What's the most efficient way to turn single `UInt8` into hexstring?
<FromGitter>
<r00ster91> `20_u8.to_s(16)`?
<FromGitter>
<dscottboggs_gitlab> if `to_s base: 16` isn't the most efficient, then it should be?
<FromGitter>
<vladfaust> Thanks, that was not obvious for me :)
<FromGitter>
<dscottboggs_gitlab> hehe I was gonna say if you find a faster way to let us know :p
<FromGitter>
<vladfaust> It's 55M/s on my machine, should be enough :)
<FromGitter>
<vladfaust> Is there a set of rules determining which string building to use -- interpolation or concatenation -- and when chars are better than strings? I.e. ⏎ ⏎ ``` code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5cb5a30fb34ccd69e7c8799c]
<FromGitter>
<vladfaust> Sometimes interpolation is faster. What does it depend on?
<FromGitter>
<dscottboggs_gitlab> i think since strings are sequences of chars (despite the whole char != UInt8 issue), a char would be more efficient to use if possible.
<FromGitter>
<vladfaust> According to the issue, the rule is using concatenation if the amount of "inner" strings is 1-2
<jokke>
vladfaust: i think for longer strings it's most efficient to use String::Builder
<jokke>
since it just uses IO::Memory
<jokke>
afair
<jokke>
but i've made it a habit to use it everywhere
<jokke>
except if it's something really trivial
<jokke>
but i never use { foo, bar }.join('.') or something
<jokke>
not sure how representative this is though because the "hello " + WORLD might be optimized into "hello " + "world" into "hello world" on compile time
fanta1 has joined #crystal-lang
fanta1 has quit [Quit: fanta1]
Vexatos has quit [Read error: Connection reset by peer]
Vexatos has joined #crystal-lang
fanta1 has joined #crystal-lang
_whitelogger has joined #crystal-lang
DmitryBochkarev has joined #crystal-lang
DmitryBochkarev_ has quit [Ping timeout: 250 seconds]
DmitryBochkarev has quit [Ping timeout: 246 seconds]
DmitryBochkarev has joined #crystal-lang
fanta1 has quit [Quit: fanta1]
gangstacat has quit [Ping timeout: 268 seconds]
lucasb has joined #crystal-lang
gangstacat has joined #crystal-lang
<wuehlmaus>
i am not even able to ``shards install'' hedron at all :-(
<FromGitter>
<TristanBomb> The function is being called on a list of entities, some of which are Drawable, some of which are not; of course, we could check whether the entity `is_a? Drawable` before calling the function rather than in the function, but there's going to be many subsystems similar to `Drawable`, so explicitly adding all of those checks will get rather tedious.
<FromGitter>
<tenebrousedge> Is it necessary to define a method for this? It's not reasonable to do `entity.try &.draw` in the parent context?
<FromGitter>
<TristanBomb> Let me give that a shot.
<FromGitter>
<Blacksmoke16> could also try like `entity.responds_to? :tryDraw`
<FromGitter>
<Blacksmoke16> is there some other method that would happen if they are not `Drawable`
<FromGitter>
<TristanBomb> The correct behavior for objects that are not `Drawable` is to simply do nothing. The way the program is structured, there is a list of entities and a number of subsystems designed to handle specific categories of entity (so there might be a `DrawableSystem` and a `ColorableSystem`). To advance the program logic, each subsystem tries to run its specific `apply` code to each entity, so long as that entity is
<FromGitter>
... the correct type. So every `Drawable` entity gets passed into `DrawableSystem.apply`, each `Colorable` entity gets passed into `ColorableSystem.apply`, and so on.
<FromGitter>
<TristanBomb> It's possible I'm going about this entirely the wrong way, though
<FromGitter>
<shreeve> wondering why I get those errors... this code worked in a crystal 0.25-ish... do I need more type hinting in later Crystals???
<FromGitter>
<Blacksmoke16> is there more to the error @shreeve ?
<FromGitter>
<shreeve> that's it...
<FromGitter>
<Blacksmoke16> @TristanBomb `responds_to? :drawTest` prob be way to go then, give that a shot
<FromGitter>
<shreeve> seems like it can't find code with the right signature?
<FromGitter>
<Blacksmoke16> is possible there was a breaking change with Kemal since then
<FromGitter>
<Blacksmoke16> maybe check the changelog
<FromGitter>
<shreeve> proxy is my own method though...
<FromGitter>
<shreeve> ah... maybe headers has a different type?
<FromGitter>
<shreeve> @Blacksmoke16 - i'll check that now... is there a way for me to see (when compiling) what type it *is* so I can find out more?
<FromGitter>
<shreeve> it'd be nice to see what type it's looking to match
<FromGitter>
<TristanBomb> `typeof()`, IIRC
<FromGitter>
<Blacksmoke16> yes
<FromGitter>
<Blacksmoke16> but not at compile time
<FromGitter>
<shreeve> checking kemal source... but, is there a way for the compiler to show what type it is looking for?
<FromGitter>
<shreeve> it knows that it cannot find a match, but it would probably be easy for the compiler to say what it was looking for (but failed to find)
<FromGitter>
<shreeve> ok, i'll try that right now
<FromGitter>
<Blacksmoke16> you dont have any type restrictions on it anyway so it shouldnt matter
<FromGitter>
<Blacksmoke16> is `type` a string in your case?
<FromGitter>
<shreeve> adding &block didn't do anything... checking kemal types to make sure that headers is an HTTP::Headers type (I gotta believe it is)
<FromGitter>
<shreeve> it's "open"
<FromGitter>
<Blacksmoke16> ah right, `&block` just makes it more clear your method takes a block
<FromGitter>
<shreeve> is it the 'body' argument that is causing the confusion?
<FromGitter>
<Blacksmoke16> no, just that i just never saw a method that takes a block without the `&block` param
<FromGitter>
<TristanBomb> Seems like `is_a?` only works on compile-time constants. So I can't do something like `if entity.is_a? subsystem.class::INPUT_TYPE`.
<FromGitter>
<Blacksmoke16> maybe try to use an `enum`
<FromGitter>
<Blacksmoke16> er nvm
<FromGitter>
<shreeve> @Blacksmoke16 - the error message `'proxy' is not expected to be invoked with a block, but a block was given` seems to imply that I really should add the "&block" when defining the method, maybe more than just best practice
<FromGitter>
<Blacksmoke16> compiler sees `yield` and knows it takes a block
<FromGitter>
<Blacksmoke16> afaik there isnt a concept of optional block?
<FromGitter>
<shreeve> I agree with you... I've never *had* to add "..., &block)" before when defining methods... That error message (which doesn't always show up) is a bit gruff though.
<FromGitter>
<Blacksmoke16> maybe thats the issue
<FromGitter>
<shreeve> i think it's mainly due to a change in the HTTP::Client.post(...) args?
<FromGitter>
<shreeve> This used to work (almost a year ago): `yield HTTP::Client.post(UPSTREAM, headers, body).body`
<FromGitter>
<shreeve> but, I think (based on those signatures) that I can't call it like this anymore... I probably need to use `.post(UPSTREAM, headers: headers, body: body)`
<FromGitter>
<Blacksmoke16> i could go with that
<FromGitter>
<Blacksmoke16> no, the third from the top should match
<FromGitter>
<shreeve> I need to pass the response's "body" to the block, I think that one passes the "response" object directly...
<FromGitter>
<shreeve> in this method, do I have to call it with (url: "foo", headers: ..., body: "...") or is ("foo", headers: ... , body: "...") okay?
<FromGitter>
<shreeve> I mean does it know that the first arg is `url` or do I have to say `url: "..."`?
<FromGitter>
<Blacksmoke16> yea but you were doing `yield HTTP::Client.post(UPSTREAM, headers, body).body` i.e. do the request and return the body param to the block
<FromGitter>
<kinxer> @TristanBomb `Drawable` inherits from `Entity`, right? Is there any reason not to define an empty `Entity#draw` method?
olbat[m] has joined #crystal-lang
<FromGitter>
<Blacksmoke16> see if you can narrow down what causes the issue to happen
<FromGitter>
<Blacksmoke16> i.e. try like `yield "FOO"` and if it still happens you know it doesnt have anything to do with the `.post`
<FromGitter>
<shreeve> ok, thanks will try...
rohitpaulk has quit [Remote host closed the connection]
<FromGitter>
<shreeve> @Blacksmoke16 - it's weird... if I have a real error in the code, like trying to use a variable as an integer when it can be a string, then the compiler will error out and show me several errors. But, when I fix that one error... it'll compile just fine. It's almost like there are a set of "warnings" that aren't bad enough to "error out" when compiling. But, if I do have a bad error, then it'll show it to me,
<FromGitter>
... along with all the other things that would otherwise only be considered a warning. Does this match your experience?
<FromGitter>
<Blacksmoke16> must have just been some cached shard or something
<FromGitter>
<shreeve> those compile messages were all pretty much red herrings?
<FromGitter>
<Blacksmoke16> well it was prob running latest crystal against some older version of kemal
<FromGitter>
<Blacksmoke16> would be my guess
<FromGitter>
<shreeve> ok
<FromGitter>
<elorest> In a few hours my company will be demoing our hydrogen electric vehicles at Nikola World 2019. The trucks and off road vehicles are running crystal/amber for their infortainment system and instrument cluster which will be part of the demo. https://nikolamotor.com/
<FromGitter>
<elorest> Live stream will be accessible though the site
<FromGitter>
<Blacksmoke16> hopefully they dont end up like the hindenburg :P
<FromGitter>
<elorest> @Blacksmoke16 Hindenburg didn't burn because of Hydrogen. Mostly it was the wax canvas. Hydrogen is less dangerous than gasoline but still flamable. It has a huge advantage though in an accident because in the case of a leak it rises so fast that the flame is almost always higher than the vehicle.
<FromGitter>
<Blacksmoke16> it probably didnt help tho
<FromGitter>
<kinxer> @elorest I learned something today. Cool.
<FromGitter>
<Blacksmoke16> im a fan of hydrogen, just need a way that as convenient/easy to fuel up as electricity at your house or one of thousands of gas stations
<FromGitter>
<elorest> @Blacksmoke16 True. However the given the circumstances the hindenburg would still have burned even even with helium. Almost everyone got off alive and those who didn't died jumping.
<FromGitter>
<Blacksmoke16> deff going to be a good source of energy in the future
<FromGitter>
<elorest> > im a fan of hydrogen, just need a way that is as convenient/easy to fuel up as electricity at your house or one of thousands of gas stations ⏎ ⏎ We're working on that too.
<FromGitter>
<elorest> Mostly stations.
<FromGitter>
<Blacksmoke16> also would really help when we figure out space travel, given its much easier to find in space than on earth
<FromGitter>
<elorest> Yeah. Methane is also really ubundant in space. As solar becomes cheaper and cheaper it's pretty inexpensive to make H2 out of water. When fuel cells combine it back together it turns back into water again anyway.
<FromGitter>
<elorest> Pretty much any hydrogen that leaks though just drifts off into space. So eventually maybe that could become an issue.
<FromGitter>
<elorest> We use up all the worlds water by turning it to H2 and releasing it...
<FromGitter>
<elorest> Doesn't seem like an issue for a long time though.
<FromGitter>
<Blacksmoke16> ill prob be dead by then ha
<FromGitter>
<Blacksmoke16> *not my problem*
<FromGitter>
<Blacksmoke16> by the time the poles melt there will be plenty of more water to use
<FromGitter>
<Blacksmoke16> ha
<FromGitter>
<shreeve> is working with JSON as hard as it seems in Crystal? just want to create a basic hash and convert it back to JSON...