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
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
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
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
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
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
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
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
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
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.
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
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 @
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
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
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
IMO need more explanations about precise-GC and cases where
behavior of precise and conservative same and differs
/* 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)
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
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
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
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
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() {
22 matches
Mail list logo
