<FromGitter>
<simonhf> 1) instead of the more verbose timestamp, something shorter like 123456789.12345678. 2. If threads are not used then don't show them...
<FromGitter>
<Blacksmoke16> threads?
<FromGitter>
<Blacksmoke16> where does that come into play
<FromGitter>
<simonhf> I'm assuming `#66625` is the thread?
<FromGitter>
<Blacksmoke16> process ID
<FromGitter>
<simonhf> kk
<FromGitter>
<Blacksmoke16> you can set the formatter proc to control how the message is created, but again, prob overkill
deavmi has quit [Ping timeout: 256 seconds]
<FromGitter>
<simonhf> > not getting much benefit over `puts` ⏎ ⏎ Yep, I was not using Log in the first interaction but I think the Log code is shorter horizontally, and I don't have to mess around with env vars myself... which is nice :-)
<FromGitter>
<Blacksmoke16> 😐
<FromGitter>
<simonhf> s~interaction~interation~
<FromGitter>
<simonhf> iteration even :-)
<FromGitter>
<Blacksmoke16> horizontal length of code isnt really a good reason but :shrug:
<FromGitter>
<simonhf> > you can set the formatter proc to control how the message is created, but again, prob overkill ⏎ ⏎ okay, so it sounds like there is no easy / quick and dirty way...
<FromGitter>
<simonhf> > horizontal length of code isnt really a good reason but :shrug: ⏎ ⏎ we should agree to disagree here :-)
<FromGitter>
<Blacksmoke16> i mean you're making an actual thing here, not some one off
<FromGitter>
<Blacksmoke16> making it more readable/useful is better than just making the lines short
<FromGitter>
<simonhf> yeah, my intention is to actually use ./cre for Crystal one liners and maybe add to it as time goes on...
<FromGitter>
<simonhf> > making it more readable/useful is better than just making the lines short ⏎ ⏎ yeah, but we need to agree to disagree that shorter doesn't always mean less intention revealing code...
deavmi has joined #crystal-lang
<FromGitter>
<Blacksmoke16> my argument there is using `Log` just because it makes the lines short doesnt make it the better option
<FromGitter>
<Blacksmoke16> you could essentially do the same thing with a method that uses `puts`
<FromGitter>
<Blacksmoke16> without all the need for log levels, sources, and such
<FromGitter>
<Blacksmoke16> which would also be even shorter
<FromGitter>
<simonhf> Like this one is longer, but also it has the unnecessarily repeating ENV stuff which is also on the right hand side... so the readers eye has to scan to the right to figure out that it's actually a debug line: ⏎ ⏎ ```Log.debug { "Running #{exe}" }``` [https://gitter.im/crystal-lang/crystal?at=5ed053ea4c9b0f060d2e539e]
<FromGitter>
<Blacksmoke16> thats why i said use a method
<FromGitter>
<Blacksmoke16> granted `Log` might be marginally more efficient since the string wouldnt be created unless its being logged, but you could replicate that if you *really* wanted
<FromGitter>
<simonhf> yep... but why reinvent the wheel with the flag stuff? why not just take advantage for the CRYSTAL_LOG_LEVEL ?
<FromGitter>
<Blacksmoke16> IMO because you dont need logging. You just want to output some debug strings to STDOUT
<FromGitter>
<Blacksmoke16> and its not reinventing the wheel, its like 1 line of code
<FromGitter>
<Blacksmoke16> could even make `log` a macro and not even include those lines in the binary w/o the flag
<FromGitter>
<Blacksmoke16> since its a compile time thing
<FromGitter>
<simonhf> that's true... what I'd really like is to have two different versions of cre; cre and cre_debug, where the cre simply has the instrumentation lines removed completely...
<FromGitter>
<Blacksmoke16> idk if id go that far
<FromGitter>
<Blacksmoke16> is common to do like `./app --debug` or `./app --verbose`
<FromGitter>
<Blacksmoke16> for how small this is its not really worth the effort of trying to remove them
<FromGitter>
<simonhf> like in C/C++ it's common to build a complete new binary for the debug version...
<FromGitter>
<Blacksmoke16> this isn't C/C++ :)
<FromGitter>
<simonhf> > for how small this is its not really worth the effort of trying to remove them ⏎ ⏎ I totally agree... but for me as a newbie, this small thing is like a quest to discover how to duplicate my Perl and C programming patterns in Crystal, and to discover new Crystal patterns... :-)
<FromGitter>
<simonhf> like even perl has constant folding in its compiler...
<FromGitter>
<Blacksmoke16> so w/o the flag `puts` is removed from the resulting binary
<FromGitter>
<simonhf> yep... right...
<FromGitter>
<simonhf> that way you can add arbitrary amounts of instrumentation without ever worrying about introducing overhead to the 'production' non-debug version...
<FromGitter>
<Blacksmoke16> that *is* where using `Log` can help. given this is meant to be a CLI tho, i dont think its required
<FromGitter>
<simonhf> how does Log help with that?
<FromGitter>
<Blacksmoke16> `Log.debug { "str" }` whatever you have in the block isn't executed until its actually logged
<FromGitter>
<Blacksmoke16> i.e. so if you have some "heavy" method, it wont run if its not actually going to be logged
<FromGitter>
<simonhf> surely whether `CRYSTAL_LOG_LEVEL=DEBUG`is set or not, Log.debug {...} is going to have an if statement under the covers which gets executed whether the string is output or not?
<FromGitter>
<Blacksmoke16> codes a bit diff in master, but same idea
<FromGitter>
<Blacksmoke16> return if there isnt a backend
<FromGitter>
<Blacksmoke16> return if the severity isnt allowed
<FromGitter>
<Blacksmoke16> block is only executed if it reaches the `yield`
<FromGitter>
<simonhf> Hmmm... but the function is still called and immediately returns... and the unless is the if statement... so isn't that an overhead?
<FromGitter>
<simonhf> Like if I have a loop from 1 to 1 million with only Log.debug {...} inside the loop... won't the function get called and return 1 million times?
<FromGitter>
<Blacksmoke16> sure, but it wont allocate 1 million strings
<FromGitter>
<simonhf> Right... but with the cre vs cre_debug method then the function call would complete disappear in the production version of the code... no overhead...
<FromGitter>
<Blacksmoke16> ok so you're script would run `0.00001` seconds faster :P
<FromGitter>
<simonhf> haha... depends on the script :-) I mean... it's a general pattern...
<FromGitter>
<simonhf> and some people like debugging with a debugger and others like debugging using instrumentation... and lots of it...
<FromGitter>
<Blacksmoke16> there was talk about removing `Log.debug` from the binary
<FromGitter>
<Blacksmoke16> if the level doesnt support it
<FromGitter>
<simonhf> that sounds like a very similar idea to what I was just explaining... then the `CRYSTAL_LOG_LEVEL=...` would be present at run time and compile time...
<FromGitter>
<simonhf> and you can effectively make a production and debug binary of the code...
<FromGitter>
<simonhf> two separate binaries...
<FromGitter>
<simonhf> makes a lot of sense...
<FromGitter>
<simonhf> like in the C/C++ world you might often make 3 binaries... production, debug, and code coverage...
<FromGitter>
<simonhf> I would love it if Log.debug could disappear at compile time depending upon `CRYSTAL_LOG_LEVEL=...` :-)
<FromGitter>
<Blacksmoke16> we shall see
<FromGitter>
<simonhf> is there a github issue for that?
<FromGitter>
<Blacksmoke16> not that i know of, its deff been brought up tho
<FromGitter>
<Blacksmoke16> adding in an empty block
<FromGitter>
<simonhf> yep...
<FromGitter>
<simonhf> and that could have an even bigger effect in a bigger binary...
<FromGitter>
<simonhf> because the not running debug logs will inflate the binary causing more cache line misses at run-time...
<FromGitter>
<simonhf> and that effect does not sure up in such a trivial example...
<FromGitter>
<simonhf> show up
<FromGitter>
<Blacksmoke16> yup
<FromGitter>
<Blacksmoke16> im not sure how true `more cache line misses at run-time` is tho
<FromGitter>
<Blacksmoke16> if thats something LLVM does or something...
<FromGitter>
<simonhf> it's an interesting subject with cache line misses... LLVM can only do so much... a lot is down to the architecture of the code...
<FromGitter>
<simonhf> for example, PHP5 was an average performance scripting language. then they redesigned the internals for PHP7 and now it's one of the very fastest scripting languages... and one component was squashing the meta data overhead for most of their internal data structures... causing way less cache line misses at run-time...
<FromGitter>
<simonhf> so generally the same PHP script uses lots less memory with PHP7 than PHP5
<FromGitter>
<Blacksmoke16> but wouldnt that be more likely to happen with a change in LLVM/crystal compiler versus user code
<FromGitter>
<simonhf> typical CPUs only have about 8 MB cache to hold all their cache lines... so if the computer has e.g. 128 GB RAM... any of the RAM needs to sit somewhere in the 8 MB cache before the CPU can actually use it...
<hightower4>
Hey how do I combine interpolation with macros - is it OK to write "#{ {% if ... %}v1{%else%}v2{%end%} }" ?
<hightower4>
yes, seems working
<FromGitter>
<simonhf> > but wouldnt that be more likely to happen with a change in LLVM/crystal compiler versus user code ⏎ ⏎ Let's say you have a 100k LOC Crystal source including 10k Log.debug lines... that's going to inflate the binary size not just for the code path, but also for all the strings that the Log.debug uses (even if they are not used, they still exist in the binary)
<FromGitter>
<simonhf> That means the cache lines in the 8 MB are used slightly more, which means slightly less to go around for other stuff... which means more cache line misses...
<FromGitter>
<Blacksmoke16> im not disagreeing with that removing debug/trace logs from the binary is a good idea
<FromGitter>
<Blacksmoke16> however
<FromGitter>
<Blacksmoke16> > We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
<FromGitter>
<Blacksmoke16> id be curious to see how much of an impact that would actually have
<FromGitter>
<simonhf> yeah, it's incredibly specific to individual programs and their use of the 8 MB cache lines...
<FromGitter>
<simonhf> however removing the debug/trace instrumentation from a binary at compile time seems to be a tantalizingly low hanging fruit regarding optimization :-)
<FromGitter>
<Blacksmoke16> write the same thing in crystal and try it?
<FromGitter>
<simonhf> It must do the same thing because crystal cannot cheat the CPU cache line usage...
<FromGitter>
<simonhf> Interestingly, if you run the second compile example and make it loop forever, then because it effectively thrashes the 8 MB of CPU cache, any other program in any language will run dog slow because it too will be starved of cache lines at run-time...
<FromGitter>
<simonhf> The programs end up competing for the little 8 MB cache resource and everything gets slower and slower...
<FromGitter>
<simonhf> but BTW how can I create a byte array in Crystal of an exact number of bytes? and then index and access exactly one of those bytes?
<FromGitter>
<simonhf> @Blacksmoke16 this code went crazy when I tried it: `NUM_BYTES = (128*1024*1024); bytes = StaticArray(UInt8, NUM_BYTES).new(0);`
<FromGitter>
<simonhf> I think it was allocating much more than 128MB ...
<FromGitter>
<simonhf> I had to kill the process... ctrl-c didn't work...
<FromGitter>
<simonhf> going for food now... nice chatting...
<FromGitter>
<mattrberry> Ahhh, I hadn't seen StaticArray. That seems to have solved my problem haha. I was passing a 4096-item Array(Float32) to a c function, and it kept segfaulting. I'm guessing crystal just chunks the array up at some point
<FromGitter>
<mattrberry> I wasted way too much time on that...
<FromGitter>
<watzon> @simonhf did it have trouble running, or compiling?
<FromGitter>
<watzon> @mattrberry you should be able to pass normal arrays, but it is possible that the garbage collector will kill them. You can circumvent that by having a class/instance variable.
<FromGitter>
<watzon> StaticArrays are the best way to go if you can though
<FromGitter>
<watzon> @j8r it's amazing how much removing my top level `HTTP::Client`instance killed performance. I may have to get a pool going quicker than I thought.
zorp_ has quit [Ping timeout: 258 seconds]
DTZUZU_ has joined #crystal-lang
DTZUZU has quit [Ping timeout: 264 seconds]
DTZUZU_ has quit [Quit: WeeChat 2.8]
<FromGitter>
<simonhf> @watzon it compiled and when running started chewing cpu without end...
DTZUZU has joined #crystal-lang
DTZUZU has quit [Read error: Connection reset by peer]
DTZUZU has joined #crystal-lang
DTZUZU has quit [Client Quit]
DTZUZU has joined #crystal-lang
sagax has quit [Remote host closed the connection]
sagax has joined #crystal-lang
rocx has quit [Ping timeout: 260 seconds]
<FromGitter>
<sam0x17> regarding that whole discussion on a performant `Log.debug` sort of thing -- a quick macro can make this zero overhead, similar to how I did asserts here https://github.com/sam0x17/assert.cr
<FromGitter>
<sam0x17> in that case`assert [expr]` statements are only compiled when `--release` is specified as a build flag
Stephie has quit [Quit: Fuck this shit, I'm out!]
Stephie has joined #crystal-lang
zorp_ has joined #crystal-lang
<FromGitter>
<simonhf> @sam0x17 very cool...
DTZUZU has quit [Ping timeout: 246 seconds]
DTZUZU has joined #crystal-lang
_whitelogger has joined #crystal-lang
alexherbo2 has joined #crystal-lang
<FromGitter>
<jwaldrip> whats faster in crystal? Class inheritence or module composition?
_whitelogger has joined #crystal-lang
renich has quit [Quit: renich]
tdc has joined #crystal-lang
<jhass>
jwaldrip: you're worrying about the wrong kind of things. assume things are fast enough until you have proven they're not and a bottleneck
<raz>
yup, in crystal that's a safe assumption for the large majority of tasks. it's very fast. absurdly fast when you consider it can be written almost like a scripting language.
<FromGitter>
<bew> @jwaldrip also, class inheritance and module composition has no runtime impact, it's all a compile-time knowledge and at runtime it makes no difference iirc
alexherbo2 has quit [Ping timeout: 260 seconds]
Vexatoast has quit [Quit: ZNC Quit]
Stephie has quit [Quit: Fuck this shit, I'm out!]
Vexatos has joined #crystal-lang
Stephie has joined #crystal-lang
alexherbo2 has joined #crystal-lang
DTZUZU_ has joined #crystal-lang
DTZUZU has quit [Ping timeout: 240 seconds]
alexherbo2 has quit [Ping timeout: 256 seconds]
zorp_ has quit [Ping timeout: 256 seconds]
rocx has joined #crystal-lang
csaba has quit [Quit: WeeChat 2.3]
csaba has joined #crystal-lang
zorp_ has joined #crystal-lang
alexherbo2 has joined #crystal-lang
<FromGitter>
<j8r> class and struct can have a difference, but composition/inheritance not
<FromGitter>
<j8r> @watzon yeah :/ the only pool is ysbaddaden's one, which is meh-ok
<raz>
i believe what you generally want as a mechanism there is a health check. basically a fiber that calls #healthy? on each pooled connection at regular intervals and evicts them when false
<raz>
could be a bit tricky in MT (needs locking to avoid races) but not super hard in general i think
<FromGitter>
<Blacksmoke16> @straight-shoota I dont suppose your error refactoring is going to fix #7147 and #7394 as well? I'm thinking not since its more so around how errors are formatted...
<FromGitter>
<jwaldrip> Orion uses inheritance to scope routes today. Mostly through a series of constants on the class. If I were to convert that to a module and use namespace scope would it make any difference?
<jhass>
talking about performance still I guess, which is just one aspect of so many to programming. Runtime performance in optimized build, I would be surprised to see one. Compile time performance might be quite affected by how many and how big types there are
<raz>
sigh, latest osx update borked my crystal
<raz>
xcode-select: Failed to locate 'clang', requesting installation of command line developer tools.
<FromGitter>
<Blacksmoke16> prob should have added a `respectively` in there
<FromGitter>
<ErikAGriffin> I see. I was actually confused about what is considered a block. I thought a method definition was a block, but I see that the only valid control-break statement in a method is `return`
<FromGitter>
<ErikAGriffin> The playground is sweet, awesome feature
<jhass>
you can think of blocks and procs as anonymous functions. A block is an implicit argument to a method and thus invoked via a keyword, yield. a proc is explicitly referenced
<raz>
sigh... google still drops me on 0.20.* versions of the docs :<
<FromGitter>
<Blacksmoke16> i just keep a tab open with master
<FromGitter>
<Blacksmoke16> never have to worry about it :p
<raz>
yeh, but it should really be fixed
<jhass>
am I the only one to just type crystal-lang.org/api into the addressbar?
<raz>
i type "crystal lang weakref"
<raz>
for the thrill of which version it will give me this time
<raz>
yea i think those triple moustaches are one too many
<jhass>
it says to use them just below?
<raz>
oh you are right
<raz>
done, submitted
<raz>
i just gave "url has changed" for the reason
<raz>
hope that's good enough
<jhass>
thank you
<jhass>
I tried with two browsers, same :/
<jhass>
weird
<raz>
np. it's a bit funny they just let anyone submit changes like that tho
<raz>
didn't even ask my email
<raz>
i'm on chrome fwiw
<raz>
perhaps adblocker or such?
<jhass>
maybe
<jhass>
no, same with disabled
<jhass>
anyway, if that's fixed and you set your search engine to duckduckgo you can just type !crdoc bla into your addressbar
<jhass>
well maybe, still not sure it's actually gonna work due to the fragment
<jhass>
this really should be a query
<raz>
yea nah, never had much success with ddg. gonna stick with the google
<raz>
what i'd actually like would be a good desktop api-doc app
<raz>
but all i tried so far were just bad (dash app etc.)
<raz>
one of those itches i gotta scratch myself one day
<jhass>
I think somebody turned devdocs.io into an electron app?
<raz>
yes, as said
<raz>
it's a tragedy
<raz>
and dash can't even *scroll* smoothly
<raz>
i have no idea how they even managed that...
<jhass>
I have no problem with that
<raz>
with dash?
<jhass>
yeah
<raz>
oh yea looks like it got fixed, just reopened it
<jhass>
maybe you were just running too many compilers in the background last time you tried :P
<raz>
nah but my last mac didn't have a GPU
<jhass>
Idk, I have dash open but somehow I tend to not use it much
<raz>
yea... the UI is also rather... questionable
<raz>
the search doesn't work for me at all
<jhass>
more for browising android docs than anything else really
<jhass>
idk it's a hard problem
<FromGitter>
<mattrberry> @watzon Ahh, that's interesting. On a related note then, why does the StaticArray not get GC'd?
<jhass>
I loved devdocs.io but then I enabled too many languages and it got useless
<jhass>
In the end I always want to search scoped for a project
<jhass>
so I just open the particular official docs
<raz>
yea... and scoped for item-type
<raz>
when i search for String i don't want everything in the universe that mentions a string to pop up
<raz>
i just want the class or module, pretty much all of the time
<FromGitter>
<mattrberry> Oh it's allocated on the stack, got it
<jhass>
Dash does that nicely actually, sorts classes first
<raz>
...followed by the ctors and methods right there
<raz>
without having to scroll through three screens of introduction text
* raz
is picky
<jhass>
yeah but just don't look down if you know you're looking for the class?
<jhass>
what I kinda want is to chain scopes, like I type "crystal string sub" and it lists me Crystal String#gsub and String#sub but Ruby's
<raz>
well, i'll give it another shot now that i have it open again :p
<jhass>
and then best fuzzy, so "cr stn sb" does the same
<raz>
yes... that too
<raz>
i bought it like a decade ago, give it a try for a day every once in a while, but something always rubs me the wrong way
<jhass>
that I didn#t figure out how to do in dash yet
<jhass>
maybe I have to manually set up this search trigger stuff
<raz>
yup
<jhass>
oh looks like for the toplevel you just need to add a :
<jhass>
and you can configure triggers on the docset
<raz>
hm hm
<jhass>
well not multiple, so still profiles for that
<jhass>
so rb: String gets me to string now, but the third word just does a search in page :/
<jhass>
ah no, it also filters the bottom pane, mmh
<jhass>
I kinda don't want to type the : though
<raz>
exactly
<raz>
crystal needs a strong UI lib, then i'll write an api alfred
<raz>
it's on my bucket list
<jhass>
which UI framework you'd want?
<raz>
this "trapped in an overloaded, dedicated window" approach just doesn't work for me. i need to zip in and out of that stuff. not switch context to an "api browser app"
<raz>
but that's just me
<raz>
well, basically just a binding that lets me do all the fancy OSX stuff (mostly overlays/chromeless windows) in crystal
<jhass>
ah okay, so just macos
<raz>
yea, that's enough for me. if it works cross platform fine, but i don't think the ui i'd want can be covered with a cross platform kit
HumanGeek has joined #crystal-lang
<FromGitter>
<Blacksmoke16> there a way to check if STDIN is empty?
<FromGitter>
<j8r> @wontruefree the site can't be in HTTPS... :[
<ryanprior>
I'm not very opinionated about the UI framework. I've used GTK and Qt and liked each one okay but didn't love either one. I've done js/html/css but don't want to go that route, I'm trying to create something fairly lightweight and snappy.
<FromGitter>
<watzon> @j8r decided to fork `pool` and make some changes. Added a mutex for some thread safety and the ability to set an initial pool size.
<FromGitter>
<watzon> If you want to request some changes go ahead and drop an issue and I'll try to work on them