Re: A function to split a range into several ranges of different chunks
On Monday, 14 September 2020 at 07:49:31 UTC, Andrej Mitrovic
wrote:
-
import std.range;
import std.stdio;
void main ()
{
auto range = sequence!((a, n) => n);
// works, but the chunks are all the same length
auto rngs = range.chunks(4);
writeln(rngs[0]);
writeln(rngs[1]);
writeln(rngs[2]);
// want this
auto ranges = range.???(3, 4, 5);
writeln(ranges[0] == [1, 2, 3]);
writeln(ranges[1] == [4, 5, 6, 7]);
writeln(ranges[2] == [8, 9, 10, 11, 12]);
}
-
Do you know of a simple way to do this? It's essentially
similar to chunks, except the chunks themselves would not be of
the same length.
You can think of a good name for '???' here. Maybe this is
already possible by combining functionality in std.range - but
I came up short.
You likely want to get involved / raise your support here:
https://github.com/dlang/phobos/pull/7600
Re: BetterC + WASM Update
On Tuesday, 1 September 2020 at 20:39:58 UTC, Mike Brown wrote: Hi All, Thank you for your replies. My tests have been via compiler explorer. https://godbolt.org/z/4f9nKj I have done this without -BetterC, as the dynamic array fails. I guess that uses GC? Is there an alternative that works with BetterC for dynamic arrays? You could try http://mir-algorithm.libmir.org/mir_rc_array.html or the planned core.experimental.rcarray (https://github.com/dlang/druntime/pull/2679).
Re: Why is there no range iteration with index by the language?
On Wednesday, 10 June 2020 at 01:35:32 UTC, Q. Schroll wrote: On Wednesday, 10 June 2020 at 00:53:30 UTC, Seb wrote: It's a bit more complicated though as you need to avoid subtle breakage with ranges that return tuples that are auto-expanded like e.g. `foreach (k,v; myDict)`. Okay, I can accept that. It's a poor decision, but well, it is what it is. Anyhow, I would be highly in favor of DMD doing this. It's one of those many things that I have on my list for D3 or a D fork. Is there any "official" or at least public list for D3 suggestions? Many people here talk about it recently... No, there's nothing "official" not public lists yet. However, there are two good related wiki pages: https://wiki.dlang.org/Language_issues https://wiki.dlang.org/Language_design_discussions
Re: 32 bit phobos
On Tuesday, 9 June 2020 at 17:58:56 UTC, welkam wrote: I tried to compile a 32 bit executable but my system does not have 32 bit phobos. How do I get 32 bit phobos? I am using Manjaro. dmd -m32 source/test2.d /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../libphobos2.a when searching for -lphobos2 /usr/bin/ld: skipping incompatible /usr/lib/libphobos2.a when searching for -lphobos2 /usr/bin/ld: cannot find -lphobos2 collect2: error: ld returned 1 exit status Error: linker exited with status 1 Download a DMD archive (.tar.xz) from https://dlang.org/download.html or use the official install script. DMD archives contain both 32 and 64-bit binaries.
Re: Why is there no range iteration with index by the language?
On Tuesday, 9 June 2020 at 23:53:16 UTC, Q. Schroll wrote:
Is there any particular reason why std.range : enumerate is a
thing and
foreach (i, e; range) { ... }
doesn't work from the get-go? I wouldn't have such an issue
with it if static foreach would work with enumerate just fine.
As far as I can tell,
foreach (e; range) { ... }
is being lowered to
for (auto _range = range; !_range.empty; _range.popFront)
{
auto e = _range.front;
...
}
So why cant DMD rewrite
foreach (i, e; range) { ... }
to
for (auto _range = range, index = size_t(0); !_range.empty;
_range.popFront, ++index)
{
size_t i = index;
auto e = _range.front;
...
}
Doesn't seem like a big deal, does it? I'm asking because I
suspect there's an odd reason I have no idea and I whish to be
educated.
It's a bit more complicated though as you need to avoid subtle
breakage with ranges that return tuples that are auto-expanded
like e.g. `foreach (k,v; myDict)`.
So IIRC the main reason why D's foreach magic isn't doing this is
that it was argued that this problem is not significant enough to
be worth fixing as there's enumerate and "there's bigger fish to
fry".
Anyhow, I would be highly in favor of DMD doing this. It's one of
those many things that I have on my list for D3 or a D fork.
Re: DMD 2.092 and DIP 25
On Saturday, 30 May 2020 at 07:00:07 UTC, Mike Parker wrote:
The following declarations now give a deprecation warning:
```d
struct ErrorInfo {
private:
char[32] _error;
char[96] _message;
public @nogc nothrow @property:
/**
Returns the string "Missing Symbol" to indicate a
symbol load failure, and
the name of a library to indicate a library load
failure.
*/
const(char)* error() const { return _error.ptr; }
/**
Returns a symbol name for symbol load failures, and a
system-specific error
message for library load failures.
*/
const(char)* message() const { return _message.ptr; }
}
```
I find it rather annoying, as I'm returning `const(char)*` and
not `char*`, but it is what it is. My question is, if I add
`return` to the function declarations, will this compile all
the way back to DMD 2.067 *without* `-preview=dip25`? It works
on 2.091.0. I always assumed a preview feature's syntax wasn't
supported without the preview switch.
Return is actually pretty old, so it will compile:
https://run.dlang.io/is/DgbYU9
Typically -preview flags are just looked at during the semantic
phases.
Another solution could be to turn the functions into templates
and let the compiler do its attribute inference.
Re: any chance to get it working on windows xp?
On Sunday, 17 May 2020 at 22:30:22 UTC, a beginner wrote: [...] You could try grabbing a newer dub release binary from here: https://github.com/dlang/dub/releases There are two versions (installer + zip archive). It looks like you're better off with the zip archive. Alternatively, if you have a working compiler building dub from scratch isn't hard. You just need to clone the repo and run the build script (build.bat in your case). Good luck!
Re: How to run program with "dmd -i" compiler swich ?
On Friday, 15 May 2020 at 14:09:00 UTC, Vinod K Chandran wrote: Hi, For some unknown reasons, dub is not working for me. But i can build my program with "dmd -i". But i would like to know if there is any code to run my program with "dmd -i". Note : "rdmd" is also working but it creates the exe file in temp directory, so my AV is catching it every time. Its annoying. Is it possible to instruct rdmd to create executable in somewhere else ? https://dlang.org/rdmd.html You could use --temp-dir or specify the output manually with -of https://dlang.org/dmd-linux.html#switch-of
Re: DMD 2.090.1: SIGILL, Illegal instruction on (ahem) intel Pentium III
On Thursday, 27 February 2020 at 00:36:49 UTC, kdevel wrote:
```test.d
void main ()
{
int [] v = new int [10];
}
```
$ [...]linux/bin32/dmd test
$ gdb test
[...]
(gdb) r
[...]
Program received signal SIGILL, Illegal instruction.
0x0809ad14 in
_D2gc4impl12conservativeQw3Gcx10smallAllocMFNbkKkkxC8TypeInfoZPv ()
[...]
(gdb) disass
[...]
0x0809ad14
<_D2gc4impl12conservativeQw3Gcx10smallAllocMFNbkKkkxC8TypeInfoZPv+172>: movsd -0x58(%ebp),%xmm0
Does this exception relate to [1] and shall I file a bug or do
I have to decommission my PIII?
I think so.
Have you tried:
1) LDC on your machine?
2) the DMD version before this change?
Re: Speeding up compilation of template-heavy code
On Saturday, 22 February 2020 at 11:26:19 UTC, Per Nordlöw wrote: We're looking for a way to speed up compilation of template-heavy code. So we are trying to find out which parts of the code that is most costly to compile. Is there a dmd flag that shows the code after template instantiations has been performed? Or some other dmd flag that can help out finding hot-spots in the compiler in our case. https://github.com/CyberShadow/dmdprof
Re: Dub - vibe.d - hunt framework ... problems
On Saturday, 1 February 2020 at 10:35:52 UTC, seany wrote: Hi I want to start a small server, that will be accessible form outside. Not a huge deal right? Not quite. [...] What version of dub did you install? 1.19 should be the latest.
Re: Dmd install to new Windows 10 system can't run app.d
On Thursday, 21 November 2019 at 08:30:33 UTC, zoujiaqing wrote: 1. Download dmd.2.088.1.windows.7z 2. Unzip it to D:\Develop\dmd2 3. Add ENV D:\Develop\dmd2\windows\bin to System Path 4. Run `dub --version` and `dmd --version` in powershell is OK 5. dub ini myproject (no dependency) 6. Run `cd myproject` and `dub run` is error... [...] Note this line: Running .\myproject.exe Program exited with code -1073741515 Your compiled program is crashing. Could you run the compiled binary manually and obtain a stack trace?
Re: Is there any writeln like functions without GC?
On Thursday, 31 October 2019 at 16:03:22 UTC, bachmeier wrote: On Thursday, 31 October 2019 at 15:11:42 UTC, Ferhat Kurtulmuş wrote: It would be nice if one reimplement writeln of Phobos by bypassing gc and use a custom nogc exception as described here*? Of course I can imagine that it would be a breaking change in the language and requires so much work for it to be compatible with other std modules/language features. *: https://www.auburnsounds.com/blog/2016-11-10_Running-D-without-its-runtime.html I can't imagine any possibility we'll ever see a breaking change to writeln. It would have to be an addition to Phobos. Yep or Phobos 2 which is more realistic at this point.
Re: dub build doesn't work
On Tuesday, 22 October 2019 at 22:14:02 UTC, OiseuKodeur wrote: Hello, i am having a problem with dub build with this project https://github.com/OiseauKodeur/cervelet/tree/master/source when i try to compile everything go well but when i click to run the .exe it give my an error missing msvcr100.dll, but with rdmd the program run fine Did you try compiling with LDC? Their Windows support is better maintained. Anyhow, so what's happening is that dmd by default uses the digitalmars C runtime (32-bit only) whereas dub will use the llvm linker (64-bit) by default. Now llvm's linker searches for the Microsoft C runtime and can't find it. Hence, the error which you're receiving. You won't need Visual Studio for this, but something which ships msvcr100.dll. So sth. like this should be enough: https://www.microsoft.com/en-us/download/details.aspx?id= BTW if you prefer using optlink and the digitalmars C runtime, you can instruct dub to do so with: --arch=x86
Re: Meta question - what about moving the D - Learn Forum to a seperate StackExchange platform?
On Friday, 18 October 2019 at 10:55:59 UTC, Martin Tschierschke wrote: On Friday, 18 October 2019 at 10:23:28 UTC, jmh530 wrote: On Friday, 18 October 2019 at 07:35:21 UTC, Martin Tschierschke wrote: [snip] I think this is something that's been proposed before, but most people are happy with just asking a question here and usually people are pretty good about helping out with answers when possible. Yes, it works as it is, but it is not the best solution to share know how. And if I just think: Hey, your answer is good, in the mailinglist / forum / newsgroup setup it is impossible to easily vote for it and get a count of this votes. I think it is possible to extended the web front end of the forum in this direction and automatically map an '+1' or '-1' comment (in a single line) to a counter which will be displayed beside the commented post. But this is reinventing the wheel... I am just sad, that many very good questions and answers given in the forum are not so easy to find as they should. In the state of the D survey, there were more people in favor of StackOverflow than D.learn, but to be fair the majority voted for "I don't care" https://rawgit.com/wilzbach/state-of-d/master/report.html
Re: selective tests
On Saturday, 12 October 2019 at 13:50:46 UTC, IGotD- wrote:
On Saturday, 12 October 2019 at 09:52:59 UTC, Jonathan M Davis
wrote:
[...]
This would be helpful. About all C++ unit test frameworks have
named test and you can select a specific one or several in the
command line. Very useful when you work on a specific test and
other tests take some time to finish.
having
unittest OptionalName
{
...
}
would actually help a lot. I don't think this would be very
difficult to implement and wouldn't break anything.
It wouldn't be hard, but someone would need to write a DIP for
it. In the meantime you can use
https://github.com/atilaneves/unit-threaded.
Re: OPTLINK : Warning 9: Unknown Option : OUT
On Monday, 15 July 2019 at 11:56:38 UTC, Vladimir Panteleev wrote: On Monday, 15 July 2019 at 11:48:13 UTC, Anonymouse wrote: dub run digger -- build "stable + druntime#2675" sc.ini and dub output at: https://pastebin.com/jPnh4yEA By default Digger builds D for 32-bit only. However, it looks like Dub is trying to build your code targeting the 64-bit model, whether due to a setting in your project's dub.json, or something else like dub.exe being a 64-bit executable. Yes, dub defaults to 64-bit on 64-bit since 2.085 IIRC. It will also never use optlink by default anymore.
Re: Is there anyone on the official website who is willing to submit this?
On Tuesday, 4 June 2019 at 22:02:54 UTC, FrankLike wrote: Hi,everyone, Is there anyone on the official website who is willing to submit this? If you can submit, the development of D language is a good thing. "https://open.soft.360.cn/regist.php; "link.exe" and "optlink.exe" found the Trojan virus: - Type: "Trojan-HEUR/QVM19.1.A5B9.Malware.Gen" Description: Trojan is a malware disguised as a normal file that steals your account, password, and other private information. Scan Engine: Cloud Feature Engine File path: "...link.exe" File size: (230,472 bytes) Document fingerprint "(MD5)": "5c092ecec3788eb7f7df2673dcbd6f5c" Digital Signature: D Language Foundation Is the digital signature valid: valid Handling suggestions: quarantine files -- Does anyone know what is going on? Is there anyone on the official website who is willing to submit this? If you can submit, the development of D language is a good thing. "https://open.soft.360.cn/regist.php; Thank you. False positives. Unfortunately, virus scanners chronically have problems with the DMD compiler. Probably, because the object file format is very different to the more common mscoff. Please feel free to report this false positives yourself. We don't have the resources to cater for every virus scanner out there. Thanks!
Re: rdmd takes 2-3 seconds on a first-run of a simple .d script
On Tuesday, 28 May 2019 at 05:11:15 UTC, Andre Pany wrote: On Monday, 27 May 2019 at 07:16:37 UTC, BoQsc wrote: [...] I can confirm, without measuring the exact timing, "dmd -run test.d" feels much faster than "rdmd test.d". I would say 1 second instead of 2 seconds. Kind regards André Well, that's because rdmd is an old legacy tool that runs the compiler twice. Use dmd -i or rund (https://github.com/dragon-lang/rund).
Re: [windows] Can't delete a closed file?
On Friday, 10 May 2019 at 08:07:32 UTC, Cym13 wrote: Which C runtime are you using? The old and buggy DigitalMars one or the official MS one? I really don't know, how can I find out? I litterally just used dmd on the script above with no special options then ran the resulting exe. Yeah, so you're using the old and buggy DigitalMars C runtime. So you can use: - use LDC - use -m64 - use -ms32mscoff and there's a high chance that your problem will go away ;-) They all use the universal C runtime.
Re: [windows] Can't delete a closed file?
On Thursday, 9 May 2019 at 13:18:44 UTC, Cym13 wrote: On Thursday, 9 May 2019 at 13:02:51 UTC, Rene Zwanenburg wrote: On Thursday, 9 May 2019 at 12:33:37 UTC, Cym13 wrote: [...] You could try to use the find handle function in Process Explorer to figure out what process has the file open: https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer I did just that and my test program truly is the only process on the system having that file open. Unless I'm missing something that process-explorer doesn't see and is even true in wine's ultra light environment comprised of a single process, this is definitely not the issue. Which C runtime are you using? The old and buggy DigitalMars one or the official MS one?
Re: __gshared 32 & 64 bit
On Monday, 6 May 2019 at 18:21:28 UTC, Jacob Carlborg wrote: On 2019-05-06 15:43, Aldo wrote: Hello, is there a difference between __gshared on 32 and 64 bit apps ? Shouldn't be. Yeah, maybe you're running into issues with the antique DigitalMars runtime? It has well-known issues with concurrency. Try LDC or the COFF output (-m32mscoff).
Re: dmd -unittest -main -run: undefined reference to `_D1c12__ModuleInfoZ'
On Wednesday, 1 May 2019 at 22:46:34 UTC, kdevel wrote: On Wednesday, 1 May 2019 at 22:35:12 UTC, ag0aep6g wrote: On 02.05.19 00:25, kdevel wrote: dmd -unittest -main -run package.d c/package.d That doesn't compile c/package.d. Everything after `-run package.d` is interpreted as an argument to the compiled program. Thanks for the information. Wouldn't it be better, if everything directly after the `-run` would be taken as argument to the programm? In this case dmd -unittest -main -run package.d would immediately fail due to missing source. Would be, but would also be a breaking change. In the past it has been discussed to use e.g. `--` as a separator, but that PR was rejected because it could only be done in a useful way with breaking changes :/
Re: Recommendations for best JSON lib?
On Sunday, 21 April 2019 at 02:09:29 UTC, evilrat wrote: On Saturday, 20 April 2019 at 20:44:22 UTC, Guillaume Piolat wrote: On Saturday, 20 April 2019 at 18:49:07 UTC, Nick Sabalausky (Abscissa) wrote: I only need to read arbitrary JSON data, no need for writing/(de)serialization. std.json is simple as pie. However IIRC it fails with trailing commas, means that for reading user written JSON's it might be annoying. I also tried experimental std json, asdf and vibe.d. The only one that worked for me is vibe.d JSON subpackage, and adding simple commented lines stripping is simple with phobos, because there is absolutely no libraries that can handle JSON comments yet. (yes, I know it's not standard) Experimental std.json is based on vibe.d's JSON package.
Re: bug in compiles?
On Thursday, 11 April 2019 at 23:55:18 UTC, Alex wrote: to judge people objectively. This isn't a nursery school and we are not 3 year olds... Exactly. So start behaving like a grown-up and professional. When you ask someone for help on the street, do you curse at him too?
Re: Dummy template parameter vs empty template parameter list
On Wednesday, 10 April 2019 at 20:37:38 UTC, Ben Jones wrote: Looking through Phobos code there's a bunch functions defined with dummy template types: void whatever(TDummy = void)( int x, ...) //TDummy is never used Why not just use an empty template parameter list? void whatever()(int x, ...) My gut tells me that his is a workaround for an old limitation preventing empty template lists, but figured I'd ask. It depends on the specific function, but there's lots of old code in Phobos. In this case it could be that it was a workaround for a DMD bug or limitation that has since been fixed. So never be afraid to question Phobos code and give it the full scrutiny it needs. A good rule of thumb is that if all unittests still pass, the reason was historic ;-)
Re: DRuntime arguments
On Wednesday, 10 April 2019 at 12:11:06 UTC, Cym13 wrote: Where can I find a list of all druntime arguments supported? Things like --DRT-covopt='merge:1' or --DRT-gcopt='gc:profile=1' are not easy to guess and I can't find any centralized documentation. There isn't any yet.
Re: Overloads not returning appropriate info. [Field reflunkory]
On Tuesday, 9 April 2019 at 16:30:53 UTC, Alex wrote: On Tuesday, 9 April 2019 at 14:59:03 UTC, Adam D. Ruppe wrote: [...] I didn't say the language. The point with the language is that it could have built in semantics to do reflection in a inform way(__traits is somewhat uniform but messy and then one has std.traits which then makes it not uniform). [...] Have you considered writing a DIP?
Re: Cannot link vibe.d sample / optlink error
On Tuesday, 9 April 2019 at 06:50:36 UTC, Michal Minich wrote: On Monday, 8 April 2019 at 14:49:02 UTC, Radu wrote: [...] Thank you Radu! Your answer helped and hello word is now running :) After using --verbose I found that I do not have libcmt.lib on my computer at all. Though I have Visual Studio 2019 installed, it is for C#. Looks like when you have VS 2019, then classical redistributable packages are not supported any more. After a bit of experimenting I found adding "MSVC v142 - VS2019 C== x86/x85 build tools (v13.20" from VS installer installed the libcmt.lib. After running dub with --arch=x86_mscoff from VS command line it worked. See also this related issue with quite some discussion on the topic: https://issues.dlang.org/show_bug.cgi?id=19760
Re: Iterate/sort associative array by value?
On Monday, 8 April 2019 at 18:04:28 UTC, kdevel wrote:
On Sunday, 7 April 2019 at 17:16:12 UTC, Seb wrote:
---
["a": 1].byPair.array.sort!((a, b) => a.value <
a.value).release.each!writeln;
---
What's the purpose of .release? The documentation in
https://dlang.org/phobos/std_range.html#.SortedRange.release is
rather monosyllabic.
As others have already explained, you'll get the original range
back (instead of the SortedRange).
Sometimes, this is useful.
The obvious example is assigning back to the original range:
---
import std.experimental.all;
void main()
{
auto arr = ["a": 1].byPair.array;
arr = arr.sort!((a, b) => a.value < a.value);
}
---
https://run.dlang.io/is/8sFxVb
OTOH this works:
---
import std.experimental.all;
void main()
{
auto arr = ["a": 1].byPair.array;
arr = arr.sort!((a, b) => a.value < a.value).release;
}
---
https://run.dlang.io/is/TgXUZj
In the example where I used it, you won't need it.
Sorry for the confusion, but as it's often every now and then
pretty useful, I thought it is a nice idea to give it more
spotlight as it's one of the lesser known parts of Phobos.
Re: Iterate/sort associative array by value?
On Monday, 8 April 2019 at 08:31:33 UTC, Dennis wrote: On Monday, 8 April 2019 at 07:53:23 UTC, Robert M. Münch wrote: Why does DMD not give a hint, that an import from the standard lib might be missing? I find these explicit import statements very annyoing. There currently are a few hard-coded import hints for common functions: https://github.com/dlang/dmd/blob/master/src/dmd/imphint.d But it definitely could be better. Yeah, it's not too hard to improve this. A quick start: https://github.com/dlang/dmd/pull/9576
Re: Iterate/sort associative array by value?
On Sunday, 7 April 2019 at 18:22:00 UTC, Robert M. Münch wrote:
On 2019-04-07 17:16:12 +, Seb said:
Then you can do:
---
["a": 1].byPair.array.sort!((a, b) => a.value <
a.value).release.each!writeln;
---
You'll have a sorted array with key and value props.
This seems to be really tricky:
int[uint] myArray;
foreach(key, value; myArray.byPair.array.sort!((a, b) =>
a.value < a.value)){...}
Error: no property sort for type Tuple!(uint, "key", int,
"value")[]
You forgot to import std.algorithm.
In doubt, use std.experimental.all or with 2.086 it will just be
`import STD;`
Re: Iterate/sort associative array by value?
On Sunday, 7 April 2019 at 20:02:15 UTC, Seb wrote:
On Sunday, 7 April 2019 at 18:22:00 UTC, Robert M. Münch wrote:
On 2019-04-07 17:16:12 +, Seb said:
Then you can do:
---
["a": 1].byPair.array.sort!((a, b) => a.value <
a.value).release.each!writeln;
---
You'll have a sorted array with key and value props.
This seems to be really tricky:
int[uint] myArray;
foreach(key, value; myArray.byPair.array.sort!((a, b) =>
a.value < a.value)){...}
Error: no property sort for type Tuple!(uint, "key", int,
"value")[]
You forgot to import std.algorithm.
In doubt, use std.experimental.all or with 2.086 it will just
be `import STD;`
*import std;
(auto-correct from my phone was too eager.)
Re: Iterate/sort associative array by value?
On Sunday, 7 April 2019 at 16:44:01 UTC, Robert M. Münch wrote: On 2019-04-07 16:24:52 +, Cym13 said: You could use sort to gather the indexes in order then traverse from there: aa.byKey.array.sort!((a, b) => aa[a] That doesn't work: Error: no property array for type Result With a wrapper caching that order and making it transparent as well as update on insertion (which should be in log(n) since you know have an ordered list of indexes, you can use dichotomy to update the indexes without walking all your AA again) I think you could have a nice little container. However if double entry is necessary maybe a simpler 2D array would be easier to work with? At the point where I need this sorted array, nothing will change it. It's a log output. So, not necessary to make things more complex. Then you can do: --- ["a": 1].byPair.array.sort!((a, b) => a.value < a.value).release.each!writeln; --- You'll have a sorted array with key and value props.
Re: CTFE & code generators based on PEG grammars?
On Saturday, 6 April 2019 at 12:06:22 UTC, Robert M. Münch wrote: I like the idea of DSL which are transpiled into the target language that gets compiled or are interpreted at run-time. Since D is compiled, I would like to transpile the DSL to D at compile-time. The idea is, that I can write a string (or maybe even a scope block?) in my DSL and use a CTFE grammer to transpile the code. Does anybody has any experience with such an approach? Are the CTFE facilities overall sufficient to implement something like this? Or is there a much better approach? One of the most famous examples here is Vibe.d's Diet template: https://github.com/rejectedsoftware/diet-ng tl;dr: CTFE is sufficient, but the downside is that it will be run everytime you build your program which can increase the build time.
Re: Issues with std.net.curl on Win 10 x64
On Monday, 25 March 2019 at 19:02:18 UTC, cptgrok wrote: On Monday, 25 March 2019 at 16:44:12 UTC, Andre Pany wrote: First idea, please switch to x86_64 if possible. This will also be the default of Dub in the next dmd release or the release after. Kind regards Andrew Figured out --arch=x86_64, thanks! Sadly I don't see any change. I'm not having luck finding known curl issues similar to what I am experiencing. I have a sneaking suspicion that the web service I am using is doing some nonsense in the background. Might try a packet capture to better see what's up. Alternatively, you could always give requests a shot: https://code.dlang.org/packages/requests It's the unofficial successor of std.net.curl.
Re: Why does D language do not support BigDecimal type?
On Monday, 11 March 2019 at 15:23:34 UTC, BoQsc wrote: There is Money datatype that can be provided by using a third party package: https://code.dlang.org/packages/money But that's only for money, what about math? Why such fundamental as BigDecimal is still not included into the D language itself? There is BigInt. If it is unavoidable to use Floating point, how can I quickly and simply understand the rules of using float to make the least error, or should I just find a third party package for that as well? There is an article on that, but it is not that straight forward: https://dlang.org/articles/d-floating-point.html Basically any thing that I find on Google, that include explaining floating point are badly written and hard to understand for the outsider lacking ability to understand advanced concepts. I recommend that you learn floating point math as this will help you not only in programming in D, but in any other language. In any case, if you need super-high precision, you might want to give decimal [1] a try. [1] https://code.dlang.org/packages/decimal
Re: Phobos in BetterC
On Friday, 8 March 2019 at 09:24:25 UTC, Vasyl Teliman wrote: I've tried to use Mallocator in BetterC but it seems it's not available there: https://run.dlang.io/is/pp3HDq This produces a linker error. I'm wondering why Mallocator is not available in this mode (it would be intuitive to assume that it's working). Also I would like to know what parts of Phobos are available there (e.g. std.traits, std.typecons...). Thanks in advance. Just for reference there's also a few number of tests in Phobos annotated with @betterC. As expected, they are tested with -betterC. However, at the moment this annotated subset is pretty small and not exposed to the documentation. Though it shouldn't be too hard to increase the subset and mark the annotated function in the documentation.
Re: Executing a D script without an [extension in the filename] leads to an error
On Friday, 1 March 2019 at 11:38:51 UTC, BoQsc wrote: On Friday, 1 March 2019 at 09:27:33 UTC, Cym13 wrote: On Friday, 1 March 2019 at 09:00:43 UTC, BoQsc wrote: [...] In such questions it's important to show your shebang since that's what runs your script. Given your symptoms I guess you're using the following: #!/bin/env rdmd And indeed rdmd won't call your script if it doesn't have the proper extension. Try using this instead: #!/bin/dmd -run The shebang I used: #!/usr/bin/env rdmd I was visiting Dlang Tour and that's where I've got an example of shebang usage, directly from there: https://tour.dlang.org/tour/en/welcome/run-d-program-locally#/on-the-fly-compilation-with-rdmd The shebang you suggested actually works perfectly: #!/bin/dmd -run "And indeed rdmd won't call your script if it doesn't have the proper extension." Then why does Dlang Tour includes shebang: #!/usr/bin/env rdmd Instead of the one you mentioned, that is fool proof. (#!/bin/dmd -run) Is that an error/mistake in Dlang Tour guide? Well, because it isn't fool proof either ;-) It won't work once you start using more files as you would then need the -i flag , but unfortunately most systems don't support more than one shebang argument. I think it's simply a missing feature of rdmd to accept files without an extension as D programs (though of course the tour could be improved to be more explanatory here too).
Re: Executing a D script without an [extension in the filename] leads to an error
On Friday, 1 March 2019 at 16:45:38 UTC, Seb wrote: On Friday, 1 March 2019 at 14:50:45 UTC, Jesse Phillips wrote: I don't know what value it brings with the -i switch existing. Almost none, except that it's twice as slow as DMD because it needs to run DMD twice to learn about all the dependencies. It's only useful for a few small things now: - '-e': evaluate d code with all modules automatically imported (though now that there's std.experimental.all this value is gone too) - makefile deps generation - shebang line (as arguments can't be part of the shebang line) (The list is not complete) I forgot one big reason why rdmd is still nice: caching. It does save the generated dependency file list and checks all modification time stamps, s.t. if nothing has changed, it'll run a cached build
Re: Executing a D script without an [extension in the filename] leads to an error
On Friday, 1 March 2019 at 14:50:45 UTC, Jesse Phillips wrote: I don't know what value it brings with the -i switch existing. Almost none, except that it's twice as slow as DMD because it needs to run DMD twice to learn about all the dependencies. It's only useful for a few small things now: - '-e': evaluate d code with all modules automatically imported (though now that there's std.experimental.all this value is gone too) - makefile deps generation - shebang line (as arguments can't be part of the shebang line) (The list is not complete)
Re: Disable dub from checking internet before building
On Monday, 25 February 2019 at 18:54:03 UTC, Jacob Carlborg wrote: On 2019-02-24 23:51, 0x wrote: How to disable dub from checking internet before building, it's slowing down build whenever it does this. I thought that was fixed [1]. Or is it doing something else? [1] https://dlang.org/changelog/2.082.0.html#upgrade_check Nope, it has been fixed (to my knowledge). Though I think that the OP is using an older version of dub.
Re: Windows Defender won't let me install DMD
On Monday, 18 February 2019 at 16:32:26 UTC, belkin wrote: I am trying to install the compiler and get started on learning D again ( attempted and stopped way back ) This is the error message I am getting. I am on Windows 10. Windows Defender SmartScreen prevented an unrecognized app from starting. Running this app might put your PC at risk. App: dmd-2.084.1.exe Publisher: Unknown publisher There was a error/oversight with the 2.084.1 release. It accidentally didn't get signed, you can try 2.084.0 if you are afraid of the warning. The next release (2.085.0) should be signed again.
Re: Query for -dip1000
On Monday, 11 February 2019 at 09:29:13 UTC, Jonathan M Davis wrote: On Sunday, February 10, 2019 1:04:29 PM MST Per Nordlöw via Digitalmars-d- learn wrote: [...] A quick grep of Phobos shows a version(DIP1000) block in std/typecons.d, which appears to be used to make it so that a particular unittest block is only compiled in when -dip1000 is used, so it looks like there's a version identifier for it. - Jonathan M Davis That one has been added manually: https://github.com/dlang/phobos/blob/master/dip1000.mak The detection would have been better...
Re: dirEntries within static foreach: memory.d(827): Error: fakePureErrno cannot be interpreted at compile time, because it has no available source code
On Monday, 11 February 2019 at 01:05:05 UTC, kdevel wrote: On Monday, 11 February 2019 at 00:54:27 UTC, Seb wrote: On Monday, 11 February 2019 at 00:19:02 UTC, kdevel wrote: [...] You can't read or list files at compile-time. dmd can read files at compile time using the import function [1] Sorry, I should have rephrased: you can't call any OS-level functions at compile-time. This includes std.file.read and std.file.dirEntries.
Re: dirEntries within static foreach: memory.d(827): Error: fakePureErrno cannot be interpreted at compile time, because it has no available source code
On Monday, 11 February 2019 at 00:19:02 UTC, kdevel wrote: I am trying to get this code compiled: ```TemplateStore.d module TemplateStore; import std.path; import std.conv; import std.file; [...] You can't read or list files at compile-time. What are you trying to do?
Re: Purpose of template DECLARE_HANDLE in druntime
On Thursday, 31 January 2019 at 20:51:37 UTC, Andre Pany wrote:
Hi,
I noticed in druntime this template is used often:
package template DECLARE_HANDLE(string name, base = HANDLE) {
mixin ("alias " ~ base.stringof ~ " " ~ name ~ ";");
The disadvantage is, IDEs like IntelliJ are not able to find
the symbols using this template e.g.
mixin DECLARE_HANDLE!("SC_HANDLE");
What is the benefit of this template?
Why can't we just use
alias HANDLE SC_HANDLE;
Kind regards
Andre
Have you tried changing it to alias and check whether the
testsuite still passes?
Druntime is a bit old, so I wouldn't be too surprised if this is
an old relict.
Re: Runtime heterogeneous collections?
On Thursday, 17 January 2019 at 02:27:20 UTC, Neia Neutuladh wrote: On Thu, 17 Jan 2019 02:21:21 +, Steven O wrote: I want to create a heterogeneous collection of red-black trees, and I can't seem to figure out if it's possible. RedBlackTree!int and RedBlackTree!string are entirely different types (they just happen to be generated from the same template). There are two reasonable ways of doing things: 1. Make a wrapper class. Now you can store Object[], or you can make a base class or base interface and use that. 2. Use Variant, which can wrap anything, or the related Algebraic, which can wrap a fixed collection of types. You can use this technique either with the collection types themselves or with the value types. As the OP is most likely looking for Variant, let me link to it: https://dlang.org/phobos/std_variant.html#Variant
Re: Reversing a string
On Friday, 11 January 2019 at 19:16:05 UTC, AlCaponeJr wrote: On Friday, 11 January 2019 at 11:15:05 UTC, Mike James wrote: Check out the origin :-) https://forum.dlang.org/thread/hl8345$2b1q$1...@digitalmars.com?page=1 Indeed a terrible name, please don't tell me this was chosen by vote. By the way currently is there any vote system for naming these things? Al. No. There are zero plans to break a ton of code by changing the name of a symbol in the standard library. It's more likely that someone comes along with a new general purpose library which hasn't seen much usage and thus can define slightly better names.
Re: Creating fixed array on stack
On Saturday, 12 January 2019 at 13:17:00 UTC, Adam D. Ruppe wrote: On Saturday, 12 January 2019 at 08:10:47 UTC, Andrey wrote: But this requires using of C function "alloca". I think this cause some RT overhead (and in output asm code) in comparison with C++ variant. Or I'm not right? alloca is a magical function; a compiler intrinsic that works the same way as the C built-in. Yup, specifically (at least for DMD) it is defined here: https://github.com/dlang/druntime/blob/master/src/rt/alloca.d
Re: Reversing a string
On Friday, 11 January 2019 at 08:05:39 UTC, AndreasDavour wrote: Hi. I've just started to learn some D, so maybe this question is extremely stupid, but please bear with me. [...] Use .retro - it is also lazy and won't allocate: https://run.dlang.io/is/A6bjrC
Re: Generating API documention
On Thursday, 10 January 2019 at 07:04:52 UTC, George wrote: What do people use to generate nice looking and simple html documentation for their projects? I would be glad (and if possible), someone could share some actual instructions rather than just tell me ddoc. For example I have seen the libmir (http://docs.mir.dlang.io/latest/index.html) and I would love to generate something similar for a project I am working on. Thank you and best wishes. George This was actually done with Ddoc (author of the ddoc setup for Mir here) ;-) See: https://github.com/libmir/mir/tree/master/doc It uses the dlang.org Ddoc theme and customizes it a bit, but is fairly tricky to setup and maintain. Also, it doesn't work with dub. For a nice out of the box experience, I would recommend scod https://github.com/MartinNowak/scod Example project: https://github.com/MartinNowak/bloom Also note that with dpldocs.info you'll automatically get documentation for your project once its published on the Dub registry, see e.g. https://pbackus.github.io/sumtype/sumtype.html
Re: Vibe.d throw link error
On Wednesday, 2 January 2019 at 20:52:26 UTC, greatsam4sure wrote: I am using windows 10. I could not run vibe project. It just give me the error: Error: linker exit with status 1 Dmd failed with exit code 1 I have use different dmd from 0.080 till 0.083. The same error. What is the possible cause and solution to this error? Have you tried using the MSCOFF output of DMD?
Re: How to build dmd properly?
On Tuesday, 18 December 2018 at 14:35:46 UTC, unDEFER wrote: What I could build wrong and how to build dmd properly? Maybe you built dmd.d with debug assertions? (ENABLE_DEBUG=1) You can build dmd with the `./build.d` script or `make -f posix.mak -j4` (assuming you are in `src). Anyway, the internal assertions should never fail, so this definitely deserves a bug report if that was the case.
Re: How do I install a library?
On Monday, 10 December 2018 at 00:18:52 UTC, Murilo wrote: Hi guys, thank you for helping me out here, there is this facebook group for the D language, here we can help and teach each other. It is called Programming in D. Please join. https://www.facebook.com/groups/662119670846705/?ref=bookmarks Please stop this spam.
Re: std.algorithm.canFind behavior difference between arrays and elements
On Friday, 7 December 2018 at 19:38:29 UTC, Arun Chandrasekaran wrote: On Friday, 7 December 2018 at 19:12:31 UTC, Seb wrote: On Friday, 7 December 2018 at 18:51:27 UTC, Arun Chandrasekaran wrote: [...] Alternatively to the answers above you can also use a custom lambda for canFind: https://run.dlang.io/is/QOXYbe Just curious, how do we find multiple needles? This throws compilation error assert(hay.canFind!(e => (e.canFind(["111", "222"]; An example in the doc would be helpful. It's variadic: https://run.dlang.io/is/AKkKA9 Please feel free to add an example to the docs.
Re: std.algorithm.canFind behavior difference between arrays and elements
On Friday, 7 December 2018 at 18:51:27 UTC, Arun Chandrasekaran
wrote:
I'm trying to find the needle in the hay that's an array of
strings. So the second assert fails for some reason. Is this
expected? https://run.dlang.io/is/7OrZTA
```
#!/usr/bin/rdmd
void main()
{
import std.experimental.all;
string s1 = "aaa111aaa";
string s2 = "aaa222aaa";
string s3 = "aaa333aaa";
string s4 = "aaa444aaa";
const hay = [s1, s2, s3, s4];
assert(canFind(s1, "111"));
assert(canFind(hay, "111"));
}
```
Why is there a difference in the behavior?
Alternatively to the answers above you can also use a custom
lambda for canFind:
https://run.dlang.io/is/QOXYbe
Re: Is there a function for this?
On Saturday, 6 October 2018 at 13:56:32 UTC, bauss wrote: On Saturday, 6 October 2018 at 13:35:38 UTC, Basile B wrote: On Saturday, 6 October 2018 at 13:17:22 UTC, bauss wrote: [...] see https://www.programming-idioms.org/idiom/119/deduplicate-list. Did you even read my post? I stated I could already write the function myself, but if a standard function existed I'd rather use that. He did and x.redBlackTree[] isn't too bad!
Re: DMD release build being faster than debug!
On Friday, 5 October 2018 at 14:11:22 UTC, Per Nordlöw wrote: I just noticed that building DMD~master via make -f posix.mak BUILD=debug currently takes 3.2 secs while building it via make -f posix.mak BUILD=release takes only 3.0 secs on my Ubuntu 18.04 64-bit machine! Are there more DMD switches other than `BUILD=release` I need to activate to produce the fastest possible compiler binary? Apart for compiling it with LDC, that is. Yeah BUILD more or less only defines in which folder the binaries will be stored as the default BUILD was RELEASE historically and the real release build can take a while and shouldn't be used by default (bad newcomer experience). We tried to change the default BUILD to debug but it was a mess with the CIs :/
Re: What does -vtls compiler flag does and ...
On Wednesday, 3 October 2018 at 20:58:01 UTC, Stanislav Blinov wrote: On Wednesday, 3 October 2018 at 20:41:15 UTC, welkam wrote: I was playing around with dmd`s make file trying to see if I can compile dmd with different compilers and different compilation flags. By playing around I found that some dmd files are compiled with -vtls flag unconditionally and that ldc do not support this flag. First I dont know what -vtls flag does so I looked at documentation... Aren't all variables thread local unless explicitly specified? No, all *static non-immutable* variables are thread-local by default, not just "all variables". What this flag does? Why some files compiled with it and other dont? Why it is added to all compilation targets unconditionally? It does what it says, just prints some diagnostic info. You can just ignore it, i.e. not use it. As for why it's in the makefile, I can only guess that someone keeps it there for diagnostic purposes :) It was added during the transition to a D codebase to avoid regressions. These days its more or less useless as it doesn't fail the build anyhow. Though LDC and GDC still rely on extern(C++) global variables for their interface with the frontend (not TLS static). See also: https://github.com/dlang/dmd/pull/8018
Re: Dub and it's build directory
On Tuesday, 21 August 2018 at 12:31:20 UTC, Petar Kirov [ZombineDev] wrote: What Dub does is what it calls "platform probing" [3]. It creates a temporary .d file containing various `pragma (msg, ..)` statements that output information to stderr during compilation. Of course the question is then: which compiler is used to compile the platform probe file? AFAICS, it uses either the one requested for on the command-line (via --compiler=... ) or via an internal heuristic which is a bit involved [4]. FYI: the plan is to use the new JSON interface (e.g. `dmd -Xi=compilerInfo -Xf=-) soon. See also: https://github.com/dlang/dub/pull/1316
Re: Deduce type of struct in function arguments
On Tuesday, 21 August 2018 at 08:47:53 UTC, Mike Parker wrote: On Tuesday, 21 August 2018 at 08:32:17 UTC, Seb wrote: How and where to vote? At the pull request via +1 and the upcoming "official" discussion of the PR. Except that there's no voting process for DIPs. The Community Review is not intended as a way to vote, simply to provide feedback on it with the aim of making it a better proposal. I know people tend to throw their +1's in there, but I wouldn't expect Walter and Andrei to put any weight on that. I'm aware, but we don't have any other process for people to show their support for a DIP, do we? And for DMD/Druntime/Phobos etc. having a bunch of +1 helps a PR to move faster as we as reviewers can thus realize that this is sth. that's very important to the community.
Re: Deduce type of struct in function arguments
On Tuesday, 21 August 2018 at 06:29:12 UTC, Andrey wrote: On Monday, 20 August 2018 at 17:45:25 UTC, Seb wrote: ... yet. Though you can vote for this DIP and show your support there: https://github.com/dlang/DIPs/pull/71 It even comes with an implementation in DMD already: https://github.com/dlang/dmd/pull/8460 How and where to vote? At the pull request via +1 and the upcoming "official" discussion of the PR. The last discussion was here (https://forum.dlang.org/post/lpixarbirhorkltaq...@forum.dlang.org) and it seems there's no clear consensus on the best syntax for this yet :/
Re: Deduce type of struct in function arguments
On Monday, 20 August 2018 at 12:33:34 UTC, Andrey wrote:
On Monday, 20 August 2018 at 11:38:39 UTC, Paul Backus wrote:
Create an overload of foo that takes two arguments and
combines them into a `Data` struct internally:
void foo(int a, string text)
{
Data data = {a, text};
foo(data);
}
Hmm, not very good solution. In C++ you can not to write type
and compiler will deduce it automatically. In D, as I
understand, this feature isn't supported.
... yet. Though you can vote for this DIP and show your support
there:
https://github.com/dlang/DIPs/pull/71
It even comes with an implementation in DMD already:
https://github.com/dlang/dmd/pull/8460
Re: tryTo: non-throwing variant of std.conv.to
On Wednesday, 15 August 2018 at 09:21:29 UTC, Per Nordlöw wrote:
Have anybody thought about non-throwing variants of std.conv.to
typically named `tryTo`
similar to what Folly
https://github.com/facebook/folly/blob/master/folly/docs/Conv.md#non-throwing-interfaces
does, for instance, as
tryTo(str).then([](int i) { use(i); });
?
Would it be sane to add these to std.conv alongside existing
std.conv.to so that underlying logic in std.conv.to can be
reused?
If so, AFAICT, existing std.conv.to should be implemented on
top of std.conv.tryTo.
Well, for now you can use `ifThrown` from std.exception:
https://dlang.org/phobos/std_exception.html#ifThrown
---
"foo".to!int.ifThrown(42)
---
https://run.dlang.io/is/nlZKOw
Usage of optionals/nullables is sadly not very common in Phobos
and I think if we want everything to work nicely, we probably
have to start a new standard library (or do massive refactorings
of the existing one.)
Re: is this a betterC bug ?
On Tuesday, 14 August 2018 at 16:31:38 UTC, Paul Backus wrote:
On Tuesday, 14 August 2018 at 13:01:57 UTC, learnfirst1 wrote:
enum string[] a = ["a"];
extern(C) void main() {
int i = 0;
auto s = a[i];
}
---
Error: TypeInfo cannot be used with -betterC
Workaround: https://run.dlang.io/is/NZykl0
Source: https://p0nce.github.io/d-idioms/
FYI: staticArray will be part of 2.082, it already works with
dmd-nightly:
https://run.dlang.io/is/tC7tix
Re: is this a betterC bug ?
On Tuesday, 14 August 2018 at 13:01:57 UTC, learnfirst1 wrote:
enum string[] a = ["a"];
extern(C) void main() {
int i = 0;
auto s = a[i];
}
---
Error: TypeInfo cannot be used with -betterC
You can use `static immutable` as a workaround for now:
https://run.dlang.io/is/7HEPst
Re: How to declare static compile-time assoc array inside struct?
On Monday, 13 August 2018 at 13:21:45 UTC, Andrey wrote:
On Monday, 13 August 2018 at 11:53:06 UTC, rikki cattermole
wrote:
You must use a module constructor to initialize it.
Tried this:
static this()
{
Test.DESCRIPTION = [Test.Type.One: "One!", Test.Type.Two:
"It's Two...", Test.Type.Three: "And... Three!"];
}
struct Test
{
// ...
}
I have an error: cannot modify immutable expression DESCRIPTION
What is your other code?
It can work, e.g.:
https://run.dlang.io/is/kAC4pl
Re: InputRange help: (1) repeated dtor calls and (2) managing resources needing free()
On Monday, 13 August 2018 at 04:23:49 UTC, James Blachly wrote: On Thursday, 14 June 2018 at 00:42:25 UTC, James Blachly wrote: ... I assume the (apparent) lack of parity between ctor and dtor is because the "default postblit" (which I figured out for a struct means an empty `this(this)` ctor) is called when a copy is made. My understanding is that I cannot disable the default postblit and still act as a range, correct? Should I be overloading this? 2. Directly related to the above, I need, when the range is consumed, to free() the underlying library's iterator handle. Naively, I had the destructor do this, but obviously with multiple calls to ~this I end up with an error free()'ing a pointer that is no longer alloc'd. What is the correct way to handle this situation in D? Other Range and destructor advice generally (e.g., "You should totally change your design or approach to X instead") is always welcomed. James I think I have a handle on #1 (copy of the range is made for consumption which is why dtor is called more often than ctor), but would still be interested in advice regarding #2 (as well as general Range and dtor advice). Here: https://github.com/blachlylab/dhtslib/blob/master/source/dhtslib/tabix.d#L98 I need to free the library's iterator, but the Range's destructor is the wrong place to do this, otherwise memory is freed more than once. Is it a better approach to (a) somehow guard the call to tbx_itr_destroy or (b) create a postblit that creates a new iterator and pointer? (or (c), None of the above) I would "guard" the call to tbx_itr_destroy by means of reference counting (see below). As above, my understanding is that disabling the default posblit prohibits acting as a Range. That's not true. It just makes the range harder to be used. Last year, for example, it was proposed to make the ranges in std.random non-copyable because you don't want to accidentally copy your random state and it was only that bigger refactorings were planned for std.random which sadly never materialized that this didn't happen. BTW it's very uncommon for empty to do work, it's much more common to do such lazy initialization in `.front`. If I use the range, the destructor seems to be called many, many times. Then you probably make many copies. In some ways, this problem is generalizable to all InputRanges that represent a file or record stream. Yep, and that's why I recommend to have a look at e.g. std.stdio.File: - it does its initialization in the constructor [1] - it uses reference-counting for its allocated space and pointers [2, 3] (File is often shared by default, that's why atomic reference counting is necessary here) Have a look at this minimal example of reference-counting: https://run.dlang.io/is/GF5vbC The copies you see go away when the struct is passed by reference: https://run.dlang.io/is/Uhs5Bt [1] https://github.com/dlang/phobos/blob/565a51f8c6e8b703c0b625568a6f14473345f5d8/std/stdio.d#L394 [2] https://github.com/dlang/phobos/blob/565a51f8c6e8b703c0b625568a6f14473345f5d8/std/stdio.d#L474 [3] https://github.com/dlang/phobos/blob/565a51f8c6e8b703c0b625568a6f14473345f5d8/std/stdio.d#L835
Re: vibe.d: Finding out if currently in webinterface request
On Friday, 10 August 2018 at 18:23:28 UTC, Johannes Loher wrote: On Friday, 10 August 2018 at 09:33:34 UTC, Timoses wrote: On Thursday, 9 August 2018 at 21:59:24 UTC, Johannes Loher wrote: I already posted this in the vibe.d forums (https://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/58891/), but it seems, there is not a lot of activity over there, so I am cross posting this here: [...] Do you have some code segments boiled down to the problem? Are you using vibe.core.log? Yes, I am using vibe.core.log, but as mentioned, I want to implement my own logger. The gist of what I am trying to do is this: https://run.dlang.io/is/7qpJ6J This actually works the way it is, but it involves catch Throwable (actually AssertError would be enough) and this is bad. I would like to find a different solution. You hit the assert of getRequestContext here: https://github.com/vibe-d/vibe.d/blob/a9589d955f10bd076a67d47ace0c78cfd3aa8246/web/vibe/web/web.d#L871 However, I don't know of a way yet to check whether one is currently in a request context from outside of vibe.web.web (adding a method to do so to vibe.web.web which checks `s_requestContext.req !is null` would probably help.)
Re: dtoh
On Monday, 6 August 2018 at 13:28:05 UTC, Laeeth Isharc wrote: Hi Walter. Can dtoh be open-sourced now that dmd is? Laeeth. Better write Walter a direct mail. He doesn't check the learn NG very often.
Re: Small program producing binary with large filesize
On Tuesday, 31 July 2018 at 15:19:19 UTC, Dan Barbarito wrote: Hi all, I am starting to write a command line tool. So far it is a small (feature-wise) program but the file size is scaring me. It's already 13 megabytes, but I would expect it to be much smaller. Is it because I'm using 3 libraries so far? The libraries are: mir, vibe.d, and d2sqlite3. Would using these libraries be causing this file size? The code can be found here (http://fossil.barbarito.me/finbot/zip/finbot.zip), if anyone wants to take a look. I am simply running "dub build" to build the binary. I tried running "dub build --build=release" but that didn't effect the file size too much. Thanks! If you use LDC, release build and their full LTO (-flto=full), the resulting binary should get smaller. DFLAGS="-flto=full" dub build --compiler=ldc -b release As an example, dlang-tour is 53M in debug build with DMD, but with LTO + release + ldc it gets down to 6.2M. You also get a smaller build, if instead of using all of Vibe.d, you only use the subset of components you actually use, e.g. dependency "vibe-d:web" version="~>0.8"
Re: Newbie: out-of-source builds with "dub"?
On Monday, 30 July 2018 at 10:23:06 UTC, CC wrote: With "targetPath", it sounds like I'd need to modify a file (DUB's .json file) that's in the source tree to indicate where some(?)/all(?) of the files resulting from the build would be stored. Yes. But it sounds like I'm maybe fighting DUB's design by even attempting out-of-source builds. So I need to ask: when using Dlang and DUB, are in-source builds simply the idiomatic way of doing things? Yes one typically uses dub within the source, e.g. `dub` (or `dub build`). As much as I'm a fan of out-of-source builds, I'm trying to be open-minded as I dive into D. There might be another way. Dub can generate Cmake files: dub generate cmake Though I think you'll need cmake-d (https://github.com/dcarp/cmake-d) for it (disclaimer: I never played with dub's support for cmake.)
Re: trait to get the body code of a function?
On Wednesday, 25 July 2018 at 19:10:03 UTC, 12345swordy wrote: On Wednesday, 25 July 2018 at 19:05:08 UTC, Guillaume Lathoud wrote: On Wednesday, 25 July 2018 at 04:46:20 UTC, rikki cattermole wrote: On 25/07/2018 5:32 AM, Guillaume Lathoud wrote: Thanks for all the answers. I've just had a look at an alternative: using dmd as a package. However that's a lot of doc to browse... Maybe someone has experience with dmd as a package? Not a solution. Leaks memory, not reusable and in general not very friendly to work with. Thanks. Please submit a bug report to Bugzilla on this, as I am also interest in this. Alexander I once had a similar PR in DMD to a potential `__traits(getFunctionBody, X)` for `__traits(documentation, X)`: https://github.com/dlang/dmd/pull/6872 There was a bit of a forum discussion about it: https://forum.dlang.org/post/cwjtsmnepvgvl...@forum.dlang.org The gist: Putting this in the Phantom Zone due it needing a compelling use case(s) to justify consuming memory and compilation time. << tl;dr: just Bugzilla won't do it. It will need a short DIP illustrating use cases. Sorry. Happy to implement it for you though.
Re: merging a group result
On Monday, 23 July 2018 at 11:49:58 UTC, Alex wrote:
Hi all,
I'm looking for a d-ish way to solve a basic
"split-apply-combine" workflow. The idea is described (and
solved) here:
https://stackoverflow.com/questions/39922986/pandas-group-by-and-sum
So, given a structure with some fields, say
´´´
struct S
{
string s;
int i;
}
´´´
I create an array of them, like
´´´
void main()
{
import std.experimental.all;
S[] sarr;
sarr.length = 6;
sarr[0].s = "a";
sarr[1].s = "a";
sarr[2].s = "b";
sarr[3].s = "b";
sarr[4].s = "c";
sarr[5].s = "c";
sarr[0].i = 1;
sarr[1].i = 2;
sarr[2].i = 4;
sarr[3].i = 8;
sarr[4].i = 16;
sarr[5].i = 32;
auto res = sarr.group!((a, b) => a.s == b.s);
//writeln(res);
}
´´´
I'm also able to group them by a field, see last line.
But now the problems begin:
- The group operation tries to use the structure itself as a
key, despite I provide a custom binary predicate.
- I could ignore the fact above, but how, given the result of
the grouping operation I can merge by some function (like sum)
the group results?
At this moment, I assume, that I'm approaching the problem from
the wrong end, and simply don't see something trivial...
Anyway, does anybody has a hint for me?
You could use chunkBy:
auto res = sarr.chunkBy!((a, b) => a.s == b.s).map!(a =>
tuple(a.front.s, a.map!(b => b.i).sum));
https://run.dlang.io/is/TJOEmf
chunkBy:
---
[S("a", 1), S("a", 2)]
[S("b", 4), S("b", 8)]
[S("c", 16), S("c", 32)]
---
group:
---
Tuple!(S, uint)(const(S)("a", 1), 2)
Tuple!(S, uint)(const(S)("b", 4), 2)
Tuple!(S, uint)(const(S)("c", 16), 2)
---
Re: QWebView requesting QtE5WebEng32.so on windows
On Saturday, 21 July 2018 at 19:11:08 UTC, Dr.No wrote: So I went to try out QWebView on Windows from this wrapper: https://github.com/MGWL/QtE5 all the examples went fine until I tried QWebView: https://github.com/MGWL/QtE5/blob/master/examples/webview.d I compile using this command line: dmd -m32 webview.d qte5.d -oflol but when I run I get this error: Error load: QtE5WebEng32.so I thought this was just a typo and what he really meant was QtE5WebEng32.dll but even so, I can't find such dll even using windeployqt --webkit2 --release Is the library's author around so that we can fix this? Try opening an issue at GitHub at the respective repository. Not everyone checks the D.learn group every day.
Re: Is there any plan for a dependency-free subset of "core" runtime?
On Friday, 20 July 2018 at 16:37:24 UTC, Seb wrote: On Friday, 20 July 2018 at 15:33:19 UTC, Radu wrote: On Thursday, 19 July 2018 at 18:16:17 UTC, kinke wrote: I'll go with Seb's suggestion and look at the betterC tests upstream for issues like this. FYI: I made a reboot of the old PR to a new one which just adds the betterC testsuite: https://github.com/dlang/phobos/pull/6640 You can now start to add your -betterC tests directly to Phobos: https://github.com/dlang/phobos/tree/master/test/betterC make -f posix.mak betterC We probably should support sth. like a `@test-betterc` (or @betterc-test`) UDA with which we can annotate existing tests that would then get extracted from Phobos automatically.
Re: Is there any plan for a dependency-free subset of "core" runtime?
On Friday, 20 July 2018 at 15:33:19 UTC, Radu wrote: On Thursday, 19 July 2018 at 18:16:17 UTC, kinke wrote: I'll go with Seb's suggestion and look at the betterC tests upstream for issues like this. FYI: I made a reboot of the old PR to a new one which just adds the betterC testsuite: https://github.com/dlang/phobos/pull/6640
Re: Is there any plan for a dependency-free subset of "core" runtime?
On Thursday, 19 July 2018 at 12:44:30 UTC, Radu wrote: Just tried something similar with new LDC Webassembly support [1] and it fails to compile ... This is a prime example of stuff that should just workTM on targets like that. I would like to submit some fixes but I think there needs to be a more systematic approach on making more core APIs modular. Also, CI support to make sure core API compile on such targets and there are no regressions. Webassembly would be an excellent target as it is both constrained and portable. To be fair, the WebAssembly support is still WIP and hasn't even been released yet ;-) Anyhow, here's how I think we can move forward for now: 1) Open the issue you experienced in the ldc issue tracker 2) Add more tests for -betterC to the test suites (and thus CI) For (2) I have an "old" PR staling around (https://github.com/dlang/phobos/pull/5952), which I should try to rebase and get into Phobos. Then it should be easier to add more -betterC tests for Phobos.
Re: Is there any plan for a dependency-free subset of "core" runtime?
On Thursday, 19 July 2018 at 12:40:09 UTC, Zheng (Vic) Luo wrote: On Thursday, 19 July 2018 at 11:35:00 UTC, Seb wrote: Well, since 2.079 it's actually possible to use D without a dependency any runtime (even libc): https://dlang.org/changelog/2.079.0.html#minimal_runtime Also with -betterC you can actually use lots of things from core that don't depend on the runtime. For example, std.algorithm/range works in betterC: https://run.dlang.io/is/38yowj Now, I assume you are asking whether there are plans for a minimal -betterC runtime? There aren't "official" plans, but AFAICT a few people are independently working on this. It might be a good idea to join efforts with them. Thank you for the clarification. I am working on a libc-free project (SAOC project: 2D rasterizer on embedded devices) and just faced some missing symbols(__assert, _memset32) from various libraries in snippets like https://run.dlang.io/is/Kme62V (more missing symbols without C runtime). I am a little bit confused at the boundary of D components: - which subset of standard library can be used under -betterC? Unfortunately, it's not properly defined (or tested) as -betterC is still WIP and there's also WIP to make the standard library more opt-in (e.g. the GC only starts when you actually use it since 2.080). Anyhow, for -betterC there's a lot of all currently supported features: https://dlang.org/spec/betterc.html In terms of the standard library, everything that is either templated or a template will very likely work, e.g. - std.algorithm (mostly) - std.range (mostly) - std.meta - std.typecons I actually have a PR in the works to add a -betterC testsuite to Phobos. - even with -betterC, the compiler sometimes require external symbols like __assert to work, so what are all the required symbols? rust-core limits them to five: memcpy, memcmp, memset, rust_begin_panic and rust_eh_personality. assert is lowered to the C runtime assert with betterC. With -betterC you should still have access to memcpy, just import core.stdc.string (see: https://dlang.org/library/core/stdc/string/memcpy.html). If you don't use the C runtime which provides assert, memcpy etc. you need to define them yourself in the minimal runtime. However, I think GDC/LDC provide intrinsics for a few of these operations. See e.g. https://github.com/JinShil/stm32f42_discovery_demo/tree/master/source/runtime Is there any way to make this project remain as a "library" with a few explicit external symbol dependencies instead of bundling a minimal d-runtime/libc stubs? Since eliminating d-runtime looks like an overkill in the most of time (almost every embedded project defines their own size_t/string/bitop/attribute, hope to see a core subset of d-runtime to prevent reinventing the wheel. Well, if you just use -betterC you still have access to all definitions in druntime (like size_t). You just need to avoid linking with the C runtime when you absolutely want to avoid it (i.e. build the executable). Here's a simple example of a D program for Linux x86_64 without any runtime that still accepts arguments , can do primitive output and uses declarations from druntime like size_t: https://gist.github.com/wilzbach/1bb812b9bdd2fed693b0ee4a6f8a2fd8 tl;dr: the declarations in druntime are still usable - you simply can't call libc functions if you plan to build an executable from your library that should be runtime free.
Re: Is there any plan for a dependency-free subset of "core" runtime?
On Thursday, 19 July 2018 at 10:27:36 UTC, Zheng (Vic) Luo wrote: Current implementation of d-runtime relies on a lot of symbols from libc, librt, libpthread, which makes it hard to create a minimal runtime used for embedded devices. Although there are some unofficial minimal versions of d-runtime, many of them lack maintenance and outdates rapidly. I was wondering that is there any plan for a https://doc.rust-lang.org/core/ library in D world, which only depends several explicitly-defined symbols? Well, since 2.079 it's actually possible to use D without a dependency any runtime (even libc): https://dlang.org/changelog/2.079.0.html#minimal_runtime Also with -betterC you can actually use lots of things from core that don't depend on the runtime. For example, std.algorithm/range works in betterC: https://run.dlang.io/is/38yowj Now, I assume you are asking whether there are plans for a minimal -betterC runtime? There aren't "official" plans, but AFAICT a few people are independently working on this. It might be a good idea to join efforts with them.
Re: HMAC and toHexString
On Wednesday, 18 July 2018 at 11:22:36 UTC, Nicholas Wilson wrote: On Wednesday, 18 July 2018 at 05:54:48 UTC, Nicholas Wilson wrote: [...] Ahh, the joys of memory corruption. Yep, actually this one is a very common one. However, -dip1000 would warn you here ...
Re: names not demangled in nm --demangle=dlang
On Tuesday, 17 July 2018 at 15:39:39 UTC, Zheng (Vic) Luo wrote: Hi, I built a simple program with dmd a.d and tried to observe symbols with nm --demangle=dlang ./a. However, I can observe that only part of the symbols (e.g., std.stdio.File.size()) are demangled, while others remain in their original name (e.g., _D3std5stdio4File8opAssignMFNfSQBdQBcQzZv). Is this a bug of nm? It probably doesn't support the new back-referencing yet. https://dlang.org/changelog/2.077.0.html#mangleBackref https://dlang.org/blog/2017/12/20/ds-newfangled-name-mangling/ Moreover, what is the suggested way to demangle symbol names in dlang? ddemangle (it should be part of your distribution or release archive)
Re: Implicit conversion of struct with methods to immutable in pure function fails
On Monday, 16 July 2018 at 13:13:53 UTC, Timoses wrote: On Monday, 16 July 2018 at 12:00:57 UTC, Simen Kjærås wrote: On Monday, 16 July 2018 at 11:43:03 UTC, Timoses wrote: Why does this fail? It doesn't. Not using DMD 2.081.1 under Windows, at least. I tried adding a bitfield since you mentioned it, but it compiles nicely for me. Which version of DMD are you using, and are you having the issues with the exact code you posted here? -- Simen https://run.dlang.io/is/Pgs527 I'm on 2.080.1. But above is on latest 2.081.1 I believe. Note that the bottom code snippet in the original post does work, while the first one does not. Yep, run.dlang.io automatically updates itself to the latest compiler (you can check this e.g. with -v).
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Monday, 16 July 2018 at 13:15:56 UTC, Timoses wrote: On Monday, 16 July 2018 at 11:31:32 UTC, Seb wrote: On Monday, 16 July 2018 at 11:12:20 UTC, Dukc wrote: On Saturday, 14 July 2018 at 03:08:50 UTC, Vladimir Panteleev wrote: I'll follow up with Alawain. Regardless, dscripten-tools borrows very little from the redistributable parts of dscripten - mostly the "minimalistic runtime", which I think was itself borrowed from somewhere else. Indeed, it appears Alawain himself just changed the runtime part to be boost! If he is reading this, thank you! https://github.com/Ace17/dscriptenQ/issues/4 Superfluous Q attack. Working link: https://github.com/Ace17/dscripten/issues/4 Sorry for the typo (not sure how that happened) and thanks for correcting!
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Monday, 16 July 2018 at 11:12:20 UTC, Dukc wrote: On Saturday, 14 July 2018 at 03:08:50 UTC, Vladimir Panteleev wrote: I'll follow up with Alawain. Regardless, dscripten-tools borrows very little from the redistributable parts of dscripten - mostly the "minimalistic runtime", which I think was itself borrowed from somewhere else. Indeed, it appears Alawain himself just changed the runtime part to be boost! If he is reading this, thank you! https://github.com/Ace17/dscriptenQ/issues/4
Re: Find out druntime/import and phobos folder on Linux
On Saturday, 14 July 2018 at 17:19:20 UTC, Andre Pany wrote:
Hi,
The IntelliJ D Language plugin has support for D-scanner and
DCD. Both tools needs to know the paths to druntime/import and
Phobos source folder.
In IntelliJ you set the path to the folder where dmd binary is
located. Based on this information on Windows and MacOS it is
possible to determine the paths.
The code can be found here
https://github.com/intellij-dlanguage/intellij-dlanguage/blob/develop/src/main/java/io/github/intellij/dlanguage/codeinsight/dcd/DCDCompletionServer.java#L180
I want to provide a fix that the paths are also automatically
determined on Linux correctly but I do not have much Linux
experience.
Is there a way to find out both paths based on the dmd
executable folder?
What I found out so far, these paths are not always correct:
/usr/include/dmd/druntime/import
/usr/include/dmd/phobos
Kind regards
Andre
DMD:
https://github.com/dlang/dmd/blob/master/src/dmd/dinifile.d#L40
LDC: https://wiki.dlang.org/Using_LDC,
https://github.com/dlang/dmd/blob/master/src/dmd/frontend.d#L97
Once you have the config file, simply parse the config files:
https://github.com/dlang/dmd/blob/master/src/dmd/frontend.d#L156
Anyhow as DMD is on DUB, there's no need for copy/pasting:
---
#!/usr/bin/env dub
/+dub.sdl:
dependency "dmd" version="~master"
+/
void main()
{
import dmd.frontend;
import std.stdio;
findImportPaths().writeln; // will determine the currently
active "dmd" compiler (can be LDC too)
}
---
DMD's order is a bit annoying, see:
https://github.com/dlang/dmd/pull/7915
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Wednesday, 11 July 2018 at 20:38:13 UTC, Dukc wrote: On Wednesday, 11 July 2018 at 19:41:37 UTC, Jordi Gutiérrez Hermoso wrote: Just getting it into -betterC territory seems like a very daunting task. You do not need -betterC anymore. At least the LDC frontend will only add linking hooks for what you use, -betterC or no. No need build a stub runtime anymore or give a switch to the compiler to not use the default one. I know because I compile to JavaScript: first to LLVM bitcode, then manual link (with llvm-link), then to JavaScript using Emscripten. I only have to compile those parts of DRuntime and Phobos I use. Its unlikely I could even have a stub runtime to work, so this is the only reason I can use D in my web page to any real degree. Also since 2.079 the GC (and many parts of Phobos) get lazily initialized, so while I think there are still some features that might require initialization, it might also be feasible to simply use normal D. Have you already tried this?
Re: Using dub and rdmd together?
On Wednesday, 11 July 2018 at 16:13:56 UTC, Matthew OConnor wrote:
Hi, I'm new to D and trying to make some command line tools
that are run with `#!/usr/bin/env rdmd`. But I would also like
to reference external packages from dub. I know I can do this
with:
#!/usr/bin/env dub
/+ dub.sdl:
name "get"
dependency "requests" version="~>0.3.2"
+/
But when I run it (with `dub get.d` on Windows), it rebuilds
every time.
Is there a way to integrate the two so that `rdmd` is used for
the builds, but `dub` is used to download the necessary
packages?
Thanks,
Matthew
I don't know of an easy way to do out of the box.
However, with dmd's new -i option, it could be as easy as:
---
dub fetch requests
cat > test.d << EOF
import std.stdio;
import requests;
void main() {
auto content = postContent("http://httpbin.org/post;,
queryParams("name", "any name", "age", 42));
writeln(content);
}
EOF
dub fetch requests
dmd -I~/.dub/packages/requests-0.8.2/requests/source -i -run
tests.d
---
However, dmd itself doesn't do any caching (though it would work
similarly with rdmd).
But, of course, this won't work for more complex dub packages.
There's `dub describe` (and a backend generator) for which they
might be used.
Re: Better diagnostics for null classes dereferencing
On Tuesday, 10 July 2018 at 20:57:02 UTC, Steven Schveighoffer
wrote:
On 7/10/18 4:02 PM, Per Nordlöw wrote:
On Tuesday, 10 July 2018 at 19:27:07 UTC, Steven Schveighoffer
wrote:
On 7/10/18 3:01 PM, Per Nordlöw wrote:
[...]
Yes, call this function on startup:
import etc.linux : registerMemoryErrorHandler;
void main()
{
registerMemoryErrorHandler();
...
}
No, it's not documented anywhere. Probably should be...
Okay thanks. When would you not want that behavior to be
default?
It was controversial at the time, and considered a hack. It's
also only supported on Linux. So I don't know the reason why
it's not always done for Linux, I really think it should be.
-Steve
https://github.com/dlang/druntime/pull/2249
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Wednesday, 20 June 2018 at 18:47:10 UTC, Jordi Gutiérrez Hermoso wrote: I'm specifically thinking of the GNU Octave codebase: http://hg.savannah.gnu.org/hgweb/octave/file/@ It's a fairly old and complicated C++ codebase. I would like to see if I could slowly introduce some D in it, anywhere. Now, as I understand it, I would need to begin with making `main` a D function, because D needs to initialise the runtime. Is this correct? Another possibility might be in dlopen'able functions. Currently Octave uses so-called oct functions, which are nothing more than C++ object code that is dynamically loaded by the interpreter at runtime. They are compiled to the Octave C++ API, but we also have a Matlab-compatible C API that perhaps could be more amenable for D-ification. What are your ideas? Maybe looking at the recent DMD Backend to D conversion PRs (https://github.com/dlang/dmd/pulls?utf8=%E2%9C%93=is%3Apr+label%3A%22D+Conversion%22+) helps? Here -betterC is used. The frontend was automatically converted to D a few years ago (https://github.com/dlang/dmd/tree/last-cdmd/src/magicport), though magicport was a bit specific to DMD's codebase.
Re: Better diagnostics for null classes dereferencing
On Tuesday, 10 July 2018 at 19:01:22 UTC, Per Nordlöw wrote: Is it possible to change run-time behaviour of null-class dereferencing, on Linux, so that it gives some other diagnostics than: Program exited with code -11 Does DMD and LDC provide different alternatives here? On a Systemd system coredumps are typically configured to be automatically generated and saved. For example you can start up gdb at the most recent crash: coredumpctl gdb -1
Re: Using C++ with D / returning a templated type from C++
On Thursday, 5 July 2018 at 06:35:01 UTC, Robert M. Münch wrote: So, the only difference left is the C++ static and the additional __ptr64 (whatever this is) on the D side. Any further ideas? Could you post your current C++ and D files? So, how or where could such a collection be done? Well, if you discover something that isn't covered/mentioned on the specification, it can even go to the spec: https://dlang.org/spec/cpp_interface.html Otherwise, I think the C++ interface isn't really mentioned to the DTour, so it could be worthwhile to add a page there and content can be more informal there: https://github.com/dlang-tour/english Otherwise, just plain markdown documents in a GitHub repo are pretty popular these days. Alternatively, there's still the DWiki too. BTW if you (or someone) has a few good examples, I think the DBlog would be more than happy about an article.
Re: How to call a C function from D that takes a FILE * as an argument?
On Wednesday, 4 July 2018 at 02:08:11 UTC, Joe wrote:
On Wednesday, 4 July 2018 at 01:58:15 UTC, Seb wrote:
So just add the declaration to your D file:
---
extern(C) void myCfunction(FILE* stream);
---
I do have a similar declaration in D. It appears the problem
is that the C program I'm trying to convert passes stdout as
the argument and the D compiler complains somewhat like the
following:
Error: function foo.main.myCfunction (shared(_IO_FILE)* stream)
is not callable using argument types (File)
So I guess the question is what to pass instead of stdout.
Hmm, calling e.g. fprintf with stdout should just work:
---
void main()
{
import core.stdc.stdio;
fprintf(stdout, "Hello %s", "world".ptr);
}
---
Could you maybe provide your whole code?
Re: How to call a C function from D that takes a FILE * as an argument?
On Wednesday, 4 July 2018 at 01:06:36 UTC, Joe wrote:
The subject basically says it all. The C function uses the
argument to call fprintf and also passes it to other functions
where it's used to call fileno, fprintf or putc.
Like you would with C's fprintf
(https://dlang.org/phobos/core_stdc_stdio.html#.fprintf).
For example, this is a valid D program:
---
void main(string[] args)
{
import core.stdc.stdio;
FILE* pFile;
int n;
char[100] name;
pFile = fopen ("myfile.txt","w"); // string literals are
zero-terminated
for (n=0 ; n<3 ; n++)
{
puts("please, enter a name: ");
gets(name.ptr);
fprintf pFile, "Name %d [%-10.10s]\n",n+1,name.ptr);
}
fclose(pFile);
}
---
(example from http://www.cplusplus.com/reference/cstdio/fprintf)
So just add the declaration to your D file:
---
extern(C) void myCfunction(FILE* stream);
---
and as long as you link your program into the D binary, you
should be good to go.
For larger C bases, tools like dstep or dpp can help translating
C/C++ header files to D.
Re: Issues with undefined symbols when using Vibe on Windows
On Tuesday, 3 July 2018 at 15:10:34 UTC, Chris M. wrote: On Tuesday, 3 July 2018 at 14:38:53 UTC, Mike Parker wrote: On Tuesday, 3 July 2018 at 13:32:21 UTC, Chris M. wrote: After hashing it out with some people on the Discord, I'm fairly certain we narrowed it down to the 64-bit user32.lib from mingw missing these functions. https://issues.dlang.org/show_bug.cgi?id=19051 So are the mingw libs only shipped in the zip file? I don't have them with the installer version of 2.080.0, nor lld for that matter. But I see them in the zip for the 2.081.0 RC. Seems to be an option in the 2.080.1 installer (which I ignored before since I wasn't entirely sure how things worked on Windows), not sure about previous versions though. BTW in case someone has a bit of time to look at the MinGW headers. They are built as part of the `build-mingw-libs` branch at the installer repo: https://github.com/dlang/installer/blob/build-mingw-libs/windows/build_mingw.bat This is automated via AppVeyor: https://github.com/dlang/installer/blob/build-mingw-libs/appveyor.yml And it's added to the zip here: https://github.com/dlang/installer/blob/master/create_dmd_release/build_all.d#L505 I think the installer detects whether Visual Studio is installed or nor, but I'm not sure on this (I don't use Windows).
Re: Issues with undefined symbols when using Vibe on Windows
On Monday, 2 July 2018 at 23:00:08 UTC, Chris M. wrote: On Monday, 2 July 2018 at 21:20:26 UTC, Seb wrote: On Monday, 2 July 2018 at 19:24:38 UTC, Chris M. wrote: On Monday, 2 July 2018 at 18:48:16 UTC, Jonathan M Davis wrote: [...] Downloaded the DMD and DMC zip files, extracted and added to PATH. Been working for the most part so far. I thought for 64-bit the bundled lld linker and mingw runtime are used? https://dlang.org/changelog/2.079.0.html#lld_mingw So in fact you shouldn't even need DMC? Ah, okay. I'm mostly on Linux so I generally miss anything Windows-related. I was using the following link and figured I'd install DMC as well. https://dlang.org/dmd-windows.html#requirements BTW have you tried using LDC? They might ship a newer version of LLD.
Re: Issues with undefined symbols when using Vibe on Windows
On Monday, 2 July 2018 at 19:24:38 UTC, Chris M. wrote: On Monday, 2 July 2018 at 18:48:16 UTC, Jonathan M Davis wrote: On Monday, July 02, 2018 18:26:27 Chris M. via Digitalmars-d-learn wrote: On Monday, 2 July 2018 at 17:33:20 UTC, Bauss wrote: > [...] Thanks for checking, I have no idea what else to try (short of getting MS Build Tools somehow, but I unfortunately can't in my current environment so I'm stuck with DMC + DMD) How are you compiling for 64-bit without the MS toolchain? - Jonathan M Davis Downloaded the DMD and DMC zip files, extracted and added to PATH. Been working for the most part so far. I thought for 64-bit the bundled lld linker and mingw runtime are used? https://dlang.org/changelog/2.079.0.html#lld_mingw So in fact you shouldn't even need DMC?
Re: range.put() to Empty Array Causes Error?
On Sunday, 17 June 2018 at 12:23:55 UTC, Steven Schveighoffer
wrote:
On 6/17/18 7:07 AM, Vijay Nayar wrote:
This code breaks with the following error:
void main()
{
import std.range;
int[] vals = [];
vals.put(3);
}
/src/phobos/std/range/primitives.d(2328): Attempting to fetch
the front of an empty array of int
The following code has no error:
void main()
{
import std.range;
int[] vals = [1];
vals.put(3);
}
Why is range.put() not allowed for empty arrays?
range.put fills an existing array like a buffer, it does not
append (as I'm guessing you are expecting). Use
std.array.Appender to get append behavior.
Or simply ~= if you want to use built-in arrays (works with
Appender too FWIW).
Re: Static Array Idiom not working anymore.
On Tuesday, 12 June 2018 at 14:35:33 UTC, SrMordred wrote:
this idiom for creating static array used to work, but they are
failing now.
What changed and whats the alternative?
(from
https://p0nce.github.io/d-idioms/#@nogc-Array-Literals:-Breaking-the-Limits)
T[n] s(T, size_t n)(auto ref T[n] array) pure nothrow @nogc
@safe
{
return array;
}
void main() @nogc
{
int[] myDynamicArray = [1, 2, 3].s; // Slice that static
array which is on stack
}
//output:
Deprecation: slice of static array temporary returned by s([1,
2, 3]) assigned to longer lived variable myDynamicArray
FYI: There's a Phobos PR for such an idiom
https://github.com/dlang/phobos/pull/6489
