Re: Bartosz about Chapel

[foobar]

Caligo Wrote:

> On Mon, Nov 7, 2011 at 7:51 PM, bearophile  wrote:
> 
> > Bartosz talks a bit about the very nicely designed Chapel language:
> >
> > http://bartoszmilewski.wordpress.com/2011/11/07/supercomputing-in-seattle/
> >
> > (But my appreciation for Chapel design is on other things).
> >
> > Bye,
> > bearophile
> >
> 
> Interesting (maybe useless) facts: Chapel has 59 keywords.  D has, I think,
> 107 keywords.  C++11, I think, 81.  Python has 33.
> 
> On Mon, Nov 7, 2011 at 7:51 PM, bearophile 
> < href="mailto:bearophileh...@lycos.com";>bearophileh...@lycos.com>
>  wrote:
> Bartosz talks a bit about the very nicely designed Chapel language:
> 
>  href="http://bartoszmilewski.wordpress.com/2011/11/07/supercomputing-in-seattle/";
>  
> target="_blank">http://bartoszmilewski.wordpress.com/2011/11/07/supercomputing-in-seattle/
> 
> (But my appreciation for Chapel design is on other things).
> 
> Bye,
> bearophile
> Interesting (maybe useless) facts: Chapel 
> has 59 keywords.  D has, I think, 107 keywords.  C++11, I think, 81.  Python 
> has 33.
> 

Smalltalk has 5. How many does lisp have? brainfuck? whiltespace? 

Many people (me included) consider smalltalk to be one of the friendliest 
languages to use. It really is like talking with the computer. 
Measuring keyword count is wrong. what should be measured is *what* keywords 
are used and ease of expressiveness the language provides. 
On such a scale, Small talk would be best and APL would probably be worst with 
C+ a tight competition for 2nd worst. 

Regarding D, it's far better than c++ but still much further from smalltalk, 
python, and other very readable languages.
Last comment, to all those who keep character/word counts and try to shorten 
words - code is read 1000 as much as written so readability is many orders of 
magnitude more important  than conciseness. Best example is c+= "=0" for 
abstract/pure virtual. 

Re: RFC curl

[Jacob Carlborg]

On 2011-11-09 21:53, Jonas Drewsen wrote:

Hi,

So after the last review of the etc.curl there were some requests for
making it simpler.

After some thinking, refactoring and documentation I've come up with a
somewhat changed API.

Before sending it for official review again I would really like some
comments on the new API and if you think it is better or worse etc.

http://freeze.steamwinter.com/D/web/phobos/etc_curl.html

Thanks,
Jonas


BTW, why is this "etc.culr" and not "std.curl".

--
/Jacob Carlborg

Re: RFC curl

[Jacob Carlborg]

On 2011-11-09 21:53, Jonas Drewsen wrote:

Hi,

So after the last review of the etc.curl there were some requests for
making it simpler.

After some thinking, refactoring and documentation I've come up with a
somewhat changed API.

Before sending it for official review again I would really like some
comments on the new API and if you think it is better or worse etc.

http://freeze.steamwinter.com/D/web/phobos/etc_curl.html

Thanks,
Jonas


I like the new high level API, that's how easy it should be to download 
a file or get the content of a webpage.


What is the actual Phobos guideline in naming things that are keywords 
in D. I'm thinking about Method.del, shouldn't it be Method.delete_ or 
something similar, don't know what the guidelines say in this case. BTW, 
I would really like to have more official guidelines somewhere at the 
dpl page.


--
/Jacob Carlborg

Re: Bartosz about Chapel

[Jacob Carlborg]

On 2011-11-09 23:45, Danni Coy wrote:



On Wed, Nov 9, 2011 at 10:31 AM, Simen Kjærås mailto:simen.kja...@gmail.com>> wrote:

On Tue, 08 Nov 2011 05:39:07 +0100, Caligo mailto:iteronve...@gmail.com>> wrote:

On Mon, Nov 7, 2011 at 7:51 PM, bearophile
mailto:bearophileh...@lycos.com>> wrote:

Bartosz talks a bit about the very nicely designed Chapel
language:


http://bartoszmilewski.__wordpress.com/2011/11/07/__supercomputing-in-seattle/



(But my appreciation for Chapel design is on other things).

Bye,
bearophile


Interesting (maybe useless) facts: Chapel has 59 keywords.  D
has, I think,
107 keywords.  C++11, I think, 81.  Python has 33.


Interesting, questionably. Useless, indeed.


how many keywords in D are needed because the preprocessor is built into
the language itself?



A couple of extra, but we also reuse some existing once, i.e. "static if".

--
/Jacob Carlborg

Re: Version Identifiers for Platforms / Architectures not supported byDMD

[Jonathan M Davis]

On Thursday, November 10, 2011 05:08:03 kennytm wrote:
> Jonathan M Davis  wrote:
> > On Thursday, November 10, 2011 04:07:43 kennytm wrote:
> >> Perhaps DMD should generate a warning if a version of platforms does
> >> not
> >> have an else clause or that version's else clause's content is not
> >> another version statement or a static assert.
> > 
> > Well, that does get a bit fuzzy. For instance, rather than duplicating
> > that else clause all over the place in std.file, only the first static
> > if-else clause has the else with the static assert in it. All of the
> > others just have the branches that work and don't have an else clause.
> > If we were to require that there be an else like that, then std.file
> > wouldn't compile. And while it wouldn't be all that bad to have to put
> > an else on all of those static-ifs, it _would_ result in unnecessary
> > code duplication.
> > 
> > - Jonathan M Davis
> 
> I said version(Platform)s, not static if.

LOL. Yes. And I meant version(Platform). I obviously had my wires crossed when 
I wrote that. std.file uses

version(Posix)
{}
else version(Windows)
{}

without an else block, except for the first one in the file which _does_ have 
an 
else which has a static assert(0) in it. Requiring that all such version 
blocks had elses would invalidate that approach.

- Jonathan M Davis

Re: Bartosz about Chapel

[Caligo]

On Wed, Nov 9, 2011 at 8:58 PM, Walter Bright wrote:

> On 11/9/2011 5:46 PM, Caligo wrote:
>
>> There are about 20 directives, so that puts the keywords count for C++ to
>> 101.
>>  It's still fewer than D.  Does that mean D is more complex than C++?
>>
>
> C++ has "unsigned", "long", and "unsigned long" while D has "uint",
> "long", and "ulong". That's one more keyword; does that make D more complex
> than C++?
>
>
In that example, I prefer the D way.  But, in both cases the different data
types exist because of speed and efficiency.Semantically, int is more
or less a subset of long, so why do we need separate data types?  We don't,
really, and it's lame to clutter up the semantics of the language like that.

Something like this would have been better, and if I recall this is how
Chapel is doing it:

int(32)  a;  // int
int(64)  b;  // long


>
>  Python with 33, I think most would agree that is has a very consice
>> grammer.
>>
>
> Python lacks a lot of powerful features that are in D.
>
>
I know, and I wasn't trying to say that Python is more powerful.

ODBC component licenses

[Steve Teale]

The libraries for unixODBC and for FreeTDS (communication with SQL 
Server) are LGPL.

Would a D ODBC driver that used these be compatible with Phobos?

Steve

Re: How about a 100% CTFE?

[foobar]

Don Wrote:

> On 09.11.2011 16:30, foobar wrote:
> > Don Wrote:
> >
> >> On 09.11.2011 09:17, foobar wrote:
> >>> Don Wrote:
> >>>
>  On 07.11.2011 14:13, Gor Gyolchanyan wrote:
> > After reading
> >
> >http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide
> >
> > https://github.com/gor-f-gyolchanyan/dmd/blob/master/src/interpret.c
> >
> > I had a thought:
> > Why not compile and run CTFE code in a separate executable, write it's
> > output into a file, read that file and include it's contents into the
> > object file being compiled?
> > This would cover 100% of D in CTFE, including external function calls
> > and classes;
> > String mixins would simply repeat the process of compiling and running
> > an extra temporary executable.
> >
> > This would open up immense opportunities for such things as
> > library-based build systems and tons of unprecedented stuff, that I
> > can't imagine ATM.
> 
>  First comment: classes and exceptions now work in dmd git. The remaining
>  limitations on CTFE are intentional.
> 
>  With what you propose:
>  Cross compilation is a _big_ problem. It is not always true that the
>  source CPU is the same as the target CPU. The most trivial example,
>  which applies already for DMD 64bit, is size_t.sizeof. Conditional
>  compilation can magnify these differences. Different CPUs don't just
>  need different backend code generation; they may be quite different in
>  the semantic pass. I'm not sure that this is solvable.
> 
>  version(ARM)
>  {
>    immutable X = armSpecificCode(); // you want to run this on an 
>  X86???
>  }
> 
> >>>
> >>> I think we discussed those issues before.
> >>> 1. size_t.sizeof:
> >>> auto a = mixin("size_t.sizeof"); // HOST CPU
> >>> auto a = size_t.sizeof; // TARGET CPU
> >>
> >> That doesn't work. mixin happens _before_ CTFE. CTFE never does any
> >> semantics whatsoever.
> >>
> >
> > If I wasn't clear before - the above example is meant to illustrate how 
> > multilevel compilation *should* work.
> 
> Sorry, I don't understand what you're suggesting here.
> 
> > If you want, we can make it even clearer by replacing 'mixin' above with 
> > 'macro'.
> That doesn't help me. Unless it means that what you're talking about 
> goes far, far beyond CTFE.
> 
> Take std.bigint as an example, and suppose we're generating code for ARM 
> on an x86 machine. The final executable is going to be using BigInt, and 
> CTFE uses it as well.
> The semantic pass begins. The semantic pass discards all of the 
> x86-specific code in favour of the ARM-specific stuff. Now CTFE runs. 
> How can it then run natively on x86? All the x86 code is *gone* by then. 
> How do you deal with this?
> 

What I'm suggesting is to generalize C++'s two level compilation into arbitrary 
N-level compilation. 
The model is actually simpler and requires much less language support. 
It works like this: 
level n: you write *regular* run-time code as a "macro" using the compiler's 
public API to access its data structures. You compile into object form plug-ins 
loadable by the compiler.
level n+1 : you write *regular* run-time code. You provide the compiler the 
relevant plug-ins from level n, the compiler loads them and then compiles level 
n+1 code.
of course, this has arbitrary n levels since you could nest macros. 

So to answer your question, I do want to go far beyond CTFE. 
The problem you describe above happens due to the fact that CTFE is *not* a 
separate compilation step. With my model bigint would be compiled twice - once 
for X86 and another for ARM. 
As far as I understand this scenario is currently impossible - you can't use 
bigint with CTFE. 

> 
> >>>
> >>> 2. version (ARM) example - this needs clarification of the semantics. Two 
> >>> possible options are:
> >>> a. immutable X = ... will be performed on TARGET as is the case today. 
> >>> require 'mixin' to call it on HOST. This should be backwards compatible 
> >>> since we keep the current CTFE and add support for multi-level 
> >>> compilation.
> >>> b. immutable x = ... is run via the new system which requires the 
> >>> function "armSpecificCode" to be compiled ahead of time and provided to 
> >>> the compiler in an object form. No Platform incompatibility is possible.
> >>>
> >>> I don't see any problems with cross-compilation. It is a perfectly sound 
> >>> design (Universal Turing machine) and it was successfully implemented 
> >>> several times before: Lisp, scheme, Nemerle, etc.. It just requires to be 
> >>> a bit careful with the semantic definitions.
> >>
> >> AFAIK all these languages target a virtual machine.
> >>
> >
> > Nope. See http://www.cons.org/cmucl/ for a native lisp compiler.
> 
> That looks to me, as if it compiles to a virtual machine IR, then 
> compiles that. The real question is whether the characteristics of the 
> real machine are allow

