Re: GC page and block metadata storage

[thedeemon via Digitalmars-d-learn]

On Tuesday, 2 October 2018 at 07:25:36 UTC, Per Nordlöw wrote:
Should a new fresh GC for D store block metadata inside the 
page itself or in a (pool) structure separate from the page?


I'm already aware of Dmitry's suggestion to separate value-type 
pools from pools of types possibly containing addresses.


I guess you would want to scan the metadata without thrashing all 
the pages. Keeping metadata together compactly is good for cache. 
Of course it depends on how exactly it's going to be used.

Re: How to proceed with learning to code Windows desktop applications?

[thedeemon via Digitalmars-d-learn]

On Tuesday, 30 January 2018 at 18:52:18 UTC, I Lindström wrote:
I've been looking into C# and VS2017 today along with VisualD. 
Reading through all this it looks like the simplest path is to 
learn C# and VS and go from there. I've found a pile of courses 
on LinkedIn that seem to build up to what I need. What makes me 
sad is that I have to drop D for at least the time being.


The good news is after you learn the basics of WinForms in C#, 
you can take DFL and have basically all the same code in D. DFL 
(D Forms Library) is a pure D thin wrapper around WinAPI that 
looks like an identical twin of WinForms. There was even some 
visual forms builder for it. And then, once you're familiar with 
this kind of GUI lib, it's not hard to learn DlangUI or GtkD or 
some other libraries mentioned above.

D does have GUI libs, just not books and courses about them.

Re: How to proceed with learning to code Windows desktop applications?

[thedeemon via Digitalmars-d-learn]

On Tuesday, 30 January 2018 at 03:07:38 UTC, rikki cattermole 
wrote:


But since Windows is the only platform mentioned or desired 
for, everything you need is in WinAPI!


It's like saying "everything you need is assembly language" when 
talking about languages and compilers. Pure WinAPI is a cruel 
advice for a novice.

Re: parallelism

[thedeemon via Digitalmars-d-learn]

On Saturday, 27 January 2018 at 20:49:43 UTC, Arun Chandrasekaran 
wrote:



Error: must use labeled break within static foreach


Just follow the compiler suggestion:

void main(string[] args) {
auto op = Operation.a;
foreach (_; 0 .. args.length) {
ops: final switch (op) {
static foreach(e; EnumMembers!Operation) {
case e:
mixin(e.to!string ~ "();");
break ops;
}
}
}
}

Here 'ops' is a label that we use to tell break what exactly it 
breaks.
But really I'm not sure why you want static foreach here, a 
simple foreach is fine, it gets unrolled statically here just 
like static one.

Re: parallelism

[thedeemon via Digitalmars-d-learn]

On Saturday, 27 January 2018 at 11:19:37 UTC, Arun Chandrasekaran 
wrote:

Simplified test case that still errors:


You got really close here. Here's a working version:

enum Operation {
a,
b
}

import std.traits, std.conv, std.stdio;

void main(string[] args) {
auto op = Operation.a;
foreach (_; 0 .. args.length) {
final switch (op) {
foreach(e; EnumMembers!Operation) {
case e:
mixin(e.to!string ~ "();");
break;
}
}
}
}

void a() { writeln("A!"); }
void b() { writeln("B!"); }

Re: Strange compiler error. Whose bug is that?

[thedeemon via Digitalmars-d-learn]

On Friday, 26 January 2018 at 21:17:14 UTC, Oleksii Skidan wrote:


struct Game {
Triangle player = new Triangle;


When you initialize a struct member like this, compiler tries to 
calculate the initial value and remember it as data, so each time 
such struct is constructed the data is just copied. Which means 
this data must be computable at compile time, however your 
Triangle constructor is using pointers to some values, these 
pointers will only be known at run time. This means you need to 
construct Triangles at run time, in Game constructor, not at 
compile time in this initialization syntax.

Re: getting member functions of a struct and Error: identifier expected following ., not this

[thedeemon via Digitalmars-d-learn]

On Tuesday, 23 January 2018 at 00:00:38 UTC, aliak wrote:
Hi, I'm trying to get a list of only member functions of a 
struct. I've found that if you do not declare a struct as 
static inside a scope, then there's a hidden "this" member as 
part of the struct. Can someone explain the logic there?


The struct defined inside a scope can mention variables defined 
in that scope (e.g. use them in its methods), so it needs a 
pointer to the place where those closed variables live. That's 
the main difference between such struct and a static one that 
cannot use those scope vars. I guess you're seeing that pointer 
as additional member.



As for static foreach, when you write a simple foreach over some 
compile-time tuple (like in this case), it's unrolled at compile 
time similarly to "static foreach", the main difference is 
whether it creates a sub-scope for the loop body or not. 
"foreach" creates one, "static foreach" doesn't.

Re: Get largest heap object at runtime? ...tracking the leak

[thedeemon via Digitalmars-d-learn]

On Monday, 22 January 2018 at 16:37:19 UTC, Andres Clari wrote:
All threads withing a process share the same heap, so whatever 
one thread allocated in that heap is not freed or reclaimed 
automatically when thread dies, it stays in the heap.


Well the destructor of some Json objects and strings should be 
called when the thread exits tho.


If some objects were on the stack of the thread proc, their 
destructors run, yes, as usual for leaving a scope. Strings don't 
have destructors, afaik.
Thread-local storage gets cleaned up too. But everything that 
lives in heap, stays there, until GC finds them. Objects in heap 
don't have any information on them  which thread they belong to.

Re: Get largest heap object at runtime? ...tracking the leak

[thedeemon via Digitalmars-d-learn]

On Monday, 22 January 2018 at 06:48:00 UTC, Andres Clari wrote:
Not sure why "spawn" would leak like that tho. I would assume 
that once the thread exits, it would get destroyed and it's 
resources reclaimed, specially when I have calls to "GC.collect 
and GC.minimize".


All threads withing a process share the same heap, so whatever 
one thread allocated in that heap is not freed or reclaimed 
automatically when thread dies, it stays in the heap.

Re: class initialization

[thedeemon via Digitalmars-d-learn]

On Tuesday, 16 January 2018 at 03:23:20 UTC, Marc wrote:


But can't figure out if D does have that for classes.


I believe there's no such thing for classes, you're supposed to 
use constructors. Class objects are in many aspects more abstract 
things than POD structs: instead of accessing their data directly 
there are constructors, virtual (by default) methods, and there 
is inheritance and interfaces which require the accesses to be 
rather abstract and indirect to work well.

Re: Interfacing with webcam

[thedeemon via Digitalmars-d-learn]

On Thursday, 11 January 2018 at 17:02:58 UTC, Amorphorious wrote:

Looking for something similar. I simply need to show the video 
of a camera and be able to do to basics like rotation, crop, 
etc.


On which platform? On Windows I've successfully used DirectShow, 
I can show an example of working with a camera.

Re: Storing struct in a array

[thedeemon via Digitalmars-d-learn]

On Tuesday, 9 January 2018 at 18:09:58 UTC, Vino wrote:
 It is possible to store struct in a array ans use the same 
in csvReader


Sure, you can just pass the type of your struct to csvReader:



Array!T1 T1s;
reader(fName, T1s); // pass the array Type as a function 
parameter


First you write a template function that takes an array of some 
generic type and fills it with records from CSV file:


void readData(DataType)(string fname, ref Array!DataType arr) {
foreach (record; fname.readText.csvReader!DataType('\t')) {
arr ~= record;
}
}

Then you can use it in your main program with different types:

struct S1 { string name; string value; int other; }
struct S2 { int a; string b; }

void main () {
...
if (someCondition) {
Array!S1 arr1;
readData("data1.csv", arr1);
} else {
Array!S2 arr2;
readData("data2.csv", arr2);
}
}

A little advice. Kindly pause and spend an evening reading this 
book:

http://ddili.org/ders/d.en/

Currently your code pieces look like a soup produced by someone 
who still confuses variables and types, and lacks basic 
programming skills. Read the book, don't rush with writing broken 
code.

Re: Storing struct in a array

[thedeemon via Digitalmars-d-learn]

On Tuesday, 9 January 2018 at 13:49:41 UTC, Vino wrote:

Hi All,

 It is possible to store struct in a array ans use the same in 
csvReader


Sure, you can just pass the type of your struct to csvReader:

struct Layout { string name; int value; double other; }

auto readArrayOfStructs(string fname) {
Array!Layout res;
foreach(record; fname.readText.csvReader!Layout('\t')) {
res ~= record;
}
return res;
}

Re: Error: variable i cannot be read at compile time

[thedeemon via Digitalmars-d-learn]

On Monday, 8 January 2018 at 07:37:31 UTC, Vino wrote:
 I tried to manipulate the writeln's as below but the output 
is not as expected as it prints the data in row wise, where 
as we need it in column wise.


Ah, sorry, now I think I get it.
Your problem is you get output like ["a","b","c"] and instead you 
want

a
b
c

right?

Well, I think you know how to write a loop and output one item 
per line inside this loop.

Re: Error: variable i cannot be read at compile time

[thedeemon via Digitalmars-d-learn]

On Monday, 8 January 2018 at 07:37:31 UTC, Vino wrote:
 I tried to manipulate the writeln's as below but the output 
is not as expected as it prints the data in row wise, where 
as we need it in column wise.

...
Using the function countUntil find the keys for each of the 
column and store the result of each column in another files.


So, you don't need row wise output.

Re: Error: variable i cannot be read at compile time

[thedeemon via Digitalmars-d-learn]

On Sunday, 7 January 2018 at 17:30:26 UTC, Vino wrote:

 I tried to manipulate the writeln's as below but the output is 
not as expected as it prints the data in row wise, where as we 
need it in column wise.


You've said before you need 6 different files, not some tables.
Also, after the "compression" data columns will have different 
length. How exactly do you want to combine them into a table?

Re: Error: variable i cannot be read at compile time

[thedeemon via Digitalmars-d-learn]

On Sunday, 7 January 2018 at 12:59:10 UTC, Vino wrote:
 Just noticed that the output writes the data and key as 2 
values , but the requirnment is to write to six files, e.g


That's the part you can implement yourself. Just replace those 
writelns with writing to corresponding files.

Re: Error: variable i cannot be read at compile time

[thedeemon via Digitalmars-d-learn]

On Saturday, 6 January 2018 at 06:47:33 UTC, Vino wrote:

On Friday, 5 January 2018 at 18:00:34 UTC, thedeemon wrote:

On Friday, 5 January 2018 at 17:59:32 UTC, thedeemon wrote:
Tuple!( staticMap!(Arr, ColumnTypes) ) res; // array of 
tuples


Sorry, I meant tuple of arrays, of course.


Hi Deemon,

 Thank you very much, I tested your code, initially the code 
did not produce the expected output, and found an issue in the 
the key line of code as below, after updating the output was as 
expected. Can you please let me know how to change the array 
from standard array to container array.


Here's a version with Array, it's very similar:

import std.algorithm: countUntil, joiner, sort, uniq, map;
import std.csv: csvReader;
import std.stdio: File, writeln;
import std.typecons: Tuple, tuple;
import std.meta;
import std.file : readText;
import std.container.array;

alias ColumnTypes = AliasSeq!(string, string, int);

auto readData(string fname) { // returns tuple of Arrays
Tuple!( staticMap!(Array, ColumnTypes) ) res;
foreach (record; 
fname.readText.csvReader!(Tuple!ColumnTypes)('\t'))

foreach(i, T; ColumnTypes)
res[i].insert(record[i]);
return res;
}

auto compress(T)(ref Array!T col) {
auto vals = Array!T( sort(col.dup[]).uniq );
auto ks = Array!ptrdiff_t( col[].map!(v => 
vals[].countUntil(v)) );

return tuple(vals, ks);
}

void main() {
auto columns = readData("data.csv");
foreach(i, ColT; ColumnTypes) {
auto vk = compress(columns[i]);
writeln(vk[0][]); //output data,   you can write files 
here

writeln(vk[1][]); //output indices
}
}

Re: Error: variable i cannot be read at compile time

[thedeemon via Digitalmars-d-learn]

On Friday, 5 January 2018 at 17:59:32 UTC, thedeemon wrote:
Tuple!( staticMap!(Arr, ColumnTypes) ) res; // array of 
tuples


Sorry, I meant tuple of arrays, of course.

Re: Error: variable i cannot be read at compile time

[thedeemon via Digitalmars-d-learn]

On Friday, 5 January 2018 at 17:50:13 UTC, thedeemon wrote:
Here's my version of solution. I've used ordinary arrays 
instead of std.container.array, since the data itself is in 
GC'ed heap anyway.
I used csv file separated by tabs, so told csvReader to use 
'\t' for delimiter.


And since lines of the file are copied to heap anyway, it's 
easier to skip unnecessary line splitting and joining and do the 
reading simpler:


import std.file : readText;

auto readData(string fname) {
Tuple!( staticMap!(Arr, ColumnTypes) ) res; // array of tuples
foreach (record; 
fname.readText.csvReader!(Tuple!ColumnTypes)('\t'))

foreach(i, T; ColumnTypes)
res[i] ~= record[i];
return res;
}

Re: Error: variable i cannot be read at compile time

[thedeemon via Digitalmars-d-learn]

On Friday, 5 January 2018 at 13:09:25 UTC, Vino wrote:
Sorry, I'm asking what problem are you solving, what the 
program should do, what is its idea. Not what code you have 
written.


Hi,

I am trying to implement data dictionary compression, and below 
is the function of the program,


Function read:
This function read a csv file which contains 3 column as and 
stores the value of each column in an array Col1: Array1 
(Ucol1), Col2: Array2 (Ucol2), Col3: Array3(Ucol3) and returns 
the data.


CSV file content:
Miller  America 23
JohnIndia   42
Baker   Australia   21
Zsuwalski   Japan   45
Baker   America 45
Miller  India   23

Function Main
This function receives the data from the function read.
Creates an array based of the function return type – ( 
typeof(read()[i]) Data );
Sorts the data and removes the duplicates and stores the data 
in the above array.
Then using “countUntil” function we can accomplish the data 
dictionary compression.


Thank you for the explanation, this is a nice little task.
Here's my version of solution. I've used ordinary arrays instead 
of std.container.array, since the data itself is in GC'ed heap 
anyway.
I used csv file separated by tabs, so told csvReader to use '\t' 
for delimiter.


import std.algorithm: countUntil, joiner, sort, uniq, map;
import std.csv: csvReader;
import std.stdio: File, writeln;
import std.typecons: Tuple, tuple;
import std.meta;
import std.array : array;

//we know types of columns, so let's state them once
alias ColumnTypes = AliasSeq!(string, string, int);
alias Arr(T) = T[];

auto readData() {
auto file = File("data.csv", "r");
Tuple!( staticMap!(Arr, ColumnTypes) ) res; // tuple of arrays
foreach (record; 
file.byLineCopy.joiner("\n").csvReader!(Tuple!ColumnTypes)('\t'))

foreach(i, T; ColumnTypes)
res[i] ~= record[i]; // here res[i] can have 
different types

return res;
}

//compress a single column
auto compress(T)(T[] col) {
T[] vals = sort(col.dup[]).uniq.array;
auto ks = col.map!(v => col.countUntil(v)).array;
return tuple(vals, ks);
}

void main() {
auto columns = readData();
foreach(i, ColT; ColumnTypes) {
// here the data can have different type for different i
auto vk = compress(columns[i]);
writeln(vk[0][]); //output data,   you can write files 
here

writeln(vk[1][]); //output indices
}
}

Re: Error: variable i cannot be read at compile time

[thedeemon via Digitalmars-d-learn]

On Friday, 5 January 2018 at 12:40:41 UTC, Vino wrote:

What exactly are you trying to do in Master()?

