I am working my way up to building NanoVG per my previous post.
I am able to compile hello world using dmd2. I am running in
cygwin because I understand bash way better than cmd.exe.
I am unable to compile hello world using ldc2. I am interested in
ldc because I am interested in compiling to
Dne 17.10.2016 v 23:40 Christian Köstlin via Digitalmars-d-learn napsal(a):
Could someone check the numbers on another OS-X machine? Unfortunately I
only have one available.
Thanks in advance!
Can you try it on OSX with ldc compiler:
dub run --build=release --compiler=ldc
On 17/10/16 14:44, Christian Köstlin wrote:
> On 17/10/16 14:09, Daniel Kozak via Digitalmars-d-learn wrote:
>> Dne 16.10.2016 v 10:41 Christian Köstlin via Digitalmars-d-learn napsal(a):
>>> Hi,
>>>
>>> for an exercise I had to implement a thread safe counter.
>>> This is what I came up with:
>>>
On Monday, 17 October 2016 at 19:10:54 UTC, Basile B. wrote:
Just a question, maybe off topic, does this work:
unittest
{
alias Key = string;
alias A = Array!int;
A[Key] x;
x["a"] = [0];
}
?
No, that works.
Thanks for your interest.
On Monday, 17 October 2016 at 19:14:49 UTC, ANtlord wrote:
On Monday, 17 October 2016 at 17:57:19 UTC, Martin Krejcirik
wrote:
On Monday, 17 October 2016 at 15:45:56 UTC, ANtlord wrote:
GDB 7.7.1
Use latest GDB, 7.10 has got much better D support.
Tested on GDB 7.11.1. Same case :(
On Monday, 17 October 2016 at 18:20:00 UTC, cym13 wrote:
On Monday, 17 October 2016 at 18:10:01 UTC, vino wrote:
[...]
I don't see what you don't understand, you said it yourself:
"neither the slice nor its elements can be modified". So you
can't modify the elements of an immutable array.
On Monday, 17 October 2016 at 17:53:30 UTC, Basile B. wrote:
On Monday, 17 October 2016 at 17:46:05 UTC, Basile B. wrote:
On Monday, 17 October 2016 at 15:45:56 UTC, ANtlord wrote:
On Monday, 17 October 2016 at 15:43:32 UTC, ANtlord wrote:
[...]
Oh Sorry, I've forgotten about pointing
On Monday, 17 October 2016 at 17:57:19 UTC, Martin Krejcirik
wrote:
On Monday, 17 October 2016 at 15:45:56 UTC, ANtlord wrote:
GDB 7.7.1
Use latest GDB, 7.10 has got much better D support.
Tested on GDB 7.11.1. Same case :(
On Monday, 17 October 2016 at 17:43:19 UTC, Nordlöw wrote:
At
https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d
I have an array container.
Everything works as expected in all unittests except for the
line at
On 10/17/16 1:43 PM, Nordlöw wrote:
At
https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d
I have an array container.
Everything works as expected in all unittests except for the line at
https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d#L1649
that fails as
On 10/17/2016 11:40 AM, Nordlöw wrote:
On Monday, 17 October 2016 at 18:22:53 UTC, Ali Çehreli wrote:
It still feels like x["a"] could return a proxy that could later add a
new element and then apply ~= on it. (I haven't read the rest of your
code to see whether you've already done that.)
On Monday, 17 October 2016 at 18:38:30 UTC, Ali Çehreli wrote:
As a consolation :) there are two unrelated issues in your
code, which a new dmd warns about:
Deprecation: Implicit string concatenation is deprecated
1) Probably a missing comma after `mark`:
enum nonStateHTMLTags = [`b`, `i`,
On Monday, 17 October 2016 at 18:22:53 UTC, Ali Çehreli wrote:
It still feels like x["a"] could return a proxy that could
later add a new element and then apply ~= on it. (I haven't
read the rest of your code to see whether you've already done
that.)
`Array` is in essence a C++-style array
On 10/17/2016 11:28 AM, Nordlöw wrote:
On Monday, 17 October 2016 at 18:22:53 UTC, Ali Çehreli wrote:
Unfortunately, as far as I know, that's a privilege reserved for
built-in AAs.
But I *am* using a built-in AA. The problem happens when the value is an
instance of an `Array!T`-container and
On Monday, 17 October 2016 at 18:22:53 UTC, Ali Çehreli wrote:
Unfortunately, as far as I know, that's a privilege reserved
for built-in AAs.
But I *am* using a built-in AA. The problem happens when the
value is an instance of an `Array!T`-container and not a slice
`T[]`.
On Monday, 17 October 2016 at 17:43:19 UTC, Nordlöw wrote:
At
https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d
I have an array container.
Everything works as expected in all unittests except for the
line at
On 10/17/2016 10:43 AM, Nordlöw wrote:
At
https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d
I have an array container.
Everything works as expected in all unittests except for the line at
https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d#L1649
that fails as
On Monday, 17 October 2016 at 18:10:01 UTC, vino wrote:
Hi All,
As per the book named in the subject it states as below,so can
some one guide me what is wrong in the below code nor correct
if my understanding is wrong.
Page 154
immutable(int[]) specifies that neither the slice nor its
On 10/17/2016 11:10 AM, vino wrote:
Hi All,
As per the book named in the subject it states as below,so can some one
guide me what is wrong in the below code nor correct if my understanding
is wrong.
Page 154
immutable(int[]) specifies that neither the slice nor its elements can
be modified.
Hi All,
As per the book named in the subject it states as below,so can
some one guide me what is wrong in the below code nor correct if
my understanding is wrong.
Page 154
immutable(int[]) specifies that neither the slice nor its
elements can be modified.
So which means that a element or
On Monday, 17 October 2016 at 15:45:56 UTC, ANtlord wrote:
GDB 7.7.1
Use latest GDB, 7.10 has got much better D support.
On Monday, 17 October 2016 at 17:46:05 UTC, Basile B. wrote:
On Monday, 17 October 2016 at 15:45:56 UTC, ANtlord wrote:
On Monday, 17 October 2016 at 15:43:32 UTC, ANtlord wrote:
[...]
Oh Sorry, I've forgotten about pointing technical parameters.
Ubuntu 14.04
GDB 7.7.1
DMD64 D Compiler
On Monday, 17 October 2016 at 15:45:56 UTC, ANtlord wrote:
On Monday, 17 October 2016 at 15:43:32 UTC, ANtlord wrote:
Hello! I've met an issue related to debugging by GDB. Directly
when I try to show call stack I get like this
http://pastebin.com/kRFRqznq. How can I make name of methods
more
At
https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d
I have an array container.
Everything works as expected in all unittests except for the line
at
https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d#L1649
that fails as
On Monday, 17 October 2016 at 15:43:32 UTC, ANtlord wrote:
Hello! I've met an issue related to debugging by GDB. Directly
when I try to show call stack I get like this
http://pastebin.com/kRFRqznq. How can I make name of methods
more human readable?
I see part of printed name matches to name
Hello! I've met an issue related to debugging by GDB. Directly
when I try to show call stack I get like this
http://pastebin.com/kRFRqznq. How can I make name of methods more
human readable?
I see part of printed name matches to name of methods from code
and I can suppose what method was
On 10/17/16 10:12 AM, timepp wrote:
there is "@disable", using @ as prefix;
there is "__gshared", using __ as prefix;
there is also "align", not using prefix.
I failed to summarize a rule here. Can anyone tell the underlined
philosiphy?
terms without adornments are keywords. They are used in
On Monday, October 17, 2016 14:12:33 timepp via Digitalmars-d-learn wrote:
> there is "@disable", using @ as prefix;
> there is "__gshared", using __ as prefix;
> there is also "align", not using prefix.
>
> I failed to summarize a rule here. Can anyone tell the underlined
> philosiphy?
There
On Friday, October 14, 2016 16:49:44 Nick Sabalausky via Digitalmars-d-learn
wrote:
> This compiles. Is it supposed to?
>
> @safe ubyte[] foo()
> {
> ubyte[512] buf;
> auto slice = buf[0..$];
> // Escaping reference to stack memory, right?
> return slice;
> }
>
> Or is the escaping
On Monday, 17 October 2016 at 14:12:33 UTC, timepp wrote:
there is "@disable", using @ as prefix;
there is "__gshared", using __ as prefix;
there is also "align", not using prefix.
I failed to summarize a rule here. Can anyone tell the
underlined philosophy?
It's an inconsistency of the
there is "@disable", using @ as prefix;
there is "__gshared", using __ as prefix;
there is also "align", not using prefix.
I failed to summarize a rule here. Can anyone tell the underlined
philosiphy?
On Monday, 17 October 2016 at 14:01:26 UTC, Basile B. wrote:
Is this a bug or a case of hijacking protection ?
struct S
{
void test(void*, size_t){}
}
void test(ref S,void[]){}
void main()
{
ubyte[] a;
(*new S).test(a);
}
Is this a bug or a case of hijacking protection ?
struct S
{
void test(void*, size_t){}
}
void test(ref S,void[]){}
void main()
{
ubyte[] a;
(*new S).test(a);
}
On 17/10/16 14:09, Daniel Kozak via Digitalmars-d-learn wrote:
> Dne 16.10.2016 v 10:41 Christian Köstlin via Digitalmars-d-learn napsal(a):
>> Hi,
>>
>> for an exercise I had to implement a thread safe counter.
>> This is what I came up with:
>>
>>
>> btw. I run the code with dub run
Dne 16.10.2016 v 10:41 Christian Köstlin via Digitalmars-d-learn napsal(a):
Hi,
for an exercise I had to implement a thread safe counter.
This is what I came up with:
btw. I run the code with dub run --build=release
Thanks in advance,
Christian
So I have done some testing, on my pc:
On Thursday, 13 October 2016 at 18:35:43 UTC, Matthias Klumpp
wrote:
The new toolchains of Ubuntu (and Debian soon too) default to
PIE code, so in order to link correctly, the project needs to
be compiled with PIE/PIC to work.
Please update the bug report.
On 2016-10-17 10:55, Nordlöw wrote:
It's the target `idgen` that fails for me.
"idgen" is a separate target [1]. It's a tool that generates some code.
[1] https://github.com/dlang/dmd/blob/master/src/posix.mak#L389
--
/Jacob Carlborg
Dne 17.10.2016 v 11:56 markov via Digitalmars-d-learn napsal(a):
Thanks.
So something like this would be helpful in core.thread?
void startThread(alias fun, P...)(P p){
new Thread({fun(p);}).start();
}
or without delegate
import std.stdio;
import core.thread;
void fun(alias a, alias
Thanks.
So something like this would be helpful in core.thread?
void startThread(alias fun, P...)(P p){
new Thread({fun(p);}).start();
}
On Monday, 17 October 2016 at 08:39:55 UTC, Nordlöw wrote:
I you only tell me what to do I can make a PR to DMD that fixes
these things.
It's the target `idgen` that fails for me.
On Monday, 17 October 2016 at 05:55:55 UTC, tcak wrote:
So, I added
-defaultlib=libphobos2.so -fPIC
Where did you add it?
To the command-line or Makefile?
And which Make variable did you change?
I've tried
make -f posix.mak MODEL_FLAG="-fPIC"
but C++ compilations still fail with
On Monday, 17 October 2016 at 07:05:24 UTC, ketmar wrote:
On Monday, 17 October 2016 at 02:07:47 UTC, rikki cattermole
wrote:
You're going to need to find an svg rasterizer in some form or
another.
I don't think we have one in D and certainly not a complete
one.
'cmon, you know that i have a
On Monday, 17 October 2016 at 02:07:47 UTC, rikki cattermole
wrote:
You're going to need to find an svg rasterizer in some form or
another.
I don't think we have one in D and certainly not a complete one.
'cmon, you know that i have a working port of NanoSVG! and it
works on top of NanoVG,
On Monday, 17 October 2016 at 06:38:08 UTC, Daniel Kozak wrote:
Dne 17.10.2016 v 07:55 Christian Köstlin via
Digitalmars-d-learn napsal(a):
[...]
I am still unable to get your java code working:
[kozak@dajinka threads]$ ./gradlew clean build
:clean
:compileJava
:processResources UP-TO-DATE
Dne 17.10.2016 v 07:55 Christian Köstlin via Digitalmars-d-learn napsal(a):
to run java call ./gradlew clean build
->
counter.AtomicIntCounter@25992ae3 expected: 200 got: 100 in: 22ms
counter.AtomicLongCounter@2539f946 expected: 200 got: 100 in: 17ms
On 17/10/16 06:55, Daniel Kozak via Digitalmars-d-learn wrote:
> Dne 16.10.2016 v 10:41 Christian Köstlin via Digitalmars-d-learn napsal(a):
>
>> My question now is, why is each mutex based thread safe variant so slow
>> compared to a similar java program? The only hint could be something
>>
On 16/10/16 19:50, tcak wrote:
> On Sunday, 16 October 2016 at 08:41:26 UTC, Christian Köstlin wrote:
>> Hi,
>>
>> for an exercise I had to implement a thread safe counter. This is what
>> I came up with:
>>
>> [...]
>
> Could you try that:
>
> class ThreadSafe3Counter: Counter{
> private long
On Sunday, 16 October 2016 at 22:36:15 UTC, Nordlöw wrote:
On Sunday, 16 October 2016 at 22:00:48 UTC, Nordlöw wrote:
Which flag(s) in `src/posix.mak` did you change?
Does
make -f posix.mak MODEL_FLAG=-fPIC
work?
I'm sitting on a 16.04 system right now (which I don't dare to
upgrade
48 matches
Mail list logo
