dataframe implementations

[Jay Norwood via Digitalmars-d-learn]

I was reading about the Julia dataframe implementation yesterday, 
trying to understand their decisions and how D might implement.


From my notes,
1. they are currently using a dictionary of column vectors.
2. for NA (not available) they are currently using an array of 
bytes, effectively as a Boolean flag, rather than a bitVector, 
for performance reasons.

3. they are not currently implementing hierarchical headers.
4. they are transforming non-valid symbol header strings (read 
from csv, for example) to valid symbols by replacing '.' with 
underscore and prefixing numbers with 'x', as examples.  This 
allows use in expressions.
5. Along with 4., they currently have @with for DataVector, to 
allow expressions to use, for example, :symbol_name instead of 
dv[:symbol_name].
6. They have operation symbols for per element operations on two 
vectors, for example a ./ b expresses applying the operation to 
the vector.

7. They currently only have row indexes,  no row names or symbols.

I saw someone posting that they were working on DataFrame 
implementation here, but haven't been able to locate any code in 
github, and was wondering what implementation decisions are being 
made here.  Thanks.

Re: Second CT-Parameter of isRange Predicates

[Nordlöw via Digitalmars-d]

On Monday, 2 November 2015 at 14:33:44 UTC, Andrei Alexandrescu 
wrote:

https://github.com/D-Programming-Language/phobos/pull/3786


Sent an ICBM its way. -- Andrei


Why not extend existing traits with a second `E`-parameter 
instead of adding a new one?

Re: Second CT-Parameter of isRange Predicates

[Nordlöw via Digitalmars-d]

On Monday, 2 November 2015 at 14:43:00 UTC, Nordlöw wrote:
On Monday, 2 November 2015 at 14:33:44 UTC, Andrei Alexandrescu 
wrote:

https://github.com/D-Programming-Language/phobos/pull/3786


Sent an ICBM its way. -- Andrei


Why not extend existing traits with a second `E`-parameter 
instead of adding a new one?


I think it's very well worth it in terms of expressability.

Re: Second CT-Parameter of isRange Predicates

[Atila Neves via Digitalmars-d]

On Monday, 2 November 2015 at 14:33:44 UTC, Andrei Alexandrescu 
wrote:

https://github.com/D-Programming-Language/phobos/pull/3786


Sent an ICBM its way. -- Andrei


I agree with the ICBM that it definitely doesn't scale. But... 
there should be an easier way to replace arrays of Widget with a 
range. If not, most people (including me on lazy days) will just 
write `Widget[]` and be done with it. I don't know what the best 
solution is.


I'm saying this as someone who's written plenty of D code that 
takes arrays as arguments not because it's right, but because it 
was a lot easier and I didn't want it getting in the way of 
whatever it is I was trying to accomplish.. 90% of my usage of 
`std.array.array` is depressingly enough at the end of an 
algorithm UFCS chain because either I'm passing this to a 
function expecting `T[]` or to a struct that stores `T[]`. It's 
not pretty, performant, or right, but it's easy and I'm lazy.


And that's for writing code. With regards to reading, it's been 
pointed out multiple times that beginners will struggle with 
template contraints on function signatures. It'll be the case 
much more often if every function and struct wanting a range of 
Ts is suddenly `if(isInputRange!R && is(ElementType!R == T))`.


Atila

Re: Second CT-Parameter of isRange Predicates

[Andrei Alexandrescu via Digitalmars-d]

https://github.com/D-Programming-Language/phobos/pull/3786


Sent an ICBM its way. -- Andrei

[Issue 4350] (mixin) mixed in template identifier is not accessible by "with" statement

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull, rejects-valid
   Hardware|Other   |All
 OS|Windows |All

--- Comment #2 from Kenji Hara  ---
https://github.com/D-Programming-Language/dmd/pull/5252

--

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

[Dmitry via Digitalmars-d-announce]

On Sunday, 1 November 2015 at 09:50:16 UTC, Joakim wrote:
 Please report your results in this thread in the ldc forum, 
which requires no registration, with the info and format 
requested there:

Samsung Galaxy Tab 2, all tests passed

Re: DIP 84: Static Inheritance

[Atila Neves via Digitalmars-d]

On Saturday, 31 October 2015 at 09:49:59 UTC, Walter Bright wrote:

On 10/31/2015 2:21 AM, Atila Neves wrote:

Interesting. Like this perhaps?

struct Struct : isInputRange ->

static assert(__traits(compilesNoSupress, 
isInputRange!Struct));

struct Struct
//...


Yes. And I think it would have much wider applicability than 
just struct inheritance.


True. Should I change the DIP?

Atila

Second CT-Parameter of isRange Predicates

[Nordlöw via Digitalmars-d]

Is there a reason why

isOutputRange(R,E)

takes a second argument `E` but not other range predicates

isInputRange(R)
isForwardRange(R)
...

?

If so, I still think it would very be nice to have a second 
argument `E` for all the other `isXRange` traits to simplify, for 
instance,


if (isInputRange!R && is(int == ElementType!R))

to simpler

if (isInputRange!(R, int))

or even

if (isInputRange!R && is(isSomeChar!(ElementType!R)))

to simpler

if (isInputRange!(R, isSomeChar))

?

What do think?

I'm planning to add a PR for this and simplify Phobos in all 
places where this pattern is used.

Re: dataframe implementations

[Laeeth Isharc via Digitalmars-d-learn]

On Monday, 2 November 2015 at 13:54:09 UTC, Jay Norwood wrote:
I was reading about the Julia dataframe implementation 
yesterday, trying to understand their decisions and how D might 
implement.


From my notes,
1. they are currently using a dictionary of column vectors.
2. for NA (not available) they are currently using an array of 
bytes, effectively as a Boolean flag, rather than a bitVector, 
for performance reasons.

3. they are not currently implementing hierarchical headers.
4. they are transforming non-valid symbol header strings (read 
from csv, for example) to valid symbols by replacing '.' with 
underscore and prefixing numbers with 'x', as examples.  This 
allows use in expressions.
5. Along with 4., they currently have @with for DataVector, to 
allow expressions to use, for example, :symbol_name instead of 
dv[:symbol_name].
6. They have operation symbols for per element operations on 
two vectors, for example a ./ b expresses applying the 
operation to the vector.
7. They currently only have row indexes,  no row names or 
symbols.


I saw someone posting that they were working on DataFrame 
implementation here, but haven't been able to locate any code 
in github, and was wondering what implementation decisions are 
being made here.  Thanks.


Hi Jay.

That may have been me.  I have implemented something very basic, 
but you can read and write my proto dataframe to/from CSV and 
HDF5.  The code is up here:


https://github.com/Laeeth/d_dataframes

You should think of it as a crude prototype that nonetheless has 
been useful for me, but it's done more in the old school hacker 
spirit of getting something working first rather than being 
designed properly.  The reason for that is I have a lot on my 
plate at the moment, and technology is only one of many of these, 
although an important one.  In time I may get someone else to 
work on dataframes and opensource the results, but that may be 
some months away.


So I'd welcome any assistance, or even taking it over.  I haven't 
really done a good job of having idiomatic access, but it's 
something and a start.



Laeeth.


I

Re: I have this game engine...

[Jacob Carlborg via Digitalmars-d]

On 2015-11-02 09:47, Manu via Digitalmars-d wrote:


It'll probably get through 95% of the files... actually, I use enum
aswell, is that supported?


Yes. You can get a rough idea of what's supported by looking in the 
"test_files" directory.


--
/Jacob Carlborg

Re: Access violation when calling C DLL from D

[Nicholas Wilson via Digitalmars-d-learn]

On Monday, 2 November 2015 at 01:02:45 UTC, AnoHito wrote:
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 D the unary * is left associative NOT right. i.e. write int* 
a,b,c; // a,b and c are all int* NOT  int*, int,int as would be 
the case in C
because you are not allowed to change the type during the 
declaration.


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')"));


string literals are automatically null terminated, no need to 
`toStringz`. if it was not a literal the you would have to.



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

But the result was:

object.Error@(0): Access Violation



(0) suggests a null pointer

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.
and the only operation here likely to call strlen is to!string 
from a char* (since D strings know their length)


perhaps you should inspect the value returned from 
mrb_string_value_cstr


few possible places to look
alignment - are the types declared in c declared with an 
alignment?

check the values of mob and result

Also take a Look at DStep on github for auto translation of C

Re: Second CT-Parameter of isRange Predicates

[Andrei Alexandrescu via Digitalmars-d]

On 11/02/2015 09:43 AM, Nordlöw wrote:

On Monday, 2 November 2015 at 14:43:00 UTC, Nordlöw wrote:

On Monday, 2 November 2015 at 14:33:44 UTC, Andrei Alexandrescu wrote:

https://github.com/D-Programming-Language/phobos/pull/3786


Sent an ICBM its way. -- Andrei


Why not extend existing traits with a second `E`-parameter instead of
adding a new one?


I think it's very well worth it in terms of expressability.


I'd say it's a minor convenience. Anyhow, integrating tests this way 
depends on how we go about reporting "no match" errors. In the constraint


isForwardRange!R && is(ElementType!R == int)

the compiler could report exactly: "isForwardRange!Widget failed" or 
"is(ElementType!Widget == int) failed". If tests are combined, the 
compiler will only be able to say "isForwardRange!(Widget, int) failed".



Andrei

Re: I have this game engine...

[Johannes Pfau via Digitalmars-d]

Am Mon, 2 Nov 2015 14:22:33 +1000
schrieb Manu via Digitalmars-d :

