date:20131004


On 2013-10-04 01:24, Martin Nowak wrote:


That's it's key feature, any attempt to first come up with a generic
tool would be doomed to fail. Also DMD's code base uses only a limited
subset of C++ which makes it more amenable to automatic translation.


Having #ifdef inside declarations must be a nightmare for a tool like 
this. Making that properly work on generic code bases sound impossible 
to me.


--
/Jacob Carlborg

Re: WTF abstract is?


On Friday, 4 October 2013 at 06:10:30 UTC, deadalnix wrote:

On Friday, 4 October 2013 at 05:07:53 UTC, Zhouxuan wrote:


//case 1

class A
{
   abstract void foo();
}

class B : A
{
   static if( __traits(isAbstractClass, typeof(this) ))


this is invalid here. Not sure what you try to achieve via this 
static if.


I want to define some variables in non-abstract class.

Re: C++ - D converter mentioned in AMA

2013-10-04 Thread Szymon Gatner


On Friday, 4 October 2013 at 06:33:10 UTC, Jacob Carlborg wrote:

On 2013-10-04 01:24, Martin Nowak wrote:

That's it's key feature, any attempt to first come up with a 
generic
tool would be doomed to fail. Also DMD's code base uses only a 
limited
subset of C++ which makes it more amenable to automatic 
translation.


Having #ifdef inside declarations must be a nightmare for a 
tool like this. Making that properly work on generic code bases 
sound impossible to me.


Well, that is nothing Clang can't handle. The subset is what I 
was asking for -  there has to be something that tool handles 
correctly, right?

Re: WTF abstract is?


On Friday, 4 October 2013 at 06:22:57 UTC, Ali Çehreli wrote:

On 10/03/2013 11:10 PM, deadalnix wrote:

 On Friday, 4 October 2013 at 05:07:53 UTC, Zhouxuan wrote:
 
 //case 1

 class A
 {
 abstract void foo();
 }

 class B : A
 {
 static if( __traits(isAbstractClass, typeof(this) ))

 this is invalid here. Not sure what you try to achieve via
this static if.

Well, obviously that is the reason for the bug. :) I think 
Zhouxuan thinks that it is an 'abstract' bug but actually it is 
some sort of __traits caching issue.


It would indeed be weird for isAbstractClass to delay its value 
until the whole class definition is seen.


Instead, what seems to happen is that isAbstractClass caches 
the first value that it determines and perhaps at least for 
consistency uses that value. Moving isAbstractClass after the 
definition of B.foo removes the issue in this case:


Indeed I found the issue from use of isAbstractClass, but after 
some

tests I'm confused by these abstract use cases.

Re: ctrl+c and destructors


On 2013-10-04 02:08, H. S. Teoh wrote:


Reminds me of a GUI app I tried years ago, that suffered from some kind
of memory corruption bug. Every now and then it would segfault due to
hitting the corruption... one time, it *didn't* segfault, but continued
merrily on and corrupted all of my data -- worth many hours of work --
all without showing any signs of problems, and then out of habit I saved
the file I was working on, and it barged ahead and wrote garbage all
over my last good copy of the data. :-(


I have had the same experience. We had to use an application in school 
that was notorious to crash and corrupt your files. I kept ten different 
save files, cycled through them when I saved. When it did crash it 
corrupt not just the file I was working on but five other of my ten save 
files. Of course, these we're the five latest files and the other were 
too old. That really sucked.


--
/Jacob Carlborg

Re: mixin module template - undefined identifier

P.S. I have tried contacting you in context of std.logger, is 
mail address mentioned on github valid one? If not, please ping 
me via public.dicebot.lv

Re: mixin module template - undefined identifier

By spec name resolution for templates happens in declaration 
scope. Mixin templates are only exception.


If referencing symbol from other module during code gen is a 
unavoidable necessity, you should use instrospection on `T` and 
add its module into code gen as template-local import (something 
like 
https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/restutil.d#L341)

Re: C++ - D converter mentioned in AMA


On 2013-10-04 08:37, Szymon Gatner wrote:


Well, that is nothing Clang can't handle. The subset is what I was
asking for -  there has to be something that tool handles correctly, right?


Of course Clang will be able to lex and parse it. But how should it be 
translated?


void foo (int a
#if BAR
,
int b
#endif
)
{ ... }

You cannot do the exact same thing in D:

void foo (int a
version (BAR)
{
,
int b
}
)
{ ... }

Doing these crazy things are only possible with a preprocessor.

Then you need to duplicate the function, use a string mixin or something 
else that's ugly.


We can take a simpler example:

#if _WIN32
void foo (int);
#elif __APPLE__
void foo (long long);
#elif linux
void foo (long long);
#endif

Translating this manually it would look like this:

version (Windows)
void foo (int);
else version (OSX)
void foo (long);
else version (linux)
void foo (long);

But how could this be translated automatically? In this case you would 
want to have all the above preprocessor macros enabled, at the same 
time. Or somehow run it multiple times with different macros enabled and 
merge them.


I don't know how the preprocessor API looks like in Clang. If you could 
search for hard coded identifiers or something similar.


--
/Jacob Carlborg

std.file.fileType

2013-10-04 Thread FreeSlave


I was suggested to bring this idea up here.

fileType should be a function for determining of file type.

Example of usage:
Suppose application uses special directory for plugins (i.e. 
dynamic libraries). In graphics user interface it can be 
reflected like list of checkboxes that show which plugins are on 
and which are off. To implement this we should know that file 
actually represents dynamic library without trying to load it 
into executable memory. Yes, we can load and unload every file in 
place to check that it's valid dynamic library but it's some kind 
of hack.


Another example is file manager. It has icons for the most common 
file types and usually relies on file extension to determine 
which icon should be used. But we can't always rely on extension. 
For example many games use .pk3 extension as alias to .zip, but 
file manager know nothing about it and shows these files like 
ones with unknown extension.


So how do you think does phobos need these capabilities? May be 
you have other examples where this function can be useful.

Re: ctrl+c and destructors


On 10/3/2013 11:46 PM, Jacob Carlborg wrote:

On 2013-10-04 02:08, H. S. Teoh wrote:


Reminds me of a GUI app I tried years ago, that suffered from some kind
of memory corruption bug. Every now and then it would segfault due to
hitting the corruption... one time, it *didn't* segfault, but continued
merrily on and corrupted all of my data -- worth many hours of work --
all without showing any signs of problems, and then out of habit I saved
the file I was working on, and it barged ahead and wrote garbage all
over my last good copy of the data. :-(


I have had the same experience. We had to use an application in school that was
notorious to crash and corrupt your files. I kept ten different save files,
cycled through them when I saved. When it did crash it corrupt not just the file
I was working on but five other of my ten save files. Of course, these we're the
five latest files and the other were too old. That really sucked.



I think it's pretty clear that the solution to saving a user's work-in-progress 
is to have the application actually save the work-in-progress at regular 
intervals, not try to save it after it has crashed.

Re: std.file.fileType

2013-10-04 Thread simendsjo


On Friday, 4 October 2013 at 07:39:36 UTC, FreeSlave wrote:

I was suggested to bring this idea up here.

fileType should be a function for determining of file type.

Example of usage:
Suppose application uses special directory for plugins (i.e. 
dynamic libraries). In graphics user interface it can be 
reflected like list of checkboxes that show which plugins are 
on and which are off. To implement this we should know that 
file actually represents dynamic library without trying to load 
it into executable memory. Yes, we can load and unload every 
file in place to check that it's valid dynamic library but it's 
some kind of hack.


Another example is file manager. It has icons for the most 
common file types and usually relies on file extension to 
determine which icon should be used. But we can't always rely 
on extension. For example many games use .pk3 extension as 
alias to .zip, but file manager know nothing about it and shows 
these files like ones with unknown extension.


So how do you think does phobos need these capabilities? May be 
you have other examples where this function can be useful.


Seems a bit specific to be put in the standard library. If you 
don't mind GPL, you can look at the source for file: 
http://www.darwinsys.com/file/

Re: mixin module template - undefined identifier

2013-10-04 Thread Robert Schadek

On 10/04/2013 09:07 AM, Dicebot wrote:
 P.S. I have tried contacting you in context of std.logger, is mail
 address mentioned on github valid one? If not, please ping me via
 public.dicebot.lv
Yes it is, strange. Try the one I use here.

Re: std.file.fileType

2013-10-04 Thread FreeSlave


On Friday, 4 October 2013 at 08:06:24 UTC, simendsjo wrote:

On Friday, 4 October 2013 at 07:39:36 UTC, FreeSlave wrote:

I was suggested to bring this idea up here.

fileType should be a function for determining of file type.

Example of usage:
Suppose application uses special directory for plugins (i.e. 
dynamic libraries). In graphics user interface it can be 
reflected like list of checkboxes that show which plugins are 
on and which are off. To implement this we should know that 
file actually represents dynamic library without trying to 
load it into executable memory. Yes, we can load and unload 
every file in place to check that it's valid dynamic library 
but it's some kind of hack.


Another example is file manager. It has icons for the most 
common file types and usually relies on file extension to 
determine which icon should be used. But we can't always rely 
on extension. For example many games use .pk3 extension as 
alias to .zip, but file manager know nothing about it and 
shows these files like ones with unknown extension.


So how do you think does phobos need these capabilities? May 
be you have other examples where this function can be useful.


Seems a bit specific to be put in the standard library. If you 
don't mind GPL, you can look at the source for file: 
http://www.darwinsys.com/file/


Ok, I'll check it out.

I've just called to mind another use, the most important I think. 
It's for web services to prevent from uploading possibly harmful 
files (executables) or to check service support for given file.

Re: mixin module template - undefined identifier

2013-10-04 Thread Robert Schadek

On 10/04/2013 04:36 AM, David Nadlinger wrote:
 Maybe you can elaborate a bit on how the problem occurs in that
 context? As I said, I've found that usually it is possible to come up
 with a design at least as pretty (or even prettier) but doesn't rely
 on stringof trickery if one just stares at the problem long enough. ;)

I will try to find a way around.

Re: std.d.lexer : voting thread

2013-10-04 Thread Jakob Ovrum


On Wednesday, 2 October 2013 at 14:41:56 UTC, Dicebot wrote:
After brief discussion with Brian and gathering data from the 
review thread, I have decided to start voting for `std.d.lexer` 
inclusion into Phobos.


No.

Let's iron out the issues first, both interface and possible 
performance issues.

Re: std.file.fileType

2013-10-04 Thread simendsjo


On Friday, 4 October 2013 at 08:27:00 UTC, FreeSlave wrote:

On Friday, 4 October 2013 at 08:06:24 UTC, simendsjo wrote:

On Friday, 4 October 2013 at 07:39:36 UTC, FreeSlave wrote:

I was suggested to bring this idea up here.

fileType should be a function for determining of file type.

Example of usage:
Suppose application uses special directory for plugins (i.e. 
dynamic libraries). In graphics user interface it can be 
reflected like list of checkboxes that show which plugins are 
on and which are off. To implement this we should know that 
file actually represents dynamic library without trying to 
load it into executable memory. Yes, we can load and unload 
every file in place to check that it's valid dynamic library 
but it's some kind of hack.


Another example is file manager. It has icons for the most 
common file types and usually relies on file extension to 
determine which icon should be used. But we can't always rely 
on extension. For example many games use .pk3 extension as 
alias to .zip, but file manager know nothing about it and 
shows these files like ones with unknown extension.


So how do you think does phobos need these capabilities? May 
be you have other examples where this function can be useful.


Seems a bit specific to be put in the standard library. If you 
don't mind GPL, you can look at the source for file: 
http://www.darwinsys.com/file/


Ok, I'll check it out.

I've just called to mind another use, the most important I 
think. It's for web services to prevent from uploading possibly 
harmful files (executables) or to check service support for 
given file.


The executable thing is quite simple:
For windows, check for .exe or .com, for *nix, check for 
executable flag.


Browsers already complain about these though, so people 
distributing malware probably does other things like putting them 
in compressed files. In that case, your file tool would have to 
open every .zip, .rar, .7z, .gz etc etc and check every file 
within recursively.


A bit OT regarding filetypes in the std lib though :)

epoll,kqueue support

2013-10-04 Thread darkofpain


Hi Friends,

D language epoll(linux/unix), kqueue(mac/freebsd) is there 
support for API


How can I use supports

Thank You

Re: ctrl+c and destructors


On 2013-10-04 09:40, Walter Bright wrote:


I think it's pretty clear that the solution to saving a user's
work-in-progress is to have the application actually save the
work-in-progress at regular intervals, not try to save it after it has
crashed.


Yes, but I don't know why it touched five of my save files. I can 
understand that it corrupted one, but not five.


--
/Jacob Carlborg

Re: std.d.lexer performance (WAS: std.d.lexer : voting thread)

2013-10-04 Thread Dejan Lekic

On Thursday, 3 October 2013 at 20:11:02 UTC, Andrei Alexandrescu
wrote:

On 10/3/13 12:47 PM, Brian Schott wrote:

On Thursday, 3 October 2013 at 19:07:03 UTC, nazriel wrote:

(Btw, someone got benchmarks of std.d.lexer?
I remember that Brain was benchmarking his module quite a lot
in order
to catch up with DMD's lexer but I can't find links in IRC
logs. I

wonder if he achieved his goal in this regard)

The most recent set of timings that I have can be found here:
https://raw.github.com/Hackerpilot/hackerpilot.github.com/master/experimental/std_lexer/images/times4.png

They're a bit old at this point, but not much has changed in
the lexer
internals. I can try running another set of benchmarks soon.
(The

hardest part is hacking DMD to just do the lexing)

The times on the X-axis are milliseconds.

I see we're considerably behind dmd. If improving performance
would come at the price of changing the API, it may be sensible
to hold off adoption for a bit.

Andrei

Quite frankly, I (or better say many of us) need a COMPLETE D
lexer that is UP TO DATE. std.lexer should be, if it is a Phobos
module, and that is all that matters. Performance optimizations
can come later.

So what if it's API will change? We, who use D2 since the very
beginning, are used to it! API changes can be done smoothly, with
phase-out stages. People would be informed what pieces of the API
will become deprecated, and it is their responsibility to fix
their code to reflect such changes. All that is needed is little
bit of planning...

Re: std.d.lexer : voting thread

2013-10-04 Thread Dejan Lekic

On Wednesday, 2 October 2013 at 18:41:32 UTC, Jacob Carlborg 
wrote:

On 2013-10-02 16:41, Dicebot wrote:
After brief discussion with Brian and gathering data from the 
review
thread, I have decided to start voting for `std.d.lexer` 
inclusion into

Phobos.


Yes.

Not a condition but I would prefer the default exception being 
thrown not to be Exception but a subclass.


Yes, I agree with Jacob.
Btw, you have a Yes, if vote here. :)

Re: std.d.lexer : voting thread

2013-10-04 Thread Dejan Lekic

Why was the Tok!=, Tok!default idea turned down. This 
leaves us with undesirable names like Tok.shiftRightAssign, 
Tok.default_.


Martin, that is truly a matter of taste. I, for an instance, do 
not like Tok!= - too many special characters there for my 
taste. To me it looks like some part of a weird Perl script.

Re: std.d.lexer : voting thread

2013-10-04 Thread ilya-stromberg


On Wednesday, 2 October 2013 at 14:41:56 UTC, Dicebot wrote:
After brief discussion with Brian and gathering data from the 
review thread, I have decided to start voting for `std.d.lexer` 
inclusion into Phobos.


No.

I really want to see `std.d.lexer` in Phobos, but have too many 
conditions.


Documentation issues:

- please specify the parser algorithm that you used for 
`std.d.lexer`. As I understand from review thread, you implement 
`GLR parser` - please document it (correct me if I wrong). Also, 
add link to the algorithm description, for example to the 
wikipedia:

http://en.wikipedia.org/wiki/GLR_parser
It helps to understand how `std.d.lexer` works.
Also, please add best-case and worst-case time complexity (for 
example, from O(n) to O(n^3)), and best-case and worst-case 
memory complexity.


- please add more usage examples. Currently you have only one big 
example how generate HTML markup of D code. Try to add a simple 
example for every function.


- explicitly specify functions that can throw: add `Throws:` 
block for it and specify conditions when they can throw.


UTF-16/UTF-32 support:
- why standart `std.d.lexer` supports only UTF-8, but not a 
UTF-16/UTF-32? The official lexing specification allows all of 
them. The conversion from UTF-16/UTF-32 to UTF-8 is not a option 
due performance issues.
If Phobos string functions too slow, please add a bug. If Phobos 
haven't got necessary functions, please add enhancement request.
I think it's serious issue that affects all string utilities 
(like std.xml or std.json), not only `std.d.lexer`.


Exception handling
- please use `ParseException` as a default exception, not the 
`Exception`.


Codestyle:
- I don't like `TokenType` enum. You can use Tok!= and 
`static if` to compare the token string to the `TokenType` enum. 
So, you will not lose performance, because string parsing will be 
done at compile time.


Not a condition, but wishlist:
- implement low-level API, not only high-level range-based API. I 
hope it can help increase performance for applications that 
really need it.


- add ability to use `std.d.lexer` at the compile time.

Official stdx

2013-10-04 Thread John Colvin

Adding new (or replacement) phobos modules without wider testing 
is not a scalable approach for D.
New modules go from unofficial to official in a single step and 
are therefore inadequately battle-tested before becoming part of 
the somewhat ossified environment of a standard library.


Assertions:

1) In the current situation, modules go from independent projects 
to becoming official parts of phobos at a single point. It's a 
binary switch.


