Re: DConf 2016, Berlin: Call for Submissions is now open!

[ponce via Digitalmars-d-announce]

On Sunday, 1 November 2015 at 02:41:37 UTC, Andrei Alexandrescu 
wrote:


There's been considerable back and forth between Sociomantic 
and ourselves before choosing this path. One concern was that 
corporate intervention risks to stifle individual contributions 
such as Jonas' and ponce's. We concluded that we've been 
roughing it long enough so a bit of structured help is welcome.



Thanks,

Andrei


Hey, no problem. The site wasn't quite good enough anyway and 
it's good to see Sociomantic endorsing D to that extent.

[Issue 4492] Version of take() which takes from the back of a range

[via Digitalmars-d-bugs]

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

Infiltrator  changed:

   What|Removed |Added

 CC||lt.infiltra...@gmail.com

--- Comment #11 from Infiltrator  ---
Andrei, take(retro(arr), n) and arr[$-n..$] seem perfectly reasonable, so do
you want to close this one off?

--

Re: I have this game engine...

[Nerve via Digitalmars-d]

On Sunday, 1 November 2015 at 02:35:49 UTC, Manu wrote:
In terms of what I've used commercially, Fuji is the platform 
abstraction and core concept implementation that lives below 
the layer that the high-level interacts with. Editors and 
tooling (I feel this is what you're talking about when you 
start using words like 'Unity' or 'Unreal') typically impose 
particular design decisions wrt scene-graph, physics 
implementations, etc. The goal of Fuji is not to be Unity, it's 
intended to be the platform which you could build Unity above, 
and all commercial engines I've had contact with do have such a 
layer.


I'm not sure if that answers your question.
For what it's intended to be, Fuji is quite comprehensive. As a
full-game-engine a-la Unity/Unreal, it needs all the high-level 
stuff
built on top. The reason I didn't touch that, is because that 
layer is
extremely subjective, and there are no right/wrong answers 
there. I
also change my mind on that stuff every year or 2. Whereas the 
lower
level is a lot less subjective, and it's been more-or-less 
constant

since I started Fuji in 2003. I still wouldn't do it differently
today, although I have a lot more experience and console 
generations

to draw wisdom from.


Nonono, you're fine, what I'm looking for is a lightweight engine 
that ISN'T like Unity or Unreal and the sophisticated nature of 
their tools. Often, their engine design decisions back me into a 
corner when it comes to how I want to organize my own project, 
and they're oftentimes overkill.


About the only thing I would want to keep from those two monster 
engines is some live compilation feature where changes in source, 
assets, or UI scripting are immediately apparent in-game. But 
that takes a massive amount of work, I understand if it's not a 
priority. You have to port the thing to D in the first place, a 
significant undertaking in and of itself.


What you have seems to be great, so I'll follow it eagerly.

Re: I have this game engine...

[Manu via Digitalmars-d]

On 1 November 2015 at 16:45, Nerve via Digitalmars-d
 wrote:
>
> About the only thing I would want to keep from those two monster engines is
> some live compilation feature where changes in source, assets, or UI
> scripting are immediately apparent in-game. But that takes a massive amount
> of work, I understand if it's not a priority. You have to port the thing to
> D in the first place, a significant undertaking in and of itself.

I actually wrote that exact thing at Remedy (for Quantum Break) which
runtime compiles D code, and hot-swaps the new code into the live
data... if only I could liberate the source >_<

Re: good reasons not to use D?

[Ilya Yaroshenko via Digitalmars-d-learn]

On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote:

Any other thoughts?


Floating point operations can be extended automatically (without 
some kind of 'fastmath' flag) up to 80bit fp on 32 bit intel 
processors. This is worst solution for language that want to be 
used in accounting or math.


Thoughts like "larger precision entails more accurate answer" are 
naive and wrong.


--Ilya

[Issue 14866] Unable to find universal runtime static libraries on windows 10 and VS 2015

[via Digitalmars-d-bugs]

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

--- Comment #2 from Rainer Schuetze  ---
Should work in
https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.43-beta1

You'll need the release candidate for dmd 2.069 though to not get undefined
symbols, though.

--

[Issue 14524] Right clicking in solution explorer to add folders does not work as expected

[via Digitalmars-d-bugs]

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

--- Comment #3 from Rainer Schuetze  ---
There are now two entries: "Add Filter" for the C++ people, and "Add Folder"
for C# people. Try it in
https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.43-beta1

--

[Issue 15105] paths never work

[via Digitalmars-d-bugs]

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

--- Comment #2 from Manu  ---
I understand it's not necessarily VD at fault, but I wonder if VisualD can
interpret pathing related errors and prompt such that it can set the PATH env
var prior to retrying the build again with the new setting?

The problem is a symptom of Windows being such a ridiculous and broken platform
that nothing lives in predictable locations. VS itself is a special kind of
crazy, and sadly, we more-or-less just have to work around it :/

--

Re: Ready for testing: vibe.d 0.7.26-alpha.3

[Sebastiaan Koppe via Digitalmars-d]

On Saturday, 31 October 2015 at 07:57:06 UTC, Brad Anderson wrote:
On Saturday, 31 October 2015 at 03:07:35 UTC, Sebastiaan Koppe 
wrote:
In frontend development people are likely to use the same 
framework/library they used last time, in order to speed up 
development. Besides know-how, most of that stuff is 
battle-tested.


[...]


Very interesting. Thanks for answering.


The other thing is that you want to tap into their workflow.

Every frontend developer uses npm and every project starts with 
tools like grunt or gulp, browserify or webpack, + a dozen others.


What these tools do is support their development - every time 
they save a file their code gets linted, cross-compiled from 
es6/7 or coffeescript down to javascript, sourcemaps get created, 
everything gets concatenated, and sometimes hot loaded into their 
browser so they don't have to press F5.


For production these tools do similar work but often uglify and 
apply some cache-busting techniques as well.


For css the tools are similar, but they operate on less or sass 
files.


This all means that the js interface that gets generated by vibe 
needs to be integrated into their gulp/grunt workflow, which 
basically means generation the interface at compile time.

[Issue 14558] Attempts to link with DMD when using MSVC LDC under VisualD

[via Digitalmars-d-bugs]

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

--- Comment #9 from Rainer Schuetze  ---
I tweaked the defaults in
https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.43-beta1
and added browse buttons to set/add path entries.

Visual D also tries to detect whether LDC is built for MSVC or MinGW
environment, but I suspect that these should just be different compilers. You
cannot really mix LDC for MinGW/32-bit and LDC for MSVC/64-bit, but these seem
to be the current options.

--

[Issue 5323] std.math: struct FloatingPointControl, duplicate code and assumes X86

[via Digitalmars-d-bugs]

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

--- Comment #3 from Iain Buclaw  ---
(In reply to Infiltrator from comment #2)
> Is this still an issue?  I'd have a look at the source, but I'm afraid that
> I wouldn't be able to tell what's X86 or SPARC, etc.

Well, X86 code is guarded by a version(X86) block, SPARC code by a
version(SPARC) block.  :-)

--

[Issue 5323] std.math: struct FloatingPointControl, duplicate code and assumes X86

[via Digitalmars-d-bugs]

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

--- Comment #4 from Iain Buclaw  ---
Both struct FloatingPointControl and Ieeeflags still have their own private
enums.  Since these values should be mirrored somewhere in druntime stdc (it
looks like the me of five years ago couldn't work out where when searching
through the libc headers), then yes this is still a valid refactoring.

--

D 2.068.2 test runner for Android ARM, please test and report results from your Android device

[Joakim via Digitalmars-d-announce]

I'm happy to announce test runners for Android ARM, which will 
run most tests from druntime and phobos on your Android device:


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

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:


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

You can build ldc from source yourself using the patches linked.  
I will soon make available a cross-compiler build of ldc on 
linux/x86 and write up the process of building everything, 
including the test runner apk, on the wiki.  I'll also port some 
more sample OpenGL apps from the Android NDK.  Help with all of 
the above and fixing the remaining issues would be appreciated.


