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. What do you mean by "doesn't add"? ubyte[] slice = pos < imageData.length ? imageData[pos..(pos + pitch)] : imageData[pos..$]; This can't possibly work. You slice past the end of array.
Re: InsertBefore in DList of structs
On 05.03.2019 2:01, r-const-dev wrote: 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. dataPoints is an aggregate type variable, not a range and slice operator opSlice/[] returns a range of this aggregate type. I have no appropriate links unfortunately but these can be useful https://dlang.org/phobos/std_container_dlist.html#.DList.opSlice - this operator returns a range https://dlang.org/phobos/std_container_dlist.html#.DList.Range - this is range that allows to iterate over DList elements http://ddili.org/ders/d.en/ranges.html - intro to ranges Find does the job! What's the difference between find and until? `find` returns a range that starts from the key `until` returns a range of all elements before the key https://run.dlang.io/is/1kpOUx P.S. `findSplit` returns three ranges, first one contains all elements before the key like `until`, second range contains all elements that are equal to the key and third range contains the rest
Re: InsertBefore in DList of structs
On Tuesday, 5 March 2019 at 08:39:56 UTC, drug wrote: On 05.03.2019 2:01, r-const-dev wrote: [...] dataPoints is an aggregate type variable, not a range and slice operator opSlice/[] returns a range of this aggregate type. I have no appropriate links unfortunately but these can be useful https://dlang.org/phobos/std_container_dlist.html#.DList.opSlice - this operator returns a range https://dlang.org/phobos/std_container_dlist.html#.DList.Range - this is range that allows to iterate over DList elements http://ddili.org/ders/d.en/ranges.html - intro to ranges [...] `find` returns a range that starts from the key `until` returns a range of all elements before the key https://run.dlang.io/is/1kpOUx [...] Thank you for clarifications, it makes sense to me now.
Re: DUB / compiling same source and config to different windows subsystems in 32/64 bit
On Tuesday, 5 March 2019 at 05:03:42 UTC, Mike Parker wrote: 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. That's right, it is not part of the dub itself, however it is directly related to it(both compiler and writing that dub platform/config specific project parts), and that adds value on usability. Such info is invaluable addition, just put it in the extra section like "How-to's" or another similar cookbook recipe-like one. This will help users that are new to Windows(esp. advanced super duper *nix power users) to solve their problem instantly where this simple, easy to follow steps with a bit of explanation is placed in a proper place. Not to mention that there is definitely more such topics that are frequently asked but people forced to dig through forums and projects on github to gather that knowledge piece by piece.
Re: precise GC
On 04/03/2019 12:12, 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? > 2) precise-GC will NOT scan it at all. is it true? As Adam pointed out, this memory block is neither scanned by the default GC nor the precise GC because they don't contain any references. > > 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? No type information is generated for closures by the compiler, so these are always scanned conservatively. > > 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? associative arrays use allocations containing both key and value. These are scanned as if they are combined to a struct, so only actual pointers with the precise GC, semi-precisely (as Adam put it) with the default GC.
Re: Help with Regular Expressions (std.regex)
On Monday, 4 March 2019 at 18:57:34 UTC, dwdv wrote:
There is also std.file.slurp which makes this quite easy:
slurp!(int, int, int, int, int)("03.input", "#%d @ %d,%d:
%dx%d");
That's brilliant! This language just keeps putting a smile on my
face every time I learn something new like this!
Re: precise GC
On Tue, Mar 05, 2019 at 09:50:34PM +0100, Rainer Schuetze via Digitalmars-d-learn wrote: > On 04/03/2019 12:12, KnightMare wrote: [...] > > 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? > > No type information is generated for closures by the compiler, so > these are always scanned conservatively. [...] Just out of curiosity, how hard would it be for the compiler to emit type information for closures? Given the prevalence of the range-based idiom in D, I'd think this is a worthwhile area for GC improvements. T -- One Word to write them all, One Access to find them, One Excel to count them all, And thus to Windows bind them. -- Mike Champion
Re: precise GC
On 05/03/2019 22:30, H. S. Teoh wrote: > On Tue, Mar 05, 2019 at 09:50:34PM +0100, Rainer Schuetze via > Digitalmars-d-learn wrote: >> On 04/03/2019 12:12, KnightMare wrote: > [...] >>> 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? >> >> No type information is generated for closures by the compiler, so >> these are always scanned conservatively. > [...] > > Just out of curiosity, how hard would it be for the compiler to emit > type information for closures? Given the prevalence of the range-based > idiom in D, I'd think this is a worthwhile area for GC improvements. I tried that first when I added debug information for closures on Windows recently, but it didn't easily work out. I suspect it cannot be generated early in the front-end as closures might also change due to inlining and optimizations. Maybe even worse than the conservative scanning: if structs are moved into the closure, their destructors are never called, even if the closure is collected.
Re: default construction is disabled for type
public this() { }
Doesn't change anything...
Re: std.zlib odd behavior
On Tuesday, 5 March 2019 at 02:19:26 UTC, Adam D. Ruppe wrote: 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... Thanks, it seems I'll have to write my own solution for this, and I really dislike the way streaming compression works in C. I've spotted some other bugs regarding my PNG implementation, but those were unrelated and didn't improve the compression issues.
Re: default construction is disabled for type
So I find out the issue: it was due a struct member of the class having @disable this();
default construction is disabled for type
What's that error? below code used to work fine, now it gives
this compiler error.
class Keyword
{
this(string value, Token type)
{
this.value = value;
this.type = type;
}
string value;
Token type;
Keyword next;
}
static Keyword[] hashtab = new Keyword[hashtab_siz];
