These are chat archives for SmingHub/Sming

17th
Mar 2018
Gabriel
@gbl08ma
Mar 17 2018 12:26
so I fixed it even though I don't understand how
I produced a build with rBoot disabled and used spiffs_mount() instead of the manual variants
and it worked, could read the filesystem
then I produced a build with rBoot enabled, but still using spiffs_mount. it still worked
and then I restored the "if slot == 0 mount manual 0, else mount manual 1" code, and it kept working
so I'll just blame it on some stuck bits in the rboot config or something that got away when I flashed the non-rboot version
now I have a problem where it will crash when scanning for wifi networks, but I think I can deal with this
Gabriel
@gbl08ma
Mar 17 2018 13:02
ugh... the new HTTP code broke some of my code
I had developed a JsonObjectAsyncStream class so that I could return a json stream asynchronously. this was needed, for example, for a HTTP request that scans for wireless networks
it's supposed to work like this: on the handler for the HTTP request, I begin scanning for wifi APs, create a new JsonObjectAsyncStream, and call response.sendJsonObject with that stream
later, on the ScanCompletedDelegate method, I take that async stream (which I saved in a global variable), write the AP information into it as json objects, and make it so that calling isFinished() on the stream finally returns true
this used to work fine
the request would "hang" during the scan, as it should, and finally end when it was done
Gabriel
@gbl08ma
Mar 17 2018 13:08
now, apparently the new HTTP code frees my JsonObjectAsyncStream before it is finished, or something, because when I try to use it on the ScanCompletedDelegate method, it just crashes when arduinojson tries to do anything with it
yep, that's exactly what is happening. I added a debug message to the destructor of the JsonObjectAsyncStream and it is getting destroyed before its isFinished() returns true
Gabriel
@gbl08ma
Mar 17 2018 13:28
by making the ESP crash on purpose on my destructor, I could see what is destroying it... apparently it's exceeding the timeout in TcpConnection::onPoll
so I need to find some way to set an infinite timeout on this type of connections
Gabriel
@gbl08ma
Mar 17 2018 13:35
apparently I can't get to the tcpclient or the httpconnection from the httprequest
@slaff any ideas on how to make my use case work again? I suspect nobody really thought one could wish to put a request "on hold" for an indefinite amount of time until it is ready (in my case, until the wifi scan results are in)
Gabriel
@gbl08ma
Mar 17 2018 14:17
it seems that as soon as any HTTP request handler takes more than a few milliseconds to run, the TCP connection is closed
I verified this with delayMilliseconds
Gabriel
@gbl08ma
Mar 17 2018 14:26
even if I make it such that my stream always returns one byte of "data" in the readMemoryBlock method, and even if it apparently sends these bytes, after some time the stream is just deleted
Gabriel
@gbl08ma
Mar 17 2018 14:58
hmm, I think that if I create my own HttpResource, I can set the timeout on the connection (like the websocket code does) and solve this problem for once
Gabriel
@gbl08ma
Mar 17 2018 16:45
ok, I finally did it. I created a CustomTimeoutResource that extends HttpCompatResource (so I could keep using my old callbacks)
assigned a custom onHeadersComplete handler on that resource
that handler does connection.setTimeOut(USHRT_MAX); on the http connection
and does response.setHeader("Connection", "close"); so that the connection is closed when I'm done writing the stream (the browser can't use content-length, because I don't know the content-length at the time the headers are sent)
to force sming's network code to not try and send a content-length by trying to compute the size of the stream (which in my case always returns wrong as I'll only know how big the stream is going to be when the resource ends), in my JsonObjectAsyncStream I override available() so that it returns -1 if the json is not written yet
this makes sming not send the content-length header