Re: Octree implementation?
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 looking to save some > >> time. > > > > I have one written in Delphi that you could prune till it fits. > > I ended up writing my own, Benjamin's was a little hard to fit to > my own code but I got some good ideas from it, particularly I > didn't really know about loose octrees but they are definitely a > good idea. I was mostly joking anyways about pruning D(elphi) to D. That was years ago and I have yet to read up on those loose octrees. -- Marco
Re: Printing a C "string" with write(f)ln
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 design choice. It ensures the string is handled by the D GC instead of the C side freeing it. `fromStringz` and `to!(String)` are for different cases. You clearly didn't read the discussion in the link. And, when copying is desired, I'll take fromStringz(cstr).idup over to!string any day.
Re: Octree implementation?
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 till it fits. I ended up writing my own, Benjamin's was a little hard to fit to my own code but I got some good ideas from it, particularly I didn't really know about loose octrees but they are definitely a good idea.
Re: Is this a bug in std.typecons.Tuple.slice?
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
Re: algorithm's .filter!() by range key
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,3,4,5];
x.filter( x_key % 2 == 1 ).sum(); // sum odd elements in array
An array is not an indexed range. It only works with foreach by key
because of special foreach behavior.
What you want is std.range.enumerate
Exactly! Thanks!
Interestingly, hackerrank doesn't seem to have it. They're using
2.067.0-b1 on Ubuntu 14.04.
For this specific problem, you can combine drop() and stride() (and even
sum()! ;) ):
import std.range;
import std.algorithm;
import std.stdio;
void main()
{
auto x = [1, 2, 3, 4, 5];
writeln(x.drop(1).stride(2).sum); // 6
}
Ali
Re: Automatic range creation for class or struct?
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 counter, .popFront(),
.empty() etc methods should be added by template.)
I don't think anything like that exists in phobos but it's not hard to
pull it out using mixin templates:
mixin template Rangify(T)
if (__traits(hasMember, T, "length")
&& __traits(hasMember, T, "opIndex")) {
ulong _counter;
bool empty() {
return _counter == this.length;
}
auto front() {
return this[_counter];
}
auto popFront() {
_counter++;
}
}
struct S {
int[] arr;
mixin Rangify!S;
auto length() {
return arr.length;
}
int opIndex(size_t i) {
return arr[i];
}
}
void main(string[] args) {
import std.stdio: writeln;
auto s = S();
s.arr = [1, 2, 3];
foreach (x ; s)
writeln(x);
}
Actually, your method can work non-intrusively if the template is a
function that returns a range (typically Voldemort):
auto rangify(T)(T range)
if (__traits(hasMember, T, "length")
&& __traits(hasMember, T, "opIndex")) {
struct Range {
T range;
ulong _counter;
bool empty() {
return _counter == range.length;
}
auto front() {
return range[_counter];
}
auto popFront() {
_counter++;
}
}
return Range(range);// <-- Now returns a Voldemort object
}
struct S { // <-- No mixin needed
int[] arr;
auto length() {
return arr.length;
}
int opIndex(size_t i) {
return arr[i];
}
}
void main(string[] args) {
import std.stdio: writeln;
auto s = S();
s.arr = [1, 2, 3];
foreach (x ; s.rangify)// <-- CHANGED
writeln(x);
}
Ali
Re: Automatic range creation for class or struct?
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 said "I don't think" I actually meant "I've searched the docs and sources and haven't found anything even remotely similar". I'll never be 100% percent sure that it isn't there though, you're free to read phobos to confirm it.
Re: Automatic range creation for class or struct?
I don't think anything like that exists in phobos I need definitive answer. I need a precise answer. (sorry, google translator :з)
Re: Automatic range creation for class or struct?
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? (I mean that internal counter, .popFront(), .empty() etc methods should be added by template.) I don't think anything like that exists in phobos I need definitive answer. but it's not hard to pull it out using mixin templates: Sure! Thanks a lot, but I want to use std lib as much as possible
Re: Is this a bug in std.typecons.Tuple.slice?
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 data *right now*. Some sort of short-term fix should be merged in the next release of D.
Re: Automatic range creation for class or struct?
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 methods should be added by template.)
I don't think anything like that exists in phobos but it's not
hard to pull it out using mixin templates:
mixin template Rangify(T)
if (__traits(hasMember, T, "length")
&& __traits(hasMember, T, "opIndex")) {
ulong _counter;
bool empty() {
return _counter == this.length;
}
auto front() {
return this[_counter];
}
auto popFront() {
_counter++;
}
}
struct S {
int[] arr;
mixin Rangify!S;
auto length() {
return arr.length;
}
int opIndex(size_t i) {
return arr[i];
}
}
void main(string[] args) {
import std.stdio: writeln;
auto s = S();
s.arr = [1, 2, 3];
foreach (x ; s)
writeln(x);
}
Automatic range creation for class or struct?
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.)
Re: why mkdir can't create tree of dirs?
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 it is bug? Here is error when I tried > to folder in folder thet do not exists. > > It's not very handy to write all levels by hands... > > td.windows.syserror.WindowsException@C:\D\dmd2\windows\bin\..\..\src\phobos\stdfile.d(2048): > F:\foo\imgs_projected\jma_vis\1602\123: ╨б╨╕╤Б╤В╨╡╨╝╨╡ ╨╜╨╡ ╤Г╨┤╨╨╡╤В╤Б╤П > ╨╜╨░╨╣╤В╨╕ ╤Г╨║╨░╨╖╨░╨╜╨╜╤Л╨╣ ╨┐╤Г╤В╤М. (error 3) You can use std.file.mkdirRecurse instead of std.file.mkdir. std.file.mkdirRecurse is similar to mkdir -p like std.file.mkdir is similar to mkdir. - Jonathan M Davis
Re: Printing a C "string" with write(f)ln
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 of the C side freeing it. `fromStringz` and `to!(String)` are for different cases.
Re: Printing a C "string" with write(f)ln
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 instead of worrying about the lifetime of pString.
Re: UFCS on Enum in Member Function
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 with methods.
Re: why mkdir can't create tree of dirs?
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
UFCS on Enum in Member Function
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 when I use the alternate version of Caz calling a
non-member function.
Bug?
enum X
{
A = 1,
}
struct Foo
{
X Bar(X x)
{
return x;
}
X Baz()
{
auto result = X.A;
return Bar(result);
}
/*
X Caz()
{
auto result = X.A;
return result.Bar();
}
*/
X Caz_alt()
{
auto result = X.A;
return result.Bar_alt();
}
}
X Bar_alt(X x)
{
return x;
}
void main()
{
auto foo = Foo();
auto result = foo.Baz();
//auto result2 = foo.Caz();
auto result3 = foo.Caz_alt();
}
Re: why mkdir can't create tree of dirs?
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.windows.syserror.WindowsException@C:\D\dmd2\windows\bin\..\..\src\phobos\stdfile.d(2048): F:\foo\imgs_projected\jma_vis\1602\123: ╨б╨╕╤Б╤В╨╡╨╝╨╡ ╨╜╨╡ ╤Г╨┤╨╨╡╤В╤Б╤П ╨╜╨░╨╣╤В╨╕ ╤Г╨║╨░╨╖╨░╨╜╨╜╤Л╨╣ ╨┐╤Г╤В╤М. (error 3) What's up with that garbled text?
Re: algorithm's .filter!() by range key
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(); // sum odd elements in array An array is not an indexed range. It only works with foreach by key because of special foreach behavior. What you want is std.range.enumerate Exactly! Thanks! Interestingly, hackerrank doesn't seem to have it. They're using 2.067.0-b1 on Ubuntu 14.04.
Re: algorithm's .filter!() by range key
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 == 1 ).sum(); // sum odd elements in array x.filter!(x_key => x_key % 2 == 1).sum(); Oh man, I really messed up my example, and did a poor one at that. Better example: auto x = [2,4,6,8,10]; x.filter( x_key => x_key % 2 == 1 ).sum(); // sums 2 + 6 + 10 == 18
Re: algorithm's .filter!() by range key
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 only works with foreach by key
because of special foreach behavior.
What you want is std.range.enumerate:
import std.range;
import std.algorithm;
import std.stdio;
void main()
{
auto x = [1, 2, 3, 4, 5];
writeln(x.enumerate.filter!(a => a[0] % 2 == 1).map!(a =>
a[1]).sum); // 6
}
-Steve
Re: algorithm's .filter!() by range key
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_key => x_key % 2 == 1).sum();
algorithm's .filter!() by range key
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
why mkdir can't create tree of dirs?
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 not very handy to write all levels by hands... td.windows.syserror.WindowsException@C:\D\dmd2\windows\bin\..\..\src\phobos\stdfile.d(2048): F:\foo\imgs_projected\jma_vis\1602\123: ╨б╨╕╤Б╤В╨╡╨╝╨╡ ╨╜╨╡ ╤Г╨┤╨╨╡╤В╤Б╤П ╨╜╨░╨╣╤В╨╕ ╤Г╨║╨░╨╖╨░╨╜╨╜╤Л╨╣ ╨┐╤Г╤В╤М. (error 3)
Re: How to warn of unused imports?
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 for DMD. I know other compilers who do this warning. It definitely does sound like a decent enhancement request. I didn't know it wasn't implemented yet, but it should be pretty straightforward, since within DMD you can access the AST. Alternatively, implementing DIP50 might let you do it outside the compiler. http://wiki.dlang.org/DIP50 DIP50 is a "golem" It looks usefull, and it will help in many cases...but after a while it'll become a problem. If you don't understand what's a "golem": AlquiaDa was the golem of the CIA (in the 80's while russians were fighting in Afgnan). Useful until a certain point. Useful until a certain point... It's time for me to leave...once again alcool drives me crazy... Latest weeks I've been ofensive against two guys: kinsley and lopatim...it's time for me to leave. https://www.youtube.com/watch?v=6ixdPnLFVIo seeya.
Re: How to warn of unused imports?
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 definitely does sound like a decent enhancement request. I didn't know it wasn't implemented yet, but it should be pretty straightforward, since within DMD you can access the AST. Alternatively, implementing DIP50 might let you do it outside the compiler. http://wiki.dlang.org/DIP50 DIP50 is a "golem" It looks usefull, and it will help in many cases...but after a while it'll become a problem. If you don't understand what's a "golem": AlquiaDa was the golem of the CIA (in the 80's while russians were fighting in Afgnan). Useful until a certain point. Useful until a certain point...
Re: Things that keep D from evolving?
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 this to be worked on (as D has a horribly slow one)? I would want it to be solved rather than being worked on... which requires design change which is probably not going to happen. There is still room for improvement though. Doesn't C# work just as well as D (or better) with most platforms? There are differences, but yeah I shouldn't have said that ~ cross-platform thingy is not a valid argument against C# anymore.
Re: Things that keep D from evolving?
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 there to get safe and fast GC. > > >> - Incredibly high abstraction and meta-programming possibilities with >> relatively easier syntax + semantics. > > Not incredibly high level abstraction... But I get what you mean. It is > fairly high level for a low level language. > > >> - Having GC (but not a horribly slow one) > > So you want this to be worked on (as D has a horribly slow one)? > > >> - Not bound to a specific platform (unlike C#, easier to do >> cross-platform work in many cases) > > Doesn't C# work just as well as D (or better) with most platforms? If you develop against .NET on Windows, you have a moderate chance of producing something non-portable. If you develop against Mono on Linux, you can produce something more portable more easily. Mono, by the way, has a good garbage collector, and .NET probably has better. Mono advertises: * precise scanning for stack, heap, and registers * generational collection using write barriers * per-thread sub-heaps for faster allocation * multithreaded scanning I think D could implement all that with a couple caveats. Write barriers are a problem for real-time code. Right now, we can tell you: you can write code with real-time sections as long as you don't allocate GC memory in the real-time sections. If we introduced write barriers, well, the most straightforward way of doing that is to use memory protection and install a fault handler. If you write to a page that hasn't been written to since the last collection, you get a page fault, the kernel dispatches it to your fault handler, the fault handler marks a "card" (it sets a boolean corresponding to the page you tried to write to). Then the handler marks that page as writable and you go on with your day. Alternatively, the compiler could insert code at every pointer write. (This is the deamortized version. Consistent latency, but if you write to the same pointer variable a million times between GC allocations, you pay that cost a million times more than you really need to.) You would need a compiler switch to disable this behavior. That's not likely to happen. Walter and Andrei would not accept that, since it makes it difficult to get bare-metal performance (and also makes it harder to interface with C). Which leads me to another thing holding D back. What use cases are we trying to support? What are we trying to optimize for? Apparently everything. That doesn't work. To some extent you can make things faster in general, but you'll still end up supporting all use cases moderately well and none exceedingly well. Anyway, another GC issue is supporting generational collection. You need a moving GC to make it work efficiently. D could support a moving collector, but it would require more runtime type information. (And stack maps, but that might be there already. Not sure.) Walter has been strongly against adding extra runtime type information in the past.
Re: Printing a C "string" with write(f)ln
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 purposes.
Print the result of std.string.fromStringz[1] instead:
writeln(fromStringz(pString));
writefln("%s", fromStringz(pString));
[1] http://dlang.org/phobos/std_string#fromStringz
Or use `to` like this:
import std.conv;
writefln("%s", pString.to!(string));
this will allocate new string which can be performance problem.
Maybe:
writefln("%s", pString.to!(char[]));
But I do not know if this works and does not allocate
void main() {
char[] chars = cast(char[])"Ahoj svete";
char* cstr = chars.ptr;
auto s1 = to!string(cstr);
auto s2 = to!(char[])(cstr);
auto s3 = fromStringz(cstr);
writeln(cstr); //46D310
writeln(s1.ptr); //7F0062EF1000
writeln(s2.ptr); //7F0062EF1010
writeln(s3.ptr); //46D310
}
Re: Printing a C "string" with write(f)ln
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:
writeln(fromStringz(pString));
writefln("%s", fromStringz(pString));
[1] http://dlang.org/phobos/std_string#fromStringz
Or use `to` like this:
import std.conv;
writefln("%s", pString.to!(string));
to!string behaving like that was a poor design choice[1]. Please
use fromStringz.
[1] https://github.com/D-Programming-Language/phobos/pull/1607
Re: Printing a C "string" with write(f)ln
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:
writeln(fromStringz(pString));
writefln("%s", fromStringz(pString));
[1] http://dlang.org/phobos/std_string#fromStringz
Or use `to` like this:
import std.conv;
writefln("%s", pString.to!(string));
this will allocate new string which can be performance problem.
Maybe:
writefln("%s", pString.to!(char[]));
But I do not know if this works and does not allocate
Re: Printing a C "string" with write(f)ln
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));
[1] http://dlang.org/phobos/std_string#fromStringz
Or use `to` like this:
import std.conv;
writefln("%s", pString.to!(string));
Re: Is this a bug in std.typecons.Tuple.slice?
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 identity-less. If you can take reference and compare, they no longer are identity-less. Like value types in general, nothing special about tuples here. I don't know what you mean by that. D doesn't provide proper value types. If you can compare identities (address) then it is not a value, but an object. I believe it's more because the concept is more frequently used in functional programming languages, for which immutability is not surprising. Other languages do have mutable tuples, e.g. Swift and C++11 (std::tuple). C++ doesn't have real tuples. I don't know the details of Swift regarding tuples, but Swift is an OO language that does not aim for high performance or very strong typing. As said above, wanting to avoid spilling is not a reason to disallow spilling. Besides, fixed-size arrays seem more similar to SIMD registers, and they don't have the restrictions you tuples to have. Well, I disagree. There is very little reason to encourage people to use tuples for storage, you end up with a weaker typed language and less performant code. (You can do various types of packing in registers too, depends on the CPU.)
Re: std.concurrency: ownerTid vs thisTid
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;
> 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*)oT.mbox);
> }
>
> void main() {
> auto tT = cast(MyTid)thisTid();
> auto sT = cast(MyTid)spawn(&f1);
> writeln("Main:worker: ", cast(void *)sT.mbox);
> writeln("Main:owner: ", cast(void *)tT.mbox);
> }
>
>
> On Tue, Feb 9, 2016 at 4:55 PM, 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 objects are printed. Otherwise,
>> everything works as expected and although they print the same value,
>> "worker1 != worker2" is true as well.
>>
>> Ali
>>
>
Re: std.concurrency: ownerTid vs thisTid
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*)oT.mbox);
}
void main() {
auto tT = cast(MyTid)thisTid();
auto sT = cast(MyTid)spawn(&f1);
writeln("Main:worker: ", cast(void *)sT.mbox);
writeln("Main:owner: ", cast(void *)tT.mbox);
}
On Tue, Feb 9, 2016 at 4:55 PM, Ali Çehreli <
digitalmars-d-learn@puremagic.com> 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 objects are printed. Otherwise,
> everything works as expected and although they print the same value,
> "worker1 != worker2" is true as well.
>
> Ali
>
>
Re: Is this a bug in std.typecons.Tuple.slice?
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 arrays? Some key common qualities for a tuple: 1. They are primarily used for multiple return values from functions. As you said, primarily. There's no reason not to use them for something else. 2. Tuples use structural typing, not nominal typing. This has no relevance for the question at hand. 3. They are identity-less. If you can take reference and compare, they no longer are identity-less. Like value types in general, nothing special about tuples here. Tuples should be considered immutable constants (think functional programming), not in-memory storage. Again, why? Because that is how a tuple is commonly defined, for performance and semantic reasons. I believe it's more because the concept is more frequently used in functional programming languages, for which immutability is not surprising. Other languages do have mutable tuples, e.g. Swift and C++11 (std::tuple). Tuple's can serve as a good approximation to SIMD registers. What relation does that have to the above? You don't want to spill out SIMD registers to the stack if you can avoid it. You want to do the changes within the CPU pipeline, i.e. using copies (and register renaming). As said above, wanting to avoid spilling is not a reason to disallow spilling. Besides, fixed-size arrays seem more similar to SIMD registers, and they don't have the restrictions you tuples to have.
Re: std.concurrency: ownerTid vs thisTid
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 objects are printed. Otherwise, everything works as expected and although they print the same value, "worker1 != worker2" is true as well. Ali Well, I'm not concerned about the order of the output but the actual values of these ids. Shouldn't it be rather: owner: Tid(18fd58) worker: Tid(24afe38) owner: Tid(18fd58) worker: Tid(24afe38) or owner: Tid(24afe38) worker: Tid(18fd58) owner: Tid(24afe38) worker: Tid(18fd58) ?
Re: std.concurrency: ownerTid vs thisTid
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, 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)
>> worker: Tid(18fd58)
>> owner: Tid(24afe38)
>> worker: Tid(24afe38)
>>
>> Is it correct? My expectation was that:
>> - thisTid called from main will be the same as ownerTid called from f1
>> - thisTid called from f1 will be the same as value returned by spawn()
>>
>> Thank you for your help.
>>
>>
>
Re: std.concurrency: ownerTid vs thisTid
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 although they print the same value, "worker1 != worker2" is true as well. Ali
Re: std.concurrency: ownerTid vs thisTid
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("worker: ", thisTid);
> }
>
> void main() {
> writeln("owner: ", thisTid);
> writeln("worker: ", spawn(&f1));
> }
>
> Gives me the following result:
>
> owner: Tid(18fd58)
> worker: Tid(18fd58)
> owner: Tid(24afe38)
> worker: Tid(24afe38)
>
> Is it correct? My expectation was that:
> - thisTid called from main will be the same as ownerTid called from f1
> - thisTid called from f1 will be the same as value returned by spawn()
>
> Thank you for your help.
>
>
std.concurrency: ownerTid vs thisTid
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)
worker: Tid(18fd58)
owner: Tid(24afe38)
worker: Tid(24afe38)
Is it correct? My expectation was that:
- thisTid called from main will be the same as ownerTid called
from f1
- thisTid called from f1 will be the same as value returned by
spawn()
Thank you for your help.
Re: How to warn of unused imports?
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 know it wasn't implemented yet, but it should be pretty straightforward, since within DMD you can access the AST. Alternatively, implementing DIP50 might let you do it outside the compiler. http://wiki.dlang.org/DIP50 DIP50 is a "golem" It looks usefull, and it will help in many cases...but after a while it'll become a problem.
Re: Things that keep D from evolving?
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] http://forum.dlang.org/thread/mailman.655.1399956110.2907.digitalmar...@puremagic.com It looks like interesting stuff, but the guy last posted in 2014. In other posts, people asked him for the code and I don't see anything on the forum indicating that he provided it. Probably an important step to improving the GC... DMD 2.067 had some garbage collector improvements, but I'm not sure how influenced those would have been by this.
Re: How do you reference variables in an AA of Variants?
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! I've found bugbears like this are distressingly common in std.variant. Another one you might find yourself dealing with is https://issues.dlang.org/show_bug.cgi?id=10223, which applies to AAs as much as regular arrays. It's actually why I stopped using it in favour of Adam Ruppe's arsd.jsvar. -Wyatt
Re: Things that keep D from evolving?
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-programming possibilities with relatively easier syntax + semantics. Not incredibly high level abstraction... But I get what you mean. It is fairly high level for a low level language. - Having GC (but not a horribly slow one) So you want this to be worked on (as D has a horribly slow one)? - Not bound to a specific platform (unlike C#, easier to do cross-platform work in many cases) Doesn't C# work just as well as D (or better) with most platforms?
Re: Is this a bug in std.typecons.Tuple.slice?
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 for multiple return values from functions. 2. Tuples use structural typing, not nominal typing. 3. They are identity-less. If you can take reference and compare, they no longer are identity-less. Tuples should be considered immutable constants (think functional programming), not in-memory storage. Again, why? Because that is how a tuple is commonly defined, for performance and semantic reasons. Tuple's can serve as a good approximation to SIMD registers. What relation does that have to the above? You don't want to spill out SIMD registers to the stack if you can avoid it. You want to do the changes within the CPU pipeline, i.e. using copies (and register renaming).
Re: Things that keep D from evolving?
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) pretty nice myself for my own use. 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. Anyway, I was expecting a lot more people to tell their specific problems, like "bla bla design desicion makes ARC incredibly dangerous and we can't properly interface with Objective-C without that" or like "bla bla D feature overlaps with some other stuff and requires redesign to be solved" or maybe "being unsafe (@system) by default breaks the deal"... GC is just one of the hundreds of problems with D and it was an example rather than the main point in this thread but thanks for anyone who replied. [1] http://forum.dlang.org/thread/mailman.655.1399956110.2907.digitalmar...@puremagic.com Thanks for pointing this one out. Opportunity comes dressed in work clothes,and I guess that until someone takes the initiative to integrate this with the newest version of the runtime / GC then nothing will happen. It's not true that there are no professional opportunities in D, as some people say, and I can say that for some people at least impressive contributions to the language and community have paid off personally even though it was a labour of love and not motivated by that. Good programmers don't grow on trees, and one benefit of the current size of the D community is that it's easier to make an impact and easier to stand out than in a much more crowded and mature domain where one person can only hope to achieve incremental progress. My impression is that barriers to adoption are fairly well understood by now and it's a matter of time and hard work for them to be addressed step by step. It's not only addressing negatives but also completing positive things that will help. Ndslice and porting BLAS on the numerical side and the interface with R will both increase the attractiveness of D on finance, not a small area. It's not yet mature, but knowing one can use all the R libraries is already a big win.
Re: Is this a bug in std.typecons.Tuple.slice?
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 references are taken. I'm pretty sure LLVM can handle this. If you don't restrict the language people will write code that the optimizer will struggle with. 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? LLVM can only handle what goes on within a compilation unit, and not if there are stores, because those are visible in other threads. Tuples should be considered immutable constants (think functional programming), not in-memory storage. Again, why? Tuple's can serve as a good approximation to SIMD registers. What relation does that have to the above?
Re: Things that keep D from evolving?
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 reasons I want to use D rather than C# / Go / something else: - Interfacing with native API without jumping through hoops - Incredibly high abstraction and meta-programming possibilities with relatively easier syntax + semantics. - It's harder to reverse engineer native code than byte code equivalent. - Trading off anything according to your needs. - Expressiveness and purity, immutablity concepts. - Having GC (but not a horribly slow one) - Syntactic sugars (associtive arrays, powerful foreach, slices...) - Compile times - Not bound to a specific platform (unlike C#, easier to do cross-platform work in many cases) I wish D could be better. I really want it with all of my heart...
Re: Things that keep D from evolving?
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 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. Anyway, I was expecting a lot more people to tell their specific problems, like "bla bla design desicion makes ARC incredibly dangerous and we can't properly interface with Objective-C without that" or like "bla bla D feature overlaps with some other stuff and requires redesign to be solved" or maybe "being unsafe (@system) by default breaks the deal"... GC is just one of the hundreds of problems with D and it was an example rather than the main point in this thread but thanks for anyone who replied. [1] http://forum.dlang.org/thread/mailman.655.1399956110.2907.digitalmar...@puremagic.com
Re: Printing a C "string" with write(f)ln
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 there a simple way to print
that string with D's write(f)ln, should I use C's printf, or
something else ? What is the best way ? Because if I do
writefln("... %s", *pString);
it only displays the first character of the string, the value
that pString points to
Thanks
sure:
http://dlang.org/phobos/std_string.html#.fromStringz
import std.string;
string dstring = my_c_string.fromStringz;
Re: Printing a C "string" with write(f)ln
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 there a simple way to print
that string with D's write(f)ln, should I use C's printf, or
something else ? What is the best way ? Because if I do
writefln("... %s", *pString);
it only displays the first character of the string, the value
that pString points to
Thanks
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));
[1] http://dlang.org/phobos/std_string#fromStringz
Re: Printing a C "string" with write(f)ln
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 chars ended by '\0'), is there a simple way to print
> that string with D's write(f)ln, should I use C's printf, or
> something else ? What is the best way ? Because if I do
> writefln("... %s", *pString);
> it only displays the first character of the string, the value
> that pString points to
>
> Thanks
http://dlang.org/phobos/std_string.html#.fromStringz
Printing a C "string" with write(f)ln
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, should I use C's printf, or
something else ? What is the best way ? Because if I do
writefln("... %s", *pString);
it only displays the first character of the string, the value
that pString points to
Thanks
Re: Is this a bug in std.typecons.Tuple.slice?
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 don't restrict the language people will write code that the optimizer will struggle with. LLVM can only handle what goes on within a compilation unit, and not if there are stores, because those are visible in other threads. Tuples should be considered immutable constants (think functional programming), not in-memory storage. Tuple's can serve as a good approximation to SIMD registers.
Re: Is this a bug in std.typecons.Tuple.slice?
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 _anything_) in registers, in some cases even if references are taken. I'm pretty sure LLVM can handle this.
Re: Is this a bug in std.typecons.Tuple.slice?
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 to need a new name anyway. I suggest lobbying for proper builtin tuple support. IMO one shouldn't be able to take the reference of a tuple, to ensure that it can be kept in registers. Modern desktop CPUs have maybe 512 bytes of register space. In most cases a tuple will be within 8 bytes * 16 or something like that.
Re: Is this a bug in std.typecons.Tuple.slice?
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 to find people who use and care about the `ref`-ness of `Tuple.slice` was ask, and then wait a few hours, strongly suggests that there are other such people among the D user base. 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 to need a new name anyway.
