InsertBefore in DList of structs

2019-03-04 Thread r-const-dev via Digitalmars-d-learn
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() {

Re: Shared with synchronized

2019-03-04 Thread Jonathan M Davis via Digitalmars-d-learn
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

Re: precise GC

2019-03-04 Thread KnightMare via Digitalmars-d-learn
/* 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)

Re: InsertBefore in DList of structs

2019-03-04 Thread drug via Digitalmars-d-learn
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

Re: InsertBefore in DList of structs

2019-03-04 Thread drug via Digitalmars-d-learn
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

precise GC

2019-03-04 Thread KnightMare via Digitalmars-d-learn
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

Re: precise GC

2019-03-04 Thread KnightMare via Digitalmars-d-learn
IMO need more explanations about precise-GC and cases where behavior of precise and conservative same and differs

Re: precise GC

2019-03-04 Thread Adam D. Ruppe via Digitalmars-d-learn
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

DUB / compiling same source and config to different windows subsystems in 32/64 bit

2019-03-04 Thread Robert M. Münch via Digitalmars-d-learn
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

Re: InsertBefore in DList of structs

2019-03-04 Thread r-const-dev via Digitalmars-d-learn
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

Re: std.zlib odd behavior

2019-03-04 Thread Adam D. Ruppe via Digitalmars-d-learn
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

Re: DUB / compiling same source and config to different windows subsystems in 32/64 bit

2019-03-04 Thread Mike Parker via Digitalmars-d-learn
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

Re: DUB / compiling same source and config to different windows subsystems in 32/64 bit

2019-03-04 Thread Mike Parker via Digitalmars-d-learn
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

Re: DUB / compiling same source and config to different windows subsystems in 32/64 bit

2019-03-04 Thread evilrat via Digitalmars-d-learn
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

Re: DUB / compiling same source and config to different windows subsystems in 32/64 bit

2019-03-04 Thread Mike Parker via Digitalmars-d-learn
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

Re: DUB / compiling same source and config to different windows subsystems in 32/64 bit

2019-03-04 Thread Mike Parker via Digitalmars-d-learn
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

std.zlib odd behavior

2019-03-04 Thread solidstate1991 via Digitalmars-d-learn
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: DUB / compiling same source and config to different windows subsystems in 32/64 bit

2019-03-04 Thread Mike Parker via Digitalmars-d-learn
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

Re: DUB / compiling same source and config to different windows subsystems in 32/64 bit

2019-03-04 Thread evilrat via Digitalmars-d-learn
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

Re: DUB / compiling same source and config to different windows subsystems in 32/64 bit

2019-03-04 Thread Robert M. Münch via Digitalmars-d-learn
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

Re: Help with Regular Expressions (std.regex)

2019-03-04 Thread Samir via Digitalmars-d-learn
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

Re: Help with Regular Expressions (std.regex)

2019-03-04 Thread dwdv via Digitalmars-d-learn
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 @