Re: Sublime Text Syntax Definition Rewrite
On Thursday, 28 February 2019 at 00:30:24 UTC, Benjamin Schaaf wrote: Hello all, I've recently gotten a massive rewrite of the D syntax highlighting merged into the Sublime Text default packages. This has since been deployed in the most recent development version 3192 (license required) and will be shipping with the next stable. Anyone trying Sublime Text has probably noticed the poor D support. Here's a very incomplete list of everything that's been fixed/improved: * Functions, classes, interfaces, enums, structs, unions, templates and aliases are now properly indexed, making GoTo Definition work properly * Function/Template calls are properly marked, making GoTo Reference work properly * Nested comments now work as expected * Shebangs are properly highlighted * Ligatures are now properly supported * `..` no longer highlights as a floating point * Strings are now properly highlighted, including postfixes and delimited strings * Token strings actually highlight tokens now * Attributes, including UDAs, are highlighted properly * Automatic indentation is no longer broken (Typing `} catch...` would re-indent the line) * Arguments are highlighted as actual arguments * Contracts are properly highlighted now You can find the pr here: https://github.com/sublimehq/Packages/pull/1850 If you do find a bug with the syntax highlighting or just something that could be done better please leave a bug report on the repository, I'll be maintaining it for the foreseeable future: https://github.com/sublimehq/Packages/issues If you don't have a license you can still use the new syntax highlighting before the next stable build by cloning the repository and symlinking the `D` folder into your Sublime Text "Packages" directory (Details in the README). You can download Sublime Text here: https://www.sublimetext.com/3 Hope you enjoy! --- Full disclosure: I work for Sublime HQ. Though I'd love to, we don't use D internally for anything. Cool, thank you so much, much appreciated! https://steel1.ir/category/equipment/coffee-shop-equipment/
Re: Project Highlight: Spasm
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
Re: Project Highlight: Spasm
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.
Re: Project Highlight: Spasm
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!
Re: Project Highlight: Spasm
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.
Re: Project Highlight: Spasm
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.
Re: Project Highlight: Spasm
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?
