return0e has quit [Remote host closed the connection]
return0e has joined #crystal-lang
<Yxhuvud>
codenoid: the challenge seems very .. specialized to make something work the way julia works, rather than actually trying to solve actual problems within a set of constraints.
<FromGitter>
<codenoid> umm right 😕 , let he do his own challenge
_whitelogger has joined #crystal-lang
<FromGitter>
<bajro17> Can someone review my code I make so simple blockchain program for tutorial purposes its about 50 lines of code
<FromGitter>
<nulty> Oh ok the above example doesn't work. I changed it before posting. ⏎ ⏎ The type arguments to Tuple must match exactly the types of the values in the array supplied. ⏎ ⏎ ```tuple = Tuple(Int32,Int32,Int32).from([1,2,3])``` [https://gitter.im/crystal-lang/crystal?at=5b9e9909b9531f2dfa76f2ac]
<lvmbdv>
tuples are not just immutable arrays like in python
<lvmbdv>
tuples are... well... tuples
<FromGitter>
<nulty> I better understand them now. Is there not facility for Tuple to infer the types of the array elements?
<FromGitter>
<bajro17> @j8r @codenoid @drum445 Thank you all I will publish this on Medium I make few changes. The hardest part now is to make good text with code to people be interested to read it :)
<FromGitter>
<j8r> @bajro17 looking forward the post :)
rohitpaulk has joined #crystal-lang
<FromGitter>
<straight-shoota> @Blacksmoke16 #6314 adds number formatting
JesseH has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 264 seconds]
<FromGitter>
<t-richards> Anyone else having trouble reading the response body of their HTTPS requests? Wondering if this is a "I broke it" problem or a more widespread issue.
<FromGitter>
<t-richards> Looks like this could be a GNU/Linux-specific issue for 0.26.1
<FromGitter>
<mwean> I have a hopefully very basic question about a C binding ⏎ I'm trying to call this function: `int proc_pidinfo(int pid, int flavor, uint64_t arg, void *buffer, int buffersize)` ⏎ I have this declaration: `fun proc_pidinfo(pid : Int8, flavor : Int8, arg : UInt64, buffer : LibC::Char*, size : Int32) : Int8` ⏎ and I'm calling it like this: ⏎ ... [https://gitter.im/c
<FromGitter>
<mwean> if I just use the constant directly, I get `undefined constant PROC_PIDVNODEPATHINFO`
<oprypin>
the thing is, it's useful to understand that C libraries don't usually deal with conventional constants, it's usually macros which cause literal expansion into a literal before compilation
<oprypin>
mwean, so it is what i was talking about, and you have no way to reference such a value because it's not part of any compiled library
<FromGitter>
<mwean> ah, ok
<oprypin>
for the case of macros you just have to hardcode it into your lib
<oprypin>
PROC_PIDVNODEPATHINFO = 9
<FromGitter>
<cfsamson> ty, I learned something new myself!
return0e has quit [Remote host closed the connection]
<oprypin>
mwean, and you probably shouldnt default to marking things as `Int8`, it's a one-byte type. and `int` is usually 4 bytes (`Int32`). best practice is to use `LibC::Int` even though technically it's always equal to `Int32` at the moment
<FromGitter>
<cfsamson> There is two things that might help. 1. It seems that bpi.pvi_cdir is a pointer
<FromGitter>
<mwean> I tried `out` and got `Error in test.cr:68: can't use out with Void* (argument 'buffer' of LibProc.proc_pidinfo is Void*)`
<FromGitter>
<cfsamson> To get the value of a pointer use `vpi.pvi_cdir.value`.....
<FromGitter>
<cfsamson> Sorry, i didn't read the last message
<FromGitter>
<mwean> ok, I tried making that struct field not a pointer
<FromGitter>
<mwean> and now I get `StaticArray[0_u8, 0_u8......`
<FromGitter>
<mwean> so I assume it's just not writing there?
<FromGitter>
<cfsamson> hmmm, I would personally think that `buffer : Void*` should be `out ProcVnodepathinfo` but I might be mistaken
<FromGitter>
<cfsamson> I mean in the LibProc declaration
<FromGitter>
<Timbus> its a void pointer because the function can take and fill multiple struct shapes, it seems. but if you're only using it for this one thing, yeah declare it as a ProcVnodepathinfo*
<FromGitter>
<mwean> getting closer...
<FromGitter>
<mwean> looks like it's now filling in some values
<FromGitter>
<Timbus> are pvi_cdir and rdir supposed to be pointers
<FromGitter>
<cfsamson> I don't have the code here, but it seems like the C code takes a reference to a `struct proc_vnodepathinfo` and "fills" that with data, so you can access it through vpi.pvi_cdir.vip_path or vpi.pvi_cdir.value.vip_path in Crystal. So without declaring that it's a ProcVnodepathinfo its "filling" it you will have a hard time using the data it points to I think. You could maybe cast it as a ProcVnodepathinfo as
<FromGitter>
<mwean> it seems like it's misalligned because I'm getting `StaticArray['\u{88}', 'D', 'R', '\u{10}', '\u{1}', '\u{0}', '\u{0}', '\u{0}', 'G', '\u{0}', 'd', 'Ð', 'n', 'x', '\u{1a}', 'b'.....`
<FromGitter>
<Timbus> probably just need to go over your definitions again, likely
<FromGitter>
<Timbus> -that you set one to the wrong size/type
<FromGitter>
<Timbus> you can always cheat, and make a padded out struct with fields you want to ignore. but that might just get you into more trouble at this point :P
<FromGitter>
<mwean> is `vip_path : LibC::Char[MAXPATHLEN]` correct for `charvip_path[MAXPATHLEN]`?
<FromGitter>
<Timbus> should be..
<FromGitter>
<mwean> I wasn't sure about `uid_t, gid_t, off_t` so I used `UInt32`
<FromGitter>
<mwean> ah!
<FromGitter>
<mwean> success!!
<FromGitter>
<Timbus> cool
<FromGitter>
<cfsamson> GJ
<FromGitter>
<mwean> I was missing `[2]` on a couple types
<FromGitter>
<cfsamson> How did it solve the problem?
<FromGitter>
<mwean> `vst_qspare : Int64[2]`
<FromGitter>
<mwean> it looks like that just fixed the alignment
<FromGitter>
<Timbus> you should point us at the header next time, otherwise we need to guess
<FromGitter>
<cfsamson> Nice
<FromGitter>
<mwean> so now the only weird thing is the value is doubled
<FromGitter>
<mwean> separated by a ton of `'\u{0}'`
<FromGitter>
<cfsamson> There is something with the mapping then, but atleast the problem is scoped down quite a bit