<jhass>
any tips on debugging crystal programs? in particular examining local and instance variables during runtime/ on errors (segfaults/fpes/exceptions etc)
bcardiff has joined #crystal-lang
kilk_ has joined #crystal-lang
drizz has joined #crystal-lang
asterite has joined #crystal-lang
<asterite>
@jhass debugger support is very limited right now
<asterite>
you can compile your program with -d or —debug and then execute it with lldb
<jhass>
yeah doing that. just don't seem to be able to access args or locals
<asterite>
Yes, but right now you can just step through the code but can’t inspect anything (I think)
<asterite>
It’s something we plan to do, and maybe eventually provide a front-end to lldb with crystal-specific information
<asterite>
Wow, that’s strange. What’s your program?
<jhass>
nothing small (or yet clean) enough to share, but I'm playing with a little terminal 2048
<jhass>
another thing I'm seeing are SIGFPEs (usually divide by zero) in Hash#bucket_index
<asterite>
Oh, that game is so addictive!
<jhass>
not sure if that's a bug on my side or something else
<jhass>
I'll probably clean it up and make a PR so you can have a look at it
<asterite>
Strange, because bucket_index does % @buckets.length, and that’s always greater than zero
<asterite>
(we still don’t handle well division by zero)
<jhass>
yes, maybe the trace is just off and ends up there
<jhass>
(though it reliably doessssss
<asterite>
:)
<jhass>
er, sorry synergy lagging
<asterite>
your PR would be for a sample program of 2048?
<jhass>
yep
<asterite>
cool
<jhass>
+ stdlib modifications needed
<jhass>
like a first dump Array#include? or a start of something like ruby's io/console
<jhass>
*dumb
<asterite>
we have Enumerable#includes?
<asterite>
but it’s with an “s” at the end
<jhass>
ah, like responds_to? vs respond_to?, missed that
<asterite>
Yes… the compiler didn’t tell you “did you mean...?"
<jhass>
maybe I overlooked it
<asterite>
maybe we’ll eventually add aliases for those names, I think it’s ok to have both
<jhass>
yeah, that would make life easier for ruby devs
<jhass>
though I repeatedly write responds_to? in ruby :P
<asterite>
:D
<asterite>
I didn’t know about io/console
<jhass>
I just assume termios is available atm. maybe it's not worth it to extract that into a lib
<jhass>
ruby's io/console seems much more sophisticated
<asterite>
there’s also a start of an ncurses wrapper in the repo
<jhass>
saw that, just can't get myself to learn ncurses :P
<asterite>
I just copied some methods and sample code from ruby, I don’t know much about it either :)
<asterite>
(because maybe we will use ncurses for a small app here, so maybe we’ll use crystal… but we are not sure yet)
<asterite>
well, I’m really looking forward to seeing your 2048 game :)
<jhass>
btw. any plan to parse header files at compile time, at least for the constants? I didn't investigate but most of termios constants look very system specific
<asterite>
we’ll have a tool to parse header files and produce a crystal lib declaration
<asterite>
but I’m not sure that doing that at compile time is good
<asterite>
we investigated this with libclang, but didn’t have much time to do it yet
<jhass>
well, I'm pretty sure you'll see system specific things sooner or later and I'm not sure maintaining all those ifdefs by hand is good idea
<asterite>
one problem of doing it at compile time is that you won’t be able to cross-compile your program
<asterite>
yes, i’m not sure either :)
<jhass>
hm, but if you cross compile, you need to have to headers nonetheless, no?
<asterite>
Just the declarations in crystal are enough
<asterite>
@waj wants to do that header-parsing, I still have my doubts, but maybe it’ll happen :)
<jhass>
I'd say having your target platforms headers available is a valid requirement for cross compiling
<asterite>
we declare a bunch of types like ContextRef, and then the function names are lowecased…
<asterite>
I’m not sure how an automatic tool can do that
<asterite>
and where to look if this tool runs at compile-time: hard to find definitions this way
<asterite>
but a tool that generates a preliminary code which you can then tweak might be better
<jhass>
I think you can get very far by just making constants and type aliases available
<asterite>
we’ll have to try it
<asterite>
too bad C’s declarations/defines are so awful
<jhass>
I'd say even something like making them available in something special cased like headers["foo.h"]["CONSTANT"] and then assigning that in a lib enum or something would help already
bcardiff has joined #crystal-lang
<jhass>
writing boilerplate generators on top of that is not that big of a deal and can have a larger error margin
<jhass>
just some way to access the values without copy pasting them would be nice
<jhass>
well + automatic type aliases I guess
<asterite>
we’ll think of something :)
<jhass>
sure, just sharing my thoughts :)
<asterite>
C bindings are something we definitely need to improve
<asterite>
Right now they are the most basic thing that we can up with to start interfacing with C
<asterite>
and we did play with libclang, so I’m sure it’ll get improvements over time
<jhass>
I already like them though
<jhass>
would you consider a read_nonblock for the core IO module?
<asterite>
Yes, I guess. What does it do?
<asterite>
(I see the description in Ruby, but I never used it, so...)
<jhass>
turn the fd to nonblock mode, read what's available, return a string of what was found (or nil if nothing was read) and turn nonblock mode off again
<jhass>
that together with the raw mode from io/console basically makes it possible to read keypresses
<asterite>
Ah, I see
<jhass>
well and of course it has a length param
<asterite>
I guess in crystal it would be: read_nonblock(buffer : UInt8*, count)
<jhass>
hm, I wanted to abstract the buffer handling and just return String/Nil
<asterite>
ah, icr is very broken, maybe we should delete it until we can do it well
<jhass>
figured ;)
<asterite>
did you run into annyoing things while coding 2048 and the related code?
<asterite>
(like bugs, hard to understand error messages or just type-inference related annoyances)
asterite has left #crystal-lang [#crystal-lang]
asterite has joined #crystal-lang
<jhass>
not more than expected at this stage
<jhass>
I've two or three comments in 2048.cr for possible method / syntax additions
<asterite>
really? cool! like what?
<jhass>
I missed x.to(y) that would upto / downto depending on x < y or y > x for example
<asterite>
oh, I forgot to tell you I was very impressed with the code you sent… so much code! It still feels scary or weird to see so much code written in crystal :-P
<jhass>
:P
<jhass>
it didn't feel that much when writing it really
<jhass>
probably because my ruby is quite good and I know the pains of java, though it's good that crystal lives up to that
<jhass>
and I've tried similar stuff in ruby before, it was nice to notice the effortless performance crystal gave
<asterite>
the to method seems a nice addition. There’s no equivalent in ruby, right?
<jhass>
actually not that I'm aware of
<jhass>
let me peek through Range and Enumerable again
<asterite>
I think there’s no equivalent. And Range is always upwards. But #to seems a good addition, and it’s shorter than upto/downto and you don’t have to think which one to use
<jhass>
yep, don't see anything either, (10..0).to, 0.downto(10), 10.downto(0) all yield empty array
<asterite>
did you write that 2048 program yourself or you translated it from ruby?
<jhass>
nope, from the ground up in crystal
<jhass>
just as a little side project in the last couple of weeks
<jhass>
ever when I was bored for an hour or so
<asterite>
really, really cool :)
<jhass>
thank you, but not possible without your work ;)
<asterite>
:)
<asterite>
I see the commented “until” instead of while
<asterite>
I didn’t know that existed in ruby
<asterite>
is that your syntax addition?
<jhass>
no ruby has it
<asterite>
ah, so it’s also a ruby syntax addition :)
<asterite>
i’ll add an issue to add “until” to the language, seems simple and useful
<jhass>
yeah
<asterite>
wow, you used a macro inside a def
<asterite>
I had no idea that worked :-P
<asterite>
ah… i think it just defines it outside as well (i’ll have to check it…)
<jhass>
I suppose so
<jhass>
I wanted some way to remove that enormous duplication there. #to basically is the other way there
<jhass>
I placed it inside just to group it to it's usage
<jhass>
oh and one of the error messages that probably could be improved is the one that you get if you replaced the while with the until, it should error out on the until already, not on the last superfluous end
<asterite>
ah… the problem is that `until …` looks like a method call. Then the body is again just two expresions. Then comes the end, which closes the def. And so on… until the last end, which is the superfluous one
<asterite>
I’m not sure that can be improved
<asterite>
(you get the same error in ruby, if you change “until” with another name)
<jhass>
hm yeah, it's a hard one
kilk_ has joined #crystal-lang
<asterite>
@jhass one question: why is io/console in libs? we can put it in std/io/console
<jhass>
hm, I guess I didn't get your core/stdlib/?? structure yet
<asterite>
:)
<asterite>
I think we won’t have a core/stdlib distinction (I think)
<asterite>
Everything in libs is something that will eventually be moved into a separate library
<jhass>
kk
<asterite>
but we are not sure yet
<jhass>
k, moved it
<asterite>
thanks :)
<asterite>
i always wonder what should be in the std
<asterite>
i think, the more is in the std, the better
<asterite>
so people don’t reinent the wheel, and there’s standarization
<jhass>
IMO you shouldn't go the java way, pick the on average best solution for a problem, don't add one performing best for each corner case. For example pick one sort algorithm
<jhass>
If you want to add more data structure for essentially the same problem, pick a target domain. For example instead of Array and LinkedList do Array and Queue etc
<jhass>
*structures
<asterite>
Java has more then one sort algorithm?
<asterite>
Ah, I see
<jhass>
not sure but I wouldn't be surprised.
<asterite>
Ah, yes, the many kinds of collections they have
<asterite>
I think that’s not bad if you can trade one for another to improve performance in some cases
<jhass>
or the half dozen of Time & Date implementations
<asterite>
but it’s good to have one default container for almost everything, that performs reasonably well (like ruby’s array and hash)
<jhass>
and that reasonable default should be in core/stdlib
<asterite>
yes
<jhass>
the corner cases can be external libraries
<jhass>
that will increase the confidence to pick the right one on the average case but lets you pick the for your case more efficient one when you know you need it
<jhass>
but in Java for example I've no idea if I should use HashSet or a TreeSet
<jhass>
I mostly choose one at random
<asterite>
Ah, yes… it’s like you can almost always try to guess what to use, but unless you profile it then any would ok
<jhass>
so what I think is more important than a big stdlib is a good "rubygems for crystal"
<jhass>
introduce a central place an package system early
<jhass>
don't let it grow out of the community, it makes it hard to find the best solution and you just end up with multiple libs doing the same thing
<asterite>
yes, we definitely don’t want that
<jhass>
so once you're at about the feature set of rubys core, that would be my main focus
<asterite>
that’s why I also think it’s good to have like, one LinkedList in the std, so everyone uses that one and we don’t end up with twenty of them
<asterite>
we want to do something like Elixir’s package management, where you can point to github
<asterite>
but… there are so many things to do :-P
<jhass>
exactly, so don't hold up with making stdlib big, let other people do that
<jhass>
if there's a central index there can be a linked_list package and people will use that
<asterite>
that’s true
<jhass>
it just needs to be discoverable, it doesn't need to ship with crystal
<asterite>
but if it comes with crystal then you’d do `require “linked_list”` and that’s all
<asterite>
you don’t need to install anything else
<jhass>
you can always move things everybody uses in every project into crystal at a later point
<asterite>
that’s also true :)
<asterite>
I think in ruby there’s proliferation because you always have the choice to do it in ruby or in C
<jhass>
maybe ship something like rubys bundler with crystal
alex-guenther has joined #crystal-lang
<jhass>
mmh, I should start porting rake, just to make it'll be called cake
<jhass>
*make sure. My typing skills are really off today
<asterite>
:)
CraigBuchek has joined #crystal-lang
<alex-guenther>
hi
<asterite>
hi
<alex-guenther>
asterite: I'm trying to get a sqlite3 wrapper running, right now it's possible to open/close the database and execute a query but no prepared statements or such. I ponder what would be the best way to contribute/publish my code...
<asterite>
(but that will also interpolate, just not right now)
<jhass>
(nvm that macro stuff, a module should have a name m( )
<jhass>
'silly\csv\using\as\separator' vs "silly\\csv\\using\\as\\separator"
<jhass>
okay contrived. my main point is that there's basically no high level language with character literals
<jhass>
and that's because you only need them when you interface with low level stuff
<asterite>
Java? :)
<asterite>
Rust?
<asterite>
Probably Nimrod too
<asterite>
Also Go
<asterite>
I think a Char is something important and already has ‘…’ in many other languages
<asterite>
Ruby, Python and Javascript make the exception
<asterite>
but many more have ‘…’ as char
<asterite>
specially because char is more performant and makes sense
<jhass>
symbols replace half that performance use cases though
<jhass>
anyway, I expected that answer, was worth a try ;)
<asterite>
:D
<jhass>
hm, if I define a macro inside a module, how do I call it?
<jhass>
ah, macro self.name helps
<asterite>
if you include that module, maybe it works (I never tried it)
<jhass>
is there already an included hook?
<asterite>
nope
<jhass>
I've seen private commented too, so method visibility isn't there yet too I guess?
e_dub has joined #crystal-lang
<asterite>
not yet
<jhass>
hm, what's the lookup path for require? dirname(filename):working_directory:$CRYSTAL_PATH ?
<asterite>
it’s /src relative to the script you are compiling, and libs
<asterite>
check bin/crystal, line 77
<jhass>
so it doesn't add anything?
<asterite>
nope
<asterite>
you mean, adding to the lookup path
<asterite>
?
<jhass>
yes
<asterite>
no, nothing gets added to the lookup path
<asterite>
but you can do relative requires
<jhass>
I'm toying around how realizing a Cakefile could work, so I came up with changing the prelude. So I added libs/cake/prelude.cr doing require 'prelude'; require 'cake' and it doesn't find things that should come from the main prelude, if I name it cake_prelude it works
<asterite>
require ‘cake’ would look for cake.cr or cake/cake.cr
<jhass>
sure, and that one doesn't fail
<jhass>
I guess your require caches, just like rubys?
<jhass>
if so, what's the cache key? full path to file or just name?
<asterite>
full path
<CraigBuchek>
Regarding single quotes, I don't find them too useful for characters. A character is just a single-character string, really.
<CraigBuchek>
I've been thinking that they'd be good for denoting symbols.
<CraigBuchek>
So 'this' and 'that' would be symbols. And you could leave off the quotes when using them in hash literals: this: 1, that: 2 would be equivalent to 'this': 1, 'that': 2.
<CraigBuchek>
The nice thing about this is that in a lot of ways, you can treat them as string-like things.
<CraigBuchek>
And we already frequently to_s symbols and to_sym strings.