Re: Is there a more elegant way to do this?

On Sunday, 12 March 2017 at 05:13:41 UTC, bauss wrote: I was wondering if there's a more elegant way to do something like this? template BitSize(T) { enum BitSize = T.sizeof * 8; } struct Data(ParentType,ChildType) { @property { ChildType low() { return

Re: Is there a more elegant way to do this?

On Sunday, 12 March 2017 at 05:13:41 UTC, bauss wrote: I was wondering if there's a more elegant way to do something like this? [...] I saw one improvement to it which would be BitSize!ChildType instead of taking parent type's bit size divided by two. Also value = ((highValue << 16 |

Is there a more elegant way to do this?

I was wondering if there's a more elegant way to do something like this? template BitSize(T) { enum BitSize = T.sizeof * 8; } struct Data(ParentType,ChildType) { @property { ChildType low() { return cast(ChildType)value; } void low(ChildType

[Issue 16210] std.utf.byUTF can be made into a bidirectional range

https://issues.dlang.org/show_bug.cgi?id=16210 --- Comment #2 from Jack Stouffer --- (In reply to Jakub Łabaj from comment #1) > Assuming "ö" == [0xC3, 0xB6], which one version would be correct: > a) behaviour of std.utf.byCodeUnit, just go by code units backward: >

Re: C interface provides a pointer and a length... wrap without copying?

On Sunday, March 12, 2017 02:47:19 cy via Digitalmars-d-learn wrote: > On Saturday, 11 March 2017 at 23:43:54 UTC, Nicholas Wilson wrote: > > A string *is* a pointer length pair, an immutable(char)[]. > > Yes, but surely there's some silly requirement, like that the > pointer must only ever point

ranges of characters and the overabundance of traits that go with them

Okay, I'm sorry, but this is a wall of text, and I don't know how to actually make it short. If you really want the TLDR version, look for the =='s at the bottom which mark off the conclusion, but you're not going to understand the reasoning if you skip the wall of text. Now, to the post...

Re: C interface provides a pointer and a length... wrap without copying?

cy wrote: On Saturday, 11 March 2017 at 23:43:54 UTC, Nicholas Wilson wrote: A string *is* a pointer length pair, an immutable(char)[]. Yes, but surely there's some silly requirement, like that the pointer must only ever point to garbage collected memory, or something? why should it? a

Re: C interface provides a pointer and a length... wrap without copying?

On Saturday, 11 March 2017 at 23:43:54 UTC, Nicholas Wilson wrote: A string *is* a pointer length pair, an immutable(char)[]. Yes, but surely there's some silly requirement, like that the pointer must only ever point to garbage collected memory, or something? ubyte[] arr; // or byte/char

Re: I think is a bug?

On Sunday, 12 March 2017 at 01:55:20 UTC, ketmar wrote: Random D user wrote: How come string* suddenly has a .length property? due to automatic pointer dereferencing that `.` does. no, not a bug. Ah... right. Silly me. Of course, since string is actually immutable(char)[]. That's bit of

Re: I think is a bug?

Random D user wrote: How come string* suddenly has a .length property? due to automatic pointer dereferencing that `.` does. no, not a bug.

I think is a bug?

int*[] foo; foo.length = 5; import std.c.string; int* baz = cast(string*)malloc(50); import std.c.stdio; printf("%d %d", foo.length, baz.length ); prints: Error: no property 'length' for type 'int*' BUT: string*[] foo; foo.length = 5; import std.c.string; string* baz =

Re: DMD win32.mak error

On Saturday, 11 March 2017 at 18:02:00 UTC, Stefan Koch wrote: On Saturday, 11 March 2017 at 02:25:15 UTC, Paul D Anderson wrote: On Saturday, 11 March 2017 at 00:34:03 UTC, Paul D Anderson wrote: On Friday, 10 March 2017 at 22:04:23 UTC, Paul D Anderson wrote: [...] I see John Colvin has

Re: C interface provides a pointer and a length... wrap without copying?

On Saturday, 11 March 2017 at 22:39:02 UTC, cy wrote: So a lovely C library does its own opaque allocation, and provides access to the malloc'd memory, and that memory's length. Instead of copying the results into garbage collected memory (which would probably be smart) I was thinking about

Re: Better ddoc defaults?

On Saturday, 11 March 2017 at 09:54:25 UTC, Yuxuan Shui wrote: On Friday, 10 March 2017 at 07:58:36 UTC, Petar Kirov [ZombineDev] wrote: On Thursday, 9 March 2017 at 21:08:17 UTC, Yuxuan Shui wrote: [...] My favorite one is: https://github.com/MartinNowak/scod. BTW, the default ddox (the

Dub and bindings

Are there any general tips or best practices for bindings in dub packages? For example, I love the d2sqlite3 package. It just works out of the box. No linker configuration or anything. However, that is probably a testament to sqlite's lack of dependencies. That cannot work for libraries,

Re: C interface provides a pointer and a length... wrap without copying?

cy wrote: So a lovely C library does its own opaque allocation, and provides access to the malloc'd memory, and that memory's length. Instead of copying the results into garbage collected memory (which would probably be smart) I was thinking about creating a structure like: struct

C interface provides a pointer and a length... wrap without copying?

So a lovely C library does its own opaque allocation, and provides access to the malloc'd memory, and that memory's length. Instead of copying the results into garbage collected memory (which would probably be smart) I was thinking about creating a structure like: struct WrappedString {

Re: Zcoin implementation bug enabled attacker to create 548, 000 Zcoins

On 11.03.2017 20:39, H. S. Teoh via Digitalmars-d wrote: On Sat, Mar 11, 2017 at 01:46:31PM +0100, Timon Gehr via Digitalmars-d wrote: On 10.03.2017 23:41, H. S. Teoh via Digitalmars-d wrote: Basically, operator syntax is just too specific to the arithmetical meanings of the operators that

[Issue 16210] std.utf.byUTF can be made into a bidirectional range

https://issues.dlang.org/show_bug.cgi?id=16210 Jakub Łabaj changed: What|Removed |Added CC||uaaabbj...@gmail.com

Re: How to debug D programs

On Monday, 8 August 2016 at 10:36:39 UTC, eugene wrote: Hello, everyone, question to you: how do you debug D programs on gnu/linux? and what ides are you using for debugging? I'm using emacs, it has great integration with gdb.

Re: Zcoin implementation bug enabled attacker to create 548, 000 Zcoins

On Friday, 10 March 2017 at 22:41:43 UTC, H. S. Teoh wrote: The problem is that "<<" was designed to be a bit-shift operator, and as such it has a specific precedence level in the hierarchy of operators. Fair point. IIRC Algol68 allowed custom precedence levels. Found this:

Re: Can you fix this code to avoid using pointers?

On Saturday, 11 March 2017 at 19:15:59 UTC, H. S. Teoh wrote: What about just: foreach (const ref p; [in1, in2, in3, in4]) I would think there will be already one copy from the local parameter variables to the in situ array. Then from that one into the for each element it's ref'd

[Issue 13619] std.container.array capacity not updated when length increases

https://issues.dlang.org/show_bug.cgi?id=13619 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 13619] std.container.array capacity not updated when length increases

https://issues.dlang.org/show_bug.cgi?id=13619 --- Comment #5 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/8ba7ce59ba4bbeb1e7f45fb34ecff2a02930aad9 Fix issue 13619 - array capacity not updated when

Re: CTFE Status 2

On Sat, Mar 11, 2017 at 02:39:54PM +, Stefan Koch via Digitalmars-d wrote: [...] > Contrary to the old interpreter no copies are made. > newCTFE slices reference memory just as runtime slices do. [...] Awesome! This alone ought to greatly expand the scope of what's feasible in CTFE. Now I

Re: Zcoin implementation bug enabled attacker to create 548, 000 Zcoins

On Sat, Mar 11, 2017 at 01:46:31PM +0100, Timon Gehr via Digitalmars-d wrote: > On 10.03.2017 23:41, H. S. Teoh via Digitalmars-d wrote: > > > > Basically, operator syntax is just too specific to the arithmetical > > meanings of the operators that overloading them to mean something > > else seems

Re: Zcoin implementation bug enabled attacker to create 548, 000 Zcoins

On Sat, Mar 11, 2017 at 03:03:30PM +, Nick Treleaven via Digitalmars-d wrote: > On Friday, 10 March 2017 at 19:02:06 UTC, H. S. Teoh wrote: > > A long-standing item on my todo list is to implement compile-time > > writefln format strings using this technique. > > Yes, the actual checking

Re: Can you fix this code to avoid using pointers?

On Sat, Mar 11, 2017 at 12:45:10PM +, XavierAP via Digitalmars-d-learn wrote: > On Saturday, 11 March 2017 at 12:35:42 UTC, XavierAP wrote: > > I do not really think it's a bad solution, to check several scalar > > arguments that must obey the same condition; just wondering if you > > have

Re: Any news on DIP88?

On Saturday, March 11, 2017 15:25:14 bauss via Digitalmars-d wrote: > Are there any news on DIP88? Will it be implemented?, when?, is > there an implementation currently in development or? > > https://wiki.dlang.org/DIP88 It has never been approved. and as mentioned on the main DIPs page on the

Re: Problem building DMD

On Saturday, 11 March 2017 at 17:54:55 UTC, ag0aep6g wrote: On 03/11/2017 06:41 PM, Eric wrote: I'm trying to build the master branch of DMD on redhat 7. I get the following errors: ddmd/root/newdelete.c:26:8: error: expected identifier or ‘(’ before string constant extern "C" ^

Re: Problem building DMD

On Saturday, 11 March 2017 at 17:54:55 UTC, ag0aep6g wrote: Looks like a C compiler is used instead of a C++ compiler. Despite the extension, dmd's *.c files are C++ code. Yes, that's what I thought - redhat has gcc, but not g++. There must be a needed compile option...

Re: DMD win32.mak error

On Saturday, 11 March 2017 at 02:25:15 UTC, Paul D Anderson wrote: On Saturday, 11 March 2017 at 00:34:03 UTC, Paul D Anderson wrote: On Friday, 10 March 2017 at 22:04:23 UTC, Paul D Anderson wrote: While building DMD -- "make -fwin32.mak release" -- I received the following error message:

Re: Problem building DMD

On 03/11/2017 06:41 PM, Eric wrote: I'm trying to build the master branch of DMD on redhat 7. I get the following errors: ddmd/root/newdelete.c:26:8: error: expected identifier or ‘(’ before string constant extern "C" ^ ddmd/root/newdelete.c:31:17: error: expected ‘=’, ‘,’, ‘;’, ‘asm’

Re: CTFE Status 2

On Saturday, 11 March 2017 at 17:38:04 UTC, Nordlöw wrote: On Saturday, 11 March 2017 at 14:39:54 UTC, Stefan Koch wrote: Basic Slicing support is in; The following code will now compile with the newCTFE_slicing branch: I guess this should greatly benefit compile-time parsing, right? As

Problem building DMD

I'm trying to build the master branch of DMD on redhat 7. I get the following errors: ddmd/root/newdelete.c:26:8: error: expected identifier or ‘(’ before string constant extern "C" ^ ddmd/root/newdelete.c:31:17: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘new’

Re: CTFE Status 2

On Saturday, 11 March 2017 at 14:39:54 UTC, Stefan Koch wrote: Basic Slicing support is in; The following code will now compile with the newCTFE_slicing branch: I guess this should greatly benefit compile-time parsing, right?

Re: Rename 'D' to 'D++'

D•• :D

Any news on DIP88?

Are there any news on DIP88? Will it be implemented?, when?, is there an implementation currently in development or? https://wiki.dlang.org/DIP88

Re: Zcoin implementation bug enabled attacker to create 548, 000 Zcoins

On Friday, 10 March 2017 at 19:02:06 UTC, H. S. Teoh wrote: A long-standing item on my todo list is to implement compile-time writefln format strings using this technique. Yes, the actual checking seems straightforward - here I implemented CT format as an overload: import std.format :

Re: Can you fix this code to avoid using pointers?

On Saturday, 11 March 2017 at 14:49:42 UTC, XavierAP wrote: But also I don't want to modify the function signature, certainly in this way. It is already copied by the time you get in to the function though because of the signature (unless they are constructed in-place at the call site).

Re: Can you fix this code to avoid using pointers?

On Saturday, 11 March 2017 at 13:44:30 UTC, Satoshi wrote: void calc(in double[] array...) { foreach (x; array) { } } To do what I want it should be foreach(ref x; array) -- or const ref. But also I don't want to modify the function signature, certainly in this way. In another situation

Re: CTFE Status 2

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] Basic Slicing support is in; The following code will now compile with the newCTFE_slicing branch: static immutable uint[] OneToTen = [1,2,3,4,5,6,7,8,9,10]; const(uint[]) SliceOf1to10(uint lwr, uint upr) { return

Re: Can you fix this code to avoid using pointers?

On Saturday, 11 March 2017 at 12:35:42 UTC, XavierAP wrote: I do not really think it's a bad solution, to check several scalar arguments that must obey the same condition; just wondering if you have better ideas. Try to avoid modifying the function's signature and defining custom types, unless

Re: Zcoin implementation bug enabled attacker to create 548, 000 Zcoins

On 11.03.2017 13:46, Timon Gehr wrote: On 10.03.2017 23:41, H. S. Teoh via Digitalmars-d wrote: Basically, operator syntax is just too specific to the arithmetical meanings of the operators that overloading them to mean something else seems like just asking for trouble. OTOH, restricting how

Re: Rename 'D' to 'D++'

On Saturday, 11 March 2017 at 10:32:02 UTC, meppl wrote: On Friday, 10 March 2017 at 11:25:11 UTC, Traktor TOni wrote: I think the name is just misleading, the D developers should at least be honest with themselves. look here: https://en.wikipedia.org/wiki/C_(programming_language)#History

Re: Zcoin implementation bug enabled attacker to create 548, 000 Zcoins

On 10.03.2017 23:41, H. S. Teoh via Digitalmars-d wrote: Basically, operator syntax is just too specific to the arithmetical meanings of the operators that overloading them to mean something else seems like just asking for trouble. OTOH, restricting how operators can be overloaded means they

Re: Can you fix this code to avoid using pointers?

On Saturday, 11 March 2017 at 12:35:42 UTC, XavierAP wrote: I do not really think it's a bad solution, to check several scalar arguments that must obey the same condition; just wondering if you have better ideas. Try to avoid modifying the function's signature and defining custom types, unless

Re: Can you fix this code to avoid using pointers?

Oh... please forget it What a terrible example :p I forgot why I was using pointers at all... I must have had a reason to write this in the past ???

Can you fix this code to avoid using pointers?

I do not really think it's a bad solution, to check several scalar arguments that must obey the same condition; just wondering if you have better ideas. Try to avoid modifying the function's signature and defining custom types, unless you have a really terrific idea. void calc(double in1,

Re: Let's kill the ddoc _name feature.

On Monday, 6 March 2017 at 03:58:11 UTC, Adam D. Ruppe wrote: I propose that we kill it in a three step process: +1 yes please

Recently added ndslice API

11 ndslice and ndField constructors was added since ndslice API had been reworked. All of them do not perform any memory allocations. mir.ndslice.slice: - slicedNdField - Creates full featured n-dimensional ndslice over an ndField. ndField is a simple user-defined multidimensional view that

Re: Rename 'D' to 'D++'

On Friday, 10 March 2017 at 11:25:11 UTC, Traktor TOni wrote: I think the name is just misleading, the D developers should at least be honest with themselves. look here: https://en.wikipedia.org/wiki/C_(programming_language)#History so, once upon a day there was _A_ssembler. then a

Re: Better ddoc defaults?

On Friday, 10 March 2017 at 07:58:36 UTC, Petar Kirov [ZombineDev] wrote: On Thursday, 9 March 2017 at 21:08:17 UTC, Yuxuan Shui wrote: I'm using ddoc for the first time. I was naively expecting something resembles dlang.org, and the results is a bit disappointing. So I looked at dlang.org and