On 6/12/2014 12:17 AM, Colin wrote:
So a find an replace will do that for you quite easily.
Other things like structs and typedefs are a bit more difficult
to do with a find replace.
All the info you need is here anyway:
wiki.dlang.org/Bind_D_to_C
And here:
On 6/12/14, 1:29 AM, Mike Franklin wrote:
Hello,
I was recently exposed to this template in core.atomic:
private
{
template HeadUnshared(T)
{
static if( is( T U : shared(U*) ) )
alias shared(U)* HeadUnshared;
else
alias T HeadUnshared;
On Wednesday, 11 June 2014 at 06:50:08 UTC, Kagamin wrote:
debug version = DebugOrUnittest;
else version(unittest)version = DebugOrUnittest;
version(DebugOrUnittest) { static
assert(false,DebugOrUnittest); }
I like this option more. I didn't knew you could assign to
version.
Thanks,
On Wed, 11 Jun 2014 17:06:41 -0400, Kapps opantm2+s...@gmail.com wrote:
On Wednesday, 11 June 2014 at 20:59:25 UTC, Nordlöw wrote:
Can somebody explain the meaning of split in the error message
Deprecation: function core.time.Duration.weeks is deprecated - Please
use split instead. weeks
On Thursday, 12 June 2014 at 00:20:28 UTC, cal wrote:
Might it be worth stitching things together into a proper image
processing package?
Well I started working on TGA because I was disappointed that no
image abstraction is present in Phobos. Go has some imaging APIs
and I think D would
So, Lately I have been avoiding the NEW keyword. I have recently
given up static allocation of classes using CTFE. I guess they
must be const or immutable? So naturally i can do most of what i
need to with structs. They are statically allocated no NEW
necessary. But without the NEW strategy.
On Thursday, 12 June 2014 at 15:58:25 UTC, Taylor Hillegeist
wrote:
But without the NEW strategy. I must allocate static arrays and
set them to a pointer in my struct. Not too big of deal really.
Have you considered just making the buffer a struct member?
On Thursday, 12 June 2014 at 16:02:18 UTC, Adam D. Ruppe wrote:
On Thursday, 12 June 2014 at 15:58:25 UTC, Taylor Hillegeist
wrote:
But without the NEW strategy. I must allocate static arrays
and set them to a pointer in my struct. Not too big of deal
really.
Have you considered just making
On Thursday, 12 June 2014 at 16:08:49 UTC, Taylor Hillegeist
wrote:
I am considering having different sized arrays for the buffer.
I just figured that meant having different structs with various
sizes.
You might be able to do it with a templated struct and alias
this. Check this out:
On Thursday, 12 June 2014 at 15:58:25 UTC, Taylor Hillegeist
wrote:
So, Lately I have been avoiding the NEW keyword.
Why? Is malloc OK?
I have recently given up static allocation of classes using
CTFE. I guess they must be const or immutable?
Funny, because you *are* allowed to default
On Thursday, 12 June 2014 at 15:46:12 UTC, Mike wrote:
On Thursday, 12 June 2014 at 00:20:28 UTC, cal wrote:
Might it be worth stitching things together into a proper
image processing package?
Well I started working on TGA because I was disappointed that
no image abstraction is present in
On Wednesday, 11 June 2014 at 17:21:54 UTC, Tim wrote:
On Wednesday, 11 June 2014 at 17:11:51 UTC, Tim wrote:
On Wednesday, 11 June 2014 at 10:09:50 UTC, FreeSlave wrote:
I conclude that because I have similar errors when trying to
build 64-bit library on 32-bit system.
/usr/bin/ld:
Le 12/06/2014 20:09, Rene Zwanenburg a écrit :
On Thursday, 12 June 2014 at 15:46:12 UTC, Mike wrote:
On Thursday, 12 June 2014 at 00:20:28 UTC, cal wrote:
Might it be worth stitching things together into a proper image
processing package?
Well I started working on TGA because I was
Le 12/06/2014 20:35, Xavier Bigand a écrit :
Le 12/06/2014 20:09, Rene Zwanenburg a écrit :
On Thursday, 12 June 2014 at 15:46:12 UTC, Mike wrote:
On Thursday, 12 June 2014 at 00:20:28 UTC, cal wrote:
Might it be worth stitching things together into a proper image
processing package?
Well I
I can shed some light on my, beginners, point of view and the
rationale behind this tiny library.
I want to create a bar/matrix-code generator (QR, DataMatrix
etc.). I really like graphics-related subjects and I thought this
would be a good start in D.
Coming from Java island and having
hi,
i just run into a (wrong code gen?) bug that manifests itself only under
certain conditions.
before i file it, i'd like to know if it is still around in the latest DMD
version and/or if other platforms and 64bit code is affected as well.
bug description:
std.algorithm.countUntil fails to
On Wednesday, 11 June 2014 at 18:29:27 UTC, Mike wrote:
Here's the link to the repo: http://bit.ly/1mIuGhv
I usually don't trust shortened URL's. Can you please post full
URL's when not constrained by a character limit?
Any feedback would be great!
First of all, I like your coding style.
On 6/12/14, 3:20 PM, captaindet wrote:
import std.stdio;
import std.algorithm;
import std.file;// not needed, but if imported, causing trouble, see
below
void main()
{
auto names = [one,FOO,two,three];
// wrong code gen(*) with -release -O -inline -noboundscheck or
// with -release
// wrong code gen(*) with -release -O -inline -noboundscheck or
// with -release -inline -noboundscheck but only if std.file is imported:
auto x = countUntil( names, FOO );
write(x);
if( 0 = x ) writeln( found a FOO); // (*) not found!
}
I'm running OSX Mavericks with
This will not compile:
alias blah = null;
The dmd message are:
di/test_hdr.d(10): Error: basic type expected, not null
di/test_hdr.d(10): Error: semicolon expected to close alias declaration
di/test_hdr.d(10): Error: Declaration expected, not 'null'
Are there any other objects that cannot be
On 06/12/2014 01:26 PM, Tom Browder via Digitalmars-d-learn wrote:
This will not compile:
alias blah = null;
The dmd message are:
di/test_hdr.d(10): Error: basic type expected, not null
di/test_hdr.d(10): Error: semicolon expected to close alias declaration
di/test_hdr.d(10): Error:
On 6/12/14, 4:29 PM, Ali Çehreli wrote:
On 06/12/2014 01:26 PM, Tom Browder via Digitalmars-d-learn wrote:
This will not compile:
alias blah = null;
The dmd message are:
di/test_hdr.d(10): Error: basic type expected, not null
di/test_hdr.d(10): Error: semicolon expected to
On Thu, Jun 12, 2014 at 03:26:13PM -0500, Tom Browder via Digitalmars-d-learn
wrote:
This will not compile:
alias blah = null;
[...]
'null' is a value, not a type. Try:
alias blah = typeof(null);
T
--
If it's green, it's biology, If it stinks, it's chemistry, If it has numbers
On 06/12/2014 01:36 PM, Andrew Edwards wrote:
void foo() {}
alias bar = foo();
Am I just misunderstanding what is meant by types?
Seems to be an old behavior. That does not compile with 2.066:
Error: function declaration without return type. (Note that constructors
are always named
On Thu, Jun 12, 2014 at 3:42 PM, H. S. Teoh via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On Thu, Jun 12, 2014 at 03:26:13PM -0500, Tom Browder via Digitalmars-d-learn
wrote:
This will not compile:
alias blah = null;
[...]
'null' is a value, not a type. Try:
On 06/12/2014 02:06 PM, Tom Browder via Digitalmars-d-learn wrote:
What I was really trying to do was D'ify C expressions like this:
typedef ((struct t*)0) blah;
Is that actually a function pointer typedef? I can't parse that line. :)
So, taking your advice, I found this to work (at
On Thu, Jun 12, 2014 at 4:17 PM, Ali Çehreli
digitalmars-d-learn@puremagic.com wrote:
On 06/12/2014 02:06 PM, Tom Browder via Digitalmars-d-learn wrote:
...
What I was really trying to do was D'ify C expressions like this:
typedef ((struct t*)0) blah;
...
So, taking your advice, I found
since null is a value maybe you want
enum blah = null;
you may also give it a type after the enum word
I built dstep from this repo on a Debian Linux 64-bit system (after
building and installing the dmd suite from its repos).
But I'm having problems using it.
Given a file t.h with sole contents:
extern const char *const sys_errlist[];
I run dstep on it and get a core dump:
$ dstep -x c -o t.d
On 2014-06-12 14:20, captaindet wrote:
before i file it, i'd like to know if it is still around in the
latest DMD version and/or if other platforms and 64bit code is
affected as well.
thanks andrew, philippe,
i had the suspicion that it is a windows only problem anyway because the only
On Thu, Jun 12, 2014 at 4:58 PM, Adam D. Ruppe via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
since null is a value maybe you want
enum blah = null;
That works.
you may also give it a type after the enum word
But I can't get any other variant to work so far.
-Tom
confirmed and commmented in that issue
On Thursday, 12 June 2014 at 22:14:23 UTC, captaindet wrote:
On 2014-06-12 14:20, captaindet wrote:
before i file it, i'd like to know if it is still around in the
latest DMD version and/or if other platforms and 64bit code is
affected as well.
thanks andrew, philippe,
i had the suspicion
On Thu, Jun 12, 2014 at 5:17 PM, Dicebot via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
confirmed and commmented in that issue
Thank you! That makes me feel better, but I guess Jacob has a valid
bug on his hands. It will be interesting to see the fix.
Best regards,
-Tom
On Thursday, 12 June 2014 at 20:44:16 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
On Thu, Jun 12, 2014 at 03:26:13PM -0500, Tom Browder via
Digitalmars-d-learn wrote:
This will not compile:
alias blah = null;
[...]
'null' is a value, not a type. Try:
alias blah = typeof(null);
On Thursday, 12 June 2014 at 21:58:32 UTC, Adam D. Ruppe wrote:
since null is a value maybe you want
enum blah = null;
you may also give it a type after the enum word
I *think* the issue might be that null is an rvalue? Because
you can alias variable names all you want. I do it all the time
On 06/12/2014 03:38 PM, monarch_dodra wrote:
Yet you can alias variables...
int i;
alias j = i;
Initially I forgot about the fact that symbols can be alias'ed as well.
So that's fine.
So there's something special about null.
The difference is that null is an expression. It is the same
I'm not sure if this is a known problem, or if it's something
that I'd need to file a new bug for, but if a program is compiled
with a module besides the one containing main() first on the
commandline, certain debug info is clobbered on 64-bit linux.
An easy testcase, with module afunc.d:
On 2014-06-12 17:27, Rene Zwanenburg wrote:
On Thursday, 12 June 2014 at 22:14:23 UTC, captaindet wrote:
On 2014-06-12 14:20, captaindet wrote:
before i file it, i'd like to know if it is still around in the
latest DMD version and/or if other platforms and 64bit code is
affected as well.
On Thursday, 12 June 2014 at 05:29:39 UTC, Mike Franklin wrote:
Hello,
I was recently exposed to this template in core.atomic:
private
{
template HeadUnshared(T)
{
static if( is( T U : shared(U*) ) )
alias shared(U)* HeadUnshared;
else
alias T
On 6/9/2014 11:42 AM, lurker wrote:
i agree with you, but you should have posted in announce, so that
adrei can use it for some marketing.
i too wait now for a long, long time to use it with win64. i am also
giving up - i guess it will stay a linux/apple show.
maybe, as a multiple os compiler,
I'm trying to create a minimal tweening library in D based on the
commonly used easing equations by Robert Penner
(http://www.robertpenner.com/easing/).
One of the goals with the design of the library is that any
numeric type should be tweenable.(The user of the library
shouldn't have to do any
Wouldn't that be nice?
it's all known at CT so why not expose it
among other things it'd allow proper association of modules to files in
stacktraces (sometimes this is impossible / ambiguous), custom user defined
error messages involving lambdas, printing unittest lines etc.
On Friday, 13 June 2014 at 04:11:38 UTC, Rutger wrote:
I'm trying to create a minimal tweening library in D based on
the
commonly used easing equations by Robert Penner
(http://www.robertpenner.com/easing/).
One of the goals with the design of the library is that any
numeric type should be
44 matches
Mail list logo
