UPDATE: life is too short to debug dlang built-in AA to right,
let's just use HashMap from emsi_containers
https://github.com/mw66/grpc-d/blob/master/source/grpc/server/package.d#L25
```
HashMap!(string, ServiceHandlerInterface) services;
```
After this change, the problem goes away.
I think
Hi,
I recently found and started playing with the grpc-d-core[1]
package, and my program structure looks like this:
https://github.com/mw66/grpc-demo/blob/master/source/main.d
If I run L64 alone (without L66 ~ 79 grpc-d part):
```
64: auto t = new Thread({fun();}).start();
```
it works fine.
On Wednesday, 30 August 2017 at 20:47:12 UTC, EntangledQuanta
wrote:
interface I
{
void Go(T)(S!T s);
static final I New()
{
return new C();
}
}
abstract class A : I
{
}
class C : A
{
void Go(T)(S!T s)
{
On Monday, 4 September 2017 at 03:08:50 UTC, EntangledQuanta
wrote:
On Monday, 4 September 2017 at 01:50:48 UTC, Moritz Maxeiner
wrote:
On Sunday, 3 September 2017 at 23:25:47 UTC, EntangledQuanta
wrote:
On Sunday, 3 September 2017 at 11:48:38 UTC, Moritz Maxeiner
wrote:
On Sunday, 3 September
On Monday, 4 September 2017 at 01:50:48 UTC, Moritz Maxeiner
wrote:
On Sunday, 3 September 2017 at 23:25:47 UTC, EntangledQuanta
wrote:
On Sunday, 3 September 2017 at 11:48:38 UTC, Moritz Maxeiner
wrote:
On Sunday, 3 September 2017 at 04:18:03 UTC, EntangledQuanta
wrote:
On Sunday, 3 September
On Sunday, 3 September 2017 at 23:25:47 UTC, EntangledQuanta
wrote:
On Sunday, 3 September 2017 at 11:48:38 UTC, Moritz Maxeiner
wrote:
On Sunday, 3 September 2017 at 04:18:03 UTC, EntangledQuanta
wrote:
On Sunday, 3 September 2017 at 02:39:19 UTC, Moritz Maxeiner
wrote:
On Saturday, 2
On Sunday, 3 September 2017 at 11:48:38 UTC, Moritz Maxeiner
wrote:
On Sunday, 3 September 2017 at 04:18:03 UTC, EntangledQuanta
wrote:
On Sunday, 3 September 2017 at 02:39:19 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 23:12:35 UTC,
EntangledQuanta wrote:
[...]
The
On Sunday, 3 September 2017 at 04:18:03 UTC, EntangledQuanta
wrote:
On Sunday, 3 September 2017 at 02:39:19 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 23:12:35 UTC, EntangledQuanta
wrote:
[...]
The contexts being independent of each other doesn't change
that we would still
On Sunday, 3 September 2017 at 02:39:19 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 23:12:35 UTC, EntangledQuanta
wrote:
On Saturday, 2 September 2017 at 21:19:31 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 00:00:43 UTC,
EntangledQuanta wrote:
On Friday, 1
On Saturday, 2 September 2017 at 23:12:35 UTC, EntangledQuanta
wrote:
On Saturday, 2 September 2017 at 21:19:31 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 00:00:43 UTC, EntangledQuanta
wrote:
On Friday, 1 September 2017 at 23:25:04 UTC, Jesse Phillips
wrote:
I've love being
On Saturday, 2 September 2017 at 21:19:31 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 00:00:43 UTC, EntangledQuanta
wrote:
On Friday, 1 September 2017 at 23:25:04 UTC, Jesse Phillips
wrote:
I've love being able to inherit and override generic
functions in C#. Unfortunately C#
On Saturday, 2 September 2017 at 00:00:43 UTC, EntangledQuanta
wrote:
On Friday, 1 September 2017 at 23:25:04 UTC, Jesse Phillips
wrote:
I've love being able to inherit and override generic functions
in C#. Unfortunately C# doesn't use templates and I hit so
many other issues where Generics
On Saturday, 2 September 2017 at 16:20:10 UTC, Jesse Phillips
wrote:
On Saturday, 2 September 2017 at 00:00:43 UTC, EntangledQuanta
wrote:
Regardless of the implementation, the idea that we should
throw the baby out with the bathwater is simply wrong. At
least there are a few who get that. By
On Saturday, 2 September 2017 at 00:00:43 UTC, EntangledQuanta
wrote:
Regardless of the implementation, the idea that we should throw
the baby out with the bathwater is simply wrong. At least there
are a few who get that. By looking in to it in a serious manner
an event better solution might
On Friday, 1 September 2017 at 23:25:04 UTC, Jesse Phillips wrote:
I've love being able to inherit and override generic functions
in C#. Unfortunately C# doesn't use templates and I hit so many
other issues where Generics just suck.
I don't think it is appropriate to dismiss the need for the
I've love being able to inherit and override generic functions in
C#. Unfortunately C# doesn't use templates and I hit so many
other issues where Generics just suck.
I don't think it is appropriate to dismiss the need for the
compiler to generate a virtual function for every instantiated T,
This happens when building, not running. This might be a Visual D
issue as when I use dmd from the command line, it works fine ;/
On Friday, 1 September 2017 at 19:25:53 UTC, Adam D Ruppe wrote:
On Friday, 1 September 2017 at 18:17:22 UTC, EntangledQuanta
wrote:
I get an access violation, changed the code to
What is the rest of your code? access violation usually means
you didn't new the class...
No, that is the
On Friday, 1 September 2017 at 18:17:22 UTC, EntangledQuanta
wrote:
I get an access violation, changed the code to
What is the rest of your code? access violation usually means you
didn't new the class...
On Friday, 1 September 2017 at 15:24:39 UTC, Adam D. Ruppe wrote:
static foreach is now in the new release! You can now do stuff
like:
---
alias I(A...) = A;
interface Foo {
static foreach(T; I!(int, float))
void set(T t); // define virt funcs for a list
of types
}
static foreach is now in the new release! You can now do stuff
like:
---
alias I(A...) = A;
interface Foo {
static foreach(T; I!(int, float))
void set(T t); // define virt funcs for a list of
types
}
class Ass : Foo {
static foreach(T; I!(int, float))
On Thursday, 31 August 2017 at 15:48:12 UTC, EntangledQuanta
wrote:
On Thursday, 31 August 2017 at 10:34:14 UTC, Kagamin wrote:
On Thursday, 31 August 2017 at 00:49:22 UTC, EntangledQuanta
wrote:
I've already implemented a half ass library solution.
It can be improved alot.
Then, by all
On Thursday, 31 August 2017 at 10:34:14 UTC, Kagamin wrote:
On Thursday, 31 August 2017 at 00:49:22 UTC, EntangledQuanta
wrote:
I've already implemented a half ass library solution.
It can be improved alot.
Then, by all means, genius!
On Thursday, 31 August 2017 at 00:49:22 UTC, EntangledQuanta
wrote:
I've already implemented a half ass library solution.
It can be improved alot.
On 08/30/2017 05:49 PM, EntangledQuanta wrote:
> The compiler can and should do this!
Yes, the compiler can do it for each compilation but there is also the
feature called /separate compilation/ that D supports. With separate
compilation, there would potentially be multiple different and
On Wednesday, 30 August 2017 at 22:52:41 UTC, Adam D. Ruppe wrote:
On Wednesday, 30 August 2017 at 20:47:12 UTC, EntangledQuanta
wrote:
This is quite surprising!
In the new version pending release (scheduled for later this
week), we get a new feature `static foreach` that will let you
loop
On Wednesday, 30 August 2017 at 22:08:03 UTC, Jonathan M Davis
wrote:
On Wednesday, August 30, 2017 21:51:57 EntangledQuanta via
Digitalmars-d- learn wrote:
[...]
Templates have no idea what arguments you intend to use with
them. You can pass them any arguments you want, and as long as
they
On Wednesday, 30 August 2017 at 20:47:12 UTC, EntangledQuanta
wrote:
This is quite surprising!
In the new version pending release (scheduled for later this
week), we get a new feature `static foreach` that will let you
loop through the types you want and declare all the functions
that way.
On Wednesday, 30 August 2017 at 22:08:03 UTC, Jonathan M Davis
wrote:
On Wednesday, August 30, 2017 21:51:57 EntangledQuanta via
Digitalmars-d- learn wrote:
The point you are trying to making, and not doing a great job,
is that the compiler cannot create an unknown set of virtual
functions
On Wednesday, August 30, 2017 21:51:57 EntangledQuanta via Digitalmars-d-
learn wrote:
> The point you are trying to making, and not doing a great job, is
> that the compiler cannot create an unknown set of virtual
> functions from a single templated virtual function. BUT, when you
> realize that
On Wednesday, 30 August 2017 at 21:33:30 UTC, Jonathan M Davis
wrote:
On Wednesday, August 30, 2017 20:47:12 EntangledQuanta via
Digitalmars-d- learn wrote:
This is quite surprising!
public struct S(T)
{
T s;
}
interface I
{
void Go(T)(S!T s);
static final I New()
{
return new
On Wednesday, 30 August 2017 at 20:47:12 UTC, EntangledQuanta
wrote:
This is quite surprising!
public struct S(T)
{
T s;
}
interface I
{
void Go(T)(S!T s);
static final I New()
{
return new C();
}
}
abstract class A : I
{
On Wednesday, 30 August 2017 at 21:13:19 UTC, Kagamin wrote:
It can't work this way. You can try std.variant.
Sure it can! What are you talking about! std.variant has nothing
to do with it! It works if T is hard coded, so it should work
generically. What's the point of templates variables if
On Wednesday, August 30, 2017 20:47:12 EntangledQuanta via Digitalmars-d-
learn wrote:
> This is quite surprising!
>
> public struct S(T)
> {
> T s;
> }
>
>
> interface I
> {
> void Go(T)(S!T s);
>
> static final I New()
> {
> return new C();
> }
> }
>
> abstract class A : I
> {
>
It can't work this way. You can try std.variant.
This is quite surprising!
public struct S(T)
{
T s;
}
interface I
{
void Go(T)(S!T s);
static final I New()
{
return new C();
}
}
abstract class A : I
{
}
class C : A
{
void Go(T)(S!T s)
{
On 8/28/17 9:34 PM, Johnson Jones wrote:
produces 4 on both x86 and x64. So, I'm not sure how you are getting 8.
Yes, this is exactly why you should use c_long and c_ulong, because just
using int makes it not portable to other systems.
-Steve
On Tuesday, 29 August 2017 at 02:47:34 UTC, Johnson Jones wrote:
[...]
Seems only long and ulong are issues.
With respect to the currently major platforms you can reasonable
expect software to run on, yes.
Just don't try to use D on something with e.g. 32 bit C shorts
unless you bind to it
On Tuesday, 29 August 2017 at 01:56:43 UTC, Moritz Maxeiner wrote:
On Tuesday, 29 August 2017 at 01:34:40 UTC, Johnson Jones wrote:
[...]
produces 4 on both x86 and x64. So, I'm not sure how you are
getting 8.
There are different 64bit data models [1] and it seems your
platform uses
On Tuesday, 29 August 2017 at 01:34:40 UTC, Johnson Jones wrote:
import core.stdc.config;
pragma(msg, c_long.sizeof);
prints 4UL
both on x64 and x86
and and C:
void foo()
{
int dummy;
switch (dummy) {
case sizeof(long) :
case sizeof(long) :
On Tuesday, 29 August 2017 at 01:34:40 UTC, Johnson Jones wrote:
[...]
produces 4 on both x86 and x64. So, I'm not sure how you are
getting 8.
There are different 64bit data models [1] and it seems your
platform uses LLP64, which uses 32bit longs. Am I correct in
assuming you're on
("%lu\n", sizeof(long)); // also prints 8 on my box
return 0;
}
They should match. If they don't, that's a D bug (in either
core.stdc.config or the compiler, I'm not sure which). If they
do, then one of the other two possibilities is happening, and I
would lean towards the bind
core.stdc.config;
pragma(msg, c_long.sizeof); // prints 8 on my box.
And in c:
#include
int main()
{
printf("%lu\n", sizeof(long)); // also prints 8 on my box
return 0;
}
They should match. If they don't, that's a D bug (in either
core.stdc.config or the compiler, I'm not
On Monday, 28 August 2017 at 21:35:27 UTC, Steven Schveighoffer
wrote:
On 8/27/17 10:17 PM, Johnson Jones wrote:
Looking at the assembly shows something like this:
0041ea98 push 0x0
0041ea9a push 0x0
0041ea9c push 0x0
0041ea9e push dword 0x100
0041eaa3 mov ecx,
On Monday, 28 August 2017 at 22:41:56 UTC, Moritz Maxeiner wrote:
On Monday, 28 August 2017 at 22:21:18 UTC, Johnson Jones wrote:
On Monday, 28 August 2017 at 21:35:27 UTC, Steven
Schveighoffer wrote:
[...]
and where are these c_ types defined? The reason I replaced
them was precisely
On Monday, 28 August 2017 at 22:21:18 UTC, Johnson Jones wrote:
On Monday, 28 August 2017 at 21:35:27 UTC, Steven Schveighoffer
wrote:
On 8/27/17 10:17 PM, Johnson Jones wrote:
[...]
For C/C++ interaction, always use c_... types if they are
available. The idea is both that they will be
On Monday, 28 August 2017 at 21:35:27 UTC, Steven Schveighoffer
wrote:
On 8/27/17 10:17 PM, Johnson Jones wrote:
[...]
For C/C++ interaction, always use c_... types if they are
available. The idea is both that they will be correctly defined
for the width, and also it will mangle correctly
On 8/27/17 10:17 PM, Johnson Jones wrote:
Looking at the assembly shows something like this:
0041ea98 push 0x0
0041ea9a push 0x0
0041ea9c push 0x0
0041ea9e push dword 0x100
0041eaa3 mov ecx, [typeid(PaStreamParameters)+0xe36fc (0x80d4cc)]
0041eaa9 mov eax, [fs:0x2c]
0041eaaf mov edx,
Looking at the assembly shows something like this:
0041ea98 push 0x0
0041ea9a push 0x0
0041ea9c push 0x0
0041ea9e push dword 0x100
0041eaa3 mov ecx, [typeid(PaStreamParameters)+0xe36fc (0x80d4cc)]
0041eaa9 mov eax, [fs:0x2c]
0041eaaf mov edx, [eax+ecx*4]
0041eab2 push dword [edx+0x1c]
lang.org/thread/lkbswgpsgxynhfyzw...@forum.dlang.org
This is either a bug in D, an issue with calling conventions, or
how one passes the data.
The original portaudio open stream function, so you can see that
it simply prints it's arguments:
PaError Pa_OpenStream( Pa
On Fri, Aug 11, 2017 at 11:34:04PM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
> On Friday, 11 August 2017 at 22:43:02 UTC, Mr. Pib wrote:
> > int and I should be able to append an int without having to worry
> > about the value of the int.
>
> Appending an int to a string really ought
On Friday, 11 August 2017 at 23:34:04 UTC, Adam D. Ruppe wrote:
On Friday, 11 August 2017 at 22:43:02 UTC, Mr. Pib wrote:
int and I should be able to append an int without having to
worry about the value of the int.
Appending an int to a string really ought to just be a type
mismatch error.
On Friday, 11 August 2017 at 22:43:02 UTC, Mr. Pib wrote:
int and I should be able to append an int without having to
worry about the value of the int.
Appending an int to a string really ought to just be a type
mismatch error.
We might be able to convince the leadership to do that too,
On Friday, 11 August 2017 at 22:50:53 UTC, ketmar wrote:
Mr. Pib wrote:
Wow, that is pretty screwed up! I thought D was against
implicit conversions that might cause problems? I'm passing
an int and I should be able to append an int without having to
worry about the value of the int.
Mr. Pib wrote:
Wow, that is pretty screwed up! I thought D was against implicit
conversions that might cause problems? I'm passing an int and I should
be able to append an int without having to worry about the value of the
int. Instead D chose to do something very strange, awkward, and error
On Friday, 11 August 2017 at 04:17:32 UTC, ketmar wrote:
Mr. Pib wrote:
string Q(alias T, alias D)()
{
pragma(msg, T);
pragma(msg, D);
enum x = T~" = "~D~";";
pragma(msg, x);
}
mixin(Q!(`x`, 100)());
outputs, at compile time,
x
100
x = d;
there is no
Mr. Pib wrote:
string Q(alias T, alias D)()
{
pragma(msg, T);
pragma(msg, D);
enum x = T~" = "~D~";";
pragma(msg, x);
}
mixin(Q!(`x`, 100)());
outputs, at compile time,
x
100
x = d;
there is no lowercase d. I did initially define Q as
string Q(alias T, D)(D
string Q(alias T, alias D)()
{
pragma(msg, T);
pragma(msg, D);
enum x = T~" = "~D~";";
pragma(msg, x);
}
mixin(Q!(`x`, 100)());
outputs, at compile time,
x
100
x = d;
there is no lowercase d. I did initially define Q as
string Q(alias T, D)(D d)
and one
58 matches
Mail list logo