2) New modules, in the form proposed for submission, are fully 
read through by a small number of people.


3) New modules, in the form proposed for submission, have often 
been seriously used by only an even smaller number of people.


4) Breaking changes to phobos are currently undesirable.


Argument:
Due to the combination of 1,2 and 3, we unwittingly introduce 
bugs and poor design decisions in to the standard library, with 
all the inflexibility that entails. Due to 4 we then either 
cannot or do not fix these problems in an optimal fashion, if at 
all. We can do better.



Necessary Solution:
People need to really use these new modules before they are 
pulled in to phobos. In particular, the API must be stress tested 
in a variety of situations.*



Implementation:
In the current situation all the code is public, so people are 
totally free to try out the proposed modules and test them. They 
don't and they won't.


I propose that the current review process be redirected to a new 
target package in the phobos repo, stdx, which would then have a 
separate review process for inclusion in std.


I would imagine a compulsory waiting period of the order of 
months, combined with a requirement of evidence that the module 
has been effective in the real world and that any outstanding 
problems have been resolved appropriately**. Stdx would make no 
explicit promises about API stability, but modules would be 
considered as semi-finished products; Revisions that effectively 
amount to a significant rewrite (in particular to the API) would 
require re-submission for initial review.


Stdx would occupy a space between phobos and unaffiliated 
packages, allowing for subtle (i.e. missed during initial review) 
but critical problems requiring breakage to be identified BEFORE 
inclusion in the standard library proper. I believe providing 
this official stepping stone for new modules will result in 
significantly wider usage and testing, benefiting phobos, D and 
it's community.



*API design is *hard*. Knowing what is a good decision ahead of 
time is a matter of experience.
** The appropriate action may be to not fix it. There are always 
trade-offs.


P.S.
I am aware that this is not a new idea at all. I thought it was 
worth presenting with a clean slate.

Re: C++ - D converter mentioned in AMA

2013-10-04 Thread Daniel Murphy

Szymon Gatner noem...@gmail.com wrote in message 
news:jqvduhyvfufpzovpy...@forum.dlang.org...
 Andrei's AMA has interesting answer:

 One of the main D(md) contributors, Daniel Murphy is working on automatic 
 conversion tool that eventually will convert DMD's C++ codebase to D.

 Is this tool already available? Are there any guidelines about how to code 
 in C++ to ease the conversion preocess (or even make it possible). I would 
 be VERY interested in such a tool when the time comes so in the mean time 
 I could slowly fix existing C++ codebase for future conversion.

The tool is available here: https://github.com/yebblies/magicport2

But as others have said, it is not meant to be a general purpose tool.  The 
same approach could easily be applied to another large and consistent 
project, but not without adapting the tool to your needs.

