Re: Phobos colour module?

[via Digitalmars-d]

On Tuesday, 6 January 2015 at 09:19:46 UTC, John Colvin wrote:
What's wrong with old-fashioned `Fast` postfixes on entry 
points where a faster but less precise method is available? Or 
template arguments like std.algorithm.SortStrategy?


If this is for phobos it should follow a common model. But since 
a fast implementation might involve an object which builds a 
table before processing


Another problem is that precise is a very loose term if the 
conversion is for display or for composition in a shader. What 
you want depends on the kind of post processing that happens 
after this and how it affects the nonlinearities of human 
perception.

Re: DMD's lexer available on code.dlang.org

[Vadim Lopatin via Digitalmars-d-announce]

On Sunday, 4 January 2015 at 13:09:42 UTC, Rikki Cattermole wrote:

On 5/01/2015 2:07 a.m., Daniel Murphy wrote:
I've created a dub package for the D version of DMD's lexer, 
generated

automatically from the C++ source.

github: https://github.com/yebblies/ddmd
dub: http://code.dlang.org/packages/ddmd

There are a few annoying limitations, such that it uses dmd's 
error
printing and allocation functions, and requires configuration 
through

'global'.

Here is an example program that uses the lexer:

==

import std.stdio;
import std.file;

import ddmd.tokens;
import ddmd.lexer;

/

void main()
{
   Lexer.initLexer();

   string data = void blah() {} // stuff;
   auto l = new Lexer(myfile, data.ptr, 0, data.length, 0, 
0);

   l.nextToken();
   do
   {
   printf(token: %s\n, l.token.toChars());
   }
   while (l.nextToken() != TOKeof);
}

==

Prints:

token: void
token: blah
token: (
token: )
token: {
token: }


I saw that. I'm really looking forward to getting my teeth into 
it and doing some good old refactoring. Although that will be a 
while because of the auto generated thing.


I have a bit similar project - lexer for D written in D.
Written just based on Lexical documentation page.

https://github.com/buggins/ddc

Trying make it fast and to do as few memory allocations as 
possible.

Re: Questions about TDPL book

[Joakim via Digitalmars-d]

On Tuesday, 6 January 2015 at 03:20:27 UTC, weaselcat wrote:
Is it still worth buying TDPL since it's almost 5 years old? I 
realize classics like KR C are near timeless, but D has seen a 
lot of changes.

Has the ebook version been updated at all(i.e, with the errata?)
How is the physical quality of the print book?


Andrei is a very good writer and presenter of ideas, so I'd say 
it's still worth it if you want to learn D.  The book was written 
to some extent as a sort of spec, so there are still features in 
the book that are unimplemented, meaning I don't think you have 
to worry much about changes.  Of course, it isn't continually 
updated like Ali's online book (http://ddili.org/ders/d.en/), so 
it's missing a few recently added features.


I don't know if the ebook is updated, but the physical quality of 
the softcover print book is not good.  Mine fell apart about 
halfway through reading it, it's in 3-4 chunks now.  I wish there 
had been a pdf version available at the time, as I always prefer 
an electronic version and bought the pdf version of Adam's book.  
I wasn't interested in signing up for informIT's book 
subscription service to read it on a screen.

Re: http://wiki.dlang.org/DIP25

[Dominikus Dittes Scherkl via Digitalmars-d]

On Tuesday, 6 January 2015 at 09:11:10 UTC, bearophile wrote:

Dominikus Dittes Scherkl:


Yeah. I wish it would be possilbe to do something like:

alias @smooth = @save pure nothrow @nogc;

and then use this instead.