Re: RFC curl

[Jimmy Cao]

2011/11/9 Brad Anderson 

> On Wed, Nov 9, 2011 at 9:31 PM, Kapps  wrote:
>
>> Windows is generally a place where people expect to not have to go and
>> install other external packages for things like this, but rather have it
>> bundled with the installer (zip in this case). Whereas on Linux, you could
>> just use your package manager to install the libraries, for Windows, you'd
>> have to actually find the website, find the library, possibly compile it
>> (difficult on Windows), implib/coffimplib it (something which has little to
>> no documentation and is very hard for new people to figure out, and
>> something I had a LOT of problems with trying to figure out originally; it
>> doesn't even come with DMD), and finally link it and hope for the best. It
>> would be MUCH better and simpler to just include it in the zip for Windows.
>>
>>
> I agree.  Python's "batteries included" style approach is a huge boon.
>  The number of users who would need a different version than the one
> included pales in comparison to the productivity gains of including it.
>  People who need a different version can just replace it themselves.  We
> could also just make the installer give the user a choice of installing it
> or not.
>
>
>>
>>
>  On 09/11/2011 6:58 PM, bearophile wrote:
>>
>>> Walter:
>>>
>>>  Thank you so much for doing this. I think it's a nice piece of work.

>>>
>>> I agree.
>>> As they say, easy things should be easy and hard things should be
>>> possible.
>>>
>>>
>>>  * libcurl should be a link to where people can read up on what it is.
 I suggest http://curl.haxx.se/libcurl
 Point out that the user will need libcurl installed on their system in
 order to
 use etc.curl.

>>>
>>> Is the (just) Windows compiled version present in the DMD zip? I don't
>>> remember what was the decision on this (I'd like it to be present).
>>>
>>> Bye,
>>> bearophile
>>>
>>
>>
>
I agree, on Windows it would be best to have a competent installer that
does this.

Re: RFC curl

[Brad Anderson]

On Wed, Nov 9, 2011 at 9:31 PM, Kapps  wrote:

> Windows is generally a place where people expect to not have to go and
> install other external packages for things like this, but rather have it
> bundled with the installer (zip in this case). Whereas on Linux, you could
> just use your package manager to install the libraries, for Windows, you'd
> have to actually find the website, find the library, possibly compile it
> (difficult on Windows), implib/coffimplib it (something which has little to
> no documentation and is very hard for new people to figure out, and
> something I had a LOT of problems with trying to figure out originally; it
> doesn't even come with DMD), and finally link it and hope for the best. It
> would be MUCH better and simpler to just include it in the zip for Windows.
>
>
I agree.  Python's "batteries included" style approach is a huge boon.  The
number of users who would need a different version than the one included
pales in comparison to the productivity gains of including it.  People who
need a different version can just replace it themselves.  We could also
just make the installer give the user a choice of installing it or not.


>
>
On 09/11/2011 6:58 PM, bearophile wrote:
>
>> Walter:
>>
>>  Thank you so much for doing this. I think it's a nice piece of work.
>>>
>>
>> I agree.
>> As they say, easy things should be easy and hard things should be
>> possible.
>>
>>
>>  * libcurl should be a link to where people can read up on what it is.
>>> I suggest http://curl.haxx.se/libcurl
>>> Point out that the user will need libcurl installed on their system in
>>> order to
>>> use etc.curl.
>>>
>>
>> Is the (just) Windows compiled version present in the DMD zip? I don't
>> remember what was the decision on this (I'd like it to be present).
>>
>> Bye,
>> bearophile
>>
>
>

Re: Reminder: Two days left to review Jesse Phillips' CSV Parser

[Jesse Phillips]

On Wed, 09 Nov 2011 20:46:51 -0500, dsimcha wrote:

> On 11/9/2011 8:02 PM, dsimcha wrote:
>> As a reminder, the review of Jesse Phillips' CSV parser ends at the end
>> of Friday and will be followed by one week of voting. Please speak up
>> now about any remaining issues.
> 
> BTW, here's my second round of review now that some changes have been
> made:
> 
> Design-level stuff:
> 
> How do I use csvReader to process a CSV file as it's being read in (i.e.
> I don't want to ever have the whole file in memory)?  I guess I could do
> something like:
> 
> import std.algorithm, std.stdio, std.csv, std.conv;
> 
> void main() {
>  auto file = File("foo.csv");
>  auto chars = joiner(file.byLine(), '\n');
> 
>  auto reader = csvReader(chars);
> }
> 
> If this would work, though, then it should be documented.

I do not see why the CSV documentation should be the place to document 
how to read a file in parts. As we don't have byChar and this is non-
trivial workaround I could see wanted to have it somewhere and CSV 
parsing might be a place to apply it.

What really don't like about it is that you don't get to see the input. 
It would be like std.algorithm showing how sorting worked by showing how 
to read in an array from a file and sorting it.

This is something people need to know how to do so we should have a good 
tutorial on it, but I don't think this is the place to document it (stdio 
or std.file is more appropriate). If you strongly disagree I will find 
some place to throw in another example.

> I'd also like
> to see csvReader tested with lowest-common-denominator input ranges
> instead of just strings, which are bidirectional ranges and can be
> treated as random access if they only have ASCII characters.

Yeah, through in a unittest wrapping a wstring with only input range 
interface.

> Also, IMHO
> we really need a ByChar range in std.stdio instead of the joiner kludge
> I used, though I'm not sure about the details with regard to how Unicode
> support should work.

I thought there was an undocumented such function, but maybe not.
 
> Still no support for writing CSVs?  I understand writing is complicated
> from an API design perspective.  Maybe it would be easiest to just
> provide an enquote() function that adds quotes to a field and escapes
> any that are already inside the field and let the user handle the higher
> level stuff, since this is pretty simple.

I'm going to make something, try a couple ideas out. Thanks for the 
naming suggestion. I ended up deciding not to do anything on it as even 
if I did get it done, it wouldn't have appropriate review time. So I'll 
let the voting be the deciding factor on whether the library is delayed 
because it doesn't have csvFormatter.

After more thought I think an enquote() type function must exist even 
with a csvFormatter, but even laying out documentation on that isn't 
trivial.

> Minor documentation nitpicks:
> 
> CSVException:  IncompletCellException -> IncompleteCellException (typo)
> 
> The first csvReader example:  You declare the variable count but don't
> use it.
> 
> Records, Record:  front(), empty(), popFront() should not mention
> std.range.InputRange.  These interfaces are virtual function-based
> interfaces in case someone needs virtual function-based access to a
> range.  They are not used in most cases when ranges are used because
> templates are usually better.

Yes, my bad. I keep forgetting we have such interfaces there. I've 
instead pointed it to isInputRange which is what I meant to do. But then 
I still call it an interface... which it is, but I don't know what we 
want to call them. Concepts? :D I want this link in there so if you have 
better suggestions...

Thank you.

Re: Version Identifiers for Platforms / Architectures not supported byDMD

[kennytm]

Jonathan M Davis  wrote:
> On Thursday, November 10, 2011 04:07:43 kennytm wrote:
>> Perhaps DMD should generate a warning if a version of platforms does not
>> have an else clause or that version's else clause's content is not another
>> version statement or a static assert.
> 
> Well, that does get a bit fuzzy. For instance, rather than duplicating that 
> else clause all over the place in std.file, only the first static if-else 
> clause 
> has the else with the static assert in it. All of the others just have the 
> branches that work and don't have an else clause. If we were to require that 
> there be an else like that, then std.file wouldn't compile. And while it 
> wouldn't be all that bad to have to put an else on all of those static-ifs, 
> it 
> _would_ result in unnecessary code duplication.
> 
> - Jonathan M Davis

I said version(Platform)s, not static if.

Re: bug in std.array.insertInPlace ?

[Ruslan Mullakhmetov]

On 2011-11-09 22:14:25 +0400, Jonathan M Davis said:


On Tuesday, November 08, 2011 23:55 Ruslan Mullakhmetov wrote:

Hi,

I found some strange behavior of std.array.insertInPlace leading to
segfault.

The example below works for int, it is failed for reference type with
array becoming of length bigger 1024 on windows (x64) and 512 on linux
(x64).

code: http://cloud.theambient.org/0O360r1d2t1g09171F1m

Is it my bug or compiler?


It might by related to http://d.puremagic.com/issues/show_bug.cgi?id=6874

- Jonathan M Davis


thakns. so i won't submit an issue.
--
BR, Ruslan Mullakhmetov

Re: assert(obj) is an atrocity

[Bernard Helyer]

Because it's a design issue, not a learning issue?

Re: assert(obj) is an atrocity

[Bernard Helyer]

Agreed on all points. It's pathetic that this is still a problem. Check 
the object for null. To not do so is a _bug_, even if Walter disagrees. 
SDC will not replicate DMD's behaviour in this regard.

-Bernard.

Re: Type Qualifiers and Wild Cards

[Kagamin]

Walter Bright Wrote:

> On 11/8/2011 11:10 AM, Martin Nowak wrote:
> > I personally find it much more astonishing that inout methods finally work.
> 
> In retrospect, it seems like a fairly straightforward solution, but it took 
> us 
> many, many hours and gallons of coffee. And, as far as I know, this solution 
> has 
> not been seen before in any other language, though there is a crying need for 
> it 
> in C++.

I don't think so. `inout` is needed in D because you get const data from const 
object because of transitivity, you have nothing like this in C++ POD. One can 
try to emulate transitive const with corresponding accessors, but is it used in 
C++ widely?

Re: RFC curl

[Kapps]

Windows is generally a place where people expect to not have to go and 
install other external packages for things like this, but rather have it 
bundled with the installer (zip in this case). Whereas on Linux, you 
could just use your package manager to install the libraries, for 
Windows, you'd have to actually find the website, find the library, 
possibly compile it (difficult on Windows), implib/coffimplib it 
(something which has little to no documentation and is very hard for new 
people to figure out, and something I had a LOT of problems with trying 
to figure out originally; it doesn't even come with DMD), and finally 
link it and hope for the best. It would be MUCH better and simpler to 
just include it in the zip for Windows.


On 09/11/2011 6:58 PM, bearophile wrote:

Walter:


Thank you so much for doing this. I think it's a nice piece of work.


I agree.
As they say, easy things should be easy and hard things should be possible.



* libcurl should be a link to where people can read up on what it is.
I suggest http://curl.haxx.se/libcurl
Point out that the user will need libcurl installed on their system in order to
use etc.curl.


Is the (just) Windows compiled version present in the DMD zip? I don't remember 
what was the decision on this (I'd like it to be present).

Bye,
bearophile

Re: Bartosz about Chapel

[Kagamin]

Caligo Wrote:

> You're right, I did forget about the preprocessor.  Besides the usual
> things in the header files, I always try to avoid macros.
> 
> There are about 20 directives, so that puts the keywords count for C++ to
> 101.  It's still fewer than D.  Does that mean D is more complex than C++?
> 
> Python with 33, I think most would agree that is has a very consice
> grammer.

If a language doesn't have `abstract`, `out` or `pure` it's fail rather than 
win.

Re: Version Identifiers for Platforms / Architectures not supported byDMD

[Jonathan M Davis]

On Thursday, November 10, 2011 04:07:43 kennytm wrote:
> Perhaps DMD should generate a warning if a version of platforms does not
> have an else clause or that version's else clause's content is not another
> version statement or a static assert.

Well, that does get a bit fuzzy. For instance, rather than duplicating that 
else clause all over the place in std.file, only the first static if-else 
clause 
has the else with the static assert in it. All of the others just have the 
branches that work and don't have an else clause. If we were to require that 
there be an else like that, then std.file wouldn't compile. And while it 
wouldn't be all that bad to have to put an else on all of those static-ifs, it 
_would_ result in unnecessary code duplication.

- Jonathan M Davis

Re: Integer overflow bug in windows

[Kagamin]

> > Solution: upgrade all computers to 64-bit
> 
> In windows ULONG is used for reference count, which is still 32-bit on 64-bit 
> system.

Although 32-bit counter may prove to be inadequate for 64-bit address space.

Re: assert(obj) is an atrocity

[bcs]

On 11/08/2011 11:42 PM, Timon Gehr wrote:

On 11/09/2011 04:52 AM, bcs wrote:

On 11/08/2011 04:28 PM, Timon Gehr wrote:

On 11/09/2011 01:21 AM, Timon Gehr wrote:

On 11/09/2011 01:18 AM, Martin Nowak wrote:

On Tue, 08 Nov 2011 23:35:33 +0100, Alex Rønne Petersen
 wrote:


Hi,

As the title suggests, I'm going to be rather blunt about this.
assert(obj) testing the invariant *without* doing a null check is
insane for the following reasons:

1) It is not what a user expects. It is *unintuitive*.
2) assert(!obj) does an is-null check. assert(obj) is a completely
broken opposite of this.
3) No AssertError is thrown, which is the entire point of the
built-in
assert().
4) The few added instructions for the null check hardly matter in a
*debug* build of all things.

I don't mind assert(obj) testing the invariant of obj. In fact, that
very much makes sense. But please, please, *please* check the object
for null first. This is a random inconsistency in the language
with no
other justification than "seg faults are convenient in a
debugger". By
the same logic, we might as well not have array bounds checks.
However, the state of things is that array bounds checks are emitted
by default and users can disable them for e.g. a release build. I
don't see why this case is any different.

- Alex


It does check for null.
Only it's a runtime support function (_d_invariant) and druntime is
likely
compiled without assertions. Are you really suggesting to add a null
check before
every method call?

martin


No, he is suggesting to add a null check for assert(objref);, a
construct that *looks* as if it was a null check, but does something
almost unrelated.


BTW, the number of occurrences of assert(objref && 1); in my code is
huge.



I would have used assert(!!obj) because it's shorter.



If you have already typed 'assert(obj', it is not shorter.


Faster to type? No. Shorter? Yes it still is. I spend enough more time 
reading and thinking about code that size is more relevant then typing 
speed.

Re: Integer overflow bug in windows

[Kagamin]

Marco Leise Wrote:

> Am 09.11.2011, 22:34 Uhr, schrieb Kagamin :
> 
> > http://blogs.technet.com/b/srd/archive/2011/11/08/assessing-the-exploitability-of-ms11-083.aspx
> 
> Solution: upgrade all computers to 64-bit

In windows ULONG is used for reference count, which is still 32-bit on 64-bit 
system.

Re: Version Identifiers for Platforms / Architectures not supported byDMD

[kennytm]

Walter Bright  wrote:
> On 11/9/2011 6:46 AM, Daniel Murphy wrote:
>> But, as it is a breaking change (very slightly), and a
>> special case, I doubt this will ever happen unless Walter loves the idea.
>> Walter?
> 
> Sorry, I don't love the idea. I dislike it for its inconsistency with the
> rest of the language. The trend in programming languages and operating
> systems has, for a long time, been towards case sensitivity.
> 
> BTW, the correct way to write version sensitive code is:
> 
> version (linux)
> {
>...
> }
> else version (OSX)
> {
>...
> }
> else
>static assert(0, "unsupported OS version");
> 
> 
> Otherwise, it's miserable to find and tweak all the version sensitive
> code in your codebase. Here's a WRONG WRONG WRONG way:
> 
> version (linux)
> {
> ...
> }
> else /* Windows */
> {
> ...
> }
> 
> Looks stupid, but I tend to often see stuff like this in C, C++ and D
> source code. Even in my own. This is also why there's no ! for versions:
> 
> version (!linux)
> {
> ...
> }
> 
> Aaaaggg. I'm pretty fed up with seeing that crap in C code. And if
> you see any of it in dmd or phobos sources, please file a bugzilla report! 
> Show no mercy.

Perhaps DMD should generate a warning if a version of platforms does not
have an else clause or that version's else clause's content is not another
version statement or a static assert.

Re: How about a 100% CTFE?

[Ary Manzana]

On 11/8/11 10:44 AM, deadalnix wrote:

Le 08/11/2011 14:31, Gor Gyolchanyan a écrit :

Well except that module can modify a and not be in the tree.


A single compilation includes only two parts: compiling D source code
and linking in object files or static libraries. object files and
static libraries are by no means involved in compile-time activity,
which leaves us with with compiling D source code. A single
compilation of D source code can be viewed as a list of import trees,
originating from the enlisted modules to be compiled. After
eliminating duplicates we have a list of small trees, which can be
rooted together to form a single tree, which in turn can be processed
as described above. Optionally, in order to allow separate
compilations, a cache can be maintained to hold the results of
previous compile-time computations to be used in the next ones inside
a "project" (to be defined).



module a;

int a = 0;

---

module b;

import a;

int somefunction() {
return ++a;
}

static assert(somefunction() = 1);

---

module c;

import a;

int somefunction() {
return ++a;
}

static assert(somefunction() = 1);


There answer here is: who cares?

Is your point to prove that you can make some code that is useless? Why 
not make something useful with CTFE?


It's sad to see people come here proposing great ideas (I think CTFE 
beyond what D is capable is great, and I'm implementing that in my own 
language) and other people come with nonsense useless examples to ask 
"What happens here?"