> On 2 November 2015 at 04:17, Johannes Pfau via Digitalmars-d
>  wrote:
> > 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?

The usual stuff: AA handling, array concatenation etc. It's not a
problem as long as you don't use these. But to build a druntime without
the GC we'd have to find all these cases and place them in a
version(GCAvailable) block. If we build the GC stub or the GC we don't
have this problem.

Then there's some Exception handling related stuff: IIRC the backtrace
data is allocated using the GC and I think core.demangle uses the GC
as well. Probably not a big issue. 

Some higher level stuff such as Threads and Fibers also have special GC
integration. And then there are probably some 'toString' methods every
so often.

> 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.
> 

Maybe I'm a little to pessimistic about the GC ;-) I'm just not sure if
it can deal with low-memory situations such as if you've only got 16MB
memory total. And IIRC the GC always preallocates some blocks. So even
if we never use the GC it might steal some memory. OTOH it would
likely be not much work to adjust this allocation size.

> 
> > 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?

These toolchains would be built like all other toolchains on
gdcproject.org/downloads and would also be listed on that page. 

We currently do not have a CI setup for all these toolchains. Building
the windows variant of a toolchain can take up to an hour (on my i5
notebook). Building all combinations for every commit on CI would be
very costly.

I hope to integrate all linux hosted toolchains with Travis-CI
(as a bonus we can probably extract nightly builds). It's a bit of a
PITA as building requires quite some disk space (10GB+ required,
semaphoreCI offers only 5GB). And I have to avoid these stupid
10 minute command timeout on travis-ci.

Let's see if this works:
https://travis-ci.org/jpf91/GDC/builds/88839377
(seems to be quite slow though...)

OTOH even if we manage to integrate CI this tests only that the code
builds. I don't think runtime testing is possible in some easy way.

> 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: Access violation when calling C DLL from D

[AnoHito via Digitalmars-d-learn]

On Monday, 2 November 2015 at 15:56:20 UTC, Atila Neves wrote:

Try this instead:

https://github.com/jacob-carlborg/dstep

It's been used to convert C Ruby declarations to D:

https://github.com/jacob-carlborg/orbit/tree/master/ruby

Atila


I might try it later, but I don't think the header conversion is 
the problem in this case. I tried to get some insight into what 
was happening by modifying the mrb_load_nstring function:


MRB_API mrb_value
mrb_load_nstring(mrb_state *mrb, const char *s, int len)
{
  FILE *f = fopen("output.txt", "w");
  fprintf(f, "mrb: %p, s: %p, len: %i\n", mrb, s, len);
  fclose(f);
  return mrb_load_nstring_cxt(mrb, s, len, NULL);
}

The output was:

mrb: 0052E818, s: 000E, len: 5

That was... odd. I tried to modify my extern statement a bit:

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


And ran the following code:

mrb = mrb_open();
mrb_value result =  mrb_load_nstring(cast(void *) 0, mrb, 
toStringz("String('test')"), 14);

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

This time the result was:

mrb: 0039E750, s: 0052E818, len: 14

Things actually got a little further now that the values were 
getting passed correctly(?) but another null pointer access 
violation got triggered later on in the code.


So something weird is definitely going on here. Is there 
something that needs to be done differently to handle the calling 
conventions here? I think all the functions in MRuby that I have 
attempted to call so far are regular cdecl functions.


Here is the definitions of MRB_API from the original header, in 
case it sheds any light on things:


#if defined(MRB_BUILD_AS_DLL)
#if defined(MRB_CORE) || defined(MRB_LIB)
# define MRB_API __declspec(dllexport)
#else
# define MRB_API __declspec(dllimport)
#endif
#else
# define MRB_API extern
#endif

Could the problem be because I used mingw to build the DLL, and 
Visual D to build my main project? It was more or less necessary, 
since Visual Studio's build tools couldn't handle the MRuby build 
scripts. I didn't think it should cause any problems, but maybe I 
was wrong.


Also, here is the command I used to generate the lib for the DLL:

implib /s mruby.lib mruby.dll

Is implib still the best tool for doing this? The only version I 
was able to find was very old, so maybe it is not generating the 
lib files correctly.

Re: I have this game engine...

[Johannes Pfau via Digitalmars-d]

Am Mon, 2 Nov 2015 14:24:18 +1000
schrieb 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.

And if dstep doesn't work maybe the DDMD magicport tool could be useful.

try.dlang.org

[Pradeep Gowda via Digitalmars-d]

One of the best ways to get new programmers a flavour of the 
language is a playground.


Examples:

- Kotlin - http://try.kotlinlang.org/
- Haskell - https://tryhaskell.org/
- Ceylon - http://try.ceylon-lang.org/# (JVM lang by RedHat)
- Go - on the homepage
- Ruby - http://tryruby.org/
- Rust - https://play.rust-lang.org/


I know there is a D playground, but I can't remember the URL for 
the life of me.


Is it possible to host  or create a CNAME for the current 
playground at http://try.dlang.org or http://play.dlang.org/ ?


It is small things like this that can help newbies "discover" a 
language and goes a long way in adopting the language.

[Issue 15275] New: Documentation for OutputRange lacking

[via Digitalmars-d-bugs]

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

  Issue ID: 15275
   Summary: Documentation for OutputRange lacking
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: landergriffith+dlan...@gmail.com

As a newcomer to D, I wanted to write a library with an output stream that
std.stream.OutputStream would have been a good candidate for but in the docs
saw that the stream module is deprecated. I went in to IRC to ask what the
replacement is and was told to use ranges -- specifically an OutputRange.

On the documentation page for std.range
(http://dlang.org/phobos/std_range.html) I searched for OutputRange and the
*only* results are in the context of NullSink and tee. The tee part of the
documentation actually hyperlinks OutputRange, so clicking that I'd expect it
to take me somewhere that I can read more info about the OutputRange but it
goes nowhere (link in question:
http://dlang.org/phobos/std_range.html#OutputRange).

>From the top of the page:

> Ranges generalize the concept of arrays, lists, or anything that involves 
> sequential access. This abstraction enables the same set of algorithms (see 
> std.algorithm) to be used with a vast variety of different concrete types. 
> For example, a linear search algorithm such as std.algorithm.find works not 
> just for arrays, but for linked-lists, input files, incoming network data, 
> etc.

The last part of that mainly involves *input* data, not output data. Some of
the methods described involve mutating or combining the arrays but I'm somewhat
surprised the "put" method is not mentioned at least once on the page. Even
referring to the source was more helpful than the docs
(https://github.com/D-Programming-Language/phobos/blob/master/std/range/interfaces.d#L235
-- I was told in IRC that this isn't entirely accurate as I want the template
method but it helped some).

I think that the documentation page for std.range is seriously lacking info
about using an OutputRange and in general that streams are two-directional.
Perhaps a documentation improvement could also be made to the std.stream module
to describe the move to ranges instead as well.

--

[Issue 15275] Documentation for OutputRange lacking

[via Digitalmars-d-bugs]

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

landaire  changed:

   What|Removed |Added

URL||http://dlang.org/phobos/std
   ||_range.html

--

Re: Capturing __FILE__ and __LINE in a variadic templated function

[Nordlöw via Digitalmars-d-learn]

On Tuesday, 3 November 2015 at 06:14:14 UTC, Jonathan M Davis 
wrote:
You should pretty much never use __FILE__ or __LINE__ as 
template arguments unless you actually need to. The reason is 
that it will end up creating a new instantiation of the 
template pretty much every time that it's used, which is going 
to be mean a _lot_ of extra code bloat if you use the template 
much. And in some, rare circumstances that may be exactly what 
you want. But it almost never is.


- Jonathan M Davis


Ahh, thanks.

Re: I have this game engine...

[Johannes Pfau via Digitalmars-d]

Am Tue, 3 Nov 2015 09:16:47 +1000
schrieb Manu via Digitalmars-d :

> I have a samples directory which it would be theoretically possible to
> run and see that they don't crash as part of a test run. Also, I'd
> like to annotate my whole engine quite comprehensively with unittests.
> It's something that I'm keen to work on, and then it further helps to
> assure those toolchains remain working.

But how exactly would you run these? All CI machines are x86_64. I
guess emulators could be a possibility as long as they run headless.
We'd need some way to get feedback from the emulator though (test
passed/failed). If you're talking about running tests on the x86_64
architecture that should be easy.

[Issue 15278] Compile-time segfault when compiling code with alias this

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull
   Hardware|x86_64  |All
 OS|Linux   |All
   Severity|normal  |major

--- Comment #2 from Kenji Hara  ---
https://github.com/D-Programming-Language/dmd/pull/5256

--

Re: Capturing __FILE__ and __LINE in a variadic templated function

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, November 02, 2015 00:36:14 anonymous via Digitalmars-d-learn wrote:
> 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__)()
>  {
>  ...
>  }
> }

You should pretty much never use __FILE__ or __LINE__ as template arguments
unless you actually need to. The reason is that it will end up creating a
new instantiation of the template pretty much every time that it's used,
which is going to be mean a _lot_ of extra code bloat if you use the
template much. And in some, rare circumstances that may be exactly what you
want. But it almost never is.

- Jonathan M Davis

Re: Efficiency of immutable vs mutable

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, November 03, 2015 03:16:06 Andrew via Digitalmars-d-learn wrote:
> I've written a short D program that involves many lookups into a
> static array. When I make the array immutable the program runs
> faster.  This must mean that immutable is more than a restriction
> on access, it must affect the compiler output. But why and how?

If a variable is immutable, then the compiler knows that it will never
change, and at least some of the time, the compiler is able to use that
information to better optimize the code. But exactly how much the compiler
is able to optimize based on immutable is going to be very dependent on the
code in question and on how the compiler's optimizer works.