You may notice that the patches are not very large, other than 
Kai's patch for cross-compiling 64-bit reals.  That's because of 
ongoing ARM work for years by Johannes, Kai, Martin, David, and 
others, the awesomeness of ldc and llvm, and the Android/x86 
patches I've upstreamed over the last couple years.


I'd like to help get some D/OpenGL app ported to Android and 
submitted to the Play Store.  Please let me know if you have any 
such project I can help with.

[Issue 14873] Build fails with message 'cannot create PDB file'

[via Digitalmars-d-bugs]

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

--- Comment #8 from Rainer Schuetze  ---
Should be fixed in
https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.43-beta1

--

[Issue 15024] Wrong keyword color for Visual Studio Dark theme

[via Digitalmars-d-bugs]

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

--- Comment #2 from Rainer Schuetze  ---
Should be fixed in
https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.43-beta1

--

[Issue 15105] paths never work

[via Digitalmars-d-bugs]

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

--- Comment #1 from Rainer Schuetze  ---
https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.43-beta1
has better defaults, but I agree that better guidance in case of errors would
be nice.

Unfortunately, path issues are not always about Visual D not finding an
executable, but the invoked tools need to find DLLs or other stuff (e.g.
link.exe needs to find mspdb*.dll and mspdbsrv.exe which needs other DLLs, GDC
needs the mingw DLLs). I'm not sure Visual D can cover all possible error
situations.

--

Re: I have this game engine...

[Manu via Digitalmars-d]

On 1 November 2015 at 17:43, Nerve via Digitalmars-d
 wrote:
> On Sunday, 1 November 2015 at 07:30:57 UTC, Manu wrote:
>>
>> I actually wrote that exact thing at Remedy (for Quantum Break) which
>> runtime compiles D code, and hot-swaps the new code into the live data... if
>> only I could liberate the source >_<
>
>
> Wow, I had no idea D was being used for such a massive project, especially
> on a current-gen console. If I might ask before taking the thread too far
> off-topic, what tools did you guys use to maintain productivity and
> organization in such a huge project? (Debuggers, editors, IDEs, etc.)

Visual Studio. I'm not aware of any practical alternatives on any platform >_<
I really, really wish there was competition in the IDE space. We're
all sick to death of MS and Visual Studio, we'd all jump ship in an
instant, but there's just nothing that comes close.

[Issue 5509] R250/521 pseudo-random number engine

[via Digitalmars-d-bugs]

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

Infiltrator  changed:

   What|Removed |Added

 CC||lt.infiltra...@gmail.com

--- Comment #1 from Infiltrator  ---
Are you still interested in adding  this generator?  If so, would you mind
putting in a pull request on github?

--

[Issue 15106] Optlink executed with LDC as compiler?

[via Digitalmars-d-bugs]

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

David Nadlinger  changed:

   What|Removed |Added

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

--- Comment #10 from David Nadlinger  ---
We (LDC) also auto-detect MSVC installations now, so this should be fixed.

--

[Issue 15106] Optlink executed with LDC as compiler?

[via Digitalmars-d-bugs]

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

--- Comment #12 from Rainer Schuetze  ---
> We (LDC) also auto-detect MSVC installations now, so this should be fixed.

I just realized that LDC checks VSINSTALLDIR, not VCINSTALLDIR which is set by
Visual D. This causes the batch with the auto detection to be run, but it uses
the highest installed version of VS. 
That is not necessarily the version I'm not currently working with (and might
want to link D code with C++ code). Visual D should probably also set
VSINSTALLDIR to disable auto detection in LDC.

--

Re: I have this game engine...

[Nerve via Digitalmars-d]

On Sunday, 1 November 2015 at 07:30:57 UTC, Manu wrote:
I actually wrote that exact thing at Remedy (for Quantum Break) 
which runtime compiles D code, and hot-swaps the new code into 
the live data... if only I could liberate the source >_<


Wow, I had no idea D was being used for such a massive project, 
especially on a current-gen console. If I might ask before taking 
the thread too far off-topic, what tools did you guys use to 
maintain productivity and organization in such a huge project? 
(Debuggers, editors, IDEs, etc.)

Re: good reasons not to use D?

[Russel Winder via Digitalmars-d-learn]

On Sat, 2015-10-31 at 20:55 +, David Nadlinger via Digitalmars-d-
learn wrote:
> On Saturday, 31 October 2015 at 18:23:43 UTC, rumbu wrote:
> > My opinion is that a decimal data type must be builtin in any 
> > modern language, not implemented as a library.
> 
> "must be builtin in any modern language" – which modern languages 
> actually have decimals as a built-in type, and what is your 
> rationale against having them as a solid library implementation? 
> It seems like it would only be interesting for a very fringe 
> sector of users (finance, and only the part of it that actually 
> deals with accounting).
> 
>   — David

It is really a question of symmetry: if there are hardware
implementations of both binary and denary floating point, then if a
language has binary floating point in the language, then it should have
denary floating point in the language. To support one hardware type in
the language but relegate another hardware type to the library is
inappropriate discrimination.

If I remember correctly (I am on a very poor Internet connection just
now and can't do the necessary research), IBM z-series has two
different denary hardware types, and there is currently a question as
to which of these to draw into the IEEE standard as the preferred type.
I think Intel are muttering about which one to support.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

[Issue 15106] Optlink executed with LDC as compiler?

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

 CC||r.sagita...@gmx.de

--- Comment #9 from Rainer Schuetze  ---
In https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.43-beta1
the executable search path settings now default to put the VC bin folder before
the dmd folder, so whenever a tool calls link.exe or lib.exe without absolute
path (dmd uses a path relative to dmd.exe), it should pick up the MS
executables.

--

[Issue 14558] Attempts to link with DMD when using MSVC LDC under VisualD

[via Digitalmars-d-bugs]

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

--- Comment #10 from Manu  ---
(In reply to Rainer Schuetze from comment #9)
> but I suspect that these should just be different compilers.

This is true. Where do you think VisualD stands in defining different
toolchains like this? We'll need a way to map 'platforms' to configured
toolchains at some point. There are cross compilers for all sorts of
architectures, and we don't really have a way to configure multiple toolchains
for different targets with VisualD at this time.

With Android and iOS coming online, I think this will be a critical issue
fairly soon.

I'm not sure the best approach. MS do it completely differently to VisualD. I
often wonder if an MSBuild style solution would be more idiomatic?

--

Re: Allocation strategies question

[ref2401 via Digitalmars-d-learn]

On Friday, 30 October 2015 at 05:21:17 UTC, Rikki Cattermole 
wrote:

What I normally do for memory to be owned by the thread is:

auto foo(IAllocator alloc=theAllocator()) {...}

Where as for if it is global to the process:

auto foo(IAllocator alloc=processAllocator()) {...}

Basically it is the difference between a screenshot of a 
display and a window instance.


What do other think?

[Issue 15107] Win32-COFF library paths are blank

[via Digitalmars-d-bugs]

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

--- Comment #3 from Rainer Schuetze  ---
fixed in
https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.43-beta1

--

[Issue 15105] paths never work

[via Digitalmars-d-bugs]

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

--- Comment #3 from Manu  ---
Thinking on it, maybe a better solution would be to remove those settings from
the user entirely.

Imagine a UI that looks something like: "Add toolchain", the user is then
prompted to locate the root directory of the toolchain they want to 'add'.
VisualD may then identify if the path appears to be a DMD/LDC/GDC toolchain
based on various indicators. It may then even like to invoke the compiler's
diagnostic to interrogate the platform(/s) it targets (ie, MSVC/MinGW/ARM/...)

I've seen QtCreator and CodeLite work this way, and it is very convenient and
easy for users. CodeLite will even do a quick scan of predictable locations for
various toolchains that will be configured and made available automatically.

Sounds like quite a bit of work, but it might make this entire class of problem
disappear once and for all :)

--

[Issue 15106] Optlink executed with LDC as compiler?

[via Digitalmars-d-bugs]

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

--- Comment #11 from Manu  ---
Great! Looking forward to trying all this out next time I do a fresh install :)
Thanks everyone for your vigilance!

