DMD32 compiling gtkd out of memory on 32bit Windows 7 machine
hi , When compiling gtkd using dub, dmd32 reported "Out for memory" and exit. OS: Windows 7 32bit. RAM : 3GB DMD version: v2.0.82.0 32bit. No VC or Windows SDK installed, when setting up dmd, I selected install vc2010 and use mingw lib.
Re: Process in parallel and output result to stdout theread-safely
On Monday, 10 September 2018 at 20:30:52 UTC, Dr.No wrote:
On Saturday, 8 September 2018 at 14:26:45 UTC, ag0aep6g wrote:
[...]
Yes, it does only happens at line breaks. I hadn't realized
that until you mentioned. It does gets in place of \r and \n,
that's why there's all in one line when this happens. Thankfor
for the notice.
[...]
I noticied this happens with everything I print in the loop, even
using C's printf:
__gshared Mutex m;
m = new Mutex();
foreach(string fn; parallel(files))
{
try
{
auto res = f(fn);
synchronized(m)
{
import std.c.stdio :
printf;
printf("hello!\n");
}
[...]
Output:
https://imgur.com/a/Mq9X4c3
Re: How to use listener.d example?
On Friday, 7 September 2018 at 17:00:21 UTC, Marcin wrote: I get it working in linux environment. I don't know why vibe-d get linker errors on win10. And I get it to work on windos dub --build=release
enforce with return type RegexMatch!string
I've got the folling function which returns a RegexMatch!string:
auto extract_list(const string entry)
{
// check if entry is valid
return matchAll(entry, some_regex);
}
I call this function using enforce(extract_list(some_argument)).
I think, that enforce is quite useless in this version. But I'd
like to add a check, if entry is valid in the
extract_list-function, something like:
if (!matchFirst(entry, other_regex)) return null;
That doesn't work, because I cannot cast null to
RegexMatch!string (I don't understand why). What works is to
create a string[] from the result of matchAll (using map and
array) and use that array instead of the range. Now I can return
null too.
Is there a way to accomplish this?
Re: Is it's correct to say that ALL types that can grow are place on heap?
11.09.2018 13:11, Timoses пишет: Is this why it is said that passing parameters by value can be more efficient? Cause for a ref parameter it would require passing the address which would require to be allocated? Aww, I really would love some insights into function parameter passing. Why is it said that passing by value can be more efficient at times? Since it is also said that passing large structs by value can be expensive, why then would it not be cheaper to ALWAYS pass everything by reference? What mechanism is behind the scene that follows one to reason that sometimes passing by value is less expensive? I get that passing an int by reference would cause indirections which need to be resolved whereas passing the int by value is just one copy (I guess). This topic kinda seemed fit for my question that I was carrying around for some time. If data size is less or equal to total size of available registers (that can be used to pass values) than passing by value is more efficient. Passing data with size less than register size by reference isn't efficient because you pass pointer (that has register size) and access memory using it.
Re: "immutable string" vs "const string*"
On Sunday, 9 September 2018 at 08:41:37 UTC, Christian Mayer wrote: On Sunday, 9 September 2018 at 08:14:41 UTC, rikki cattermole wrote: Are you aware that a string is just an alias of immutable(char)[]? Yes, I'm aware of that. But it's the same, for example, with just one char. "immutable char" vs "const char*". Or int, or any other data type. As of my current understanding "char" will create a new variable and copy the content of the original to the new variable. "char*" will just use the pointer. And "const char*" is good for when not modifying. But I also can achieve the same using "immutable char". But I'm not sure when better using "immutable char". In C I would rather use a const pointer. But since I just started learing D I'm not so sure because there are so many ways. Since strings are slices (immutable(char)[]) it could also be worth reading into slices [1]. Assigning an existing slice to another slice will not copy the content but only the slice struct (length and pointer to data). [1] https://dlang.org/articles/d-array-article.html
Re: Is it's correct to say that ALL types that can grow are place on heap?
On Saturday, 8 September 2018 at 22:51:17 UTC, Ali Çehreli wrote: On 09/08/2018 02:19 AM, Suliman wrote: > Is it's correct to say that ALL types that can grow are place on heap > and types that not growing (int, char, pointer) are place on stack? The question is not that simple. :) First, there is also the area used for objects that are static and object that are defined at module scope. That is different from both the call stack and the heap. Let's ignore them... There are automatic objects like local variables inside a function and function parameters. They normally live on the stack. (However, the compiler may pass some parameters in CPU registers without allocating any memory at all.) Is this why it is said that passing parameters by value can be more efficient? Cause for a ref parameter it would require passing the address which would require to be allocated? Aww, I really would love some insights into function parameter passing. Why is it said that passing by value can be more efficient at times? Since it is also said that passing large structs by value can be expensive, why then would it not be cheaper to ALWAYS pass everything by reference? What mechanism is behind the scene that follows one to reason that sometimes passing by value is less expensive? I get that passing an int by reference would cause indirections which need to be resolved whereas passing the int by value is just one copy (I guess). This topic kinda seemed fit for my question that I was carrying around for some time.
Re: traits getOverload of a template method
On Thursday, 6 February 2014 at 23:06:03 UTC, QAston wrote:
How do i get aliases to overloads of a template method like
Class A
{
int a(T)(T tq,T tw);
int a(T)(T tq);
}
__traits(getOverloads, A, "a(int)")doesnt work
Support for template in the getOverloads trait has been added
recently.
You have to set an optional trailing parameter to `true`:
```
class A
{
int a(T)(T,T){}
int a(T)(T){}
}
enum include_templates = true;
static foreach (overload; __traits(getOverloads, A, "a",
include_templates))
pragma(msg, overload.stringof);
```
a(T)(T, T)
a(T)(T)
specs: https://dlang.org/spec/traits.html#getOverloads
