03:22 <SeanTAllen> yeah that seems to have happened at some point, iso instead of ref, we've noticed at sendence but havent had a chance to track down

03:22 <SeanTAllen> btab: i see a problem here: https://gist.github.com/btab/1d814e886e9216c26cf0be485c1a0f5d

03:23 <SeanTAllen> or at least a possible problem. depends on what you are trying to do

03:23 <SeanTAllen> you are returning a val in a spot where it calls for a ref

03:44 <btab> I may not be following you but I was basically trying to satisfy #read in the second argument of Map.get_or_else.

03:45 <btab> If I swap the final 'recover val' for 'recover ref', the error message changes accordingly to 'ref is not a subtype of #read'

03:45 <btab> Maybe I should clarify - when you say 'it' calls for a ref - which 'it' do you mean :-)?

03:54 <doublec> btab: the problem in line 17 is because the 'this' of the method is box

03:54 <doublec> btab: so the 'm2' map is slightly different due to viewpoint adaption that what you expect

03:55 <doublec> btab: if you make the method a 'fun ref' it compiles

03:56 <doublec> btab: and the reason for that is the value of the 'alt' parameter in get_or_else in a ref map is a Array[String] ref

03:56 <doublec> btab: but in a box method, the the 'alt' parameter becomes box->Array[String] ref

03:56 <doublec> btab: (I think)

03:58 <doublec> yes, I think that's it. Because it's a box method, the 'm2' field is of type Map[...] box due to viewpoint adaption. (box->ref == box)

03:58 <btab> And there was me thinking I understood viewpoint adaptation.

03:58 <doublec> And the 'alt' parameter on get_or_else is "this->V"

03:59 <doublec> The 'this' for the map is box

03:59 <doublec> so the alt parameter expects box->V, V being a ref, so that's box->ref which is again box.

04:01 <doublec> so there may be some other reason but it's a viewpoint adaption happening that's causing the type to be unexpected

04:06 <doublec> First attempt at a cut down version, removing map from the equation: http://pastebin.com/rBfhZGC9

04:08 <btab> When I think about why methods have refcaps in the first place, my understanding is that you basically shouldn't ask for a ref receiver unless you need one as you're getting permission to write to something when you don't need it.

04:08 <btab> That was my (admittedly very basic) understanding of why funs default to box,

04:09 <btab> So in order to fix retrieval of a value in this example, I've had to open up to requirements from box to ref. That feels idiomatically weird.

04:10 <doublec> This removes generics from the equation: http://pastebin.com/3ZG84p91

04:10 <doublec> btab: yes, I'm trying to track down what viewpoint adaption is happening and why

04:18 <doublec> What's weird is this works: http://pastebin.com/hKG6jp6L

04:19 <doublec> It assigns the field to a box rcap and calls the method through that. But shouldn't that be the same as not assigning it to the box rcap since it's box already?

04:31 <doublec> btab: here's an explanation of why it needs to be "fun ref" and why "fun box" is actually wrong

04:32 <doublec> btab: the getThingsStringArrayLiteral() function has the return type defined as "Array[String] ref"

04:32 <doublec> btab: the body tries to return the value of a map, a Array[String] ref.

04:33 <doublec> btab: the returned object is a borrowed item from the map - it's a reference to something held by the map

04:33 <doublec> btab: and a writeable reference at that

04:33 <doublec> btab: but we can't return a writeable reference to something from a box function as it wouldn't then work for 'val'

04:34 <doublec> btab: because that would enable returning a writeable reference to something internal to a val object

04:34 <doublec> btab: and that's why the method needs to be "fun ref" - because we are actually returning a writeable reference to an internal object

04:34 <doublec> btab: make sense?

04:44 <btab> Yes it does, thankyou. This trap was *very* easy to fall into. I'm wondering what the compiler could have done to be more helpful - not sure.

05:06 <btab> I was thinking about how (given this discussion) I'd adapt that function to return a Array[String] val even if the value type in the Map was Array[String] ref.

