Re: Linus' idea of "good taste" code

[Walter Bright via Digitalmars-d]

On 10/29/2016 10:30 PM, Dicebot wrote:

At the same time intended wasm spec (https://github.com/WebAssembly/design) is
much more simple than machine code for something like x86_64. If Walter gets
interested, that may be a feasible path :)


I looked at it for 5 minutes :-) and it looks like typical intermediate code 
that a compiler might generate. It wouldn't be hard to translate the 
intermediate code generated for the dmd back end to wasm. What I didn't see was 
any mention symbolic debug information, linking, or how to connect to system 
services like mutexes, I/O, etc. Time risks would also be wasm is an incomplete, 
moving target.


Looks like a fun project, but I don't see how I could split off time to work on 
it.

Re: Linus' idea of "good taste" code

[Dicebot via Digitalmars-d]

On Saturday, 29 October 2016 at 21:46:37 UTC, Laeeth Isharc wrote:
Any thoughts on how much work is involved to port the runtime?  
And what other changes might be involved? The chap that used 
the C backend for LLVM wrote a little mini runtime but I guess 
didn't have to worry about the version blocks in the compiler 
front end as much.   (don't recall what architecture he 
pretended to be compiling to).


Glibc has obviously already been ported to run in browser by 
emscripten.


I have actually meant something quite different - implementing 
new backend for DMD which emits wasm directly (possibly by 
embedding binaryen). That is more work than simply using LLVM 
stack as-is but would result in unique marketing advantage - 
existing pipeline of C -> Emscripten -> asm.js -> asm2wasm is 
rather annoying. And native wasm backend for LLVM is in 
development for quite a while now with no clear ETA.


At the same time intended wasm spec 
(https://github.com/WebAssembly/design) is much more simple than 
machine code for something like x86_64. If Walter gets 
interested, that may be a feasible path :)

[Issue 14613] DMD: Internal error: backend/cod1.c 1567 on '-O' switch

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14613

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #3 from Walter Bright  ---
https://github.com/dlang/dmd/pull/6156

--

[Issue 16555] Stack corruption when calling multi-parameter outer function from nested function

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16555

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #2 from Walter Bright  ---
https://github.com/dlang/dmd/pull/6171

--

[Issue 16650] New: Wrong mangling for extern(C++) with posix stat_t

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16650

  Issue ID: 16650
   Summary: Wrong mangling for extern(C++) with posix stat_t
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: hexagonalsta...@gmail.com

---
import core.sys.posix.sys.stat;
extern(C++):
void myFunc(stat_t*){}
---
Doesn't match the c++ mangling
---
#include 

void myFunc(struct stat*){}
---
D mangles myFunc as "_Z6myFuncP6stat_t"
C++ mangles myFunc as "_Z6myFuncP4stat"

--

CSV - 2.5 GB/sec (sadly C++)

[Laeeth Isharc via Digitalmars-d-learn]

On Tuesday, 26 January 2016 at 22:36:31 UTC, H. S. Teoh wrote:
So the moral of the story is: avoid large numbers of small 
allocations. If you have to do it, consider consolidating your 
allocations into a series of allocations of large(ish) buffers 
instead, and taking slices of the buffers.


Thanks for sharing this, HS Teoh.  I tried replacing allocations 
with using a Region from std.experimental.allocator (with 
FreeList and Quantizer on top), and then just deallocating 
everything in one go once I am done with the data.  Seems to be a 
little faster, but I haven't had time to measure it.


Just came across this C++ project, which seems to have 
astonishing performance.  7 minutes for reading a terabyte, and 
2.5 to 4.5 GB/sec for reading file cold.  That's pretty 
impressive.  (Obviously they read in parallel, but I haven't yet 
read source to see what the other tricks might be).


It would be nice to be able match that in D, though practically 
speaking it's probably easiest just to wrap it:


http://www.wise.io/tech/paratext

https://github.com/wiseio/paratext

ACM paper: CPU is the new bottleneck

[Laeeth Isharc via Digitalmars-d-learn]

From Jan 2016:

https://queue.acm.org/detail.cfm?id=2874238

