Re: Argon: an alternative parser for command-line arguments
On Wednesday, 9 March 2016 at 18:56:10 UTC, Markus Laker wrote: To support git-style syntax while using Argon, I'd do this: 1. Find the (possibly empty) initial sequence of tokens that start with a dash. Pass them to an Argon-derived class which we'll call `Stem', which parses them. 2. If no more tokens exist (as in "my-command --help"), do what we can with the options we've seen, and then exit. 3. Otherwise, the next token must be a subcommand name: we've seen something "my-command --verbose display-widgets --paginate". Use that token to select a leaf class, also derived from Argon. There's one leaf class per subcommand. 4. Pass the remaining tokens (in this example, just "--paginate") to the selected leaf pass for parsing. Also pass a reference to Stem, so that the leaf code can use any options garnered by Stem. It is a wrong way, because switches may have arguments (not starting with a dash). I am now considering to write a new object-oriented command line parser from scratch because it is sometimes easier to write new code than to understand other's one. It shouldn't be hard to write some reusable code to do this, if it were a common requirement.
Re: GtkD Blog Now Up and Running
On Friday, 25 January 2019 at 21:19:45 UTC, Ron Tarrant wrote: PS: And let me know if you find any inaccuracies or if something isn't clear. Great Job! ^_^ and for dub type of project, just add `gtk-d` as a dependency, it works well both on windows and linux right out of box, the only thing is on windows we need to install runtime for gtkd.org first, and ldc or dmd only support MS buildtools to link aginst with gtkd runtime, the default mingw linker will not work. Thanks for the great work!
Re: Spasm 0.1.3 released - with bindings to web apis
On Saturday, 26 January 2019 at 10:24:05 UTC, Sebastiaan Koppe wrote: Spasm is a betterC library for web development that uses LDC to compile to WebAssembly, and I just released a major update. It now has bindings to most web api's, like the dom, fetch, audio, webgl, etc. [...] See the repo for more info: https://github.com/skoppe/spasm It is still a WIP but I am getting there. This is really cool; nice work! Over the past 6 months I've been working a lot with .Net's WASM implementation, code-named Blazor. I estimate I can build GUI applications at 20% the development cost, while also getting portability, and a more rich features set (alpha transparency, flow layout, SVG, video, GL, etc...). Bundled with Electron, it makes for a convenient cross-platform application GUI framework. It's actually changed everything I do for desktop and ARM Cortex-A embedded GUI work (still need something for Cortex-M, though), and I don't think I'll be going back. The upcoming .Net Core 3.0 will include something called Razor Components, previously called Server-Side Blazor. It uses Microsoft's SignalR (think web sockets) to create signals on the server, slots on the client, and to push UI render changes to the client. Are you aware of SignalR, and do you see something similar eventually being added to Spasm? Also, what are the limitations that prevent the D runtime (just druntime, not Phobos) from being ported to WASM? Again, nice work! Mike
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/26/2019 8:28 AM, Rubn wrote: [...] The point is, the DIP needs to spell this out in an organized and complete fashion, like any proper spec does. We all want a better specified language, let's make it happen.
Re: GtkD Blog Now Up and Running
On Friday, 25 January 2019 at 21:16:59 UTC, Ron Tarrant wrote: Hi y'all, As of January 11, 2019, http://gtkdcoding.com is up. It's a blog, it's a github page, it's simple examples of how to use GtkD for all that GUI stuff. My approach is to lay out a firm foundation for both imperative and object-oriented paradigms, then build from there, taking things one step at a time. This being Friday, the 4th post went up this morning. Please do let me know if you find it useful. And why did I wait until now to announce? Well, on day one, it seemed a bit silly to announce with only one post. After the second and third, well... I still didn't feel there was enough to warrant excitement. But four posts? Now that's something to speak up about, ain't it? Yup. That's what I thought, too. Hi Ron, Glad to see this gtkd-programming blog up. When I started using Gtkd I gathered several tutorials[1][2] (they are old) and more recently found this project[3] from Carlos Soriano which covers meson + flatpak. Hope they are good for you. Antonio [1] https://sites.google.com/site/gtkdtutorial/ [2] http://britseyeview.com/software/articles/gsgtkd.html [3] https://gitlab.com/csoriano/GtkDApp
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Saturday, 26 January 2019 at 06:15:22 UTC, Walter Bright wrote: On 1/25/2019 7:44 PM, Manu wrote: I never said anything about 'rvalue references', The DIP mentions them several times in the "forum threads" section. I see you want to distinguish the DIP from that; I recommend a section clearing that up. However, my points about the serious problems with @disable syntax remain. A section comparing with the C++ solution is necessary as well, more than the one sentence dismissal. For example, how C++ deals with the: void foo(const int x); void foo(const int& x); situation needs to be understood and compared. Failing to understand it can lead to serious oversights. For example, C++ doesn't require an @disable syntax to make it work. [...] Should `s` be promoted to an int temporary, then pass the temporary by reference? I can find no guidance in the DIP. What if `s` is a uint (i.e. the implicit conversion is a type paint and involves no temporary)? As per the DIP; yes, that is the point. The text you seek is written: "[...]. The user should not experience edge cases, or differences in functionality when calling fun(int x) vs fun(ref int x)." I don't see how that addresses implicit type conversion at all. Anything that could be implicitly converted to use foo(int) can be implicitly converted to pass a ref to the temporary that was implicitly converted to int into foo(ref int). No rules change in this regard. If you don't see how this address type conversion perhaps a code sample might help? The one that was given with short: void foo(ref int); void bar(int); bar( short(10) ); // is ok foo( short(10) ); // expected to be ok short->int ; ref to temp passed to foo Just as bar(int) can be passed a short(10), foo(ref int) can be passed a reference to the temporary that was created as well. Don't accept naked ref unless you want these semantics. There is a suite of tools offered to use where this behaviour is undesirable. Naked `ref` doesn't do anything particularly interesting in the language today that's not *identical* semantically to using a pointer and adding a single '&' character at the callsite. It's not good enough. The DIP needs to specifically address what happens with implicit conversions. The reader should not be left wondering about what is implied. I often read a spec and think yeah, yeah, of course it must be that way. But it is spelled out in the spec, and reading it gives me confidence that I'm understanding the semantics, and it gives me confidence that whoever wrote the spec understood it. (Of course, writing out the implications sometimes causes the writer to realize he didn't actually understand it at all.) Furthermore, D has these match levels: 1. exact 2. const 3. conversion 4. no match If there are two or more matches at the same level, the decision is made based on partial ordering. How does adding the new ref/value overloading fit into that? The DIP goes over this, though not in a lot of detail. All the same rules apply as with the current implementation. Where there would be a compiler error trying to pass an rvalue would instead forward the value. Effectively what is being implemented is the following (for type matching only): void foo( ref int ); void foo( int value ) { foo( value ); } Anything that would have been passed to foo(int) is passed to foo(ref int) as a reference to a temporary instead. No rules are changed in this regard for matching, all the same rules apply (as stated in the DIP). It's pretty clear, unless you can give a specific problem faced where this doesn't hold? D is pretty strict to ensure rvalues aren't passed to ref's and that's what makes this relatively simple to implement without changing matching rules.
Re: Spasm 0.1.3 released - with bindings to web apis
On Saturday, 26 January 2019 at 10:24:05 UTC, Sebastiaan Koppe wrote: Spasm is a betterC library for web development that uses LDC to compile to WebAssembly, and I just released a major update. It now has bindings to most web api's, like the dom, fetch, audio, webgl, etc. So you can do things like this: --- import spasm.bindings; import spasm.dom; import spasm.types; extern (C) export void _start() { auto elem = document.createElement("div").as!HTMLElement; elem.style.backgroundColor = "green"; elem.innerHTML = "BLA BLA!"; elem.addEventListener("mouseover",(event){ console.log("onmouseover"); console.log(event); console.log(event.as!MouseEvent.clientX); }); auto root = document.querySelector("body").front; root.appendChild(elem); } --- And have it Just Work. See the repo for more info: https://github.com/skoppe/spasm It is still a WIP but I am getting there. amazing! I would really like to try it but it seem the precompiled LDC version doesn't support the wasm output and I have no idea what that wercker stuff is you mentioned or how to use the container you sent with compiling on my local filesystem and not inside a sandbox :/ Still looks great having this, especially now with all these APIs. I would really like to try making WebGL run with this in the future Great work, keep it up!
Spasm 0.1.3 released - with bindings to web apis
Spasm is a betterC library for web development that uses LDC to compile to WebAssembly, and I just released a major update. It now has bindings to most web api's, like the dom, fetch, audio, webgl, etc. So you can do things like this: --- import spasm.bindings; import spasm.dom; import spasm.types; extern (C) export void _start() { auto elem = document.createElement("div").as!HTMLElement; elem.style.backgroundColor = "green"; elem.innerHTML = "BLA BLA!"; elem.addEventListener("mouseover",(event){ console.log("onmouseover"); console.log(event); console.log(event.as!MouseEvent.clientX); }); auto root = document.querySelector("body").front; root.appendChild(elem); } --- And have it Just Work. See the repo for more info: https://github.com/skoppe/spasm It is still a WIP but I am getting there.
Re: GtkD Blog Now Up and Running
On Saturday, 26 January 2019 at 09:32:53 UTC, Andre Pany wrote: On Friday, 25 January 2019 at 21:16:59 UTC, Ron Tarrant wrote: Hi y'all, As of January 11, 2019, http://gtkdcoding.com is up. It's a blog, it's a github page, it's simple examples of how to use GtkD for all that GUI stuff. My approach is to lay out a firm foundation for both imperative and object-oriented paradigms, then build from there, taking things one step at a time. This being Friday, the 4th post went up this morning. Please do let me know if you find it useful. And why did I wait until now to announce? Well, on day one, it seemed a bit silly to announce with only one post. After the second and third, well... I still didn't feel there was enough to warrant excitement. But four posts? Now that's something to speak up about, ain't it? Yup. That's what I thought, too. Great posts! Is there a reason you do not use dub? With dub it is even possible to set default architecture to x86_64 in the settings file. And the command line looks a bit less cryptic for new users. Defintely worths a post on r/programming! Kind regards Andre There was even the idea to support custom skeletons for dub init: dub init sample1 -t gtdk This would create a dub skeleton folder with a sample gtkd source file. Martin Nowak had here a great idea how to achieve this https://github.com/dlang/dub/pull/600 This feature would become quite handy. Kind regards Andre
Re: GtkD Blog Now Up and Running
On Friday, 25 January 2019 at 21:16:59 UTC, Ron Tarrant wrote: Hi y'all, As of January 11, 2019, http://gtkdcoding.com is up. It's a blog, it's a github page, it's simple examples of how to use GtkD for all that GUI stuff. My approach is to lay out a firm foundation for both imperative and object-oriented paradigms, then build from there, taking things one step at a time. This being Friday, the 4th post went up this morning. Please do let me know if you find it useful. And why did I wait until now to announce? Well, on day one, it seemed a bit silly to announce with only one post. After the second and third, well... I still didn't feel there was enough to warrant excitement. But four posts? Now that's something to speak up about, ain't it? Yup. That's what I thought, too. Great posts! Is there a reason you do not use dub? With dub it is even possible to set default architecture to x86_64 in the settings file. And the command line looks a bit less cryptic for new users. Defintely worths a post on r/programming! Kind regards Andre