Re: Atomic updates
On Tuesday, 22 January 2013 at 00:10:22 UTC, bearophile wrote: I suggest to put your code on Rosettacode now, and then we'll do the changes there... As you see in other answers, both me and monarch_dodra have other ideas for improvements. Ok, posted it. http://rosettacode.org/wiki/Atomic_updates#D I incorporated some of your and monarch_dodra's suggestions.
Re: Atomic updates
On Tuesday, 22 January 2013 at 08:12:03 UTC, qznc wrote: On Tuesday, 22 January 2013 at 00:10:22 UTC, bearophile wrote: I suggest to put your code on Rosettacode now, and then we'll do the changes there... As you see in other answers, both me and monarch_dodra have other ideas for improvements. Ok, posted it. http://rosettacode.org/wiki/Atomic_updates#D I incorporated some of your and monarch_dodra's suggestions. Just curious: in the transfer function, why do you lock/unlock the lower bucket number first? Why does the order matter?
Re: Pull 1019
On Friday, 18 January 2013 at 13:13:03 UTC, Jacob Carlborg wrote: On 2013-01-18 14:07, Namespace wrote: Despite the danger that this annoy you probably: What about pull 1019 (https://github.com/D-Programming-Language/dmd/pull/1019)? I'm still quite new with Git so I do not know exactly what 1 Fail, 9 Pending means (and why it stands there so long) It means that the test suite failed. You can click Details to get more details about what failed. Ok I observe the pull been a while and have to say that the status is always the same: 1 Fails, 9 Pending. I also see that it is updated every few hours, but the status is still the same every time. Is this normal? Is that automatically update accordingly? And how is such a nice test environment integrated into a pull request?
Re: Atomic updates
On Tuesday, 22 January 2013 at 09:26:25 UTC, cal wrote: On Tuesday, 22 January 2013 at 08:12:03 UTC, qznc wrote: On Tuesday, 22 January 2013 at 00:10:22 UTC, bearophile wrote: I suggest to put your code on Rosettacode now, and then we'll do the changes there... As you see in other answers, both me and monarch_dodra have other ideas for improvements. Ok, posted it. http://rosettacode.org/wiki/Atomic_updates#D I incorporated some of your and monarch_dodra's suggestions. Just curious: in the transfer function, why do you lock/unlock the lower bucket number first? Why does the order matter? Avoids deadlock. imagine 2 threads: a: from 2 to 5. b: from 5 to 2. If both threads acquire their first lock, then you have a dead lock, and your program is basically dead. By always locking low first, you avoid the deadlock in a rather simple but elegant way.
TDPL message passing: OwnerFailed?
I was trying to do a simple program to test message passing.
Basically, I have 1 owner, and 2 slave threads.
I'm facing two problems:
1 ) First, I want the slaves to be informed of when the master
dies in an abnormal way.
TDPL suggest OwnerFailed, but apparently, the out of band
exception that is thrown is an OwnerTerminated, which does not
allow me to know if the termination is normal or not.
Does that mean I have to manually send a message to my slaves to
tell them master is finished, and have the slaves take
OwnerTerminated as always abnormal?
2 ) Ditto, I need the master to be informed of when a slave dies
(via exception).
However, no matter what I do, it would appear the master simply
isn't informed of the death of its slaves. It just keeps running
until it finishes, at which point it may and/or may not show the
exception...
//
import std.concurrency, std.stdio;
import core.thread;
void main()
{
auto tid1 = spawn(fileWriter1);
auto tid2 = spawn(fileWriter2);
Thread.sleep(dur!seconds(1));
send(tid1, 1);
send(tid2, 2);
stderr.writeln(Normally master.);
}
void fileWriter1() {
throw new Exception(Bwah ha ha 1!);
}
void fileWriter2() {
throw new Exception(Bwah ha ha 2!);
}
//
Normally master.
//
If I remove the sleep, I get:
//
Normally master.
object.Exception@main.d(20): Bwah ha ha 2!
//
FYI, the original project was writing a file writer that takes 1
input, and 2 outputs. THis is rather easy, but the error handling
is eluding me.
Re: Pull 1019
On Tuesday, 22 January 2013 at 09:29:07 UTC, Namespace wrote: On Friday, 18 January 2013 at 13:13:03 UTC, Jacob Carlborg wrote: On 2013-01-18 14:07, Namespace wrote: Despite the danger that this annoy you probably: What about pull 1019 (https://github.com/D-Programming-Language/dmd/pull/1019)? I'm still quite new with Git so I do not know exactly what 1 Fail, 9 Pending means (and why it stands there so long) It means that the test suite failed. You can click Details to get more details about what failed. Ok I observe the pull been a while and have to say that the status is always the same: 1 Fails, 9 Pending. I also see that it is updated every few hours, but the status is still the same every time. Is this normal? Is that automatically update accordingly? And how is such a nice test environment integrated into a pull request? It will remain the same until author of the pull request will actually take time to fix test errors or whatever fails there. AFAIR Brad is the one who should get most gratitude for that nice CI suite.
Re: Atomic updates
On Tuesday, 22 January 2013 at 10:27:58 UTC, bearophile wrote: I have modified a little the code on RosettaCode (no changes in the logic). monarch_dodra: Avoids deadlock. imagine 2 threads: a: from 2 to 5. b: from 5 to 2. If both threads acquire their first lock, then you have a dead lock, and your program is basically dead. By always locking low first, you avoid the deadlock in a rather simple but elegant way. The Go language has four different solutions, one of them is: http://rosettacode.org/wiki/Atomic_updates#Lock-free [SNIP] Bye, bearophile That's a good point, and I'm sure we could also have a version of D that could also do it that way. D has attomic swap operations too, AFAIK. But I was really just answering the original question of if you need 2 locks, why do it that way?.
Re: Atomic updates
monarch_dodra:
That's a good point, and I'm sure we could also have a version
of D that could also do it that way.
Someone is willing to create that second version for RosettaCode?
I have modified a bit the second and third Go versions on
Rosettacode, now there are 20 buckets and it shows the print
every 1 second (like the D version currently present on
Rosettacode). I have compiled the Go code with the latest go1.0.3
(that is a fast compiler, but I think it doesn't produce a very
efficient binary). The outputs:
Go atomic2b:
sum ---updates---mean buckets
1000 825883 825883 1651766 [96 19 7 45 119 35 67 4 45 19
106 51 19 69 8 102 34 47 56 52]
1000 754038 754037 1579920 [27 92 16 9 17 34 74 26 69 20
110 120 38 16 93 10 131 8 34 56]
1000 815841 815842 1597174 [27 10 46 54 32 19 55 87 125 87
46 29 70 57 37 2 14 151 2 50]
1000 748939 748938 1572350 [78 52 82 64 12 6 15 36 13 103
52 21 12 55 58 137 100 69 16 19]
1000 748836 748837 1557414 [78 79 29 114 13 12 131 105 22
20 68 77 40 19 68 30 36 57 1 1]
1000 751092 751092 1548209 [23 17 35 106 58 74 40 141 35
124 3 46 32 46 0 47 32 37 57 47]
1000 747933 747933 1540732 [43 32 31 32 29 36 41 46 37 51
46 1 48 263 37 61 51 61 43 11]
Go atomic3b
sum ---updates---mean buckets
1000 1098238 1098238 2196476 [93 22 4 122 48 20 52 37 50 73
13 22 85 103 93 22 2 13 86 40]
1000 907417 907417 2005655 [36 57 36 134 6 48 21 134 47 76
18 65 22 18 61 92 67 15 23 24]
1000 814198 814197 1879901 [21 51 56 37 55 36 22 50 106 0
99 6 59 107 55 21 40 67 65 47]
1000 725805 725805 1772828 [32 5 105 39 123 17 46 23 25 38
24 104 109 51 87 32 13 1 39 87]
1000 793476 793476 1735653 [65 24 63 62 88 59 57 99 27 47
25 70 30 4 31 0 57 89 24 79]
1000 837247 837247 1725460 [23 28 95 35 31 37 105 40 15 13
46 53 36 17 36 134 50 76 94 36]
1000 991714 991714 1762312 [20 86 116 42 32 52 59 11 55 49
41 102 82 59 17 7 7 28 31 104]
1000 838766 838767 1751715 [18 29 15 17 31 140 12 42 52 90
53 136 57 42 31 73 31 44 43 44]
1000 764370 764370 1726940 [64 5 78 77 127 90 43 14 46 0 46
70 63 20 42 57 3 20 58 77]
D version (-O -release -inline -noboundscheck):
n. randomize, n. equalize, buckets, buckets sum:
409363 2 [47, 0, 70, 77, 9, 0, 70, 36, 130, 24, 53, 64, 52, 17,
56, 65, 116, 65, 17, 40] 1008
2318049 2265054 [51, 51, 51, 51, 51, 51, 51, 50, 51, 51, 51, 51,
51, 51, 51, 51, 51, 51, 51, 40] 1008
2063793 2447437 [9, 0, 196, 76, 0, 2, 60, 36, 23, 40, 17, 44, 0,
29, 156, 16, 147, 76, 41, 40] 1008
2010050 2579035 [51, 51, 51, 51, 51, 51, 51, 51, 51, 51, 51, 51,
51, 51, 51, 51, 51, 50, 51, 40] 1008
2180213 2151695 [152, 130, 12, 46, 6, 5, 10, 0, 0, 130, 109, 11,
73, 39, 15, 72, 0, 60, 98, 40] 1008
1930470 2646068 [50, 51, 51, 51, 51, 51, 51, 51, 51, 51, 51, 51,
51, 51, 51, 51, 51, 51, 51, 40] 1008
1967369 2650625 [64, 17, 16, 260, 29, 50, 94, 128, 65, 24, 49,
30, 42, 0, 35, 9, 28, 15, 13, 40] 1008
To compile the second Go version you need:
import (
fmt
math/rand
time
sync
runtime
)
...
func main() {
// Create a concrete object implementing the bucketList
interface.
bl := newRwList(20, originalTotal, nUpdaters)
And for the third:
import (
fmt
math/rand
time
sync
runtime
sync/atomic
)
...
func main() {
// Create a concrete object implementing the bucketList
interface.
bl := newLfList(20, originalTotal, nUpdaters)
Bye,
bearophile
Re: Atomic updates
I have modified a bit the second and third Go versions on Rosettacode, The changes on the Go versions are only on my local copies of the code. Bye, bearophile
Re: Error by building druntime
Hey, me again. I cloned dmd from git head and try to build it with: make -fwin32.mak release But I get these errors: dmc -c -Ibackend;tk -DMARS -cpp -D -g -DUNITTEST -e -wx -DDM_TARGET_CPU_X86=1 - I. backend\cgelem elerr, ^ elxxx.c(3) : Error: need explicit cast to convert from: elem*(*C func)(elem*,unsigned ) to : elem*(*C func)(elem*) eladd, ^ elxxx.c(4) : Error: need explicit cast to convert from: elem*(*C func)(elem*,unsigned ) to : elem*(*C func)(elem*) elmin, ^ elxxx.c(5) : Error: need explicit cast to convert from: elem*(*C func)(elem*,unsigned ) to : elem*(*C func)(elem*) elmul, ^ elxxx.c(6) : Error: need explicit cast to convert from: elem*(*C func)(elem*,unsigned ) to : elem*(*C func)(elem*) eldiv, ^ elxxx.c(7) : Error: need explicit cast to convert Fatal error: too many errors --- errorlevel 1 --- errorlevel 1 --- errorlevel 1 I see them for the first time, so can someone explain me what is going on there? o.O
Re: TDPL message passing: OwnerFailed?
On 22.1.2013 11:08, monarch_dodra wrote: I was trying to do a simple program to test message passing. Basically, I have 1 owner, and 2 slave threads. I'm facing two problems: 1 ) First, I want the slaves to be informed of when the master dies in an abnormal way. TDPL suggest OwnerFailed, but apparently, the out of band exception that is thrown is an OwnerTerminated, which does not allow me to know if the termination is normal or not. Does that mean I have to manually send a message to my slaves to tell them master is finished, and have the slaves take OwnerTerminated as always abnormal? 2 ) Ditto, I need the master to be informed of when a slave dies (via exception). However, no matter what I do, it would appear the master simply isn't informed of the death of its slaves. It just keeps running until it finishes, at which point it may and/or may not show the exception... Hi, wouldn't this help you? http://dlang.org/phobos/std_concurrency.html#.spawnLinked According to documentation: Executes the supplied function in a new context represented by Tid. This new context is linked to the calling context so that if either it or the calling context terminates a LinkTerminated message will be sent to the other, causing a LinkTerminated exception to be thrown on receive(). The owner relationship from spawn() is preserved as well, so if the link between threads is broken, owner termination will still result in an OwnerTerminated exception to be thrown on receive(). Martin
Re: Atomic updates
I have tried to scope the Mutex, but the D code gets a little
slower, I don't know why:
5,6d5
import std.typecons: scoped;
import std.traits: ReturnType;
19,22c17,19
ReturnType!(scoped!Mutex) mtx;
alias this = value;
}
// pragma(msg, Bucket.sizeof); // 52 bytes
---
Mutex mtx;
alias this = value;
}
31c28
b = Bucket(uniform(0, 100), scoped!Mutex());
---
b = Bucket(uniform(0, 100), new Mutex());
35c32
return buckets[index].value;
---
return buckets[index];
70,76c67,68
//sink(text(buckets));
sink([);
foreach (ref b; buckets) {
sink(text(b.value));
sink( );
}
sink(] );
---
sink(text(buckets));
sink( );
(And as you see the alias this of Bucket partially stops
working).
Bye,
bearophile
Re: Atomic updates
On Tuesday, 22 January 2013 at 10:27:58 UTC, bearophile wrote:
The Go language has four different solutions, one of them is:
http://rosettacode.org/wiki/Atomic_updates#Lock-free
From the site:
This version uses no locking for the phase where the
two clients are updating the buckets. Instead it
watches for collisions and retries as needed.
func (bl *lfList) transfer(b1, b2, a int, ux int) {
if b1 == b2 {
return
}
bl.RLock()
for {
t := int32(a)
v1 := atomic.LoadInt32(bl.b[b1])
if t v1 {
t = v1
}
if atomic.CompareAndSwapInt32(bl.b[b1], v1, v1-t) {
atomic.AddInt32(bl.b[b2], t)
break
}
// else retry
}
bl.tc[ux]++
bl.RUnlock()
runtime.Gosched()
}
Is that solution actually correct?
If I am not mistaken, the buckets are in an inconsistent state
between CompareAndSwapInt32 and AddInt32.
Re: Atomic updates
On Tuesday, 22 January 2013 at 14:10:14 UTC, qznc wrote:
On Tuesday, 22 January 2013 at 10:27:58 UTC, bearophile wrote:
The Go language has four different solutions, one of them is:
http://rosettacode.org/wiki/Atomic_updates#Lock-free
From the site:
This version uses no locking for the phase where the
two clients are updating the buckets. Instead it
watches for collisions and retries as needed.
func (bl *lfList) transfer(b1, b2, a int, ux int) {
if b1 == b2 {
return
}
bl.RLock()
for {
t := int32(a)
v1 := atomic.LoadInt32(bl.b[b1])
if t v1 {
t = v1
}
if atomic.CompareAndSwapInt32(bl.b[b1], v1, v1-t) {
atomic.AddInt32(bl.b[b2], t)
break
}
// else retry
}
bl.tc[ux]++
bl.RUnlock()
runtime.Gosched()
}
Is that solution actually correct?
If I am not mistaken, the buckets are in an inconsistent state
between CompareAndSwapInt32 and AddInt32.
So?
buckets[from] -= realAmount; //Inconsistent state here
buckets[to ] += realAmount;
The bottom line is that there *has* to be a point in time where
the state is inconsistent. Your job is to make sure this
inconsistency does not overlap and corrupt the overall state.
Re: TDPL message passing: OwnerFailed?
On 01/22/2013 04:26 AM, Martin Drasar wrote: On 22.1.2013 11:08, monarch_dodra wrote: I was trying to do a simple program to test message passing. wouldn't this help you? http://dlang.org/phobos/std_concurrency.html#.spawnLinked The following chapter may be helpful as well: http://ddili.org/ders/d.en/concurrency.html Especially the following sections: - Exceptions during the execution of the worker - Detecting thread termination - Receiving exceptions as messages Ali
Re: Error by building druntime
Hm, has really no one an idea what's wrong? I'm followed strict the steps that are described in the wiki.
Re: Error by building druntime
On Tuesday, 22 January 2013 at 14:56:16 UTC, Namespace wrote: Hm, has really no one an idea what's wrong? I'm followed strict the steps that are described in the wiki. Do you have the latest github dmd? Could just be that you pulled the code at the exact moment it wasn't compiling.
Re: Atomic updates
monarch_dodra: D has attomic swap operations too, AFAIK. In core.atomic I think there is what's needed, cas and atomicOp: https://github.com/D-Programming-Language/druntime/blob/master/src/core/atomic.d Do you know why the site doesn't show the ddocs here? http://dlang.org/phobos/core_atomic.html Bye, bearophile
Re: TDPL message passing: OwnerFailed?
On Tuesday, 22 January 2013 at 12:27:12 UTC, Martin Drasar wrote: Hi, wouldn't this help you? http://dlang.org/phobos/std_concurrency.html#.spawnLinked According to documentation: Executes the supplied function in a new context represented by Tid. This new context is linked to the calling context so that if either it or the calling context terminates a LinkTerminated message will be sent to the other, causing a LinkTerminated exception to be thrown on receive(). The owner relationship from spawn() is preserved as well, so if the link between threads is broken, owner termination will still result in an OwnerTerminated exception to be thrown on receive(). Martin Thanks. I tried using it, but it is giving me problems in the sense that: 1) If the worker sends a message, and then dies, the LinkTerminated message is sometimes not caught by the owner. 2) When the worker needs to die its natural death, it is creating some LinkTerminated errors :/ Gotta keep tinkering. On Tuesday, 22 January 2013 at 14:47:10 UTC, Ali Çehreli wrote: On 01/22/2013 04:26 AM, Martin Drasar wrote: On 22.1.2013 11:08, monarch_dodra wrote: I was trying to do a simple program to test message passing. wouldn't this help you? http://dlang.org/phobos/std_concurrency.html#.spawnLinked The following chapter may be helpful as well: http://ddili.org/ders/d.en/concurrency.html Especially the following sections: - Exceptions during the execution of the worker - Detecting thread termination - Receiving exceptions as messages Ali TY. Gonna read everything.
Re: Atomic updates
On 22.1.2013 16:00, bearophile wrote: Do you know why the site doesn't show the ddocs here? http://dlang.org/phobos/core_atomic.html Wild guess, but couldn't it be because the ddoc documentation is inside version(CoreDdoc) and not processed? Martin
Re: Error by building druntime
On Tuesday, 22 January 2013 at 14:58:50 UTC, monarch_dodra wrote: On Tuesday, 22 January 2013 at 14:56:16 UTC, Namespace wrote: Hm, has really no one an idea what's wrong? I'm followed strict the steps that are described in the wiki. Do you have the latest github dmd? Could just be that you pulled the code at the exact moment it wasn't compiling. Yes, I pulled several times and dmd is last updated before 6 hours. So I don't believe that I catched this moment.
Re: Atomic updates
Martin Drasar: Wild guess, but couldn't it be because the ddoc documentation is inside version(CoreDdoc) and not processed? The question then becomes why is that version(CoreDdoc) used :-) Bye, bearophile
Re: Error by building druntime
On Tuesday, 22 January 2013 at 15:10:14 UTC, Namespace wrote: On Tuesday, 22 January 2013 at 14:58:50 UTC, monarch_dodra wrote: On Tuesday, 22 January 2013 at 14:56:16 UTC, Namespace wrote: Hm, has really no one an idea what's wrong? I'm followed strict the steps that are described in the wiki. Do you have the latest github dmd? Could just be that you pulled the code at the exact moment it wasn't compiling. Yes, I pulled several times and dmd is last updated before 6 hours. So I don't believe that I catched this moment. I have cloned again, but the error is still there.
Re: Atomic updates
On Tuesday, 22 January 2013 at 09:47:25 UTC, monarch_dodra wrote: Avoids deadlock. imagine 2 threads: a: from 2 to 5. b: from 5 to 2. If both threads acquire their first lock, then you have a dead lock, and your program is basically dead. By always locking low first, you avoid the deadlock in a rather simple but elegant way. Ah neat. And what about the case from = to? Why doesn' that deadlock in this code? (Concurrency is rather new to me)
Re: Atomic updates
On Monday, 21 January 2013 at 20:35:16 UTC, bearophile wrote: qznc: Code: http://dpaste.dzfl.pl/e6615a53 Any comments or improvements? I have reformatted your code a little, according to the style used in all other D entries of RosettaCode: http://codepad.org/ceDyQ8lE The usage of a sink for toString() isn't common, but it's OK. I suggest to add something to make it stop after 20 seconds or so (I run all the rosettacode entries every so often to test them, so I prefer them to not go on forever. Some entries are required to produce infinite loops, but I think this time it's not necessary). I actually implemented a more scalable version than most of the other languages used, by using a lock per item instead of a single lock for the whole array. Then I suggest you to add this comment before the entry. Bye, bearophile I note you always seem to use in in your functions and on reddit seemed to imply that this was the idiomatic way of using D yet I recall Jonathan M Davies posting that using in was a bad idea.
Re: Atomic updates
On Tuesday, 22 January 2013 at 18:10:27 UTC, cal wrote: On Tuesday, 22 January 2013 at 09:47:25 UTC, monarch_dodra wrote: Avoids deadlock. imagine 2 threads: a: from 2 to 5. b: from 5 to 2. If both threads acquire their first lock, then you have a dead lock, and your program is basically dead. By always locking low first, you avoid the deadlock in a rather simple but elegant way. Ah neat. And what about the case from = to? Why doesn' that deadlock in this code? (Concurrency is rather new to me) Because a single thread may acquire the same lock more than once. At which point, it will increment the lock counter. The lock is released when the counter reaches zero. This allows having easy nested logic, where a function does not have to worry if the caller function already has a lock.
Re: Atomic updates
ixid: I note you always seem to use in in your functions and on reddit seemed to imply that this was the idiomatic way of using D yet I recall Jonathan M Davies posting that using in was a bad idea. I think in is supposed to be(come) idiomatic, because it's short, and it's supposed to combine two attributes that you usually want, const and scope. On the other hand scope for arguments is not implemented yet (and Walter doesn't show lot of interest in implementing it, I don't know why. Few days ago Hara has said he wants to try to implement scope. But it's a lot of work, so I don't know if and when he will be done). So if you annotate something with scope, and you let the reference escape, the code now compiles, but later will break. Breaking the D code on Rosettacode is acceptable, because that site is like a wide variety of tiny test programs. So using in in Rosettacode is good. But if you are writing a largish D2 project, then Jonathan is right, it's better to not use in and scope arguments, unless you want to fix ton of future errors. Bye, bearophile
Re: TDPL message passing: OwnerFailed?
On 01/22/2013 09:04 AM, monarch_dodra wrote:
I'm getting some errors with this program:
I can not reproduce this problem on Linux. Not with -m64 nor with -m32.
I don't think the following is necessary but it has been a workaround
for me in the past:
import core.thread;
void main(string[] args)
{
// ...
thread_joinAll();
}
Ali
S-Expressions
After Atomic Updates from rosettacode.org, here is S-Expressions. Problem: http://rosettacode.org/wiki/S-Expressions Code: http://dpaste.dzfl.pl/fd485808 Comments, improvements?
Re: Error by building druntime
Maybe I should describe _exactly_ what I did to earn help. I make a new directory with: mkdir d then I wrote git clone git://github.com/D-Programming-Language/dmd.git git clone git://github.com/D-Programming-Language/druntime.git git clone git://github.com/D-Programming-Language/phobos.git dir and get the following directory structure: dmd druntime phobos I changed to dmd/src (where all files are, also win32.mak) and wrote: make -fwin32.mak clean and then make -fwin32.mak release (I tried also -release) It runs a few seconds and generates these executables: idgen.exe impcnvgen.exe optabgen.exe vergen.exe but I get still these errors: [code] dmc -c -Ibackend;tk -DMARS -cpp -D -g -DUNITTEST -e -wx -DDM_TARGET_CPU_X86=1 - I. backend\cgelem elerr, ^ elxxx.c(3) : Error: need explicit cast to convert from: elem*(*C func)(elem*,unsigned ) to : elem*(*C func)(elem*) eladd, ^ elxxx.c(4) : Error: need explicit cast to convert from: elem*(*C func)(elem*,unsigned ) to : elem*(*C func)(elem*) elmin, ^ elxxx.c(5) : Error: need explicit cast to convert from: elem*(*C func)(elem*,unsigned ) to : elem*(*C func)(elem*) elmul, ^ elxxx.c(6) : Error: need explicit cast to convert from: elem*(*C func)(elem*,unsigned ) to : elem*(*C func)(elem*) eldiv, ^ elxxx.c(7) : Error: need explicit cast to convert Fatal error: too many errors --- errorlevel 1 --- errorlevel 1 --- errorlevel 1 [/code] So what is wrong now? A few days ago it works fine. I don't understand that. :/
Re: Error by building druntime
On Tuesday, 22 January 2013 at 20:47:46 UTC, Namespace wrote: So what is wrong now? A few days ago it works fine. I don't understand that. :/ Strange. That's what I do (verbatim), so it should work. Which make is being called? What is your DMC? Could you try it with *only* X/dm/bin in you path? It know it should work with 8.56, that's the one I use. http://www.digitalmars.com/download/freecompiler.html
Re: Error by building druntime
No idea. Just updated my own dmd sources. I rebuilt it fine with both dmc 852c and 856c, in both release non-release :/
Re: Error by building druntime
On Tuesday, 22 January 2013 at 21:35:48 UTC, Namespace wrote: dmc prints before Digital Mars Compiler Version 8.42n and also after I replaced it with your version. Have I forget something? And still the same error. That weird. oO Ah, I forgot, sorry. I'm using: Digital Mars Make Version 5.06
Re: Win32 api with 2.061
Am 22.01.2013 23:25, schrieb cal: const uint WINVER = blah try: static const uint WINVER = blah But I have no idea why it changed
Re: Error by building druntime
On Tuesday, 22 January 2013 at 22:15:13 UTC, Namespace wrote: In my distress I have now tried with dmd_msc_vs10. I get no such error but others: 1cl : Befehlszeile warning D9025: /TC wird durch /TP überschrieben 1mars.c(905): warning C4805: '!=': unsichere Kombination von Typ 'char' mit Typ 'bool' in einer Operation 1c1xx : fatal error C1083: Datei (Quelle) kann nicht geöffnet werden: ph.c: No such file or directory 1c1xx : fatal error C1083: Datei (Quelle) kann nicht geöffnet werden: util.c: No such file or directory I didn't tried dmd_msc_vs10 before, so I have no comparison. Strange but interest: If I build with Visual Studio I get the error messages above. But when I try then make -fwin32.mak it works without errors and I get a dmd.exe. Could someone explain me this? o.O
Re: Win32 api with 2.061
On 1/22/13, cal callumena...@gmail.com wrote: I am trying to compile a project using the Win32 api header's (the Dsource ones) with 2.061 and am getting errors for the first time with things like this: Try making these changes: https://github.com/AndrejMitrovic/WindowsAPI/commit/6d8ef98508063c5a4741c72eda68aa485d3b25fa WindowsAPI should really be moved to Github..
Re: MS ODBC encoding issue
On Thursday, 17 January 2013 at 18:36:16 UTC, Regan Heath wrote: On Mon, 14 Jan 2013 10:02:04 -, Regan Heath re...@netmail.co.nz wrote: Ok, solved the issue I think. Appreciatd all the help and am very excited that it finaly works,WOW! Now I can see (in Visual-D debugger) the Chinese characters in the rowData, but I can't get it to display correctly on my windows console.. can someone remind me how to do that? Before I am deep into the code later sometime as end of the Chinese New Year I am crazy busy on my job,for windows console show Chinese character issue,I've solved and posted on the forum before.Please refer to below link: http://forum.dlang.org/thread/suzymdzjeifnfirtb...@dfeed.kimsufi.thecybershadow.net#post-suzymdzjeifnfirtbnrc:40dfeed.kimsufi.thecybershadow.net You can see when ppl asked Chinese character (with Windows Console) such questions in the forum,rarely ppl will answer,strange ^_^ Regards, Sam
Re: MS ODBC encoding issue
I've tested and the Chinese character issue really fixed!
But I have two more issues here.
1.for connect with DSNless string function provided by my
original code as below,I can not make it to connect successfully
with really database file.Don't now why yours works.
bool connect(string connectionString)
{
SQLCHAR connStrOut[256];
SQLSMALLINT connStrOutLen;
if(bState==false)
{
retCode=SQLDriverConnect(hDbc, null,
cast(SQLCHAR*)toStringz(connectionString), SQL_NTS,
cast(ubyte*)connStrOut, connStrOut.length, connStrOutLen,
SQL_DRIVER_COMPLETE);
if((retCode != SQL_SUCCESS) (retCode !=
SQL_SUCCESS_WITH_INFO))
{
throw new Exception(format(Erro AllocHandle with retCode:
%d,retCode));
SQLFreeHandle( SQL_HANDLE_DBC, hDbc );
return false;
}
retCode=SQLAllocHandle(SQL_HANDLE_STMT,hDbc,hStmt);
if((retCode != SQL_SUCCESS) (retCode !=
SQL_SUCCESS_WITH_INFO))
{
throw new Exception(format(Erro AllocHandle with retCode:
%d,retCode));
SQLDisconnect( hDbc );
SQLFreeHandle( SQL_HANDLE_DBC, hDbc);
return false;
}
}
bState=true;
return true;
}
2.Inserting new record from windows console faile on Chinese
characters but success on English characters.If I enter a Chinese
character to feed the new record,the program closed (crashed I
think) immedialtey and none row affected in the database.
Any tips would be appreciated.
Regards,
Sam
shared std.signals
Is it possible to create a shared signal class?
I would like to create a shared signal class so some other
process that knows certain things can come along emit its info to
any observer:
import std.stdio, std.signals;
class Observer {
void watch(string msg) {
writeln(msg);
}
}
class Foo {
string value() {
return _value;
}
string value(string v) {
if (v != _value) {
_value = v;
emit(_value);
}
return v;
}
mixin Signal!(string);
private:
string _value;
}
shared Foo a;
void main() {
a = new shared Foo();
Observer o1 = new Observer();
a.connect(o1.watch);
}
Re: shared std.signals
On Wednesday, 23 January 2013 at 07:11:59 UTC, Joshua Niehus wrote: Is it possible to create a shared signal class? oh god... dont tell me __gshared ! Think i answered my own question, it got me to the next step. going to have to read through those giant shared threads again