For the entire careers of most practicing computer scientists, a 
fundamental observation has consistently held true: CPUs are 
significantly more performant and more expensive than I/O 
devices. The fact that CPUs can process data at extremely high 
rates, while simultaneously servicing multiple I/O devices, has 
had a sweeping impact on the design of both hardware and software 
for systems of all sizes, for pretty much as long as we've been 
building them.


This assumption, however, is in the process of being completely 
invalidated.

===
Even today, a Spark committer says that for Spark CPU is already 
often the bottleneck (for decompression):


https://www.oreilly.com/ideas/investigating-sparks-performance

Re: Battle-plan for CTFE

[Stefan Koch via Digitalmars-d-announce]

On Friday, 28 October 2016 at 16:52:46 UTC, Stefan Koch wrote:

Another update on CTFE.

I have found a few errors in my handling of switch-statments.
An efficient solution for this is still pending,

Futhermore I have begun to work on ctfe handling refernces.
These are a little bit harder to do in bytecode and do 
pessimise performance if overused.


I hope to make another leap at the end of this month.

We should have string Concat-support fairly soon.

Cheers,
stefan


I just made progress on another fundamental feature,
function call support.

It's does not work yet, but it shows promise.

Re: Ever want to compile D on your Android phone? Well, now you can!

[rikki cattermole via Digitalmars-d-announce]

On 30/10/2016 10:47 AM, Mergul wrote:

On Sunday, 24 January 2016 at 15:12:30 UTC, Joakim wrote:

An alpha release of ldc, the llvm-based D compiler, for Android
devices is now available.  It is best used with the excellent Termux
app (https://play.google.com/store/apps/details?id=com.termux=en)
and a bluetooth keyboard. ;) Updated test runners, that run most tests
from the standard library on any Android device, are also available
(results have been reported for everything from a TomTom BRIDGE GPS
navigation device to a Huawei Watch):

https://github.com/joakim-noah/android/releases/tag/polish

You can install a test runner app or run a command-line binary.
 Please report your results in this thread in the ldc forum, which
requires no registration, with the info and format requested there,
particularly for Android 4.1 or earlier:

https://forum.dlang.org/thread/bafrkjfwmoyriyhmq...@forum.dlang.org

If you try out the native compiler, take a look at the README that
comes with it for instructions.

If you have a D/OpenGL app you'd like to port to Android and submit to
the Play Store, let me know if I can help with that process.


I'm trying to build native-activity sample in .d.
I have build cross ldc compiler using your instructions. When I have
build native activity its work properly on BlueStack, but on my phone
(android 4.2.1) this always crash and run again. Your app test runner
work perfect and every test passed.
Application always crash when I'm using android_app.savedState.

if (state.savedState != null) {
// We are starting with a previous saved state; restore from it.
engine.state = *cast(saved_state*)state.savedState; //crash!
}

Sorry for bad english.


Don't compare against null using =, compare using is.

if (state.savedState !is null) {

Re: Binding temporaries to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

[bitwise via Digitalmars-d]

On Friday, 28 October 2016 at 21:05:33 UTC, bitwise wrote:

On Friday, 21 October 2016 at 07:56:40 UTC, Ethan Watson wrote:
On Thursday, 20 October 2016 at 19:49:42 UTC, Andrei 
Alexandrescu wrote:
I think a solid DIP addressing the problem would have a good 
chance to get traction.


I think all the information in this thread and the "Binding 
rvalues to const ref in D" thread that Atilla started is 
enough for me to write up a solid DIP.


I'll start doing that. Hopefully I'll get a draft up that I'll 
pass to Manu for comment/input this weekend before posting it 
properly.


Any news on this?


Hmm. Why did I expect this?

-_-

Re: What is the right level of abstractions for D?

[Danni Coy via Digitalmars-d]

I am going to talk as a person who mostly works with group 3 languages
but will use whatever they need to use to get the job done (tm).

> The reason for the split is that there are different levels of software
> expertise and performance needs, and each of those groups is geared for a
> different level.  Show templates to a scripting user and they probably run
> away screaming.

The bit that sends group 3 people off screaming is static typing, once
you have accepted the need to explicitly type everything then Template
functions are pretty straight forward in D.

> D can probably do well with groups 1 and 2, but the level
> of power and expertise that is needed for those lower levels will scare away
> people from 3.  Those already using it for 1 and 2 may also be comfortable
> with reusing D for scripting, but that's not attracting people from group 3,
> ie those who only want something easy to use and don't want to know the
> difference between a static and dynamic array.

Again this boils down to static typing, once your group 3 programmer
has accepted this then is is a minor issue. At worst case I could see
a grumble then avoiding static arrays.

>
>> I've noticed that, for many of the people who don't "get" D, the problem
>> they're hitting is that they're minds are so twisted around by the
>> "polyglot" culture, that they're looking for "the one" tiny little niche
>> that D is for, not seeing that, and thus missing the whole entire point.
>
>
> Yes, this has definitely hurt D, being stuck between 1 and 2.  People from 2
> probably look at D and think it's too low-level.  People from 1 are always
> looking to squeeze out _more_ performance, so the GC is a way for them to
> just write off D.  You and I think they're making a mistake, but maybe
> they're not wrong for their own uses.
>
> As I said, the recent push for @nogc and C++ compatibility suggests that a
> renewed effort is being made to focus on group 1, particularly when combined
> with the D benchmarks for regex and recently math.  I'm happy in that space
> between 1 and 2, and the recent push to move languages from 2 to AoT
> compilation suggests that is a good place to be.  So maybe group 2 will also
> come to us. :)