Use the tool to make magic, not to show how you can get undefined 
behaviour...

Re: RFC curl

[Jonathan M Davis]

On Wednesday, November 09, 2011 18:38:48 Walter Bright wrote:
> On 11/9/2011 5:13 PM, Jonathan M Davis wrote:
> > On Wednesday, November 09, 2011 16:58 bearophile wrote:
> >> Is the (just) Windows compiled version present in the DMD zip? I don't
> >> remember what was the decision on this (I'd like it to be present).
> > 
> > Currently, no version of libcurl is included in the zip file. I don't
> > believe that there has been any decision on what to do about it. But if
> > we do end up including it, then that's one more reason to consider
> > splitting up the zip file by OS.
> 
> I don't want us to get caught in the rat race of "the version that comes
> with the compiler is out of date". libcurl has its own development cycle,
> and dmd should not be slaved to that.

Yeah. That's one reason why I'm not a fan of the idea of distributing it with 
dmd. So, it won't hurt my feelings any if it never gets put into the zip file. 
However, we're going to have to make it clear in the documentation on how to 
get your hands on an appropriate libcurl library (especially since any version 
of it that you're likely to find online would be in the wrong library format).

- Jonathan M Davis

Re: Bartosz about Chapel

[Walter Bright]

On 11/9/2011 5:46 PM, Caligo wrote:

There are about 20 directives, so that puts the keywords count for C++ to 101.
  It's still fewer than D.  Does that mean D is more complex than C++?


C++ has "unsigned", "long", and "unsigned long" while D has "uint", "long", and 
"ulong". That's one more keyword; does that make D more complex than C++?




Python with 33, I think most would agree that is has a very consice grammer.


Python lacks a lot of powerful features that are in D.

Re: RFC curl

[Andrei Alexandrescu]

On 11/9/11 6:24 PM, Walter Bright wrote:

I tend to like references to things in other modules to be hyperlinks.
For example, writeln should be $(LINK2
http://www.d-programming-language.org/phobos/std_stdio.html#writeln,
writeln)


That should be XREF actually.

Andrei

Re: Bartosz about Chapel

[Danni Coy]

On Thu, Nov 10, 2011 at 11:46 AM, Caligo  wrote:

>
>
> On Wed, Nov 9, 2011 at 5:20 PM, Walter Bright 
> wrote:
>
>> On 11/9/2011 2:45 PM, Danni Coy wrote:
>>
>>> how many keywords in D are needed because the preprocessor is built into
>>> the
>>> language itself?
>>>
>>
>> It's true, people forget about the preprocessor keywords when counting
>> C++ keywords.
>>
>>
>>
> You're right, I did forget about the preprocessor.  Besides the usual
> things in the header files, I always try to avoid macros.
>
> There are about 20 directives, so that puts the keywords count for C++ to
> 101.  It's still fewer than D.  Does that mean D is more complex than C++?
>

Do keywords like unittest make the language more or less complex? (to use
one that isn't in C++).



Python with 33, I think most would agree that is has a very consice
> grammer.
>
> Being a dynamic language python would not have keywords for data types
right?
That has to be a large part of the difference. That said I do have to say
that Python does feel very concise.

Re: Bartosz about Chapel

[Kapps]

It means D can do the same thing with more explanatory keywords, yet in 
a more concise way.


On 09/11/2011 7:46 PM, Caligo wrote:



On Wed, Nov 9, 2011 at 5:20 PM, Walter Bright
mailto:newshou...@digitalmars.com>> wrote:

On 11/9/2011 2:45 PM, Danni Coy wrote:

how many keywords in D are needed because the preprocessor is
built into the
language itself?


It's true, people forget about the preprocessor keywords when
counting C++ keywords.



You're right, I did forget about the preprocessor.  Besides the usual
things in the header files, I always try to avoid macros.

There are about 20 directives, so that puts the keywords count for C++
to 101.  It's still fewer than D.  Does that mean D is more complex than
C++?

Python with 33, I think most would agree that is has a very consice
grammer.

Re: RFC curl

[Walter Bright]

On 11/9/2011 5:13 PM, Jonathan M Davis wrote:

On Wednesday, November 09, 2011 16:58 bearophile wrote:

Is the (just) Windows compiled version present in the DMD zip? I don't
remember what was the decision on this (I'd like it to be present).


Currently, no version of libcurl is included in the zip file. I don't believe
that there has been any decision on what to do about it. But if we do end up
including it, then that's one more reason to consider splitting up the zip
file by OS.


I don't want us to get caught in the rat race of "the version that comes with 
the compiler is out of date". libcurl has its own development cycle, and dmd 
should not be slaved to that.

Re: moving wxd to github

[Andrej Mitrovic]

FWIW the samples compile fine with the latest changesets, using dmd
make. Thanks for your work, Anders!

Re: Reminder: Two days left to review Jesse Phillips' CSV Parser

[dsimcha]

On 11/9/2011 8:02 PM, dsimcha wrote:

As a reminder, the review of Jesse Phillips' CSV parser ends at the end
of Friday and will be followed by one week of voting. Please speak up
now about any remaining issues.


BTW, here's my second round of review now that some changes have been made:

Design-level stuff:

How do I use csvReader to process a CSV file as it's being read in (i.e. 
I don't want to ever have the whole file in memory)?  I guess I could do 
something like:


import std.algorithm, std.stdio, std.csv, std.conv;

void main() {
auto file = File("foo.csv");
auto chars = joiner(file.byLine(), '\n');

auto reader = csvReader(chars);
}

If this would work, though, then it should be documented.  I'd also like 
to see csvReader tested with lowest-common-denominator input ranges 
instead of just strings, which are bidirectional ranges and can be 
treated as random access if they only have ASCII characters.  Also, IMHO 
we really need a ByChar range in std.stdio instead of the joiner kludge 
I used, though I'm not sure about the details with regard to how Unicode 
support should work.


Still no support for writing CSVs?  I understand writing is complicated 
from an API design perspective.  Maybe it would be easiest to just 
provide an enquote() function that adds quotes to a field and escapes 
any that are already inside the field and let the user handle the higher 
level stuff, since this is pretty simple.


Minor documentation nitpicks:

CSVException:  IncompletCellException -> IncompleteCellException (typo)

The first csvReader example:  You declare the variable count but don't 
use it.


Records, Record:  front(), empty(), popFront() should not mention 
std.range.InputRange.  These interfaces are virtual function-based 
interfaces in case someone needs virtual function-based access to a 
range.  They are not used in most cases when ranges are used because 
templates are usually better.

Re: Bartosz about Chapel

[Caligo]

On Wed, Nov 9, 2011 at 5:20 PM, Walter Bright wrote:

> On 11/9/2011 2:45 PM, Danni Coy wrote:
>
>> how many keywords in D are needed because the preprocessor is built into
>> the
>> language itself?
>>
>
> It's true, people forget about the preprocessor keywords when counting C++
> keywords.
>
>
>
You're right, I did forget about the preprocessor.  Besides the usual
things in the header files, I always try to avoid macros.

There are about 20 directives, so that puts the keywords count for C++ to
101.  It's still fewer than D.  Does that mean D is more complex than C++?

Python with 33, I think most would agree that is has a very consice
grammer.

Re: Linking Error (WS2_32.LIB)

[Vladimir Panteleev]

On Wed, 09 Nov 2011 20:09:39 +0200, Tobse  wrote:


Hey,
i wanted to write a basic cli chat to get familiar with d. So i looked  
up the
default library for sockets and found std.socket; There is a note that  
says

"compile with ws2_32.lib". When i simply run:

dmd main.d

it tells me:

OPTLINK (R) for Win32  Release 8.00.12
Copyright (C) Digital Mars 1989-2010  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
dist\client.obj(client)
 Error 42: Symbol Undefined _D3std6socket7Address8toStringMFZAya
dist\client.obj(client)
 Error 42: Symbol Undefined  
_D3std6socket7Address13addressFamilyMFZE3std6socket1

3AddressFamily
dist\client.obj(client)
 Error 42: Symbol Undefined _D3std6socket7Address7nameLenMFZi
dist\client.obj(client)
 Error 42: Symbol Undefined  
_D3std6socket7Address4nameMFZPS3std1c7windows7winsoc

k8sockaddr
--- errorlevel 4


These errors don't have anything to do with ws2_32.lib. It looks like you  
are trying to use the latest version of std.socket sources (from git) with  
an outdated phobos.lib. Did you download the latest version of std.socket  
without rebuilding Phobos, or something?


--
Best regards,
 Vladimirmailto:vladi...@thecybershadow.net

Re: RFC curl

[Jonathan M Davis]

On Wednesday, November 09, 2011 17:05 Simen Kjærås wrote:
> On Thu, 10 Nov 2011 01:25:29 +0100, Walter Bright
> 
>  wrote:
> > On 11/9/2011 4:24 PM, Walter Bright wrote:
> >> On 11/9/2011 12:53 PM, Jonas Drewsen wrote:
> >>> Before sending it for official review again I would really like some
> >>> comments on
> >>> the new API and if you think it is better or worse etc.
> >>> 
> >>> http://freeze.steamwinter.com/D/web/phobos/etc_curl.html
> >> 
> >> Thank you so much for doing this. I think it's a nice piece of work.
> > 
> > I forgot to mention: I like the cheat sheet a lot.
> 
> Indeed. I am tempted to argue all of our docs should have that.

It's essentially what std.algorithm does now, and std.container does something 
similar. I'd love to do something like that with std.datetime, but the fact 
that the anchors that ddoc generates have no concept of hiearchy (e.g. every 
year function in the file gets #year for its anchor rather than something like 
#Date.year, #DateTime.year, etc.). So, I couldn't provide any links in such a 
cheat sheat. I think that one or two people have said that they'd look into 
fixing it, but no one has actually fixed it yet. If no one else fixes it any 
time soon, I may be forced to go dig into ddoc to figure it out myself, which 
is definitely not where I want to be spending my time if I can avoid it.

- Jonathan M Davis

Re: How about a 100% CTFE?

[Don]

On 07.11.2011 17:00, Gor Gyolchanyan wrote:

Well and somefunction ? It does modify teh value of a too. Is it executed 
before ? after ? What is the value at the end of all that ?


Obviously it will be incremented first.
The order is dependent of the rules by which the conditions are
evaluated at compile-time. For example, the compiler will build a
depth-first list of the import tree and evaluate code sequentially in
each module.


This is not what it does now. At present, the order of compile-time 
evaluation is not defined; DMD currently does it vaguely in lexical 
order but that is planned to change in the near future. 'static if' and 
'mixin' will be evaluated in lexical order, before anything else is 
done. Afterwards, everything else will be evaluated on-demand.


Apart from the "static if/mixin" pass, compilation can proceed in 
parallel (though the current implementation doesn't yet do this) which 
means there's no ordering (multiple items may complete compilation 
simultaneously).


Allowing globals to be modified at compile time would destroy this.

Re: RFC curl

[Jonathan M Davis]

On Wednesday, November 09, 2011 16:58 bearophile wrote:
> Is the (just) Windows compiled version present in the DMD zip? I don't
> remember what was the decision on this (I'd like it to be present).

Currently, no version of libcurl is included in the zip file. I don't believe 
that there has been any decision on what to do about it. But if we do end up 
including it, then that's one more reason to consider splitting up the zip 
file by OS.

- Jonathan M Davis

Re: RFC curl

[Simen Kjærås]

On Thu, 10 Nov 2011 01:25:29 +0100, Walter Bright  
 wrote:



On 11/9/2011 4:24 PM, Walter Bright wrote:

On 11/9/2011 12:53 PM, Jonas Drewsen wrote:
Before sending it for official review again I would really like some  
comments on

the new API and if you think it is better or worse etc.

http://freeze.steamwinter.com/D/web/phobos/etc_curl.html


Thank you so much for doing this. I think it's a nice piece of work.


I forgot to mention: I like the cheat sheet a lot.


Indeed. I am tempted to argue all of our docs should have that.

Reminder: Two days left to review Jesse Phillips' CSV Parser

[dsimcha]

As a reminder, the review of Jesse Phillips' CSV parser ends at the end 
of Friday and will be followed by one week of voting.  Please speak up 
now about any remaining issues.

Re: RFC curl

[bearophile]

Walter:

> Thank you so much for doing this. I think it's a nice piece of work.

I agree.
As they say, easy things should be easy and hard things should be possible.


> * libcurl should be a link to where people can read up on what it is.
> I suggest http://curl.haxx.se/libcurl
> Point out that the user will need libcurl installed on their system in order 
> to 
> use etc.curl.

Is the (just) Windows compiled version present in the DMD zip? I don't remember 
what was the decision on this (I'd like it to be present).

Bye,
bearophile

Re: RFC curl

[Walter Bright]

On 11/9/2011 4:24 PM, Walter Bright wrote:

On 11/9/2011 12:53 PM, Jonas Drewsen wrote:

Before sending it for official review again I would really like some comments on
the new API and if you think it is better or worse etc.

http://freeze.steamwinter.com/D/web/phobos/etc_curl.html


Thank you so much for doing this. I think it's a nice piece of work.


I forgot to mention: I like the cheat sheet a lot.

Re: RFC curl

[Walter Bright]

On 11/9/2011 12:53 PM, Jonas Drewsen wrote:

Before sending it for official review again I would really like some comments on
the new API and if you think it is better or worse etc.

http://freeze.steamwinter.com/D/web/phobos/etc_curl.html


Thank you so much for doing this. I think it's a nice piece of work.

Some nitpicky comments:

* libcurl should be a link to where people can read up on what it is.
I suggest http://curl.haxx.se/libcurl
Point out that the user will need libcurl installed on their system in order to 
use etc.curl.


* Need a brief statement on why a D programmer should prefer using etc.curl 
rather than directly use libcurl.


* "ranges" should be a link to what a range is

* examples should include

import etc.curl;

and any other needed, like std.stdio. In fact, they should be cut & paste 
complete examples that are compilable and runnable.


* Keep comment lines under 40 characters; use multiple lines for longer 
comments. (This is so things format better for small screens.) Try to format 
code so it doesn't need more than 40 lines. I tend to indent by only two spaces 
in documentation which helps.


* Remove all instances of the word "you". For example,

"If you need more control than the low high level functions provide, you'll have 
to use the low level API:"


rewrite as:

"For more control than the low high level functions provide, use the low level 
API:"

Note how much simpler and direct it is. "You" is almost always an unnecessary 
filler word, and frankly has no place in a reference work.


* For the same reason, get rid of "we":

"First, we create an instance" => "First, create an instance"
"We then set" => "Then set"

* derivate => derived

* "Connection type used when the url should be used to auto detect protocol"
 .. I have no idea what this sentence means.

* "HTTP/FTP upload from local file system." => Upload file from local
 file system using the HTTP or FTP protocol."
And which protocol would be used?

* "A string with the content of the resource pointer to by the url"
Missing period. Grammar problems, how about:
"A string containing the content of the resource pointed to by the url."

Most of these apply to the rest of the documentation.

Also, need more examples.

I tend to like references to things in other modules to be hyperlinks. For 
example, writeln should be $(LINK2 
http://www.d-programming-language.org/phobos/std_stdio.html#writeln, writeln)

Re: Version Identifiers for Platforms / Architectures not supported byDMD

[Walter Bright]

On 11/9/2011 6:46 AM, Daniel Murphy wrote:

But, as it is a breaking change (very slightly), and a
special case, I doubt this will ever happen unless Walter loves the idea.
Walter?


Sorry, I don't love the idea. I dislike it for its inconsistency with the rest 
of the language. The trend in programming languages and operating systems has, 
for a long time, been towards case sensitivity.


BTW, the correct way to write version sensitive code is:

version (linux)
{
   ...
}
else version (OSX)
{
   ...
}
else
   static assert(0, "unsupported OS version");


Otherwise, it's miserable to find and tweak all the version sensitive code in 
your codebase. Here's a WRONG WRONG WRONG way:


version (linux)
{
...
}
else /* Windows */
{
...
}

Looks stupid, but I tend to often see stuff like this in C, C++ and D source 
code. Even in my own. This is also why there's no ! for versions:


version (!linux)
{
...
}

Aaaaggg. I'm pretty fed up with seeing that crap in C code. And if you see 
any of it in dmd or phobos sources, please file a bugzilla report! Show no mercy.

Re: Bartosz about Chapel

[Walter Bright]

On 11/9/2011 2:45 PM, Danni Coy wrote:

how many keywords in D are needed because the preprocessor is built into the
language itself?


It's true, people forget about the preprocessor keywords when counting C++ 
keywords.

Re: Integer overflow bug in windows

[Alex Rønne Petersen]

On 09-11-2011 23:49, bearophile wrote:

Kagamin:


http://blogs.technet.com/b/srd/archive/2011/11/08/assessing-the-exploitability-of-ms11-083.aspx


I'd like a runtime error when an integral overflows (unsigned numbers too, the 
C99 Standard is not a religion book for me), unless where asked otherwise.

Bye,
bearophile


If anything, we should do it like C#: have checked/unchecked arithmetic 
blocks.


- Alex

Re: How about a 100% CTFE?

[Don]

On 09.11.2011 16:30, foobar wrote:

Don Wrote:


On 09.11.2011 09:17, foobar wrote:

Don Wrote:


On 07.11.2011 14:13, Gor Gyolchanyan wrote:

After reading

   http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide
   https://github.com/gor-f-gyolchanyan/dmd/blob/master/src/interpret.c

I had a thought:
Why not compile and run CTFE code in a separate executable, write it's
output into a file, read that file and include it's contents into the
object file being compiled?
This would cover 100% of D in CTFE, including external function calls
and classes;
String mixins would simply repeat the process of compiling and running
an extra temporary executable.

This would open up immense opportunities for such things as
library-based build systems and tons of unprecedented stuff, that I
can't imagine ATM.


First comment: classes and exceptions now work in dmd git. The remaining
limitations on CTFE are intentional.

With what you propose:
Cross compilation is a _big_ problem. It is not always true that the
source CPU is the same as the target CPU. The most trivial example,
which applies already for DMD 64bit, is size_t.sizeof. Conditional
compilation can magnify these differences. Different CPUs don't just
need different backend code generation; they may be quite different in
the semantic pass. I'm not sure that this is solvable.

version(ARM)
{
  immutable X = armSpecificCode(); // you want to run this on an X86???
}



I think we discussed those issues before.
1. size_t.sizeof:
auto a = mixin("size_t.sizeof"); // HOST CPU
auto a = size_t.sizeof; // TARGET CPU


That doesn't work. mixin happens _before_ CTFE. CTFE never does any
semantics whatsoever.



If I wasn't clear before - the above example is meant to illustrate how 
multilevel compilation *should* work.


Sorry, I don't understand what you're suggesting here.


If you want, we can make it even clearer by replacing 'mixin' above with 
'macro'.
That doesn't help me. Unless it means that what you're talking about 
goes far, far beyond CTFE.


Take std.bigint as an example, and suppose we're generating code for ARM 
on an x86 machine. The final executable is going to be using BigInt, and 
CTFE uses it as well.
The semantic pass begins. The semantic pass discards all of the 
x86-specific code in favour of the ARM-specific stuff. Now CTFE runs. 
How can it then run natively on x86? All the x86 code is *gone* by then. 
How do you deal with this?





2. version (ARM) example - this needs clarification of the semantics. Two 
possible options are:
a. immutable X = ... will be performed on TARGET as is the case today. require 
'mixin' to call it on HOST. This should be backwards compatible since we keep 
the current CTFE and add support for multi-level compilation.
b. immutable x = ... is run via the new system which requires the function 
"armSpecificCode" to be compiled ahead of time and provided to the compiler in 
an object form. No Platform incompatibility is possible.

I don't see any problems with cross-compilation. It is a perfectly sound design 
(Universal Turing machine) and it was successfully implemented several times 
before: Lisp, scheme, Nemerle, etc.. It just requires to be a bit careful with 
the semantic definitions.


AFAIK all these languages target a virtual machine.



Nope. See http://www.cons.org/cmucl/ for a native lisp compiler.


That looks to me, as if it compiles to a virtual machine IR, then 
compiles that. The real question is whether the characteristics of the 
real machine are allowed to affect front-end semantics. Do any of those 
languages do that?

Re: Type Qualifiers and Wild Cards

[bearophile]

Walter:

> http://drdobbs.com/blogs/cpp/231902461
> 
> Anyone want to do the reddit honors?

On Reddit I see the discussion is a bit about merging of templates that produce 
the same function code. This is already possible in D, compiling with the LDC1 
(and maybe LDC2 too) compiler using the -mergefunc switch.

I think according to the C standard all functions must have different function 
pointers, and I presume D has the same rule (even if I don't remember reading 
it in the D specs). This problem is solved leaving a tiny stub that just 
contains a jump instruction for the removed duplicated functions. This jump is 
probably nearly always correctly "predicted" by the CPU, because it's 
hard-coded.

As far as I know this -mergefunc is not able to remove partially duplicated 
functions, this is left to future improvements of the LLVM back-end.

Bye,
bearophile

Re: Integer overflow bug in windows

[bearophile]

Kagamin:

> http://blogs.technet.com/b/srd/archive/2011/11/08/assessing-the-exploitability-of-ms11-083.aspx

I'd like a runtime error when an integral overflows (unsigned numbers too, the 
C99 Standard is not a religion book for me), unless where asked otherwise.

Bye,
bearophile

Re: Bartosz about Chapel

[Danni Coy]

On Wed, Nov 9, 2011 at 10:31 AM, Simen Kjærås wrote:

> On Tue, 08 Nov 2011 05:39:07 +0100, Caligo  wrote:
>
>  On Mon, Nov 7, 2011 at 7:51 PM, bearophile 
>> wrote:
>>
>>  Bartosz talks a bit about the very nicely designed Chapel language:
>>>
>>> http://bartoszmilewski.**wordpress.com/2011/11/07/**
>>> supercomputing-in-seattle/
>>>
>>> (But my appreciation for Chapel design is on other things).
>>>
>>> Bye,
>>> bearophile
>>>
>>>
>> Interesting (maybe useless) facts: Chapel has 59 keywords.  D has, I
>> think,
>> 107 keywords.  C++11, I think, 81.  Python has 33.
>>
>
> Interesting, questionably. Useless, indeed.
>

how many keywords in D are needed because the preprocessor is built into
the language itself?

Re: RFC curl

[Marco Leise]

Am 09.11.2011, 21:53 Uhr, schrieb Jonas Drewsen :


Hi,

So after the last review of the etc.curl there were some requests  
for making it simpler.


After some thinking, refactoring and documentation I've come up with a  
somewhat changed API.


Before sending it for official review again I would really like some  
comments on the new API and if you think it is better or worse etc.


http://freeze.steamwinter.com/D/web/phobos/etc_curl.html

Thanks,
Jonas


Amazing! D docs that look like they were made to be read by a human being!  
;)
I like the accessibility, that gets you right to the point for any use  
case. I did not compare it to your previous version though.
The external links sometimes have four slashes http: and the text  
"Authentication method equal to" looks incomplete and you wrote valie  
instead of value. Good luck with the next review!

Re: Integer overflow bug in windows

[Marco Leise]

Am 09.11.2011, 22:34 Uhr, schrieb Kagamin :


http://blogs.technet.com/b/srd/archive/2011/11/08/assessing-the-exploitability-of-ms11-083.aspx


Solution: upgrade all computers to 64-bit

Integer overflow bug in windows

[Kagamin]

http://blogs.technet.com/b/srd/archive/2011/11/08/assessing-the-exploitability-of-ms11-083.aspx

Re: ScintillaD 0.0.1

[Trass3r]

Any features you're planning to add that aren't in C++ Scintilla? (I'd  
*love* to be able to have support for elastic tabstops.)


Never heard of elastic tabstops before. Thx for mentioning that.

RFC curl

[Jonas Drewsen]

Hi,

   So after the last review of the etc.curl there were some requests 
for making it simpler.


After some thinking, refactoring and documentation I've come up with a 
somewhat changed API.


Before sending it for official review again I would really like some 
comments on the new API and if you think it is better or worse etc.


http://freeze.steamwinter.com/D/web/phobos/etc_curl.html

Thanks,
Jonas

Re: Type Qualifiers and Wild Cards

[Tobias Pankrath]

Andrei Alexandrescu wrote:

> On 11/9/11 9:58 AM, Nick Treleaven wrote:
>> On 09/11/2011 15:29, deadalnix wrote:
>>> inout isn't reminding in any way of its functionnality. It is more
>>> readable than ##, for sure, but way less than any word from
>>> const/immutable lexical field.
>>
>> inout means transfer the input qualifier to the output, it is
>> descriptive enough.
> 
> Thank you. I was itching to write that but was hoping somebody else would.
> 
> Andrei

it would be a good solution, if in and out didn't exists.

I was _very_ confused, when I first saw inout and thougth it would be
a combination of in and out.

So I think it deserves a prominent place in the documentation next to in and 
out.

Re: Linking Error (WS2_32.LIB)

[mta`chrono]

After compiling the sources dmd will call optlink to do the linking. I
don't know why it's failing, but try to pass -v to dmd to see what's
happening.

Once you're done, you'll see how it calls optlink which is documented
here: http://www.digitalmars.com/ctg/optlink.html

Command line operation of OPTLINK uses the following syntax:
LINK obj[,out[,map[,lib[,def[,res]

Please also have a look at the environment variables (See link). Optlink
will use them as search pathes. But it's also explanied there.

I'm not quite sure, because I'm living in the linux world. But maybe you
could also use the mingw tools to link ???

- mta`chrono

Re: Linking Error (WS2_32.LIB)

[Tobse]

No, did not work, same result.

C:\Users\Tobse\Documents\chat>dmd main.d ws2_32.lib -ofdist\client.exe
OPTLINK (R) for Win32  Release 8.00.12
Copyright (C) Digital Mars 1989-2010  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
dist\client.obj(client)
 Error 42: Symbol Undefined _D3std6socket7Address8toStringMFZAya
dist\client.obj(client)
 Error 42: Symbol Undefined _D3std6socket7Address13addressFamilyMFZE3std6socket1
3AddressFamily
dist\client.obj(client)
 Error 42: Symbol Undefined _D3std6socket7Address7nameLenMFZi
dist\client.obj(client)
 Error 42: Symbol Undefined _D3std6socket7Address4nameMFZPS3std1c7windows7winsoc
k8sockaddr
--- errorlevel 4

Re: Type Qualifiers and Wild Cards

[Andrei Alexandrescu]

On 11/9/11 9:58 AM, Nick Treleaven wrote:

On 09/11/2011 15:29, deadalnix wrote:

inout isn't reminding in any way of its functionnality. It is more
readable than ##, for sure, but way less than any word from
const/immutable lexical field.


inout means transfer the input qualifier to the output, it is
descriptive enough.


Thank you. I was itching to write that but was hoping somebody else would.

Andrei

Re: Linking Error (WS2_32.LIB)

[Nick Sabalausky]

"Tobse"  wrote in message 
news:j9efl3$2igk$1...@digitalmars.com...
> Hey,
> i wanted to write a basic cli chat to get familiar with d. So i looked up 
> the
> default library for sockets and found std.socket; There is a note that 
> says
> "compile with ws2_32.lib". When i simply run:
>
> dmd main.d
>
> it tells me:
>
> OPTLINK (R) for Win32  Release 8.00.12
> Copyright (C) Digital Mars 1989-2010  All rights reserved.
> http://www.digitalmars.com/ctg/optlink.html
> dist\client.obj(client)
> Error 42: Symbol Undefined _D3std6socket7Address8toStringMFZAya
> dist\client.obj(client)
> Error 42: Symbol Undefined 
> _D3std6socket7Address13addressFamilyMFZE3std6socket1
> 3AddressFamily
> dist\client.obj(client)
> Error 42: Symbol Undefined _D3std6socket7Address7nameLenMFZi
> dist\client.obj(client)
> Error 42: Symbol Undefined 
> _D3std6socket7Address4nameMFZPS3std1c7windows7winsoc
> k8sockaddr
> --- errorlevel 4
>
> So then i tried this:
>
> dmd main.d -Llib ws2_32.lib
>
> But i keep getting the exact same error plus
>
> OPTLINK : Warning 9: Unknown Option : NOILIB
>
> doing this:
>
> dmd main.d
> link client.obj -lib ws2_32.lib
>
> Its the same again plus
>
> OPTLINK : Warning 9: Unknown Option : LIB
>
>
> Can somone please tell me how to link the compiled code correctly so that 
> i
> can run it? Or is this a bug?
>
> Greets, Tobi

Not sure whether or not there's some other problem, but try this:

dmd main.d ws2_32.lib

Re: bug in std.array.insertInPlace ?

[Jonathan M Davis]

On Tuesday, November 08, 2011 23:55 Ruslan Mullakhmetov wrote:
> Hi,
> 
> I found some strange behavior of std.array.insertInPlace leading to
> segfault.
> 
> The example below works for int, it is failed for reference type with
> array becoming of length bigger 1024 on windows (x64) and 512 on linux
> (x64).
> 
> code: http://cloud.theambient.org/0O360r1d2t1g09171F1m
> 
> Is it my bug or compiler?

It might by related to http://d.puremagic.com/issues/show_bug.cgi?id=6874

- Jonathan M Davis

Linking Error (WS2_32.LIB)

[Tobse]

Hey,
i wanted to write a basic cli chat to get familiar with d. So i looked up the
default library for sockets and found std.socket; There is a note that says
"compile with ws2_32.lib". When i simply run:

dmd main.d

it tells me:

OPTLINK (R) for Win32  Release 8.00.12
Copyright (C) Digital Mars 1989-2010  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
dist\client.obj(client)
 Error 42: Symbol Undefined _D3std6socket7Address8toStringMFZAya
dist\client.obj(client)
 Error 42: Symbol Undefined _D3std6socket7Address13addressFamilyMFZE3std6socket1
3AddressFamily
dist\client.obj(client)
 Error 42: Symbol Undefined _D3std6socket7Address7nameLenMFZi
dist\client.obj(client)
 Error 42: Symbol Undefined _D3std6socket7Address4nameMFZPS3std1c7windows7winsoc
k8sockaddr
--- errorlevel 4

So then i tried this:

dmd main.d -Llib ws2_32.lib

But i keep getting the exact same error plus

OPTLINK : Warning 9: Unknown Option : NOILIB

doing this:

dmd main.d
link client.obj -lib ws2_32.lib

Its the same again plus

OPTLINK : Warning 9: Unknown Option : LIB


Can somone please tell me how to link the compiled code correctly so that i
can run it? Or is this a bug?

Greets, Tobi

Re: ScintillaD 0.0.1

[Andrej Mitrovic]

Hey zhang,

I see you can now run SciteD, but it still crashes of course. Does
ScintillaD have more bugs to fix, or just SciteD, or even both?

Re: Damn - again!

[Justin Whear]

KNode.


Steve Teale wrote:

> I use the Pan newsreader. In the mornings when I'm looking at
> digitalmars.D I regularly make the mistake of editing the panel that
> displays the individual posts.
> 
> I'll mark some of the older text and hit delete. At that point you are
> hosed. The article disappears, and there's no obvious way to get it back.
> 
> Any recommendations for a different reader?
> 
> Steve

Re: Type Qualifiers and Wild Cards

[Nick Treleaven]

On 09/11/2011 15:29, deadalnix wrote:

inout isn't reminding in any way of its functionnality. It is more
readable than ##, for sure, but way less than any word from
const/immutable lexical field.


inout means transfer the input qualifier to the output, it is 
descriptive enough.

Re: How about a 100% CTFE?

[foobar]

Don Wrote:

> On 09.11.2011 09:17, foobar wrote:
> > Don Wrote:
> >
> >> On 07.11.2011 14:13, Gor Gyolchanyan wrote:
> >>> After reading
> >>>
> >>>   http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide
> >>>   https://github.com/gor-f-gyolchanyan/dmd/blob/master/src/interpret.c
> >>>
> >>> I had a thought:
> >>> Why not compile and run CTFE code in a separate executable, write it's
> >>> output into a file, read that file and include it's contents into the
> >>> object file being compiled?
> >>> This would cover 100% of D in CTFE, including external function calls
> >>> and classes;
> >>> String mixins would simply repeat the process of compiling and running
> >>> an extra temporary executable.
> >>>
> >>> This would open up immense opportunities for such things as
> >>> library-based build systems and tons of unprecedented stuff, that I
> >>> can't imagine ATM.
> >>
> >> First comment: classes and exceptions now work in dmd git. The remaining
> >> limitations on CTFE are intentional.
> >>
> >> With what you propose:
> >> Cross compilation is a _big_ problem. It is not always true that the
> >> source CPU is the same as the target CPU. The most trivial example,
> >> which applies already for DMD 64bit, is size_t.sizeof. Conditional
> >> compilation can magnify these differences. Different CPUs don't just
> >> need different backend code generation; they may be quite different in
> >> the semantic pass. I'm not sure that this is solvable.
> >>
> >> version(ARM)
> >> {
> >>  immutable X = armSpecificCode(); // you want to run this on an X86???
> >> }
> >>
> >
> > I think we discussed those issues before.
> > 1. size_t.sizeof:
> > auto a = mixin("size_t.sizeof"); // HOST CPU
> > auto a = size_t.sizeof; // TARGET CPU
> 
> That doesn't work. mixin happens _before_ CTFE. CTFE never does any 
> semantics whatsoever.
> 

If I wasn't clear before - the above example is meant to illustrate how 
multilevel compilation *should* work. 
If you want, we can make it even clearer by replacing 'mixin' above with 
'macro'.

> >
> > 2. version (ARM) example - this needs clarification of the semantics. Two 
> > possible options are:
> > a. immutable X = ... will be performed on TARGET as is the case today. 
> > require 'mixin' to call it on HOST. This should be backwards compatible 
> > since we keep the current CTFE and add support for multi-level compilation.
> > b. immutable x = ... is run via the new system which requires the function 
> > "armSpecificCode" to be compiled ahead of time and provided to the compiler 
> > in an object form. No Platform incompatibility is possible.
> >
> > I don't see any problems with cross-compilation. It is a perfectly sound 
> > design (Universal Turing machine) and it was successfully implemented 
> > several times before: Lisp, scheme, Nemerle, etc.. It just requires to be a 
> > bit careful with the semantic definitions.
> 
> AFAIK all these languages target a virtual machine.
> 

Nope. See http://www.cons.org/cmucl/ for a native lisp compiler. 

Re: Type Qualifiers and Wild Cards

[deadalnix]

The whole "too many keywords" issue strikes me as strange. English has
over a million words in it. Who cares if a language uses 80 or 100 of
them? What difference can it possibly make? How can an extra 20 words
pollute the million word namespace (and not including any non-word
identifiers (like inout))?

Another silly aspect of this issue is all keywords could be replaced by
a sequence of special characters. For example, we could replace inout
with ##. Voila! Less keywords! But is that better?

Keywords exist to make the language more readable. That's why we use
inout instead of ##, and it's why we use + instead of add.


Well, using inout contradict this argument. inout isn't reminding in any 
way of its functionnality. It is more readable than ##, for sure, but 
way less than any word from const/immutable lexical field.

Re: Version Identifiers for Platforms / Architectures not supported byDMD

[Daniel Murphy]

"Alex Rønne Petersen"  wrote in message 
news:j9dviv$1jbd$4...@digitalmars.com...

...
>
> In general, I agree, but this would be a breaking change no matter how you 
> look at it. I'm not sure if that's a good idea.
>
> - Alex

Thanks for the comments.  I expect this change would fix many, many more 
bugs than it causes.  But, as it is a breaking change (very slightly), and a 
special case, I doubt this will ever happen unless Walter loves the idea. 
Walter? 

Re: Type Qualifiers and Wild Cards

[Kagamin]

Don Wrote:

> I'd be happy with auto_ref or autoref or pretty much any sequence of 
> characters that doesn't contain " auto ".

As it's a function attribute, it doesn't have to be a keyword in the first 
place. @autoref is just fine.

Re: Type Qualifiers and Wild Cards

[Kagamin]

Timon Gehr Wrote:

> Actually, we don't have the transitive qualifier safety yet:
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=6912
> 
> But it should be a fairly easy fix to do.

Yeah, I think a simple fix will be enough here.

Re: Phobos examples and auto

[Manu]

On 5 November 2011 22:14, Andrei Alexandrescu  wrote:

> On 11/5/11 3:02 PM, bearophile wrote:
>
>> Andrei Alexandrescu:
>>
>>  If we avoid "auto" in documentation examples but we do use it in
>>> everyday code, we effectively foster a style that's foreign and
>>> non-idiomatic to newcomers.
>>>
>>> Sample code should mimic real code. If real code would use auto,
>>> sample code should use auto.
>>>
>>
>> D programmers are probably able to learn to use auto later, because
>> it's handy, it's an attractor. On the other hand one of the main
>> purposes of the online documentation is to be as clear as possible. D
>> written by newbies is not the same D written by D experts. But
>> documentation must be written for D newbies too, because they are
>> ones that have more need of documentation. The code written in the
>> thousands of examples in the very good Pascal/Delphi docs was written
>> in a clear style that is not the same compact style an expert Delphi
>> programmer writes code. So I'd like D docs to avoid auto when the
>> types are not very clear. The purpose of the docs is not to shows
>> examples of idiomatic D code written by experts.
>>
>
> Patronizing one's reader is a common trap.


There's nothing patronising about printing the types clearly.

As a D new comer myself, I DEFINITELY want to see the types associated with
function documentation in such examples. It re-enforces my memory, and also
informs me if I don't know without wasting my time looking it up.
It might even be nice if that doc also hyperlinked to the type and function
references themselves... save me more time looking this stuff up.

Re: Damn - again!

[Steven Schveighoffer]

On Wed, 09 Nov 2011 08:02:21 -0500, Trass3r  wrote:


Any recommendations for a different reader?


Opera :)


I use opera too.  And it has been somewhat valuable for finding old posts.

I set opera to download all headers, and now I have instant search through  
headers and messages I've viewed.  Makes it easy to find bugs and old  
messages.


-Steve

Re: Phobos examples and auto

[Simen Kjærås]

On Tue, 08 Nov 2011 17:53:06 +0100, Jonathan M Davis   
wrote:



On Tuesday, November 08, 2011 17:25:57 Marco Leise wrote:

After some hacking into the keyboard layout file, I now use the alias ℕ
(the mathematical symbol for the non-negative integral number)  
everywhere

instead of the ugly size_t. It is even shorter than 'auto'.

ℕ i = 5;
ℕ j = i;
ℕ k = j;
ℕ l = k;

;)


LOL. And no one but you will have any idea what your code is doing. It  
_is_
kind of cool to see unicode like that in D, but that's _really_ bad  
practice
if you intend anyone else to ever read your code. If it's just for you,  
then
you obviously can do whatever you want, but size_t is the correct name  
and

what others are going to expect if they ever read your code.


Also, ℕ would more correctly be a BigUInt, as it has no upper bound.

Re: Disallow arrays as pointers

[Don]

On 07.11.2011 10:45, Dejan Lekic wrote:

Don wrote:



It was a bug. And it's now been fixed.


Don, care to explain why? If I want to treat D's array like I would do in C,
why not allow me do so?


I had no involvement with it at all.

Although, when we originally banned implicit conversions from arrays to 
pointers, it was because it was _the_ most common bug in D code. 
Especially when you pass a char[] array to an extern(C) function that 
accepts a char *. It really was a disaster.


Just add .ptr if you want to convert it to a pointer. It's beautiful, 
really.

Re: assert(obj) is an atrocity

[Alex Rønne Petersen]

On 09-11-2011 12:48, Dejan Lekic wrote:

Alex, it is a well know bug, I remember it from... ~2006... It has been
reported as a bug ages ago... I/we totally agree with you.


Yep, I just figured I'd bring some attention to it again, as well as 
some arguments for why the way it is now is broken.


- Alex

Re: assert(obj) is an atrocity

[Alex Rønne Petersen]

On 09-11-2011 06:23, Davidson Corry wrote:

I don't get it -- why is this even necessary? Please don't answer here.
Swing over to D.learn, where I am starting an "assert(obj) is a mystery"
thread...

...because answers that start with "because..." belong in a "learn"
newsgroup.

Thanks in advance.

-- Davidson



On 11/8/2011 2:35 PM, Alex Rønne Petersen wrote:

Hi,

As the title suggests, I'm going to be rather blunt about this.
assert(obj) testing the invariant *without* doing a null check is insane
for the following reasons:

1) It is not what a user expects. It is *unintuitive*.
2) assert(!obj) does an is-null check. assert(obj) is a completely
broken opposite of this.
3) No AssertError is thrown, which is the entire point of the built-in
assert().
4) The few added instructions for the null check hardly matter in a
*debug* build of all things.

