<FromGitter>
<fridgerator> I don't know, its only been in development since November
<FromGitter>
<fridgerator> I've used it in several personal projects and now am working on a project that will be in production
<FromGitter>
<elorest> good point. but the other ones don't seem to have moved much in the last 6 months. Crecto appears to have validations and a few associations that were lacking in the other ones I tried.
<FromGitter>
<elorest> @fridgerator Does crecto have migrations?
<FromGitter>
<Zhomart> Which task manager do you prefer for crystal project?
<FromGitter>
<fridgerator> it does not
<FromGitter>
<fridgerator> Ive beeen using micrate
<FromGitter>
<elorest> thanks. does that work with it? or require me to define my schema twice.
<FromGitter>
<fridgerator> have to do both migrations and models separately
<FromGitter>
<elorest> sort of lame but definitely advantages to not having them together.
<FromGitter>
<fridgerator> I wouldn't mind having that feature, i've just been working on others
<FromGitter>
<elorest> Kemalyst::Model lets you run ModelName.migrate which I've found to be handy.
<FromGitter>
<fridgerator> so you don't have to generate migrations separately? its handled by model changes like Django?
<FromGitter>
<elorest> yeah
<FromGitter>
<fridgerator> ah
<FromGitter>
<fridgerator> if I were to implement a migration feature it would be more like ActiveRecord / Ecto
<FromGitter>
<elorest> yeah.
<FromGitter>
<elorest> that's what I would prefer.
<FromGitter>
<fridgerator> you're not the only person to mention migrations though, so I might start looking into it
<FromGitter>
<fridgerator> seems like a pretty large feature though
<FromGitter>
<elorest> perhaps even the ability to create micrate migrations from model schema's would easier and make sense.
<FromGitter>
<elorest> or some sort of generator that let you do both at once.
<FromGitter>
<elorest> similar to `rails g model User name:string email:string age:integer`
Raimondii has joined #crystal-lang
Raimondi has quit [Ping timeout: 268 seconds]
Raimondii is now known as Raimondi
<FromGitter>
<codingphasedotcom> hey guys
<FromGitter>
<codingphasedotcom> i'm trying to write a file with
<FromGitter>
<Zhomart> @drosehn thanks, I went with `File.expand_path`
<FromGitter>
<fridgerator> anyone know of something similar to `after_initialize` ?
<FromGitter>
<fridgerator> trying to figure out how i'm going to set default values in crecto
bungoman_ has joined #crystal-lang
bungoman has quit [Ping timeout: 246 seconds]
DaleK5whr has joined #crystal-lang
DaleK5whr has left #crystal-lang [#crystal-lang]
<crystal-gh>
[crystal] Sija opened pull request #4171: Add specs for #4163 (master...add-specs-for-pr-4163) https://git.io/vyALH
sija has joined #crystal-lang
<FromGitter>
<Sija> @fridgerator there’s `included`, `extended` or `finished` which by your way
akwiatkowski has joined #crystal-lang
bjz has joined #crystal-lang
mark_66 has joined #crystal-lang
minus_ is now known as minus
akwiatkowski has quit [Ping timeout: 260 seconds]
akwiatkowski has joined #crystal-lang
gloscombe has joined #crystal-lang
unshadow has joined #crystal-lang
unshadow_ has joined #crystal-lang
alibby has joined #crystal-lang
alibby1 has quit [Ping timeout: 260 seconds]
<FromGitter>
<yxhuvud> Hmm. I don't like the new stacktrace format with a space between the path and the line number. It breaks the assumptions of my line detection script in Emacs, and it is not so simple to fix as the assumption of no spaces is needed to get a decent accuracy :(
buggs has quit [Quit: WeeChat 1.5]
<FromGitter>
<sdogruyol> @RX14 installing Crystal 0.20.5 via crane :)
<RX14>
nice
<FromGitter>
<sdogruyol> compiling from source is good but takes a lot of time
<FromGitter>
<sdogruyol> :/
<RX14>
it only takes 6 minutes for me!
<RX14>
I added a --no-release flag for testing though
<FromGitter>
<yxhuvud> How do I use crystal tool expand? That help text really needs an example.
<unshadow_>
So, I wanted to see how much would be written in 5 sec, but, it seems that the Fiber wont "release" back to the main program: http://screencloud.net/v/htP49 Is that a bug ?
Qchmqs has joined #crystal-lang
<unshadow_>
Doing the same in Ruby with Thread.new is working as expected, so the Logic seems sound, except maybe Fiber and Ruby's green threads don't really behave the same ?
<FromGitter>
<fridgerator> @RX14 are you using oh-my-zsh ?
<FromGitter>
<alex-lairan> Hi guy's, how can I cast a `Int62` to a `Int32` ? Thanks :)
<FromGitter>
<KCreate> you mean Int64?
<FromGitter>
<KCreate> just do `num.to_i32`
<FromGitter>
<alex-lairan> Yes ^^
<FromGitter>
<alex-lairan> Okay, easy :p thank you :)
<FromGitter>
<KCreate> this goes for all numerics btw
<FromGitter>
<KCreate> to_i8, to_i16 and so on
<FromGitter>
<KCreate> and to_f32 and to_f64 for floating point numbers
<FromGitter>
<alex-lairan> ok :+1:
Qchmqs has quit [Quit: Konversation terminated!]
bjz_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
bjz has joined #crystal-lang
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
akwiatkowski has quit [Ping timeout: 240 seconds]
unshadow_ has quit [Quit: leaving]
unshadow has quit [Remote host closed the connection]
akwiatkowski has joined #crystal-lang
<FromGitter>
<yxhuvud> @RX14 I did some work on integrating macro expansion into the crystal emacs mode. https://github.com/yxhuvud/emacs-crystal-mode (last 3 commits). It is really nice and convenient, but perhaps not worth the added dependency. perhaps it is possible to work around somehow.
greengriminal has joined #crystal-lang
mark_66 has quit [Remote host closed the connection]
<FromGitter>
<khepin> hi! I was wondering if the default `HTTP::Server` handles requests each in a Fiber or if it’s all synchronous?
<FromGitter>
<sdogruyol> in a different fiber
<FromGitter>
<khepin> thanks!
<RX14>
@yxhuvud would be nice to have some more basic stuff in crystal-emacs-mode
<RX14>
like indentation actually working properly
<RX14>
i really should report all the bugs I find in crystal-emacs-mode but i'm always coding in crystal when I find the bugs so i don't want to context switch
<Yxhuvud>
You have format. That works. But yeah, that would be nice.
<RX14>
yeah I just :w
<RX14>
and the formatter fixes it
<RX14>
but it is annoying
<RX14>
i really should start the spacemacs layer from scratch though
<RX14>
it's pretty bad
<Yxhuvud>
next step will be running tests I think. Everything is in place to do that from within.
<RX14>
yeah
<RX14>
tests would be easy
<RX14>
you'd just assert that formatting x with the crystal-mode would be the same as with tool format
<RX14>
Yxhuvud, i'm pretty sure emacs packages can depend on other packages so why do you need to have it in the readme?
<RX14>
doesn't melpa handle that somehow?
<Yxhuvud>
1st off it isn't on melpa yet, and secondly there needs to be config for crystal in there. But if it is solvable somehow, I'd be very happy to improve further
<RX14>
i'm sure dotmilk would do it if you researched how to publish it
<RX14>
made a PR with instructions, etc.
<Yxhuvud>
last action in the issue for it is 'I'll do it tonight'. :P
<RX14>
he's willing at least
<Yxhuvud>
but I honestly have no idea how to do that.
gloscombe has quit [Ping timeout: 268 seconds]
<RX14>
Yxhuvud, i think you just use (require 'package-name) ?
<RX14>
it's all very confusing
<RX14>
oh never mind
<RX14>
Yxhuvud, you would need a -pkg.el file which has a (define-package) in
<FromGitter>
<fridgerator> is documented how he does it in there
<FromGitter>
<jwoertink> no
<FromGitter>
<jwoertink> oh cool.
<FromGitter>
<jwoertink> I'll check that out. I have my package for fez
<FromGitter>
<jwoertink> but after installing fez through homebrew, fez won't do anything
<FromGitter>
<jwoertink> but it works fine when installing from github directly
<FromGitter>
<fridgerator> ah
<FromGitter>
<ysbaddaden> Paris Crystal Meetup is over! Great talk about Kemal & Topaz, about Toro (people were amazed by raw performance of Crystal vs Ruby).
<FromGitter>
<andrius> Stuck with this, how do you handle the, guys? in src/asterisk/manager.cr:22: undefined method 'tcp_keepalive_interval=' for Nil (compile-time type is (TCPSocket | Nil)) ⏎ ⏎ ``` @conn.tcp_keepalive_interval = 10``` [https://gitter.im/crystal-lang/crystal?at=58d19a5b2215a08f04ae5579]
<FromGitter>
<ysbaddaden> It's because ``
<FromGitter>
<ysbaddaden> conn is nilable
<FromGitter>
<ysbaddaden> You must assign it to a local variable or use an accessor that will make sure to return a TCPSocket, not a nil
<FromGitter>
<andrius> problem is that TCPSocket.new connects immediately to a socket, I do not want to have this logic in initialize
<FromGitter>
<ysbaddaden> @txdv crystal isn't 1:1 ruby, but syro gem and toro shard are mostly the same, so comparable.
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<RX14>
@andrius i'd recommend using a raise-on-nil getter then
<RX14>
or if you don't want a getter, you can use @conn.not_nil!.<whatever>
<RX14>
or assign conn = @conn.not_nil! and it'll raise at runtime
<RX14>
or use `if conn = @conn` and do either something else or nothing if @conn is nil
<FromGitter>
<ysbaddaden> ?
<FromGitter>
<andrius> in initialize I did this @conn = TCPSocket.new, then it won't connect anywhare. And defined connect! methid where recreating @conn with credentials
<crystal-gh>
[crystal] bcardiff pushed 1 new commit to master: https://git.io/vypzj
<crystal-gh>
crystal/master e4d1f92 Sijawusz Pur Rahnama: Add specs for printing backtrace to STDERR in case of unhandled exception or crash (#4171)
<kodo[m]>
TIL not_nil!
<RX14>
try not to use it :)
<RX14>
there are a few places where you have to
<RX14>
but just raising a "x is nil" exception isn't usually what you want
<kodo[m]>
what if my thing is like FOO | Nil and then I do thing.bar and it's like dude it can be nil
<RX14>
you consider what you want to happen if your thing is nil
<RX14>
it's just that there's very often a better thing to do than raise
<kodo[m]>
throw an exception because it really shouldn't be nil
<kodo[m]>
heh
<kodo[m]>
like if it's nil something bad happened
<RX14>
if something really bad happens, raise
<RX14>
not return nil
<RX14>
often you can reorganise or rethink your code to remove nils
<kodo[m]>
catching nils at compile time ios probably my favourite crystal feature
<kodo[m]>
is probably*
<RX14>
@sdogruyol WDYT about the idea of crane performing a quick debug build of crystal then forking and doing a release build in the background? It would provide quick-ish installs + release compiler eventually
<FromGitter>
<bew> I was also at the crystal meetup in Paris with @ysbaddaden , BTW thanks for the talk! And thanks for the other talks too, my friend who accepted to come is moving more and more to Crystal, it's so worth it :smile:
<FromGitter>
<bew> just a fun note: how to make infinite loop with the compiler: https://aww.moe/yq74mf.png
<FromGitter>
<exts> can anyone help me w/ this error http://pastebin.com/raw/6nh32B3T was trying to use this (blocknotes/curl-crystal) curl shard
<Papierkorb>
Added an experimental feature on the thing I'm working on: showing context while typing https://i.imgur.com/Bg1Geit.png
<Papierkorb>
Have to figure out how to get the crystal parser to accept broken input for real highlighting though, don't want to do regex magic when there's a real parser I could just ask what is what
<FromGitter>
<bew> yeah, how did you do that ?
<Papierkorb>
What part exactly? Prompt? REPL? Context analysis?
<RX14>
Papierkorb, that's the problem I always hit when thinking about using the crystal compiler for a completion tool
<FromGitter>
<bew> the parser part, to accept broken input ?
<RX14>
the only *use* of a language/completion server is to write code
<RX14>
when you're writing code your code is by definition not going to work
<RX14>
or maybe even not parse
<Papierkorb>
bew, that's what I have to figure out. May take a week though, I'm away over the week-end ;)
<RX14>
so a completion server has to handle broken code a lot more than valid code
<RX14>
however the very point of a compiler is not to accept broken code
<Papierkorb>
A parser is not a compiler
<FromGitter>
<bew> oh I thought you figured it out already, because that's indeed THE issue here in code completion etc..
<Papierkorb>
a parser can accept broken input and still make a good effort on it
<RX14>
it can
<RX14>
but this parser is part of a compiler
<Papierkorb>
and then set a flag if it's compilable or not
<RX14>
so guess what it does
<RX14>
it rejects it
<RX14>
so I figure that creating a compiler from a completion tool would be a lot easier than the reverse
onionhammer has quit [Read error: Connection reset by peer]
<RX14>
a completion tool has to handle valid and invalid code, and guess intent from both
<Papierkorb>
When I have serious time, I'll invest some into looking into it, maybe modifying the parser to do backtracking for that
<FromGitter>
<bew> @RX14 if you have a completion tool, you already have a good part of the compiler ^^
<RX14>
however a compiler only has to deal with valid code
<RX14>
@bew that's my point
<RX14>
that trying to turn the crystal compiler into a completion tool would require a rewrite
<RX14>
i.e. don't bother, work on a seperate completion server
<Papierkorb>
*parser
<RX14>
yes
<RX14>
parser rewrite
<RX14>
i meant
<FromGitter>
<bew> Papierkorb you might want to look into PEG parser maybe
<Papierkorb>
Better now than later RX14 if it'd would come down to that
<RX14>
all these parser generator tools seem kinda annoying to me, why not just write a lexer and parser from scratch like crystal
<Papierkorb>
bew, yeah something or stick to the LL(1) approach, I don't care as far that goes, I just don't want to implement a PEG generator :P
<Papierkorb>
RX14: Because it's sooo much easier
<FromGitter>
<bew> I have a project to make a PEG parser generator, that could allow to write a parser for Crystal (and maybe use it in-place instead of the current scanner+parser), but this is currently not functionnal ^^
<Papierkorb>
Just write a rule, the code to call, done
<RX14>
iirc even gcc has given up and just used a hand-written recursive descent parser
<FromGitter>
<bew> (in crystal of course)
<Papierkorb>
The grammar is checked for problems, etc
<RX14>
i thought we wanted control of that checking?
<Papierkorb>
No, the grammar itself
<Papierkorb>
if there are conflicting rules of sorts
<RX14>
i'm sure crystal's grammar is non-uniform
<RX14>
iirc ruby's was weird
<Papierkorb>
a proper parser generator tool can also parse partial input, even if you have to add synchronization tokens or so
<RX14>
and needed hacks
<RX14>
parser generators never look easier to me, they always just look like shorter code
<Papierkorb>
For C I really liked `lemon`, developed by the SQLite guys for SQLite
<Papierkorb>
RX14: You can't express every language in LL(1)
<RX14>
i know
<RX14>
i havent done the theory though
<RX14>
maybe I should
<Papierkorb>
And writing a PEG or LR(1) by hand is crazy
<FromGitter>
<bew> @RX14 shorter code, yes, but then also more maintainable, and often, more extensible
<Papierkorb>
e.g. look at type definitions in Crystal: `name : Type` That is LL(1)-able as far it goes. You know what's funny?
<Papierkorb>
If it'd be C-style: `Type name` it wouldn't be anymore on its own
<Papierkorb>
at least if you allow it to be written in a (method) body
<RX14>
i'm pretty sure a LL(1) wouldn't be able to parse crystal
<Papierkorb>
RX14: Recursive decent is LL(1)
<Papierkorb>
well, can be any LL(k), but most commonly LL(1), and in our case, it is LL(1)
<Papierkorb>
The grammar rules for Crystal aren't even that crazy if you'd write them down
<RX14>
how do you know it's ll(1)?
<Papierkorb>
what part? LL or K=1?
<Papierkorb>
Recursive descent parsers implement a parser for a LL(k) grammar by definition
<RX14>
the K=1
<Papierkorb>
k = 1 cause I only know of `next_token` (for lookahead), and not any part which does a look ahead farther than that one token
<RX14>
but you can store tokens in local vars, wouldn't that potentially make k>1 a thing?
<Papierkorb>
the k is strictly for look ahead
<Papierkorb>
Hardest rule I can think of is '{' which can be a hash, named tuple, or a block
<RX14>
aparrently / is a problem too
<RX14>
commonly crops up with regex or operator
<Papierkorb>
that's a lexer thing
<Papierkorb>
the parser shouldn't care less
<Papierkorb>
So I evangelized Crystal over in #ruby a bit, one or two hadn't hard of us before
bungoman has joined #crystal-lang
bungoman_ has quit [Ping timeout: 246 seconds]
akwiatkowski has quit [Ping timeout: 260 seconds]
<FromGitter>
<Zhomart> Did I understood correctly: Crystal programs are not parallel, they don't run fibers in multiple OS threads?