[Issue 15382] std.uri has an incorrect set of reserved characters

[via Digitalmars-d-bugs]

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

Eugene Wissner  changed:

   What|Removed |Added

 CC||be...@caraus.de

--- Comment #1 from Eugene Wissner  ---
Look at "2.4.  When to Encode or Decode":
"the only time when octets within a URI are percent-encoded is during the
process of producing the URI from its component parts.  This is when an
implementation determines which of the reserved characters are to be used as
subcomponent delimiters and which can be safely used as data."

So reserved characters can be encoded but it isn't a must. Only characters used
as delimiters in a particular URL scheme must be encoded. Wikipedia differs
between reserved characters with or without reserved meaning.
I tested it quickly in Firefox and Firefox doesn't seem to encode characters
like * or ().
The behavior of encodeComponent is actually exactly the same as
encodeURIComponent from JavaScript. The behavior described in the issue, is how
PHP urlencode works, that encodes all reserved characters.

--

Re: How about use Gc as a big memory pool?

[Olivier Pisano via Digitalmars-d-learn]

On Friday, 8 April 2016 at 03:27:04 UTC, Dsby wrote:

when the soft start, call GC.disable().
use "new " create a class , struct or a array. and use 
destory(T/void *) to call the ~this(), then GC.free to free the 
memory， and use RAII in class or Struct.
And user the Timer, or in some where to call : GC.enable(), 
GC.collect(), GC.disable();


In this way , i can know and control when is GC runing.

Is This way   feasible? will It  have a problem？


It should work, but you cannot predict how much time collect() 
will take, since it depends on the system state (how much work it 
has to do). So instead of calling it at fixed intervals, you'd 
better call it when your application is idle.


Why don't you try to use 
https://dlang.org/phobos/std_experimental_allocator.html ?

Re: Any usable SIMD implementation?

[Walter Bright via Digitalmars-d]

On 4/7/2016 3:15 AM, Johannes Pfau wrote:

The problem is that march=x can set more than one
feature flag. So instead of

gdc -march=armv7-a
you have to do
gdc -march=armv7-a -fversion=ARM_FEATURE_CRC32
-fversion=ARM_FEATURE_UNALIGNED ...

Sou have to know exactly which features are supported for a CPU.
Essentially you have to duplicate the CPU<=>feature database already
present in GCC (and likely LLVM too) in your Makefile. And you'll need
-march=armv7-a anyway to make sure the GCC codegen can use these
features as well.

So this issue is not a blocker, but what you propose is a workaround at
best, not a solution.



Having a veritable blizzard of these predefined versions, that constantly are 
obsoleted and new ones appearing, seems like a serious problem when trying to 
standardize the language.

Re: Any usable SIMD implementation?

[Walter Bright via Digitalmars-d]

On 4/7/2016 5:27 PM, Manu via Digitalmars-d wrote:

You'll have noticed that C++ interaction is my recent focus, since
that's directly related to my current day-job, and the path that I
need to solve now to get D into my work.


We recognize C++ interoperability to be a key feature of D. I hope you like the 
support you got with the C++ virtual functions! I got bogged down recently with 
getting the C++ exception handling support working better, hopefully we've 
turned the corner on that one. I'd hoped to be further along at the moment with 
C++ interoperability (but it's always going to be a work in progress).




That's consuming almost 100% of my D-time-allocation... if I could
ever manage to just kick that goal, it might free me up >_< .. I keep
on trying.


I do appreciate your efforts in this direction.



Doing it at a high level is what I meant, not for each SIMD code fragment.

Sure, so you agree we need a mechanism for the author to tune the
default selection then?


From the command line, probably not. I like the pragma thing better.



Or are you suggesting SSE2 is 'fine' as a default? (ie, that is what is implied 
by D_SIMD)


It is fine as a default, as it is the baseline minimum machine D is expecting.

What is the state of Microcontroller support in d?

[Taylor Hillegeist via Digitalmars-d]

So, for me one of the greatest things about d is that it is 
compiled to machine language. But It makes me sad that this 
strength doesn't seem to be available in one of the most obvious 
places.


There are some projects:

minilibd:
https://bitbucket.org/timosi/minlibd
The example code is still waiting for decision what is the proper 
way to

access peripheral registers in D code.

The Discovery board Demo:
https://github.com/JinShil/stm32f42_discovery_demo
I actually was able to run the code on this board.

These are very cool, I do notice that both of these use GDC.

The discovery demo looked tedious to implement 
(https://github.com/JinShil/stm32_datasheet_to_d).


I cheated and used a CMSIS .svd file to build the peripherals 
registers.

https://www.keil.com/pack/doc/CMSIS/SVD/html/svd__outline_pg.html

There are big hurdles:
Typeinfo bloat.
Register/Linker file configuation.
Standardized build environments.
More complete runtimes with examples :)
better documentation on d runtime and what is needed for x 
functionality.


But bottom line is it really isn't easy to do. I follow the 
examples for the most part. I feel like the Build environment was 
clunkly for micros and dub certainly was not the right build tool.


I was just curious what is the story?

I know its a goal that in time the community would love to reach.

How about use Gc as a big memory pool?

[Dsby via Digitalmars-d-learn]

when the soft start, call GC.disable().
use "new " create a class , struct or a array. and use 
destory(T/void *) to call the ~this(), then GC.free to free the 
memory， and use RAII in class or Struct.
And user the Timer, or in some where to call : GC.enable(), 
GC.collect(), GC.disable();


In this way , i can know and control when is GC runing.

Is This way   feasible? will It  have a problem？

Re: is std.algorithm.joiner lazy?

[Puming via Digitalmars-d-learn]

On Friday, 8 April 2016 at 02:49:01 UTC, Jonathan M Davis wrote:

[...]


Thanks. I'll adopt this idiom. Hopefully it gets used often 
enough to warrent a phobos function :-)

Re: @nogc inconsistent for array comparison depending on mutability of elements

[Xinok via Digitalmars-d-learn]

On Friday, 8 April 2016 at 01:36:18 UTC, rcorre wrote:

@nogc unittest {
int[2] a = [1, 2];
assert(a == [1, 2]); // OK

immutable(int)[2] b = [1, 2];
assert(b == [1, 2]); // fail: array literal may cause 
allocation

}

Is there any logic behind allowing the comparison with `a` but 
not `b`, or is this a compiler bug?


Semantically, array literals are always allocated on the heap. In 
this case, the optimizer can obviously place the array on the 
stack or even make it static/global. However, it would be in poor 
design to rely on the optimizer to satisfy @nogc. It comes down 
to portability; if the code compiles successfully with one 
compiler, then it should compile successfully in any other 
compiler.


Also, the way that compilers are typically built is that semantic 
analysis is done in the frontend and optimization is done in the 
backend. Trying to build a bridge between these two would be 
incredibly difficult and make implementing the compiler much more 
complex with little gain.

Re: Unexpected Crash

[default0 via Digitalmars-d-learn]

On Thursday, 7 April 2016 at 21:22:19 UTC, Ali Çehreli wrote:

On 04/07/2016 01:49 PM, default0 wrote:

On Thursday, 7 April 2016 at 20:47:35 UTC, Adam D. Ruppe wrote:

On Thursday, 7 April 2016 at 20:42:17 UTC, default0 wrote:
If I enter "5,5,5" on the commandline, hit enter, then enter 
"5,5,5"



When you hit enter, that puts a \n character in the buffer. 
readf
doesn't skip that automatically, so it complains upon hitting 
that
newline (the error message shows the character *after* it 
though,

which sucks).


But what you want to do is to read whitespace too. I think 
putting a
space in the format string at the beginning or end will do it 
(I don't

use readf often though).


Changing the format string to "%d,%d,%d\n" fixed the problem. 
Would've

figured if the error complained about '\n' instead of '5'.


Which compiler version? This is fixed:

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

It's now better but \n may be hard to decode from the following 
message:


std.conv.ConvException@/usr/include/dmd/phobos/std/conv.d(2002): Unexpected '
' when converting from type LockingTextReader to type int

Ali


dmd --version prints out 2.070.2

I believe 2.071 is the most recent version?

Re: is std.algorithm.joiner lazy?

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, April 08, 2016 02:01:07 Puming via Digitalmars-d-learn wrote:
> So what you mean is to read the front in constructor, and read
> further parts in the popFront()? that way multiple access to the
> front won't hurt anything. I think it might work, I'll change my
> code.
>
> So the guideline is: when accessing front is costly, don't use
> map, use a customized range struct instead. right?

