Re: Efficient idiom for fastest code

On Wednesday, 23 May 2018 at 03:12:52 UTC, IntegratedDimensions wrote: I knew someone was going to say that and I forgot to say DON'T! Saying to profile when I clearly said these ARE cases where they are slow is just moronic. Please don't use default answers to arguments. This was a general

Re: Tiny D suitable for embedded JIT

On Wednesday, 23 May 2018 at 18:49:05 UTC, Dibyendu Majumdar wrote: Now that D has a better C option I was wondering if it is possible to create a small subset of D that can be used as embedded JIT library. I would like to trim the language to a small subset of D/C - only primitive types and

Re: Looks like Digital Mars C++ is on the front page of HN at the moment!

Back on the front page with an apparent followup: Consider using Digital Mars C compiler (virtualbox.org) 33 points by yuhong 3 hours ago | flag | hide | past | web | favorite | 14 comments https://news.ycombinator.com/news

Re: Ideas for students' summer projects

On Wednesday, 23 May 2018 at 14:25:44 UTC, Steven Schveighoffer wrote: How do I know I'm in a function? I don't think you're ever actually "in a function". The code is just data passing through the compiler. I think what your may be asking is "How do I know I'm working on a function?".

Re: Looks like Digital Mars C++ is on the front page of HN at the moment!

On Thursday, 24 May 2018 at 01:52:24 UTC, Nick Sabalausky (Abscissa) wrote: "C++, now powered by D" :) :) +1

[Issue 18899] destroy is inefficient for small structs

https://issues.dlang.org/show_bug.cgi?id=18899 --- Comment #4 from Manu --- Yes, that's what I'm saying :) ... you're not happy with memcpy, do want element-copy? --

Re: Looks like Digital Mars C++ is on the front page of HN at the moment!

On 05/23/2018 09:01 PM, Walter Bright wrote: It's been a great thread. Everyone was very nice. Now that it's gone from the front page, here's the direct link: https://news.ycombinator.com/item?id=17129678 Whoa, I didn't even realize D was now used in some of the DMC++ source. That's a very

Re: D's Destructors are What Scott Meyers Warned Us About

On Wednesday, 23 May 2018 at 13:12:57 UTC, Steven Schveighoffer wrote: Hm.. that should be fixed. I don't see why we can't just do = T.init, we should at least be optimizing to this for small enough structs. The problem I ran into with this is that if you use T.init directly you end up

Re: T opImplCast(T)() so we can add @disable to it?

On Thursday, May 24, 2018 00:30:03 Sjoerd Nijboer via Digitalmars-d wrote: > While tinkering with some code I eventually found that the > following didn't do as I expected > > import std.conv; > import std.stdio; > > void main() > { > Foo foo = 5; > writeln(foo); > } > > struct Foo{ >

[Issue 18899] destroy is inefficient for small structs

https://issues.dlang.org/show_bug.cgi?id=18899 --- Comment #3 from Mike Franklin --- Yes, `dest[] = src[]` gets lowered to _d_arraycopy, which ultimately calls memcpy View ASM here: https://run.dlang.io/is/izCLp0 _d_arraycopy implementation here:

[Issue 18900] GC doesn't collect large arrays on 32-bit Windows

https://issues.dlang.org/show_bug.cgi?id=18900 | changed: What|Removed |Added CC||dhase...@gmail.com --- Comment #1

Re: T opImplCast(T)() so we can add @disable to it?

I would REALLY love a way to implement an implicit cast that wasn't `alias this` based... for reasons that are NOT to @disable it :P Well, explicit casts can be annoying at times when type conversion wouldn't mean loss of precision, but disabling an implicit cast on any type that has such

Re: T opImplCast(T)() so we can add @disable to it?

On Thursday, 24 May 2018 at 00:53:00 UTC, Manu wrote: I would REALLY love a way to implement an implicit cast that wasn't `alias this` based... for reasons that are NOT to @disable it :P Well, explicit casts can be annoying at times when type conversion wouldn't mean loss of precision, but

[Issue 18899] destroy is inefficient for small structs

https://issues.dlang.org/show_bug.cgi?id=18899 Mike Franklin changed: What|Removed |Added CC||slavo5...@yahoo.com