DMD uses a very nice subset of C++ (very few templates, no stl, no MI, etc) 
so most of the things I've needed to clean up were actually C-isms.

You can get a comprehensive list of changes by looking at past commits with 
[DDMD] in the title, along with the un-merged ones here: 
https://github.com/D-Programming-Language/dmd/pull/1980

Re: Official stdx

I liked the proposal to add special `dub` category for those 
(`dub` needs some categorization anyway). Only drawback is that 
it actually needs to be implemented instead of simply making a 
decision :)

Re: C++ - D converter mentioned in AMA

2013-10-04 Thread Daniel Murphy

Jacob Carlborg d...@me.com wrote in message 
news:l2lqik$1vdt$1...@digitalmars.com...
 On 2013-10-04 08:37, Szymon Gatner wrote:

 Well, that is nothing Clang can't handle. The subset is what I was
 asking for -  there has to be something that tool handles correctly, 
 right?

 Of course Clang will be able to lex and parse it. But how should it be 
 translated?

 void foo (int a
 #if BAR
 ,
 int b
 #endif
 )
 { ... }

 You cannot do the exact same thing in D:

 void foo (int a
 version (BAR)
 {
 ,
 int b
 }
 )
 { ... }

 Doing these crazy things are only possible with a preprocessor.

 Then you need to duplicate the function, use a string mixin or something 
 else that's ugly.

 We can take a simpler example:

 #if _WIN32
 void foo (int);
 #elif __APPLE__
 void foo (long long);
 #elif linux
 void foo (long long);
 #endif

 Translating this manually it would look like this:

 version (Windows)
 void foo (int);
 else version (OSX)
 void foo (long);
 else version (linux)
 void foo (long);

 But how could this be translated automatically? In this case you would 
 want to have all the above preprocessor macros enabled, at the same time. 
 Or somehow run it multiple times with different macros enabled and merge 
 them.

 I don't know how the preprocessor API looks like in Clang. If you could 
 search for hard coded identifiers or something similar.

 -- 
 /Jacob Carlborg

I deal with this by not running a preprocessor.  The #if directives are 
parsed as if they're real C++ constructs, and this means everything inside 
(and around) them must be valid C++ code.

With this constraint, translating them to static if/version and doing all 
versions simultaneously becomes possible.

Re: Official stdx


On 04/10/13 12:02, John Colvin wrote:

I propose that the current review process be redirected to a new target package
in the phobos repo, stdx, which would then have a separate review process for
inclusion in std.


As you say, this has been proposed before and I think the objection was along 
the lines that in practice, so many people would just use stdx (because they 
wanted those features NOW, NOW, NOW!) that you'd have the same backwards 
compatibility issues arising there -- you'd wind up with the same fear of 
breaking change and deprecation as we currently have in the standard library, 
and it would also cause breaking change if stdx.somemodule was approved and 
moved to std.somemodule.


I remember someone pointed to a similar experimental module namespace in Java, 
which effectively became a standard namespace in this way.



Stdx would occupy a space between phobos and unaffiliated packages, allowing for
subtle (i.e. missed during initial review) but critical problems requiring
breakage to be identified BEFORE inclusion in the standard library proper. I
believe providing this official stepping stone for new modules will result in
significantly wider usage and testing, benefiting phobos, D and it's community.


There is an alternative risk -- that people will be more inclined to just throw 
stuff over the wall into stdx because, hey, it's an experimental/testing area, 
the whole idea is for people to try out imperfect code and work out what's wrong 
with it ...


... but then people are kind of locked into that imperfect code, because even if 
it's imperfect it still provides something that no other library/module does, 
and they and their code suffer from the breaking changes all the same.



I am aware that this is not a new idea at all. I thought it was worth presenting
with a clean slate.


I've presented Devil's Advocate positions above, but of course it was worth 
re-raising the idea.  Anything that does in practice raise the bar of Phobos 
quality is very welcome.

Re: Official stdx

2013-10-04 Thread John Colvin

On Friday, 4 October 2013 at 10:30:56 UTC, Joseph Rushton 
Wakeling wrote:

On 04/10/13 12:02, John Colvin wrote:
I propose that the current review process be redirected to a 
new target package
in the phobos repo, stdx, which would then have a separate 
review process for

inclusion in std.


As you say, this has been proposed before and I think the 
objection was along the lines that in practice, so many people 
would just use stdx (because they wanted those features NOW, 
NOW, NOW!) that you'd have the same backwards compatibility 
issues arising there -- you'd wind up with the same fear of 
breaking change and deprecation as we currently have in the 
standard library


The lack of promise of API stability in stdx would have to be 
very explicit and obvious. The maintainers of phobos would have 
to remain stalwart in preventing any alteration of this, whether 
de facto or deliberate.


and it would also cause breaking change if stdx.somemodule was 
approved and moved to std.somemodule.


That is the least bad type of breaking change.

I remember someone pointed to a similar experimental module 
namespace in Java, which effectively became a standard 
namespace in this way.


Stdx would occupy a space between phobos and unaffiliated 
packages, allowing for
subtle (i.e. missed during initial review) but critical 
problems requiring
breakage to be identified BEFORE inclusion in the standard 
library proper. I
believe providing this official stepping stone for new modules 
will result in
significantly wider usage and testing, benefiting phobos, D 
and it's community.


There is an alternative risk -- that people will be more 
inclined to just throw stuff over the wall into stdx because, 
hey, it's an experimental/testing area, the whole idea is for 
people to try out imperfect code and work out what's wrong with 
it ...


The bar for passing initial review should remain exactly where it 
is now. Nothing should be allowed in to stdx unless it appears 
for all intents and purposes to be a finished, high quality 
module that would - to the best of the evidence available - be 
fine to add straight to phobos. The purpose of stdx is to gather 
more evidence before making the commitment.


I am aware that this is not a new idea at all. I thought it 
was worth presenting

with a clean slate.


I've presented Devil's Advocate positions above, but of course 
it was worth re-raising the idea.  Anything that does in 
practice raise the bar of Phobos quality is very welcome.

What endiannesses do D support?

2013-10-04 Thread Denis Shelomovskij

Some of druntime/phobos code assumes it is one of little/big endianness 
others have `static assert(0)` for third case. Lets clear the situation 
and make a decision.


--
Денис В. Шеломовский
Denis V. Shelomovskij

Re: Official stdx

On Friday, 4 October 2013 at 10:30:56 UTC, Joseph Rushton 
Wakeling wrote:
There is an alternative risk -- that people will be more 
inclined to just throw stuff over the wall into stdx because, 
hey, it's an experimental/testing area, the whole idea is for 
people to try out imperfect code and work out what's wrong with 
it ...


And to be 100% clear - I meant this dub category to be moderated 
and only filled after formal review process. We simply need some 
place for modules which got conceptually approved but can't yet 
meet API stability and/or implementation quality required for 
inclusion into Phobos as-is.

Re: Official stdx

2013-10-04 Thread Chris

The thing is, code is never perfect and as a language keeps 
evolving your latest tricks will soon become obsolete or 
deprecated. It happens all the time (Java, Cocoa etc. use this 
instead). If I look back at the code I wrote years ago, it still 
works, but it's no longer up to current standards (my own as well 
as the language's). I think including things in the std. library 
really makes people (like me) use and thereby _test_ them, asking 
(not so) stupid questions on D.learn etc. If I have learned 
anything it's that my most ignorant (innocent) questions trigger 
responses from people who are more experienced, pointing out this 
or that flaw, telling you tricks and workarounds. D is a language 
based on practical experience, not on ideology or anything 
(that's why I like it). So stdx, while it seems to be a good 
idea, would be a limbo for code, eternally in a state of not 
bad, but not quite there yet. And all code is like that. We'll 
never quite get there.

Re: What endiannesses do D support?

2013-10-04 Thread Alex Rønne Petersen

On Friday, 4 October 2013 at 10:59:05 UTC, Denis Shelomovskij 
wrote:
Some of druntime/phobos code assumes it is one of little/big 
endianness others have `static assert(0)` for third case. Lets 
clear the situation and make a decision.


Little endian and big endian must be supported. Little endian 
PowerPC, for example, is extremely rare (if not entirely 
extinct), so just supporting little endian is not enough.

Re: std.d.lexer performance (WAS: std.d.lexer : voting thread)

On Thursday, 3 October 2013 at 20:11:02 UTC, Andrei Alexandrescu 
wrote:
I see we're considerably behind dmd. If improving performance 
would come at the price of changing the API, it may be sensible 
to hold off adoption for a bit.


Andrei


The old benchmarks measured total program run time. I ran a new 
set of benchmarks, placing stopwatch calls around just the lexing 
code to bypass any slowness caused by druntime startup. I also 
made a similar modification to DMD.


Here's the result:

https://raw.github.com/Hackerpilot/hackerpilot.github.com/master/experimental/std_lexer/images/times5.png

I suspect that I've made an error in the benchmarking due to how 
much faster std.d.lexer is than DMD now, so I've uploaded what I 
have to Github.


https://github.com/Hackerpilot/lexerbenchmark

Re: C++ - D converter mentioned in AMA


On 2013-10-04 12:21, Daniel Murphy wrote:


I deal with this by not running a preprocessor.  The #if directives are
parsed as if they're real C++ constructs, and this means everything inside
(and around) them must be valid C++ code.

With this constraint, translating them to static if/version and doing all
versions simultaneously becomes possible.


Then you need to A) build your own preprocessor or B) limiting yourself 
to non-generic code, as you have done in this case. This was my original 
point, having it work on generic code.


--
/Jacob Carlborg

Re: What endiannesses do D support?

2013-10-04 Thread Denis Shelomovskij


04.10.2013 15:00, Alex Rønne Petersen пишет:

On Friday, 4 October 2013 at 10:59:05 UTC, Denis Shelomovskij wrote:

Some of druntime/phobos code assumes it is one of little/big
endianness others have `static assert(0)` for third case. Lets clear
the situation and make a decision.


Little endian and big endian must be supported. Little endian PowerPC,
for example, is extremely rare (if not entirely extinct), so just
supporting little endian is not enough.


Of course. The question is about a third case.

--
Денис В. Шеломовский
Denis V. Shelomovskij

Re: Official stdx


On 2013-10-04 12:17, Dicebot wrote:

I liked the proposal to add special `dub` category for those (`dub`
needs some categorization anyway). Only drawback is that it actually
needs to be implemented instead of simply making a decision :)


For that, dub needs to be bundled with DMD.

--
/Jacob Carlborg

Re: Can we please kill the hyphenator already?

2013-10-04 Thread Andrej Mitrovic

On 10/2/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
 On 10/1/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
 Fixed - I just pushed the fixed druntime docs.

 It's also apparently loading hyphenator here:
 http://dlang.org/changelog.html

And in http://dlang.org/ddoc.html

Can we get rid of it? I don't know how it's injected into the website,
otherwise I'd make a pull request myself.

Re: std.d.lexer performance (WAS: std.d.lexer : voting thread)


On 2013-10-04 13:28, Brian Schott wrote:


Here's the result:

https://raw.github.com/Hackerpilot/hackerpilot.github.com/master/experimental/std_lexer/images/times5.png


I suspect that I've made an error in the benchmarking due to how much
faster std.d.lexer is than DMD now, so I've uploaded what I have to Github.

https://github.com/Hackerpilot/lexerbenchmark


If these results are correct, me like :)

--
/Jacob Carlborg

Re: std.d.lexer performance (WAS: std.d.lexer : voting thread)

2013-10-04 Thread Piotr Szturmaj


Brian Schott wrote:

On Thursday, 3 October 2013 at 20:11:02 UTC, Andrei Alexandrescu wrote:

I see we're considerably behind dmd. If improving performance would
come at the price of changing the API, it may be sensible to hold off
adoption for a bit.

Andrei


The old benchmarks measured total program run time. I ran a new set of
benchmarks, placing stopwatch calls around just the lexing code to
bypass any slowness caused by druntime startup. I also made a similar
modification to DMD.

Here's the result:

https://raw.github.com/Hackerpilot/hackerpilot.github.com/master/experimental/std_lexer/images/times5.png


I suspect that I've made an error in the benchmarking due to how much
faster std.d.lexer is than DMD now, so I've uploaded what I have to Github.

https://github.com/Hackerpilot/lexerbenchmark


Interestingly, DMD is only faster when lexing std.datetime. This is 
relatively big file, so maybe the slowness is related to small buffering 
in std.d.lexer?

Re: Official stdx


On Friday, 4 October 2013 at 13:30:39 UTC, Jacob Carlborg wrote:

On 2013-10-04 12:17, Dicebot wrote:
I liked the proposal to add special `dub` category for those 
(`dub`
needs some categorization anyway). Only drawback is that it 
actually

needs to be implemented instead of simply making a decision :)


For that, dub needs to be bundled with DMD.


I think it will at some moment. Adding such categorization 
capabilities is just another step towards official endorsement.

Re: std.rational -- update and progress towards review


On 03/10/13 16:38, Dicebot wrote:

On Thursday, 3 October 2013 at 12:16:51 UTC, Joseph Rushton Wakeling wrote:

It's not about your opinions of the code per se, so much as about your
experience of what is likely to provide a smooth review process ...


Experience? :D I have not yet finished a single complete review process.


You've managed a few, no? :-P

Anyway, here's the state of play: I have two distinct branches that both 
implement std.rational as a new module in Phobos.


https://github.com/WebDrake/phobos/tree/rational implements things as I think 
they should be, with several generic functions/templates parcelled out to 
std.traits and std.numeric.


https://github.com/WebDrake/phobos/tree/rational-standalone implements things as 
a standalone module with all non-essential functions (or local duplications) 
marked as private.


I would be happy for either or preferably both side-by-side to be subject to 
review now.  I think both are at the point where my asking on the forums is not 
going to get this code the scrutiny it needs.  That said, my concern is that 
there will be some significant changes requested and it may be knocked back this 
time -- which is why I've tried asking questions on the forums in the first place.


So really, as review manager, it's your call.  If you'd like me to keep 
following up on my concerns and delay submission, I'll do that, but if you're 
happy to move forward, let's do it. :-)


Thanks  best wishes,

-- Joe

Re: std.d.lexer : voting thread


On Friday, 4 October 2013 at 09:41:49 UTC, ilya-stromberg wrote:

On Wednesday, 2 October 2013 at 14:41:56 UTC, Dicebot wrote:
After brief discussion with Brian and gathering data from the 
review thread, I have decided to start voting for 
`std.d.lexer` inclusion into Phobos.


No.

I really want to see `std.d.lexer` in Phobos, but have too many 
conditions.


Documentation issues:


clip


- please add more usage examples. Currently you have only one 
big example how generate HTML markup of D code. Try to add a 
simple example for every function.



clip

Woah! A simple example for every function? Then it would put 
the rest of the Phobos documents to shame :o)

Re: epoll,kqueue support

2013-10-04 Thread Adam D. Ruppe


You can call the functions with extern(C).

There's also bindings to libraries that handle both, but I've 
never used them:

http://code.dlang.org/packages/libev


Here's how to do epoll without a library:

// calling epoll directly

version(linux) {
extern(C):

alias int c_int;

alias uint uint32_t;
alias ulong uint64_t;

union epoll_data {
void*ptr;
int  fd;
uint32_t u32;
uint64_t u64;
}

struct epoll_event {
uint32_t   events;/* Epoll events */
epoll_data data;  /* User data variable */
}

enum EPOLL_CTL_ADD = 1;
enum EPOLL_CTL_DEL = 2;
enum EPOLL_CTL_MOD = 3;


import std.conv : octal;
enum {
EPOLL_CLOEXEC = octal!200,
EPOLL_NONBLOCK = octal!4000
}

enum EPOLL_EVENTS {
EPOLLIN = 0x001,
EPOLLPRI = 0x002,
EPOLLOUT = 0x004,
EPOLLRDNORM = 0x040,
EPOLLRDBAND = 0x080,
EPOLLWRNORM = 0x100,
EPOLLWRBAND = 0x200,
EPOLLMSG = 0x400,
EPOLLERR = 0x008,
EPOLLHUP = 0x010,
EPOLLRDHUP = 0x2000,
EPOLLONESHOT = (1  30),
EPOLLET = (1  31)
}

int epoll_create1(int flags);
int epoll_ctl(int epfd, int op, int fd, epoll_event* event);
	int epoll_wait(int epfd, epoll_event* events, int maxevents, int 
timeout);


import core.sys.posix.sys.time;
}



Then you use epoll_create(), etc., just like you would in C. 
kqueue would be similar, though I've never done that in D.

Re: epoll,kqueue support

2013-10-04 Thread S


On 2013-10-04 14:30:39 +, Adam D. Ruppe said:


You can call the functions with extern(C).

There's also bindings to libraries that handle both, but I've never used them:
http://code.dlang.org/packages/libev


+1 on this.  Use libev, or libevent2.  There are bindings around for 
them.  (I know vibe-d is using them)

Re: John Carmack on Eclipse performance

2013-10-04 Thread Bruno Medeiros


On 27/09/2013 23:10, Nick Sabalausky wrote:

On Fri, 27 Sep 2013 12:35:29 +0100
Bruno Medeiros brunodomedeiros+...@gmail.com wrote:


Hardware does get faster more rapidly than software gets slower --



Well, when you're in an industry that's constantly upgrading to the
latest top-of-the-line hardware, perhaps; for everyone else, certainly
not.



New hardware is cheap, for a developer's salary. But even so desktop 
specs haven't even improved much in the last 3 years or so (apart from 
GPUs). My desktop is 4 years old and I don't think I would tell a 
difference in performance if I upgraded it (again, apart from the GPU).



--
Bruno Medeiros - Software Engineer

Re: std.d.lexer : voting thread

2013-10-04 Thread ilya-stromberg


On Friday, 4 October 2013 at 14:30:12 UTC, Craig Dillabaugh wrote:

On Friday, 4 October 2013 at 09:41:49 UTC, ilya-stromberg wrote:

On Wednesday, 2 October 2013 at 14:41:56 UTC, Dicebot wrote:
After brief discussion with Brian and gathering data from the 
review thread, I have decided to start voting for 
`std.d.lexer` inclusion into Phobos.


No.

I really want to see `std.d.lexer` in Phobos, but have too 
many conditions.


Documentation issues:


clip


- please add more usage examples. Currently you have only one 
big example how generate HTML markup of D code. Try to add a 
simple example for every function.



clip

Woah! A simple example for every function? Then it would 
put the rest of the Phobos documents to shame :o)


I said: TRY to add. But yes, I feel that `std.d.lexer` don't 
have enough documentation.

Re: Can we please kill the hyphenator already?

2013-10-04 Thread Andrei Alexandrescu


On 10/4/13 6:38 AM, Andrej Mitrovic wrote:

On 10/2/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:

On 10/1/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:

Fixed - I just pushed the fixed druntime docs.


It's also apparently loading hyphenator here:
http://dlang.org/changelog.html


And in http://dlang.org/ddoc.html

Can we get rid of it? I don't know how it's injected into the website,
otherwise I'd make a pull request myself.


Removed the js files from the site, uploaded fresh dox.

Andrei

Re: std.d.lexer : voting thread

2013-10-04 Thread H. S. Teoh

On Fri, Oct 04, 2013 at 04:30:11PM +0200, Craig Dillabaugh wrote:
 On Friday, 4 October 2013 at 09:41:49 UTC, ilya-stromberg wrote:
[...]
 - please add more usage examples. Currently you have only one big
 example how generate HTML markup of D code. Try to add a simple
 example for every function.
 
 clip
 
 Woah! A simple example for every function? Then it would put the
 rest of the Phobos documents to shame :o)

The rest of Phobos docs *should* be put to shame. Except maybe for a few
exceptions here and there, most of Phobos docs are far too scant, and
need some serious TLC with many many more code examples.


T

-- 
Customer support: the art of getting your clients to pay for your own 
incompetence.

Re: std.d.lexer : voting thread

2013-10-04 Thread Andrei Alexandrescu


On 10/4/13 7:30 AM, Craig Dillabaugh wrote:

On Friday, 4 October 2013 at 09:41:49 UTC, ilya-stromberg wrote:

On Wednesday, 2 October 2013 at 14:41:56 UTC, Dicebot wrote:

