The Crystal programming language | http://crystal-lang.org | Fund Crystal's development: http://is.gd/X7PRtI | Docs: http://crystal-lang.org/docs/ | API: http://crystal-lang.org/api/
but putting it in a macro doesn't work either, probably because of the order compilation and type inference happen in at compile time
take a look here https://play.crystal-lang.org/#/r/627q
and then reread over the type inference rules
so you could do
Klass.new [1, 2, 3] and Klass.new
that's the duped array trying to come
then, add the second initializer, boom: https://play.crystal-lang.org/#/r/628j
But with your first one, you could do https://play.crystal-lang.org/#/r/628k
and @dscottboggs_gitlab ty too. i think i'm getting it now
Hi, I made a more detailed forum post with my c-binding proc problem from yesterday, if anyone has some time to take a look and give me some suggestions, that would be great :)
https://forum.crystal-lang.org/t/help-c-binding-of-function-that-takes-callback/325
https://forum.crystal-lang.org/t/help-c-binding-of-function-that-takes-callback/325
Haha :) If i read this correctly the ruby bindings neatly sidestep the issue: https://github.com/WiringPi/WiringPi-Ruby/blob/master/lib/wiringpi/event.rb
by polling :)
by polling :)
@mavu ^
the signal handling code is 'a bit' complex though
on a sidenote, if I ever invent a programming language I shall name it "gmahbld", because that word yields exactly 3 hits on google and will make searching stuff much easier without constantly having esoteric articles or things about chemistry in my results.
from crystal signal.cr :
module Crystal::Signal
The number of libc functions that can be called safely from a signal(2)
handler is very limited. An usual safe solution is to use a pipe(2) and
just write the signal to the file descriptor and nothing more. A loop in
the main program is responsible for reading the signals back from the
pipe(2) and handle the signal there.
module Crystal::Signal
The number of libc functions that can be called safely from a signal(2)
handler is very limited. An usual safe solution is to use a pipe(2) and
just write the signal to the file descriptor and nothing more. A loop in
the main program is responsible for reading the signals back from the
pipe(2) and handle the signal there.
Apparently the "loop to read variable" idea is not too far off the way signals are handled.
Thats a great point.
If I do the same thing, write to a pipe instead of a global variable, I can to the same and wait for IO. That sounds promising!
now just need to cut off the .txt of the file names
puts file_name.chomp(".txt") :heartpulse: me some chomp
I find
chomp(String | Char) confusing, this duplicates .chomp.rchop(String | Char)
I'm opening an issue on this
the internal code is also duplicated from rchop :/
chomp is an alias?
if you use the parameter
i guess it removes last character, not carriage