I don't mind assert(obj) testing the invariant of obj. In fact, that
very much makes sense. But please, please, *please* check the object for
null first. This is a random inconsistency in the language with no other
justification than "seg faults are convenient in a debugger". By the
same logic, we might as well not have array bounds checks. However, the
state of things is that array bounds checks are emitted by default and
users can disable them for e.g. a release build. I don't see why this
case is any different.

- Alex




This has nothing to do with learning. This entire thread is a language 
design counter-argument.


- Alex

Re: Version Identifiers for Platforms / Architectures not supported byDMD

[Alex Rønne Petersen]

On 09-11-2011 02:29, Daniel Murphy wrote:

There is always one backwards compatible solution:

We could make version identifiers case insensitive.


That's not backwards-compatible. What if someone out there is really 
using Foo and fOO for two different things? I know this sounds 
far-fetched, but the possibility is there.




It's a change from everywhere else in the language, but...

There is no 'correct' casing for os/architecture etc
windows vs Windows, linux vs Linux, x86 vs X86 are meaningless distinctions.


It's proper spelling of the titles of the architectures/OSs. I don't see 
how this is not correct.




Invalid identifiers are _silently_ accepted.
eg.
version(Linux) {}
Would anybody ever _actually_ mean Linux here?


Maybe... they could have:

