<jemc>
aceluck: we do occasionally have compiler crashes for certain edge cases - often they are invalid forms that should not compile, but they obviously shouldn't crash the compiler either - if you file an issue ticket that shows a minimal reproduction for the issue (or as minimal as you can get it), we can track it in our issue tracker and resolve the issue
<aceluck>
jemc: This line does it: let ev2 = myfun(x, 3, 2, 5) as I64
<aceluck>
The error is not having explicit type on the literal integers
<aceluck>
If I add that, it compiles fine. Wasn't sure if this kind of thing should be reported or not. Where would I file? Github?
<jemc>
the line you showed definitely wouldn't be a crash under normal circumstances, so there must be some other circumstances defining the edge case
<jemc>
in fact, you shouldn't have to specify integer literal types at all when giving them as arguments - they should be inferred from the parameter type
<aceluck>
myfun accepts (I64 | somethingElse) so that might be it
<jemc>
inherently that shouldn't be a problem either, if `SomethingElse` is not an integer literal
<jemc>
but I can take a look when you supply the full compilable code in the ticket
<aceluck>
jemc: Done - included full code
<aceluck>
There's still some irrelevant things there I'm sure, but you'll get the error at least
<jemc>
yes, having a compilable place to start is the most important point - I or someone else can help narrow it down to a more minimal case as part of the investigation
<jemc>
thanks for filing it!
<aceluck>
No problem. Just discovered pony, and it looks to be everything I wanted and them some!
<aceluck>
Thanks for all the good work on it!
<aceluck>
Oh, and this bug is by no means a showstopper so feel free to downprioritize it :)
<jemc>
I definitely had the same feeling when arriving at Pony - it seemed to synthesize the main things I was looking for in a language (actors, reference management, performance, etc)
<jemc>
I personally wasn't very into static type systems when I arrived, but I came to appreciate it over time :)
hakvroot_ has quit [Ping timeout: 258 seconds]
<jemc>
and the static reference capabilities don't really make sense without a static typing system anyway, so I was sort of sold on it by extension
<aceluck>
I just love the type system. Union types, go style interfaces + traits? And a generics system that actually works (I'm looking at you swift)! Fantastic
hakvroot has joined #ponylang
<jemc>
the generics can be a bit tricky to write, when reference capabilities get involved
<aceluck>
I'm mainly working on iOS development now - not sure how easy it is to include there - but arm target is supported right? I could include it as a .o I suppose
<jemc>
though it actually gets a lot easier to write generics if you restrict them to immutable/persistent data types (`val`)
<aceluck>
Yeah, it's tricky - just watched the vug #1 - but still - it's flexible enough to get things to work once you get it right
<aceluck>
I'm coding swift daily, and it just gets confused and gives up if you do something slightly advanced. And without workarounds - you have to manually reify
<jemc>
yes, ARM is treated as supported, though we don't currently have any ARM CI
<aceluck>
CI = ?
<jemc>
continuous integration testing - on GitHub, we run our tests on a CI platform for every commit to master, and every PR before merging
<jemc>
we test on Linux, MacOS, and Windows, against several different versions of LLVM
<aceluck>
Ah
<jemc>
we don't currently have CI testing for ARM (because the major free CI platforms for open source projects don't offer it) so it's conceivable that some bugs could get introduced for ARM and not be noticed
<jemc>
still, we're careful to think about ARM when writing platform-specific code
<jemc>
aceluck: swift has some FFI capabilities, right?
<jemc>
that is, it has some way of calling arbitrary C functions?
<aceluck>
Yes, it's pretty easy
<aceluck>
Although it was easier in pony
<jemc>
if so, you could use the ponyc option to compile your Pony project to a linkable library + C headers instead of a binary
<jemc>
I personally haven't worked much with that workflow, but others in the community have
<aceluck>
Yes, that's what I was thinking. I can't find the right target option though - it says arm not supported for this target (I guess that's osx )
<aceluck>
I'll try first for some macos projects, so at least the target and cpu will be the same, then I'll worry about iOS
<jemc>
also, since swift is an LLVM language, it's conceivable you could find some way to join them at the LLVM IR level, and get whole-program-optimization in LLVM machine code generation, across the swift/pony barrier
<aceluck>
Yes, both swiftc and ponyc have options to dump the llvm ir
<jemc>
yeah
<aceluck>
concat & pray ;)
<jemc>
Praetonus might have some thoughts about how that might work - it seems like something he's probably thought-experimented about before :)
<Praetonus>
I thought a while ago about allowing ponyc to collect LLVM bitcode files in addition to static/dynamic libraries
<aceluck>
I couldn't find in the docs, but can I pass around a class method ? Or do I need to wrap it in a lambda?
<Praetonus>
I didn't find the time to actually toy with an implementation but it could be interesting to try
<Praetonus>
aceluck: You probably want partial application
<aceluck>
Praetonus: Thanks - that solves it exactly
amclain has quit [Quit: Leaving]
amclain has joined #ponylang
autodidaddict has joined #ponylang
<autodidaddict>
Is anyone actively working on a protobuf implementation for Pony? I'd like to play around with a gRPC server in pony
<SeanTAllen>
autodidaddict: someone mentioned doing it but nothing has popped up. Maybe ping the mailing list.
<jemc>
autodidaddict: I do remember others talking about protobuf in pony, but I'm not aware of a finished library
<jemc>
I have a CapnProto library that is in a semi-finished state; I haven't had time to come back to it recently, but is public on github if it gives you any ideas: https://github.com/jemc/pony-capnp
<autodidaddict>
I haven't done much with capnproto, mostly just using protoc to generate protos for my gRPC services. How does capnproto work with gRPC, if at all?
<jemc>
capnproto is an alternative to protobuf, and also has an alternative RPC system - it has some optimizations relating to zero-copy and pipelining that make it mroe attractive to me than protobuf
<jemc>
I just meant you may be able to get some inspiration about the code generation process
aceluck has quit []
endformationage has quit [Quit: WeeChat 1.7]
ajit has joined #ponylang
ajit has quit [Quit: Page closed]
papey_la1 has quit [Ping timeout: 260 seconds]
papey_la1 has joined #ponylang
endformationage has joined #ponylang
papey_la1 has quit [Ping timeout: 248 seconds]
kajstrom_ has quit [Ping timeout: 260 seconds]
kajstrom has joined #ponylang
_andre has quit [Quit: leaving]
<autodidaddict>
hmm... so for gRPC I basically need: a) code to round-trip a byte array in and out of a Pony class, b) code to generate such a class from protobuf IDL, c) an HTTP/2 server d) a layer on top of HTTP/2 that supports the gRPC spec.
<autodidaddict>
^^ no big deal. Shouldn't take more than 10 minutes :P
Matthias247 has joined #ponylang
autodidaddict has quit [Ping timeout: 260 seconds]
<SeanTAllen>
Ha
endformationage has quit [Quit: WeeChat 1.7]
Matthias247 has quit [Read error: Connection reset by peer]