<FromGitter>
<MatthewBennington> Hi I'm a bit new to Crystal, and was hoping to get help with C binding (sorry if this is the incorrect medium, I'm not familiar with gitter).
<wmoxam>
@MatthewBennington it's fine to ask here, what's the trouble?
DaleK5whr has joined #crystal-lang
DaleK5whr has left #crystal-lang [#crystal-lang]
<FromGitter>
<MatthewBennington> So I'm trying to make an application using ncurses. There are a bunch a shard for it, but I haven't found one which handles ncurses extended characters (stuff like horizontal and vertical lines for making boxes). If you're using ncurses natively, they're available to you (I'm not sure what to call this, because it's not a variable, preprocessor defined keyword?) as "ACS_HLINE" for example. Am I making se
<wmoxam>
hrmm
<wmoxam>
I'm unfamiliar with ncurses ectended chars
<FromGitter>
<MatthewBennington> I guess they're all just UInts under the hood, but I've been fiddling all night to try and figure out a way to get their values, and haven't had any luck
<FromGitter>
<MatthewBennington> Yeah
<wmoxam>
ok, if I'm reading this right, ACS_ULCORNER gets translated to: _nc_acs_map()[(unsigned char)('l')]
<zipR4ND>
I still don't get over the new macro magic look at this combination of module extension and inheritance, it's beautiful : https://play.crystal-lang.org/#/r/1xwv
<FromGitter>
<Sija> FYI calls to `calloc` are nowhere to be found within the crystal codebase
<FromGitter>
<Sija> @zipR4ND: that’s one sweet macro magic example, thx!
<zipR4ND>
yeah, the syntax is pretty clumpsy but I mean as far as I understand we get this with zero runtime penalty and full type safety. I think crystal is very special. If 1.0 is achieved and with concurrency and stability this can really take off I think :excited:
<FromGitter>
<chuckremes> @zipr4nd That is some impressive macro magic. If you don’t mind, I’m going to “steal” some of that for the macro wiki page I’ve been working on.
<FromGitter>
<chuckremes> those techniques look very useful and should be documented.
<zipR4ND>
@chuckremes definitely!
<FromGitter>
<chuckremes> great, thanks! I’ll attribute it to you by your handle unless you want it to be anonymous.
<zipR4ND>
yes thanks, i'd like that :)
<FromGitter>
<chuckremes> you are gonna be famous
<zipR4ND>
haha! I just want to find someone to pay me for doing this all day! hence graphql ..
<FromGitter>
<chuckremes> you and me both :)
<FromGitter>
<chuckremes> gotta run for now. have a good one.
<FromGitter>
<bew> being paid for making crystal code.... I hope that day will come!!!!
<zipR4ND>
I mean a pure ruby dev will still have to fight hard to get to cribs with this stuff (as I do) but once your comfortable with it you already can reach high productivity, I think this is where crystal really beats go and rust, like the ease with which you do TDD from the beginning through specs ..
<zipR4ND>
oh btw. the NamedTuple.merge of course is not by creation ...
<zipR4ND>
is there any particular reason this hasn't entered the stdlib already? it's been around for some time already ..
iTARIS has joined #crystal-lang
bjz has joined #crystal-lang
unshadow has joined #crystal-lang
<unshadow>
I'm trying to check is a socket is alive or not, it seems that .closed? will only return true if you called .close on the socket. Is there another way to check if the socket is alive or not without writing\reading from it ? (I would have used select(nil, nil, [socket]) but it seems that select is broken)
oz has joined #crystal-lang
tliff has quit [Ping timeout: 264 seconds]
tliff has joined #crystal-lang
iTARIS has quit [Read error: Connection reset by peer]
<FromGitter>
<ysbaddaden> @unshadow no, there aren't.
sz0 has joined #crystal-lang
<unshadow>
ysbaddaden: Can't I use libevent or something to test the IO's ?
<FromGitter>
<ysbaddaden> nope
<FromGitter>
<ysbaddaden> there is no way to know whether a socket is opened or closed until you try to write or read from it
<FromGitter>
<bew> I'd say, this is by design
<FromGitter>
<ysbaddaden> yes
<unshadow>
Isn't it an oversight ? If I dont know what a socket is readable\writable I can't so event based socket programming
<unshadow>
even using epool or something similar
<FromGitter>
<ysbaddaden> readable / writable and closed are different matters
<FromGitter>
<ysbaddaden> closed : no way to know, you must try it
<FromGitter>
<ysbaddaden> readable / writable : crystal does the job for you (using libevent), you have *nothing* to do
<FromGitter>
<ysbaddaden> i.e. spawn fibers, have them handle read/write from/to the socket and let crystal switch between fibers
<unshadow>
Hm... this is what I do, but, It just means that the socket status is handled by me again in a higher place where I need to check if socket.read > 0 , else I know there was nothing to read, So Crystal dosn't really handle it for me, It just knows when to switch around Fibers
<unshadow>
If it would really handle it, then I could do something like SocketArray << socket, and SocketArray.each |redable, writable, error| etc... as in, I would have access to socket state or atlest to manipulate my code based on events
<FromGitter>
<bew> you could have a fiber per socket, that reads when available and push the eent to a channel, then use `Channel.select` to do stuff based on which channel is readable or sth like that
<FromGitter>
<ysbaddaden> exactly, spawn fibers and either communicate actions through channels, or just run the action in the fiber when something is received / try to write the response; let them idle until the socket is ready or something happens (EOF, EPIPE, ...)
<FromGitter>
<ysbaddaden> a fiber is so lightweight, you may have thousands of them running or idling with little impact
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<BlaXpirit>
Sija, I don't think I was incorrect. C malloc does not 0, GC.malloc does not 0, Pointer(T).malloc zeroes. whatever..
<FromGitter>
<bew> @BlaXpirit can you link the lines that zeroes ?
<FromGitter>
<bew> I can't find them
<FromGitter>
<bew> it initialize the buffer when using `Pointer(T).malloc(size, value)` but not with `Pointer(T).malloc(size)` or I really don't find where..
<BlaXpirit>
maybe, let me check
<BlaXpirit>
.malloc(size : UInt64)
<BlaXpirit>
Allocates size * sizeof(T) bytes from the system's heap initialized to zero and returns a pointer to the first byte from that memory.
<FromGitter>
<elorest> gave out a couple hundred crystal stickers.
<FromGitter>
<elorest> also went to the helix-rails talk. It’s a gem that makes it pretty easy to write gems in rust. It would be cool if we got something going like that in crystal.
unshadow has joined #crystal-lang
<unshadow>
Is there a way to change {"string" => Slice(UInt8)} into a JSON ?
Dreamer3 has quit [Quit: Computer has gone to sleep.]
<BlaXpirit>
unshadow, JSON does not have a type tha stores arbitrary byte
<BlaXpirit>
unshadow, you can look into producing a base64 string and turn that into json
<zipR4ND1>
hey all, does the method_missing work for class methods?
<RX14>
@elorest that was great
<BlaXpirit>
zipR4ND1, no, and as far as i remember there is no alternative
<RX14>
yeah it's really annoying
<zipR4ND1>
ok ..
<RX14>
i'm pretty sure you can't access context in method_missing either
<RX14>
which is also annoying
<zipR4ND1>
I guess i´ll find another solution then ..
<DissonantGuile>
Sounds like a smell to me
<DissonantGuile>
...which is a sentence that only makes sense in software dev ha
<RX14>
`git bisect run` is great
Raimondi has quit [Write error: Broken pipe]
Raimondi has joined #crystal-lang
pabs_ has joined #crystal-lang
unshadow_ has joined #crystal-lang
livcd_ has joined #crystal-lang
unshadow has quit [Write error: Broken pipe]
livcd has quit [Write error: Broken pipe]
fmcevoy has quit [Write error: Broken pipe]
pabs has quit [Remote host closed the connection]
pabs_ is now known as pabs
unshadow has joined #crystal-lang
unshadow_ has quit [Ping timeout: 255 seconds]
unshadow_ has joined #crystal-lang
<FromGitter>
<elorest> <RX14> Thanks. :)
unshadow has quit [Ping timeout: 252 seconds]
Dreamer3 has joined #crystal-lang
Ven has joined #crystal-lang
Ven is now known as Guest68828
<FromGitter>
<elthariel> Hi gentle people ! Is there anyone here which is aware of or involved with the thread support work in crystal ?
<FromGitter>
<elthariel> I've skimmed through the branch and I'm wondering if it's working yet (as it seems) or not at all
<FromGitter>
<elthariel> @waj, @ggiraldez : ^^^ ?
Dreamer3 has quit [Quit: Leaving...]
<FromGitter>
<MatthewBennington> Can you set default arguments for a function binding to a C lib? Like `fun foo(bar = 0) : Int32`?
<FromGitter>
<Sija> @MatthewBennington nope
<FromGitter>
<chuckremes> @elthariel Check out the single-msqueue branch. It should be semi-working. As far as I can tell it hasn’t been extensively tested. It’s still very much in the experimentation stage.
<FromGitter>
<chuckremes> I am not working on it. There are some folks in channel who might be, but last I heard (yesterday?) is that the person shepherding this branch is on vacation right now.
<FromGitter>
<elthariel> @chuckremes What's the difference between the `single-msqueue` and the `thread-support` branch ?
<FromGitter>
<chuckremes> Run a diff (do a branch comparison on github) to see. Not much is different. It’s mainly (as the name suggests) a single work queue that all threads & fibers pop work from.
<FromGitter>
<elthariel> Yeah sorry. I went to do that :)
<FromGitter>
<chuckremes> no prob :)
<FromGitter>
<chuckremes> @elthariel And now you have exhausted my knowledge on this topic. I am interested in it like you but there’s not a lot of real “news” about it yet.
<FromGitter>
<elthariel> You cought me before I wrote the next questions :D
<FromGitter>
<chuckremes> I anticipated you had more!
<FromGitter>
<mverzilli> I'll work on a mini list of instructions on how to run tests on the single-msqueue and the current challenges
<FromGitter>
<elthariel> I haven't found any issue tracking this, are you aware of any ?
<FromGitter>
<elthariel> @mverzilli Much interested in that. I'd like to start playing with it and I'd appreciate to know where problems are to be expected and what still need to be done
<FromGitter>
<mverzilli> can't promise anything, but I guess during next week we could have something
<FromGitter>
<elthariel> @mverzilli No worries. Do you have a 10 words version of it ?
pduncan has quit [Ping timeout: 245 seconds]
<FromGitter>
<elthariel> Looks like you don't. Thanks for the heads up anyway. Looking forward to read about it
<FromGitter>
<mverzilli> (just a sec, I'm translating sth)
<FromGitter>
<mverzilli> Most of the work is on the branch “thread-support”. There are (almost) all the necessary fixes to support multiple threads in the stdlib. It’s almost usable, but the scheduler isn’t reentrant-safe. The scheduler makes some memory allocations that may trigger GC collection. If the GC collects FileDescriptors, it ends up calling finalize on them, which reschedules their pending readers and writers (if any).
<FromGitter>
... the scheduler reentry happens, which derives in memory allocations, which causes a deadlock in the GC mutex. ⏎ ⏎ For that reason, and in attempt to take step back, work with simpler concepts and reduce complexity, we spend the ‘single-msqueue’ branch. That’s basically a rework of the scheduler. Fundamentally, it ... [https://gitter.im/crystal-lang/crystal?at=59024f13881b89e1019165b8]
<FromGitter>
<mverzilli> (sorry there are a couple of typos there, but for the most part that's it)
<FromGitter>
<mverzilli> again, we need to sit back for a while and think how we can make this testable for the brave ones in the community who want to give it a try, and also clearly articulate what specs we want this to pass, so everyone who wants to help can do so
<FromGitter>
<elthariel> Thank you very much. I'll start by sending a PR to get ConcurrentKit included in homebrew :) and I'll give it a spin.
<Yxhuvud>
Have you looked at stuff like work stealing?
<Yxhuvud>
or is that way too complicated to start with?
<FromGitter>
<elthariel> Yxhuvud: I've seen some code about it in the branch
<FromGitter>
<Sija> @BlaXpirit fair ‘nuff, yet it’s easy to misundestrand C `malloc` which doesn’t zero-out the allocated region with `Pointer.malloc` which does it
<FromGitter>
<mverzilli> yeah, you can see some o that in the thread-support branch
<FromGitter>
<elthariel> @mverzilli I understand that the work so far is (logically) focused on making Fibers multi-thread. Have you heard of any plans to support the more traditional threading model (i.e. integration with C library which won't cooperate with fiber-aware IOs) ?
<FromGitter>
<elthariel> Just by curiosity, I totally get that this is not at all a priority
fmcevoy has joined #crystal-lang
yogg-saron has joined #crystal-lang
<FromGitter>
<mverzilli> nope, no plans in that direction
<FromGitter>
<elthariel> But I assume it shouldn't be that hard after fibers use multiple threads
<FromGitter>
<chuckremes> @elthariel You can bind directly to libpthread and makes many of those calls yourself. How well that integrates with other crystal machinery is sketchy.
Yxhuvud has quit [Remote host closed the connection]
<crystal-gh>
[crystal] orangethunder opened pull request #4346: Small grammar fix in description of Nil#try (master...patch-1) https://git.io/v9Gjp
<FromGitter>
<elthariel> @chuckremes : Yeah, doesn't sound like a great idea :D
<FromGitter>
<mverzilli> do you have any concrete use case in mind?
<FromGitter>
<chuckremes> Heh. Point is you can use condvars and threads from there to communicate with non-crystal code if you really need to do it.
<FromGitter>
<chuckremes> (At least I think this would work. Haven’t written any code to do so.)
<RX14>
@mverzilli Will starting non-scheduled dedicated threads be supported?
<FromGitter>
<elthariel> @mverzilli, I'm writing 'bindings' for libenet, a small C library which implements reliable UDP. They're using `select` to multiplex IOs, so fibers won't work
<FromGitter>
<mverzilli> @elthariel I guess once we support multithreading it wouldn't make much sense to bind to a lib like libenet, it'd be much more appropriate to write something in crystal
<FromGitter>
<mverzilli> @RX14 I don't know :). I'll check with the team and get back to you on that one.
<RX14>
it would pretty much cover @elthariel's usecase i think
<RX14>
because you could just start up a thread and communicate with it using channels
<RX14>
and use the C library threaded from that
<FromGitter>
<elthariel> @mverzilli, I don't really care about the way they multiplex their IOs, I just don't want to rewrite their protocol :)
<FromGitter>
<elthariel> But yeah, it'd be better to have something written in crystal but that's quite some work + the competing standards thing
<Papierkorb>
it's not competing if you're implementing the protocol
<FromGitter>
<elthariel> Hum, it's not exactly documented
<FromGitter>
<elthariel> But I read ya
<FromGitter>
<elthariel> But yeah, my initial plan was to work on a small game for fun, and it's turning into re-implement the world -_-
<FromGitter>
<mverzilli> can't say I'm surprised. an year or so ago I sat to start Stanford's Deep Learning course (http://ufldl.stanford.edu/tutorial/). When I got to the first exercise (in Matlab), I thought "it would be cool to do this in Crystal", then I realized I had to bind to Lapack and Blas for that, then I wrote https://github.com/mverzilli/crystalla, and never moved past the first exercise :P
Guest68828 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<FromGitter>
<mverzilli> yak shaving FTW
<FromGitter>
<elthariel> @mverzilli Unrelated I used to leave in Oak's Creek residence, just behind Standford's golf course :)
<FromGitter>
<elthariel> But yeah, I'm already running down the rabbit hole, and I don't feel like forking into another nested rabbit hole
<FromGitter>
<MatthewBennington> Quick question: I'm binding to a c library, and I want to tell a function to print the character `─`. The function doesn't like it when given the character though, so I have to set a `unsigned char c = 4194417` instead of `unsigned char c = '─'`. When binding the function, should I have the parameter as a Int and give it 4194417, or should I make it a Char and give it `4194417.chr`?
<FromGitter>
<MatthewBennington> Does that question even make sense?
<FromGitter>
<elthariel> @MatthewBennington : The maximum value for an unsigned char is 255. So `unsigned char c = 4194417` is going to overflow
<FromGitter>
<elthariel> If you're trying to send a non-ASCII character to C, you have to read about UTF-8
<FromGitter>
<elthariel> Those are multi-bytes characters and as such cannot be stored in a single byte (`char`). You'd have to use a string (an array of `char`)
<RX14>
and if there's no way to send a char*, you're stuck
<FromGitter>
<elthariel> If you have control over the C code, just use a char*
<FromGitter>
<MatthewBennington> I don't have control over the c code
<FromGitter>
<elthariel> If it doesn't support UTF-8, you're ~~fucked~~ stuck
<FromGitter>
<MatthewBennington> Well that sucks
bjz has joined #crystal-lang
<FromGitter>
<elthariel> You could actually try to split the multibyte character into many char, and call the method a few times
<BlaXpirit>
MatthewBennington, please explain more. there's no way that the C function accepts unsigned char and passing 4194417 works
<BlaXpirit>
i mean, a sane library would accept an UInt32 and that would be good
<FromGitter>
<elthariel> Depending on the implementation, buffering at some stage might make it work
<FromGitter>
<MatthewBennington> The specific function it ncurses' `mvwhline`
<FromGitter>
<elthariel> Hum, using ASCII-only isn't *insane*
<BlaXpirit>
type chtype = int
<FromGitter>
<MatthewBennington> declared as: `int mvwhline(WINDOW *, int y, int x, chtype ch, int n);`
<FromGitter>
<MatthewBennington> I don't know enough c to understand that
<BlaXpirit>
MatthewBennington, chtype is a 32-bit unsigned integer, not a char like you assumed
<RX14>
it's a LibC::UInt
<BlaXpirit>
which on platforms supported by crystal is always a 32-bit unsigned integer
<FromGitter>
<elthariel> Fair but not super future proof ^^
<RX14>
except I always like to use the LibC types in this kind of code
<BlaXpirit>
sure
<RX14>
you'll never know when crystal will be ported to insane DSPs with 256bit words
<FromGitter>
<elthariel> I mean, I totally agree on using the LibC types
Raimondi has quit [Ping timeout: 260 seconds]
Raimondii is now known as Raimondi
<BlaXpirit>
int is pretty much stuck at 32 bits at this point
<BlaXpirit>
it's not like we dont have machines with 64 bit words
<FromGitter>
<elthariel> Maybe one day we'll get tired of `long long long long verylong int` :D
<FromGitter>
<elthariel> Just ignore this comment
<BlaXpirit>
MatthewBennington, so.. you can bind that as LibC::UInt and pass '-'.chr to it
<BlaXpirit>
pass '─'.ord to it, i mean
<FromGitter>
<MatthewBennington> I don't think '─'.ord would produce the right value
<RX14>
it very likely won't
<FromGitter>
<MatthewBennington> I am not 100% sure it won't
<RX14>
curses predates unicode by a long way
<BlaXpirit>
MatthewBennington, so then what did you do to find the value 4194417
<BlaXpirit>
it's not utf-8 either
<FromGitter>
<MatthewBennington> All the non-ascii character you need for ncurses are defined as ints by the preprocessor (to the best of my knowledge). So I did `int i = ACS_HLINE; std::cout << i;`
<BlaXpirit>
MatthewBennington, ok fine, so you need to copy those definitions of ACS_* to crystal code and use them.
<BlaXpirit>
why is curses unsearchable
<BlaXpirit>
i found ocaml, c# but not the original
<FromGitter>
<MatthewBennington> I can't tell that that is, it looks to me like you are setting the type of ch to ACS_HLINE?
<BlaXpirit>
MatthewBennington, crystal allows optionally explicitly specifying names of arguments
<BlaXpirit>
i'm saying that you should pass ACS_HLINE as the ch argument
<BlaXpirit>
but just saying `mvwhline(........, ACS_HLINE, ....)` wuld not convey that
<BlaXpirit>
where `ACS_HLINE = 4194417`
<FromGitter>
<MatthewBennington> Is this a `def` of a `fun`?
<BlaXpirit>
fun
<BlaXpirit>
ugh i made too many imprecisions, this is not enough to get by for a beginner
unshadow has joined #crystal-lang
<BlaXpirit>
`lib Curses; alias Chtype = UInt; ACS_HLINE = 4194417; fun mvwhline(Window*, y: Int, x: Int, ch : Chtype, n : Int)`; `Curses.mvwhline(some_window, some_y, some_x, Curses::ACS_HLINE, some_n)`
<BlaXpirit>
there we go
<BlaXpirit>
still wrong but we're getting there
unshadow_ has quit [Ping timeout: 240 seconds]
<FromGitter>
<MatthewBennington> Okay, I follow now. And if you want to pass a normal char you just have to cal `.ord`?
<BlaXpirit>
MatthewBennington, I think so. if that's how curses works, anyway.
<BlaXpirit>
where in C you would write 'x' in crystal you would write 'x'.ord, yes
<BlaXpirit>
but of course non-ascii will not work, like in C
<FromGitter>
<MatthewBennington> In my experience it's been able to understand acsii characters passed to it
<FromGitter>
<MatthewBennington> But okay
<FromGitter>
<MatthewBennington> I think I'll wrap it in a method to convert ACS characters to their values, and ascii characters to their values, does that make sense?
<BlaXpirit>
MatthewBennington, sure, great!
<FromGitter>
<MatthewBennington> Thanks a lot!
<BlaXpirit>
i mean that's a lot of wrapping to do if you want to make this mess usable in crystal
<BlaXpirit>
keep in mind that `fun`s are not suposed to be used by normal code. library makers alwawys wrap those in `def`s
<BlaXpirit>
"always" is an overstatement..
kubaxvx__ has joined #crystal-lang
kubaxvx_ has quit [Read error: Connection reset by peer]
<Papierkorb>
In other words, it's considered good style to crystalize the libraries API, even if that only means adding OOP semantics to some extend
[spoiler] has quit [Ping timeout: 240 seconds]
mjblack- has joined #crystal-lang
mjblack has quit [Ping timeout: 240 seconds]
mjblack- is now known as mjblack
[spoiler] has joined #crystal-lang
kellabyte has quit [Read error: Connection reset by peer]
twisterghost has quit [Ping timeout: 240 seconds]
Majost has quit [Ping timeout: 240 seconds]
mroth has quit [Ping timeout: 240 seconds]
DeBot has quit [Ping timeout: 240 seconds]
<FromGitter>
<elthariel> +1
kellabyte has joined #crystal-lang
twisterghost has joined #crystal-lang
Majost has joined #crystal-lang
mroth has joined #crystal-lang
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
sz0 has quit [Quit: Connection closed for inactivity]