Re: Help with Concurrency
On Tuesday, 3 November 2015 at 23:16:59 UTC, bertg wrote:
I am having trouble with a simple use of concurrency.
Running the following code I get 3 different tid's, multiple
"sock in" messages printed, but no receives. I am supposed to
get a "received!" for each "sock in", but I am getting hung up
on "receiving...".
[...]
I had a similarily odd experience with std.concurrency - my
receive would not work unless I also received on Variant,
although the Variant receiver was a no-op:
receive(
(Event event)
{
// handle event
},
(Variant v) {}
);
Re: How to break gdb on D exception ?
On Sunday, 4 October 2015 at 14:31:43 UTC, BBasile wrote: On Friday, 2 October 2015 at 09:15:13 UTC, Dmitri wrote: On Friday, 2 October 2015 at 04:50:59 UTC, BBasile wrote: On Friday, 2 October 2015 at 04:46:51 UTC, BBasile wrote: On Friday, 2 October 2015 at 04:24:11 UTC, Adam D. Ruppe wrote: On Friday, 2 October 2015 at 03:58:45 UTC, BBasile wrote: none of the following GB commands work: give break d_throw or maybe `break d_throwc` a try unfortunately it doesn't work, i get --- (gdb) Function "d_throw"/"d_throwc" not defined. it was almost that actually, 'break _d_throwc Or you could break on a specific exception class's constructor. This would be better. 1/ because I could propose a modifiable list of the exception kinds to track in the options). 2/ because with _d_trow_c, info stack #1 is really not interesting. #2 or #3 is usually where the 'thing' really happens. How can I do that, for example with FileException class ? Well, you look it up: info func FileException 0x005ff7c4 std.file.FileException.this(const(char[]), const(char[]), immutable(char)[], ulong) 0x005ff89c std.file.FileException.this(const(char[]), uint, immutable(char)[], ulong) 0x006139ec std.stream.StreamFileException.this(immutable(char)[]) and then set either via a name or an address: b std.file.FileException.this or b *0x5ff7c4 with the difference that the name version potentially sets multiple breakpoints and moves it just after the frame setup code.
Re: problem with exceptions
On Friday, 2 October 2015 at 12:45:38 UTC, steven kladitis wrote:
On Friday, 2 October 2015 at 12:18:36 UTC, Dmitri wrote:
On Friday, 2 October 2015 at 11:44:21 UTC, steven kladitis
wrote:
C:\d\examples>pb2
=>main's first line
=>makeOmelet's first line
=>prepareAll's first line
=>prepareEggs's first line
object.Exception@pb2.d(64): Cannot take -8 eggs from the
fridge
0x00402252
0x0040512F
0x00405043
0x00403E48
0x7600338A in BaseThreadInitThunk
0x77A497F2 in RtlInitializeExceptionChain
0x77A497C5 in RtlInitializeExceptionChain
- I always see the info at the bottom. Is this normal. I
was thinkig I should only the the exception message itself.
--- this is windows 7 32 bit.
that would the stack of the thread leading up to the
exception. I think you get that if you dump the exception
object itself (not just the message).
-- code is below
import std.stdio;
import std.string;
void indent(in int level)
{
foreach (i; 0 .. level * 2)
{
write(' ');
}
}
void entering(in char[] functionName, in int level)
{
indent(level);
writeln("=>", functionName, "'s first line");
}
void exiting(in char[] functionName, in int level)
{
indent(level);
writeln("<=", functionName, "'s last line");
}
void main()
{
entering("main", 0);
makeOmelet(-8);
eatOmelet();
exiting("main", 0);
}
void makeOmelet(int eggCount)
{
entering("makeOmelet", 1);
prepareAll(eggCount);
cookEggs();
cleanAll();
exiting("makeOmelet", 1);
}
void eatOmelet()
{
entering("eatOmelet", 1);
exiting("eatOmelet", 1);
}
void prepareAll(int eggCount)
{
entering("prepareAll", 2);
prepareEggs(eggCount);
prepareButter();
preparePan();
exiting("prepareAll", 2);
}
void cookEggs()
{
entering("cookEggs", 2);
exiting("cookEggs", 2);
}
void cleanAll()
{
entering("cleanAll", 2);
exiting("cleanAll", 2);
}
void prepareEggs(int count)
{
entering("prepareEggs", 3);
if (count < 1)
{
throw new Exception(
format("Cannot take %s eggs from the fridge",
count));
}
exiting("prepareEggs", 3);
}
void prepareButter()
{
entering("prepareButter", 3);
exiting("prepareButter", 3);
}
void preparePan()
{
entering("preparePan", 3);
exiting("preparePan", 3);
}
I guess it's normal:
void main()
{
throw new Exception("duh");
}
-->
object.Exception@/home/d955/f505.d(3): duh
./f505(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv+0x1f) [0x41e467] ./f505(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x2a) [0x41e3c2] ./f505(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll()+0x2b) [0x41e423] ./f505(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x2a) [0x41e3c2] ./f505(_d_run_main+0x1d2) [0x41e342] ./f505(main+0x12) [0x41d9ce] /usr/lib/libc.so.6(__libc_start_main+0xf5) [0x40967a15]
Looks like the runtime always dumps the uncaught exception that
way. If you need it any other way, catch by Exception and print
only the message.
chunkBy limitation?
I wondered if this is a current limitation of chunkBy
implementation:
// http://dpaste.dzfl.pl/52d6a0c5d0ab
void bar(int[] foo)
{
bool less(int a, int b) // contrived
{
return a < b;
};
foo.sort!less.groupBy;
}
resulting in:
/opt/compilers/dmd2/include/std/algorithm/iteration.d(1529):
Error: function f351.bar.SortedRange!(int[],
less).SortedRange.groupBy!().groupBy.ChunkByImpl!(__lambda1,
int[]).ChunkByImpl.Group.popFront cannot access frame of function
f351.bar.SortedRange!(int[], less).SortedRange.groupBy!().groupBy
...
I can see that the implementation of chunkBy is nested:
struct ChunkByImpl
{
static struct Group {}
}
and that the predicate (less in this case) is accessed from the
nested struct Group which is, probably, what's causing the
compilation error.
The question is if this is an implementation error (i.e. Group
should probably be moved to the top level) or a compiler issue?
Thanks in advance.
Re: problem with exceptions
On Friday, 2 October 2015 at 11:44:21 UTC, steven kladitis wrote: C:\d\examples>pb2 =>main's first line =>makeOmelet's first line =>prepareAll's first line =>prepareEggs's first line object.Exception@pb2.d(64): Cannot take -8 eggs from the fridge 0x00402252 0x0040512F 0x00405043 0x00403E48 0x7600338A in BaseThreadInitThunk 0x77A497F2 in RtlInitializeExceptionChain 0x77A497C5 in RtlInitializeExceptionChain - I always see the info at the bottom. Is this normal. I was thinkig I should only the the exception message itself. --- this is windows 7 32 bit. that would the stack of the thread leading up to the exception. I think you get that if you dump the exception object itself (not just the message).
Re: How to break gdb on D exception ?
On Friday, 2 October 2015 at 04:50:59 UTC, BBasile wrote: On Friday, 2 October 2015 at 04:46:51 UTC, BBasile wrote: On Friday, 2 October 2015 at 04:24:11 UTC, Adam D. Ruppe wrote: On Friday, 2 October 2015 at 03:58:45 UTC, BBasile wrote: none of the following GB commands work: give break d_throw or maybe `break d_throwc` a try unfortunately it doesn't work, i get --- (gdb) Function "d_throw"/"d_throwc" not defined. it was almost that actually, 'break _d_throwc Or you could break on a specific exception class's constructor.
Re: chunkBy limitation?
On Friday, 2 October 2015 at 18:16:59 UTC, Ali Çehreli wrote:
On 10/02/2015 02:21 AM, Dmitri wrote:
> [...]
implementation:
> [...]
Error:
> [...]
function
> [...]
less).SortedRange.groupBy!().groupBy
> [...]
the nested
> [...]
compilation error.
> [...]
Group should
> [...]
This is a known D issue. Currently, objects have a single
context pointer. Here is a bug discussion about it:
https://issues.dlang.org/show_bug.cgi?id=5710
A workaround for your example is making less() static, which
removes its context pointer:
void bar(int[] foo)
{
import std.algorithm : sort;
static bool less(int a, int b) // contrived
{
return a < b;
}
foo.sort!less.groupBy;
}
void main() {}
I've just realized that I don't know how to handle the case
where less() really needs some other state (e.g. it may need to
use a local variable in main). What can we do?
Ali
Thanks, Ali - this is helpful. The problem was figuring out what
exactly is wrong given a bunch of unhelpful error messages. A
somewhat better message comes when using a unary predicate
version of chunkBy.
