<FromGitter>
<drinkmorewaters> Having an issue learning about user input, getting stuck on the second if i can't call 'name' variable again.
<FromGitter>
<drinkmorewaters> `Error in input.cr:18: undefined method '+' for Nil (compile-time type is (String | Nil)) ⏎ ⏎ puts name + "Your age is " + age`
<FromGitter>
<bew> Can you please send your code using sth like bpaste.net (with crystal highlighting) or carc.in? It's illisible like this
<FromGitter>
<bew> About your problem: you have to handle the case where `gets` returns nil, meaning that there is no more data from the user
<FromGitter>
<bew> One way is to quit the program with an error message
<FromGitter>
<drinkmorewaters> @bew Sure! Didn't know what those were. Will send the final once i'm done, i am making sure the name first letter is uppercase first, then i'll post the final and maybe someone can tell me whats wrong.
<FromGitter>
<bew> Doing `gets.to_s` is a bad idea because you're "hiding" the problem
<FromGitter>
<drinkmorewaters> I guess 3 years is a long time, so they would have changed how user input is done by now.
<FromGitter>
<bew> It didn't changed, it's just that I like to be clear in my error handling, if you don't care what the program does where there is no data, you can use the given examples there
<FromGitter>
<drinkmorewaters> @bew Not that i don't care, it's that i have no idea what i'm doing as i started 3 days ago xD
<FromGitter>
<drinkmorewaters> I'm hacking together Ruby tutorials and trying them on Crystal with in and out effects
<FromGitter>
<bew> Sure no problems, you'll learn a lot :) Welcome to Crystal!
renzhi has quit [Quit: WeeChat 2.1]
<FromGitter>
<bew> So `gets` can return a string or nil
<FromGitter>
<bew> Try to handle the case where it's nil and quit your program with a message telling that the user didn't enter the wanted information
<FromGitter>
<straight-shoota> Although I didn't feel the need for any of this when using the stdlib spec
<FromGitter>
<straight-shoota> it's just really simple and easy to understand
<Yxhuvud>
one thing I've wished for is scoped definitions of helper classes, but that also isn't possible
<FromGitter>
<straight-shoota> you can name helper classes whatever you want, why do you need to scope them beyond file level?
<Yxhuvud>
because I don't want them in the global scope. Same with helper methods for only a single spec file. being able to do that scoped is so very nice and probably the thing I miss most from rspec
<jokke>
Yxhuvud: have you looked into spec2?
<jokke>
it's very similar to rspec
<jokke>
straight-shoota didn't we have a discussion about env configs some time ago?
<jokke>
where i wanted to write some macros which would coerce env var values into given types
<FromGitter>
<straight-shoota> Hey, michaeldorf, great to read such an evaluation
<FromGitter>
<straight-shoota> It definitely highlights some serious shortcomings
<Yxhuvud>
I wonder if there is some parts of the amber code generation that could be improved - I'd bet the compiler and stdlib has more code than was generated but still is faster than that to compile
Raimondii has joined #crystal-lang
<Yxhuvud>
(though still a bit slow)
<FromGitter>
<straight-shoota> Yeah, I also suspect there are issues with amber
<michaeldorf>
straight-shoota: Thank you, it is appreciated. Could you assess if I got the internals correct? Is Crystal performing global inference and global inlining?
Raimondi has quit [Ping timeout: 264 seconds]
Raimondii is now known as Raimondi
<michaeldorf>
I have studied the codebase only for a week and I would love feedback from developers with more experience
<FromGitter>
<straight-shoota> Yes, the type inference is global.
<FromGitter>
<straight-shoota> As far as I know, the compiler itself doesn't inline anything. That's part of code optimizations performed by LLVM.
<FromGitter>
<straight-shoota> To combat exponentially typed method instantiations , the trend goes towards more explicitly declaring types in method signatures. At least in libraries. This should IMHO be the default, as it also greatly helps documenting the API. ⏎ The great thing about Crystal is, that you can use explicit type restrictions but you don't have to =)
<FromGitter>
<straight-shoota> My major point of critique is the approach that you only benchmark a single Crystal application and claim it represents slow compilation time of the language. You're effectively not evaluating Crystal itself, but rather just Amber. This makes sense as a comparison between Amber, Phoenix and Rails, but doesn't tell too much about Crystal by itself.
<michaeldorf>
straight-shoota: That's a good point. That's why I bring the compiler measurements and the deps measurements later on.
<FromGitter>
<straight-shoota> I don't know much about Amber's design, and I'm not sure if these compilation times are to be expected or are even Ambers fault. Maybe it's just that the compiler can't efficiently handle such large code bases.
<michaeldorf>
But point taken, I will clarify this. :)
<FromGitter>
<straight-shoota> I'd at least test a few other Crystal applications in a similar way (for example Kemal and Lucky) to make this evaluation more meaningful.
<michaeldorf>
Regarding the compiler, I will wait for more confirmation then. My understanding is that code is emitted in a way that LLVM can optimize across those boundaries, but I want to be sure
<michaeldorf>
straight-shoota: I looked at lucky but it doesn't have a scaffold generator. I will look at Kemal.
<michaeldorf>
Is there any open source Crystal web app around?
<FromGitter>
<straight-shoota> Also, I'd clarify that the evaluation is about usefulness for large-scale monolithic applications in the introduction, to set the boundaries of your assesment
abm has joined #crystal-lang
<michaeldorf>
I wanted to compare real applications too but I couldn't find one in Crystal.
<FromGitter>
<straight-shoota> yeah, you'll probably have to generate the code manually
<michaeldorf>
Thanks Timbus. From what I understood with Lucky you need to invoke 3 separate commands and wire them manually. I decided to take a different approach for now though and measure the bootstrap of a newly generated Amber and Lucky applications.
wontruefree has joined #crystal-lang
michaeldorf has quit [Quit: Page closed]
wontruefree has quit [Ping timeout: 260 seconds]
rohitpaulk has quit [Quit: Ping timeout (120 seconds)]
rohitpaulk has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 256 seconds]
livcd has quit [Changing host]
livcd has joined #crystal-lang
<FromGitter>
<asterite> By the way, let's stop saying Crystal has global type inference. It does not. It just instantiated methods per call site. I'd say global type inference is something like Haskell where you don't specify types and the compiler figures them out, generically (it can deduce the type of a function). In Crystal we don't deduce the general type of a method, they are just instantiated per call site.
<Yxhuvud>
and anyhow, as everything (?) that is stored on the heap is explicitly typed, it is not very global in any case.
<FromGitter>
<straight-shoota> yeah, true
<FromGitter>
<straight-shoota> is there a better term to describe Crystal's type inference? =)
<FromGitter>
<Val> *per call type inference* ?
<Yxhuvud>
"nice" ?
<FromGitter>
<straight-shoota> :D
<FromGitter>
<asterite> michaeldorf: your findings are correct. Crystal has a limit to the size of programs it can compile. As such, I mostly find it useful for small programs. Compilation times will get bigger and bigger as your application size grows, and there's nothing you can do about it. I always wanted to find a way to change the language to provide incremental or modular compilation, but the community doesn't seem to care
<FromGitter>
... about that, or they think it could be tackled later (that's so untrue). At this point I don't care anymore: if you use the language and it suits you, you use it. If not, then choose another tool. I also don't know what's wrong with Amber, the code is probably way too complex to compile. I compiled code with 40~50k lines of co ... [https://gitter.im/crystal-lang/crystal?at=5b586e31bd17b961590163c2]
<FromGitter>
<asterite> I also won't spend more time trying to optimize the compiler, because without modular or incremental compilation it's useless (it will always be O(code size)). That said, Jonathan Blow is creating a language that supposedly can compile extremely fast, he's targeting somethinf like 1 million lines of code per second, an no incremental/modular compilation. But that's a fully typed language, I think. Crystal
<FromGitter>
... should probably become fully typed at one point to survive (and ban many features, like reopening classes, redefining methods, remove compile-time reflection, etc., essentially becoming something Crystal is not :-P (conclusion: Crystal won't survive))
<Yxhuvud>
I think you understate the importance of language usability and expressiveness. But anyhow, there needs to be more people that understand the code generation on a deeper level - perhaps someone can figure out a way to make the problem go away - at least in practice if not in theory.
<FromGitter>
<asterite> The code generation is not the problem, it's the language itself. The way methods are typed (or not).
<FromGitter>
<j8r> There could be two modes
<FromGitter>
<j8r> I mean, a flag that will require strict typing of everything and will allow incremental builds
<FromGitter>
<j8r> I agree with Yxhuvud, the average user care more about the API (at least first). Go has different compilers, Crystal could also have several. At the end the problem is always the same - resources, money
<FromGitter>
<asterite> Try to solve the hating problem with resources and money. In this case, I don't think that's the issue.
<FromGitter>
<j8r> So the main issue *only* the compile time performance?
<dom96>
asterite: Any plans to redesign Crystal or to make a completely new language that is fully typed?
<FromGitter>
<j8r> lol
<FromGitter>
<j8r> I can't imagine the amount of time 😮
<FromGitter>
<j8r> At least Crystal fits well the new patterns like microservices and DevOps - very happy with 😄
<FromGitter>
<asterite> dom96: no time nor interest (one language was already enough :-P). How is Nim doing? I read it also had issues with compilation times and macros (I think)
<dom96>
Nim is doing well, I would maybe even go as far as saying it's doing very well :)
<dom96>
I never had any compile time issues, where did you read that?
maksima has joined #crystal-lang
<dom96>
But actually, we are working on incremental compilation right now.
<maksima>
hello, can I ask questions about the crystal website itself here ?
<FromGitter>
<j8r> It uses C, and C compilers are deemed to be slow. In single threaded cold compilation, i would bet on Crystal compilation
<dom96>
C compilers are deemed slow? By whom?
<FromGitter>
<j8r> Compare Rust, Go and Swift compilation time vs C/C++ :)
<Yxhuvud>
c++ is a different story, with the templates.
<dom96>
Rust will definitely be much slower than C
<dom96>
Go and Nim are actually surprisingly close when it comes to compilation times.
<FromGitter>
<j8r> oh yes right Rust is slow
<FromGitter>
<j8r> I may be C++ so
<FromGitter>
<j8r> not C
<dom96>
I compared how long bootstrapping the Go compiler vs. the Nim compiler and Go was only a little bit faster.
<dom96>
But yes, keep in mind that Nim runs C compilation in parallel and only on those C files which changed.
<RX14>
crystal does the same with LLVM modules
<FromGitter>
<j8r> 👍
<dom96>
From a cold cache the Nim compiler takes 30 seconds to compile on my MBP (just checked)
<RX14>
its not incremental compilation but it does help
<RX14>
dom96, its about 40 cold and 20 hot for a crystal compiler
<RX14>
majority is in typing
<dom96>
7 seconds hot for Nim
<FromGitter>
<j8r> that quite fast considering Crystal is only single threaded
<RX14>
yeah, nim has a lot less type inference though
<RX14>
threads dont help
<RX14>
well, threads dont help if your algorithm isnt parallelizable
<FromGitter>
<asterite> dom96: oh, yes, it was incremental compilation
<FromGitter>
<j8r> you can't compile using parallelism like `-j4`?!
<dom96>
40 seconds for Crystal sounds good
<dom96>
How much memory does it use?
<FromGitter>
<j8r> and with `-j1` for nim :)
<RX14>
one or two gigs
<dom96>
:o
<RX14>
much more for the spec suite
<RX14>
you really need 8 gigs for the spec suite
<FromGitter>
<asterite> Like 1gb or more to compile the compiler :-P
<RX14>
you actually cant run the whole spec suite in travis
<dom96>
400mb for Nim
<RX14>
you need to plit it into std_spec and compiler_spec
<FromGitter>
<asterite> RX14: type inference, or omitting types, isn't really important. That second you save not putting a type annotation you lose it every time you compile your code. It's not a good trade
<jokke>
asterite: sad to hear such pessimism from a core dev :( Crystal is so far my favourite language from a usablily standpoint.
<jokke>
as in developer-friendliness
<RX14>
@asterite you've said this before and i've answered this before
<FromGitter>
<asterite> It's not pessimism, it's reality. I know the compiler and I (think I) know it's limitations
<FromGitter>
<j8r> it's a good trade for prototyping.
<FromGitter>
<j8r> (at least)
<RX14>
@asterite but you dont seem to realise how little those limitations matter to the people in this channel
<RX14>
if it really were as bad as you say then why are we all here?
<RX14>
surely nobody would use it
<jokke>
asterite: you said, there's nothing one can do about it. It seems you can speed up the compile-time by adding type annotations?
maksima has quit [Quit: Page closed]
<FromGitter>
<asterite> Nope, type annotations are just part of the problem
<FromGitter>
<asterite> Generics, reopening, redefining, macros, compile time reflection
<jokke>
those are all things that make crystal so great :)
<FromGitter>
<asterite> The list probably continues. Each point makes improving compile times incredibly harder
<jokke>
i'm still not sure i understand why lot of this can't be cached.
<jokke>
(across compilations)
<jokke>
the compiler caches the AST as far as i know
<FromGitter>
<asterite> Nope
<jokke>
oh
<jokke>
ok
<jokke>
what's the limitation in doing that?
<RX14>
caching the ast is useless since the parsing takes maybe 100ms
<jokke>
ah i see
<FromGitter>
<j8r> And the symbol table?
<jokke>
but can't macros change the AST?
<jokke>
(i know they can)
<jokke>
so is the parsing you talk about _after_ all macros have been substituted?
<RX14>
@asterite at the end of the day we both know the problems theres no point sitting here and complaining about it, it doesn't really help
<RX14>
bcardiff wants to make macros far more pure functions so they can be cached
<RX14>
or at least know the inputs
<RX14>
thats one small helpful thing being done to help
<FromGitter>
<asterite> jokke: I'll prepare a few examples showing the problems
<RX14>
he also wants to make it so you can't call methods that aren't covered by the type restrictions
<jokke>
one thing that could help is some sort of marshalling and shared memory storage to handle communication between separate compiled parts of a program, that you'd only have to link together
<Yxhuvud>
rx14: I'm not certain I understand what you mean by the last part. What type restrictions?
<RX14>
if you pass a bar into foo you can call all of bars methods
<RX14>
even if you restricted the type to fo
<RX14>
type restrictions dont restrict the methods you can call on a type
<FromGitter>
<bew> Wut
<jokke>
really??
<RX14>
of course
<jokke>
wtf
<FromGitter>
<bew> Seems i don't get it..
<FromGitter>
<bew> Ah i think i understand
<RX14>
imagine you did a type restriction for a method with enumerable
<RX14>
and passed an array in
<RX14>
you can call all the array methods
<jokke>
oooh
<jokke>
why?
<RX14>
even though you should only be able to call enumerable methods
<jokke>
yeah
<RX14>
because thats how the compiler works
<RX14>
because array is an enumerable
<RX14>
so it fits the type restriction
<jokke>
hmm and if you call it once with a map and once with an array and try to call array methods, that wouldn't work anymore, right?
<RX14>
type restrictions do not help the compiler or tell the compiler anything at all
<RX14>
they're only for humans
<RX14>
(unless for ivars/cvars)
<jokke>
sorry with a hash
<Yxhuvud>
Yeah, that doesn't make sense and restricting method calls there would be nice. But it would still be possible to call a specialized version of a method that exist in both places, right?
<RX14>
jokke, yeah youd get an error
<FromGitter>
<bew> But then there should be a more chirurgical restrictions system, to be able to restrict something (a method presence?) and still be able to call the original methods?
<FromGitter>
<straight-shoota> RX14 the compiler won't match the method to the call if the type restriction doesn't match
<FromGitter>
<asterite> In fact type restrictions slow down the compiler because it has to check a type...
<RX14>
@asterite by a miniscule amount
<jokke>
i see
<FromGitter>
<asterite> still... :-)
<RX14>
being too thorough is just going to mislead people
<RX14>
@straight-shoota what
<RX14>
just try it
<jokke>
RX14: no it was valuable since my misconception was that type restrictions could potentially speed up the compile-time
<RX14>
i meant the "type restrictions slow down" isn't valuable
<jokke>
yeah sure
<RX14>
the "type restrictions 9currently) don't lep" is
<jokke>
RX14: that seems like a low hanging fruit!
<RX14>
its not
<RX14>
@straight-shoota yeah but thats not what I said
<FromGitter>
<straight-shoota> you said "type restrictions do not [...] tell the compiler anything at all".
<FromGitter>
<straight-shoota> :P
<RX14>
i said they dont help the compiler
<RX14>
they help the human
<jokke>
i don't understand how haskell does it
<jokke>
its typesystem is way more complex
<RX14>
no its not
<FromGitter>
<straight-shoota> I guess they help avoid instantiating a chain of methods when the type doesn't fit in the first place
<RX14>
haskell's type system is far more restrictive then crystal's
<jokke>
mh ok
<jokke>
but they support partial compilation right?
<RX14>
they use the formally specified hindley milner type inference
<RX14>
and yeah they do
<RX14>
and HM only works for functional languages
<jokke>
i see
<RX14>
like you can't have "subtyping" (inheritance) in HM at all
<jokke>
true
<RX14>
let alone do any of the crazy stuff you can in crystal
<FromGitter>
<j8r> could it work with Go (which doesn't have inheritance)
<RX14>
i don't know, probably not, and thyey wouldnt want it anyway
<FromGitter>
<j8r> I'm wondering what path it has take
<jokke>
j8r could what work with go?
<jokke>
subtyping?
<FromGitter>
<j8r> Go isn't really OO
<FromGitter>
<j8r> anyway, Crystal fits well in small to med programs :)
<Yxhuvud>
rx14: one thing the haskell type inference do have though, is a bunch of different variants of type polymorphism, and they are working to get more variants of it (to enable stuff like linear types)
* Yxhuvud
saw a keynote on it (in person) a week or so ago.
<jokke>
apparently ghc spits out some sort of interface files for shared libs
<jokke>
this is something that could be done without soooo much effort in crystal as well
<FromGitter>
<j8r> do you think you could do it so?
<jokke>
hard to tell
<jokke>
basically you'd expose c functions for your relevant interfaces in your lib and map those back to crystal types
<FromGitter>
<j8r> why C?
<jokke>
because you want to link together a bunch of .o files
<jokke>
way cooler would be to do this on llvm level
<jokke>
but i have no clue how this could be done
<jokke>
the c approach would be something you could publish as a shard and just plug it into your lib
<jokke>
it would also allow using it from other languages.
<jokke>
RX14: what was the syntax for exposing c functions again?
<jokke>
just fun outside of a lib?
<RX14>
with a body, yes
<RX14>
or just
<RX14>
s/def/fun
<jokke>
i see
<RX14>
and use only C types in the args
<jokke>
sure
<jokke>
and the last line should be a c type as well?
<RX14>
well you should specify the return type
<RX14>
and yeah
<jokke>
yeah ok
<jokke>
RX14: could i just return pointerof(something)?
<jokke>
or is this still not primitive?
<FromGitter>
<diegogub> hello guys! how should I handle multiple types return from a fuction? In this case I need it to be String, but has type: (Array(String) | Bool | Int32 | String | Nil))
<RX14>
you can the question is if it'll segfault
<RX14>
Pointer is a primitive
<jokke>
RX14: why should it segfault?
<RX14>
you cant return a pointer to something on the stack
<RX14>
thats just basic C
<jokke>
yeah ok sure
<RX14>
so be careful with structs and returning pointers
<jokke>
i'm thinking of instances of classes
<RX14>
but apart from that no problem
<RX14>
yeah
<RX14>
instance.unsafe_as(Void*)
<RX14>
thats always fine to return
<jokke>
ah ok that's nice
<jokke>
what about instanciating instances from pointers ;)
<FromGitter>
<j8r> @diegogub the simpler option is to handle them early and avoid unions
<FromGitter>
<j8r> @diegogub specially large unions. Else you could aso use `.is_a? String`, `.is_a? Bool` etc.
<RX14>
jokke, pointer.unsafe_as(Class) lol
<RX14>
just the exact opposite
<jokke>
hihi
<RX14>
you don't "instantiate" from a pointer
<RX14>
because its already been constructed
<jokke>
yeah
rohitpaulk has joined #crystal-lang
<RX14>
you just have to convince the compiler that this pointer is a pointer to a class instance
<RX14>
not to void
<jokke>
i see
<RX14>
also you can't just do that between processes
<RX14>
or more accurately
<jokke>
yeah sure
<FromGitter>
<diegogub> @j8r , I understand..This library use a union https://github.com/chenkovsky/docopt.cr as return type. I guess I would have to use as
<jokke>
you need shm
<RX14>
you can do it between processes but not different compilations
<RX14>
because type IDs will be different
<jokke>
oh
<jokke>
shit
<RX14>
yeah
<jokke>
even when nothing has changed?
<jokke>
(in the specific class)
<RX14>
well that will work
<RX14>
its fairly deterministic
<RX14>
but you want to use it to speed up compilation which means youll want to use different sets of source files
<RX14>
unsafe_as is a normal method call, unlike as
<RX14>
so you can't use type shorthand
<RX14>
Void* works in as but not unsafe_as
<RX14>
so Pointer(Void)
<jokke>
ah
<jokke>
i see
rohitpaulk has quit [Ping timeout: 244 seconds]
rohitpaulk has joined #crystal-lang
<robacarp>
is there a way to check the number of unread bytes in an IO? I thought #peek would do that, but it's blocking when calling #peek on STDIN
akaiiro has joined #crystal-lang
<robacarp>
my goal is to be able to read and distinguish between the ESC and F keys, which appear to be ESC followed by a second byte. I'm able to do one or the other just fine, but asking the IO if there is a second byte is stumping me
<RX14>
robacarp, no
<RX14>
and even if you could, it wouldnt solve your issue
<RX14>
because the terminal doesnt submit characters to STDIN right away
<RX14>
it writes to stdin one whole line at a time
<RX14>
when you press enter
<RX14>
you need to enter "raw mode" to disable that
<robacarp>
RX14, I'm using raw mode already
<RX14>
oh cool
<RX14>
well you still can't - or at least it wouldnt be robust
<robacarp>
I was just reading the doc on IO#read, do you think attempting to read 2 bytes at once will read one when there's one byte and two when there are two, without blocking to attempt to read the second?
<robacarp>
or do I need to build a timer and state manager to read F keys in raw mode
akaiiro has quit [Remote host closed the connection]
<robacarp>
@j8r, okay, I think that'll work, thanks.
wontruefree has joined #crystal-lang
<robacarp>
hm, muting between the uint(8) and a char seems not to be straightforward. is it worth trying to use the encoding stuff to extract a Char, or should I just write the interface on parsing UInt8s
Flipez has joined #crystal-lang
snsei has quit [Ping timeout: 240 seconds]
<Flipez>
Hi guys, I like to gzip a whole directory in crystal. In the past I used tar and gzipped it via a shell exec. But I'd like to move this into the code direclty. Any ideas how I could do this? The gzip lib can only handle one file and I found no easy solution - despite of adding everything manually via zip
snsei has joined #crystal-lang
<FromGitter>
<straight-shoota> michaeldorf, why did you not include Lucky or Kemal or any of the suggested web applications into your evaluation?
<FromGitter>
<straight-shoota> Flipez, just iterate through all files and zip them...
<z64>
@yorci yes, you need to define `#to_h` that produces the hash structure you want
<robacarp>
jokke: a preload is executed as a different query and just loads associated records ahead of time in batch; a join is executed as part of the original query. (or that's my understanding)
<FromGitter>
<fridgerator> ^
moei has joined #crystal-lang
<FromGitter>
<kazzkiq> I'm getting an odd error on `HTTP::Server.new` when trying to run the server example of the website.
<FromGitter>
<kazzkiq> ``` code paste, see link```
<FromGitter>
<kazzkiq> Has the API changed in newer versions of crystal?
<FromGitter>
<GaryMiller> I ordered "Learning Crystal Programming" on Amazon by Serdar Dogruyol back on June 14th. It was supposed to be out early in July I believe but Amazon delayed my order and it looks like the release date was changed to October 9, 2018. Has anybody received an advanced copy or reviewed the book yet? Any first impressions? https://www.amazon.com/Learning-Crystal-Program
literal has quit [Read error: Connection reset by peer]
literal has joined #crystal-lang
akaiiro has joined #crystal-lang
<jokke>
fridgerator: hm i'm still not sure what the difference is since you will have all columns of an associated record in the result so instanciating the models from those should be easy..
<FromGitter>
<fridgerator> `Query#join` will run an actual join in the sql query thats generated
<FromGitter>
<bew> @kazzkiq which crystal version do you use?
<FromGitter>
<fridgerator> as robocarp mentioned, `Query#preload` will not do a join query, but will run extra queries to fetch the association records for you.
<jokke>
fridgerator: oh ok
<jokke>
But isn't that inferior to a join?
<jokke>
Performance-wise
<FromGitter>
<fridgerator> it just depends on what you want, they're not related
<FromGitter>
<fridgerator> if a user has many posts, and you query the user table and join on posts, it doesn't also return posts
<jokke>
Aah
<jokke>
Dang
<FromGitter>
<fridgerator> its just a join query, it serves a different purpose
<jokke>
What purpose does it serve then?
<jokke>
Ah ok i think i know
<jokke>
Find all users that have posts with the word "crystal" in them
<FromGitter>
<fridgerator> yeah
<jokke>
I see
<FromGitter>
<fridgerator> if you use `join`, then you have to specify table names in your `where` queries
<jokke>
And preloads would make a single additional query per result record per association?
<FromGitter>
<talbergs> im havin trouble in line 10 (block expects 0 arguments but one given) =/
<jokke>
Does it have any benefit over doing the queries manually (except for being convenient)
<FromGitter>
<fridgerator> No not really
<FromGitter>
<fridgerator> just for convenience like you said
<jokke>
Is it possible to add where clauses to association getters?
<FromGitter>
<bew> @kazzkiq this is not the last version, (almost) all documentation have been updated for it, and may not be valid anymore for old versions
<FromGitter>
<fridgerator> using preload?
<jokke>
Or what happens if i use user.posts when posts isn't preloaded. Returns nil?
<FromGitter>
<jwoertink> Is this what you're looking for?
<FromGitter>
<kazzkiq> Do you guys know any MongoDB driver *written* in Crystal (not only bindings to C driver)
<FromGitter>
<talbergs> I think that's not what im looking for. I must not call the block, just forward it https://play.crystal-lang.org/#/r/4lw8 ⏎ ⏎ the method accepts (string, &block),
<FromGitter>
<jwoertink> me personally, I always have issues with forwarding blocks in crystal for some reason. It should be as simple as what you're doing there
<FromGitter>
<talbergs> yes sure, readin em bottom-up not so clear. ⏎ hey made my learning curve - if you remove the last call - all things work, the last call is what I needed to work. https://play.crystal-lang.org/#/r/4lwd This surely now illustrates my point/issue.
<FromGitter>
<talbergs> Me too - there is no system - impossible to remember when `&->` or `&->(Type)` etc...
<FromGitter>
<talbergs> damn.. nvm - the link I gave has stupid mistake, sorry for timewasting.
<FromGitter>
<jwoertink> well, that syntax is `Type the proc takes -> Type the proc returns` so like `String -> String` is the same as `Proc(String, String)`
<FromGitter>
<jwoertink> Then when calling the proc it's `->(arg : Type) {}` if it takes an arg otherwise `-> {}` if it doesn't
<FromGitter>
<talbergs> Yup, that's tru, it's late here (gmt+2)
<FromGitter>
<talbergs> what's your timezones?
Raimondii has joined #crystal-lang
Raimondi has quit [Ping timeout: 264 seconds]
Raimondii is now known as Raimondi
<FromGitter>
<jwoertink> That's like in the future!
<FromGitter>
<jwoertink> -7 here lol
akaiiro has quit [Ping timeout: 256 seconds]
alex`` has quit [Ping timeout: 240 seconds]
<FromGitter>
<bew> Where are you @jwoertink?
<FromGitter>
<jwoertink> Las Vegas
akaiiro has joined #crystal-lang
wontruefree has quit [Quit: bye]
Cyrus has quit [Read error: Connection reset by peer]
wontruefree has joined #crystal-lang
wontruefree has quit [Ping timeout: 244 seconds]
<FromGitter>
<bew> oh I was in Las Vegas a few months ago, I'm at university in san marcos, finishing my summer semester now (and going back to france in one month :/)
wontruefree has joined #crystal-lang
Cyrus has joined #crystal-lang
<FromGitter>
<jwoertink> oh nice! Well you missed the hot part. It's about 115 here today 😅
<crystal-gh>
[crystal] straight-shoota opened pull request #6445: Fix Random#rand(Range(Float, Float)) to return Float (master...jm/fix/random-rand-float-range) https://git.io/fN0Hi
<FromGitter>
<bew> oh yeah, it's quite hot here too fortunately computers can work inside where it's not too hot x)