thanks for the reply...
the method you described is suitable for appending to an array, but I'm
using the singly-linked-list container.
I've extended the test, and I'm pretty sure it's a bug...
--ted
Nicholas Wilson wrote:
On Thursday, 13 August 2015 at 08:40:13 UTC, ted wrote:
have
Compiler dmd_2.068.0-0_amd64.deb on Ubuntu 12.04 Linux:
auto lookup = [ one:1, two:2 ];
The dmd error:
Error: non-constant expression [one:1, two:2]
Why doesn't it compile?
As a workaround I could do the assignment one element at a time
in a loop. It would be uglier though.
On 08/13/2015 11:48 PM, Adel Mamin wrote:
Compiler dmd_2.068.0-0_amd64.deb on Ubuntu 12.04 Linux:
auto lookup = [ one:1, two:2 ];
The dmd error:
Error: non-constant expression [one:1, two:2]
I think the problem is when the variable is defined at module scope. It
works inside functions, etc.
On Friday, 14 August 2015 at 06:48:27 UTC, Adel Mamin wrote:
Compiler dmd_2.068.0-0_amd64.deb on Ubuntu 12.04 Linux:
auto lookup = [ one:1, two:2 ];
The dmd error:
Error: non-constant expression [one:1, two:2]
Why doesn't it compile?
As a workaround I could do the assignment one element at a
On Wednesday, 12 August 2015 at 23:23:03 UTC, Yuxuan Shui wrote:
Is there a way to do thread-local allocations?
Yes, either manually or just putting things on the stack, but the
std.string functions you use doesn't try to do them.
You might try replacing format() with formattedWrite(),
On Friday, 14 August 2015 at 07:04:53 UTC, BBasile wrote:
It's because of the key type (string is a library type).
This is not true. It's not because of the key type. And string is
not a library type.
On 08/14/2015 05:12 AM, H. S. Teoh via Digitalmars-d-learn wrote:
On Fri, Aug 14, 2015 at 02:42:26AM +, Laeeth Isharc via Digitalmars-d-learn
wrote:
I have a range that is an array of structs. I would like to iterate
through the range, calling a function with the prior k items in the
On 08/14/2015 03:26 PM, Timon Gehr wrote:
On 08/14/2015 05:12 AM, H. S. Teoh via Digitalmars-d-learn wrote:
...
I didn't figure out how to eliminate the short slices toward the end,
...
:o)
...
Less hacky and less efficient:
auto slidingWindow(R)(R range, int k) {
return
This is more a theoretical exercise than specific code nitty
gritty, but...
Let's say I have some code like this:
class World {
// Bunch of members and other functions
void happyDay () {
if (bCthulhuRises) {
debug(logging) {
i'm trying to have my own versions of my dependencies as git
submodules.
problem:
i include a local version of vibe.d and then i add other local
versions of
packages that themselves include vibe.d
somehow my version of vibe isn't picked up by the other
dependencies and it results in an
On Friday, 14 August 2015 at 08:06:15 UTC, yawniek wrote:
i'm trying to have my own versions of my dependencies as git
submodules.
whats the correct way of having a chain of packages included
from git submodules so that every packages get's only picked
once?
dub add-local allows you to
On Thursday, 13 August 2015 at 16:05:19 UTC, Steven Schveighoffer
wrote:
On 8/13/15 11:59 AM, Steven Schveighoffer wrote:
That is definitely a bug. It's because typeid is looking up
the derived
type via the vtable, but the compiler should rewrap it with
'shared'
afterwards.
Actually, now
On Friday, 14 August 2015 at 08:09:18 UTC, Edwin van Leeuwen
wrote:
On Friday, 14 August 2015 at 08:06:15 UTC, yawniek wrote:
dub add-local allows you to add local copy of a package. This
will be system wide though, not only for the current package.
i actually tried this, somehow did't work
It's because it's implemented in DMD only partly.
There's a bug report associated with it.
On 08/13/2015 06:05 PM, Steven Schveighoffer wrote:
On 8/13/15 11:59 AM, Steven Schveighoffer wrote:
That is definitely a bug. It's because typeid is looking up the derived
type via the vtable, but the compiler should rewrap it with 'shared'
afterwards.
Actually, now that I think about it,
On 8/14/15 11:39 AM, Timon Gehr wrote:
On 08/13/2015 06:05 PM, Steven Schveighoffer wrote:
On 8/13/15 11:59 AM, Steven Schveighoffer wrote:
That is definitely a bug. It's because typeid is looking up the derived
type via the vtable, but the compiler should rewrap it with 'shared'
afterwards.
On Friday, 14 August 2015 at 20:48:43 UTC, Adam D. Ruppe wrote:
On Friday, 14 August 2015 at 20:40:13 UTC, D_Learner wrote:
Perhaps I have to get myself a copy.
you should! There's a lot of little tips and tricks in there.
Am currently looking at your Dconf2015 talk .
My blasphemous talk
On Friday, 14 August 2015 at 12:40:08 UTC, Steven Schveighoffer
wrote:
I would do it this way:
// at module level
debug(logging) {
Logger logger;
static this() { logger = new Logger;}
}
If you want to have the logger be global, add 'shared' to both
the logger and the static this.
On Thursday, 13 August 2015 at 19:26:12 UTC, Adam D. Ruppe wrote:
On Thursday, 13 August 2015 at 19:13:55 UTC, D_Learner wrote:
[...]
It is currently not possible to build an associative array at
compile time and keep it as a runtime table due to the
implementation.
[...]
Am aware you
On Friday, 14 August 2015 at 20:40:13 UTC, D_Learner wrote:
Perhaps I have to get myself a copy.
you should! There's a lot of little tips and tricks in there.
Am currently looking at your Dconf2015 talk .
My blasphemous talk as I like to call it :)
There's a bit in the video where i went
On Thursday, 13 August 2015 at 19:54:18 UTC, anonymous wrote:
On Thursday, 13 August 2015 at 19:13:55 UTC, D_Learner wrote:
[...]
I think you may have some fundamental misunderstandings
regarding CTFE, templates, etc. Your code seems to be half-way
between a template-based and a
On Friday, 14 August 2015 at 22:25:15 UTC, DarthCthulhu wrote:
Ahh, that is a much cleaner way to do it rather than using a
singleton.
By 'module level', I assume you mean in the module that defines
the Logger class? An 'import debug.logger' or somesuch would
then give all relevant modules
On Friday, 14 August 2015 at 23:17:44 UTC, Tofu Ninja wrote:
On Friday, 14 August 2015 at 22:25:15 UTC, DarthCthulhu wrote:
Ahh, that is a much cleaner way to do it rather than using a
singleton.
By 'module level', I assume you mean in the module that
defines the Logger class? An 'import
On Saturday, 15 August 2015 at 01:09:15 UTC, D_Learner wrote:
When writting a pure fucntion involving C non pure functions
like
memcpy() and memset()
Those functions are pure already, and marked so in the newest dmd
(and I think older ones too, though I haven't confirmed.
Your code
On Saturday, 15 August 2015 at 02:21:46 UTC, D_Learner wrote:
Well, the actual error I got is : Error: memset cannot be
interpreted at compile time, because it has no available source
code . I seems to suggest I miss the actual code.
I guess I gave you a wrong impression of how pure relates
On 08/14/2015 06:09 PM, D_Learner wrote:
When writting a pure fucntion involving C non pure functions
If you want to live dangerously, you can use assumePure, which is found
in one of the unittest blocks of std.traits:
import std.traits;
auto assumePure(T)(T t)
if (isFunctionPointer!T ||
On Friday, 14 August 2015 at 13:32:57 UTC, Timon Gehr wrote:
On 08/14/2015 03:26 PM, Timon Gehr wrote:
On 08/14/2015 05:12 AM, H. S. Teoh via Digitalmars-d-learn
wrote:
...
I didn't figure out how to eliminate the short slices toward
the end,
...
:o)
...
Less hacky and less efficient:
On Saturday, 15 August 2015 at 02:21:46 UTC, D_Learner wrote:
Well, the actual error I got is : Error: memset cannot be
interpreted at compile time, because it has no available source
code . I seems to suggest I miss the actual code.
yeah, ctfe is different than pure functions. That's where
On Saturday, 15 August 2015 at 02:21:46 UTC, D_Learner wrote:
On Saturday, 15 August 2015 at 01:13:02 UTC, Adam D. Ruppe
wrote:
On Saturday, 15 August 2015 at 01:09:15 UTC, D_Learner wrote:
When writting a pure fucntion involving C non pure functions
like
memcpy() and memset()
Those
When writting a pure fucntion involving C non pure functions like
memcpy() and memset() , what could be the way around? Should I
re-write these and make them pure?
The code am converting is as below :-
int ag_cmatch(const string pattern, const string text,
int[char] bmBc , int[size]
On Saturday, 15 August 2015 at 01:13:02 UTC, Adam D. Ruppe wrote:
On Saturday, 15 August 2015 at 01:09:15 UTC, D_Learner wrote:
When writting a pure fucntion involving C non pure functions
like
memcpy() and memset()
Those functions are pure already, and marked so in the newest
dmd (and I
http://code.dlang.org/packages/windows-headers - as a dub package.
https://issues.dlang.org/show_bug.cgi?id=14920
On 8/14/15 4:22 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net
wrote:
On Thursday, 13 August 2015 at 16:05:19 UTC, Steven Schveighoffer wrote:
On 8/13/15 11:59 AM, Steven Schveighoffer wrote:
That is definitely a bug. It's because typeid is looking up the derived
type via the vtable, but
On 8/14/15 5:21 AM, DarthCthulhu wrote:
This is more a theoretical exercise than specific code nitty gritty, but...
Let's say I have some code like this:
class World {
// Bunch of members and other functions
void happyDay () {
if (bCthulhuRises) {
On Friday, 14 August 2015 at 09:21:56 UTC, DarthCthulhu wrote:
I only want to access the logger object when the program is
compiled with the -debug option, so I don't want to pass it
along to the object constructor or set a member as a reference
to it (which is both tedious and pointless if
36 matches
Mail list logo