In general, when you're dealing with a non-random access range, it's best
for popFront to do the work of setting up front and then have front return
the same object every time. If front is doing the work, then if it gets
called multiple times, that work is being repeated every time it gets
called. map is a funny case, because it can be a random-access range (if the
underlying range it's wrapping is a random-access range). So, fundamentally,
it doesn't work in map to do the work in popFront. It pretty much has to be
done in front. So, doing stuff like range.map!(a => to!string(a))() is
problematic in that a new allocation is going to occur every time that front
is called - or when any element is accessed via opIndex. It works so long as
the element is equal every time, and calling front multiple times does not
affect the rest of the range, but it can be costly. In theory, cache should
solve that case (and it would result in a range that wasn't random access,
so opIndex wouldn't be called on it), but obviously, you're running into
problems with it.

In any case, in general, when doing something like reading from a file with
a range, it works best to do the work in popFront to avoid issues with
multiple calls to front, and the constructor needs to do that work as well
(be it by calling popFront or not), because front needs to be valid as soon
as the range has been created, and it's not empty. So, you end up with
something like

struct MyRange
{
public:
@property T front() { return _value; }
@property bool empty() { ... }
void popFront()
{
_value = readNextValueFromFile();
}

private:

this(Something s)
{
...
popFront();
}

T _value;
}

It also encapsulates things better than having a function whose only purpose
is to be used in map, though there are obviously cases where writing a
function just to use in map would make sense.

In general, I would only use map for cases where I'm converting something to
something else and not for functions that do arbitrary work. A function for
map that cannot be pure is a danger sign IMHO. Certainly, if you're going to
follow how ranges are expected to work, whatever function you give map needs
to return equal values every time front is called between calls to popFront,
and multiple calls to front cannot affect the rest of the range.  And what
you did with map, doesn't follow those guidelines, though it probably would
if cache worked, and you always fed it into cache.  Still, for something
like this, I'd just create my own range and be done with it. You often need
to anyway in order to manage extra state. And it tends to be more idiomatic,
though I suppose that that's somewhat subjective.

- Jonathan M Davis

Re: how to parse a string into a phobos datatype with additional logic

[Puming via Digitalmars-d-learn]

On Thursday, 7 April 2016 at 11:07:35 UTC, Marc Schütz wrote:

On Thursday, 7 April 2016 at 08:06:03 UTC, Puming wrote:

On Thursday, 7 April 2016 at 07:45:06 UTC, yawniek wrote:

what is the way one is supposed to parse e.g. a
double of unixtime (as delived by nginx logs) into a SysTime?

currently i'm creating a wrapper struct around SysTime with 
alias this as:


https://gist.github.com/yannick/6caf5a5184beea0c24f35d9d4a4c7783

really ugly imho.

is there a better way to do this?


you mean 
http://dlang.org/phobos/std_datetime.html#.SysTime.fromUnixTime ?


That one only accepts `long`, though, so you'd lose sub-second 
precision.


Yes, might be due to that standard UnixTime only has second 
precision.


For the sub-second part, you need to add a duration like nsecs. 
It's still ugly, but you don't need another struct if what you 
want is just a SysTime.


SysTime parseNginxTime(string t) {
   // assuming the nginx time has precision of nano-seconds.
   return SysTime.fromUnixTime(t[0..$-9].to!long)
   + t[$-9..$].to!long.nsecs;
}

The problem though is that SysTime only hode precision to the 
hnsec, so the last three digits is actually lost.

Re: Building DWT

[chrisalex via Digitalmars-d-dwt]

The same thing happens with GtkD

Re: is std.algorithm.joiner lazy?

[Puming via Digitalmars-d-learn]

On Friday, 8 April 2016 at 01:14:11 UTC, Jonathan M Davis wrote:

[...]

Well, given your example, I would strongly argue that you 
should write a range that calls read in its constructor and in 
popFront rather (so that calling front multiple times doesn't 
matter) rather than using map. While map can theoretically be 
used the way that you're trying to use it, it's really intended 
for converting an element using rather than doing stuff like 
I/O in it. Also, if the range that you give map is random 
access (like an array would be), then opIndex could be used to 
access random elements, which _really_ wouldn't work with 
reading from a file. So, I think that map is just plain a bad 
choice for what you're trying to do.




Well, I used map because of when viewing the scenario in a data 
flow, map seems an intuitive choise:


what I have: a bunch of large files, each file containing 
sections of data, each sections is composed of many lines of 
record. For each file, I have an list of indices.


what I want: given a list of files and indices for each file, I 
want to construct a lazy stream of records for other program to 
use.


here is the data flow:

query constraints
-> [(filePath, [index])]
-> [(File, [index])] // map, needs cache
-> [[section]] // map, needs cache
-> [[[record]]]  // joiner.joiner
-> Range of record

And after reading cache's docs, I get that cache is perfect for 
converting a Range with front side effect into a Range with 
popFront side effect.


So if cache and map works harmoniously, they should do the same 
trick as manually writing two Ranges here.




- Jonathan M Davis

Re: is std.algorithm.joiner lazy?

[Puming via Digitalmars-d-learn]

On Friday, 8 April 2016 at 01:14:11 UTC, Jonathan M Davis wrote:

[...]

Lazy means that it's not going to consume the entire range when 
you call the function. Rather, it's going to return a range 
that you can iterate over. It may or may not process the first 
element before returning, depending on how it works, and 
there's definitely nothing that says whether it's going to 
access front multiple times or not before calling popFront. And 
accessing front multiple times without calling popFront is 
_normal_ whether you're dealing with a lazy range or an eager 
one. All that lazy means is that you're getting a range from 
the function rather than it consuming the range before 
returning.


So, whatever you do with a range, in general, you have to 
assume that an algorithm might access front multiple times, and 
the implementation is free to change so that it accesses it 
more times or fewer times, because the range API says nothing 
about whether front is accessed multiple times or not. front 
needs to return equal values every time that it's called before 
popFront is called, but that doesn't mean that they have to be 
the same objects, and it doesn't mean that there's any 
restriction on how many times front is accessed before a call 
to popFront.


So, I see no reason for joiner to say anything in its docs 
about how many times it accesses front. It's pretty much 
irrelevant to how ranges are expected to work, and it could 
change. If it actually matters for what you're doing, then you 
need to figure out how to rework your code so that it doesn't 
matter whether front is accessed multiple times per call to 
popFront or not. That's just part of working with ranges, 
though I can certainly understand if you didn't realize that 
previously.

That makes sense. Thanks for the clarification.


There is another problem, map, cache, and joiner don't work 
when composed multiple times. I've submitted a bug, 
https://issues.dlang.org/show_bug.cgi?id=15891, can you 
confirm?


Well, given your example, I would strongly argue that you 
should write a range that calls read in its constructor and in 
popFront rather (so that calling front multiple times doesn't 
matter) rather than using map. While map can theoretically be 
used the way that you're trying to use it, it's really intended 
for converting an element using rather than doing stuff like 
I/O in it. Also, if the range that you give map is random 
access (like an array would be), then opIndex could be used to 
access random elements, which _really_ wouldn't work with 
reading from a file. So, I think that map is just plain a bad 
choice for what you're trying to do.


So what you mean is to read the front in constructor, and read 
further parts in the popFront()? that way multiple access to the 
front won't hurt anything. I think it might work, I'll change my 
code.


So the guideline is: when accessing front is costly, don't use 
map, use a customized range struct instead. right?




It's not obvious to me why your example is failing to compile - 
the problem appears to be with cache specifically and has 
nothing to do with joiner - and I am inclined to agree that 
there's a bug there (be it in cache or in the compiler), but I 
really think that using map is a bad move for what you're 
trying to do anyway - especially when you consider what will 
happen if opIndex is used. I'd strongly encourage you to just 
write a range that does what you need instead.


OK, hope it'll get fixed. I'll try to look for it once I'm able 
to understande the code in phobos.




- Jonathan M Davis

@nogc inconsistent for array comparison depending on mutability of elements

[rcorre via Digitalmars-d-learn]

@nogc unittest {
int[2] a = [1, 2];
assert(a == [1, 2]); // OK

immutable(int)[2] b = [1, 2];
assert(b == [1, 2]); // fail: array literal may cause 
allocation

}

Is there any logic behind allowing the comparison with `a` but 
not `b`, or is this a compiler bug?

[Issue 15890] IFTI for static array argument length when element type supplied

[via Digitalmars-d-bugs]

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

r...@rcorre.net changed:

   What|Removed |Added

 CC||r...@rcorre.net

--

[Issue 15894] Allow setting of rt_trapExceptions from module c'tors

[via Digitalmars-d-bugs]

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

Marenz  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=4385

--

Re: is std.algorithm.joiner lazy?

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, April 08, 2016 00:30:05 Puming via Digitalmars-d-learn wrote:
> On Thursday, 7 April 2016 at 18:15:07 UTC, Jonathan M Davis wrote:
> > On Thursday, April 07, 2016 08:47:15 Puming via
> >
> > Digitalmars-d-learn wrote:
> >> On Thursday, 7 April 2016 at 08:27:23 UTC, Edwin van Leeuwen
> >>
> >> wrote:
> >> > On Thursday, 7 April 2016 at 08:17:38 UTC, Puming wrote:
> >> >> On Thursday, 7 April 2016 at 08:07:12 UTC, Edwin van
> >> >> Leeuwen wrote:
> >> >>
> >> >> OK. Even if it consumes the first two elements, then why
> >> >> does it have to consume them AGAIN when actually used? If
> >> >> the function mkarray has side effects, it could lead to
> >> >> problems.
> >> >
> >> > After some testing it seems to get each element twice, calls
> >> > front on the MapResult twice, on each element. The first two
> >> > mkarray are both for first element, the second two for the
> >> > second. You can solve this by caching the front call with:
> >> >
> >> > xs.map!(x=>mkarray(x)).cache.joiner;
> >>
> >> Thanks! I added more elements to xs and checked that you are
> >> right.
> >>
> >> So EVERY element is accessed twice with joiner. Better add
> >> that to the docs, and note the use of cache.
> >
> > I would note that in general, it's not uncommon for an
> > algorithm to access front multiple times. So, this really isn't
> > a joiner-specific issue. If anything, it's map that should get
> > a note in its docs, not joiner. You really should just expect
> > front to be called multiple times. So, if that's a problem, use
> > cache. But joiner is not doing anything abnormal.
>
> But in the joiner docs, it says joiner is lazy. But accessing
> front multiple times is not true laziness. I think it better note
> that after the lazy part: "joiner is lazy, but it will access the
> front twice".
>
> If there are many other lazy functions behave like this, I
> suggest to make a new name for it, like 'semi-lazy', to be more
> accurate.
>
> Maybe its my fault, I didn't know what cache does before Edwin
> told me.
> So there is the solution, it just is not easy for newbies to find
> out because there is no direct link between these functions.

Lazy means that it's not going to consume the entire range when you call the
function. Rather, it's going to return a range that you can iterate over. It
may or may not process the first element before returning, depending on how
it works, and there's definitely nothing that says whether it's going to
access front multiple times or not before calling popFront. And accessing
front multiple times without calling popFront is _normal_ whether you're
dealing with a lazy range or an eager one. All that lazy means is that
you're getting a range from the function rather than it consuming the range
before returning.

So, whatever you do with a range, in general, you have to assume that an
algorithm might access front multiple times, and the implementation is free
to change so that it accesses it more times or fewer times, because the
range API says nothing about whether front is accessed multiple times or
not. front needs to return equal values every time that it's called before
popFront is called, but that doesn't mean that they have to be the same
objects, and it doesn't mean that there's any restriction on how many times
front is accessed before a call to popFront.

So, I see no reason for joiner to say anything in its docs about how many
times it accesses front. It's pretty much irrelevant to how ranges are
expected to work, and it could change. If it actually matters for what
you're doing, then you need to figure out how to rework your code so that it
doesn't matter whether front is accessed multiple times per call to popFront
or not. That's just part of working with ranges, though I can certainly
understand if you didn't realize that previously.
>
> There is another problem, map, cache, and joiner don't work when
> composed multiple times. I've submitted a bug,
> https://issues.dlang.org/show_bug.cgi?id=15891, can you confirm?

Well, given your example, I would strongly argue that you should write a
range that calls read in its constructor and in popFront rather (so that
calling front multiple times doesn't matter) rather than using map. While
map can theoretically be used the way that you're trying to use it, it's
really intended for converting an element using rather than doing stuff like
I/O in it. Also, if the range that you give map is random access (like an
array would be), then opIndex could be used to access random elements, which
_really_ wouldn't work with reading from a file. So, I think that map is
just plain a bad choice for what you're trying to do.

It's not obvious to me why your example is failing to compile - the problem
appears to be with cache specifically and has nothing to do with joiner -
and I am inclined to agree that there's a bug there (be it in cache or in
the compiler), but I really think that using map is a bad move for what
you're trying to do anyway - 

Re: The day before DConf 2016

[Mike Parker via Digitalmars-d]

Alrighty, then. Plenty of people around so I'm confident I won't 
be lonely. I suppose I'll get a little bit of sightseeing in 
during the a.m. and early afternoon then make for the lobby 
after. I at least want to get to Potsdamer Platz and visit some 
of the touristy spots around there.


On Thursday, 7 April 2016 at 19:33:36 UTC, Steven Schveighoffer 
wrote:




Regarding exploring, I'm in Berlin all day Saturday (7th). 
Anyone going to do anything that day?


I wish I could hang around. I have a 6:30 a.m. flight that I am 
sooo not looking forward to. I need to be back in Seoul before 
Sunday evening. There weren't many options that fit my budget and 
didn't have a ridiculously long layover. My wife handled the 
booking (she was planning to come with me and we were going to 
make 10 days of it, but she couldn't get away from work), but if 
it had been solely up to me I would have said to hell with the 
budget for the extra sleep.

Re: is std.algorithm.joiner lazy?

[Puming via Digitalmars-d-learn]

On Thursday, 7 April 2016 at 18:15:07 UTC, Jonathan M Davis wrote:
On Thursday, April 07, 2016 08:47:15 Puming via 
Digitalmars-d-learn wrote:

On Thursday, 7 April 2016 at 08:27:23 UTC, Edwin van Leeuwen

wrote:
> On Thursday, 7 April 2016 at 08:17:38 UTC, Puming wrote:
>> On Thursday, 7 April 2016 at 08:07:12 UTC, Edwin van 
>> Leeuwen wrote:

>>
>> OK. Even if it consumes the first two elements, then why 
>> does it have to consume them AGAIN when actually used? If 
>> the function mkarray has side effects, it could lead to 
>> problems.

>
> After some testing it seems to get each element twice, calls 
> front on the MapResult twice, on each element. The first two 
> mkarray are both for first element, the second two for the 
> second. You can solve this by caching the front call with:

>
> xs.map!(x=>mkarray(x)).cache.joiner;

Thanks! I added more elements to xs and checked that you are 
right.


So EVERY element is accessed twice with joiner. Better add 
that to the docs, and note the use of cache.


I would note that in general, it's not uncommon for an 
algorithm to access front multiple times. So, this really isn't 
a joiner-specific issue. If anything, it's map that should get 
a note in its docs, not joiner. You really should just expect 
front to be called multiple times. So, if that's a problem, use 
cache. But joiner is not doing anything abnormal.


But in the joiner docs, it says joiner is lazy. But accessing 
front multiple times is not true laziness. I think it better note 
that after the lazy part: "joiner is lazy, but it will access the 
front twice".


If there are many other lazy functions behave like this, I 
suggest to make a new name for it, like 'semi-lazy', to be more 
accurate.


Maybe its my fault, I didn't know what cache does before Edwin 
told me.
So there is the solution, it just is not easy for newbies to find 
out because there is no direct link between these functions.




And it's not even the case that it necessarily makes sense to 
make a rule of thumb that ranges should copy front instead of 
calling it multiple times, because if front returns by ref, 
calling front multiple times is likely to be cheapepr, and 
while we don't properly support non-copyable types (like 
UniquePtr) with ranges right now, we really should, so if 
anything, it becomes the case that algorithms should favor 
calling front multiple times over copying its value.


Indeed. I think copy is not good. But multiple access is a thing 
to note. When I want to use lazy things, it usually is that I'm 
reading files, so accessing twice is not acceptable.




So, there are pros and cons involved with copying front vs 
calling it multiple times, and I think that both approaches are 
both pretty common at this point. So, given how frequently it 
makes sense for map to allocate (e.g. to!string(a)), map should 
probably have a note about cache, but overall, it's just 
something that you need to be aware of. Regardless, I don't 
think that it makes sense to put anything in joiner's docs 
about it.


There is another problem, map, cache, and joiner don't work when 
composed multiple times. I've submitted a bug, 
https://issues.dlang.org/show_bug.cgi?id=15891, can you confirm?


Because of this, now I have to read a file multiple times(using 
only joiner), or have to eagerly retrieve data in an array (which 
is too big), or fall back to an imperative way of manually 
accessing each file. They are all bad.


- Jonathan M Davis

Re: Any usable SIMD implementation?

[Walter Bright via Digitalmars-d]

On 4/7/2016 3:52 AM, Kai Nacke wrote:

On Thursday, 7 April 2016 at 03:27:31 UTC, Walter Bright wrote:

Then,

void app(int simd)() { ... my fabulous app ... }

int main() {
  auto fpu = core.cpuid.getfpu();
  switch (fpu) {
case SIMD: app!(SIMD)(); break;
case SIMD4: app!(SIMD4)(); break;
default: error("unsupported FPU"); exit(1);
  }
}



glibc has a special mechanism for resolving the called function during loading.
See the section on the GNU Indirect Function Mechanism here:
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/W51a7ffcf4dfd_4b40_9d82_446ebc23c550/page/Optimized%20Libraries


Would be awesome to have something similar in druntime/Phobos.


We already have core.cupid, which covers most of what that article talks about. 
The indirect function thing appears to be a way to selectively load from various 
dlls. But that can be done anyway with core.cpuid and dynamic dll loading, so 
I'm not sure what advantage it brings.

Re: Any usable SIMD implementation?

[Manu via Digitalmars-d]

On 7 April 2016 at 13:27, Walter Bright via Digitalmars-d
 wrote:
> On 4/6/2016 7:43 PM, Manu via Digitalmars-d wrote:
>>>
>>> 1. This has been characterized as a blocker, it is not, as it does not
>>> impede writing code that takes advantage of various SIMD code generation
>>> at
>>> compile time.
>>
>>
>> It's sufficiently blocking that I have not felt like working any
>> further without this feature present. I can't feel like it 'works' or
>> it's 'done', until I can demonstrate this functionality.
>> Perhaps we can call it a psychological blocker, and I am personally
>> highly susceptible to those.
>
>
> I can understand that it might be demotivating for you, but that is not a
> blocker. A blocker has no reasonable workaround. This has a trivial
> workaround:
>
>gdc -simd=AFX foo.d
>
> becomes:
>
>gdc -simd=AFX -version=AFX foo.d
>
> It's even simpler if you use a makefile variable:
>
> FPU=AFX
>
> gdc -simd=$(FPU) -version=$(FPU)

Sure. I've done this in my own tests. I just never published that
anyone else should do it.


> You also mentioned being blocked (i.e. demotivated) for *years* by this, and
> I assume that may be because we don't care about SIMD support. That would be
> wrong, as I care a lot about it. But I had no idea you were having a problem
> with this, as you did not file any bug reports. Suffering in silence is
> never going to work :-)

There's been threads, but sure, I could have done more to push it along.
Motivation is a complex and not particularly logical emotion, there's
a lot of factors feeding into it.

Not least of which, is that I haven't been working in games for a
while, which means I haven't depended on it for my work. Don't take
that to read I have lost interest in the support, just that the
pressure is reduced.
You'll have noticed that C++ interaction is my recent focus, since
that's directly related to my current day-job, and the path that I
need to solve now to get D into my work.
That's consuming almost 100% of my D-time-allocation... if I could
ever manage to just kick that goal, it might free me up >_< .. I keep
on trying.


>>> 2. I'm not sure these global settings are the best approach, especially
>>> if
>>> one is writing applications that dynamically adjusts based on the CPU the
>>> user is running on.
>>
>>
>> They are necessary to provide a baseline. It is typical when building
>> code that you specify a min-spec. This is what's used by default
>> throughout the application.
>
>
> It is not necessary to do it that way. Call std.cpuid to determine what is
> available at runtime, and issue an error message if not. There is no runtime
> cost to that. In fact, it has to be done ANYWAY, as it isn't user friendly
> to seg fault trying to execute instructions that do not exist.

The author still needs to be able to control at compile-time what
min-spec shall be supported.
I agree the check is valuable, but I think it's an unrelated detail.


>> Runtime selection is not practical in a broad sense. Emitting small
>> fragments of SIMD here and there will probably take a loss if they are
>> all surrounded by a runtime selector. SIMD is all about pipelining,
>> and runtime branches on SIMD version are antithesis to good SIMD
>> usage; they can't be applied for small-scale deployment.
>> In my experience, runtime selection is desirable for large scale
>> instantiations at an outer level of the work loop. I've tried to
>> design this intent in my library, by making each simd API capable of
>> receiving SIMD version information via template arg, and within the
>> library, the version is always passed through to dependent calls.
>> The Idea is, if you follow this pattern; propagating a SIMD version
>> template arg through to your outer function, then you can instantiate
>> your higher-level work function for any number of SIMD feature
>> combinations you feel is appropriate.
>
>
> Doing it at a high level is what I meant, not for each SIMD code fragment.

Sure, so you agree we need a mechanism for the author to tune the
default selection then? Or are you suggesting SSE2 is 'fine' as a
default? (ie, that is what is implied by D_SIMD)


>> Naturally, this process requires a default, otherwise this usage
>> baggage will cloud the API everywhere (rather than in the few cases
>> where a developer specifically wants to make use of it), and many
>> developers in 2015 feel SSE2 is a weak default. I would choose SSE4.1
>> in my applications, xbox developers would choose AVX1, it's very
>> application/target-audience specific, but SSE2 is the only reasonable
>> selection if we are not to accept a hint from the command line.
>
>
> I still don't see how it is a problem to do the switch at a high level.

It's not a problem, that's exactly my design, but it's not a universal solution.

> Heck, you could put the ENTIRE ENGINE inside a template, have a template
> parameter be the instruction set, and instantiate the template for each
> 

Re: __traits(compiles) and template instantiation

[jkpl via Digitalmars-d-learn]

On Thursday, 7 April 2016 at 21:36:37 UTC, Alex Parrill wrote:

On Thursday, 7 April 2016 at 20:31:12 UTC, jmh530 wrote:
I've been playing around with __traits and I find myself 
confused on one aspect. In the code below, I was testing 
whether some templates would compile given types. For the most 
part it works as I would expect.

[...]

Neither the third nor sixth lines should be true.

alias wrongfoo = foo!int; /* Error: template instance 
foo!int does not match template declaration foo(T, U)(T x, U y) 
if (isNumeric!T && isNumeric!U) */

alias rightfoo = foo!(int, int); /* ok */

File a DMD bug.

(Also, you can use static assert here to check the assertions 
at build-time instead of run-time)


is(typeof()) gives the expected results:

import std.traits : isNumeric;
import std.range : isInputRange;

void foo(T, U)(T x, U y) if (isNumeric!T && isNumeric!U) { }

void bar(T, U)(T x, U y) if (isNumeric!T && isInputRange!U) { }

unittest
{
static assert(is(typeof(foo!(int, int;  //I get this
static assert(!is(typeof(foo!(bool, bool;   //I get this
static assert(!is(typeof(foo!(int;  //I think I get this
static assert(is(typeof(bar!(int, int[];//I get this
static assert(!is(typeof(bar!(int, int; //I get this
static assert(!is(typeof(bar!(int;  //I don't get this
}

(note well I have changed the assertion 3 and 6).

There must be a subtle difference between __traits(compile,...) 
and is(typeof()).
Does "compiles" mean that you've get something but that this 
thing is not always of a valid type ?

Re: DConf 2016 registrations have now hit 128!

[Walter Bright via Digitalmars-d-announce]

132 today!

Re: The day before DConf 2016

[Walter Bright via Digitalmars-d]

On 4/7/2016 11:13 AM, Mike Parker wrote:

I'm flying in to Berlin late on May 2nd. I'll be staying at the Hotel Ibis,
slated to be the "unofficial hangout place" according to the DConf site. I'm
curious who else will be in the area on the 3rd. I'm usually an explorer when I
visit a city for the first time, but on this trip I'd be more interested in
hanging out with others from DLand, conversing about our favorite language, if
anyone's up for it.


I'm arriving Sunday afternoon and plan to spend the next 2 days sightseeing. 
Berlin is a very historic city, and I want to cram in as much as I can :-)


I was there in 1969, and want to visit the same sites and do "now and then" 
retakes of old pictures I have.

Re: __traits(compiles) and template instantiation

[Alex Parrill via Digitalmars-d-learn]

On Thursday, 7 April 2016 at 20:31:12 UTC, jmh530 wrote:
I've been playing around with __traits and I find myself 
confused on one aspect. In the code below, I was testing 
whether some templates would compile given types. For the most 
part it works as I would expect.


I think I get why the third one works with foo!(int). My guess 
is that it assumed that U is the same as T and both are int. 
However, that wouldn't make sense with the last one where I use 
bar!(int). In that one it's basically ignoring the second 
template constraint. So I don't understand what's going on for 
that last line to compile. To confirm I wasn't crazy, I get an 
error with

alias bar_ = bar!(int);



import std.traits : isNumeric;
import std.range : isInputRange;

void foo(T, U)(T x, U y) if (isNumeric!T && isNumeric!U) { }

void bar(T, U)(T x, U y) if (isNumeric!T && isInputRange!U) { }

void main()
{
assert(__traits(compiles, foo!(int, int))); //I get this
assert(!__traits(compiles, foo!(bool, bool)));  //I get this
assert(__traits(compiles, foo!(int)));  //I think I get this
assert(__traits(compiles, bar!(int, int[])));   //I get this
assert(!__traits(compiles, bar!(int, int)));//I get this
assert(__traits(compiles, bar!(int)));  //I don't get this
}


Neither the third nor sixth lines should be true.

alias wrongfoo = foo!int; /* Error: template instance foo!int 
does not match template declaration foo(T, U)(T x, U y) if 
(isNumeric!T && isNumeric!U) */

alias rightfoo = foo!(int, int); /* ok */

File a DMD bug.

(Also, you can use static assert here to check the assertions at 
build-time instead of run-time)

Re: Unexpected Crash

[Ali Çehreli via Digitalmars-d-learn]

On 04/07/2016 01:49 PM, default0 wrote:

On Thursday, 7 April 2016 at 20:47:35 UTC, Adam D. Ruppe wrote:

On Thursday, 7 April 2016 at 20:42:17 UTC, default0 wrote:

If I enter "5,5,5" on the commandline, hit enter, then enter "5,5,5"



When you hit enter, that puts a \n character in the buffer. readf
doesn't skip that automatically, so it complains upon hitting that
newline (the error message shows the character *after* it though,
which sucks).


But what you want to do is to read whitespace too. I think putting a
space in the format string at the beginning or end will do it (I don't
use readf often though).


Changing the format string to "%d,%d,%d\n" fixed the problem. Would've
figured if the error complained about '\n' instead of '5'.


Which compiler version? This is fixed:

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

It's now better but \n may be hard to decode from the following message:

std.conv.ConvException@/usr/include/dmd/phobos/std/conv.d(2002): 
Unexpected '

' when converting from type LockingTextReader to type int

Ali

Re: The day before DConf 2016

[Timon Gehr via Digitalmars-d]

On 07.04.2016 22:17, Nordlöw wrote:

On Thursday, 7 April 2016 at 18:13:16 UTC, Mike Parker wrote:

I'm flying in to Berlin late on May 2nd. I'll be staying at the Hotel
Ibis, slated to be the "unofficial hangout place" according to the
DConf site. I'm curious who else will be in the area on the 3rd. I'm
usually an explorer when I visit a city for the first time, but on
this trip I'd be more interested in hanging out with others from
DLand, conversing about our favorite language, if anyone's up for it.


Both Hotel Ibis and Hotel Britz were already booked.
...


I actually rejected an offer I got from Hotel Britz yesterday.


...
Does anyone have any other recommendations for hotels nearby?
...


I'm staying at Hotel Britzer Tor.


I'm arriving Tuesday evening.


Me too.

Re: The day before DConf 2016

[Mathias Lang via Digitalmars-d]

2016-04-07 22:17 GMT+02:00 Nordlöw via Digitalmars-d <
digitalmars-d@puremagic.com>:

> Is
>
> Paul-Lincke-Ufer 39-40, 10999 Berlin, Tyskland
>
> the correct adress?
>

Nope. The conference will be held on Karl-Marx Str. 141 (
http://dconf.org/2016/venue.html).

Re: Unexpected Crash

[default0 via Digitalmars-d-learn]

On Thursday, 7 April 2016 at 20:47:35 UTC, Adam D. Ruppe wrote:

On Thursday, 7 April 2016 at 20:42:17 UTC, default0 wrote:
If I enter "5,5,5" on the commandline, hit enter, then enter 
"5,5,5"



When you hit enter, that puts a \n character in the buffer. 
readf doesn't skip that automatically, so it complains upon 
hitting that newline (the error message shows the character 
*after* it though, which sucks).



But what you want to do is to read whitespace too. I think 
putting a space in the format string at the beginning or end 
will do it (I don't use readf often though).


Changing the format string to "%d,%d,%d\n" fixed the problem. 
Would've figured if the error complained about '\n' instead of 
'5'.

Re: Get VTable pointer as a constant

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

On Thursday, 7 April 2016 at 20:43:04 UTC, Johan Engelen wrote:
Does anybody know how to get the class's vtable pointer without 
doing a memory read?



I don't think you can... why do you want it though?

Re: Unexpected Crash

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

On Thursday, 7 April 2016 at 20:42:17 UTC, default0 wrote:
If I enter "5,5,5" on the commandline, hit enter, then enter 
"5,5,5"



When you hit enter, that puts a \n character in the buffer. readf 
doesn't skip that automatically, so it complains upon hitting 
that newline (the error message shows the character *after* it 
though, which sucks).



But what you want to do is to read whitespace too. I think 
putting a space in the format string at the beginning or end will 
do it (I don't use readf often though).

Get VTable pointer as a constant

[Johan Engelen via Digitalmars-d-learn]

I am trying to get the vtable pointer as a constant (!).
I've found
  auto vptr = typeid(A).vtbl.ptr
gets me the pointer, but because TypeInfo is not immutable 
(another forum thread), this will read the pointer from memory 
instead of loading a direct value.


Does anybody know how to get the class's vtable pointer without 
doing a memory read?


Thanks!
  Johan

Unexpected Crash

[default0 via Digitalmars-d-learn]

Consider the following program:

import std.stdio;

void main(string[] args) {
int a, b, c;
while(true) {
readf("%d,%d,%d", , , );
writeln(a, b, c);
}
}

If I enter "5,5,5" on the commandline, hit enter, then enter 
"5,5,5" a second time, hit enter again, the second time it 
crashes. Why? What am I getting wrong here?


The error I am getting is the following:
std.conv.ConvException@/usr/include/dmd/phobos/std/conv.d(2002): 
Unexpected '5' when converting from type LockingTextReader to 
type int


/usr/include/dmd/phobos/std/conv.d:58 int std.conv.parse!(int, 
std.stdio.LockingTextReader).parse(ref 
std.stdio.LockingTextReader) [0x440072]
/usr/include/dmd/phobos/std/conv.d:2226 int std.conv.parse!(int, 
std.stdio.LockingTextReader).parse(ref 
std.stdio.LockingTextReader, uint) [0x43fd63]
/usr/include/dmd/phobos/std/format.d:4383 int 
std.format.unformatValue!(int, std.stdio.LockingTextReader, 
char).unformatValue(ref std.stdio.LockingTextReader, ref 
std.format.FormatSpec!(char).FormatSpec) [0x43f529]
/usr/include/dmd/phobos/std/format.d:631 uint 
std.format.formattedRead!(std.stdio.LockingTextReader, char, 
int*, int*, int*).formattedRead(ref std.stdio.LockingTextReader, 
const(char)[], int*, int*, int*) [0x43a452]
/usr/include/dmd/phobos/std/stdio.d:1661 uint 
std.stdio.File.readf!(int*, int*, int*).readf(const(char[]), 
int*, int*, int*) [0x43a391]
/usr/include/dmd/phobos/std/stdio.d:3331 uint 
std.stdio.readf!(int*, int*, int*).readf(const(char[]), int*, 
int*, int*) [0x43a2a7]

source/app.d:47 _Dmain [0x43a253]
??:? 
_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv 
[0x44852a]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).tryExec(scope void delegate()) [0x448468]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).runAll() [0x4484e6]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).tryExec(scope void delegate()) [0x448468]

??:? _d_run_main [0x4483c5]
??:? main [0x4445f7]
??:? __libc_start_main [0x2a3f]

__traits(compiles) and template instantiation

[jmh530 via Digitalmars-d-learn]

I've been playing around with __traits and I find myself confused 
on one aspect. In the code below, I was testing whether some 
templates would compile given types. For the most part it works 
as I would expect.


I think I get why the third one works with foo!(int). My guess is 
that it assumed that U is the same as T and both are int. 
However, that wouldn't make sense with the last one where I use 
bar!(int). In that one it's basically ignoring the second 
template constraint. So I don't understand what's going on for 
that last line to compile. To confirm I wasn't crazy, I get an 
error with

alias bar_ = bar!(int);



import std.traits : isNumeric;
import std.range : isInputRange;

void foo(T, U)(T x, U y) if (isNumeric!T && isNumeric!U) { }

void bar(T, U)(T x, U y) if (isNumeric!T && isInputRange!U) { }

void main()
{
assert(__traits(compiles, foo!(int, int))); //I get this
assert(!__traits(compiles, foo!(bool, bool)));  //I get this
assert(__traits(compiles, foo!(int)));  //I think I get this
assert(__traits(compiles, bar!(int, int[])));   //I get this
assert(!__traits(compiles, bar!(int, int)));//I get this
assert(__traits(compiles, bar!(int)));  //I don't get this
}

Re: I want this so badly, please implement

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 7 April 2016 at 19:25:57 UTC, Steven Schveighoffer 
wrote:
I hear you. I'm actually fervently on the side of having a seg 
fault printout of some kind (an exception may not be the best 
choice because with a seg fault, you can't trust the stack).


Aye. I'm personally a bit lukewarm on it now because it is 
possible to enable core dumps... but I often don't think to do it 
until it is too late. So it would be really nice if it just 
worked.


But I'd make the dereferences generated in the compiler to do 
check it:


byte* a;
*a = 0;

Could be magically compiled into `a || 
makeNullPointerException(line), *a`, just like it does for 
pointers.


In that case, throwing the Error should actually be OK because it 
is caught before attempting to use it.




I guess the difficulty though is:

struct A { int a; int b; }
A* ptr;
ptr.b = 0;


because then, the pointer is null, but the pointer+offset isn't, 
so maybe the codegen needs to be a big different. But the same 
principle should apply - if the ptr is checked before attempting 
the change, it is exactly the same as a RangeError - "safe" to 
throw because the write hasn't actually occurred yet.


(I say "safe" with scare quotes because it is still a bug and 
still not supposed to actually be recovered, you are supposed to 
let the program die, but the error throw mechanism should be 
fairly ok.)


I'm sure you are in a similar situation with this. 
Instrumenting and running again is not only costly and time 
consuming, but may even subvert the actual problem (especially 
if it's timing sensitive).


Absolutely, and it is also really annoying when it happens 
because of a user request.


So a web server dies with a RangeError because of some POST data. 
What was the user submission that killed it? POST data isn't 
ordinarily logged, so I have no idea and cannot reproduce. (I 
typically just add assertions around it and try to debug from the 
code without knowing the data.)



But, there's another thing that bothers me, and that is in the 
development process: I like to quickly guess and check programs 
over realistic data. Sometimes it can take a minute for the 
program to run (like I said, there might be millions of lines) 
and I'm trying to just quickly hammer this "script" out. Having 
to stop, add log spamming, and run again kills the good attitude.


If I wanted to fight my programming language, I wouldn't be using 
D!

Re: I want this so badly, please implement

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 7 April 2016 at 16:22:17 UTC, Daniel Murphy wrote:

you'll need to copy elems to temps when they're
used multiple times to avoid the multiple-references 
asserts/ICEs.



Well, I copied the elemns using el_same and it all compiles, but 
I realize this calls module.__array, which is a generated 
function in glue.c, and doesn't forward the arguments :(


Blah, so gotta change that too.

Check genhelpers() in glue.c, it has "// Get sole parameter, 
linnum" but it isn't the sole param anymore :(



I kinda wish it just generated a code string and compiled tha, 
it'd certainly be easier for us n00bs.




But, could you take a look at this and tell me how it looks?

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

Re: The day before DConf 2016

[Nordlöw via Digitalmars-d]

On Thursday, 7 April 2016 at 18:13:16 UTC, Mike Parker wrote:
I'm flying in to Berlin late on May 2nd. I'll be staying at the 
Hotel Ibis, slated to be the "unofficial hangout place" 
according to the DConf site. I'm curious who else will be in 
the area on the 3rd. I'm usually an explorer when I visit a 
city for the first time, but on this trip I'd be more 
interested in hanging out with others from DLand, conversing 
about our favorite language, if anyone's up for it.


Both Hotel Ibis and Hotel Britz were already booked.

Is

Paul-Lincke-Ufer 39-40, 10999 Berlin, Tyskland

the correct adress?

Does anyone have any other recommendations for hotels nearby?

I'm arriving Tuesday evening.

[Issue 15886] Add an uncaught exception handler

[via Digitalmars-d-bugs]

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

--- Comment #5 from Vladimir Panteleev  ---
Well, yes, exception objects often contain information about the error which
otherwise can be difficult to obtain directly from the debugger, such as the
error message (obviously), the file name / line number where the exception was
created (which may not be in the stack trace), and other exception fields for
custom exception types.

--

[Issue 15886] Add an uncaught exception handler

[via Digitalmars-d-bugs]

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

--- Comment #4 from Marenz  ---
>It's very difficult to print the exception object from within abort()'s stack 
>frame, because the exception object may be optimized out and not easily 
>available from the debugger.

Hm that seems true, I don't seem to be getting any access to it at all because
the druntime is not compiled with debugging I guess.

But do you really need that if you have the whole stack available including the
place where it was thrown from?

--

[Issue 15886] Add an uncaught exception handler

[via Digitalmars-d-bugs]

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

--- Comment #3 from Vladimir Panteleev  ---
(In reply to Marenz from comment #1)
> > Currently, rt.dwarfeh calls terminate(__LINE__) which calls abort()
> 
> If abort() is called that will — outside of a debugger — create a core dump
> allowing you to investigate the memory state at the place where the
> exception was thrown. 
> 
> I don't see why you would need a hook here?

A hook is not *NEEDED* but it sure as heck will help. It's very difficult to
print the exception object from within abort()'s stack frame, because the
exception object may be optimized out and not easily available from the
debugger.

(In reply to Marenz from comment #2)
> The bigger problems I found are that you can't set rt_trapExceptions to 0
> from inside your program or through environment variables / command line
> parameters.

Yes, that would be nice (though it does not absolve my need for this
enhancement). It's trivial to set it from within gdb (break main / run / set
rt_trapExceptions=0 / continue).

It could probably also be made settable via environment variables or the
command line, like the GC tuning parameters.

> That's why I created 
> 
> https://github.com/D-Programming-Language/druntime/pull/1538
> 
> and 
> 
> https://github.com/D-Programming-Language/druntime/pull/1537

Nice.

--

[Issue 15895] New: Make rt_trapExceptions apply to fibers as well

[via Digitalmars-d-bugs]

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

  Issue ID: 15895
   Summary: Make rt_trapExceptions apply to fibers as well
   Product: D
   Version: D2
  Hardware: x86_64
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: dmdtrac...@supradigital.org

rt_trapExceptions is meant to avoid trapping of exceptions.

However, Exceptions thrown from Fibers are still trapped making the option only
usable for code that avoids fibers.

This PR changes the code flow so that the rt_trapExceptions is respected for
fibers as well.

https://github.com/D-Programming-Language/druntime/pull/1537

--

[Issue 15894] New: Allow setting of rt_trapExceptions from module c'tors

[via Digitalmars-d-bugs]

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

  Issue ID: 15894
   Summary: Allow setting of rt_trapExceptions from module c'tors
   Product: D
   Version: D2
  Hardware: x86_64
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: dmdtrac...@supradigital.org

If you want a proper core dump upon an assert failure (or generally a uncaught
exception), you have to set rt_trapExceptions to 0. 

You can't do that however without either compiling your own runtime or
attaching a debugger and setting it from there before main() is called.

While you can change the variable (as it is a global extern (C), your change
has no effect because all user code is run only after the variable has been
read.

This PR changes the behavior so that changes to that variable done from a
module c'tor will cause your main() to be called without the exception trap:

https://github.com/D-Programming-Language/druntime/pull/1538

--

Re: I want this so badly, please implement

[Steven Schveighoffer via Digitalmars-d]

On 4/7/16 2:14 PM, Adam D. Ruppe wrote:

On Thursday, 7 April 2016 at 17:55:20 UTC, Steven Schveighoffer wrote:

Can't you throw a segfault in the handler? The information is still
there on the stack, no?


Yes, of course, I can also printf the indexes myself. But the error
could also carry a bit more useful information by default - and
practically for free!


I'm even actually almost sold on the null pointer exception people ask
for. It has more cost than a RangeError with index (seriously, the index
and length are *already loaded* in registers for the comparison, it
really is as close to free as you can get), but the convenience of the
message by default is nice - and you can still get the nice segfault
when actually running in the debugger by breaking on the handler or
whatever.


I hear you. I'm actually fervently on the side of having a seg fault 
printout of some kind (an exception may not be the best choice because 
with a seg fault, you can't trust the stack).


Having to deal with real world situations where a program runs for weeks 
and fails on a customer's system, just having "Segmentation Fault" 
staring at you is no help at all.


I'm sure you are in a similar situation with this. Instrumenting and 
running again is not only costly and time consuming, but may even 
subvert the actual problem (especially if it's timing sensitive).


-Steve

[Issue 15886] Add an uncaught exception handler

[via Digitalmars-d-bugs]

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

--- Comment #2 from Marenz  ---
The bigger problems I found are that you can't set rt_trapExceptions to 0 from
inside your program or through environment variables / command line parameters.

So you never actually have a core dump generated other then when started
through a debugger (the comments for that variable claim a debugger would set
it to 0).

Another problem is that fibers also have an exception trap so the switch
doesn't even have an effect there. 

That's why I created 

https://github.com/D-Programming-Language/druntime/pull/1538

and 

https://github.com/D-Programming-Language/druntime/pull/1537

--

[Issue 15886] Add an uncaught exception handler

[via Digitalmars-d-bugs]

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

Marenz  changed:

   What|Removed |Added

 CC||dmdtrac...@supradigital.org

--- Comment #1 from Marenz  ---
> Currently, rt.dwarfeh calls terminate(__LINE__) which calls abort()

If abort() is called that will — outside of a debugger — create a core dump
allowing you to investigate the memory state at the place where the exception
was thrown. 

I don't see why you would need a hook here?

--

Re: The day before DConf 2016

[Steven Schveighoffer via Digitalmars-d]

On 4/7/16 2:13 PM, Mike Parker wrote:

I'm flying in to Berlin late on May 2nd. I'll be staying at the Hotel
Ibis, slated to be the "unofficial hangout place" according to the DConf
site. I'm curious who else will be in the area on the 3rd. I'm usually
an explorer when I visit a city for the first time, but on this trip I'd
be more interested in hanging out with others from DLand, conversing
about our favorite language, if anyone's up for it.


I'm landing on the afternoon of the 3rd. I'll finally have to experience 
what everyone outside the US has been for the last 3 with the time 
change :) Also, having a red-eye isn't going to help...


Will see you guys all in the Lobby!

Regarding exploring, I'm in Berlin all day Saturday (7th). Anyone going 
to do anything that day?


Now I definitely have to pack my copy of Learning D :)

-Steve

Re: the most D-ish GUI library

[Jacob Carlborg via Digitalmars-d]

On 2016-04-07 00:18, Nick Sabalausky wrote:


Last I used OSX even Apple's own programs were fairly inconsistent with
each other. I guess that's changed?


Not sure what you're referring to.


In what ways does Qt stuff not look native on OSX?


I don't have a really good example that is Qt and not the application. 
One example that might be Qt is that most modal dialogs on OS X are 
action sheets. That is, a dialog that is attached to a window. Other 
examples are the main toolbar and preference windows. The rows of the 
colors in tables are wrong. I don't know what Qt offers so I don't 
really know if it's Qt or the application.


The icons for a Qt application usually looks alien but that's more a 
choice for the application than the framework, I would guess.



How does it compare  to GTK on OSX?


Well, GTK doesn't even try to look native. It looks as it does on Linux, 
at least last time I used it. They actually have a native application 
menu now days.


--
/Jacob Carlborg

Re: The day before DConf 2016

[Jacob Carlborg via Digitalmars-d]

On 2016-04-07 20:13, Mike Parker wrote:

I'm flying in to Berlin late on May 2nd. I'll be staying at the Hotel
Ibis, slated to be the "unofficial hangout place" according to the DConf
site. I'm curious who else will be in the area on the 3rd. I'm usually
an explorer when I visit a city for the first time, but on this trip I'd
be more interested in hanging out with others from DLand, conversing
about our favorite language, if anyone's up for it.


I'm landing the 1st of May and are also staying at the Hotel Ibis. I'll 
be doing some sightseeing before the conference.


--
/Jacob Carlborg

Re: how to parse a string into a phobos datatype with additional logic

[Ali Çehreli via Digitalmars-d-learn]

On 04/07/2016 11:35 AM, Ali Çehreli wrote:

On 04/07/2016 11:29 AM, Jonathan M Davis via Digitalmars-d-learn wrote:

On Thursday, April 07, 2016 07:45:06 yawniek via Digitalmars-d-learn
wrote:

what is the way one is supposed to parse e.g. a
double of unixtime (as delived by nginx logs) into a SysTime?

currently i'm creating a wrapper struct around SysTime with alias
this as:

https://gist.github.com/yannick/6caf5a5184beea0c24f35d9d4a4c7783

really ugly imho.

is there a better way to do this?


Functions like format, to, etc. all use toString and constructors when
dealing with conversions to and from string. There is no way to provide a
custom conversion function for them to use with a type instead of what's
built into the type.


I think FormatSpec (and the undocumented FormatElement?) comes close:

   http://dlang.org/phobos/std_format.html#.FormatSpec

Ali



I don't agree with myself anymore. :)

Ail

Re: how to parse a string into a phobos datatype with additional logic

[yawniek via Digitalmars-d-learn]

On Thursday, 7 April 2016 at 18:29:19 UTC, Jonathan M Davis wrote:
On Thursday, April 07, 2016 07:45:06 yawniek via 
Digitalmars-d-learn wrote:
So, while I understand your frustration, I just don't see any 
other sane way to approach this problem than what you've done. 
Putting it all in a wrapper type encapsulates it in a way that 
it can actually work, whereas the other options get messy 
really fast if they're possible at all.


- Jonathan M Davis


thank you Jonathan for the extensive answer, really helpful.
And the Longer i think about it the more i come to the conclusion 
that its actually not even that ugly as it allows you to easily 
add more logic to the structs if needed.


i already extensively alias standard datatypes to another name 
where it is used in a specific context (latest example: alias 
ColumnName = string) and it became helpful because you can easily 
refactor it to something bigger.

Re: The day before DConf 2016

[Jonathan M Davis via Digitalmars-d]

On Thursday, April 07, 2016 18:13:16 Mike Parker via Digitalmars-d wrote:
> I'm flying in to Berlin late on May 2nd. I'll be staying at the
> Hotel Ibis, slated to be the "unofficial hangout place" according
> to the DConf site. I'm curious who else will be in the area on
> the 3rd. I'm usually an explorer when I visit a city for the
> first time, but on this trip I'd be more interested in hanging
> out with others from DLand, conversing about our favorite
> language, if anyone's up for it.

I'm staying at Hobel Ibis as well and showing up on Sunday morning
(primarily due to which flights were cheapest), and I'm not much of a
sightseer, so I expect that I'll be at the hotel, and I expect that there
will be other D folks hanging out there a day or two before the conference,
though how many would be in the lobby where you could find them without
posting about it first, I don't know. :) But I expect that I'll see you
there.

- Jonathan M Davis

Re: how to parse a string into a phobos datatype with additional logic

[Ali Çehreli via Digitalmars-d-learn]

On 04/07/2016 11:29 AM, Jonathan M Davis via Digitalmars-d-learn wrote:

On Thursday, April 07, 2016 07:45:06 yawniek via Digitalmars-d-learn wrote:

what is the way one is supposed to parse e.g. a
double of unixtime (as delived by nginx logs) into a SysTime?

currently i'm creating a wrapper struct around SysTime with alias
this as:

https://gist.github.com/yannick/6caf5a5184beea0c24f35d9d4a4c7783

really ugly imho.

is there a better way to do this?


Functions like format, to, etc. all use toString and constructors when
dealing with conversions to and from string. There is no way to provide a
custom conversion function for them to use with a type instead of what's
built into the type.


I think FormatSpec (and the undocumented FormatElement?) comes close:

  http://dlang.org/phobos/std_format.html#.FormatSpec

Ali

Re: The day before DConf 2016

[Ali Çehreli via Digitalmars-d]

On 04/07/2016 11:13 AM, Mike Parker wrote:

I'm flying in to Berlin late on May 2nd. I'll be staying at the Hotel
Ibis, slated to be the "unofficial hangout place" according to the DConf
site. I'm curious who else will be in the area on the 3rd. I'm usually
an explorer when I visit a city for the first time, but on this trip I'd
be more interested in hanging out with others from DLand, conversing
about our favorite language, if anyone's up for it.


I'm landing at around noon. Staying at Hotel Britz, two blocks away from 
Hotel Ibis. See you then... :)


Ali

Re: how to parse a string into a phobos datatype with additional logic

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, April 07, 2016 07:45:06 yawniek via Digitalmars-d-learn wrote:
> what is the way one is supposed to parse e.g. a
> double of unixtime (as delived by nginx logs) into a SysTime?
>
> currently i'm creating a wrapper struct around SysTime with alias
> this as:
>
> https://gist.github.com/yannick/6caf5a5184beea0c24f35d9d4a4c7783
>
> really ugly imho.
>
> is there a better way to do this?

Functions like format, to, etc. all use toString and constructors when
dealing with conversions to and from string. There is no way to provide a
custom conversion function for them to use with a type instead of what's
built into the type. So, if you want this to be automatic as you pass the
type around, then AFAIK, your solution is really the only solution.
Certainly, you can create a custom conversion function and use it in your
own code, but nothing else is going to know about it or use it.

But honestly, I don't see how we even _could_ make it possible to provide a
custom conversion function except for having another argument (either an
alias template argument, or a function argument which is a delegate), and
that would mean that everything that might use such a conversion function
would have to accept it. That might work for something like std.conv.to, but
once you're dealing with something like the CSVParser, what's it going to
do? Have every function that might use such a conversion take a template
argument for the conversion function so that it could pass it on to
std.conv.to or std.conv.parse? And what of code that then uses CSVParser?
Does it need to then accept and pass on such conversion functions? And what
if you need more than one conversion function, because you're dealing with
multiple types that you want to convert differently than normal? I just
don't see how that scales.

Really, as annoying as it may be to wrap the type in another type just to
get the conversion, it's by far the cleanest way to do it. I just don't see
how we even _could_ do in a sane way that involved any kind of free
function. That would be like trying to arbitrarily add a constructor or
overloaded operator to a type and have all other code magically use it,
which is pretty much impossible given D's compilation model (e.g. the type
could be being used in a library that was already compiled when you try and
use it in your program), and how on earth would you deal with conflicts? If
two different modules both tried to add a constructor or overloaded operator
to a type, and those conflicted, how would other code know which to use -
especially when this is supposed to be invisible to them?

So, while I understand your frustration, I just don't see any other sane way
to approach this problem than what you've done. Putting it all in a wrapper
type encapsulates it in a way that it can actually work, whereas the other
options get messy really fast if they're possible at all.

- Jonathan M Davis

Re: Another algo for faster sorting

[tsbockman via Digitalmars-d]

On Thursday, 7 April 2016 at 13:32:43 UTC, Andrea Fontana wrote:
Anyway my topic about sort optimization seems not to have a 
good luck if not for benchmark inaccuracy :)


I was planning to respond to your original question, I just 
didn't have time last night...


I don't think that the simple "counting sort" you demonstrated in 
the other thread is particularly useful to have in Phobos, by 
itself:
- It doesn't scale well at all to higher-entropy element 
types, like `int` or `string`.

- It only works on value types, not reference types.
- It's so trivial to implement, that anyone who really needs 
it can write it themselves.


However, what might be really useful is to have a good generic 
implementation of "bucket sort". Using a user-supplied fast hash 
function whose output follows the same ordering as the original 
elements:
1. Move/copy each element into a bucket list chosen by the 
hash function.

2. Sort each individual bucket list using another algorithm.
3. Iterate through all the buckets lists, and move/copy each 
element to the output.


With good design, it should be possible to express counting sort 
for small value types like `bool` and `byte` simply as a 
parameterization of bucket sort. (This would require that the 
bucket list type be parameterized, in addition to the hash 
function.)

Re: is std.algorithm.joiner lazy?

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, April 07, 2016 08:47:15 Puming via Digitalmars-d-learn wrote:
> On Thursday, 7 April 2016 at 08:27:23 UTC, Edwin van Leeuwen
>
> wrote:
> > On Thursday, 7 April 2016 at 08:17:38 UTC, Puming wrote:
> >> On Thursday, 7 April 2016 at 08:07:12 UTC, Edwin van Leeuwen
> >> wrote:
> >>
> >> OK. Even if it consumes the first two elements, then why does
> >> it have to consume them AGAIN when actually used? If the
> >> function mkarray has side effects, it could lead to problems.
> >
> > After some testing it seems to get each element twice, calls
> > front on the MapResult twice, on each element. The first two
> > mkarray are both for first element, the second two for the
> > second. You can solve this by caching the front call with:
> >
> > xs.map!(x=>mkarray(x)).cache.joiner;
>
> Thanks! I added more elements to xs and checked that you are
> right.
>
> So EVERY element is accessed twice with joiner. Better add that
> to the docs, and note the use of cache.

I would note that in general, it's not uncommon for an algorithm to access
front multiple times. So, this really isn't a joiner-specific issue. If
anything, it's map that should get a note in its docs, not joiner. You
really should just expect front to be called multiple times. So, if that's a
problem, use cache. But joiner is not doing anything abnormal.

And it's not even the case that it necessarily makes sense to make a rule of
thumb that ranges should copy front instead of calling it multiple times,
because if front returns by ref, calling front multiple times is likely to
be cheapepr, and while we don't properly support non-copyable types (like
UniquePtr) with ranges right now, we really should, so if anything, it
becomes the case that algorithms should favor calling front multiple times
over copying its value.

So, there are pros and cons involved with copying front vs calling it
multiple times, and I think that both approaches are both pretty common at
this point. So, given how frequently it makes sense for map to allocate
(e.g. to!string(a)), map should probably have a note about cache, but
overall, it's just something that you need to be aware of. Regardless, I
don't think that it makes sense to put anything in joiner's docs about it.

- Jonathan M Davis

Re: I want this so badly, please implement

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 7 April 2016 at 17:55:20 UTC, Steven Schveighoffer 
wrote:
Can't you throw a segfault in the handler? The information is 
still there on the stack, no?


Yes, of course, I can also printf the indexes myself. But the 
error could also carry a bit more useful information by default - 
and practically for free!



I'm even actually almost sold on the null pointer exception 
people ask for. It has more cost than a RangeError with index 
(seriously, the index and length are *already loaded* in 
registers for the comparison, it really is as close to free as 
you can get), but the convenience of the message by default is 
nice - and you can still get the nice segfault when actually 
running in the debugger by breaking on the handler or whatever.

The day before DConf 2016

[Mike Parker via Digitalmars-d]

I'm flying in to Berlin late on May 2nd. I'll be staying at the 
Hotel Ibis, slated to be the "unofficial hangout place" according 
to the DConf site. I'm curious who else will be in the area on 
the 3rd. I'm usually an explorer when I visit a city for the 
first time, but on this trip I'd be more interested in hanging 
out with others from DLand, conversing about our favorite 
language, if anyone's up for it.

Re: I want this so badly, please implement

[Steven Schveighoffer via Digitalmars-d]

On 4/7/16 1:16 PM, Adam D. Ruppe wrote:

On Thursday, 7 April 2016 at 17:03:31 UTC, Kagamin wrote:

The length of data will tell you which data it is?


It tells me more than ABSOLUTELY NOTHING. Between the length and the
index, I can at least get an idea of if there's a broken record or
broken code.


Sounds like code bloat for little gain.


It is already there, just discarded!

D's error handling does this a lot, and there's no reason good for it.
Useless RangeErrors (a segmentation fault would be more helpful!),


Can't you throw a segfault in the handler? The information is still 
there on the stack, no?


-Steve

Re: Another algo for faster sorting

[tsbockman via Digitalmars-d]

On Thursday, 7 April 2016 at 16:23:31 UTC, Jonathan Villa wrote:
...then searching for other sorting algorithms I found 
SHELL-SORT, it's not recursive and it ended being even faster 
than Quicksort (what the heck? xd, well probably the JIT 
compiler).


It would be cool to have a shell sort implementation available 
for small data sets. It's a bad choice in the general case 
though, because its asymptotic scaling is worse than the standard 
O(N log(N)) achieved by stuff like Timsort.


Quicksort is actually bad too, because its worst case asymptotic 
complexity is an embarrassing O(N^2), which makes it highly 
vulnerable to denial-of-service attacks.

Re: How to set padding for base64 encoding

[ag0aep6g via Digitalmars-d-learn]

On 07.04.2016 14:57, rikki cattermole wrote:

Ugh, 2.070.2 definitely has it still.
I have no idea when that changed


I don't think """...""" ever was a thing. You could definitely put 
newlines in normal "..." literals since basically forever. And 
concatenation of adjacent "..." literals is also an old feature. I'm 
fairly certain that """abc""" has always meant ""~"abc"~"". It works, of 
course, but it's the same as just "abc".

Re: I want this so badly, please implement

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 7 April 2016 at 16:22:17 UTC, Daniel Murphy wrote:
If you have a patch I can probably point out the error.  You're 
right that it should be fairly straightforward, although you'll 
need to copy elems to temps when they're used multiple times to 
avoid the multiple-references asserts/ICEs.


That's probably it, I'll try later today and let you know...

Re: I want this so badly, please implement

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 7 April 2016 at 17:03:31 UTC, Kagamin wrote:

The length of data will tell you which data it is?


It tells me more than ABSOLUTELY NOTHING. Between the length and 
the index, I can at least get an idea of if there's a broken 
record or broken code.



Sounds like code bloat for little gain.


It is already there, just discarded!

D's error handling does this a lot, and there's no reason good 
for it. Useless RangeErrors (a segmentation fault would be more 
helpful!), generic Exceptions with random strings instead of 
useful info, dumb crap like enforce discarding easy info. Ugh.

Re: I want this so badly, please implement

[Kagamin via Digitalmars-d]

Maybe set up onRangeError handler to create the process dump? 
Then you will get everything.

Re: I want this so badly, please implement

[Kagamin via Digitalmars-d]

On Thursday, 7 April 2016 at 15:35:31 UTC, Adam D. Ruppe wrote:
A program dies with a RangeError. I don't know why because it 
doesn't tell me any useful information about the failing data.


The length of data will tell you which data it is?

This is quite frustrating because that information is available 
and trivial to attach to the object, but it is just dropped.


Sounds like code bloat for little gain. I'm afraid data length 
and index value are not generally useful to diagnose this 
problem. Throwing the slice can be helpful, but can't be done 
because it can be a static array on stack.

[Issue 14615] std.regex.replaceFirstInto throws exception when no match is found

[via Digitalmars-d-bugs]

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

Dmitry Olshansky  changed:

   What|Removed |Added

   Severity|enhancement |major

--

Re: Another algo for faster sorting

[Jonathan Villa via Digitalmars-d]

On Thursday, 7 April 2016 at 10:58:21 UTC, Dmitry Olshansky wrote:
Coincidentally with another NG thread I'm curious if we can 
special-case our sort for

strings to Three-Way Radix QuickSort which is more efficient:

http://www.drdobbs.com/database/sorting-strings-with-three-way-radix-qui/184410724


The other day I had problems using Quicksort (trying to sorting 
100_000 doubles) causing stackoverflow for so many recursive 
calls (using .NET), then searching for other sorting algorithms I 
found SHELL-SORT, it's not recursive and it ended being even 
faster than Quicksort (what the heck? xd, well probably the JIT 
compiler).


Now you want to sort strings, I don't know in that case, but 
maybe that can be useful, who knows? c:


Here's the link where I got the algorithm (is in visual basic D:)
https://support.microsoft.com/en-us/kb/169617

JV

Re: I want this so badly, please implement

[Daniel Murphy via Digitalmars-d]

On 8/04/2016 1:59 AM, Adam D. Ruppe wrote:


(I thought this would be easy but I keep hitting dmd assert failures.
However, that's probably because I'm a n00b, it probably is easy if you
know the e2ir style.)


If you have a patch I can probably point out the error.  You're right 
that it should be fairly straightforward, although you'll need to copy 
elems to temps when they're used multiple times to avoid the 
multiple-references asserts/ICEs.

Re: Best properly way to destroy a 2 dimensional array?

[Steven Schveighoffer via Digitalmars-d-learn]

On 4/6/16 3:54 PM, Jonathan Villa wrote:

I wrote a little program that given some number it generates a list of
different combinations (represented by a ubyte array), so in the end my
function with name GenerateCombinations(int x) returns a ubyte[][] (list
of arrays of ubytes).

Now the problem is, the quantity of combinations generated are pow(2,
`x`), thus, giving 20 it returns me a list of 1_048_576 arrays of ubyte,
every array has length of `x` so, in the end this function allocates
(seeing the Windows Task Manager) 42 MB of data after input `20` the
first time.

When the list is ready it prints the quantity of combinations given
(combinations.length), after that I added a foreach(ubyte[] a;
combinations) calling destroy to every array and then
destroy(combinations), and before to re-input a new number to generate a
new combination list I call GC.Collect() and GC.minimize().

My question is if I'm doing good calling destroy to those arrays,
because I don't see any change in the quantity of memory the program is
using: In the start it uses 1496 KB, after input `20` it now have 43000
KB (approx.) and if I input again 20 then it sums up to 9 KB.

In the end I don't see some kind of real memory free. I'm doing
something wrong?
That's the reason I'm asking for your advice.

PD: All arrays are constructed with the `new` expression.
PD2: Don't ask me why I don't better do an `int count` instead of
constructing arrays, this little program is going to be part of a more
huge application and I need the combination list.

Regards. JV


You are likely running into the GC being conservative. You are also 
possibly running into an issue where you are expecting the compiler to 
do something with the stack where it may do something else. A classic 
question that is asked on D forums all the time is why when you null 
some variable and then call GC collect, the memory isn't collected. The 
answer is because quite possibly the value is still in a register, and 
the registers must be scanned too.


As for conservatism, if you generate a 1-million element array of 
pointers (each element has a pointer in it), then you have some random 
stack variable that "happens" to point into that giant array (more 
likely in 32-bit systems), then both the array, and all it's pointing at 
gets saved.


Note that destroying an array is equivalent to setting it to null. It 
doesn't write any data to the array itself.


Ironically, your example of this:

foreach(ubyte[] a; combs) destroy(a);

does absolutely nothing. Because all you are doing is setting a to null, 
and a is a local variable.


The only thing that could make a difference is destroying combs, which 
is equivalent to setting combs to null. But like I said, it's possible 
there is still a pointer in registers, or that some other stack variable 
points at your huge array.


-Steve

Re: Best properly way to destroy a 2 dimensional array?

[Jonathan Villa via Digitalmars-d-learn]

On Thursday, 7 April 2016 at 10:05:02 UTC, Andrea Fontana wrote:

On Thursday, 7 April 2016 at 10:02:05 UTC, Andrea Fontana wrote:
On Wednesday, 6 April 2016 at 20:30:33 UTC, Jonathan Villa 
wrote:


Anything change if you wrap your code like:


while ...
{
...
   {
  ubyte[][] ...
  ...
   }

   GC.collect();
   GC.minimieze();
}

?


Or maybe you could try to do:

combs = null;

before collecting.



Yep, I enclosed the ubyte[][] allocation in a new scope, like our 
friend Alex suggested, but nothing seems to change. I'm going to 
try combs = null...


Big news, I've tested my code using Debian x64 8.2 and it really 
frees memory! even without adding `combs = null` (I'm going to 
add it anyway just in case).


So, looks like is some kind of Windows plataform problem. Next 
time I boot on Windows I'm going to add the null assignment and 
hope for results.


Regards!

Re: Fixed-Length Array Sorting

[Andrei Alexandrescu via Digitalmars-d]

On 04/07/2016 09:28 AM, Nordlöw wrote:

On Thursday, 7 April 2016 at 13:09:22 UTC, Andrei Alexandrescu wrote:

This is a good start but we'd need a more principled attack on the
problem. There are optimal sorting networks for a number of small
sizes; a good start is Knuth's TAoCP Volume 3 but there's newer
research as well, which needs to be investigated. A sorting network in
D can be nicely done with variadic template parameters, e.g. this:


Could these fixed-length overloads be reused in the deepest recursions
of existing Phobos algorithms, such as std.algorithm.sorting.sort()


Could and should.


provided that the comparison-predicate matches.


How do you mean that?


Andrei

Re: Issue with 2.071: Regression or valid error?

[Steven Schveighoffer via Digitalmars-d-learn]

On 4/6/16 11:10 AM, Andre wrote:

Hi,

With 2.071 following coding does not compile anymore and somehow I feel
it should compile.
The issue is with line "cat.create();".
Cat is a sub type of Animal. Animal "owns" method create and I want to
call the method
create within the class Animal for cat.

Is the error message "no property create for type 'b.cat'" valid or not?

Kind regards
André

module a;
import b;

class Animal
{
 private void create() {}

 void foo(Cat cat)
 {
 cat.create(); // >> no property create for type 'b.cat'
 }
}

void main() {}

--

module b;
import a;

class Cat: Animal {};


Just FYI, you don't need a semicolon there.



compile with

rdmd a b


Wow, totally agree with you. Compiler shouldn't make you jump through 
this hoop:


void foo(Cat cat)
{
   Animal a = cat;
   a.create();
}

Please file a bug report, not sure why this happened.

-Steve

Re: I want this so badly, please implement

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 7 April 2016 at 07:07:32 UTC, Nordlöw wrote:
Could you please add a test-program with current and wanted 
behaviour?


int[] a = new int[](1);
a[2]; // currently throws RangeError, telling file and line of 
code



I'd like it to throw a RangeError telling file and line of code, 
and idx == 2, length == 1.



The way it works is the compiler, in e2ir.c (unless I'm mistaken) 
turns the index and slice expressions into code. It basically 
generates this code:


((idx < length) || _d_array_bounds(module*, cast(uint) 
line_number)), array.ptr[idx]



What I want it to do is generate this code:


((idx < length) || _d_array_bounds(module*, cast(uint) 
line_number), idx, length), array.ptr[idx]



Just so idx and length is passed to the druntime function.

That's dmd's change. Make sure it covers all the places the array 
bounds functions are called.


(I thought this would be easy but I keep hitting dmd assert 
failures. However, that's probably because I'm a n00b, it 
probably is easy if you know the e2ir style.)


Then, on the druntime side, change the function to accept the 
size_t idx, size_t length in addition to its current args.


Forward them through to the RangeError object (or a subclass), 
which then prints them too.

[Issue 15893] New: std.algorithm.each returns a misleading compile error

[via Digitalmars-d-bugs]

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

  Issue ID: 15893
   Summary: std.algorithm.each returns a misleading compile error
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: tri...@katamail.com

This code:

import std.algorithm : each;

void main()
{

auto arr = [1,2,3];
arr.each!(x => writeln(x));
}

won't compile:

/d768/f609.d(8): Error: template f609.main.each!((x) => writeln(x)).each cannot
deduce function from argument types !()(int[]), candidates are:
/opt/compilers/dmd2/include/std/algorithm/iteration.d(875):   
f609.main.each!((x) => writeln(x)).each(Range)(Range r) if
(isRangeIterable!Range && !isForeachIterable!Range)
/opt/compilers/dmd2/include/std/algorithm/iteration.d(899):   
f609.main.each!((x) => writeln(x)).each(Iterable)(Iterable r) if
(isForeachIterable!Iterable)

The real problem is that x => writeln(x) doesn't compile because you missed
import std.stdio in this case. The same goes if any error exists inside lambda.
But error won't give help you that much (in this case error is easy to spot)

--

Re: Get third part of front-end version number

[Steven Schveighoffer via Digitalmars-d-learn]

On 4/5/16 2:11 PM, Johan Engelen wrote:

On Tuesday, 5 April 2016 at 18:01:05 UTC, Nick Sabalausky wrote:

These days, DMD/DMDFE version numbers are three parts, ex: 2.070.1.

I can get the first two via std.compiler.version_major and
std.compiler.version_minor. Is there a way to get the third part?

I know I can "dmd --help | grep DMD", but that only works for DMD.
GDC's "gdc --version" doesn't appear to show the DMDFE version, and I
have no idea about LDC.


"ldc2 --version" will give you the full DMDFE version it is based on.
E.g.
❯ bin/ldc2 --version
LDC - the LLVM D compiler (dff841):
   based on DMD v2.068.2 and LLVM 3.8.0svn-r262738



Note dmd --version works too. This was added a few releases ago.

As for getting it inside the code itself, I'm not sure. Docs here is how 
std.compiler does it: http://dlang.org/spec/lex.html#specialtokens


Don't see a way to get patch number. Technically, it shouldn't matter, 
as there should be no functional changes in the patches, just regression 
fixes. In other words, anything compiled with 2.x.n should be compilable 
with 2.x.n+1


I realize reality isn't always so nice though.

-Steve

[Issue 14615] std.regex.replaceFirstInto throws exception when no match is found

[via Digitalmars-d-bugs]

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

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

https://github.com/D-Programming-Language/phobos/commit/add07e7ea6815bdfa6f89b12e78f76d0ecaff6fd
Fix issue 14615 - std.regex.replaceFirstInto throws exception when no match is
found

https://github.com/D-Programming-Language/phobos/commit/efd74a5fea9dd7c8c14bf53d192ca2236f9013ef
Merge pull request #4160 from DmitryOlshansky/issue-14615

Fix issue 14615 - std.regex.replaceFirstInto throws exception when no match is
found

--

Re: I want this so badly, please implement

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 7 April 2016 at 09:31:15 UTC, Kagamin wrote:

How do you spend time on it?


A program dies with a RangeError. I don't know why because it 
doesn't tell me any useful information about the failing data. 
This is quite frustrating because that information is available 
and trivial to attach to the object, but it is just dropped.


What I'd actually do in a perfect world is attach the whole array 
to the object:


class RangeError : Error {}
class TypedRangeError(T) : RangeError {
   T[] slice;
   size_t attemptedIndex;
   override string toString() { /* print the above in some 
human-readable way */ }

}


Because then I can see what runtime data specifically caused the 
problem.



But like I said about AAs, adding an array is harder, so I'm 
happy with just the numbers as a compromise - at least then I can 
see what part of the loop is the problem instead of just the line 
of code.




The time sink comes when processing a million items and seeing a 
random RangeError in the middle of processing. file.d:6 is great, 
but which one of the million lines of DATA was the problem? At 
least giving me the index and length narrows that down.


I typically go back and edit the source to print out some kind of 
log info, then wait for it to all run again. Just a frustration - 
one of the few I face regularly in D.

Re: Any usable SIMD implementation?

[Johan Engelen via Digitalmars-d]

On Thursday, 7 April 2016 at 14:46:06 UTC, Johannes Pfau wrote:

Am Thu, 07 Apr 2016 13:27:05 +
schrieb Johan Engelen :


On Thursday, 7 April 2016 at 11:25:47 UTC, Johannes Pfau wrote:
> Am Thu, 07 Apr 2016 10:52:42 +
> schrieb Kai Nacke :
> 
>> glibc has a special mechanism for resolving the called 
>> function during loading. See the section on the GNU 
>> Indirect Function Mechanism here: 
>> https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/W51a7ffcf4dfd_4b40_9d82_446ebc23c550/page/Optimized%20Libraries
>> 
>> Would be awesome to have something similar in 
>> druntime/Phobos.
>> 
>> Regards,

>> Kai
>
> Available in GCC as the 'ifunc' attribute: 
> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes

>
> What do you mean by 'something similar in druntime/phobos'? 
> A platform independent (slightly slower) variant?:

>
> http://dpaste.dzfl.pl/0aa81325a26a

I thought that the ifunc mechanism means an indirect call 
(i.e. a function ptr is set at the start of the program) ? 
That would be the same as what you are doing without 
performance difference.


https://gcc.gnu.org/wiki/FunctionMultiVersioning
"To keep the cost of dispatching low, the IFUNC mechanism is 
used
for dispatching. This makes the call to the dispatcher a 
one-time
thing during startup and a call to a function version is a 
single

jump ** indirect ** instruction." (emphasis mine)


The simple variant I've posted needs an additional branch on 
every function call. If we instead initialize the function 
pointer in a shared static ctor there's indeed no performance 
difference.


Yep exactly.
For @target multiversioned functions, I thought one would want to 
create one static ctor that calls cpuid once and sets all 
function ptrs of that module.



(does `` return `impl`?)


No,  will return the address of the wrapper function. I'm 
not sure if we can solve this. IIRC we can't overload &.


OK. Well, the @target multifunctioning would need compiler 
support anyway and it is easy to do something slightly different 
for `` when foo is a multiversioned function.


This should be fairly easy to implement in LDC, with some smarts 
needed in ordering and selecting the best function version.

Re: So... let's document dmd

[Nick Sabalausky via Digitalmars-d]

On 04/05/2016 05:40 PM, Walter Bright wrote:


I don't really understand why IDE makers don't use an actual programming
language for plugins


Programmer's Notepad 2 uses Python for plugins. Although the syntax 
highlighting is done through Scintilla which has it's own separate 
(non-programming-language IIRC) system for lex/parse.

[Issue 12625] implicit slicing of RValue static array should be illegal

[via Digitalmars-d-bugs]

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

--- Comment #6 from Sobirari Muhomori  ---
Allow sliced temporary to be passed straight to function parameter (sounds like
rvalue reference though), disallow everything else?

--

Re: Any usable SIMD implementation?

[Johannes Pfau via Digitalmars-d]

Am Thu, 07 Apr 2016 13:27:05 +
schrieb Johan Engelen :

> On Thursday, 7 April 2016 at 11:25:47 UTC, Johannes Pfau wrote:
> > Am Thu, 07 Apr 2016 10:52:42 +
> > schrieb Kai Nacke :
> >  
> >> glibc has a special mechanism for resolving the called 
> >> function during loading. See the section on the GNU Indirect 
> >> Function Mechanism here: 
> >> https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/W51a7ffcf4dfd_4b40_9d82_446ebc23c550/page/Optimized%20Libraries
> >> 
> >> Would be awesome to have something similar in druntime/Phobos.
> >> 
> >> Regards,
> >> Kai  
> >
> > Available in GCC as the 'ifunc' attribute: 
> > https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
> >
> > What do you mean by 'something similar in druntime/phobos'? A 
> > platform independent (slightly slower) variant?:
> >
> > http://dpaste.dzfl.pl/0aa81325a26a  
> 
> I thought that the ifunc mechanism means an indirect call (i.e. a 
> function ptr is set at the start of the program) ? That would be 
> the same as what you are doing without performance difference.
> 
> https://gcc.gnu.org/wiki/FunctionMultiVersioning
> "To keep the cost of dispatching low, the IFUNC mechanism is used 
> for dispatching. This makes the call to the dispatcher a one-time 
> thing during startup and a call to a function version is a single 
> jump ** indirect ** instruction." (emphasis mine)

The simple variant I've posted needs an additional branch on every
function call. If we instead initialize the function pointer in a
shared static ctor there's indeed no performance difference. The main
problem here is because of cyclic constructor detection it will be more
difficult to implement a generic template solution.

http://www.airs.com/blog/archives/403
"An alternative to all this linker stuff would be a variable holding a
function pointer. The function could then be written in assembler to do
the indirect jump. The variable would be initialized at program startup
time. The efficiency would be the same. The address of the function
would be the address of the indirect jump, so function pointers would
compare consistently."

> I looked into this some time ago and did not see a reason to use 
> the ifunc mechanism (which would not be available on Windows). I 
> thought it should be implementable in a library, exactly as you 
> did in your dpaste! :-)

> (does `` return `impl`?)

No,  will return the address of the wrapper function. I'm not sure
if we can solve this. IIRC we can't overload &. Here's the alternative
using a constructor which makes the address accessible. The syntax
will still be different though:

__gshared void function() foo;
shared static this()
{
foo = 
}

auto addr =  // address of the variable
addr = cast(void*)foo; // the function address

[Issue 15892] New: Can't use alias this with struct static member

[via Digitalmars-d-bugs]

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

  Issue ID: 15892
   Summary: Can't use alias this with struct static member
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ntrel-...@mybtinternet.com

With dmd 2.070.2:

struct S
{
struct Static
{
static:
int payload;
}
alias Static.payload this; // no identifier for declarator Static.payload

alias get this; // OK
ref @property get(){return Static.payload;}
}

Same error if Static is moved outside of S.

(This pattern is useful for grouping members and methods of S that shouldn't
conflict with the symbol used with alias this).

--

Re: New deb packages on d-apt

[Ilya Korobitsyn via Digitalmars-d-announce]

On Wednesday, 6 April 2016 at 13:06:54 UTC, Jordi Sayol wrote:

d-apt has three new deb packages for Dfix, Dfmt and Dscanner.

$ sudo apt-get install dfix dfmt dscanner

d-apt 


Thank you for this!

[Issue 12625] implicit slicing of RValue static array should be illegal

[via Digitalmars-d-bugs]

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

Nick Treleaven  changed:

   What|Removed |Added

 CC||ntrel-...@mybtinternet.com

--- Comment #5 from Nick Treleaven  ---
(In reply to monarchdodra from comment #2)
> I thought about it some more, and there *are* case where you can slice an
> rvalue static array, provided you've "used" it by the end of the expression.
...
> enum int[3] ints = [1, 2, 3];
> auto s = sum(ints);
...
> - Do we find some way to detect *only* the "rvalue static array to dynamic
> array assignment" case?

Your original example is always wrong:

int[1] foo();
int[] a = foo();

Slicing a returned static array should be disallowed by the compiler. Should we
rename this issue or file a new one for just this?

--

[Issue 15891] New: Compiler error when std.algorithm.cache and std.algorithm.joiner and map composed

[via Digitalmars-d-bugs]

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

  Issue ID: 15891
   Summary: Compiler error when std.algorithm.cache and
std.algorithm.joiner and map composed
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: zhaopum...@gmail.com

I have a range of range of range, which is obtained by two levels of map, I'd
like to flatten it into a simple range, so two joiners are needed.

But I found that joiners are not completely lazy, the front element would be
evaluated (twice!). See discussion here:
http://forum.dlang.org/post/qswryemgvixhpqpyb...@forum.dlang.org. So I need a
cache before the joiner to prevent my map function called twice.

But when two levels of cache.joiner and cache.joiner are composed, the compiler
will complain, see a demo code here:

```
import std.stdio : writeln;
import std.algorithm : map, cache, joiner;
import std.array : array;

auto read(int a) {
   return [0, a]; // second level
}

auto mkarray(int a) {
  return [-a, a].map!(x=>read(x)).cache.joiner; // to avoid calling read twice
}

void main() {
  auto xs = [1,2 ,3, 4];
  auto r = xs.map!(x=>mkarray(x)).array;

  // Both lines below should be equal, but second does not compile
  [[0, -1, 0, 1], [0, -2, 0, 2], [0, -3, 0, 3], [0, -4, 0,
4]].cache.joiner.writeln;
  r.cache.joiner.writeln;
}
```

Above results in following error:
/opt/compilers/dmd2/include/std/algorithm/iteration.d(326): Error: one path
skips field __caches_field_0
/d617/f62.d(19): Error: template instance
std.algorithm.iteration.cache!(Result[]) error instantiating

--

Re: VibeCustomMain not working

[yawniek via Digitalmars-d-learn]

On Thursday, 7 April 2016 at 13:40:17 UTC, Rene Zwanenburg wrote:

On Thursday, 7 April 2016 at 13:25:29 UTC, Jerry wrote:
I generated a visuald project and tried that. Now suddenly it 
is working as expected. So I guess it's a bug in dub.


That's possible of course, but I'd expect something so 
fundamental breaking to be noticed sooner.


Just to make sure, could you run dub with --force to rule out 
that it's picking up some stale object files from somewhere?


i also had it multiple times that my build was broken and not 
even --force would fix it.
then i deleted ~/.dub  and .dub and rebuild everything and 
suddenly it worked.

Re: VibeCustomMain not working

[Rene Zwanenburg via Digitalmars-d-learn]

On Thursday, 7 April 2016 at 13:40:17 UTC, Rene Zwanenburg wrote:
That's possible of course, but I'd expect something so 
fundamental breaking to be noticed sooner.


Just to make sure, could you run dub with --force to rule out 
that it's picking up some stale object files from somewhere?


And if that doesn't work, post the output of dub --force 
--verbose and we should be able to figure out where it goes wrong.

Re: VibeCustomMain not working

[Rene Zwanenburg via Digitalmars-d-learn]

On Thursday, 7 April 2016 at 13:25:29 UTC, Jerry wrote:
I generated a visuald project and tried that. Now suddenly it 
is working as expected. So I guess it's a bug in dub.


That's possible of course, but I'd expect something so 
fundamental breaking to be noticed sooner.


Just to make sure, could you run dub with --force to rule out 
that it's picking up some stale object files from somewhere?

Re: Another algo for faster sorting

[Andrea Fontana via Digitalmars-d]

On Thursday, 7 April 2016 at 10:58:21 UTC, Dmitry Olshansky wrote:
Coincidentally with another NG thread I'm curious if we can 
special-case our sort for

strings to Three-Way Radix QuickSort which is more efficient:

http://www.drdobbs.com/database/sorting-strings-with-three-way-radix-qui/184410724


Radix sort is a very fast way to sort strings and integers . But 
it does not work with a custom " less" function . It just sorts 
date to lexical way .


If phobos had a lexicalSort ( T [ ] , Ascending.YES ) ; probably 
a lot of optimizations could be done for many data types.


Anyway my topic about sort optimization seems not to have a good 
luck if not for benchmark inaccuracy :)



Andrea

Re: VibeCustomMain not working

[Jerry via Digitalmars-d-learn]

On Thursday, 7 April 2016 at 13:17:32 UTC, Jerry wrote:

On Thursday, 7 April 2016 at 13:13:14 UTC, Suliman wrote:

dup upgdare

dub upgdare


Tried that. I have to say this is odd.


I generated a visuald project and tried that. Now suddenly it is 
working as expected. So I guess it's a bug in dub.

Re: Fixed-Length Array Sorting

[Nordlöw via Digitalmars-d]

On Thursday, 7 April 2016 at 13:09:22 UTC, Andrei Alexandrescu 
wrote:
This is a good start but we'd need a more principled attack on 
the problem. There are optimal sorting networks for a number of 
small sizes; a good start is Knuth's TAoCP Volume 3 but there's 
newer research as well, which needs to be investigated. A 
sorting network in D can be nicely done with variadic template 
parameters, e.g. this:


Could these fixed-length overloads be reused in the deepest 
recursions of existing Phobos algorithms, such as 
std.algorithm.sorting.sort() provided that the 
comparison-predicate matches.

Re: Any usable SIMD implementation?

[Johan Engelen via Digitalmars-d]

On Thursday, 7 April 2016 at 11:25:47 UTC, Johannes Pfau wrote:

Am Thu, 07 Apr 2016 10:52:42 +
schrieb Kai Nacke :

glibc has a special mechanism for resolving the called 
function during loading. See the section on the GNU Indirect 
Function Mechanism here: 
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/W51a7ffcf4dfd_4b40_9d82_446ebc23c550/page/Optimized%20Libraries


Would be awesome to have something similar in druntime/Phobos.

Regards,
Kai


Available in GCC as the 'ifunc' attribute: 
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes


What do you mean by 'something similar in druntime/phobos'? A 
platform independent (slightly slower) variant?:


http://dpaste.dzfl.pl/0aa81325a26a


I thought that the ifunc mechanism means an indirect call (i.e. a 
function ptr is set at the start of the program) ? That would be 
the same as what you are doing without performance difference.


https://gcc.gnu.org/wiki/FunctionMultiVersioning
"To keep the cost of dispatching low, the IFUNC mechanism is used 
for dispatching. This makes the call to the dispatcher a one-time 
thing during startup and a call to a function version is a single 
jump ** indirect ** instruction." (emphasis mine)
I looked into this some time ago and did not see a reason to use 
the ifunc mechanism (which would not be available on Windows). I 
thought it should be implementable in a library, exactly as you 
did in your dpaste! :-)  (does `` return `impl`?)

Re: VibeCustomMain not working

[Suliman via Digitalmars-d-learn]

dup upgdare

dub upgdare

Re: VibeCustomMain not working

[Jerry via Digitalmars-d-learn]

On Thursday, 7 April 2016 at 13:13:14 UTC, Suliman wrote:

dup upgdare

dub upgdare


Tried that. I have to say this is odd.

Re: Any usable SIMD implementation?

[9il via Digitalmars-d]

On Thursday, 7 April 2016 at 12:35:51 UTC, jmh530 wrote:

On Thursday, 7 April 2016 at 10:03:50 UTC, 9il wrote:


This is not true for BLAS based on D.


Perhaps if you provide him a simplified example he might see 
what you're talking about?


He know what I am talking about. This is about 
architecture/style/concepts. If Walter disagree with this then 
nobody can change it.

Re: VibeCustomMain not working

[Suliman via Digitalmars-d-learn]

On Thursday, 7 April 2016 at 12:01:59 UTC, Jerry wrote:

Hello, I am trying to use vibe with DMD 2.67, dub and windows.
But in some way the default main function is sneaking in my 
build system even when I'm using VibeCustomMain version.


Main file:

import vibe.vibe;

void main() {
   writeln("Hello world");
}


And dub file:

{
"targetType": "executable",
"versions": [ "VibeCustomMain" ],
"dependencies": {
"luad": "~master",
"kxml": "~>1.0.1",
"jsonizer": "~>0.5.2",
"vibe-d": "==0.7.23"
}
}


I also tried this on DMD 2.71, 2.69 with same results. And I 
even tryed passing in VibeCustomMain manually.


Any ideas?


You need to upgrade to the last dmd and vibed version. AFAIK the 
was issue old releases.


than do:

dup upgdare
dub build

Here is working code:
dub.json:
{
"name": "App",
"targetType": "executable",
"versions": [ "VibeCustomMain" ],
"dependencies": {
"luad": "~master",
"kxml": "~>1.0.1",
"jsonizer": "~>0.5.2",
"vibe-d": "==0.7.29"
}
}

app.d:

import vibe.vibe;
import std.stdio;

void main()
{
writeln("Edit source/app.d to start your project.");
}

Re: Fixed-Length Array Sorting

[Andrei Alexandrescu via Digitalmars-d]

On 04/04/2016 05:36 AM, Nordlöw wrote:

I have some C++ that does optimal sorting of 3 and 4 elements at

https://github.com/nordlow/justcxx/blob/master/sortn.hpp

Would anybody be interesting in getting this integrated into

std.algorithm.sorting

?


This is a good start but we'd need a more principled attack on the 
problem. There are optimal sorting networks for a number of small sizes; 
a good start is Knuth's TAoCP Volume 3 but there's newer research as 
well, which needs to be investigated. A sorting network in D can be 
nicely done with variadic template parameters, e.g. this:


r.conditionalSwap!(less, 0, 2, 1, 3);

expands to:

if (less(r[0], r[1])) r.swapAt(0, 2);
if (less(r[1], r[3])) r.swapAt(1, 3);

so then building a sorting network boils down to writing the right 
sequence of indexes.


We'd need to figure at which point the size of the generated code 
overwhelms any gains made from the specialized routines.


All of the above should be packaged in a routine:

auto sortUpTo(uint n, alias less = "a < b", Range)(Range r);

which asserts that r.length <= n, or maybe two because this is also useful:

auto sortExactly(uint n, alias less = "a < b", Range)(Range r);

which asserts that r.length == n. The documentation specifies the 
largest available n.



Andrei

Re: How to set padding for base64 encoding

[Suliman via Digitalmars-d-learn]

On Thursday, 7 April 2016 at 12:43:54 UTC, rikki cattermole wrote:

On 08/04/2016 12:39 AM, Suliman wrote:
On Thursday, 7 April 2016 at 12:30:59 UTC, rikki cattermole 
wrote:

On 08/04/2016 12:19 AM, Kagamin wrote:
Create a range that would remove the newline characters from 
string,

then decode from that.


Can confirm, its \n and \r that is causing the problems here.


with:
std.file.write("output.png", 
Base64.decode(myimg.replace("\r\n", "")));


I am getting same issue. But it should remove all new lines...


ok split myimg value into another file, remove all \r and \n 
separately via e.g. tr.

Then read it in, that's what I did.


Thanks! That is work!

Re: How to set padding for base64 encoding

[rikki cattermole via Digitalmars-d-learn]

On 08/04/2016 12:52 AM, ag0aep6g wrote:

On 07.04.2016 13:59, rikki cattermole wrote:

"abc" strings are not multiline.
Use """abc""" for that purpose.


Wat. We're talking about, aren't we? In D, "abc" strings are multiline,
and """abc""" is not a thing. `"""abc"""` is the same as `"" "abc" ""`
is the same as `"" ~ "abc" ~ ""` is the same as `"abc"`.


Ugh, 2.070.2 definitely has it still.
I have no idea when that changed