<vaninwagen>
hi, is there a way to generate documentation for a pony library (without main) only? ``ponyc --docs`` generates docs for all used packages, like builtin and collections. i just want stuff for my lib - and only public types, kind of an API documentation.
<vaninwagen>
docgen.c is the part to look at, right?
<vaninwagen>
while i am at it, why do we have private types and test types in the stdlib docs? just curious
vaninwagen has quit [Ping timeout: 260 seconds]
oldmanmike has joined #ponylang
vaninwagen has joined #ponylang
oldmanmike has quit [Ping timeout: 260 seconds]
_andre has joined #ponylang
acarrico has quit [Quit: Leaving.]
<SeanTAllen>
vaninwagen: we have private types and test types because people have different usage for documentation. some might be internal where that is appropriate. others might be "public only" which would require something different
<SeanTAllen>
docgen.c is where you would want to look
vaninwagen has quit [Ping timeout: 240 seconds]
autodidaddict has joined #ponylang
<autodidaddict>
Submitted a PR for the "interrogating actors with promises" pattern
<SeanTAllen>
autodidaddict: me being an annoying author i left a number of comments.
<autodidaddict>
awesome. love feedback
<SeanTAllen>
im glad you are in the community, im hoping you push my stuff as well
<SeanTAllen>
giving you are already an author, i left shorter notes rather than longer ones i would do for someone who might be less experienced
endformationage has joined #ponylang
<autodidaddict>
responded to your feedback. let me know if there are more suggestions
<SeanTAllen>
ill take a look tonight (hopefully) autodidaddict. i have to write up a scope of work for a client POC today.
<SeanTAllen>
autodidaddict: i had a chance to look. kick ass!
<SeanTAllen>
i had two tiny tiny formatting changes
<SeanTAllen>
if you can push those when you have a chance ill squash it all down to a single commit and merge
jemc has joined #ponylang
autodidaddict has quit [Ping timeout: 260 seconds]
amclain has joined #ponylang
catern has quit [Ping timeout: 260 seconds]
plietar has joined #ponylang
catern has joined #ponylang
catern has quit [Ping timeout: 260 seconds]
catern has joined #ponylang
autodidaddict has joined #ponylang
<autodidaddict>
pushed updates
<SeanTAllen>
and merged!
TheNet has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
TheNet has joined #ponylang
TheNet has quit [Remote host closed the connection]
TheNet has joined #ponylang
vaninwagen has joined #ponylang
<vaninwagen>
SeanTAllen concerning the docgen question i had, do you think it is worth putting any effort into adapting the docgen part to be able to create public API for the local package only?
<vaninwagen>
From my side this is pretty useful as i could use it to create and publish some API docs for ponycheck
<vaninwagen>
should an idea like this go through the RFC process?
<vaninwagen>
if it makes sense in the first place
<SeanTAllen>
vaninwagen: i think its reasonable. i don't think an RFC is needed as long as it is adding functionality. that said, i think discussion would be good. this could be either on the developer mailing list, an issue on ponyc repo, or in person during the sync call.
<SeanTAllen>
is there a particular format you prefer? i think any of the 3 works fine.
<vaninwagen>
SeanTAllen i'd say it should definitely be somehow in written form. I'd prefer a github issue (optionally with additional sync call) tbh.
<SeanTAllen>
Open a github issue as an enhancement. reference this conversation here. and bring up what you want to accomplish and why and we can start to collect feedback. the document generation as far as i know has only seen usage with the standard library.
<SeanTAllen>
So it could certainly use more loving. I'm glad you have interest in the area. I'm not particularly fond with it being tied to mkdocs but I wasnt going to touch that until we had "pony in pony" for the compiler so it would be easier to get contributions
<vaninwagen>
oh how i miss doing plain C :)
Matthias247 has joined #ponylang
<SeanTAllen>
as compared to? c++?
<autodidaddict>
running into yet another refcaps issue.. Trying to create a map field:
<autodidaddict>
let foo: Map[String, MyActorTrait tag]
<autodidaddict>
to store a map from string to actors that conform to a particular trait
<jemc>
sounds right so far
<jemc>
(but quick note: if you declare your `trait MyActorTrait` as `trait tag MyActorTrait`, you can leave out the `tag` pretty much everywhere else)
<vaninwagen>
SeanTAllen as compared to all the high level stuff without pointer arithmetic i have to use for my sad day2day job
<autodidaddict>
when I do _foo("special") = conformingactor I get "receiver type this->HashMap[String val, CommandHandler ref, HashEq[String val] val] ref ... and target type is the same but without "this->"
<SeanTAllen>
autodidaddict: can you gist a short playground example?
<autodidaddict>
I'll try
<jemc>
autodidaddict: can confirm for sure after you post a gist, but the most likely cause of that error is you need to change the method you're in the body of to a `fun ref`
<jemc>
`fun` methods are read-only by default (`fun` with no explicit receiver cap implies `fun box`), and you can't modify a field from a read-only method
<jemc>
or to be a bit more pedantic, the rcap of the field is transformed by the rcap of the origin through the process known as "viewpoint adaptation", which is that the `this->` part is describing - it refers to "how `this` sees your field" - whch in this case is "how `box` sees `ref`", the answer to which is that it sees it as a `box` - read-only
<autodidaddict>
I'm used to being able to sneak mutability
<autodidaddict>
e.g. object.some_mutable_method() doesn't trigger a mutation warning because it's not a re-assignment
<autodidaddict>
but .apply and .remove on a map are definitely mutations
<jemc>
yeah, this is the whole benefit of the rcap system in pony - it applies deeply, and the compiler won't let you "sneak" :)
<autodidaddict>
it would be beyond awesome if the error message could take a quick look at that and offer a hint
<autodidaddict>
e.g. clippy pops up and says, "It looks like you're trying to mutate a field from a non-ref fun"
<jemc>
autodidaddict: it's a common question that pops up for a lot of users, so seeing if we can add an extra hint to the compiler message is probably a good idea
<jemc>
we have some other compiler error hints that take the form of "this would be possible if [...]"
<jemc>
and that could be appropriate here
<jemc>
I don't know if we already have an issue ticket for this, but if not, you could file one and I could label it as an error message improvement ticket
* SeanTAllen
is typing something, jemc's pops up. me deletes what he is typing
<autodidaddict>
jemc: the viewpoint adaptation tutorial is really dense...and it's still fuzzy after reading it a dozen times. And re-reading it didn't give me an inclination that I need to "ref my fun" :)
<jemc>
it could probably use some more specific mentions of how receiver capabilities fit in
<jemc>
`[]` should be possible in the future, but for now, to create an empty array, call the constructor of it
<jemc>
`let array = Array[MyElementType]`
<autodidaddict>
here's another dumb one
<autodidaddict>
I've got a class that has a method that returns the value in a Map[String, SomeActor tag]
<autodidaddict>
e.g. `fun get(key: String) : CommandHandler tag => recover _strorage(verb) end`
<autodidaddict>
I'm getting the "can't access field of non-sendable object" thing. I fixed this before by doing the destructive assignment.. but I don't want to ruin that map element - I need to keep it around as well as return the tag that's sitting in the map
<autodidaddict>
er, destructive read I think is the official term
<jemc>
autodidaddict: why are you feeling that you need to use `recover` in the first place?
<jemc>
you're trying to return a `tag`
<autodidaddict>
because I got an error when I tried to return the raw value
<autodidaddict>
so I started trying random crap
<jemc>
`recover` is for "lifting" capabilities, but you don't need any assistance to "drop" a capability, and `tag` is the "lowest" capability
<autodidaddict>
that's my goto troubleshooting technique for refcaps
<autodidaddict>
got it working. arg.
<autodidaddict>
I was _sure_ I'd tried just returning the tag raw before and it failed
<autodidaddict>
I'm adding a flexible capability to the PonyMUD to write small actors as command handlers.. So I add the ability to type "who" to the player by invoking this in the player actor constructor: `CmdWho(this, _cm)`
<autodidaddict>
it registers the verb, stores it in the map via hidden trait, etc
autodidaddict has quit [Ping timeout: 260 seconds]
plietar has quit [Remote host closed the connection]
Matthias247 has quit [Read error: Connection reset by peer]
oldmanmike has joined #ponylang
autodidaddict has joined #ponylang
<autodidaddict>
Traits question.. For giggles I wrote two traits, both with the `save()` method and default implementations inside the trait. When I make an actor (SaveA & SaveB) the compiler says that there are possible multiple bodies and "local disambiguation is required" How does one locally disambiguate?
<autodidaddict>
and can I make it so that both SaveA.save() and SaveB.save() are invoked when MyActor.save() is called?
<SeanTAllen>
I've never hit that issue before autodidaddict. I believe it is that you have to define save() yourself and implement it yourself without being able call the default methods on the trait (because well, you have a save that has overridden them).
endformationage has quit [Quit: WeeChat 1.7]
<SeanTAllen>
but i could be very very wrong
<autodidaddict>
I haven't actually found a practical need for this behavior, I was just messing around and wondered... "If I have 10 mixins that all have the same method name but different default implementations, can I invoke all 10 at once?" :)
<SeanTAllen>
they aren't mixins so, that would be a no
<SeanTAllen>
sylvan and i have talked about if mixins would be better than traits
<SeanTAllen>
end of the discussion was ¯\_(ツ)_/¯ maybe.
oldmanmike has quit [Ping timeout: 255 seconds]
<SeanTAllen>
we have agreed that the code sharing story needs to be improved.
<SeanTAllen>
ᕕ( ᐛ )ᕗ
<autodidaddict>
I was using "mixins" in a deliberately incorrect way. I used to annoy Scala people by calling traits mixins
<autodidaddict>
I'm a big fan of keeping things simple and constrained and only expanding and relaxing when there's a real, evidence-based demand
<autodidaddict>
otherwise you get "kitchen sink" languages (Java)
<autodidaddict>
and abominations like "monkeypatching"
<autodidaddict>
Want to change the type signature and vtable of an object at runtime? Suuuuuure go for it. What could go wrong?
<SeanTAllen>
but Scala traits are mixins!
<autodidaddict>
not really
<autodidaddict>
not under the hood
<SeanTAllen>
they arent traits
<SeanTAllen>
perhaps it depends on your definition of mixin
<autodidaddict>
they're smoke-and-mirrors attached to the backside of Java classes with tape and bubble gum and given psuedo scopes with closures
<autodidaddict>
but they look and feel like mixins, which is so shiny and tempting