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
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 idea
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 wron
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 templat
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 probl
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 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: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:
vm.defRTConst("OBJ_MIN_CAP"
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 a
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, 12 Aug 2014 17:36:40 +
Maxime Chevalier-Boisvert via Digitalmars-d-learn
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.
signature.asc
Description: PGP s
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_CAP"w, OBJ_MIN_CAP);
vm.defRTConst("PROTO_SLOT_IDX"w, PROTO_SLOT_IDX);
vm.defRTCons
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 ;)
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
wrote:
Was that a joke or does opApplyReverse exist?
it's not a joke.
http://dlang.org/statement.html
ctrl+f, opApplyReverse
Ha, awes
On Tue, 12 Aug 2014 16:50:33 +
Gary Willoughby via Digitalmars-d-learn
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 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?
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 Tue, 12 Aug 2014 16:02:01 +
Sean Kelly via Digitalmars-d-learn
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.
sure, *any* access to shared va
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 expected;
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 you'll
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 compil
On Tue, 12 Aug 2014 03:01:22 -0700
Timothee Cour via Digitalmars-d-learn
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 simultaneous
access in this given part of
On Tue, 12 Aug 2014 13:17:37 +
Meta via Digitalmars-d-learn 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 requires that the type _b
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, isN
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 virtua
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 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 fo
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 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.
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 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 a_uint(ui
On Tuesday, 12 August 2014 at 10:01:46 UTC, Timothee Cour via
Digitalmars-d-learn wrote:
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;
}
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 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, Pa
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
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 pro
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 narrow
On Tue, 12 Aug 2014 07:16:49 +
Jeremy DeHaan via Digitalmars-d-learn
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 and fill the bug.
signature.asc
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 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
wrote:
why do you need that info? D types has well-defined sizes (i.e
uint is
always 32 bits, and so on).
I came up with a better solutio
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
wrote:
Hi,
I'm trying to allow implicit conversions for my own type
happening. I have the following:
import std.math;
import std.t
41 matches
Mail list logo