<CraigBuchek>
Anyone around? The docs say I can overload a method, but I can't seem to overload initialize(). Anyone know if that's the case, or if I might be doing something wrong?
<farleyknight>
I would imagine you'd just have to mess with the CRYSTAL_PATH or something?
<waj>
but we would like avoid having a central repository
<farleyknight>
I've been trying to study the source..
<farleyknight>
Is T* a shorthand for Pointer(T) ?
<waj>
I've been just spiking around the idea of a native crystal connector. It should be possible to take advantage of some features to make it much faster than using libmysqlclient
<waj>
yes
<farleyknight>
Crystal faster than C?
<farleyknight>
That would be impressive!
<waj>
absolutely
<waj>
well… is not that crystal is faster than C
<waj>
sometimes it's the same
<waj>
but using native crystal it's possible for example to read the data coming in directly into the structures that you'll later use in your app
<waj>
for example, I've playing around something like this:
<waj>
class User
<waj>
property id
<waj>
@id = row.read_int
<waj>
def initialize(row_reader)
<waj>
property email
<waj>
@email = row.read_string
<waj>
end
<waj>
end
<waj>
and the row_reader would be something that directly deserialises the incoming packets
<waj>
that's comparable to the json mapping that we have now
<waj>
we just skip intermediate structures
<farleyknight>
I saw you guys also have a project called frank, which looks like a sinatra styled framework.
<farleyknight>
How long until we have a full web stack application ready for crystal?
<farleyknight>
What can I do to make that happen sooner?
<farleyknight>
*web application framework
<waj>
hehe… toooo much stuff missing yet
<farleyknight>
Well MySQL bindings was what came to mind for me. But you've kind of got that covered!
dancinglightning has joined #crystal-lang
<farleyknight>
I believe there was something on the mailing list about ECR macros..
<farleyknight>
That covers templating.
<farleyknight>
Maybe an Arel type system for generating SQL?
<waj>
that would be wonderful
<farleyknight>
Yea, I've dug around the Rails source code, in that area before.
<waj>
still looking for some way to maximise the code generated at compile time
<farleyknight>
I might come to you for optimization questions, though!
<waj>
all the stuff we have in frank is still really basic
<waj>
the current http server only attends one request at a time
<waj>
I have some work done with fibers and libevent
<waj>
but still too many segfaults :P
<farleyknight>
Wow! I'm loving how far you guys are taking this language in such a short time!
<farleyknight>
So I think I might continue with my MySQL C API bindings, and then put some benchmarks in the README so you can get an idea how fast it is.
<waj>
yup! that would be great
<waj>
we also need to figure out a db model to abstract the implementations
<farleyknight>
I believe Arel has a separate class for every database connection. I don't think it's a terribly difficult interface to implement.
dancinglightni-1 has joined #crystal-lang
waj has joined #crystal-lang
<CraigBuchek>
How can I specify a Tuple return type? I tried Tuple(Int, Int, Int) and {Int, Int, Int} but I'm getting the same error for both: wrong number of type vars for Tuple(T) (3 for 1)
<CraigBuchek>
If I leave the return type off the signature, it works fine.
<dancinglightni-1>
hi, is ary around ? what’s his nick?
<CraigBuchek>
@waj, @farleyknight for an ORM, take a look at https://github.com/boochtek/ruby_preserves/. If you stop trying to have your ORM write SQL for you, it reduces the code to about 200 lines.
<CraigBuchek>
@dancinglightni-1, he goes by @asterite.
<CraigBuchek>
After I get Ruby Preserves working well, I'll likely create a Crystal Preserves port.
<dancinglightni-1>
@craigbuchek thanks
waj has joined #crystal-lang
<CraigBuchek>
How can I specify a Tuple return type? I tried Tuple(Int, Int, Int) and {Int, Int, Int} but I'm getting the same error for both: wrong number of type vars for Tuple(T) (3 for 1)
<waj>
Tuple({Int, Int, Int})
<waj>
actually, {Int, Int, Int} should work but seems there is a bug
<CraigBuchek>
A method_missing macro! Whoa!
<waj>
;)
<CraigBuchek>
Things just got interesting.
<CraigBuchek>
interestinger
<waj>
what would you use it for?
<waj>
we currently use it on a single place
<waj>
to decorate the LLVM builder and forward all the undefined methods
<CraigBuchek>
Dunno, but method_missing in a non-dynamic language is pretty mind-blowing.
<CraigBuchek>
So I'm trying to create a macro that takes a block myself. And can't get it to work.
<CraigBuchek>
I want to do let(:a) { value } like RSpec.
<CraigBuchek>
The obvious implementation isn't working for me:
<CraigBuchek>
macro let(name, block)
<CraigBuchek>
def {{name.id}}
<CraigBuchek>
end
<CraigBuchek>
end
<CraigBuchek>
@{{name.id}} ||= {{block}}.call
<waj>
mm… the macro expert (@asterite) is not online ;)
<waj>
let me see...
<CraigBuchek>
I think I found a work-around.
<CraigBuchek>
I created a method that calls the macro, which converts the &block for me.
<CraigBuchek>
Should really support &block in macros.
<waj>
you should be able to {{ yield }}
<waj>
otherwise you'll be creating a fun type
<CraigBuchek>
Ah, that seems to work even better.
<waj>
that's a nice feature to have in the specs btw :)
bcardiff has joined #crystal-lang
<CraigBuchek>
Only trouble now is that describe blocks aren't in a scope that allows setting instance variables. The let and let! were easy enough though.
<CraigBuchek>
Not sure if it'll be possible to get describe blocks to be created in a way that will allow creating a class so we can use instance variables. I suspect it'll require a macro.
<CraigBuchek>
I'll keep trying though.
<CraigBuchek>
After let and let!, I'll try adding before blocks.
<waj>
there are some ideas to change the whole thing
<CraigBuchek>
Then I want to try something like Hamcrest matchers.
<waj>
right now is not possible to run just a single test
<CraigBuchek>
Running a single test is hard. RSpec lets you specify a line number, then figures out the inner-most describe block enclosing that line.
<CraigBuchek>
I think Crystal is fast enough that that's not all that useful.
<CraigBuchek>
Perhaps allow specifying by name though.
<CraigBuchek>
But that seems kinda verbose.
<waj>
is not because the speed, but it's annoying when you are trying to debug just one thing
<waj>
if "it" was a macro we could use __LINE__ to get the line number where the test is defined
bcardiff has joined #crystal-lang
<CraigBuchek>
True.
<CraigBuchek>
So then it() will have to be a macro, describe() will probably have to be a macro.
<CraigBuchek>
I hope you're happy with the macro language!
<waj>
I am! I think it's the right way to do metaprogramming in crystal