version (linux) { version (Linux); }

to fix the inconsistency that is in place now. ;)



Because it works on a is/is not defined basis, this is one case where case
sensitivity harms usability.  You never get an error for messing up the
casing, unless you explicitly add a static assert in an else clause.


Very true. But you're supposed to do that anyway, as Walter pointed out 
in a post to the druntime mailing list, because it aids portability.




Does anybody really define both 'MyVersion' and 'myVersion' and expect them
to do different things?

I think the inconsistency and the small addition to the spec are worth it to
have the compiler silently and automatically do the right thing, and remove
the impact of some incredibly inconsistent and arbirtary casing choices.




In general, I agree, but this would be a breaking change no matter how 
you look at it. I'm not sure if that's a good idea.


- Alex

Re: Type Qualifiers and Wild Cards

[Don]

On 09.11.2011 00:57, bearophile wrote:

Walter:


The whole "too many keywords" issue strikes me as strange. English has over a
million words in it. Who cares if a language uses 80 or 100 of them? What
difference can it possibly make? How can an extra 20 words pollute the million
word namespace (and not including any non-word identifiers (like inout))?


I agree. This is also why I have suggested "auto_ref" instead of "auto ref", 
that I think is a bit confusing.


"auto ref" is something we should *really* get rid of. Because it isn't 
'auto'.