- Jonathan M Davis

[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

Walter Bright  changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Linux   |All

--

[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 #15 from Walter Bright  ---
BTW, this is a critical bug.

--

Re: Capturing __FILE__ and __LINE in a variadic templated function

[Nordlöw via Digitalmars-d-learn]

On Tuesday, 3 November 2015 at 06:14:14 UTC, Jonathan M Davis 
wrote:
You should pretty much never use __FILE__ or __LINE__ as 
template arguments unless you actually need to. The reason is 
that it will end up creating a new instantiation of the 
template pretty much every time that it's used, which is going 
to be mean a _lot_ of extra code bloat if you use the template 
much. And in some, rare circumstances that may be exactly what 
you want. But it almost never is.


- Jonathan M Davis


So why is this pattern is used all over std.experimental.logger?

Re: try.dlang.org

[deadalnix via Digitalmars-d]

On Monday, 2 November 2015 at 18:44:19 UTC, Pradeep Gowda wrote:
One of the best ways to get new programmers a flavour of the 
language is a playground.


Examples:

- Kotlin - http://try.kotlinlang.org/
- Haskell - https://tryhaskell.org/
- Ceylon - http://try.ceylon-lang.org/# (JVM lang by RedHat)
- Go - on the homepage
- Ruby - http://tryruby.org/
- Rust - https://play.rust-lang.org/


I know there is a D playground, but I can't remember the URL 
for the life of me.


Is it possible to host  or create a CNAME for the current 
playground at http://try.dlang.org or http://play.dlang.org/ ?


It is small things like this that can help newbies "discover" a 
language and goes a long way in adopting the language.


Seems like the place to resurrect drepl :)

[Issue 14282] executeShell should use sh and ignore the SHELL env variable

[via Digitalmars-d-bugs]

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

Mark Isaacson  changed:

   What|Removed |Added

 CC||marki...@umich.edu

--- Comment #9 from Mark Isaacson  ---
We really should have a means of specifying what shell we'd like to use at the
call site. The fix for this issue ended up breaking some of my code without
providing a nice path back to correctness (I'll write a fix up in a sec, it's
just going to be more work than I expected).

Put in an enhancement request along these lines:
https://issues.dlang.org/show_bug.cgi?id=15276

--

Re: Lazy std.algorithm.replace()

[Nordlöw via Digitalmars-d-learn]

On Monday, 2 November 2015 at 20:25:44 UTC, Adam D. Ruppe wrote:

On Sunday, 1 November 2015 at 14:26:21 UTC, Nordlöw wrote:
Is there a reason why Phobos doesn't contain a lazy range 
variant of std.string.replace?


Would something like map work with the predicate being 
if(matches_needle) return replacement; else return original; ?


I'm already using `map` in the simple overloads (Range haystack, 
ElementType needle) mentioned in my previous post.

Re: Lazy std.algorithm.replace()

[Ali Çehreli via Digitalmars-d-learn]

On 11/02/2015 04:22 AM, Nordlöw wrote:

On Sunday, 1 November 2015 at 14:26:21 UTC, Nordlöw wrote:

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


Ping.


What is the use case?

The implementation doesn't seem trivial to me as it needs to maintain an 
internal buffer as large as the 'to' argument to do the mutation in.


Ali

[Issue 15276] New: Allow specification of shell for spawnShell/executeShell/pipeShell

[via Digitalmars-d-bugs]

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

  Issue ID: 15276
   Summary: Allow specification of shell for
spawnShell/executeShell/pipeShell
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: marki...@umich.edu

We should allow callers to specify a particular shell to be used, be it sh,
bash, zsh, or what the user has in their SHELL environment variable.

One of the things that made the fix for
https://issues.dlang.org/show_bug.cgi?id=14282 so jarring is that there's no
easy way to work around it to achieve the old behavior. That fix ended up being
reverted.

--

Re: try.dlang.org

[Andrei Alexandrescu via Digitalmars-d]

On 11/02/2015 02:02 PM, deadalnix wrote:

Seems like the place to resurrect drepl :)


s/resurrect/bring to the front burner/

Last time Martin and I talked about it it was definitely on his radar to 
scale it up for delivery, but understandably he has a bunch more urgent 
things to tend to. -- Andrei

Re: Lazy std.algorithm.replace()

[Nordlöw via Digitalmars-d-learn]

On Monday, 2 November 2015 at 19:53:09 UTC, Ali Çehreli wrote:

On 11/02/2015 04:22 AM, Nordlöw wrote:

On Sunday, 1 November 2015 at 14:26:21 UTC, Nordlöw wrote:
Is there a reason why Phobos doesn't contain a lazy range 
variant of

std.string.replace?


Ping.


What is the use case?


Chaining replacement with other filterings. I need in my 
knowledge database (graph) i building...which a *lot* of string 
processing.


The implementation doesn't seem trivial to me as it needs to 
maintain an internal buffer as large as the 'to' argument to do 
the mutation in.


Ali


I'm aware of that.

I'm done with the easy cases at

https://github.com/nordlow/justd/blob/master/algorithm_ex.d#L1946

and

https://github.com/nordlow/justd/blob/master/algorithm_ex.d#L1997