--

[Issue 15105] paths never work

[via Digitalmars-d-bugs]

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

--- Comment #4 from Rainer Schuetze  ---
> Sounds like quite a bit of work, but it might make this entire class of 
> problem disappear once and for all :)

Although it sounds like a feasible idea I'm a bit hesitent to build a framework
for specifying a new tool chain. Each one has its special cases not easily
mapped to a simple definition file.
It also means that a project won't compile correctly on another system without
also transferring the tool chain setup (which is not part of the project).

I'll have a closer look at how QtCreator is dealing with this...

I was also considering allowing to build through msbuild, but that needs people
to write support assemblies for the specific tool chains.

--

[Issue 666] missing pthread functions

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||and...@erdani.com
 Resolution|--- |WONTFIX

--

Re: I have this game engine...

[Jack Stouffer via Digitalmars-d]

On Sunday, 1 November 2015 at 07:30:57 UTC, Manu wrote:
I actually wrote that exact thing at Remedy (for Quantum Break) 
which runtime compiles D code, and hot-swaps the new code into 
the live data... if only I could liberate the source >_<


Well, Remedy owns the source, but they can't own your knowledge. 
You could write something up explaining how it works and let 
someone else write something from that.

Re: D 2.068.2 test runner for Android ARM, please test and report results from your Android device

[Martin Nowak via Digitalmars-d-announce]

On 11/01/2015 10:50 AM, Joakim wrote:
> http://forum.dlang.org/thread/bafrkjfwmoyriyhmq...@forum.dlang.org

Nice works for me as well (Galaxy S3 on cm-12.1 (5.1.1)).
Would be nice to run this as automated test on an Android Emulator.

[Issue 15105] paths never work

[via Digitalmars-d-bugs]

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

--- Comment #5 from Manu  ---
(In reply to Rainer Schuetze from comment #4)
> > Sounds like quite a bit of work, but it might make this entire class of 
> > problem disappear once and for all :)
> 
> Although it sounds like a feasible idea I'm a bit hesitent to build a
> framework for specifying a new tool chain. Each one has its special cases
> not easily mapped to a simple definition file.
> It also means that a project won't compile correctly on another system
> without also transferring the tool chain setup (which is not part of the
> project).

This is an open problem. A project with an 'XBox 360' platform can't build
those configurations if the user doesn't have the toolset installed.
In the case of C/C++, if the platform is unavailable, the project still loads,
but those particular configurations give build errors.

I think the conventional way to solve this problem is to make the solution
platforms known defined values. That way, when the user configures the
toolchain, the solution platform names will be standardised and match properly.

Clang support is implemented via platform-toolset, but the same story there;
platform toolset names need to match appropriately, although in that case, it's
all just MSBuild mischief. If LLVM isn't installed, it just complains when
trying to build that config.

> I'll have a closer look at how QtCreator is dealing with this...
> 
> I was also considering allowing to build through msbuild, but that needs
> people to write support assemblies for the specific tool chains.

I had a brief look into this at one point; it looked to me like it might be
possible to make regular vcxproj files capable of building D code with
appropriate property pages. The problem then would probably become launching
the correct debug environment when launching.

--

Re: good reasons not to use D?

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Saturday, 31 October 2015 at 23:16:04 UTC, Ali Çehreli wrote:
Although still years away from production, the Mill CPU will 
have decimal floating point:


  http://millcomputing.com/wiki/Instruction_Set



Mill is a fun project, and there are also base 10 floating point 
FPGA coprocessors available, but probably not widely deployed.


I've personally settled for storing in cents instead, as integers 
have accurate precision (storing "30.0" instead of "0.3"). The 
problem is then reduced to writing a wrapper for floats with a 
dedicated string_to_float conversion that is loss free.

Re: Sociomantic Labs is looking for Software Developers! (D language)

[Andrej Mitrovic via Digitalmars-d-announce]

On 10/31/15, Andrea Fontana via Digitalmars-d-announce
 wrote:

> I think you need an Italian translator too. :) Your ad on
> facebook sounds bad in italian where "display" is translated as a
> female word but all big italian dictionaries report it as male.
>
> You write "La programmatic display" but it should be "Il
> programmatic display".

Absolutely! I've studied Italian as a kid and still remember those rules. :)

I'll forward this to our web admins. Thanks!

Re: DConf 2016, Berlin: Call for Submissions is now open!

[Jonas Drewsen via Digitalmars-d-announce]

On Sunday, 1 November 2015 at 02:41:37 UTC, Andrei Alexandrescu 
wrote:

On 10/31/15 5:24 PM, Jonas Drewsen wrote:

[...]


Many thanks to both you and ponce! This is great work.

I have good news and bad news. The bad news is we won't likely 
be able to accept either of these proposals.


[...]


No worries - I just quickly threw something together that I 
though could do.


Having an actual pro team behind this is great news!

[Issue 15272] [2.069-rc2,inline] nothing written to output when -inline is set

[via Digitalmars-d-bugs]

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