There should be a symmetry between:

auto --- const
auto ref --- const ref

But there isn't. The correct patten is:

auto --- const
ref  --- const ref
auto ref --- const auto ref

And note that auto const ref is not the same as const auto ref.

I'd be happy with auto_ref or autoref or pretty much any sequence of 
characters that doesn't contain " auto ".

Re: assert(obj) is an atrocity

[Alex Rønne Petersen]

On 09-11-2011 01:57, Martin Nowak wrote:

On Wed, 09 Nov 2011 01:21:47 +0100, Timon Gehr  wrote:


On 11/09/2011 01:18 AM, Martin Nowak wrote:

On Tue, 08 Nov 2011 23:35:33 +0100, Alex Rønne Petersen
 wrote:


Hi,

As the title suggests, I'm going to be rather blunt about this.
assert(obj) testing the invariant *without* doing a null check is
insane for the following reasons:

1) It is not what a user expects. It is *unintuitive*.
2) assert(!obj) does an is-null check. assert(obj) is a completely
broken opposite of this.
3) No AssertError is thrown, which is the entire point of the built-in
assert().
4) The few added instructions for the null check hardly matter in a
*debug* build of all things.

I don't mind assert(obj) testing the invariant of obj. In fact, that
very much makes sense. But please, please, *please* check the object
for null first. This is a random inconsistency in the language with no
other justification than "seg faults are convenient in a debugger". By
the same logic, we might as well not have array bounds checks.
However, the state of things is that array bounds checks are emitted
by default and users can disable them for e.g. a release build. I
don't see why this case is any different.