I'm planning to implement the most generic version where 
`haystack` and keys are both ranges by reusing  std.algorithm : 
find`. Do you have any more advice on that overload?

Re: Lazy std.algorithm.replace()

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

On Sunday, 1 November 2015 at 14:26:21 UTC, Nordlöw wrote:
Is there a reason why Phobos doesn't contain a lazy range 
variant of std.string.replace?


Would something like map work with the predicate being 
if(matches_needle) return replacement; else return original; ?

[Issue 12021] VS2012-2013 .vcxproj files don't show in the solution explorer

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |---

--- Comment #5 from Rainer Schuetze  ---
Arrgh! I'm getting this with Visual D 0.3.43-beta1 and VS2015.

--

[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

safety0ff.bugz  changed:

   What|Removed |Added

 CC||safety0ff.b...@gmail.com

--- Comment #13 from safety0ff.bugz  ---
(In reply to Martin Nowak from comment #12)
> I diggered and found https://github.com/D-Programming-Language/dmd/pull/4909
> to be the culprit.

FWIW, the following patch fixes it for me:

--- a/src/backend/cgelem.c
+++ b/src/backend/cgelem.c
@@ -3545,8 +3545,8 @@ STATIC elem * eleq(elem *e, goal_t goal)
 {
 e->E2 = e2->E1;
 eb = el_bin(OPeq,ty,eb,e2->E2);
-e2->E1 = eb;
-e2->E2 = e;
+e2->E1 = e;
+e2->E2 = eb;
 }
 else
 {

--

Re: Unionize range types

[Jakob Ovrum via Digitalmars-d-learn]

On Tuesday, 3 November 2015 at 01:55:27 UTC, Freddy wrote:

Is there any way I can Unionize range Types?
---
auto primeFactors(T)(T t, T div = 2)
{
if (t % div == 0)
{
return t.only.chain(primeFactors(t / div, div));
}
if (div > t)
{
return [];
}
else
{
return primeFactors(t, div + 1);
}
}

---


http://dlang.org/phobos/std_range#choose

Re: how to make the commented out lines work when they are uncommented

[Ali Çehreli via Digitalmars-d-learn]

On 11/02/2015 08:43 PM, steven kladitis wrote:
> import std.stdio, std.algorithm, std.array, std.traits,std.range,
> std.typecons,std.complex;
>
> enum AreSortableArrayItems(T) = isMutable!T &&
>  __traits(compiles, T.init < T.init) &&
>  !isNarrowString!(T[]);
>
> void selectionSort(T)(T[] data) if (AreSortableArrayItems!T) {
>  foreach (immutable i, ref d; data)
>  data.drop(i).minPos[0].swap(d);
> }

> //char[] a4 = ['a', 'b'];
> //a4.selectionSort;

That doesn't compile because selectionSort() requires !isNarrowString 
but char[] is a narrow string. If you are fine with sorting those bytes, 
then try ubyte[] as the type. Otherwise, sorting chars is dubious 
because char is a Unicode code unit, potentially a part of a Unicode 
character.


> //auto a7 = [complex(1.0,0.0), complex(2.0,0.0)];
> //a7.selectionSort;

That fails because there is no default ordering between complex numbers. 
(Ditto for a8.) (I haven't looked at the implementation of 'complex' but 
I remember from Math that that doesn't make sense anyway.)


Ali

Having some issues using Generator's yield with an interface

[Ben via Digitalmars-d-learn]

When I create a generator using an interface (or abstract class) 
I must cast the concrete instance to the interface. Why does the 
Generator not know that B is a implementation of the interface of 
A?


/// Test Code
interface A {}
class B : A{}

// Fails
auto testGen1 = new Generator!A({
yield (new B());
});

// Succeeds
auto testGen2 = new Generator!A({
yield ( cast(A) new B());
});

Re: I have this game engine...

[Jacob Carlborg via Digitalmars-d]

On 2015-11-02 05:24, Manu via Digitalmars-d wrote:


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.


DStep currently only supports C code, not almost C code :).

--
/Jacob Carlborg

Re: #ifdef hell

[Joakim via Digitalmars-d]

On Thursday, 29 October 2015 at 23:55:14 UTC, Jonathan M Davis 
wrote:
The idea is that you get rid of all of the & and ||ing that 
tends to make #ifdefs really hard to follow and error-prone. 
And by having each version fully separate, changing one version 
won't break another.


Now, that comes at the cost of forcing you to duplicate a lot 
of code, which almost everyone other than Walter thinks is 
worse than the risks associated with merging similar versions 
together, but as far as I can tell, Walter is completely 
consistent in his arguments.


I agree that his position is consistent, but I disagree that it 
implies duplicating all your code.  He suggests one possibility 
in that thread where you can keep code common to OS X and iOS in 
a single version(Darwin) block, but explicitly stick a 
"version(OSX) version = Darwin; version(iOS) version = Darwin;" 
at the top of each druntime file that does so.  While that may 
look like a pimple at the top of each file, it has the virtue 
that it explicitly, locally documents exactly where this new 
version is coming from.


Note that that's only for druntime and phobos: users are always 
free to define Darwin for themselves in their build scripts if 
they want.


The alternative in current compilers like gcc is this mess, as he 
notes on that PR:


shell# gcc -dM -E - < /dev/null
#define __DBL_MIN_EXP__ (-1021)
#define __pentiumpro__ 1
#define __UINT_LEAST16_MAX__ 0x
#define __ATOMIC_ACQUIRE 2
#define __FLT_MIN__ 1.17549435082228750797e-38F
#define __GCC_IEC_559_COMPLEX 2
#define __UINT_LEAST8_TYPE__ unsigned char
#define __SIZEOF_FLOAT80__ 12
#define __INTMAX_C(c) c ## LL
#define __CHAR_BIT__ 8
#define __UINT8_MAX__ 0xff
#define __WINT_MAX__ 0xU
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __SIZE_MAX__ 0xU
#define __WCHAR_MAX__ 0x7fffL
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
#define __DBL_DENORM_MIN__ ((double)4.94065645841246544177e-324L)
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
#define __GCC_ATOMIC_CHAR_LOCK_FREE 2
#define __GCC_IEC_559 2
#define __FLT_EVAL_METHOD__ 2
#define __unix__ 1
#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
#define __UINT_FAST64_MAX__ 0xULL
#define __SIG_ATOMIC_TYPE__ int
#define __DBL_MIN_10_EXP__ (-307)
#define __FINITE_MATH_ONLY__ 0
#define __GNUC_PATCHLEVEL__ 0
#define __UINT_FAST8_MAX__ 0xff
#define __has_include(STR) __has_include__(STR)
#define __DEC64_MAX_EXP__ 385
#define __INT8_C(c) c
#define __UINT_LEAST64_MAX__ 0xULL
#define __SHRT_MAX__ 0x7fff
#define __LDBL_MAX__ 1.18973149535723176502e+4932L
#define __UINT_LEAST8_MAX__ 0xff
#define __GCC_ATOMIC_BOOL_LOCK_FREE 2
#define __UINTMAX_TYPE__ long long unsigned int
#define __linux 1
#define __DEC32_EPSILON__ 1E-6DF
#define __unix 1
#define __UINT32_MAX__ 0xU
#define __LDBL_MAX_EXP__ 16384
#define __WINT_MIN__ 0U
#define __linux__ 1
#define __SCHAR_MAX__ 0x7f
#define __WCHAR_MIN__ (-__WCHAR_MAX__ - 1)
#define __INT64_C(c) c ## LL
#define __DBL_DIG__ 15
#define __GCC_ATOMIC_POINTER_LOCK_FREE 2
#define __SIZEOF_INT__ 4
#define __SIZEOF_POINTER__ 4
#define __USER_LABEL_PREFIX__
#define __STDC_HOSTED__ 1
#define __LDBL_HAS_INFINITY__ 1
#define __FLT_EPSILON__ 1.1920928955078125e-7F
#define __LDBL_MIN__ 3.36210314311209350626e-4932L
#define __STDC_UTF_16__ 1
#define __DEC32_MAX__ 9.99E96DF
#define __INT32_MAX__ 0x7fff
#define __SIZEOF_LONG__ 4
#define __STDC_IEC_559__ 1
#define __STDC_ISO_10646__ 201304L
#define __UINT16_C(c) c
#define __DECIMAL_DIG__ 21
#define __gnu_linux__ 1
#define __has_include_next(STR) __has_include_next__(STR)
#define __LDBL_HAS_QUIET_NAN__ 1
#define __GNUC__ 5
#define __FLT_HAS_DENORM__ 1
#define __SIZEOF_LONG_DOUBLE__ 12
#define __BIGGEST_ALIGNMENT__ 16
#define __i686 1
#define __DBL_MAX__ ((double)1.79769313486231570815e+308L)
#define __INT_FAST32_MAX__ 0x7fff
#define __DBL_HAS_INFINITY__ 1
#define __DEC32_MIN_EXP__ (-94)
#define __INT_FAST16_TYPE__ int
#define __LDBL_HAS_DENORM__ 1
#define __DEC128_MAX__ 9.9E6144DL
#define __INT_LEAST32_MAX__ 0x7fff
#define __DEC32_MIN__ 1E-95DF
#define __DBL_MAX_EXP__ 1024
#define __DEC128_EPSILON__ 1E-33DL
#define __ATOMIC_HLE_RELEASE 131072
#define __PTRDIFF_MAX__ 0x7fff
#define __STDC_NO_THREADS__ 1
#define __ATOMIC_HLE_ACQUIRE 65536
#define __LONG_LONG_MAX__ 0x7fffLL
#define __SIZEOF_SIZE_T__ 4
#define __SIZEOF_WINT_T__ 4
#define __GCC_HAVE_DWARF2_CFI_ASM 1
#define __GXX_ABI_VERSION 1009
#define __FLT_MIN_EXP__ (-125)
#define __i686__ 1
#define __INT_FAST64_TYPE__ long long int
#define __DBL_MIN__ ((double)2.22507385850720138309e-308L)
#define __DECIMAL_BID_FORMAT__ 1
#define __DEC128_MIN__ 1E-6143DL
#define __REGISTER_PREFIX__
#define __UINT16_MAX__ 0x
#define __DBL_HAS_DENORM__ 1
#define __UINT8_TYPE__ unsigned char
#define __NO_INLINE__ 1
#define __i386 1
#define __FLT_MANT_DIG__ 

Re: Capturing __FILE__ and __LINE in a variadic templated function

[Nordlöw via Digitalmars-d-learn]

On Sunday, 1 November 2015 at 23:36:15 UTC, anonymous wrote:

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__)()
{
...
}
}


Doesn't work.

I need `T` to be an alias in order for .stringof to work.

How do I specify a variadic template argument alias list of 
aliases?

Re: #ifdef hell

[Daniel Murphy via Digitalmars-d]

On 31/10/2015 12:01 AM, Jacob Carlborg wrote:

On 2015-10-30 03:01, Walter Bright wrote:


I might add that over time, I'd been removing #if's and #ifdef's from
the dmd front end source code. The results were very satisfactory - the
code was easier to read, understand and maintain. It also made running
magicport on the code practical.


The DMD source code contained #ifdef's inside expressions, which is
quite a difference compared to "or" and "and" in "static if".



Yes, this was the major problem with converting the #ifdefs, not 
conditions ||ed together.  If D allowed oring versions together then 
version would have been a lot more useful in DDMD.

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

[Russel Winder via Digitalmars-d-announce]

On Sun, 2015-11-01 at 21:55 +0100, Andrej Mitrovic via Digitalmars-d-
announce wrote:
> 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? :)

If they do, and they are long-body t-shirts, is there any chance of
people buying them who will not be able to be at the conference?

-- 
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

Re: Access violation when calling C DLL from D

[Atila Neves via Digitalmars-d-learn]

On Monday, 2 November 2015 at 02:30:09 UTC, AnoHito wrote:

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...


Try this instead:

https://github.com/jacob-carlborg/dstep

It's been used to convert C Ruby declarations to D:

https://github.com/jacob-carlborg/orbit/tree/master/ruby

Atila

[Issue 15274] New: typeid(this) inside of an interface contract segfaults

[via Digitalmars-d-bugs]

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

  Issue ID: 15274
   Summary: typeid(this) inside of an interface contract segfaults
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: initrd...@gmail.com

Example code:

interface MyFace {
Object bar()
out(v) {
assert(typeid(this));
}
}

class MyClass : MyFace {
override Object bar() {
return new MyClass();
}
}

void main() {
(new MyClass()).bar();
}

This code causes a segfault when ran. Removing the `assert(typeid(this))` line
causes the error to go away. Putting the out contract on the class also does
not cause an error.

GDB output:

(gdb) bt
#0  0x0041f3d9 in invariant._d_invariant() ()
#1  0x0041dbd4 in test.MyFace.bar() (this=0x7fffdca8, 
v=@0x7fffdca0: 0x77ed0020) at ./test.d:5
#2  0x0041dc45 in test.MyClass.bar() (this=0x77ed)
at ./test.d:10
#3  0x0041dc80 in D main () at ./test.d:16
#4  0x0041f35f in rt.dmain2._d_run_main() ()
#5  0x0041f2ba in rt.dmain2._d_run_main() ()
#6  0x0041f31b in rt.dmain2._d_run_main() ()
#7  0x0041f2ba in rt.dmain2._d_run_main() ()
#8  0x0041f23a in _d_run_main ()
#9  0x0041dd28 in main ()

Version:

> dmd --version
DMD64 D Compiler v2.068.2
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright

--

Re: good reasons not to use D?

[Laeeth Isharc via Digitalmars-d-learn]

On Saturday, 31 October 2015 at 16:06:47 UTC, Russel Winder wrote:
On Sat, 2015-10-31 at 15:41 +, tcak via Digitalmars-d-learn 
wrote:

On Saturday, 31 October 2015 at 14:37:23 UTC, rumbu wrote:
> 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.
> > 
> > Any other thoughts?
> 
> For finance stuff - missing a floating point decimal data 
> type. Things like 1.1 + 2.2 = 3.3003


I always thought that this type of arithmetic operations can 
be solved with BigInt, but never tried it. Since the issue is 
related to IEEE standard, a simulated (not supported by 
hardware directly) data type might be required.


In that std.bigint.BigInt provides the accuracy, yes it does 
suffice. But it is slow. As far as I am aware only IBM Big Iron 
(aka mainframes, aka z-Series) has hardware decimal floating 
point these days. (Even though 1970s and 1980s microprocessors 
had the feature.)


It would be nice to have fixed point numbers in Phobos, although 
it's not much work to implement, and there is a library solution 
already (which is maintained, but sometimes for a while breaks 
with newer versions of dmd).

Re: good reasons not to use D?

[Laeeth Isharc via Digitalmars-d-learn]

On Sunday, 1 November 2015 at 09:07:56 UTC, Ilya Yaroshenko wrote:

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


Thanks, Ilya.  An important but subtle point.  Funnily enough, I 
haven't done so much specifically heavily numerical work so far, 
but trust that in the medium term the dlangscience project by 
John Colvin and others will bear fruit.


What would you suggest is a better option to address the concerns 
you raised?

Re: Easy and efficient database usage

[BLM768 via Digitalmars-d]

On Friday, 23 October 2015 at 12:42:08 UTC, w0rp wrote:


Does anyone have any thoughts on this topic?


A couple of years ago, I started playing with the idea. The basic 
concept was to dump DB records into "dumb" (i.e. representing 
just the basic aspects of the model object) structs, which can be 
stack-allocated to minimize GC usage. It's very far from complete 
and has been dormant for a while, but someone might be able to 
make use of some of the code. It would probably need to be 
rewritten to use a "standard" DB driver framework, though; right 
now, it's just got its own abstraction layer over SQLite.

Re: good reasons not to use D?

[Laeeth Isharc via Digitalmars-d-learn]

On Sunday, 1 November 2015 at 20:38:44 UTC, Freddy wrote:

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.


Idiomatic D doesn't need to use the GC, and may generate much 
less garbage anyway.  Andrei's allocator is pretty easy to use, 
and EMSI containers on top make it even easier.  And those aren't 
the only options.

Re: good reasons not to use D?

[Laeeth Isharc via Digitalmars-d-learn]

On Saturday, 31 October 2015 at 05:25:06 UTC, ref2401 wrote:

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'd suggest enterprise software because many necessary 
libraries and tools do not exist in D ecosystem. Though you've 
already named these reasons.


Thank you very much to every one who has replied on this thread, 
and my apologies for not engaging - just haven't had time.  But I 
have read them all and it will help me clarify what I say.


Incidentally, there is enterprise and enterprise.  What's 
necessary really depends on what you're trying to do.  For me, so 
far, I don't see the lack of libraries as a major problem.  How 
much work really is it to port some bindings?  Not much in 
relation to the larger goal.  I've done that myself for many of 
them I wanted so far, because I wanted to get to know the tools I 
was working with and you can't delegate learning.  In coming 
months others will be helping me, which will allow me to spend a 
bit more time and energy on the investment aspect and the bigger 
picture.


That's not only been my perspective, but also that of other 
financial adopters of languages perceived as niche - for example, 
Jane Street with ocaml.


A benefit of the D community that also resonates with what Yaron 
Minsky at Jane Street says about ocaml is that there are some 
very good programmers here (and the less experienced ones learn 
from the more experienced ones, and the reason that's possible is 
the very thing that turns off more corporate sorts of people - 
it's a small community so people have more time and energy to 
spend).  You couldn't buy for any price what people I have talked 
to have learnt by becoming language contributors...



Laeeth.

[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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #12 from Martin Nowak  ---
I diggered and found https://github.com/D-Programming-Language/dmd/pull/4909 to
be the culprit.

--

Re: Release Candidate D 2.069.0-rc2

[deadalnix via Digitalmars-d-announce]

On Friday, 30 October 2015 at 20:44:35 UTC, deadalnix wrote:

On Friday, 30 October 2015 at 18:11:08 UTC, Martin Nowak wrote:

Second release candidate for the 2.069.0.

http://dlang.org/download.html#dmd_beta 
http://dlang.org/changelog/2.069.0.html


A list of fixes over 2.069.0-rc1 can be found here. 
https://github.com/D-Programming-Language/dlang.org/commit/78fb5704def71c63cd70b474f86a5aea2b85b372


Please report any bugs at https://issues.dlang.org

-Martin


Download seems to be broken. It just hangs forever right now.


Ok, it is back and so far so good.

Re: dataframe implementations

[Jay Norwood via Digitalmars-d-learn]

On Monday, 2 November 2015 at 15:33:34 UTC, Laeeth Isharc wrote:

Hi Jay.

That may have been me.  I have implemented something very 
basic, but you can read and write my proto dataframe to/from 
CSV and HDF5.  The code is up here:


https://github.com/Laeeth/d_dataframes



yes, thanks.  I believe I did see your comments previously.
That's great that you've already got support for hdf5. I'll take 
a look.

[Issue 15277] unable to compile .d flies with numbers at the beginning of the name

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ag0ae...@gmail.com
 Resolution|--- |INVALID

--- Comment #1 from ag0ae...@gmail.com ---
As far as I can see, everything works as expected here.

dmd doesn't mind "1.d" as a file name.

What's rejected is "1" as a module name. The module name is taken from the file
name when there is no module declaration (`module foo;`). Module names are
specified to be identifiers [1]. Identifiers are specified not to start with
digits [2].

Closing as invalid. Please reopen if I'm missing something here.

[1] http://dlang.org/module.html#ModuleName
[2] http://dlang.org/lex.html#IdentifierStart

--

[Issue 15254] is expression compares string sub-type equal to an array

[via Digitalmars-d-bugs]

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

steven kladitis  changed:

   What|Removed |Added

   Keywords||ice
 CC||steven_kladi...@yahoo.com

--- Comment #1 from steven kladitis  ---
1.d
--
void main() {}

--
try to compile in widows and I get.
--> 1.d: Error: module 1 has non-identifier characters in filename, use module
declaration instead

a1.d
-
void main() {}


no errors during compile.
dmd 2.069.rc2

--

[Issue 15277] New: unable to compile .d flies with numbers at the beginning of the name

[via Digitalmars-d-bugs]

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

  Issue ID: 15277
   Summary: unable to compile .d flies with numbers at the
beginning of the name
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: steven_kladi...@yahoo.com

any .d file with a number in the beginning of the name will not compile with
dmd.

filename -> 1.d
or   -> 1a1aa1.d
-
void main () {}


if I rename with a leading letter dmd seems to like it.
I see
1.d: Error: module 1 has non-identifier characters in filename, use module
declaration instead.


this is dmd 2.069 rc2
I am looking to see if imports have this problem also.

--

Re: I have this game engine...

[Kagamin via Digitalmars-d]

On Sunday, 1 November 2015 at 17:07:17 UTC, Joseph Rushton 
Wakeling wrote:
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 ...


For D1 there was DDL 
http://www.dsource.org/projects/ddl/wiki/AboutDDL that could load 
and relocate object files as dynamic libraries.

Re: Capturing __FILE__ and __LINE in a variadic templated function

[Nordlöw via Digitalmars-d-learn]

On Monday, 2 November 2015 at 09:02:28 UTC, Gary Willoughby wrote:

On Monday, 2 November 2015 at 08:23:16 UTC, Nordlöw wrote:

I need `T` to be an alias in order for .stringof to work.


typeof(T).stringof


No, I want the variable name from the calling scope.

This works for a single argument.

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

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

}
catch (Exception) { }
}

unittest
{
int x = 11;
show!x;
}

Prints

dbg.d:80: debug: x is 11

My try at variadic

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

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

foreach (const i, Arg; Args)
{
if (i) debug write(", "); // separator
debug write(Arg.stringof, " is ", Arg);
}
debug writeln();
}
catch (Exception) { }
}
}

fails with compilation error

dbg.d(83,5): Error: variable x cannot be read at compile time

Why can't I make Args a sequence of aliases?

Re: Capturing __FILE__ and __LINE in a variadic templated function

[John Colvin via Digitalmars-d-learn]

On Monday, 2 November 2015 at 09:16:09 UTC, Nordlöw wrote:
On Monday, 2 November 2015 at 09:02:28 UTC, Gary Willoughby 
wrote:

On Monday, 2 November 2015 at 08:23:16 UTC, Nordlöw wrote:

I need `T` to be an alias in order for .stringof to work.


typeof(T).stringof


No, I want the variable name from the calling scope.

This works for a single argument.

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

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

}
catch (Exception) { }
}

unittest
{
int x = 11;
show!x;
}

Prints

dbg.d:80: debug: x is 11

My try at variadic

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

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

foreach (const i, Arg; Args)
{
if (i) debug write(", "); // separator
debug write(Arg.stringof, " is ", Arg);
}
debug writeln();
}
catch (Exception) { }
}
}

fails with compilation error

dbg.d(83,5): Error: variable x cannot be read at compile time

Why can't I make Args a sequence of aliases?


Works for me on multiple compilers. To be precise, this worked:

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

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

foreach (const i, Arg; Args)
{
if (i) debug write(", "); // separator
debug write(Arg.stringof, " is ", Arg);
}
debug writeln();
}
catch (Exception) { }
}
}

unittest
{
int x = 11;
show!x;
}

Compiling DOtherSide

[karabuta via Digitalmars-d-learn]

Well, I use Ubuntu 14.04 and I have managed to get qt5.5 at my 
/opt/qt55 since the default(usr/lib) directory is occupied by 
qt4. Since DOtherSide looks for qt5 from usr/lib, how do I change 
it to now point to /opt/qt55?



This is the setup in /opt/qt55

karabuta@mx:/opt/qt55$ ls
bin   icudtl.dat  lib  phrasebooks  
qtwebengine_resources.pak

doc   imports libexec  plugins  share
examples  include mkspecs  qml  translations


and DOtherSide is at /home/DOtherSide

karabuta@mx:~/DOtherSide$ ls
build  CHANGELOG.md  CMakeLists.txt  LICENSE  README.md  src  test

Re: Release Candidate D 2.069.0-rc2

[Andrea Fontana via Digitalmars-d-announce]

On Friday, 30 October 2015 at 18:11:08 UTC, Martin Nowak wrote:

Second release candidate for the 2.069.0.

http://dlang.org/download.html#dmd_beta 
http://dlang.org/changelog/2.069.0.html


A list of fixes over 2.069.0-rc1 can be found here. 
https://github.com/D-Programming-Language/dlang.org/commit/78fb5704def71c63cd70b474f86a5aea2b85b372


Please report any bugs at https://issues.dlang.org

-Martin


Now it works for me.

Re: Capturing __FILE__ and __LINE in a variadic templated function

[Daniel N via Digitalmars-d-learn]

On Monday, 2 November 2015 at 09:54:50 UTC, John Colvin wrote:

Why can't I make Args a sequence of aliases?


Works for me on multiple compilers. To be precise, this worked:



Except it prints Arg instead of x, try:
debug write(Args[i].stringof, " is ", Arg);

Re: I have this game engine...

[Manu via Digitalmars-d]

On 2 November 2015 at 17:55, Jacob Carlborg via Digitalmars-d
 wrote:
> On 2015-11-02 05:24, Manu via Digitalmars-d wrote:
>
>> 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.
>
>
> DStep currently only supports C code, not almost C code :).

It'll probably get through 95% of the files... actually, I use enum
aswell, is that supported?

Re: Capturing __FILE__ and __LINE in a variadic templated function

[Gary Willoughby via Digitalmars-d-learn]

On Monday, 2 November 2015 at 08:23:16 UTC, Nordlöw wrote:

I need `T` to be an alias in order for .stringof to work.


typeof(T).stringof

[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

Marc Schütz  changed:

   What|Removed |Added

 CC||schue...@gmx.net

--- Comment #9 from Marc Schütz  ---
Digger blames this PR for me:
https://github.com/D-Programming-Language/dmd/pull/5060

... but this looks very unlikely to be the culprit.

--

Re: Safe reference counting cannot be implemented as a library

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 1 November 2015 at 22:04:51 UTC, deadalnix wrote:

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.


Yes, ARC does the atomic RC too, but ARC is bound by prior focus 
on manual RC without compiler support and should not be used as 
an example to be followed.


D could go for a more generic solution with specialized 
restricted integer types for resource tracking with different 
capabilites. Same amount of work, but much more versatile.


The library could then use templated RCPointers with the 
capabilites as parameters which recast the resource tracking 
integer to the desired type which injects the appropriate 
assumptions to the optimizer before/after each operation on the 
integer.


E.g. for the non-transfer-to-other-threads/fiber integer counter 
type:


1. the optimizer needs to know that below a specific 
block/stackframe the test "counter==0" always fails.


2. semantics that ensures that  contexts (fiber/thread) only are 
allowed to subtract a value they already have added. Easy way out 
is RAII.

[Issue 15279] dchar is treated as char in case range

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
I don't think this is an issue with dchar/char. The same happens with int:


void main() {
int d;

switch (d) {
case 0: .. case 0x0101:
break;
}
}


Looks like more than 256 cases are not supported.

--

Re: DIP 84: Static Inheritance

[Walter Bright via Digitalmars-d]

On 11/2/2015 5:58 AM, Atila Neves wrote:

On Saturday, 31 October 2015 at 09:49:59 UTC, Walter Bright wrote:

Yes. And I think it would have much wider applicability than just struct
inheritance.


True. Should I change the DIP?


I think that's a good idea.

Re: generate with state

[Ali Çehreli via Digitalmars-d-learn]

On 11/02/2015 03:56 PM, Freddy wrote:

Is there a version of http://dlang.org/phobos/std_range.html#.generate
with state.


generate() already allows "callables", which can be a delegate:

import std.stdio;
import std.range;

struct S {
int i;

int fun() {
return i++;
}
}

void main() {
auto s = S(42);
writefln("%(%s %)", generate().take(5));
}

Prints

42 43 44 45 46

Shorter but more cryptic:

  ... generate((42).fun).take(5)

If the generation process is naturally recursive like traversing a tree, 
then you may want to consider std.concurrency.Generator (which does not 
involve multiple threads at all):


  http://dlang.org/phobos/std_concurrency.html#.Generator

Here is an example:


http://ddili.org/ders/d.en/fibers.html#ix_fibers.Generator,%20std.concurrency

import std.stdio;
import std.range;
import std.concurrency;

/* This alias is used for resolving the name conflict with
 * std.range.Generator. */
alias FiberRange = std.concurrency.Generator;

void fibonacciSeries() {
int current = 0;
int next = 1;

while (true) {
yield(current);

const nextNext = current + next;
current = next;
next = nextNext;
}
}

void main() {
auto series = new FiberRange!int();
writefln("%(%s %)", series.take(10));
}

Ali

[Issue 15278] Compile-time segfault when compiling code with alias this

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||ice
 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
Reduced:

interface IAllocator {}

struct List
{
IAllocator allocator;
List unqualifiedCopy() const;
alias unqualifiedCopy this;
}


--

Re: I have this game engine...

[Manu via Digitalmars-d]

On 3 November 2015 at 04:38, Johannes Pfau via Digitalmars-d
 wrote:
> Am Mon, 2 Nov 2015 14:22:33 +1000
> schrieb Manu via Digitalmars-d :
>
> Maybe I'm a little to pessimistic about the GC ;-) I'm just not sure if
> it can deal with low-memory situations such as if you've only got 16MB
> memory total. And IIRC the GC always preallocates some blocks. So even
> if we never use the GC it might steal some memory. OTOH it would
> likely be not much work to adjust this allocation size.

Perhaps the pre-allocation could become an API which the user might
prefer not to call?


> Let's see if this works:
> https://travis-ci.org/jpf91/GDC/builds/88839377
> (seems to be quite slow though...)
>
> OTOH even if we manage to integrate CI this tests only that the code
> builds. I don't think runtime testing is possible in some easy way.

I have a samples directory which it would be theoretically possible to
run and see that they don't crash as part of a test run. Also, I'd
like to annotate my whole engine quite comprehensively with unittests.
It's something that I'm keen to work on, and then it further helps to
assure those toolchains remain working.

[Issue 15279] New: dchar is treated as char in case range

[via Digitalmars-d-bugs]

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

  Issue ID: 15279
   Summary: dchar is treated as char in case range
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: acehr...@yahoo.com

void main() {
dchar d;

switch (d) {
case '\u': .. case '\u0101':
break;
}
}

Error: had 257 cases which is more than 256 cases in case range

Same problem with wchar...

Ali

--

[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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #14 from Walter Bright  ---
(In reply to safety0ff.bugz from comment #13)
> FWIW, the following patch fixes it for me:
> 
> --- a/src/backend/cgelem.c
> +++ b/src/backend/cgelem.c
> @@ -3545,8 +3545,8 @@ STATIC elem * eleq(elem *e, goal_t goal)
>  {
>  e->E2 = e2->E1;
>  eb = el_bin(OPeq,ty,eb,e2->E2);
> -e2->E1 = eb;
> -e2->E2 = e;
> +e2->E1 = e;
> +e2->E2 = eb;
>  }
>  else
>  {

https://github.com/D-Programming-Language/dmd/pull/5253

--

generate with state

[Freddy via Digitalmars-d-learn]

Is there a version of 
http://dlang.org/phobos/std_range.html#.generate with state.

[Issue 15278] Compile-time segfault when compiling code with alias this

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

   Severity|enhancement |normal

--

[Issue 15278] New: Compile-time segfault when compiling code with alias this

[via Digitalmars-d-bugs]

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

  Issue ID: 15278
   Summary: Compile-time segfault when compiling code with alias
this
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: and...@erdani.com

dmd v2.069-devel-5db650f segfaults while compiling this code with -unittest:

module persistent_list;
import std.experimental.allocator;

struct List(T)
{
private IAllocator allocator;
private List!T unqualifiedCopy() const;
alias unqualifiedCopy this;
}

void main()
{
List!(immutable int) lst;
}

--

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

[Walter Bright via Digitalmars-d-announce]

On 11/1/2015 8:51 PM, Joakim wrote:

Hmm, taking place at Symantec's cafeteria, maybe you can mention that D is still
using their backend in the reference dmd compiler, might cheer them after their
recent security issues. ;)


Maybe someday they'll let me Boost license it :-)

Re: Capturing __FILE__ and __LINE in a variadic templated function

[Nordlöw via Digitalmars-d-learn]

On Monday, 2 November 2015 at 09:54:50 UTC, John Colvin wrote:

Works for me on multiple compilers. To be precise, this worked:

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

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

foreach (const i, Arg; Args)
{
if (i) debug write(", "); // separator
debug write(Arg.stringof, " is ", Arg);
}
debug writeln();
}
catch (Exception) { }
}
}

unittest
{
int x = 11;
show!x;
}


No. This prints:

Arg is 11

I want it to print the name of Arg in the closing as

x is 11

equivalent to what my single-parameter overload

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

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

}
catch (Exception) { }
}

does.

Re: Capturing __FILE__ and __LINE in a variadic templated function

[Nordlöw via Digitalmars-d-learn]

On Monday, 2 November 2015 at 11:44:45 UTC, Daniel N wrote:

On Monday, 2 November 2015 at 11:36:27 UTC, Nordlöw wrote:

I want it to print the name of Arg in the closing as

x is 11


See my previous comment:
Arg -> Args[i].stringof


Ahh! Great! Thx!

[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 #10 from ag0ae...@gmail.com ---
(In reply to ag0aep6g from comment #7)
> Here's a reduction that segfaults reliably for me with -release -O -inline:
> 
[...]
> 

Reduced a little further, showing that bucketCount gets corrupted:

import core.stdc.stdio: printf;

pragma(inline, false) void[] calloc_(size_t bc) nothrow pure
{
debug printf("%x\n", bc); /* prints "", should print "1" */
return [];
}

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

auto scache = StringCache(1);
}

struct File
{
~this() {}
}

void nop() {}

struct StringCache
{
this(size_t bucketCount)
{
buckets = calloc_(bucketCount)[0 .. bucketCount];
printf("");
}

void[] buckets;
}


--

Re: Capturing __FILE__ and __LINE in a variadic templated function

[Daniel N via Digitalmars-d-learn]

On Monday, 2 November 2015 at 11:36:27 UTC, Nordlöw wrote:

I want it to print the name of Arg in the closing as

x is 11


See my previous comment:
Arg -> Args[i].stringof

Re: generate with state

[Freddy via Digitalmars-d-learn]

On Tuesday, 3 November 2015 at 00:08:54 UTC, Ali Çehreli wrote:

generate() already allows "callables", which can be a delegate:

import std.stdio;
import std.range;

struct S {
int i;

int fun() {
return i++;
}
}

void main() {
auto s = S(42);
writefln("%(%s %)", generate().take(5));
}

Prints

42 43 44 45 46


Will that allocate gc memory? Is there any why I pass state as a 
tuple and have my generator modify state as It's called?

Re: I have this game engine...

[mattcoder via Digitalmars-d]

On Sunday, 1 November 2015 at 02:36:16 UTC, Manu wrote:

...
Does it support Dreamcast? :P


I don't know if you are being serious here but if yes... what's 
the catch with Dreamcast? I mean this is a Fan thing or what?


PS: I'm asking this because I used to code for GBA a long time 
ago but just for fun and hobby!


Matheus.

Re: Access violation when calling C DLL from D

[AnoHito via Digitalmars-d-learn]

Okay, I finally got it working. The problem was that mrb_value 
needed to be fully defined in order for my code to work, because 
it was being passed on the stack directly instead of by a pointer:


struct mrb_value
{
union
{
mrb_float f;
void* p;
mrb_int i;
mrb_sym sym;
}
mrb_vtype tt;
}

Re: Second CT-Parameter of isRange Predicates

[Sebastiaan Koppe via Digitalmars-d]

On Monday, 2 November 2015 at 14:43:00 UTC, Nordlöw wrote:
Why not extend existing traits with a second `E`-parameter 
instead of adding a new one?


What will E be when you only care whether R is an InputRange and 
not about its ElementType?

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

[Dmitry via Digitalmars-d-announce]

On Monday, 2 November 2015 at 13:41:32 UTC, Dmitry wrote:

Samsung Galaxy Tab 2, all tests passed

(Android 4.2.2)

Re: Second CT-Parameter of isRange Predicates

[Atila Neves via Digitalmars-d]

On Monday, 2 November 2015 at 14:16:53 UTC, Nordlöw wrote:

Is there a reason why

isOutputRange(R,E)

takes a second argument `E` but not other range predicates

isInputRange(R)
isForwardRange(R)
...

?

If so, I still think it would very be nice to have a second 
argument `E` for all the other `isXRange` traits to simplify, 
for instance,


if (isInputRange!R && is(int == ElementType!R))

to simpler

if (isInputRange!(R, int))

or even

if (isInputRange!R && is(isSomeChar!(ElementType!R)))

to simpler

if (isInputRange!(R, isSomeChar))

?

What do think?

I'm planning to add a PR for this and simplify Phobos in all 
places where this pattern is used.


https://github.com/D-Programming-Language/phobos/pull/3786

Atila

Re: Second CT-Parameter of isRange Predicates

[Alex Parrill via Digitalmars-d]

On Monday, 2 November 2015 at 14:16:53 UTC, Nordlöw wrote:

Is there a reason why

isOutputRange(R,E)

takes a second argument `E` but not other range predicates

isInputRange(R)
isForwardRange(R)
...

?

If so, I still think it would very be nice to have a second 
argument `E` for all the other `isXRange` traits to simplify, 
for instance,


if (isInputRange!R && is(int == ElementType!R))

to simpler

if (isInputRange!(R, int))

or even

if (isInputRange!R && is(isSomeChar!(ElementType!R)))

to simpler

if (isInputRange!(R, isSomeChar))

?

What do think?

I'm planning to add a PR for this and simplify Phobos in all 
places where this pattern is used.


I think it's because output ranges can accept more than one type 
of value. That said, the `isInputRange!(R,E)` shortcut for 
`isInputRange!R && is(int == ElementType!R)` would be nice.

Re: Efficiency of immutable vs mutable

[TheFlyingFiddle via Digitalmars-d-learn]

On Tuesday, 3 November 2015 at 03:16:07 UTC, Andrew wrote:
I've written a short D program that involves many lookups into 
a static array. When I make the array immutable the program 
runs faster.  This must mean that immutable is more than a 
restriction on access, it must affect the compiler output. But 
why and how?


Thanks
Andrew


I'm going to speculate a bit here since you did not post any code.

Say you have this code:

static char[4] lookup = ['a', 't', 'g', 'c']

This lookup table will be in thread local storage (tls). TLS is a 
way to have global variables that are not shared between threads 
that is every thread has it's own copy of the variable. TLS 
variables are not as fast to access as true global variables 
however since the accessing code has to do some additional lookup 
based on the thread to gain access to the correct copy.


If you change the above code to this:
static immutable char[4] lookup = ['a', 't', 'g', 'c'];

Then you get an immutable array. Since this array cannot change 
and is the same on all threads there is no reason to have 
separate storage for each thread. Thus the above code will create 
a true global variable that is shared between the threads. So 
what you are likely seeing is that a variable changed from being 
tls to being a shared global. Global accessing is faster then TLS 
accessing so this is probably what made your code run faster.


If you want a shared global that is not immutable you can do this.
__gshared char[4] lookup = ['a', 't', 'g', 'c];

Be warned though these kinds of globals are not thread safe so 
mutation and accessing should be synchronized if your using more 
then one thread.

Re: I have this game engine...

[Manu via Digitalmars-d]

On 3 November 2015 at 11:07, mattcoder via Digitalmars-d
 wrote:
> On Sunday, 1 November 2015 at 02:36:16 UTC, Manu wrote:
>>
>> ...
>> Does it support Dreamcast? :P
>
>
> I don't know if you are being serious here but if yes... what's the catch
> with Dreamcast? I mean this is a Fan thing or what?

I'm just a massive nerd, and the Dreamcast was a great console! :P

Re: generate with state

[Ali Çehreli via Digitalmars-d-learn]

On 11/02/2015 04:51 PM, Freddy wrote:
> On Tuesday, 3 November 2015 at 00:08:54 UTC, Ali Çehreli wrote:
>> generate() already allows "callables", which can be a delegate:
>>
>> import std.stdio;
>> import std.range;
>>
>> struct S {
>> int i;
>>
>> int fun() {
>> return i++;
>> }
>> }
>>
>> void main() {
>> auto s = S(42);
>> writefln("%(%s %)", generate().take(5));
>> }
>>
>> Prints
>>
>> 42 43 44 45 46
>
> Will that allocate gc memory?

Not the way I wrote it. You can test it by putting @nogc to the function 
that uses that code. (The only GC code up there is writefln).


> Is there any why I pass state as a tuple and have my generator modify 
state

> as It's called?

Yes but you must ensure that the object will live long enough. A closure 
is simple but it uses GC. The following code passes a temporary object 
and makeMyRange() closes over that variable:


import std.stdio;
import std.range;

struct S {
int i;

int fun() {
return i++;
}
}

auto makeMyRange(S s) {
return generate(() => s.fun()).take(5);// <-- closure
}

void main() {
writefln("%(%s %)", makeMyRange(S(42)));
}

Alternatively, as long as it will live long enough, you can make a local 
object like 's' in my original code.


Ali

Re: Unionize range types

[TheFlyingFiddle via Digitalmars-d-learn]

On Tuesday, 3 November 2015 at 01:55:27 UTC, Freddy wrote:

Is there any way I can Unionize range Types?
---
auto primeFactors(T)(T t, T div = 2)
{
if (t % div == 0)
{
return t.only.chain(primeFactors(t / div, div));
}
if (div > t)
{
return [];
}
else
{
return primeFactors(t, div + 1);
}
}
---


Simplest way would be to go with a polymorphic approach.
import std.range;

interface IInputRange(T)
{
T front();
bool empty();
void popFront();
}

class InputRange(Range) : IInputRange(ElementType!Range)
{
   Range inner;
   T front() { return inner.front; }
   bool empty() { return inner.empty; }
   void popFront() { inner.popFront; }
}

Simply wrap the ranges in the InputRange!Range class template. 
And return an IInputRange!T. This will require allocation though 
and is not really the way I would tackle the problem.


Or you could use Algebraic from std.variant which is probably 
more what you were looking for. But it's kind of awkward to use 
in the example you posted since it's not really clear what the 
specific range types are.


I would suggest creating a new range for prime-factors instead of 
trying to mix several ranges together. Something like this should 
do the trick. (if i am understanding the problem correctly)


auto primeFactors(T)(T t) if(isIntegral!T)
{
   struct Factors
   {
  T value;
  T front;
  bool empty() { return value == 1; }
  void popFront()
  {
 while(true)
 {
if(value % front == 0)
{
   value /= front;
   break;
}
if(front > value)
{
   value = 1;
   break;
}
else
{
   front = front + 1;
}
 }
  }
   }

   auto f = Factors(t, 2);
   f.popFront();
   return f;
}

how to make the commented out lines work when they are uncommented

[steven kladitis via Digitalmars-d-learn]

import std.stdio, std.algorithm, std.array, std.traits,std.range, 
std.typecons,std.complex;


enum AreSortableArrayItems(T) = isMutable!T &&
__traits(compiles, T.init < 
T.init) &&

!isNarrowString!(T[]);

void selectionSort(T)(T[] data) if (AreSortableArrayItems!T) {
foreach (immutable i, ref d; data)
data.drop(i).minPos[0].swap(d);
}
void main() {
auto a = [3, 1, 4, 1, 5, 9, 2, 6, 5, 3, 5, 8, 9, 7, 9, 3, 2];
a.selectionSort;
a.writeln;
int[] a0;
a0.selectionSort;
a0.writeln;

auto a1 = [1];
a1.selectionSort;
a1.writeln;

auto a2 = ["a", "b"];
a2.selectionSort;
a2.writeln;

auto a3 = ["b", "a"];
a3.selectionSort;
a3.writeln;

//char[] a4 = ['a', 'b'];
//a4.selectionSort;
//a4.writeln;

dstring[] a5 = ["b", "a"];
a5.selectionSort;
a5.writeln;


alias Nullable!int N;
auto a6 = [N(2), N(1)];
a6.selectionSort; // Not nothrow.
a6.writeln;

//auto a7 = [complex(1.0,0.0), complex(2.0,0.0)];
//a7.selectionSort;
//a7.writeln;


//  auto a8 = [complex(1.0L), complex(2.0L)];
//a8.selectionSort;
//a8.writeln;


static struct F {
int x;
int opCmp(F f) { // Not pure.
return x < f.x ? -1 : (x > f.x ? 1 : 0);
}
}
auto a9 = [F(2), F(1)];
a9.selectionSort;
a9.writeln;
}
// dmd 2.069 rc2

[Issue 15273] New: json.d parseJSON doesnt parse current json string

[via Digitalmars-d-bugs]

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

  Issue ID: 15273
   Summary: json.d parseJSON doesnt parse current json string
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: a_perfi...@mail.ru

jsonValue is empty after parseJSON

Here is code example:

import std.json;

public static void main() {
string jsondata =
"{\"results\":[{\"paramName\":\"GeoEnrichmentResult\",\"dataType\":\"GeoEnrichmentResult\",\"value\":{\"version\":\"2.0\",\"FeatureSet\":[{\"displayFieldName\":\"\",\"fieldAliases\":{\"OBJECTID\":\"Object
ID\",\"ID\":\"ID\",\"sourceCountry\":\"sourceCountry\",\"HasData\":\"HasData\",\"TOTPOP\":\"Total
Population\",\"TOTHH\":\"Total Households\",\"TOTMALES\":\"Male
Population\",\"TOTFEMALES\":\"Female Population\",\"AVGHHSZ\":\"Average
Household
Size\"},\"fields\":[{\"name\":\"OBJECTID\",\"type\":\"esriFieldTypeOID\",\"alias\":\"Object
ID\"},{\"name\":\"ID\",\"type\":\"esriFieldTypeString\",\"alias\":\"ID\",\"length\":256},{\"name\":\"sourceCountry\",\"type\":\"esriFieldTypeString\",\"alias\":\"sourceCountry\",\"length\":256},{\"name\":\"HasData\",\"type\":\"esriFieldTypeInteger\",\"alias\":\"HasData\"},{\"name\":\"TOTPOP\",\"type\":\"esriFieldTypeDouble\",\"alias\":\"Total
Population\",\"fullName\":\"KeyGlobalFacts.TOTPOP\",\"component\":\"demographics\",\"decimals\":0,\"units\":\"count\"},{\"name\":\"TOTHH\",\"type\":\"esriFieldTypeDouble\",\"alias\":\"Total
Households\",\"fullName\":\"KeyGlobalFacts.TOTHH\",\"component\":\"demographics\",\"decimals\":0,\"units\":\"count\"},{\"name\":\"TOTMALES\",\"type\":\"esriFieldTypeDouble\",\"alias\":\"Male
Population\",\"fullName\":\"KeyGlobalFacts.TOTMALES\",\"component\":\"demographics\",\"decimals\":0,\"units\":\"count\"},{\"name\":\"TOTFEMALES\",\"type\":\"esriFieldTypeDouble\",\"alias\":\"Female
Population\",\"fullName\":\"KeyGlobalFacts.TOTFEMALES\",\"component\":\"demographics\",\"decimals\":0,\"units\":\"count\"},{\"name\":\"AVGHHSZ\",\"type\":\"esriFieldTypeDouble\",\"alias\":\"Average
Household
Size\",\"fullName\":\"KeyGlobalFacts.AVGHHSZ\",\"component\":\"scripts\",\"decimals\":2,\"units\":\"count\"}],\"features\":[{\"attributes\":{\"OBJECTID\":1,\"ID\":\"0\",\"sourceCountry\":\"US\",\"HasData\":1,\"TOTPOP\":318536439,\"TOTHH\":120746349,\"TOTMALES\":156936483,\"TOTFEMALES\":161599956,\"AVGHHSZ\":2.57}}]}]}}],\"messages\":[]}";
JSONValue jsonValue = parseJSON(jsondata);
}

--

Re: Lazy std.algorithm.replace()

[Nordlöw via Digitalmars-d-learn]

On Sunday, 1 November 2015 at 14:26:21 UTC, Nordlöw wrote:
Is there a reason why Phobos doesn't contain a lazy range 
variant of std.string.replace?


Ping.

[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 #11 from ag0ae...@gmail.com ---
(In reply to ag0aep6g from comment #10)
> Reduced a little further, showing that bucketCount gets corrupted:
> 
[...]
> 

And further, removing -inline from the equation (still needs -release -O):

import core.stdc.stdio: printf;

void[] calloc_(size_t bc) nothrow pure
{
debug printf("%x\n", bc); /* prints "", should print "1" */
return [];
}

void main()
{
try nop();
finally {}

StringCache scache;
size_t bucketCount = 1;
void[]* buckets = 
*buckets = calloc_(bucketCount)[0 .. bucketCount];
printf("");
}

void nop() {}

struct StringCache
{
void[] buckets;
}


--

Unionize range types

[Freddy via Digitalmars-d-learn]

Is there any way I can Unionize range Types?
---
auto primeFactors(T)(T t, T div = 2)
{
if (t % div == 0)
{
return t.only.chain(primeFactors(t / div, div));
}
if (div > t)
{
return [];
}
else
{
return primeFactors(t, div + 1);
}
}

---

Re: Benchmark memchar (with GCC builtins)

[Iakh via Digitalmars-d]

On Friday, 30 October 2015 at 21:33:25 UTC, Andrei Alexandrescu 
wrote:
Could you please take a look at GCC's generated code and 
implementation of memchr? -- Andrei


So i did. I rewrite code to do main work in cacheLineSize chunks. 
And this

is what GLIBC version do.
So main loop looks this:

-
do
{
// ptr16 is aligned 64
ubyte16 r1 = __builtin_ia32_pcmpeqb128(ptr16[0], niddles);
ubyte16 r2 = __builtin_ia32_pcmpeqb128(ptr16[1], niddles);
ubyte16 r3 = __builtin_ia32_pcmpeqb128(ptr16[2], niddles);
ubyte16 r4 = __builtin_ia32_pcmpeqb128(ptr16[3], niddles);

r3 = __builtin_ia32_pmaxub128(r1, r3);
r4 = __builtin_ia32_pmaxub128(r2, r4);
r4 = __builtin_ia32_pmaxub128(r3, r4);
mask = __builtin_ia32_pmovmskb128(r4);

if (mask != 0)
{
mask = __builtin_ia32_pmovmskb128(r1);
mixin(CheckMask); // Check and return value

++ptr16; num -= 16;
mask = __builtin_ia32_pmovmskb128(r2);
mixin(CheckMask);

++ptr16; num -= 16;
r3 = __builtin_ia32_pcmpeqb128(*ptr16, niddles);
mask = __builtin_ia32_pmovmskb128(r3);
mixin(CheckMask);

++ptr16; num -= 16;
r4 = __builtin_ia32_pcmpeqb128(*ptr16, niddles);
mask = __builtin_ia32_pmovmskb128(r4);
mixin(CheckMask);
}

num -= 64;
ptr16 += 4;
}
while (num > 0);
-

and my best result:

-
Naive:21.46 TickDuration(132842482)
SIMD: 1.161 TickDuration(7188211)
(was)SIMD: 3.04 TickDuration(18920182)
C:1 TickDuration(6189222)