After brief discussion with Brian and gathering data from the review
thread, I have decided to start voting for `std.d.lexer` inclusion
into Phobos.


No.

I really want to see `std.d.lexer` in Phobos, but have too many
conditions.

Documentation issues:


clip


- please add more usage examples. Currently you have only one big
example how generate HTML markup of D code. Try to add a simple
example for every function.


clip

Woah! A simple example for every function? Then it would put the
rest of the Phobos documents to shame :o)


I would say matters that are passable for now and easy to improve later 
without disruption don't necessarily preclude approval.


Andrei

Re: dub: should we make it the de jure package manager for D?

2013-10-04 Thread Bruno Medeiros


On 27/09/2013 12:53, Jacob Carlborg wrote:

On 2013-09-27 13:22, Bruno Medeiros wrote:


It compiles packages when used as dependencies in another package, and
run with the dub build command.

What perhaps you meant to say is that dub doesn't compile application
packages that it downloads from the registry. That might be true. Even
so, if you do dub install of one such package, then navigate to the
directory where it was installed, and do dub build, it should compile
the executable. I haven't tried that myself though.


Yes, it does. But that's where I draw the line with the dub install
command actually installs or not. So since it doesn't build the package
I wouldn't considered the package installed, which is what I expect from
a command named install. But what you already have said cache sounds
like a better name for what it currently does.



mirror would also be a good name for what it currently does. But 
personally I'm not that bothered about install.


--
Bruno Medeiros - Software Engineer

Re: std.d.lexer : voting thread


On Friday, 4 October 2013 at 16:03:25 UTC, ilya-stromberg wrote:
On Friday, 4 October 2013 at 14:30:12 UTC, Craig Dillabaugh 
wrote:
On Friday, 4 October 2013 at 09:41:49 UTC, ilya-stromberg 
wrote:

On Wednesday, 2 October 2013 at 14:41:56 UTC, Dicebot wrote:
After brief discussion with Brian and gathering data from 
the review thread, I have decided to start voting for 
`std.d.lexer` inclusion into Phobos.


No.

I really want to see `std.d.lexer` in Phobos, but have too 
many conditions.


Documentation issues:


clip


- please add more usage examples. Currently you have only one 
big example how generate HTML markup of D code. Try to add a 
simple example for every function.



clip

Woah! A simple example for every function? Then it would 
put the rest of the Phobos documents to shame :o)


I said: TRY to add. But yes, I feel that `std.d.lexer` don't 
have enough documentation.


I think it was a good idea ... it just sort of jumped out at me 
as the Phobos documentation tends to be missing lots of examples. 
 Thus the smiley on the end.

Re: std.d.lexer : voting thread

2013-10-04 Thread Robert

I created https://github.com/phobos-x/phobosx for this, it is also in
the dub registry. 

It could be used, until something more official is established.

Best regards,

Robert

On Fri, 2013-10-04 at 05:29 +0200, David Nadlinger wrote:
 On Friday, 4 October 2013 at 02:57:41 UTC, Martin Nowak wrote:
  Adding it as experimental module would be a good idea.
 
 I would be in favor of adding such community-reviewed but 
 not-quite-there-yet libraries to a special category on the DUB 
 registry instead.
 
 It would also solve the visibility problem, and apart from the 
 fact that it isn't really clear what being an »experimental« 
 module would entail, having it as a package also allows for 
 faster updates not reliant on the core release schedule.
 
 David

std.d.lexer - discussion (not the voting thread)


When running:

   dmd std/d/lexer -cov -main -unittest

what is the percent coverage?

Re: std.d.lexer - discussion (not the voting thread)


On Friday, 4 October 2013 at 18:03:46 UTC, Walter Bright wrote:

When running:

   dmd std/d/lexer -cov -main -unittest

what is the percent coverage?


lexer.d is 86% covered

Re: std.d.lexer - discussion (not the voting thread)


On 2013-10-04 20:10, Brian Schott wrote:


lexer.d is 86% covered


Do we have a minimum coverage level?

--
/Jacob Carlborg

Re: std.d.lexer - discussion (not the voting thread)


On Friday, 4 October 2013 at 18:32:59 UTC, Jacob Carlborg wrote:

Do we have a minimum coverage level?


If we do, nobody has written it down.

Re: Can we please kill the hyphenator already?

2013-10-04 Thread Andrej Mitrovic

On 10/4/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
 Removed the js files from the site, uploaded fresh dox.

Thanks.

It's a shame you don't work for Google so you can give them a slap on
the wrist for not implementing this feature in the browser. :)

Re: std.d.lexer - discussion (not the voting thread)


On 10/4/2013 11:32 AM, Jacob Carlborg wrote:

On 2013-10-04 20:10, Brian Schott wrote:


lexer.d is 86% covered


Do we have a minimum coverage level?


No, but any low hanging fruit uncovered lines need to get test cases added, 
i.e. there needs to be some sort of justification for lines not covered.


In general, I'd say we need to be shooting for = 95%.

If you look at phobos' win32.mak, which lists coverage percentages for the 
various phobos modules, a lot of phobos modules are very inadequately covered.

Re: std.rational -- update and progress towards review


On 10/2/2013 7:25 AM, Joseph Rushton Wakeling wrote:

Anyway, I'd really value your feedback at this point.


To add to your burdens :-) please also run a -cov -unittest -main, and determine 
the unittest coverage. Please shoot for = 95% coverage. 100% is even better!

Re: std.rational -- update and progress towards review

2013-10-04 Thread Brad Roberts

On 10/4/13 7:16 AM, Joseph Rushton Wakeling wrote:

On 03/10/13 16:38, Dicebot wrote:

On Thursday, 3 October 2013 at 12:16:51 UTC, Joseph Rushton Wakeling wrote:

It's not about your opinions of the code per se, so much as about your
experience of what is likely to provide a smooth review process ...

Experience? :D I have not yet finished a single complete review process.

You've managed a few, no? :-P

Anyway, here's the state of play: I have two distinct branches that both
implement std.rational as a
new module in Phobos.

https://github.com/WebDrake/phobos/tree/rational implements things as I think
they should be, with
several generic functions/templates parcelled out to std.traits and std.numeric.

https://github.com/WebDrake/phobos/tree/rational-standalone implements things
as a standalone module
with all non-essential functions (or local duplications) marked as private.

I would be happy for either or preferably both side-by-side to be subject to
review now. I think
both are at the point where my asking on the forums is not going to get this
code the scrutiny it
needs. That said, my concern is that there will be some significant changes
requested and it may be
knocked back this time -- which is why I've tried asking questions on the
forums in the first place.

So really, as review manager, it's your call. If you'd like me to keep
following up on my concerns
and delay submission, I'll do that, but if you're happy to move forward, let's
do it. :-)

Thanks best wishes,

-- Joe

Ideally, the unrelated but required non-rational code would be delt with before the review, then the
issue is moot. If you've got important or useful changes to other parts of phobos, separate them
and get them delt with.

Re: John Carmack on Eclipse performance

2013-10-04 Thread Nick Sabalausky

On Fri, 04 Oct 2013 16:36:12 +0100
Bruno Medeiros brunodomedeiros+...@gmail.com wrote:

 On 27/09/2013 23:10, Nick Sabalausky wrote:
  On Fri, 27 Sep 2013 12:35:29 +0100
  Bruno Medeiros brunodomedeiros+...@gmail.com wrote:
 
  Hardware does get faster more rapidly than software gets slower --
 
 
  Well, when you're in an industry that's constantly upgrading to the
  latest top-of-the-line hardware, perhaps; for everyone else,
  certainly not.
 
 
 New hardware is cheap, for a developer's salary.

But not always necessary, depending on the exact field and industry.

 But even so desktop 
 specs haven't even improved much in the last 3 years or so (apart
 from GPUs). My desktop is 4 years old and I don't think I would tell
 a difference in performance if I upgraded it (again, apart from the
 GPU).
 

Yea, exactly.

I'm amazed that even low-end budget machines are so
ridiculously powerful these days. Pretty damn cool.

Re: std.rational -- update and progress towards review


On Friday, 4 October 2013 at 18:56:35 UTC, Walter Bright wrote:

On 10/2/2013 7:25 AM, Joseph Rushton Wakeling wrote:

Anyway, I'd really value your feedback at this point.


To add to your burdens :-) please also run a -cov -unittest 
-main, and determine the unittest coverage. Please shoot for = 
95% coverage. 100% is even better!


It is 95% -- I can always see if I can improve that :-)

Re: std.rational -- update and progress towards review


On 10/4/2013 12:31 PM, Joseph Rushton Wakeling wrote:

It is 95% -- I can always see if I can improve that :-)


attachment: excellent.jpg

A question for Mr Bright

2013-10-04 Thread ProgrammingGhost

Walter Bright: Did you have a beard during anytime of the the 
design or development of D? and if not do you regret it?


Context: http://c2.com/cgi/wiki?LanguageAuthorBeardPattern

Re: A question for Mr Bright

2013-10-04 Thread sclytrack


On Friday, 4 October 2013 at 20:23:22 UTC, ProgrammingGhost wrote:
Walter Bright: Did you have a beard during anytime of the the 
design or development of D? and if not do you regret it?


Context: http://c2.com/cgi/wiki?LanguageAuthorBeardPattern


If he hasn't had a beard. He should better start growing one. :-)

Re: std.rational -- update and progress towards review


On 04/10/13 21:00, Brad Roberts wrote:

Ideally, the unrelated but required non-rational code would be delt with before
the review, then the issue is moot.  If you've got important or useful changes
to other parts of phobos, separate them and get them delt with.


I don't mind doing that, but it seemed to me that _all_ of this code deserved 
the level of scrutiny that a formal review would bring, both generic and 
specialized parts.

Re: A question for Mr Bright


On 10/4/2013 1:23 PM, ProgrammingGhost wrote:

Walter Bright: Did you have a beard during anytime of the the design or
development of D? and if not do you regret it?


No. I had a beard in my early 20's, and it never stopped itching. I don't want 
one again.


Besides, I work with power tools and have no interest in having my face pulled 
into the drill press because my beard got snagged on it.

Re: A question for Mr Bright