- Alex


It does check for null.
Only it's a runtime support function (_d_invariant) and druntime is
likely
compiled without assertions. Are you really suggesting to add a null
check before
every method call?

martin


No, he is suggesting to add a null check for assert(objref);, a
construct that *looks* as if it was a null check, but does something
almost unrelated.


Then just for reference, apply this patch to druntime and you'll get an
assertion instead.

diff --git a/src/rt/invariant.d b/src/rt/invariant.d
index 71337f1..bc5e53a 100644
--- a/src/rt/invariant.d
+++ b/src/rt/invariant.d
@@ -16,13 +16,16 @@
/**
*
*/
+import core.exception;
+
void _d_invariant(Object o)
{ ClassInfo c;

//printf("__d_invariant(%p)\n", o);

// BUG: needs to be filename/line of caller, not library routine
- assert(o !is null); // just do null check, not invariant check
+ if (o is null)
+ throw new AssertError("_d_invariant called with null reference.");

c = o.classinfo;
do


But as that BUG note states, it still isn't sufficient/consistent. :) 
Thanks for the patch though!


- Alex

Re: Type Qualifiers and Wild Cards

[Steven Schveighoffer]

On Tue, 08 Nov 2011 08:08:19 -0500, deadalnix  wrote:


Le 08/11/2011 02:08, Walter Bright a écrit :

http://drdobbs.com/blogs/cpp/231902461

Anyone want to do the reddit honors?


Great article. The only point I would raise is the choice of inout as a  
keyword for this.


This make no sens whatsoever. Here is why :
- inout did exist in D1 and is different.
- in and out qualifier already exists and have nothing to do with inout.
- in and out are used for contracts and have nothing to do with inout.
- the inout term has nothing to do with const/immutable/mutable. This is  
in a totally different lexical field.


The argument given to use inout is that it was a dead keyword (it's  
totally superseded by ref).


At the time of proposal, an argument against such a feature was that  
people didn't want to add any more keywords.  Reusing inout keyword was a  
way to cut the legs off that argument, although I would have preferred not  
to use inout.


It is kind of related, as in, the qualifier you pass in becomes the  
qualifier passed out.




Another keyword should be choosen. vconst, as suggested here :  
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP2 is way more  
appropriate.


On external details, but still important, I face the need of inout few  
days ago and did knew about it. The documentation on const/immutable (  
http://www.d-programming-language.org/const3.html ) doesn't mention it.  
The page on fucntion mention it, but it would be nice to have at least a  
link on the const/immutable page.


That documentation is not exactly documentation.  It's an article on  
const.  I agree it needs to be updated.


-Steve

Re: How about a 100% CTFE?

[Don]

On 09.11.2011 09:17, foobar wrote:

Don Wrote:


On 07.11.2011 14:13, Gor Gyolchanyan wrote:

After reading

  http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide
  https://github.com/gor-f-gyolchanyan/dmd/blob/master/src/interpret.c

I had a thought:
Why not compile and run CTFE code in a separate executable, write it's
output into a file, read that file and include it's contents into the
object file being compiled?
This would cover 100% of D in CTFE, including external function calls
and classes;
String mixins would simply repeat the process of compiling and running
an extra temporary executable.

This would open up immense opportunities for such things as
library-based build systems and tons of unprecedented stuff, that I
can't imagine ATM.


First comment: classes and exceptions now work in dmd git. The remaining
limitations on CTFE are intentional.

With what you propose:
Cross compilation is a _big_ problem. It is not always true that the
source CPU is the same as the target CPU. The most trivial example,
which applies already for DMD 64bit, is size_t.sizeof. Conditional
compilation can magnify these differences. Different CPUs don't just
need different backend code generation; they may be quite different in
the semantic pass. I'm not sure that this is solvable.

version(ARM)
{
 immutable X = armSpecificCode(); // you want to run this on an X86???
}



I think we discussed those issues before.
1. size_t.sizeof:
auto a = mixin("size_t.sizeof"); // HOST CPU
auto a = size_t.sizeof; // TARGET CPU


That doesn't work. mixin happens _before_ CTFE. CTFE never does any 
semantics whatsoever.




2. version (ARM) example - this needs clarification of the semantics. Two 
possible options are:
a. immutable X = ... will be performed on TARGET as is the case today. require 
'mixin' to call it on HOST. This should be backwards compatible since we keep 
the current CTFE and add support for multi-level compilation.
b. immutable x = ... is run via the new system which requires the function 
"armSpecificCode" to be compiled ahead of time and provided to the compiler in 
an object form. No Platform incompatibility is possible.

I don't see any problems with cross-compilation. It is a perfectly sound design 
(Universal Turing machine) and it was successfully implemented several times 
before: Lisp, scheme, Nemerle, etc.. It just requires to be a bit careful with 
the semantic definitions.


AFAIK all these languages target a virtual machine.

Re: Damn - again!

[Trass3r]

Any recommendations for a different reader?


Opera :)

Re: Type Qualifiers and Wild Cards

[Steven Schveighoffer]

On Tue, 08 Nov 2011 18:57:19 -0500, Martin Nowak  wrote:

On Wed, 09 Nov 2011 00:01:09 +0100, Walter Bright  
 wrote:



On 11/8/2011 11:10 AM, Martin Nowak wrote:
I personally find it much more astonishing that inout methods finally  
work.

I literally meant methods as in member functions.
Being able to use inout as method qualifier is way more
important than achieving the same for free functions as it
makes transitive qualifiers almost hassle free in simple cases.


To give a bit of trivia, the main motivator for proposing what is now  
inout was trying to port Tango to D2.  In doing this, I realized that in  
order to be const-correct, I was going to have to triplicate all property  
accessors on classes (and Tango uses classes + properties much more than  
Phobos does).  The prospect of having three *identical* copies of the same  
function just so I could have something as simple as an accessor was  
reason enough to find a better solution before moving forward on Tango for  
D2.


In other words, the astonishment was intentional :)