You most probably want something more principled instead, as 
the algebra of effects of Koka language 
(http://rise4fun.com/Koka/tutorial/guide ) or something even 
better.


Bye,
bearophile


Sounds interesting, but would be hard to cover other attributes 
(or effects) like @save and @nogc within this system.
And I think using alias for creating combined attributes by hand 
would be easy to implement, not breaking any existing code and 
handy enough for most common combinations.
And by the way, this would also allow to define ore remove the @ 
as one wiches:

alias nogc = @nogc;
or vice versa:
alias @pure = pure;

Re: http://wiki.dlang.org/DIP25

[via Digitalmars-d]

On Tuesday, 6 January 2015 at 09:11:10 UTC, bearophile wrote:
You most probably want something more principled instead, as 
the algebra of effects of Koka language 
(http://rise4fun.com/Koka/tutorial/guide ) or something even 
better.


Thanks for sharing the link. I had not heard of Koka before.

Behavioural types

[via Digitalmars-d]

Since D is experimenting with behavioural typing, it might be 
nice to get an overview of the state of the art. Which is what 
survey papers are for:


http://www.behavioural-types.eu/publications/WG1-State-of-the-Art.pdf
http://www.behavioural-types.eu/publications/WG2-State-of-the-Art.pdf
http://www.behavioural-types.eu/publications/WG3-State-of-the-Art.pdf
http://www.behavioural-types.eu/publications

Any thoughts?

Re: Phobos colour module?

[via Digitalmars-d]

On Monday, 5 January 2015 at 23:39:17 UTC, Manu via Digitalmars-d 
wrote:

I'm finding myself at a constant struggle between speed and
maximizing-precision. I feel like a lib should maximise 
precision, but

the trouble then is that it's not actually useful to me...


If you create a pixel converter that aims for speed, the 
programmer might also want it to generate a shader (as text 
string) with exactly the same properties.  It makes less and less 
sense to create a performant imaging library that is CPU only.


I suggest reducing the scope to:

1. Provide generic accurate conversion and iterators for colours 
(or more general; for arrays of spectral values). Useful for 
doing batch like stuff or initialization.


2. Provide fast colour support for transforms that are simple 
enough to not warrant GPU processing, but where you accept the 
cost of building lookup tables before processing. (Build tables 
using (1).)


Very few applications care about colour precision beyond ubyte, 
so I

feel like using double for much of the processing is overkill :/
I'm not sure what the right balance would look like exactly.


I think a precise reference implementation using double is a good 
start. People creating PDFs, SVGs or some other app that does not 
have real time requirements probably want that. It is also useful 
for building LUTs.


One thing to consider is that you also might want to handle 
colour compontents that have negative values or values larger 
than 1.0:


-  it is useful in non-realistic rendering as darklights ( 
http://www.glassner.com/wp-content/uploads/2014/04/Darklights.pdf 
)


- with negative values you can then have a unique representation 
of a single colour in CIE (the theoretical base for RGB that was 
developed in the 1930s).


- it allows the programmer to do his own gamut compression after 
conversion

Re: http://wiki.dlang.org/DIP25

[Dominikus Dittes Scherkl via Digitalmars-d]

On Monday, 5 January 2015 at 22:04:58 UTC, Steven Schveighoffer 
wrote:
Making some way to bundle attributes, or be able to negate 
currently one-way attributes would go a long way IMO.


Yeah. I wish it would be possilbe to do something like:

alias @smooth = @save pure nothrow @nogc;

and then use this instead.

Re: Phobos colour module?

[via Digitalmars-d]

On Tuesday, 6 January 2015 at 08:52:06 UTC, Ola Fosheim Grøstad 
wrote:
- with negative values you can then have a unique 
representation of a single colour in CIE (the theoretical base 
for RGB that was developed in the 1930s).


Actually, what I refer to here is a model of how humans perceive 
colour:


http://en.wikipedia.org/wiki/CIE_1931_color_space#CIE_standard_observer

Re: http://wiki.dlang.org/DIP25

[bearophile via Digitalmars-d]

Dominikus Dittes Scherkl:


Yeah. I wish it would be possilbe to do something like:

alias @smooth = @save pure nothrow @nogc;

and then use this instead.


You most probably want something more principled instead, as the 
algebra of effects of Koka language 
(http://rise4fun.com/Koka/tutorial/guide ) or something even 
better.


Bye,
bearophile

Re: @api: One attribute to rule them All

[John Colvin via Digitalmars-d]

On Tuesday, 6 January 2015 at 09:12:43 UTC, John Colvin wrote:
On Monday, 5 January 2015 at 21:15:00 UTC, Zach the Mystic 
wrote:
Hello everybody. My name is Zach, and I have a suggestion for 
the improvement of D. I've been looking at the following 
stalled pull request for a while now:


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

...in which Walter Bright wants to introduce 
built-in-attribute inference for a relatively small set of 
functions. It seems like the most obvious thing in the world 
to me to desire this, and not even just for 'auto' and 
templated functions, but for *every* function. And there's no 
reason it can't be done. So long as the compiler has 
everything it needs to determine which attributes can be 
applied, there's no reason to demand anything from the 
programmer. Look how simple this function is:


int plusOne(int a) { return a+1; }

Let's say I later want to call it, however, from a fully 
attributed function:


int plusTwo(int a) pure nothrow @safe @nogc  {
 return plusOne(plusOne(a));
}

I get a compiler error. The only way to stop it is to add 
unnecessary visual noise to the first function. All of these 
attributes should be something that you *want* to add, not 
something that you *need*. The compiler can obviously figure 
out if the function throws or not. Just keep an additional 
internal flag for each of the attributes. When any attribute 
is violated, flip the bit and boom, you have your implicit 
function signature.


I think this is how it always should have been. It's important 
to remember that the above attributes have the 'covariant' 
property, which means they can always be called by any 
function without that property. Therefore no existing code 
will start failing to compile. Only certain things which would 
have *errored* before will stop. Plus new optimizations can be 
done.


So what's the problem? As you can read in the vehement 
opposition to pull 1877 above, the big fear is that function 
signatures will start changing willy-nilly, causing the 
exposed interface of the function to destabilize, which will 
cause linker errors or require code intended to be kept 
separate in large projects to be recompiled at every little 
change.


I find this depressing! That something so good should be 
ruined by something so remote as the need for separate 
compilation in very large projects? I mean, most projects 
aren't even very large. Also, because D compiles so much 
faster than its predecessors, is it even such a big deal to 
have to recompile everything?


But let's admit the point may be valid. Yes, under attribute 
inference, the function signatures in the exposed API will 
indeed find themselves changing every time one so much as adds 
a 'printf' or calls something that throws.


But they don't *have* to change. The compiler doesn't need to 
include the inferred attributes when it generates the mangled 
name and the .di signature, only the explicit ones. From 
within the program, all the opportunities for inference and 
optimization could be left intact, while outside programs 
accessing the code in precompiled form could only access the 
functions as explicitly indicated.


This makes no change to the language, except that it allows 
new things to compile. The only hitch is this: What if you 
want the full advantages of optimization and inference from 
across compilation boundaries? You'd have to add each of the 
covariant function attributes manually to every function you 
exposed. From my perspective, this is still a chore.


I suggest a new attribute, @api, which does nothing more than 
to tell the compiler to generate the function signature and 
mangle the name only with its explicit attributes, and not 
with its inferred ones. Inside the program, there's no reason 
the compiler can't continue to use inference, but with @api, 
the exposed interface will be stabilized, should the 
programmer want that. Simple.


I anticipate a couple of objections to my proposal:

The first is that we would now demand that the programmer 
decide whether he wants his exposed functions stabilized or 
not. For a large library used by different people, this choice 
might pose some difficulty. But it's not that bad. You just 
choose: do you want to improve compilation times and/or 
closed-source consistency by ensuring a stable interface, or 
do you want to speed up runtime performance without having to 
clutter your code? Most projects would choose the latter. @api 
is made available for the those who don't. The opposition to 
attribute inference put forth in pull 1877 is thereby appeased.


A second objection to this proposal: Another attribute? 
Really? Well, yeah.


But it's not a problem, I say, for these reasons:

1. This one little attribute allows you to excise gajillions 
of unnecessary little attributes which are currently forced on 
the programmer by the lack of inference, simply by appeasing 
the opponents of inference and allowing it to be 

Re: @api: One attribute to rule them All

[John Colvin via Digitalmars-d]

On Monday, 5 January 2015 at 21:15:00 UTC, Zach the Mystic wrote:
Hello everybody. My name is Zach, and I have a suggestion for 
the improvement of D. I've been looking at the following 
stalled pull request for a while now:


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

...in which Walter Bright wants to introduce built-in-attribute 
inference for a relatively small set of functions. It seems 
like the most obvious thing in the world to me to desire this, 
and not even just for 'auto' and templated functions, but for 
*every* function. And there's no reason it can't be done. So 
long as the compiler has everything it needs to determine which 
attributes can be applied, there's no reason to demand anything 
from the programmer. Look how simple this function is:


int plusOne(int a) { return a+1; }

Let's say I later want to call it, however, from a fully 
attributed function:


int plusTwo(int a) pure nothrow @safe @nogc  {
  return plusOne(plusOne(a));
}

I get a compiler error. The only way to stop it is to add 
unnecessary visual noise to the first function. All of these 
attributes should be something that you *want* to add, not 
something that you *need*. The compiler can obviously figure 
out if the function throws or not. Just keep an additional 
internal flag for each of the attributes. When any attribute is 
violated, flip the bit and boom, you have your implicit 
function signature.


I think this is how it always should have been. It's important 
to remember that the above attributes have the 'covariant' 
property, which means they can always be called by any function 
without that property. Therefore no existing code will start 
failing to compile. Only certain things which would have 
*errored* before will stop. Plus new optimizations can be done.


So what's the problem? As you can read in the vehement 
opposition to pull 1877 above, the big fear is that function 
signatures will start changing willy-nilly, causing the exposed 
interface of the function to destabilize, which will cause 
linker errors or require code intended to be kept separate in 
large projects to be recompiled at every little change.


I find this depressing! That something so good should be ruined 
by something so remote as the need for separate compilation in 
very large projects? I mean, most projects aren't even very 
large. Also, because D compiles so much faster than its 
predecessors, is it even such a big deal to have to recompile 
everything?


But let's admit the point may be valid. Yes, under attribute 
inference, the function signatures in the exposed API will 
indeed find themselves changing every time one so much as adds 
a 'printf' or calls something that throws.


But they don't *have* to change. The compiler doesn't need to 
include the inferred attributes when it generates the mangled 
name and the .di signature, only the explicit ones. From within 
the program, all the opportunities for inference and 
optimization could be left intact, while outside programs 
accessing the code in precompiled form could only access the 
functions as explicitly indicated.


This makes no change to the language, except that it allows new 
things to compile. The only hitch is this: What if you want the 
full advantages of optimization and inference from across 
compilation boundaries? You'd have to add each of the covariant 
function attributes manually to every function you exposed. 
From my perspective, this is still a chore.


I suggest a new attribute, @api, which does nothing more than 
to tell the compiler to generate the function signature and 
mangle the name only with its explicit attributes, and not with 
its inferred ones. Inside the program, there's no reason the 
compiler can't continue to use inference, but with @api, the 
exposed interface will be stabilized, should the programmer 
want that. Simple.


I anticipate a couple of objections to my proposal:

The first is that we would now demand that the programmer 
decide whether he wants his exposed functions stabilized or 
not. For a large library used by different people, this choice 
might pose some difficulty. But it's not that bad. You just 
choose: do you want to improve compilation times and/or 
closed-source consistency by ensuring a stable interface, or do 
you want to speed up runtime performance without having to 
clutter your code? Most projects would choose the latter. @api 
is made available for the those who don't. The opposition to 
attribute inference put forth in pull 1877 is thereby appeased.


A second objection to this proposal: Another attribute? Really? 
Well, yeah.


But it's not a problem, I say, for these reasons:

1. This one little attribute allows you to excise gajillions of 
unnecessary little attributes which are currently forced on the 
programmer by the lack of inference, simply by appeasing the 
opponents of inference and allowing it to be implemented.


2. It seems like most people will be okay just recompiling 

Re: Phobos colour module?

[John Colvin via Digitalmars-d]

On Monday, 5 January 2015 at 23:39:17 UTC, Manu via Digitalmars-d 
wrote:

On 6 January 2015 at 04:11, via Digitalmars-d
digitalmars-d@puremagic.com wrote:

On Monday, 5 January 2015 at 16:08:27 UTC, Adam D. Ruppe wrote:


Yeah, in my misc repo, there used to be stand along image.d 
and
simpledisplay.d. Now, they both depend on color.d. Even just 
a basic
definition we can use elsewhere is nice to have so other libs 
can interop on
that level without annoying casts or pointless conversions 
just to please

the type system when the contents are identical.



Yes, that too. I was more thinking about the ability to create 
an adapter
that extracts colour information from an existing data 
structure and adds
context information such as gamma. Then let  you build a 
function that say
reads floats from 3 LAB pointers and finally returns a tuple 
with a 16 bit
RGB pixel with gamma correction and the residue in a specified 
format

suitable for dithering... ;-]

It is quite common error to do computations on colours that 
are ignorant of
gamma (or do it wrong) which results in less accurate imaging. 
E.g. When
dithering you need to make sure that the residue that is left 
when doing bit
truncation is added to the neighbouring pixels in a linear 
addition
(without gamma). Making stuff like that less tedious would 
make it a very

useful library.


I have thought about how to handle residue from lossy-encoding, 
but I

haven't thought of an API I like for that yet.
Dithering operates on neighbourhoods of pixels, so in some ways 
I feel
it is beyond the scope of colour.d, but residue is an important 
detail
to enable dithering that should probably be expressed while 
encoding.


Currently, I have a colour template which can be arbitrarily 
typed and

components defined in some user-specified order. It binds the
colourspace to colours. 'CTo to(CTo, CFrom)(CFrom colour)' is 
defined

and performs arbitrary conversions between colours.

I'm finding myself at a constant struggle between speed and
maximizing-precision. I feel like a lib should maximise 
precision, but

the trouble then is that it's not actually useful to me...
Very few applications care about colour precision beyond ubyte, 
so I

feel like using double for much of the processing is overkill :/
I'm not sure what the right balance would look like exactly.
I can make fast-paths for common formats, like ubyte conversions
between sRGB/Linear, etc use tables. Performing colourspace
conversions in fixed point (where both sides of conversion are 
integer
types) might be possible without significant loss of precision, 
but

it's tricky... I just pipe through double now, and that's way
overkill.

I'll make a PR tonight some time for criticism.


What's wrong with old-fashioned `Fast` postfixes on entry points 
where a faster but less precise method is available? Or template 
arguments like std.algorithm.SortStrategy?

Re: DlangUI project update

[Vadim Lopatin via Digitalmars-d-announce]

On Saturday, 27 December 2014 at 06:32:17 UTC, Suliman wrote:
Vadim, could you add in file path in browsing window ability to 
click on any needed segment of path and move to it level.


I mean system like does in Windows 7 in when you can move to
D:\code\foo\bar\baz, and after click on foo move to 
D:\code\foo\


Issue #22 is implemented.
Now path in FileDialog is shown as segments like on Win 7 - 
clicking on segment moves to directory, clicking on arrow after 
segments opens popup with subdirs inside directory. Clicking on 
right space of path control opens editor for path.

Re: @api: One attribute to rule them All

[ketmar via Digitalmars-d]

On Mon, 05 Jan 2015 21:14:58 +
Zach the Mystic via Digitalmars-d digitalmars-d@puremagic.com wrote:

 Hello everybody. My name is Zach, and I have a suggestion for the 
 improvement of D. I've been looking at the following stalled pull 
 request for a while now:
 
 https://github.com/D-Programming-Language/dmd/pull/1877

heh. i did a little hack based on this patch: autoinference is turned
on only for `private auto`. i also added a bunch of UDAs to control the
process: `@inferattr` (can be applied to any function), `@notinferattr`,
`@canthrow`, `@impure` and `@gc` (to control inference).

any explicit attribute on function will block inference too.

as druntime and phobos has no `private auto` which is not templated or
without explicit attribues, it compiles fine. and for my code i have
some control.

this feature can be poorly designed, but as it doesn't conflict with
most of the existing code, i'm happy with it. one should be carefull
with templates calling private functions with inferred attributes (it
breaks linking -- for obvious reason), but it's ok for me. `private
auto` is so ugly that it will rise my alarm level anyway. i mean
function returning 'auto' is suspicious.


signature.asc
Description: PGP signature

Re: decodeReverse

[Jakob Ovrum via Digitalmars-d]

On Tuesday, 6 January 2015 at 06:43:13 UTC, HaraldZealot wrote:
For my particular project (it binds with something like finite 
state machine) I will write some counterpart of decode function 
from std.utf. Future function will decode string backward, 
return dchar and change index passed by reference.


Is it interesting for community that I code this feature in 
general way targeting in phobos for future?


For UTF, there's already std.utf.strideBack which does most of 
the work. I don't know why there is no std.utf.decodeBack - 
should be very simple to wrap over strideBack.


However, for grapheme clusters, there isn't yet a counterpart for 
std.uni.graphemeStride/decodeGrapheme, which notably affects 
std.uni.byGrapheme, which is currently not a bidirectional range. 
Any improvement would be much appreciated.

Re: decodeReverse

[Jonathan M Davis via Digitalmars-d]

On Tuesday, January 06, 2015 08:09:57 Jakob Ovrum via Digitalmars-d wrote:
 On Tuesday, 6 January 2015 at 06:43:13 UTC, HaraldZealot wrote:
  For my particular project (it binds with something like finite
  state machine) I will write some counterpart of decode function
  from std.utf. Future function will decode string backward,
  return dchar and change index passed by reference.
 
  Is it interesting for community that I code this feature in
  general way targeting in phobos for future?

 For UTF, there's already std.utf.strideBack which does most of
 the work. I don't know why there is no std.utf.decodeBack -
 should be very simple to wrap over strideBack.

I'm pretty sure that you basically have to do what strideBack does before
you can decode a code point, so all decodeBack would do would be to do
exactly what back already does for strings, which is to use strideBack
followed by decode.

- Jonathan M Davis

Re: For the lulz: ddmd vs libdparse lexer timings

[Daniel Murphy via Digitalmars-d]

Brian Schott  wrote in message 
news:bhmpbqutpimjxtbcs...@forum.dlang.org...



Now with more copy-paste inlining!

http://i.imgur.com/D5IAlvl.png

I'm glad I could get this kind of speed up, but not happy with how ugly 
the changes were.


Nice!  How far would @forceinline go to getting the same results without the 
ugly?


I don't expect you to do this, but what features would ddmd's lexer need 
before you could entirely replace libdparse's with it? 

Re: An idea for commercial support for D

[uri via Digitalmars-d]

Hi,

Your business model is flawed for a number of reasons. Firstly, 
companies make money from their own products, not paying staff to 
figure out which bug fixes/features to cherry pick for the tool 
chain.


Secondly, no one makes money by locking out others when they 
themselves can be locked out in the same manner. This is 
basically what your model seems to boil down to.


Party 'A' provides patches X,Y,Z in the compiler and others have 
to pay for them. Party 'B' provides patches M,N,O and similarly, 
others pay for them.  Now party A does not benefit from M,N,O 
unless they pay for it and party B does not benefit from X,Y,Z 
unless they pay for it. So no one wins.


So the best solution is A and B both open their patches and both 
benefit from all contributions.


Thirdly, how can one separate the features? For example, say I'm 
willing to pay for features X,Y,Z but not M,N,O. How do the D 
devs split the features out so I only get M,N,O? Separate and 
special builds for each paying customer?


Fourthly, what about the OSS people using D?  Are the X,Y,Z and 
M,N,O features released GPL so they can benefit immediately or do 
they wait 6 months?


If it's 6 months why would anyone pay for the features? If it's 
longer than 6 months, or even if its GPL I think most will 
abandon D and go to Nim or Rust.



Cheers,
uri

Re: @api: One attribute to rule them All

[Joseph Rushton Wakeling via Digitalmars-d]

On Tuesday, 6 January 2015 at 03:29:39 UTC, Zach the Mystic wrote:
A more likely scenario is that your library starts small enough 
not to need the @api attribute, then at some point it gets 
really, really huge. Then in one fell swoop you decide to 
@api: your whole file so that the public interface won't 
change so often. I'm picking the most extreme case I can think 
of, in order to argue the point from a different perspective.


Note that if you want auto-inferred attributes during the alpha 
phase of library development, it's just as trivial to put a 
general @autoinfer: or @noapi: or whatever you like, and that in 
turn is a pretty nice signifier to the user this function's 
attributes are not guaranteed to be stable.



Attribute inference provides convenience, not guarantees.


Indeed.  But any publicly-available API is a guarantee of sorts.  
From the moment people are using something, you can no longer 
vicariously break things.


If a user was relying on the purity of a function which was 
never marked 'pure', it's only convenience which allows him to 
do it, both on the part of the user, for adding 'pure', and the 
library writer, for *not* adding it.


Nevertheless, if a user relies on that inferred purity (which 
they will do), and you tweak things so the function is no longer 
pure, you have broken that downstream user's code.  Worse, you'll 
have done it in a way which flies under the radar until someone 
actually tries to build against your updated library.  You, as 
the library developer, won't get any automatic warning that 
you've broken backwards compatibility with your earlier 
implementation; the downstream user won't get any 
automatically-documented warnings of this breaking change.


If instead you have an explicit please auto-infer attributes for 
this function marker, then at least the user has a very clear 
warning that any attributes possessed by this function cannot be 
relied on.  (Absence of a guarantee != presence of a statement 
that there is NO guarantee:-)


Adding @api (or 'extern (noinfer)') cancels that convenience 
for the sake of modularity. It's a tradeoff. The problem  
itself is solved either by the library writer marking the 
function 'pure', or the user removing 'pure' from his own 
function.


As a library writer, I don't think you can responsibly expect 
users to bear the burden of fixing undocumented breaking change.



Without @api,  the problem only arises when the library writer
actually does something impure, which makes perfect sense.
It's @api (and D's existing default, by the way) which adds
the artificiality to the process, not my suggested default.


I'm not sure what exactly you mean when you talk about D's 
existing default, but one aspect that I think is important is: 
D's default position is that a function has no guarantees, and 
you _add_ guarantees to it via attributes.


This whole discussion would be quite different if the default was 
that a function is expected to be @safe, pure, nothrow, etc., and 
the developer is expected to use attributes to indicate 
_weakening_ of those guarantees.


It's quite analogous in this respect to the argument about 
final vs. virtual by default for class methods.


I don't think so, because of so-called covariance. Final and 
virtual each have their own advantages and disadvantages, 
whereas inferring attributes only goes one way. There is no 
cost to inferring in the general case.


I think you have missed the point I was making.

If you have final-by-default for classes, and you accidentally 
forget to tag a public method as 'virtual', then you can fix that 
without breaking any downstream user's code.  If by contrast you 
have virtual-by-default and you accidentally forget to tag a 
public method as 'final', then you can't fix that without the 
risk of breaking downstream; _someone_ may have relied on that 
function being virtual.


The situation is very similar here.  If your function has no 
attributes, and then later you add one (say, 'pure'), then you 
don't do any downstream user any harm.  If on the other hand your 
function _does_ have attributes -- whether explicit or inferred 
-- and then you remove them, you risk breaking downstream code.


If you don't auto-infer, this is not really an issue, because you 
have to manually add and remove attributes, and so you can never 
unintentionally or unknowingly remove an attribute.  But if you 
_do_ auto-infer, then it's very easy indeed to accidentally 
remove attributes that your downstream may have relied on.



My suggestion, (I now prefer 'extern(noinfer)'), does absolutely
nothing except to restore D's existing default, for what I think
are the rare cases it is needed. I could be wrong about just how
rare using extern(noinfer) will actually be, but consider that
phobos, for example, just doesn't need it, because it's too 
small

a library to cause trouble if all of a sudden one of its
non-templated functions becomes impure.


I don't think you 

Broken dlang traits page

[Rikki Cattermole via Digitalmars-d]

Just in case nobody knows about this.
But the language docs for traits is broken.

http://dlang.org/traits.html

Re: Any chance of a linux dtoh?

[ketmar via Digitalmars-d-learn]

On Tue, 06 Jan 2015 14:08:30 +
Laeeth Isharc via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:

 I realize Walter has far better things to work on, but value of 
 having a translation tool is considerable, since it opens up easy 
 access to an enormous range of libraries.  It is not much work to 
 do the translation oneself, but in the world as it is small 
 frictions cumulatively have large consequences.  Access to 
 libraries is a big advantage of python, and the like.  Once you 
 have the wrapper in place, I find D as productive as python, but  
 for now it is still a bit of work first.

i bet that the only realistic way to do something like that is to take
some existing C/C++ parser and write the tool from scratch.


signature.asc
Description: PGP signature

Re: Any chance of a linux dtoh?

[Dicebot via Digitalmars-d-learn]

On Tuesday, 6 January 2015 at 14:22:54 UTC, ketmar via 
Digitalmars-d-learn wrote:

On Tue, 06 Jan 2015 14:08:30 +
Laeeth Isharc via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:

I realize Walter has far better things to work on, but value 
of having a translation tool is considerable, since it opens 
up easy access to an enormous range of libraries.  It is not 
much work to do the translation oneself, but in the world as 
it is small frictions cumulatively have large consequences.  
Access to libraries is a big advantage of python, and the 
like.  Once you have the wrapper in place, I find D as 
productive as python, but  for now it is still a bit of work 
first.


i bet that the only realistic way to do something like that is 
to take

some existing C/C++ parser and write the tool from scratch.


Which is exactly what dstep is.

Re: @api: One attribute to rule them All

[Atila Neves via Digitalmars-d]

tldr: I like what you're thinking, please can we have this.


+1

Atila

Re: Phobos colour module?

[Manu via Digitalmars-d]

On 6 January 2015 at 19:31, via Digitalmars-d
digitalmars-d@puremagic.com wrote:
 On Tuesday, 6 January 2015 at 09:19:46 UTC, John Colvin wrote:

 What's wrong with old-fashioned `Fast` postfixes on entry points where a
 faster but less precise method is available? Or template arguments like
 std.algorithm.SortStrategy?


 If this is for phobos it should follow a common model. But since a fast
 implementation might involve an object which builds a table before
 processing

 Another problem is that precise is a very loose term if the conversion is
 for display or for composition in a shader. What you want depends on the
 kind of post processing that happens after this and how it affects the
 nonlinearities of human perception.

I think an important facet of 'fast' image processing is in the loop
that processes batches of pixels, rather than in the api that
processes a single pixel.
I've gone with accurate; that's the strategy throughout phobos.

I can't create look-up-tables at the moment, since '^^' doesn't work
in CTFE! _

Here's a PR to see where I'm at:
https://github.com/D-Programming-Language/phobos/pull/2845

Re: Any chance of a linux dtoh?

[Dicebot via Digitalmars-d-learn]

On Tuesday, 6 January 2015 at 14:14:28 UTC, Laeeth Isharc wrote:

On Tuesday, 6 January 2015 at 14:11:19 UTC, Dicebot wrote:
dstep is your only realistic chance currently. htod is 
completely unmaintained, even on Windows. Please report any 
issues found with it in relevant issue tracker.


I got it the wrong way around - yes, I meant htod.

I have reported the issue, and author doesn't know what is 
wrong.


You must be referring to 
https://github.com/jacob-carlborg/dstep/issues/33


You mention using DMD beta there. Please don't. Use last 
currently available public release. This specific beta is 
especially harmful being left-over from unfinished beta cycle.

Re: decodeReverse

[HaraldZealot via Digitalmars-d]

I'm pretty sure that you basically have to do what strideBack 
does before
you can decode a code point, so all decodeBack would do would 
be to do
exactly what back already does for strings, which is to use 
strideBack

followed by decode.

- Jonathan M Davis


I have to read more attentively std.utf, but strideBack seems 
very suitable for me.


Thanks you both!!!

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Tuesday, 6 January 2015 at 12:05:34 UTC, uri wrote:
Your business model is flawed for a number of reasons. Firstly, 
companies make money from their own products, not paying staff 
to figure out which bug fixes/features to cherry pick for the 
tool chain.


Before you make such claims, you should probably think about them 
a little bit first.  Please tell me one company that does not buy 
outside commercial software which they then use to build their 
own products.  Some companies will want to cherry pick features, 
others will just buy an accumulated patchset against the point 
release from many devs.  The suggestion that all companies will 
have to spend a great deal of time picking what patches they want 
is just silly.


Secondly, no one makes money by locking out others when they 
themselves can be locked out in the same manner. This is 
basically what your model seems to boil down to.


Party 'A' provides patches X,Y,Z in the compiler and others 
have to pay for them. Party 'B' provides patches M,N,O and 
similarly, others pay for them.  Now party A does not benefit 
from M,N,O unless they pay for it and party B does not benefit 
from X,Y,Z unless they pay for it. So no one wins.


I was with you until no one wins, what the hell does that mean? 
 If party A wants to run patches M,N,O with their D compiler and 
vice versa for party B, they can just pay for them, just like 
everybody else.  Since party A will be making money off X,Y,Z, 
they shouldn't have any problem using some of that money to pay 
for the other patches they need.


So the best solution is A and B both open their patches and 
both benefit from all contributions.


This means A and B can't make any money off their patches, so 
they have to get some other job. That means they only have time 
to work on M and X on the occasional weekend and each of those 
patches takes six months to finish.  You are obviously okay with 
that glacial pace as long as you get their work for free, but 
others are willing to pay to get the pace of D development sped 
up.


Thirdly, how can one separate the features? For example, say 
I'm willing to pay for features X,Y,Z but not M,N,O. How do the 
D devs split the features out so I only get M,N,O? Separate and 
special builds for each paying customer?


Glad you brought this up, there are several possibilities.  Many 
users would probably just buy all the closed patches against a 
point release, so there is no question of splitting features.  
But a handful of paying customers may be more adventurous, or 
cheap, ;) and choose to only buy a custom build with their needed 
features X,Y,Z.  This probably wouldn't happen right away, as it 
will take more time to setup a build process to support it, but 
supporting custom builds like that is definitely worthwhile.


Fourthly, what about the OSS people using D?  Are the X,Y,Z and 
M,N,O features released GPL so they can benefit immediately or 
do they wait 6 months?


To begin with, D is not a GPL project, so why would they release 
them under the GPL?  As stated earlier, the patches would need to 
be funded up to some monetary and time limits before they would 
be released back to the OSS project.  So party A might contract 
with their paying customers that they'll release patches X,Y,Z 
once they accumulate $5k in payments from all the customers who 
buy those patches, plus a six month delay after that.  If they 
don't make $5k for a long time, the patches won't be released for 
a long time.


If it's 6 months why would anyone pay for the features? If it's 
longer than 6 months, or even if its GPL I think most will 
abandon D and go to Nim or Rust.


Why does anyone pay for software now?  It doesn't much matter to 
a paying customer that the feature will probably be free in a 
year or two if they need to use it to make money _now_.


As for people leaving because somebody else has developed a 
proprietary feature for D and not given it to them for free, 
companies like Sociomantic have already developed such features 
and they haven't been integrated upstream, why haven't most 
left already?  The dmd backend is not under an OSS license, why 
haven't they left?  I suspect there are not very many of the type 
of people you're talking about in the D community.


Maybe a handful of FOSS zealots would leave, but the resulting 
commercially supported D would be so much better, they'd be 
swamped by the new people coming on board. :)

Re: http://wiki.dlang.org/DIP25

[Steven Schveighoffer via Digitalmars-d]

On 1/6/15 1:48 AM, Walter Bright wrote:

On 1/5/2015 2:04 PM, Steven Schveighoffer wrote:

To give you an example of why that sucks, imagine that your accessor for
member_x is nothrow, but your setter is not. This means you either
make an
exception, or you just split up obvious file-mates into separate
corners.
Source control gets confused if one of those attributes changes.
Nobody is happy.

Grouping by attributes is probably one of the worst ways to have
readable/maintainable code.

One of the most important reasons why unittests are so successful is
that you
can just plop the code that tests a function right next to it. So easy
to find
the code, so easy to maintain when you change the target of the test.
Making
some way to bundle attributes, or be able to negate currently one-way
attributes
would go a long way IMO.



I know and agree. I was just responding to the 'impossible'
characterization.


OK, Mr. Literal :) Sorry, I should have said impossible without totally 
screwing up the code


-Steve

Re: I'll be presenting at NWCPP on Jan 21 at Microsoft

[Laeeth Isharc via Digitalmars-d-announce]

On Monday, 5 January 2015 at 21:07:04 UTC, Walter Bright wrote:

On 1/5/2015 5:31 AM, Laeeth Isharc wrote:

Will audio be available afterwards?


NWCPP usually will post the video afterwards.


At a slight tangent, has anything more recent been written on 
the C++
interface?  I understand it is more complete than what is 
described on the
Wiki/at dlang.org and have not been able to find a write-up of 
this.


Sorry, nothing yet. It's a work in progress.


Thanks, Walter.

D bindings and high level wrapper for systemd journal

[Laeeth Isharc via Digitalmars-d-announce]

D Language bindings and high level wrapper for the systemd 
journal logging service (journalctl)


https://github.com/Laeeth/d_sysdlog

alpha status

rather than grep /var/log/messages, systemd interface makes it 
easy to filter by field and period of interest. metadata is 
stored along with regular log messages, which reduces the ability 
of bad actors to spoof logs


Link to C API here: 
http://www.freedesktop.org/software/systemd/man/sd-journal.html


Description

systemd-journald is a system service that collects and stores 
logging data. It creates and maintains structured, indexed 
journals based on logging information that is received from a 
variety of sources:


Kernel log messages, via kmsg

Simple system log messages, via the libc syslog(3) call

Structured system log messages via the native Journal API, see 
sd_journal_print(4)


Standard output and standard error of system services

Audit records, via the audit subsystem
The daemon will implicitly collect numerous metadata fields for 
each log messages in a secure and unfakeable way. See 
systemd.journal-fields(7) for more information about the 
collected metadata.


Log data collected by the journal is primarily text-based but can 
also include binary data where necessary. All objects stored in 
the journal can be up to 2^64-1 bytes in size.

Re: An idea for commercial support for D

[via Digitalmars-d]

On Tuesday, 6 January 2015 at 13:34:59 UTC, Joakim wrote:
Maybe a handful of FOSS zealots would leave, but the resulting 
commercially supported D would be so much better, they'd be 
swamped by the new people coming on board. :)


If there is a market for a commercial version of D then I think 
the most sensible thing for a company would be to create a 
dialect and only distribute binary versions. Maybe a free edition 
for non-commercial use. The reasons for this is simple: the D 
community is not large enough to keep a commercial vendor from 
improving the language semantics. There is no installed base...


I don't think that would be a bad thing either... It would not 
kill D, it would just create a newD.

Re: Questions about TDPL book

[Steven Schveighoffer via Digitalmars-d]

On 1/5/15 10:20 PM, weaselcat wrote:

Is it still worth buying TDPL since it's almost 5 years old? I realize
classics like KR C are near timeless, but D has seen a lot of changes.


I would still recommend buying. TDPL purposely was very scant on phobos 
because it was constantly changing. The language features are generally 
accurate. The developers try to make sure we do not invalidate TDPL 
without a very good reason.


-Steve

Any chance of a linux dtoh?

[Laeeth Isharc via Digitalmars-d-learn]

I realize Walter has far better things to work on, but value of 
having a translation tool is considerable, since it opens up easy 
access to an enormous range of libraries.  It is not much work to 
do the translation oneself, but in the world as it is small 
frictions cumulatively have large consequences.  Access to 
libraries is a big advantage of python, and the like.  Once you 
have the wrapper in place, I find D as productive as python, but  
for now it is still a bit of work first.


There is also dstep, but this doesn't seem to compile right now, 
and I don't have time to figure out why and fix it.  (I took a 
look, and it is not so easy to figure out).  Something 
mambo/tango related.  I have raised a bug report.




Laeeth

Re: Any chance of a linux dtoh?

[Laeeth Isharc via Digitalmars-d-learn]

On Tuesday, 6 January 2015 at 14:11:19 UTC, Dicebot wrote:
dstep is your only realistic chance currently. htod is 
completely unmaintained, even on Windows. Please report any 
issues found with it in relevant issue tracker.


I got it the wrong way around - yes, I meant htod.

I have reported the issue, and author doesn't know what is wrong.

Re: Any chance of a linux dtoh?

[Dicebot via Digitalmars-d-learn]

dstep is your only realistic chance currently. htod is completely 
unmaintained, even on Windows. Please report any issues found 
with it in relevant issue tracker.

Re: DMD's lexer available on code.dlang.org

[Dicebot via Digitalmars-d-announce]

It will be really cool when same package will be reused by DMD 
itself :P

Re: DMD's lexer available on code.dlang.org

[Joakim via Digitalmars-d-announce]

On Tuesday, 6 January 2015 at 14:38:21 UTC, Dicebot wrote:
It will be really cool when same package will be reused by DMD 
itself :P


I believe ddmd has passed all tests on most platforms for a long 
time now, so there is nothing stopping those building from source 
from using ddmd now. :)

Re: @api: One attribute to rule them All

[via Digitalmars-d]

On Tuesday, 6 January 2015 at 12:07:21 UTC, Joseph Rushton 
Wakeling wrote:
As a library writer, I don't think you can responsibly expect 
users to bear the burden of fixing undocumented breaking change.


I agree, maybe just replace module with library. Also make 
module mandatory. It takes no extra keyword if it always is the 
first token.


Then the compiler can be more lax with module files and more 
strict with library files.

Re: For the lulz: ddmd vs libdparse lexer timings

[David Nadlinger via Digitalmars-d]

On Monday, 5 January 2015 at 17:44:31 UTC, Daniel Murphy wrote:
I think I've got a handle on this, sort of.  I've moved the 
declaration of __va_argsave into the glue layer, and added 
intrinsic detection for va_start/va_end/va_arg (the two-arg 
form).


I've implemented them in the backend for win32 and they have 
passed a simple test!


I'd suggest you have a look at Posix x86_64 first before 
finalizing the easy x86 implementation. The former comes with 
two extra niceties compared to the simple pointer to 
stack-allocated arguments model:


 1) You need to copy the registers to the stack on function entry 
(in case the arguments are later accessed using va_arg, they are 
just regular functions on the caller side), and then be able to 
access the address of this area in va_start. This is what 
va_argsave is currently used for in DMD.


 2) The issue with passing va_list as a parameter (especially 
regarding C ABI compatibility) vs. allocating the struct storage 
allocation. If you simply make it a pointer on x86_64, it's hard 
to implement va_copy correctly. The DMD implementation of the 
latter is currently broken, which is the reason for some of the 
vararg-related version(X86_64) blocks.


Do you think we can change _all_ the druntime and phobos code 
to just use va_arg directly?  It would be nice to have it all 
portable like that.


Yes. Some parts might need a bit of rework, though. This job 
would be quite a bit easier if we could finally ditch the old 
vararg-based std.format stuff before.


Be sure to let me know if you have any specific questions.

David

Re: Improving ddoc

[Adam D. Ruppe via Digitalmars-d]

On Tuesday, 6 January 2015 at 15:00:06 UTC, Dicebot wrote:
Wait what? It isn't formatted as hX as far as I can see. How 
exactly this is supposed to work?


That makes a DDOC_SECTION. The default macro is

DDOC_SECTION_H = $(B $0)$(BR)
DDOC_SECTION   = $0$(BR)$(BR)

But if these macros were better, it could be a 
headerhx$0/hx/header where the x is the right level.


I might spend a day revamping these macros eventually, the 
default ones are so bad, they make poor html and hide some of 
ddoc's own features.

Re: Phobos colour module?

[via Digitalmars-d]

On Tuesday, 6 January 2015 at 14:28:52 UTC, Manu via 
Digitalmars-d wrote:
I think an important facet of 'fast' image processing is in the 
loop

that processes batches of pixels, rather than in the api that
processes a single pixel.
I've gone with accurate; that's the strategy throughout phobos.


Yeah, I agree. For fast on the CPU you want to use simd, and 
maybe one register for red, another for green, using saturating 
instructions, doing it differently on ARM vs x86 etc...


Besides, an accurate reference implementation is a good starting 
point and also very useful for unit testing a faster 
batch-oriented version later on.



Here's a PR to see where I'm at:
https://github.com/D-Programming-Language/phobos/pull/2845


Nice start. Most libraries use US-English color, though. I 
guess phobos should try to be internally consistent (pick either 
UK or US vocabulary).

Re: Improving ddoc

[Dicebot via Digitalmars-d]

On Thursday, 1 January 2015 at 21:52:59 UTC, Walter Bright wrote:

On 1/1/2015 7:09 AM, Dicebot wrote:

   headers
3. ===


   headers:


Wait what? It isn't formatted as hX as far as I can see. How 
exactly this is supposed to work?

Re: Improving ddoc

[via Digitalmars-d]

On Tuesday, 6 January 2015 at 15:13:00 UTC, Adam D. Ruppe wrote:
But if these macros were better, it could be a 
headerhx$0/hx/header where the x is the right level.


The header element belongs in a sectioning element and the 
first heading in each section should be h1:


sectionh1.../h1
  sectionh1.../h1
/section
/section

Re: http://wiki.dlang.org/DIP25

[Zach the Mystic via Digitalmars-d]

On Tuesday, 6 January 2015 at 06:48:34 UTC, Walter Bright wrote:
One of the most important reasons why unittests are so 
successful is that you
can just plop the code that tests a function right next to it. 
So easy to find
the code, so easy to maintain when you change the target of 
the test. Making
some way to bundle attributes, or be able to negate currently 
one-way attributes

would go a long way IMO.



I know and agree. I was just responding to the 'impossible' 
characterization.


Is it bikeshedding time?? If so, I was thinking '@~' to be the 
universal canceller... @~pure, @~final. I'm only half kidding.

Re: Kill as soon as possible the special case handling of tuples in foreach

[deadalnix via Digitalmars-d]

Tuple unpacking is necessary for things like bypair. Why not 
unpack consistently ?

Re: An idea for commercial support for D

[Zach the Mystic via Digitalmars-d]

On Sunday, 4 January 2015 at 08:31:23 UTC, Joakim wrote:
This is an idea I've been kicking around for a while, and given 
the need for commercial support for D, would perhaps work well 
here.


The notion is that individual developers could work on patches 
to fix bugs or add features to ldc/druntime/phobos then sell 
those closed patches to paying customers.  After enough time 
has passed, so that sufficient customers have adequately paid 
for the work or after a set time limit beyond that, the patch 
is open sourced and merged back upstream.  It would have to be 
ldc and not dmd, as the dmd backend is not open source and the 
gdc backend license doesn't allow such closed patches.


A funny scenario based on this proposal: Company A wants feature 
B, and signs a contract with a developer for a certain amount, 
receiving the feature as soon as possible, releasing the paid-for 
software to the public after a year. During that year, company C 
comes to the same developer wanting the same feature. They say, 
It's already paid for, but you can pay company A half the 
development cost, minus the proportion of time left before it's 
open to everyone, and you can both have it! Or something like 
that.

Re: import std.random fails

[ixid via Digitalmars-d-learn]

On Tuesday, 6 January 2015 at 18:37:25 UTC, Rene Zwanenburg wrote:

On Monday, 5 January 2015 at 15:59:17 UTC, ixid wrote:
On Friday, 31 August 2012 at 22:52:13 UTC, Jonathan M Davis 
wrote:

On Saturday, September 01, 2012 00:40:25 deed wrote:


import std.random

void main() {}
---

results in:

Error 42: Symbol Undefined
_D4core6memory2GC6qallocFkkZS4core6memory8BLkInfo_
Error 42: Symbol Undefined _D4core6memory2GC6extendFPvkkZk
Error 42: Symbol Undefined _D4core5bitop3bsrFNaNbkZi
--- errorlevel 3


What is wrong?


You druntime installation is bad due to some cruft left from 
a previous
install (the installer obviously needs some work). If you 
used an installer,
then uninstall dmd, make sure that it's completely removed, 
and then reinstall

it.

If you installed it manually, then make sure that you blow 
away druntime's
import directory and then restore it with the current version 
of those files.


- Jonathan M Davis


I am having this issue now. What else would I need to do other 
than uninstall and reinstall D on Windows to get it working? I 
tried that and it's not fixed it. Importing std.random in my 
own module which is in the project directory fails to find the 
symbol while importing std.algorithm works fine. Importing 
std.random in main.d works fine as well.


Error   1   Error 42: Symbol Undefined _D7objects12__ModuleInfoZ


How do you build your program? Dmd, rdmd, Dub, etc.?


Dmd latest non-beta, with the latest VisualD. Debug build. Debug 
build and no additional or non default settings.

Re: Phobos colour module?

[H. S. Teoh via Digitalmars-d]

On Tue, Jan 06, 2015 at 10:44:38AM -0800, Walter Bright via Digitalmars-d wrote:
 On 1/6/2015 10:07 AM, H. S. Teoh via Digitalmars-d wrote:
 Implementing union painting in CTFE would singlehandedly solve
 (almost?) all of std.math CTFE issues, AFAICT.
 
 I thought it did allow painting of the form *(cast(T*)t).

Was that a recent addition? I don't remember that working last year.

In any case, the current std.math code tries to achieve repainting via
unions, which currently doesn't work in CTFE:

ulong ctfeFunc(double d) {
union U {
double f;
ulong  ul;
}
U u;
u.f = d;
return u.ul;// --- CTFE error
}
enum x = ctfeFunc(3.141592);


Maybe I remembered wrong, but the original std.math code relied on
*(cast(T*)t) to work, but was rewritten to use union repainting, IIRC
because union painting is considered more likely to be implemented in
CTFE (? -- my guess; I could be wrong).

In any case, it's great news that repainting is now supported in CTFE.
Hopefully this means more of std.math will be usable at compile-time
soon!


T

-- 
The whole problem with the world is that fools and fanatics are always so 
certain of themselves, but wiser people so full of doubts. -- Bertrand 
Russell. How come he didn't put 'I think' at the end of it? -- Anonymous

Re: decodeReverse

[HaraldZealot via Digitalmars-d]

On Tuesday, 6 January 2015 at 16:58:24 UTC, Andrei Alexandrescu 
wrote:

On 1/5/15 10:43 PM, HaraldZealot wrote:
For my particular project (it binds with something like finite 
state
machine) I will write some counterpart of decode function from 
std.utf.
Future function will decode string backward, return dchar and 
change

index passed by reference.

Is it interesting for community that I code this feature in 
general way

targeting in phobos for future?


back() and popBack() for narrow strings do reverse decode. -- 
Andrei


I need reverse decode from any position, not only from the last.
I have coded a litle with stideBack allready, it works. But usage 
isn't clear as could: first strideBack, then decode, and decode 
move index forward, then I have to strideBack again :)


Perhaps i will wrap such algorithm in some function, but an other 
side i will be forced to optimize that and write real decodeBack 
function.

Re: Phobos colour module?

[H. S. Teoh via Digitalmars-d]

On Tue, Jan 06, 2015 at 06:28:03PM +, via Digitalmars-d wrote:
 On Tuesday, 6 January 2015 at 18:09:19 UTC, H. S. Teoh via Digitalmars-d
 wrote:
 It's the non-integral exponents that require the
 currently-non-CTFE-able code, right?
 
 http://en.wikipedia.org/wiki/Gamma_correction

Right, integral exponents aren't the interesting (useful) case here.


T

-- 
Valentine's Day: an occasion for florists to reach into the wallets of nominal 
lovers in dire need of being reminded to profess their hypothetical love for 
their long-forgotten.

Re: Phobos colour module?

[Walter Bright via Digitalmars-d]

On 1/6/2015 10:07 AM, H. S. Teoh via Digitalmars-d wrote:

Implementing union painting in CTFE would singlehandedly solve (almost?)
all of std.math CTFE issues, AFAICT.


I thought it did allow painting of the form *(cast(T*)t).

Re: For the lulz: ddmd vs libdparse lexer timings

[Brian Schott via Digitalmars-d]

On Tuesday, 6 January 2015 at 12:39:27 UTC, Daniel Murphy wrote:
Nice!  How far would @forceinline go to getting the same 
results without the ugly?


@forceinline would solve all of it.

I don't expect you to do this, but what features would ddmd's 
lexer need before you could entirely replace libdparse's with 
it?


It would have to be range-based and be capable of performing 
syntax highlighting. My D lexer is based on lexer generator code 
that might someday become std.lexer, so I want to keep it around 
to make sure that the std.lexer code is good enough.

Re: An idea for commercial support for D

[anonymous via Digitalmars-d]

On Tuesday, 6 January 2015 at 06:14:37 UTC, Joakim wrote:
On Monday, 5 January 2015 at 22:51:25 UTC, Joseph Rushton 
Wakeling via Digitalmars-d wrote:

[...]
Most commercial adopters are going to consider it very 
important to have a support option that says, If you have a 
serious blocker, you can pay us money to guarantee that it 
gets fixed.


They are not going to be at all happy about a support option 
that says, If we develop a fix, then you are not going to get 
it in a timely manner unless you pay.


Understanding that distinction is very important.


Haha, you do realize that those two quotes you laid out are the 
exact same option?  In the first option, you pay for a fix.  In 
the second option, you pay for a fix.  What distinction you're 
hoping to draw has not been made.


In the first option, you pay for a fix now, or you get it for 
free when it's done independently of you, e.g. because someone 
else paid.
In the second option, you pay for a fix. If it's done 
independently of you, you still pay.


[...]
I also think you assume far too much value on the part of 
privileged/early access to bugfixes.  A bug in a programming 
language toolchain is either a commercial problem for you or 
it isn't.  If it's a commercial problem, you need it fixed, 
and that fix in itself has a value to you.  There is not 
really any comparable change in value if that fix also gets 
delivered to other users (who may or may not be competitors of 
yours), because that isn't what differentiates your product.


Of course there's a change in value.  If another user or 
competitor also needs that fix and pays for it and upstreams it 
before you do, that's a cost you don't have to pay at all.  
Hence the whole tragedy of the commons I laid out in my first 
post.


If I get him right, Joseph's point is that the patch's value (not 
its cost) for the customer doesn't change whether others have 
access to it or not. So there's no advantage for the customer in 
the early-access model. But there's a disadvantage: have to pay 
for every patch. And so, an early-access model may not be 
attractive to paying customers.


If I get you right, you're saying that the revenue for the patch 
writer changes depending on if they sell the patch once or twice. 
And therefore, there's an advantage for the patch writer in the 
early-access model: can sell one patch multiple times.


You're both not wrong. If it works as planned, the early-access 
isn't benefitial to the buyer, but to the seller. And that's the 
point: move (more) money from customers to patch writers. It's 
not a win-win. It's not supposed to be. But if there's nothing 
to gain in an early-access for the customer, why should they 
prefer it over a competitor with immediate-access-for-everyone?


[...]
On the contrary, D is a programming language, and as such is 
used by people to make commercial projects, and so those 
people have a very strong interest in paying for commercial 
support, based around the principle If we need something 
fixed, it will be fixed.


But they don't have an interest in a situation where, If 
something gets fixed, we have to pay.


The first of those options delivers value.  The second is 
exploitation.


I suggest you actually read what you're writing:

people have a very strong interest in paying for commercial 
support, based around the principle 'If we need something 
fixed, it will be fixed.'


If something gets fixed, we have to pay.

In both cases, they're paying for fixes.  If your point is that 
in the first model they're paying up front through a support 
subscription, whereas in the second model they're paying after 
they identify the fix- a distinction I'm stretching to find as 
you haven't really made it- both are still paying for a fix.


In the first model, they pay for specific fixes and get any 
others for free.

In the second model, they pay for all fixes.

I think calling it exploitation may have been a bit inciting, 
but I can understand the concern. Charging for bug fixes is a bit 
shady, when we introduced the bugs ourselves.


And the whole thing could put off existing users, maybe even 
contributors. Especially when core developers would work on the 
early-access patches, the larger community could feel left out in 
the rain.

Re: DMD's lexer available on code.dlang.org

[Walter Bright via Digitalmars-d-announce]

On 1/6/2015 1:37 AM, Vadim Lopatin wrote:

I have a bit similar project - lexer for D written in D.
Written just based on Lexical documentation page.

https://github.com/buggins/ddc

Trying make it fast and to do as few memory allocations as possible.


Should also make it available on code.dlang.org

We need a DConf 2015 logo

[Andrei Alexandrescu via Digitalmars-d]

The DConf 2015 dates have been confirmed and the site will be soon up - 
see preview at http://erdani.com/d/bvbvuntf/.


Please contribute with a DConf logo image. Also any design updates for 
the site would be welcome, Thanks!



Andrei

Re: We need a DConf 2015 logo

[Steven Schveighoffer via Digitalmars-d]

On 1/6/15 2:27 PM, Andrei Alexandrescu wrote:

The DConf 2015 dates have been confirmed and the site will be soon up -
see preview at http://erdani.com/d/bvbvuntf/.

Please contribute with a DConf logo image. Also any design updates for
the site would be welcome, Thanks!


I plan to submit my talk on 2/27 at 23:59:59.991 PST. I hope that's ok.

-Steve

Re: Kill as soon as possible the special case handling of tuples in foreach

[bearophile via Digitalmars-d]

deadalnix:

Tuple unpacking is necessary for things like bypair. Why not 
unpack consistently ?


I'm all for unpacking consistently, but to reach consistency you 
first have to break something, the iteration on arrays or the 
iteration on ranges of tuples. The first is documented and it's 
present since D1, the second is recent and undocumented and it 
causes evolution troubles for D toward possible implementations 
of tuples. What do you want to kill? I prefer to kill the second, 
and do it yesterday.


Bye,
bearophile

Re: Questions about TDPL book

[weaselcat via Digitalmars-d]

On Tuesday, 6 January 2015 at 09:51:13 UTC, Joakim wrote:
I don't know if the ebook is updated, but the physical quality 
of the softcover print book is not good.  Mine fell apart about 
halfway through reading it, it's in 3-4 chunks now.  I wish 
there had been a pdf version available at the time, as I always 
prefer an electronic version and bought the pdf version of 
Adam's book.  I wasn't interested in signing up for informIT's 
book subscription service to read it on a screen.


Oh, that's disappointing. My 20-some year old secondhand copy of
KR C seems like it could last a nuclear blast haha.

Thanks everyone for their answers, I'll pick up the ebook version
- I already bought Ruppe's book and have thoroughly read Ali's D
book(extremely good book quality, especially for being free) and
wanted more.

Re: import std.random fails

[Rene Zwanenburg via Digitalmars-d-learn]

On Tuesday, 6 January 2015 at 20:26:25 UTC, ixid wrote:
Dmd latest non-beta, with the latest VisualD. Debug build. 
Debug build and no additional or non default settings.


Hmm..

Did you verify that the D installation directory was completely 
empty after uninstalling?


Does VisualD have some kind of verbose mode to show the exact 
command used to invoke DMD?


What happens if you run rdmd on your main file?

Re: DConf 2015?

[Chuck Allison via Digitalmars-d]

Just so you all know, DConf 2015 is scheduled when Utah is it's 
most beautiful. Not too hot, everything green, perfect for 
hiking, whatever. If you have never been to Southern Utah before, 
you might want to consider scheduling some time to see the 
National Parks and other like places before or after the 
conference.



On Tuesday, 30 December 2014 at 03:38:08 UTC, Walter Bright wrote:

On 12/29/2014 3:37 AM, Kingsley wrote:
I'm interested in coming to the next D conference. Please let 
me know if there
is anything I can do to help out. I've been working on IDE 
support for intellij

here: https://github.com/kingsleyh/DLanguage


The best thing you can do is submit a speaking proposal.

which I thought might be an interesting topic for a brief 
presentation. Although

I guess it depends on the audience at these conferences.

Will the next one be in the same place? I'm based in London - 
I guess it's not

going to be in London?


It'll be at Utah Valley University:

http://www.uvu.edu/visitors/aboutuvu/

Re: An idea for commercial support for D

[anonymous via Digitalmars-d]

On Tuesday, 6 January 2015 at 19:46:51 UTC, Joakim wrote:

On Tuesday, 6 January 2015 at 19:06:27 UTC, anonymous wrote:

[...]
I don't know of any commercial support model where you only pay 
for the fixes you need at any given moment and the fixes that 
others paid for are provided to you for free.


I'm not knowledgeable about any of this business stuff, and I 
don't mean to pretend I am. I just wanted to clarify what I think 
Joseph meant there, as I understood it.


As far as I know there are companies that employ developers to 
work on open source software, with their patches open-sourced 
immediately. I'm assuming the employer can direct where exactly 
the effort goes. That's essentially it, no?


 I presume you're referring to support subscriptions, where you 
pay a monthly fee to subscribe to an stream of ongoing fixes 
and pay extra for fixes you need right away.  But that's not 
free, you're paying a monthly fee for that ongoing 
subscription, which subsidizes the cost of those fixes that 
others paid for first.


No, I didn't have that in mind.

[...]
My point was that he's wrong that the patch's value doesn't 
change if others have access to it.  Just because that patch 
doesn't clearly differentiate your product on a spec sheet 
doesn't mean those patches in aggregate don't differentiate 
your time to market and cost of making the product, which will 
all affect your bottom line.


So, the point is that competitors can't leech off my paid 
patches, right? I mean, sure, that's a thing. I'm definitely not 
business enough to put a number on it. Seems like the number you 
put on it is higher than the one Joseph puts on it.


There is no disadvantage to paying for the patch in this model, 
because otherwise you don't get the patch.  You are paying 
someone to write the patch so that it exists in the first 
place.  Otherwise, you can hope that some OSS dev gets to it 
someday when he gets some spare time.


The counter-proposal is not to rely on the free (as in beer) 
devs, but to hire someone to write OSS patches. This would of 
course allow your competition to leech off of you. But if others 
do the same, the benefits may be greater than if everyone is 
protective of their stuff. Again, I don't want to pretend to know 
what's best business-wise.


[...]
It _is_ win-win, that's the whole point.  It's even 
win-win-win, to crib a term from The Office, ;) because the OSS 
project eventually also gets the patch after a delay.


I don't think the win for the customer is so clear. The win 
that your competitors have to pay, too, seems rather slim to me 
(remember, not a business guy). And if competitors would buy 
patches collectively, eliminating the need for an exclusive 
access period, they could be better off than when each of them 
pays for it separately. But this may not be realistic, of course.


I don't know who this hypothetical competitor is who provides 
immediate-access-for-everyone and is cranking out a ton of 
patches.  They currently don't exist.


Neither exists at the moment for D. It's all hypothetical.

[...]
I think calling it exploitation may have been a bit 
inciting, but I can understand the concern. Charging for bug 
fixes is a bit shady, when we introduced the bugs ourselves.


Who is the we?  Paid devs fixing bugs in the existing OSS 
project that were introduced by OSS devs is not a we.


The OSS devs is we. If others write the patches that argument 
doesn't apply, of course.


And the whole thing could put off existing users, maybe even 
contributors. Especially when core developers would work on 
the early-access patches, the larger community could feel left 
out in the rain.


Who cares.  First off, D's core OSS devs have given no 
indication they'd be interested in working on such paid 
patches, so the paid devs would likely be a completely separate 
group.


If it's not current developers selling the patches, then I think 
it's much less likely to back-fire.


Even if some of the existing OSS devs wrote some paid patches, 
the D OSS project exists because of the generosity of Walter, 
Andrei, Kenji, and a couple dozen other volunteer contributors 
who give away their work for free under an OSS license.  To 
suggest that they are therefore bound to always provide future 
patches for free is frankly ridiculous.  They could all just 
stop working on D tomorrow, they have no responsibility to keep 
providing all this free work.


Similarly, they have no responsibility to not sell some patches 
to paying customers, simply because some spoiled handful will 
throw a hissy fit because they're not getting _everything_ for 
free anymore.  If they really want those patches, they can pay 
for them or write them themselves.


It's not so much about responsibilites, definitely not legal 
ones. It's more about keeping good relations with the community. 
I'm also thinking more about minor/occasional contributors, like 
myself, not so much about pure consumers (or potential 

DConf 2015 Call for Submissions is now open

[Andrei Alexandrescu via Digitalmars-d-announce]

Hello,


Exciting times! DConf 2015 will take place May 27-29 2015 at Utah Valley 
University in Orem, UT.


The call for submissions is now open at http://dconf.org. Please mind 
the submission deadline: February 27, 2015.


We are hoping to build a strong program with the help of D established 
luminaries who spoke at previous editions of DConf, as well as 
up-and-coming contributors. So please send us your submissions soon. 
There's a good deal of progress and strength building in our community 
as of late, and you can make the conference reflect it.



Good luck!

Andrei

Re: DConf 2015 Call for Submissions is now open

[Andrei Alexandrescu via Digitalmars-d-announce]

On 1/6/15 3:24 PM, Andrei Alexandrescu wrote:
[snip]

http://www.reddit.com/r/programming/comments/2rkg7i/call_for_submissions_the_d_programming_language/

https://twitter.com/D_Programming/status/552607568195883009


Andrei

Re: Copy only frame pointer between objects of nested struct

[Artur Skawina via Digitalmars-d-learn]

On 01/06/15 23:14, Peter Alexander via Digitalmars-d-learn wrote:
 auto foo(T)(T a) {
 T b;  // Error: cannot access frame pointer of main.X
 b.data[] = 1;
 return b;
 }
 
 void main() {
 struct X {
 this(int) {}
 int[4096] data;
 }
 foo(X());   
 }
 
 Note the error is because you cannot construct the main.X object without a 
 frame pointer.
 
 You could do `T b = a` here to get a's frame pointer, but it would also copy 
 all of a's data, which is expensive and unnecessary.
 
 Is there a way to only copy a's frame pointer into b?

The obvious hack would be

T b = void;
b.tupleof[$-1] = a.tupleof[$-1];

but you probably don't want to do it like that...

 (Note: this is just an illustrative example, real problem here: 
 https://issues.dlang.org/show_bug.cgi?id=13935)

That shows a static struct, so I'm not sure it's the same problem.

artur

Re: Ready to make page-per-item ddocs the default?

[weaselcat via Digitalmars-d]

On Tuesday, 6 January 2015 at 22:43:45 UTC, Andrei Alexandrescu 
wrote:
Let's crowdsource the review. Please check the entries linked 
from here: http://dlang.org/library/index.html.


Andrei


Is it intentional for all of the stdc pages to be empty?

Re: Ready to make page-per-item ddocs the default?

[Brad Anderson via Digitalmars-d]

On Wednesday, 7 January 2015 at 00:06:28 UTC, Danny wrote:

http://dlang.org/library/core/math/ldexp.html

Compute n * 2⊃

Huh?


Weird.

It's `Compute n * 2$(SUP exp)` in the source[1]. SUP is a locally 
defined macro. Maybe ddox doesn't like local macros?


1. 
https://github.com/D-Programming-Language/druntime/blob/v2.066.1/src/core/math.d#L96

Re: Ready to make page-per-item ddocs the default?

[Danny via Digitalmars-d]

http://dlang.org/library/core/math/ldexp.html

Compute n * 2⊃

Huh?

Re: Phobos colour module?

[via Digitalmars-d]

For inspiration:

http://golang.org/pkg/image/color/

Re: Ready to make page-per-item ddocs the default?

[Brian Schott via Digitalmars-d]

On Tuesday, 6 January 2015 at 23:44:30 UTC, weaselcat wrote:

Is it intentional for all of the stdc pages to be empty?


I think it's intentional that they don't duplicate the 
documentation for those headers, but we probably should add links 
to pages that document the C headers.

Re: DConf 2015 Call for Submissions is now open

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

Reddit downvotes seem to be the most arbitrary things on the 
Internet. I don't understand them at all.

Re: Phobos colour module?

[Manu via Digitalmars-d]

On 7 January 2015 at 09:22, via Digitalmars-d
digitalmars-d@puremagic.com wrote:
 For inspiration:

 http://golang.org/pkg/image/color/

Umm, is there something about this that you like? This looks... really terrible.

Re: Ready to make page-per-item ddocs the default?

[Robert burner Schadek via Digitalmars-d]

std.string looks fine only the indexOfNeither and 
lastIndexOfNeither are missing

Re: DConf 2015?

[Chuck Allison via Digitalmars-d]

No tie required, Adam (you'd be the only one :-).

Chuck


On Tuesday, 30 December 2014 at 03:47:17 UTC, Adam D. Ruppe wrote:
On Tuesday, 30 December 2014 at 03:38:08 UTC, Walter Bright 
wrote:

It'll be at Utah Valley University:


OOh, I might not be the only person there wearing a tie this 
time!

Re: Error: function declaration without return type.

[Suliman via Digitalmars-d-learn]

On Tuesday, 6 January 2015 at 21:19:38 UTC, bearophile wrote:

Suliman:


void foo()
{
writeln(test);
writeln(mystring);
}
foo();   
}


I guess you have to remove that line.

Bye,
bearophile


Why? I can't call function in instance of class?

Re: == operator

[Jonathan Marler via Digitalmars-d]

I've create a PR for a templated opEquals here 
(https://github.com/D-Programming-Language/druntime/pull/1087).  
Currently it will not build without some changes in phobos, PR 
here 
(https://github.com/D-Programming-Language/phobos/pull/2848).  
Using the new templated opEquals it fixed the 
overhead/performance issues as seen here:


compiled on windows(x64): dmd opEqualsTest.d -inline -O -release

run 1 (loopcount 1000)
  x.x == y.x   : 11609 microseconds
  x.opEquals(y): 22303 microseconds
  x.opEquals(cast(Object)y): 146859 microseconds
  x == y   : 37685 microseconds
run 2 (loopcount 1000)
  x.x == y.x   : 7525 microseconds
  x.opEquals(y): 7528 microseconds
  x.opEquals(cast(Object)y): 106771 microseconds
  x == y   : 37251 microseconds

As you can see the '==' operator is now much close to the direct 
call to opEquals.  There is still some minimal overhead (I think 
caused by an extra function call and some null checks) but it is 
much closer.  I'm still working on the PRs but this may be a good 
solution.

Re: An idea for commercial support for D

[uri via Digitalmars-d]

On Tuesday, 6 January 2015 at 13:34:59 UTC, Joakim wrote:

Before you make such claims, you should probably think about 
them a little bit first.  Please tell me one company that does 
not buy outside commercial software which they then use to 
build their own products.  Some companies will want to cherry 
pick features, others will just buy an accumulated patchset 
against the point release from many devs.  The suggestion that 
all companies will have to spend a great deal of time picking 
what patches they want is just silly.


To me it doesn't make sense for a company to cherry pick compiler 
patches. The model you propose may work for applications where 
there is a clean distinction between user needs and wants but in 
a compiler you generally need all the features to work 
effectively and produce reasonable code. The optimizer may be a 
different story so perhaps that aspect of compilation could be 
split.


Besides splitting the compiler will result in a maintenance 
headache. Missing features in the compiler will not result in 
subset-D and complete-D but half-baked-nearly-working-D and 
working-D, if you're lucky.




This means A and B can't make any money off their patches, so 
they have to get some other job. That means they only have time 
to work on M and X on the occasional weekend and each of those 
patches takes six months to finish.  You are obviously okay 
with that glacial pace as long as you get their work for free, 
but others are willing to pay to get the pace of D development 
sped up.


This is only true if all patches are equally priced. Otherwise it 
breaks down and has been proven mathematically.



Glad you brought this up, there are several possibilities.  
Many users would probably just buy all the closed patches 
against a point release, so there is no question of splitting 
features.  But a handful of paying customers may be more 
adventurous, or cheap, ;) and choose to only buy a custom build 
with their needed features X,Y,Z.  This probably wouldn't 
happen right away, as it will take more time to setup a build 
process to support it, but supporting custom builds like that 
is definitely worthwhile.


OK, but the D devs still need to split the release between paid 
patches and non-paid patches. This is non-trivial in a compiler 
and adds additional work for the volunteers. Companies won't pay 
for the split because it isn't value adding for them so it will 
fall on the volunteers.


To begin with, D is not a GPL project, so why would they 
release them under the GPL?


So we wait some time period for the patch to be released.

As stated earlier, the patches would need to be funded up to 
some monetary and time limits before they would be released 
back to the OSS project.  So party A might contract with their 
paying customers that they'll release patches X,Y,Z once they 
accumulate $5k in payments from all the customers who buy those 
patches, plus a six month delay after that.  If they don't make 
$5k for a long time, the patches won't be released for a long 
time.


Then I think most OSS users would move on to another language. 
There is no point working with a compiler that is half-baked 
unless you pay for it. This is an issue because it's the OSS 
community that provides ongoing maintenance to the paid for 
patches. If OSS isn't there anymore then Digital Mars needs to 
start charging maintenance costs to upkeep the codebase. I don't 
think that will work, but it's only my opinion.


Why does anyone pay for software now?  It doesn't much matter 
to a paying customer that the feature will probably be free in 
a year or two if they need to use it to make money _now_.


But that's assuming an entity needs D to make money now. They 
don't because we have C++, Java, C# already. Why not just use one 
of those more mature languages?




As for people leaving because somebody else has developed a 
proprietary feature for D and not given it to them for free, 
companies like Sociomantic have already developed such features 
and they haven't been integrated upstream, why haven't most 
left already?


The features from Sociomantic features are all D1 and also there 
are devs from Sociomantic are trying to get features released 
upstream. Sociomantic isn't the blocker it's integrating the 
features into D2.



The dmd backend is not under an OSS license, why haven't they 
left?  I suspect there are not very many of the type of people 
you're talking about in the D community.


It's possible that you're right but I don't see it happening. The 
backend doesn't provide any benefit to GDC and LDC and Walter has 
a very good reason for closing the backend sources which is 
understood by all.


Maybe a handful of FOSS zealots would leave, but the resulting 
commercially supported D would be so much better, they'd be 
swamped by the new people coming on board. :)


We'll see :)

Cheers,
uri

What is the absolute minimum code for a D kernel, and how should it be compiled?

[Stijn via Digitalmars-d-learn]

After writing a bootloader and getting it to jump to a Hello 
World kernel written in assembly, I want to give it a go with a 
kernel written in D. I'm using GDC because I didn't have much 
luck with making DMD skip the D runtime and standard libs.


Starting with this code:

void main() { }

Compiling it like this:

i686-gdcproject-mingw32-gdc.exe kernel.d -o 
../bin/kernel.bin -nophoboslib -nostdlib -s



This is the output:
kernel.d:(.text+0xa): undefined reference to `__main'
kernel.d:(.text+0x24): undefined reference to `_d_run_main'
(.text+0x38): undefined reference to `_Dmodule_ref'
(.text+0x43): undefined reference to `_Dmodule_ref'

According to 
http://stackoverflow.com/questions/13573289/how-to-compile-d-application-without-the-d-runtime 
I need something more like this:


extern(C) __gshared void* _Dmodule_ref;
extern(C) int main() { return 0; }

Now this is the output:
kernel.d:(.text+0x7): undefined reference to `__main'

So I have two problems here. The first one is that it's not 
working. The second one is that I'm copy pasting code, and 
perhaps by trying a bunch of variations I'll manage to get 
something that compiles, but I probably still won't understand 
what I'm doing and why it does or does not work.


Now I'm hoping that someone can give me a hand with working code, 
and also explain the reasoning behind it.

Re: What is the absolute minimum code for a D kernel, and how should it be compiled?

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

I showed how to do it in my book using dmd. Here's the code:

http://arsdnet.net/dcode/book/chapter_11/01/

Explanation is in chapter 11 here:
https://www.packtpub.com/application-development/d-cookbook

In the appendix, I also did ARM with gdc:
http://arsdnet.net/dcode/book/appendix_a/01/


The arm one might be easier to start with than the dmd one, 
despite dmd being x86. I went a bit further there, even up to 
keyboard support in the second section with interrupt handlers.



Short version of the explanation is that the compiler outputs 
hooks for the runtime library and you need to stub those out as 
you hit them. Some are required just for the beginning.



BTW make sure your bootloader puts the processor in 32 bit more. 
D doesn't support 16 bit code.

Ready to make page-per-item ddocs the default?

[Andrei Alexandrescu via Digitalmars-d]

Let's crowdsource the review. Please check the entries linked from here: 
http://dlang.org/library/index.html.


Andrei

Re: How to prevent sensitive information is displayed when the extension 'exe' is modified to 'txt' on windows?

[Martin Drašar via Digitalmars-d-learn]

Dne 6.1.2015 v 18:15 FrankLike via Digitalmars-d-learn napsal(a):
 How to prevent sensitive information is displayed when the extension
 'exe' is modified to 'txt' on windows?
 
 If you build a exe ,such as which can get Data from DataBase,when you
 modify the exe's  extension to 'txt',
 and you open it by notepad.exe (on windows),you will find the info,it's
 important for me,so how to stop  the info to display  ?
 
 
   Driver={SQL Server Native Client
 10.0};Server=127.0.0.1;Database=test;Trusted_Connection=Yes\   €`B
 SELECT top 10 * FROM testtable     鑐B atest.d    aB
 testcolumnname  aB std.stdio.File err.text    GaB w   
   XaB
 error :
    haB  @ 
 
 
 Thank you.

What you want is some kind of code obfuscation. The easiest thing for
you is to use exe compression. It is not going to stop a dedicated
attacker, but ordinary people will not be able to extract any
information from it.

http://upx.sourceforge.net/

Martin



smime.p7s
Description: Elektronicky podpis S/MIME

Re: std.experimental.logger formal review round 3

[Andrei Alexandrescu via Digitalmars-d]

On 1/6/15 8:51 AM, Robert burner Schadek wrote:

recent updates:
* Martins CT log function disabling (thanks Martin)
* new thread local indirection Logger between free standing log
functions and program global Logger
* more documentation
* some @trusted have been remove (thanks Dicebot)
* local imports

please review


Links for the lazy.

Code:

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

Dox:

http://burner.github.io/phobos/phobos-prerelease/std_experimental_logger_core.html
http://burner.github.io/phobos/phobos-prerelease/std_experimental_logger_filelogger.html
http://burner.github.io/phobos/phobos-prerelease/std_experimental_logger_multilogger.html
http://burner.github.io/phobos/phobos-prerelease/std_experimental_logger_nulllogger.html


Andrei

Copy only frame pointer between objects of nested struct

[Peter Alexander via Digitalmars-d-learn]

Consider:

auto foo(T)(T a) {
T b;  // Error: cannot access frame pointer of main.X
b.data[] = 1;
return b;
}

void main() {
struct X {
this(int) {}
int[4096] data;
}
foo(X());   
}

Note the error is because you cannot construct the main.X object 
without a frame pointer.


You could do `T b = a` here to get a's frame pointer, but it 
would also copy all of a's data, which is expensive and 
unnecessary.


Is there a way to only copy a's frame pointer into b?

(Note: this is just an illustrative example, real problem here: 
https://issues.dlang.org/show_bug.cgi?id=13935)

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Tuesday, 6 January 2015 at 19:06:27 UTC, anonymous wrote:

On Tuesday, 6 January 2015 at 06:14:37 UTC, Joakim wrote:
On Monday, 5 January 2015 at 22:51:25 UTC, Joseph Rushton 
Wakeling via Digitalmars-d wrote:

[...]
Most commercial adopters are going to consider it very 
important to have a support option that says, If you have a 
serious blocker, you can pay us money to guarantee that it 
gets fixed.


They are not going to be at all happy about a support option 
that says, If we develop a fix, then you are not going to 
get it in a timely manner unless you pay.


Understanding that distinction is very important.


Haha, you do realize that those two quotes you laid out are 
the exact same option?  In the first option, you pay for a 
fix.  In the second option, you pay for a fix.  What 
distinction you're hoping to draw has not been made.


In the first option, you pay for a fix now, or you get it for 
free when it's done independently of you, e.g. because someone 
else paid.


I don't know of any commercial support model where you only pay 
for the fixes you need at any given moment and the fixes that 
others paid for are provided to you for free.  I presume you're 
referring to support subscriptions, where you pay a monthly fee 
to subscribe to an stream of ongoing fixes and pay extra for 
fixes you need right away.  But that's not free, you're paying 
a monthly fee for that ongoing subscription, which subsidizes the 
cost of those fixes that others paid for first.


In the second option, you pay for a fix. If it's done 
independently of you, you still pay.


You pay for both types of fixes in both models.


[...]
I also think you assume far too much value on the part of 
privileged/early access to bugfixes.  A bug in a programming 
language toolchain is either a commercial problem for you or 
it isn't.  If it's a commercial problem, you need it fixed, 
and that fix in itself has a value to you.  There is not 
really any comparable change in value if that fix also gets 
delivered to other users (who may or may not be competitors 
of yours), because that isn't what differentiates your 
product.


Of course there's a change in value.  If another user or 
competitor also needs that fix and pays for it and upstreams 
it before you do, that's a cost you don't have to pay at all.  
Hence the whole tragedy of the commons I laid out in my 
first post.


If I get him right, Joseph's point is that the patch's value 
(not its cost) for the customer doesn't change whether others 
have access to it or not. So there's no advantage for the 
customer in the early-access model. But there's a disadvantage: 
have to pay for every patch. And so, an early-access model may 
not be attractive to paying customers.


My point was that he's wrong that the patch's value doesn't 
change if others have access to it.  Just because that patch 
doesn't clearly differentiate your product on a spec sheet 
doesn't mean those patches in aggregate don't differentiate your 
time to market and cost of making the product, which will all 
affect your bottom line.


There is no disadvantage to paying for the patch in this model, 
because otherwise you don't get the patch.  You are paying 
someone to write the patch so that it exists in the first place.  
Otherwise, you can hope that some OSS dev gets to it someday when 
he gets some spare time.


If I get you right, you're saying that the revenue for the 
patch writer changes depending on if they sell the patch once 
or twice. And therefore, there's an advantage for the patch 
writer in the early-access model: can sell one patch multiple 
times.


Yes, that's one of the big benefits, the patches become his 
product.


You're both not wrong. If it works as planned, the early-access 
isn't benefitial to the buyer, but to the seller. And that's 
the point: move (more) money from customers to patch writers. 
It's not a win-win. It's not supposed to be. But if there's 
nothing to gain in an early-access for the customer, why should 
they prefer it over a competitor with 
immediate-access-for-everyone?


It _is_ win-win, that's the whole point.  It's even win-win-win, 
to crib a term from The Office, ;) because the OSS project 
eventually also gets the patch after a delay.


I don't know who this hypothetical competitor is who provides 
immediate-access-for-everyone and is cranking out a ton of 
patches.  They currently don't exist.



[...]
On the contrary, D is a programming language, and as such is 
used by people to make commercial projects, and so those 
people have a very strong interest in paying for commercial 
support, based around the principle If we need something 
fixed, it will be fixed.


But they don't have an interest in a situation where, If 
something gets fixed, we have to pay.


The first of those options delivers value.  The second is 
exploitation.


I suggest you actually read what you're writing:

people have a very strong interest in paying for commercial 
support, 

Re: DConf 2015?

[CraigDillabaugh via Digitalmars-d]

On Tuesday, 6 January 2015 at 21:05:57 UTC, Chuck Allison wrote:
Just so you all know, DConf 2015 is scheduled when Utah is it's 
most beautiful. Not too hot, everything green, perfect for 
hiking, whatever. If you have never been to Southern Utah 
before, you might want to consider scheduling some time to see 
the National Parks and other like places before or after the 
conference.


Will the ski hills still be open?

Re: Error: function declaration without return type.

[bearophile via Digitalmars-d-learn]

Suliman:


void foo()
{
writeln(test);
writeln(mystring);
}
foo();   
}


I guess you have to remove that line.

Bye,
bearophile

Error: function declaration without return type.

[Suliman via Digitalmars-d-learn]

class Test
{
string mystring;

this(string mystring)
{
this.mystring = mystring;
}

void foo()
{
writeln(test);
writeln(mystring);
}
foo();
}

source\app.d(303): Error: function declaration without return 
type. (Note that c

onstructors are always named 'this')
source\app.d(303): Error: no identifier for declarator foo()
FAIL 
.dub\build\application-debug-windows-x86-dmd_2066-EF7A441AE01F652132F0A1ED8

B06EB48\ seismodownloader executable
Error executing command run: dmd failed with exit code 1.

What I am doing wrong?

Re: Error: function declaration without return type.

[Martin Drašar via Digitalmars-d-learn]

Dne 6.1.2015 v 22:25 Suliman via Digitalmars-d-learn napsal(a):
 On Tuesday, 6 January 2015 at 21:19:38 UTC, bearophile wrote:
 Suliman:

 void foo()
 {
 writeln(test);
 writeln(mystring);
 }
 foo();   
 }

 I guess you have to remove that line.

 Bye,
 bearophile
 
 Why? I can't call function in instance of class?

What would that even mean? When would the function ran? If you want to
call that function during instantiation, put it into constructor. If you
want to call it sometime later, than you have to call it from somewhere
else. But having a function call inside a class does not compute...

Martin



smime.p7s
Description: Elektronicky podpis S/MIME

Re: @api: One attribute to rule them All

[Elie Morisse via Digitalmars-d]

On Tuesday, 6 January 2015 at 12:07:21 UTC, Joseph Rushton 
Wakeling wrote:

I think you have missed the point I was making.

If you have final-by-default for classes, and you accidentally 
forget to tag a public method as 'virtual', then you can fix 
that without breaking any downstream user's code.  If by 
contrast you have virtual-by-default and you accidentally 
forget to tag a public method as 'final', then you can't fix 
that without the risk of breaking downstream; _someone_ may 
have relied on that function being virtual.



For people making libraries which really need to keep ABI 
compatibility there should be some quick trick to tell the 
compiler to build those ABI-stable interfaces like:


  class {
  final @api:
...

  virtual @api:
...
  }

It's imho a small price to pay for not having to always write 
explicit attributes for most D functions.

Re: What is the absolute minimum code for a D kernel, and how should it be compiled?

[Stijn via Digitalmars-d-learn]

On Tuesday, 6 January 2015 at 22:41:06 UTC, Adam D. Ruppe wrote:

I showed how to do it in my book using dmd. Here's the code:

http://arsdnet.net/dcode/book/chapter_11/01/


I've just bought the book, I'll dive right into it :) Thanks!

Re: Ready to make page-per-item ddocs the default?

[Walter Bright via Digitalmars-d]

On 1/6/2015 2:43 PM, Andrei Alexandrescu wrote:

Let's crowdsource the review. Please check the entries linked from here:
http://dlang.org/library/index.html.


The table:

  http://dlang.org/phobos/std_math.html#.cos

got lost:

  http://dlang.org/library/std/math/cos.html

Also, the 2$(SUP 64). got turned into 2,64.

Re: For the lulz: ddmd vs libdparse lexer timings

[David Nadlinger via Digitalmars-d]

On Tuesday, 6 January 2015 at 15:42:22 UTC, Daniel Murphy wrote:
Yes, but __va_argsave is declared in the frontend, which is 
unnecessary.  It was easy enough to make the glue layer reserve 
the right number of bytes for varargs functions.


I agree. Walter said that he didn't manage to implement it back 
then, though, and I never looked at the glue layer.


I made it a magic compiler type, and I'll make it automagically 
pass by ref when used as a function argument on X86_64 posix.  
That should do it.


Yes, that should indeed do it. I shied away from unilaterially 
making it a magic type in LDC to avoid unpleasant surprises for 
users. However, it is definitely the cleaner option imho.


How does LDC currently handle it?  Does llvm have an easy way 
to handle the implementation of va_* for you?


LLVM gives us va_start/…, and in theory also va_arg. However, 
there are two issues why we don't use the latter on Posix x86_64 
and rely on Walter's druntime implementation instead:


 1) For the template version of va_arg(), we'd need to redo the 
lowering of D types to the ABI types (passing in registers and so 
on, which is sadly not automatic in LLVM as its type system can't 
represent all C types). This could be implemented somewhat easily 
on top of argTypes, but because of 2) it was not really worth the 
effort.


 2) There is also a va_arg version that takes a TypeInfo at 
runtime. There doesn't really seem to be a way to implement this 
on top of what LLVM offers.


And as I said above, we currently have va_list as a pointer type 
for reasons of simplicity. Thus, we need to actually have our LDC 
va_start/va_copy intrinsics actually allocate memory for the 
register save area on the stack before forwarding to the LLVM 
ones. This is a huge hack, but just about seems to be enough to 
covervirtually all real-world use cases. In any case, I'm looking 
forward to cleaning this mess up once your DMD patches are in.


David

Re: Ready to make page-per-item ddocs the default?

[Andrei Alexandrescu via Digitalmars-d]

On 1/6/15 4:42 PM, Brad Anderson wrote:

On Wednesday, 7 January 2015 at 00:06:28 UTC, Danny wrote:

http://dlang.org/library/core/math/ldexp.html

Compute n * 2⊃

Huh?


Weird.

It's `Compute n * 2$(SUP exp)` in the source[1]. SUP is a locally
defined macro. Maybe ddox doesn't like local macros?

1.
https://github.com/D-Programming-Language/druntime/blob/v2.066.1/src/core/math.d#L96


Yah, looks like a problem with ddox. Anyhow for now I fixed by using 
SUPERSCRIPT.


https://github.com/D-Programming-Language/druntime/commit/8f655bbdd8f7aa77907053c918d78d2286c93ab2

http://dlang.org/library-prerelease/core/math/ldexp.html


Andrei

Re: Ready to make page-per-item ddocs the default?

[Andrei Alexandrescu via Digitalmars-d]

On 1/6/15 4:26 PM, Robert burner Schadek wrote:

std.string looks fine only the indexOfNeither and lastIndexOfNeither are
missing


Could you please fix -- thanks! -- Andrei

Re: Ready to make page-per-item ddocs the default?

[Steven Schveighoffer via Digitalmars-d]

On 1/6/15 5:43 PM, Andrei Alexandrescu wrote:

Let's crowdsource the review. Please check the entries linked from here:
http://dlang.org/library/index.html.


std.algorithm has many of the descriptions showing samples. Also, I 
know the table at the top is to make things easier for standard ddoc, 
should that be removed?


BTW, I'm all for the docs to be switched. Just the cross-referencing 
alone is worth it.


-Steve

Re: We need a DConf 2015 logo

[Walter Bright via Digitalmars-d]

On 1/6/2015 11:37 AM, Steven Schveighoffer wrote:

I plan to submit my talk on 2/27 at 23:59:59.991 PST. I hope that's ok.


We'd prefer it was before 2/27 at 23:59:59.989 PST

Re: Ready to make page-per-item ddocs the default?

[Walter Bright via Digitalmars-d]

On 1/6/2015 2:43 PM, Andrei Alexandrescu wrote:

Let's crowdsource the review. Please check the entries linked from here:
http://dlang.org/library/index.html.


In:

  http://dlang.org/library/std/algorithm/make_index.html

if you click on the 'forward' link, it takes you to something quite unexpected. 
Looks like an issue with automatic cross referencing?

Re: Ready to make page-per-item ddocs the default?

[Paul O'Neil via Digitalmars-d]

On 01/06/2015 05:43 PM, Andrei Alexandrescu wrote:
 Let's crowdsource the review. Please check the entries linked from here:
 http://dlang.org/library/index.html.
 
 Andrei

On that page itself, the descriptions for at least std.regex and std.uni
include the headers (e.g Intro, Overview) from those pages.

-- 
Paul O'Neil
Github / IRC: todayman

Re: An idea for commercial support for D

[Joseph Rushton Wakeling via Digitalmars-d]

On 06/01/15 23:32, uri via Digitalmars-d wrote:

The dmd backend is not under an OSS license, why haven't they left?  I suspect
there are not very many of the type of people you're talking about in the D
community.


It's possible that you're right but I don't see it happening. The backend
doesn't provide any benefit to GDC and LDC and Walter has a very good reason for
closing the backend sources which is understood by all.


Small point: the DMD backend may not be released under a free software license, 
but it is not closed -- the source is available, development happens in the 
open, and in a de facto (rather than de jure) sense there is little to 
distinguish from an open source project.  The licensing situation is obviously 
unfortunate, but it makes little practical difference considering that the vast 
majority of D language development is in the freely-licensed frontend, runtime 
or standard library, and there are two excellent free backends available.


This is a pretty good example of what I have referred to elsewhere in this 
thread, about the contextual nature of objections to non-free.

Re: Ready to make page-per-item ddocs the default?

[Walter Bright via Digitalmars-d]

On 1/6/2015 2:43 PM, Andrei Alexandrescu wrote:

Let's crowdsource the review. Please check the entries linked from here:
http://dlang.org/library/index.html.


Looks nice! And will provide motivation to fix a lot of the under-documented 
functions.