--- Comment #2 from ag0ae...@gmail.com ---
(In reply to bb.temp from comment #0)
> So far I'm here but it doesn't capture the essence of the problem.
> 
> ---
[...]
> ---

As far as I can tell, everything works as expected in that code.

The different `children` arrays are GC allocated (via ~=), but the `Foo`s
themselves are not. So a parent `Foo` doesn't keep its `children` alive, and at
some point the GC collects the seemingly dead arrays.

--

Re: Collection, why COW collection are important

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 1 November 2015 at 13:43:25 UTC, Gary Willoughby wrote:

What does COW mean here?


Copy-On-Write. You can use it with shared ref counting and 
immutable for filling out templates, transactional computations 
and other situations where you want to create  a new version of 
something without affecting the original immediately.

Re: I have this game engine...

[Johannes Pfau via Digitalmars-d]

Am Sun, 1 Nov 2015 11:33:21 +1000
schrieb Manu via Digitalmars-d :

> So, I just wanted to put this idea out there, and see what other
> people make of it.
> 
> I have this game engine (https://github.com/TurkeyMan/fuji), it's
> lived for about 12 years now (first commit in 2004, and it existed
> prior before source control). I called it 'Fuji' (a modest, yet
> pleasing and attractive mountain). It supports (or has supported)
> shit-loads of platforms; I'm a game-engine dev for life, and I have a
> fetish for portability, and niche platform support.
> Needless to say, it has had a LOT of time and energy put into it, and
> I would say it's infrastructurally better than most proprietary
> commercial game-engines I've worked with (although there are some
> missing features, I just implement what I need), mainly in that I have
> the luxury to aggressively refactor when design decisions turned out
> to be mistakes, and no deadlines to meet.
> It is a very good example of what we use in real-world AAA gamedev.
> 
> It's written in C, obviously. It has comprehensive bindings for D,
> which I'm pretty sure I'm the only one that's ever used, and I use it
> in all my modern D projects.
> 
> Anyway. I'm spending less time on hobby game-dev these days, obviously
> I'm not going to make the worlds next big game engine... Hobbyists
> will just use Unity. I'm not quite sure what to do with it.
> 
> I have been thinking about full-scale porting to D, and it would serve
> there is a massive-scale long-term codebase, with portability as it's
> primary objective, and I don't know of another project quite like this
> in the D ecosystem? Also, perhaps D gamedevs might be interested in an
> all-D game engine they can use and hack on.
> 
> So, when I think on that, I consider what would be lost... and the
> answer is; almost all platforms. But this is something that can be
> addressed.
> 
> If people find this to be an interesting project, and I do take some
> time to do this port, what I'd really love is to work together with
> some of the niche platform support guys and use it to stress test
> toolchains for various platforms. I'd also like help from guys like
> Johannes to make regularly released builds of some console
> cross-compilers available so that it can keep on building.
> The CI of this project for those platforms would more-or-less verify
> that the toolchains and druntime+friends are working.

Sounds like a great idea!

I can certainly build the GDC toolchains*. But I guess the first thing
you'll need if you want to use Dreamcast, NDS and other low memory
systems is a @nogc druntime port? I had a look at this some time ago and
there's some work to be done until we can build a druntime completely
without GC.



*
or better: also provide build scripts. We now use docker.io containers
to build the binary GDC toolchains. Building a toolchain with the latest
GDC version is as simple as running one docker command:

docker run
-v ~/shared-dir/:/home/build/shared #results will be saved here
-t jpf91/build-gdc /usr/bin/build-gdc build
--toolchain=x86_64-w64-mingw32/gcc-5/x86_64-w64-mingw32

It should be easy enough to add support for console toolchain build
scripts.

Docs:
http://build-gdc.readthedocs.org/en/latest/
Sources:
https://github.com/D-Programming-GDC/build-gdc
https://github.com/D-Programming-GDC/build-gdc-config
https://github.com/D-Programming-GDC/build-gdc-docker

[Issue 4492] Version of take() which takes from the back of a range

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

--- Comment #12 from Andrei Alexandrescu  ---
(In reply to Infiltrator from comment #11)
> Andrei, take(retro(arr), n) and arr[$-n..$] seem perfectly reasonable, so do
> you want to close this one off?

Yes, thanks.

--

Re: dlang.org/library/* - is this still being used?

[Vladimir Panteleev via Digitalmars-d]

On Sunday, 1 November 2015 at 13:49:32 UTC, Gary Willoughby wrote:

In the /library version there are many broken links/anchors.


You can report issues with the DDox documentation here:

https://github.com/rejectedsoftware/ddox/issues


It doesn't really matter if it's outdated or not.


Whether it "really matters" or not is not relevant to my 
question. I asked because it should be completely synced with the 
DDoc version, as it is generated from the same source. If the two 
are not in sync, that would indicate a problem somewhere, 
possibly something I can fix.


The fact that we now have 3 public URLs for each reference page 
is crazy.


For example:

http://dlang.org/phobos/std_string.html
http://dlang.org/library/std/string.html
http://dlang.org/library-prerelease/std/string.html


Four:

http://dlang.org/phobos-prerelease/std_string.html

The -prerelease versions are excluded from search engine indexing.

Re: Release Candidate D 2.069.0-rc2

[Martin Nowak via Digitalmars-d-announce]

On 10/31/2015 01:00 PM, BBasile wrote:
> 
> Despite of what I had say previously I've encountered another "inliner"
> bug today that looks like a regression. I don't know what's the 2.069
> ETA but I'm not sure to be able to file a bugzilla entry quickly.

Please just file ticket with whatever you have (e.g. project x fails
with ...). We can reduce the code ourself or might already recognize the
issue.
Regarding the ETA, we're already overdue by 2 weeks.

-Martin

Re: I have this game engine...

[Joakim via Digitalmars-d]

On Sunday, 1 November 2015 at 01:33:29 UTC, Manu wrote:
If people find this to be an interesting project, and I do take 
some
time to do this port, what I'd really love is to work together 
with
some of the niche platform support guys and use it to stress 
test
toolchains for various platforms. I'd also like help from guys 
like

Johannes to make regularly released builds of some console
cross-compilers available so that it can keep on building.
The CI of this project for those platforms would more-or-less 
verify

that the toolchains and druntime+friends are working.


Sounds great, would make a good stress test for Android and maybe 
even a base for D games for Android.  See my post in the announce 
forum earlier today about Android progress.

Re: D 2.068.2 test runner for Android ARM, please test and report results from your Android device

[Joakim via Digitalmars-d-announce]

On Sunday, 1 November 2015 at 18:41:26 UTC, Martin Nowak wrote:

On 11/01/2015 10:50 AM, Joakim wrote:

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


Nice works for me as well (Galaxy S3 on cm-12.1 (5.1.1)).
Would be nice to run this as automated test on an Android 
Emulator.


Yes, would be good to integrate this with CI, I was thinking of 
trying to get ldc for Android going on Travis:


http://docs.travis-ci.com/user/languages/android/

Re: dlang.org/library/* - is this still being used?

[Gary Willoughby via Digitalmars-d]

On Sunday, 1 November 2015 at 05:13:49 UTC, Vladimir Panteleev 
wrote:

On Sunday, 1 November 2015 at 02:56:08 UTC, rsw0x wrote:

The documentation is outdated and obfuscates google searches


How is it outdated?


In the /library version there are many broken links/anchors. It 
doesn't really matter if it's outdated or not. The fact that we 
now have 3 public URLs for each reference page is crazy.


For example:

http://dlang.org/phobos/std_string.html
http://dlang.org/library/std/string.html
http://dlang.org/library-prerelease/std/string.html

Lazy std.algorithm.replace()

[Nordlöw via Digitalmars-d-learn]

Is there a reason why Phobos doesn't contain a lazy range variant 
of std.string.replace?

Re: I have this game engine...

[Joseph Rushton Wakeling via Digitalmars-d]

On 01/11/15 08:30, Manu via Digitalmars-d wrote:

I actually wrote that exact thing at Remedy (for Quantum Break) which
runtime compiles D code, and hot-swaps the new code into the live
data... if only I could liberate the source >_<


Wow.  That sounds like it could have uses far beyond games -- I'm thinking 
Erlang-style hot-swapping of components of super-high-uptime (web) services ...

Can't get winapi working

[dozksaw via Digitalmars-d-learn]

Hi. I was trying all day to get this working, but i give up and 
post it here.


module tryingwinapi;

import core.runtime;
import std.utf;

auto toUTF16z(S)(S s)
{
return toUTFz!(const(wchar)*)(s);
}

import win32.windef;
import win32.winuser;

extern (Windows)
int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR 
lpCmdLine, int iCmdShow)

{
int result;
void exceptionHandler(Throwable e) { throw e; }

try
{
Runtime.initialize();
result = myWinMain(hInstance, hPrevInstance, lpCmdLine, 
iCmdShow);

Runtime.terminate();
}
catch (Throwable o)
{
MessageBox(null, o.toString().toUTF16z, "Error", MB_OK | 
MB_ICONEXCLAMATION);

result = 0;
}

return result;
}

int myWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR 
lpCmdLine, int iCmdShow)

{
MessageBox(NULL, "Hello, Windows!", "Your Application", 0);
return 0;
}

I have found that code here 
https://github.com/AndrejMitrovic/DWinProgramming/blob/master/Samples/Chap01/HelloMsg/HelloMsg.d

I have copied the win32 directory from his github.
Thats how my directory looks:
ls
win32  winapi.d
Getting this error:
dmd winapi.d
win32/winnt.d(2130): Error: undefined identifier 'CONTEXT', did 
you mean alias 'PCONTEXT'?
win32/winnt.d(2130): Error: undefined identifier 'CONTEXT', did 
you mean alias 'PCONTEXT'?
win32/winbase.d(2004): Error: undefined identifier 'CONTEXT', did 
you mean alias 'PCONTEXT'?


I was trying another code what i found on the web:
module tryingwinapi;

import core.runtime;
import core.sys.windows.windows;

extern(Windows)  int WinMain( HINSTANCE hInstance, HINSTANCE 
hPrevInstance, LPSTR lpCmdLine, int nCmdShow )

{
MessageBox( NULL, "text", "title", MB_OKCANCEL);
return 0;
}

This returns me:
dmd winapi.d
winapi.d(6): Error: undefined identifier 'HINSTANCE'
winapi.d(6): Error: undefined identifier 'HINSTANCE'
winapi.d(6): Error: undefined identifier 'LPSTR'


What is the correct code to show the MessageBox in windows?

[Issue 15272] New: [2.069-rc2, inline] nothing written to output when -inline is set

[via Digitalmars-d-bugs]

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

  Issue ID: 15272
   Summary: [2.069-rc2,inline] nothing written to output when
-inline is set
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bb.t...@gmx.com

Created attachment 1560
  --> https://issues.dlang.org/attachment.cgi?id=1560=edit
involed project

I have this project that compiles fine with 2.069-rc2 but doesn't work anymore.
So far I didn't manage to reduce the issue because several factors are mixed:

What happens now:
=

nothing is written to stdout.

what should happens:


stdout filled.

when does this work anyway:
===

1/ if I use the 'new' operator instead of my custom 'construct' template.
2/ if I disable the inline switch.
3/ if I create a File with "w" flag before writing stdout.

with the 3rd workaround being totally WTF. So maybe something in File __ctor
fix the issue ?!.

code:
=

see attachment

shell commands:
===

dmd
/home/basile/Dev/pasproj/Coedit/cesyms/cesyms.d
/home/basile/Dev/metad/libs/libdparse.a
-I/home/basile/Dev/metad/repos/libdparse/src
-w
-inline
-O
-release
-boundscheck=off
-of../lazproj/cesyms


Attempt to reduce:
==

So far I'm here but it doesn't capture the essence of the problem.

---
//#!runnable-flags: -O -inline
module runnable;

import core.memory;
import std.stdio, std.array, std.conv;
import std.experimental.allocator.mallocator;

ST* construct(ST, Allocator = Mallocator, A...)(A a)
if(is(ST==struct))
{
auto memory = Allocator.instance.allocate(ST.sizeof)[0 .. ST.sizeof];
//GC.addRange(memory.ptr, ST.sizeof);
return emplace!(ST, A)(memory, a);
}

struct Foo
{
Foo*[] children;
void get(ref Appender!string app)
{
app.put("whatever");
foreach(child; children) child.get(app);
}
}

void main(string[] args)
{
Appender!string app;
Foo* foo = construct!Foo;
foreach(i; 0..100) 
{ 
foo.children ~= construct!Foo;
foreach(j; 0..100) foo.children[i].children ~= construct!Foo; 
}
foo.get(app);
auto s = app.data;
assert(0, s);
}---

the assertion failure doesn't happen at all when GC.addRange() is commented.
Then in the real project project I've added GC.addRange() too to the
struct/class allocators but the bug still happens (empty stdout). It looks like
actually there's a crash before reaching 'write(stuff.serialize)'.

--

[Issue 15272] [2.069-rc2,inline] nothing written to output when -inline is set

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
(In reply to bb.temp from comment #0)
> So far I'm here but it doesn't capture the essence of the problem.
> 
> ---
[...]
> ---

That code segfaults for me. Is that what you see, too?

--

Re: Collection, why COW collection are important

[Gary Willoughby via Digitalmars-d]

On Saturday, 31 October 2015 at 23:02:12 UTC, deadalnix wrote:
The hack team recently released project to add COW collection 
to hack in addition to current, reference type, collections. 
You can find explanation here :


http://hhvm.com/blog/10649/improving-arrays-in-hack

As collection are discussed here, I think this is relevant, 
especially the explanations as of why COW matters.


What does COW mean here?

Re: I have this game engine...

[Jacob Carlborg via Digitalmars-d]

On 2015-11-01 02:33, Manu via Digitalmars-d wrote:


I have been thinking about full-scale porting to D


You could enhance DStep [1] to handle complete source code and not only 
headers.


[1] https://github.com/jacob-carlborg/dstep

--
/Jacob Carlborg

Re: Ready for testing: vibe.d 0.7.26-alpha.3

[Ola Fosheim Grøstad via Digitalmars-d]

On Saturday, 31 October 2015 at 03:07:35 UTC, Sebastiaan Koppe 
wrote:

On Friday, 30 October 2015 at 21:03:21 UTC, Brad Anderson wrote:

On Friday, 30 October 2015 at 16:16:11 UTC, Sebastiaan Koppe
I really have to say I fail to see any value in that JS 
interface generation feature. The idea is nice, but it needs 
adapters to common ajax libraries, instead of homegrown stuff.


I'm not really a web developer. Do you have any examples of 
what you mean?


In frontend development people are likely to use the same 
framework/library they used last time, in order to speed up 
development. Besides know-how, most of that stuff is 
battle-tested.


Keep in mind that javascript frameworks die after ~2 years.

Instead, what you want to do is generate code that uses one of 
those libraries. Here is an example of how an ajax call looks


Browsers are now providing promises/futures for fetching data:

https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch
https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Promise

Re: Capturing __FILE__ and __LINE in a variadic templated function

[anonymous via Digitalmars-d-learn]

On 01.11.2015 23:49, Adam D. Ruppe wrote:

Yeah, just make the other args normal runtime instead of template:


Or make it two nested templates:

template show(T ...)
{
void show(string file = __FILE__, uint line = __LINE__,
string fun = __FUNCTION__)()
{
...
}
}

Re: Ready for testing: vibe.d 0.7.26-alpha.3

[Sebastiaan Koppe via Digitalmars-d]

On Sunday, 1 November 2015 at 19:44:12 UTC, Ola Fosheim Grøstad 
wrote:

Keep in mind that javascript frameworks die after ~2 years.


They may die young, but every framework is an improvement upon 
the last. So in a way the reasoning and principles behind them 
continue. In that sense it follows the development pattern 
everything with computers does:


Cool Idea -> Everybody Happy -> It Sucks -> Complete Rewrite


Browsers are now providing promises/futures for fetching data:

https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch
https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Promise


Yep, that would be another target. And while it is a nice 
development, promises and futures don't even come close to the 
power of RxJS or BaconJS.


https://github.com/Reactive-Extensions/RxJS
http://baconjs.github.io/

Access violation when calling C DLL from D

[AnoHito via Digitalmars-d-learn]

Hi, I am trying to write a simple interface to the MRuby Ruby 
interpreter so I can use ruby scripts in my D program. I was able 
to get MRuby compiled as a DLL without too much difficulty, but 
the headers are very long and complicated, and porting them 
entirely to D would be a huge project in and of itself. I am 
trying to get by with only what I need, so here is what I have so 
far:


module script.mruby;

alias mrb_bool = bool;
alias mrb_int = int;
alias mrb_float = double;
alias mrb_sym = uint;

alias mrb_aspec = uint;

struct mrb_value
{

}
struct RObject
{

}

struct RClass
{

}

struct mrb_value
{

}

struct mrb_state
{

}

extern(C) char *mrb_string_value_cstr(mrb_state *mrb, mrb_value 
*ptr);


extern (C) mrb_value mrb_load_string(mrb_state *mrb, const char 
*s);
extern (C) mrb_value mrb_load_nstring(mrb_state *mrb, const char 
*s, int len);


extern (C) mrb_state *mrb_open();
extern (C) void mrb_close(mrb_state *mrb);

In theory, this should be enough to test that MRuby is working, 
so I tried to run the following code:


mrb = mrb_open();
mrb_value result = mrb_load_string(mrb, 
toStringz("String('test')"));

Log.info(to!string(mrb_string_value_cstr(mrb, )));

But the result was:

object.Error@(0): Access Violation

I wasn't able to get the Visual D debugger to trace into the 
code, but after some investigation, I figured out that the error 
was occurring in the strlen runtime function. I don't think I did 
anything wrong with the way I passed a string into the 
mrb_load_string function, so I am kind of at a loss as to what 
the problem might be.

Re: I have this game engine...

[Manu via Digitalmars-d]

On 2 November 2015 at 01:50, Jack Stouffer via Digitalmars-d
 wrote:
> On Sunday, 1 November 2015 at 07:30:57 UTC, Manu wrote:
>>
>> I actually wrote that exact thing at Remedy (for Quantum Break) which
>> runtime compiles D code, and hot-swaps the new code into the live data... if
>> only I could liberate the source >_<
>
>
> Well, Remedy owns the source, but they can't own your knowledge. You could
> write something up explaining how it works and let someone else write
> something from that.

It's not that. We all felt happy to release the tech open-source (at
the time I left), which may have changed since, but I have no reason
to believe it has. It's just taking the time to separate the tech from
any proprietary stuff.

Re: Access violation when calling C DLL from D

[AnoHito via Digitalmars-d-learn]

On Monday, 2 November 2015 at 02:13:29 UTC, BBasile wrote:

On Monday, 2 November 2015 at 01:02:45 UTC, AnoHito wrote:

[...]
the headers are very long and complicated, and porting them 
entirely to D would be a huge project in and of itself.

[...]


You can give a try at h2d, the C header to D interface 
converter:


http://dlang.org/htod.html


I did, but it just produced a ton of errors...

[Issue 14779] incorrect addressing of arguments in require/in-contract

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

 CC||lt.infiltra...@gmail.com

--- Comment #4 from Kenji Hara  ---
*** Issue 15266 has been marked as a duplicate of this issue. ***

--

[Issue 15266] Parameters to methods of final classes become uninitialised in out contracts for DMD only

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Kenji Hara  ---
This is a dup of issue 14779, and it's fixed from 2.069.0-b1 or later.

*** This issue has been marked as a duplicate of issue 14779 ***

--

Re: Access violation when calling C DLL from D

[BBasile via Digitalmars-d-learn]

On Monday, 2 November 2015 at 01:02:45 UTC, AnoHito wrote:

[...]
the headers are very long and complicated, and porting them 
entirely to D would be a huge project in and of itself.

[...]


You can give a try at h2d, the C header to D interface converter:

http://dlang.org/htod.html

[Issue 12421] Allow simpler syntax for lambda template declarations

[via Digitalmars-d-bugs]

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

--- Comment #9 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/dlang.org

https://github.com/D-Programming-Language/dlang.org/commit/9446e513e4ba1b984d03b159ad0820c1e58024d5
fix Issue 12421 - Allow simpler syntax for lambda template declarations

https://github.com/D-Programming-Language/dlang.org/commit/5d2f9dfd8a496896e22bf227855b6de9629b3f71
Merge pull request #1148 from MartinNowak/alias_funclit

fix Issue 12421 - Allow simpler syntax for lambda template declarations

--

Re: I have this game engine...

[Manu via Digitalmars-d]

On 2 November 2015 at 04:17, Johannes Pfau via Digitalmars-d
 wrote:
> Am Sun, 1 Nov 2015 11:33:21 +1000
> schrieb Manu via Digitalmars-d :
>
>> If people find this to be an interesting project, and I do take some
>> time to do this port, what I'd really love is to work together with
>> some of the niche platform support guys and use it to stress test
>> toolchains for various platforms. I'd also like help from guys like
>> Johannes to make regularly released builds of some console
>> cross-compilers available so that it can keep on building.
>> The CI of this project for those platforms would more-or-less verify
>> that the toolchains and druntime+friends are working.
>
> Sounds like a great idea!
>
> I can certainly build the GDC toolchains*. But I guess the first thing
> you'll need if you want to use Dreamcast, NDS and other low memory
> systems is a @nogc druntime port? I had a look at this some time ago and
> there's some work to be done until we can build a druntime completely
> without GC.

Awesome! Your support on this is really encouraging. Almost all
consoles are typically targeted by GCC. PS4 uses Clang officially, but
I'm sure GCC works just as well.

Easiest to start with some of the bigger systems. I think another
benefit of this project may be that building for the smaller systems
will start to reveal binary size issues, and perhaps we can use it as
a vessel to drive some improvements in that area. Binary size is
something that's been really irk-ing me for years.

What implicitly linked parts of druntime are not @nogc?
I have no good reason to say that @nogc should be an absolute
requirement... it is almost certainly preferable to many gamedevs so
it would be nice to support it, but GC should be available if the
developer wants it... I'm not sure what cost that comes at in terms of
binary size. Runtime memory is a matter for the developer, they know
the compromise they are making if they opt to use the GC.


> or better: also provide build scripts. We now use docker.io containers
> to build the binary GDC toolchains. Building a toolchain with the latest
> GDC version is as simple as running one docker command:
>
> docker run
> -v ~/shared-dir/:/home/build/shared #results will be saved here
> -t jpf91/build-gdc /usr/bin/build-gdc build
> --toolchain=x86_64-w64-mingw32/gcc-5/x86_64-w64-mingw32
>
> It should be easy enough to add support for console toolchain build
> scripts.

Awesome, and that would just be run along with the rest of the CI when
producing toolchains? Reliable binary downloads available in known
places? Even the presence of these toolchains (whether people use them
or not) will inspire some confidence in gamedev's that D means
business in gamedev. They are more likely to give D a shot if they
know that toolchains are available should ports need to be made at
some later stage.

Re: I have this game engine...

[Manu via Digitalmars-d]

On 2 November 2015 at 05:27, Jacob Carlborg via Digitalmars-d
 wrote:
> On 2015-11-01 02:33, Manu via Digitalmars-d wrote:
>
>> I have been thinking about full-scale porting to D
>
>
> You could enhance DStep [1] to handle complete source code and not only
> headers.

I'll give it a shot... see how close it gets me.
It's almost C code (C with light internal use of classes), so it
should port really easily.

Re: DConf 2016, Berlin: Call for Submissions is now open!

[Dicebot via Digitalmars-d-announce]

On Sunday, 1 November 2015 at 19:28:48 UTC, Iain Buclaw wrote:

Many thanks to both you and ponce! This is great work.

I have good news and bad news. The bad news is we won't likely 
be able to accept either of these proposals.


The good news is Sociomantic wants to get behind the DConf 
logo design, more generally behind the dconf.org site design, 
and even more generally get more involved in helping the 
Foundation and the language. It will take their design team a 
bit longer to get things done, but they want to do it right.




Does the design team know this yet?  :-)

Iain.


Yes :)

Re: Can't get winapi working

[Vladimir Panteleev via Digitalmars-d-learn]

On Sunday, 1 November 2015 at 17:52:08 UTC, dozksaw wrote:

I have copied the win32 directory from his github.


Try the official repository:

https://github.com/smjgordon/bindings/tree/master/win32

These headers will also be available as core.sys.windows.* 
starting with D 2.070.

Re: Safe reference counting cannot be implemented as a library

[deadalnix via Digitalmars-d]

On Sunday, 1 November 2015 at 20:55:00 UTC, Martin Nowak wrote:

On 11/01/2015 09:51 PM, Martin Nowak wrote:

Any hint/numbers showing that this is actually useful?


Also doesn't a good backend optimizer already fuse writes?


Yes but you have this myth flying around that it is necessary for 
good RC, because language like C++ do implicit sharing, so RC 
must be done atomically, so the optimizer can't optimize.

[Issue 15272] [2.069-rc2,inline] nothing written to output when -inline is set

[via Digitalmars-d-bugs]

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

--- Comment #8 from bb.t...@gmx.com ---
(In reply to ag0aep6g from comment #7)
> Here's a reduction that segfaults reliably for me with -release -O -inline:
> 
> extern(C) void* calloc(size_t, size_t) nothrow pure;
> 
> void main()
> {
> {
> File file_;
> nop();
> }
> 
> auto scache = StringCache(1);
> foreach (nodePointer; scache.buckets)
> {
> if (nodePointer !is null) new Object;
> }
> }
> 
> struct File
> {
> ~this() {}
> }
> 
> void nop() {}
> 
> struct StringCache
> {
> this(size_t bucketCount)
> {
> buckets = (cast(void**) calloc(8, bucketCount))[0 .. bucketCount];
> }
> 
> void*[] buckets;
> }
> 

Yes that's it. Thx much for your patience.

--

[Issue 15272] [2.069-rc2,inline] nothing written to output when -inline is set

[via Digitalmars-d-bugs]

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

bb.t...@gmx.com changed:

   What|Removed |Added

   Severity|normal  |regression

--

Re: Safe reference counting cannot be implemented as a library

[rsw0x via Digitalmars-d]

On Sunday, 1 November 2015 at 22:36:46 UTC, Andrei Alexandrescu 
wrote:

On 11/01/2015 03:51 PM, Martin Nowak wrote:

On 10/27/2015 01:27 PM, Andrei Alexandrescu wrote:
Unrelated, and a foreshadowing of the discussion on the 
lifetime mailing
list: the compiler has ample opportunity to fuse incs/decs 
together, so

the signatures of these functions is:

void opInc(uint delta);
void opDec(uint delta);


Any hint/numbers showing that this is actually useful?


Would be great to collect some, and generally get rigorous 
about the whole approach.


Implementing such a cross statement optimization is quite some 
work. If
this occurs often enough (in particular for shared classes 
with atomic

ref counting) it might be worth the effort.


Most reference counting techniques revolve around reducing 
mutation of the reference count. See e.g. 
https://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2012.pdf.


So we need to show that many refcount updates take it from 1 to 
larger than 1 and back. According to 
https://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2012.pdf, many objects have a reference count of just one; the "eclipse" benchmark has 31.8% objects with a refcount greater than 1.



Andrei


That paper is assuming that you take Java(a language that does 
*not* have allocation patterns like D such as favoring data on 
the stack, tightly packed arrays of data, and immutability) rip 
out its GC, and replace it with a RC-based GC with no concept of 
unique ownership - no?

Re: good reasons not to use D?

[Freddy via Digitalmars-d-learn]

On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote:

I'm writing a talk for codemesh on the use of D in finance.

I want to start by addressing the good reasons not to use D.  
(We all know what the bad ones are).  I don't want to get into 
a discussion here on them, but just wanted to make sure I cover 
them so I represent the state of affairs correctly.


So far what comes to mind: heavy GUI stuff (so far user 
interface code is not what it could be); cases where you want 
to write quick one-off scripts that need to use a bunch of 
different libraries not yet available in D and where it doesn't 
make sense to wrap or port them; where you have a lot of code 
in another language (especially non C, non Python) and defining 
an interface is not so easy; where you have many inexperienced 
programmers and they need to be productive very quickly.


Any other thoughts?


I would advise against using D in applications where memory is 
essential. Idiomatic D uses a garbage collector which has a non 
free runtime cost.

[Issue 15272] [2.069-rc2,inline] nothing written to output when -inline is set

[via Digitalmars-d-bugs]

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

--- Comment #4 from ag0ae...@gmail.com ---
I think this is a bug in libdparse.

Its `StringCache` allocates space for `buckets`, but doesn't null the pointers.
On destruction it then tries to `free` the garbage pointers in there.

https://github.com/Hackerpilot/libdparse/blob/8230f207912b40a46e5eae84e50ee59215b7c67f/src/dparse/lexer.d#L2009

Could you try adding `buckets[] = null;` after that line, then rebuild
libdparse, and see if your project still crashes?

--

[Issue 15272] [2.069-rc2,inline] nothing written to output when -inline is set

[via Digitalmars-d-bugs]

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

--- Comment #5 from ag0ae...@gmail.com ---
(In reply to ag0aep6g from comment #4)
> I think this is a bug in libdparse.
> 
> Its `StringCache` allocates space for `buckets`, but doesn't null the
> pointers. On destruction it then tries to `free` the garbage pointers in
> there.

Forget that. It's using calloc, not malloc, so it should be all zeros already.

--

Re: Safe reference counting cannot be implemented as a library

[rsw0x via Digitalmars-d]

On Sunday, 1 November 2015 at 20:55:00 UTC, Martin Nowak wrote:

On 11/01/2015 09:51 PM, Martin Nowak wrote:

Any hint/numbers showing that this is actually useful?


Also doesn't a good backend optimizer already fuse writes?


AFAIK the fear of RC being too slow comes from C++'s shared_ptr's 
reference count being required to be synchronized by the C++ 
spec, which heavily limits what kinds of optimizations that can 
be done on it. Thread-local by default RC should, in theory, be 
able to be optimized much much more aggressively.

[Issue 15272] [2.069-rc2,inline] nothing written to output when -inline is set

[via Digitalmars-d-bugs]

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

--- Comment #7 from ag0ae...@gmail.com ---
Here's a reduction that segfaults reliably for me with -release -O -inline:

extern(C) void* calloc(size_t, size_t) nothrow pure;

void main()
{
{
File file_;
nop();
}

auto scache = StringCache(1);
foreach (nodePointer; scache.buckets)
{
if (nodePointer !is null) new Object;
}
}

struct File
{
~this() {}
}

void nop() {}

struct StringCache
{
this(size_t bucketCount)
{
buckets = (cast(void**) calloc(8, bucketCount))[0 .. bucketCount];
}

void*[] buckets;
}


(In reply to bb.temp from comment #6)
> Yes. I confirm that the fix you suggested in libdparse works.
> 
> But now I don't know whom the bug belongs to...
> Was it accidental that the program worked without -inline and without the
> libdparse fix ?!

I was mistaken. The bug I saw in libdparse is not there. My "fix" probably just
masks the issue somehow.

--

ACCU: Self Publishing a Technical Book / Ask an expert about D; November 11, 2015

[Ali Çehreli via Digitalmars-d-announce]

I will be giving a talk at the Silicon Valley ACCU:

  http://www.meetup.com/SFBay-Association-of-C-C-Users/events/225125586/

(I did not write that title nor the synopsis, which may have been 
updated by the time you read this.)


Although I am confident about the self publishing part, I am sure there 
will be D questions that I am not expert enough. So, please make an 
effort to show up and support me. :)


Thank you,
Ali

Re: Safe reference counting cannot be implemented as a library

[Andrei Alexandrescu via Digitalmars-d]

On 11/1/15 5:52 PM, rsw0x wrote:

On Sunday, 1 November 2015 at 22:36:46 UTC, Andrei Alexandrescu wrote:

On 11/01/2015 03:51 PM, Martin Nowak wrote:

On 10/27/2015 01:27 PM, Andrei Alexandrescu wrote:

Unrelated, and a foreshadowing of the discussion on the lifetime
mailing
list: the compiler has ample opportunity to fuse incs/decs together, so
the signatures of these functions is:

void opInc(uint delta);
void opDec(uint delta);


Any hint/numbers showing that this is actually useful?


Would be great to collect some, and generally get rigorous about the
whole approach.


Implementing such a cross statement optimization is quite some work. If
this occurs often enough (in particular for shared classes with atomic
ref counting) it might be worth the effort.


Most reference counting techniques revolve around reducing mutation of
the reference count. See e.g.
https://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2012.pdf.

So we need to show that many refcount updates take it from 1 to larger
than 1 and back. According to
https://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2012.pdf,
many objects have a reference count of just one; the "eclipse"
benchmark has 31.8% objects with a refcount greater than 1.


Andrei


That paper is assuming that you take Java(a language that does *not*
have allocation patterns like D such as favoring data on the stack,
tightly packed arrays of data, and immutability) rip out its GC, and
replace it with a RC-based GC with no concept of unique ownership - no?


The class objects we're focusing on for RC support are supposed to be 
used much like in Java. -- Andrei

Re: DConf 2016, Berlin: Call for Submissions is now open!

[Iain Buclaw via Digitalmars-d-announce]

On 1 November 2015 at 03:41, Andrei Alexandrescu via Digitalmars-d-announce
 wrote:

> On 10/31/15 5:24 PM, Jonas Drewsen wrote:
>
>> On Sunday, 25 October 2015 at 23:59:16 UTC, Andrei Alexandrescu wrote:
>>
>>> On 10/25/15 8:04 AM, ponce wrote:
>>>
 On Friday, 23 October 2015 at 16:37:20 UTC, Andrei Alexandrescu wrote:

>
> http://dconf.org/2016/index.html
>

 Do you need a new logo this year? I would be happy to make another,
 better one.

>>>
>>> Yes please! Forgot to mention that. Many thanks!! -- Andrei
>>>
>>
>> I gave it a shot:
>>
>> https://dl.dropboxusercontent.com/u/188292/g4421.png
>>
>> /Jonas
>>
>
> Many thanks to both you and ponce! This is great work.
>
> I have good news and bad news. The bad news is we won't likely be able to
> accept either of these proposals.
>
> The good news is Sociomantic wants to get behind the DConf logo design,
> more generally behind the dconf.org site design, and even more generally
> get more involved in helping the Foundation and the language. It will take
> their design team a bit longer to get things done, but they want to do it
> right.
>
>
Does the design team know this yet?  :-)

Iain.

[Issue 15272] [2.069-rc2,inline] nothing written to output when -inline is set

[via Digitalmars-d-bugs]

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

--- Comment #3 from bb.t...@gmx.com ---
(In reply to ag0aep6g from comment #2)
> (In reply to bb.temp from comment #0)
> > So far I'm here but it doesn't capture the essence of the problem.
> > 
> > ---
> [...]
> > ---
> 
> As far as I can tell, everything works as expected in that code.
> 
> The different `children` arrays are GC allocated (via ~=), but the `Foo`s
> themselves are not. So a parent `Foo` doesn't keep its `children` alive, and
> at some point the GC collects the seemingly dead arrays.

Take care with the small sample. I've written that <>, it was just an attempt. So far it just helped to show that it's
necessary to add the ranges to the GC, which I've done to the real program.

Despite of this in the real program it's still the same, if I call
'write(slb.serialize)':

- with '-inline': stdout is empty.
- without: stdout is filled

When you consider those two facts it really looks that the inliner does
something wrong.

--

[Issue 15272] [2.069-rc2,inline] nothing written to output when -inline is set

[via Digitalmars-d-bugs]

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

--- Comment #6 from bb.t...@gmx.com ---
(In reply to ag0aep6g from comment #4)
> I think this is a bug in libdparse.
> 
> Its `StringCache` allocates space for `buckets`, but doesn't null the
> pointers. On destruction it then tries to `free` the garbage pointers in
> there.
> 
> https://github.com/Hackerpilot/libdparse/blob/
> 8230f207912b40a46e5eae84e50ee59215b7c67f/src/dparse/lexer.d#L2009
> 
> Could you try adding `buckets[] = null;` after that line, then rebuild
> libdparse, and see if your project still crashes?

Yes. I confirm that the fix you suggested in libdparse works.

But now I don't know whom the bug belongs to...
Was it accidental that the program worked without -inline and without the
libdparse fix ?!

--

Re: Safe reference counting cannot be implemented as a library

[Martin Nowak via Digitalmars-d]

On 10/27/2015 12:41 PM, Andrei Alexandrescu wrote:
> It follows that if we want safe reference counting, there must be
> language support for it. One possibility is to attach an attribute to
> the class definition:
> 
> @safe @rc class Widget {
>   ...
> }

Let's think about this more clearly before we bake a monolithic feature
for a single problem into the language.

A few thoughts:

- @rc and @noescape are orthogonal

  while @rc requires @noescape the latter could
  be useful for other purposes

- If the compiler knows a reference has a limited lifetime
  it could check for @noescape making most of RC implementable
  in a library.

  struct RC
  {
Object get() return; // lifetime of Object is bound to RC, compiler
could check any function called on Object for @noescape
  }

- I'm not a fan of adding yet another attribute but as inference support
  is currently limited it seems we'd need an explicit attribute for
  public APIs.

Re: Safe reference counting cannot be implemented as a library

[Martin Nowak via Digitalmars-d]

On 10/27/2015 01:27 PM, Andrei Alexandrescu wrote:
> Unrelated, and a foreshadowing of the discussion on the lifetime mailing
> list: the compiler has ample opportunity to fuse incs/decs together, so
> the signatures of these functions is:
> 
> void opInc(uint delta);
> void opDec(uint delta);

Any hint/numbers showing that this is actually useful?
Implementing such a cross statement optimization is quite some work. If
this occurs often enough (in particular for shared classes with atomic
ref counting) it might be worth the effort.

Re: DConf 2016, Berlin: Call for Submissions is now open!

[Andrej Mitrovic via Digitalmars-d-announce]

On 11/1/15, Dicebot via Digitalmars-d-announce
 wrote:
> Yes :)

Are they going to design some kick-ass T-shirts to go along with it too? :)

Re: Safe reference counting cannot be implemented as a library

[Martin Nowak via Digitalmars-d]

On 11/01/2015 09:51 PM, Martin Nowak wrote:
> Any hint/numbers showing that this is actually useful?

Also doesn't a good backend optimizer already fuse writes?

Re: Safe reference counting cannot be implemented as a library

[Andrei Alexandrescu via Digitalmars-d]

On 11/01/2015 03:54 PM, Martin Nowak wrote:

On 11/01/2015 09:51 PM, Martin Nowak wrote:

Any hint/numbers showing that this is actually useful?


Also doesn't a good backend optimizer already fuse writes?


My understanding is that no, that won't happen in most patterns that 
matter. -- Andrei

Re: Safe reference counting cannot be implemented as a library

[Andrei Alexandrescu via Digitalmars-d]

On 11/01/2015 03:51 PM, Martin Nowak wrote:

On 10/27/2015 01:27 PM, Andrei Alexandrescu wrote:

Unrelated, and a foreshadowing of the discussion on the lifetime mailing
list: the compiler has ample opportunity to fuse incs/decs together, so
the signatures of these functions is:

void opInc(uint delta);
void opDec(uint delta);


Any hint/numbers showing that this is actually useful?


Would be great to collect some, and generally get rigorous about the 
whole approach.



Implementing such a cross statement optimization is quite some work. If
this occurs often enough (in particular for shared classes with atomic
ref counting) it might be worth the effort.


Most reference counting techniques revolve around reducing mutation of 
the reference count. See e.g. 
https://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2012.pdf.


So we need to show that many refcount updates take it from 1 to larger 
than 1 and back. According to 
https://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2012.pdf, 
many objects have a reference count of just one; the "eclipse" benchmark 
has 31.8% objects with a refcount greater than 1.



Andrei

Capturing __FILE__ and __LINE in a variadic templated function

[Nordlöw via Digitalmars-d-learn]

Is it possible to make the following definition

void show(alias T, string file = __FILE__, uint line = __LINE__, 
string fun = __FUNCTION__)()

{
import std.stdio: writeln;
try { debug writeln(file, ":",line, ":" /* , ": in ",fun */, 
" debug: ", T.stringof, ":", T); }

