Re: How to tell DMD to use lld-link?
On Tuesday, 18 July 2023 at 07:19:44 UTC, Vladimir Panteleev wrote: Seeing this link failure on Windows: https://github.com/CyberShadow/ae/actions/runs/5574489393/jobs/10184021009#step:8:30 Looks like an MS link SNAFU. lld-link also fails, so this looks like a DMDBE bug... probably https://issues.dlang.org/show_bug.cgi?id=24002 Is there any way I can tell DMD to ignore the presence of MS link and use the bundled lld-link anyway? Answer: `env LINKCMD=lld-link.exe ...`
How to tell DMD to use lld-link?
Seeing this link failure on Windows: https://github.com/CyberShadow/ae/actions/runs/5574489393/jobs/10184021009#step:8:30 Looks like an MS link SNAFU. Is there any way I can tell DMD to ignore the presence of MS link and use the bundled lld-link anyway?
Re: How to use Dub and Digger to build Pull Requests?
On Tuesday, 23 May 2023 at 13:50:09 UTC, Quirin Schroll wrote: ``` object.Exception@%LOCALAPPDATA%\dub\packages\ae-0.0.3236\ae\sys\d\manager.d(898): Command ["make", "-f", "win32.mak", "MODEL=32", "HOST_DC=C:\\Users\\qschroll\\Documents\\d\\mydmd\\work\\dl\\dmd-2.079.0\\dmd2/windows/bin\\dmd.exe", "dmd"] failed with status 1 ``` This shows that the build failed, but you will have to look above this line to see why.
Re: Bug in DMD?
On Friday, 3 March 2023 at 01:21:52 UTC, ryuukk_ wrote: I have some questions: 1. why does it work with LDC? 2. why does it work with DMD when build/link in 2 step? 3. why it doesn't work when DMD is invoked once for build/link I think these are probably coincidences and the answer can be summarized as "that's what ends up happening due to the details of the implementation". 4. is this a bug in DMD or my code is wrong? I would say the code is wrong in principle, though as you've noted it can still work in some specific circumstances. 5. if it's wrong, then why does it compile/no error? `extern(C) main` is a low-level feature, because it effectively turns off parts of the language. However, the rest of the program doesn't know that this is the case - currently the compiler simply assumes you know what you're doing. Maybe it's not OK that it's easy to use it by accident.
Re: Bug in DMD?
On Friday, 3 March 2023 at 01:07:07 UTC, ryuukk_ wrote: I couldn't figure out dustmite, so i started from 0 and managed to hit something: https://github.com/ryuukk/dmd_bug ``Assertion failed: array index out of bounds, file game\app.d, line 5`` Wich indicates probably TLS problem? Yeah... `rt.a.stuffs` is a TLS variable. The D runtime manages TLS. `extern(C) main` bypasses D runtime initialization.
Re: Thinking about the difference between fixed and 'dynamic' arrays.
On Wednesday, 30 November 2022 at 01:53:10 UTC, Siarhei Siamashka
wrote:
Rust also appears to be picky about the order of operations:
```Rust
fn main() {
let mut a = [1, 2, 3, 4, 5];
let c = a;
let b = a;
b[1] = 99;
println!("{:?}", b); // [1, 99, 3, 4, 5]
println!("{:?}", a); // [1, 99, 3, 4, 5]
println!("{:?}", c); // [1, 2, 3, 4, 5]
}
```
This seems unsurprising to me, `b` is a slice. The same in D:
```d
import std.array, std.stdio;
void main()
{
version (dynamic)
{
auto a = [1, 2, 3, 4, 5];
auto c = a.dup;
auto b = a;
}
else
{
auto a = [1, 2, 3, 4, 5].staticArray;
auto c = a;
auto b = a[];
}
b[1] = 99;
writeln(b); // [1, 99, 3, 4, 5]
writeln(a); // [1, 99, 3, 4, 5]
writeln(c); // [1, 2, 3, 4, 5]
}
```
I agree the syntax is inconsistent.
It is too late to change it in D, nor is it often useful in
practice.
If this is really desired, then the D compiler can probably
introduce a more verbose syntax for shallow array copies and
start spitting out warnings about simple assignments like
`"auto b = a;"`. A few years later the old syntax can be
dropped.
I only meant that variable-sized value types are not often useful
in practice.
But way too many languages behave in the same way as D right
now. I personally don't see any problem.
Slices are such a fundamental feature of D that it is unrealistic
to think about changing syntax there. It would effectively be a
new language, because almost no programs from before the change
would compile after the change.
Re: How do I _really_ implement opApply?
On Wednesday, 30 November 2022 at 01:30:03 UTC, Steven Schveighoffer wrote: On 11/29/22 7:50 PM, WebFreak001 wrote: (note: I don't want to use a template, this way of writing it has the advantage that the compiler checks all different code paths for errors, so the errors aren't delayed until someone actually tries to iterate over my data structure) 1. use the template 2. use a unittest to prove they all compile. +1. I use this pattern often: https://github.com/CyberShadow/ae/blob/86b016fd258ebc26f0da3239a6332c4ebecd3215/utils/graphics/libpng.d#L716-L721 https://github.com/CyberShadow/ae/blob/86b016fd258ebc26f0da3239a6332c4ebecd3215/utils/math/combinatorics.d#L220-L222
Re: dirEntries removes entire branches of empty directories
On Thursday, 10 November 2022 at 21:27:28 UTC, Ali Çehreli wrote: However, ftw performs about twice as fast as dirEntries Yes, `dirEntries` isn't as fast as it could be. Here is a directory iterator which tries to strictly not do more work than what it must: https://github.com/CyberShadow/ae/blob/86b016fd258ebc26f0da3239a6332c4ebecd3215/sys/file.d#L178
Re: Thinking about the difference between fixed and 'dynamic' arrays.
On Wednesday, 30 November 2022 at 00:40:57 UTC, Vladimir Panteleev wrote: On Tuesday, 29 November 2022 at 18:59:46 UTC, DLearner wrote: Suggestion: it would be clearer if the two concepts were separated: 1. Convert 'int[] VarArr;' so it produces a straightforward _value-type_ variable array, called 'VarArr'; 2. Implement a new concept 'int slice Window;' to produce an object of type 'int slice', called 'Window'. 'Window' is a 'slice' into an int array, not an array itself or even a variable. Opinions? Yes, that's what Rust does. It has first-class variable-size value types, D doesn't have such a feature. Cool page explaining this in The Rustonomicon: https://doc.rust-lang.org/nomicon/exotic-sizes.html
Re: Thinking about the difference between fixed and 'dynamic' arrays.
On Tuesday, 29 November 2022 at 18:59:46 UTC, DLearner wrote: Suggestion: it would be clearer if the two concepts were separated: 1. Convert 'int[] VarArr;' so it produces a straightforward _value-type_ variable array, called 'VarArr'; 2. Implement a new concept 'int slice Window;' to produce an object of type 'int slice', called 'Window'. 'Window' is a 'slice' into an int array, not an array itself or even a variable. Opinions? Yes, that's what Rust does. It has first-class variable-size value types, D doesn't have such a feature. It is too late to change it in D, nor is it often useful in practice.
Re: dirEntries removes entire branches of empty directories
On Wednesday, 9 November 2022 at 19:05:58 UTC, Ali Çehreli wrote:
Running the program shows no output; 'a' is not visited as a
directory entry.
That's not what happens for me:
```d
import std.exception;
import std.file;
import std.path;
import std.stdio;
void ls()
{
foreach (e; dirEntries(absolutePath("./deleteme"),
SpanMode.breadth)) {
writeln(e.name);
}
}
void main()
{
"./deleteme".rmdirRecurse.collectException;
"./deleteme".mkdir();
writeln("empty");
ls();
writeln("only a directory");
mkdir("./deleteme/a");
ls();
writeln("directory and file");
std.file.write("./deleteme/a/x", "");
ls();
}
```
Locally and on run.dlang.io I get:
```
empty
only a directory
/sandbox/./deleteme/a
directory and file
/sandbox/./deleteme/a
/sandbox/./deleteme/a/x
```
Re: dustmite and Windows file access errors
On Monday, 24 January 2022 at 17:17:28 UTC, Anonymouse wrote: Indexing is off for the parent directory. What else can I do? Disable anti-virus. If that doesn't help, you could try using Sysinternals Process Monitor to check what is accessing the file.
Re: Dustmite and linking error
On Saturday, 4 September 2021 at 07:38:34 UTC, Andre Pany wrote: The Dustmite condition you are using seems very generic, therefore this error message can be triggered by various code constellations. This might be the reasons why Dustmite is running so long. Overly generic test conditions would be more likely to cause DustMite to finish very quickly (and produce the wrong result), rather than the other way around.
Re: Dustmite and linking error
On Saturday, 4 September 2021 at 06:18:52 UTC, JG wrote: I tried again. What am I doing wrong? cp source ~/tmp/source cd ~/tmp/source dub build --config prog1 2>&1 | grep "collect2: error: ld returned 1 exit status" echo $? #produces 0 find . -name *.o -delete ~/d/DustMite/dustmite -j ./ 'dub build --config prog1 2>&1 | grep "collect2: error: ld returned 1 exit status"' cd ../source.reduced dub build --config prog1 2>&1 | grep "collect2: error: ld returned 1 exit status" echo $? #produces 1 One potential source of trouble is using Dub. Dub doesn't play well with tools such as DustMite, because it keeps state outside of the current directory. In some cases, it even writes to that state, which works very poorly especially with `-j`. Dub has a built-in "dustmite" command, though it is a bit limited - you could use `dub -v` to get the compiler and linker commands that Dub runs, and run them directly from your test command. Some bugs do not reproduce 100% of the time, and are random in nature, due to depending on memory layout or thread timing. Try running the test command a number of times and see if that affects the result. Regardless, your workflow looks OK from a high level - the source.reduced directory should indeed contain the contents of a directory for which the test command did return 0, for one reason or another.
Re: Dustmite and linking error
On Thursday, 2 September 2021 at 11:20:18 UTC, Vladimir Panteleev wrote: One way to get a very rough estimate is to take the square of the current reduction (.reduced directory), and divide it by the square of the original source. I meant the square of the size of the respective directory. (bytes / LOC / SLOC...) One week later it is still running (depth 22). If you are still on the first iteration, you may also try switching to the "careful" strategy.
Re: Dustmite and linking error
On Thursday, 2 September 2021 at 11:04:12 UTC, JG wrote: Hi, We hit a linking error (after upgrading to dub 1.26.0). I thought I would try to use dustmite to create a reduced error test case. One week later it is still running (depth 22). I don't suppose there is anyway of determining when it will finish? One way to get a very rough estimate is to take the square of the current reduction (.reduced directory), and divide it by the square of the original source. For best performance, make sure that: 1) You are using the latest version from https://github.com/CyberShadow/DustMite 2) DustMite itself is built in release mode 3) You are using the -j switch to enable parallelism 4) You are running the reduction on a RAM disk or equivalent If you don't want to risk losing progress by putting everything (including the result directory) on a RAM disk, the latest bleeding-edge version on the "next" branch introduces a --temp-dir option. DustMite reductions can be stopped and resumed by pointing DustMite at the latest .reduced directory from a previous run.
Re: How to profile compile times of a source code?
On Saturday, 30 January 2021 at 22:47:39 UTC, Ahmet Sait wrote: I'm looking for ways to figure out what parts of the code slows down the compiler other than brute force trial. You could try some of the tools listed on the wiki for build time profiling: https://wiki.dlang.org/Development_tools#Build_time_profiling (intentional bump to aid search results, as apparently this list is not very well known)
Re: Build time
On Friday, 23 July 2021 at 18:53:06 UTC, JG wrote: Any suggestion on how to try and improve the build time. You could try some of the tools listed on the wiki for build time profiling: https://wiki.dlang.org/Development_tools#Build_time_profiling (intentional bump to aid search results, as apparently this list is not very well known)
Re: float price; if (price == float.nan) { // initialized } else { // uninitialized } ... valid ?
On Wednesday, 30 June 2021 at 03:52:51 UTC, someone wrote: One of the things I do not like with D, and it causes me to shoot me on the foot over and over, is the lack of null for *every* data type. Things like: If you want to give any type a "null" value, you could use [`std.typecons.Nullable`](https://dlang.org/library/std/typecons/nullable.html).
Re: float price; if (price == float.nan) { // initialized } else { // uninitialized } ... valid ?
On Wednesday, 30 June 2021 at 03:15:46 UTC, someone wrote: Is the following code block valid ? Comparison with `nan` always results in `false`: See section 10.11.5: https://dlang.org/spec/expression.html#equality_expressions You can use the `is` operator to perform bitwise comparison, or use `std.math.isNaN`.
Re: Internal Server Error on reload of dfeed.js
On Wednesday, 16 June 2021 at 06:28:40 UTC, guest wrote: STR: 1. open http://forum.dlang.org/static-bundle/637528586548394375/dlang.org/js/dlang.js+js/dfeed.js 2. press reload (F5 or ctrl+R) Noticed this too and fixed it a bit ago. It was sending 500 instead of 304, so actually the only way you could see it was to press F5 (but not Ctrl+F5).
Re: Unpacking Slices
On Monday, 14 June 2021 at 18:08:27 UTC, Justin Choi wrote: Is there any shortcut for unpacking slices like I'd want to do in a scenario like this? `info = readln.strip.split;` `string a = info[0], b = info[1], c = info[2];` I tried to implement PHP's "list" language construct here, which does something similar: https://github.com/cybershadow/ae/blob/next/utils/array.d#L763 For your example, it would look like: ```d string a, b, c; list(a, b, c) = readln.strip.split; ```
Re: How to unit-test a phobos module?
On Friday, 27 November 2020 at 04:08:33 UTC, Q. Schroll wrote: I think using digger in principle works and I assume the problems I got aren't Digger's fault, but ae's. Building DMD + DRuntime failed. Sorry about this. It was caused by a breaking change in Druntime's build script: https://github.com/dlang/druntime/pull/3026 I pushed a new version of Digger which includes a fix.
Re: Function Pointer Not Working
On Thursday, 19 November 2020 at 04:23:13 UTC, Marcone wrote:
// Function threadingw()
void threadingw(HWND hwn, void delegate() fun) nothrow {
try {
// Function _fun()
extern(Windows)
uint _fun(void * arg){
(*(cast(void delegate()*) arg))(); // Do not show "Hello
World!" :(
return 0;
}
CreateThread(null, 0, &_fun, , 0, null);
} catch(Throwable){}
}
void main(){
null.threadingw({writeln("Hello World!");});
}
A delegate is a "fat" pointer (function pointer + context), so it
can't fit in a void*.
You could do something like the following to "uncurry" the
delegate and extract its context to a void* and a regular
function, which can then combine the void* given to it later to
call the original delegate:
import std.traits;
auto uncurryDelegate(alias anchor, alias target)()
{
alias Args = Parameters!target;
alias R = ReturnType!target;
alias ContextPtr = void*;
alias Dg = typeof();
union Delegate
{
Dg dg;
struct
{
void* ptr;
void* funcptr;
}
}
auto dg = Delegate();
__gshared void* funcptr; // Will always be the same for this
instantiation
funcptr = ().funcptr;
static struct Result
{
R function(ContextPtr ptr, Args args) fun;
ContextPtr context;
}
static R fun(ContextPtr ptr, Args args)
{
Delegate dg;
dg.funcptr = funcptr;
dg.ptr = ptr;
return dg.dg(args);
}
return Result(, dg.ptr);
}
auto uncurryDelegate(alias target)()
{
return uncurryDelegate!(target, target);
}
unittest
{
int fun(int i)
{
return i + 1;
}
auto r = uncurryDelegate!fun;
assert(r.fun(r.context, 2) == 3);
}
unittest
{
struct S
{
int i;
int fun(int j)
{
return i + j;
}
auto funUncurried() { return uncurryDelegate!(i, fun); }
}
auto s = S(2);
auto r = s.funUncurried();
assert(r.fun(r.context, 3) == 5);
}
Sadly you can't write `static immutable void* funcptr =
().funcptr;`, because the compiler tries to evaluate
first.
Alternatively you could do this (not recommended):
https://stackoverflow.com/a/8656294/21501
Re: Renaming Flag!"" in API
On Monday, 12 October 2020 at 10:24:44 UTC, FreeSlave wrote: Can this issue overcome somehow? Why not add a deprecated overload for your function which takes the old Flag value?
Re: std.process - avoid interaction with parent shell
On Monday, 20 July 2020 at 20:55:52 UTC, Steven Schveighoffer wrote: I tried redirecting /dev/null to stdin when executing my application (and I assumed that would pass onto the process child), but it still asks. What am I doing wrong? Generically, I think you want to detach the program from the current terminal (as well as doing the above). I think setsid can be used for this purpose. Specifically, checking git's source code, I see that setting the environment variable GIT_TERMINAL_PROMPT to 0 will disable password prompts.
Re: Allocating an empty non null associative arary
On Tuesday, 31 March 2020 at 02:51:11 UTC, Superstar64 wrote:
How do I generically create an empty associative array?
If you can't pass it by ref, then adding and then removing an
element is the only way I know.
/// Ensure that arr is non-null if empty.
V[K] nonNull(K, V)(V[K] aa)
{
if (aa !is null)
return aa;
aa[K.init] = V.init;
aa.remove(K.init);
assert(aa !is null);
return aa;
}
unittest
{
int[int] aa;
assert(aa is null);
aa = aa.nonNull;
assert(aa !is null);
assert(aa.length == 0);
}
Re: Convert program to 2020: replace foreach loop with map, filter and friends
On Tuesday, 31 March 2020 at 04:00:28 UTC, User wrote:
I'd like to convert the following program to 2020 standards
(i.e, replace the foreach block with a one-line code). I've
tried much and I failed.
Here is how I'd do it.
Because the program downloads and then reads the local file
unconditionally, I replaced it with byLine. This allows it to
process the data as it is being downloaded, without first waiting
to download everything.
import std;
void main()
{
immutable URL =
r"https://raw.githubusercontent.com/CSSEGISandData/COVID-19/master/csse_covid_19_data/csse_covid_19_time_series/time_series_covid19_confirmed_global.csv;;
immutable country = "Poland";
URL
.byLine
.map!(line => line.splitter(","))
.enumerate
.filter!(t => t.index == 0 || t.value.dropOne.front == country)
.map!(t => t.value)
.take(2)
.each!writeln;
}
Re: digger: Failed to spawn new process (The system cannot find the file specified.)
On Monday, 3 February 2020 at 22:01:18 UTC, Anonymouse wrote: No, C:\Temp\work\dl\git does not exist. :o OK, that makes sense. Please try the latest Digger version (24cd4168956dad382d05984b4b8d37d9e8ebe3ae).
Re: digger: Failed to spawn new process (The system cannot find the file specified.)
On Monday, 3 February 2020 at 21:44:20 UTC, Anonymouse wrote: New log: https://pastebin.com/raw/uUMNQjEN It looks like it fails to execute git (to get the current version for the build). I don't know why that fails, as I see C:\Temp\work\dl\git\cmd is in PATH in the environment that build.exe is invoked with. I assume that that directory does contain a git.exe? You may have some luck further debugging the cause of the error with a strace-like tool such as Process Monitor.
Re: digger: Failed to spawn new process (The system cannot find the file specified.)
On Monday, 3 February 2020 at 21:30:57 UTC, Anonymouse wrote: I was on beta 8. I forced dub to download the latest now (3.0.0-alpha-9), wiped the work directory and retried, but to similar results. The latest is v3.0.0-alpha-11. Oh, I guess that's not how semantic versioning works. Probably I should make a normal stable release. For now you can clone and build from source.
Re: digger: Failed to spawn new process (The system cannot find the file specified.)
On Monday, 3 February 2020 at 20:41:00 UTC, Anonymouse wrote: It doesn't seem to include debugging symbols. Is your Digger version up-to-date? https://github.com/CyberShadow/ae/commit/48ee31a3b0d47e52769ee87b0e673034abe4add5
Re: wstring comparison is failing
On Tuesday, 24 September 2019 at 21:40:47 UTC, Brett wrote: The only issue is that buggy dynamic code can result if someone compares the two and it will fail silently. But, you don't know if the static array actually contains a null-terminated string (in which case the comparison is a bug) or an actual meaningful string of that length, such as a string literal represented as a static array (in which case the comparison is completely valid). It could be quite complex bug that destroys the space station. The worst kind of bugs are the ones for which the program works correctly 99.9% of the time (including in all unit tests), but 0.1% of the time things explode. This doesn't seem to me like that kind of a bug, if only that a NUL character will always be presented in a zero-terminated string embedded in a static array, but practically never in a D string. If I convert a static array to a string, I want the "string" portion of the array. Zero-terminated strings are kind of a C thing. D isn't C, it has its own string type. Even though many libraries use a C ABI for interop, and thus use C strings, this isn't a requirement for a D program - after all, you can write your own kernel and operating system in D, all fully without zero-terminated strings.
Re: wstring comparison is failing
On Monday, 23 September 2019 at 23:22:14 UTC, Brett wrote: I guess you are probably right... I was thinking that it would compare up to a null terminator. Seems kinda buggy... maybe the compiler needs to give a warning? After all, compared a fixed size array with a dynamic array then will almost always fail since it is unlikely the sizes will match... ...rather than failing silently. It might still be useful for generic code, so a compiler warning would probably not be suitable. However, it might be a good idea for a linter such as Dscanner, which, unlike the compiler, sees types as they are written in the code, not as they are calculated through metaprogramming.
Re: Single D app entered multiple times from command line
On Monday, 23 September 2019 at 19:14:15 UTC, Brett wrote: I imagine I could potentially create a separate process that has a communication layer between it and the D program but I'm hoping it would be less work. You're pretty much describing a client-server design. A lot of software does work in this way, e.g.: - MS toolchain spawns mspdbsrv to write PDB files - Gradle (Java build tool) spawns a daemon which caches information in memory - Git on Windows also creates long-lived processes to cache filesystem information The simplest design would be for the server to listen on a named pipe (perhaps named after the current directory), and the client to do nothing but forward the command-line arguments and input to the daemon through the pipe, then read back the result and present it to the user.
Re: wstring comparison is failing
On Monday, 23 September 2019 at 20:38:03 UTC, Brett wrote: cast(wstring)entry.szExeFile == Name to!wstring(entry.szExeFile) == Name These all fail. The strings are clearly the same. I can compare char by char and it works. latest D 2.088. The only thing is that szExeFile is a static wchar array... which shouldn't effect the comparison. If you're comparing a static array, you're also comparing the bytes after the NUL character. Both of those conversions will give you a wstring with the length of the entire array, regardless of and including any NUL characters, so that's probably not what you want. fromStringz would probably be more appropriate there.
Re: Why is the fPIC switch missing?
On Monday, 23 September 2019 at 08:19:35 UTC, Boris Carvajal wrote: On Monday, 23 September 2019 at 01:31:03 UTC, Emmanuelle wrote: Hello. My problem is exactly what it says on the title: my dmd (windows 7, x64) doesn't seem to have -fPIC: I think it's not needed. The generated code on Windows is always position independent. I believe Windows uses relocations. Relocations require patching the image after loading using a relocation table. Position-independent code does not require relocations, it is ready to run from any address straight after loading. This allows multiple copies of programs or libraries to be loaded at the same time in different processes at different addresses (with ASLR), but share their physical memory pages.
Re: Simplifying process piping
On Sunday, 22 September 2019 at 16:06:04 UTC, Jesse Phillips
wrote:
https://github.com/JesseKPhillips/std.process-example/
I'm wondering if there are any thoughts for simplification. I
don't mean simplify to perform the same end result, but is the
threading and data copies as simple as they could be? Did I
misrepresent anything?
Your approach is OK for more complicated cases. When you need to
just pipe one process into another, create a `pipe`, pass the
writeEnd to the first process's stderr, and the readEnd to the
second process's stdin. To discard output, pass File("/dev/null",
"w") to its stdout.
There is a ticket somewhere in Bugzilla to add something like
Python's Popen.communicate to pipe multiple things at once. it is
not difficult, on Linux it is a select loop, doesn't even require
threads. There was no consensus on what the interface should look
like.
Re: Downloading a file and showing progress via curl.
On Tuesday, 20 August 2019 at 11:51:03 UTC, Daniel Kozak wrote: For that you can use https://dlang.org/phobos/std_file#append Don't do that. It will reopen and close the file on every received chunk. Not only is it slow, but if the file is renamed/moved/deleted while the download is occurring, the file will be corrupted. The same will happen if you run the program twice, if you don't clean up. The correct way is to open a File once, then use rawWrite for every received chunk.
Re: OPTLINK : Warning 9: Unknown Option : OUT
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. If you'd like to build 64-bit versions of your project, then specify `--model=64` (or `--model=32,64`, or even `--model=32,64,32mscoff`) when building D with Digger. Otherwise, you should tell Dub to target the 32-bit model, or figure out why Dub is configured to or defaults to targeting 64-bit.
Re: OPTLINK : Warning 9: Unknown Option : OUT
On Monday, 15 July 2019 at 10:27:49 UTC, Anonymouse wrote: OPTLINK : Warning 9: Unknown Option : OUT It looks like it's trying to use MS link command-line syntax with DM OPTLINK. I'm not sure why that would happen, as Digger creates a complete sc.ini file containing full paths to all relevant linkers (OPTLINK, and 32-bit / 64-bit MS link). Perhaps Dub or the CygWin environment is interfering somehow? Could you please post the following: - The Digger command-line and digger.ini you used to build D - The contents of ...\Digger\work\result\bin\sc.ini - Also if you could please run the Dub command with -v, and post the full dmd.exe command line that Dub generates and runs.
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Thursday, 16 May 2019 at 20:17:37 UTC, Steven Schveighoffer
wrote:
We do have a nanosecond resolution, and it's just rounded down
to the nearest 10.
For example:
auto d = 15.nsecs;
assert(d == 10.nsecs);
I'm not sure how to feel about this. Maybe there was a better way
to handle nanoseconds here.
You shouldn't be relying on what a string says to know what the
tick resolution is.
I don't like that with your proposal, it seems to add data that's
not there. The 0 is entirely fictional. It might as well be part
of the format string.
For example, if I do writefln("%f", 1.0), I get 1.00.
%f is a C-ism, %s does not do that.
hnsecs is more confusing than nanoseconds. People know what a
nanosecond is, a hecto-nano-second is not as familiar a term.
Agreed, which is why Duration.toString shouldn't be used to
present durations to users.
Developers, however, are expected to know what a hectonanosecond
is, same as with all the other technical terms.
If the output is meant for the user, then hectonanoseconds or
nanoseconds are going to be almost always irrelevant. The
duration should be formatted appropriately to the use case.
Depends on the user and the application.
If the durations are so small or so precise that it makes sense
to display them with such precision, then yes, applications would
do better to use nanoseconds instead of hectonanoseconds.
Re: disabling and enabling console output
On Thursday, 16 May 2019 at 17:42:17 UTC, Alex wrote: I'm not sure if they are failing to block or if they are blocking what is being opened(and not the original console). That is, do I need to not open and simply close stdout? Yes, I see. It won't work because the two libraries are using different C standard libraries, so, SDLImage can't see that the FD was dup'd, and the DM C library most likely doesn't also dup/close the Windows handle. I'm not sure how to do this on Windows, then; maybe someone with more experience would know. Windows has DuplicateHandle, but no equivalent for dup2 that I know of, which would be needed to restore stdin using this method.
Re: disabling and enabling console output
On Thursday, 16 May 2019 at 17:18:01 UTC, Alex wrote: adding int dup(int) @trusted; int dup2(int, int) @trusted; int close(int) @trusted; int open(in char*, int, ...) @trusted; Be sure to make them extern(C). Sorry, I haven't tried it, I'm guessing that it should work based on: https://github.com/digitalmars/dmc/blob/master/include/io.h#L142-L147
Re: disabling and enabling console output
On Thursday, 16 May 2019 at 17:05:01 UTC, Alex wrote: One thing you could try is going one level lower, and using dup() to save the stream to another fd, close() to close the stdout one, and dup2() to restore the saved fd over the stdout one. Unfortunately D doesn't seem to have dup, dup2. They are in the C library. Looks like Druntime has D declarations only for Posix: https://github.com/cybershadow/druntime/blob/issue19433/src/core/sys/posix/unistd.d#L51-L52 You can just copy those.
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Thursday, 16 May 2019 at 16:52:22 UTC, Vladimir Panteleev wrote: On Thursday, 16 May 2019 at 16:49:35 UTC, Alex wrote: Why not just use u? It generally works fine on all the other filesystems * operating systems
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Thursday, 16 May 2019 at 16:49:35 UTC, Alex wrote: Why not just use u? It generally works fine on all the other filesystems, which today have mostly standardized on UTF-8. If that is too much trouble then detect the code page and use u rather than the extended ascii which looks very out of place? Well, a more correct solution would be to check if we're printing to the Windows console, and use Unicode APIs, which would allow this to work regardless of the current 8-bit codepage. However, this (and your suggestion) are complicated to implement due to reasons related to how tightly Phobos is tied to C's FILE* for file input and output.
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Thursday, 16 May 2019 at 15:52:05 UTC, Steven Schveighoffer wrote: Hecto-nano-second, the smallest representable unit of time in SysTime and Duration. The output shouldn't involve the inner workings of the type. It should be changed to say 10 ns. If the output is meant for the developer, then I disagree subjectively, as that creates the impression that the lowest resolution or representable unit of time is the nanosecond. If the output is meant for the user, then hectonanoseconds or nanoseconds are going to be almost always irrelevant. The duration should be formatted appropriately to the use case.
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Thursday, 16 May 2019 at 15:19:03 UTC, Alex wrote: 1 - 17 ms, 553 ╬╝s, and 1 hnsec WTH!! is there any way to just get a normal u rather than some fancy useless asci hieroglyphic? Why don't we have a fancy M? and an h? It's outputting UTF-8, but, your console is not configured to display UTF-8. On Windows, you can do so (before running your program), by running: chcp 65001 Or, within your program, by calling: SetConsoleOutputCP(CP_UTF8); Note that this has some negative side effects, which is why D doesn't do it automatically. (Blame Windows.) What's an hnsec anyways? Hecto-nano-second, the smallest representable unit of time in SysTime and Duration.
Re: disabling and enabling console output
On Thursday, 16 May 2019 at 14:53:14 UTC, Alex wrote: I have some code that disables the console because some other code puts junk on it that I don't want to see... then I enable it. One thing you could try is going one level lower, and using dup() to save the stream to another fd, close() to close the stdout one, and dup2() to restore the saved fd over the stdout one.
Re: Error: template instance `Reflect!(type)` cannot use local `type` as parameter to non-global template `Reflect(Ts...)()`
On Sunday, 7 April 2019 at 05:24:38 UTC, Alex wrote: Error: template instance `Reflect!(type)` cannot use local `type` as parameter to non-global template `Reflect(Ts...)()` mixin(`import `~moduleName!(T)~`;`); mixin(`alias X = T.`~name~`;`); super.Reflect!(X); I realize X is local but I'm trying to figure out why it can't be passed to a "non-global" template. - In DMD, objects may have at most one scope (which can be a class, struct, or stack frame). - Instantiating a template with a scoped object makes the template have the same scope as the object. - If a template is already scoped (non-global), then it thus cannot have a second scope. Hence the error. IIRC there is an experimental pull request which removes this limitation. Workarounds: - Make either the template or the argument global (non-scoped) - Instead of passing the object as a template parameter, pass it as a runtime parameter with a type encapsulating the object. Each runtime parameter may be scoped, thus bypassing the limitation. I'm not sure this applies to your use case, if the Reflect template needs to perform compile-time introspection on the parameter. - If you just need to pass the type, typeof(X) should work of course.
Re: Reading data from the network without knowing the size of the buffer that is coming
On Thursday, 21 March 2019 at 16:54:01 UTC, Roman Sztergbaum wrote: I would like to get rid of the "ubytes[256]" because I do not know the size of the data that is comming, I would like to read the entire buffer that I send at once. Can someone point me? If you do not know the size of the response, then how can you know when you should stop waiting for more bytes? Some connections are stream-oriented, and some are datagram-oriented. With a datagram-oriented connection, each packet has a fixed size (though there is a maximum size). You mentioned this is a UNIX socket connection, and I believe UNIX sockets can be either stream-oriented or datagram-oriented. If the socket is stream-oriented, there should generally be a way for the other end to signal when it's done sending bytes. This can be in the form of a fixed-size "header" containing the body length, or maybe the other end just closes the connection when it's done writing. Other approaches, like reading until there are no more bytes in the buffer (though more may yet to arrive one millisecond later) are generally not reliable. Perhaps you should include more information like what program you are trying to talk to, or the protocol being used.
Re: File.lockingBinaryWriter is not output range?
On Tuesday, 19 March 2019 at 13:25:27 UTC, Denis Feklushkin wrote: On Tuesday, 19 March 2019 at 13:20:37 UTC, Vladimir Panteleev wrote: On Tuesday, 19 March 2019 at 13:14:52 UTC, Denis Feklushkin wrote: /+ dub.sdl: name "hello_world" +/ This doesn't seem necessary :) I add it ~everywhere for faster reproducing of cases. Not sure what you mean by this, because 1) it's not even doing anything if there are no dependencies on Dub packages, and 2) test cases should be self-contained and not have external dependencies anyway. If the test case can only be reproduced with some compiler switches, a shebang using rdmd (with --shebang for multiple switches) can be used to illustrate it.
Re: File.lockingBinaryWriter is not output range?
On Tuesday, 19 March 2019 at 13:14:52 UTC, Denis Feklushkin wrote: /+ dub.sdl: name "hello_world" +/ This doesn't seem necessary :) static assert(isOutputRange!(typeof(stdout.lockingBinaryWriter), byte)); static assert(isOutputRange!(typeof(stdout.lockingBinaryWriter()), byte)); typeof(stdout.lockingBinaryWriter) is a function type. You need the ().
Re: Any easy way to extract files to memory buffer?
On Monday, 18 March 2019 at 21:09:55 UTC, Michelle Long wrote: Trying to speed up extracting some files that I first have to extract using the command line to files then read those in... Not sure what is taking so long. I imagine windows caches the extraction so maybe it is pointless? You can speed up such things using a tmpfs or RAM disk. On Linux you just use mount -t tmpfs ... On Windows it is a little more complicated, there are programs like ImDisk that can create RAM drives (which can then be formatted to whatever). If it's just one file, sometimes you can pipe it from the unpacking program (tar etc.) into the consuming program.
Re: Tricky DMD bug, but I have no idea how to report
On Friday, 8 February 2019 at 09:28:48 UTC, JN wrote: I will try. However, one last thing - in the example test scripts, it runs first with one compiler setting (or D version) and the second time with the other compiler setting (or D version). But it looks like the exit code of the first run is ignored anyway, so why run it? With "set -e", the shell interpreter will exit the script with any command that fails (returns with non-zero status), unless it's in an "if" condition or such. I'll update the article to clarify it.
Re: Tricky DMD bug, but I have no idea how to report
On Thursday, 7 February 2019 at 22:16:19 UTC, JN wrote: Does it also work for dub projects? It will work if you can put all the relevant D code in one directory, which is harder for Dub, as it likes to pull dependencies from all over the place. When "dub dustmite" is insufficient (as in this case), the safest way to proceed would be to build with dub in verbose mode, take note of the compiler command lines it's using, then put them in a shell script and all mentioned D files in one directory, then pass that to Dustmite.
Re: Tricky DMD bug, but I have no idea how to report
On Monday, 17 December 2018 at 21:59:59 UTC, JN wrote: while working on my game engine project, I encountered a DMD codegen bug. It occurs only when compiling in release mode, debug works. Old thread, but FWIW, such bugs can be easily and precisely reduced with DustMite. In your test script, just compile with and without the compiler option which causes the bug to manifest, and check that one works and the other doesn't. I put together a short article on the DustMite wiki describing how to do this: https://github.com/CyberShadow/DustMite/wiki/Reducing-a-bug-with-a-specific-compiler-option
Re: Putting dmd error through grep for dustmite
On Monday, 5 November 2018 at 03:01:43 UTC, Dennis wrote: Does anybody know what the problem is? I'm using Windows 10 and Git Bash. Sounds like the problem comes from the differences in shell syntax (quoting style) for the two shells here. When you run the command in Git Bash, the syntax used is Bash's. However, Dustmite will call shellExecute, which will pass the command to cmd.exe. cmd.exe will interpret \` verbatim (i.e. as \`), so, try not quoting the ` characters (or just replace them with . if you want the command to work in both shells).
Re: Can i watch folders/files for changes with D language?
On Tuesday, 9 October 2018 at 17:20:25 UTC, Ephrahim wrote: So i need your help guys, can you point me to any documentation or libraries i can use to watch files/folders for changes (delete, edit, new content)? This package seems to do what you need: https://code.dlang.org/packages/fswatch Also i'm very sorry if i didn't post this to the right Thread/Forum, i just found this forum and i wasn't very sure where i'd post this. Thanks a lot You posted this in the right forum :)
Re: What does -vtls compiler flag does and ...
On Wednesday, 3 October 2018 at 20:41:15 UTC, welkam wrote: This flag blocks compilation and I want to just remove it but since I dont know what it is used for I hesitate. If my attempts were to be successful in compiling dmd with other compilers I would make pull request but now I have more question than answers. What this flag does? Why some files compiled with it and other dont? Why it is added to all compilation targets unconditionally? A long time ago, D global and static variables worked just like in C/C++, and went in the data segment (i.e. there was one per program). At one point, this was changed, so that they would go into TLS by default (i.e. one per thread), thus making a lot of code that was previously not thread-safe, magically thread-safe. To allow developers who wanted to make sure that their code compiled to exactly the same behavior as before to update their programs easily, this flag was added, so that they could find all the places in their program where the new behavior will take into effect. Today, it is still useful for finding globals in programs that shouldn't have any. I don't know why it's used in DMD, but that might certainly be the reason, considering there is a long-term ongoing effort to make DMD usable as a library. The flag otherwise should have no effect on the result of the compilation (i.e. produced object files / binaries), so you can remove it locally. You will probably need to investigate why the compiler you're using doesn't support it (perhaps it's there under another name) - the code for its implementation should still be there, as all of DMD/LDC/GDC use the same frontend.
Wrong module initialization order when building with Dub on Windows?
Ran into this today, don't have time to dig in now but maybe someone ran into this too. Steps to reproduce: - git clone https://github.com/CyberShadow/ae - cd ae/demo/inputtiming - (download/unpack https://www.libsdl.org/release/SDL2-2.0.8-win32-x86.zip or https://www.libsdl.org/release/SDL2-2.0.8-win32-x64.zip to current directory) - dub On Windows, I get a range violation (in ae.sys.log) which indicates that Runtime.args has length 0, which should never happen. This doesn't happen if I build as usual with rdmd, or on Linux (either rdmd or Dub).
Re: transposed with enforceNotJagged not throwing?
On Saturday, 22 September 2018 at 06:16:41 UTC, berni wrote: Is it a bug or is it me who's doing something wrong? Looking at the implementation, it looks like enforceNotJagged was just never implemented for transposed (only transversed).
Re: Converting a character to upper case in string
On Friday, 21 September 2018 at 12:15:52 UTC, NX wrote: How can I properly convert a character, say, first one to upper case in a unicode correct manner? That would depend on how you'd define correctness. If your application needs to support "all" languages, then (depending how you interpret it) the task may not be meaningful, as some languages don't have the notion of "upper-case" or even "character" (as an individual glyph). Some languages do have those notions, but they serve a specific purpose that doesn't align with the one in English (e.g. Lojban). In which code level I should be working on? Grapheme? Or maybe code point is sufficient? Using graphemes is necessary if you need to support e.g. combining marks (e.g. ̏◌ + S = ̏S).
Re: SerialPort
On Thursday, 20 September 2018 at 10:51:52 UTC, braboar wrote: Can anybody give me a guide of using serial port? Here's a program I wrote (after lots of trial-and-error) to control my monitor through an USB serial-port adapter: https://github.com/CyberShadow/misc/blob/master/pq321q.d Hope this helps.
Re: Get variables with call stack
On Saturday, 22 September 2018 at 05:49:05 UTC, Vladimir Panteleev wrote: In short: there is no easy way, in the general sense. If you can find something that achieves what you need in C++, there's a good chance that it would work to some extent (or could be adapted with reasonable effort) for D, too. D debug information has much in common with C++, however exceptions vary from platform to platform.
Re: Get variables with call stack
On Saturday, 22 September 2018 at 05:43:53 UTC, Vladimir Panteleev wrote: The only way to do that would be using a debugger. The specifics of the solution would thus depend on the platform. On POSIX, it would probably mean getting gdb to print a detailed backtrace for your project. On Windows, you might be able to achieve this by spawning a thread which then uses dbgeng.dll to get a detailed stack trace. One thing to note: only variables in stack frames since the most top-level exception block will be visible (so, you'll also need to disable D runtime's standard exception handler). The reason for this is that exceptions do not capture the entire stack, but extract only a stack trace during instantiation, so to get the entire stack, you'd need to breakpoint _d_throw or such, but at that point you don't know if you're within an exception frame ready to catch the thrown exception. In short: there is no easy way, in the general sense.
Re: Get variables with call stack
On Friday, 21 September 2018 at 19:08:36 UTC, ANtlord wrote: Hello! I need to make a some sort of error report system for an application. I want to catch base Exception class instance and report call stack and with the call stack I want to report all variables with their values. There are a couple of services that make report using call stack and provides variables' values. Sentry.io, New Relic etc. I see how to get call stack, the book Adam Ruppe writes helps me. How to get all variables from every layer of call stack? The only way to do that would be using a debugger. The specifics of the solution would thus depend on the platform. On POSIX, it would probably mean getting gdb to print a detailed backtrace for your project. On Windows, you might be able to achieve this by spawning a thread which then uses dbgeng.dll to get a detailed stack trace.
Re: -O flag ; automatic cast in a bitshift
On Thursday, 20 September 2018 at 11:14:05 UTC, Guillaume Lathoud wrote: Thanks! FYI, it's undefined in D mainly because the behavior of the actual Intel CPU instruction is undefined in such cases: https://c9x.me/x86/html/file_module_x86_id_285.html "it is undefined for SHL and SHR instructions where the count is greater than or equal to the size (in bits) of the destination operand".
Re: Manual delegates
On Sunday, 16 September 2018 at 14:12:27 UTC, Guillaume Piolat wrote: Anyone has any information about the ABI of delegates? In particular how to call them with a particular "this"/frame pointer? To solve a hairy problem I need a delegate with a synthesized frame pointer. https://dpaste.dzfl.pl/cf44417c98f9 The problem is that delegate forwarding seems to require GC closures. I want manually-managed closures. Have a look at the implementation of toDelegate, which does exactly this: https://github.com/dlang/phobos/blob/v2.082.0/std/functional.d#L1463
Re: try find the fastest way to convert a group string into index?
On Sunday, 16 September 2018 at 10:04:09 UTC, learnfirst1 wrote:
how to make this more fast like with one loop and get the
results.
This is a more general problem than any specific programming
language; you may want to look into perfect hashing:
https://en.wikipedia.org/wiki/Perfect_hash_function
There exists software to generate perfect hash functions, e.g.
GNU gperf:
https://www.gnu.org/software/gperf/
It looks like Basile wrote one for D:
https://github.com/BBasile/IsItThere
If you don't want to go that far, you can generate a string
switch using string mixins:
void main()
{
static immutable string[] keywords = ["foo", "bar", "baz"];
enum Keyword { foo, bar, baz }
Keyword parseKeyword(string s)
{
switch (s)
{
mixin({
string code;
foreach (keyword; keywords)
code ~= `case "` ~ keyword ~ `": return Keyword.` ~ keyword
~ `;`;
return code;
}());
default:
throw new Exception("No such keyword!");
}
}
assert(parseKeyword("bar") == Keyword.bar);
}
Re: Cannot use UFCS in lambda?
On Sunday, 16 September 2018 at 09:46:15 UTC, berni wrote: Where is my mistake? Lambdas are not the issue here. The problem is more general: you can only use top-level symbols in UFCS. You can use an identity alias template to bypass this: https://blog.thecybershadow.net/2015/04/28/the-amazing-template-that-does-nothing/ (search for UFCS in the page).
Re: array to string functional?
On Friday, 14 September 2018 at 20:43:45 UTC, SrMordred wrote:
On Friday, 14 September 2018 at 19:44:37 UTC, berni wrote:
a) I've got an int[] which contains only 0 und 1. And I want
to end with a string, containing 0 and 1. So [1,1,0,1,0,1]
should become "110101". Of course I can do this with a loop
and ~. But I think it should be doable with functional style,
which is something I would like to understand better. Can
anyone help me here? (I think a.map!(a=>to!char(a+'0')) does
the trick, but is this good style or is there a better way?)
Yes, that's fine. That gives you a range; if you want an array,
call array() with that expression. Also, since you know the
addition won't overflow, you can substitute the to!char call with
a cast (arr.map!(c => cast(char)(c + '0')).array).
Another option is to index a string literal: arr.map!(c =>
"01"[c]).array
auto a = [1,0,1,1,1,0,1,0,1,1,1,1,0];
a.map!(to!string)
.join("")
.chunks(4)
.map!(to!string) //don´t know why the chunks are not
already strings at this point ;/
.writeln;
That's needlessly complicated and inefficient; this will allocate
one string per array element.
If you don't need the result to be actual arrays, this works:
auto res = [1,0,1,1,1,0,1,0,1,1,1,1,0]
.map!(c => "01"[c])
.chunks(4);
assert(equal!equal(res, ["1011","1010","","0"]));
If you need a real array of arrays:
auto arr = res
.map!array
.array;
assert(arr == ["1011","1010","","0"]);
Re: x64 Privileged instruction
On Saturday, 15 September 2018 at 18:05:58 UTC, Josphe Brigmo wrote: I have always gotten these types of errors on x64 and, it may be my machine, it has happened with many dmd versions, visual D and visual studio... Oh, you mean the message that appears in Visual Studio, not stderr. Exception handling in Win64 is very different than on Win32, so that's probably it. Visual Studio probably doesn't know how to extract the error message from a D exception in Win64. If you run the D program without a debugger attached, you should see the exception message on stderr (or a MessageBox, if you're building a GUI executable).
Re: x64 Privileged instruction
On Thursday, 13 September 2018 at 05:50:53 UTC, Josphe Brigmo wrote: Privileged instruction Lots of code. I pretty much always get this error. Something must have gone really wrong to get this error. Most likely, the CPU instruction pointer ended up in a memory area without any code in it. Windows exception handling is tricky (see Don/Walter's recent discussion), but basic cases should be well-covered by the compiler/runtime test suite. So, I suspect one of the following happened: - Your program is exhibiting an edge case and uncovering a bug not covered by the test case. If this is the case, please reduce your program to a minimal, self-contained example, and file a bug report. - There is a bug in your program that is causing its memory to be corrupted. Using @safe can help narrow it down (https://dlang.org/spec/memory-safe-d.html). - There is something specific to your machine that causes the problem to occur there, but not on the test runners. This could happen e.g. due to software which alter behavior of other programs (like through DLL injection), or using a specific Windows version. You can eliminate this possibility by running the DMD test suite.
Re: dealing with very long paths and names
On Friday, 14 September 2018 at 21:16:31 UTC, Jonathan M Davis wrote: Yeah, though if you write cross-platform applications or libraries (and ideally, most applications and libraries would be platform-agnostic), you can't necessarily avoid all of the Windows insanity, even if you yourself use a platform without those problems. Linux generally allows you to go ahead and use the filesystem as a database, and this works pretty well in a lot of cases. Filesystem performance is much better, and so are the limitations - not just the path length as discussed in this thread, but also the range of valid characters (anything except / and NUL is fine). Plus, depending on your choice of filesystem, you get bonus features like snapshots, incremental backups, and deduplication. It's a boon for prototyping (or Linux-only software).
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Friday, 13 July 2018 at 07:51:51 UTC, Dukc wrote: I know about Vladimir's d-scripten tools library which would help, but it's based on Alawains library copyleft library, which makes also Vladimir's work copyleft, so I won't use it. Hmm, I wasn't aware of this. I wonder if the decision to make the redistributable parts of dscripten was intentional (maybe the intention was to apply the license only to the scripts which build the toolchain). 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.
Re: D'ish similar_text?
On Thursday, 10 May 2018 at 20:32:11 UTC, Dgame wrote: immutable size_t len = s1.length + s2.length; percent = (len - distance) * 100.0 / len; Note that this formula will give you only 50% similarity for "abc" and "def", i.e. two completely different strings. I suggest to divide by max(s1.length, s2.length) instead.
Re: D'ish similar_text?
On Thursday, 10 May 2018 at 20:08:04 UTC, Dgame wrote: void similar_text_similar_str(char* txt1, size_t len1, char* That looks like an implementation of Levenshtein distance. We have one in Phobos: https://dlang.org/library/std/algorithm/comparison/levenshtein_distance.html
Re: dustmite watch shell script (.test vs .lookahead.*)
On Friday, 6 April 2018 at 15:35:59 UTC, Anonymouse wrote: The dustmite wiki[0] lists the following example script for use to monitor the reduction progress: Here's a more complete version that also works with -j: https://gist.github.com/CyberShadow/2e8f01895c248111c171e982313bb008
Re: Spawning a process: Can I "have my cake and eat it too"?
On Friday, 2 March 2018 at 04:50:06 UTC, Nick Sabalausky (Abscissa) wrote: Launch a process (spawnProcess, pipeShell, etc) so the child's stdout/stderr go to the parent's stdout/stderr *without* the possibility of them getting inadvertently reordered/reinterleaved when viewed on the terminal, *and* still allow the parent to read the child's stdout and stderr? I think it's possible on Linux. 1. Disable buffering on the pipe (see stdbuf etc.) 2. Fake output type to fool isatty (e.g. script -c 'child_program args...' /dev/null)
Re: Wiki spam
On Saturday, 3 February 2018 at 06:34:57 UTC, Tony wrote: Don't know if there is a better place to report this, but the wiki attracted a spammer: Deleted, thanks. We're generally doing pretty well with spam (compared to other wikis) thanks to https://github.com/CyberShadow/dcaptcha , but feel free to report any extant instances to me by email directly.
Re: database or disk is full ; Error while posting message in this D forum
On Friday, 15 December 2017 at 17:26:04 UTC, Vino wrote: Hi All, We are getting the above error message while posting any message in this forum, can any look into this please. Should be fixed now. Google was classifying one monitoring service's emails as spam, and completely rejecting another monitoring service's emails because it did not have a reverse IPv6 PTR record...
Re: behaviour of spawnProcess
On Saturday, 25 November 2017 at 02:32:17 UTC, Fra Mecca wrote: I have noticed that whenever j contains a string with a space in it, spawnprocess splits the string into another argument. That shouldn't happen. If you are on Windows, note that processes do not see the command line as an array of arguments, but as a single string. It is then the duty of the process to split up the string into individual arguments. If the program lets the C runtime do it by reading main's argc/argv, or uses CommandLineToArgvW (which is what C runtimes usually use under the hood), things generally work ask expected. However, some programs don't do that, and instead use their own custom logic for parsing the command line string (such as many built-in or standard DOS/Windows commands). On POSIX, this can be caused if the program you're running is itself running another program, and isn't constructing its arguments correctly (e.g. it uses the system() function instead of an exec* function).
Re: Dustmite always reduced to empty set after two iterations
On Wednesday, 11 October 2017 at 20:36:58 UTC, Nordlöw wrote: What am I doing wrong? Invoking dub from dustmite probably isn't going to work well. Instead, try using dub's dustmite command: https://code.dlang.org/docs/commandline#dustmite
Re: segfault on gc.impl.conservative.gc.Gcx.smallAlloc
On Monday, 25 September 2017 at 21:34:40 UTC, Mengu wrote: delete fileContents; This looks suspicious - it is a slice of the memory-mapped file, not memory on the GC-managed heap, so "delete" is inapplicable to it. The GC ought to throw an exception when attempting to delete things not on the GC heap though. I think the stack trace itself looks like something that should only happen when the GC's internal data structures are corrupted, so you may want to investigate in that direction.
Re: It makes me sick!
On Tuesday, 1 August 2017 at 14:29:28 UTC, Adam D. Ruppe wrote: So we can keep the search path: `datetime.di`, then `datetime.d`, then `datetime/package.d`, and any one of them, as long as it has `module std.datetime;` at the top, can count equally as the package.d. Sorry, isn't that how things work now? The problem here is that the compiler picks up the OLD datetime.d, and then things fail at the linking stage because symbols in the old datetime.d are not present in the new phobos.lib.
Re: Need simple sound
On Monday, 3 July 2017 at 10:40:03 UTC, Martin Tschierschke wrote: On Monday, 3 July 2017 at 09:24:35 UTC, Guillaume Piolat wrote: On Monday, 3 July 2017 at 08:55:20 UTC, Martin Tschierschke wrote: Hello for a simple game I would like to add some very simple sound, not much different than the beeps of "PAC Man". Is there anything I can use for this? DerelictSDL supports the loading of SDL_mixer, which makes it very practical. Thank you for the hint, a short google search was not so successful, can you give me an additional hint / link? I think I would have to produce a time series of a sinus for example and to play it? Here's a program that plays some square waves: https://dump.thecybershadow.net/9db4fcd7b004e5dfccf537e49cbb72a6/test.d
Re: D and memory mapped devices
On Wednesday, 14 June 2017 at 08:10:57 UTC, Russel Winder wrote: This would appear a priori to not allow for actual memory mapped devices using it, or am I missing something? I believe the only case where it might matter is if the device was sensitive to the read/write size (1/2/4 bytes). Otherwise, the generated code should be functionally the same as C bitfields.
Re: How to Get Screenshot on Windows ?
On Sunday, 28 May 2017 at 04:05:47 UTC, Softwarez wrote: Hi can anyone please help me how to get screenshot on Windows using D, because all the other threads are using linux to get screenshot. In the same way you'd do it in C. Here is a more convoluted D example in the form of a program I had lying around. It takes a screenshot of a window with alpha transparency, by taking two screenshots with white and black background, and calculating the alpha channel from those: https://dump.thecybershadow.net/e6e1fc9bb0da97dbe0b198a243aac31c/windowscr.d It uses my image library for bitmap manipulation: https://github.com/CyberShadow/ae
Re: trait detecting anonymous union?
On Monday, 22 May 2017 at 21:03:42 UTC, Bastiaan Veelo wrote: Is there a way to detect at CT that S has overlapping data members, when an anonimous union is used as above? I have an implementation here: https://github.com/CyberShadow/rclidasm/blob/31bde3347ec1259026b6ab15e2305f2a99e63a30/src/rclidasm/meta.d#L110-L183
Re: std.getopt and std.datetime
On Saturday, 13 May 2017 at 05:53:25 UTC, Russel Winder wrote:
Is there a canonical, idiomatic way of processing std.datetime
objects using std.getopt?
As std.getopt is going to give you strings, you need to convert
strings to SysTime values, e.g. using fromSimpleString:
import std.datetime;
import std.getopt;
import std.stdio;
void main()
{
string[] args = ["program", "--date", "2017-May-13 05:58:59"];
SysTime t;
getopt(args,
"date", (string _, string s) { t = SysTime.fromSimpleString(s);
},
);
writeln(t);
}
For more flexibility, you'll need a date parser. Mine is here:
https://github.com/CyberShadow/ae/blob/master/utils/time/parse.d
Re: How can I pass an argument to rdmd --evel=
On Sunday, 7 May 2017 at 11:29:30 UTC, k-five wrote: It should be possible! rdmd --eval=, without accepting argument is useless. FWIW, you can still pass input through stdin.
Re: How can I pass an argument to rdmd --evel=
On Sunday, 7 May 2017 at 11:11:05 UTC, Vladimir Panteleev wrote: Currently it's not possible: https://issues.dlang.org/show_bug.cgi?id=13345
Re: How can I pass an argument to rdmd --evel=
On Sunday, 7 May 2017 at 10:49:25 UTC, k-five wrote:
After reading about rdmd and --eval, I tried this:
rdmd --eval='auto f=File("ddoc.html");foreach(line;f.byLine)
if(line.length<10) writeln(line);f.close'
and worked!
Now I am wonder if there is a way to pass "ddoc.html" to this
one-liner? that can work with --loop.
I mean:
// --loop by default has foreach(line ...
// like perl -n
rdmd --loop='if( line.length < 10 ) writeln( line );' ddoc.html
but it is an error in syntax and rdmd says:
Cannot have both --eval and a program file ('ddoc.html')
Currently it's not possible:
Re: std.digest toHexString
On Thursday, 16 March 2017 at 16:13:33 UTC, Carl Sturtivant wrote: What's going on here? Looks like this bug: https://issues.dlang.org/show_bug.cgi?id=9279 Has it not been fixed?
Re: 'Access Violation Error' with parallel-foreach loop
On Saturday, 18 March 2017 at 16:15:30 UTC, ooyu wrote: I don't understand why got Access Violation error. :-( That looks like https://issues.dlang.org/show_bug.cgi?id=13727, though I thought a fix was included in recent DMD Windows versions. Try using std.file.write.
Re: code folding
On Monday, 13 March 2017 at 21:33:56 UTC, Inquie wrote: One can say that it is a useless feature because D doesn't have it... or one could say that D is useless because it doesn't have it. A nice balance is simply to say "It is a useful feature that has proven it's worth and it is time that D implements something like it". As D becomes more mainstream, these features will be requested. D should learn from other language/compilers just as other languages/compilers have learned from it. (it's a two a way street) FYI: The "you must implement my feature request or D will never succeed" attitude is rather common and never helpful. Not to mention that such an argument would be demonstrably false: every popular language without the feature you want has apparently succeeded despite not having said feature. When one had a shit load of types in a single file, it is nice to be able to fold them. It is also nice to be able to group them in some way(hence the question) and fold the group so that large chunks of the file can be visibly reduced. If you have enough declarations in one file that they call for code folding, it may be better to move them to a separate module. Public imports and aliases allow doing this without breaking any code. If you would like a way to achieve code folding without involving language constructs, I think the starting point would be your IDE/editor's D plugin vendor. Once implemented in one editor, the syntax could be implemented in others and be informally standardized. I don't think that it would make sense to introduce it into the language syntax proper. The #region syntax in C# makes sense for C# because, as already mentioned, the language vendor is also the main IDE vendor; but also because C#, like Java, requires a lot more boilerplate - writing programs in C# is much more tedious without an IDE than with. This is not the case of D, which was designed to solve problems that would otherwise require boilerplate code in the language itself. Generally speaking, I would recommend to simply avoid code folding altogether: https://blog.codinghorror.com/the-problem-with-code-folding/
Re: Concatenate 2 ranges
On Friday, 11 November 2016 at 13:39:32 UTC, RazvanN wrote: It does work, the problem is that [1, 2, 3].sort() is of type SortedRange(int[], "a < b") while r is of type SortedRange(Result, "a < b"). This is a problem if you want to return r in a function which has return type SortedRange(int[], "a < b"). If you absolutely need a `SortedRange(int[], "a < b")` without substitute, then there's no way except building an array that has the numbers sorted, which is always going to be O(n) unless you can place the two input arrays adjacent into memory beforehand somehow. However, if you just want the pre-chain ranges and post-chain ranges be a compatible type, you can use a class wrapper, such as RandomAccessFinite - thus, the assumeSorted result will be `SortedRange(RandomAccessFinite, "a < b")`. Note, though, that even though the algorithmic complexity will be O(1), every access to the wrapped range will go through a virtual method call, so it will affect performance in practice. There is no way around this because the type pulls in the underlying range's behavior, and e.g. SortedRange!(int[]) knows that the underlying elements are arranged linearly in memory, SortedRange of a chain knows that it first has to check which sub-range any operation will refer to, and SortedRange of a RandomAccessFinite knows that it just has to pass the request to a virtual class method which hides the underlying implementation.
Re: Concatenate 2 ranges
On Friday, 11 November 2016 at 13:30:17 UTC, RazvanN wrote: I know that I can use the .array property, but I think that this iterates through all of my elements. Using assumeSorted(chain(r1, r2).array) will return a SortedRange, but I am not sure what the complexity for this operation is. .array allocates, so it's going to be O(n), but the allocation will probably be more expensive. Is there a way to concatenate 2 ranges (SortedRange in my case) in O(1) time? assumeSorted(chain(a, b)) ? This works for me: auto r = assumeSorted(chain([1, 2, 3].sort(), [1, 2, 3].sort()));
