Re: DUB / compiling same source and config to different windows subsystems in 32/64 bit
On Tuesday, 5 March 2019 at 07:25:40 UTC, Mike Parker wrote: documentation. Instead, it belongs in the DMD windows documentation. It's currently missing: https://dlang.org/dmd-windows.html#linking The 32-bit COFF support is missing there I mean. It does specifically mention that there are different linkers involved in the 32-bit and 64-bit toolchain.
Re: DUB / compiling same source and config to different windows subsystems in 32/64 bit
On Tuesday, 5 March 2019 at 07:10:51 UTC, Robert M. Münch wrote: t. My missing point was, that I didn't expect to work with two different links. And I totally agree, DUB needs to mention this. Make everyones live easy. I don't want to dig through fragmented information, collect and sort all pieces etc. That's just waste of time. If I use DUB, I want to see all things around building D programs. That simple... Is there an I have never seen *-x86_mscoff mentioned anywhere... Again, this has nothing to do with dub. It's the behavior of the linkers. When you use WinMain, the MS Linker will give you a windows subsystem by default. When you use main, it will give you a console subsystem. DMD gained the -m32mscoff a good while ago in order to enable coff output and compatibility with the MS linker in 32-bit mode. Built-in dub support came much later with x86_mscoff. *That* needs to be documented in the dub docs, but the behavior of the various linkers out there is beyond the scope of dub's documentation. Instead, it belongs in the DMD windows documentation. It's currently missing: https://dlang.org/dmd-windows.html#linking
Re: DUB / compiling same source and config to different windows subsystems in 32/64 bit
On 2019-03-05 05:03:42 +, Mike Parker said: On Tuesday, 5 March 2019 at 04:32:57 UTC, evilrat wrote: On Tuesday, 5 March 2019 at 03:48:22 UTC, Mike Parker wrote: I stopped using WinMain with D a long time ago. It's not necessary. If you always use `main`, then both linkers will provide you with a console subsystem app by default. That's particularly useful during development. You can add a configuration to your dub.json that turns on the windows subsystem for both linkers. For OPTLINK (x86) you only need to pass to the linker `/SUBSYSTEM:windows`. For the MS linker (x86_mscoff, x86_64) you need to that and you need to specify that the entry point is `main`, because it will expect `WinMain` when you specify the windows subsystem. You can do that with `/ENTRY:mainCRTStartup` https://docs.microsoft.com/en-us/cpp/build/reference/subsystem-specify-subsystem?view=vs-2017 https://docs.microsoft.com/en-us/cpp/build/reference/entry-entry-point-symbol?view=vs-2017 All of this should be added on dub docs with small snippets and explanation as a section dedicated to Windows and maybe even on D docs as well, because you know, it shows up again and again from time to time This has nothing to do with dub, so that’s the wrong place for it. The dmd for windows docs needs to make clear the distinction between the linkers and the differences in behavior, and point to the linked docs for options. I just checked the Optlink page and didn’t see /subsystem documented, so that needs to be fixed. I’ll put it on my todo list. My missing point was, that I didn't expect to work with two different links. And I totally agree, DUB needs to mention this. Make everyones live easy. I don't want to dig through fragmented information, collect and sort all pieces etc. That's just waste of time. If I use DUB, I want to see all things around building D programs. That simple... Is there an I have never seen *-x86_mscoff mentioned anywhere... -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: DUB / compiling same source and config to different windows subsystems in 32/64 bit
On Tuesday, 5 March 2019 at 04:32:57 UTC, evilrat wrote: On Tuesday, 5 March 2019 at 03:48:22 UTC, Mike Parker wrote: I stopped using WinMain with D a long time ago. It's not necessary. If you always use `main`, then both linkers will provide you with a console subsystem app by default. That's particularly useful during development. You can add a configuration to your dub.json that turns on the windows subsystem for both linkers. For OPTLINK (x86) you only need to pass to the linker `/SUBSYSTEM:windows`. For the MS linker (x86_mscoff, x86_64) you need to that and you need to specify that the entry point is `main`, because it will expect `WinMain` when you specify the windows subsystem. You can do that with `/ENTRY:mainCRTStartup` https://docs.microsoft.com/en-us/cpp/build/reference/subsystem-specify-subsystem?view=vs-2017 https://docs.microsoft.com/en-us/cpp/build/reference/entry-entry-point-symbol?view=vs-2017 All of this should be added on dub docs with small snippets and explanation as a section dedicated to Windows and maybe even on D docs as well, because you know, it shows up again and again from time to time This has nothing to do with dub, so that’s the wrong place for it. The dmd for windows docs needs to make clear the distinction between the linkers and the differences in behavior, and point to the linked docs for options. I just checked the Optlink page and didn’t see /subsystem documented, so that needs to be fixed. I’ll put it on my todo list.
Re: DUB / compiling same source and config to different windows subsystems in 32/64 bit
On Tuesday, 5 March 2019 at 03:48:22 UTC, Mike Parker wrote: I stopped using WinMain with D a long time ago. It's not necessary. If you always use `main`, then both linkers will provide you with a console subsystem app by default. That's particularly useful during development. You can add a configuration to your dub.json that turns on the windows subsystem for both linkers. For OPTLINK (x86) you only need to pass to the linker `/SUBSYSTEM:windows`. For the MS linker (x86_mscoff, x86_64) you need to that and you need to specify that the entry point is `main`, because it will expect `WinMain` when you specify the windows subsystem. You can do that with `/ENTRY:mainCRTStartup` https://docs.microsoft.com/en-us/cpp/build/reference/subsystem-specify-subsystem?view=vs-2017 https://docs.microsoft.com/en-us/cpp/build/reference/entry-entry-point-symbol?view=vs-2017 All of this should be added on dub docs with small snippets and explanation as a section dedicated to Windows and maybe even on D docs as well, because you know, it shows up again and again from time to time.
Re: DUB / compiling same source and config to different windows subsystems in 32/64 bit
On Monday, 4 March 2019 at 18:34:09 UTC, Robert M. Münch wrote:
Hi, when compiling a minimal Windows GUI app (using WinMain())
and compiling it with DUB, the 32-bit x86 version is a
character subsystem EXE (writeln works) and for x86_64 it's a
GUI subsystem EXE (writeln doesn't work). Since compiling the
same source, with the same DUB config file, I would expect the
x86 and x86_64 version to be equal.
That's the DUB JSON I use:
{
"targetType" : "executable",
"libs-windows-x86_64": ["user32", "gdi32"],
"libs-windows-x86" : ["gdi32"],
}
So, how can I get a character subsystem for x86_64 and a GUI
subsystem for x86?
I stopped using WinMain with D a long time ago. It's not
necessary. If you always use `main`, then both linkers will
provide you with a console subsystem app by default. That's
particularly useful during development. You can add a
configuration to your dub.json that turns on the windows
subsystem for both linkers.
For OPTLINK (x86) you only need to pass to the linker
`/SUBSYSTEM:windows`.
For the MS linker (x86_mscoff, x86_64) you need to that and you
need to specify that the entry point is `main`, because it will
expect `WinMain` when you specify the windows subsystem. You can
do that with `/ENTRY:mainCRTStartup`
https://docs.microsoft.com/en-us/cpp/build/reference/subsystem-specify-subsystem?view=vs-2017
https://docs.microsoft.com/en-us/cpp/build/reference/entry-entry-point-symbol?view=vs-2017
Re: DUB / compiling same source and config to different windows subsystems in 32/64 bit
On Tuesday, 5 March 2019 at 02:13:30 UTC, evilrat wrote:
This should do for MS linker
"lflags-windows-x86_64": ["/SUBSYSTEM:CONSOLE"],
"lflags-windows-x86_mscoff": ["/SUBSYSTEM:WINDOWS"]
For old optlink x86 it is a bit harder, you need to include
special .def file that has instruction for linker, here is an
example from dlangui[2], adding it with linker libs should
work, probably, or maybe, or...
No, you don't need a def file. OPTLINK understands the same
option:
hello.d
```
void main() {
import std.stdio;
writeln("Hello");
```
`dmd hello` outputs "hello"
`dmd -L/SUBSYSTEM:windows hello` outputs nothing.
Re: std.zlib odd behavior
On Tuesday, 5 March 2019 at 01:43:42 UTC, solidstate1991 wrote: https://github.com/ZILtoid1991/dimage/blob/master/source/dimage/png.d It seems that after a certain point, it doesn't add more data to the compression stream, flushing doesn't help. I haven't found the bug in your code yet, but one thing I suspect from my experience is you might be reusing a buffer. std.zlib actually stores pointers internally across function calls, so if you are trying to compress a stream, you are liable to get corruption. (std.zlib is very bad code, frankly.) I don't know for sure though, my brain is in the compiler tonight...
Re: DUB / compiling same source and config to different windows subsystems in 32/64 bit
On Monday, 4 March 2019 at 18:34:09 UTC, Robert M. Münch wrote:
Hi, when compiling a minimal Windows GUI app (using WinMain())
and compiling it with DUB, the 32-bit x86 version is a
character subsystem EXE (writeln works) and for x86_64 it's a
GUI subsystem EXE (writeln doesn't work). Since compiling the
same source, with the same DUB config file, I would expect the
x86 and x86_64 version to be equal.
That's the DUB JSON I use:
{
"targetType" : "executable",
"libs-windows-x86_64": ["user32", "gdi32"],
"libs-windows-x86" : ["gdi32"],
}
So, how can I get a character subsystem for x86_64 and a GUI
subsystem for x86?
For MS linker just pass the linker flag /SUBSYSTEM:CONSOLE for
console, or /SUBSYSTEM:WINDOWS for no console, it also detects
that by the presence of WinMain(), more about linker[1]
This should do for MS linker
"lflags-windows-x86_64": ["/SUBSYSTEM:CONSOLE"],
"lflags-windows-x86_mscoff": ["/SUBSYSTEM:WINDOWS"]
For old optlink x86 it is a bit harder, you need to include
special .def file that has instruction for linker, here is an
example from dlangui[2], adding it with linker libs should work,
probably, or maybe, or...
Ok while I writting this I checked dlangui example[3], so do this
with that def file
"sourceFiles-windows-x86": ["$PACKAGE_DIR/src/win_app.def"],
[1]
https://docs.microsoft.com/en-us/cpp/build/reference/subsystem-specify-subsystem?view=vs-2017
[2] https://github.com/buggins/dlangui/blob/master/src/win_app.def
[3]
https://github.com/buggins/dlangui/blob/master/examples/example1/dub.json#L14
std.zlib odd behavior
https://github.com/ZILtoid1991/dimage/blob/master/source/dimage/png.d It seems that after a certain point, it doesn't add more data to the compression stream, flushing doesn't help.
Re: InsertBefore in DList of structs
On Monday, 4 March 2019 at 10:09:19 UTC, drug wrote:
On 04.03.2019 13:03, drug wrote:
insertStable needs DList.Range, not Until!... one. You can do
something like this https://run.dlang.io/is/A2vZjW
Oops, it was wrong example, I'd recommend this way -
https://run.dlang.io/is/ugPL8j
```
import std.algorithm, std.container, std.stdio;
struct DataPoint {
immutable ulong time;
ulong value;
}
void main() {
auto dataPoints = DList!DataPoint([
DataPoint(10_000_000, 1),
DataPoint(30_000_000, 3),
DataPoint(40_000_000, 4),
]);
auto time = 30_000_000;
auto r = findSplit!((a, b) => a.time == b)(dataPoints[],
[time]);
auto dp = dataPoints[].find(r[1].front);
writeln("before: ", dataPoints[]);
dataPoints.insertBefore(dp, DataPoint(20_000_000, 2));
writeln("after: ", dataPoints[]);
}
```
Thanks, seems that using dataPoints[] makes dataPoints usable as
an range. How can I learn more about [] operator? I'm not sure I
understand how is this documented in DList.
Find does the job! What's the difference between find and until?
Re: Help with Regular Expressions (std.regex)
On 3/3/19 7:07 PM, Samir via Digitalmars-d-learn wrote:
I am belatedly working my way through the 2018 edition of the Advent of
Code[1] programming challenges using D and am stumped on Problem 3[2].
The challenge requires you to parse a set of lines in the format:
#99 @ 652,39: 24x23
#100 @ 61,13: 15x24
#101 @ 31,646: 16x28
I would like to store each number (match) as an element in an array so
that I can refer to them by index.
There is also std.file.slurp which makes this quite easy:
slurp!(int, int, int, int, int)("03.input", "#%d @ %d,%d: %dx%d");
You can then later expand the matches in a loop and process the claims:
foreach(id, offX, offY, width, height; ...
Re: Help with Regular Expressions (std.regex)
On Sunday, 3 March 2019 at 19:27:17 UTC, user1234 wrote: oops forgot the bang auto allMatches = matchAll(line, pattern).map!(a => a.hit).array; Thanks, user1234! Looks like `map` is another topic I need to read up upon. I slightly modified your suggestion and went with: auto allMatches = matchAll(line, pattern).map!(a => to!int(a.hit)).array; which also takes care of converting the string to int. Samir
DUB / compiling same source and config to different windows subsystems in 32/64 bit
Hi, when compiling a minimal Windows GUI app (using WinMain()) and
compiling it with DUB, the 32-bit x86 version is a character subsystem
EXE (writeln works) and for x86_64 it's a GUI subsystem EXE (writeln
doesn't work). Since compiling the same source, with the same DUB
config file, I would expect the x86 and x86_64 version to be equal.
That's the DUB JSON I use:
{
"targetType" : "executable",
"libs-windows-x86_64": ["user32", "gdi32"],
"libs-windows-x86" : ["gdi32"],
}
So, how can I get a character subsystem for x86_64 and a GUI subsystem for x86?
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: precise GC
On Monday, 4 March 2019 at 10:38:29 UTC, KnightMare wrote:
For example, we have some rooted memory block as
auto rooted = new long[1_000_000];
1) conservative-GC will scan it for false pointers every
GC-cycle. is it true?
Well, conservative GC in general might, but D's GC would NOT.
D's old GC is arguably semi-precise. It would scan void[]
conservatively, anything that looks like a pointer is considered
maybe a pointer. But it would NOT scan blocks allocated as long[]
or ubyte[]. It would allocate those as NO_SCAN blocks.
The difference is in combination things, like the stack or
structs with static blocks.
struct {
int a;
void* b;
}
The old GC would treat that whole struct as potentially pointers,
both a and b. The new precise GC would know only b needs to be
scanned inside that struct.
The even bigger deal with precise is it also knows only b would
need to be changed if the pointer were to move - that's the big
gain precise is setting the groundwork for, to enable moving GC
optimizations.
Re: precise GC
IMO need more explanations about precise-GC and cases where behavior of precise and conservative same and differs
Re: precise GC
/* English is not my native, and I tried to use Google translate. I hope u will understand subtleties of questions */ For precise-GC: 3) closures: do the closures have any internal types that helps to GC or are they (full closure memory block) scanned as in the conservative mode? 4) associative arrays: SomeTypeWithRefsToClasses[string] any pair will be allocated at some memory block [hash, key, value] as I imagine. Will be precise-GC scan at every pair block only some fields of SomeTypeWithRefsToClasses or full [pair-block]? will be scanned string-key memory block: span-struct and\or chars data?
precise GC
As I understood conservative-GC scans all allocated memory blocks for false pointers. In other hand precise-GC scans only explicit memory blocks that contains (objects of types that contains) pointers/refs or "muddy" types (void, void[]...). For example, we have some rooted memory block as auto rooted = new long[1_000_000]; 1) conservative-GC will scan it for false pointers every GC-cycle. is it true? 2) precise-GC will NOT scan it at all. is it true?
Re: InsertBefore in DList of structs
On 04.03.2019 13:03, drug wrote:
insertStable needs DList.Range, not Until!... one. You can do something
like this https://run.dlang.io/is/A2vZjW
Oops, it was wrong example, I'd recommend this way -
https://run.dlang.io/is/ugPL8j
```
import std.algorithm, std.container, std.stdio;
struct DataPoint {
immutable ulong time;
ulong value;
}
void main() {
auto dataPoints = DList!DataPoint([
DataPoint(10_000_000, 1),
DataPoint(30_000_000, 3),
DataPoint(40_000_000, 4),
]);
auto time = 30_000_000;
auto r = findSplit!((a, b) => a.time == b)(dataPoints[], [time]);
auto dp = dataPoints[].find(r[1].front);
writeln("before: ", dataPoints[]);
dataPoints.insertBefore(dp, DataPoint(20_000_000, 2));
writeln("after: ", dataPoints[]);
}
```
Re: InsertBefore in DList of structs
On 04.03.2019 11:14, r-const-dev wrote:
I have a DList of structs, DataPoint, ordered by a struct field, time.
I'm trying to insert a new entry preserving order, so I'm trying to use
`until` to find the insertion point and `insertBefore` with the result.
struct DataPoint {
immutable ulong time;
ulong value;
}
void main() {
DList!DataPoint dataPoints;
void incrementAt(ulong time) {
auto dataPoint = until!(dp => dp.time >= time)(dataPoints);
if (dataPoint.time == time) {
++dataPoint.value;
} else {
dataPoints.insertBefore(dataPoint, DataPoint(time, 1));
}
}
}
But I'm getting:
/dlang/dmd/linux/bin64/../../src/phobos/std/algorithm/searching.d(4898):
Error: template instance `onlineapp.main.incrementAt.Until!(__lambda2,
DList!(DataPoint), void)` does not match template declaration
Until(alias pred, Range, Sentinel) if (isInputRange!Range)
onlineapp.d(14): Error: template instance
`onlineapp.main.incrementAt.until!((dp) => dp.time >= time,
DList!(DataPoint))` error instantiating
dataPoints itself isn't a range, you need to use dataPoints[]. Also
insertStable needs DList.Range, not Until!... one. You can do something
like this https://run.dlang.io/is/A2vZjW
Re: Shared with synchronized
On Sunday, March 3, 2019 5:07:39 PM MST r-const-dev via Digitalmars-d-learn wrote: > On Sunday, 3 March 2019 at 22:35:54 UTC, r-const-dev wrote: > > I'm trying to implement a thread safe class, guarding data > > access with synchronized and atomicOp. > > > > Inside the class I'm using non-shared fields, such as Nullable, > > but I guarantee the thread safety using synchronized. How can I > > tell the compiler to allow using non-shared fields/methods > > inside synchronized? > Found a solution, hope it is a recommended one: cast `this` to > non-shared and invoke an "unsafe" method. Inside everything is > allowed: That's basically what you have to do. shared makes most operations which are not atomic illegal (it really should make them _all_ illegal, but it doesn't currently), thereby protecting you from bugs related threading isssues. So, what you then typically need to do is protect the shared variable with a mutex and then cast away shared while the mutex is locked so that you can operate on the object as thread-local. It's then up to the programmer to ensure that no thread-local references to the shared object escape. So, when the mutex is released, all of the thread-local references should be gone. It can be a bit annoying, but it means that your code in general is protected from threading bugs, and the code that has to actually deal with the threading issues is segregated (similar to how @safe code doesn't have to worry about memory issues, and @trusted is then used to allow @system stuff to be done from @safe code, thereby segregating the code that needs to be verified for memory issues). - Jonathan M Davis
InsertBefore in DList of structs
I have a DList of structs, DataPoint, ordered by a struct field,
time. I'm trying to insert a new entry preserving order, so I'm
trying to use `until` to find the insertion point and
`insertBefore` with the result.
struct DataPoint {
immutable ulong time;
ulong value;
}
void main() {
DList!DataPoint dataPoints;
void incrementAt(ulong time) {
auto dataPoint = until!(dp => dp.time >=
time)(dataPoints);
if (dataPoint.time == time) {
++dataPoint.value;
} else {
dataPoints.insertBefore(dataPoint, DataPoint(time,
1));
}
}
}
But I'm getting:
/dlang/dmd/linux/bin64/../../src/phobos/std/algorithm/searching.d(4898): Error:
template instance `onlineapp.main.incrementAt.Until!(__lambda2,
DList!(DataPoint), void)` does not match template declaration Until(alias pred,
Range, Sentinel) if (isInputRange!Range)
onlineapp.d(14): Error: template instance
`onlineapp.main.incrementAt.until!((dp) => dp.time >= time,
DList!(DataPoint))` error instantiating