BTW, I want to publicly thank Kenji Hara for his work on making inout a  
reality.  He created the patch that solved all the remaining inout  
problems, then quickly fixed most of the remaining bugs found with his  
patch before this last release.  Without his work, inout would still be a  
pipe-dream!


-Steve

Re: Type Qualifiers and Wild Cards

[Steven Schveighoffer]

On Tue, 08 Nov 2011 03:16:30 -0500, Timon Gehr  wrote:


On 11/08/2011 02:08 AM, Walter Bright wrote:

http://drdobbs.com/blogs/cpp/231902461

Anyone want to do the reddit honors?


Nice article!


 > It isn't a template, and inout can only be used on function  
parameters and the return value.


What about local variables?


Yes.  Local variables cease to exist beyond the scope of the function, so  
they are allowed.  the main principal of inout is that it only exists as  
inout during the scope of the function, then goes back to its original  
const flavor (const/immutable/mutable).  In fact, my original proposal  
called inout "scoped const".


-Steve

Re: Damn - again!

[Jacob Carlborg]

On 2011-11-09 12:39, Dejan Lekic wrote:

Steve Teale wrote:



Any recommendations for a different reader?

Steve


Steve, a good alternative is what I use at the moment - KNode. Thunderbird
is also a good choice for a newsgroups reader. I think Pan is okay as well.


I'm using Thunderbird. I've symlinked the News directory to dropbox to 
have it automatically synced.


--
/Jacob Carlborg

Re: assert(obj) is an atrocity

[Dejan Lekic]

Alex, it is a well know bug, I remember it from... ~2006... It has been 
reported as a bug ages ago... I/we totally agree with you.

Re: Damn - again!

[Dejan Lekic]

Steve Teale wrote:

> 
> Any recommendations for a different reader?
> 
> Steve

Steve, a good alternative is what I use at the moment - KNode. Thunderbird 
is also a good choice for a newsgroups reader. I think Pan is okay as well.

Re: Damn - again!

[Jonathan M Davis]

On Wednesday, November 09, 2011 14:47:47 Gor Gyolchanyan wrote:
> I've signed up for puremagic.D using my gmail acoount and i made a
> filder in gmail to add the "D" tag on emails, that come from
> puremagic.D.
> The discussion threads are stored as conversations (a neat feature of
> gmail) and are tagged with a red "D" label, making them very easy to
> work with.

Though gmail has a nasty habit of not sending your own messages to you (the 
ones that you send to the list), so it tends to screw up the threading. And 
since gmail's threads are linear, they don't handle the mesage hierarchy very 
well. I've always used a client on my machine which _is_ able to handle all of 
the threading correctly (or at least far better than gmail). And while I used 
to use gmail for the e-mail address (even if I didn't use it for reading any 
e-mail), I stopped due to issues like it not sending my own e-mails to me. I 
switched to gmx.com, which isn't quite a stable, but feature-wise it's much 
better IMHO.

Regardless, having an IMAP account and using the mailing list can work quite 
well - especially if you're trying to access the newsgroup on multiple 
computers and therefore have to worry about syncing between them.

- Jonathan M Davis

Re: Damn - again!

[Manu]

On 9 November 2011 12:47, Gor Gyolchanyan wrote:

> I've signed up for puremagic.D using my gmail acoount and i made a
> filder in gmail to add the "D" tag on emails, that come from
> puremagic.D.
> The discussion threads are stored as conversations (a neat feature of
> gmail) and are tagged with a red "D" label, making them very easy to
> work with.


Ditto.. win!

Re: Damn - again!

[Gor Gyolchanyan]

I've signed up for puremagic.D using my gmail acoount and i made a
filder in gmail to add the "D" tag on emails, that come from
puremagic.D.
The discussion threads are stored as conversations (a neat feature of
gmail) and are tagged with a red "D" label, making them very easy to
work with.

On Wed, Nov 9, 2011 at 2:36 PM, Jonathan M Davis  wrote:
> On Wednesday, November 09, 2011 05:25:55 Steve Teale wrote:
>> I use the Pan newsreader. In the mornings when I'm looking at
>> digitalmars.D I regularly make the mistake of editing the panel that
>> displays the individual posts.
>>
>> I'll mark some of the older text and hit delete. At that point you are
>> hosed. The article disappears, and there's no obvious way to get it back.
>>
>> Any recommendations for a different reader?
>
> IPersonally, I sign up for the mailing list and use that instead of the
> newsgroup. That way, I can use my e-mail client to read everything, and the
> state is synced between machines (since I use IMAP).
>
> - Jonathan M Davis
>

Re: How about a 100% CTFE?

[Gor Gyolchanyan]

I knew I'm not crazy :-)
I knew there would be at least somebody, who will see what I meant :-)

On Wed, Nov 9, 2011 at 12:17 PM, foobar  wrote:
> Don Wrote:
>
>> On 07.11.2011 14:13, Gor Gyolchanyan wrote:
>> > After reading
>> >
>> >      http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide
>> >      https://github.com/gor-f-gyolchanyan/dmd/blob/master/src/interpret.c
>> >
>> > I had a thought:
>> > Why not compile and run CTFE code in a separate executable, write it's
>> > output into a file, read that file and include it's contents into the
>> > object file being compiled?
>> > This would cover 100% of D in CTFE, including external function calls
>> > and classes;
>> > String mixins would simply repeat the process of compiling and running
>> > an extra temporary executable.
>> >
>> > This would open up immense opportunities for such things as
>> > library-based build systems and tons of unprecedented stuff, that I
>> > can't imagine ATM.
>>
>> First comment: classes and exceptions now work in dmd git. The remaining
>> limitations on CTFE are intentional.
>>
>> With what you propose:
>> Cross compilation is a _big_ problem. It is not always true that the
>> source CPU is the same as the target CPU. The most trivial example,
>> which applies already for DMD 64bit, is size_t.sizeof. Conditional
>> compilation can magnify these differences. Different CPUs don't just
>> need different backend code generation; they may be quite different in
>> the semantic pass. I'm not sure that this is solvable.
>>
>> version(ARM)
>> {
>>     immutable X = armSpecificCode(); // you want to run this on an X86???
>> }
>>
>
> I think we discussed those issues before.
> 1. size_t.sizeof:
> auto a = mixin("size_t.sizeof"); // HOST CPU
> auto a = size_t.sizeof; // TARGET CPU
>
> 2. version (ARM) example - this needs clarification of the semantics. Two 
> possible options are:
> a. immutable X = ... will be performed on TARGET as is the case today. 
> require 'mixin' to call it on HOST. This should be backwards compatible since 
> we keep the current CTFE and add support for multi-level compilation.
> b. immutable x = ... is run via the new system which requires the function 
> "armSpecificCode" to be compiled ahead of time and provided to the compiler 
> in an object form. No Platform incompatibility is possible.
>
> I don't see any problems with cross-compilation. It is a perfectly sound 
> design (Universal Turing machine) and it was successfully implemented several 
> times before: Lisp, scheme, Nemerle, etc.. It just requires to be a bit 
> careful with the semantic definitions.
>

Re: Global immutable AA literals

[Gor Gyolchanyan]

I think this is a bug and i even recall seeing it in bugzilla, but i
don't have a link to it.

On Wed, Nov 9, 2011 at 10:43 AM, bearophile  wrote:
> Is it possible to modify DMD to allow a program like:
>
>
> immutable int[int] aa = [1:15, 2: 7];
> void main() {}
>
>
> With the latest DMD it gives:
> test.d(1): Error: non-constant expression [1:15,2:7]
>
> Global immutable associative arrays are handy in script-like programs, I use 
> them now and then in Python (despite they are not immutable).
> This is a workaround for script-like programs, that I sometimes use:
>
>
> immutable int[int] aa;
> static this() {
>    aa = [1:15, 2: 7];
> }
> void main() {}
>
>
> But when possible I try to avoid using static this.
>
> Bye,
> bearophile
>

Re: Damn - again!

[Jonathan M Davis]

On Wednesday, November 09, 2011 05:25:55 Steve Teale wrote:
> I use the Pan newsreader. In the mornings when I'm looking at
> digitalmars.D I regularly make the mistake of editing the panel that
> displays the individual posts.
> 
> I'll mark some of the older text and hit delete. At that point you are
> hosed. The article disappears, and there's no obvious way to get it back.
> 
> Any recommendations for a different reader?

IPersonally, I sign up for the mailing list and use that instead of the 
newsgroup. That way, I can use my e-mail client to read everything, and the 
state is synced between machines (since I use IMAP).

- Jonathan M Davis

Re: How about a 100% CTFE?

[foobar]

Don Wrote:

> On 07.11.2011 14:13, Gor Gyolchanyan wrote:
> > After reading
> >
> >  http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide
> >  https://github.com/gor-f-gyolchanyan/dmd/blob/master/src/interpret.c
> >
> > I had a thought:
> > Why not compile and run CTFE code in a separate executable, write it's
> > output into a file, read that file and include it's contents into the
> > object file being compiled?
> > This would cover 100% of D in CTFE, including external function calls
> > and classes;
> > String mixins would simply repeat the process of compiling and running
> > an extra temporary executable.
> >
> > This would open up immense opportunities for such things as
> > library-based build systems and tons of unprecedented stuff, that I
> > can't imagine ATM.
> 
> First comment: classes and exceptions now work in dmd git. The remaining 
> limitations on CTFE are intentional.
> 
> With what you propose:
> Cross compilation is a _big_ problem. It is not always true that the 
> source CPU is the same as the target CPU. The most trivial example, 
> which applies already for DMD 64bit, is size_t.sizeof. Conditional 
> compilation can magnify these differences. Different CPUs don't just 
> need different backend code generation; they may be quite different in 
> the semantic pass. I'm not sure that this is solvable.
> 
> version(ARM)
> {
> immutable X = armSpecificCode(); // you want to run this on an X86???
> }
> 

I think we discussed those issues before. 
1. size_t.sizeof: 
auto a = mixin("size_t.sizeof"); // HOST CPU
auto a = size_t.sizeof; // TARGET CPU

2. version (ARM) example - this needs clarification of the semantics. Two 
possible options are:
a. immutable X = ... will be performed on TARGET as is the case today. require 
'mixin' to call it on HOST. This should be backwards compatible since we keep 
the current CTFE and add support for multi-level compilation.
b. immutable x = ... is run via the new system which requires the function 
"armSpecificCode" to be compiled ahead of time and provided to the compiler in 
an object form. No Platform incompatibility is possible. 

I don't see any problems with cross-compilation. It is a perfectly sound design 
(Universal Turing machine) and it was successfully implemented several times 
before: Lisp, scheme, Nemerle, etc.. It just requires to be a bit careful with 
the semantic definitions. 

bug in std.array.insertInPlace ?

[Ruslan Mullakhmetov]

Hi,

 I found some strange behavior of std.array.insertInPlace leading to segfault.

 The example below works for int, it is failed for reference type with 
array becoming of length bigger 1024 on windows (x64) and 512 on linux 
(x64).


 code: http://cloud.theambient.org/0O360r1d2t1g09171F1m

 Is it my bug or compiler?
--
BR, Ruslan Mullakhmetov