ChanServ changed the topic of #crystal-lang to: The Crystal programming language | | Fund Crystal's development: | GH: | Docs: | Gitter:
ur5us has joined #crystal-lang
HumanG33k has quit [Quit: WeeChat 3.0]
HumanG33k has joined #crystal-lang
<FromGitter> <nanobowers> @christopherzimmerman yes still working (slowly) on fixing up py2cr. I had started working on a branch devoted to, then backtracked to fix some other remaining non-numpy related translation issues, probably will try to get in some refactoring and then go back to integrating numpy--> support. I'm considering redoing the numpy translation features that were from py2rb which relied on a big YAML
<FromGitter> ... mapping file and handle it all on the python side with some extra python modules, but that's still a half baked idea.
<FromGitter> <nanobowers> thanks for putting together the `device-agnostic` branch, looking forward to using it.
<FromGitter> <jemc> Is there a macro method way of getting the doc comment string for a given type/property? I'm interfacing with a C framework that supports runtime reflection of docs for user types, so I'd like to be able to register the doc strings at runtime. ⏎ ⏎ I see that AST nodes have the `doc` method on them, but I don't see it exposed in
<FromGitter> ... b/master/src/compiler/crystal/macros/ ⏎ ⏎ Is it just not exposed (yet)? []
<FromGitter> <HertzDevil> the compiler has no access to docs outside the docs generator
<FromGitter> <jemc> Thanks!
<FromGitter> <jemc> *contemplates the evil workaround of `.filename`, `.line_number`, and `read_file`*
ur5us has quit [Ping timeout: 264 seconds]
Munto has quit [Ping timeout: 260 seconds]
olbat__ has joined #crystal-lang
olbat__ has joined #crystal-lang
lanodan_ has joined #crystal-lang
olbat has quit [Ping timeout: 260 seconds]
lanodan has quit [Ping timeout: 260 seconds]
Munto has joined #crystal-lang
ur5us has joined #crystal-lang
ur5us has quit [Ping timeout: 258 seconds]
sorcus has quit [Quit: WeeChat 3.2.1]
sorcus has joined #crystal-lang
<FromGitter> <Blacksmoke16> @jemc could you parse the `index.json` file and just use that?
lanodan_ is now known as lanodan
<FromGitter> <gregoryc> Hi!
<FromGitter> <gregoryc> Is this chat active?
<FromGitter> <Blacksmoke16> yes
<FromGitter> <gregoryc> Oh nice! I love Crystal
<FromGitter> <gregoryc> I've used it a fair bit
<FromGitter> <gregoryc> Does Crystal have a mailing list?
<FromGitter> <gregoryc> I'm pretty active on the Ruby one
<FromGitter> <Blacksmoke16> seems to mention it, but not sure if that's just outdated or if it's still a thing
<FromGitter> <gregoryc> I have a question
<FromGitter> <gregoryc> Why is Crystal's regexp so fast? It has been faster than C or C++ using multiple libraries, including PCRE (which Crystal seems to use)
<FromGitter> <gregoryc> It would have to do with mutlithreading
<FromGitter> <gregoryc> But why?
<FromGitter> <gregoryc> in my testing, I mean
<FromGitter> <gregoryc> My email is
<FromGitter> <Blacksmoke16> Crystal binds to libpcre yea
<FromGitter> <Blacksmoke16> but by default Crystal is still single threaded, so dont think it has anything to do with MT
<FromGitter> <gregoryc> Supposedly, but it has been faster than plain C PCRE, or std::thread or boost thread
<FromGitter> <gregoryc> Every time
<FromGitter> <gregoryc> For C or C++
<FromGitter> <gregoryc> There might be optimizations that the compiler does?
<FromGitter> <gregoryc> idk
<FromGitter> <Blacksmoke16> :shrug: LLVM is pretty amazing in how it can optimize stuff so who knows
<FromGitter> <gregoryc> Idk
<FromGitter> <gregoryc> But it was MARKEDLY faster
<FromGitter> <gregoryc> It was actually kind of annoying me, lol
<FromGitter> <gregoryc> Is there are Crystal library that makes porting from ruby easier?
<FromGitter> <gregoryc> No, I mean like a library that extends IO and adds read to do gets_to_end
<FromGitter> <gregoryc> Stuff like that
<FromGitter> <Blacksmoke16> nope
<FromGitter> <Blacksmoke16> just have to make the updates
<FromGitter> <gregoryc> Maybe I can make that
<FromGitter> <gregoryc> And shareit
<FromGitter> <gregoryc> *share it
<FromGitter> <Blacksmoke16> could prob start by just copy pasting the Ruby and run it, then fix the errors the compiler finds until there are no more
<FromGitter> <Blacksmoke16> assuming it's not huge
<FromGitter> <gregoryc> Yeah
<FromGitter> <gregoryc> I use Crystal for like 20 or 30 programs as it is
<FromGitter> <gregoryc> I haven't shared this that much
<FromGitter> <gregoryc> But this is my gem
<FromGitter> <gregoryc> gem install democracy
<FromGitter> <gregoryc> If anyone lives near Ottawa, give me an email at, and let's meet in person :)
<FromGitter> <gregoryc> I'm already going to meet someone from the Ruby mailing list
<FromGitter> <gregoryc> But that will probably just be 2 person
<FromGitter> <gregoryc> I <3 Crystal
<yxhuvud> gregory: if it is a static regexp perhaps crystal is smart enough to precompile it so that it isn't compiled every time?
<FromGitter> <gregoryc> But they weren't static!
<FromGitter> <gregoryc> I even tried with arguments from ARGV
<FromGitter> <gregoryc> Still faster
<yxhuvud> oh, then I don't know. especially as the enabling of PCRE JIT compilation isn't merged yet.
<FromGitter> <gregoryc> And I even tried against optimization settings, e.g., for std::regexp
<FromGitter> <gregoryc> Still faster
<FromGitter> <gregoryc> I used PRCE JIT
<FromGitter> <gregoryc> still faster!
<FromGitter> <gregoryc> Supposedly, NIM's regexp is extremely fast
<FromGitter> <gregoryc> Nim
<FromGitter> <gregoryc> But Crystal's regexp is better than nim
<FromGitter> <gregoryc> Btw, I use Crystal to make a simpler sed
<FromGitter> <gregoryc> There are different programs
<FromGitter> <gregoryc> One is gsub!
<FromGitter> <gregoryc> Like the ruby and Crystal method
<FromGitter> <gregoryc> gsub! foo bar file
<FromGitter> <gregoryc> Foo is a regexp
<FromGitter> <gregoryc> I also have r!, which is like Python replace, but in place
r0bby has quit [Ping timeout: 264 seconds]
r0bby has joined #crystal-lang
<FromGitter> <jemc> Trying to make my library as easy to use as possible. ⏎ ⏎ Requiring the library user to do a separate `crystal docs` step ahead of time and make that available to find at runtime in a predefined location seems to be counter to that goal. Unless I misunderstood your suggestion.
<FromGitter> <jemc> Also for my particular program using this library I want zero runtime file dependencies - all the assets will be embedded in the program binary. So that rules out loading an `index.json` at runtime anyway
<FromGitter> <Blacksmoke16> `make docs` then can do whatever you need and still a single command
<FromGitter> <Blacksmoke16> could deff generate/embed it in the binary and process before the app runs? cache it in a class var
<FromGitter> <> I should be able to brew install crystal on arm now correct?
<FromGitter> <> ``````
<FromGitter> <jemc> When it gets to the point that I'm generating Crystal code as text to a `.cr` file it begins to feel no less hacky than the ugly `read_file` approach
<FromGitter> <jemc> Anyway, I'm not complaining here. I appreciate your help.
<FromGitter> <asterite> @gregoryc maybe the C/C++ code you are trying it recompiling regexes all the time?
<FromGitter> <asterite> it -> is
<FromGitter> <asterite> When you use /regex/ in Crystal, it will compile it once and cache that compiled regex. Maybe in the other languages they don't do that, so the regex is recompiled again (probably they don't have regex literals so you are doing the compiling+matching all of the time)
ur5us has joined #crystal-lang
postmodern has joined #crystal-lang
postmodern has quit [Read error: Connection reset by peer]
postmodern has joined #crystal-lang
ur5us has quit [Ping timeout: 258 seconds]
postmodern has quit [Read error: Connection reset by peer]
ur5us has joined #crystal-lang
Chillfox has joined #crystal-lang