Apart from in application scripting, I have replaced python with D at
work. (I was largely using python because my brain and shell scripting
are largely incompatible). The reasons for this was mostly because
with D I can compile and distribute the binary without having to worry
if the right version of python was installed on the target machine.

For this whip up a tool to automate some file processing quickly I
found D as pleasant as anything else I have used.
The only thing missing are bindings for a high quality crossplatform
gui toolkit.

Where I see the future potential of D in regards to the levels 1,2 and
3 is having a team where different programmers are working at
different levels within the same language on the same project. Take a
game engine, typically you have low level engine guys (level 1) some
guys on the engine team who aren't quite as good but don't have to be
(effectively level 2) and the guys who do the level / ai scripting
(level 3). I would quite happily use D as a high level language in a
team where I had a good lower level team designing most of the stuff I
use with my level of expertise in mind as they designed it.

To this end the really critical things for me are that my level 1 guys
can create code that performs in low latency environments without
missing deadlines and can present their APIs in such a way that is
easy/enjoyable for us level 3 guys to use (see the batch processing
thread a little while back).

Re: Ever want to compile D on your Android phone? Well, now you can!

[Mergul via Digitalmars-d-announce]

On Sunday, 24 January 2016 at 15:12:30 UTC, Joakim wrote:
An alpha release of ldc, the llvm-based D compiler, for Android 
devices is now available.  It is best used with the excellent 
Termux app 
(https://play.google.com/store/apps/details?id=com.termux=en) and a bluetooth keyboard. ;) Updated test runners, that run most tests from the standard library on any Android device, are also available (results have been reported for everything from a TomTom BRIDGE GPS navigation device to a Huawei Watch):


https://github.com/joakim-noah/android/releases/tag/polish

You can install a test runner app or run a command-line binary.
 Please report your results in this thread in the ldc forum, 
which requires no registration, with the info and format 
requested there, particularly for Android 4.1 or earlier:


https://forum.dlang.org/thread/bafrkjfwmoyriyhmq...@forum.dlang.org

If you try out the native compiler, take a look at the README 
that comes with it for instructions.


If you have a D/OpenGL app you'd like to port to Android and 
submit to the Play Store, let me know if I can help with that 
process.


I'm trying to build native-activity sample in .d.
I have build cross ldc compiler using your instructions. When I 
have build native activity its work properly on BlueStack, but on 
my phone (android 4.2.1) this always crash and run again. Your 
app test runner work perfect and every test passed.

Application always crash when I'm using android_app.savedState.

if (state.savedState != null) {
// We are starting with a previous saved state; restore from 
it.

engine.state = *cast(saved_state*)state.savedState; //crash!
}

Sorry for bad english.

Re: Linus' idea of "good taste" code

[Laeeth Isharc via Digitalmars-d]

On Thursday, 27 October 2016 at 16:14:03 UTC, Dicebot wrote:

On 10/27/2016 07:12 PM, Laeeth Isharc wrote:

On Thursday, 27 October 2016 at 16:01:26 UTC, Chris wrote:
On Thursday, 27 October 2016 at 15:54:59 UTC, Jonathan M 
Davis wrote:
On Thursday, October 27, 2016 15:42:53 Chris via 
Digitalmars-d wrote:

Not easy to be smart with Javascript ;)


