<FromGitter>
<3n-k1> ran into a weird issue ⏎ ⏎ ``` code paste, see link``` ⏎ ⏎ the dlopen call is returning a null pointer, but the code runs perfectly and exits with a 0 exit code. what's up with that? [https://gitter.im/crystal-lang/crystal?at=5ffb9cb181c55b09c7fd69a7]
<FromGitter>
<3n-k1> like, how is the null pointer working perfectly fine in the call to dlsym?
sagax has quit [Quit: Konversation terminated!]
HumanG33k has quit [Ping timeout: 260 seconds]
HumanG33k has joined #crystal-lang
<FromGitter>
<asterite> Probably passing a null pointer to dlsym is valid. I see two special values can be passed, maybe one of them is the null pointer. Check man
HumanG33k has quit [Remote host closed the connection]
HumanG33k has joined #crystal-lang
<FromGitter>
<3n-k1> passing in an explicit null pointer has the same effect. my only guess is that it's an undocumented feature
<FromGitter>
<3n-k1> which now brings up the interesting question of "why is dlopen returning null?"
<FromGitter>
<3n-k1> beacuse my libm file is a linker script, not a shared library ⏎ okay then
<FromGitter>
<Blacksmoke16> > If dlopen() fails for any reason, it returns NULL.
alexherbo2 has quit [Ping timeout: 240 seconds]
<FromGitter>
<3n-k1> why is dlopen failing*
deavmi has quit [Ping timeout: 272 seconds]
deavmi has joined #crystal-lang
yxhuvud has quit [Remote host closed the connection]
yxhuvud has joined #crystal-lang
<FromGitter>
<naqvis> if an attempt to `dlopen` fails, it will return `NULL`. You should check the reason by invoking `dlerror`
<FromGitter>
<naqvis> > If filename is NULL, then the returned handle is for the main program. If filename contains a slash ("/"), then it is interpreted as a (relative or absolute) pathname. Otherwise, the dynamic linker searches for the object as follows (see ld.so(8) for further details):
<FromGitter>
<naqvis> you better do `libm = LibC.dlopen("libm.so", LibC::RTLD_LAZY)` on linux systems ⏎ or ⏎ `libm = LibC.dlopen("libm.dylib", LibC::RTLD_LAZY)` on mac
_ht has joined #crystal-lang
<FromGitter>
<3n-k1> > you better do `libm = LibC.dlopen("libm.so", LibC::RTLD_LAZY)` on linux systems ⏎ > or ⏎ > `libm = LibC.dlopen("libm.dylib", LibC::RTLD_LAZY)` on mac ⏎ ⏎ libm.so is not a valid elf in gcc and so dlopen returns null [https://gitter.im/crystal-lang/crystal?at=5ffc08379632f63d870d168d]
ua_ has quit [Ping timeout: 265 seconds]
ua has joined #crystal-lang
alexherbo2 has joined #crystal-lang
Volk has joined #crystal-lang
<FromGitter>
<Ashvith> Hello folks
<FromGitter>
<Blacksmoke16> o/
<FromGitter>
<Ashvith> I was wondering if this is the right place to ask, but I was thinking of participating in GSOC...
<FromGitter>
<Ashvith> To be honest, I don't have much experience with Crystal, but I've done Ruby before...
<FromGitter>
<Ashvith> How about Crystal for Windows?
<FromGitter>
<Ashvith> Or maybe ML gems for Crystal?
<straight-shoota>
yeah, there's a lot to be done on that field ;)
<straight-shoota>
or both
<FromGitter>
<Ashvith> Under <off-topic> or <crystal-contrib>?
<FromGitter>
<Ashvith> > *<straight-shoota>* yeah, there's a lot to be done on that field ;) ⏎ ⏎ I have experienced Railsinstaller before, and that was not a pleasant experience
<straight-shoota>
crystal contrib
<FromGitter>
<Ashvith> > *<straight-shoota>* crystal contrib ⏎ ⏎ Thanks a lot mate!
<FromGitter>
<Ashvith> Hmm, seems to me that the forum does not have a reply button? Am I missing something? It looks similar to the Discourse forum actually...
<straight-shoota>
it is discourse
<straight-shoota>
an there should be reply buttons
<FromGitter>
<Ashvith> Umm, there seems to be a "problem" with the forum
<FromGitter>
<Ashvith> But I finally got the workaround for it
<FromGitter>
<Blacksmoke16> iirc someone else had a problem like that
<FromGitter>
<Ashvith> There is no login button, so I had to go to a random post and press on reply
<FromGitter>
<Ashvith> then I was able to use my GitHub acc
<straight-shoota>
ah, I guess that's that stupid custom header which has been broken for a long time
<repo>
@RX14: since you're the maintainer of pub-relay, do you have a list of public relay servers by any chance?
<FromGitter>
<Ashvith> Hmmm, wow, so maybe this counts as bug contribution lol?
<FromGitter>
<Ashvith> Anyways, I have to deal with a long, exhausting exam, so I'll see you folks soon, after a week, and maybe we can talk more on the GSOC thingy?
<FromGitter>
<Blacksmoke16> 👍 gl
<FromGitter>
<Daniel-Worrall> shame it's aimed at students, I'd love a crystal lib mentor :D
<Stephie>
repo, that project's dead
deavmi has quit [Ping timeout: 272 seconds]
deavmi has joined #crystal-lang
<straight-shoota>
@Daniel-Worrall Maybe a mentor program could be initiated in the Crystal community independent of outside initiatives like GSOC
<FromGitter>
<RespiteSage> Is all Crystal I/O ultimately implemented through bindings? I've been thinking through what would be required for a Crystal static security analyzer for dependencies (basically, generating a report for each dependency about redefinitions, filesystem accesses, network accesses, etc.), and I thought maybe it could process the LLVM IR, but it seems like the IR doesn't deal directly with I/O.
<FromGitter>
<RespiteSage> If the static security analyzer idea is infeasible or unwise somehow, I'm also interested to know how.
<straight-shoota>
yes, IO is handled by libc
<FromGitter>
<RespiteSage> Thanks!
<straight-shoota>
@RespiteSage maybe you could talk to @bararchy, he's doing security analysis with Crystal
ua has quit [Ping timeout: 264 seconds]
<FromGitter>
<RespiteSage> Oh, cool. Thanks for the recommendation! I honestly know very little about security, but it's concerning to me that Crystal (just like, it seems, most language ecosystems) doesn't really have any tools for dependency security analysis.
<FromGitter>
<RespiteSage> Obviously, other kinds of security analysis are also crucial, but I'm not as interested in that side of things.
<FromGitter>
<RespiteSage> Or, rather, I'm specifically interested in this one part.
ua has joined #crystal-lang
alexherbo2 has quit [Ping timeout: 240 seconds]
alexherbo2 has joined #crystal-lang
Volk has quit [Quit: See you next time!]
<FromGitter>
<jrei:matrix.org> when using websockets, better using bytes if I own the server and the client
<FromGitter>
<jrei:matrix.org> By bytes I mean a byteformat, vs sending JSON strings for instance
<straight-shoota>
as always, depends on what you're doing
Volk has joined #crystal-lang
<FromGitter>
<jrei:matrix.org> not really
<straight-shoota>
okay, then just use what's always best
<FromGitter>
<jrei:matrix.org> excluding the very simple cases, overall a byte format will be more efficient
<FromGitter>
<jrei:matrix.org> one point of JSON is it's openness. I made sense for a REST API, so I use it, but I don't see for WebSocket
<FromGitter>
<jrei:matrix.org> also I guess I'll have to use json_discriminator if JSON will be sent/received to a single WS endpoint :/
Volk has quit [Quit: See you next time!]
<FromGitter>
<Sija> oh, what a swoop of pr mergin’ action I see there, nice!
<FromGitter>
<Daniel-Worrall> If you use bytes, then you need to write both the serializing and deserializing code
<FromGitter>
<Sija> there’s already bson, msgpack, not to mention protobuf
<FromGitter>
<jrei:matrix.org> @Daniel-Worrall: that's exactly like JSON. I use a library for this
<FromGitter>
<jrei:matrix.org> I came up with a very simple non-descriptive protocol based on IO::ByteFormat
<FromGitter>
<jrei:matrix.org> The first byte declares the message type, then the following is a list of float, integers and/or strings
_ht has quit [Remote host closed the connection]
o5r has quit [Ping timeout: 260 seconds]
alexherbo2 has quit [Quit: Ping timeout (120 seconds)]
alexherbo2 has joined #crystal-lang
<raz>
oki doki.... so i have a little story to tell...
<raz>
so yesterday my mbp 16" died. it was very sudden. GPU. denial. stages of grief. tears. you know how it goes... :(
<raz>
so today i went out to get a replacement. m1 of course. because who would buy intel anymore.
<raz>
and i was a bit nervous about crystal in emulation and stuff. :X
<raz>
and yea... i kinda expected it to be bad
<raz>
so, well, under emulation, on this 13" mbp m1
<raz>
my compile times are almost half of the i9 ¯\_(ツ)_/¯
<raz>
it's a bit bonkers how fast this thing is. i mean, i expected maybe a bit slower. or much slower. but not faster by such a margin.
<straight-shoota>
that seems really unrealistic
<raz>
it is 7.07 real
<raz>
on my i9 it was 12
<straight-shoota>
warm cache maybe?
<raz>
i kid you not
<raz>
well, perhaps my i9 was dying a little already before it went. but it had no symptoms at all (GPU just zapped out yesterday)
<FromGitter>
<Blacksmoke16> What were the clock speeds for each?
<FromGitter>
<Blacksmoke16> Single core is the main factor in compile times
<raz>
too lazy to look'em up, but was the fastest i9
<raz>
and now is the 8G/512G mbp
<raz>
if you have something small/self-contained i should try compiling
<raz>
happy to do a bench
<raz>
ah i'll try athena
<raz>
time crystal spec = real0m31.523s
<raz>
(on warm cache, 2nd run)
<FromGitter>
<Blacksmoke16> not a great benchmark as there are a few programs being compiled in there
<raz>
as long it does the same on your end, it should be comparable, no?