Re: What's the secret to static class members
On Wednesday, 29 June 2016 at 15:40:57 UTC, Andrea Fontana wrote: On Wednesday, 29 June 2016 at 15:33:58 UTC, Guido wrote: The problem is actually much more profound. The classes need to be declared outside the main() scope. WTF?!?!?! I put them in main() so they would be in scope. This seems like a *MAJOR* design flaw with the language, not to mention the compiler not giving useful feedback. This decision, if it is a decision, makes no sense given all the attention to scoping rules. I'm not interested in trading one set of bad language decisions for another. Can someone fix this? I wonder which language you usually use in your programming experience. C++ I have all this business generally working in C++. I just wanted to try D for a production level quick project. So, the language is not ready. I'm really sad about this. I had hoped that I could get some useful work done. C++ is painfully slow to write & debug, but what can you do. As I said, why exchange one set of bad design decisions for another? On another topic, tuples seem to have a major problem as well. Tuple!(float, float, float) test; Tuple!(float, float, float) [] array_data; test[0] = 1.0; // works array_data[i][0] = 1.0; // doesn't work. Compile-time error, probably because the language itself doesn't have a dedicated extension for tuple elements that is distinguished from array dereferencing. This is the logical extension of how to access tuples. I normally use structs in C++, but since pointer arithmetic is really frowned upon in D, I decided to use Tuples. A mistake, I supposed. So, I've spent a huge amount of time getting ready to write in D. That's all wasted. I'll check back in another 10 years to see if your hobby language is still around. In the mean time, try to think about improving the compiler error messages. I can write code any way the language demands, but it has to make sense and I can't be doing a research project on the language every 10 minutes to figure out the right incantation. I already have that with C++. Bye
Re: What's the secret to static class members
On Wednesday, 29 June 2016 at 15:18:53 UTC, Guido wrote:
I'm using a static class member in a parent class, but can't
get the compiler to see it.
Class Grid{
public:
uint xdim;
}
Class Holder : Grid {
uint var;
}
Any of the following should work, but none of them do:
Grid.xdim = 0;
grid = new Grid;
grid.xdim = 0;
holder = new Holder;
holder.xdim = 0;
This is the way static class vars were intended to work. What
magics have I forgotten?
Platform
DMD latest, Windows 7
Visual D
The problem is actually much more profound. The classes need to
be declared outside the main() scope. WTF?!?!?!
I put them in main() so they would be in scope. This seems like a
*MAJOR* design flaw with the language, not to mention the
compiler not giving useful feedback. This decision, if it is a
decision, makes no sense given all the attention to scoping rules.
I'm not interested in trading one set of bad language decisions
for another. Can someone fix this?
What's the secret to static class members
I'm using a static class member in a parent class, but can't get
the compiler to see it.
Class Grid{
public:
uint xdim;
}
Class Holder : Grid {
uint var;
}
Any of the following should work, but none of them do:
Grid.xdim = 0;
grid = new Grid;
grid.xdim = 0;
holder = new Holder;
holder.xdim = 0;
This is the way static class vars were intended to work. What
magics have I forgotten?
Platform
DMD latest, Windows 7
Visual D
Re: Examples of dub use needed
On Thursday, 23 June 2016 at 07:46:41 UTC, Mike Parker wrote: FWIW, this thread has inspired me to begin work on a project I've titled 'The DUB Handbook'. I've been meaning to write some tutorials about DUB (among other things) for learningd.org, but I think a detailed guide would be a more worthwhile project to pursue. My intention with the text is to provide a detailed description of every dub command and configuration directive, along with examples of how to use them in both JSON and SDLang formats. I've spent an hour getting it set up today (I'm using gitbook) and expect to be working on it over the next several weeks. When it's ready for feedback, I'll make it publicly available and announce it here in the forums. I plan to release it under a CC license. Like I said, thanks for clearing things up. But I have to say that more detailed descriptions of commands is not what I had in mind. What are the best coding practices and why? I obviously haven't started using dub yet, so I won't be able to judge whether a code example is merely adequate or very robust. For example, why subpackages? It's in there for a reason; what situations call for subpackages? Why use -ddoxFilterArgs? When & how to static link? What dub-based project does a good job building for multiple platforms? From what's been discussed, I should always specify version number. Is there some best practice for flagging when a change to dependencies breaks your code? I would create a build type that lists the latest version of each dependency & run unittests. Is there a better way that someone is using in the field? Right now, I'm going around trying to steal the best coding practices, and I only want to steal from the best.
Re: Examples of dub use needed
On Tuesday, 21 June 2016 at 08:58:59 UTC, Dicebot wrote: On 06/21/2016 10:24 AM, poliklosio wrote: Wow, really? Then what is the fetch command for? I started using dub a recently (2 months ago) and totally didn't notice that there is any other purpose of the fetch command. I even installed dcd, dfmt and dscanner through dub fetch, only to find out these were older versions which didn't work. So what is the purpose of dub fetch? Apart from `--cache=local` version, one of intended use case is to get various small utility tools needed only during development and not needing to be distributed to the end user, like dfmt. After `dub fetch dfmt` one can run `dub run dfmt ` to invoke such tool without knowing where dub cache is located. But it is indeed supposed to be rare case and I do recommend to install such tools via system package manager instead whenever possible. So yes, you don't need `dub fetch` at all for most part. Thanks for the replies. This really clears things up. I'm the sort of person who learns by example, and what I was saying is that there aren't enough examples online of how dub is used in a practical setting. I'm also the sort of person who doesn't trust toolchains that need to download things every time from the internet just to compile. Is this what dub is doing? In other words, when a project is built using dub, does it use the local cache from the last build by default, check for later versions, pull things from the internet, etc? Or do I need -cache=local for that?
Examples of dub use needed
Dub doesn't really work like other package managers. When I load
a package:
dub fetch scriptlike
It stores it someplace and doesn't say where. You have to run
'dub list' to figure out where. That's is very different than
other packages. It deserves a bigger mention in the meager
documentation.
I've been trying to init a project using the command
dub -init -f sdl trickproject
-or-
dub -f sdl -init trickproject
and nothing seems to parse.
So, I look at the source code for the format option and see this:
args.getopt("f|format", _format, [
"Sets the format to use for the package description file.
Possible values:",
" " ~ [__traits(allMembers, PackageFormat)].map!(f => f ==
m_format.init.to!string ? f ~ " (default)" : f).join(", ")
]);
It doesn't look straightforward at all. Not sure why there is so
much complexity on this particular commandline option, but
shouldn't these command options work the way I have them?
In the interactive mode, I get to make the selection for the
project file format. I don't see many examples of how to use
options.
Re: Why don't we write configuration files in D instead of JSON?
have a look at `dub convert` - in your case e.g. `dub convert -f sdl` This dub convert command is weird. It works as `cat dub.json | dub convert -sdl' and makes a nice SDL file called dub.sdl, but it blows away the source file, which I've never seen before with piped output from cat. I don't like deleting the source file being the default behavior. Also, commands like `dub convert -f sdl dub.json' and variations of that sort don't seem to work as a command. They have errors. What's the weirdness here?
Re: Why don't we write configuration files in D instead of JSON?
On Thursday, 16 June 2016 at 06:07:55 UTC, Seb wrote: On Thursday, 16 June 2016 at 05:31:26 UTC, Guido wrote: It would seem that by running the file through mixin, you can simply create the vars you want in scope. The drawback being random code execution. Is there any way to sanitize mixin code from user-configurable file? Well it's a configuration file that e.g. the registry has to parse too, hence (as for all config files) random code execution is pretty bad. Apart from that it's just about a small configuration file for the name, title etc. - you don't need a full-blown D interpreter for this. Imho SDL does a good job at keeping the syntax rather minimal :) Of course do one stops you to use D to generate a configuration file. Once that's shot down, does anyone know a .json to .sdl converter program have a look at `dub convert` - in your case e.g. `dub convert -f sdl` Thanks for the answer. I conceptually like SDL better than JSON. We'll see how I like it in practice. I went looking for examples of SDL online and found that even the SDlang-D project is using a dub.json configuration file. How weird is that? Also, LOL @Ketmar.
Why don't we write configuration files in D instead of JSON?
It would seem that by running the file through mixin, you can simply create the vars you want in scope. The drawback being random code execution. Is there any way to sanitize mixin code from user-configurable file? Once that's shot down, does anyone know a .json to .sdl converter program