On Friday, 4 October 2013 at 20:29:37 UTC, sclytrack wrote:
On Friday, 4 October 2013 at 20:23:22 UTC, ProgrammingGhost 
wrote:
Walter Bright: Did you have a beard during anytime of the the 
design or development of D? and if not do you regret it?


Context: http://c2.com/cgi/wiki?LanguageAuthorBeardPattern


If he hasn't had a beard. He should better start growing one. 
:-)


But the list of counterexamples is nearly as long as the Examples 
list.
I think the beard/programming language success correlation is not 
statistically significant!

Re: A question for Mr Bright

2013-10-04 Thread ProgrammingGhost


On Friday, 4 October 2013 at 20:54:07 UTC, Walter Bright wrote:

On 10/4/2013 1:23 PM, ProgrammingGhost wrote:
Walter Bright: Did you have a beard during anytime of the the 
design or

development of D? and if not do you regret it?


No. I had a beard in my early 20's, and it never stopped 
itching. I don't want one again.


Besides, I work with power tools and have no interest in having 
my face pulled into the drill press because my beard got 
snagged on it.


Language Combo Breaker

Re: std.rational -- update and progress towards review


On 04/10/13 21:43, Walter Bright wrote:

On 10/4/2013 12:31 PM, Joseph Rushton Wakeling wrote:

It is 95% -- I can always see if I can improve that :-)


It's now 98% :-)

It'd be 99% if these two expressions were each placed on one line instead of 
wrapped, but I figure that would be greedy:

https://github.com/WebDrake/phobos/blob/rational/std/rational.d#L827-L830

Apart from that there's one line that is not an assert(0) that is not covered, 
which I guess just comes down to it being very rare that it should be activated:

https://github.com/WebDrake/phobos/blob/rational/std/rational.d#L593

Re: std.rational -- update and progress towards review

On Friday, 4 October 2013 at 21:09:26 UTC, Joseph Rushton 
Wakeling wrote:

It's now 98% :-)


That's not fair! You're not triggering any bugs in the coverage 
analyzer. :-)

Re: std.rational -- update and progress towards review


On 10/4/2013 2:09 PM, Joseph Rushton Wakeling wrote:

On 04/10/13 21:43, Walter Bright wrote:

On 10/4/2013 12:31 PM, Joseph Rushton Wakeling wrote:

It is 95% -- I can always see if I can improve that :-)


It's now 98% :-)

It'd be 99% if these two expressions were each placed on one line instead of
wrapped, but I figure that would be greedy:
https://github.com/WebDrake/phobos/blob/rational/std/rational.d#L827-L830

Apart from that there's one line that is not an assert(0) that is not covered,
which I guess just comes down to it being very rare that it should be activated:
https://github.com/WebDrake/phobos/blob/rational/std/rational.d#L593


Methinks you can get the 100% gold!

Re: What endiannesses do D support?

2013-10-04 Thread Stewart Gordon


On 04/10/2013 11:59, Denis Shelomovskij wrote:

Some of druntime/phobos code assumes it is one of little/big endianness others 
have
`static assert(0)` for third case. Lets clear the situation and make a decision.


Are you thinking of middle-endian orders such as 2,3,0,1?  Or just wondering in what 
situations neither BigEndian nor LittleEndian would be set?


I suppose that most, if not all, 32+-bit machines are either big-endian or little-endian. 
 But still, I imagine that the third-case is just a safeguard in case it is missed when 
somebody comes across a middle-endian platform and tries to compile that code on it.  Or 
maybe it was just put in out of belief that it is a good programming practice.


Endianness support as far as the D language is concerned doesn't seem to be 
clear-cut.
http://dlang.org/version.html
lists LittleEndian and BigEndian, but doesn't state that one of these will always be set. 
 So middle-endian machines, if a D compiler exists for them, would use this third case. 
 Further work would be needed to determine what particular middle-endian order the 
machine implements for each size of integer.  (Floating points are even more complicated, 
so I guess you can't rely on any version flag to tell you about the format of these.)


OTOH, the platforms on which DMD runs are big-endian or little-endian.  If DMD is ported 
to a middle-endian platform, or the DMD Phobos/druntime code is cribbed for use with a 
third-party D compiler for a middle-endian machine, then the static assert will fire, 
thereby drawing attention to this unimplemented functionality rather than silently 
generating code that won't work because it's written for a little-endian machine, or for a 
big-endian machine.


Stewart.

--
My email address is valid but not my primary mailbox and not checked regularly.  Please 
keep replies on the 'group where everybody may benefit.

Re: ctrl+c and destructors


On 10/4/2013 1:50 AM, Jacob Carlborg wrote:

On 2013-10-04 09:40, Walter Bright wrote:


I think it's pretty clear that the solution to saving a user's
work-in-progress is to have the application actually save the
work-in-progress at regular intervals, not try to save it after it has
crashed.


Yes, but I don't know why it touched five of my save files. I can understand
that it corrupted one, but not five.


Because its internal logic and code got scrambled, it can exhibit any behavior. 
That's the point.

Re: What endiannesses do D support?

2013-10-04 Thread Brad Roberts


On 10/4/13 3:26 PM, Stewart Gordon wrote:

On 04/10/2013 11:59, Denis Shelomovskij wrote:

Some of druntime/phobos code assumes it is one of little/big endianness others 
have
`static assert(0)` for third case. Lets clear the situation and make a decision.


Are you thinking of middle-endian orders such as 2,3,0,1?  Or just wondering in 
what situations
neither BigEndian nor LittleEndian would be set?

I suppose that most, if not all, 32+-bit machines are either big-endian or 
little-endian.  But
still, I imagine that the third-case is just a safeguard in case it is missed 
when somebody comes
across a middle-endian platform and tries to compile that code on it.  Or maybe 
it was just put in
out of belief that it is a good programming practice.

Endianness support as far as the D language is concerned doesn't seem to be 
clear-cut.
http://dlang.org/version.html
lists LittleEndian and BigEndian, but doesn't state that one of these will 
always be set.  So
middle-endian machines, if a D compiler exists for them, would use this third 
case.  Further work
would be needed to determine what particular middle-endian order the machine 
implements for each
size of integer.  (Floating points are even more complicated, so I guess you 
can't rely on any
version flag to tell you about the format of these.)

OTOH, the platforms on which DMD runs are big-endian or little-endian.  If DMD 
is ported to a
middle-endian platform, or the DMD Phobos/druntime code is cribbed for use with 
a third-party D
compiler for a middle-endian machine, then the static assert will fire, thereby 
drawing attention to
this unimplemented functionality rather than silently generating code that 
won't work because it's
written for a little-endian machine, or for a big-endian machine.

Stewart.



Good answer.  I'll add only one point:  The use of the else static assert is a good way to catch a 
new platform that's one of little or big but fails to specify.  If the code instead did if (little) 
{...} else {...}, the wrong choice would be potentially made.  Better to require explicitness.

Re: std.rational -- update and progress towards review

2013-10-04 Thread Brad Roberts


On 10/4/13 1:39 PM, Joseph Rushton Wakeling wrote:

On 04/10/13 21:00, Brad Roberts wrote:

Ideally, the unrelated but required non-rational code would be delt with before
the review, then the issue is moot.  If you've got important or useful changes
to other parts of phobos, separate them and get them delt with.


I don't mind doing that, but it seemed to me that _all_ of this code deserved 
the level of scrutiny
that a formal review would bring, both generic and specialized parts.


That's not an argument against splitting the changes up and getting the dependencies handled first. 
 It's an argument to do a good job with both sets of changes, which I agree with.

Re: std.rational -- update and progress towards review

2013-10-04 Thread Jesse Phillips

On Wednesday, 2 October 2013 at 14:26:04 UTC, Joseph Rushton 
Wakeling wrote:

Hello all,

I thought I'd ask for some guidance here, since this is the 
first time I'm involved in bringing a new Phobos module to 
review.


You've gotten some general input, I'll provide mine.

If I understand right, review means that I present a pull 
request to Phobos, rather than just a standalone piece of code 
as currently available.  The question is how to handle various 
bits of std.rational that arguably could or maybe should be 
implemented elsewhere in Phobos.  Is there a preference to 
present the module as-is, and have the review process decide 
what goes where, or is it better to present the pull request 
including patches against other modules?


People want to be able to review how the code will fit into 
Phobos, having the source incorporated in a branch of Phobos is 
the best way (and makes it easier to generate docs which resemble 
Phobos). A pull request should not be created.



   * Because it doesn't just want to work with built-in integer 
types, David
 Simcha was forced to define custom versions of various 
functionality
 found elsewhere in Phobos (or in some cases, perhaps at 
the time the
 functionality simply was not there).  Some of these have 
been deleted
 in my recent updates as they are no longer necessary: e.g. 
today it is
 fine to use std.math.abs, std.traits.isAssignable.  Others 
remain, and

 the question is how to handle these cases.


If the custom changes can be made to work with the existing 
functions, it can replace those existing functions. E.g. 
std.math.gcd can be updated to accept Rational as long as it 
continues to work on all types.


   * David defines an isRational template, which is currently 
very simple
 (it just checks that the type has numerator and 
denominator properties).
 This presumably is fine to keep in std.rational and should 
not be moved

 elsewhere.


Yes, leave the trait check inside the rational library. We don't 
have an integer... library so std.traits contains a number of 
traits for built in types.


   * Because std.rational doesn't just want to work with 
built-in integer types
 it can't rely on the existing isIntegral.  Instead, David 
defined a new
 template, isIntegerLike, which checks the operations 
supported by the
 type and whether they work in an integer-like way.  
Could/should this be
 placed in std.traits?  Better to do this in the initial 
pull or let the

 decision be part of the review process?


Add to std.traits for below.

   * For similar reasons, CommonType is insufficient and David 
defined two
 new templates, CommonInteger (which works out an 
appropriate common
 type for two integer-like types) and CommonRational.  
The former at
 least looks to me like it should be in std.traits.  Again, 
better to
 do this in the initial pull request, or make it a decision 
to take at

 review time?


Keep private for now.

   * Several Rational-based overrides for std.math functions 
are defined:
 floor, ceil and round.  I believe it's normal for such 
type-specific

 overrides to be in the same module as their type?


Yes, if it is just an override leave it here.

   * Finally, there are two mathematical functions, gcf 
(greatest common factor)
 and lcm (least common multiple) which again are locally 
defined because
 Phobos' existing std.math.gcd cannot handle BigInts (let 
alone any other
 user-defined integer type).  These should presumably be 
