digitalmars.D.announce - Project Highlight: Spasm
- Mike Parker (10/10) Feb 28 2019 You may have seen Sebastiaan Koppe's announcements about his work
- Radu (11/21) Feb 28 2019 Nice!
- Sebastiaan Koppe (16/25) Feb 28 2019 At least partly. One memory issue spasm has is to release JS
- Radu (10/35) Feb 28 2019 Dip1000 would make reference counting safe.
- Sebastiaan Koppe (4/10) Mar 01 2019 :)
- Radu (2/13) Mar 01 2019 yes, dip1000 is usable, albeit poorly documented.
- kinke (3/4) Feb 28 2019 Interesting read, thx Mike and Sebastiaan. [And I appreciate the
- Olivier FAURE (21/25) Mar 01 2019 I've seen spasm around quite a few times, but reading this
- Sebastiaan Koppe (9/24) Mar 01 2019 Maybe. But in the beginning no one is willing to give it :)
- Olivier FAURE (3/6) Mar 01 2019 I'll create an issue once I've written down my thoughts on the
- Jordan Wilson (4/21) Mar 01 2019 Nice example of collaboration and good attitude. One day hope to
You may have seen Sebastiaan Koppe's announcements about his work with D and WebAssembly, the most recent regarding his project, Spasm. He sent me a great deal of information about the project, from which I was able to put together the first Project Highlight of 2019. He talks about how the project came about, what it does, and where it's going. The Blog: https://dlang.org/blog/2019/02/28/project-highlight-spasm/ Reddit: https://www.reddit.com/r/programming/comments/avqioi/spasm_d_to_webassembly_for_single_page_apps/
Feb 28 2019
On Thursday, 28 February 2019 at 12:24:27 UTC, Mike Parker wrote:You may have seen Sebastiaan Koppe's announcements about his work with D and WebAssembly, the most recent regarding his project, Spasm. He sent me a great deal of information about the project, from which I was able to put together the first Project Highlight of 2019. He talks about how the project came about, what it does, and where it's going. The Blog: https://dlang.org/blog/2019/02/28/project-highlight-spasm/ Reddit: https://www.reddit.com/r/programming/comments/avqioi/spasm_d_to_webassembly_for_single_page_apps/Nice! Re. the memory management section, I wonder if reference counting using dip1000 would work for memory management. You could also use the type system information for a D malloc implementation that uses free lists for known sizes. Something in line with https://github.com/JinShil/memcpyD It is quite interesting to see that WebAssembly lines up pretty close to bare metal programming, maybe there are some synergies here that can be exploited and create the minimum runtimes for both.
Feb 28 2019
On Thursday, 28 February 2019 at 12:47:32 UTC, Radu wrote:Re. the memory management section, I wonder if reference counting using dip1000 would work for memory management.At least partly. One memory issue spasm has is to release JS objects once D code is done with them. The approach I am likely to take is to simply disallow more than 1 reference to a JS object, and then when that reference is destroyed, to also destroy the JS object. Basically a non-copyable struct with a destructor. Over time this can be expanded with dip1000 to allow having more references to the same JS object as long as the compiler can prove it doesn't escape and has shorter lifetime. I don't see how dip1000 can help free memory though.You could also use the type system information for a D malloc implementation that uses free lists for known sizes. Something in line with https://github.com/JinShil/memcpyDI saw memcpyD before. In fact I used part of the implementation in a (uncompleted) wasm port of druntime. But again, I don't see how it would help with freeing unused objects.It is quite interesting to see that WebAssembly lines up pretty close to bare metal programming, maybe there are some synergies here that can be exploited and create the minimum runtimes for both.Definitely.
Feb 28 2019
On Thursday, 28 February 2019 at 20:36:57 UTC, Sebastiaan Koppe wrote:On Thursday, 28 February 2019 at 12:47:32 UTC, Radu wrote:Dip1000 would make reference counting safe. Memory management should be handled by reference counting. RC should delegate malloc, free to an allocator. Hence my suggestion to implement a typed malloc. Probably an allocator and memcpy friends that works in betterc without any C dependencies would worth its own dub package :) The complexity of the allocator and ref counting is drastically reduced as there is no multithreading involved.Re. the memory management section, I wonder if reference counting using dip1000 would work for memory management.At least partly. One memory issue spasm has is to release JS objects once D code is done with them. The approach I am likely to take is to simply disallow more than 1 reference to a JS object, and then when that reference is destroyed, to also destroy the JS object. Basically a non-copyable struct with a destructor. Over time this can be expanded with dip1000 to allow having more references to the same JS object as long as the compiler can prove it doesn't escape and has shorter lifetime. I don't see how dip1000 can help free memory though.You could also use the type system information for a D malloc implementation that uses free lists for known sizes. Something in line with https://github.com/JinShil/memcpyDI saw memcpyD before. In fact I used part of the implementation in a (uncompleted) wasm port of druntime. But again, I don't see how it would help with freeing unused objects.It is quite interesting to see that WebAssembly lines up pretty close to bare metal programming, maybe there are some synergies here that can be exploited and create the minimum runtimes for both.Definitely.
Feb 28 2019
On Friday, 1 March 2019 at 07:28:06 UTC, Radu wrote:Dip1000 would make reference counting safe. Memory management should be handled by reference counting. RC should delegate malloc, free to an allocator.I see. Yeah, RC could work. Sure.Hence my suggestion to implement a typed malloc. Probably an allocator and memcpy friends that works in betterc without any C dependencies would worth its own dub package :):) dip1000 is usable right?
Mar 01 2019
Radu <void null.pt> On Friday, 1 March 2019 at 08:22:24 UTC, Sebastiaan Koppe wrote:On Friday, 1 March 2019 at 07:28:06 UTC, Radu wrote:yes, dip1000 is usable, albeit poorly documented.Dip1000 would make reference counting safe. Memory management should be handled by reference counting. RC should delegate malloc, free to an allocator.I see. Yeah, RC could work. Sure.Hence my suggestion to implement a typed malloc. Probably an allocator and memcpy friends that works in betterc without any C dependencies would worth its own dub package :):) dip1000 is usable right?
Mar 01 2019
On Thursday, 28 February 2019 at 12:24:27 UTC, Mike Parker wrote:...Interesting read, thx Mike and Sebastiaan. [And I appreciate the many cross-links.]
Feb 28 2019
On Thursday, 28 February 2019 at 12:24:27 UTC, Mike Parker wrote:The Blog: https://dlang.org/blog/2019/02/28/project-highlight-spasm/ Reddit: https://www.reddit.com/r/programming/comments/avqioi/spasm_d_to_webassembly_for_single_page_apps/I've seen spasm around quite a few times, but reading this article has made me want to actually take a look at the documentation and try to understand how the library works. Would the author be interested in structural level-feedback? As in, not "I wish there was this feature", but "I think the way you're doing X and Y is wrong, and the project would probably benefit from a complete refactoring". I realize this kind of feedback is pretty irritating to get and hard to act on several months into the project, hence why I'm asking. The short version is, it's pretty clear Sebastiaan has designed spasm with the goal of giving the library compile-time information on the structure of the widgets to render, to avoid React's superfluous updates and prop comparison; that said, I think it's possible to give the library that information without losing React's "your components are all functions, don't worry about how the data is updated" simplicity, which I think is an area where spasm comes up short. Anyway, I'm ready to spend more time documenting for a deeper analysis if Sebastiaan is interested.
Mar 01 2019
On Friday, 1 March 2019 at 13:26:58 UTC, Olivier FAURE wrote:Would the author be interested in structural level-feedback? As in, not "I wish there was this feature", but "I think the way you're doing X and Y is wrong, and the project would probably benefit from a complete refactoring". I realize this kind of feedback is pretty irritating to get and hard to act on several months into the project, hence why I'm asking.Maybe. But in the beginning no one is willing to give it :) I am very much interested in qualitative feedback on spasm's internals and its design. It is the main reason I announced the project. I am completely willing to overhaul each and every line if that benefits the project.The short version is, it's pretty clear Sebastiaan has designed spasm with the goal of giving the library compile-time information on the structure of the widgets to render, to avoid React's superfluous updates and prop comparison; that said, I think it's possible to give the library that information without losing React's "your components are all functions, don't worry about how the data is updated" simplicity, which I think is an area where spasm comes up short.That would be awesome. I initially tried very hard to stick to React/JSX functional rendering. I could not find a way to make it a zero-cost abstraction, but maybe you have more success!
Mar 01 2019
On Friday, 1 March 2019 at 14:27:36 UTC, Sebastiaan Koppe wrote:That would be awesome. I initially tried very hard to stick to React/JSX functional rendering. I could not find a way to make it a zero-cost abstraction, but maybe you have more success!I'll create an issue once I've written down my thoughts on the subject.
Mar 01 2019
On Friday, 1 March 2019 at 14:27:36 UTC, Sebastiaan Koppe wrote:On Friday, 1 March 2019 at 13:26:58 UTC, Olivier FAURE wrote: I am very much interested in qualitative feedback on spasm's internals and its design. It is the main reason I announced the project. I am completely willing to overhaul each and every line if that benefits the project.Nice example of collaboration and good attitude. One day hope to contribute in such a manner. JordanThe short version is, it's pretty clear Sebastiaan has designed spasm with the goal of giving the library compile-time information on the structure of the widgets to render, to avoid React's superfluous updates and prop comparison; that said, I think it's possible to give the library that information without losing React's "your components are all functions, don't worry about how the data is updated" simplicity, which I think is an area where spasm comes up short.That would be awesome. I initially tried very hard to stick to React/JSX functional rendering. I could not find a way to make it a zero-cost abstraction, but maybe you have more success!
Mar 01 2019