<achamb3rs>
Hi there, anyone tried to build pony on openbsd?
<achamb3rs>
I gave it a try using the llvm400 branch but hit some problems about thread local storage.
<SeanTAllen>
achamb3rs: not that i am aware of
<SeanTAllen>
achamb3rs: we dont currently support llvm4.0, there's ongoing work for that. you'd need to use 3.9.x
<SeanTAllen>
64-bit FreeBSD should work, so I think OpenBSD should be reasonable. Note that we dont have CI for BSDs so its best effort on our part not to break it.
<SeanTAllen>
If you find issues building with 3.9.x on OpenBSD and would be up for opening PR to fix, let me know. I'm happy to try and help point you in the correct direction to fix issues you find.
<achamb3rs>
Thank you, I think you guys have done a great job so far.
<SeanTAllen>
Thank you. Its a volunteer project but lots of us have put a lot of time in. Kind words help motivate us.
<achamb3rs>
I read everything online, one issue potentially
<achamb3rs>
does Pony have finalizers now?
<achamb3rs>
I think in one location in the docs I read it does, but in another place it says a weakness of pony is there are no finalizers so you must be careful with c ffi
<achamb3rs>
I'll try find the precise locations.
<Praetonus>
There are finalisers, you can define one by defining a `fun _final()` method on a type
<SeanTAllen>
that because an actor isn't GC'd immediately, you can expect...
<SeanTAllen>
but i am guessing.
<SeanTAllen>
we should update that.
<achamb3rs>
Yeah, i understood it to mean you can't guarantee when memory will be freed. But the one sentence about there being no finalizers is wrong.
<jemc>
also, we should consistently use the "british" spelling for "finaliser", since Pony uses the "british" spellings everywhere else
<achamb3rs>
:)
<achamb3rs>
I can submit a PR.
<jemc>
that would be awesome, thanks!
<SeanTAllen>
thank you achamb3rs
Praetonus has quit [Quit: Leaving]
silverjam has joined #ponylang
silverjam has quit [Remote host closed the connection]
<achamb3rs>
One observation, it seems like a large part of writing pony is writing state machines by hand, would you say that is accurate?
<jemc>
achamb3rs: I think that's not necessarily true in general
<jemc>
it depends on what you're doing and what approach you're using - if you're hitting pain points with your current approach there may be some other approach you can try
<SeanTAllen>
achamb3rs: we have some of that in our code base and we are working on patterns for it but i wouldn't say a large part is by hand.
<SeanTAllen>
i'd be interested in hearing what you problems you are solving with your and how you are going about it that has lead to that statement. maybe we can suggest alternatives or maybe there's a pain point there that we should be looking for solutions to.
<achamb3rs>
I am just trying to imagine how I would write protocol parsers. I'm coming from Go mainly.
<achamb3rs>
my current application is just an sftp server
<jemc>
ah, well, if your domain is protocol parsers, than yeah, you'll end up writing some state machines in the process :)
<jemc>
depending on what protocol you're working with you could try doing something generated from a grammar, but yeah, I'd expect most protocol parsers to be written by hand by default
<achamb3rs>
thats a cool idea, reminds me of what bearssl does. (run protocol parsing in a mini interpreter you can step)
<achamb3rs>
I will try to avoid speculating too much. thanks again
<jemc>
I've played with state machines a little bit in pony and the mini interpreter pattern sounds like a nice way to go
<jemc>
one of the patterns I've used with some success is having a `primitive` representing each "state" in the machine, having an `apply` function that handles input during that state
<jemc>
where the first argument to that `apply` function is a "stateful object" that is being executed over
<jemc>
to transition states, the currently executing state does `object.state = StateSomeOther`, where `StateSomeOther` is some other state
<jemc>
I'd definitely be interested to see what you come up with, and feel free to ask questions around here if you run into a corner
<achamb3rs>
Will do, still just evaluating and learning. Pony seems like the sort of language that is a great secret weapon if it matches your problem well
<SeanTAllen>
It's been a huge leg up for us achamb3rs. Qcon is releasing my talk on that subject in about 2 weeks.
silverjam has joined #ponylang
<achamb3rs>
I will watch it, i really enjoy those talks.
silverjam has quit [Client Quit]
DDR has quit [K-Lined]
achamb3rs has quit [K-Lined]
aturley has quit [K-Lined]
bimawa has quit [K-Lined]
dom96 has quit [K-Lined]
atk has quit [K-Lined]
mdcox has quit [K-Lined]
lisael has quit [K-Lined]
obadz has quit [K-Lined]
jemc has quit [K-Lined]
kempe has quit [K-Lined]
inara has quit [K-Lined]
jmiven has quit [K-Lined]
bodie_ has quit [K-Lined]
kajstrom has quit [K-Lined]
yggdr has quit [K-Lined]
Xe has quit [K-Lined]
mabi has quit [K-Lined]
catern has quit [K-Lined]
ohir has quit [K-Lined]
CcxWrk has quit [K-Lined]
shepheb has quit [K-Lined]
doublec has quit [K-Lined]
tokenrove has quit [K-Lined]
hakvroot has quit [K-Lined]
Licenser has quit [K-Lined]
abeaumont has quit [K-Lined]
endformationage has quit [K-Lined]
nicolai86 has quit [K-Lined]
tscho has quit [K-Lined]
malthe has quit [K-Lined]
SimonJF has quit [K-Lined]
kempe_ has joined #ponylang
Xe has joined #ponylang
tokenrove has joined #ponylang
Xe has quit [Changing host]
Xe has joined #ponylang
bimawa has joined #ponylang
tscho has joined #ponylang
jemc has joined #ponylang
mindB has quit [Ping timeout: 246 seconds]
irx[m] has quit [Ping timeout: 246 seconds]
atk has joined #ponylang
ada[m] has quit [Ping timeout: 240 seconds]
hakvroot has joined #ponylang
srenatus[m] has quit [Ping timeout: 255 seconds]
M-hrjet has quit [Ping timeout: 255 seconds]
atk has quit [Changing host]
atk has joined #ponylang
dtz has quit [Ping timeout: 255 seconds]
DDR has joined #ponylang
endformationage has joined #ponylang
obadz has joined #ponylang
dom96 has joined #ponylang
lisael1 has joined #ponylang
inara has joined #ponylang
Licenser has joined #ponylang
CcxWrk has joined #ponylang
jmiven has joined #ponylang
yggdr has joined #ponylang
nicolai86 has joined #ponylang
bodie_ has joined #ponylang
srenatus[m] has joined #ponylang
catern has joined #ponylang
irx[m] has joined #ponylang
M-hrjet has joined #ponylang
ada[m] has joined #ponylang
mindB has joined #ponylang
dtz has joined #ponylang
silverjam has joined #ponylang
silverjam has quit [Client Quit]
jemc has quit [Ping timeout: 260 seconds]
tscho has quit [Read error: Connection reset by peer]
tscho has joined #ponylang
abeaumont has joined #ponylang
endformationage has quit [Quit: WeeChat 1.9]
doublec has joined #ponylang
plietar has joined #ponylang
plietar_ has joined #ponylang
plietar has quit [Ping timeout: 240 seconds]
plietar_ has quit [Remote host closed the connection]
plietar has joined #ponylang
plietar has quit [Ping timeout: 248 seconds]
samuell has joined #ponylang
kempe_ is now known as kempe
_andre has joined #ponylang
Praetonus has joined #ponylang
jemc has joined #ponylang
jemc has quit [Ping timeout: 240 seconds]
plietar has joined #ponylang
plietar_ has joined #ponylang
plietar has quit [Ping timeout: 255 seconds]
jemc has joined #ponylang
plietar_ has quit [Remote host closed the connection]
justicefries has left #ponylang [#ponylang]
jemc has quit [Ping timeout: 255 seconds]
endformationage has joined #ponylang
jemc has joined #ponylang
samuell has quit [Remote host closed the connection]
Matthias247 has joined #ponylang
etc has joined #ponylang
<etc>
Hi! Is there any existing tools for matrix multiplication in pony?
<etc>
Are there*
<jemc>
etc: not that I'm aware of
<jemc>
your best bet is to probably make your own primitive that accepts tuples of tuples
<etc>
(thumbsup) no problem - thanks!
<jemc>
btw, I was able to easily build you project on my machine and see the flying shapes - fun!
<etc>
Awesome - good to hear!
<etc>
Do you know how passing tuples into the c ffi works? I was using .cpointer for arrays but I don't see an equivalent for tuples - are they just consecutive memory?
<jemc>
yes, I think passing a tuple to FFI is the equivalent to passing a C struct by value - but I remember there was some change to that area recently, so let me check to see if that's still trie
<jemc>
but yeah, I think it should work to think of them as "consecutive memory", though maybe Praetonus or aturley could speak up and tell me I'm wrong
<etc>
Interesting, yeah it might be that they don't work as structs but could translate to arrays if you take the address of one
<Praetonus>
etc: Long story short, passing struct by value is complex. The C ABI has different ways of representing the parameter depending on the contents of the type
<Praetonus>
The current plan is to use the Clang API to correctly generate struct arguments to FFI calls
<Praetonus>
Unfortunately the relevant Clang APIs will only be publicly exposed in Clang 5 and onwards so we'll have to wait until Pony supports LLVM/Clang 5 before proceeding
<jemc>
Praetonus: any thoughts on treating it like a C array?
<Praetonus>
I forgot to mention that tuples are implemented as a struct value (as opposed to Pony structs which are implemented as struct pointers)
<Praetonus>
jemc: I don't really see what you mean by that
<jemc>
Praetonus: I'm just going off of what etc was asking, but I guess it would be something like `var tuple: (U8, U8, U8) = (1, 2, 3); @memcpy(some_ptr, addressof tuple, 3)`
<jemc>
that is, making the assumption that you can treat it like contiguous memory
<Praetonus>
I think you can do that
<Praetonus>
Though there might be padding between struct members, I think
<Praetonus>
Err, tuple members
<jemc>
right, so you'd want to double-check the rules for struct padding before doing so
<jemc>
etc: hopefully that helps ^
<etc>
That does - thanks! Yeah I'm not sure what will happen with struct padding so I might stick to arrays
<jemc>
etc: what element type would be going in your tuple? F32?
<jemc>
> Storage for the basic C datatypes on an x86 or ARM processor doesn’t normally start at arbitrary byte addresses in memory. Rather, each type except char has an alignment requirement; chars can start on any byte address, but 2-byte shorts must start on an even address, 4-byte ints or floats must start on an address divisible by 4, and 8-byte longs or doubles must start on an address divisible by 8.
<jemc>
> In general, a struct instance will have the alignment of its widest scalar member. Compilers do this as the easiest way to ensure that all the members are self-aligned for fast access.
<jemc>
In general, a brief scan of that page leads me to believe that as long as your tuple is *only* composed of F32s, and you're not mixing in another data type with a different size, you should be okay (at least on x86 and ARM)
<Praetonus>
That seems correct to me
<etc>
Ah that's awesome!
<etc>
Thanks!
<jemc>
another possibly useful bit of info from that website:
<jemc>
> The clang compiler has a -Wpadded option that causes it to generate messages about alignment holes and padding. Some versions also have an undocumented -fdump-record-layouts option that yields more information.
<Praetonus>
That reminds me, we still don't have documentation for the `packed` annotation
<Praetonus>
I should fix that
etc has quit [Ping timeout: 260 seconds]
Matthias247 has quit [Read error: Connection reset by peer]
Guest87549 has joined #ponylang
Guest87549 is now known as achambers
<achambers>
I've seen some references to distributed pony in tickets/talks ~ 1 year old
<achambers>
what is the current status of that?
<jemc>
achambers: basically, it doesn't exist in any meaningful way yet - some planning has been done, and some work has been done that will eventually be a part of that runtime, but no one is currently working on the implementation of it as their main focus