On Saturday, 11 January 2014 at 16:07:30 UTC, Philippe Sigaud
wrote:
I'm a bit leery of putting D call syntax into semantic actions,
because it'll also explode the Pegged grammar size (I'm fairly
sure
I'd have to pull in a big part of D if I want to get function
calls
right). That's one feature
Ok, I can reproduce this, and it seems that the crash happens somewhere
in no mans land. That means there is no debugging information present
and the stack frame isn't valid either. So the debugger and druntimes
buildin stacktrace code has no chance. My guess would be that this
happens inside d
Le 12/01/2014 00:30, Benjamin Thaut a écrit :
Am 11.01.2014 22:56, schrieb Xavier Bigand:
Le 11/01/2014 22:15, Benjamin Thaut a écrit :
Am 11.01.2014 20:50, schrieb Xavier Bigand:
Yes I have no stack trace and adding import core.sys.windows.stacktrace
change nothing.
That is very strange. C
Am 11.01.2014 22:56, schrieb Xavier Bigand:
Le 11/01/2014 22:15, Benjamin Thaut a écrit :
Am 11.01.2014 20:50, schrieb Xavier Bigand:
Yes I have no stack trace and adding import core.sys.windows.stacktrace
change nothing.
That is very strange. Can you reduce this? Or is this project on githu
On Saturday, 11 January 2014 at 20:38:33 UTC, Abdulhaq wrote:
On Saturday, 11 January 2014 at 20:17:14 UTC, Tobias Pankrath
wrote:
class X {};
X x;
x is an reference to an instance of X, with other words a
pointer without arithmetic but with syntax sugar. &x will take
the address of this poi
Le 11/01/2014 22:15, Benjamin Thaut a écrit :
Am 11.01.2014 20:50, schrieb Xavier Bigand:
Yes I have no stack trace and adding import core.sys.windows.stacktrace
change nothing.
That is very strange. Can you reduce this? Or is this project on github
somewhere? Did you try using a debugger?
K
Am 11.01.2014 20:50, schrieb Xavier Bigand:
Yes I have no stack trace and adding import core.sys.windows.stacktrace
change nothing.
That is very strange. Can you reduce this? Or is this project on github
somewhere? Did you try using a debugger?
Kind Regards
Benjamin Thaut
On 01/11/2014 09:35 AM, "Casper Færgemand" " wrote:
On Saturday, 11 January 2014 at 07:50:51 UTC, Jakob Ovrum wrote:
Your problem is probably better solved without string mixins, but we'd
probably need to see some code or more elaboration to accurately
suggest a solution.
enum semanticArray =
On Saturday, 11 January 2014 at 20:17:14 UTC, Tobias Pankrath
wrote:
class X {};
X x;
x is an reference to an instance of X, with other words a
pointer without arithmetic but with syntax sugar. &x will take
the address of this pointer/reference. If you want the address
of the actual instance
Object[void*] wrappingRegistry;
but of course that prevents the wrapped objects from being
garbage collected - I need weak ref semantics.
I had a go at making it e.g.
ulong[ulong] and storing the cast(ulong) address of the D
object, but it seems that I don't understand what taking the
addres
I'm implementing a wrapper program for wrapping generic C++
libraries - it's going very well (subclassing, virtual methods,
nested classes, enums working) but I've hit an area that I don't
have enough D experience to answer, and am hoping someone can
point me in the right direction. My backgrou
Le 11/01/2014 19:40, Benjamin Thaut a écrit :
Am 11.01.2014 19:16, schrieb Xavier Bigand:
Le 11/01/2014 18:45, Benjamin Thaut a écrit :
Am 11.01.2014 17:24, schrieb Xavier Bigand:
I get some troubles to solve a memory bug, just cause I don't have any
informations for debuggers and I can't neit
On Saturday, 11 January 2014 at 17:50:01 UTC, Eric wrote:
Apparently the line,
static shared static int x;
will compile just fine. Is this sort of a bug,
or does it mean something different from just
static shared int x;
?
Also, the line,
static static static int x;
will also compile. Do
On Saturday, 11 January 2014 at 18:38:22 UTC, Gary Willoughby
wrote:
Is it possible to call a parent's destructor? If so what's the
syntax?
Parent destructors are called automatically:
import std.stdio;
class Foo {
~this() { writeln("Foo.dtor"); }
}
class Bar : Foo {
~this() {
On Saturday, 11 January 2014 at 17:50:01 UTC, Eric wrote:
Does this mean x is extra static?
It is just that repeated storage classes aren't always caught as
an error (though they sometimes are!)
Am 11.01.2014 19:16, schrieb Xavier Bigand:
Le 11/01/2014 18:45, Benjamin Thaut a écrit :
Am 11.01.2014 17:24, schrieb Xavier Bigand:
I get some troubles to solve a memory bug, just cause I don't have any
informations for debuggers and I can't neither use DrMemory.
Is it possible to get the ca
Is it possible to call a parent's destructor? If so what's the
syntax?
Le 11/01/2014 17:24, Xavier Bigand a écrit :
I get some troubles to solve a memory bug, just cause I don't have any
informations for debuggers and I can't neither use DrMemory.
Is it possible to get the callstack when calling a method on a null
pointer with specifics DMD flags?
Maybe DMD need a
Le 11/01/2014 18:45, Benjamin Thaut a écrit :
Am 11.01.2014 17:24, schrieb Xavier Bigand:
I get some troubles to solve a memory bug, just cause I don't have any
informations for debuggers and I can't neither use DrMemory.
Is it possible to get the callstack when calling a method on a null
point
Le 11/01/2014 18:20, Namespace a écrit :
On Saturday, 11 January 2014 at 16:24:08 UTC, Xavier Bigand wrote:
I get some troubles to solve a memory bug, just cause I don't have any
informations for debuggers and I can't neither use DrMemory.
Is it possible to get the callstack when calling a meth
On Saturday, 11 January 2014 at 16:24:08 UTC, Xavier Bigand wrote:
I get some troubles to solve a memory bug, just cause I don't
have any informations for debuggers and I can't neither use
DrMemory.
Is it possible to get the callstack when calling a method on a
null pointer with specifics DMD
Apparently the line,
static shared static int x;
will compile just fine. Is this sort of a bug,
or does it mean something different from just
static shared int x;
?
Also, the line,
static static static int x;
will also compile. Does this mean x is extra static?
-Eric
Am 11.01.2014 17:24, schrieb Xavier Bigand:
I get some troubles to solve a memory bug, just cause I don't have any
informations for debuggers and I can't neither use DrMemory.
Is it possible to get the callstack when calling a method on a null
pointer with specifics DMD flags?
Maybe DMD need ad
On Saturday, 11 January 2014 at 16:24:08 UTC, Xavier Bigand wrote:
I get some troubles to solve a memory bug, just cause I don't
have any informations for debuggers and I can't neither use
DrMemory.
Is it possible to get the callstack when calling a method on a
null pointer with specifics DMD
> Note that closures are not (yet) supported in CTFE, because else
> another solution would be a function-returning function:
>
> auto bar(string s, int i)
> {
> return
> (ParseTree p) {
> p.name ~= s ~ to!string(i);
> return p;
> };
> }
Duh, instead of
I get some troubles to solve a memory bug, just cause I don't have any
informations for debuggers and I can't neither use DrMemory.
Is it possible to get the callstack when calling a method on a null
pointer with specifics DMD flags?
Maybe DMD need add null ptr call checks in debug mode?
On 1/11/2014 10:08 PM, Gary Willoughby wrote:
On Saturday, 11 January 2014 at 12:57:38 UTC, Mike Parker wrote:
On 1/11/2014 9:01 PM, Gary Willoughby wrote:
I'm currently using the 32bit compiler on Windows which uses optlink for
linking. I know the compiler command line accepts the -L option to
On Sat, Jan 11, 2014 at 2:34 PM, <"Casper Færgemand\"
"@puremagic.com> wrote:
> On Saturday, 11 January 2014 at 09:17:34 UTC, Philippe Sigaud wrote:
>>
>> case "Gramm.Expr":
>> return foo(t);
>> case "Gramm.FunctionCall":
>> return foo(t);
>> case "G
Thanks all.
On Saturday, 11 January 2014 at 15:13:45 UTC, Gary Willoughby
wrote:
How to launch a Windows compiled exe without showing a console?
I've tried the following two ways and when i execute the
resulting *.exe file a console is shown alongside the dialog
box. How can i suppress the console?
impo
On Saturday, 11 January 2014 at 15:13:45 UTC, Gary Willoughby
wrote:
box. How can i suppress the console?
Add -L/subsystem:windows to the dmd command line, that should do
it.
How to launch a Windows compiled exe without showing a console?
I've tried the following two ways and when i execute the
resulting *.exe file a console is shown alongside the dialog box.
How can i suppress the console?
import std.string;
import core.sys.windows.windows;
void main(string[] ar
On Saturday, 11 January 2014 at 14:10:20 UTC, Casper Færgemand
wrote:
On Saturday, 11 January 2014 at 13:46:51 UTC, Gary Willoughby
wrote:
I've seen this but the problem is not with my project but a
dependency. I only include two files from the dependency but
when my project is compiled the ent
On Saturday, 11 January 2014 at 13:46:51 UTC, Gary Willoughby
wrote:
I've seen this but the problem is not with my project but a
dependency. I only include two files from the dependency but
when my project is compiled the entire source of the dependency
is compiled and produces the error.
Is
On Saturday, 11 January 2014 at 13:46:51 UTC, Gary Willoughby
wrote:
On Saturday, 11 January 2014 at 13:01:26 UTC, Mike Parker wrote:
I think adding an "excludedSourceFiles" entry to your
package.json is is what you want. See [1].
[1] http://code.dlang.org/package-format
I've seen this but t
On Saturday, 11 January 2014 at 13:01:26 UTC, Mike Parker wrote:
I think adding an "excludedSourceFiles" entry to your
package.json is is what you want. See [1].
[1] http://code.dlang.org/package-format
I've seen this but the problem is not with my project but a
dependency. I only include tw
On Saturday, 11 January 2014 at 13:19:10 UTC, Rene Zwanenburg
wrote:
There's the --rdmd switch to use rdmd for building, so it'll
only compile imported files. I'm not sure what it uses as
'main' file though.
Yes, that's what i have to use to build correctly as dub creates
errors.
On Saturday, 11 January 2014 at 09:17:34 UTC, Philippe Sigaud
wrote:
case "Gramm.Expr":
return foo(t);
case "Gramm.FunctionCall":
return foo(t);
case "Gramm.Declaration":
return foo(t);
default:
throw new Exception(".
On Saturday, 11 January 2014 at 12:16:36 UTC, Gary Willoughby
wrote:
Is it true that dub compiles everything in the source dir
whether it's imported or not?
Using it to compile a project that seems to be the case but i
want to learn if that's true.
I draw this conclusion when investigating t
I would like to efficiently compare lots of strings. The usual
approach is String-interning as Java calls it. After a string is
"interned" they can be compared via just a single pointer
comparison instead of comparing char by char.
I have not found anything like that in Phobos. Somebody alread
On Saturday, 11 January 2014 at 12:57:38 UTC, Mike Parker wrote:
On 1/11/2014 9:01 PM, Gary Willoughby wrote:
I'm currently using the 32bit compiler on Windows which uses
optlink for
linking. I know the compiler command line accepts the -L
option to pass
arguments to the linker. So what i'm aft
On 1/11/2014 9:16 PM, Gary Willoughby wrote:
Is it true that dub compiles everything in the source dir whether it's
imported or not?
Using it to compile a project that seems to be the case but i want to
learn if that's true.
I draw this conclusion when investigating this problem:
http://forum.d
On 1/11/2014 9:01 PM, Gary Willoughby wrote:
I'm currently using the 32bit compiler on Windows which uses optlink for
linking. I know the compiler command line accepts the -L option to pass
arguments to the linker. So what i'm after is the correct way to pass an
option to optlink to link a define
Is it true that dub compiles everything in the source dir whether
it's imported or not?
Using it to compile a project that seems to be the case but i
want to learn if that's true.
I draw this conclusion when investigating this problem:
http://forum.dlang.org/thread/fvhdqcjfqfojzsyjp...@forum
I'm currently using the 32bit compiler on Windows which uses
optlink for linking. I know the compiler command line accepts the
-L option to pass arguments to the linker. So what i'm after is
the correct way to pass an option to optlink to link a defined
library.
On Linux i would use: dmd -L-L
Maybe you could use just one name and put the dispatching code inside it?
T actor(T)(T t)
{
switch (t.name)
{
case "Gramm.Expr":
return foo(t);
case "Gramm.FunctionCall":
return foo(t);
case "Gramm.Declaration":
return foo(t);
On Saturday, 11 January 2014 at 07:50:51 UTC, Jakob Ovrum wrote:
Your problem is probably better solved without string mixins,
but we'd probably need to see some code or more elaboration to
accurately suggest a solution.
enum semanticArray = ["test"];
mixin(`T ` ~ semanticArray[0] ~ `(T)(T t)
47 matches
Mail list logo
