Sorry should add this is on 2.066.0-rc2 and it used to work on
2.064.
Cheers,
uri
On Tuesday, 12 August 2014 at 06:21:19 UTC, uri wrote:
Hi,
I'm trying to allow implicit conversions for my own type
happening. I have the following:
import std.math;
import std.traits;
struct S(T)
Hi,
I'm trying to allow implicit conversions for my own type
happening. I have the following:
import std.math;
import std.traits;
struct S(T)
if(isFloatingPoint!T)
{
T val;
alias val this;
}
void main()
{
auto s = S!float();
assert(isNaN(s));
s = 10.0;
On Tue, 12 Aug 2014 06:21:17 +
uri via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
Hi,
I'm trying to allow implicit conversions for my own type
happening. I have the following:
import std.math;
import std.traits;
struct S(T)
if(isFloatingPoint!T)
{
T
On Tuesday, 12 August 2014 at 06:37:45 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
On Tue, 12 Aug 2014 06:21:17 +
uri via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
Hi,
I'm trying to allow implicit conversions for my own type
happening. I have the following:
On Monday, 11 August 2014 at 06:17:22 UTC, ketmar via
Digitalmars-d-learn wrote:
On Mon, 11 Aug 2014 05:18:59 +
Jeremy DeHaan via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
why do you need that info? D types has well-defined sizes (i.e
uint is
always 32 bits, and so on).
I recently got this error messege when building my library:
dmd: cppmangle.c:154: void
CppMangleVisitor::cpp_mangle_name(Dsymbol*): Assertion `0' failed.
I have no idea what it means and haven't found much information
about it. I think I have narrowed it down to the file that is
giving this
On Tue, 12 Aug 2014 07:16:49 +
Jeremy DeHaan via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
but does anyone know what the heck causes something like this?
it's internal compiler error, the thing that should never happen.
try to use dustmite to build minimalictic test case
On 12/08/2014 7:16 p.m., Jeremy DeHaan wrote:
I recently got this error messege when building my library:
dmd: cppmangle.c:154: void CppMangleVisitor::cpp_mangle_name(Dsymbol*):
Assertion `0' failed.
I have no idea what it means and haven't found much information about
it. I think I have
Rewatching lectures... And a thought came to me.
Most sorting algorithms work with handling one element at a
time; Although you may do a binary tree to sort getting NlogN,
the optimal number of compares is still out of reach due to the
number of extra compares done.
However to build a
On Tuesday, 12 August 2014 at 05:23:53 UTC, Dicebot wrote:
On Monday, 11 August 2014 at 13:00:27 UTC, John Colvin wrote:
alias Parent = TypeTuple!(__traits(parent, foo!float))[0];
Say hello to optional parens - you are trying to call
foo!float() here and apply result to trait.
I thought
On Monday, 11 August 2014 at 13:00:27 UTC, John Colvin wrote:
can someone talk me through the reasoning behind this:
import std.typetuple;
void foo(T)(T v){}
void foo(){}
version(ThisCompiles)
{
alias Parent = TypeTuple!(__traits(parent, foo))[0];
pragma(msg, __traits(getOverloads,
dmd 2.066(rc) generates warning: 'Deprecation: Read-modify-write operations
are not allowed for shared variables. Use core.atomic.atomicOp!-=(a, 1)
instead.' for following code:
synchronized {
++a;
}
Is that correct given that it's inside synchronized?
On Monday, 11 August 2014 at 18:21:04 UTC, Baz wrote:
Hi, I try to get why the last way of generating an interface
implementation fails. I've put assumptions: is it right ?
---
module itfgen;
import std.stdio;
interface itf{
void a_int(int p);
void
What's the easiest way to get support for demangling of
GCC-supported languages of symbols extracted from GCC compiled
ELF files?
Are the demangle algorithms complex? Could they be ported to D
easily?
On Tuesday, 12 August 2014 at 11:30:24 UTC, Nordlöw wrote:
What's the easiest way to get support for demangling of
GCC-supported languages of symbols extracted from GCC compiled
In D, that is.
On Monday, 11 August 2014 at 18:21:04 UTC, Baz wrote:
interface itf{
void a_int(int p);
void a_uint(uint p);
}
[...]
// FAILS because: alias are probably generated after the itf
check
class impl3: itf{
void tmp(T)(T p){};
alias a_int = tmp!int;
alias a_uint = tmp!uint;
}
On Tue, Aug 12, 2014 at 07:16:49AM +, Jeremy DeHaan via Digitalmars-d-learn
wrote:
I recently got this error messege when building my library:
dmd: cppmangle.c:154: void CppMangleVisitor::cpp_mangle_name(Dsymbol*):
Assertion `0' failed.
I have no idea what it means and haven't found
On Tuesday, 12 August 2014 at 11:34:01 UTC, anonymous wrote:
On Monday, 11 August 2014 at 18:21:04 UTC, Baz wrote:
interface itf{
void a_int(int p);
void a_uint(uint p);
}
[...]
// FAILS because: alias are probably generated after the itf
check
class impl3: itf{
void tmp(T)(T p){};
On Tuesday, 12 August 2014 at 12:08:14 UTC, John Colvin wrote:
I think the problem is that impl3.tmp is not virtual because
it's
a template, and interfaces need to be implemented by virtual
methods.
The instantiations of the template are just normal functions
though, no?
They are not
On Tuesday, 12 August 2014 at 06:37:45 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
The problem is that isNaN is now templatized, and its
constraint uses
isFloatingPoint, which requires that the type _be_ a floating
point type, not
that it implicitly convert to one. So, as it stands,
On Tue, 12 Aug 2014 13:17:37 +
Meta via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
On Tuesday, 12 August 2014 at 06:37:45 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
The problem is that isNaN is now templatized, and its
constraint uses
isFloatingPoint, which
On Tue, 12 Aug 2014 03:01:22 -0700
Timothee Cour via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
Is that correct given that it's inside synchronized?
yes. synchronized doesn't lock *any* access to a (consider two
different shared classes, for example), it just prevents
On Tuesday, 12 August 2014 at 14:26:46 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
AFAIK, the only time that the implicit conversion would take
place is when the
type is being used in a situation where it doesn't work
directly but where the
aliased type is used. In that case, the
On Tuesday, 12 August 2014 at 15:06:38 UTC, ketmar via
Digitalmars-d-learn wrote:
besides, using atomic operations will allow you to drop
synchronize altogether which makes your code slightly faster.
... and potentially quite broken. At the very least, if this
value is ready anywhere
On Tuesday, 12 August 2014 at 15:39:09 UTC, Meta wrote:
What I mean is that this breaks the Liskov Substitution
Principle, which alias this should obey, as it denotes a
subtype.
Since S!float has an alias this to float, it should behave as a
float in all circumstances where a float is
On Tue, 12 Aug 2014 16:02:01 +
Sean Kelly via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
... and potentially quite broken. At the very least, if this
value is ready anywhere you'll have to use an atomicLoad there in
place of the synchronized block you would have used.
Awesome, thanks everyone.
I'll take the suggestion to use Dustmite as an excuse to
familiarize myself with it, but if normally extern(C++) types
cause it I know just where to look.
On Monday, 11 August 2014 at 20:02:38 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
opApplyReverse.
Was that a joke or does opApplyReverse exist?
On Tue, 12 Aug 2014 16:50:33 +
Gary Willoughby via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
Was that a joke or does opApplyReverse exist?
it's not a joke.
http://dlang.org/statement.html
ctrl+f, opApplyReverse
signature.asc
Description: PGP signature
On Tuesday, 12 August 2014 at 17:00:26 UTC, ketmar via
Digitalmars-d-learn wrote:
On Tue, 12 Aug 2014 16:50:33 +
Gary Willoughby via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
Was that a joke or does opApplyReverse exist?
it's not a joke.
http://dlang.org/statement.html
On Friday, 1 August 2014 at 21:42:02 UTC, Nordlöw wrote:
I just posted a d-mode.el fix to Russel Winder.
See the recent posts at
https://stackoverflow.com/questions/25089090/emacs-d-mode-cannot-handle-backquoted-backslashes
If you can't wait ;)
In my JavaScript VM, I have a function whose purpose is to expose
D/host constants to the JavaScript runtime code running inside
the VM. This makes for somewhat redundant code, as follows:
vm.defRTConst(OBJ_MIN_CAPw, OBJ_MIN_CAP);
vm.defRTConst(PROTO_SLOT_IDXw, PROTO_SLOT_IDX);
On Tue, 12 Aug 2014 17:36:40 +
Maxime Chevalier-Boisvert via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
I'm just wondering if there's a way to template defRTConst so
that the name of an identifier I'm passing (e.g.: ATTR_DEFAULT)
seems that this is the work for mixins.
On Tue, Aug 12, 2014 at 05:36:40PM +, Maxime Chevalier-Boisvert via
Digitalmars-d-learn wrote:
In my JavaScript VM, I have a function whose purpose is to expose
D/host constants to the JavaScript runtime code running inside the VM.
This makes for somewhat redundant code, as follows:
On Tue, Aug 12, 2014 at 04:04:41PM +, Jonathan M Davis via
Digitalmars-d-learn wrote:
On Tuesday, 12 August 2014 at 15:39:09 UTC, Meta wrote:
What I mean is that this breaks the Liskov Substitution
Principle, which alias this should obey, as it denotes a subtype.
Since S!float has an
On Tuesday, 12 August 2014 at 17:36:41 UTC, Maxime
Chevalier-Boisvert wrote:
In my JavaScript VM, I have a function whose purpose is to
expose D/host constants to the JavaScript runtime code running
inside the VM. This makes for somewhat redundant code, as
follows:
On Tuesday, 12 August 2014 at 19:03:58 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
tl;dr: there are so many ways template code can go wrong, that
I don't
it justifies blaming alias this for problems.
Allowing implicit conversions makes the problem much worse IMHO.
It makes it far too easy
On Tuesday, 12 August 2014 at 17:28:25 UTC, Nordlöw wrote:
And a PR:
https://github.com/Emacs-D-Mode-Maintainers/Emacs-D-Mode/pull/22
On Tue, Aug 12, 2014 at 08:23:30PM +, Jonathan M Davis via
Digitalmars-d-learn wrote:
On Tuesday, 12 August 2014 at 19:03:58 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
tl;dr: there are so many ways template code can go wrong, that I
don't it justifies blaming alias this for problems.
On Tuesday, 12 August 2014 at 12:43:46 UTC, anonymous wrote:
On Tuesday, 12 August 2014 at 12:08:14 UTC, John Colvin wrote:
I think the problem is that impl3.tmp is not virtual because
it's
a template, and interfaces need to be implemented by virtual
methods.
The instantiations of the
On 8/12/14, 6:31 PM, H. S. Teoh via Digitalmars-d-learn wrote:
On Tue, Aug 12, 2014 at 08:23:30PM +, Jonathan M Davis via
Digitalmars-d-learn wrote:
On Tuesday, 12 August 2014 at 19:03:58 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
tl;dr: there are so many ways template code can go
I'm having an issue with building programs that link with LuaD
using VisualD. If I use Dub, it builds without an issue, but
generating a project file and compiling it through VisualD
results in Error 162: Bad Type Index reference to type 84A9
when linking luad.lib(base).
Anyone has any ideas
On Mon, 2014-08-04 at 12:25 +, Atila Neves via Digitalmars-d-learn
wrote:
I took a look and I don't really know if it's possible without
using the Emacs 24 only suggestion in the Stack Overflow
comment to your question.
As far as I can see, before that Emacs syntax tables have a
43 matches
Mail list logo