05:06 <btab> One interesting consequence of this thought process is that it isn't enough to reason 'I want to return an immutable thing therefore my receiver type can be read-only'.

05:06 <btab> It has to have permission in the first place to get at a mutable thing.

05:07 <btab> And the compiler errors are basically driving me to realize (suddenly, and way too late) that I can't just pretend a shared ref is a val. In other words, the compiler's basically waiting for me to realize I need to clone something.

05:08 <btab> Even if the compiler error was pretty obtuse in this case, I like that it's cornered me into reasoning correctly about the permissions in the code.

12:54 <SeanTAllen> doublec: there's a bug in assigning to fields and refcaps at the moments. sylvan has an open PR to merge. that might be impacting on your example

20:05 <TwoNotes> Is there an ongoing discussion somewhere about improvements to the http server package?

20:56 <TwoNotes> I am wondering whether the multi-dispatch feature ("pipelined requests") is worth all the problem it causes

21:09 <jemc_> TwoNotes: I don't think the discussion has been collated anywhere, but we all very much would like the HTTP server to be redesigned for better performance and usability

21:09 <jemc_> if you have ideas for a design, you could open an RFC in our ponylang/rfcs repo with the details

21:09 <TwoNotes> I have been working on some ideas. The way it is now, it can not handle streaming at all, and insists o buffering entire responses in memory, regardless of size, before sending anything to the client

21:10 <TwoNotes> Ok, so there is no existing RFC on this topic?

21:12 <jemc_> on the usability front, I think it's problematic that the incoming request is an `iso` (for the purposes of allowing only a single response) - the fact that it's an `iso` makes it cumbersome to read details from the header and the payload (many have complained about this) - I think I'd rather see the request object be a `val`, but have an `iso` response lambda that you call to send the response

21:12 <jemc_> yeah, there's no existing RFC yet

21:12 <TwoNotes> I wil read up on the RFC process then

21:13 <jemc> the TLDR is: open a PR that copies the template file and fills in all the sections with your detailed proposal

21:13 <TwoNotes> Current code is also vulnerable to DoS attacks, whether intentional or not. There does not seem to be any throttling

21:14 <jemc> when the discussion has settled, we go to a 1-week final comment period, then the core maintainers vote on it at the following sync call

21:33 <jemc> TwoNotes: (just saw your last sentence) yeah, I agree we should at least have a mechanism for the application to issue backpressure

21:42 <TwoNotes> There was a previous Issue on the TCP package to provide a way for a program to detect whether backpressure had been applied

21:42 <TwoNotes> Or to apply it, so that the TCPCOnnection actor stops reading from the socket

21:56 <jemc> TwoNotes: yes, see `TCPConnection.mute` and `unmute` for the latter

21:56 <jemc> and `TCPConnectionNotify.throttled` and `unthrottled` for the former

21:57 <jemc> main question in my mind would be what is the most useful mechanism for an application to apply backpressure to the http server abstraction

21:58 <jemc> whether that would be something like a `mute`/`unmute`, or a pool of request handlers with a maximum size

21:58 <jemc> latter sounds like it might be easier to manage

21:59 <TwoNotes> On the server side, if it is in the middle of streaming a large media file back to the client, there is no point in accepting additional requests.

21:59 <jemc> also, in terms of an HTTP Server, I think we probably need a `mute`/`unmute` for `TCPServer` to tell it to stop accepting new connections

22:00 <TwoNotes> You would not want to dispatch those requests in any case. You can queue them up to a point, but there has to be a limit. Either they fail with an HTTP status code, or you backpressure the link

22:00 <jemc> that should probably be an RFC of its own - it's an extension of the `TCPConnection.mute`/`unmute` case

22:00 <TwoNotes> Or, just do not implement parallel (pipelined) dispatch at all.

22:01 <TwoNotes> Perhaps a given HTTP Server can decide whether it wants to accept parallel dispatch. If it is going to be serving media files, it could just disable them up gront, and you get simple FIFO processing