Sure, it is. Avoid it. ;)

- Jonathan M Davis


I wish I could! I wish we had DScript for browsers!


I am hoping that when asm.js is more mature,  then we can use 
the llvm back end to write at least part of front end in D.   
Would need runtime ported of course.


I consider native compiler from D to WebAssembly to be one of 
possible unique breakthrough points for D in coming years.


I asked Kai at dconf about what would be involved in porting to 
wasm,  but I think he misheard me,  as his answer was just 
generically about what was involved in porting to a new platform.


Any thoughts on how much work is involved to port the runtime?  
And what other changes might be involved? The chap that used the 
C backend for LLVM wrote a little mini runtime but I guess didn't 
have to worry about the version blocks in the compiler front end 
as much.   (don't recall what architecture he pretended to be 
compiling to).


Glibc has obviously already been ported to run in browser by 
emscripten.

Re: State of issues.dlang.org

[ketmar via Digitalmars-d]

On Saturday, 29 October 2016 at 17:14:20 UTC, Jacob wrote:
Let me rephrase that then, no one does anything about the 
issues.


you are plainly wrong. this is as right as your "noone does 
anything". it is especially fun considering that "ag0aep6g" often 
provides clarifications and further sample minimization for alot 
of bugs (it is alot for one man). and other people watching bugs 
too via rss or email subscriptions. DFeed also reports new bugs 
to IRC, so some IRC people are watching too.


but if what you really complaining about is "bugfix rate"... this 
is completely different thing, and it has nothing to do with bug 
tracking software.


p.s. and "resolution" feature *is* used. Vladimir is right about 
reading manuals.

[Issue 16641] Infinite loop on InvalidMemoryOperationError in __dmd_personality_v0

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16641

--- Comment #2 from Etienne  ---
(In reply to ag0aep6g from comment #1)
> Do you have code to reproduce this? InvalidMemoryOperationError is usually
> thrown when a destructor tries to allocate GC memory during a collection.
> The current GC can't do that. So problem might be in your code or in vibe.d
> instead of druntime.

Unfortunately the stack trace cycles into itself so I can't pinpoint the
problem, but it always happens here:

https://github.com/etcimon/vibe.0/blob/master/source/vibe/stream/botan.d#L147

The issue here happens very very rarely, it's probably a very complex set of
circumstances, but the fact here is that I didn't voluntarily create a cycle in
the stack trace linked list and the problem is amplified by this function in
druntime lacking proper cycle detection.

--

[Issue 16641] Infinite loop on InvalidMemoryOperationError in __dmd_personality_v0

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16641

--- Comment #1 from ag0ae...@gmail.com ---
Do you have code to reproduce this? InvalidMemoryOperationError is usually
thrown when a destructor tries to allocate GC memory during a collection. The
current GC can't do that. So problem might be in your code or in vibe.d instead
of druntime.

--

Re: State of issues.dlang.org

[ag0aep6g via Digitalmars-d]

On 10/29/2016 07:14 PM, Jacob wrote:

On Tuesday, 25 October 2016 at 13:04:22 UTC, ag0aep6g wrote:

On 10/25/2016 05:17 AM, Jacob wrote:
I think you're mistaken in thinking that no one looks at issues. I
usually at least glance over newly filed ones, and often check if
they're valid.


Let me rephrase that then, no one does anything about the issues. I look
at a lot of issues to, some that can easily be answered and the issue
closed. But that's the problem, everyone is just an observer and no one
does anything.


Of course, I also close them if they're invalid, add tags, minimize test 
cases. And sometimes I can even just fix the issue. You're very welcome 
to do the same. If you see issues that can be answered and closed, 
please do so. This is a problem of manpower.


That said, if you want to help out, fixing compiler bugs would probably 
be more effective than doing janitor's work on Bugzilla issues. It's 
also a lot harder, as far as I can tell.

[Issue 16641] Infinite loop on InvalidMemoryOperationError in __dmd_personality_v0

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16641

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--

Re: State of issues.dlang.org

[Jacob via Digitalmars-d]

On Tuesday, 25 October 2016 at 13:04:22 UTC, ag0aep6g wrote:

On 10/25/2016 05:17 AM, Jacob wrote:
I think you're mistaken in thinking that no one looks at 
issues. I usually at least glance over newly filed ones, and 
often check if they're valid.


Let me rephrase that then, no one does anything about the issues. 
I look at a lot of issues to, some that can easily be answered 
and the issue closed. But that's the problem, everyone is just an 
observer and no one does anything.

Re: DLang Youtube channel

[Karabuta via Digitalmars-d]

On Friday, 28 October 2016 at 16:22:18 UTC, Patric Dexheimer 
wrote:

There isn't a official D youtube channel right?
Would be  be nice to have all the D related videos spread on 
youtube centralized in one place :)


