| 00:08 | <TabAtkins> | a-ja: pong |
| 00:23 | <TabAtkins> | a-ja: ;_; |
| 00:26 | <a-ja> | TabAtkins: sorry....back now |
| 00:27 | <a-ja> | TabAtkins: an observation re counter-styles |
| 00:28 | <a-ja> | TabAtkins: predefined disclosure close arrow....shouldn't there be rtl and ltr versions? |
| 00:29 | <TabAtkins> | Yes, there should be. |
| 00:29 | <TabAtkins> | I've had an open issue on that for a while, and haven't been sure how I want to handle it. |
| 00:30 | <a-ja> | TabAtkins: thought it a good time to mention it....since there's patches in progress |
| 00:33 | <a-ja> | dependancy on dir() ? |
| 00:34 | <TabAtkins> | Yeah, probably. |
| 00:34 | <a-ja> | perhaps in L2? dunno about timing |
| 00:35 | <TabAtkins> | Either dir(), or a hypothetical "text as <image>" function + image() function with ltr/rtl keywords. |
| 00:35 | <TabAtkins> | The Counter Styles spec is still hovering in LC right now (like 3 months after the LC period ended) as people are implementing and finding bugs and necessary clarifications. So I can make the change now. |
| 00:37 | <a-ja> | TabAtkins: url for issue bug? |
| 00:37 | <TabAtkins> | Doubt I have one, but I've recorded it for now in the list of bugs I'm trying to burn down at https://github.com/tabatkins/specs/issues/29 |
| 00:44 | <TabAtkins> | a-ja: Out for the night, feel free to mention me here in chat or in email or in the github issue or anywhere else you think I might see it. ^_^ |
| 00:44 | <a-ja> | TabAtkins: different topic....colors4. an example of how to use named hues would probably be helpful. is it hsl(namedhue,?,?) or ? |
| 00:45 | <a-ja> | TabAtkins: good night....take care |
| 05:21 | <zcorpan> | <http://www.w3.org/mid/CAPJYB1gDsLK5Oppjges-uTenQWHOuZy+GEAg=8sTy4A7iVXTTA⊙mgc>; |
| 05:27 | zcorpan | notices http://w3c-test.org/resources.whatwg.org/ is gone |
| 05:28 | <zcorpan> | i guess i don't need https anymore |
| 05:31 | <zcorpan> | Hixie: for onload you'd need to check target == document :-) |
| 06:55 | <heycam> | Hixie, yeah, I'm behind on webidl editing. please point me to the relevant bug and I'll prioritise it. |
| 09:21 | <aleray> | hi, how would you markup the editor note of a paper |
| 09:21 | <aleray> | ? |
| 09:23 | <aleray> | eg. http://dpaste.com/1775599/ |
| 09:27 | <webben> | aleray: http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-header-element possibly |
| 09:37 | <aleray> | webben, thanks |
| 09:47 | <annevk_> | JakeA: Hixie: if we are going to standardize requestautocomplete, should we at least use a promise? |
| 10:50 | <JakeA> | annevk_: the Chrome impl is getting promises. I posted a link to the ticket here earlier |
| 11:30 | <annevk> | JakeA: k |
| 11:32 | <JakeA> | annevk: https://code.google.com/p/chromium/issues/detail?id=343630#c10 |
| 11:55 | <annevk> | JakeA: so you removed non-GET methods from the cache API, but did you keep HEAD working? |
| 11:56 | <JakeA> | annevk: I need to add something for HEAD. It's only used in the matching, not the storage I guess |
| 11:57 | <annevk> | JakeA: so there's the thing of doing a HEAD request and then updating the headers of a stored entry, but I'm not sure if we should support that |
| 12:00 | <JakeA> | annevk: yeah, more than happy to drop that. If we allow storing other methods we can do that then |
| 12:12 | Ms2ger | pokes foolip |
| 12:32 | <jgraham> | So I wonder what UK/London events would have participants also interested in doing Test The Web Forward. So far I didn't think of anything better than full frontal, which has the disadvantages of being in Brighton in November (just after TPAC I think), but the advantage of attrating the kind of people I would love to see at a TTWF event |
| 12:34 | <Ms2ger> | Something happens in Brighton? |
| 12:36 | <jgraham> | I'm told lots of things happen in Brighton |
| 12:37 | <jgraham> | (the main problem with Brighton is "can't use the Mozilla space conveniently") |
| 12:37 | <jgraham> | remysharp: Any ideas? :) |
| 13:00 | <annevk> | jgraham: we could just try to host one on a Saturday |
| 13:03 | <jgraham> | annevk: Sure |
| 13:05 | <jgraham> | annevk: My theory is that the participants they have had so far have been relatively untargeted and so we have been relatively ineffective at getting either great tests or retaining people |
| 13:06 | <jgraham> | That might not be the right theory, but I wanted to test it by jumping on the coattails of a conference that attracts people who are already working in web development rather than mainly attracting students (which I think has been the case with TestTWF to date) |
| 13:07 | <jgraham> | The idea being that getting those people the message that when they find browser bugs there is a simple way for then to contribute to getting the bugs fixed is good for the industry as a whole |
| 13:32 | <annevk> | jgraham: could ping Jeremy Keith too |
| 13:33 | <annevk> | jgraham: and others |
| 15:02 | <arunranga> | annevk, ping |
| 15:02 | <annevk> | arunranga: http://www.nohello.com/ |
| 15:04 | <arunranga> | annevk, w.r.t. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25302 I’d like to round up the loose ends in neutered Blobs. I think we can say that structured clones fail on a neutered Blob. |
| 15:04 | <arunranga> | annevk, this will ensure that pre-neutering asynchronous operations on a Blob can take a structured clone. |
| 15:04 | <arunranga> | annevk, even if there’s a mid-operation neutering. |
| 15:05 | <arunranga> | annevk, if we do this I this, I think you’ll have the pieces you need in affiliated specs, but don’t need a keepalive list of objects. |
| 15:07 | <annevk> | yeah, I forgot how we already got around the whole being neutered thing using structured clones |
| 15:07 | <arunranga> | annevk, sorry about preemptive pinging. I should have known better. |
| 15:08 | <arunranga> | annevk, so I think if we explicitly say that Blobs that are CLOSED can be cloned, we’re ok. That way, operations on clones while still OPENED will work as intended in asynchronous settings. |
| 15:08 | <arunranga> | s/can be cloned/cannot be cloned. |
| 15:09 | <annevk> | yes, structured cloning should fail or some such |
| 15:09 | <annevk> | still unclear to me what happens to closed blobs, does reading from them result in empty sequences? |
| 15:10 | <arunranga> | annevk, but that still leaves the “status check” about how exactly to determine if a Blob is closed. I think there’s merit to the 0 byte approach, but zewt asks if there are any use cases in script for knowing if a Blob is neutered. |
| 15:10 | <arunranga> | annevk, yes, I like the 0 byte approach |
| 15:10 | <arunranga> | annevk, I’d like this to be what happens to neutered Blobs |
| 15:10 | <annevk> | it might be a bit cumbersome to write the FormData serialization algorithm if some blobs end up being empty and cannot be cloned whereas others have to be cloned |
| 15:10 | <annevk> | but maybe it's okay |
| 15:11 | <arunranga> | I actually don’t think it will be cumbersome. |
| 15:11 | <arunranga> | Why would a developer actually need a 0 byte Blob, for example? It seems rare that a non-neutered Blob will be 0 bytes |
| 15:12 | <arunranga> | of course, you could do var blob = new Blob() but that alone isn’t terribly useful. |
| 15:14 | <annevk> | I mean writing the serialization algorithm of FormData in the specification |
| 15:15 | <annevk> | If neutered blobs cannot be cloned you end up with special code paths |
| 15:15 | <annevk> | But it should not be too bad I suppose |
| 15:15 | <arunranga> | Hmmm |
| 15:16 | <SamB> | hmm, what was that site with the "You had a problem" quotes? |
| 15:17 | <SamB> | or however that's phrased |
| 15:46 | <zewt> | i very strongly dislike the 0-byte thing; it's a bad, hacky API, it breaks with actual 0-byte files, it sacrifices the blob size being immutable, it forces developers to cache the size if they want it after closing (progress meters, etc) |
| 15:47 | <zewt> | you'll easily get 0-byte blobs, as soon as you use <input type=file> and a user opens an empty file |
| 15:47 | <SamB> | aren't there, like, negative numbers that could be used if magic numbers are needed? |
| 15:48 | <zewt> | if we want to expose the closedness of a blob, add a property. i don't see why we would use the size property for that at all |
| 15:53 | <annevk> | why would you want to cache the size of the original object? |
| 15:53 | <annevk> | you just neutered it |
| 15:55 | <zewt> | you might still be using the size, eg. setTimeout(function() { progress.innerText = (totalBytesSent*100 / blob.size) + "%"; }, 500) |
| 15:56 | <zewt> | now suddenly that shows 0 or NaN% or whatever |
| 15:56 | <zewt> | i gave a similar example on the bug |
| 16:03 | annevk | shrugs |
| 16:05 | <zewt> | ... |
| 16:05 | <zewt> | it's a bizarre, hacky, unexpected API with no redeeming values. hopefully we can do better than "shrugs" |
| 16:09 | <jgraham> | I think zewt has a point here. I'm not sure what problem this is trying to solve |
| 16:11 | <arunranga> | zewt, jgraham: I suppose if we specify that ALL operations on neutered Blob objects fail at the API level, then maybe we don’t need to expose this, even as a property. |
| 16:12 | <zewt> | what do you mean "fail at the API level"? |
| 16:12 | <zewt> | i think that sync APIs should always *not* fail |
| 16:12 | <arunranga> | zewt, I mean: FileReader.readAsXxx should fail and report an error asynchronously |
| 16:12 | <zewt> | for reasons I mentioned earlier (minimizes the surface area of the "closed blob" feature, fewer error cases for developers to have to handle, etc) |
| 16:12 | <zewt> | ah, OK |
| 16:13 | <arunranga> | zewt, we’ll have to reason through what other things fail. |
| 16:14 | <arunranga> | But when you say sync APIs should always *not* fail, do you mean, not throw? |
| 16:14 | <arunranga> | So FileReaderSync probaby has to throw in this case |
| 16:14 | <arunranga> | Affiliated APIs, including URL.createObjectURL and URL.createFor, won’t “fail” but will generate a URL that results in a network error. |
| 16:15 | <zewt> | sync versions of async APIs are an exception |
| 16:15 | <zewt> | maybe it's more precise to say that the only thing that should fail is attempts to access the data inside the blob, and it should fail in the same way that the API normally fails |
| 16:16 | <arunranga> | zewt, ok, I’m coming round to this. |
| 16:16 | <zewt> | sync fetch APIs fail by throwing an exception, so that's OK--that's the error handling the user has anyway for using that API |
| 16:16 | <Hixie> | annevk: not clear to me how promises would actually work for rAc |
| 16:17 | <zewt> | (eg. FileReaderSync() against a File that the user has deleted) |
| 16:19 | <Hixie> | annevk: and you still have to fire the input/change/invalid events, so it's not like it takes you away from events. |
| 16:19 | <annevk> | Hixie: yeah, didn't realize that |
| 16:23 | <arunranga> | zewt, I guess that leaves .slice(), which you think should do what it does normally with byte sequences, but simply neuter the output. |
| 16:25 | <zewt> | arunranga: say you have a black-box API readZipFileFooter(blob), which slices the end of the blob and reads it ... if I pass in a closed blob, it'll cause an error along a typical code path (during the read), instead of throwing an exception in slice(), which that function is probably much less likely to handle |
| 16:26 | <arunranga> | zewt, yup, makes perfect sense to me. Can’t argue with that. |
| 16:27 | <zewt> | an API might parse out a ZIP into a list of filename: (start, size) items, and let you say zip.openFile(filename), which does { var info = data[filename]; return this.blob.slice(info.start, info.end); }, which also makes sense to just propagate the closed-ness instead of failing |
| 16:28 | <arunranga> | zewt, but I guess this does mean that you can access properties of closed Blobs such as size, which the 0 byte approach addressed but perhaps hackishly. |
| 16:29 | <arunranga> | so I’m determining whether this is a Bad Thing. |
| 16:29 | <zewt> | but i'm saying that the size should remain unchanged |
| 16:30 | <zewt> | (and other similar properties, like File's .type) |
| 16:30 | <arunranga> | I see what you’re saying. I’m trying to determine if that results in anything bad/inconsistent happening. |
| 16:30 | <arunranga> | For instance, a developer might do a if(file.size != 0) test before a read operation |
| 16:31 | <arunranga> | Which would fail anyway on a closed Blob. |
| 16:31 | <zewt> | what would be the purpose of that test? |
| 16:31 | <arunranga> | Well, the purpose of that test would be to see if you’ve got a readable file with bytes to be read |
| 16:31 | <arunranga> | But, the Blob is in fact closed. The bytes cannot be read. |
| 16:32 | <zewt> | then that test would be wrong; the read might fail anyway, such as if it's a File pointing to a userspace file that the user has deleted |
| 16:32 | <arunranga> | zewt, right; but that’s because of the snapshot condition |
| 16:33 | <arunranga> | Which is a failure that’s not programmatically determinable from within the sandbox. |
| 16:33 | <arunranga> | But a check for neutered objects might need to be. |
| 16:33 | <zewt> | but if(file.size != 0) is not a test for whether you can read from the file |
| 16:34 | <arunranga> | zewt, yes, it’s not a reliable test. |
| 16:34 | <zewt> | (by the way, since this ended up being a different thing than "neutered", we should probably not call it that) |
| 16:34 | <arunranga> | zewt, well, even with Blob.close() we’re going to prohibit structured cloning I think |
| 16:34 | <zewt> | i don't think we should do that, either |
| 16:35 | <annevk> | zewt: most APIs when you neuter them their attributes will return some kind of initial value |
| 16:35 | <annevk> | zewt: e.g. ArrayBuffer |
| 16:36 | <arunranga> | zewt, I think it would help with FormData (and your proposal) if we can’t structured clone on a .close() |
| 16:36 | <zewt> | arunranga: how? |
| 16:37 | <zewt> | seems like it makes it easier, actually |
| 16:37 | <zewt> | (if you can) |
| 16:38 | <arunranga> | Ah wait. You’re right. In the case of FormData, the structured clone won’t create a normal point of failure upon close, but the read will. |
| 16:38 | <zewt> | eg. you structured clone the Blob synchronously at the start; if the blob was closed, you don't fail there, you fail later when you try to use the clone (in the same spec code path where you handle other read errors) |
| 16:39 | <arunranga> | I guess this does reduce the “points of failure.” |
| 16:40 | <arunranga> | annevk, would it be ok if neutering a blob doesn’t affect its ability to be cloned? |
| 16:40 | <zewt> | it seems nicer for postMessage, etc. too: if I want to post a FileList containing 100 files and I've closed one or two of them, just let me do it without making a new FileList with the closed blobs removed |
| 16:40 | <annevk> | arunranga: per the HTML spec it currently throws |
| 16:41 | <annevk> | arunranga: I don't really care |
| 16:41 | <zewt> | i was planning on filing a bug on HTML about structured clone, but only after the stuff inside file api itself was decided |
| 16:41 | <annevk> | arunranga: I think it would make sense to expose isClosed |
| 16:42 | <arunranga> | zewt, your bug would be to allow structured cloning of neutered objects? |
| 16:42 | <zewt> | yeah |
| 16:43 | <arunranga> | zewt, based on the same “limit the points of failure” reasoning, or some other reasoning? |
| 16:44 | <zewt> | well, if the effect of blob.close() is defined as something like "act as though the underlying file was deleted", then disallowing cloning doesn't make sense--structured clone doesn't throw if a File's file is deleted, for example |
| 16:44 | <annevk> | arunranga: why is it defined as neutuered and not as closed? |
| 16:45 | <zewt> | arunranga: oh, my bug would probably be specifically for closed Blobs (with a side note of "i think this should apply to neutered objects like ArrayBuffer as well") |
| 16:45 | <arunranga> | annevk: that should change, I think. |
| 16:45 | <arunranga> | annevk: I think terminology is misleading. |
| 16:46 | <arunranga> | annevk, though they are similar. |
| 16:46 | <annevk> | arunranga: not really, neutering happens as the result of a transfer |
| 16:47 | <zewt> | transfer is a user of neutering, neutering isn't tied to transfer (but that's a whole long separate discussion that I've given up on) |
| 16:47 | <arunranga> | annevk, well, I’m going to kill the word ‘neuter’ |
| 16:48 | <arunranga> | (it should be used consistently to mean one thing. By re-using it in FileAPI, I’ve created a confusion bug) |
| 16:49 | <zewt> | (i thought that had already been changed, but I guess I thought that since it was changed in HTML, which says "disabled through the close() method") |
| 16:50 | <arunranga> | well if annevk doesn’t really care about whether .close() affects cloning, it may as well not affect cloning, and rather, only affect reading. |
| 16:50 | <arunranga> | I think FileAPI should position success and failure as reading bytes success and failure anyway. I agree with the bugs that push in this direction. |
| 17:29 | <Hixie> | heycam|away: why are trailing commas in enum descriptions not valid? |
| 18:54 | <Domenic_> | bahaha http://w3cmemes.tumblr.com/post/82309160313/philosoraptor-couldnt-sleep-last-night-so-she |
| 18:57 | <Hixie> | for whomever posted http://w3cmemes.tumblr.com/image/82219740533 - i present to you http://ln.hixie.ch/?start=1056847759&count=1 |
| 19:00 | <arunranga> | Domenic_ I’ll soon expunge “neutered” from the FileAPI spec. They’ll simply be closed. |
| 19:00 | <arunranga> | :-) |
| 19:00 | <Domenic_> | seems good :) |
| 19:20 | <arunranga> | Domenic_, is AbortableProgressPromise something that we should expect to land as a real thing? I’m using it in spec, but handwaving a bit. |
| 19:20 | <Domenic_> | arunranga: no, definitely not |
| 19:20 | <Domenic_> | arunranga: Progress is almost certainly dead. Cancellation/abortion is probably going to happen at some point though so collecting spec use cases would be helpful. Still early days. |
| 19:20 | <arunranga> | Domenic_, uh-oh. Fx has a sandboxed version of FileSystem API hat uses something a lot like it :-) |
| 19:21 | <arunranga> | Domenic_, to be honest, I don’t hate AbortableProgressPromise. |
| 19:21 | <Domenic_> | Progress generally means you should be using streams :P. And yes, I'm aware we need to pick up the pace there. |
| 19:21 | <arunranga> | Domenic_, but I just want something that addresses the use case. |
| 19:21 | <Domenic_> | Actually both of those are better addressed by streams... |
| 19:21 | <Domenic_> | Promises should be for one-and-done, non-interruptible, atomic-ish operations |
| 19:22 | <darobin> | that's what she said |
| 19:22 | <TabAtkins> | Promises are definitely abortable if you want them to be, though - you just have to extract and vend the reject function yourself. |
| 19:22 | <TabAtkins> | Exposing them primitively for cases that could use them makes sense to me. |
| 19:23 | <Domenic_> | that's true. That's a good way to look at it. |
| 19:23 | <TabAtkins> | (You can convert any normal promise into an abortable one by wrapping it in a promise of your own, passing accept and reject to the normal promise and leaking the reject outside of your promise as well.) |
| 19:23 | arunranga | gives darobin scowly smile |
| 19:24 | <TabAtkins> | I'm much less convinced about progress, though. |
| 19:24 | <Domenic_> | Abortion usually implies that it has some impact back to the promise creator though. It's not only a capability-vending, but always a backward communication channel |
| 19:24 | <TabAtkins> | Domenic_: Yeah, true, so the op usually does more than *just* reject. |
| 19:24 | <Domenic_> | We are prototyping an interesting alternative to progress (viz. estimated time of arrival) in user-space. So far it composes much better. But it's very very early days for that. |
| 19:24 | <Domenic_> | s/always/also/ |
| 19:26 | <arunranga> | TabAtkins, I’d like to use something like AbortableProgresPromise for an operation like FileHandleWritable in http://w3c.github.io/filesystem-api/Overview.html#the-directory-interface |
| 19:26 | <arunranga> | To write some bytes, and then abort. |
| 19:27 | <TabAtkins> | Right, I'm not saying that progress monitoring is a bad thing, I'm just not convinced it's best modeled as a Promise extension. |
| 19:27 | <TabAtkins> | I dithered over this a bit in my EventStream proposal. |
| 19:27 | <Domenic_> | arunranga: "write some bytes then abort" sounds exactly like streams... |
| 19:28 | <Domenic_> | arunranga: what is the timeline on this FS API? |
| 19:28 | <arunranga> | Domenic_, yes, you’re right; it’s streamlike, but streams aren’t forthcoming. We’re left with Blobs and whatnot. |
| 19:28 | <Domenic_> | arunranga: who says streams aren't forthcoming!? |
| 19:29 | <arunranga> | Domenic_, well, the timeline, as of today, is “a more specifc draft will land in two-ish weeks.” |
| 19:29 | <arunranga> | Domenic_, huzzah! Tell me what I don’t know. Where have Streams been my whole life? |
| 19:31 | <Domenic_> | arunranga: https://github.com/whatwg/streams ! |
| 19:31 | <Domenic_> | we're closing in on something pretty close to final |
| 19:31 | <Domenic_> | TCP and UDP sockets spec is based on them |
| 19:31 | <Domenic_> | https://rawgithub.com/ClaesNilsson/raw-sockets/gh-pages/index.html |
| 19:31 | Hixie | shudders at the idea of allowing the web access to raw UDP or TCP |
| 19:32 | <Domenic_> | arunranga: if you give me deadlines I can push myself to meet them. right now what I have is "everyone wants this yesterday." |
| 19:33 | <arunranga> | Heh, well… sounds like you’re going to land this as a WHATWG draft soon-ish. If you land in two weeks, I can bash out details left in FileSystem. |
| 19:33 | <Domenic_> | two weeks!! Can do. |
| 19:34 | <Domenic_> | important question: do those two weeks include three weekends, or two weekends? |
| 19:34 | <Domenic_> | (i.e., is it Monday, or is it Friday) |
| 19:34 | <arunranga> | If that’s unreasonable, push back :-) There isn’t really too much “fall off the cliff” pressure about FileSystem, TBH. It’s already in Firefox, but sandboxed (and uses constructs that you disapprove of based on the above ^^). And, user agents are exactly beating down our door with support. |
| 19:34 | <Domenic_> | nah two weeks sounds like a perfect incentive |
| 19:34 | <arunranga> | I mean, are not exactly. |
| 19:35 | <Domenic_> | tyoshino ^ |
| 19:35 | <arunranga> | So, take two weekends, if you aren’t slammed? Three if you are? |
| 19:35 | <arunranga> | I’m not totally blocked on you. |
| 19:35 | <arunranga> | I can tweak other things. |
| 19:35 | <Domenic_> | Sounds good :) |
| 19:35 | <arunranga> | But should also fix my FileAPI bugs *mumble mumble* |
| 19:36 | <Domenic_> | I want streams to succeed and FS is like use case #1 for streams so I am very motivated to make them work for you. |
| 19:36 | darobin | looks at arunranga sheepishly |
| 19:37 | <arunranga> | Domenic_ oooh synergy! |
| 19:38 | <arunranga> | Domenic_ well, we’ll have to unleash sicking on you :-) He’s got strong opinions about Streams vs. AbortableProgressPromise, etc. |
| 19:38 | <arunranga> | Also, the use cases are legion. |
| 19:47 | <Domenic_> | arunranga: haha great. I talked streams with sicking recently at the TAG meeting but we didn't talk about vs. AbortableProgressPromise in particular. |
| 20:06 | <tyoshino> | o |
| 20:06 | <Ms2ger> | p |
| 20:09 | <sicking> | Domenic_: streams and AbortableProgressPromise actually has quite different use cases. But we should definitely add streams to filesystem |
| 20:10 | <sicking> | Domenic_: filesystem needs both async-generator "object Streams", as well as IO streams |
| 20:10 | <Domenic_> | sicking: object streams being for e.g. directory listings? |
| 20:10 | <sicking> | Domenic_: yup |
| 20:10 | <Domenic_> | yeah interestingly even node.js doesn't have those |
| 20:10 | <sicking> | iirc it's only needed for directory listings |
| 20:11 | <tyoshino> | sg |
| 20:11 | <sicking> | Domenic_: oh! node.js just returns an array with all the names? |
| 20:11 | <Domenic_> | sicking: yeah, it's kind of embarassing |
| 20:12 | <sicking> | hehe |
| 20:12 | <sicking> | Domenic_: hopefully we can do better :) |
| 20:12 | <sicking> | Domenic_: and then have node.js implement our filesystem |
| 20:12 | <Domenic_> | yesss |
| 20:12 | <tyoshino> | http://nodejs.org/api/fs.html#fs_fs_readdir_path_callback |
| 20:14 | <sicking> | Domenic_: and have filesystem https://www.youtube.com/watch?v=2BRXmgcBHBM#t=75 |
| 20:14 | sicking | hopes he got the right quote. |
| 20:14 | sicking | is on mute |