www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Project Highlight: Spasm

reply Mike Parker <aldacron gmail.com> writes:
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
next sibling parent reply Radu <void null.pt> writes:
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
parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
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/memcpyD
I 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
parent reply Radu <rad.racariu gmail.com> writes:
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:
 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/memcpyD
I 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.
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.
Feb 28
parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
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
parent Radu <void null.pt> writes:
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:
 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?
yes, dip1000 is usable, albeit poorly documented.
Mar 01
prev sibling next sibling parent kinke <noone nowhere.com> writes:
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
prev sibling parent reply Olivier FAURE <couteaubleu gmail.com> writes:
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
parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
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
next sibling parent Olivier FAURE <couteaubleu gmail.com> writes:
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
prev sibling parent Jordan Wilson <wilsonjord gmail.com> writes:
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.

 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!
Nice example of collaboration and good attitude. One day hope to contribute in such a manner. Jordan
Mar 01