  Please find the full code,


Sorry, I'm asking what problem are you solving, what the program 
should do, what is its idea. Not what code you have written.

Re: I want to transmit the class name and the member name in the method

[thedeemon via Digitalmars-d-learn]

On Friday, 5 January 2018 at 07:40:14 UTC, Brian wrote:

I think code style like:
db.select(User).where(email.like("*@hotmail.com")).limit(10);


You need to read about templates in D, here's a good guide:
https://github.com/PhilippeSigaud/D-templates-tutorial

Basically you can write a function like
auto select(Class, string fieldName)(Class value) {
 ...

and call it later as
select!(User, "name")(u);

Here User and "name" are compile-time arguments, you can pass 
there types, values and more exotic stuff like other templates.


And inside the function you can use
__traits(getMember, u, fieldName)
to get field by its name from the passed value.
See: https://dlang.org/spec/traits.html

Re: Error: variable i cannot be read at compile time

[thedeemon via Digitalmars-d-learn]

On Friday, 5 January 2018 at 09:09:00 UTC, Vino wrote:
  Thank you very much, can you suggest the best way around this 
issue.


What exactly are you trying to do in Master()? The code seems 
very broken. Each time you write read[i] is will call read() and 
read the whole file, you're going to read the file so many times 
in this code. I don't think that was the intent.

Re: Gc/D_runtime prevents dangling pointers?

[thedeemon via Digitalmars-d-learn]

On Thursday, 4 January 2018 at 11:05:25 UTC, tipdbmp wrote:

What is your definition of a dangling pointer?
A pointer pointing to freed memory, which presumably '&a[0]' 
should be because it reallocates.


It allocates a larger array, but the old version is not freed up 
front. Right because there might be live references to the old 
data. Your pointer is such live reference. So while this pointer 
references that old version of the array, it's not freed. Only 
after no references are left the GC will make it free (and only 
when next GC cycle happens, not immediately).


It seems that the '~=' operator "knows" that there's a 
reference to 'a's old memory and it keeps it around instead of 
freeing it.


It's just not its job to free that memory. That memory is freed 
later by GC, when it's safe to do so.

Re: Gc/D_runtime prevents dangling pointers?

[thedeemon via Digitalmars-d-learn]

On Wednesday, 3 January 2018 at 22:22:06 UTC, tipdbmp wrote:


x doesn't seem to be a dangling pointer, how come?


What is your definition of a dangling pointer?
In the shown example we have a reference to a piece of memory 
containing 'x', so this memory is not freed, it's used by the 
program. So when you access it via the pointer you get that 'x' 
value, everything's ok.
The comment also shows misunderstanding: when you allocate a new 
array you don't reuse the old memory, especially when it's still 
used, as it is here. This is how all GC'ed languages work: as 
long as you have live references to data, it's not freed and not 
reused. This makes all those references valid and not "dangling".

Re: how to localize console and GUI apps in Windows

[thedeemon via Digitalmars-d-learn]

On Wednesday, 3 January 2018 at 09:11:32 UTC, thedeemon wrote:
you need to use TextOutW that accepts 16-bit Unicode, so just 
convert your UTF-8 D strings to 16-bit Unicode wstrings, there 
are appropriate conversion functions in Phobos.


Some details:
import std.utf : toUTF16z;
...
string s = "привет";
TextOutW(s.toUTF16z);

Re: how to localize console and GUI apps in Windows

[thedeemon via Digitalmars-d-learn]

On Wednesday, 3 January 2018 at 06:42:42 UTC, Andrei wrote:

AFAIK, Windows GUI have no ANSI/OEM problem.
You can use Unicode.


Partly, yes. Just for a test I tried to "russify" the example 
Windows GUI program that comes with D installation pack 
(samples\d\winsamp.d). Window captions, button captions, 
message box texts written in UTF8 all shows fine. But direct 
text output functions CreateFont()/TextOut() render all 
Cyrillic from UTF8 strings into garbage.


Windows API contains two sets of functions: those whose names end 
with A (meaning ANSI), the other where names end with W (wide 
characters, meaning Unicode). The sample uses TextOutA, this 
function that expects 8-bit encoding. Properly, you need to use 
TextOutW that accepts 16-bit Unicode, so just convert your UTF-8 
D strings to 16-bit Unicode wstrings, there are appropriate 
conversion functions in Phobos.

Re: structs inheriting from and implementing interfaces

[thedeemon via Digitalmars-d-learn]

On Friday, 29 December 2017 at 12:03:59 UTC, Mike Franklin wrote:
Is that simply because it hasn't been implemented or suggested 
yet for D, or was there a deliberate design decision?


It's a design decision.
Look carefully at structs vs. classes here:
https://dlang.org/spec/struct.html

There is no virtual methods table (VMT) for structs, no 
inheritance. Structs have value semantics. A variable with a type 
of some interface implies it's a pointer, with reference 
semantics and a VMT.

Re: Write native GUI applications for Windows

[thedeemon via Digitalmars-d-learn]

On Monday, 18 December 2017 at 07:55:25 UTC, Andrey wrote:
I have a question about creating native GUI applications for 
Windows 7 or/and Windows 10.
And what about D? What should I do? Make some kind of wrapper 
above C WinApi?


I've used DFL which is a thin wrapper over WinAPI and its native 
widgets. Links statically, no dependencies, no code bloat. 
Examples:

http://www.infognition.com/VideoEnhancer/autovideoenhance.png
http://www.infognition.com/blogsort/blogsort500.jpg

https://bitbucket.org/thedeemon/autovideoenhance
https://bitbucket.org/infognition/bsort

There are several forks of DFL in github, I'm not sure which one 
is the most fresh today. I think I used this one:

https://github.com/Rayerd/dfl

Re: GC: Understanding potential sources of false pointers

[thedeemon via Digitalmars-d-learn]

On Thursday, 20 April 2017 at 02:27:37 UTC, Nick Sabalausky 
(Abscissa) wrote:

According to :

"Registers, the stack, and any other memory locations added 
through the GC.addRange function are always scanned 
conservatively."


1. Can that be safely assumed to be a canonical list of all 
possible sources of false pointers?


2. What about memory allocated through language constructs such 
as "new", append ("~"/"~="), closures, or any others I may be 
forgetting? Is this memory always/never/sometimes set to 
NO_SCAN? (I assume not "always", as that would be silly.) If 
"sometimes", what are the conditions?


A couple specific examples:

3. Are there any situations where a (for example) int[] or 
long[] that is stored on the GC heap could lead to false 
pointers?


4. Same question as #3, but if it's an array of structs, and 
the struct type contains no members that are statically-typed 
as pointers.


1. No, that's not the full list. Closures are indeed an important 
source of GC-allocated objects with pointers and often false 
pointers, for example.


2. With "new" compiler decides by the type whether the data may 
contain pointers, so arrays of numbers or arrays of structs with 
no pointers inside will be allocated as NO_SCAN.


3-4. As long as the compiler is sure about absence of pointers in 
allocated type, you're safe, I don't see a way for that data to 
become a source of false pointers (unless you fool the compiler 
with casts).

Re: List Comprehension equivalent

[thedeemon via Digitalmars-d-learn]

On Saturday, 18 March 2017 at 11:09:34 UTC, Russel Winder wrote:

Is this foldr or foldl' ?


It's a left fold of course, having foldr by default in eager 
language would be awkward.

Re: Sorting Assosiative Arrays and Finding Largest Common Substring

[thedeemon via Digitalmars-d-learn]

On Thursday, 16 March 2017 at 16:02:13 UTC, helxi wrote:
I was looking for ways to find the largest common substring 
between two given substrings and have learnt

1. .length is of type ulong


Only when compiling to 64 bits. On 32-bit target it's different.


2. writing string[int] will not give me a sorted array


Sure, it's just a hash table, its key type may not even have any 
ordering, not be comparable.



What's the trick to sort the associative array by their keys?


If you need the max key value you can just write
auto k = commons.byKey.maxElement;
so that commons[k] will give you your longest string.
(byKey returns a range of keys, maxElement is a function from 
std.algorithm)


You can use .keys property to get an array of keys of associative 
array so you can sort them if you need.


Btw in your case you don't need an array if you're really 
interested in longest substring, just have a single string 
variable and update it when current candidate is longer.

Re: scope(~this)

[thedeemon via Digitalmars-d-learn]

On Wednesday, 15 March 2017 at 12:56:10 UTC, Inquie wrote:
If it is trivial, can you write up a quick solution. I don't 
see how to accomplish it easily.


Here it is, source and output:
https://dpaste.dzfl.pl/bbf162529c6c

Re: scope(~this)

[thedeemon via Digitalmars-d-learn]

On Tuesday, 14 March 2017 at 14:35:11 UTC, Inquie wrote:
There is really no any arrays to keep track of or anything like 
that matter you stated.

...
3 steps:
...
3. The compiler calls all the delegates on destruction.


Here you are. "All the delegates" - where are they stored? This 
is the array of delegates I was talking about.


In a library solution you don't even need to think about the 
string mixins and variables copying. Just make a method that 
takes a delegate. Then call it like this:

scopeThis({ dealloc(x); });
The compiler will create the delegate for you and store x in the 
heap in the first place. In scopeThis() you just add the passed 
delegate to an array of other delegates, then in destructor call 
them. Seems rather trivial, I don't see a need for a language 
feature that affects all the classes and objects.

Re: scope(~this)

[thedeemon via Digitalmars-d-learn]

On Monday, 13 March 2017 at 14:28:01 UTC, Inquie wrote:

On Monday, 13 March 2017 at 05:18:18 UTC, Nicholas Wilson wrote:

On Sunday, 12 March 2017 at 21:38:44 UTC, Inquie wrote:
Is there any easy way to create a scope for termination of 
the object?


I have a template method that takes a type and allocates and 
deallocates based on that type.


class bar
{
   void foo(T)()
   {
  T x;
  alloc(x);
  scope(~this) dealloc(x); // hypothetical that wraps the 
statement in a lambda and deallocates in the destructor


  ... x must stay allocated until class instance 
termination(has to do with COM, can't release it in foo)

   }

}



I think the feature you're asking for is too complicated/involved 
for a language feature. Because it means there must be some 
implicit array in each object of your 'bar' class that holds some 
number of closures that will be executed in destructor. This 
affects object's memory layout and raises questions of allocating 
memory for those closures and since those closures will have 
pointers to some data (like 'x' here) it affects garbage 
collection. So there are a lot of things to be careful about and 
things that might affect other language features we haven't 
thought about yet. This is something quite big and something that 
affects a lot of code, not just a couple of classes you'll write 
in your one app. Probably it would be better to implement it as a 
library feature. Just make a base class having a method for 
registering such closures and calling them in destructor, and 
inherit from it or just embed it in your 'bar'.

Re: Recommend: IDE and GUI library

[thedeemon via Digitalmars-d-learn]

On Wednesday, 1 March 2017 at 23:44:47 UTC, XavierAP wrote:
Still I want to be able to be  able to work and debug from 
Visual Studio.


The way I did on Windows:
1) get dlangui via dub
2) go to its folder in AppData\roaming\dub\packages and edit 
dub.json:

 * find "minimal" configuration
 * add "USE_WIN32" to "versions-windows",
 * remove mentions of "derelict-sdl2" and "derelict-gl3" from 
"dependencies"

 * remove "ForceLogs" from "versions" (just to avoid logspamming)
3) run "dub build --build=release --config=minimal"
4) use the result .lib file from my VisualD project

This way no dependency on OpenGL which causes problems for you.

Re: Recommend: IDE and GUI library

[thedeemon via Digitalmars-d-learn]

On Wednesday, 1 March 2017 at 17:37:02 UTC, XavierAP wrote:
I'm trying now DlangUI on Visual D. I'm getting different 
errors from missing Derelict library dependencies...


If you're building your app with VisualD (as opposed to invoking 
dub externally), make sure you've set up import paths in project 
settings properly. Two paths must be there: one like

C:\Users\...\AppData\Roaming\dub\packages\dlangui-0.9.46\dlangui\src\
and the other like
C:\Users\...\AppData\Roaming\dub\packages\dlangui-0.9.46\dlangui\3rdparty\
and in linker tab of project settings make sure you link to the 
dlangui.lib you should have built beforehand.
Also, if you use "minimal" configuration of DLangUI (which I 
recommend) you can remove mentions of SDL and GL from its 
dependencies in its dub.json, this way there are less things for 
compiler and VisualD to look for.

Re: Recommend: IDE and GUI library

[thedeemon via Digitalmars-d-learn]

On Friday, 24 February 2017 at 22:44:55 UTC, XavierAP wrote:
Hi I've looked at wiki.dlang.org/IDEs, and I see that Visual D 
is linked from dlang.org/download.html. Still I was looking for 
personal opinions and experiences beyond hard specs, I wonder 
if one of the IDEs is already dominant at least for each OS for 
any good reason.


I don't think there is anything dominant, different people tend 
to make different choices.
For me Visual-D served well for years, and for GUI on Windows 
I've used DFL successfully (quite nice lib, very WinForms-like, 
with a visual editor) and now mostly use DLangUI (on both Windows 
and Linux).

Re: Serializer class

[thedeemon via Digitalmars-d-learn]

On Wednesday, 22 February 2017 at 18:34:26 UTC, houdoux09 wrote:

