On Thu, Feb 20, 2014 at 04:25:29PM -0500, Karl Dahlke wrote: > Well I just needed to be a bit more patient. > It was actually creating those 160,000 objects over again, very slowly. > Each time it had just enough memory to make the new object, > then knowing it was out of space it ran gc, and deleted the old one, > and slowly step through and replaced all those objects. > Very slow but understandable.
Yeah. > That's most of the mystery solved. > But why does a printf, outside of javascript, > tweak the memory pool inside javascript just enough > so it can't create that first object, whence it stops right away? > I can't imagine the connection. > They should be independent of each other. Yeah, particularly as the js memory pool is on the heap. > > I added a free memory button to jsrt, > so we don't have to quit and restart to get js working again. Good idea. > > The noscript tags hide everything inside, > but they could let this pass through if isJSAlive fails. > This would only have meaning when the page was first parsed. > So if you turned js off, or it turned itself off because > of an error in another session, then yes you would see > the text in <noscript>, > but it wouldn't jump out at you if js stopped in this session > for any reason. > If you still think it's a good feature > I could implement it without too much fuss. Yeah, I didn't expect the noscript stuff to appear when js failed to execute, after all that could leave the page in an unknown (possibly completely messed up) state. However I think displaying the contents of the noscript tags if js is already dead makes sense, since if we have a js failure, it'd then be possible to refresh the page to get the noscript contents. Cheers, Adam. _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
