That_Guy_Anon has quit [Ping timeout: 265 seconds]
That_Guy_Anon has joined #crystal-lang
That_Guy_Anon1 has joined #crystal-lang
faustinoaq has joined #crystal-lang
That_Guy_Anon has quit [Ping timeout: 264 seconds]
<FromGitter>
<faustinoaq> @fgimian I guess we need still to fix breaking changes on scry 😅
wontruefree has quit [Quit: bye]
<FromGitter>
<fgimian> @faustinoaq kewl mate, just checking it wasn't me 😄
<FromGitter>
<fgimian> thanks!
<FromGitter>
<fgimian> perhaps it may be worth trying to ensure that all tooling is compatible before a new release
<FromGitter>
<fgimian> it makes the ecosystem more refined when a new user tries out Crystal for the first time too
johndescs has quit [Ping timeout: 260 seconds]
johndescs has joined #crystal-lang
<FromGitter>
<S-YOU> @faustinoaq, it is working for plain text and json, but I am looking to postgresql async to get it working, you get like 1.2k /s on db write if you do non async, but h2o can be done 10k/s with async call.
<FromGitter>
<S-YOU> Only the issue is they kind of wrote state machine to postgresql and h2o event loop tightly together, I need to replicate that.
<FromGitter>
<Daniel-Worrall> Well, I finally achieved getting the hello world to compile on Windows
<FromGitter>
<Daniel-Worrall> inlcuding using the windows ssh server
wontruefree has joined #crystal-lang
wontruefree has quit [Quit: bye]
That_Guy_Anon2 has joined #crystal-lang
That_Guy_Anon1 has quit [Ping timeout: 260 seconds]
wontruefree has joined #crystal-lang
wontruef_ has joined #crystal-lang
wontruefree has quit [Ping timeout: 265 seconds]
Philpax has joined #crystal-lang
<FromGitter>
<msa7> ``` code paste, see link``` ⏎ ⏎ I would say speed up compilation will help a lot. 20 seconds to run specs on Mac Pro 2015 with Docker 8 CPU is long time. Also compilation time affect work with ECR where on each change you have to wait for recompile. [https://gitter.im/crystal-lang/crystal?at=5b21e76586343c3a32031c60]
<FromGitter>
<snadon> what is the best way of converting an XML to JSON in crystal?
bmcginty has quit [Ping timeout: 248 seconds]
bmcginty has joined #crystal-lang
That_Guy_Anon2 has quit [Quit: Leaving]
<wontruef_>
The structure of json and xml are pretty different I guess it depends on how you want the json to look like
<FromGitter>
<snadon> i just want to map like <key>value</key> to "key": "value" and children should become arrays, i will iterate manually thanks
<FromGitter>
<fgimian> I suppose you could iterate over items in XML and use JSON::Builder to build a JSON object
<FromGitter>
<fgimian> I'm not aware of any way to do a direct conversion of the two, as wontruef_ mentioned, they are different formats, JSON has no concept of attributes like XML does
<FromGitter>
<fgimian> I've seen some solutions to this, seen the xmltodict Python package for some inspiration
<z64>
@j8r interesting :) thanks for looking into it. i'm a contributor to the library my program uses, so i'm very familiar with it. I'll try to reduce it to a small example
akaiiro has quit [Ping timeout: 240 seconds]
<FromGitter>
<bendietze_twitter> If anyone interested: code-runner for VS Code runs with Crystal on Windows WSL too, so its often nice zu run just a selected part with one click as complete source 🕙 but its needed to change terminal to bash (ok, not the problem?) and set code-runner runInTerminal true 💫 maybe interesting for you too @fgimian 😊
<FromGitter>
<bararchy> @bcardiff is there a way to automate the binery signing process? It seems it is right now the only manual part
<FromGitter>
<bendietze_twitter> @sdogruyol if there is any possibility to talk about it would be very nice to know when packtpub will start shipping Learning Crystal Programming 📬 :)
zolbatar has joined #crystal-lang
zolbatar has quit [Client Quit]
zolbatar has joined #crystal-lang
<FromGitter>
<sdogruyol> @bendietze_twitter the book is not finished yet. Giving an exact date would not be a good thing
<FromGitter>
<bendietze_twitter> ok :)
pbodev1 has joined #crystal-lang
<FromGitter>
<bendietze_twitter> @faustinoaq maybe interesting for your useful extensions part of vscode-crystal-lang: code-runner (WSL too) 😄 👍
<FromGitter>
<bendietze_twitter> Ok great :) i will do at evening when i am at home :)
<zolbatar>
Just getting started with Crystal, looking at some test projects to get me up to speed. Is there a "standard" ORM extension?
<FromGitter>
<r00ster91> why is the lexer of Crystal not using StringScanner to lex?
<FromGitter>
<fgimian> Hey @faustinoaq, just working on the VS Code extension but a recent commit seems to have broken syntax highlighting for Crystal, specifically commit id `31cdbec`. I'm not sure why yet, but just be aware of this mate.
<FromGitter>
<fgimian> It threw me off while I was working on the Markdown feature just now.
<FromGitter>
<fgimian> At least this way the master branch is stable again
<FromGitter>
<fgimian> Then I can work on the Markdown improvement we discussed on GitHub 😄
<FromGitter>
<faustinoaq> Well, as RX14 said, parallelism can't make crystal faster on those benchmarks, in fact `reuse_port: true` can be faster than multi threading 😅
<FromGitter>
<bararchy> in Ruby you have `alias_method`
<FromGitter>
<bararchy> don't know if we have it in Crystal
<FromGitter>
<vlazar> just realized LLVM does tail call optimization for Crystal... nice! :)
<FromGitter>
<straight-shoota> Aliases are considered harmful in Crystal. Therefore there's no `alias` macro to encourage using them.
<txdv>
llvm does alot
dogweather has joined #crystal-lang
<FromGitter>
<bendietze_twitter> Sorry guys, but ~30k on this system - i am completely confused. I would say this is impossible less? Knows anybody previous r/s? @Grabli66 @faustinoaq :)
<FromGitter>
<fgimian> the sample rate is the number of samples takes per second, usually measured in Hz
<FromGitter>
<fgimian> 44,100 Hz is CD quality, although pro studios go all the way up to 192,000 Hz (192 kHz)
<FromGitter>
<fgimian> bit depth is the precision by which each sample is taken, 16-bit is CD, and studios use bit depths all the way up to 32-bits
<FromGitter>
<fgimian> hope this helps 😄
<FromGitter>
<codenoid> thank you for helping me get started with audio programming ^^
<FromGitter>
<fgimian> no worries 😄
ragmaanir has joined #crystal-lang
zolbatar has quit [Quit: zolbatar]
Philpax has quit [Ping timeout: 240 seconds]
rohitpaulk has quit [Ping timeout: 240 seconds]
rohitpaulk has joined #crystal-lang
<FromGitter>
<bendietze_twitter> About which_is_the_fastest ... They changed a lot, so it seems from 4-8sec to ~30s Ave and about 30k would be correct 😟 We will be back! 💪 😄
<FromGitter>
<Grabli66> I think if node with 8 cores have almost the same speed as crystal on one core, it's awesome.
<FromGitter>
<bendietze_twitter> You are right! 😄
<FromGitter>
<bararchy> indeed ;)
rohitpaulk has quit [Ping timeout: 256 seconds]
<FromGitter>
<Grabli66> I want to believe that crystal will be the fastest, or atleast faster than .NET and JVM. :)
<FromGitter>
<bararchy> syntax, ease of use, tool-chain, community
<FromGitter>
<bendietze_twitter> Its not every time a good idea to pinch a jvm :) There are things where only the best assembler should do this... But would be a nice thing and possible in many sections :)
<FromGitter>
<Grabli66> But i want everything. :) Good syntax, speed, low memory.
<FromGitter>
<bendietze_twitter> :)
duane has quit [Ping timeout: 260 seconds]
<FromGitter>
<fridgerator> Crystal already has all of those things
<FromGitter>
<bendietze_twitter> 💯 :)
<FromGitter>
<Grabli66> But benchmarks say that .NET and JVM are faster. Hate those benchmarks. They are depress me.
<FromGitter>
<j8r> the performance itself doesn't really matter - except to reduce costs
<FromGitter>
<j8r> if we have an app that scales, we have near infinite performance :)
<FromGitter>
<j8r> Crystal, Java, Go, Rust, C has more or less similar performance - compared to Ruby, Python, Node.JS
<FromGitter>
<bararchy> Yeha
<FromGitter>
<bararchy> also the differance is so low. ⏎ fib is 5 sec in Crystal and 5.1 in Go
<FromGitter>
<bararchy> does anyone cares?
<FromGitter>
<bararchy> will people go from Go to crystal over it?
<FromGitter>
<bararchy> it's 3.9 sec in C
<FromGitter>
<bararchy> should we start working in C?
<FromGitter>
<fridgerator> assembly?
<FromGitter>
<fridgerator> 😆
<FromGitter>
<bararchy> also real world is RPs and JSON parsing speed
<RX14>
nah
<RX14>
real world is DB
<RX14>
JSON parsing and HTTP are likely minimal compared to waiting on the DB in most applications
<RX14>
and template rendering
<RX14>
template rendering is a big one
<FromGitter>
<bararchy> true
<RX14>
if ruby got evented IO, I bet rail's performance wouldn't be a big issue
<RX14>
the most important part of crystal's speed is the CSP and IO scheduler, not the actual code execution speed
<FromGitter>
<asterite> Why everyone is so concerned about performance? Just forget about it. Crystal is about nice syntax, blocks, and being able to provide thousands of overloads for a same method. It's not about performance. Parallelism will make it go slower, not faster, but it will utilize all cores so that a thread doesn't block the entire program. But that's it. Just focus on the happiness of programming in Crystal, not the
<FromGitter>
... end result
<FromGitter>
<fridgerator> I wish people would stop linking techempower benchmarks
<RX14>
techempower benchmarks are good
<RX14>
they're realistic
<RX14>
and newsflash: the reality is that crystal doesn't perform too well
<RX14>
it's natural, performance comes from optimizations which come from maturity
<RX14>
the important thing is that crystal has set an excelent foundation for future performance being at least as good as go
<FromGitter>
<asterite> techempower really sucks. Nobody will choose a language or framework because of the results there
<FromGitter>
<asterite> Who uses h2o in real life?
<RX14>
it doesn't suck for evaluating performance of frameworks
<FromGitter>
<fridgerator> probably richard stallman, I bet he uses h2o
<FromGitter>
<asterite> Crystal can be as good as go in a thousand years :-P
<RX14>
@asterite you're correct that nobody is going to just pick the top result of techempower and use it
<RX14>
but that doesn't mean it sucks
<RX14>
@asterite crystal is already better than go in a few areas and it's improving rapidly, please stop being unrealistically negative
<FromGitter>
<asterite> I'm just being realistic
<FromGitter>
<asterite> If it takes a week to sign release binaries, how much time will it take to do other complex things?
<FromGitter>
<asterite> I mean, it's just paper and pen :-P
<RX14>
@asterite you have many valid points about crystal but saying that crystal cannot achieve the same level of performance as go is completely unrealistic
<FromGitter>
<asterite> Just kidding, everything will be fine
<FromGitter>
<asterite> Well, Go has specialized code for stack space
<FromGitter>
<asterite> It also has specialized code for choosing which registers to use, and which ones are dedicated to context switch
<FromGitter>
<asterite> it has a specialized GC that works really fast
<FromGitter>
<asterite> and so on... and for that you need a huge team of experts
<FromGitter>
<asterite> I'm not saying it's impossible, but it's super hard, and it will take a lot of time, I think
<RX14>
yes, and we're trying to move the language into a position where crystal deserves a huge team of experts
<RX14>
of course it's hard
<FromGitter>
<asterite> That's a good point
<RX14>
but a long time is maybe 5 years not forever
<FromGitter>
<Grabli66> You are right. We are doomed :)
<RX14>
also saying that paralellism will never be as fast as a single core is just wrong
<RX14>
maybe of you compare HTTP benchmarks with SO_REUSEPORT
<RX14>
but not everything is HTTP
<RX14>
look at @bararchy doing ML in crystal
<RX14>
he doesn't care about IO performance on multiple cores he just wants shared memory and lots of compute
<FromGitter>
<asterite> Oh, I said the stack but I wanted to mean the registers. I think the stack starts smaller in Go, not sure if it can grow.
<RX14>
in go they have segmented stacks
<FromGitter>
<asterite> Right
<RX14>
we could implement that in crystal with some effort if it becomes neccesary
<RX14>
for now just malloc and using virtual address space is fine
<FromGitter>
<asterite> And to be honest, I'm currently programming in C# and, man, it's so verbose and there are so many XMLs and strange formats (.csproj, .sln)
<FromGitter>
<asterite> I miss programming in a language like Ruby or Crystal now... :-P
<FromGitter>
<asterite> I mean, it's a really nice, well thought, language... but it ends up being so verbose
<RX14>
@asterite also: i agree with you that crystal isn't about having the best performance, it's about having the nice syntax and blocks and expressiveness. But crystal is already competitively fast *with* those expressive features.
<RX14>
so we can at least not regress crystal too much
<FromGitter>
<S-YOU> btw, HTTP benchmarks with SO_REUSEPORT, crystal can do same level as C, right?
<FromGitter>
<asterite> I know. That's why I think you shouldn't worry about being even more performant :-)
<RX14>
I don't worry
<RX14>
because I know crystal has the right foundations
<RX14>
and the rest can be fixed up after 1.0
<FromGitter>
<bararchy> 👏
<FromGitter>
<asterite> I guess that's true. It just needs time
<RX14>
benchmarks are marketing
<FromGitter>
<asterite> BTW, it was nice seeing your face after so much time :-)
<RX14>
which is why other people worry
<RX14>
but i'm not too worried about marketing
<FromGitter>
<asterite> I was going to join at some point, but I had a meeting at work...
<FromGitter>
<bararchy> RX14, yeha, SHAInet wuold really love getting non-blocking Fibers on heavy math
<FromGitter>
<S-YOU> To get top5 or 10 in TFB is not difficult, do as what h2o do, it will be the same, but not for real world use case.
<RX14>
we should merge a working Thread.new which just does blocking IO in threads
<FromGitter>
<asterite> For heavy math you can probably fire up a thread and do that there, as long as you don't use IO or (I think) allocate memory... but of course it's super unsafe
<RX14>
then merge nonblocking IO in all threads which aren't the main one later
<RX14>
@asterite yeah, it's the allocating memory bit that needs to be fixed
<RX14>
@S-YOU it would be difficult - perhaps I should try and see how ysbaddaden's new GC does on the tfb benchmarks though :P
<RX14>
probably wouldn't submit the result but it'd be fun to compare the two
<FromGitter>
<fuegito> > *<RX14>* but i'm not too worried about marketing
<FromGitter>
<bararchy> From our internal testing @ysbaddaden GC is on par performance wise
<FromGitter>
<bararchy> a little faster in allocations
<FromGitter>
<S-YOU> That's true for Thread. I do multiple pthreads with crystal already, packet modifier. It is ok as long as it does not hit GC, and Fiber.
<FromGitter>
<fuegito> If you mean (only) benchmarks with marketing i would agree. But it goes further. Marketing for Crystal means also defining "attraction/selling points" for furture developers. More developers will lead to more contributors. More contributors will (propably) help to catch up to go. And marketing for a computer-language means also selling it to managers/deciders of companies.
<FromGitter>
<S-YOU> Thats awesome that his gc is faster in allocation, i know bohem gc is faster than C malloc. I should try that.
<FromGitter>
<asterite> Crystal really needs a precise GC
<FromGitter>
<asterite> I don't think ysbaddaden GC's is precise
<FromGitter>
<S-YOU> Go's GC is the best?
<RX14>
@asterite I don't think it really needs a precice gc
duane has joined #crystal-lang
<RX14>
i think it will get one in the future and it'll help a lot
<RX14>
but as you said, performance doesn't really matter
<RX14>
so it doesn't really need one
<RX14>
and GC isn't going to double crystal's speed or anything
<FromGitter>
<S-YOU> Right
<RX14>
the performance i and you are worried about is that of the crystal compiler
<FromGitter>
<asterite> There was one Google Groups thread about PyPy being faster than Crystal, and there the GC was the bottleneck... but yeah, performance will still be acceptable without a precise GC
<RX14>
LLVM has some really good infrastructure for the codegen part of GC
<RX14>
my opinion is that getting crystal used by a company large enough that they can spare a GC expert to work on crystal is going to be much easier than any of the core team trying to make a GC by itself
<RX14>
well, at least a super high performance GC
<RX14>
a precice-ish GC with stop-the-world is somewhat easy
<FromGitter>
<S-YOU> Hopefully
<RX14>
once you get to write barriers...
<RX14>
then it gets hairy
<RX14>
maybe crystal just needs to get big enough that some academics realise crystal is low hanging fruit to get some performance papers about their pet GC out :P
<FromGitter>
<S-YOU> btw, it is okay to submit plaintext only library to tfb? I like to confirm binding is as fast as h2o.
<FromGitter>
<fuegito> But there is some way to go to get a large company using crystal and to openly advertise it. I use it in a big company but I'm just one guy in a niche. If there would be a USP for crystal like "... best and fastest for microservices.." things like no multithreading/processing wouldn't seem so important (in terms of having a good excuse for not really *needing* it). For me these features are at low priority. But
<FromGitter>
... I maybe alone....
<FromGitter>
<codenoid> can we make crystal GC optional (*C/wGC)
<RX14>
no
<FromGitter>
<S-YOU> you can use -Dgc_none
<RX14>
theres a difference between being able to turn off the GC and being GC otional
<FromGitter>
<S-YOU> okay, you are right :)
<RX14>
you can turn off the GC in crystal - it just means that you'll leak memory forever
<RX14>
GC optional means you can use manual memory management in crystal
<RX14>
and no, you can't
<FromGitter>
<S-YOU> unless you dont let crystal malloc :)
<FromGitter>
<S-YOU> It is possible with application or libarary with mempool support.
<RX14>
making the crystal stdlib not malloc will never happen#
<RX14>
crystal is the wrong language for this
<FromGitter>
<S-YOU> of course
<livcd>
well crystal is not ruby but is crystal different from Ruby enough to deserve its own space ?
<FromGitter>
<sdogruyol> great to see so many people having a good time here 👍
<RX14>
talking about "what ifs" is dangerous because people too often believe them
<livcd>
looks like Graal will be usable before Crystal attracts the critical mass of people
<FromGitter>
<fuegito> I use it as an (not 100%) replacement for ruby. 1. Single binary 2. Fibers
<RX14>
graal solves ruby performance
<RX14>
crystal isn't about performance
<RX14>
it's about static typing
<FromGitter>
<fuegito> If you come from ruby, performance of crystal matters. But it wasn't the reason I chose crystal over ruby.
<FromGitter>
<S-YOU> For me, it is performance though.
<livcd>
graal will solve the single binary and performance. Is not Ruby team planning to do something about the static typing ?
<FromGitter>
<fuegito> At least not the most important
<FromGitter>
<fuegito> You hear and read something about it every once in a while
<livcd>
and at that point...what does Crystal offer that is not already here ? (sorry dont want to be overly pessimistic)
<RX14>
ruby cannot solve the static typing problem
<FromGitter>
<fuegito> Slick as ruby, (almost) fast as C 😁
<RX14>
crystal has solved the problem and look at how different crystal is to ruby
<RX14>
ruby will add some concessions to static typing
<RX14>
and it'll help some of the time
<FromGitter>
<S-YOU> type based method overloading awesome feature
<RX14>
but ruby will never have true static typing
<RX14>
you can't change the nature of a language afer it's written
<livcd>
What I like about Nim for example that it is already ready (almost). That I can develop and substitute an already existing sysadmin scripts and deploy it to eg. Solaris box
<FromGitter>
<fuegito> Well there are gems for something like type enforcement. But this is not the same as static typing
<RX14>
nim has been ready for years :P
<FromGitter>
<fuegito> I hope crystal will not end in something being "ready for years"...
<FromGitter>
<S-YOU> I started crystal, nim, elixir since start of this year. I am still doing crystal, and reading elixir sometime :)
<livcd>
With Crystal I would really have to look with a mgnifying glass to find an area where I would actually use it
<RX14>
livcd, then you are not the target audience
<RX14>
because there are so many people who do want to use it
<livcd>
RX14: yeah but i dont get to use Ruby either
<livcd>
because it simply lost the momentum and marketshare in this area
<FromGitter>
<fuegito> Using it for microservices is a no-brainer imho
<livcd>
There are only so many Ruby shops that I can work for
<livcd>
which kinda makes me sad
<livcd>
I think not open sourcing and not trying to make RubyMotion popular was a very big mistake
<FromGitter>
<asterite> I think crystal is a good fit for microservices, because you don't have a lot of code in each service (so you don't wait a lot to compile). But then crystal really needs to run multiple threads... or not, I don't know, I think node doesn't run on multiple threads (not sure who uses node for server)
<FromGitter>
<fuegito> The biggest asset of ruby was rails. Now I think it is its biggest problem. If you Google around there is almost no ruby but ruby/rails..
<livcd>
there's lots of chef/puppet
ua_ has joined #crystal-lang
<FromGitter>
<fuegito> For my use cases multiple threads are not important
ua has quit [Ping timeout: 276 seconds]
<FromGitter>
<fuegito> Non blocking io / fibers are the killer..
<FromGitter>
<fuegito> And the syntax of course
<livcd>
I want to write Ruby/Crystal today but it's kinda hard to do so :X
<FromGitter>
<S-YOU> Btw, I am reading Initial Commit, that is awesome @asterite :)
<FromGitter>
<fuegito> In terms of being able to or being paid for?
<FromGitter>
<asterite> :-P
<FromGitter>
<S-YOU> Feels like I understood the compiler.
<FromGitter>
<codenoid> it's hard to write code with Crystal, bcoz i have no motivation, and i just wanna go sleep
<livcd>
fuegito: being paid to
<FromGitter>
<ArtLinkov> Hey all, we finished working on the cool new evolutionary optimizer for SHAInet! :D It doesn't use any back-propagation and is very promising. If you want more info on the method check this paper: https://blog.openai.com/evolution-strategies/
<FromGitter>
<asterite> YOU: to be honest, most of the code in that initial commit already came from another project/language: https://github.com/asterite/crystal
<FromGitter>
<S-YOU> I knew that repo, havn't look detail yet. but to understand current compiler, this is the only way I guess.
<FromGitter>
<codenoid> i'm unproductive
<FromGitter>
<codenoid> and i hate it
<livcd>
i might as well just dedicate my life to JavaScript/Java/C#
<FromGitter>
<S-YOU> Ah, didn't know asterite/crystal has codegen part, thanks
<FromGitter>
<fuegito> @livcd there's perl6, too 😜 (which is great I think)
<RX14>
I can only ever imagine crystal being as popular as ruby
<RX14>
any more would astound me
<RX14>
but thats not a bad thing
<RX14>
@ArtLinkov looks cool, wish I knew more about ML :P
<FromGitter>
<S-YOU> Ruby is just per country-wised in japan. that is main reason, I guess. outside japan, python is more popular in my understanding.
<RX14>
yeah
<FromGitter>
<ArtLinkov> RX14 never too late to (M)Learn ;)
<RX14>
yeah, it's just about time and motivation...
zignoob_ has joined #crystal-lang
<FromGitter>
<fuegito> Has someone already mentioned that the android client for gitter sucks?
<FromGitter>
<S-YOU> @faustinoaq one question about TFB, it is okay to submit partial library, like only plain text support? give me your opinion when saw my msg.
<RX14>
it's possible
<RX14>
crystal used to only be plaintext and json
<FromGitter>
<S-YOU> thanks, hopefully crystal binding is as par with h2o.
<RX14>
@S-YOU is it integrated with libevent properly?
<FromGitter>
<S-YOU> Ah, no. It is same as h2o, only with own eventloop or libuv.
<FromGitter>
<S-YOU> Thats why I said earlier it is not for real world use case.
<FromGitter>
<S-YOU> Hold on, if it is possible with libuv, it should be possible with libevent.
zignoob_ has quit [Quit: Lost terminal]
<RX14>
hmm
<RX14>
not sure
<RX14>
maybe if crystal was using libuv
<FromGitter>
<bendietze_twitter> What a nice discus 😄 👍 just away for a hour, huhh :) I think, Crystal is on a very good way, comparing to Go. If we getting near in concurrency and some other things (db etc) its a very good foundation to overtake Go on market :) Why? Because of syntax and concept that Google is hardly following. There are very great developers who are already leaving Go because of problems in errorhandling and
<FromGitter>
... other things. Please let us exactly go this way you are already gone, it would become a very good time for us :)
faustinoaq has quit [Quit: IRC client terminated!]
<FromGitter>
<S-YOU> I think h2o own eventloop is more closer to libevent
<RX14>
perhaps it would be possible to patch h2o to optionally use libevent
<FromGitter>
<S-YOU> it has h2o_socket_read_start, which is like event_set ⏎ h2o_evloop_run which is like event_base_loop, no?
<RX14>
but i dont think it would be possible right now
<RX14>
yeah
<RX14>
but you'd still have to patch it out to change the usages
<RX14>
even if it was an easy patch
<FromGitter>
<S-YOU> might be, let me try h2o alone and see the result, we can also see some stats of daily build of TFB?
<FromGitter>
<S-YOU> in my local machine, performance is par with source code of h2o on tfb repo on plain text
<FromGitter>
<S-YOU> with multiple process with reuse port
<FromGitter>
<S-YOU> thansk
That_Guy_Anon has joined #crystal-lang
akaiiro has joined #crystal-lang
That_Guy_Anon has quit [Ping timeout: 276 seconds]
alex`` has quit [Quit: WeeChat 2.1]
alex`` has joined #crystal-lang
faustinoaq has joined #crystal-lang
wontruefree has joined #crystal-lang
<FromGitter>
<hmans> <3 <3 <3
<FromGitter>
<rumenzu> I just read the previous discussion. Crystal is very competitive for CPU-bound applications. Just avoid intermediate allocations and Hash lookups, and you can beat C++ 👍
<FromGitter>
<rumenzu> But I agree, to me Crystal is about beautiful syntax and static typing
wontruefree has quit [Quit: bye]
wontruefree has joined #crystal-lang
<FromGitter>
<meraxes_twitter> … and fun. :)
<FromGitter>
<bew> 👌
<FromGitter>
<bendietze_twitter> 👌
<FromGitter>
<sdogruyol> :metal:
<FromGitter>
<bendietze_twitter> 😁
<FromGitter>
<bendietze_twitter> 25 ?
<FromGitter>
<bendietze_twitter> 🙊🙈🙈
<crystal-gh>
[crystal] bcardiff opened pull request #6193: Increase no_output_timeout to 20m for linux builds (master...ci/increase-linux-timeout) https://git.io/vhihR
wontruefree has quit [Quit: bye]
<FromGitter>
<GaryMiller> Any progress happening on a native Windows version of Crystal? I'm using pypy now and got a 17x speedup over regular Python but some benchmarks I've seen seem to suggest I could get another 12x speedup if I ported to Crystal. Is it unrealizstic to expect a working Windows version by the end of 2018? Also will Crystal-rails be the Web Framework for Crystal or are Crystal and Ruby too different (static
<FromGitter>
... typing) for the Framework to work the same way?
<RX14>
I'm working on windows support, shouldn't be too far off
<RX14>
it's not unreasonable to expect it by the end of summer
<RX14>
and crystal doesn't run ruby code
<RX14>
so it can't run rails
<RX14>
stuff like activerecord adds methods to objects based on the database schema so...
GoldenBear has quit [Quit: ZNC 1.6.3+deb1 - http://znc.in]
<RX14>
there are some good frameworks for crystal already though like amber and lucky
GoldenBear has joined #crystal-lang
zachk has joined #crystal-lang
zachk has quit [Changing host]
zachk has joined #crystal-lang
<crystal-gh>
[crystal] bcardiff closed pull request #6193: Increase no_output_timeout to 20m for linux builds (master...ci/increase-linux-timeout) https://git.io/vhihR
<FromGitter>
<ArtLinkov> Is there any library in Crystal with some decent data visualization (similar to matplotlib in python)?
<RX14>
@ArtLinkov probably not unfortunately
<FromGitter>
<ArtLinkov> RX14 ok, thanks
<RX14>
not many people doing data science in crystal
<FromGitter>
<bendietze_twitter> @RX14 🙏 Windows 💃 👍