2024-04-12 [10:54:20.0613] Hello everyone! [11:04:25.0761] is the bot in the room with us right now? 👀 [11:04:46.0025] doesn't look like it [11:06:48.0382] it takes a bit [11:08:32.0863] Is there any way we could set the signals logo as the avatar to the room? [11:08:46.0977] https://github.com/tc39/proposal-signals/blob/main/signals-logo.png [11:08:52.0901] fine if it's a little cropped [11:10:01.0156] https://matrixlogs.bakkot.com/TC39_Signals/2024-04-12 🚀 [11:12:11.0630] Thank you! [11:12:13.0517] irrationally bothering me that the lights are not evenly spaces in the logo [11:12:26.0747] * irrationally bothering me that the lights are not evenly spaced in the logo [11:12:28.0396] :old-man-yells-at:signals: [11:12:30.0841] oh actually I got an update which fixes the spacing, I should update it... [11:12:36.0820] * :old-man-yells-at-signals: [11:12:38.0696] I'm surprised that you're the first person to point it out [11:12:46.0045] small format logo (suitable for this context) in progress [11:13:13.0748] also we can still iterate on this; any feedback is welcome [11:14:24.0818] PRs welcome to put this in various places (but unfortunately I don't have the SVG yet) [11:14:51.0645] my favorite part about this logo is the way the oval tapers down just slightly [11:14:55.0748] it creates some movement [11:14:55.0778] can we get the lights horizontally aligned? [11:15:19.0685] oh are they not? I wasn't sure if I was imagining that [11:15:35.0383] The circles kind of feel like a fingerprint. Which is cool but unfortunately irrelevant to Signals :) [11:15:59.0239] no they are radio signals! maybe [11:16:08.0189] all this makes me glad I don't work at a marketing agency anymore [11:16:37.0494] the only proper way to make a logo is to hand-write the SVG [11:16:43.0653] so then you don't get any alignment wrong [11:17:11.0063] facts [11:19:49.0422] oh I do have the semi-fixed svg: 2024-04-14 [06:37:39.0003] I made it! [06:37:45.0495] Hello everyone 👋 [07:32:39.0859] Hi [07:34:41.0133] > <@littledan:matrix.org> no they are radio signals! maybe I think it'd be more apparent if the lines were shorter? Like making a cone-ish shape instead of overlapping semicircles [08:29:31.0972] > <@usharma:igalia.com> I think it'd be more apparent if the lines were shorter? Like making a cone-ish shape instead of overlapping semicircles I think i agree. Tbh, i thought it was more a fingerprint until reading this [08:31:27.0655] Should we add the archive to the channel description? https://matrixlogs.bakkot.com/TC39_Signals/ [11:05:31.0893] hey everyone 👋 2024-04-15 [06:36:13.0495] > <@usharma:igalia.com> I think it'd be more apparent if the lines were shorter? Like making a cone-ish shape instead of overlapping semicircles huh sorry what do you mean? [06:36:22.0225] yeah I'll try to make sure it doesn't look like a fingerprint [06:36:28.0269] sorry for being too vague [06:36:43.0030] np all feedback is good; I'm meeting with the designer this afternoon anyway [06:36:52.0351] I will give a visual example of what I mean [06:57:37.0403] well, how would that be integrated with the rest of the logo? also what problem are you trying to solve? [07:18:50.0407] basically the surrounding lines that are supposed to look like a radio signal don't look like one IMO [07:19:07.0388] and nullvoxpopuli mistook the entire thing for a fingerprint because of that [07:19:29.0932] I just proposed that changing the width of the lines like this would make it more... signal-y [07:19:48.0329] well, there's a particular resemblance to the Apple fingerprint logo (which I guess isn't used so much anymore now that we have faceID) [07:20:01.0289] but I kinda like the rings visually; I'm not sure how to integrate the radio cone [07:20:39.0754] I like the rings visually too [07:20:53.0399] I'm just proposing reducing the length (angle?) of the arc [07:21:12.0622] so that it's a tad more conical and people find it easier to see that they're resembling a radio signal [07:21:15.0109] Probably tracking how different users interact in different ways with a page, causing signal computation to flow more towards one possibility or another, is a potential fingerprinting vector :) [07:21:24.0309] also there's a common radio tower image with rings in different directions (some of the earlier drafts included more of a tower; in this one the traffic light is trying to be the radio tower kinda [07:21:41.0327] * Probably tracking how different users interact in different ways with a page, causing signal computation to flow more towards one possibility or another, is a potential fingerprinting vector :) /s [07:22:21.0715] like in this image [07:22:50.0902] just because the arcs are more or less shaped into a cone I think it's easier to see that it's a signal [07:23:36.0985] oh I see... [07:25:03.0749] I guess the rings could be made incrementally more cone-shaped without upsetting the whole design overall, right? [07:25:16.0818] by sort of trimming the outer ones a little [07:25:30.0177] absolutely [07:25:50.0579] everything would remain pretty much exactly where it is [07:26:07.0554] but you'd shorten the angle of the signal arcs [07:26:14.0874] right [07:26:34.0832] so I guess you'd be left with a bit of whitespace on the sides [07:26:38.0105] even just a little bit (e.g., if it's a 120 degree arc, but cut off consistently at all levels) it might be OK [07:26:55.0580] actually yes [07:27:11.0932] if you made them all the same angle it could work even just like that 2024-04-16 [17:21:06.0304] > <@usharma:igalia.com> just because the arcs are more or less shaped into a cone I think it's easier to see that it's a signal Ye, actual radio signals are shaped like a rope with adhd [03:48:15.0500] Hello 👋 Just stumbled upon [this issue](https://github.com/tc39/proposal-signals/issues/96) and thought about reaching out. For VS Code, we have an internal [implementation of observables](https://github.com/microsoft/vscode/blob/5ccc2db0a2ed24e8c0dc3ecd7d515e4f76c87e69/src/vs/base/common/observableInternal/base.ts#L22-L88). You can find some demo usage ([here](https://github.com/microsoft/vscode/blob/5ccc2db0a2ed24e8c0dc3ecd7d515e4f76c87e69/src/vs/base/test/common/observable.test.ts#L18)). While our implementation/API is heavily inspired by MobX, it tries to include some of our learnings of using MobX in other projects, mostly by making many things less magic and more debuggable. Since most of VS Code uses plain simple fields and change-events, we wanted to make it very clear what is observable and what not and when a derived/autorun subscribes to something observable. Observable usage is not yet very widespread in the VS Code source and it is mostly driven by me, but it is already used in core components, such as some editor contributions and the diff editor and so far the very explicit API style paid off. However, I also understand the advantages of transparent observables as presented by this proposal and don't necessarily see a need of this proposal to support use-cases such as ours, where we wanted a more explicit API. There are some things though where we also could use some browser support, mostly around inferring the name of an observable from its variable name/field. [04:27:33.0558] Something novel (to my knowledge) of our observable implementation is the concept of delta information, which can be used to inform observers how or why a value changed. We call observables that don't have a state and just delta information a "signal", which, alone, basically just represents an event with event args. However, observables and signals can be updated/triggered in the same transaction and also be handled at once in the same derived/autorun, which enables some new use cases of observables. This is quite useful when it matters how a certain state was reached, and not just what the state is. [04:30:26.0199] * Something novel (to my knowledge) of our observable implementation is the concept of delta information, which can be used to inform observers how or why a value changed. We call observables that don't have a state and just delta information a "signal", which, alone, basically just represents an event with event args. However, observables and signals can be updated/triggered in the same transaction and also be handled at once in the same derived/autorun, which enables some new use cases of observables. This is quite useful when it matters how a certain state was reached, and not just what the state is. I think this "signal" part can be used to bring some rxjs ideas to observables. [06:59:18.0891] ah, interesting! there seems to be a significant group of existing implementations that use "reader capabilities" of some sort. I'd been wondering if we should provide a facility to move between explicit and implicit readers, something like `trackImplicitly: (read: Reader, f: () => R) => R` `trackExplicitly: (f: (read: Reader) => R) => R` with `get` taking an optional Reader. ... though this does have the unfortunate implication that library code would end up encouraged to use the explicit plumbing version universally (`undefined` plumbs through just fine if the caller wants to be implicit). might be too much bifurcation, and we didn't have many examples/participants using it at scale, which is why we left it out of this first iteration. are you using the readers for async tracking/lexical capture of the tracking environment, or just for the sake of explicitness? [07:11:09.0646] > though this does have the unfortunate implication that library code would end up encouraged to use the explicit plumbing version universally I agree that mixing explicit and implicit implementations might be tricky and potentially confusing. > are you using the readers for async tracking/lexical capture of the tracking environment, or just for the sake of explicitness? For now, just for the sake of explicitness, as we didn't need tracking after an await yet. [07:12:11.0750] > <@hediet:matrix.org> Something novel (to my knowledge) of our observable implementation is the concept of delta information, which can be used to inform observers how or why a value changed. We call observables that don't have a state and just delta information a "signal", which, alone, basically just represents an event with event args. However, observables and signals can be updated/triggered in the same transaction and also be handled at once in the same derived/autorun, which enables some new use cases of observables. This is quite useful when it matters how a certain state was reached, and not just what the state is. I think this "signal" part can be used to bring some rxjs ideas to observables. I've been looking into a couple of very different delta-based systems (https://signia.tldraw.dev/, and separately differential dataflow which if you squint is very related) and might have to go chew on yours for a bit to tell where it places [07:14:59.0064] [Here is an example of how emitting and handling deltas works.](https://github.com/microsoft/vscode/blob/5ccc2db0a2ed24e8c0dc3ecd7d515e4f76c87e69/src/vs/base/test/common/observable.test.ts#L304-L345) [07:19:42.0667] ah, are your deltas and deriveds both eager? signia's thing is making them lazy (so deltas are lossy -- if you don't read them they'll be discarded instead of piling up), so seems pretty different [07:20:34.0597] the deltas are not lazy per se, but of cause they could be backed by an lazy implementation [07:20:54.0159] signias approach is also very interesting! [07:21:10.0566] the deriveds in our implementation are as lazy as possible [07:21:26.0742] * the deriveds in our implementation are as lazy as possible, but at the moment they cannot produce deltas [07:22:13.0449] can they consume them? [07:22:26.0022] * the deriveds in our implementation are as lazy as possible, but at the moment they cannot produce deltas (so currently only observable values and signals, i.e. atoms, can produce deltas, which can be handled in deriveds or autoruns, but there is no derived implementation that can produce them yet) [07:22:40.0848] yes, they can consume them - the derived example would be analog to the autorun one [07:23:43.0740] deltas can be consumed lazily or eagerly, that depends on the implementation (see autorunHandleChanges, the user can either push all the deltas into an array or combine them using a different method). [07:25:00.0077] ahh, so the consumer sort of "receives them" eagerly but separately from their reactive body rerunning, so they get to choose whether to buffer or process the information online? [07:26:12.0741] exactly. They are also not allowed to call into other code when they receive them [07:26:34.0777] * exactly. They are also not allowed to call into other code when they receive them, because other observables might not have received the event at this point yet [07:26:42.0701] * exactly. They are also not allowed to call into other code when they receive the deltas, because other observables might not have received the event at this point yet [07:27:55.0764] "delta stuff" in some sense or another seems necessary to get an efficient way to (eg) "count how many of these input signals are `true`", so I'm definitely interested in figuring out what minimal-but-sufficient support they'd need from the implementation [07:28:19.0544] (ideally minimal, sufficient, and not too opinionated -- not guaranteed to be a bar that's clearable...) [07:28:50.0400] [Here is a production example](https://github.com/microsoft/vscode/blob/0a141d23179c76c5771df25a43546d9d9b6ed71c/src/vs/editor/contrib/inlineCompletions/browser/inlineCompletionsModel.ts#L93) (and yes, this derived has some "ugly" side effects and is basically an autorun, but that way callers can wait on the fetch promise) [07:32:33.0088] do you guarantee some particular order in the changes each thing gets to fold over? [07:33:45.0475] (I'm squinting at this (on a phone) and realizing it could be cousin to Jane Street `incremental`'s `unorderedFold` nodes) [07:35:32.0410] what do you mean with "gets to fold over"? The only guarantee is that an observer receives all deltas from an observable in the same order. However, if an observable has multiple observers, it is not specified which observer gets the change first. But this does not matter, because the observer is not allowed to interact with other observers at this point. [07:36:51.0564] btw, a `countTrues(o: IObservable[]): IObservable` can also be efficiently implemented using an `autorun` for each item in `o`. However, transactions cannot see through such side-effect autoruns anymore [07:39:44.0679] the view from a single observer that observes multiple observables, I meant -- maybe fold isn't the intended way to think about it, I just saw an "initial summary" and a "summarize previous summary + incoming context into new summary" and jumped to the "ah, folding over a stream" framing [07:40:30.0213] > <@hediet:matrix.org> btw, a `countTrues(o: IObservable[]): IObservable` can also be efficiently implemented using an `autorun` for each item in `o`. However, transactions cannot see through such side-effect autoruns anymore ... however that might be circumvented by having a derived for each item in `o` that has a side effect which increments/decrements some shared count variable. Then you can create one derived that reads all these deriveds and returns the count field - I think this should give you an optimal solution without deltas. [07:45:28.0349] don't you lose if you ever have to rerun that one derived that reads all the others, or if you ever have to traverse each edge back towards the N deriveds it reads? but yeah that's sort of what you want -- you lose the topology/scheduling constraint if you just use an autorun, and the derived version tries to recover that [07:52:05.0398] > don't you lose if you ever have to rerun that one derived that reads all the others Right, this would require a derived that does not need to resubscribe to all observables when it reruns. [07:57:37.0574] Btw. our implementation has a different problem (which I guess mobx also has): When a source observable is changed, where n deriveds depend on it transitively, then updating that source observable is O(n), even if the change stops after the first derived. [08:11:24.0897] y eah that's a thing; it seems pretty inescapable in lazy-deriveds systems. even when you rerun the minimal set of deriveds, you sometimes do more traversal/bookkeeping than would be ideal [08:12:52.0934] "deep graph" "high fanout" "high fan-in" are the stress tests... along with maybe "toggling which nodes are observed" for systems that have that concept 2024-04-17 [05:20:36.0866] hello! I've finally had some time to write up my thoughts on Relays and Effects, could use feedback if anyone has a chance before I publish it on my blog 😄 https://gist.github.com/pzuraq/bb9f474bfb9a25cb7961f151bfecd318 [05:24:31.0154] also, is Justin Fagnani in here by chance? Trying to get a hold of him [05:25:48.0284] ah, nvm, I just need to figure out how Matrix works lol 2024-04-18 [06:52:49.0941] ok, have updated the post based on early feedback, and added a section on why we needed Watchers [10:59:56.0735] and now the full thing is public: https://www.pzuraq.com/blog/on-signal-relays 2024-04-30 [07:04:18.0406] Signals community call starting in 1 hour at https://us02web.zoom.us/j/84763180621?pwd=bjVBT1B4dzdhdk80V3lQZG41eEVCZz09 [07:06:26.0526] > <@littledan:matrix.org> Signals community call starting in 1 hour at https://us02web.zoom.us/j/84763180621?pwd=bjVBT1B4dzdhdk80V3lQZG41eEVCZz09 not on the TC39 calendar? 🧐 [08:01:55.0938] https://docs.google.com/document/d/1I9kYCHLmLG3lfM0HlMbDPLY0huWST4zkGmELDxlPodI/edit [08:02:08.0287] > <@softwarechris:matrix.org> not on the TC39 calendar? 🧐 I did file an issue in the Reflector for this