void Read(T)(T value)
{
   foreach(i, mm; value.tupleof)
   {
  writeln(__traits(identifier, value.tupleof[i]), " = ", 
mm);


  if(isArray!(typeof(mm)))
  {
  Read(mm[0]); //Error
  }
   }
}


You need to use "static if" here inside foreach. Otherwise the 
body of your "if" gets compiled for all the different fields of 
"value" and of course fails for the fields that are not arrays.

Re: GC question

[thedeemon via Digitalmars-d-learn]

On Saturday, 4 February 2017 at 12:56:55 UTC, osa1 wrote:
- Automatic but conservative. Can leak at any time. You have to 
implement manual management (managed heaps) to avoid leaks. 
Leaks are hard to find as any heap value may be causing it.


By "managed heap" I just meant the GC heap, the one used by "new" 
operator.
Besides it, there are already other allocators and container 
libraries available, don't need to implement this stuff manually.



the worst of both worlds.


It may look so from a distance. But in my experience it's not 
that bad. In most software I did in D it did not matter really 
(it's either 64-bit or short lived programs) and the control D 
gives to choose how to deal with everything makes it all quite 
manageable, I can decide what to take from both worlds and hence 
pick the best, not the worst.

Re: GC question

[thedeemon via Digitalmars-d-learn]

On Wednesday, 1 February 2017 at 06:58:43 UTC, osa1 wrote:

I'm wondering what
are the implications of the fact that current GC is a 
Boehm-style conservative
GC rather than a precise one, I've never worked with a 
conservative GC before.
Are there any disallowed memory operations? Can I break things 
by not following
some unchecked rules etc. ? How often does it leak? Do I need 
to be careful

with some operations to avoid leaks?


Here's some practical perspective from someone who released a 
32-bit video processing app in D with thousands of users.
When developing with GC in D you need to keep in mind 3 key 
things:


1) The GC will treat some random stack data as possible pointers, 
and some of those false pointers will accidentally point to some 
places in the heap, so for any object in GC heap there is a 
probability that GC will think it's alive (used) even when it's 
not, and this probability is directly proportional to the size of 
your object.


2) Each GC iteration scans the whole GC heap, so the larger your 
managed heap, the slower it gets.


Main consequence of 1 and 2: don't store large objects (images, 
big file chunks etc.) in the GC heap, use other allocators for 
them. Leave GC heap just for the small litter. This way you 
practically don't leak and keep GC pauses short.


3) GC will call destructors (aka finalizers) for the objects that 
have them, and during the GC phase no allocations are allowed. 
Also, since you don't know in which order objects are collected, 
accessing other objects from a destructor is a bad idea, those 
objects might be collected already.


Main consequence of 3: don't do silly things in destructor (like 
throwing exceptions or doing other operations that might 
allocate), try avoiding using the destructors at all, if 
possible. They may be used to ensure you release your resources, 
but don't make it the primary and only way to release them, since 
some objects might leak and their destructors won't be called at 
all.


If you follow these principles, your app will be fine, it's not 
hard really.

Re: Thread will get garbage collected?

[thedeemon via Digitalmars-d-learn]

On Monday, 16 January 2017 at 22:08:56 UTC, JN wrote:

Am I correctly understanding, that after going out of scope, 
it's possible for GC to destroy my thread before the file 
finishes loading? How to prevent GC from destroying my thread 
before it finishes and make sure the file is loaded completely?


As far as I know, GC never kills threads.

Re: writeln and ~

[thedeemon via Digitalmars-d-learn]

On Saturday, 14 January 2017 at 17:42:05 UTC, Ignacious wrote:

writeln(x ~ " ok");


Just write writeln(x, " ok");
Any number of arguments, no unnecessary allocations.
Do you really need ~?

Re: Auto recursive function

[thedeemon via Digitalmars-d-learn]

On Wednesday, 11 January 2017 at 19:23:10 UTC, Razvan Nitu wrote:

Hi,

I am currently trying to create a function 
makeMultidimensionalArray which allocates memory for a 
multidimensional array.


You were very close to the answer:

auto makeMultidimensionalArray(int N, T, Allocator)(auto ref 
Allocator alloc, size_t[N] lengths)

{
static if (lengths.length == 1)
{
return makeArray!T(alloc, lengths[0]);
}
else
{
alias E = typeof(makeMultidimensionalArray!(N-1,T)(alloc, 
lengths[1..$]));

auto ret = makeArray!E(alloc, lengths[0]);
foreach (ref e; ret)
e = makeMultidimensionalArray!(N-1, T)(alloc, 
lengths[1..$]);

return ret;
}
}


The key point is that return type depends on length of "lengths" 
array (dimensionality), so if this length is only known at 
runtime this is a dependent type, something D lacks (you'll need 
Idris or Agda for those). In D return type must be known at 
compile time and hence the length of "lengths" must be a compile 
time argument. With such argument everything compiles smoothly.

Re: Impressed with Appender - Is there design/implementation description?

[thedeemon via Digitalmars-d-learn]

On Sunday, 4 December 2016 at 20:03:37 UTC, Jon Degenhardt wrote:
I've been using Appender quite a bit recently, typically when I 
need append-only arrays with variable and unknown final sizes. 
I had been prepared to write a custom data structure when I 
started using it with large amounts of data, but very nicely 
this has not surfaced as a need. Appender has held up quite 
well.


I haven't actually benchmarked it against competing data 
structures, nor have I studied the implementation. I'd be very 
interested in understanding the design and how it compares to 
other data structures. Are there any write-ups or articles 
describing it?


--Jon


It's rather simple, just take a look at its source code in 
std.array.
It's an ordinary linear array partially filled with your data. 
When your data fills it up, it gets resized to make more space. 
Just two interesting points:


1. When it needs to grow it uses a formula like k = 1 + 10 / 
log2(newsize) for the growth factor (but with a limit of k <= 2), 
which means up to 16 KB it doubles the size each time, then tries 
to grow by a factor of 2/3, then by lower and lower factors.


2. Up until 4 KB it reallocates when growing, but after 4 KB the 
array lives in a larger pool of memory where it can often grow a 
lot without reallocating, so in many scenarios where other 
allocations do not interfere, the data array of appender grows in 
place without copying any data, thanks to GC.extend() method.

Re: Memory allocation failed. Why?

[thedeemon via Digitalmars-d-learn]

On Sunday, 20 November 2016 at 17:47:50 UTC, MGW wrote:



core.exception.OutOfMemoryError@src\core\exception.d(693): 
Memory allocation failed



Simple program and error. Why?  Windows 7 (32) dmd 2.072.0


Making a 100 million bytes array by appending one byte at a time 
creates a lot of intermediate-size arrays. Ideally these should 
be garbage collected away but GC in D is not only slow but also 
leaky. In 32 bits if you have 1000 random int values on the stack 
or data segment, with uniform distribution, this is 1000 random 
locations in memory pinned and seen by GC as live, i.e. one per 4 
MB of address space. Which means if your array is 4 MB or larger 
it's almost doomed to be never collected by GC in this scenario. 
Your program creates a lot of large arrays and they don't get 
collected because of false pointers and not precise enough GC. 
Moral of the story: in 32 bits don't allocate anything big (1 MB 
or more) in GC heap, otherwise there are good chances it will 
create a memory leak. Use std.container.array  or something 
similar.

Re: how to debug memory errors

[thedeemon via Digitalmars-d-learn]

On Tuesday, 8 November 2016 at 05:36:22 UTC, Era Scarecrow wrote:

 Hmmm.. I had the impression that if something was referenced 
by another object, then it couldn't be collected,


Another *live* object, i.e. reachable from globals and stack.
If you have a big tree and it becomes unreachable (you only had a 
pointer to its root and you nulled it), then this whole tree 
becomes garbage, and its nodes and leafs will be collected in 
unpredictable order, with destructors being run in unpredictable 
order, even when these dead nodes reference each other.

Re: how to debug memory errors

[thedeemon via Digitalmars-d-learn]

On Monday, 7 November 2016 at 02:22:35 UTC, Steven Schveighoffer 
wrote:
OP: it's not legal to destroy or even access GC allocated 
members in a destructor. The GC may have already destroyed that 
data.


Isn't destroy() fine there? It doesn't call destructors for 
already destroyed objects, so I guess it should be safe. 
(assuming the destructors don't do any allocations)

Re: D code optimization

[thedeemon via Digitalmars-d-learn]

On Thursday, 22 September 2016 at 16:09:49 UTC, Sandu wrote:

const int n = 252;
double[] call = new double[n+1];
...
	//delete call; // since D is has a garbage collector, 
explicit deallocation of arrays is not necessary.


If you care about speed, better uncomment that `delete`. Without 
delete, when allocating this array 1 times you'll trigger GC 
multiple times without good reason to do so. With delete, the 
same memory shall be reused and no GC triggered, run time should 
be much better.

Re: Commit size and Page fault's very large for simple program

[thedeemon via Digitalmars-d-learn]

On Monday, 4 July 2016 at 11:56:14 UTC, Rene Zwanenburg wrote:

On Monday, 4 July 2016 at 11:42:40 UTC, Rene Zwanenburg wrote:

...


I forgot to mention:

If you're on Windows compilation defaults to 32 bit, false 
pointers can be a problem with D's current GC in 32 bit 
applications. This isn't an issue for the sample application 
though, since you're not putting random numbers in the 
allocated arrays.


It is an issue here. It doesn't matter what numbers are in the 
arrays, what matters is if some random values on stack look like 
pointers pointing inside those arrays, which often happens with 
large arrays.
Essentially it means in 32 bits we shouldn't GC-allocate anything 
larger than a few KBs, the larger the thing you allocate the more 
chances are it won't be collected due to false pointers on the 
stack and other data.

Re: Hooking into GC

[thedeemon via Digitalmars-d-learn]

On Wednesday, 29 June 2016 at 02:18:27 UTC, MMJones wrote:
I read somewhere that one can modify the D files from phobos 
and runtime to supply a stub for the GC. I would like to add 
some logging features to the GC.



You don't need to recompile anything, a stub can be installed 
from your program. See an example (which can do logging) here:

https://bitbucket.org/infognition/dstuff/src/97cef6d4a0438f9a9f4ff0d18f819262b8a74888/trackallocs.d?fileviewer=file-view-default

Re: Registration-free COM client

[thedeemon via Digitalmars-d-learn]

On Monday, 27 June 2016 at 21:17:52 UTC, Thalamus wrote:

Hi everyone,

I've succeeded in using D as a client for regular (registered) 
COM servers in the past, but in this case, I'm building the 
server as well. I would like to avoid registering it if 
possible so XCOPY-like deployment remains an option. Can a 
registration-free COM client be built in D? If so, how can the 
code be setup to consume the manifest file, or alternately, is 
there a way to just point D to the correct assembly directly in 
code?


To load load a COM object from a given file (DLL or AX) without 
having it registered, just load the file with CoLoadLibrary() and 
use its DllGetClassObject() function to get IClassFactory which 
will give you any kind of object in this library.
Here's how I do it (in my case the requested object has 
"IBaseFilter" COM interface):