Who handles YouTube for the community?

Re: State of issues.dlang.org

[Jacob via Digitalmars-d]

On Tuesday, 25 October 2016 at 12:48:48 UTC, Vladimir Panteleev 
wrote:
I don't think its state is much worse than that of a typical 
bugtracker for projects of this scale.


What projects are those? For ones of similar size at the very 
least all issues get tagged. There are a bunch of issues that 
have nothing done with them.



Anyways for the site itself, it seems to be lacking features.


It is a standard Bugzilla instance. We do not develop the 
software.


That doesn't make the point any less valid. If something is broke 
you fix it or replace it.


When viewing issues as a list there isn't that much 
information about the issue, other than the summary.


You can create custom views for whatever task you have at hand.


Didn't know that, the setting was buried at the bottom of the 
page past the hundreds of errors.


The "Resolution", only ever seen it as "---", maybe it means 
something for closed issues but I haven't seen any closed 
issues.


If something is unclear, please refer to the Bugzilla manual.


Not unclear so much as the feature is there and is never used.


If it is a bit bigger of an enhancement and needs a DIP to add 
the functionality.


Feature requests that require a DIP do not belong on Buzilla.


Who is to determine that? I see a lot of Buzilla reports that are 
large enhancements that should need a DIP. But they stay as open 
issues flagged enchancement. That's the point. There's no, or at 
least no one does say, this needs a DIP, closes the issue to 
remove it from sight.


TLDR; The issue system in place right now needs to be removed 
and a better system with oversight put in place.


Err, no. Just because you haven't seen a Bugzilla instance 
elsewhere doesn't mean we should replace it. The UI is a bit 
90's, but otherwise it has served us well.


Umm, who said I haven't seen it elsewhere? If a system is 
un-maintainable that doesn't mean it's ok and should just be 
overlooked.

[Issue 16649] New: Header gen skips parens

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16649

  Issue ID: 16649
   Summary: Header gen skips parens
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: blocker
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: temta...@gmail.com

It makes from
 sign = data.isZero() ? false : sign ^ (y < 0);

a
sign = data.isZero() ? false : sign ^ y < 0;

which gives

Error: y < 0 must be parenthesized when next to operator ^

--

Re: Munich D October Meetup

[Stefan via Digitalmars-d-announce]

Seb's slides for everybody who couldn't attend:
https://github.com/d-muc/talks/raw/master/2019_10_26.mir/seb-mir.pdf

Having Ilya avail for questions via hangout was great.

[Issue 16648] New: Header generation skips postblit

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16648

  Issue ID: 16648
   Summary: Header generation skips postblit
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: blocker
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: temta...@gmail.com

It discards this(this) on the struct if it is in templated function.
But keeps other members.

--

[Issue 16647] New: package.di is not recognized

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16647

  Issue ID: 16647
   Summary: package.di is not recognized
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: blocker
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: temta...@gmail.com

Dmd looks just for package.d, and skips package.di with an error

--

[Issue 16646] Header generation on druntime

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16646

--- Comment #1 from Temtaime  ---
Also it generated strange statements.

ref rename(names...)() return
if (names.length == 0 || allSatisfy!(isSomeString, typeof(names)))