Contributing to DMD

On Wednesday, 23 May 2018 at 14:25:44 UTC, Steven Schveighoffer wrote: Common questions I have when looking at dmd code: Where is this in the source? How do I know I'm in a function? How do I know I'm in a template? What module am I in? How do I know what has been run? What is the proper way

Re: Looks like Digital Mars C++ is on the front page of HN at the moment!

On 5/22/2018 9:38 PM, Dmitry Olshansky wrote: On Wednesday, 23 May 2018 at 01:18:43 UTC, Walter Bright wrote: Yay! Any thoughts about opening runtime library? Yes, I just didn't get around to it yet. I didn't think anyone was interested :-) https://news.ycombinator.com/news And it’s

Re: T opImplCast(T)() so we can add @disable to it?

On 23 May 2018 at 17:30, Sjoerd Nijboer via Digitalmars-d wrote: > While tinkering with some code I eventually found that the following didn't > do as I expected > > import std.conv; > import std.stdio; > > void main() > { > Foo foo = 5; > writeln(foo); > } >

T opImplCast(T)() so we can add @disable to it?

While tinkering with some code I eventually found that the following didn't do as I expected import std.conv; import std.stdio; void main() { Foo foo = 5; writeln(foo); } struct Foo{ int i; alias i this; @disable T opCast(T)(); this(int j) {i =j;} } If the cast in

Re: run.dlang.io/ add scrolling window and possibly src line mapping

On Wednesday, 23 May 2018 at 22:33:05 UTC, IntegratedDimensions wrote: Large code is produced for assmly and others and it would be nice if it had it's own window to scroll rather than scrolling the entire window. Also it would be nice if clicking on a line in the src scrolled to the proper

Re: D's Destructors are What Scott Meyers Warned Us About

On 23 May 2018 at 16:34, Rubn via Digitalmars-d wrote: > On Wednesday, 23 May 2018 at 22:47:21 UTC, sarn wrote: >> >> On Wednesday, 23 May 2018 at 02:13:13 UTC, rikki cattermole wrote: >>> >>> I would consider the current state with classes a bug. >>> So ticket

Re: D's Destructors are What Scott Meyers Warned Us About

On Wednesday, 23 May 2018 at 22:47:21 UTC, sarn wrote: On Wednesday, 23 May 2018 at 02:13:13 UTC, rikki cattermole wrote: I would consider the current state with classes a bug. So ticket please, it should not require a DIP to change (although Walter may disagree). Unfortunately, the way

[Issue 18899] destroy is inefficient for small structs

https://issues.dlang.org/show_bug.cgi?id=18899 Manu changed: What|Removed |Added CC||turkey...@gmail.com --- Comment

Re: D's Destructors are What Scott Meyers Warned Us About

On Wednesday, 23 May 2018 at 15:43:31 UTC, Steven Schveighoffer wrote: Coincidentally, this JUST changed due to a different reason: https://github.com/dlang/druntime/pull/2178 Please file an enhancement request. I still think it could be better, so I added a further issue:

Re: D's Destructors are What Scott Meyers Warned Us About