IBaseFilter createDSFilterFromFile(GUID guid, string dir, string 
fname) {

auto curdir = getcwd();
scope(exit) chdir(curdir);
chdir(dir); // in case the lib depends on other dlls nearby

	auto hinst = CoLoadLibrary( cast(wchar*) buildPath(dir, 
fname).toUTF16z, TRUE);

enforce!COMException(hinst);

	auto fnGetClassObject = cast(LPFNGETCLASSOBJECT) 
GetProcAddress(hinst, "DllGetClassObject");

enforce!COMException(fnGetClassObject);

IClassFactory factory;
auto iid = IID_IClassFactory;
	fnGetClassObject(&guid, &iid, 
cast(void**)&factory).checkHR("fnGetClassObject failed");

enforce!COMException(factory);

IBaseFilter ibf;
	factory.CreateInstance(null, &IID_IBaseFilter, 
cast(void**)&ibf).checkHR("factory.CreateInstance");

return ibf;
}

Re: Accessing COM Objects

[thedeemon via Digitalmars-d-learn]

On Wednesday, 15 June 2016 at 21:06:01 UTC, Joerg Joergonson 
wrote:

Ok, I've tried things like uncommenting

	Document Open(BSTR Document, VARIANT As, VARIANT 
AsSmartObject);

void Load(BSTR Document);

/*[id(0x70537673)]*/ BSTR get_ScriptingVersion();
  /*[id(0x70464D4D)]*/ double get_FreeMemory();
  /*[id(0x76657273)]*/ BSTR get_Version();
and everything crashes with bad reference.
...
My thinking is that CoCreateinstance is suppose to give us a 
pointer to the interface so we can use it, if all this stuff is 
crashing does that mean the interface is invalid or not being 
assigned properly or is there far more to it than this?


First of all, you can't just comment/uncomment parts of COM 
interface descriptions. Each COM interface has some specific 
layout of its functions, and if you list them in wrong order or 
skip some of them the virtual methods table gets completely 
screwed up, so you think you call one method but end up calling 
another, because you intended to call method #12 and instead 
called method #4. COM interface definitions in D must match their 
definitions in IDL exactly. One omission of a method, one mistake 
in its type, and you're fucked.

Re: ARSD PNG memory usage

[thedeemon via Digitalmars-d-learn]

On Friday, 17 June 2016 at 01:51:41 UTC, Joerg Joergonson wrote:
Hi, so, do you have any idea why when I load an image with 
png.d it takes a ton of memory?


I've bumped into this previously. It allocates a lot of temporary 
arrays for decoded chunks of data, and I managed to reduce those 
allocations a bit, here's the version I used:

http://stuff.thedeemon.com/png.d
(last changed Oct 2014, so may need some tweaks today)

But most of allocations are really caused by using std.zlib. This 
thing creates tons of temporary arrays/slices and they are not 
collected well by the GC. To deal with that I had to use GC 
arenas for each PNG file I decode. This way all the junk created 
during PNG decoding is eliminated completely after the decoding 
ends. See gcarena module here:

https://bitbucket.org/infognition/dstuff
You may see Adam's PNG reader was really the source of motivation 
for it. ;)

Re: Accessing COM Objects

[thedeemon via Digitalmars-d-learn]

On Wednesday, 15 June 2016 at 07:01:30 UTC, Joerg Joergonson 
wrote:



It  seems idl2d from VD is not easily compilable?


I don't remember problems with that, anyway here's the binary I 
used:

http://stuff.thedeemon.com/idl2d.exe

Re: Accessing COM Objects

[thedeemon via Digitalmars-d-learn]

On Monday, 13 June 2016 at 17:38:41 UTC, Incognito wrote:

Cool. Oleview gives me the idl files. How to convert the idl 
files to d or possibly c?


There are ready tools idl2d:
https://github.com/dlang/visuald/tree/master/c2d

and tlb2idl:
https://github.com/dlang/visuald/tree/master/tools

I've used this idl2d and it works pretty well (although not 
perfect, sometimes manual editing still required).


Example of real-world DirectShow interfaces translated:
https://gist.github.com/thedeemon/46748f91afdbcf339f55da9b355a6b56

Would I just use them in place of IUnknown once I have the 
interface?


If you have the interface defined AND you know its IID, you can 
request it from CoCreateInstance and then use as ordinary D 
object.


You might want to look at this wrapper that takes most of COM 
machinery:

https://gist.github.com/thedeemon/3c2989b76004fafe9aa0

Then you just write almost as in C#, something like

  auto pGraph = ComPtr!IGraphBuilder(CLSID_FilterGraph, 
"pGraph").require;


  ComPtr!ICaptureGraphBuilder2 pBuilder = 
ComPtr!ICaptureGraphBuilder2(CLSID_CaptureGraphBuilder2).require;

  pBuilder.SetFiltergraph(pGraph);
  ...
  auto CLSID_NullRenderer = 
Guid!("C1F400A4-3F08-11D3-9F0B-006008039E37"); //qedit.dll
  auto pNullRendr = ComPtr!IBaseFilter(CLSID_NullRenderer, 
"nulrend");

  pGraph.AddFilter(pNullRendr, "Null Renderer"w.ptr);
  ...
  auto imf = ComPtr!IMediaFilter(pGraph);
  imf.SetSyncSource(null);

All the CreateInstance, QueryInterface, AddRef/Release etc. is 
taken care of. And even HRESULT return codes are automatically 
checked.

Re: Generation of AST for semantic rule checking

[thedeemon via Digitalmars-d-learn]

On Sunday, 22 May 2016 at 04:33:44 UTC, Chris Katko wrote:

Basically, I want compile-time enforcement of semantic rules.


So the question is: Is there a way to get LDC2 to generate AST 
or similar, and if not, any other way to go about this?


I think one popular approach to the task is to use linters / 
static analysis tools before compiling, as a build step or 
separately. There is this project:

https://github.com/Hackerpilot/Dscanner
that uses a D parser to get AST and applies different semantic 
checks, you could use that as a base and just add your own checks 
and conditions.

Re: .array changes the order

[thedeemon via Digitalmars-d-learn]

On Thursday, 12 May 2016 at 10:17:19 UTC, xtreak wrote:

Thanks a lot. Can you kindly elaborate a little more on 
File.byLine with an example of the scenario so that I don't get 
bitten by it. File.byLine.array works as expected for me. A 
little more explanation on the permutations will also be 
helpful since joiner.map!array converts the subranges to 
arrays, so does joiner work by mutating state if so how does it 
do.


With some ranges the value they return by .front is only valid 
until the next call to popFront(). For example, File.byLine() 
reuses its buffer so after popFront() is called the buffer 
contains different data and if you had references to the contents 
of previously returned value they become invalid. This is why 
byLineCopy() was added. In the same vein permutations() returns a 
range that has a mutable array of indices inside, which changes 
every time popFront() is called, and since every value returned 
by its .front refers to that indices array, if you collect such 
permutations they will all use the same array of indices and show 
the same order of elements, the same permutation.
Because of this mutable nature of some ranges it's important to 
understand in which order calls to .front and .popFront() happen. 
The array() function calls popFront on its input in  a loop, 
consuming the mutable ranges, while map() does not. So in

 r.map!f.array
function f will receive different valid values, before they get 
invalidated in the loop of array(). But if they contain 
references to something mutable, it makes sense to make copies 
before the thing they refer to mutates.

Re: .array changes the order

[thedeemon via Digitalmars-d-learn]

On Thursday, 12 May 2016 at 09:44:39 UTC, xtreak wrote:
I came across the issue where using .array after .joiner caused 
the changes to the output. The program is at 
https://dpaste.dzfl.pl/0885ba2eddb4 . I tried to debug through 
the output but I couldn't get the exact issue. It will be 
helpful if someone confirms this as a bug.


It's not a bug per se, just probably documentation being not 
clear enough. Essentially it's the same issue as with 
File.byLine: a range that mutates its state, so it's ok to 
consume lazily but if you just store references (as array() does) 
you get references to the same mutated value as result.


Quick fix:

  r.chunks(2).map!permutations.joiner.map!array.array.writeln;

i.e. copy each permutation to separate array before it's gone.

Re: DlangIDE Themes

[thedeemon via Digitalmars-d-learn]

On Thursday, 12 May 2016 at 09:17:24 UTC, Chris wrote:

They shouldn't be hardwired. Best would be to load them 
dynamically with their respective names encoded in the xml 
file. In this way people could add their own themes as they see 
fit. I wouldn't mind creating themes and adding them to 
DlangIDE as a humble contribution.


