Re: DUB help plz
On Thursday, 3 July 2014 at 04:46:02 UTC, K.K. wrote: Is the only thing I'm missing the .dll's? Thanks! Yes, everything went fine, and you find the missing DLL here: https://www.libsdl.org/download-2.0.php
Re: DUB help plz
Derelict contains bindings to other libraries, not these libraries themselves. dub downloads only these bindings, not original libraries (since they are written in C, not D, and not included in dub repositories). You should manually get necessary libraries and put them in folder where .exe will be placed or in some path from PATH environment variable, so application would be able to find them at runtime.
Source transformation for D
Hi, Is there a source transformation for D available? Could someone please point me to it? If not, I'd like to work on one - I'd appreciate any pointers on getting started. I am considering writing the whole thing in D and not relying the lexer/parser in C that is already there. Regards, Kashyap
integer out of range
why is this possible? int count = 50_000_000;
Re: Source transformation for D
On Thursday, 3 July 2014 at 10:17:59 UTC, Kashyap wrote: Hi, Is there a source transformation for D available? Could someone please point me to it? If not, I'd like to work on one - I'd appreciate any pointers on getting started. I am considering writing the whole thing in D and not relying the lexer/parser in C that is already there. Regards, Kashyap https://github.com/Hackerpilot/Dscanner https://github.com/deadalnix/SDC
Re: integer out of range
On Thursday, 3 July 2014 at 10:22:14 UTC, ponce wrote: On Thursday, 3 July 2014 at 10:15:25 UTC, pgtkda wrote: why is this possible? int count = 50_000_000; int is always 4 bytes, it can contains from -2_147_483_648 to 2_147_483_647. oh, ok. I thought it only contains numbers to 2_000_000, but 2 to the power of 32 is your result, thanks.
Re: integer out of range
On Thursday, 3 July 2014 at 10:15:25 UTC, pgtkda wrote: why is this possible? int count = 50_000_000; int is always 4 bytes, it can contains from -2_147_483_648 to 2_147_483_647.
Re: spawn and wait
There is also a Semaphore and Barrier class: http://dlang.org/phobos/core_sync_barrier.html http://dlang.org/phobos/core_sync_semaphore.html
Re: Source transformation for D
On Thursday, 3 July 2014 at 10:23:31 UTC, ponce wrote: On Thursday, 3 July 2014 at 10:17:59 UTC, Kashyap wrote: Hi, Is there a source transformation for D available? Could someone please point me to it? If not, I'd like to work on one - I'd appreciate any pointers on getting started. I am considering writing the whole thing in D and not relying the lexer/parser in C that is already there. Regards, Kashyap https://github.com/Hackerpilot/Dscanner https://github.com/deadalnix/SDC Thank you Ponce. Regards, Kashyap
Re: spawn and wait
On Thursday, 3 July 2014 at 04:51:07 UTC, Ali Çehreli wrote:
On 07/02/2014 08:29 PM, Puming wrote:
I want to spawn several similar tasks and then wait for all
of them to
complete to go on do some other things
If you don't care about account for each of them individually,
core.thread.thread_joinAll would work. The following program
starts two waves of threads and waits for both of the waves to
complete:
import std.stdio;
import std.concurrency;
import core.thread;
void foo(Duration duration)
{
writefln(Working for %s, duration);
Thread.sleep(duration);
}
void spawnThreads(size_t count)
{
foreach (i; 0 .. count) {
spawn(foo, (i + 1).seconds);
}
writefln(Started %s workers, count);
}
void main()
{
spawnThreads(2);
writefln(Waiting for all to finish);
thread_joinAll();
spawnThreads(3);
writefln(Waiting for all to finish);
thread_joinAll();
}
Ali
Thanks that is what I'm looking for
Re: DUB help plz
On Thursday, 3 July 2014 at 07:20:52 UTC, ponce wrote: On Thursday, 3 July 2014 at 04:46:02 UTC, K.K. wrote: Is the only thing I'm missing the .dll's? Thanks! Yes, everything went fine, and you find the missing DLL here: https://www.libsdl.org/download-2.0.php On Thursday, 3 July 2014 at 09:38:23 UTC, FreeSlave wrote: Derelict contains bindings to other libraries, not these libraries themselves. dub downloads only these bindings, not original libraries (since they are written in C, not D, and not included in dub repositories). You should manually get necessary libraries and put them in folder where .exe will be placed or in some path from PATH environment variable, so application would be able to find them at runtime. O okay. That really clears things up; thanks for the help guys!
Re: CTFE bug or enhancement?
On Thu, Jul 03, 2014 at 02:09:09AM +, safety0ff via Digitalmars-d-learn wrote: On Thursday, 3 July 2014 at 02:02:19 UTC, safety0ff wrote: On Thursday, 3 July 2014 at 01:55:14 UTC, safety0ff wrote: Actually, this is an enhancement because adding: enum b = blah Makes them fail. :( The question is now: how can the delegate be evaluated for the return value but not for the enum? Looks like an ICE: https://github.com/D-Programming-Language/dmd/blob/master/src/interpret.c#L5169 All ICE's are bugs and should be reported as such. T -- If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher
Re: spawn and wait
On 07/02/2014 08:29 PM, Puming wrote:
I want to spawn several similar tasks and then wait for all of them to
complete to go on do some other things, like:
[...]
My current workaround is using messages:
I forgot to mention that if message passing is merely a workaround :)
in this case then perhaps std.parallelism is more suitable.
For example, your code may be as simple as running a loop in .parallel
in a foreach loop. The foreach loop would not advance until all of the
parallel tasks have been completed:
import std.stdio;
import std.parallelism;
import std.range;
void task(size_t id)
{
writefln(Working for %s, id);
}
void main()
{
foreach (id; iota(10).parallel) {
task(id);
}
writeln(All done);
}
Ali
Re: spawn and wait
On Thursday, 3 July 2014 at 10:25:41 UTC, Bienlein wrote: There is also a Semaphore and Barrier class: http://dlang.org/phobos/core_sync_barrier.html http://dlang.org/phobos/core_sync_semaphore.html This is probably what I'd do, though both this and thread_joinAll will only work if you have one kernel thread per spawn. If you're using a fiber-based Scheduler, this won't work as expected. In that case you might want to use spawnLinked and trap the LinkTerminated messages or something like that.
Re: integer out of range
On Thu, 03 Jul 2014 10:24:26 + pgtkda via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Thursday, 3 July 2014 at 10:22:14 UTC, ponce wrote: On Thursday, 3 July 2014 at 10:15:25 UTC, pgtkda wrote: why is this possible? int count = 50_000_000; int is always 4 bytes, it can contains from -2_147_483_648 to 2_147_483_647. oh, ok. I thought it only contains numbers to 2_000_000, but 2 to the power of 32 is your result, thanks. If you want to know the min and max of the numeric types, just use their min and max properties - e.g. int.min or long.max. - Jonathan M Davis
immutable/mutable aliasing
void foo(immutable int* x, int* y) {
bar(*x); // bar(3)
*y = 4; // undefined behavior
bar(*x); // bar(??)
}
...
int i = 3;
foo(cast(immutable)i, i);
--
In the 2.065 version, I can compile. But that is not in the
documentation.
Re: immutable/mutable aliasing
There, how to distinguish between const and immutable? thank you~:) /** Const types are like immutable types, except that const forms a read-only view of data. Other aliases to that same data may change it at any time. Any data referenced by the const declaration cannot be changed from the const declaration, but it might be changed by other references to the same data. **/ Can sample code, please?
Re: immutable/mutable aliasing
On Thursday, 3 July 2014 at 21:06:12 UTC, Jet wrote:
There, how to distinguish between const and immutable? thank
you~:)
/**
Const types are like immutable types, except that const forms
a read-only view of data. Other aliases to that same data may
change it at any time.
Any data referenced by the const declaration cannot be changed
from the const declaration, but it might be changed by other
references to the same data.
**/
Can sample code, please?
When you replace 'immutable' with 'const' in your sample code,
then there is no undefined behaviour, and no cast is needed.
void foo(const int* x, int* y) {
bar(*x); // bar(3)
*y = 4; // perfectly fine
bar(*x); // bar(4)
}
void main()
{
int i = 3;
foo(i, i); // no cast
}
Re: immutable/mutable aliasing
On Thursday, 3 July 2014 at 20:43:33 UTC, Jet wrote:
void foo(immutable int* x, int* y) {
bar(*x); // bar(3)
*y = 4; // undefined behavior
bar(*x); // bar(??)
}
...
int i = 3;
foo(cast(immutable)i, i);
--
In the 2.065 version, I can compile. But that is not in the
documentation.
It's undefined behaviour, which means: don't do it. Your sample
compiles, because you're casting. By casting you're saying shut
up compiler, I know what I'm doing.
See also: http://dlang.org/const3.html - Removing Immutable With
A Cast
Re: immutable/mutable aliasing
On Thu, Jul 03, 2014 at 09:06:11PM +, Jet via Digitalmars-d-learn wrote:
There, how to distinguish between const and immutable? thank you~:)
/**
Const types are like immutable types, except that const forms a
read-only view of data. Other aliases to that same data may change it
at any time.
Any data referenced by the const declaration cannot be changed from
the const declaration, but it might be changed by other references to
the same data.
**/
Can sample code, please?
This diagram may help understand D's const/immutable system:
const
/ \
(mutable)immutable
Mutable is the default unqualified type. It means you're free to modify
it. Immutable is the opposite: it is guaranteed that neither you, nor
anybody else, can modify it. Once an immutable value is initialized, it
might as well be cast in stone, it can never change again.
int x = 1; // mutable
x++;// OK
immutable int y = 1;
//y++; // ILLEGAL: cannot modify immutable
Const is the bridge between mutable and immutable. It means that *you*
cannot change the value, but somebody else might. The reason we want
const is so that you can pass both a mutable or an immutable value to
the same function. The function cannot change the value, but the caller
can, if it's mutable. (And of course, immutable cannot be changed by
anyone -- which is OK, since the function isn't allowed to change a
const parameter anyway.)
class MyData {
int x;
}
auto data = new MyData; // mutable
data.x++; // OK
auto idata = new immutable(MyData);
//idata.x++;// ILLEGAL: cannot modify immutable
bool myFunc(const(MyData) obj) {
obj.x++;// ILLEGAL: cannot modify const
return obj.x 0; // OK: can read const
}
bool b1 = myFunc(data); // OK, can pass mutable to const
bool b2 = myFunc(idata); // OK, can pass immutable to const
// (since myFunc cannot modify it)
void cache(immutable(MyData) iobj) {
static immutable(MyData) _cache;
_cache = iobj;
}
cache(data);// ILLEGAL: cannot pass mutable to immutable
cache(idata); // OK: can pass immutable to immutable
Usually, you'd write function parameters to be const rather than
immutable, because you want to accept both mutable and immutable
arguments. But sometimes, you want to be 100% sure that nobody outside
the function can modify the value while you're using it. For example:
int longCalculation(const(MyData) obj) {
int acc = 0;
foreach (i; 0 .. 1_000_000) {
acc += obj.x;
}
return acc;
}
auto evil = MyData(1);
spawn((const(MyData) d) {
// This runs in a different thread
writeln(longCalculation(d));
}, evil);
evil.x = 5; // Oops
Since evil is mutable, it's allowed to be passed to a const parameter:
it just means that longCalculation cannot modify it. However, that
doesn't guarantee that somebody else can't modify it; for example, in
the above code we run longCalculation in a different thread, and then we
set evil.x = 5 in the main thread. The result is that the value of obj.x
in longCalculation gets mutated while the loop is running, causing the
result to become corrupted. So the child thread will *not* print
100, but something else, depending on the relative timing of the
threads.
To prevent this sort of problems, the solution is to make
longCalculation take an immutable parameter. Then if you try to compile
it, the compiler will complain that you can't pass mutable to immutable,
so you're forced to make evil either const or immutable. Which means
that the evil.x = 5 line will be rejected by the compiler because
nobody is allowed to modify an immutable value, thus preventing the
corruption problem.
T
--
Truth, Sir, is a cow which will give [skeptics] no more milk, and so they are
gone to milk the bull. -- Sam. Johnson
Re: immutable/mutable aliasing
Thank you all. These answers are very detailed. I think I learned a lot.
Re: immutable/mutable aliasing
Awesome!!! Thank you so much!
Re: immutable/mutable aliasing
On 07/03/2014 01:43 PM, Jet wrote:
void foo(immutable int* x, int* y) {
bar(*x); // bar(3)
*y = 4; // undefined behavior
bar(*x); // bar(??)
}
...
int i = 3;
foo(cast(immutable)i, i);
--
In the 2.065 version, I can compile. But that is not in the
documentation.
In addition to the excellent responses in this thread, this is how I
like to describe the semantics between const versus immutable references
(including pointers) on a function interface:
- const reference or pointer parameter: I will not modify your data.
- immutable reference or pointer parameter: I demand data from you that
nobody will modify.
When the semantics are described that way, they are not related at all:
One is a promise to the caller, the other is a request from the caller.
Ali