On 23 May 2018 at 15:47, sarn via Digitalmars-d wrote: > On Wednesday, 23 May 2018 at 02:13:13 UTC, rikki cattermole wrote: >> >> I would consider the current state with classes a bug. >> So ticket please, it should not require a DIP to change (although Walter >> may

Re: D's Destructors are What Scott Meyers Warned Us About

On Wednesday, 23 May 2018 at 13:12:57 UTC, Steven Schveighoffer wrote: On 5/22/18 9:59 PM, sarn wrote: * Some code uses __dtor as a way to manually run cleanup code on an object that will be used again.  Putting this cleanup code into a normal method will cause fewer headaches. Using __dtor

Re: D's Destructors are What Scott Meyers Warned Us About

On Wednesday, 23 May 2018 at 02:13:13 UTC, rikki cattermole wrote: I would consider the current state with classes a bug. So ticket please, it should not require a DIP to change (although Walter may disagree). Unfortunately, the way __dtor and __xdtor work for classes can't be changed

Re: D's Destructors are What Scott Meyers Warned Us About

On Wednesday, 23 May 2018 at 19:28:28 UTC, Paul Backus wrote: On Wednesday, 23 May 2018 at 01:59:50 UTC, sarn wrote: The one other usage of these low-level destructor facilities is checking if a type is a plain old data struct. This is an important special case for some code, but everyone

run.dlang.io/ add scrolling window and possibly src line mapping

Large code is produced for assmly and others and it would be nice if it had it's own window to scroll rather than scrolling the entire window. Also it would be nice if clicking on a line in the src scrolled to the proper location in the output It would also be nice if the imports were

Re: Why is 64-bit dmd not built as part of the Windows release?

On 5/23/2018 3:20 PM, Vladimir Panteleev wrote: On Wednesday, 23 May 2018 at 20:17:04 UTC, Dlang User wrote: I tried adding bootstrap option for 64 bit: digger -c build.components.dmd.dmdModel=64 -c build.components.dmd.bootstrap.ver=v2.075.0 build --model=64 v2.080.0 Which didn't work

Re: CI buildbots

On 5/23/18 4:51 PM, Manu wrote: I'm not suggesting adding new machines... I'm suggesting removing the ones that take ~50 minutes. I think this thought has merit. Or at least delegate them to only test older PRs. I guess the flow I observed on the weekend, where it took me 3 days to get my

[Issue 18642] VisualD - Demangle link errors?

https://issues.dlang.org/show_bug.cgi?id=18642 --- Comment #10 from Manu --- Haha, out by one! :) Just tried the new one. It works. It still emits the message: 1> pipelink called with: "C:\Program Files (x86)\VisualD\msbuild\pipelink.exe" /ERRORREPORT:PROMPT

[Issue 18900] New: GC doesn't collect large arrays on 32-bit Windows

https://issues.dlang.org/show_bug.cgi?id=18900 Issue ID: 18900 Summary: GC doesn't collect large arrays on 32-bit Windows Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: normal

[Issue 18642] VisualD - Demangle link errors?

https://issues.dlang.org/show_bug.cgi?id=18642 --- Comment #9 from Rainer Schuetze --- That was dmd 2.071 from 2016, with rather fresh support for -m32mscoff. I don't think it's worth investigating what the issue was back then. dmd 2.072 produces a working exe. --

Re: CI buildbots

On 23 May 2018 at 07:09, Seb via Digitalmars-d wrote: > On Monday, 21 May 2018 at 04:46:15 UTC, Manu wrote: >> >> This CI situation with the DMD/druntime repos is not okay. >> It takes ages... **hours** sometimes, for CI to complete. >> It's all this 'auto-tester'

[Issue 18642] VisualD - Demangle link errors?

https://issues.dlang.org/show_bug.cgi?id=18642 --- Comment #8 from Manu --- How was it that DMD produced a broken executable? Is that a thing? That sounds like a critical bug if it's producing subtly broken code. --

Re: Tiny D suitable for embedded JIT

On Wednesday, 23 May 2018 at 20:08:53 UTC, Jonathan Marler wrote: I've recently been looking into how QEMU works and it uses something called TCG (Tiny Code Generator). QEMU works by taking code from another platform/cpu and translates it to TCG, which then gets "jitted" to the instructions

Re: Why is 64-bit dmd not built as part of the Windows release?

On Wednesday, 23 May 2018 at 20:17:04 UTC, Dlang User wrote: I tried adding bootstrap option for 64 bit: digger -c build.components.dmd.dmdModel=64 -c build.components.dmd.bootstrap.ver=v2.075.0 build --model=64 v2.080.0 Which didn't work (totally different error): Looks like more DMD

Re: Why is 64-bit dmd not built as part of the Windows release?

On 5/23/2018 12:42 PM, Vladimir Panteleev wrote: On Wednesday, 23 May 2018 at 17:35:28 UTC, Dlang User wrote: I too am looking for 64-bit on Windows 10.  Not just DMD but ideally everything. When I try the command exactly as above, or a slightly modified version (on a second run show after

Re: Efficient idiom for fastest code

On Wednesday, 23 May 2018 at 10:55:02 UTC, Malte wrote: On Wednesday, 23 May 2018 at 02:24:08 UTC, IntegratedDimensions wrote: [...] I would just do [...] [...] Thanks, I didn't think about using a for loop like that. While it is not the most general it does solve the specific case for

Re: Tiny D suitable for embedded JIT

On Wednesday, 23 May 2018 at 18:49:05 UTC, Dibyendu Majumdar wrote: Now that D has a better C option I was wondering if it is possible to create a small subset of D that can be used as embedded JIT library. I would like to trim the language to a small subset of D/C - only primitive types and

Re: How to convert ubyte[] to uint?

On 5/23/18 3:53 PM, Dr.No wrote: On Wednesday, 23 May 2018 at 19:49:27 UTC, Jonathan M Davis wrote: On Wednesday, May 23, 2018 19:36:07 Dr.No via Digitalmars-d-learn wrote:   [...] As the template constraint in the error message says, read requires an input range. Static arrays are not

Re: How to convert ubyte[] to uint?

On Wednesday, 23 May 2018 at 19:49:27 UTC, Jonathan M Davis wrote: On Wednesday, May 23, 2018 19:36:07 Dr.No via Digitalmars-d-learn wrote: [...] As the template constraint in the error message says, read requires an input range. Static arrays are not input ranges. You need to give it

Re: How to convert ubyte[] to uint?

On Wednesday, May 23, 2018 19:36:07 Dr.No via Digitalmars-d-learn wrote: > read fails with both uint and ulong on 64bit platform: > > Error: template std.bitmanip.read cannot deduce function from > argument types !(ulong)(ubyte[8]), candidates are: >

How to convert ubyte[] to uint?

read fails with both uint and ulong on 64bit platform: Error: template std.bitmanip.read cannot deduce function from argument types !(ulong)(ubyte[8]), candidates are: C:\ldc2-1.9.0-windows-x64\bin\..\import\std\bitmanip.d(3213,3): std.bitmanip.read(T, Endian endianness =

Re: D's Destructors are What Scott Meyers Warned Us About

On Wednesday, 23 May 2018 at 01:59:50 UTC, sarn wrote: The one other usage of these low-level destructor facilities is checking if a type is a plain old data struct. This is an important special case for some code, but everyone seems to do the check a different way. Maybe a special isPod

[Issue 18642] VisualD - Demangle link errors?

https://issues.dlang.org/show_bug.cgi?id=18642 --- Comment #7 from Rainer Schuetze --- appveyor built with dmd 2.071 which was the last version to produce a broken executable. Now updated to 2.080. Please try the new version. --

Re: Support alias this in module scope?

On Wed, May 23, 2018 at 10:28:33AM -0700, Manu via Digitalmars-d wrote: > On 23 May 2018 at 10:12, 12345swordy via Digitalmars-d > wrote: [...] > > You can make an argument against security using that logic. > > Regardless there are many things that a web forum can do

Re: D's Destructors are What Scott Meyers Warned Us About

On 23 May 2018 at 10:59, Steven Schveighoffer via Digitalmars-d wrote: > On 5/23/18 1:41 PM, Manu wrote: >> >> On 23 May 2018 at 05:38, Steven Schveighoffer via Digitalmars-d >> wrote: >>> >>> On 5/22/18 10:15 PM, Manu wrote:

Re: dlang feed, thunderbird

On 05/23/2018 10:25 AM, number wrote: > I don't get any posts for this forum in Thunderbird since today. It > worked previously. Stop playing with Thunderbird's settings! :p > the URL : https://forum.dlang.org/feed/posts > works in Firefox, but creating a new account and subscription in >

Tiny D suitable for embedded JIT

Now that D has a better C option I was wondering if it is possible to create a small subset of D that can be used as embedded JIT library. I would like to trim the language to a small subset of D/C - only primitive types and pointers - and remove everything else. The idea is to have a high

Re: D's Destructors are What Scott Meyers Warned Us About

On Wednesday, 23 May 2018 at 18:11:45 UTC, Jonathan M Davis wrote: On Wednesday, May 23, 2018 18:04:28 12345swordy via Digitalmars-d wrote: On Wednesday, 23 May 2018 at 17:47:12 UTC, Jonathan M Davis wrote: > On Wednesday, May 23, 2018 17:29:11 12345swordy via > > Digitalmars-d wrote: >> [...]

Re: Locking data

On Wednesday, 23 May 2018 at 13:36:20 UTC, rikki cattermole wrote: On 24/05/2018 1:29 AM, Malte wrote: On Wednesday, 23 May 2018 at 13:24:35 UTC, rikki cattermole wrote: On 24/05/2018 1:20 AM, Malte wrote: On Tuesday, 22 May 2018 at 21:45:07 UTC, IntegratedDimensions wrote: an idea to lock

Re: Help with DMD internals

On 23 May 2018 at 06:36, Steven Schveighoffer via Digitalmars-d wrote: > On 5/22/18 9:48 PM, Manu wrote: >> >> On 22 May 2018 at 06:44, Steven Schveighoffer via Digitalmars-d >> wrote: >>> >>> On 5/22/18 1:01 AM, Manu wrote: Ah!

Re: Help with DMD internals

On 20 May 2018 at 13:25, Walter Bright via Digitalmars-d wrote: > On 5/20/2018 12:28 PM, Manu wrote: >> >> I've started digging at some surfac-ey extern(C++) issues. > > > I've improved the definition of how construction works, such as when the > .init happens, in the

Re: D's Destructors are What Scott Meyers Warned Us About

On Wednesday, May 23, 2018 18:04:28 12345swordy via Digitalmars-d wrote: > On Wednesday, 23 May 2018 at 17:47:12 UTC, Jonathan M Davis wrote: > > On Wednesday, May 23, 2018 17:29:11 12345swordy via > > > > Digitalmars-d wrote: > >> On Wednesday, 23 May 2018 at 15:43:31 UTC, Steven Schveighoffer >

Re: D's Destructors are What Scott Meyers Warned Us About

On 5/23/18 1:41 PM, Manu wrote: Is everything in object.d globally available? You don't have to import `destroy()` right? Oh, didn't answer this, yes object.d is always imported. -Steve

Re: D's Destructors are What Scott Meyers Warned Us About

On Wednesday, 23 May 2018 at 17:47:12 UTC, Jonathan M Davis wrote: On Wednesday, May 23, 2018 17:29:11 12345swordy via Digitalmars-d wrote: On Wednesday, 23 May 2018 at 15:43:31 UTC, Steven Schveighoffer wrote: > On 5/23/18 9:12 AM, Steven Schveighoffer wrote: >> [...] > > Coincidentally, this

Re: D's Destructors are What Scott Meyers Warned Us About

On 5/23/18 1:41 PM, Manu wrote: On 23 May 2018 at 05:38, Steven Schveighoffer via Digitalmars-d wrote: On 5/22/18 10:15 PM, Manu wrote: If you're in the mood to prepare a DIP, I think you should prepare this dip: Support the syntax: classInstance.~this();

Re: extern(C++) template problem

On 23 May 2018 at 03:14, Nicholas Wilson via Digitalmars-d wrote: > On Wednesday, 23 May 2018 at 07:09:40 UTC, Manu wrote: >> >> C++: >> --- >> class C {}; >> >> template >> void create(T** x); >>

Re: D's Destructors are What Scott Meyers Warned Us About

On Wednesday, May 23, 2018 17:29:11 12345swordy via Digitalmars-d wrote: > On Wednesday, 23 May 2018 at 15:43:31 UTC, Steven Schveighoffer > > wrote: > > On 5/23/18 9:12 AM, Steven Schveighoffer wrote: > >> On 5/22/18 9:59 PM, sarn wrote: > >>> (Unfortunately destroy() currently isn't

Re: Why is 64-bit dmd not built as part of the Windows release?

On Wednesday, 23 May 2018 at 17:35:28 UTC, Dlang User wrote: I too am looking for 64-bit on Windows 10. Not just DMD but ideally everything. When I try the command exactly as above, or a slightly modified version (on a second run show after this run), I hit an error on my machine:

Re: D's Destructors are What Scott Meyers Warned Us About

On 23 May 2018 at 05:38, Steven Schveighoffer via Digitalmars-d wrote: > On 5/22/18 10:15 PM, Manu wrote: >> >> If you're in the mood to prepare a DIP, I think you should prepare this >> dip: >> >> Support the syntax: >>classInstance.~this(); > > > Isn't this just

Re: Why is 64-bit dmd not built as part of the Windows release?

On 5/22/2018 10:03 AM, Atila Neves wrote: On Tuesday, 22 May 2018 at 13:30:02 UTC, Vladimir Panteleev wrote: On Tuesday, 22 May 2018 at 13:11:00 UTC, Atila Neves wrote: On Thursday, 17 May 2018 at 03:28:33 UTC, Vladimir Panteleev wrote: digger build --model=64 If you don't have Digger yet,

Re: Online impersonation

On 5/23/18 1:19 PM, Bastiaan Veelo wrote: On Wednesday, 23 May 2018 at 12:32:50 UTC, Steven Schveighoffer wrote: I'm just going to warn everyone here that one person is posting as KingJoffrey, VectorThis, Grady Booch, FuckYou, and in this thread he is impersonating 12345swordy, and in others

dlang feed, thunderbird

I don't get any posts for this forum in Thunderbird since today. It worked previously. the URL : https://forum.dlang.org/feed/posts works in Firefox, but creating a new account and subscription in Thunderbird he says 'The Feed URL is not a valid feed' and the validation link gets me here:

Re: D's Destructors are What Scott Meyers Warned Us About

On Wednesday, 23 May 2018 at 15:43:31 UTC, Steven Schveighoffer wrote: On 5/23/18 9:12 AM, Steven Schveighoffer wrote: On 5/22/18 9:59 PM, sarn wrote: (Unfortunately destroy() currently isn't zero-overhead for plain old data structs because it's based on RTTI, but at least it works.) Hm..

Re: Support alias this in module scope?

On 23 May 2018 at 10:12, 12345swordy via Digitalmars-d wrote: > On Wednesday, 23 May 2018 at 16:28:22 UTC, H. S. Teoh wrote: >> >> On Wed, May 23, 2018 at 02:34:07PM +, 12345swordy via Digitalmars-d >> wrote: [...] >>> >>> Can you please support actual web forms

Online impersonation

On Wednesday, 23 May 2018 at 12:32:50 UTC, Steven Schveighoffer wrote: I'm just going to warn everyone here that one person is posting as KingJoffrey, VectorThis, Grady Booch, FuckYou, and in this thread he is impersonating 12345swordy, and in others he has impersonated WalterBright as well.

Re: Support alias this in module scope?

On Wednesday, 23 May 2018 at 16:28:22 UTC, H. S. Teoh wrote: On Wed, May 23, 2018 at 02:34:07PM +, 12345swordy via Digitalmars-d wrote: [...] Can you please support actual web forms to prevent this impersonation? Unfortunately, "actual" web forums are just as prone to impersonation to

Re: Support alias this in module scope?

On Wed, May 23, 2018 at 02:34:07PM +, 12345swordy via Digitalmars-d wrote: [...] > Can you please support actual web forms to prevent this impersonation? Unfortunately, "actual" web forums are just as prone to impersonation to someone determined enough. T -- Error: Keyboard not attached.

Re: Is HibernateD dead?

On Monday, 7 May 2018 at 18:10:14 UTC, Matthias Klumpp wrote: On Saturday, 5 May 2018 at 09:32:32 UTC, Brian wrote: On Thursday, 3 May 2018 at 10:27:47 UTC, Pasqui23 wrote: Last commit on https://github.com/buggins/hibernated was almost a year ago So what is the status of HibernateD?Should I

[Issue 18886] Explicitly invoking super.__ctor in a constructor does not count as calling a super constructor

https://issues.dlang.org/show_bug.cgi?id=18886 RazvanN changed: What|Removed |Added CC|

Re: Support alias this in module scope?

On Wednesday, 23 May 2018 at 03:44:36 UTC, Manu wrote: If we can use `alias this` to mirror an entire C++ namespace into the location we want (ie, the scope immediately outside the C++ namespace!!), then one sanitary line would make the problem quite more tolerable: extern(C++, FuckOff) {

Re: D's Destructors are What Scott Meyers Warned Us About

On 5/23/18 9:12 AM, Steven Schveighoffer wrote: On 5/22/18 9:59 PM, sarn wrote: (Unfortunately destroy() currently isn't zero-overhead for plain old data structs because it's based on RTTI, but at least it works.) Hm.. that should be fixed. I don't see why we can't just do = T.init, we

Re: Semantic change from 2.078.3 to 2.079.0

On 5/23/18 11:31 AM, Márcio Martins wrote: On Wednesday, 23 May 2018 at 09:43:28 UTC, Jonathan M Davis wrote: [...] Got it! Thanks! Note, you could create an isSomeStringOrEnum template that does the old behavior, and just do a sed 's/isSomeString!/isSomeStringOrEnum!/g' -Steve

[Issue 18899] New: destroy is inefficient for small structs

https://issues.dlang.org/show_bug.cgi?id=18899 Issue ID: 18899 Summary: destroy is inefficient for small structs Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement

Re: Semantic change from 2.078.3 to 2.079.0

On Wednesday, 23 May 2018 at 09:43:28 UTC, Jonathan M Davis wrote: [...] Got it! Thanks!

[Issue 18828] [-betterC] helpless error in object.d

https://issues.dlang.org/show_bug.cgi?id=18828 --- Comment #10 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/0bb16606a23851680c818a64e6bb69e6a8e6650e Fix Issue 18828 - [-betterC] helpless error in

[Issue 18898] std.algorithm.iteration : each & overloads of opApply don't play well together

https://issues.dlang.org/show_bug.cgi?id=18898 Steven Schveighoffer changed: What|Removed |Added CC|

Re: each & opApply

On Wednesday, 23 May 2018 at 14:24:18 UTC, Alex wrote: Ah... ok. Then, let me file a bug... Bug filed. https://issues.dlang.org/show_bug.cgi?id=18898

[Issue 18898] New: std.algorithm.iteration : each & overloads of opApply don't play well together

https://issues.dlang.org/show_bug.cgi?id=18898 Issue ID: 18898 Summary: std.algorithm.iteration : each & overloads of opApply don't play well together Product: D Version: D2 Hardware: x86 OS: Mac OS X

Re: Ideas for students' summer projects

On Wednesday, 23 May 2018 at 04:30:28 UTC, 12345swordy wrote: On Wednesday, 23 May 2018 at 04:17:19 UTC, Mike Franklin wrote: Try to replace some of the basic software building blocks (memcpy, memcmp, malloc, free, realloc) that are currently leveraged from the platform's C library with

Re: Ideas for students' summer projects

On 24/05/2018 2:25 AM, Steven Schveighoffer wrote: On 5/22/18 10:00 PM, Mike Franklin wrote: On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote: Let the brainstorming begin! An apprentice for Walter. I think Walter needs an apprentice (or 10).  Too much knowledge about D's

Re: Support alias this in module scope?

On Wednesday, 23 May 2018 at 12:32:50 UTC, Steven Schveighoffer wrote: On 5/23/18 1:49 AM, Manu wrote: On 22 May 2018 at 22:06, VectorThis via Digitalmars-d wrote: On Wednesday, 23 May 2018 at 04:38:48 UTC, Manu wrote: Sure he does! It's a fair call. Hey, it

Re: Ideas for students' summer projects

On 5/22/18 10:00 PM, Mike Franklin wrote: On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote: Let the brainstorming begin! An apprentice for Walter. I think Walter needs an apprentice (or 10).  Too much knowledge about D's design decisions, present, and future are locked up in

Re: D's Destructors are What Scott Meyers Warned Us About

On Wednesday, 23 May 2018 at 03:45:39 UTC, Manu wrote: On 22 May 2018 at 19:39, 12345swordy via Digitalmars-d wrote: On Wednesday, 23 May 2018 at 02:15:25 UTC, Manu wrote: It should recurse the ClassInfo calling the dtors there to perform a full virtual

Re: each & opApply

On Wednesday, 23 May 2018 at 14:19:31 UTC, Steven Schveighoffer wrote: On 5/23/18 9:59 AM, Alex wrote: On Wednesday, 23 May 2018 at 13:49:45 UTC, Steven Schveighoffer wrote: Right, but not foreach(el1, el2; c), which is the equivalent of your each call. Yes. I tried this in the first place

Re: each & opApply

On 5/23/18 9:59 AM, Alex wrote: On Wednesday, 23 May 2018 at 13:49:45 UTC, Steven Schveighoffer wrote: Right, but not foreach(el1, el2; c), which is the equivalent of your each call. Yes. I tried this in the first place and get a compiler error. But it seemed logical to me, that if I

Re: CI buildbots

On Monday, 21 May 2018 at 04:46:15 UTC, Manu wrote: This CI situation with the DMD/druntime repos is not okay. It takes ages... **hours** sometimes, for CI to complete. It's all this 'auto-tester' one, which seems to lock up on the last few tests. This makes DMD is a rather unenjoyable

Re: each & opApply

On Wednesday, 23 May 2018 at 13:49:45 UTC, Steven Schveighoffer wrote: Right, but not foreach(el1, el2; c), which is the equivalent of your each call. Yes. I tried this in the first place and get a compiler error. But it seemed logical to me, that if I define two opApply overloads, which

Re: each & opApply

On 05/23/2018 06:49 AM, Steven Schveighoffer wrote: Apparently, but that's not very good. IMO, it should use the same rules as foreach. In which case, BOTH lines should fail to compile. -Steve I think this is a compiler bug (limitation), which I think has been reported already (or similar

Re: each & opApply

On 5/23/18 9:37 AM, Alex wrote: This is a question is about usage of ´each´ https://dlang.org/phobos/std_algorithm_iteration.html#each with a type where different opApply overloads are defined. Say, I have something like this: ´´´ void main() { import std.stdio : writeln; import

each & opApply

This is a question is about usage of ´each´ https://dlang.org/phobos/std_algorithm_iteration.html#each with a type where different opApply overloads are defined. Say, I have something like this: ´´´ void main() { import std.stdio : writeln; import std.algorithm : each;

Re: Locking data

On 24/05/2018 1:29 AM, Malte wrote: On Wednesday, 23 May 2018 at 13:24:35 UTC, rikki cattermole wrote: On 24/05/2018 1:20 AM, Malte wrote: On Tuesday, 22 May 2018 at 21:45:07 UTC, IntegratedDimensions wrote: an idea to lock data by removing the reference: class A {    Lockable!Data data; }

Re: Help with DMD internals

On 5/22/18 9:48 PM, Manu wrote: On 22 May 2018 at 06:44, Steven Schveighoffer via Digitalmars-d wrote: On 5/22/18 1:01 AM, Manu wrote: Ah! Dangling pointers... that might conservatively retain garbage. That's a good reason. Well, I was thinking more along the

Re: Locking data

On Wednesday, 23 May 2018 at 13:24:35 UTC, rikki cattermole wrote: On 24/05/2018 1:20 AM, Malte wrote: On Tuesday, 22 May 2018 at 21:45:07 UTC, IntegratedDimensions wrote: an idea to lock data by removing the reference: class A {    Lockable!Data data; } [...] This sounds like you are

Re: Ideas for students' summer projects

All of your suggestions are good ideas, Mike, but they're way too big for an 8-10 week student project. We need something smaller, like making key Phobos functions @nogc/@safe/pure/nothrow/etc.

Re: Locking data

On Tuesday, 22 May 2018 at 21:45:07 UTC, IntegratedDimensions wrote: an idea to lock data by removing the reference: class A { Lockable!Data data; } [...] This sounds like you are looking for is an atomic swap. Afaik it doesn't exist in the standard library. You could use asm for the

Re: Locking data

On 24/05/2018 1:20 AM, Malte wrote: On Tuesday, 22 May 2018 at 21:45:07 UTC, IntegratedDimensions wrote: an idea to lock data by removing the reference: class A {    Lockable!Data data; } [...] This sounds like you are looking for is an atomic swap. Afaik it doesn't exist in the standard

Re: Support alias this in module scope?

On Wednesday, 23 May 2018 at 03:44:36 UTC, Manu wrote: Okay, I'm still really angry about the stupid stupid decision to make C++ namespaces into scopes rather than just a detail used for mangling, with absolutely no consultation of the community, in particular the target audience, who are

  1   2   >