Don't forget that contents of all those files in resources.list 
is also "hardwired" into the executable, so there's not much 
difference between mentioning something in such list file and in 
the source code. Of course, dynamic loading would be a nice thing 
to do, in addition to what there is now.

Re: DlangIDE Themes

[thedeemon via Digitalmars-d-learn]

On Wednesday, 11 May 2016 at 12:55:13 UTC, Chris wrote:
Is there a way I can add my own themes? I've created a theme 
file and added it to views/resources.list


However, it doesn't show up. "Default" and "Dark" seem to be 
hardwired somewhere in the source code.


Indeed they are, just grep for "ide_theme_dark" and you'll find 
those two places (settings.d, idesettings.d).

Re: DlangUI translations

[thedeemon via Digitalmars-d-learn]

On Saturday, 23 April 2016 at 15:44:22 UTC, stunaep wrote:
I am wondering how to use other languages and how to NOT use 
other languages.


Did you see example1 from examples folder in dlangui? It has two 
languages and allows switching at runtime via menu.

Re: How do you use D to launch/open a window?

[thedeemon via Digitalmars-d-learn]

On Friday, 22 April 2016 at 21:13:31 UTC, anonymousuer wrote:
What code is needed to tell D to open a window? Thank you in 
advance.


import dlangui;
mixin APP_ENTRY_POINT;

extern (C) int UIAppMain(string[] args) {
Window window = Platform.instance.createWindow("Window 
caption", null);

window.mainWidget = parseML(q{
TextWidget {text: "hi!"}
});

window.show();
return Platform.instance.enterMessageLoop();
}

Re: Compiler or Interpreter or Hybrid

[thedeemon via Digitalmars-d-learn]

On Thursday, 21 April 2016 at 02:06:00 UTC, newB wrote:
How is D  implemented? (Compiler, Interpreter and Hybrid). Can 
you please explain why?


Generally D is a compiled language: you give the compiler some 
source code and it produces executable binary with native machine 
code. Then you can distribute and run this binary without having 
to have any source code.
However inside the compiler there is also an interpreter for most 
of D, it's used during the compilation to perform some 
compile-time computations and decisions, including ability to 
generate more D code that gets further interpreted or compiled.

Re: Something wrong with GC

[thedeemon via Digitalmars-d-learn]

On Tuesday, 22 March 2016 at 13:46:41 UTC, stunaep wrote:

So what am I do to?


Just learn more about available containers and their semantics. 
Maybe you don't need Array!T when there is a simple T[].
If you think you do need Array, then think about memory 
management: where are you going to allocate the data - in the GC 
heap or outside it. Depending on your answers there are different 
approaches. It's all solvable if you pause and think what exactly 
you're trying to do.

Re: Something wrong with GC

[thedeemon via Digitalmars-d-learn]

On Sunday, 20 March 2016 at 07:49:17 UTC, stunaep wrote:
The gc throws invalid memory errors if I use Arrays from 
std.container.


Those arrays are for RAII-style deterministic memory release, 
they shouldn't be freely mixed with GC-allocated things. What 
happens here is while initializing Array sees it got some GC-ed 
value type (strings), so it tells GC to look after those strings. 
When your program ends runtime does a GC cycle, finds your Test 
object, calls its destructor that calls Array destructor that 
tries to tell GC not to look at its data anymore. But during a GC 
cycle it's currently illegal to call such GC methods, so it 
throws an error.
Moral of this story: try not to store "managed" (collected by GC) 
types in Array and/or try not to have Arrays inside "managed" 
objects. If Test was a struct instead of a class, it would work 
fine.

Re: Can DUB --combined builds be faster?

[thedeemon via Digitalmars-d-learn]

On Monday, 14 March 2016 at 11:50:38 UTC, Rene Zwanenburg wrote:

When building in release mode the call to foo() gets inlined 
just fine without --combined.


How does it work? Is it because the source of foo() is visible to 
the compiler when producing the result?

Re: Use of GUID constants

[thedeemon via Digitalmars-d-learn]

On Thursday, 10 March 2016 at 15:48:14 UTC, Mike Parker wrote:
Personally I would just declare one immutable value in module 
scope and be done with it. It really just doesn't matter. 
Unless you're following some sort of style guide, personal 
preference rules the day. I don't know if Rainers has a special 
reason for what he did with the Visual D code or if it was 
personal preference.


There is one good reason for doing it VisualD way.
It defines and uses smart pointers ComPtr(ISomething) where you 
can just write


auto x = ComPtr!ISomeInterface(someObject);

and if someObject has a different COM type this constructor will 
QueryInterface() for the proper interface, and to do this it 
needs to know its IID, so a common way to get IID knowing just an 
interface type is really helpful.

Re: GC scan for pointers

[thedeemon via Digitalmars-d-learn]

On Wednesday, 9 March 2016 at 15:14:02 UTC, Gerald Jansen wrote:
I've studied [1] and [2] but don't understand everything there. 
Hence these dumb questions:


Given

  enum n = 100_000_000; // some big number
  auto a = new ulong[](n);
  auto b = new char[8][](n);
  struct S { ulong x; char[8] y; }
  auto c = new S[](n);

will the large memory blocks allocated for a, b and/or c 
actually be scanned for pointers to GC-allocated memory during 
a garbage collection? If so, why?


I've just tested it with my GC tracker ( 
https://bitbucket.org/infognition/dstuff ), all 3 allocations go 
with flags APPENDABLE | NO_SCAN which means these blocks will not 
be scanned.


But if you define S as
struct S { ulong x; char[] y; }
so there is some pointer inside, then it gets allocated with just 
APPENDABLE flag, i.e. it will be scanned then.

Re: Memory Efficient HashSet

[thedeemon via Digitalmars-d-learn]

On Wednesday, 9 March 2016 at 22:31:50 UTC, Nordlöw wrote:

consumes 842.m MiB on my Ubuntu.


Here's mine:
https://bitbucket.org/infognition/robinhood/src
(you just need one file rbhash.d to use in your apps)

The following test takes ~130 MB and can take less with some 
tweaks in the settings:


import std.stdio, rbhash;

alias Set(T) = RHHash!(T, void);

void main() {
auto set = new Set!uint;
foreach(i; 0..10_000_000)
set.add(i);

writeln(set.contains(444));
readln;
}

It's a GC-free Robin Hood hash table implementation with special 
treatment for void as value type, i.e. sets.

Re: Photoshop programming

[thedeemon via Digitalmars-d-learn]

On Sunday, 14 February 2016 at 09:48:54 UTC, Patience wrote:
Photoshop has the ability to be controlled by scripts and 
programming languages. For example, C# can be used to access 
photoshop by adding the appropriate reference and using 
directives. I believe it is COM based but I am not totally sure.


I've tried reading the docs but it's not making much sense.

http://www.lunesu.com/uploads/ModernCOMProgramminginD.pdf

links at the bottom are down.

It says one has to create a wrapper, but then talks like it can 
be done automatically. I assume that is what project does? But 
then one has to create an idl, not sure what that is ;\


Any info on how to do this stuff properly?


Unfortunately the project mentioned in that presentation seems to 
be unavailable.


In order to work with COM objects from D you need to have 
definitions of their interfaces translated to D. Initially they 
are often described in IDL files (Interface Definition Language) 
or TLB files (type library), and there are nice tools like 
tlb2idl.exe and idl2d.exe that can convert them to .d files. You 
can find them in the VisualD project tree. And if original 
definitions are in C++, in many cases Ctrl-C-Ctrl-V is all you 
need to convert to D. ;)


Then you may work with them directly or you might want a wrapper 
that will call Release() for you when appropriate. I'm using a 
wrapper like this:

https://gist.github.com/thedeemon/3c2989b76004fafe9aa0
Originally taken from VisualD source but then modified to my 
needs.


For example, I need to use IAMVfwCompressDialogs interface from 
Microsoft SDK. It's defined in axextend.idl file in the SDK and 
looks like this:


[
object,
local,
uuid(D8D715A3-6E5E-11D0-B3F0-00AA003761C5),
pointer_default(unique)
]
interface IAMVfwCompressDialogs : IUnknown
{

// Bring up a dialog for this codec
HRESULT ShowDialog(
[in]  int iDialog,   // VfwCompressDialogs enum
[in]  HWND hwnd
);

// Calls ICGetState and gives you the result
HRESULT GetState(
[out, size_is(*pcbState), 
annotation("__out_bcount_part(*pcbState, *pcbState)")] LPVOID 
pState,

[in, out, annotation("__inout")]  int *pcbState
);

// Calls ICSetState
HRESULT SetState(
[in, size_is(cbState), 
annotation("__in_bcount(cbState)")] LPVOID pState,

[in]  int cbState
);

// Send a codec specific message
HRESULT SendDriverMessage(
[in]  int uMsg,
[in]  long dw1,
[in]  long dw2
);
}

I use idl2d.exe and get following D code (minus some comments):

const GUID IID_IAMVfwCompressDialogs = IAMVfwCompressDialogs.iid;

interface IAMVfwCompressDialogs : IUnknown
{
static const GUID iid = { 0xD8D715A3,0x6E5E,0x11D0,[ 
0xB3,0xF0,0x00,0xAA,0x00,0x37,0x61,0xC5 ] };


// Bring up a dialog for this codec
HRESULT ShowDialog(
   in  int iDialog,   // VfwCompressDialogs 
enum

   in  HWND hwnd
   );

// Calls ICGetState and gives you the result
HRESULT GetState(
 LPVOID pState,
 int *pcbState
 );

// Calls ICSetState
HRESULT SetState(
 in LPVOID pState,
 in  int cbState
 );

// Send a codec specific message
HRESULT SendDriverMessage(
  in  int uMsg,
  in  int dw1,
  in  int dw2
  );
}

