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