sent over to
 std.math but that relies on isIntegerLike being accepted 
for std.traits,

 or else some alternative type check being in place.


Fix std.math to work with the new type.

You'll want to get the public interface as polished as possible. 
Another solution would be to remove gcf/lcm from public API, if 
missing those would hold back inclusion then people will tell 
you. Once the module has been accepted then pull requests can be 
done to fix gcd and add lcm and it will not need formal review.

Re: std.rational -- update and progress towards review


On 04/10/13 23:40, Walter Bright wrote:

Methinks you can get the 100% gold!


I don't think any code containing an assert(0) should be able to get 100%, 
unless it's broken and that assert is actually getting triggered, no?  Well, 
unless you want to revise the coverage analyser to ignore assert(0) and 
assert(false) statements. ;-)


The interesting thing is the lines I highlighted, how those enforce statements 
broken across 2 lines actually come out as one covered line and one not:


enforce(someCondition,   // gets evaluated/covered
This message never gets used so the line is not covered.);

But there is the one single return statement that never gets used.  I'll have to 
work out exactly what triggers it and make sure there's a unittest for that.

Re: John Carmack on Eclipse performance


On 01/10/13 14:14, Dicebot wrote:

On Tuesday, 1 October 2013 at 12:02:29 UTC, w0rp wrote:

I'm waiting for Carmack to adopt D already. Barring some implementation
details (GC issues, shared libraries, bla bla) it's pretty much the perfect
language for what he wants to do. (Fast and functional in parts.) Plus, if
anyone could work around issues or figure out how to do really cool things
with D, it would be Carmack.


He is familiar with D and has shown appreciation for D `pure` functions in his
twitter posts.


One thing that I noted in his QuakeCon talk was his remarks about multiparadigm 
languages versus strictly functional languages, and how the former while they 
seem superior have the problem that, because you _can_ break the paradigm, you _do_.


I rather suspected he might have had D partially in mind with that remark, 
although he was gracious enough to not single out any languages.


That said, although I don't feel experienced enough in functional programming to 
comment with any authority, my impression is that D lets you be as strictly 
functional as you want to be, and has enough to let software architects impose 
strict purity etc. on a codebase.  But it is arguably less nice to have to keep 
marking pure const nothrow ... everywhere, plus const/immutable parameters, 
compared to something like Haskell where everything is that way by default.


I don't suppose it's possible to do that either by scope or even by module?

module my.module const nothrow pure @safe

or

const nothrow pure @safe
{
// my code here ...
}

Re: std.rational -- update and progress towards review


On 04/10/13 23:12, Brian Schott wrote:

On Friday, 4 October 2013 at 21:09:26 UTC, Joseph Rushton Wakeling wrote:

It's now 98% :-)


That's not fair! You're not triggering any bugs in the coverage analyzer. :-)


Well, unless you count the fact that an assert statement split across 2 lines 
registers as one line covered and one line not, because the error message 
doesn't get printed, which happens because the code works correctly ... :-)


It's got me ever so slightly miffed that if only I was prepared to have an 
uncivilly long line in the code, I'd be on 99% instead.

Re: std.rational -- update and progress towards review


On 05/10/13 00:40, Brad Roberts wrote:

That's not an argument against splitting the changes up and getting the
dependencies handled first.  It's an argument to do a good job with both sets of
changes, which I agree with.


Understood, but given that currently the supposedly independent changes are 
_only_ used by std.rational, there is a case for presenting everything in 
context together, because people may have alternative suggestions for how to 
handle these cases which don't rely on new templates.


Yes, I am trying to avoid a situation where I get caught up in weeks of pull 
request feedback before I can even think about submitting std.rational for 
review, but it's not _all_ about saving me time. :-)

Re: John Carmack on Eclipse performance

2013-10-04 Thread deadalnix

On Friday, 4 October 2013 at 23:38:17 UTC, Joseph Rushton 
Wakeling wrote:

On 01/10/13 14:14, Dicebot wrote:

On Tuesday, 1 October 2013 at 12:02:29 UTC, w0rp wrote:
I'm waiting for Carmack to adopt D already. Barring some 
implementation
details (GC issues, shared libraries, bla bla) it's pretty 
much the perfect
language for what he wants to do. (Fast and functional in 
parts.) Plus, if
anyone could work around issues or figure out how to do 
really cool things

with D, it would be Carmack.


He is familiar with D and has shown appreciation for D `pure` 
functions in his

twitter posts.


One thing that I noted in his QuakeCon talk was his remarks 
about multiparadigm languages versus strictly functional 
languages, and how the former while they seem superior have the 
problem that, because you _can_ break the paradigm, you _do_.


I rather suspected he might have had D partially in mind with 
that remark, although he was gracious enough to not single out 
any languages.


That said, although I don't feel experienced enough in 
functional programming to comment with any authority, my 
impression is that D lets you be as strictly functional as you 
want to be, and has enough to let software architects impose 
strict purity etc. on a codebase.  But it is arguably less nice 
to have to keep marking pure const nothrow ... everywhere, 
plus const/immutable parameters, compared to something like 
Haskell where everything is that way by default.


I don't suppose it's possible to do that either by scope or 
even by module?


module my.module const nothrow pure @safe

or

const nothrow pure @safe
{
// my code here ...
}


D has some really serious flaw when it come to functionnal style.

 - Function aren't first class.
 - Delegates break type system.
 - Immutable object have identity issue that wouldn't show up in 
a functional language. It is unsure what the semantic around them 
is (and if identity must be preserved, then functional style is 
badly impaired).
 - Many qualifier do start to not make any sense when using 
functions as arguments (inout for instance).
 - Expect for type qualifier, it is impossible to express return 