Then in my D code I just write

enum { VfwCompressDialog_Config = 0x01, 
VfwCompressDialog_About =  0x02 }

...
auto vfw = ComPtr!IAMVfwCompressDialogs(pg.vcodec);
if (vfw) vfw.ShowDialog(VfwCompressDialog_Config, hwnd);

where pg.vcodec is my variable of type ComPtr!IBaseFilter I 
created earlier. Here the ComPtr wrapper uses internally 
QueryInterface() to get pointer to desired interface, and when my 
vfw variable goes out of scope, Release() will be called 
automatically. Moreover, if ShowDialog here returns a bad value a 
COMException will be generated automatically (this is my own 
addition to ComPtr behavior).


To create some COM object in the first place, knowing its CLSID, 
I do like this:


auto CLSID_NullRenderer = 
Guid!("C1F400A4-3F08-11D3-9F0B-006008039E37"); //qedit.dll
auto pNullRendr = ComPtr!IBaseFilter(CLSID_NullRenderer, 
"null renderer");


Here IBaseFilter is just some COM interface from Microsoft SDK I 
need.
ComPtr constructor understands what to do depending on whether 
it's given some GUID or a pointer to some object.


Moral of this story, if you have the COM interfaces defined in D, 
you can have wrappers to do resource management, interface 
querying and error checking automatically, but first you need to 
translate (often using automatic

Re: D Book page 402 Concurrency FAIL

[thedeemon via Digitalmars-d-learn]

On Sunday, 14 February 2016 at 22:54:36 UTC, Brother Bill wrote:

Please provide full replacement of this toy program that works 
with D version 2.070.0


This one works fine for me in Windows with VisualD and DMD 
2.070.0:

--
import std.concurrency, std.stdio, std.exception;

void main() {
auto low = 0,
high = 100;
auto tid = spawn(&writer);

foreach (i; low .. high) {
writeln("Main thread: ", i);
tid.send(thisTid, i);
enforce(receiveOnly!Tid() == tid);
}
}

void writer() {
scope(failure) return;
for (;;) {
auto msg = receiveOnly!(Tid, int)();
writeln("secondary thread: ", msg[1]);
msg[0].send(thisTid);
}
}

--

Just one line added to writer() in order to catch OwnerTerminated 
exception and end the thread silently. Original version produced 
an error when main thread finished before the writer thread.

Re: Things that keep D from evolving?

[thedeemon via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 17:41:34 UTC, NX wrote:

I would want it to be solved rather than being worked on... 
which requires design change which is probably not going to 
happen. There is still room for improvement though.


Right. I think there are at least two things that can improve 
current GC without any changes in design: parallel marking and 
lazy sweeping. Currently (at least last time I checked) GC pauses 
the world, then does all the marking in one thread, then all the 
sweeping. We can do the marking in several parallel threads (this 
is much harder to implement but still doable), and we can kick 
the sweeping out of stop-the-world pause and do the sweeping 
lazily: when you try to allocate some memory it will not just 
look in free lists, it will try to collect some unused unswept 
memory from the heap first. This way allocations become a bit 
slower but GC pause time reduces significantly. Concurrent 
sweeping is another possibility.
Of course, it's all easier said than done, without an actual hero 
who would code this, it remains just talk.

Re: Things that keep D from evolving?

[thedeemon via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
What language semantics prevent precise & fast GC  
implementations?


Unions and easy type casting prevent precise GC.
Lack of write barriers for reference-type fields prevent fast 
(generational and/or concurrent) GC. Some more detailed 
explanations here:

http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html

Re: Functions that return type

[thedeemon via Digitalmars-d-learn]

On Wednesday, 20 January 2016 at 04:27:27 UTC, blm768 wrote:

I guess the constraints are that of a static language.


(This is not true.)


I'm playing with the design of such a language myself. 
Basically, anything can create/use/return type objects


This is usually possible in dependently typed languages such as 
Idris, Agda or Coq. Check out Idris, it's rather small but very 
nice and interesting.

Re: Graphics/font/platform backends with common interfaces?

[thedeemon via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 23:34:58 UTC, Rikki Cattermole 
wrote:


So far I've been implementing windowing and image libraries for 
Phobos.
Right now windowing works on Windows minice eventing. Once 
eventing is done it is ready for the first stage of feedback.


I don't understand something about this project. Having existing 
GtkD, DFL, DlangUI, SimpleDisplay, DQuick and probably a few 
others, creating windows on different platforms and eventing 
seems to be a solved problem, multiple times solved. But your 
project is lasting for years at this little stage. And this makes 
me wonder what it is about.

Re: How is D doing?

[thedeemon via Digitalmars-d-learn]

On Tuesday, 22 December 2015 at 21:38:22 UTC, ZombineDev wrote:

Google Trends shows something interesting:
https://google.com/trends/explore#q=%2Fm%2F01kbt7%2C%20%2Fm%2F0dsbpg6%2C%20%2Fm%2F091hdj%2C%20%2Fm%2F03j_q%2C%20C%2B%2B&cmpt=q&tz=Etc%2FGMT-2


Today I Learned C++ is most interested by in Ethiopia. ;)

Re: Make Simple Things Hard to Figure out

[thedeemon via Digitalmars-d-learn]

On Monday, 21 December 2015 at 13:51:57 UTC, default0 wrote:
As this isn't really a question for Learn I'm not sure if it 
fits here. This is more of a "This is how I went about trying 
to learn X. These are the problems I encountered. Ideas to 
improve?" but I guess I might as well post it here.


Thanks for sharing! Obviously Phobos documentation could and 
should be improved, people are working on it but unlike some 
other languages there's nobody in D community working full time 
on documentation and articles. And D user base is still quite 
small, so Stack Overflow is not quite overflown with D-related 
answers.


Out of curiosity I looked into "D Cookbook" to check if it 
contains your particular case but the only mention of Base64 
there is about encoding some data into Base64, not the other way 
around.

Re: How to use D parallel functions/library

[thedeemon via Digitalmars-d-learn]

On Tuesday, 24 November 2015 at 18:49:25 UTC, Bishop120 wrote:
I figured this would be a simple parallel foreach function with 
an iota range of sizeX and just making int X declared inside 
the function so that I didnt have to worry about shared 
variable but I cant get around the alive++ reduction and I dont 
understand enough about D's reduction/parallel library.


Any ideas?  Thanks in advance for yalls patience and assistance!


Incrementing often the same variable from different parallel 
threads is a very bad idea in terms of performance. I would 
suggest counting number of alive cells for each row independently 
(in a local non-shared variable) and storing it to an array (one 
value per row), then after the loop sum them up.


auto aliveCellsPerRow = new int[N];

foreach(i; iota(N).parallel) {
  int aliveHere;
  //...process a row...
  aliveCellsPerRow[i] = aliveHere;
}

alive = aliveCellsPerRow.sum;

Then everything will be truly parallel, correct and fast.

Re: Why my app require MSVCR120.dll?

[thedeemon via Digitalmars-d-learn]

On Sunday, 8 November 2015 at 05:11:50 UTC, suliman wrote:

On Sunday, 8 November 2015 at 04:50:49 UTC, thedeemon wrote:

On Saturday, 7 November 2015 at 10:03:58 UTC, Suliman wrote:


I am using DMD.


-m64 or -m32mscoff ?


Without any keys. I use dub for building


I suspect your issue is caused by botan library on which vibe-d 
depends:

http://code.dlang.org/packages/botan
It says it needs MS linker on Windows and so most probably 
depends on MSVC runtime.
Usually when you build something with DMD without -m64 or 
-m32mscoff it makes a binary without such dependencies, it uses 
its own C library (snn.lib) statically linked.

Re: Why my app require MSVCR120.dll?

[thedeemon via Digitalmars-d-learn]

On Saturday, 7 November 2015 at 10:03:58 UTC, Suliman wrote:


I am using DMD.


-m64 or -m32mscoff ?

Re: Tell GC to use shared memory

[thedeemon via Digitalmars-d-learn]

On Thursday, 8 October 2015 at 09:25:36 UTC, tcak wrote:

On Thursday, 8 October 2015 at 05:46:31 UTC, ketmar wrote:

On Thursday, 8 October 2015 at 04:38:43 UTC, tcak wrote:
Is it possible to modify GC (without rebuilding the 
compiler), so it uses a given shared memory area instead of 
heap for allocations?


sure. you don't need to rebuild the compiler, only druntime.


Any better solution? Like overriding GC class, etc.


You can install your own GC proxy, see module gc.proxy in 
druntime, the struct Proxy and functions gc_getProxy, 
gc_setProxy. No need to recompile druntime.


Here's an example where I install my own GC proxy to do all 
allocations in my arena:

https://bitbucket.org/infognition/dstuff/src/97cef6d4a0438f9a9f4ff0d18f819262b8a74888/gcarena.d?at=default&fileviewer=file-view-default

Re: Can I check if a value is convertible to a valid value of an enum?

[thedeemon via Digitalmars-d-learn]

On Friday, 25 September 2015 at 03:12:20 UTC, French Football 
wrote:

...without having to loop over the enum?
writeln( test( valid_value ) ); //prints true


Since `value` is known only at run time, some checks need to be 
performed at run time anyway. One way of doing it without 
iterating over all variants is to create a static hash table


bool[string] valid_strings;

and populate it in static constructor, then in your function you 
can just write


if (value in valid_strings) ...

Re: Do users need to install VS runtime redistributable if linking with Microsoft linker?

[thedeemon via Digitalmars-d-learn]

On Monday, 21 September 2015 at 15:00:24 UTC, ponce wrote:

All in the title.

DMD 64-bit links with the VS linker.
Do users need to install the VS redistributable libraries?


I think they don't.
Generated .exe seems to depend only on kernel32.dll and 
shell32.dll, i.e. things users already have.

Re: spawn X different workers & wait for results from all of them

[thedeemon via Digitalmars-d-learn]

On Thursday, 3 September 2015 at 16:50:21 UTC, Robert M. Münch 
wrote:

Hi, I'm not sure how to best implement the following:

1. I have 4 different tasks to do.
2. All can run in parallel
3. Every task will return some result that I need

Now how to best do it?


I think the Task and taskPool from std.parallelism are a good fit.
Something like:

auto task1 = task!fun1(params1);
auto task2 = task!fun2(params2);
auto task3 = task!fun3(params3);
auto task4 = task!fun4(params4);

taskPool.put(task1);
taskPool.put(task2);
taskPool.put(task3);
taskPool.put(task4);

auto res1 = task1.workForce();
auto res2 = task2.workForce();
auto res3 = task3.workForce();
auto res4 = task4.workForce();

//here we have all the results, they were calculated in parallel

Re: Working Windows GUI library?

[thedeemon via Digitalmars-d-learn]

On Friday, 4 September 2015 at 13:54:25 UTC, Andre Polykanine 
wrote:

Hello thedeemon,

tvDdl> Yes, DFL!
tvDdl> https://github.com/Rayerd/dfl

Sounds  good.  but still... I can't find any examples or 
documentation :(


Here's some original docs and examples:
http://wiki.dprogramming.com/Dfl/Tutorial
http://wiki.dprogramming.com/Dfl/HomePage

Documentation is a bit scarce, but if you're familiar with 
WinForms (from .NET) you'll recognize everything immediately and 
will feel at home with DFL.


Here's a real world sample - an app I made for our clients:
https://bitbucket.org/thedeemon/autovideoenhance
For instance, a simple typical form (window) code:
https://bitbucket.org/thedeemon/autovideoenhance/src/b0259ca763577cb50169eaa7ee99f074da21724d/folderform.d?at=default
(most of the big setup code is generated by Entice Designer, not 
written manually)

Re: Working Windows GUI library?

[thedeemon via Digitalmars-d-learn]

On Thursday, 3 September 2015 at 15:46:28 UTC, Andre Polykanine 
wrote:
So  my  question  is:  is  there any reliable GUI library 
implementing native Windows controls?


Yes, DFL!
https://github.com/Rayerd/dfl
It's a thin wrapper over WinAPI so all controls are native. I've 
built several apps with it and quite happy with this library. It 
comes with a graphical interface builder called Entice Designer 
which is rather old but still works fine. Also, with this lib 
your app is just a single binary less than 1 MB, no additional 
DLLs required.

Re: interprocess communication and sharing memory

[thedeemon via Digitalmars-d-learn]

On Thursday, 3 September 2015 at 02:52:00 UTC, Laeeth Isharc 
wrote:

On Thursday, 3 September 2015 at 01:27:15 UTC, j55 wrote:
This is my first attempt at a project in D, so pardon me if 
I'm overlooking something obvious:


I'm using libasync to create an eventloop, to set up something 
like a server/daemon process.  This part works very well.  
We'll call this Server A.


Now I'd like to write another process (running on the same 
computer), we'll call Client B, and pass signals in to Server 
A.


It's probably a stupid idea, but until someone with experience 
answers: what happens if you declare the memory as shared or 
__gshared and send a pointer to it via message passing or a 
pipe?


Pointer from one process doesn't make any sense in another 
process, they point to different data in different address 
spaces, and most probably in the second process memory at this 
"address" isn't even allocated by the app, so it would be an 
access violation.

Re: GC and MMM

[thedeemon via Digitalmars-d-learn]

On Thursday, 20 August 2015 at 17:13:33 UTC, Ilya Yaroshenko 
wrote:

Hi All!

Does GC scan manually allocated memory?


Only if you ask GC to do it - by calling core.memory.addRange.

Re: Getting a TypeTuple of a Template's Arguments

[thedeemon via Digitalmars-d-learn]

On Monday, 17 August 2015 at 21:23:49 UTC, Meta wrote:
For functions, we have std.traits.ParameterTypeTuple. Is there 
any equivalent functionality for templates?


I've recently searched for this thing and haven't found anything 
for uninstantiated templates, only for instantiated.

Re: How to provide this arg or functor for algorithm?

[thedeemon via Digitalmars-d-learn]

On Monday, 17 August 2015 at 16:18:50 UTC, thedeemon wrote:
I've just checked with my runtime GC hook. Here the call to 
func() allocates 12 bytes via gc_malloc, and it's the same for 
a 4-elements array, so it's not for the array itself, it's for 
a closure, I think.


Also, compiling with -vgc says nothing, compiler (2.068) seems to 
miss this allocation.

Re: How to provide this arg or functor for algorithm?

[thedeemon via Digitalmars-d-learn]

On Monday, 17 August 2015 at 12:38:05 UTC, anonymous wrote:

auto func()(uint[] arr, uint delegate(uint) pure @nogc d) @nogc
{
return arr.map!(d);
}

void main() @nogc
{
uint[3] arr = [1,2,3];
uint context = 2;
auto c = Caller(context);
auto d = &c.method;

auto r = func(arr[], d);

import std.algorithm: equal;
import std.range: only;
assert(equal(r, only(2, 4, 6)));
}


I've just checked with my runtime GC hook. Here the call to 
func() allocates 12 bytes via gc_malloc, and it's the same for a 
4-elements array, so it's not for the array itself, it's for a 
closure, I think.

Re: How to provide this arg or functor for algorithm?

[thedeemon via Digitalmars-d-learn]

On Monday, 17 August 2015 at 09:51:47 UTC, anonymous wrote:
Huh. I think func being a template is the key here. When the 
original code is put in a template, it works too (with 2.068):


Nope, it "works" only because "r" is unreferenced and gets thrown 
out. Just try using r.front there, for example, and the error 
returns.

Re: Thread communication

[thedeemon via Digitalmars-d-learn]

On Tuesday, 4 August 2015 at 15:19:51 UTC, Chris wrote:

I want to stop (and abort) the worker as soon as new input 
arrives. However, while executing the function that contains 
the foreach-loop the worker thread doesn't listen, because it's 
busy, of course.


I think this is a matter of architecture. If you want to use 
message-passing and you want the worker to react quickly to new 
events, this means it needs to check for new messages (via 
receiveTimeout) often enough, there's no way around it.

Re: incorrect data when returning static array in place of dynamic

[thedeemon via Digitalmars-d-learn]

On Sunday, 5 July 2015 at 18:57:46 UTC, sigod wrote:
Why does function return incorrect data? Using `.dup` in return 
expression or using `ubyte[20]` as return type fixes problem, 
but why?


Because sha1Of() returns ubyte[20], this is a stack-allocated 
array, a value type. If you put correct return type there, it 
will be returned by value and everything's fine. If your return 
type is ubyte[] (a reference type), a slice of stack-allocated 
array is returned which creates a reference to stack data that 
doesn't exist anymore.

Re: More type-flexible arrays?

[thedeemon via Digitalmars-d-learn]

On Sunday, 14 June 2015 at 06:12:30 UTC, Ozan wrote:


Is it possible to create arrays which has more then one type,
f. ex. array[0] = 1; array[1] = "z"; array[2] = new clazz(),


Probably tuples are what you really need here.
http://dlang.org/phobos/std_typecons.html#.Tuple

Re: DFL background tasks

[thedeemon via Digitalmars-d-learn]

On Wednesday, 10 June 2015 at 22:18:21 UTC, Scroph wrote:

client.perform;
while(!client.isStopped)


I don't think this will work as you expect. "perform" is a 
synchronous call, it will not return until the download finishes, 
as I understand, so your while loop is too late. I think you 
should insert message processing stuff inside onProgress, though 
it's also suboptimal (if no progress for long time - no joy). 
Proper design will require more thought...

Re: DFL background tasks

[thedeemon via Digitalmars-d-learn]

On Monday, 8 June 2015 at 07:45:28 UTC, Ali Çehreli wrote:


> receiveTimeout(dur!"msecs"(0).
UFCS makes durations more pleasant: :)
receiveTimeout(0.msecs)


Oh, thanks! I missed this bit. This is much nicer!

Re: DFL background tasks

[thedeemon via Digitalmars-d-learn]

A more general and proper approach is to use message passing from 
std.concurrency. With DFL it looks like this: you spawn() a 
thread and don't pass any GUI controls to it, just thisTid 
(identifier of your main UI thread). In that worker tread when 
you've got some data to show in the UI (be it end result of just 
some status update) you use tid.send(...) and send the data in 
appropriate messages (defined as separate structs or classes). In 
the main UI thread you've got a Timer running that checks whether 
there are any messages in the main thread's mailbox and process 
them there.


Here's an example from a real DFL project:
https://bitbucket.org/infognition/undup/src/e8d295b89bc76545860e38a8c9ee171c86f3c84c/newscan.d?at=default#cl-200

OnStart() is a button callback. It does some quick UI updates and 
spawns a thread, passing relevant data and thisTid:


  worker = spawn(&makeScan, fname, hdr, thisTid);

(makeScan is a function with some long running operation, it's 
defined in another module)


There is also a timer set up when a form is created, and in the 
timer function OnTimer() there is a check for new messages via 
receiveTimeout(dur!"msecs"(0).


while(receiveTimeout(dur!"msecs"(0), &RcvMsgNumOfDirs, 
&RcvMsgScanning, &RcvMsgDone)) {}


Important part here is to make it non-blocking, it should not sit 
here waiting for new messages, otherwise UI will not be 
responsive.


And RcvMsgNumOfDirs, RcvMsgScanning, RcvMsgDone are functions 
that react to corresponding messages sent from the worker thread. 
They work in the UI thread, of course.