Re: D web site and accessibility
On Monday, 24 September 2018 at 03:50:57 UTC, Vladimir Panteleev wrote: On Monday, 24 September 2018 at 03:16:50 UTC, Bauss wrote: like the use of b tags on the front page, they should be replaced by strong tags The two usages of are part of the presentation, not content. Their use is correct. I disagree: https://achecker.ca/checker/index.php See: "1.4 Distinguishable: Make it easier for users to see and hear content including separating foreground from background. Success Criteria 1.4.4 Resize text (AA) Check 116: b (bold) element used. Repair: Replace your b (bold) elements with em or strong. Error Line 430, Column 67: D Error Line 432, Column 18: D Programming Language"
Re: Warn on unused imports?
On 09/25/2018 09:14 AM, Jonathan M Davis wrote:
On Tuesday, September 25, 2018 7:03:30 AM MDT FeepingCreature via
Digitalmars-d wrote:
I'm playing with a branch of DMD that would warn on unused
imports:
https://github.com/FeepingCreature/dmd/tree/feature/Issue-3507-warn-on-unu
sed-imports
Two problems have arisen.
First:
import std.stdio;
void foo(T)() { writeln("Hello World"); }
foo.d: Warning: unused import
To be fair, it's not *wrong*: if you remove the import, the
module itself compiles just fine. In any case, it's trivial to
instead move the import into the template.
The real problem is this:
import std.format;
class TestException(T) : FormatException { }
Now I can't move the import inside the template, because it's
needed at the point of instantiation, but not inside the template
scope *per se*.
I could require the class to be written as
template TestException(T) {
import std.format;
class TestException : FormatException { }
}
but that's kind of terrible.
I've been working around this for now, with import std.format :
FormatException, but I'm not really happy with it.
Any ideas?
Honestly, in general, warnings are a terrible idea. Anything that's a
warning in your code has to be fixed, because it's bad practice to leave
warnings in your code, meaning that ultimately, there's not much difference
between a warning and an error. To make matters worse, there's a compiler
flag that turns warnings into errors. And when you combine that with stuff
like is(typeof(...)) and template constraints, whether you use that compiler
flag or not could actually change the resulting program. So, as it stands,
warnings are an even worse idea in D than they are in other languages.
Walter likes to talk about how warnings in C/C++ are there simply because
folks couldn't agree on what should or shouldn't be an error in the
language.
If something is definitively wrong, then it should be an error. If it's not
definitively wrong, then the compiler shouldn't say anything about it, and
it should be left up to a linter tool of some kind like dcd.
Warnings ARE a lint tool. The only reason people have gotten the idea
they're basically toggleable errors is because of the horrid mess that
is C/C++, where it's common practice to permit things that no sane
language would ever even CONSIDER not making a big, giant flashing
sirens-blazing error (thus necessitating, at very least, a warning).
Hell, even the actual lint tools in C/C++ land spit out tons of stuff
that should be errors.
Summary: Warning are not bad. The C/C++ approach to warnings is bad, and
had corrupted millions of programmer's minds.
Re: Updating D beyond Unicode 2.0
On 2018-09-21 18:27, Neia Neutuladh wrote: D's currently accepted identifier characters are based on Unicode 2.0: * ASCII range values are handled specially. * Letters and combining marks from Unicode 2.0 are accepted. * Numbers outside the ASCII range are accepted. * Eight random punctuation marks are accepted. This follows the C99 standard. Many languages use the Unicode standard explicitly: C#, Go, Java, Python, ECMAScript, just to name a few. A small number of languages reject non-ASCII characters: Dart, Perl. Some languages are weirdly generous: Swift and C11 allow everything outside the Basic Multilingual Plane. I'd like to update that so that D accepts something as a valid identifier character if it's a letter or combining mark or modifier symbol that's present in Unicode 11, or a non-ASCII number. This allows the 146 most popular writing systems and a lot more characters from those writing systems. This *would* reject those eight random punctuation marks, so I'll keep them in as legacy characters. It would mean we don't have to reference the C99 standard when enumerating the allowed characters; we just have to refer to the Unicode standard, which we already need to talk about in the lexical part of the spec. It might also make the lexer a tiny bit faster; it reduces the number of valid-ident-char segments to search from 245 to 134. On the other hand, it will change the ident char ranges from wchar to dchar, which means the table takes up marginally more memory. And, of course, it lets you write programs entirely in Linear B, and that's a marketing ploy not to be missed. I've got this coded up and can submit a PR, but I thought I'd get feedback here first. Does anyone see any horrible potential problems here? Or is there an interestingly better option? Does this need a DIP? I'm not a native English speaker but I write all my public and private code in English. Anyone I work with, I will expect them and make sure they're writing the code in English as well. English is not enough either, it has to be American English. Despite this I think that D should support as much of the Unicode as possible (including using Unicode for identifiers). It should not be up to the programming language to decide which language the developer should write the code in. -- /Jacob Carlborg
Re: D web site and accessibility
On 9/25/2018 1:49 AM, Chris wrote: This said, I was working with a blind person a couple of years ago (I think it was 3 years ago) and he used D for one of his assignments, he never had a problem with the documentation. That's good to hear.
Re: How to correctly deal with dmd.conf with multiple dmd installations - [ref osx, brew, digger]
On 09/25/2018 06:34 AM, aliak wrote: Alo, I'm wondering what’s the deal with dmd.conf and what’s the correct way to handle it with dmd installations. Basically, you want an appropriate, matching `dmd.conf` together with (ie, "in the same directory as") each `dmd` executable. No other `dmd.conf` should ever exist in any place where it could potentially be picked up by a D compiler.[1] Anything other than that just breeds problems and totally screws up normally-perfectly-safe things like upgrading the compiler or having multiple compilers installed. Using that rule, I've NEVER had any problems from having many different compilers installed. I'm not familiar with how digger or brew work, so I can't really comment on whether they do things safely or not. [1] There USED to arguably be a (sorta-)good use for having a common `dmd.conf` in a non-compiler-specific location: That was in the D1 days when there was no DUB, and the built-in `dmd.conf` was trivial and rarely changed. In those days, `dmd.conf` could be used as a really hacky substitute for a package manager. But there were still downsides/dangers to that then, and even more now, so it's really not a recommended approach anymore.
Re: Rather D1 then D2
On 2018-09-22 10:48, Nemanja Borić wrote: So it is possible to use D2 language and compiler and avoid all the features that you don't like, at least to a reasonable degree, and as a bonus you still get to cherry pick D2 features you like (and there are some even for D1 minded person). Yeah, for example, the DWT [1] code base use very few D2 features. It was originally written in D1 and then ported to D2 with as few changes as possible. It might actually still compile using a D1 compiler. [1] https://github.com/d-widget-toolkit/dwt -- /Jacob Carlborg
[Issue 19265] New: Multiple calls to rt_init/rt_term leads to SIGILL in _d_initMonoTime
https://issues.dlang.org/show_bug.cgi?id=19265
Issue ID: 19265
Summary: Multiple calls to rt_init/rt_term leads to SIGILL in
_d_initMonoTime
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: chalu...@gmail.com
I'm playing with fork() with druntime initialized after the fork, but I found
that I can't call rt_init/rt_term to cleanup the runtime multiple times.
Simple test case:
extern extern(C) int _d_run_main(int, char**, void*);
extern (C) int rt_init();
extern (C) int rt_term();
extern(C) int main(int argc, char** argv)
{
auto res = _d_run_main(argc, argv, );
res = _d_run_main(argc, argv, );
return res;
}
int testmain(string[] args)
{
return 1;
}
Backtrace:
#0 0x004327af in _d_initMonoTime ()
#1 0x0042a553 in rt_init ()
#2 0x00427c50 in rt.dmain2._d_run_main(int, char**, extern(C)
int(char[][]) function).runAll() ()
#3 0x00427be8 in rt.dmain2._d_run_main(int, char**, extern(C)
int(char[][]) function).tryExec(scope void() delegate) ()
#4 0x00427b50 in _d_run_main ()
#5 0x00427896 in main ()
Is this the expected behavior?
I guess that the problem is at least here:
https://github.com/dlang/druntime/blob/8fd52019826259dc92ab712f4b37a3f0ea4d8265/src/core/time.d#L2514
Tried with dmd-2.082.0
--
Re: Forums intermittently going down?
On Tuesday, 25 September 2018 at 18:26:58 UTC, CharlesM wrote: Yeah it happened again today. I heard this site was made in D, maybe is because the GC? No, just old server hardware and database fragmentation.
Re: Forums intermittently going down?
On Tue, Sep 25, 2018 at 08:41:51PM +, Vladimir Panteleev via Digitalmars-d wrote: > On Tuesday, 25 September 2018 at 18:26:58 UTC, CharlesM wrote: > > Yeah it happened again today. I heard this site was made in D, maybe > > is because the GC? > > No, just old server hardware and database fragmentation. Wow, that's GC-phobia like I've never seen before! T -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- Michael Beibl
Re: Forums intermittently going down?
On Tuesday, 25 September 2018 at 21:12:54 UTC, Steven Schveighoffer wrote: Well, I thought it might be GC related also. It behaves similarly to how you would expect a GC pause to behave (several fast responses, then one that takes 5 seconds to come back). I think that would be plausible if parts of the managed heap were swapped out to spinning-rust HDDs. Fortunately, RAM is plentiful in our case.
Re: Forums intermittently going down?
On Tuesday, 25 September 2018 at 21:20:29 UTC, Vladimir Panteleev wrote: Sometimes the database (SQLite) behaves unusually slow until you tell it to analyze itself, then it figures out some internal index it has to use that it wasn't using before (with no changes to schema). Those analysis runs take a long time to run, though, during which the database is offline. More generally, though, a big factor is probably that the size of the data set is exceeding the intended use cases for the database software used. How much data can there possibly be for a mailing list? I regularly see stories about companies using SQLite for databases in the hundreds of GB.
Re: Why is CI not running dmd's unittests?
On 2018-09-22 15:29, wolframw wrote: Hi, I ran the dmd unittests on my Windows machine today and one of the tests in filename.d asserted. The cause for this has already been noticed a few days ago by someone else [1] but not by CI. Is it well-known that the dmd unittests (at least for the Windows build) are not automatically run? If so, what is the reasoning behind it? [1] https://github.com/dlang/dmd/commit/7baa0e82802839940fb0620bad02e97f741d2c27#r30571264 I'm guessing because originally there weren't that many unit test blocks in the DMD source (or any at all). The main test suite is in the separate directory "tests". -- /Jacob Carlborg
Re: How to correctly deal with dmd.conf with multiple dmd installations - [ref osx, brew, digger]
On 2018-09-25 13:55, Jonathan M Davis wrote: Yes. You want dmd.conf, or certain paths won't be set correctly (like where to find Phobos). Personally, I'd strongly suggest against having multiple copies of dmd installed at the same time. It just sounds like a recipe for disaster. Regardless, here's the description for how dmd finds dmd.conf: https://dlang.org/dmd-linux.html#dmd-conf Having multiple copies of DMD (or rather multiple versions) works perfectly fine. That's the entire point of DVM [1]. But I've never used a global dmd.conf file either. [1] https://github.com/jacob-carlborg/dvm -- /Jacob Carlborg
Natvis, CV8, dAssocArray
I almost finished my -gc for Natvis experiment (to use MS C++ Debugger from VS Code, fully translating type names from what comes from DMD frontend to valid C++ type name so Natvis works), but then I encountered dAssocArray, which has form of: void* as CodeView structure member, KeyType __key_t and ValueType __val_t as nested types. As for someone who just found about CodeView today: what is nested type, what is the deal with void*, what to do with __key_t and __val_t to get values.
[Issue 19265] Multiple calls to rt_init/rt_term leads to SIGILL in _d_initMonoTime
https://issues.dlang.org/show_bug.cgi?id=19265
--- Comment #1 from Tomáš Chaloupka ---
Other test case:
extern extern(C) int _d_run_main(int, char**, void*);
extern (C) int rt_init();
extern (C) int rt_term();
extern(C) int main(int argc, char** argv)
{
rt_init();
rt_term();
rt_init(); // SIGILL
rt_term();
return 0;
}
--
Re: Forums intermittently going down?
On Friday, 21 September 2018 at 00:57:42 UTC, Vladimir Panteleev wrote: Performance should now be back to normal. Looks like my previous hunch as to why it was slow was off. Should be fixed now.
Re: Forums intermittently going down?
On Tuesday, 25 September 2018 at 21:12:54 UTC, Steven Schveighoffer wrote: I'll note that when I started running into DB slowdowns on a system (not related to D), adding one index fixed the issue. Sometimes linear searches are fast enough to hide in plain sight :) I'm no DBA. Here's the schema: https://github.com/CyberShadow/DFeed/blob/master/schema.sql Sometimes the database (SQLite) behaves unusually slow until you tell it to analyze itself, then it figures out some internal index it has to use that it wasn't using before (with no changes to schema). Those analysis runs take a long time to run, though, during which the database is offline. More generally, though, a big factor is probably that the size of the data set is exceeding the intended use cases for the database software used.
Re: How to correctly deal with dmd.conf with multiple dmd installations - [ref osx, brew, digger]
On Tue, Sep 25, 2018 at 09:00:57PM +0200, Jacob Carlborg via Digitalmars-d wrote: > On 2018-09-25 13:55, Jonathan M Davis wrote: > > > Yes. You want dmd.conf, or certain paths won't be set correctly > > (like where to find Phobos). Personally, I'd strongly suggest > > against having multiple copies of dmd installed at the same time. It > > just sounds like a recipe for disaster. Regardless, here's the > > description for how dmd finds dmd.conf: > > > > https://dlang.org/dmd-linux.html#dmd-conf > > Having multiple copies of DMD (or rather multiple versions) works > perfectly fine. That's the entire point of DVM [1]. But I've never > used a global dmd.conf file either. [...] Unlike many other similar software, dmd works remarkably well when installed with multiple copies of itself. Provided you setup a suitable dmd.conf in the same directory as the executable, and pointing to the appropriate versions of druntime/phobos. (The latter two are more liable to cause headaches if you point dmd to the wrong versions thereof. When in doubt, run dmd -v to see exactly which dmd.conf and which druntime/phobos are being used.) If you're using multiple versions of dmd, though, I'd highly recommend *not* having a /etc/dmd.conf (nor a $HOME/dmd.conf), because all versions of dmd will look there, and all except one will pick up the wrong settings. Save yourself the ensuing headache. T -- If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher
Re: Warn on unused imports?
On 2018-09-25 16:20, FeepingCreature wrote: If that's the way D wanted to go, it shouldn't have turned itself into a metaprogramming monster that's completely unevaluable by Linter tools, *or* it should offer some way to dump a fixed-format lowered representation with line number information that tools can analyze. As it stands, it is literally impossible to evaluate whether an import is unused without evaluating the entire compile-time subset of D. The DMD compiler is available as a library. A linter tool can be based on that. -- /Jacob Carlborg
Re: Rather D1 then D2
On 09/22/2018 10:31 AM, Jonathan Marler wrote: On Saturday, 22 September 2018 at 13:25:27 UTC, rikki cattermole wrote: Then D isn't the right choice for you. I think it makes for a better community if we can be more welcoming, helpful a gracious instead of responding to criticism this way. This is someone who saw enough potential with D to end up on the forums but had some gripes with it, after all who doesn't? I'm glad he took the initiative to provide us with good feedback, and he's not the first to take issue with the inconsistent '@' attribute syntax. I'm sure everyone can agree this inconsistency is less than ideal but that doesn't mean D isn't right for them and we should respond this feedback like this with thanks rather than dismissal. Ordinarily yes, but most of what "new" has said above has been very trollish and borderline irrational.
Re: Forums intermittently going down?
On 9/25/18 5:05 PM, H. S. Teoh wrote: On Tue, Sep 25, 2018 at 08:41:51PM +, Vladimir Panteleev via Digitalmars-d wrote: On Tuesday, 25 September 2018 at 18:26:58 UTC, CharlesM wrote: Yeah it happened again today. I heard this site was made in D, maybe is because the GC? No, just old server hardware and database fragmentation. Wow, that's GC-phobia like I've never seen before! Well, I thought it might be GC related also. It behaves similarly to how you would expect a GC pause to behave (several fast responses, then one that takes 5 seconds to come back). But lately, I've noticed I just get the "down for maintenance" message more than a delayed response. In any case, I generally don't use the forum except read-only mode on my phone. For posting, I'm generally using NNTP. I'll note that when I started running into DB slowdowns on a system (not related to D), adding one index fixed the issue. Sometimes linear searches are fast enough to hide in plain sight :) -Steve
Re: Then new forum moderation
On Monday, 24 September 2018 at 12:56:43 UTC, JN wrote: Well, it requires you to know what a ternary operator is It wouldn't be a captcha if the questions were like "what is the most popular social network?". Also int doesn't implicitly convert to bool. On Tuesday, 25 September 2018 at 05:52:57 UTC, bauss wrote: Not for someone who is just introduced to programming and doesn't D want to attract newcomers? If so we cannot have a programmer specific captcha. I don't think you can go into programming from absolute zero. I mean if you want to learn about history, what if history forums presented you with something like: "In which country was the first monarchy?" Monarchy is prehistoric (watching the Troy movie should be enough), and yes, history forums do something like that. Also you don't study history out of the blue, you're taught it in school.
Re: D web site and accessibility
On Tuesday, 25 September 2018 at 06:01:58 UTC, bauss wrote: On Monday, 24 September 2018 at 03:50:57 UTC, Vladimir Panteleev wrote: On Monday, 24 September 2018 at 03:16:50 UTC, Bauss wrote: like the use of b tags on the front page, they should be replaced by strong tags The two usages of are part of the presentation, not content. Their use is correct. And also representation should generally be done with It's more important how the screen reading software parses and represents it to the user. Screen readers build their own DOM in the background. So don't get lost in semantic details that may have no bearing whatsoever on accessibility. I remember that a while ago "" was not supported by all browsers, that's why devs opted for "" or "" (which is the one I prefer). Usually, if a homepage is marked up normally in bog standard HTML, then users of screen readers have no problems reading the content. Problems may arise when it comes to things like code examples that are somehow handled by JS or the like. I'd say you start testing the general examples, the language specs and the library documentation. If they're not accessible, then a visually impaired user cannot use D. This said, I was working with a blind person a couple of years ago (I think it was 3 years ago) and he used D for one of his assignments, he never had a problem with the documentation.
Re: Updating D beyond Unicode 2.0
On 9/23/2018 12:06 PM, Abdulhaq wrote: The early history of computer science is completely dominated by cultures who use latin script based characters, Small character sets are much more implementable on primitive systems like telegraphs and electro-mechanical ttys. It wasn't even practical to display a rich character set until the early 1980's or so. There wasn't enough memory. Glass ttys at the time could barely, and I mean barely, display ASCII. I know because I designed and built one.
Re: Updating D beyond Unicode 2.0
On Friday, 21 September 2018 at 23:17:42 UTC, Seb wrote: In all seriousness I hate it when someone thought its funny to use the lambda symbol as an identifier and I have to copy that symbol whenever I want to use it because there's no convenient way to type it. (This is already supported in D.) I just want to chime in that I've definitely used greek letters in "ordinary" code - it's handy when writing math and feeling lazy. Note that on Linux, with a simple configuration tweak (Windows key mapped to Compose, and https://gist.githubusercontent.com/zkat/6718053/raw/4535a2e2a988aa90937a69dbb8f10eb6a43b4010/.XCompose ), you can for instance type " l a m" to make the lambda symbol, or other greek letters very easily.
Can I create static c callable library?
I need to write a library to statically link into a c program. Can I write this library in D? Will I be able to use proper D abilities like gc? Obviously the public interface will need to be basic c callable functions... I 'main' is a c program will this work?
[Issue 19263] New: Segfault trying to print out a default-initialized SysTime
https://issues.dlang.org/show_bug.cgi?id=19263
Issue ID: 19263
Summary: Segfault trying to print out a default-initialized
SysTime
Product: D
Version: D2
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: andrej.mitrov...@gmail.com
-
import std.datetime;
import std.stdio;
void main ( )
{
SysTime systime;
writeln(systime);
}
-
The above segfaults at runtime.
Using DMD v2.081.1 on Linux x64.
--
Re: D web site and accessibility
On Tuesday, 25 September 2018 at 08:49:13 UTC, Chris wrote: On Tuesday, 25 September 2018 at 06:01:58 UTC, bauss wrote: On Monday, 24 September 2018 at 03:50:57 UTC, Vladimir Panteleev wrote: On Monday, 24 September 2018 at 03:16:50 UTC, Bauss wrote: like the use of b tags on the front page, they should be replaced by strong tags The two usages of are part of the presentation, not content. Their use is correct. And also representation should generally be done with It's more important how the screen reading software parses and represents it to the user. Screen readers build their own DOM in the background. So don't get lost in semantic details that may have no bearing whatsoever on accessibility. I remember that a while ago "" was not supported by all browsers, that's why devs opted for "" or "" (which is the one I prefer). Usually, if a homepage is marked up normally in bog standard HTML, then users of screen readers have no problems reading the content. Problems may arise when it comes to things like code examples that are somehow handled by JS or the like. I'd say you start testing the general examples, the language specs and the library documentation. If they're not accessible, then a visually impaired user cannot use D. This said, I was working with a blind person a couple of years ago (I think it was 3 years ago) and he used D for one of his assignments, he never had a problem with the documentation. Yes I agree to an extend, but if a browser doesn't support (All does by now though.) then you could still support it technically with css. The "not supporting" is really just the browser not having default styling for it which you can do with css, that's why things like angular material etc. have their own tags that aren't standard tags, but are still represented with styles that resemble what the tag is. Of course there are exceptions like will become etc. I'm probably just nitpicking though, but if you care about accessibility then you should follow all standards, no exceptions or at least try to. https://developer.mozilla.org/en-US/docs/Learn/Accessibility/HTML https://developer.mozilla.org/en-US/docs/Learn/Accessibility/CSS_and_JavaScript It might not be a bottleneck in this case and probably won't make much of a difference, but yah. Some screenreaders might actually interpret as etc. which will also make it a misrepresentation in this case, because it's supposed to just be a presentation and not emphasised text. So in my opinion either it should be emphasised the correct way using or , or it should be tags with styling, just like you showed with font-weight.
Re: How to correctly deal with dmd.conf with multiple dmd installations - [ref osx, brew, digger]
On Tuesday, September 25, 2018 4:34:17 AM MDT aliak via Digitalmars-d wrote: > Alo, > > I'm wondering what’s the deal with dmd.conf and what’s the > correct way to handle it with dmd installations. > > Scenario: `brew install dmd` puts dmd in `/usr/local/bin/dmd` > (symlink) and sets the `SYSCONFDIR` in its build config so > `dmd.conf` is in `/usr/local/etc/dmd.conf`. > > AFAICT: that seems correct. Is it? > > The problem comes with tools like digger. Which seems to be part > of DMD’s PR process as D bot seems to love it :) so I guess it's > officially supported? - plus it seems super convenient for dmd > development. > > But anyway, it’s broken on the mac if you use brew (and brew is > [probably?] defacto). There is a workaround when running `digger > build` but it’s not nice, and you’d never be able to guess it, > and it’s error prone [0]. > > When you do `digger install` it seems to not “install” a > `dmd.conf` but it does install the `dmd` binary in > `/usr/local/bin/dmd` - but that wasn’t built with `SYSCONFDIR` so > it doesn’t find `/usr/local/etc/dmd.conf` either, but even if it > did, that’s the wrong `dmd.conf` (i.e. not the one that the build > was based on - so would it even point to the right env?). > > So basically, is dmd.conf supposed to go along with an ad hoc > installation of dmd? > > And, is dmd.conf necessary or can I safely ignore its existence? > (it seems like maybe dub depends on it though so maybe not). > > Cheers, > - Ali > > [0]: https://github.com/CyberShadow/Digger/issues/74 Yes. You want dmd.conf, or certain paths won't be set correctly (like where to find Phobos). Personally, I'd strongly suggest against having multiple copies of dmd installed at the same time. It just sounds like a recipe for disaster. Regardless, here's the description for how dmd finds dmd.conf: https://dlang.org/dmd-linux.html#dmd-conf - Jonathan M Davis
How to correctly deal with dmd.conf with multiple dmd installations - [ref osx, brew, digger]
Alo, I'm wondering what’s the deal with dmd.conf and what’s the correct way to handle it with dmd installations. Scenario: `brew install dmd` puts dmd in `/usr/local/bin/dmd` (symlink) and sets the `SYSCONFDIR` in its build config so `dmd.conf` is in `/usr/local/etc/dmd.conf`. AFAICT: that seems correct. Is it? The problem comes with tools like digger. Which seems to be part of DMD’s PR process as D bot seems to love it :) so I guess it's officially supported? - plus it seems super convenient for dmd development. But anyway, it’s broken on the mac if you use brew (and brew is [probably?] defacto). There is a workaround when running `digger build` but it’s not nice, and you’d never be able to guess it, and it’s error prone [0]. When you do `digger install` it seems to not “install” a `dmd.conf` but it does install the `dmd` binary in `/usr/local/bin/dmd` - but that wasn’t built with `SYSCONFDIR` so it doesn’t find `/usr/local/etc/dmd.conf` either, but even if it did, that’s the wrong `dmd.conf` (i.e. not the one that the build was based on - so would it even point to the right env?). So basically, is dmd.conf supposed to go along with an ad hoc installation of dmd? And, is dmd.conf necessary or can I safely ignore its existence? (it seems like maybe dub depends on it though so maybe not). Cheers, - Ali [0]: https://github.com/CyberShadow/Digger/issues/74
Re: Then new forum moderation
On Tuesday, 25 September 2018 at 05:52:57 UTC, bauss wrote: Not for someone who is just introduced to programming and doesn't D want to attract newcomers? If so we cannot have a programmer specific captcha. https://forum.dlang.org/post/vrehthdqtenpnysru...@forum.dlang.org Please address the counter-arguments directly instead of just reiterating your flawed arguments elsewhere in the thread.
Re: D web site and accessibility
On Tuesday, 25 September 2018 at 05:57:06 UTC, bauss wrote: On Monday, 24 September 2018 at 03:50:57 UTC, Vladimir Panteleev wrote: The two usages of are part of the presentation, not content. Their use is correct. I disagree: That doesn't address the argument. A program can't know whether a tag is part of the presentation or content. The argument stands.
Re: D web site and accessibility
On Monday, 24 September 2018 at 03:50:57 UTC, Vladimir Panteleev wrote: On Monday, 24 September 2018 at 03:16:50 UTC, Bauss wrote: like the use of b tags on the front page, they should be replaced by strong tags The two usages of are part of the presentation, not content. Their use is correct. And also representation should generally be done with
Re: Updating D beyond Unicode 2.0
When I make code that I expect to be only used around here, I generally write the code itself in english but comments in my own language. I agree that in general, it's better to stick with english in identifiers when the programming language and the standard library is English. On Tuesday, 25 September 2018 at 09:28:33 UTC, FeepingCreature wrote: On Friday, 21 September 2018 at 23:17:42 UTC, Seb wrote: In all seriousness I hate it when someone thought its funny to use the lambda symbol as an identifier and I have to copy that symbol whenever I want to use it because there's no convenient way to type it. (This is already supported in D.) I just want to chime in that I've definitely used greek letters in "ordinary" code - it's handy when writing math and feeling lazy. On the other hand, Unicode identifiers till have their value IMO. The quote above is one reason for that -if there is a very specialized codebase it may be just inpractical to letterize everything. Another reason is that something may not have a good translation to English. If there is an enum type listing city names, it is IMO better to write them as normal, using Unicode. CityName.seinäjoki, not CityName.seinaejoki.
Re: Forums intermittently going down?
On Tuesday, 25 September 2018 at 21:42:40 UTC, bachmeier wrote: How much data can there possibly be for a mailing list? Currently, 3.8 GB. A good part of that is the full-text index required for searching. (It does work really well, though - no need for Lucene or such.) I regularly see stories about companies using SQLite for databases in the hundreds of GB. One thing possible with a traditional RDBMS that's not possible with SQLite is processing several simultaneous requests. The synchronous API translates to the synchronous nature of the entire program: when the forum hits a request it needs a few seconds to handle, it can't process any requests during that time, even those it could answer without consulting the database (as much is cached in RAM).
Re: Warn on unused imports?
On Tuesday, September 25, 2018 1:21:50 PM MDT Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:
> On 09/25/2018 09:14 AM, Jonathan M Davis wrote:
> > On Tuesday, September 25, 2018 7:03:30 AM MDT FeepingCreature via
> >
> > Digitalmars-d wrote:
> >> I'm playing with a branch of DMD that would warn on unused
> >> imports:
> >>
> >> https://github.com/FeepingCreature/dmd/tree/feature/Issue-3507-warn-on->
> >> >> unu sed-imports
> >>
> >> Two problems have arisen.
> >>
> >> First:
> >>
> >> import std.stdio;
> >>
> >> void foo(T)() { writeln("Hello World"); }
> >>
> >> foo.d: Warning: unused import
> >>
> >> To be fair, it's not *wrong*: if you remove the import, the
> >> module itself compiles just fine. In any case, it's trivial to
> >> instead move the import into the template.
> >>
> >> The real problem is this:
> >>
> >> import std.format;
> >>
> >> class TestException(T) : FormatException { }
> >>
> >> Now I can't move the import inside the template, because it's
> >> needed at the point of instantiation, but not inside the template
> >> scope *per se*.
> >>
> >> I could require the class to be written as
> >>
> >> template TestException(T) {
> >>
> >> import std.format;
> >> class TestException : FormatException { }
> >>
> >> }
> >>
> >> but that's kind of terrible.
> >>
> >> I've been working around this for now, with import std.format :
> >> FormatException, but I'm not really happy with it.
> >>
> >> Any ideas?
> >
> > Honestly, in general, warnings are a terrible idea. Anything that's a
> > warning in your code has to be fixed, because it's bad practice to leave
> > warnings in your code, meaning that ultimately, there's not much
> > difference between a warning and an error. To make matters worse,
> > there's a compiler flag that turns warnings into errors. And when you
> > combine that with stuff like is(typeof(...)) and template constraints,
> > whether you use that compiler flag or not could actually change the
> > resulting program. So, as it stands, warnings are an even worse idea in
> > D than they are in other languages. Walter likes to talk about how
> > warnings in C/C++ are there simply because folks couldn't agree on what
> > should or shouldn't be an error in the language.
> >
> > If something is definitively wrong, then it should be an error. If it's
> > not definitively wrong, then the compiler shouldn't say anything about
> > it, and it should be left up to a linter tool of some kind like dcd.
>
> Warnings ARE a lint tool. The only reason people have gotten the idea
> they're basically toggleable errors is because of the horrid mess that
> is C/C++, where it's common practice to permit things that no sane
> language would ever even CONSIDER not making a big, giant flashing
> sirens-blazing error (thus necessitating, at very least, a warning).
> Hell, even the actual lint tools in C/C++ land spit out tons of stuff
> that should be errors.
>
> Summary: Warning are not bad. The C/C++ approach to warnings is bad, and
> had corrupted millions of programmer's minds.
The way that C++ handles warnings is how I've seen most languages handle
warnings. IMHO, the only time that anything along the lines of a warning
makes sense is when the programmer is proactively running a tool to
specifically ask to be informed of a potential type of problem where they
will then go look at each of them individually and decide whether what the
tool is telling them is valid or not - at which point, some of what the tool
says will be followed, and some if it will be ignored. It's not something
that should be run as part of a normal build process. If it is, then
inevitably what happens is that either all of the warnings get "fixed" (at
which point, they might as well have all been errors), or they all get
ignored, meaning that you get a huge wall of them, and they're completely
useless. As such, I really have nothing good to say about having any kind of
warnings being built into the compiler. As I understand it, on the whole,
Walter agrees with me and that he only added them in to dmd, because he was
essentially bullied into it, and I wish that he'd never given in. And when
you consider features like is(typeof(...)), the side effects of having -w
are particularly bad.
- Jonathan M Davis
Re: How to correctly deal with dmd.conf with multiple dmd installations - [ref osx, brew, digger]
On Tuesday, 25 September 2018 at 10:34:17 UTC, aliak wrote: When you do `digger install` it seems to not “install” a `dmd.conf` but it does install the `dmd` binary in `/usr/local/bin/dmd` - but that wasn’t built with `SYSCONFDIR` so it doesn’t find `/usr/local/etc/dmd.conf` either, but even if it did, that’s the wrong `dmd.conf` (i.e. not the one that the build was based on - so would it even point to the right env?). The solution I'm thinking of for Digger is to attempt to detect the SYSCONFDIR of the current `dmd` binary in `PATH`, and use that by default when Digger builds D. Doing so would break Digger's "maximally reproducible builds" policy a little, so we'd need to be loud about it. An alternative would be to complain loudly when attempting to build or (especially) install a compiler with a mismatching SYSCONFDIR, but still proceed with the default.
Re: Forums intermittently going down?
On Wed, Sep 26, 2018 at 01:07:29AM +, Vladimir Panteleev via Digitalmars-d wrote: [...] > One thing possible with a traditional RDBMS that's not possible with > SQLite is processing several simultaneous requests. The synchronous > API translates to the synchronous nature of the entire program: when > the forum hits a request it needs a few seconds to handle, it can't > process any requests during that time, even those it could answer > without consulting the database (as much is cached in RAM). [...] What version of SQLite are you using? AFAIK, SQLite itself does support concurrent access. Though it does have to be explicitly compiled with that option, otherwise it will only issue a runtime error. Of course, locking is not as fine-grained, so if one request locks one table then it will block everything else. IME, though, SQLite performance can be greatly improved simply by indexing columns used for lookup. Except for row ID, SQLite doesn't index by default, so if you're filtering your selects by other columns, you're potentially hitting O(n) table scans per lookup. I don't know what your schema looks like, so it's hard to give specifics, but basically, any column used in a WHERE clause is a candidate for indexing. Of course, it's a judgment call which columns are best for indexing -- you don't want to index everything since the overhead might make it even slower than without indexing. You might have to play around a bit to find the best candidates to index. Usually, though, as is typical for performance optimizations, there's just a small number of columns that are causing a bottleneck; once they are indexed, it should yield much improved performance. T -- Fact is stranger than fiction.
OT: Bad translations
On 09/24/2018 08:17 AM, 0xEAB wrote: > - Non-idiomatic translations of tech terms [2] This is something I had heard from a Digital Research programmer in early 90s: English message was something like "No memory left" and the German translation was "No memory on the left hand side" :) Ali
Re: Can I create static c callable library?
On Tuesday, 25 September 2018 at 11:03:11 UTC, John Burton wrote: I need to write a library to statically link into a c program. Can I write this library in D? Will I be able to use proper D abilities like gc? Obviously the public interface will need to be basic c callable functions... I 'main' is a c program will this work? Yes, for example https://github.com/libmir/mir-optim It has *.cpp example.
Re: Then new forum moderation
On Tuesday, 25 September 2018 at 07:43:39 UTC, Kagamin wrote: I don't think you can go into programming from absolute zero. So I assume for what you're saying that anybody who comes here already knows at least: ternary, promotion, implicit casting. For example: If a person knows VB/Delphi and now he is trying D and have any doubt, he will need to evolve first to understand ternary before posting something, because ternary in these languages are different. Awesome and great mentality. S.G.
Re: D web site and accessibility
On Monday, 24 September 2018 at 15:19:01 UTC, Chris wrote: On Monday, 24 September 2018 at 03:50:57 UTC, Vladimir Panteleev wrote: On Monday, 24 September 2018 at 03:16:50 UTC, Bauss wrote: like the use of b tags on the front page, they should be replaced by strong tags The two usages of are part of the presentation, not content. Their use is correct. HTML tags are usually fine. JS can cause problems. Some older posts (in order of appearance): https://forum.dlang.org/post/avyxxydzbghsjmsuc...@forum.dlang.org https://forum.dlang.org/post/arkvmtfljjtjpfrcc...@forum.dlang.org https://forum.dlang.org/post/wcnwyqugkcqkkyegh...@forum.dlang.org But I think browsers / screen reading software have improved a lot in this regard. I dunno how react (native) and the like are handled though. Aside using semantic HTML elements like strong, em,... the WAI-ARIA standard follows. Also the use of title, alt and tab-index is also encouraged in forms (where necessary). This article highlights some of the most important things to consider. https://www.sitepoint.com/real-world-accessibility-html5-aria-and-the-modern-web/
Re: Then new forum moderation
On Tuesday, 25 September 2018 at 13:16:14 UTC, Chris wrote: The captchas are awful, why would you want to waste brain cycles on that if you wanna send a one line response or so... If it is for mitigate spam/bot, you can easily by pass it with a simple script[1]. I'd prefer a captcha system that is commonly used than some that requires a specific knowledge of a language, which may be a barrier for newbies. [1] https://forum.dlang.org/post/gpykpzmwrpcowktue...@forum.dlang.org S.G.
Re: D web site and accessibility
On Tuesday, 25 September 2018 at 15:10:53 UTC, aberba wrote: Aside using semantic HTML elements like strong, em,... the WAI-ARIA standard follows. Also the use of title, alt and tab-index is also encouraged in forms (where necessary). This article highlights some of the most important things to consider. https://www.sitepoint.com/real-world-accessibility-html5-aria-and-the-modern-web/ Careful with the ARIA stuff. It is useful but not always necessary. Screen reading software is aware of sliders etc. and may already pass on the relevant information to the user. The only way to go about it is to have things tested by real users of _various_ screen readers (Dolphin, NVDA, VoiceOver etc.) You don't wanna waste time making a website accessible only to find out that the screen reader already understood it without your help.
Re: Then new forum moderation
On Tuesday, 25 September 2018 at 07:43:39 UTC, Kagamin wrote: On Monday, 24 September 2018 at 12:56:43 UTC, JN wrote: Well, it requires you to know what a ternary operator is It wouldn't be a captcha if the questions were like "what is the most popular social network?". Also int doesn't implicitly convert to bool. On Tuesday, 25 September 2018 at 05:52:57 UTC, bauss wrote: Not for someone who is just introduced to programming and doesn't D want to attract newcomers? If so we cannot have a programmer specific captcha. I don't think you can go into programming from absolute zero. I mean if you want to learn about history, what if history forums presented you with something like: "In which country was the first monarchy?" Monarchy is prehistoric (watching the Troy movie should be enough), and yes, history forums do something like that. Also you don't study history out of the blue, you're taught it in school. You can as a student at the university, where you're just introduced to programming. How is monarchy prehistoric? Monarchies still exist today. https://en.wikipedia.org/wiki/List_of_current_monarchies That is beside my point though, my point was not about history and you completely missed it. Facepalm.
Re: Can I create static c callable library?
On Tuesday, September 25, 2018 5:03:11 AM MDT John Burton via Digitalmars-d- learn wrote: > I need to write a library to statically link into a c program. > Can I write this library in D? > Will I be able to use proper D abilities like gc? Obviously the > public interface will need to be basic c callable functions... > > I 'main' is a c program will this work? If you use -betterC, then it's trivial, because your D program is restricted to extern(C) functions and features which don't require druntime. It can also be done without -betterC (and thus with druntime), but it gets to be _way_ more of a pain, because it requires that you manually initialize druntime - either by forcing whatever is using your "C" library to call a specific function to initialize druntime before using any of its normal functions or by having every function in the library check whether druntime has been initialized yet and initialize it if it hasn't been before it does whatever it's supposed to do. And of course, if you pass any GC-allocated memory out of the library, you have to worry about calling all of the appropriate GC functions so that it knows not to free it and knowing when to tell the GC that that memory can be freed. It's all very feasible and all very annoying. In general, it's far, far easier to write D programs that call into C code than to write C programs that call into D code. That's part of why some folks are so excited about -betterC. It makes it _way_ easier to write D libraries that can be called from C or C++ - though because you lose out on so many D features in the process (like the GC), whether it's even worth it is highly debatable. - Jonathan M Davis
discussion of bulletproof equipment; exchange of good ideas
Hello everyone. I am new here. I am an employee of Newtech armor, a great manufacturer of body armor, we produce HAP, Bulletproof Vest, Shield and Helmet. We used to tender for many armies from different countries like Pakistan, and have established long-term partnership with many counties. I think we can exchange ideas here, and discuss the technologies and science about bulletproof equipment, I am looking forward to receive your advices and suggestions, so we can make further improvement on our protective products. if you are interested in our products, welcome to visit our official website: http://www.newtecharmor.com/
Re: is there something like `stm32-rs` in D?
On Wednesday, 26 September 2018 at 03:46:21 UTC, dangbinghoo wrote: hi, https://github.com/adamgreig/stm32-rs looks great, is there something like this in Dlang? thanks! --- dangbinghoo You might take a look at https://github.com/JinShil/stm32f42_discovery_demo and https://github.com/JinShil/stm32_datasheet_to_d
Re: Forums intermittently going down?
On Tuesday, 25 September 2018 at 21:20:29 UTC, Vladimir Panteleev wrote: Sometimes the database (SQLite) SQLite was designed initially to be single local process, one connection. You should get much better results with postgres though of course it has some maintenance overhead (mainly installation)
Re: Forums intermittently going down?
On Wednesday, 26 September 2018 at 01:52:31 UTC, H. S. Teoh wrote: I don't know what your schema looks like, so it's hard to give specifics https://github.com/CyberShadow/DFeed/blob/master/schema.sql
Re: Forums intermittently going down?
On Tuesday, 25 September 2018 at 21:20:29 UTC, Vladimir Panteleev wrote: Sometimes the database (SQLite) https://github.com/CyberShadow/DFeed/blob/master/schema.sql CREATE TABLE [Groups] ( [Group] VARCHAR(50) NULL, [ArtNum] INTEGER NULL, [ID] VARCHAR(50) NULL , Time INTEGER); If you're using SQLite you don't need to specify the size of the columns, for what I gather it's useless for this DB. You may declare GROUP VARCHAR(50), but if you insert something bigger, it will insert anyway, because the column adjust according the value. And if I'm not mistaken it usually preferable to use TEXT for strings. And should avoid NULL columns every time you can, because it impacts (Negatively) in the index.
Re: Forums intermittently going down?
On Wednesday, 26 September 2018 at 01:52:31 UTC, H. S. Teoh wrote: What version of SQLite are you using? AFAIK, SQLite itself does support concurrent access. Though it does have to be explicitly compiled with that option, otherwise it will only issue a runtime error. Of course, locking is not as fine-grained, so if one request locks one table then it will block everything else. Yep, well, it's not very good at it (as it wasn't designed for it). It locks the entire database when writing, and when the lock is held, you get an exception or have to retry on a timer. So, it's "supported" but not actually scalable. I don't know what your schema looks like, so it's hard to give specifics, I posted a link to the schema earlier in the thread. but basically, any column used in a WHERE clause is a candidate for indexing. Yep, I think we're past that already. The last issue I ran into was subscriptions. Some people seem to be creating subscriptions to collect and email them frequently, sometimes on every post - not that those work well, because the forum stops emailing people as soon as they have unread messages in their subscriptions, but they still get saved to the queue. Still, the longer the forum was online, the more subscriptions have accumulated, and every new post resulted in all those subscriptions getting triggered. Now, every time a subscription with an email action was triggered, we had to check if there are any unread messages in their subscription queue, and there can be a lot of messages in there - thus, this caused something like an O(m*n) database operation (with the underlying database implementation also not having a constant execution time of course). I fixed this by limiting the check to the first unread post instead of reusing a function to count all unread messages in the subscription queue: https://github.com/cybershadow/DFeed/commit/9cfcab2
Re: Forums intermittently going down?
On Wednesday, 26 September 2018 at 02:28:27 UTC, CharlesM wrote: If you're using SQLite you don't need to specify the size of the columns, for what I gather it's useless for this DB. Yep, this is mostly descriptive. Types in column declarations have mostly the same effect. And if I'm not mistaken it usually preferable to use TEXT for strings. In SQLite? How so? And should avoid NULL columns every time you can, because it impacts (Negatively) in the index. The only thing I could find on NULL in index performance was this: For example, a partial index might omit entries for which the column being indexed is NULL. When used judiciously, partial indexes can result in smaller database files and improvements in both query and write performance. However, a lot of those NULL columns should never be null. I wonder why I declared them as such...
Re: Forums intermittently going down?
On Wednesday, 26 September 2018 at 02:42:15 UTC, Vladimir Panteleev wrote: On Wednesday, 26 September 2018 at 02:28:27 UTC, CharlesM wrote: If you're using SQLite you don't need to specify the size of the columns, for what I gather it's useless for this DB. Yep, this is mostly descriptive. Types in column declarations have mostly the same effect. And if I'm not mistaken it usually preferable to use TEXT for strings. In SQLite? How so? I don't remember where I read, but it's because the type affinity, in fact in the and it doesn't matter because VARCHAR will be TEXT in the end: https://www.sqlite.org/datatype3.html So at least you save space in your script. :) I'm a bit rusty with SQLite, but I was on a project a year ago, and I had this big table and trying with/without NULL, I got a better performance without it. By the way I found this: https://blog.paddlefish.net/?p=885
is there something like `stm32-rs` in D?
hi, https://github.com/adamgreig/stm32-rs looks great, is there something like this in Dlang? thanks! --- dangbinghoo
Re: Copy Constructor DIP and implementation
On Tuesday, September 25, 2018 6:33:30 AM MDT RazvanN via Digitalmars-d- announce wrote: > After discussing with Walter and Andrei we have decided that we > are going to drop @implicit for now as it may cause bugs (as > Jonathan has highlighted) and consider constructors that have the > form this(ref $q1 S rhs) $q2 as copy constructors. I will update > the DIP with more information. > > Also, regarding the cohabitation between postblit and copy > constructor: in order to make the transition smoother, whenever a > postblit and a copy constructor are found togheter in a struct, > the former is used and the latter is ignored (even if it is a > field postblit). Once the postblit is going to be deprecated we > can do the opposite and use the copy constructor and ignore the > postblit. > > If @implicit is going to be introduced then that is going to be a > DIP on its own. Yay! Thank you. - Jonathan M Davis
Re: Then new forum moderation
On Saturday, 22 September 2018 at 16:48:35 UTC, SashaGreat wrote:
I'll not create a topic to check this behavior, but this
message doesn't show up when replying inside a topic.
PS: By the way the CAPTCHA is awful, look what they throw to us:
int v()
{
return 26 % 3
? 13 / 3
: 42 % 5;
}
I mean
S.G.
The captchas are awful, why would you want to waste brain cycles
on that if you wanna send a one line response or so. Why not have
captchas like most other websites that give you a random
selection of letters/numbers in an image file like "2B4aHg". You
just need to type them into a text field. A programming /
D-specific captcha is a bit nahhh. But it tells you something
about the mentality...
Re: Copy Constructor DIP and implementation
On Tuesday, 25 September 2018 at 12:33:30 UTC, RazvanN wrote: After discussing with Walter and Andrei we have decided that we are going to drop @implicit for now as it may cause bugs (as Jonathan has highlighted) and consider constructors that have the form this(ref $q1 S rhs) $q2 as copy constructors. I will update the DIP with more information. Also, regarding the cohabitation between postblit and copy constructor: in order to make the transition smoother, whenever a postblit and a copy constructor are found togheter in a struct, the former is used and the latter is ignored (even if it is a field postblit). Once the postblit is going to be deprecated we can do the opposite and use the copy constructor and ignore the postblit. If @implicit is going to be introduced then that is going to be a DIP on its own. Thanks! I still think a -dip10xx flag to control which to prefer is worth doing, since a) it won't be hard to do and will make the transition smoother still , and b) IIRC the motivating factor for this is memory safety. Delaying memory safety while waiting for a deprecation period to expire ( O(years) ) for code that wants to remain backwards compatible with older compiler versions is not something we should be encouraging. In the deprecation period if no flag is given prefer postblit to copy if both are defined, if flag is given prefer copy over postblit. Nic
Warn on unused imports?
I'm playing with a branch of DMD that would warn on unused
imports:
https://github.com/FeepingCreature/dmd/tree/feature/Issue-3507-warn-on-unused-imports
Two problems have arisen.
First:
import std.stdio;
void foo(T)() { writeln("Hello World"); }
foo.d: Warning: unused import
To be fair, it's not *wrong*: if you remove the import, the
module itself compiles just fine. In any case, it's trivial to
instead move the import into the template.
The real problem is this:
import std.format;
class TestException(T) : FormatException { }
Now I can't move the import inside the template, because it's
needed at the point of instantiation, but not inside the template
scope *per se*.
I could require the class to be written as
template TestException(T) {
import std.format;
class TestException : FormatException { }
}
but that's kind of terrible.
I've been working around this for now, with import std.format :
FormatException, but I'm not really happy with it.
Any ideas?
Re: Warn on unused imports?
On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature wrote: I'm playing with a branch of DMD that would warn on unused imports: [...] For instance, I've been thinking about hiding the warning behind an additional flag (-wunused-imports or -wu?) so that it's opt-in. Would that be an acceptable approach?
Re: Forums intermittently going down?
On Friday, 21 September 2018 at 00:57:42 UTC, Vladimir Panteleev wrote: On Monday, 17 September 2018 at 11:51:04 UTC, Vladimir Panteleev wrote: The high load is temporary, but will take a week or two to resolve. Performance should now be back to normal. forum.dlang.org is temporarily down for maintenance, and should be back up shortly. Apologies for the inconvenience. forum.dlang.org is temporarily down for maintenance, and should be back up shortly. Apologies for the inconvenience. forum.dlang.org is temporarily down for maintenance, and should be back up shortly. Apologies for the inconvenience. forum.dlang.org is temporarily down for maintenance, and should be back up shortly. Apologies for the inconvenience. forum.dlang.org is temporarily down for maintenance, and should be back up shortly. Apologies for the inconvenience. forum.dlang.org is temporarily down for maintenance, and should be back up shortly. Apologies for the inconvenience. G! For a TEXT ONLY newsgroup proxy... come one guys!
Re: Warn on unused imports?
On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature wrote: I'm playing with a branch of DMD that would warn on unused imports: Honestly, I hate these types of warnings/errors. It makes playing with and designing code such a chore. I hope this is opt-in.
Re: Can I create static c callable library?
On Tuesday, 25 September 2018 at 12:05:21 UTC, Jonathan M Davis wrote: If you use -betterC, then it's trivial, because your D program is restricted to extern(C) functions and features which don't require druntime. It can also be done without -betterC (and thus with druntime), but it gets to be _way_ more of a pain, because it requires that you manually initialize druntime - either by forcing whatever is using your "C" library to call a specific function to initialize druntime before using any of its normal functions or by having every function in the library check whether druntime has been initialized yet and initialize it if it hasn't been before it does whatever it's supposed to do. Shouldn't it be possible to use a C initialization function, i.e. pragma(crt_constructor) to initialize druntime? Then it only needs to be initialized once and it's not required to check if it's initialized all the time. -- /Jacob Carlborg
Re: Warn on unused imports?
On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature
wrote:
I'm playing with a branch of DMD that would warn on unused
imports:
https://github.com/FeepingCreature/dmd/tree/feature/Issue-3507-warn-on-unused-imports
Two problems have arisen.
First:
import std.stdio;
void foo(T)() { writeln("Hello World"); }
foo.d: Warning: unused import
To be fair, it's not *wrong*: if you remove the import, the
module itself compiles just fine. In any case, it's trivial to
instead move the import into the template.
The real problem is this:
import std.format;
class TestException(T) : FormatException { }
Now I can't move the import inside the template, because it's
needed at the point of instantiation, but not inside the
template scope *per se*.
I could require the class to be written as
template TestException(T) {
import std.format;
class TestException : FormatException { }
}
but that's kind of terrible.
I've been working around this for now, with import std.format :
FormatException, but I'm not really happy with it.
Any ideas?
Doesn't the "from" idiom work?
I'm not sure if it is allowed at the template declaration
template from(string moduleName)
{
mixin("import from = " ~ moduleName ~ ";");
}
class TestException(T) from!"std.format".FormatException
: FormatException
{
}
Re: Warn on unused imports?
On Tuesday, 25 September 2018 at 13:14:36 UTC, Jonathan M Davis wrote: If something is definitively wrong, then it should be an error. If it's not definitively wrong, then the compiler shouldn't say anything about it, and it should be left up to a linter tool of some kind like dcd. - Jonathan M Davis If that's the way D wanted to go, it shouldn't have turned itself into a metaprogramming monster that's completely unevaluable by Linter tools, *or* it should offer some way to dump a fixed-format lowered representation with line number information that tools can analyze. As it stands, it is literally impossible to evaluate whether an import is unused without evaluating the entire compile-time subset of D.
Re: Warn on unused imports?
On Tuesday, 25 September 2018 at 14:15:32 UTC, Dominikus Dittes
Scherkl wrote:
On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature
wrote:
I'm playing with a branch of DMD that would warn on unused
imports:
https://github.com/FeepingCreature/dmd/tree/feature/Issue-3507-warn-on-unused-imports
Two problems have arisen.
First:
import std.stdio;
void foo(T)() { writeln("Hello World"); }
foo.d: Warning: unused import
To be fair, it's not *wrong*: if you remove the import, the
module itself compiles just fine. In any case, it's trivial to
instead move the import into the template.
The real problem is this:
import std.format;
class TestException(T) : FormatException { }
Now I can't move the import inside the template, because it's
needed at the point of instantiation, but not inside the
template scope *per se*.
I could require the class to be written as
template TestException(T) {
import std.format;
class TestException : FormatException { }
}
but that's kind of terrible.
I've been working around this for now, with import std.format
: FormatException, but I'm not really happy with it.
Any ideas?
Doesn't the "from" idiom work?
I'm not sure if it is allowed at the template declaration
template from(string moduleName)
{
mixin("import from = " ~ moduleName ~ ";");
}
class TestException(T) from!"std.format".FormatException
: FormatException
{
}
class TestException(T) : from!"std.format".FormatException?
That should work, but it's kind of a big step. In any case, I'll
never get a weird hacky template like that through code review :)
Might as well make import an expression - class TestException(T)
: (import std.format).FormatException. In any case, it's probably
not viable to solve the problem that a warning has a false
positive by introducing a workaround in the language - imo,
that'd rather mean the warning just isn't viable.
(It's so useful, though!)
Maybe stick the info in -v or -deps?
SOLVED: I'll put it in -deps
On Tuesday, 25 September 2018 at 14:28:48 UTC, FeepingCreature wrote: Maybe stick the info in -v or -deps? Actually, -deps is the perfect place for it. It needs to recursively evaluate modules anyways, so it'll see an import even if it was only used from a template. And it doesn't spam up warnings, and the -deps info is made to be extensible anyways. Great! I'll port it to there.
Re: Warn on unused imports?
On Tuesday, September 25, 2018 7:03:30 AM MDT FeepingCreature via
Digitalmars-d wrote:
> I'm playing with a branch of DMD that would warn on unused
> imports:
>
> https://github.com/FeepingCreature/dmd/tree/feature/Issue-3507-warn-on-unu
> sed-imports
>
> Two problems have arisen.
>
> First:
>
> import std.stdio;
>
> void foo(T)() { writeln("Hello World"); }
>
> foo.d: Warning: unused import
>
> To be fair, it's not *wrong*: if you remove the import, the
> module itself compiles just fine. In any case, it's trivial to
> instead move the import into the template.
>
> The real problem is this:
>
> import std.format;
>
> class TestException(T) : FormatException { }
>
> Now I can't move the import inside the template, because it's
> needed at the point of instantiation, but not inside the template
> scope *per se*.
>
> I could require the class to be written as
>
> template TestException(T) {
>import std.format;
>class TestException : FormatException { }
> }
>
> but that's kind of terrible.
>
> I've been working around this for now, with import std.format :
> FormatException, but I'm not really happy with it.
>
> Any ideas?
Honestly, in general, warnings are a terrible idea. Anything that's a
warning in your code has to be fixed, because it's bad practice to leave
warnings in your code, meaning that ultimately, there's not much difference
between a warning and an error. To make matters worse, there's a compiler
flag that turns warnings into errors. And when you combine that with stuff
like is(typeof(...)) and template constraints, whether you use that compiler
flag or not could actually change the resulting program. So, as it stands,
warnings are an even worse idea in D than they are in other languages.
Walter likes to talk about how warnings in C/C++ are there simply because
folks couldn't agree on what should or shouldn't be an error in the
language.
If something is definitively wrong, then it should be an error. If it's not
definitively wrong, then the compiler shouldn't say anything about it, and
it should be left up to a linter tool of some kind like dcd.
- Jonathan M Davis
[Issue 19264] New: byCodeUnit should compare with strings
https://issues.dlang.org/show_bug.cgi?id=19264
Issue ID: 19264
Summary: byCodeUnit should compare with strings
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: enhancement
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: schvei...@yahoo.com
In order for byCodeUnit to be a near drop-in replacement for strings, it would
be nice to have them compare directly with strings.
This means, I would expect this to work:
assert("hello".byCodeUnit == "hello");
This probably means adding opEquals overloads for everything, which also means
adding toHash overloads.
I'd say just comparing to the base type should be sufficient, no need for
transcoding for comparison.
--
[Issue 19264] byCodeUnit should compare with strings
https://issues.dlang.org/show_bug.cgi?id=19264
--- Comment #1 from Steven Schveighoffer ---
It shouldn't matter the constancy of the original.
This should also work:
assert("hello".byCodeUnit == "hello".dup.byCodeUnit);
--
Re: Can I create static c callable library?
On 9/25/18 10:13 AM, Jacob Carlborg wrote: On Tuesday, 25 September 2018 at 12:05:21 UTC, Jonathan M Davis wrote: If you use -betterC, then it's trivial, because your D program is restricted to extern(C) functions and features which don't require druntime. It can also be done without -betterC (and thus with druntime), but it gets to be _way_ more of a pain, because it requires that you manually initialize druntime - either by forcing whatever is using your "C" library to call a specific function to initialize druntime before using any of its normal functions or by having every function in the library check whether druntime has been initialized yet and initialize it if it hasn't been before it does whatever it's supposed to do. Shouldn't it be possible to use a C initialization function, i.e. pragma(crt_constructor) to initialize druntime? Then it only needs to be initialized once and it's not required to check if it's initialized all the time. I don't know if that's the right call. pragma(crt_constructor) tasks run *before* C main. If you are initializing the runtime, it means you are running D static ctors. Since C initialization functions have no order to them, it's possible that some initialization functions in the D runtime are using uninitialized pieces of the C runtime. But of course, I'm not sure. I just wouldn't trust it if it were me. We don't test initializing the D runtime before C main is started (in which case, the C runtime is guaranteed to be set up). Does anyone know if the C runtime is set up before these functions are run? Is it guaranteed? -Steve
Re: Forums intermittently going down?
On Monday, 17 September 2018 at 11:02:39 UTC, Michael wrote: ... Yeah it happened again today. I heard this site was made in D, maybe is because the GC?
