<FromGitter>
<martinos> @oprypin , I got it working by: ⏎ CC=/usr/bin/gcc crystal run my_server.cr
<FromGitter>
<martinos> Anyone knows what is the best way to handle this case. Should I export CC=/usr/bin/gcc ? What is the recommended way.
<FromGitter>
<krypton97> Make a sh script and run it
<FromGitter>
<martinos> I have completely fixed the issue, I had a export CC in one of my config file, I removed it and the problem disapeared.
<FromGitter>
<martinos> So happy to start coding in crystal. Hope i'll love it and contribute back.
<FromGitter>
<krypton97> Great!
Creatornator has joined #crystal-lang
<FromGitter>
<taylorfinnell> hello! sorry if this is a dumb question, but does it make sense for IO::Sized or the subclass i am dealing with HTTP::FixedContentLength to have a #seek implementation?
jfontan has quit [Ping timeout: 246 seconds]
jfontan has joined #crystal-lang
alex`` has joined #crystal-lang
Creatornator has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
wontruefree has quit [Quit: The Internet needs a break and I need a cookie]
wontruefree has joined #crystal-lang
wontruefree has quit [Client Quit]
Ven has joined #crystal-lang
Ven is now known as Guest43745
<FromGitter>
<zyriuse75> hello everyone
Papierkorb_ has joined #crystal-lang
<FromGitter>
<zyriuse75> @martinos next time put your code in a gist https://gist.github.com/ it will be more readable to read
<Groogy>
Morning!
<Papierkorb_>
Morning
mark_66 has joined #crystal-lang
claudiuinberlin has joined #crystal-lang
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<FromGitter>
<petoem> good morning
claudiuinberlin has joined #crystal-lang
rohitpaulk has joined #crystal-lang
DTZUZO has quit [Ping timeout: 248 seconds]
<crystal-gh>
[crystal] RX14 closed pull request #5095: Use query string from WebSocket URI-based instantiation (master...master) https://git.io/vdVIc
flaviodesousa has joined #crystal-lang
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<FromGitter>
<zyriuse75> i've a problem in my menu i call a method `install_soft` but he dont execute my shell script who is in this method ! but if i execute my methode from icr everything it's okay
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
claudiuinberlin has joined #crystal-lang
<Papierkorb_>
livcd: competitors in which field?
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Papierkorb_>
Go and Rust are both rivals in speed, though both have different target audiences. Though I think there's a fair potentional overlap in audiences of Go and Crystal, though I think Crystal has the usability edge over Go, where Go shines with parallelism and company backing
claudiuinberlin has joined #crystal-lang
Guest53747 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rohitpaulk has quit [Ping timeout: 255 seconds]
<livcd>
Papierkorb_: in general
<Papierkorb_>
livcd: In that case, my answer is: `Yes`
<Papierkorb_>
Maybe
<Papierkorb_>
No
<Papierkorb_>
Kinda
rohitpaulk has joined #crystal-lang
<crystal-gh>
[crystal] iSarCasm opened pull request #5113: Add Math sqrt overloads for Bigs (master...master) https://git.io/vdPZA
gcds has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 248 seconds]
Ven has joined #crystal-lang
Ven is now known as Guest45011
rohitpaulk has joined #crystal-lang
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Papierkorb_ has quit [Remote host closed the connection]
ShalokShalom_ has joined #crystal-lang
Papierkorb_ has joined #crystal-lang
ShalokShalom has quit [Ping timeout: 240 seconds]
Creatornator has joined #crystal-lang
Creatornator has quit [Client Quit]
<FromGitter>
<imonmyown> Hey guys, what do you think about adding an offtop channel extra to this one?
<crystal-gh>
[crystal] MakeNowJust opened pull request #5114: Allow flat rescue/ensure/else block in do/end block (master...feature/crystal/do-end-with-ensure-rescue-else) https://git.io/vdP8F
snsei has joined #crystal-lang
Creatornator has joined #crystal-lang
Creatornator has quit [Client Quit]
<FromGitter>
<imonmyown> Probably not a very good idea, but... whatever
<Groogy>
I don't mind but I am not on Gitter so I would most probably not be part of that channel anyway :P
<RX14>
we could create #crystal-offtopic in IRC i guess
<RX14>
but it would require more discussion
<RX14>
traditionally this chat has moved slow enough to just have offtopic here
<FromGitter>
<imonmyown> Thanks for the feedback, probably we should wait till we have more offtop discussions here. (I personally would prefer the same scheme with gitter and IRC chats and relay bot inbetween)
Creatornator has joined #crystal-lang
<FromGitter>
<straight-shoota> Currently it would just cause separation
<FromGitter>
<straight-shoota> for no real reason
<Papierkorb_>
For #ruby it works fine, but they have (had) >1k people in #ruby, so..
<RX14>
yeah we'll probably want it eventually
<RX14>
but probably not yet
<RX14>
probably
<Papierkorb_>
Heh, I just updated my arch. the text rendering changed .. at least in Konversation
<Papierkorb_>
The bold text looks .. different. not bad, but different
<RX14>
hmm
<RX14>
i havent noticed anything
Creatornator has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<RX14>
and im up to date
<FromGitter>
<sdogruyol> @Papierkorb I've also updated Gnome to 3.26
<FromGitter>
<imonmyown> Seems like time to run updates :)
rohitpaulk has quit [Ping timeout: 248 seconds]
ShalokShalom_ is now known as ShalokShalom
rohitpaulk has joined #crystal-lang
claudiuinberlin has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 240 seconds]
Creatornator has joined #crystal-lang
Creatornator has quit [Client Quit]
Ven has joined #crystal-lang
Ven is now known as Guest83577
Guest45011 has quit [Read error: No route to host]
Ven_ has joined #crystal-lang
Guest83577 has quit [Ping timeout: 248 seconds]
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
snsei_ has joined #crystal-lang
claudiuinberlin has joined #crystal-lang
claudiuinberlin has quit [Client Quit]
snsei has quit [Ping timeout: 258 seconds]
Ven has joined #crystal-lang
Ven is now known as Guest22988
claudiuinberlin has joined #crystal-lang
Ven_ has quit [Ping timeout: 260 seconds]
Papierkorb_ has quit [Quit: Konversation terminated!]
ShalokShalom_ has joined #crystal-lang
ShalokShalom has quit [Ping timeout: 260 seconds]
alex`` has quit [Quit: WeeChat 1.9.1]
snsei_ has quit [Remote host closed the connection]
<FromGitter>
<faustinoaq> Yeah, I think the community should be optimistic, Crystal is a great language
<FromGitter>
<thewalkingtoast> If we need to become more often-than-not typed that's fine. Typing isn't the issue to me. I'd hate for us to adopt a bunch of other syntax changes that make the language less like ruby. Typed Ruby is fine IMHO.
<RX14>
more often than not is fine
<RX14>
forced is not
<RX14>
see: haskell, you can define functions without types but the community guidance is to do so
<RX14>
granted its for a different reason
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
ShalokShalom_ has quit [Ping timeout: 248 seconds]
snsei has joined #crystal-lang
gcds has quit [Ping timeout: 260 seconds]
olbat has joined #crystal-lang
<FromGitter>
<thewalkingtoast> I agree
Creatornator has joined #crystal-lang
<FromGitter>
<jipiboily> Hey folks! It’s been a long time :) I didn’t play with Crystal for a few months now…and thinking about getting back at it shortly. Where is at it with concurrency, or parallelism?
<RX14>
nothing's changed
<FromGitter>
<jipiboily> It looks like it’s not in there yet...
<FromGitter>
<jipiboily> gotcha
<RX14>
unfortunately
<FromGitter>
<jipiboily> and do we know if people are *actually* working on it?
<Papierkorb>
Concurrency has been in for a long time, no one knows how long parallelism is going to take
<RX14>
nobody is
<FromGitter>
<jipiboily> It feels like the language development have slowed down…or is it just me?
<RX14>
it's not just you
<FromGitter>
<jipiboily> ah ok
<FromGitter>
<jipiboily> sad :(
<RX14>
indeed
<Papierkorb>
^ - Even though there was a spike recently when ary was around
<FromGitter>
<jipiboily> oh, so one of the creators thinks the language is a joke…?
<FromGitter>
<jipiboily> I think I misread :)
<Papierkorb>
RX14: Without even knowing the compiler internals, my bet is one could improve speed considerably by changing used algorithms and structures, not the language. Though, and this I know, for me, the speed is fine..
<RX14>
yeah
gcds has joined #crystal-lang
<RX14>
i agree
<RX14>
but
<RX14>
no matter how much we changed it it'd still be O(n^2)
<RX14>
and we'd still have LLVM time
<Papierkorb>
n²? What's the algorithm?
snsei has quit [Remote host closed the connection]
<RX14>
each method typed can type n different methods from the codebase
<FromGitter>
<bew> RX14 from where are the quotes in your message?
<RX14>
ary deleted his comment
<RX14>
which i knew he would do so i quoted it
<Papierkorb>
For a call, isn't it 1) for all arguments, do 2) trace the argument through all calls, until hitting a primitive action 3) or until it hits a cached code type deduction ?
<FromGitter>
<bew> oh ok
<FromGitter>
<asterite> Sorry, that was a bit impulsive from me
<Papierkorb>
RX14: That algorithm is expensive, but where does the square-part come in?
<RX14>
we have n methods which need to be typed can instantiate a fraction of n other methods
<RX14>
which is n * n * 1/k
<RX14>
or O(n^2)
<RX14>
maybe i'm using big-O wrong
<RX14>
but you get the gist
<Papierkorb>
Yes, but if cached, wouldn't that amortize real quick to O(n)?
<FromGitter>
<asterite> My main issue is that I'm not using the language and lately not having any fun participating in all the discussions about something I don't use
<RX14>
Papierkorb, except there's little which can be cached
<FromGitter>
<asterite> So I guess I'll just stop contributing to it
<FromGitter>
<asterite> I just can't take it anymore
<FromGitter>
<asterite> Sorry :-)
<FromGitter>
<asterite> (I meant :( )
<RX14>
@asterite it'd be great if one day you could start using the language again
<RX14>
I can understand it's hard to be invested in something you don't use any more
<FromGitter>
<bew> @asterite why you don't use it now?
Creatornator has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<RX14>
perhaps one day you'll find a side project that you want to do and you can re-remember the parts of crystal which do work @asterite
<RX14>
im sure if you judged any language by the issues you saw on it's issue tracker you'd get a worse perception of it
<FromGitter>
<asterite> Well, I never used it aside from the compiler. Maybe just small scripts, or things like that thing that happens on christmas. Well, I did do one thing in Manas and it worked well, though
<FromGitter>
<crisward> Take a look at VSCode's issue tracker - and I didn't think there was anything wrong with it.
<FromGitter>
<asterite> The problem is that other languages have issues like "This is a bug" or "This std piece has a bug"
<Papierkorb>
The Java Standarization Process looks like a yell contest. Still, java thrives
ShalokShalom has joined #crystal-lang
<RX14>
@asterite I think that's why you dislike it so much. We've all been using it in small projects, where crystal absolutely shines.
<FromGitter>
<asterite> But in Crystal there's not even a formal definition of the language that we can settle on and move forward with other things
<FromGitter>
<asterite> Take for example Go or Ruby
<RX14>
Is there a formal specification of ruby?
<FromGitter>
<asterite> Or Elixir
<RX14>
and that's pretty darn successful
<Papierkorb>
Ruby had one for 1.8
<FromGitter>
<asterite> Those languages are finished, now it's just about polishing things
<RX14>
is it a "real" spec or justa hopeless definition of what the implementation does Papierkorb
<RX14>
@asterite they weren't always like that
<Papierkorb>
RX14: Well Ruby 1.8 has an ISO standard :)
<RX14>
doesn't mean its not shit
<FromGitter>
<bew> ^^
<Papierkorb>
Rust was so fast paced, it broke everything almost on every release.
<RX14>
if it wasn't worthless then maybe it'd have been updated past 1.8
<Papierkorb>
And yet, people love Rust. Not for that it constantly broke. But what they saw in it it could be
<Papierkorb>
And Rust grew by that
<RX14>
i'm honestly more worried about what's happening at manas than scaling the compiler
<Papierkorb>
I know that I switched to Crystal because it solved my main pain points of ruby at first, but it offers so much more than that. So .. erm .. thanks for Crystal.
<Papierkorb>
^
<RX14>
from the outside position like me, it appears as if they're taking bountysource money and nothing much is really happening with it
<RX14>
I doubt that that's the case in reality
<livcd>
well i use Go because it's kinda polished on all platforms
<RX14>
but it's all about perception by the community
<FromGitter>
<asterite> RX14: I wouldn't worry about that at all. They are just having lots of other projects that have clients right now, so that needs attention first. But once that passes I'm sure they will continue working on that. And that money will then be spent.
<RX14>
I'd much rather have a steady x hours a week than the money banked and spent dynamically
<RX14>
it's really not OK
<livcd>
well i guess that really happens to the majory of "please back me projects" :D
<Papierkorb>
Yeah visible progress is important. To the outsider, even progress for the sake of progress.
<RX14>
^
<RX14>
the manas team doesn't exist in a vaccum
<RX14>
progress by them inspires progress by the community
<livcd>
btw rust does not really have an alternative does it
<livcd>
no wonder it grows
<Papierkorb>
livcd: C? C++? D?
<RX14>
the core team has an amplifying effect on the community's progress as a whole
<RX14>
and given that it makes way more sense to work continuously
<Papierkorb>
livcd: Depends on what you're doing of course
<livcd>
Papierkorb: but Rust is THE alternative for those languages (i would not really add D here btw)
<RX14>
it's not as bad as it was in the early summer (winter at manas) but it's somewhat concerning
<livcd>
Papierkorb: while there is the alternative forrust
<FromGitter>
<asterite> Well, there are comments, issues replies and PRs merged and reviewed. That takes time. And parallelism is pretty much invisible and a huge/hard task. And so does solving the main issues of the language as a whole (the type system, for instance). I'd rather have that solved than continue fixing issues or doing minor stuff.
<livcd>
^
<FromGitter>
<asterite> Maybe it does make sense to think of Crystal as something only useful for small/medium projects, with a type system that's half-way defined?
<RX14>
I agree @asterite but it doesn't appear as if they are getting solved either
<Papierkorb>
To be honest, I'd be much more fine if I knew what the current progress on e.g. Parallelism is. Every two weeks, even if only a few sentences what's being done, or tried.
<FromGitter>
<asterite> I mean, it works for the programs that use the happy path
<RX14>
Papierkorb, exactly
<RX14>
it's all about perceptions
<RX14>
i've had people come to me and say they dont want to donate to the bountysource because they have no idea how the money is used
<RX14>
thats a problem that needs to be solved
<Papierkorb>
Even if some weeks it's a "oh yeah that idea was terrible after all, redone parts of it" - Almost like how programming works
<RX14>
to them and to some extent me the money appears to be going into a black whole which it isn't
<RX14>
hole*
<RX14>
@asterite I don't think it's really worth formalizing the type system
<RX14>
it's pretty much at the bottom of the to-do list
<FromGitter>
<kazzkiq> Why not do a blog post every 15 days? It could be just a "changelog" with things being worked on. And the community (mainly those who are helping fix stuff and know what is happening) could help write it.
<Papierkorb>
^
<RX14>
^
Creatornator has joined #crystal-lang
<Papierkorb>
*cough* sdogruyol
<FromGitter>
<kazzkiq> I feel the blog has too few posts. It could be more useful in this regard.
<RX14>
anything they can point to to get more donations
<FromGitter>
<sdogruyol> @Papierkorb got you
<livcd>
oh doh i thought asterite was key person behind crystal :-O and now he is saying he had enough
<FromGitter>
<asterite> RX14: on the contrary, I think having the spec for the language, as in "this works like this" is the most important thing. Also thinking about all the corner cases, and thinking about an efficient implementation to solve that. Once that's done you can focus on a small and solid std, and the ecosystem can grow. Look at Go, since 1.0 the language didn't change, but the ecosystem and the runtime grew a lot. But I
<FromGitter>
... understand it's a bit difficult when the language (Crystal) came to exist as a result of an experiment :-)
<livcd>
i agree 100000%
<RX14>
@asterite sure, if we had infinite runway
<FromGitter>
<asterite> That's another issue, too
<RX14>
but we don't and i'd like to take off sometime
<RX14>
for all of our sanity
<FromGitter>
<asterite> The good thing is that you and many others are having fun and using the language :)
<FromGitter>
<asterite> (and me too, from time to time)
<FromGitter>
<sdogruyol> @asterite why don't you use too and have fun together :P
<Papierkorb>
The issue is not having a spec (setting aside the discussion if it's worthwhile). It's treating having a spec as one big block, opaque task. Write it alongside, add something to it if it's missing something. And change it.
<livcd>
There are only two kinds of languages: the ones people complain about and the ones nobody uses
<RX14>
@asterite I think at a certain point we have to be pragmatic and say "we'll fix this as issues arise"
<Papierkorb>
Trying to write a huge spec and then implement would work for a corporate with pretty much infinite time and money. Waterfall ahoy.
<RX14>
to me it's "too late" to go the language spec ruote
<FromGitter>
<thewalkingtoast> Is crystal not used within Manas anymore?
<RX14>
plus a language spec does to some extent limit your flexibility
<FromGitter>
<sdogruyol> agree
<FromGitter>
<asterite> thewalkingghost: it's used
<FromGitter>
<thewalkingtoast> Unless they never used it for actual client work, which is totally understandable
<Papierkorb>
RX14: it's fine to amend it later on, even if only for major releases, but that's enforced by semver already anyway. See C/C++.
<RX14>
perhaps for crystal 2 we can write a spec from the grouns up and write (multiple) compilers from the ground up
<RX14>
but I think we should attempt 1.0 by solving the problems as they arise
<RX14>
simply because we cannot afford to throw away all the 60k lines of code we do have
<FromGitter>
<bew> 👍
<Papierkorb>
I also doubt that many devs would go like "no spec? no me"
<Papierkorb>
A spec also doesn't ensure compiler correctness, not even language correctness
<RX14>
if you look at all the people contributing to rust
<FromGitter>
<asterite> Well, it's so good that you all think that way :-)
<RX14>
thet's a key asset that we don't have
<RX14>
so we'll have to do the best we can with what we have
<FromGitter>
<asterite> Many (or all) at Manas think that way too. I'm probably too biased because of the issues and knowledge about how the compiler works or is implemented
<FromGitter>
<sdogruyol> before having a language spec we need some kind of development flow / spec which is transparent and more visible to the community
<livcd>
well the majority of people are looking for Go with Ruby's syntax + some extras
<livcd>
and that's it
<RX14>
until we have a community that's lucky enough to get large contributions from loads of very smart people
<FromGitter>
<asterite> And are you OK with a concurrency model like Go, where if you share a variable between fibers you can get random crashes?
<RX14>
OK isn't binary
<RX14>
it's on a spectrum
<FromGitter>
<asterite> I mean, examples that exist now like `SOCKETS = []` and adding to that in a websocket handler will still compile, but probably randomly crash
<RX14>
it's very much improvable
<Papierkorb>
I'm sure that they'll add a thread sanitizer as time comes. Heck, clang did so many years after C/C++'s inception
<RX14>
if we trade off having fearless concurrency and having to redesignin the language with keeping the status quo i'd go with the status quo every time
<FromGitter>
<asterite> Go has a race detector
<RX14>
there's always the java model
<FromGitter>
<asterite> but it's quite a challenge to implement that
<RX14>
which is just raise
<RX14>
is that what you mean by a race detector?
<FromGitter>
<asterite> I think Go's race detector just adds checks at runtime so you get a message (at runtime) when a variable or something was shared between fibers
<RX14>
it "works"
<RX14>
it works for google
<RX14>
we don't have to innovate on every level
<Papierkorb>
What's not now can be improved as time comes, and it will
<RX14>
we should pick our battles
<RX14>
and concurrency shouldn't be one I think
<RX14>
well
<RX14>
memory safety part of concurrency
<RX14>
CSP makes it easy enough to do concurrency without locking
<RX14>
CSP makes it easy to *not* use shared memory
<RX14>
which isnt nearly perfect but it's not locks and threads
<RX14>
at least
<FromGitter>
<asterite> It's true. I guess in Java you have the same problems. And in JRuby probably too. In Elixir and Rust that problem doesn't exist but comes with other tradeoffs
<RX14>
@asterite the more obvious comparison is Go
<livcd>
I would love to see Crystal gaining momentum before it's too late :)
<RX14>
which succedded in an era where rust and elixir where there with "perfect solutions"
<RX14>
it shows that the "traditional" shared memory approach works
<FromGitter>
<asterite> Well, you've convinced me, Crystal is great :-P I'll just try to spend time on the fun parts of it
<FromGitter>
<fridgerator> 🎉
<livcd>
yay!
<Papierkorb>
What good is a perfect solution if it's too hard to use? Rust is fantastic and amazing. But it's also much harder to write code in than in other imperative/object-oriented languages.
<livcd>
this 10000%
<FromGitter>
<bew> ✨ 🎉 ;)
<FromGitter>
<fridgerator> group hug
<RX14>
@asterite, actually perhaps the biggest problem is that the compiler isn't fun...
<FromGitter>
<bew> (anymore?)
<RX14>
which gets us back into the fixing the big-O of the compiler debacle
<FromGitter>
<asterite> Yes, many times I try to tackle compiler issues but fail
<FromGitter>
<asterite> and that's a bit frustrating
<FromGitter>
<asterite> so I guess I won't fix compiler bugs anymore, unless they are trivial
<RX14>
any help is of course better than none
<FromGitter>
<bew> @asterite or unless you're having fun doing it? ;)
<RX14>
@asterite I think the key is moderation
<RX14>
spend at most 1/3 of your "crystal time" on the compiler or something like that
<livcd>
Papierkorb: well statistically speaking people will not pick Rust for projects which are traditionally better server by go,java,c# and alike
<RX14>
hacking on the compiler is much more bearable when it's to fix something for a project you do enjoy
<Papierkorb>
Well the Java/C# crowd is huge and has large parts in writing serious-business software. I don't think Crystal nor Go, Rust or Ruby is for those. Which is fine, thank god we have different languages to choose from
<Papierkorb>
livcd:
<livcd>
Papierkorb: well i think Go is getting there
<Papierkorb>
Which would be .. interesting considering Go isn't meant for that. But oh well, what do I know, I also don't get why many web devs jumped to Go
<RX14>
i can understand go for REST
<RX14>
like backend
<RX14>
i can understand it
<RX14>
but for the frontend god no
<livcd>
what do you mean by frontend ?
<livcd>
gopherjs ?
<RX14>
see thats the problem with web dev these days
<RX14>
nobody knows
wontruefree has joined #crystal-lang
<livcd>
well in any way these are just tools to solve the same ol same ol problems
lacour has joined #crystal-lang
<FromGitter>
<crisward> Crystal needs to be at a point where a 'well known' project uses it. I think github / gitlab could really benefit if their ruby devs could migrate to a familiar compiled language, but they'd never even consider it pre v1.
<Papierkorb>
No one would rewrite all of their main projects in Crystal right away. At least I wouldn't recommend it.
<Papierkorb>
But if they'd openly use it for small services for a singular feature as trial run, that'd be amazing of course
<FromGitter>
<crisward> With all this micro service stuff going on, I don't think they'd need to rewrite their project.
<livcd>
i think crystal can eat only Go's/Ruby's/python's piece of cake at first + some niche areas
<RX14>
@asterite I honestly think that you need to sit down and write something basic and simple in crystal, perhaps a side project. Working on the compiler all the time you can forget what issues actually affect people working in crystal on a daily basis.
<FromGitter>
<crisward> We run gitlab locally and it eats memory and runs slow.
Creatornator has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<livcd>
crisward: we run graylog and it's also slow and eats memory. But we have no money to get splunk for everyone :))
<FromGitter>
<paulcsmith> I'd love to see Crystal continue moving forward, but sometimes you need a break. @asterite you've done a ton of work, and I love the Crystal language. So thank you for all you've done!
<FromGitter>
<asterite> RX14: Yeah. Maybe I should write a game using crsfml. But I don't have ideas :-P
<livcd>
or well...we do...the company is just a bunch of scrooges
<Papierkorb>
livcd: That's every company ever
<livcd>
Papierkorb: nah it's more like they are not very efficient when it comes to spending
<livcd>
but hey atleast i get to fly business
<livcd>
:3
<RX14>
@asterite i'm sure someone creative like you will find an interesting idea in a week or two haha
<FromGitter>
<paulcsmith> BTW, not sure this is the best place to put it, but I've been working on a new web framework in Crystal. Things are moving forward slowly but surely, but if you're interested you can sign up for updates here: http://luckyframework.org or check out the code at the GitHub link
<FromGitter>
<paulcsmith> Working on fleshing out the guides right now
<FromGitter>
<asterite> Maybe a puzzle game where rooms are chests and chests are rooms? No, wait...
<livcd>
asterite: it should be something you would like to play :P
<livcd>
and realistic
<livcd>
:D
<Papierkorb>
A sudoku with a solve button to make you feel good
<FromGitter>
<crisward> I used to like a game on the Amstrad master system (1981, showing my age), It involved tanks, the bullets would bounce of the walls, realistic I know! I quite like the idea of an infinite scrolling map online, with users controlling their own tanks via web sockets. It'd be cool.
<livcd>
but playing games is so 2006
<livcd>
in 2017 i watch other people playing games
<Papierkorb>
2014 called, they want their way of life back
<livcd>
asterite what about doing twitch and working on crystal on it ? :P and interact with people
<FromGitter>
<asterite> cirsward: I had one of those! I think it had E.T.
<FromGitter>
<sdogruyol> @asterite you shall teach others the secrets of the compiler, for fun and profit :D
<Papierkorb>
that's gaming history man
<RX14>
^
<livcd>
asterite: well i just finished watching Dominik Picheta's twitch video about improving nim bot :X
<FromGitter>
<sdogruyol> Twitch can be a great way of teaching for that
<Papierkorb>
wasn't there a coding centric twitch clone?
<FromGitter>
<sdogruyol> @livcd he also stalks in this channel (from time to time :D)
<livcd>
he is present :O
<FromGitter>
<sdogruyol> @paulcsmith thoughtbot?
<livcd>
Papierkorb: there is
<FromGitter>
<paulcsmith> @sdogruyol Yes I'm working on it for investment days at thoughtbot. Did a workshop at thoughtbot and there was a lot of interest
<FromGitter>
<paulcsmith> Crystal was pretty easy for people to pick up. Some issues with confusing errors inside macros, but was mostly quite well received
<RX14>
do we need a coding=centric twitch clone?
<RX14>
twitch has certain economies of scale
<FromGitter>
<sdogruyol> @paulcsmith that's great to hear
<Papierkorb>
RX14: "No one asked for it, but there it is"
<RX14>
sometimes that works out
<RX14>
sometimes that doesnt
<livcd>
RX14: no but you could say the same about Twitch when we have YouTube
<RX14>
not really
<livcd>
why?
<RX14>
youtube didnt do livestreaming when twitch came out
<Papierkorb>
didn't get YouTube streaming introduced after twitch come around?
<RX14>
or at least it was shite
<RX14>
plus it was justin.tv back then
<FromGitter>
<paulcsmith> We've been investigating a lot of staticly typed languages. Haskell is one, but most find it too hard. Elm is great, but only for the front end. Scala is also pretty interesting, but I like the Crystal syntax and type system a lot. Plus the macros are very easy to use. Much friendlier than in other languages I've used
<Papierkorb>
and twitch was basically a justintv clone in the beginning
<RX14>
nooo
<RX14>
it was justin wasn't it
<RX14>
i thought they just rebranded?
<RX14>
am i wrong?
<RX14>
is my life a lie?
<Papierkorb>
It was a bit turbulent. Whatever it was, it's gone now.
<FromGitter>
<paulcsmith> One of the my main focuses in Lucky is making things as safe as possible. So the query builder is totally type safe. No symbols. You do something like `UserQuery.new.age.gt(30).name.lower.is("paul")`
<RX14>
personally I think strings are the best SQL builders
<livcd>
RX14: well did we really need facebook after myspace ? :P
<RX14>
it just needs a minimalistic bit of sugar to reduce the impedance mismatch
<RX14>
but i never got time to work on that
<Papierkorb>
RX14: Ever used RCTEs?
<RX14>
Papierkorb, no
<Papierkorb>
Yeah, writing those by hand sucks big time
<FromGitter>
<paulcsmith> I like the type safety I can get with this approach. It also makes for really cool ways of saving and validating data with form objects
<Papierkorb>
Good ORMs do it though. Sequels `rcte_tree` plugin is amazing for this, and it can do so much more
<RX14>
yet i'd much rather have raw SQL for the 99% of expressions which are simple
<FromGitter>
<crisward> Agree
<RX14>
postgres is so powerful
<RX14>
ORMs take away that magic
<RX14>
and i hate it
<FromGitter>
<paulcsmith> It's really easy to accidentally pass `nil` or some other value with strings though. I see why people like strings, but that type safety is super important to me
<FromGitter>
<paulcsmith> If a column can't be `nil` I don
<RX14>
i think that can be solved
<Papierkorb>
Yeah one of the points is that ORMs can be type safe, and, you can share "snippets" of queries much more easily. pass them around like objects (..they are objects), refine, and so on.
<FromGitter>
<crisward> ORM's are very good at writing really slow queries. They seem less bad at update/insert
<RX14>
in an ORM you still rely on your object having the same schema as your DB schema
<RX14>
you can still do the same typechecks with raw SQL
<Papierkorb>
That alone enables you to make your code more modular
<Papierkorb>
Sequel exposes just a glimpse of this power through its subset feature
<FromGitter>
<paulcsmith> Yeah it could be done with string queries, but I like defining the column type just once and then not having to worry about.
<FromGitter>
<paulcsmith> Makes it easier in the future if I make something nil able or not nil able. I just change one places and the rest of the code gets the right type automatically
<FromGitter>
<paulcsmith> Also I don't like SQL so I'm biased :)
<RX14>
my problems with ORMs is they rarely ever get basic things like joins right
<Papierkorb>
Though my current project at work made me like SQL much more. Though that interface is really small, and simple, so I interact with the SQLite through manually prepared statements
<RX14>
they say you have to join this table using foreign keys only
<Papierkorb>
That's a shit ORM then
<RX14>
well do we have non-shit ORMs in crystal?
<Papierkorb>
The only non-shit ORM I know in general is Sequel *hides*
<RX14>
i tried sequel once but it was ages ago and i didnt find much documentation
alex`` has quit [Ping timeout: 240 seconds]
<RX14>
i like using postgres-specific stuff like value arrays and json and word search
<RX14>
and sometimes the occational SQL function
<RX14>
and ORMs just do not enjoy that
<FromGitter>
<crisward> Thats the other ORM issue, they often only support features which are supported by all the databases they work with.
<RX14>
Papierkorb, ok yeah sequal is alright, now port it to crystal lol
<RX14>
sequel*
<Papierkorb>
Hey man, I'm binding Qt already
<RX14>
its joke
<FromGitter>
<paulcsmith> Lucky will only support Postgres so that it can do the array and json stuff. Doesn't do it yet, but I hope to do that. No joins yet though :( Focusing on the basics. I plan to make it so that you can use strings for more complex stuff if needed. Or just don't use the ORM haha
<Papierkorb>
As Postgres is the one RDBMS to rule them all, this is fine (lul)
<FromGitter>
<paulcsmith> That's pretty much how I see it lol
<FromGitter>
<paulcsmith> I've never had the need to use anything else
<RX14>
i mean if you're not using postgres perhaps you dont deserve a good ORM lol
<Papierkorb>
Oh I'm thankful for SQLite. But PSQL and SQLite have completely different use-cases, so...
<RX14>
oh yeah sqlite is alright
<Papierkorb>
As long fewer people use MySQL and move to PSQL, it's a worthy cause :P
<FromGitter>
<DRVTiny> Hello2All!
<RX14>
and perhaps cocroachdb will be alright in a few years
<RX14>
but i dont see much else good in the DB world
<FromGitter>
<DRVTiny> Anybody knows, how to wait for all fibers? fibCount+=1 and send message to some channelFin, and than channelFin.receive fibCount times?
<RX14>
yep
<RX14>
pretty much
<FromGitter>
<DRVTiny> fibCount+=1 before spawn, send to channelFin inside fiber
Creatornator has joined #crystal-lang
<Papierkorb>
DRVTiny, have a "waiter" channel. Every fiber sends something into it. Then to wait, simply `count_of_fibers.times{ ch.receive }`
<RX14>
youd typically want to know fibCount beforehand though
<RX14>
@asterite thats a good abstraction but for short-lived tasks done in parallel i cant help but think the promise pattern would fit better
<RX14>
that way you can wait for all, n, one and get all, n or 1 results
<RX14>
it handles sync and result passing as one
<FromGitter>
<DRVTiny> If i will do fibCount+=1 in the "main" fiber before spawn and after that i will collect fibCount.times{ finChan.receive } - it will be enough to wait all fibers (?)
<FromGitter>
<DRVTiny> > **<RX14>** not use += 1 ⏎ Why?
<RX14>
If you can calculate n beforehand its cleaner
<RX14>
If you can't then you have to use +=
<FromGitter>
<asterite> `+=` will break with parallelism
<FromGitter>
<DRVTiny> Understand... Thank you. But for now parallelism is not on the agenda for Crystal
<RX14>
@asterite not if its a local variable??
<RX14>
the idea presumably is loop { i += 1; spawn foo } n.times { recieve} right @DRVTiny ?
<FromGitter>
<imonmyown> Guys, was out for a while and went back to a lovely discussion thread, enjoyed reading it a lot. Thank you all :)
<FromGitter>
<asterite> Ah, OK. I though `i` was incremented inside spawn
tax has quit [Quit: Leaving]
<FromGitter>
<imonmyown> Wish to see more of this kind of discussions here and more regularly. @asterite really glad you changed your original decision.
<FromGitter>
<asterite> I'm glad I expressed my concerns because the feedback was extremely positive, so thank you all :)
<FromGitter>
<bew> 2nd group hug :P
<FromGitter>
<sdogruyol> hey @asterite, we all love what you've done with Crystal, thanks a lot 🙏
<FromGitter>
<sdogruyol> wish we could help you more 👍
olbat has quit [Ping timeout: 240 seconds]
<vegai>
huh, what's with all the melting down suddenly
<vegai>
something's been brewing for a longer time, I guess?
<oprypin>
yeah crystal has been brewing for over 5 years
<livcd>
well making a language successful is a lifetime job and even then you cant make everyone including yourself happy
<FromGitter>
... offered so far. You can start reading from secion 3, to get to the core of the solution skipping the introductory discussion of issues it aims at.
<vegai>
by the way, latest Bikeshed episode talked about Crystal for some time
<vegai>
@asterite you asked "What's the point of creating a language with an artificial limit imposed on it?" to my comment where I said >1M LOC projects are not important
<vegai>
well, I guess no point if those limits can be easily overcome
<FromGitter>
<asterite> I meant that the compiler won't be able to deal with 1M LOC, either because of the time it takes to compile that or because you'll run out of RAM/swap
<vegai>
but... and I'm saying this as only a dabbler, not designer of programming languages... isn't artificial limits quite the fundamental thing of programming language design?
<oprypin>
vegai, tell that to the c++ guy
<oprypin>
no sacrifices
<FromGitter>
<asterite> Yes, limits to prevent mistakes
<vegai>
but also when you make some PL design decision, you close a lot of doors
<vegai>
in practical terms at least
<vegai>
like the Java designer made lots of decisions, and the combination ended up limiting a lot of things
<vegai>
designers*
<vegai>
accidental limits, perhaps
<vegai>
I'm sure the Java guys never meant that Java desktop applications would be horrible
<FromGitter>
<asterite> What limits? You can pretty much do anything with Java, and soon (or now?) you'll be able to compile it to native code
<vegai>
well, ever since GCJ that has been possible
<vegai>
but due to many reasons, almost nobody does that
<livcd>
well Go arguably made some self-imposed limits but at the end it does not matter and it did not turn out to be yet another sinkhole for features language like C#
<vegai>
I just mean that no language is good for everything
<vegai>
I'm not sure I see the point that all languages need to try to be good at everything
<vegai>
case in point: Rust has a brilliant concurrency story, which imposes a heavy cognitive load on the programmer in the form of lifetimes and ownership
<oprypin>
livcd, *yet*
<vegai>
however only a tiny percentage of practical problems require the sort of performance that allows
<crystal-gh>
[crystal] reindeer-cafe opened pull request #5115: Updated Random::ISAAC to use ISAAC+ (master...isaac-plus) https://git.io/vdXtu
<vegai>
so is it worth it? Is it worth for others to try to be as good in that area?
<vegai>
there are of course some things which are pretty much win win... at least it seems to me
<vegai>
I cannot abide languages that don't provide protection from null pointers anymore, after seeing it being solved so easily several times
<FromGitter>
<imonmyown> @vegai C++ is a straightjacket to me, Rust is like a coloured straightjacket, but a straightjacket nonetheless.
<livcd>
well for 99% people on the planet javascript is good enough to be the one and true language :)
<vegai>
sure... but in some areas you just to be surfing on the limit of what is possible performance-wise
<vegai>
heavily graphical computer games, for instance
<livcd>
hey i thought unity supports smh like js :)
<livcd>
but yeah i get your point
<FromGitter>
<imonmyown> @vegai that is mostly kernel tasks in my point of view. As far as games and their sophistication are concerned I'd say this: as the screen resolutions go up the quality of content proportionately goes down
alex`` has joined #crystal-lang
<livcd>
imonmyown: well i think the costs of making a quality content have also increased like the resolutions :P
<vegai>
I bet there are some good and pretty games too
<vegai>
cannot think of any right now, though :P
<vegai>
System Shock 1 was pretty when it came out :P
<livcd>
Cuphead is pretty :)
<livcd>
and the OST
<livcd>
ahh
<FromGitter>
<imonmyown> I like Ori and the blind forest :)
<FromGitter>
<imonmyown> Ok guys a matter of discussion, I admit that :)
<oprypin>
wait what
<vegai>
and I suppose nobody writes games in Java anymore
<vegai>
even Minecraft was rewritten in C++ after Microsoft acquired it
<vegai>
(is that just a rumour, I'm not sure)
<livcd>
well it's like with movies...remember the time when an xmen themed movie was "WOW". Nowdays every second one pictures a marvel hero or whatever
<oprypin>
where's this discussion going and how did we arrive here?
<vegai>
well, games. That's one of the few rare programming fields where it matters what language you use
<vegai>
I mean *actually* matters
<vegai>
in that you will fail if you pick wrong
<FromGitter>
<crisward> Has anyone wrote up anywhere exactly (or even roughly) how the crystal compiler works. I was going to start reading through the code, but an overview would be nice.
<vegai>
and that the failure will be because of the language
<vegai>
typically it's more about soft issues like processes, human problems, etc
<RX14>
@crisward do you know the traditional compiler stages?
<FromGitter>
<asterite> Ah, yes, there's one there. Then there was another which explains how bindings between nodes work
Creatornator has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<FromGitter>
<crisward> thanks for all the links. Just want to get a better understanding of the compiler to better appreciate the challenges involved in improving it.
<livcd>
well guys let me know when crystal will be ready on windows till then i will use Go and try Nim :D
<FromGitter>
<bew> Very interesting things in those slides!!! I always wondered what a Meta* thing was ;)
<FromGitter>
<bew> @asterite I've found a typo! part 2 > slide 25 > before last bullet point: `re` => `are`
<FromGitter>
<bew> and slide 26: `recalcualte` => `recalculate`
<FromGitter>
<bew> Ah, the part 2 slides are not finished :/ snif
<FromGitter>
<bew> is it a work in progress?
<FromGitter>
<asterite> They are finished... or, well, I gave the talk already
<FromGitter>
<bew> oh okay, the last slide ends in the middle of a sentence so I was wondering where is the end of it (and maybe other slides?)
<FromGitter>
<asterite> Oooh... yeah, I think I never finished it. Maybe I stopped the talk before that (it was a super informal talk)
<FromGitter>
<bew> otherwise the slides are 👌
<FromGitter>
<crisward> Just reading about method restrictions, it was something I sort of knew, but this explains it really well. Reminds me a little of css specificity.
<oprypin>
Papierkorb, this all should be disallowed. what's not great the?
<oprypin>
n
<Papierkorb>
`def f(@a)` should not
<oprypin>
of course, but these are separate things
<oprypin>
very easy to discern
<Papierkorb>
but `def f(@a = 123 + 456)` is fine. You have to parse an expression in there. if you'd do that in the parser, you'd duplicate the complete parsing logic for just that
<oprypin>
parser has a thing for parameter name and whether it has @, then it has the assigned expression
<oprypin>
Papierkorb, parser does not group the @a into that expression
<FromGitter>
<bew> now that I think about it, about to restrict it, I think those should still work, but should fail only if referencing a previous ivar that is assigned in this def
wontruef_ has joined #crystal-lang
<Papierkorb>
^
<oprypin>
bew, no, i think everyone agrees that using an ivar in initialization should not be allowed
<Papierkorb>
No, as i said, it's a syntactic way of conveying default behaviour to the user without having to write docs for it
<oprypin>
Papierkorb, I'm not sure you understand. the question is whether `def f(a = @b)` should be allowed
<Papierkorb>
I do something like `def crystal_name(override = @name)`. It's pretty clear from the prototype alone what's going on and what happens if you pass or not pass.
wontruefree has quit [Ping timeout: 240 seconds]
<oprypin>
Papierkorb, I see, so maybe I was considering only the case of initialize
<oprypin>
then we could make another clear cut rule: disallow using ivars in initialize
<FromGitter>
<bew> if we restrict it, I think that `def f(@a, @b = @a)` should break, but `def f(a = @other_ivar)` should still work
<Papierkorb>
`def f(@a = 1, @b = @a)` is broken for me too. Or more simple: A default assigning to an ivar, using an ivar, is broken.
<oprypin>
`def initialize(a = @b)` should not work
<FromGitter>
<bew> or we just make it work ^^
<Papierkorb>
oprypin: That's a reasonable, but different issue
<oprypin>
Papierkorb, what you're really saying is that my suggestion does not fix the issue
<Papierkorb>
I'm saying that your line is addressing a different issue
<oprypin>
it's not a different issue. it's the most typical but only one case of this issue
<oprypin>
disallowing using ivars in initialize would indeed fix the issue for initialize
<Papierkorb>
there it would
<Papierkorb>
Sema ftw
Groogy2 has joined #crystal-lang
<oprypin>
Papierkorb, `def initialize(@a = b, b = @c)` - how do u like that one?
<oprypin>
does that even work
<Papierkorb>
Two-fold broken of course
<Papierkorb>
May, but not in a reasonable fashion. Defaulting to later arguments doesn't make sense in any case
Groogy has quit [Disconnected by services]
Groogy2 is now known as Groogy
<Groogy>
Hiya! o/
<Papierkorb>
\o
Groogy_ has joined #crystal-lang
<FromGitter>
<bew> `@a = b` won't work (or should not) I think, as `b` is not yet defined here
<FromGitter>
<asterite> Oh, another idea is to replace instance variables with local variables if they were assigned to before them
<FromGitter>
<asterite> So `def initialize(@a, @b = @a)` would be rewritten to `def initialize(@a, @b = a)`
<oprypin>
if arg order is meant to be relied on, then sure
<FromGitter>
<asterite> but maybe that's not sound, I don't know
<Papierkorb>
oprypin: It's what I'd expect in any case
<Papierkorb>
(Wasn't C/C++ order right-to-left?)
<Groogy>
no it is undefined
<Groogy>
unless later versions defined it
<Groogy>
OOS problem we've had between cross-platform clients have been compilers doing arguments left to right or right to left
<Papierkorb>
Wasn't that the de-facto standard? Probably because some early compilers evaluated from right to left and pushed the value directly onto the stack for the impending CALL?
<FromGitter>
<bew> oprypin arg order will always be ok here imo, we're not in a call
<Papierkorb>
Groogy: Heh, could've sworn that it was de-facto. Remember quite some libs which relied on it
<Groogy>
might also just be Windows being special ¯\(°_o)/¯
<FromGitter>
<bew> @asterite sound like a very good idea to me!
<Papierkorb>
Never liked shit like `compare(*it++, *++it)` anyway :P
<oprypin>
bew, my point was that i'd prefer if relying on order was not allowed. if there's any ambiguity, just break
<Papierkorb>
oh shit, ENV is a module
<oprypin>
lol
<oprypin>
crystal has this elegance where a module can feel entirely like an instance
<Papierkorb>
Yeah feel, can't store it though
<oprypin>
Random::System is that way
<FromGitter>
<bew> `ENV` could have been a constant to a hash (almost)
<Papierkorb>
don't care if it's a Hash or not, would've been nice to have any instance
<oprypin>
why?
<FromGitter>
<bew> Papierkorb `ENV.to_h` ?
<Papierkorb>
I want to store the environment, which may be ENV (for actual use) or a Hash (for testing)
<oprypin>
Papierkorb, I do believe that if this abstraction "where a module can feel entirely like an instance" ever breaks, it's a bug
<oprypin>
Papierkorb, use : Hash | typeof(ENV)
<oprypin>
or Hash and require converting it
<oprypin>
or was it : Hash | ENV.class
<oprypin>
one of these definitely works
<Papierkorb>
Need to have write access to it, don't feel like going into the realms of subclassing or having a "EnvironmentWriter", when a #[]= is all I want basically
<oprypin>
Papierkorb, i still dont see any problem
<FromGitter>
<bew> `@a : Hash = ENV.to_h`
<oprypin>
> Need to have write access to it
<oprypin>
i already provided a solution anyway
<Papierkorb>
Huh why does .class work but typeof doesn't
<Papierkorb>
as typeof is guaranteed to be compile-time, it's what I expected to work
<oprypin>
Papierkorb, i dunno, one is part of type grammar and the other one isnt
<FromGitter>
<bew> @oprypin the hash from ENV.to_h is writable
<Papierkorb>
But doesn't change what I want to change
<FromGitter>
<bew> ah I see ><
Creatornator has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]