catch (Exception) { }
}

used as

unittest
{
int x = 11;
int y = 12;
int z = 13;
show!x;
show!y;
show!z;
}

variadic so that it, instead, can be called as

unittest
{
int x = 11;
int y = 12;
int z = 13;
show!(x,y,z);
}

and still capture current file, line and function?

Re: Capturing __FILE__ and __LINE in a variadic templated function

[Adam D. Ruppe via Digitalmars-d-learn]

Yeah, just make the other args normal runtime instead of template:

void show(T...)(string file = __FILE__, uint line = __LINE__, 
string fun = __FUNCTION__) {

  // same body
}

// same usage

Re: Allocation strategies question

[Jeffery via Digitalmars-d-learn]

On Sunday, 1 November 2015 at 09:48:20 UTC, ref2401 wrote:
On Friday, 30 October 2015 at 05:21:17 UTC, Rikki Cattermole 
wrote:

What I normally do for memory to be owned by the thread is:

auto foo(IAllocator alloc=theAllocator()) {...}

Where as for if it is global to the process:

auto foo(IAllocator alloc=processAllocator()) {...}

Basically it is the difference between a screenshot of a 
display and a window instance.


What do other think?


Create a "repository" of allocators. The "programmers" query the 
allocators for their "best fit", but because it is a repository, 
they are easier to deal with than hard coding.


E.g.,

auto allocator = 
GetAllocator(allocatorsRepository.processAllocator);


GetAllocator would get the actual allocator using the arg as a 
"hint".


One could, hypothetically, make this as complex as one would 
want. e.g., passing the file name as an argument(hidden) which 
can then be used as a constraint on the allocator allocation(pun 
;). e.g., you can have file specific optimization techniques by 
altering the allocation strategy per file(or better yet, per 
line).


Since all that can be done retroactively, it alleviates some of 
the problems with the programmers interfacing directly with 
std.experimental.allocator. They have to go through your 
interface first which gives you some control.


You could then print special debug messages sort of like -vgc but 
instead, for allocation strategies. The sky's the limit! Have fun 
with it!