<dos000>
Seems like the error happens during link ^^^ this happened after i did 1) install all the prerequisite listed for ubuntu bionic 2) did a make on the latest git clone of the repo
<jemc>
looking at your paste, I see this message as part of the error output: `relocation R_X86_64_32 against symbol `ponyint_personality_v0' can not be used when making a PIE object; recompile with -fPIC`
<dos000>
I did exactly as that page is saying but i still get that error
<jemc>
to me, that implies that the part you're missing is adding the `default_pic=true` argument to the `make` command
<SeanTAllen>
the installation instructions redirecting to GitHub is intentional so we dont have to maintain it more than one place
jemc has joined #ponylang
_whitelogger has joined #ponylang
a_chou has quit [Remote host closed the connection]
a_chou has joined #ponylang
a_chou has quit [Client Quit]
endformationage has quit [Quit: WeeChat 2.3]
dos000 has quit [Quit: Page closed]
PrsPrsBK has quit [Quit: PrsPrsBK]
PrsPrsBK has joined #ponylang
_whitelogger has joined #ponylang
a-pugachev has joined #ponylang
srenatus has joined #ponylang
PrsPrsBK has quit [Quit: PrsPrsBK]
PrsPrsBK has joined #ponylang
a-pugachev has quit [Quit: a-pugachev]
a-pugachev has joined #ponylang
EEVV has joined #ponylang
<EEVV>
is it not possible to loop through an `Array[U8] iso`?
<EEVV>
for me it says there is an issue with `.values()`: receiver type is not a subtype of target type
<EEVV>
all I want to do is copy the array
<EEVV>
to get a `Array[U8 val] val`
<vaninwagen>
Do you have a playground with an example?
<EEVV>
vaninwagen, no
<EEVV>
the array is input to the received function for TCPConnectionNotify `fun ref received(conn: TCPConnection ref, data: Array[U8] iso, times: USize): Bool`
<vaninwagen>
Can you paste your exact error messages?
<EEVV>
jemc, thanks... I don't know how I missed this
<jemc>
String can be converted back and forth with Array[U8], but yeah, in this case either one will work
<EEVV>
if I was to get a cpointer to an array should I follow some guidelines? As in... What should my capabilities be for the array? `Array[U8] iso`, `Array[U8] ref`, etc...
<jemc>
it depends on what happens to the pointer later - it's safe to grab a pointer anytime, but it becomes potentially unsafe as soon as you use FFI and give that pointer to a library that could do horrible things with it
<jemc>
that is, everything in Pony should be memory safe until it starts interacting with FFI
<jemc>
I don't know off hand how the SSL library uses that pointer, but you as the author of the FFI-using code have to know the lifecycle of that pointer and how it's used across time
<EEVV>
yeah, so it wouldn't be a problem if the library itself can guarantee safety
<jemc>
well, you need to know about how that pointer will be read from and written to across time (and across threads)
<EEVV>
how can I find out what argument types to give for FFI?
<EEVV>
sometimes I don't know if I should give USize, U64, U32
jemc has quit [Ping timeout: 250 seconds]
jemc has joined #ponylang
<jemc>
EEVV: it's a matter of correlating the cross-platform size of that C type to the corresponding cross-platform Pony type
<jemc>
which, yeah, is not necessarily common knowledge for everyone and we could probably use a guide on it
<jemc>
some of them are fairly obvious: `int64_t -> I64`, `uint64_t -> U64`
<jemc>
we also have `ISize`, `USize`, `ILong`, and `ULong` to correspond to signed and unsigned `size_t` and `long` respectively
<jemc>
C `int` is pretty much assumed to always be 32 bits, so: `int -> I32`, `unsigned -> U32`
<EEVV>
jemc, would there be a problem if I, for example, do `int -> USize`?
<jemc>
on some platforms, in some situations, yeah
<jemc>
code situations, that is
<jemc>
`USize` is 64 bits on 64-bit platforms
<jemc>
`int` is 32 bits on every platform that we care about
<jemc>
so that's a safety issue that could result in a segfault depending on where it appears and how it is used
<EEVV>
for me from testing so far I see that `int -> USize` works, but I'm not sure what is happening on the low level exactly
<EEVV>
if C had better type definitions, we wouldn't have this discussion... Alot of C libraries give their own definitions for types
<jemc>
having `int -> USize` work without crashing is just a lucky fluke, even if it is deterministic and never crashes - it's just situational
<jemc>
you should use either `I32` or `U32` for your FFI signature, then convert to `USize` explicitly in Pony-land
<jemc>
(by calling `.usize()` on the result)
<EEVV>
well I'm thinking about it and I think the stack for 64 bit systems would have to be 64 bit aligned, but there may be some cases where maybe you store 2 bytes within 64 bits
<EEVV>
which would break
<jemc>
I personally don't know a lot about C ABI magic, so there may or may not be safe places to use it, but there are definitely unsafe places to
<jemc>
and it's just a philosophical question anyway, because you have a safe alternative available to you (the approach I described above)
<jemc>
an explicitly/guaranteed safe alternative, I mean
<EEVV>
yes
<EEVV>
I am just maybe thinking why it works if I give it a bigger datatype
<EEVV>
also pointers are `USize`? (I am aware that Pointer[T] exists)
<jemc>
yeah, you can bank on the guarantee that the bitwidth of `USize` is the same as the bitwidth of a C pointer, so you can theoretically use `USize` (or `ISize`) as FFI pointers in a pinch
<jemc>
that's sort of the definitional - the "size" in `USize` is basically "size of a pointer"
<EEVV>
jemc, what do you recommend I do for cases where the library only takes in a pointer to a struct (e.g. OpenSSL `RSA*`), I made a `primitive RSAStruct` and did `Pointer[RSAStruct]`. Should I actually make a proper structure?
<EEVV>
*even if I won't use the structure*
<jemc>
if you never "unwrap" the pointer, the `Pointer[<primitive>]` approach should be fine, yeah
<jemc>
I think the stdlib SSL library does something similar, but not sure - I'll look it up