Re: D is for Data Science
On Tuesday, 25 November 2014 at 01:10:56 UTC, Walter Bright wrote: On 11/24/2014 4:50 PM, Adam D. Ruppe wrote: On Tuesday, 25 November 2014 at 00:34:30 UTC, Walter Bright wrote: Thought I'd post this as a counterpoint to the recent please break our code thread. I would caution against putting very much weight in Reddit opinions - there's people who will never use D and just look for excuses to justify their prejudice and there's people who think they want something, but don't really have any idea (this is common in feature requests, as I'm sure you know) That comment, in particular, seems very questionable to me. dstats at least compiles out of the box and has github activity within the last few months. It has a lot of templates, so maybe actually using it would reveal compilation problems, but at quick glance it seems to work. I know it's a tough call. But I do see these sorts of comments regularly, and it is a fact that there are too many D libraries gone to seed that won't compile anymore, and that makes us look bad. If that it's the problem, it's time to go ahead with an explicit support for the work done in dfix, no? It's not a silver bullet, but it's a clear indication to the potential adopters that there's a plan, and actively indicate that definitely we care about that particular issue, common to every language. --- /Paolo
Re: D is for Data Science
On Tuesday, 25 November 2014 at 01:10:56 UTC, Walter Bright wrote: I know it's a tough call. But I do see these sorts of comments regularly, and it is a fact that there are too many D libraries gone to seed that won't compile anymore, and that makes us look bad. Or this: https://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/cmbssac It was the endless std.logger bikeshedding that finally did me in. Even if they get it into std.experimental in the next release, I'm finally done. I cancelled my projects and pulled them off dub. Is this a much better reason?
Separate compilation of Temple templates
Also, because long compile times due to template compilation are a pain for both Vibe's Diet and Temple, I've put together a repo demonstrating how to do separate compilation with Temple templates: https://github.com/dymk/temple-separate-compilation The idea is to put views in separate Dub submodules, so if the views don't change, the submodule isn't recompiled with the rest of the application.
Re: D is for Data Science
weaselcat: I see array.sort is planned for future deprecation, what does future fall under? For us that activate warnings in dmd (because for a design mistake they are disabled on default, but hopefully this will be fixed in future) in the latest github version of the compiler it gives a warning if you use the built-in sort and reverse. Unfortunately the library reverse still needs to be fixed to return the array as the built-in reverse. Bye, bearophile
Re: D is for Data Science
On Mon, 24 Nov 2014 17:10:25 -0800 Walter Bright via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: I know it's a tough call. But I do see these sorts of comments regularly, and it is a fact that there are too many D libraries gone to seed that won't compile anymore, and that makes us look bad. but D wins in overall. being one of the architects in my bussiness i was eagerly pushing D as our main development language. it's good that this thing (and some other too) happens before i succeeded. now we keep going with C++, as it fscks safety too, fscks principle of least astonishment, almost never fixes inconsistencies, but it has alot more libraries and i can hire alot more programmers with it. i'm still using D as a language for my hobbyst throw-away projects though, and D is great for such things. D wins, 'cause i *almost* stopped ranting (not only in this NG) and just accepting it as is. well, almost as is, i'm applying alot of patches over vanilla D. this, of course, makes my code incompatible with every other D compiler out here, but luckily this is not a concern anymore. signature.asc Description: PGP signature
Re: dfix 0.2.0
On Mon, 24 Nov 2014 19:22:51 +
Brian Schott via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
dfix is a tool for automatically upgrading the syntax of D source
code.
Changes since 0.1.1:
* #1 dfix will now rewrite const int foo() {} to int foo()
const {}
* #6 The C-style array syntax fix is no longer incorrectly
applied to
certain ASM statements.
* #9 You can now provide directory names as arguments to dfix in
case
you're too lazy to run find and xargs. (And really, who isn't?)
* #11 dfix is now registered on code.dlang.org.
http://code.dlang.org/packages/dfix
* Added tests.
can it detect top-level @properties and @properties with args? this
would be very valuable addition for property enforcing patch. std.file,
for example, declared top-level `isFile()`, `isDir()` and some other
functions as @properties, which is meaningless, as we have UFCS. and
this breaks with Kenji's PR 2305, for example.
signature.asc
Description: PGP signature
Re: dfix 0.2.0
On Monday, 24 November 2014 at 19:22:52 UTC, Brian Schott wrote:
dfix is a tool for automatically upgrading the syntax of D
source code.
Changes since 0.1.1:
* #1 dfix will now rewrite const int foo() {} to int foo()
const {}
* #6 The C-style array syntax fix is no longer incorrectly
applied to
certain ASM statements.
* #9 You can now provide directory names as arguments to dfix
in case
you're too lazy to run find and xargs. (And really, who
isn't?)
* #11 dfix is now registered on code.dlang.org.
http://code.dlang.org/packages/dfix
* Added tests.
When trying to build dfix with dmd git master as
dub -v
I get
Generate target libdparse (staticLibrary
/home/per/.dub/packages/libdparse-0.1.1 libdparse)
Target
'/home/per/.dub/packages/libdparse-0.1.1/.dub/build/library-debug-linux.posix-x86_64-dmd_2067-BB8147F4EBDBE336D187810BFAA258B4/liblibdparse.a'
doesn't exist, need rebuild.
Building libdparse 0.1.1 configuration library, build type
debug.
Running dmd...
dmd -lib
-of../../.dub/packages/libdparse-0.1.1/.dub/build/library-debug-linux.posix-x86_64-dmd_2067-BB8147F4EBDBE336D187810BFAA258B4/liblibdparse.a
-debug -g -w -version=Have_libdparse
-I../../.dub/packages/libdparse-0.1.1/src
-I../../.dub/packages/libdparse-0.1.1/src/
../../.dub/packages/libdparse-0.1.1/src/std/allocator.d
../../.dub/packages/libdparse-0.1.1/src/std/d/ast.d
../../.dub/packages/libdparse-0.1.1/src/std/d/entities.d
../../.dub/packages/libdparse-0.1.1/src/std/d/formatter.d
../../.dub/packages/libdparse-0.1.1/src/std/d/lexer.d
../../.dub/packages/libdparse-0.1.1/src/std/d/parser.d
../../.dub/packages/libdparse-0.1.1/src/std/lexer.d
../../.dub/packages/libdparse-0.1.1/src/std/allocator.d(4229):
Warning: instead of C-style syntax, use D-style syntax
'Allocator[(max - (min - 1)) / step] buckets'
FAIL
../../.dub/packages/libdparse-0.1.1/.dub/build/library-debug-linux.posix-x86_64-dmd_2067-BB8147F4EBDBE336D187810BFAA258B4/
libdparse staticLibrary
Error executing command run:
Why?
I guess one solution would be to make warnings non-errors right
but that seems dumb concerning what dfix can do for us regarding
auto-converting C-style arrays syntax to D-style :)
Re: dfix 0.2.0
On Tuesday, 25 November 2014 at 23:45:17 UTC, Nordlöw wrote: I guess one solution would be to make warnings non-errors right but that seems dumb concerning what dfix can do for us regarding auto-converting C-style arrays syntax to D-style :) BTW: How do I specify that a dependency package (libdparse) should be compiled with -wi instead of -w?
Re: dfix 0.2.0
On Tuesday, 25 November 2014 at 23:47:07 UTC, Nordlöw wrote: On Tuesday, 25 November 2014 at 23:45:17 UTC, Nordlöw wrote: I guess one solution would be to make warnings non-errors right but that seems dumb concerning what dfix can do for us regarding auto-converting C-style arrays syntax to D-style :) The issue trackers for dfix and libdparse are on github. BTW: How do I specify that a dependency package (libdparse) should be compiled with -wi instead of -w? You can read DUB's documentation here: http://code.dlang.org/package-format
Re: dfix 0.2.0
On Monday, 24 November 2014 at 19:22:52 UTC, Brian Schott wrote:
dfix is a tool for automatically upgrading the syntax of D
source code.
Changes since 0.1.1:
* #1 dfix will now rewrite const int foo() {} to int foo()
const {}
* #6 The C-style array syntax fix is no longer incorrectly
applied to
certain ASM statements.
* #9 You can now provide directory names as arguments to dfix
in case
you're too lazy to run find and xargs. (And really, who
isn't?)
* #11 dfix is now registered on code.dlang.org.
http://code.dlang.org/packages/dfix
* Added tests.
very good.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Monday, 24 November 2014 at 21:34:19 UTC, Walter Bright wrote: On 11/24/2014 2:20 AM, Don wrote: I believe I do understand the problem. As a practical matter, overflow checks are not going to be added for performance reasons. The performance overhead would be practically zero. All we would need to do, is restrict array slices such that the length cannot exceed ssize_t.max. This can only happen in the case where the element type has a size of 1, and only in the case of slicing a pointer, concatenation, and memory allocation. (length1 + length2) / 2 That's not an issue with length, that's an issue with doing a calculation with an insufficient bit width. Unsigned doesn't actually help, it's still wrong. For unsigned values, if length1 = length2 = 0x8000_, that gives an answer of 0. In exchange, 99% of uses of unsigned would disappear from D code, and with it, a whole category of bugs. You're not proposing changing size_t, so I believe this statement is incorrect. From the D code that I've seen, almost all uses of size_t come directly from the use of .length. But I concede (see below) that many of them come from .sizeof. Also, in principle, uint-uint can generate a runtime check for underflow (i.e. the carry flag). No it cannot. The compiler does not have enough information to know if the value is intended to be positive integer, or an unsigned. That information is lost from the type system. Eg from C, wrapping of an unsigned type is not an error. It is perfectly defined behaviour. With signed types, it's undefined behaviour. I know it's not an error. It can be defined to be an error, and the compiler can insert a runtime check. (I'm not proposing this, just saying it can be done.) But it can't do that, without turning unsigned into a different type. You'd be turning unsigned into a 'non-negative' which is a completely different type. This is my whole point. unsigned has no sign, you just get the raw bit pattern with no interpretation. This can mean several things, for example: 1. extended_non_negative is where you are using it for the positive range 0.. +0x_ Then, overflow and underflow are errors. 2. a value where the highest bit is always 0. This can be safely used as int or uint. 3. Or, it can be modulo 2^^32 arithmetic, where wrapping is intended. 4. It can be part of extended precision arithmetic, where you want the carry flag. 5. It can be just a raw bit pattern. 6. The high bit can be a sign bit. This is a signed type, cast to uint. If the sign bit ever flips because of a carry, that's an error. The type system doesn't specify a meaning for the bit pattern. We've got a special type for case 6, but not for the others. The problem with unsigned is that since it can mean so many things, as if it were a union of these possibilities. So it's not strictly typed -- you need to careful, requiring some element of faith-based programming. And signed-unsigned mismatch is really where you are implicitly assuming that the unsigned value is case 2 or 6. But, if it is one of the other cases, you get nonsense. But those signed unsigned mismatch errors only catch some of the possible cases where you may forget which interpretation you are using, and act as if it were another one. To make this clear: I am not proposing that size_t should be changed. I am proposing that for .length returns a signed type, that for array slices is guaranteed to never be negative. There'll be mass confusion if .length is not the same type as .sizeof Ah, that is a good point. .sizeof is another source of unsigned. Again, quite unnecessarily, can a single type ever actually use up half of the memory space? (It was possible in the 8 and 16 bit days, but it's hard to imagine today). Even sillier, it is nearly always known at compile time! But still, .sizeof is low-level in a way that .length is not.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Tuesday, 25 November 2014 at 07:39:44 UTC, Don wrote: No, that is not overflow. That is a carry. Overflow is when the sign bit changes. I think this discussion will be less confusing with clearing up the terminology. An overflow condition happens when the representation cannot hold the magnitude of the intended type. In floating point that is +Inf and -Inf. And underflow condition happens when the representation cannot represent the precision of small numbers. In floating point that is +0, -0 and denormal numbers, detected or undetected. Carry is an extra bit that can be considered part of the computation for a concrete machine code instruction that provides carry. Eg 32bits + 32bits = (32+1) bits. If the intended type is true Reals and the representation is integer then we get: 0u - 1u = overflow 1u / 2u = underflow Carry can be taken as an overflow condition, but it is not proper overflow if you interpret it as s part of the result that depends on the machine language instruction and use of it. For a regular ADD/SUB instruction with carry the ALU covers two intended types (signed/unsigned) and use the control register flags in a way which let's the programmer make the interpretation. Some SIMD instructions does not provide control register flags and are therefore true modular arithmetic that does not overflow by definition, but if you use them for representing a non-modular intended type then you get undetected overflow… Overflow is in relation to an interpretation: the intended type versus the internal representation and the concrete machine language instruction.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Monday, 24 November 2014 at 21:34:19 UTC, Walter Bright wrote: In exchange, 99% of uses of unsigned would disappear from D code, and with it, a whole category of bugs. You're not proposing changing size_t, so I believe this statement is incorrect. The idea is to make unsigned types opt-in, a deliberate choice of individual programmers, not forced by the language. Positive signed integers convert to unsigned integers perfectly without losing information, so mixing types will work perfectly for those who request it.
Re: Does RTTI and exceptions work in dlls on windows?
On Monday, 24 November 2014 at 20:56:29 UTC, Rainer Schuetze wrote: The different DLLs have different copies of the RTTI for the classes (you could not link them separately otherwise). Looking for base classes or derived classes only compares RTTI pointers, so it doesn't find the target class of a cast in the hierarchy inside another DLL. Maybe we can have a function, which will search the typeinfo based on type name, like C++ does it?
Re: std.experimental.logger formal review round 3
On Tuesday, 25 November 2014 at 00:37:00 UTC, Walter Bright wrote: Anyone know anything about this? https://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/cmbssac You mean the second part, about him leaving D because of the discussion about the logger?
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Monday, 24 November 2014 at 15:56:44 UTC, Andrei Alexandrescu wrote: On 11/24/14 4:54 AM, Don wrote: In D, 1u - 2u 0u. This is defined behaviour, not an overflow. I think I get what you mean, but overflow is also defined behavior (in D at least). -- Andrei Aargh! You're right. That's new, and dreadful. It didn't used to be. The offending commit is alexrp 2012-05-15 15:37:24 which only provides an unsigned example. Why are defining behaviour that is always a bug? Java makes it defined, but it has to because it doesn't have unsigned types. I think the intention probably was to improve on the C situation, where there is undefined behaviour that really should be defined. But do we really want to preclude ever having overflow checking for integers?
Re: 'int' is enough for 'length' to migrate code from x86 to x64
Don: Aargh! You're right. That's new, and dreadful. It didn't used to be. The offending commit is alexrp 2012-05-15 15:37:24 which only provides an unsigned example. Why are defining behaviour that is always a bug? Java makes it defined, but it has to because it doesn't have unsigned types. I think the intention probably was to improve on the C situation, where there is undefined behaviour that really should be defined. But do we really want to preclude ever having overflow checking for integers? +1 Bye, bearophile
DMD hackers: pragma(address): Is this possible?
I've tested some ideas with Volatile!T but there's always one remaining
problem:
In C people often define a macro to describe a MMIO location:
#define PORTB *((ubyte*)0x05)
which can then be used like this:
PORTB |= 0b1000_;
It's not really possible to represent this in D. There are workarounds,
but all have drawbacks. Naive approaches require space in the data
section. Defining PORTB as an enum ubyte* is working, but then operator
overloading doesn't work correctly (or the user always has to
dereference manually). immutable ubyte* also doesn't work because of
transitivity.
So I think we do need a way to specify this: I've got an extern
variable, and it's at this address. This is quite similar to
pragma(mangle), so in some way it seems natural to use this:
pragma(address, 0x05) extern ubyte PORTB;
But does this really make sense? What makes a variable a variable? For
example the GCC backends has builtin support for extern, static, const,
manifest variables, but no way to specify an address for an extern
variable. Is there a reason for this?
(Another solution are alias expressions but that's much more invasive.)
I've also implemented a small proof-of concept for this idea: Right now
I simply implemented the pragma and return a pointer dereference
expression from VarExp::sematic. This seems to work fine so far, but
are there other ways to access a variable without a VarExp or could
there be any other problems?
-
import gcc.builtins;
struct Noop
{
ubyte _data;
void opOpAssign(string op)(in ubyte rhs) nothrow
{
ubyte val = __builtin_volatile_load(_data);
mixin(val ~ op ~ = rhs;);
__builtin_volatile_store(_data, val);
}
}
pragma(address, 0x1000) extern Noop PORTB;
void main()
{
auto addr = PORTB;
PORTB |= 0b1000_000;
}
;; Function D main (_Dmain)
;; enabled by -tree-original
{
struct Noop * addr;
(void) (addr = 4096B);
opOpAssign (4096B, 64);
return retval = 0;
}
;; Function opOpAssign
(_D4test4Noop25__T10opOpAssignVAyaa1_7cZ10opOpAssignMFNbxhZv) ;;
enabled by -tree-original
{
ubyte val;
if (this != 0)
{
Unknown tree: void_cst
}
else
{
_d_assert_msg ({.length=9, .ptr=null this},
{.length=9, .ptr=../test.d}, 7); }
(void) (val = (ubyte) *(volatile ubyte *) this-_data);
(void) (val = val | (ubyte) rhs);
(void) (*(volatile ubyte *) this-_data = val);
}
(With -O1 this generates perfect ASM. Of course once we have this
working there are much better ways to access the registers than
simple bit manipulation)
Re: DMD hackers: pragma(address): Is this possible?
Johannes Pfau wrote in message news:m51upj$u2v$1...@digitalmars.com...
But does this really make sense? What makes a variable a variable? For
example the GCC backends has builtin support for extern, static, const,
manifest variables, but no way to specify an address for an extern
variable. Is there a reason for this?
Makes sense to me. I image gcc backends don't natively support this
because it's equivalent to casting to a pointer and dereferencing.
Do we really need it with ref return and force-inline?
pragma(always_inline)
ref ubyte PORTB() @property { return *cast(ubyte*)0x1000; }
That should also result in optimal asm, right?
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Tuesday, 25 November 2014 at 11:43:01 UTC, Don wrote: Why are defining behaviour that is always a bug? Java makes it defined, but it has to because it doesn't have unsigned types. I think the intention probably was to improve on the C situation, where there is undefined behaviour that really should be defined. Mostly to prevent optimizations based on no-overflow assumption. But do we really want to preclude ever having overflow checking for integers? Overflow checking doesn't contradict to overflow being defined. The latter simply reflects how hardware works, nothing else. And hardware works that way, because that's a fast implementation of arithmetic for general case.
Re: DMD hackers: pragma(address): Is this possible?
Am Wed, 26 Nov 2014 00:28:52 +1100
schrieb Daniel Murphy yebbliesnos...@gmail.com:
Johannes Pfau wrote in message news:m51upj$u2v$1...@digitalmars.com...
But does this really make sense? What makes a variable a variable?
For example the GCC backends has builtin support for extern,
static, const, manifest variables, but no way to specify an address
for an extern variable. Is there a reason for this?
Makes sense to me. I image gcc backends don't natively support this
because it's equivalent to casting to a pointer and dereferencing.
Do we really need it with ref return and force-inline?
pragma(always_inline)
ref ubyte PORTB() @property { return *cast(ubyte*)0x1000; }
That should also result in optimal asm, right?
Good idea, this works and results in equal ASM. A minor drawback is
that this emits an additional function (even with always inline), but
that's a problem that also occurs in other contexts and I've got a
workaround for that.
Inlining in GDC right now only works across modules when templates are
used. Templating the PORTB property doesn't work (PORTB()() is not an
lvalue when taking the address PORTB).
So I'll probably have to implement cross-module inlining then.
Re: std.experimental.logger formal review round 3
On Tuesday, 25 November 2014 at 01:12:03 UTC, Walter Bright wrote: On 11/24/2014 4:51 PM, Brian Schott wrote: On Tuesday, 25 November 2014 at 00:37:00 UTC, Walter Bright wrote: Anyone know anything about this? https://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/cmbssac You are posting to page 16 of the third iteration of a single review. I know, and the reddit comment refers to this. This discussion is indeed most unsettling to read. Third review of a much-needed module in the ecosystem, and I remember of previous attempts at logging, each time taken down because it does not satisfy the whims of top-tier D developers that would have done it differently (and of course better). What is accepted or not in Phobos no longer interest me. I can rely on interesting modules through DUB which has versionned dependencies, while Phobos has not. Better XML parsers/JSON parsers/serialization/argument parsers exist outside of Phobos currently, and in my opinion maybe they didn't belong there in the first place.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Tuesday, 25 November 2014 at 13:52:32 UTC, Kagamin wrote: Overflow checking doesn't contradict to overflow being defined. The latter simply reflects how hardware works, nothing else. And hardware works that way, because that's a fast implementation of arithmetic for general case. So you are basically saying that D does not provide modular arithmetic, but allows you to continue with the incorrect result of an overflow as a modulo representation? Because you have to choose, you cannot both have modular arithmetic and overflow at the same time for the same operator. Overflow happens because you have monotonic semantics for addition, not modular semantics. Btw, http://dlang.org/expression needs a clean up, the term underflow is not used correctly.
Re: DMD hackers: pragma(address): Is this possible?
Johannes Pfau wrote in message news:m522gv$1rav$1...@digitalmars.com...
Good idea, this works and results in equal ASM. A minor drawback is
that this emits an additional function (even with always inline), but
that's a problem that also occurs in other contexts and I've got a
workaround for that.
Awesome.
Inlining in GDC right now only works across modules when templates are
used. Templating the PORTB property doesn't work (PORTB()() is not an
lvalue when taking the address PORTB).
So I'll probably have to implement cross-module inlining then.
Will it be cross-module inlined if it's an alias to a templated function
instantation?
module a;
ref ubyte IOREG(size_t addr)() { return *cast(ubyte*)addr; }
alias PORTA = IOREG!(0x1);
alias PORTB = IOREG!(0x10001);
==
module b;
import a;
void main()
{
auto x = PORTA;
PORTB |= 7;
}
Re: std.experimental.logger formal review round 3
On Tuesday, 25 November 2014 at 14:29:12 UTC, ponce wrote: Better XML parsers/JSON parsers/serialization/argument parsers exist outside of Phobos currently, and in my opinion maybe they didn't belong there in the first place. Yes, it is often a good idea to standardize after solutions have been established. Creating a good logger is harder than it sounds like as the logger have to used by everyone or else you have to deal with N incompatible versions in the same project due to different libraries using different loggers. Starting with the interface with no performant proof of concept means you go for a long run. Starting with an existing performant solution and abstracting it into a cleaner interface would reach completion faster and with less risk of hitting gotchas later. A logger that isn't good enough for just about everyone will become dead weight as people will gravitate towards an external adhoc standard solution instead (re Tango vs Phobos).
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Tuesday, 25 November 2014 at 14:30:36 UTC, Ola Fosheim Grøstad wrote: So you are basically saying that D does not provide modular arithmetic, but allows you to continue with the incorrect result of an overflow as a modulo representation? Correctness is an emergent property - when behavior matches expectation, so overflow has variable correctness in various parts of the code.
Re: DMD hackers: pragma(address): Is this possible?
Am Wed, 26 Nov 2014 01:44:02 +1100 schrieb Daniel Murphy yebbliesnos...@gmail.com: Johannes Pfau wrote in message news:m522gv$1rav$1...@digitalmars.com... Good idea, this works and results in equal ASM. A minor drawback is that this emits an additional function (even with always inline), but that's a problem that also occurs in other contexts and I've got a workaround for that. Awesome. Inlining in GDC right now only works across modules when templates are used. Templating the PORTB property doesn't work (PORTB()() is not an lvalue when taking the address PORTB). So I'll probably have to implement cross-module inlining then. Will it be cross-module inlined if it's an alias to a templated function instantation? No, unfortunately not. The module where the template is instantiated needs to be the 'main' module. Or rather toObjfile must have been called on the function for backend inlining. Unfortunately this seems to be a complicated task.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Tuesday, 25 November 2014 at 15:42:13 UTC, Kagamin wrote: Correctness is an emergent property - when behavior matches expectation, so overflow has variable correctness in various parts of the code. I assume you are basically saying that Walter's view that matching C++ is more important than getting it right, because some people might expect C++ behaviour. Yet Ada chose a different path and is considered a better language with respect to correctness. I think it is important to get the definitions consistent and sound so they are easy to reason about, both for users and implementors. So one should choose whether the type is primarily monotonic, with incorrect values truncated into modulo N, or if the type is primarily modular. If addition is defined to be primarily monotonic it means you can optimize if(x x+1)… into if (true)…. If it is defined to be primarily modular, then you cannot.
Re: DMD hackers: pragma(address): Is this possible?
Am Wed, 26 Nov 2014 00:28:52 +1100
schrieb Daniel Murphy yebbliesnos...@gmail.com:
Johannes Pfau wrote in message news:m51upj$u2v$1...@digitalmars.com...
But does this really make sense? What makes a variable a variable?
For example the GCC backends has builtin support for extern,
static, const, manifest variables, but no way to specify an address
for an extern variable. Is there a reason for this?
Makes sense to me. I image gcc backends don't natively support this
because it's equivalent to casting to a pointer and dereferencing.
Do we really need it with ref return and force-inline?
pragma(always_inline)
ref ubyte PORTB() @property { return *cast(ubyte*)0x1000; }
That should also result in optimal asm, right?
Is taking addresses on properties still undefined? Or how exactly is it
defined? Anyway, PORTB returns the address of the PORTB function
which is a small annoyance.
Re: Does RTTI and exceptions work in dlls on windows?
On Tuesday, 25 November 2014 at 10:02:00 UTC, Kagamin wrote: On Monday, 24 November 2014 at 20:56:29 UTC, Rainer Schuetze wrote: The different DLLs have different copies of the RTTI for the classes (you could not link them separately otherwise). Looking for base classes or derived classes only compares RTTI pointers, so it doesn't find the target class of a cast in the hierarchy inside another DLL. Maybe we can have a function, which will search the typeinfo based on type name, like C++ does it? I was sure that when dll is loaded, runtimes will merge (hook) and all type info is shared between dll and application.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Tuesday, 25 November 2014 at 15:52:22 UTC, Ola Fosheim Grøstad wrote: I assume you are basically saying that Walter's view that matching C++ is more important than getting it right, because some people might expect C++ behaviour. Yet Ada chose a different path and is considered a better language with respect to correctness. C++ legacy is huge especially in culture. That said, the true issue is in beliefs (which probably stem from 16-bit era). Can't judge Ada, have no experience with it, though examples of Java and .net show how marginal is importance of unsigned types. I think it is important to get the definitions consistent and sound so they are easy to reason about, both for users and implementors. So one should choose whether the type is primarily monotonic, with incorrect values truncated into modulo N, or if the type is primarily modular. In this light examples by Marco Leise become interesting, he tries to evade wrapping even for unsigned types, so, yes types are primarily monotonic and optimized for small values. If addition is defined to be primarily monotonic it means you can optimize if(x x+1)… into if (true)…. If it is defined to be primarily modular, then you cannot. Such optimizations have a bad reputation. If they were more conservative and didn't propagate back in code flow, the situation would be probably better. Also isn't (x x+1) a suspicious expression, is it a good idea to mess with it?
Re: Does RTTI and exceptions work in dlls on windows?
Am 24.11.2014 19:20, schrieb MrSmith: I've got little test here https://gist.github.com/MrSmith33/8750dd43c0843d45ccf8#file-sharedmodule2-d-L17-L29. I have one application and two dlls. Application loads both dlls, calls their factory functions and then passes each IModule instance that it got from factories to those modules. Modules then try to cast those IModule refs back to their real interfaces (ISharedModule1) but i am getting null there. A have found a workaround for this by returning a void* pointer to real interface and it back when needed. Another, and more major issue is, that when exception is thrown application fail immediately. Is it broken on windows, or it is me doing it wrong? Dlls are generally broken on windows. If you hack around in druntime (e.g. the casting routines) you can get it to work to some degree, but you are going to be happier if you just stay away from it.
Re: DMD hackers: pragma(address): Is this possible?
Johannes Pfau wrote in message news:m52aq3$dla$1...@digitalmars.com... Is taking addresses on properties still undefined? Or how exactly is it defined? Anyway, PORTB returns the address of the PORTB function which is a small annoyance. Urrgh I forgot about that. Hopefully @property will be fixed one of these years.
Re: DMD hackers: pragma(address): Is this possible?
Johannes Pfau wrote in message news:m5288s$l8$1...@digitalmars.com... No, unfortunately not. The module where the template is instantiated needs to be the 'main' module. Or rather toObjfile must have been called on the function for backend inlining. Unfortunately this seems to be a complicated task. Would it make sense to always call toObjfile for always-inline template functions? That should be harmless...
Re: Does RTTI and exceptions work in dlls on windows?
On Tuesday, 25 November 2014 at 18:39:56 UTC, Benjamin Thaut wrote: Am 24.11.2014 19:20, schrieb MrSmith: I've got little test here https://gist.github.com/MrSmith33/8750dd43c0843d45ccf8#file-sharedmodule2-d-L17-L29. I have one application and two dlls. Application loads both dlls, calls their factory functions and then passes each IModule instance that it got from factories to those modules. Modules then try to cast those IModule refs back to their real interfaces (ISharedModule1) but i am getting null there. A have found a workaround for this by returning a void* pointer to real interface and it back when needed. Another, and more major issue is, that when exception is thrown application fail immediately. Is it broken on windows, or it is me doing it wrong? Dlls are generally broken on windows. If you hack around in druntime (e.g. the casting routines) you can get it to work to some degree, but you are going to be happier if you just stay away from it. Is there a bugzilla issue for this? And what is the status of windows dlls?
Re: Named parameter builder pattern for template parameters
On Sat, 22 Nov 2014 17:36:02 +0100 Artur Skawina via Digitalmars-d digitalmars-d@puremagic.com wrote: You can just use a struct and D's phenomenal compile time programming possibilities. ;) heh. thank you, with `alias` and function instead of struct my compile-time formatted writter now works with both GDC and DMD. yay! signature.asc Description: PGP signature
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Tuesday, 25 November 2014 at 18:24:29 UTC, Kagamin wrote: C++ legacy is huge especially in culture. That said, the true issue is in beliefs (which probably stem from 16-bit era). Can't judge Ada, have no experience with it, though examples of Java and .net show how marginal is importance of unsigned types. Unsigned bytes are important, and I personally tend to make just about everything unsigned when dealing with C-like languages because that makes me aware of the pitfalls and I avoid the signedness issue. The downside is that it takes extra work to get the evaluation order right and you have to take extra care to make sure loops terminate correctly by being very conscious about +-1 issues when terminating around zero. But I don't really think C++ legacy is a good reason to keep implicit coercion no matter what programming style one has. Coercion is generally something I try to avoid, even explicitly, so why would I want the compiler to do it with no warning? Such optimizations have a bad reputation. If they were more conservative and didn't propagate back in code flow, the situation would be probably better. Also isn't (x x+1) a suspicious expression, is it a good idea to mess with it? It is just an example, it could be the result of substituting aliased values. Anyway, I think it is important to not only define what happens if you add 1 to 0x, but also define whether that result is considered in correspondence with the type. If it isn't a correct value for the type, then the programmer will have to make no assumptions that optimizations will heed the resulting incorrect value. The only acceptable alternative is to have the language specification explicitly define the type as modular and overflow free. If not you end up with weak typing…? I personally would take the monotonic optimizations and rather have a separate bit-fidling type that provides a clean builtin swiss-army-knife toolset that gives close to direct access to the whole arsenal that the CPU instruction set provides (carry, ROL/ROR, bitcounts etc).
Re: std.experimental.logger formal review round 3
On 11/25/2014 2:26 AM, Robert burner Schadek wrote: On Tuesday, 25 November 2014 at 00:37:00 UTC, Walter Bright wrote: Anyone know anything about this? https://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/cmbssac You mean the second part, about him leaving D because of the discussion about the logger? Yes.
Re: Comparing Parallelization in HPC with D, Chapel, and Go
On Sun, 2014-11-23 at 13:09 -0800, Ziad Hatahet via Digitalmars-d wrote: On Sat, Nov 22, 2014 at 7:17 AM, Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: I have emailed the author. Keep us posted! The author is currently having a vacation. He has though sent me the codes. I shall review them and report back to him, not publicly at this stage. When back from vacation his intention is to set the codes up for public availability, and hence wider review and debate. At this point the D community (and I hope the Go community) at large will be able to constructively chip in suggestions. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Does RTTI and exceptions work in dlls on windows?
Am 25.11.2014 21:46, schrieb MrSmith: On Tuesday, 25 November 2014 at 18:39:56 UTC, Benjamin Thaut wrote: Am 24.11.2014 19:20, schrieb MrSmith: I've got little test here https://gist.github.com/MrSmith33/8750dd43c0843d45ccf8#file-sharedmodule2-d-L17-L29. I have one application and two dlls. Application loads both dlls, calls their factory functions and then passes each IModule instance that it got from factories to those modules. Modules then try to cast those IModule refs back to their real interfaces (ISharedModule1) but i am getting null there. A have found a workaround for this by returning a void* pointer to real interface and it back when needed. Another, and more major issue is, that when exception is thrown application fail immediately. Is it broken on windows, or it is me doing it wrong? Dlls are generally broken on windows. If you hack around in druntime (e.g. the casting routines) you can get it to work to some degree, but you are going to be happier if you just stay away from it. Is there a bugzilla issue for this? And what is the status of windows dlls? Yes there is: https://issues.dlang.org/show_bug.cgi?id=9816 Also: http://wiki.dlang.org/DIP45 I'm currently working on it, but I can not promise anything. Also its unclear how long its going to take to get it merged once its actually working. Kind Regards Benjamin Thaut
Re: Does RTTI and exceptions work in dlls on windows?
Am 25.11.2014 21:46, schrieb MrSmith: Is there a bugzilla issue for this? And what is the status of windows dlls? If you want a bit more dll support right now, I suggest that you take a look at these changes and merge them into your own version of druntime: https://github.com/Ingrater/druntime/commit/7e54eac91dd34810913cfe740e709b18cbbc00d6 Kind Regards Benjamin Thaut
Re: DerelictOrg and SDL_Mixer
On 11/25/2014 9:26 AM, torea wrote: Oh.. I didn't know about the DerelictSDL2Mixer.load()! I thought the initialization of sdl_mixer was done with DerelictSDL2.load() Every time you call DerelictFoo.load, you are loading exactly one library. You will never see a Derelict package that loads multiple libraries in one call.
Re: A nice D coding pattern
On Monday, 24 November 2014 at 22:50:33 UTC, bearophile wrote: In some D programs I'm using this coding pattern: You can see an example of this pattern that I've used here: http://rosettacode.org/wiki/Solve_a_Hopido_puzzle#D Bye, bearophile Awesome gist and great pattern ! Sometimes your forum post doesn't get any answers but you can be sure I read and enjoy them all (and I'm sure I am not alone). Keep it up ! :)
Re: A nice D coding pattern
On Monday, 24 November 2014 at 22:50:33 UTC, bearophile wrote: And the @disable this() assures that a struct is correctly initialized by the constructor. In the statement: @disable this() May I understand that you're disabling the default constructor of the struct to use your own constructor? Matheus.
Re: A nice D coding pattern
MattCoder: May I understand that you're disabling the default constructor of the struct to use your own constructor? Right. So the instance data of the struct is more likely correct when you call its methods. Bye, bearophile
Reducing Pegged ASTs
Is there a way to (on the fly) reduce Pegged parse results such as C [0, 6][int, x, ;] +-C.TranslationUnit [0, 6][int, x, ;] +-C.ExternalDeclaration [0, 6][int, x, ;] +-C.Declaration [0, 6][int, x, ;] +-C.DeclarationSpecifiers [0, 4][int] | +-C.TypeSpecifier [0, 4][int] +-C.InitDeclaratorList [4, 5][x] +-C.InitDeclarator [4, 5][x] +-C.Declarator [4, 5][x] +-C.DirectDeclarator [4, 5][x] +-C.Identifier [4, 5][x] to C [0, 6][int, x, ;] +-C.TranslationUnit [0, 6][int, x, ;] +-C.ExternalDeclaration [0, 6][int, x, ;] +-C.Declaration [0, 6][int, x, ;] +-C.TypeSpecifier [0, 4][int] +-C.Identifier [4, 5][x] and still, when needed, be able query that C.Identifier is an instance of C.DirectDeclarator etc? If not this seems like a cool feature to have ;) I guess it would reduce memory requirements by about a magnitude right?
Re: Reducing Pegged ASTs
On Tuesday, 25 November 2014 at 15:12:39 UTC, Nordlöw wrote: I guess it would reduce memory requirements by about a magnitude right? Correction: For consistency we probably want this example to be reduced to +-C.Declaration [0, 6][int, x, ;] +-C.TypeSpecifier [0, 4][int] +-C.Identifier [4, 5][x]
Re: Reducing Pegged ASTs
On Tuesday, 25 November 2014 at 15:15:40 UTC, Nordlöw wrote: +-C.Declaration [0, 6][int, x, ;] +-C.TypeSpecifier [0, 4][int] +-C.Identifier [4, 5][x] Correction again: +-C.Declaration [0, 6][int, x, ;] +-C.TypeSpecifier [0, 4][int] +-C.Identifier [4, 5][x]
Re: A nice D coding pattern
That's a neat trick, although if preconditions were able to be run at compile time when possible you wouldn't have to resort to using enum to force CTFE (you've talked a bit about this before I remember). Thinking about something like a good ranged number implementation, we can now get almost all the way there. Manually having to specify enum is still an undesirable.
Re: A nice D coding pattern
On Tuesday, 25 November 2014 at 13:56:23 UTC, bearophile wrote: Right. So the instance data of the struct is more likely correct when you call its methods. Thanks. - Well I'd like to see more of these tips. My current code in D looks like C++ and of course I sure that I'm not extracting the power of D. In fact lately I was looking around the Phobos source to open my mind for new features. Matheus.
Re: Dub / Derelict confusion
On Sunday, 23 November 2014 at 00:37:07 UTC, Mike Parker wrote: On 11/23/2014 3:52 AM, Paul wrote: Whenever I try to learn a new language I always seem to end up fighting the OS or the IDE rather than spending time where I should. Therefore, I'm going to put this idea on hold and stick to console programs for a while (tried to install ncurses as well earlier but dub doesn't like the ~master setting in dub.json - grrr!). DUB used to support using github branches for the version, but it was deprecated not so long ago. There's a workaround for it, though, IIRC. If you search the dub forums [1], or ask about it there, you should get an answer. [1] http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/ I've finally got this working - the SDL FAQ page sort of identifies the cause; the xorg dev files have to be installed before building SDL otherwise you end up with a 'non-x' version (not sure what you'd do with that!). I built SDL first and then tried installing the missing x development files.
Re: A nice D coding pattern
void main() {
// Created at compile-time.
enum something = .Foo;
I don't think we should encourage UFCS with typenames or
uppercase names. If anything, it does not provide any benefit in
this case and Foo(.) is much more clearer without any
syntactical overhead.
Re: A nice D coding pattern
On 11/25/2014 01:51 AM, matovitch wrote: On Monday, 24 November 2014 at 22:50:33 UTC, bearophile wrote: Sometimes your forum post doesn't get any answers but you can be sure I read and enjoy them all (and I'm sure I am not alone). Keep it up ! :) Same here! Thank you, bearophile! :) An artist friend of mine is working on the book cover for Programming in D. Initially, I thought of having a subtle reference to a bear. :) (We are not pursuing that idea though.) Ali
Re: windows linker error
On Tuesday, 25 November 2014 at 21:22:24 UTC, Vlad Levenfeld wrote: On Windows 7 I have built dmd (using the vcxproj), druntime (win64.mak) and phobos (win64.mak). I went into sc.ini and set the LINKCMD to point to Visual Studio 12.0's linker. When I try to compile anything with dmd, I get LINK : fatal error LNK1181: cannot open input file 'test,,nul,user32+kernel132/noi;.obj' I'm pretty sure else is ok as I didn't see any errors while I was building. What can I try next? Solved it by pointing to the dmc linker instead. Now I have LNK1104: cannot open file 'shell32.lib' I'm compiling with -m64... couldn't compile 32-bit phobos because of missing zlib.
Re: Reducing Pegged ASTs
On 2014-11-25 10:12, Nordlöw wrote: Is there a way to (on the fly) reduce Pegged parse results such as I've made an asn.1 parser using pegged tree map, it's not so complex and does the reducing as well. https://github.com/globecsys/asn1.d Most of the meat is in asn1/generator/ In short, it's much easier when you put all the info in the same object, in this case it's an AEntity: https://github.com/globecsys/asn1.d/blob/master/asn1/generator/asntree.d#L239 When the whole tree is done that way, you can easily traverse it and move nodes like a linked list.. I've made a helper function here: https://github.com/globecsys/asn1.d/blob/master/asn1/generator/asntree.d#L10 You can see it being used here: https://github.com/globecsys/asn1.d/blob/38bd1907498cf69a08604a96394892416f7aa3bd/asn1/generator/asntree.d#L109 and then here: https://github.com/globecsys/asn1.d/blob/master/asn1/generator/generator.d#L500 Also, the garbage collector really makes it easy to optimize memory usage, ie. when you use a node in multiple places and need to re-order the tree elements. I still have a bunch of work to do, and I intend on replacing botan's ASN1 functionalities with this and a DER serialization module. Beware, the pegged structure isn't insanely fast to parse because of the recursion limits I implemented very inefficiently because I was too lazy to translate the standard asn.1 BNF into PEG.. Also, the bigger bottleneck would be error strings. For a 1-2 months of work (incl. learning ASN.1), I'm very satisfied with the technology involved and would recommend intermediate structures with traversal helpers.
Re: DerelictOrg and SDL_Mixer
On 11/26/2014 4:42 AM, torea wrote: ok, so basically, each time I want to access some specific functions imported like: import derelict.sdl2.foo; I have to load it like this? DerelictSDL2foo.load(); Don't think of it that way. Think of it this way: you have to load every library you want to use. SDL2_mixer is a library, SDL2_image is a library, SDL2_ttf is a library, and so on. You have to load them individually. DerelictSDL2 binds to SDL2, DerelictSDL2Mixer binds to SDL2_mixer and so on. After that I also got a SDL_mixer error : No such device. This was solved by installing libasound-dev and libpulse-dev and recompiling SDL2. Now I have sound!! The Derelict packages are all just bindings to C libraries and nothing more. To use those libraries, you need to install their dependencies on each platform you need to use them on. If you don't know what the dependencies are, you should visit the website or support forums for that library.
Re: Dub / Derelict confusion
On 11/26/2014 3:27 AM, Paul wrote: I've finally got this working - the SDL FAQ page sort of identifies the cause; the xorg dev files have to be installed before building SDL otherwise you end up with a 'non-x' version (not sure what you'd do with that!). I built SDL first and then tried installing the missing x development files. Yes, the development files aren't going to help you if you've already built the project! They need to be available for the compile link process.
Re: windows linker error
On Tuesday, 25 November 2014 at 23:08:07 UTC, Vlad Levenfeld wrote: On Tuesday, 25 November 2014 at 21:22:24 UTC, Vlad Levenfeld wrote: On Windows 7 I have built dmd (using the vcxproj), druntime (win64.mak) and phobos (win64.mak). I went into sc.ini and set the LINKCMD to point to Visual Studio 12.0's linker. When I try to compile anything with dmd, I get LINK : fatal error LNK1181: cannot open input file 'test,,nul,user32+kernel132/noi;.obj' I'm pretty sure else is ok as I didn't see any errors while I was building. What can I try next? Solved it by pointing to the dmc linker instead. Now I have LNK1104: cannot open file 'shell32.lib' I'm compiling with -m64... couldn't compile 32-bit phobos because of missing zlib. Just so we're clear, you're trying to compile for Win64 COFF? It sounds like you don't have something about your environment set up right, as Win64 requires the MSVC toolchain and some configuration if you use the dmd zip. Did you install from the exe installer or are you using the zip? The dmc linker is not going to work, as it only does OMF. You may find this page helpful, though it may be a bit outdated: http://wiki.dlang.org/Installing_DMD_on_64-bit_Windows_7_%28COFF-compatible%29
Re: DerelictOrg and SDL_Mixer
On Wednesday, 26 November 2014 at 01:25:51 UTC, Mike Parker wrote: Don't think of it that way. Think of it this way: you have to load every library you want to use. SDL2_mixer is a library, SDL2_image is a library, SDL2_ttf is a library, and so on. You have to load them individually. DerelictSDL2 binds to SDL2, DerelictSDL2Mixer binds to SDL2_mixer and so on. OK! Somehow I had overlooked the most obvious documentation on DerelictSDL2: the readme.md file on the github repository page which displays these informations.. Sorry! The Derelict packages are all just bindings to C libraries and nothing more. To use those libraries, you need to install their dependencies on each platform you need to use them on. If you don't know what the dependencies are, you should visit the website or support forums for that library. Yes, it was an issue unrelated to D or DerelictOrg but still some problem encountered by clueless me on its quest to use SDL_Mixer functions with D.. This might be of some help for a beginner like me who had difficulties to find some straightforward documentation to set everything up. The SDL and SDL_mixer websites did not help much (..or I overlooked some stuffs again).
Cheap Kitchen Sale
Cheap Kitchen Sale. Thirty Ex Display Kitchens To Clear. www.exdisplaykitchens1.co.uk £ 595 Each with appliances.Tel 01616-694785
Re: windows linker error
On Wednesday, 26 November 2014 at 01:35:20 UTC, Joakim wrote:
On Tuesday, 25 November 2014 at 23:08:07 UTC, Vlad Levenfeld
wrote:
On Tuesday, 25 November 2014 at 21:22:24 UTC, Vlad Levenfeld
wrote:
On Windows 7 I have built dmd (using the vcxproj), druntime
(win64.mak) and phobos (win64.mak).
I went into sc.ini and set the LINKCMD to point to Visual
Studio 12.0's linker.
When I try to compile anything with dmd, I get
LINK : fatal error LNK1181: cannot open input file
'test,,nul,user32+kernel132/noi;.obj'
I'm pretty sure else is ok as I didn't see any errors while I
was building. What can I try next?
Solved it by pointing to the dmc linker instead. Now I have
LNK1104: cannot open file 'shell32.lib'
I'm compiling with -m64... couldn't compile 32-bit phobos
because of missing zlib.
Just so we're clear, you're trying to compile for Win64 COFF?
It sounds like you don't have something about your environment
set up right, as Win64 requires the MSVC toolchain and some
configuration if you use the dmd zip. Did you install from the
exe installer or are you using the zip?
The dmc linker is not going to work, as it only does OMF. You
may find this page helpful, though it may be a bit outdated:
http://wiki.dlang.org/Installing_DMD_on_64-bit_Windows_7_%28COFF-compatible%29
I'm compiling the latest build from github.
(I normally stay up to date with the current builds on 64bit
Debian and everything works more or less without a hitch there,
but now I need to get some of my tools working in a Windows
environment)
I'm not really sure what my options are regarding the COFF or
what they mean, 64-bit is really the only requirement (mostly
because I can't get the 32-bit stuff to compile).
I've got Visual Studio Premium, I tried to install from the exe
at one point and got Visual D in the process (and this did work,
except that the code I need is built against the latest
dmd/druntime/phobos builds).
Installing it from the instructions, IIRC, also worked for me,
but again, the version.
So I used the dmd visual studio project to build dmd, then built
druntime and phobos with Digital Mars make;
I had previously tried to use dmc to build dmd but couldn't get
it to work.
Anyway, I manage to build successfully but then I get this linker
error when I try to run dmd on some test.d consisting of void
main (){}.
I've gone into sc.ini and pulled out the ;VC2012 comments to
expose the LIB instruction (to fix a different problem) and this
is the point that I've gotten stuck at.
Uninitialized object hangs without warning.
I ran into this a while ago and have already moved on, but I had
a class such as this
Class MyClass{
this(){}
void someFunction(){
//body
}
}
And in my app I had something like
MyClass classObject;
classObject.someFunction();
When I compile, no warnings or errors. But when I run the
application it just hangs at the function call. Eventually the
app kills itself.
The problem is classObject is never initialized. This drove me
crazy for an entire evening before I added a bunch of debug lines
to narrow it down and then visually saw what the problem was.
I feel there should be some type of warning or error when
compiling, or an error when we get to classObject.someFunction().
This is on 2.065, so forgive me if this has already been
addressed. Again, it's been a while since I actually encountered
the error, so not sure if i missed an aspect of it.
Re: Uninitialized object hangs without warning.
On Wednesday, 26 November 2014 at 05:24:49 UTC, Bear Cherian
wrote:
I ran into this a while ago and have already moved on, but I
had a class such as this
Class MyClass{
this(){}
void someFunction(){
//body
}
}
And in my app I had something like
MyClass classObject;
classObject.someFunction();
When I compile, no warnings or errors. But when I run the
application it just hangs at the function call. Eventually the
app kills itself.
The problem is classObject is never initialized. This drove me
crazy for an entire evening before I added a bunch of debug
lines to narrow it down and then visually saw what the problem
was.
I feel there should be some type of warning or error when
compiling, or an error when we get to
classObject.someFunction().
This is on 2.065, so forgive me if this has already been
addressed. Again, it's been a while since I actually
encountered the error, so not sure if i missed an aspect of it.
This *does* cause an error on 2.065:
http://dpaste.dzfl.pl/0d6663890081
Or did you mistakenly type Class instead of class? In the
above code, when you replace Class with class, it runs and
then segfaults. Either way, there is no hang.
Where did you install the compiler from? This is definitely a
problem on your end.
Re: Reducing Pegged ASTs
On Tue, Nov 25, 2014 at 4:12 PM, Nordlöw digitalmars-d-learn@puremagic.com wrote: Is there a way to (on the fly) reduce Pegged parse results such as C [0, 6][int, x, ;] +-C.TranslationUnit [0, 6][int, x, ;] +-C.ExternalDeclaration [0, 6][int, x, ;] +-C.Declaration [0, 6][int, x, ;] +-C.DeclarationSpecifiers [0, 4][int] | +-C.TypeSpecifier [0, 4][int] +-C.InitDeclaratorList [4, 5][x] +-C.InitDeclarator [4, 5][x] +-C.Declarator [4, 5][x] +-C.DirectDeclarator [4, 5][x] +-C.Identifier [4, 5][x] to C [0, 6][int, x, ;] +-C.TranslationUnit [0, 6][int, x, ;] +-C.ExternalDeclaration [0, 6][int, x, ;] +-C.Declaration [0, 6][int, x, ;] +-C.TypeSpecifier [0, 4][int] +-C.Identifier [4, 5][x] and still, when needed, be able query that C.Identifier is an instance of C.DirectDeclarator etc? The reducing can be done, either with operators or semantic actions. IIRC there is a free function in Pegged that does it. I did not automate it, because every time I cut down severely a parse tree, I later regret it because I lost information that way. Cutting while still retaining original info (who is this node's ancestor) is more difficult: you would have to store it somewhere anyhow. You cannot create node classes to represent the hierarchy, because of loops in the grammar: an Identifier can have many different ancestors. Note also that Pegged produces parse trees (complete parsing information), not ASTs. ASTs would indeed be much smaller, but we would have to define what are the master nodes in the D grammar. If not this seems like a cool feature to have ;) I guess it would reduce memory requirements by about a magnitude right? If you want to remember the intermediate nodes you cut down, not really, since you still need to store them somehow. I think what's consuming memory right now is that I duplicate the matched strings at each level, even concatenating them at the higher levels. I should let them only in the 'leaves' of the tree (heck, like an AST). Halas, I've no free time to code anything in D these days... but of course, feel free to push any pull request you might have!
[Issue 13773] std.traits.ReturnType does not resolve inout
https://issues.dlang.org/show_bug.cgi?id=13773 Martin Nowak c...@dawg.eu changed: What|Removed |Added Priority|P1 |P2 Severity|enhancement |normal --
[Issue 13773] New: std.traits.ReturnType does not resolve inout
https://issues.dlang.org/show_bug.cgi?id=13773
Issue ID: 13773
Summary: std.traits.ReturnType does not resolve inout
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: c...@dawg.eu
cat bug.d CODE
import std.traits;
struct Foo
{
inout(int)[] keys() inout @property
{
return null;
}
}
void main()
{
Foo m;
const(Foo) c;
immutable(Foo) i;
pragma(msg, typeof(m.keys), , , ReturnType!(m.keys));
pragma(msg, typeof(c.keys), , , ReturnType!(c.keys));
pragma(msg, typeof(i.keys), , , ReturnType!(i.keys));
}
CODE
dmd -c bug
int[], inout(int)[]
const(int)[], inout(int)[]
immutable(int)[], inout(int)[]
--
[Issue 13773] std.traits.ReturnType does not resolve inout
https://issues.dlang.org/show_bug.cgi?id=13773 --- Comment #1 from Kenji Hara k.hara...@gmail.com --- I think this should be marked as invalid or changed as a compiler enhancement, because: 1. ReturnType takes an alias (through the index 0 of the TupleParameter). 2. Currently alias parameter cannot handle the runtime context of the expression, so ReturnType!(m.keys), ReturnType!(c.keys), and ReturnType!(i.keys) are perfectly same with ReturnType!(Foo.keys). 3. The return type of Foo.keys is inout(int)[]. --
[Issue 13759] VS2010 Win64 linker path wrong
https://issues.dlang.org/show_bug.cgi?id=13759 --- Comment #4 from Sobirari Muhomori dfj1es...@sneakemail.com --- On my installation of VS2010 vcvars64.bat adds Common7\IDE to path, but VC\BIN\amd64 comes first, so 64-bit mspdb100.dll is picked from there. --
[Issue 13755] core.sys.linux.stdio, std.stdio.File: fopencookie, fmemopen missing
https://issues.dlang.org/show_bug.cgi?id=13755 --- Comment #6 from Danny Milosavljevic danny.m...@gmail.com --- Pull request https://github.com/D-Programming-Language/druntime/pull/1045 --
[Issue 13754] src/std/mmfile.d: MmFile neither has ioctl nor a way to get the fd
https://issues.dlang.org/show_bug.cgi?id=13754 --- Comment #1 from Danny Milosavljevic danny.m...@gmail.com --- I'm trying to implement that right now. Is there are way not to repeat the .ioctl signature in the (potential) member function MmFile.ioctl ? Like ioctl = .ioctl fileno; ? Also, there are many different prototypes for ioctl in core/sys/posix/sys/ioctl.d . Do I just choose a superset? Is ulong.sizeof = c_ulong.sizeof always ? Is ulong.sizeof = int.sizeof always ? (Then I'd use int ioctl(ulong request, ...) as the member function, if really necessary) --
[Issue 13764] std.getopt: throw an UnknownOptionException rather than Exception
https://issues.dlang.org/show_bug.cgi?id=13764 Danny Milosavljevic danny.m...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Danny Milosavljevic danny.m...@gmail.com --- It's already fixed in git phobos master, there's a GetOptException now. Still have to do string comparison to find out what happened (required option missing vs. unrecognized option). Oh well. --
[Issue 13774] New: Multiple definition of `conv_50c_dc8` with three libraries and `std.file` import
https://issues.dlang.org/show_bug.cgi?id=13774 Issue ID: 13774 Summary: Multiple definition of `conv_50c_dc8` with three libraries and `std.file` import Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: regression Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: verylonglogin@gmail.com The first library is Phobos. This code should build fine: m1.d m2.d: --- import std.file; --- Command (for Windows): --- dmd -debug -lib m1.d dmd -debug -lib m2.d m1.lib --- m2.lib: Error: multiple definition of conv_50c_dc8: _D3std4conv52__T18emplaceInitializerTSАЕдfile15DirIterato∙АГкZАФ▒FNaNbNcNeKАЬ║4iАГ▓yАЫв and conv: _D3std4conv52__T18emplaceInitializerTSАЕдfile15DirIterato∙АГкZАФ▒FNaNbNcNeKАЬ║4iАГ▓yАЫв --- (command output is probably encoded in CP1251) This issue almost blocks Phobos usage in real projects as it breaks building libraries and linker error doesn't give any clue of its reason. Also see Issue 13359. Note: this report is about Phobos regression preventing its usage. Underlying compiler bug is some critical bug triggered by current Phobos version. Tools versions: dmd: c0e814350948feac34946c29186d17518ea954dd druntime: 2350ee4ec77d7b919454eb2f16d91b23c3891cb6 phobos: e46ccaae82d6ddbd0c98ac233562204c7007f296 --
[Issue 13359] Multiple definition of `format_c_5b3` with three libraries and local imports
https://issues.dlang.org/show_bug.cgi?id=13359 --- Comment #1 from Denis Shelomovskij verylonglogin@gmail.com --- So now probably because of this issue we have Issue 13774 which makes current Phobos almost unusable. --
[Issue 13774] Multiple definition of `conv_50c_dc8` with three libraries and `std.file` import
https://issues.dlang.org/show_bug.cgi?id=13774 Denis Shelomovskij verylonglogin@gmail.com changed: What|Removed |Added Keywords||link-failure, rejects-valid --
[Issue 13775] New: Broken explicit casting of dynamic array slices of known size to static array of different type
https://issues.dlang.org/show_bug.cgi?id=13775
Issue ID: 13775
Summary: Broken explicit casting of dynamic array slices of
known size to static array of different type
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: ice, rejects-valid
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: verylonglogin@gmail.com
This code used to compile:
---
void main()
{
ubyte[4] ubytes;
byte[2] bytes = cast(byte[2]) ubytes[0 .. 2];
}
---
main.d(4): Error: e2ir: cannot cast ubytes[0..2] of type ubyte[] to type
byte[2]
---
In case it was an accept-invalid bug, what is the reason to disallow the
feature and break user code without any deprecation message and with such
unpleasant minor ICE message?
--
[Issue 13764] std.getopt: throw an UnknownOptionException rather than Exception
https://issues.dlang.org/show_bug.cgi?id=13764 hst...@quickfur.ath.cx changed: What|Removed |Added Severity|trivial |enhancement --
[Issue 13764] std.getopt: throw an UnknownOptionException rather than Exception
https://issues.dlang.org/show_bug.cgi?id=13764 hst...@quickfur.ath.cx changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #2 from hst...@quickfur.ath.cx --- I think this is a worthwhile enhancement request. Reopening. --
[Issue 13775] Broken explicit casting of dynamic array slices of known size to static array of different type
https://issues.dlang.org/show_bug.cgi?id=13775 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #1 from hst...@quickfur.ath.cx --- I don't think any ICE is ever deliberate! :-) It's probably a breakage caused by fixing other parts of the compiler. --
[Issue 13776] New: Incorrect recursive alias declaration error with `__traits(compiles, ...)`
https://issues.dlang.org/show_bug.cgi?id=13776
Issue ID: 13776
Summary: Incorrect recursive alias declaration error with
`__traits(compiles, ...)`
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: verylonglogin@gmail.com
This code used to compile:
---
enum t1(T) = __traits(compiles, { T; });
enum t2(A...) = 1;
template t3()
{
struct S;
alias t3 = t2!(t1!S);
}
void main()
{
alias t = t3!();
}
---
main.d(8): Error: alias main.t3!().t3 recursive alias declaration
main.d(8): Error: template instance t2!(t1!(S)) recursive template expansion
main.d(8): Error: alias main.t3!().t3 recursive alias declaration
main.d(8): Error: alias main.t3!().t3 recursive alias declaration
main.d(8): Error: template instance main.t1!(S) error instantiating
main.d(13):instantiated from here: t3!()
---
--
[Issue 13763] std.string.representation of immutables
https://issues.dlang.org/show_bug.cgi?id=13763 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 13753] src/std/process.d: _spawnvp error handling is broken
https://issues.dlang.org/show_bug.cgi?id=13753 --- Comment #4 from Danny Milosavljevic danny.m...@gmail.com --- Also, both the OSX and the Posix version of browse in the same file are broken in the same way... --
[Issue 6607] critical_.d and critical.c use double check locking the wrong way
https://issues.dlang.org/show_bug.cgi?id=6607 hst...@quickfur.ath.cx changed: What|Removed |Added CC|hst...@quickfur.ath.cx | --
[Issue 13696] Missing entry for unicode code point literals on the lexer page
https://issues.dlang.org/show_bug.cgi?id=13696 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||pull --- Comment #1 from hst...@quickfur.ath.cx --- https://github.com/D-Programming-Language/dlang.org/pull/710 --
[Issue 2525] Can't use `override` when implementing abstract base class's interface function
https://issues.dlang.org/show_bug.cgi?id=2525 --- Comment #8 from Andrej Mitrovic andrej.mitrov...@gmail.com --- Shame on you, Andrej Mitrovic! I totally support this now, perhaps not so much 'override' as wanting a new 'implements' keyword. But the distinction is so pale, and the real benefit is really *knowing* that a method is actually part of a base class / interface API, so I'm now definitely in huge favor of allowing (and perhaps even *requiring*) override for implementing keywords. --
