16:44 <emilbayes> I find it a bit confusing what the idiomatic "byte" array is in pony. Is it String or Array[U8] or something else?

16:47 <jemc> emilbayes: you're not the only one - this is still a UX point that we want to work on

16:47 <jemc> I personally tend to use String for everything that *could* contain something that I want to print

16:48 <emilbayes> jemc: What's the overhead of String vs. Array[U8]?

16:49 <emilbayes> What if you know the size in advance and it is constant?

16:49 <emilbayes> jemc: I'm actually working on sodium again, and find the string type a bit awkward in the case of keys

16:49 <jemc> emilbayes: the performance overhead should be pretty much identical for all operations shared between the two types

16:50 <jemc> neither String nor Array provide any useful features for cases where the size of the buffer is constant, unfortunately - this would require the "dependent types" feature that Luke Cheeseman is working on to be finished

16:51 <emilbayes> jemc: Ah ok

16:51 <jemc> in general in Pony, without dependent types we can't have any types that are "aware of" values, like a constant-size buffer

16:51 <emilbayes> jemc: Which type would be more correct - if even possible - for the guarded heap allocations feature that sodium has? https://download.libsodium.org/doc/helpers/memory_management.html

16:52 <emilbayes> jemc: Ah ok, I don't mean for it to be enforced by the type checker. I just meant that I could declare that I know the size

16:53 <jemc> regarding guarded heap allocs: you're just wanting to use them for byte buffers, right? not to allocate arbitrary Pony objects in the guarded heap?

16:53 <emilbayes> jemc: Yeah, just for keys

16:53 <emilbayes> so byte arrays / buffers yeah :)

16:54 <jemc> regarding declaring a String or Array that you know the size of ahead of time: the constructors for both String and Array allow you to specify the expected number of bytes, and it will preallocate (some number at least as high as) that many bytes

16:56 <emilbayes> jemc: Oh, that sounds good. I should read the stdlib for the two before asking more questions

16:57 <jemc> going back to guarded heap allocs: it would be fairly simple to call `sodium_malloc`, then pass it into a new String (or Array[U8]) with `String.from_cpointer`

16:57 <emilbayes> jemc: Ah, nice. How do I pevent pony from attempting to resize?

16:58 <jemc> the problem is that you'd have to explicitly call `sodium_free` as well

16:58 <jemc> so I'd recommend something like making a new wrapper class

16:58 <emilbayes> jemc: Yeah ok. There's no destructor / gc hooks?

16:58 <emilbayes> jemc: Oh yeah, I think it should be explicit that you're doing something fancy

16:59 <emilbayes> Because it also takes up a couple of pages of memory

16:59 <jemc> there is a hook, but you have to define it on the class that's being destroyed, and you can't define it on String

16:59 <emilbayes> jemc: Makes sense

16:59 <jemc> something like:

16:59 <jemc> (give me a sec to whip something up in a text editor)

16:59 <emilbayes> hehe kk!

17:04 <jemc> http://pony-playpen.lietar.net/?gist=fa434a8b019426714f166d862df77eac

17:05 <jemc> is this something you were thinking about doing a PR to my pony-sodium package on github?

17:05 <jemc> because I definitely like the idea

17:06 <emilbayes> Yes!

17:06 <jemc> note that by using a wrapper class, this also gives you the chance to "protect" the underlying array from being resized inadvertently

17:06 <emilbayes> jemc: For now I'm just doing my own small bindings for a small project (being inexperience with pony and all)

17:06 <emilbayes> jemc: Yes ok!

17:07 <jemc> you can also provide convenience methods to convert to/from array and string

17:07 <emilbayes> jemc: So there are a couple of things I thought I didn't like about how pony-sodium is currently structured, but maybe you can give some feedback on my ideas :)

17:08 <emilbayes> jemc: I thought the String types everywhere should be Seq[U8], but that doesn't make a difference, right?

17:11 <jemc> the problem with that is, some places are creating new Strings, and you can't call a constructor on a trait or interface

17:11 <jemc> however, we could adapt it to use type parameters - are you familiar with those yet?

17:11 <emilbayes> jemc: No not yet

17:11 <emilbayes> jemc: I should look it up

17:15 <jemc> so, to take the example of `CryptoHash`, we'd convert `primitive CryptoHash` to something like `primitive CryptoHash[A: Seq[U8] iso = String iso]`, then replace all uses of `String` with `A`

17:16 <jemc> it's probably going to be a bit more complicated to get the rcaps right, but the gist is that we'd make it generic, where you can pass in a different kind of `Seq` if you wish

17:16 <emilbayes> jemc: Oh, so how do I read that? CryptoHash is generic on A where A is ... what?

17:16 <jemc> A is the type of Seq that you want to using

17:16 <jemc> s/using/use/

17:16 <emilbayes> jemc: How do I read `Seq[U8] iso = String iso`?

17:17 <jemc> the general format for type params is pretty much the same as it is for normal params - `Name: Constraint` for a "normal" type param, and `Name: Constraint = Default` for an optional type param

17:18 <jemc> so, `A` is the parameter, `Seq[U8]` is the constraint, and `String` is the default

17:18 <emilbayes> So is String a type of Seq[U8]?

17:18 <jemc> gotta go, but I'll read the channel log when I get back if you have any more questions

17:18 <emilbayes> structurally or via inheritance?

17:19 <jemc> emilbayes: yeah, structurally

17:19 <emilbayes> jemc: Ok! thanks for all the help

17:19 <emilbayes> jemc: Will do a PR later with pwhash :)