Am Wed, 10 Feb 2016 05:41:24 +
schrieb Tofu Ninja :
> On Thursday, 4 February 2016 at 17:56:06 UTC, Marco Leise wrote:
> > Am Mon, 01 Feb 2016 02:56:06 +
> > schrieb Tofu Ninja :
> >
> >> Just out of curiosity, does anyone have an octree
> >> implementation for D laying around? Just looki
On Tuesday, 9 February 2016 at 22:39:14 UTC, Gary Willoughby
wrote:
On Tuesday, 9 February 2016 at 17:02:28 UTC, Jakob Ovrum wrote:
to!string behaving like that was a poor design choice[1].
Please use fromStringz.
[1] https://github.com/D-Programming-Language/phobos/pull/1607
It's not a poor
On Thursday, 4 February 2016 at 17:56:06 UTC, Marco Leise wrote:
Am Mon, 01 Feb 2016 02:56:06 +
schrieb Tofu Ninja :
Just out of curiosity, does anyone have an octree
implementation for D laying around? Just looking to save some
time.
I have one written in Delphi that you could prune til
On Wednesday, 10 February 2016 at 00:24:56 UTC, tsbockman wrote:
[...]
`Tuple.slice` is corrupting data *right now*.
Some sort of short-term fix should be merged in the next
release of D.
+1
On 02/09/2016 12:54 PM, Charles wrote:
On Tuesday, 9 February 2016 at 20:48:01 UTC, Steven Schveighoffer wrote:
On 2/9/16 3:40 PM, Charles wrote:
This seems to be true of any range function really... is there a way to
access the key within my range?
Example of what I want to do:
auto x = [1,2
On 02/09/2016 04:22 PM, cym13 wrote:
On Wednesday, 10 February 2016 at 00:05:36 UTC, Peka wrote:
Hi!
I have class (or struct) which realises .length() and .opIndex(size_t)
methods.
It is possible to create from this class some sort of range using
template from std? (I mean that internal counte
On Wednesday, 10 February 2016 at 00:27:54 UTC, Peka wrote:
I don't think anything like that exists in phobos
I need definitive answer.
I need a precise answer.
(sorry, google translator :з)
"Definitive" is good, maybe even better in the context.
I should have been clearer, sorry. When I
I don't think anything like that exists in phobos
I need definitive answer.
I need a precise answer.
(sorry, google translator :з)
On Wednesday, 10 February 2016 at 00:22:46 UTC, cym13 wrote:
On Wednesday, 10 February 2016 at 00:05:36 UTC, Peka wrote:
Hi!
I have class (or struct) which realises .length() and
.opIndex(size_t) methods.
It is possible to create from this class some sort of range
using template from std? (
On Tuesday, 9 February 2016 at 09:05:58 UTC, Ola Fosheim Grøstad
wrote:
I suggest lobbying for proper builtin tuple support.
Built-in tuple support would be great (although to my mind,
mostly because the current syntax is clunky). But that is a
long-term goal, and `Tuple.slice` is corrupting
On Wednesday, 10 February 2016 at 00:05:36 UTC, Peka wrote:
Hi!
I have class (or struct) which realises .length() and
.opIndex(size_t) methods.
It is possible to create from this class some sort of range
using template from std? (I mean that internal counter,
.popFront(), .empty() etc metho
Hi!
I have class (or struct) which realises .length() and
.opIndex(size_t) methods.
It is possible to create from this class some sort of range using
template from std? (I mean that internal counter, .popFront(),
.empty() etc methods should be added by template.)
On Tuesday, February 09, 2016 20:20:59 Suliman via Digitalmars-d-learn wrote:
> It's look like that I can only create one nesting level sub
> folder, for example there is exists dir: D:\foo
> I can't create dir D:\foo\bar\baz I can only create D:\foo\bar
>
> D:\foo\bar
>
> Is it's rational limit or
On Tuesday, 9 February 2016 at 17:02:28 UTC, Jakob Ovrum wrote:
to!string behaving like that was a poor design choice[1].
Please use fromStringz.
[1] https://github.com/D-Programming-Language/phobos/pull/1607
It's not a poor design choice. It ensures the string is handled
by the D GC instead
On Tuesday, 9 February 2016 at 16:58:03 UTC, Daniel Kozak wrote:
Or use `to` like this:
import std.conv;
writefln("%s", pString.to!(string));
this will allocate new string which can be performance problem.
Which is good in most cases. It's better to have the GC take care
of the D string ins
On Tuesday, 9 February 2016 at 21:05:50 UTC, jmh530 wrote:
For instance, in the code below, I could use Baz but not Caz.
It seems to work when I use the alternate version of Caz
calling a non-member function.
Bug?
No bug; works as intended. UFCS can only be used with free
functions, not wit
On Tuesday, 9 February 2016 at 20:20:59 UTC, Suliman wrote:
It's look like that I can only create one nesting level sub
folder, for example there is exists dir: D:\foo
I can't create dir D:\foo\bar\baz I can only create D:\foo\bar
http://dlang.org/phobos/std_file.html#.mkdirRecurse
-Wyatt
I have been working with some C error codes that are organized in
an enum. I noticed that if I tried to write a function that
processes these error codes within a struct, then I could not use
a UFCS-style call.
For instance, in the code below, I could use Baz but not Caz. It
seems to work whe
On Tuesday, 9 February 2016 at 20:20:59 UTC, Suliman wrote:
It's look like that I can only create one nesting level sub
folder, for example there is exists dir: D:\foo
I can't create dir D:\foo\bar\baz I can only create D:\foo\bar
http://dlang.org/phobos/std_file.html#.mkdirRecurse
td.window
On Tuesday, 9 February 2016 at 20:48:01 UTC, Steven Schveighoffer
wrote:
On 2/9/16 3:40 PM, Charles wrote:
This seems to be true of any range function really... is there
a way to
access the key within my range?
Example of what I want to do:
auto x = [1,2,3,4,5];
x.filter( x_key % 2 == 1 ).sum
On Tuesday, 9 February 2016 at 20:44:34 UTC, cym13 wrote:
On Tuesday, 9 February 2016 at 20:40:44 UTC, Charles wrote:
This seems to be true of any range function really... is there
a way to access the key within my range?
Example of what I want to do:
auto x = [1,2,3,4,5];
x.filter( x_key % 2
On 2/9/16 3:40 PM, Charles wrote:
This seems to be true of any range function really... is there a way to
access the key within my range?
Example of what I want to do:
auto x = [1,2,3,4,5];
x.filter( x_key % 2 == 1 ).sum(); // sum odd elements in array
An array is not an indexed range. It onl
On Tuesday, 9 February 2016 at 20:40:44 UTC, Charles wrote:
This seems to be true of any range function really... is there
a way to access the key within my range?
Example of what I want to do:
auto x = [1,2,3,4,5];
x.filter( x_key % 2 == 1 ).sum(); // sum odd elements in array
x.filter!(x_k
This seems to be true of any range function really... is there a
way to access the key within my range?
Example of what I want to do:
auto x = [1,2,3,4,5];
x.filter( x_key % 2 == 1 ).sum(); // sum odd elements in array
It's look like that I can only create one nesting level sub
folder, for example there is exists dir: D:\foo
I can't create dir D:\foo\bar\baz I can only create D:\foo\bar
D:\foo\bar
Is it's rational limit or it is bug? Here is error when I tried
to folder in folder thet do not exists.
It's n
On Tuesday, 9 February 2016 at 17:54:30 UTC, Basile B. wrote:
On Tuesday, 9 February 2016 at 15:21:59 UTC, Basile B. wrote:
On Monday, 8 February 2016 at 20:48:29 UTC, cy wrote:
On Monday, 8 February 2016 at 18:57:52 UTC, Basile B. wrote:
Otherwise, it sounds like a decent enhancement request
On Tuesday, 9 February 2016 at 15:21:59 UTC, Basile B. wrote:
On Monday, 8 February 2016 at 20:48:29 UTC, cy wrote:
On Monday, 8 February 2016 at 18:57:52 UTC, Basile B. wrote:
Otherwise, it sounds like a decent enhancement request for
DMD. I know other compilers who do this warning.
It defi
On Tuesday, 9 February 2016 at 14:35:48 UTC, Ola Fosheim Grøstad
wrote:
Not incredibly high level abstraction... But I get what you
mean. It is fairly high level for a low level language.
Coming from C#, it looks amazing but probably not that incredible
when coming from C++.
So you want th
On Tue, 09 Feb 2016 14:35:48 +, Ola Fosheim Grøstad wrote:
> On Tuesday, 9 February 2016 at 13:41:30 UTC, NX wrote:
>> There are several reasons I want to use D rather than C# / Go /
>> something else:
>> - Interfacing with native API without jumping through hoops
>
> Well, but the hoops are
On Tuesday, 9 February 2016 at 16:58:03 UTC, Daniel Kozak wrote:
On Tuesday, 9 February 2016 at 16:52:09 UTC, Gary Willoughby
wrote:
On Tuesday, 9 February 2016 at 12:50:27 UTC, Jakob Ovrum wrote:
writefln et al sensibly does *not* assume that a pointer to
char is a C string, for memory safety
On Tuesday, 9 February 2016 at 16:52:09 UTC, Gary Willoughby
wrote:
On Tuesday, 9 February 2016 at 12:50:27 UTC, Jakob Ovrum wrote:
writefln et al sensibly does *not* assume that a pointer to
char is a C string, for memory safety purposes.
Print the result of std.string.fromStringz[1] instead:
On Tuesday, 9 February 2016 at 16:52:09 UTC, Gary Willoughby
wrote:
On Tuesday, 9 February 2016 at 12:50:27 UTC, Jakob Ovrum wrote:
writefln et al sensibly does *not* assume that a pointer to
char is a C string, for memory safety purposes.
Print the result of std.string.fromStringz[1] instead:
On Tuesday, 9 February 2016 at 12:50:27 UTC, Jakob Ovrum wrote:
writefln et al sensibly does *not* assume that a pointer to
char is a C string, for memory safety purposes.
Print the result of std.string.fromStringz[1] instead:
writeln(fromStringz(pString));
writefln("%s", fromStringz(pString))
On Tuesday, 9 February 2016 at 16:00:09 UTC, Marc Schütz wrote:
2. Tuples use structural typing, not nominal typing.
This has no relevance for the question at hand.
It does if you allow casting and to use tuples a types in
aggregates. The language becomes less strongly typed.
3. They are i
https://github.com/D-Programming-Language/phobos/blob/v2.070.0/std/concurrency.d#L340
formattedWrite(sink, "Tid(%x)", &mbox);
should be:
formattedWrite(sink, "Tid(%x)", cast(void *)mbox);
On Tue, Feb 9, 2016 at 5:25 PM, Daniel Kozak wrote:
> You are right:
> import std.stdio, std.concurrency;
You are right:
import std.stdio, std.concurrency;
import std.concurrency : MessageBox;
struct MyTid
{
MessageBox mbox;
}
static void f1() {
auto tT = cast(MyTid)thisTid;
auto oT = cast(MyTid)ownerTid;
writeln("F1:worker: ", cast(void*)tT.mbox);
writeln("F1:owner: ", cast(void*
On Tuesday, 9 February 2016 at 14:28:35 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 9 February 2016 at 13:43:16 UTC, Marc Schütz wrote:
So what? Using that argument, you could just as well forbid
taking the address of any variable. What's so special about
tuples, in contrast to structs and arra
On Tuesday, 9 February 2016 at 15:55:34 UTC, Ali Çehreli wrote:
On 02/09/2016 07:52 AM, Daniel Kozak via Digitalmars-d-learn
wrote:
It is OK, I guess the output is just mixed
Yes, that's an important point but it is not the reason. (Just
tested.)
I think this is just an issue with how Tid o
OK it seems wierd
On Tue, Feb 9, 2016 at 4:52 PM, Daniel Kozak wrote:
> It is OK, I guess the output is just mixed
>
> On Tue, Feb 9, 2016 at 4:35 PM, miazo via Digitalmars-d-learn <
> digitalmars-d-learn@puremagic.com> wrote:
>
>> Hi,
>>
>> The following simple program:
>>
>> import std.stdio,
On 02/09/2016 07:52 AM, Daniel Kozak via Digitalmars-d-learn wrote:
It is OK, I guess the output is just mixed
Yes, that's an important point but it is not the reason. (Just tested.)
I think this is just an issue with how Tid objects are printed.
Otherwise, everything works as expected and al
It is OK, I guess the output is just mixed
On Tue, Feb 9, 2016 at 4:35 PM, miazo via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
> Hi,
>
> The following simple program:
>
> import std.stdio, std.concurrency;
>
> void f1() {
> writeln("owner: ", ownerTid);
> writeln("wo
Hi,
The following simple program:
import std.stdio, std.concurrency;
void f1() {
writeln("owner: ", ownerTid);
writeln("worker: ", thisTid);
}
void main() {
writeln("owner: ", thisTid);
writeln("worker: ", spawn(&f1));
}
Gives me the following result:
owner: Tid(18fd58)
worke
On Monday, 8 February 2016 at 20:48:29 UTC, cy wrote:
On Monday, 8 February 2016 at 18:57:52 UTC, Basile B. wrote:
Otherwise, it sounds like a decent enhancement request for
DMD. I know other compilers who do this warning.
It definitely does sound like a decent enhancement request. I
didn't
On Tuesday, 9 February 2016 at 13:01:29 UTC, NX wrote:
Well, GC being better than it used to be doesn't change the
fact it's still the > worst of it's kind. I don't know if
this[1] work actually got released or merged but looks like
it's abandoned. Pretty sad as it seemed very promising.
[1]
h
On Tuesday, 9 February 2016 at 03:49:11 UTC, Enjoys Math wrote:
This:
double b = 1.0;
Variant[string] aa = ["b": &b];
writeln(aa["b"]);
fails with:
Error: cannot implicitly convert expression(["b":&b]) of type
double*[string] to VariantN!20u[string]
Helps please!
On Tuesday, 9 February 2016 at 13:41:30 UTC, NX wrote:
There are several reasons I want to use D rather than C# / Go /
something else:
- Interfacing with native API without jumping through hoops
Well, but the hoops are there to get safe and fast GC.
- Incredibly high abstraction and meta-pro
On Tuesday, 9 February 2016 at 13:43:16 UTC, Marc Schütz wrote:
So what? Using that argument, you could just as well forbid
taking the address of any variable. What's so special about
tuples, in contrast to structs and arrays?
Some key common qualities for a tuple:
1. They are primarily used
On Tuesday, 9 February 2016 at 13:01:29 UTC, NX wrote:
On Monday, 8 February 2016 at 22:21:50 UTC, Laeeth Isharc wrote:
The GC itself may still be far from perfect but its much
better than it was, and there are more options now. I have
found emsi containers (built on top of Andrei's allocator)
On Tuesday, 9 February 2016 at 11:38:14 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 9 February 2016 at 10:54:42 UTC, Marc Schütz wrote:
No need to restrict the language here, there's nothing
stopping a decent compiler from storing tuples (actually
_anything_) in registers, in some cases even if
On Monday, 8 February 2016 at 17:51:02 UTC, Ola Fosheim Grøstad
wrote:
C++ compilers have lots of optional warnings/errors, so it is
quite possible. But I suppose those that want it would rather
use Go, C# or some other GC language than can do ahead of time
compilation.
There are several reas
On Monday, 8 February 2016 at 22:21:50 UTC, Laeeth Isharc wrote:
The GC itself may still be far from perfect but its much better
than it was, and there are more options now. I have found emsi
containers (built on top of Andrei's allocator) pretty nice
myself for my own use.
Well, GC being be
On Tuesday, 9 February 2016 at 12:46:59 UTC, Whirlpool wrote:
Hello,
When you are using a C function (from an external library) that
returns a pointer on char which is the beginning of a string (I
know that C does not have a string type, that they are just
arrays of chars ended by '\0'), is t
On Tuesday, 9 February 2016 at 12:46:59 UTC, Whirlpool wrote:
Hello,
When you are using a C function (from an external library) that
returns a pointer on char which is the beginning of a string (I
know that C does not have a string type, that they are just
arrays of chars ended by '\0'), is t
V Tue, 09 Feb 2016 12:46:59 +
Whirlpool via Digitalmars-d-learn
napsáno:
> Hello,
>
> When you are using a C function (from an external library) that
> returns a pointer on char which is the beginning of a string (I
> know that C does not have a string type, that they are just
> arrays of
Hello,
When you are using a C function (from an external library) that
returns a pointer on char which is the beginning of a string (I
know that C does not have a string type, that they are just
arrays of chars ended by '\0'), is there a simple way to print
that string with D's write(f)ln, sh
On Tuesday, 9 February 2016 at 10:54:42 UTC, Marc Schütz wrote:
No need to restrict the language here, there's nothing stopping
a decent compiler from storing tuples (actually _anything_) in
registers, in some cases even if references are taken. I'm
pretty sure LLVM can handle this.
If you do
On Tuesday, 9 February 2016 at 09:05:58 UTC, Ola Fosheim Grøstad
wrote:
IMO one shouldn't be able to take the reference of a tuple, to
ensure that it can be kept in registers.
No need to restrict the language here, there's nothing stopping a
decent compiler from storing tuples (actually _anyth
On Tuesday, 9 February 2016 at 08:35:21 UTC, tsbockman wrote:
When faced with a judgment call like this, we really ought to
err on the side of maintaining backwards compatibility -
especially since this does not preclude adding a separate
by-value version of `Tuple.slice`, as well. It was going
On Tuesday, 9 February 2016 at 06:22:55 UTC, Marco Leise wrote:
As mentioned I never used the feature myself and wont vote for
one or the other. Three people with no source code to exemplify
current use of .slice! is indeed not much to base decisions
on...
The mere fact that all I had to do t
59 matches
Mail list logo