to

ref return rename(names...)() if (names.length == 0 ||
allSatisfy!(isSomeString, typeof(names)))

which leads to errors.

--

[Issue 16646] New: Header generation on druntime

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16646

  Issue ID: 16646
   Summary: Header generation on druntime
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: blocker
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: temta...@gmail.com

druntime\core\atomic.di(238): Error: asm statement is assumed to be @system -
mark it with '@trusted' if it is not

But compiling this file is OK.

--

[Issue 16504] [REG 2.072a]`dup` can't use storage class `scope` for its parameter in general

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16504

--- Comment #1 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/ce6aef38adbf7f652db67bc7287a97e45c173b8f
Revert "Merge pull request #1637 from WalterBright/scope-dup"

This reverts commit 35cd63567095bf865e0c7b4bb8bb92945b6244a5, reversing
changes made to aee373fb541dafce2769792b4430be82ef25bd2b.

- fixes Issue 16504 - dup can't use storage class scope for its parameter in
general

https://github.com/dlang/druntime/commit/2f3f7c80d9843f4c2de05fdd2e15af71f185cf62
add unittest example for Issue 16504

- fairly synthetic example, but serves as documentation

--

[Issue 16504] [REG 2.072a]`dup` can't use storage class `scope` for its parameter in general

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16504

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

Re: Mir GLAS is a C library and passes Natlib's test suite! And questions :-)

[Nicholas Wilson via Digitalmars-d]

On Saturday, 29 October 2016 at 10:21:02 UTC, Guillaume Piolat 
wrote:
On Saturday, 29 October 2016 at 01:43:03 UTC, Nicholas Wilson 
wrote:


If you have any experience with either OpenCL or CUDA we'd 
love to have your input.


Have experience with both, more CUDA than OpenCL though. Feel 
free to contact me.


Great! I'll let you know when the compiler stuff is merged, 
probably in mir's public gitter.

Strange bug when doing a custom build of druntime

[Temtaime via Digitalmars-d]

Hi !
I'm trying to figure out what happens.

http://pastebin.com/e6HPvjJ4
There's a full command line.

It builds OK and works too.
But there's some strange bug with bounds check.

The code of _d_arraybounds is just:

.text:000140014210 _d_arraybounds proc near; 
CODE XREF: j__d_arrayboundsj

.text:000140014210 pushrbp
.text:000140014211 mov rbp, rsp
.text:000140014214 pop rbp
.text:000140014215 retn

I don't know why dmd ommits _d_arraybounds body. So if app built 
with that druntime tries to access out of bounds element it just 
crashes instead of throwing oob error.
If i remove -release from command line when building druntime all 
seems to be OK.

But i had seen that in win64.mak there's a release switch.

Where can be a problem?
Thanks for a help.

Re: D garbage collector and real-time systems

[Guillaume Piolat via Digitalmars-d]

On Wednesday, 28 January 2015 at 08:12:25 UTC, Mike wrote:

On Wednesday, 28 January 2015 at 06:58:42 UTC, Tom wrote:


Or is there now the possibility of disabling the GC altogether,
or replacing it with a refcounting 'GC' etc?


You can disable the GC:  
http://dlang.org/phobos/core_memory.html#.GC.disable





I think it's important to note that there is three ways to go to 
minimize GC impact, by order of increasing difficulty:


1. Minimize allocations andthe size of scanned heap. This allows 
to still use the GC which is handy. Stay at this level if you 
need only speed.


2. Not enabling the runtime. This forces you to be fully @nogc 
but using the GC is a runtime error instead of a link error. Stay 
at this level if you need reduced memory consumption.


3. Not link with the runtime, or link with a minimal runtime. 
This is the hardest way and yield smaller binary size of all, 
along with the speed and reduced memory consumption.


GC avoidance is a spectrum.

Re: Mir GLAS is a C library and passes Natlib's test suite! And questions :-)

[Guillaume Piolat via Digitalmars-d]

On Saturday, 29 October 2016 at 01:43:03 UTC, Nicholas Wilson 
wrote:


If you have any experience with either OpenCL or CUDA we'd love 
to have your input.


Have experience with both, more CUDA than OpenCL though. Feel 
free to contact me.