qualification depending on the input(s qualification (and see 
point above, that do not work when using first class 
functions/delegates).


On implementation side, heap allocated values aren't optimized to 
go on the stack, ever. And the GC is unable to take advantage of 
immutability. Note that because everything is immutable in 
functional programming, both are mandatory if you don't want to 
trash your performances.

Re: std.d.lexer : voting thread

2013-10-04 Thread Andrei Alexandrescu


On 10/2/13 7:41 AM, Dicebot wrote:

After brief discussion with Brian and gathering data from the review
thread, I have decided to start voting for `std.d.lexer` inclusion into
Phobos.


Thanks all involved for the work, first of all Brian.

I have the proverbial good news and bad news. The only bad news is that 
I'm voting no on this proposal.


But there's plenty of good news.

1. I am not attempting to veto this, so just consider it a normal vote 
when tallying.


2. I do vote for inclusion in the /etc/ package for the time being.

3. The work is good and the code valuable, so even in the case my 
suggestions (below) will be followed, a virtually all code pulp that 
gets work done can be reused.


Vision
==

I'd been following the related discussions for a while, but I have made 
up my mind today as I was working on a C++ lexer today. The C++ lexer is 
for Facebook's internal linter. I'm translating the lexer from C++.


Before long I realized two simple things. First, I can't reuse anything 
from Brian's code (without copying it and doing surgery on it), although 
it is extremely similar to what I'm doing.


Second, I figured that it is almost trivial to implement a simple, 
generic, and reusable (across languages and tasks) static trie searcher 
that takes a compile-time array with all tokens and keywords and returns 
the token at the front of a range with minimum comparisons.


Such a trie searcher is not intelligent, but is very composable and 
extremely fast. It is just smart enough to do maximum munch (e.g. 
interprets == and foreach as one token each, not two), but is not 
smart enough to distinguish an identifier whileTrue from the keyword 
while (it claims while was found and stops right at the beginning of 
True in the stream). This is for generality so applications can define 
how identifiers work (e.g. Lisp allows - in identifiers but D doesn't 
etc). The trie finder doesn't do numbers or comments either. No regexen 
of any kind.


The beauty of it all is that all of these more involved bits (many of 
which are language specific) can be implemented modularly and trivially 
as a postprocessing step after the trie finder. For example the user 
specifies /* as a token to the trie finder. Whenever a comment starts, 
the trie finder will find and return it; then the user implements the 
alternate grammar of multiline comments.


To encode the tokens returned by the trie, we must do away with 
definitions such as


enum TokenType : ushort { invalid, assign, ... }

These are fine for a tokenizer written in C, but are needless 
duplication from a D perspective. I think a better approach is:


struct TokenType {
  string symbol;
  ...
}

TokenType tok(string s)() {
  static immutable string interned = s;
  return TokenType(interned);
}

Instead of associating token types with small integers, we associate 
them with string addresses. (For efficiency we may use pointers to 
zero-terminated strings, but I don't think that's necessary). Token 
types are interned by design, i.e. to compare two tokens for equality it 
suffices to compare the strings with is (this can be extended to 
general identifiers, not only statically-known tokens). Then, each token 
type has a natural representation that doesn't require the user to 
remember the name of the token. The left shift token is simply tok! 
and is application-global.


The static trie finder does not even build a trie - it simply generates 
a bunch of switch statements. The signature I've used is:


Tuple!(size_t, size_t, Token)
staticTrieFinder(alias TokenTable, R)(R r) {

It returns a tuple with (a) whitespace characters before token, (b) 
newlines before token, and (c) the token itself, returned as 
tok!whatever. To use for C++:


alias CppTokenTable = TypeTuple!(
  ~, (, ), [, ], {, }, ;, ,, ?,
  , , =, =, , , =, %, %=, =, ==, !, 
!=,

  ^, ^=, *, *=,
  :, ::, +, ++, +=, , , =, |, ||, |=,
  -, --, -=, -, -*,
  /, /=, //, /*,
  \\,
  .,
  ',
  \,
  #, ##,
  and,
  and_eq,
  asm,
  auto,
  ...
);

Then the code uses staticTrieFinder!([CppTokenTable])(range). Of course, 
it's also possible to define the table itself as an array. I'm exploring 
right now in search for the most advantageous choices.


I think the above would be a true lexer in the D spirit:

- exploits D's string templates to essentially define non-alphanumeric 
symbols that are easy to use and understand, not confined to predefined 
tables (that enum!) and cheap to compare;


- exploits D's code generation abilities to generate really fast code 
using inlined trie searching;


- offers and API that is generic, flexible, and infinitely reusable.

If what we need at this point is a conventional lexer for the D 
language, std.d.lexer is the ticket. But I think it wouldn't be 
difficult to push our ambitions way beyond that. What say you?



Andrei

Re: Official stdx

2013-10-04 Thread Jesse Phillips


On Friday, 4 October 2013 at 10:02:21 UTC, John Colvin wrote:
I would imagine a compulsory waiting period of the order of 
months, combined with a requirement of evidence that the module 
has been effective in the real world and that any outstanding 
problems have been resolved appropriately**.


I think this requirement is unobtainable. You're basically 
saying, Hey go use this in your real world applications. We've 
got a mandated break of that application, just don't know when 
that is. But totally use this like you can rely on it.


I know it is really nice to have these test libraries released 
with the compiler, but people really just need to go out and use 
these libraries before the inclusion. I'm guilty too. I had use 
for std.uuid, but didn't test it against my real code. It went 
through review and even after inclusion I was still using the 
basic generator I created from an RFC doc. I've since made the 
switch, but I didn't do it because a review needed my help.


I think a stdx could be beneficial in our current state but I 
think it should be temporary. One maybe two years. The timing for 
move should be clear, accepted = stdx = next release = std.

Re: std.d.lexer : voting thread

2013-10-04 Thread deadalnix

On Saturday, 5 October 2013 at 00:24:22 UTC, Andrei Alexandrescu 
wrote:

Vision
==

I'd been following the related discussions for a while, but I 
have made up my mind today as I was working on a C++ lexer 
today. The C++ lexer is for Facebook's internal linter. I'm 
translating the lexer from C++.


Before long I realized two simple things. First, I can't reuse 
anything from Brian's code (without copying it and doing 
surgery on it), although it is extremely similar to what I'm 
doing.


Second, I figured that it is almost trivial to implement a 
simple, generic, and reusable (across languages and tasks) 
static trie searcher that takes a compile-time array with all 
tokens and keywords and returns the token at the front of a 
range with minimum comparisons.


Such a trie searcher is not intelligent, but is very composable 
and extremely fast. It is just smart enough to do maximum munch 
(e.g. interprets == and foreach as one token each, not 
two), but is not smart enough to distinguish an identifier 
whileTrue from the keyword while (it claims while was 
found and stops right at the beginning of True in the 
stream). This is for generality so applications can define how 
identifiers work (e.g. Lisp allows - in identifiers but D 
doesn't etc). The trie finder doesn't do numbers or comments 
either. No regexen of any kind.


The beauty of it all is that all of these more involved bits 
(many of which are language specific) can be implemented 
modularly and trivially as a postprocessing step after the trie 
finder. For example the user specifies /* as a token to the 
trie finder. Whenever a comment starts, the trie finder will 
find and return it; then the user implements the alternate 
grammar of multiline comments.




That is more or less how SDC's lexer works. You pass it 2AA : one 
with string associated with tokens type, and one with string to 
function's name that return the actual token (for instance to 
handle /*) and finally one when nothing matches.


A giant 3 headed monster mixin is created from these data.

That has been really handy so far.

If what we need at this point is a conventional lexer for the D 
language, std.d.lexer is the ticket. But I think it wouldn't be 
difficult to push our ambitions way beyond that. What say you?




Yup, I do agree.

Re: std.d.lexer : voting thread


On 10/4/2013 5:24 PM, Andrei Alexandrescu wrote:

Such a trie searcher is not intelligent, but is very composable and extremely
fast.


Well, boys, I reckon this is it — benchmark combat toe to toe with the cooders. 
Now look, boys, I ain't much of a hand at makin' speeches, but I got a pretty 
fair idea that something doggone important is goin' on around there. And I got a 
fair idea the kinda personal emotions that some of you fellas may be thinkin'. 
Heck, I reckon you wouldn't even be human bein's if you didn't have some pretty 
strong personal feelin's about benchmark combat. I want you to remember one 
thing, the folks back home is a-countin' on you and by golly, we ain't about to 
let 'em down. I tell you something else, if this thing turns out to be half as 
important as I figure it just might be, I'd say that you're all in line for some 
important promotions and personal citations when this thing's over with. That 
goes for ever' last one of you regardless of your race, color or your creed. Now 
let's get this thing on the hump - we got some benchmarkin' to do.

How to get runtime type of this?


import std.stdio;

class A
{
static int id = 0;
this()
{
writeln(typeid=, typeid(this));
		writeln(id=,typeof(this).id); //how to get runtime type of 
this ??

}
}

class B : A
{
static int id = 1;
}

class C : A
{
static int id = 2;
}

void main()
{
A a = new B;
A b = new C;
}

typeof(this) can get compile time type while typeid yield a 
runtime TypeInfo instance, but how to get runtime type? I want 
the output to be id=1 and id=2 respectively.

Re: How to get runtime type of this?


On 2013-10-04 10:03, Zhouxuan wrote:

import std.stdio;

class A
{
 static int id = 0;
 this()
 {
 writeln(typeid=, typeid(this));
 writeln(id=,typeof(this).id); //how to get runtime type of
this ??
 }
}

class B : A
{
 static int id = 1;
}

class C : A
{
 static int id = 2;
}

void main()
{
 A a = new B;
 A b = new C;
}

typeof(this) can get compile time type while typeid yield a runtime
TypeInfo instance, but how to get runtime type? I want the output to be
id=1 and id=2 respectively.


You can do this:

class A
{
static int id = 0;
this(this T)()
{
writeln(typeid=, typeid(T));
writeln(id=,T.id); //how to get runtime type of this ??
}
}

class B : A
{
static int id = 1;
this () { super(); }
}

class C : A
{
static int id = 2;
this () { super(); }
}

void main()
{
A a = new B;
A b = new C;
}

Put I'm guess you want to avoid the constructor in the subclasses. I 
think there's a bug report about this.


--
/Jacob Carlborg

Re: How to get runtime type of this?


On Friday, 4 October 2013 at 08:23:11 UTC, Jacob Carlborg wrote:

On 2013-10-04 10:03, Zhouxuan wrote:

import std.stdio;

class A
{
static int id = 0;
this()
{
writeln(typeid=, typeid(this));
writeln(id=,typeof(this).id); //how to get runtime 
type of

this ??
}
}

class B : A
{
static int id = 1;
}

class C : A
{
static int id = 2;
}

void main()
{
A a = new B;
A b = new C;
}

typeof(this) can get compile time type while typeid yield a 
runtime
TypeInfo instance, but how to get runtime type? I want the 
output to be

id=1 and id=2 respectively.


You can do this:

class A
{
static int id = 0;
this(this T)()
{
writeln(typeid=, typeid(T));
writeln(id=,T.id); //how to get runtime type of this 
??

}
}

class B : A
{
static int id = 1;
this () { super(); }
}

class C : A
{
static int id = 2;
this () { super(); }
}

void main()
{
A a = new B;
A b = new C;
}

Put I'm guess you want to avoid the constructor in the 
subclasses. I think there's a bug report about this.


This is exactly what I want, thank you very much!
Redundant constructor here is not a problem, however there're so 
many workarounds atm.

Re: How to get runtime type of this?


On Friday, 4 October 2013 at 08:23:11 UTC, Jacob Carlborg wrote:

On 2013-10-04 10:03, Zhouxuan wrote:

import std.stdio;

class A
{
static int id = 0;
this()
{
writeln(typeid=, typeid(this));
writeln(id=,typeof(this).id); //how to get runtime 
type of

this ??
}
}

class B : A
{
static int id = 1;
}

class C : A
{
static int id = 2;
}

void main()
{
A a = new B;
A b = new C;
}

typeof(this) can get compile time type while typeid yield a 
runtime
TypeInfo instance, but how to get runtime type? I want the 
output to be

id=1 and id=2 respectively.


You can do this:

class A
{
static int id = 0;
this(this T)()
{
writeln(typeid=, typeid(T));
writeln(id=,T.id); //how to get runtime type of this 
??

}
}

class B : A
{
static int id = 1;
this () { super(); }
}

class C : A
{
static int id = 2;
this () { super(); }
}

void main()
{
A a = new B;
A b = new C;
}

Put I'm guess you want to avoid the constructor in the 
subclasses. I think there's a bug report about this.


Unfortunately it doesn't work if C inherits from B.

Re: How to get runtime type of this?

I am afraid if you want true polymorphic behavior, `id` needs to 
become a virtual getter function. D runtime reflection is quite 
lacking in that are.

Re: Ddoc WEB function


On 03/10/13 20:06, Jonathan M Davis wrote:

I don't see the problem. If you want the standard set of macros, then look at
the docs. If you want more, then add your own. We need more in the Phobos
docs, so we define more - many of which wouldn't even make sense as standard
macros. I see no reason to restrict Phobos to the standard set of macros.


I wouldn't dream of restricting Phobos just to the standard macros, but I did 
find it a little odd to define a new macro that does essentially much the same 
as a built-in one.  I suppose the logic would be that if you use WEB for 
internal dlang.org links, and LINK2 for externals, then you can control the 
protocol used for dlang.org -- e.g. switch everything from http to https if that 
ever becomes desirable.



I don't know how Walter arrived at the standard ones. I don't think that we
ever mess with those at this point. If we need new ones, we add them to
std.ddoc.


The main problem was that I didn't know about std.ddoc (it's in the dlang.org 
repo and not the Phobos one).  Now that I know, it's trivial to build a single 
Phobos doc file with


dmd -o -D std/whatever.d ../dlang.org/std.ddoc

I'd had some hassles building the docs en masse previously, and it was annoying 
to have to rebuild the lot when the goal was to check the tweaked docs of a 
single file.


So, thanks for the insight, and apologies if it seems like I'm over-complaining 
about a minor issue :-)


Best wishes,

-- Joe

Re: How to get runtime type of this?


On 2013-10-04 10:42, Zhouxuan wrote:


Unfortunately it doesn't work if C inherits from B.


What you need is a template constructor in B, just as in A. But it seems 
it's not possible to forward the template type to the base class.


--
/Jacob Carlborg

Re: Conflict between std.file write() and std.stdio write()