Re: binary downloads from github

[Suliman]

On Saturday, 24 August 2013 at 03:33:18 UTC, Walter Bright wrote:

I just ran across this:

https://github.com/blog/1547-release-your-software

Should we be using that for dmd binaries?


I think very soon it's would become standard distribution system 
for many of different opensource apps. So the short answer is YES.

Re: Parallel Rogue-like benchmark

[Walter Bright]

On 8/23/2013 10:23 PM, H. S. Teoh wrote:

Like I said, you can still game it. I think some common sense
applies, not a literal interpretation.

You conveniently snipped the rest of my post, which postulates a far
better metric that's no harder to apply in practice. :)


You can't compress by visually looking at the code, and LOC is a unit that 
people fairly intuitively understand.




All it takes is for you to run zip instead of wc -l, and you have a far
better metric for measuring language expressiveness. Insisting on using
LOC despite this just makes one lose one's credibility.


LOC ain't that far off, if you use it with some common sense rather than literal 
dogma.

Re: D-thrift package detects regressions since 2.061, where is the regression suite located?

[Joseph Rushton Wakeling]

On 23/08/13 20:38, H. S. Teoh wrote:

One idea that occurred to me is to put large external projects under a
separate tester, not bound to the core dmd/druntime/phobos autotesting,
but an independent tester that regularly checks out git HEAD and
compiles & tests said large projects.


I proposed something along these lines shortly after DConf:
http://forum.dlang.org/thread/mailman.47.1369319426.13711.digitalmar...@puremagic.com

I thought it could be useful both as a stability tester _and_ as a means to 
evaluate the prospective impact of deliberately breaking changes.


It was quite well received as an idea but is probably a big job to take on ... 
:-(

Re: DIP44: scope(class) and scope(struct)

[Simen Kjaeraas]

On Sat, 24 Aug 2013 03:34:32 +0200, Ramon  wrote:

What, for instance, if I aquire 10 resources in ctor and during normal  
programm execution cleanup 7 of them, so only some are left for dtor?


Then they don't have the same lifetime as the object, and scope(this)
would be the wrong tool for the job.

--
Simen

Re: binary downloads from github

[Rikki Cattermole]

On Saturday, 24 August 2013 at 03:33:18 UTC, Walter Bright wrote:

I just ran across this:

https://github.com/blog/1547-release-your-software

Should we be using that for dmd binaries?


Just a thought but github does provide pages and cdn backing them.
We could move e.g. our documentation as well as downloads there 
to save cost and increase download speed.

Re: DLang FastCGI and Web Programming

[Jason den Dulk]

On Friday, 23 August 2013 at 15:07:06 UTC, netwalker wrote:
How do you d want to use fastcgi with the easiest and simplest 
way


You may want to consider something I have written.

It is a fairly thin wrapper around fcgiapp to provide a more D 
friendly interface.


It provides an input range to access the input stream, output 
ranges to access the output/error streams, and converts the 
environment variables to a string[string] array.


It loops through the requests, creating a new thread for each 
one, which passes the request to a function that you provide.


And that's it.

It has not been completely put through the wringer, so consider 
it beta, but I have successfuly used it.


You can get it at

http://jaypha.com.au/fcgi.zip

I don't have a github account as yet, but I will get one if 
people like my code enough.

Re: DLang FastCGI and Web Programming

[Jason den Dulk]

http://jaypha.com.au/fcgi.zip




Of course you will need to have the Open Market fcgi library and 
link to it.



It is available here

http://www.fastcgi.com/dist/fcgi.tar.gz

or in most Linux repositories.

Re: std.logger

[Robert Schadek]

On 08/23/2013 11:49 PM, Andrei Alexandrescu wrote:
> On 8/23/13 1:10 PM, Robert Schadek wrote:
>> On 08/23/2013 09:41 PM, Andrei Alexandrescu wrote:
>>> (Just hanging this to a random comment in this thread.) I think
>>> there's some pretty good work on logging by myself and another poster
>>> (Jose?) that has since gone abandoned. It included some nice approach
>>> to conditional logging and had both compile-time and run-time
>>> configurability
>>
>> Yes I know, but as you said, it got abandoned. So something must have
>> been wrong.
>> I rather start something fresh and argue about whats wrong with that,
>> than argue
>> whats wrong with something old that has been already argued about and
>> got abandoned.
>>
>
> Great. There was nothing wrong with it except it got no more work. I'd
> expect a new framework to be at least as good if not better.
>
> Andrei
>
Of course, it has to be phobos worthy.

Re: DIP44: scope(class) and scope(struct)

[Artur Skawina]

On 08/24/13 08:30, Piotr Szturmaj wrote:
> H. S. Teoh wrote:
>> I've written up a proposal to solve the partially-constructed object
>> problem[*] in D in a very nice way by extending scope guards:
>>
>> http://wiki.dlang.org/DIP44

> 2. allow referring to local variables and create the closure. This causes 
> additional memory allocation and also reference to the closure must be stored 
> somewhere, perhaps in the class hidden field. Of course, this is a "no go", 
> I'm writing this here for comparison.

That is what he's actually proposing. And, yes, it's not a good idea.
Implementing it via runtime delegates, implicit captures/allocs and 
extra hidden fields inside aggregates would work, but the cost is too
high. It's also not much of an improvement over manually registering
and calling the delegates. Defining what happens when a ctor fails
would be a good idea, having a cleanup method which defaults to `~this`,
but can be overridden could help too.

There are other problems with that DIP, like making it harder to see
what's actually going on, by splitting the dtor code and having it
interleaved with another separate flow.


It *is* possible to implement a similar solution without any RT cost,
but it would need:
a) flow analysis - to figure out the cleanup order, which might not be 
statically known (these cases have to be disallowed)
b) a different approach for specifying the cleanup code, so that 
implicit capturing of ctor state doesn't happen and it's not
necessary to read the complete body of every ctor just to find
out what a dtor does.


artur

Re: DIP44: scope(class) and scope(struct)

[deadalnix]

On Saturday, 24 August 2013 at 00:45:46 UTC, H. S. Teoh wrote:
I've written up a proposal to solve the partially-constructed 
object

problem[*] in D in a very nice way by extending scope guards:

http://wiki.dlang.org/DIP44

[*] The partially-constructed object problem is when you have a 
class
(or struct) that must acquire some number of external 
resources, usually
to set them as member fields, but before the ctor is able to 
initialize
all of these fields, an Exception is thrown. Now the object is 
in a
partially-constructed state: some member fields have been 
initialized,
and need to be destructed in order to release the associated 
external
resources, but other fields are still uninitialized so should 
not be
destructed. This leads to the problem of, how do we clean up in 
this
situation? We can't call the dtor -- the dtor assumes *all* 
fields have
been set and will wrongly try to release resources that haven't 
been
acquired yet. But we can't ignore the issue either -- the 
resources that
*have* been required need to be released somehow. This DIP 
proposes a
nice solution to this problem that fits in very well with the 
existing

scope guards in D.

Destroy! ;-)


T


I like the feature. I wouldn't say this is the most important 
thing to add here, the same can be achieved with scope(failure) 
and destructor.

Re: binary downloads from github

[David Nadlinger]

On Saturday, 24 August 2013 at 09:45:02 UTC, Rikki Cattermole 
wrote:
Just a thought but github does provide pages and cdn backing 
them.
We could move e.g. our documentation as well as downloads there 
to save cost and increase download speed.


The GitHub TOS don't allow hosting large binaries in repositories 
(which one would have to do in order to use Pages).


David

Re: binary downloads from github

[Rikki Cattermole]

On Saturday, 24 August 2013 at 12:06:01 UTC, David Nadlinger 
wrote:
On Saturday, 24 August 2013 at 09:45:02 UTC, Rikki Cattermole 
wrote:
Just a thought but github does provide pages and cdn backing 
them.
We could move e.g. our documentation as well as downloads 
there to save cost and increase download speed.


The GitHub TOS don't allow hosting large binaries in 
repositories (which one would have to do in order to use Pages).


David


I was thinking static web pages only. But ok damn. There goes 
that idea.

Re: DIP44: scope(class) and scope(struct)

[Ramon]

On Saturday, 24 August 2013 at 08:34:10 UTC, Simen Kjaeraas wrote:
On Sat, 24 Aug 2013 03:34:32 +0200, Ramon  
wrote:


What, for instance, if I aquire 10 resources in ctor and 
during normal programm execution cleanup 7 of them, so only 
some are left for dtor?


Then they don't have the same lifetime as the object, and 
scope(this)

would be the wrong tool for the job.


Understood. But there *are* objects with different lifetimes. If, 
for instance, I aquire some "nice" objects (GC'd, properly 
through D) - and - some "dirty" malloced stuff (not talking about 
externals).


Thinking about it I also dislike a special thing that also feels 
and shows a special thing (namely "this" rather than e.g. 
"failure").


"Holy rule": No special cases if any possible but everything in a 
consistent way. If there are special cases, somehow make them not 
look like it; try to make them look consistent. The scope 
mechanism deals with success, with failure and with exit. That's 
great, that's sufficient. That's how it should at least *look* 
like in ctors, too.


Another inconsistency: If this mechanism is to "guard" on class 
level, it should be there, at class level and not in a function 
like entity (albeit the rather special "function" this).


Maybe I'm overly shy but I feel that logical consistency is a 
major issue to be a good language and for safety, too.

Re: DIP44: scope(class) and scope(struct)

[Tobias Pankrath]

On Saturday, 24 August 2013 at 00:45:46 UTC, H. S. Teoh wrote:
I've written up a proposal to solve the partially-constructed 
object

problem[*] in D in a very nice way by extending scope guards:


[snip]

What about a language rule, that for every type T destroy(t) must 
be valid if t == T.init?


Couldn't this problem be solved by using RAII and destructors? 
You would (only) need to make sure that every member is either 
correctly initialised or T.init.

Re: std.serialization: pre-voting review / discussion

[ilya-stromberg]

On Friday, 23 August 2013 at 20:28:10 UTC, Jacob Carlborg wrote:

On 2013-08-22 21:30, ilya-stromberg wrote:


What about more difficult cases?


Actually, my previous answer was not entirely correct. By 
default it will throw an exception. But you can implement the 
above using custom serialization (here using Orange) :


Great job!
A little question. For example, I would like to load data from 
previos format and store current version in default 
std.serialization format. So, I don't want to implement "toData" 
at all? Is it possible? Or can I call the default serialization 
method? Something like this:


class Foo : Serializable
{
long b;

//I don't want to implement this
void toData (Serializer serializer, Serializer.Data key)
{
serializer.serialize(this);
}

void fromData (Serializer serializer, Serializer.Data key)
{
b = serializer.deserialize!(int)("b");
}
}

Also, please add this examlpe to the documentation, it could be 
useful for many users.


Note that we can split Serializable interface for 2 interfaces:

interface ToSerializable
{
void toData(Serializer serializer, Serializer.Data key);
}

interface FromSerializable
{
void fromData(Serializer serializer, Serializer.Data key);
}

interface Serializable : ToSerializable, FromSerializable
{
}

class Foo : FromSerializable
{
long b;

void fromData (Serializer serializer, Serializer.Data key)
{
b = serializer.deserialize!(int)("b");
}

//I must NOT to implement toData
}

Re: DIP44: scope(class) and scope(struct)

[Joseph Rushton Wakeling]

On 24/08/13 02:44, H. S. Teoh wrote:

I've written up a proposal to solve the partially-constructed object
problem[*] in D in a very nice way by extending scope guards


Converse problem: suppose that you need certain resources to be _created_ in 
order for the struct to work correctly.  Consider:


struct Foo
{
Resource res;

this(int n)
{
res = getResource(n);
}
}

void main()
{
auto foo1 = Foo(10);  // Good! Resource is initialized
Foo foo2;   // Bad! Resource is uninitialized
}

... where we can probably reasonably assume that getResource is doing some kind 
of allocation.


Is there any way to handle this needed-at-entry-to-scope requirement, in a 
similar way to how your DIP handles exit of scope?

Re: DLang FastCGI and Web Programming

[Adam D. Ruppe]

On Friday, 23 August 2013 at 15:07:06 UTC, netwalker wrote:
cumbersome multi-stack library is a library to communicate with 
fastcgi


As far as I know, there are no D fastcgi libraries that don't use 
the C fcgilib.


There are standalone D libraries for scgi and http though.

Re: DIP44: scope(class) and scope(struct)

[Tobias Pankrath]

On Saturday, 24 August 2013 at 13:34:06 UTC, Joseph Rushton 
Wakeling wrote:

On 24/08/13 02:44, H. S. Teoh wrote:
I've written up a proposal to solve the partially-constructed 
object

problem[*] in D in a very nice way by extending scope guards


Is there any way to handle this needed-at-entry-to-scope 
requirement, in a similar way to how your DIP handles exit of 
scope?


Invariants?

Re: DIP44: scope(class) and scope(struct)

[Joseph Rushton Wakeling]

On 24/08/13 15:55, Tobias Pankrath wrote:

Invariants?


Don't they get stripped out in -release code?

Re: std.logger

[SomeDude]

On Thursday, 22 August 2013 at 22:01:09 UTC, Jonathan M Davis 
wrote:

On Thursday, August 22, 2013 23:36:48 David Nadlinger wrote:

On Thursday, 22 August 2013 at 15:51:53 UTC, Craig Dillabaugh

wrote:
> Do you really find the three extra characters a big problem.

They are unnecessary. If you want to make clear you are dealing
with logging, you can just write something along the lines of:

import log = std.logger;
log.error("123");


I'd oppose warning, critical, error, etc. because they're not 
verbs like
functions are supposed to be. It's variables or properties 
which are nouns.
So, while I agree that the module system makes it so that the 
name clashes
shouldn't be a big deal, I disagree with the names anyway and 
would still

prefer logWarning to warning.

- Jonathan M Davis


OTOH, they are used in just about every logging API ever devised. 
Everybody knows what they mean. I just don't see the need to 
reinvent these words and make them longer by adding log. I 
seriously hate it.


It clutters code (once you've read your thousand's log 
instruction, it hurts), adds ugly and useless redundancy and 
nothing else to its understanding. This alone is far worse than 
not using verbs.

Re: DIP44: scope(class) and scope(struct)

[Tobias Pankrath]

On Saturday, 24 August 2013 at 14:40:36 UTC, Joseph Rushton 
Wakeling wrote:

On 24/08/13 15:55, Tobias Pankrath wrote:

Invariants?


Don't they get stripped out in -release code?


Yes. But the example code that you presented looked to me like 
logic/coding errors. Invariants should be good enough here. If 
you want to pay for the added safety, because you think your code 
isn't tested well enough at all, you can always compile without 
debug.

Re: Parallel Rogue-like benchmark

[Joseph Rushton Wakeling]

On 24/08/13 06:58, H. S. Teoh wrote:

In none of the above examples did I try to deliberately game with the
metric. But the metric is still pretty inaccurate, and requires
subjective judgment calls.


It's a heuristic, rather than a metric, I'd say.  But as a heuristic it may be 
useful to compare things like


(i) what's the minimal number of lines needed (not artificially compressing
them!) to write the algorithm idiomatically?

   (ii) how many more (or less) lines do you need to optimize the code for
performance?

  (iii) how many more lines do you need to parallelize the code effectively and
safely?

By the way, for your example:


auto formatYear(int year, int monthsPerRow)
{
enum colSpacing = 1;
return
datesInYear(year)
.byMonth()
.chunks(monthsPerRow)
.map!(r =>
r.formatMonths()
 .array()
 .pasteBlocks(colSpacing)
 .join("\n"))
.join("\n\n");
}


Although obviously there are only 3 _logical_ lines there (the function 
declaration, the enum, and the return statement), here I'd be inclined to say 
the number of _significant_ lines is 12 (I'm ignoring the braces).  The fact 
that you needed to spread the expression out across multiple lines in order to 
be readable does carry useful information about the language, IMO.


That doesn't necessarily say the language is _bad_.  It's difficult to see how a 
language could reduce the space needed for that expression without also reducing 
comprehensibility.

Re: Parallel Rogue-like benchmark

[H. S. Teoh]

On Sat, Aug 24, 2013 at 12:13:06AM -0700, Walter Bright wrote:
> On 8/23/2013 10:23 PM, H. S. Teoh wrote:
> >>Like I said, you can still game it. I think some common sense
> >>applies, not a literal interpretation.
> >You conveniently snipped the rest of my post, which postulates a far
> >better metric that's no harder to apply in practice. :)
> 
> You can't compress by visually looking at the code, and LOC is a
> unit that people fairly intuitively understand.
[...]

What's so difficult about running zip on the code?

The fault of LOC is precisely that people "fairly intuitively"
understand it. The problem is that no two people's intuitions ever
match.  So any conclusions drawn from LOC must necessarily be
subjective, and really not that much better than saying "I feel like
language A is better than language B, because I just like it better, and
besides, it has a nicer color (aka better LOC or whatever other
subjective metric)."

Which is fine, if that's what you're looking for. But let's not pretend
it has anything to do with the objective quality of a language.


T

-- 
Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry

Re: DIP44: scope(class) and scope(struct)

[Simen Kjaeraas]

On Sat, 24 Aug 2013 15:55:52 +0200, Tobias Pankrath   
wrote:


On Saturday, 24 August 2013 at 13:34:06 UTC, Joseph Rushton Wakeling  
wrote:

On 24/08/13 02:44, H. S. Teoh wrote:

I've written up a proposal to solve the partially-constructed object
problem[*] in D in a very nice way by extending scope guards


Is there any way to handle this needed-at-entry-to-scope requirement,  
in a similar way to how your DIP handles exit of scope?


Invariants?


I would also like to mention @disable this();

--
Simen

Re: DIP44: scope(class) and scope(struct)

[Joseph Rushton Wakeling]

On 24/08/13 18:21, Simen Kjaeraas wrote:

I would also like to mention @disable this();


Yes, I know, but suppose that I don't _want_ to disable this() ... ?

Really this is one of those cases where a parameter-free constructor would be 
useful.

Re: Parallel Rogue-like benchmark

[Ramon]

I think that there is a lot speaking against sloc.

First it's often (ab?)used for "Ha! My language x is better than 
yours. I can write a web server in 3 lines, you need 30".
And then slocs say a lot of things about a lot of things. Like: 
Experience (being new or not used to X I'll need more lines in X 
than in "my" lang, say, D), built in vs. library, coding style, 
and others.


In the end "100 sloc in X vs. 180 sloc in Y" quite often means 
close to nothing. Putting it bluntly: If I know enough about all 
the relevant details of the languages+environment to arrive at 
having sloc mean anything useful, I won't need that comparison in 
the first place.

Re: DIP44: scope(class) and scope(struct)

[Ramon]

I'd seriously *hate* to abuse invariants for that. The job of 
invariants is to give guarantees about state - not to manage e.g. 
allocations, creations, cleanups, etc.


"Has something properly succeeded and if not is there cleanup 
needed?" is the job of scope and possibly (but ugly and 
non-elegantly) exceptions.

Re: ARM targetting cross-toolchain with GDC

[ilya-stromberg]

On Thursday, 22 August 2013 at 15:15:37 UTC, Johannes Pfau wrote:

Am Tue, 06 Aug 2013 23:28:51 +0200
schrieb "Timofei Bolshakov" :

I was trying to compile the latest version of GDC for ARM and 
meet multiple problems with static asserts. Do you know if ARM 
fixes exists?


Sorry for the late answer. I'm currently working on ARM
support but it'll take a little bit longer than I first thought.


Do you have any plans for Android support?

Re: Parallel Rogue-like benchmark

[Jesse Phillips]

On Saturday, 24 August 2013 at 16:19:07 UTC, H. S. Teoh wrote:

The fault of LOC is precisely that people "fairly intuitively"
understand it. The problem is that no two people's intuitions 
ever

match.  So any conclusions drawn from LOC must necessarily be
subjective, and really not that much better than saying "I feel 
like
language A is better than language B, because I just like it 
better, and

besides, it has a nicer color (aka better LOC or whatever other
subjective metric)."


That sounds to be the exactly what we wish to capture.

Which is fine, if that's what you're looking for. But let's not 
pretend

it has anything to do with the objective quality of a language.


See above. What use is an objective measure when peoples taste 
for a language is subjective?

Re: DIP44: scope(class) and scope(struct)

[Dmitry Olshansky]

24-Aug-2013 04:44, H. S. Teoh пишет:

I've written up a proposal to solve the partially-constructed object
problem[*] in D in a very nice way by extending scope guards:

http://wiki.dlang.org/DIP44




Destroy! ;-)



Instead of introducing extra mess into an already tricky ctor/dtor 
situation. (Just peek at past issues with dtors not being called, being 
called at wrong time, etc.)


I'd say just go RAII in bits and pieces. Unlike scope, there it works 
just fine as it has the right kind of lifetime from the get go. In 
function scope (where scope(exit/success/failure) shines) RAII actually 
sucks as it may prolong the object lifetime I you are not careful to 
tightly wrap it into { }.


Start with this:

class C {
Resource1 res1;
Resource2 res2;
Resource3 res3;

this() {
res1 = acquireResource!1();
res2 = acquireResource!2();
res3 = acquireResource!3();
}

~this() {
res3.release();
res2.release();
res1.release();
}
}

Write a helper once:

struct Handler(alias acquire, alias release)
{
alias Resource = typeof(acquire());
Resource resource;
this(int dummy) //OMG when 0-argument ctor becomes usable?
{
resource = acquire();
}

static auto acquire()
{
return Handler(0); //ditto
}

~this()
{
release(resource);
}
alias this resource;
}


Then:

class C{
Handler!(acquireResource!1, (r){ r.release(); }) res1;
Handler!(acquireResource!2, (r){ r.release(); }) res2;
Handler!(acquireResource!3, (r){ r.release(); }) res3;
this(){
res1 = typeof(res1).acquire();
res2 = typeof(res2).acquire();
res3 = typeof(res3).acquire();
}
}

There are many more alternatives on how to auto-generate RAII helpers. 
The point is we can easily do so, after all our compile-time kung-fu is 
strong.


--
Dmitry Olshansky

codeblocks - simple newbie tip/correction

[Ramon]

While rdmd is extremey handy, newcomers might often want to start 
simple and easy for the beginning. Looking in the D wiki, there 
is quite a lot listed under IDE and Editors and Code:Blocks might 
actually be one of the more attractive beginners solutions.


Unfortunately the documentation (mainly on the code:blocks side) 
isn't reliable and/or correct and I feel that we should make it 
as easy and painfree as possible for newcomers to like and 
getting to try/work with D.


I'm now sitting in front of a working installation on a current 
Debian/Ubuntu/Mint (which might be pretty often encountered) and 
could provide/share a short howto for that scenario leading to a 
properly working codeblocks for D.


A) is that welcome/wanted?
B) if so, what's the right place for such a howto?
C) (for the future) is the forum the right place to introduce/ask 
about such stuff? If not, apologies for my misuse and: what's the 
right place and procedure?


Thanks - R

Re: std.serialization: pre-voting review / discussion

[Jacob Carlborg]

On 2013-08-24 14:45, ilya-stromberg wrote:


Great job!
A little question. For example, I would like to load data from previos
format and store current version in default std.serialization format.
So, I don't want to implement "toData" at all? Is it possible? Or can I
call the default serialization method? Something like this:

class Foo : Serializable
{
 long b;

 //I don't want to implement this
 void toData (Serializer serializer, Serializer.Data key)
 {
 serializer.serialize(this);
 }

 void fromData (Serializer serializer, Serializer.Data key)
 {
 b = serializer.deserialize!(int)("b");
 }
}


I actually noticed this problem when I wrote the example. First, the 
interface Serializable is actually not necessary because this is 
actually checked with at template at compile time, it's possible to use 
these methods for structs as well. Second, instead of checking for both 
"toData" and "fromData" when serializing and deserializing it should 
only check for "toData" when serializing and only for "fromData" when 
deserializing.


I'll add this to my todo list.

--
/Jacob Carlborg

Re: std.logger

[Jonathan M Davis]

On Saturday, August 24, 2013 16:49:24 SomeDude wrote:
> OTOH, they are used in just about every logging API ever devised.
> Everybody knows what they mean. I just don't see the need to
> reinvent these words and make them longer by adding log. I
> seriously hate it.
> 
> It clutters code (once you've read your thousand's log
> instruction, it hurts), adds ugly and useless redundancy and
> nothing else to its understanding. This alone is far worse than
> not using verbs.

Well, we're going to have to agree to disagree on that point. Functions are 
supposed to be verbs. They're only nouns if they're properties, in which case, 
they're emulating variables, which are nouns. And I'd consider following the 
proper naming conventions like that to be far more important than saving a few 
characters.

- Jonathan M Davis

Re: ARM targetting cross-toolchain with GDC

[Johannes Pfau]

Am Sat, 24 Aug 2013 19:18:42 +0200
schrieb "ilya-stromberg" :

> On Thursday, 22 August 2013 at 15:15:37 UTC, Johannes Pfau wrote:
> > Am Tue, 06 Aug 2013 23:28:51 +0200
> > schrieb "Timofei Bolshakov" :
> >
> >> I was trying to compile the latest version of GDC for ARM and 
> >> meet multiple problems with static asserts. Do you know if ARM 
> >> fixes exists?
> >
> > Sorry for the late answer. I'm currently working on ARM
> > support but it'll take a little bit longer than I first thought.
> 
> Do you have any plans for Android support?

Not until the 'usual' Linux/GlibC combination works well on ARM.
Android has it's own C library, Bionic. Druntime has only been tested
on glibc on Posix systems so it's some work to port it. And Android
also needs solid shared library support (A D shared library needs to be
loaded by a Java app).

Re: codeblocks - simple newbie tip/correction

[deadalnix]

On Saturday, 24 August 2013 at 17:33:54 UTC, Ramon wrote:
While rdmd is extremey handy, newcomers might often want to 
start simple and easy for the beginning. Looking in the D wiki, 
there is quite a lot listed under IDE and Editors and 
Code:Blocks might actually be one of the more attractive 
beginners solutions.


Unfortunately the documentation (mainly on the code:blocks 
side) isn't reliable and/or correct and I feel that we should 
make it as easy and painfree as possible for newcomers to like 
and getting to try/work with D.


I'm now sitting in front of a working installation on a current 
Debian/Ubuntu/Mint (which might be pretty often encountered) 
and could provide/share a short howto for that scenario leading 
to a properly working codeblocks for D.


A) is that welcome/wanted?
B) if so, what's the right place for such a howto?
C) (for the future) is the forum the right place to 
introduce/ask about such stuff? If not, apologies for my misuse 
and: what's the right place and procedure?


Thanks - R


As you just did it, I think the best option is that you put what 
you just did somewhere in the wiki. Then we can work on form, 
link that where appropriate.


That'd be great.

Re: codeblocks - simple newbie tip/correction

[Ramon]

On Saturday, 24 August 2013 at 18:01:55 UTC, deadalnix wrote:


As you just did it, I think the best option is that you put 
what you just did somewhere in the wiki. Then we can work on 
form, link that where appropriate.


That'd be great.


Thank you.
I do, however, not have permission to edit anything in the wiki 
(nor any experience in editing wikis).


How to proceed?

Thanks - R

Re: codeblocks - simple newbie tip/correction

[deadalnix]

On Saturday, 24 August 2013 at 18:08:53 UTC, Ramon wrote:

On Saturday, 24 August 2013 at 18:01:55 UTC, deadalnix wrote:


As you just did it, I think the best option is that you put 
what you just did somewhere in the wiki. Then we can work on 
form, link that where appropriate.


That'd be great.


Thank you.
I do, however, not have permission to edit anything in the wiki 
(nor any experience in editing wikis).


How to proceed?

Thanks - R


Create an account here : 
http://wiki.dlang.org/?title=Special:UserLogin&returnto=The+D+Programming+Language&type=signup


And you'll be able to edit. Then go to the page you want, and 
start editing. You can figure the syntax along the way, it is 
quite simple. I'm not a specialist and usually look at what 
already exists and cargo cult when editing wiki :D

Observation on packages

[Russel Winder]

Due to a blocking, but short-lived, problem with Debian Unstable, I
upgraded my Fedora dual boot to Fedora 19. I note that whilst GCC is
4.8.1, and Go is packaged, D is not packaged. We know GCC 4.8.1 has GCD,
it is packaged and released for Debian, it is not packaged and released
in Fedora 19 as far as I can tell.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Experimental approach to reference-type random number generators

[Joseph Rushton Wakeling]

Hello all,

Today I spent some time playing around with an attempt at a wrapper for random 
number generation.  The idea is that random number generators should exist as 
reference types, but without needing to be implemented as classes.


The basic wrapper is here: http://codepad.org/AlhLJa6A

And a partial port of std.random using the new wrapper is here:
http://codepad.org/SEBYMns6

See e.g. lines 392-394 and 666-670 for how the wrapper interacts with the random 
number engines.


The basic idea seems to work, and with minimal overhead (it may even be slightly 
faster in some scenarios).  A few of the unittests have had to be commented out 
(e.g. an opEquals needs to be implemented for the wrapper).


It looks promising to me, so before I go further I thought I'd open it up for 
review and commentary.


Some of the features, e.g. the need for the engine to be initialized, may 
explain some of my earlier questions on the mailing lists today ... :-)


I do have one specific query, about whether the way that .save is implemented 
for the wrapper could leak memory given the fact that RefCounted is passed the 
template parameter RefCountedAutoInitialize.yes.


Apart from that, {enj, destr}oy.  Does this look like a valid route to a 
next-gen std.random? :-)


Best wishes,

-- Joe

Re: Experimental approach to reference-type random number generators

[Joseph Rushton Wakeling]

On 24/08/13 20:35, Joseph Rushton Wakeling wrote:

Apart from that, {enj, destr}oy.  Does this look like a valid route to a
next-gen std.random? :-)


I should offer a vote of thanks to monarch_dodra, who referred me to ByLine as 
an example of a reference range (from where I got the idea to use RefCounted), 
and to John Colvin and Artur Skawina who pointed me at some useful info on 
wrapping arbitrary structs.

Re: Experimental approach to reference-type random number generators

[Joseph Rushton Wakeling]

On 24/08/13 20:35, Joseph Rushton Wakeling wrote:

I do have one specific query


Actually, two.  Lines 448-457 of the second codepad paste have this unittest, 
with the last line commented out:



// Check .save works
foreach (Type; TypeTuple!(MinstdRand0, MinstdRand))
{
auto rnd1 = Type(unpredictableSeed);
auto rnd2 = rnd1.save;
//assert(rnd1 == rnd2);
// Enable next test when RNGs are reference types
version(none) { assert(rnd1 !is rnd2); }
//assert(rnd1.take(100).array() == rnd2.take(100).array());
}

If the last assert is uncommented,

assert(rnd1.take(100).array() == rnd2.take(100).array());

... then running the unittests results in the following error:

/opt/dmd/include/d2/std/array.d(37): Error: variable 
std.array.array!(Take!(RandomGenerator!(LinearCongruentialEngine!(uint, 16807, 
0, 2147483647.array.r has scoped destruction, cannot build closure


This is rather worrying and I'm concerned that this could be a fundamental flaw 
in the whole design.  Can anyone advise on how to fix it?

Re: force inline/not-inline

[Temtaime]

Bump.
Will forceinline be introduced?

Re: force inline/not-inline

[jerro]

On Saturday, 17 March 2012 at 22:53:58 UTC, Manu wrote:
I just started writing an emulator in D for some fun; I needed 
an
application to case-study aggressive performance 
characteristics in

hot-loop situations.
I know this has come up time and time again, but I just want to 
put it out
there again... if I were shipping this product, I would NEED 
forceinline +

force-not-inline.


You could use GDC and @attribute("forceinline") and
@attribute("noinline"). But I agree it would be nice to have
something like that as a part of the language.

Re: Allocators

[Namespace]

On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander wrote:

On Friday, 23 August 2013 at 11:40:48 UTC, Namespace wrote:
On Friday, 23 August 2013 at 11:33:11 UTC, Andrej Mitrovic 
wrote:

On Friday, 23 August 2013 at 11:30:01 UTC, deadalnix wrote:

I see Andrei running away !


I see an upcoming drinking game at the next dconf. A shot of 
whiskey anytime anyone mentions allocators. :P


Or auto ref. ;)


Or shared.

Or const.

Or scope.

Or Object methods.

There's quite a few unresolved issues!


Or: 
http://forum.dlang.org/thread/mailman.835.1332024849.4860.digitalmar...@puremagic.com#post-wyloejdfqjzglqbybpxv:40forum.dlang.org

Re: codeblocks - simple newbie tip/correction

[Ramon]

Thanks a lot, Deadalnix

What/How you told me to do worked fine.
The new Howto (section) for D on Debian/Ubuntu/Mint with 
Code:Blocks can now be found here -> 
http://wiki.dlang.org/CodeBlocks


Maybe someone with more experience might want to have a look and 
make sure I did't rape the wiki too badly.


Thank you - R

Re: Ideas for a brand new widget toolkit

[Jonas Drewsen]

On Tuesday, 20 August 2013 at 13:19:33 UTC, Adam D. Ruppe wrote:

On Friday, 16 August 2013 at 22:22:06 UTC, Jonas Drewsen wrote:

Awesome... looking forward to have a look at it.


I pushed the changes to my github today. Still a few little 
changes I want to make, but nothing major. (for example, the 
input enum is based on my US keyboard, so it doesn't have 
entries for other keys. But that's generally additive so should 
be be major breakage.)


https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff


Thanks!

/Jonas

Re: std.serialization: pre-voting review / discussion

[ilya-stromberg]

On Saturday, 24 August 2013 at 17:47:35 UTC, Jacob Carlborg wrote:
I actually noticed this problem when I wrote the example. 
First, the interface Serializable is actually not necessary 
because this is actually checked with at template at compile 
time, it's possible to use these methods for structs as well. 
Second, instead of checking for both "toData" and "fromData" 
when serializing and deserializing it should only check for 
"toData" when serializing and only for "fromData" when 
deserializing.


In that case maybe we should remove "Serializable" interface? And 
just spesify that user must implement "toData" or "fromData" for 
custom serializing or deserializing. Is it possible?

Re: DIP44: scope(class) and scope(struct)

[Walter Bright]

On 8/23/2013 5:44 PM, H. S. Teoh wrote:

I've written up a proposal to solve the partially-constructed object
problem[*] in D in a very nice way by extending scope guards:

http://wiki.dlang.org/DIP44


Not a bad idea, but it has some issues:

1. scope(failure) takes care of most of it already

2. I'm not sure this is a problem that needs solving, as the DIP points out, 
these issues are already easily dealt with. We should be conservative about 
adding more syntax.


3. What if the destructor needs to do more than just unwind the transactions? 
Where does that code fit in?


4. The worst issue is the DIP assumes there is only one constructor, from which 
the destructor is inferred. What if there is more than one constructor?

Re: std.logger

[Robert Schadek]

On 08/24/2013 08:01 PM, Jonathan M Davis wrote:
> On Saturday, August 24, 2013 16:49:24 SomeDude wrote:
>> OTOH, they are used in just about every logging API ever devised.
>> Everybody knows what they mean. I just don't see the need to
>> reinvent these words and make them longer by adding log. I
>> seriously hate it.
>>
>> It clutters code (once you've read your thousand's log
>> instruction, it hurts), adds ugly and useless redundancy and
>> nothing else to its understanding. This alone is far worse than
>> not using verbs.
> Well, we're going to have to agree to disagree on that point. Functions are 
> supposed to be verbs. They're only nouns if they're properties, in which 
> case, 
> they're emulating variables, which are nouns. And I'd consider following the 
> proper naming conventions like that to be far more important than saving a 
> few 
> characters.
>
> - Jonathan M Davis
luckily all log functions are called log and logf now.

Re: std.serialization: pre-voting review / discussion

[Jacob Carlborg]

On 2013-08-24 21:26, ilya-stromberg wrote:


In that case maybe we should remove "Serializable" interface? And just
spesify that user must implement "toData" or "fromData" for custom
serializing or deserializing. Is it possible?


Yes, that's what I'm planning to do.

--
/Jacob Carlborg

Re: Parallel Rogue-like benchmark

[Walter Bright]

On 8/24/2013 9:17 AM, H. S. Teoh wrote:

What's so difficult about running zip on the code?


It's not so easy to run zip on a snippet in a magazine article, as opposed to 
visually just looking at it.




The fault of LOC is precisely that people "fairly intuitively"
understand it. The problem is that no two people's intuitions ever
match.  So any conclusions drawn from LOC must necessarily be
subjective,


Language comparisons are *always* subjective.

A corollary to that is one can always game any supposedly objective criteria.

Re: Experimental approach to reference-type random number generators

[bearophile]

Joseph Rushton Wakeling:

Today I spent some time playing around with an attempt at a 
wrapper for random number generation.  The idea is that random 
number generators should exist as reference types, but without 
needing to be implemented as classes.


I think I'd like std.random2.Random to be a final class.

Bye,
bearophile

Re: Experimental approach to reference-type random number generators

[Joseph Rushton Wakeling]

On Saturday, 24 August 2013 at 19:42:18 UTC, bearophile wrote:

I think I'd like std.random2.Random to be a final class.


That was also an approach I considered.  It's easy -- even 
trivial -- to do.  But since Phobos has such a strong 
struct-oriented approach, I thought I'd try something that could 
make that work.


One of the benefits of that approach is that it should be 
possible to drop std.random2 into 99% of code and have it Just 
Work, without downstreams having to change a line of their own 
code.

Re: DIP44: scope(class) and scope(struct)

[H. S. Teoh]

On Sat, Aug 24, 2013 at 01:01:12PM +0200, Artur Skawina wrote:
> On 08/24/13 08:30, Piotr Szturmaj wrote:
> > H. S. Teoh wrote:
> >> I've written up a proposal to solve the partially-constructed
> >> object problem[*] in D in a very nice way by extending scope
> >> guards:
> >>
> >> http://wiki.dlang.org/DIP44
> 
> > 2. allow referring to local variables and create the closure. This
> > causes additional memory allocation and also reference to the
> > closure must be stored somewhere, perhaps in the class hidden field.
> > Of course, this is a "no go", I'm writing this here for comparison.
> 
> That is what he's actually proposing. And, yes, it's not a good idea.
> Implementing it via runtime delegates, implicit captures/allocs and
> extra hidden fields inside aggregates would work, but the cost is too
> high. It's also not much of an improvement over manually registering
> and calling the delegates. Defining what happens when a ctor fails
> would be a good idea, having a cleanup method which defaults to
> `~this`, but can be overridden could help too.

The issue with that is that the initialization code and the cleanup code
has to be separated, potentially by a lot of unrelated stuff in between.
The genius of scope guards is that initialization and cleanup is written
in one place even though they actually happen in different places, so
it's very unlikely you will forget to cleanup correctly.


> There are other problems with that DIP, like making it harder to see
> what's actually going on, by splitting the dtor code and having it
> interleaved with another separate flow.

I think it's unhelpful to conflate scope(this) with dtors. Yes there is
some overlap, but if you treat them separately, then there is no
problem (assuming that a dtor is actually necessary).


> It *is* possible to implement a similar solution without any RT cost,
> but it would need:
> a) flow analysis - to figure out the cleanup order, which might not be 
> statically known (these cases have to be disallowed)
> b) a different approach for specifying the cleanup code, so that 
> implicit capturing of ctor state doesn't happen and it's not
> necessary to read the complete body of every ctor just to find
> out what a dtor does.

I think that's an unhelpful way of thinking about it. What about we
think of it this way: the ctor is acquiring X number of resources, and
by wrapping the resource-releasing code in scope(this), we guarantee
that these resources will be correctly released. Basically, scope(this)
will take care of invoking the release code whenever the object's
lifetime is over, whether it's unsuccessful construction, or
destruction.

It's just like saying scope guards are useless because it's equivalent
to a try-catch block anyway (and in fact, that's how the front end
implements scope guards). One may even argue scope guards are bad
because the cleanup code is sprinkled everywhere rather than collected
in one place. But it's not really about whether it's equivalent to
another language construct; it's about better code maintainability.
Separating the code that initializes something from the code that cleans
up something makes it harder to maintain, and more error-prone (e.g.
initialize 9 things, forget to clean up one of them). Keeping them
together in the same place makes code correctness clearer.


On Sat, Aug 24, 2013 at 02:48:53PM +0200, Tobias Pankrath wrote:
[...]
> Couldn't this problem be solved by using RAII and destructors? You
> would (only) need to make sure that every member is either correctly
> initialised or T.init.

How would you use RAII to solve this problem? If I have a class:

class C {
Resource1 res1;
Resource2 res2;
Resource3 res3;
this() {
...
}
}

How would you write the ctor with RAII such that if it successfully
inits res1 and res2, but throws before it inits res3, then only res1 and
res2 will be cleaned up?


On Sat, Aug 24, 2013 at 09:31:52PM +0400, Dmitry Olshansky wrote:
[...]
> Instead of introducing extra mess into an already tricky ctor/dtor
> situation. (Just peek at past issues with dtors not being called,
> being called at wrong time, etc.)
> 
> I'd say just go RAII in bits and pieces. Unlike scope, there it
> works just fine as it has the right kind of lifetime from the get
> go. In function scope (where scope(exit/success/failure) shines)
> RAII actually sucks as it may prolong the object lifetime I you are
> not careful to tightly wrap it into { }.
> 
> Start with this:
> 
> class C {
> Resource1 res1;
> Resource2 res2;
> Resource3 res3;
> 
> this() {
> res1 = acquireResource!1();
> res2 = acquireResource!2();
> res3 = acquireResource!3();
> }
> 
> ~this() {
> res3.release();
> res2.release();
> res1.release();
> }
> }
> 
> Write a helper once:
> 
> struct Handler(alias acquire,

Re: codeblocks - simple newbie tip/correction

[H. S. Teoh]

On Sat, Aug 24, 2013 at 09:16:41PM +0200, Ramon wrote:
> Thanks a lot, Deadalnix
> 
> What/How you told me to do worked fine.
> The new Howto (section) for D on Debian/Ubuntu/Mint with Code:Blocks
> can now be found here -> http://wiki.dlang.org/CodeBlocks
> 
> Maybe someone with more experience might want to have a look and
> make sure I did't rape the wiki too badly.
[...]

Looks good to me. Might want to link it to the front page navigation
somehow (perhaps through the page(s) that talks about IDEs for D).


T

-- 
There are 10 kinds of people in the world: those who can count in binary, and 
those who can't.

Re: std.serialization: pre-voting review / discussion

[ilya-stromberg]

On Saturday, 24 August 2013 at 19:32:13 UTC, Jacob Carlborg wrote:

On 2013-08-24 21:26, ilya-stromberg wrote:

In that case maybe we should remove "Serializable" interface? 
And just
spesify that user must implement "toData" or "fromData" for 
custom

serializing or deserializing. Is it possible?


Yes, that's what I'm planning to do.


Maybe we should rename methods "toData" and "fromData" to avoid 
name collisions? For example, we can use serializeToData and 
deserializeFromData, it will be clearer.

Re: DIP44: scope(class) and scope(struct)

[H. S. Teoh]

On Sat, Aug 24, 2013 at 01:09:44PM -0700, H. S. Teoh wrote:
[...]
> On Sat, Aug 24, 2013 at 12:27:37PM -0700, Walter Bright wrote:
[...]
> > 4. The worst issue is the DIP assumes there is only one constructor,
> > from which the destructor is inferred. What if there is more than
> > one constructor?
> 
> This is not a problem. If there is more than one constructor, then
> only those scope(this) statements in the ctor that were actually
> encountered will trigger when the object reaches the end of its
> lifetime.  You already have to do this anyway, since if the ctor
> throws an Exception before completely constructing the object, only
> those scope(this) statements that have been encountered up to that
> point will be triggered, not all of them. Otherwise, you'd still have
> the partially-initialized object problem.
[...]

Argh, that was poorly worded. What I mean is this:

struct S {
this(int) {
scope(this) writeln("A");
}
this(float) {
scope(this) writeln("B");
}
}

void fun1() {
auto s = S(1);
}   // prints "A"

void fun2() {
auto s = S(1.0);
}   // prints "B"


T

-- 
Dogs have owners ... cats have staff. -- Krista Casada

Re: Allocators

[David Nadlinger]

On Saturday, 24 August 2013 at 19:15:13 UTC, Namespace wrote:
On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander 
wrote:

There's quite a few unresolved issues!


Or: 
http://forum.dlang.org/thread/mailman.835.1332024849.4860.digitalmar...@puremagic.com#post-wyloejdfqjzglqbybpxv:40forum.dlang.org


That's not a language issue, that's a compiler feature request 
that does not affect the language semantics at all.


David

Re: Allocators

[Namespace]

On Saturday, 24 August 2013 at 20:56:09 UTC, David Nadlinger 
wrote:

On Saturday, 24 August 2013 at 19:15:13 UTC, Namespace wrote:
On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander 
wrote:

There's quite a few unresolved issues!


Or: 
http://forum.dlang.org/thread/mailman.835.1332024849.4860.digitalmar...@puremagic.com#post-wyloejdfqjzglqbybpxv:40forum.dlang.org


That's not a language issue, that's a compiler feature request 
that does not affect the language semantics at all.


David


What's about the probable change of virtual by default -> final 
by default?

Re: Allocators

[Timon Gehr]

On 08/24/2013 12:42 AM, Peter Alexander wrote:

On Friday, 23 August 2013 at 20:20:21 UTC, Timon Gehr wrote:

On 08/23/2013 10:08 PM, Peter Alexander wrote:

On Friday, 23 August 2013 at 20:04:28 UTC, H. S. Teoh wrote:

What's the problem with const again?


I'm thinking mainly of const postblit, and the ramifications of solving
that.


What problem does const postblit have that a const constructor does
not have?


Currently, const postblit completely breaks the type system.

struct Foo
{
 this(this) { *p = 2; }
 int* p;
}
...


That's a mutable postblit, but I see the point.


void main()
{
 import std.stdio;
 immutable int i = 1;
 const(Foo) a = const(Foo)(&i);
 const(Foo) b = a;


I think this line should fail for lack of an appropriately qualified 
postblit.



 writeln(a.p, " ", *a.p);
 writeln(b.p, " ", *b.p);
 writeln(&i, " ", i);
}

For me, this gives:

7FFF5257D418 2
7FFF5257D418 2
7FFF5257D418 1

The immutable int is changed, and apparently the same address has two
different values at the same time!

I'm not aware of any way to do this with constructors, but maybe I'm
just not aware :-)


import std.stdio;

void main(){
void check(immutable(int)* ptr){
writeln(ptr," ",*ptr);
}
struct S{
immutable(int) x;
this(int)const{
check(&x);
x=2;
check(&x);
}
}
auto s = S(0);
}

7FFFAFAA4B80 0
7FFFAFAA4B80 2

Re: Allocators

[Andrej Mitrovic]

On 8/24/13, Namespace  wrote:
> What about the probable change of virtual by default -> final
> by default?

Btw, can someone find the link to the forum thread where the last
discussion of this took place? I remember Walter agreeing to
something, but can't recall anymore.

Re: DIP44: scope(class) and scope(struct)

[Artur Skawina]

On 08/24/13 22:09, H. S. Teoh wrote:
> On Sat, Aug 24, 2013 at 01:01:12PM +0200, Artur Skawina wrote:
>> On 08/24/13 08:30, Piotr Szturmaj wrote:
>>> H. S. Teoh wrote:
 I've written up a proposal to solve the partially-constructed
 object problem[*] in D in a very nice way by extending scope
 guards:

 http://wiki.dlang.org/DIP44
>>
>>> 2. allow referring to local variables and create the closure. This
>>> causes additional memory allocation and also reference to the
>>> closure must be stored somewhere, perhaps in the class hidden field.
>>> Of course, this is a "no go", I'm writing this here for comparison.
>>
>> That is what he's actually proposing. And, yes, it's not a good idea.
>> Implementing it via runtime delegates, implicit captures/allocs and
>> extra hidden fields inside aggregates would work, but the cost is too
>> high. It's also not much of an improvement over manually registering
>> and calling the delegates. Defining what happens when a ctor fails
>> would be a good idea, having a cleanup method which defaults to
>> `~this`, but can be overridden could help too.
> 
> The issue with that is that the initialization code and the cleanup code
> has to be separated, potentially by a lot of unrelated stuff in between.
> The genius of scope guards is that initialization and cleanup is written
> in one place even though they actually happen in different places, so
> it's very unlikely you will forget to cleanup correctly.

The "scope guards" are actually an ugly hack - but one that is useful
and where the alternatives aren't significantly better. In fact, its
"ugliness" makes it stand out more, which in this case is a positive
trait.

What makes your proposal different is:

a) scope guards are *local*. They are contained within a single (lexical)
   scope. Which means that you can easily spot them, just by looking at
   *one* continuous piece of source code. For most sanely written code
   the distance from where they are defined to where they are executed is
   small enough (ie functions spanning multiple pages are/should be
   relatively uncommon).
   You are proposing defining them in *completely different functions*.
   To see what will actually happen at destruction time one would have
   to read *every single ctor*. 

b) scope guards are just *static syntax sugar*. All they do is let you
   define blocks of code using slightly different syntax and move them
   closer to the location where related operations happen.
   Your proposal introduces *dynamic* behavior - it's no longer just a
   trivial rewriting from one form to another. /Order/ starts to matter.
  
   struct S {
  R r1, r2;

  this(A a) {
  auto cond = pick_one();
  if (cond) { r1 = i1(); scope(this) cl1(); } else { r2 = i2(); 
scope(this) cl2(); }
  //...   
  if (!cond) { r2 = i3(); scope(this) cl3(); } else { r1 = i4(); 
scope(this) cl4(); }
  //...   
  }

  this(B b) { r1 = i1(); scope(this) cl1(); r2 = i2(); scope(this) cl2(); }
  this(C c) { r2 = i2(); scope(this) cl2(); r1 = i1(); scope(this) cl1(); }
   }

   Consider what is going to (has to) happen when this object is destructed/
   finalized. If one path ends up being taken rarely (say, just under memory
   pressure) /and/ contains a race related to the cleanup order, the result can
   be subtle and extremely hard to reproduce bugs. Those would also happen when
   using an explicit scheme (manually registering the delegates etc), but you
   just made it all implicit - so now all of the magic is completely invisible
   and these kinds of bugs became much harder to spot.

>> There are other problems with that DIP, like making it harder to see
>> what's actually going on, by splitting the dtor code and having it
>> interleaved with another separate flow.
> 
> I think it's unhelpful to conflate scope(this) with dtors. Yes there is
> some overlap, but if you treat them separately, then there is no
> problem (assuming that a dtor is actually necessary).

See above. "scope(this)" moves parts of a dtor to inside the ctors (there
can be many of those) *and* introduces reordering.


>> It *is* possible to implement a similar solution without any RT cost,
>> but it would need:
>> a) flow analysis - to figure out the cleanup order, which might not be 
>> statically known (these cases have to be disallowed)
>> b) a different approach for specifying the cleanup code, so that 
>> implicit capturing of ctor state doesn't happen and it's not
>> necessary to read the complete body of every ctor just to find
>> out what a dtor does.
> 
> I think that's an unhelpful way of thinking about it. What about we
> think of it this way: the ctor is acquiring X number of resources, and
> by wrapping the resource-releasing code in scope(this), we guarantee
> that these resources will be correctly released. Basically, scope(this)
> will take care of invoking the release code whenev

Re: DIP44: scope(class) and scope(struct)

[Ramon]

Maybe I'm just plain too unexperienced or dumb but I see problems.

- What's a dtor's job in D? This is not C++ (where cleaning up 
often means freeing/not leaking), in D the GC saves us lots of 
problems. Actually, we do not even really free anything (except 
malloc'ed stuff) but rather hinting the runtime expressis verbis 
that sth. isn't needed anymore.


- scope(this) adds something new to the scope mechanism wich is 
per se bad and imo not justified for luxury.


- I see H.S. Teoh's point to in a way have stuff aquired or 
allocated in ctor kind of "registered" in dtor for proper 
cleanup, but that *can* be done with what we have right now.


- From what I understand the proposal implies some kind of a 
transactional "all or nothing" mechanism. Is a ctor and class 
level the right place to implement that?



@H.S. Teoh

Maybe it would helpful to explain why you think this is an 
*important* problem (rather than a nuisance) and more clearly 
define it (and why it can't be solved using what we have)?


Thanks

Re: DIP44: scope(class) and scope(struct)

[Tobias Pankrath]

On Saturday, 24 August 2013 at 20:11:14 UTC, H. S. Teoh wrote:

How would you use RAII to solve this problem? If I have a class:

class C {
Resource1 res1;
Resource2 res2;
Resource3 res3;
this() {
...
}
}

How would you write the ctor with RAII such that if it 
successfully
inits res1 and res2, but throws before it inits res3, then only 
res1 and

res2 will be cleaned up?


Like someone else already proposed: Using a wrapper type W that 
releases the resources in it's destructor. W.init wouldn't 
release anything. So by definition (if I recall the rules 
correctly) every new instance of C would have res3 = 
Resource3.init prior to it's constructor called.


Now make sure that a) res3's destructor gets called (check) b) 
res3's destructor may be called on Resource3.init. That would be 
a new rule similar to 'no internal aliasing' and c) that every 
constructor of C either sets res3 to a destructable value or does 
not touch it at all ('transactional programming').

Re: Allocators

[Kapps]

On Saturday, 24 August 2013 at 21:53:47 UTC, Andrej Mitrovic 
wrote:

On 8/24/13, Namespace  wrote:

What about the probable change of virtual by default -> final
by default?


Btw, can someone find the link to the forum thread where the 
last

discussion of this took place? I remember Walter agreeing to
something, but can't recall anymore.


It seemed like eventually Walter supported virtual by default, 
but nothing came of it. For some reason I can't find the thread 
anymore with Google.

Re: DIP44: scope(class) and scope(struct)

[Walter Bright]

On 8/24/2013 1:09 PM, H. S. Teoh wrote:

On Sat, Aug 24, 2013 at 12:27:37PM -0700, Walter Bright wrote:
[...]

Not a bad idea, but it has some issues:

1. scope(failure) takes care of most of it already

2. I'm not sure this is a problem that needs solving, as the DIP
points out, these issues are already easily dealt with. We should be
conservative about adding more syntax.

3. What if the destructor needs to do more than just unwind the
transactions? Where does that code fit in?


I think it's unhelpful to conflate scope(this) with dtors. They are
related, but -- and I guess I was a bit too strong about saying dtors
are redundant -- if we allow both, then scope(this) can be reserved for
transactions, and you can still put code in ~this() to do non-trivial
cleanups.


If you take out automatic dtor generation, I see no difference between 
scope(this) and scope(failure).




4. The worst issue is the DIP assumes there is only one constructor,
from which the destructor is inferred. What if there is more than
one constructor?


This is not a problem. If there is more than one constructor, then only
those scope(this) statements in the ctor that were actually encountered
will trigger when the object reaches the end of its lifetime.


Do you mean multiple dtors will be generated, one for each constructor?

Re: [dox] Text describing Sections in Documentation Generator page needs improvement

[Andre Artus]

On Friday, 23 August 2013 at 21:41:01 UTC, H. S. Teoh wrote:

Sorry for the late reply, it's kinda hard keeping up with this
high-volume mailing list. :)


Tell me about it :)


On Sat, Aug 17, 2013 at 12:08:06AM +0200, Andre Artus wrote:

The text describing Sections in Documentation Generator page
(http://dlang.org/ddoc.html) needs improvement.

It reads:

>Sections

>The document comment is a series of Sections. A Section is a 
>name

>that is the first non-blank character on a line
>immediately followed by a ':'. This name forms the section
>name. The section name is not case sensitive.


My issues with this are the following.

1. A section is not a name. It ~has~ a name (except when it
doesn't).


Yeah, it should say that the document comment is divided into 
sections, and section names consist of a sequence of non-blank 
characters followed a ':'.


I think the description/explanation of a section name should be 
done separately from the description of sections. As far as I 
understand it there are only 2 section types that are sans name 
(summary and description), but bringing in names as part of the 
section description muddies the waters a bit (in my opinion).




[...]
2. A name can be more than one character. I believe all the 
standard sections have names longer than 1 character.



HST
Yes.


3. Some sections do not end their identifiers with a colon 
(':') to

wit "Escapes=".



HST
Oh? I don't think that's a section, that looks like a macro 
definition.


A^2
It's kind of a section for text substitutions, each substitution 
pair can be seen as an parameter-less macro, but I think 
"Escapes=" still denotes a section, similar to the "Macros:" 
section.


I'm not quite clear on how "Escapes=", "Macros:", and embedded 
HTML serves the goal of decoupling the content from the 
presentation (e.g. PDF, LaTex,...). I would think that escape 
sequences would be configuration for the [output] generator.



4. The wording leaves the impression that arbitrary named 
sections are
possible, is this the case? Or are the named sections 
predefined (i.e.

those listed as standard and special sections)?



HST
Arbitrary names are possible. The predefined names may have 
special interpretations.


A^2
If one wants to add a new named section (not predefined), do you 
need to create a macro expansion for it, or how does it work? It 
would probably be good to add some guidance for that.

Re: [dox] Text describing Sections in Documentation Generator page needs improvement

[Andre Artus]

I have been racking my brain to find a suitable replacement for 
the section description, I would appreciate your critique.


"A section is a block of text that is processed by the document 
generator. There are only two unlabeled sections, summary and 
description, all other sections are identified by a label (or 
name). A section label starts with the first non-blank 
character[1] on a line and continues until terminated by a colon 
(:).


Details of each kind of section follow"


1. This is technically not true, as the first non-blank character 
could be an asterisk. As far as  I can see the section labels 
follow the same rules as other identifiers. But, according to the 
description above the following,


/**
* 7^%$#@!  ][|:
*/

would be a valid section name/label --with the value "* 7^%$#@!  
][|"-- which seems questionable to me.


I think we should tighten up the rules regarding section labels.

Re: Allocators

[luminousone]

On Saturday, 24 August 2013 at 22:41:54 UTC, Kapps wrote:
On Saturday, 24 August 2013 at 21:53:47 UTC, Andrej Mitrovic 
wrote:

On 8/24/13, Namespace  wrote:

What about the probable change of virtual by default -> final
by default?


Btw, can someone find the link to the forum thread where the 
last

discussion of this took place? I remember Walter agreeing to
something, but can't recall anymore.


It seemed like eventually Walter supported virtual by default, 
but nothing came of it. For some reason I can't find the thread 
anymore with Google.


Pretty sure Walter supported final by default, he even laid out a 
transition plan as I recall. Seems like Manu was involved, so 
asking him might bear fruit on that question.

Re: DIP44: scope(class) and scope(struct)

[Andrei Alexandrescu]

On 8/24/13 10:31 AM, Dmitry Olshansky wrote:

24-Aug-2013 04:44, H. S. Teoh пишет:

I've written up a proposal to solve the partially-constructed object
problem[*] in D in a very nice way by extending scope guards:

http://wiki.dlang.org/DIP44




Destroy! ;-)



Instead of introducing extra mess into an already tricky ctor/dtor
situation. (Just peek at past issues with dtors not being called, being
called at wrong time, etc.)

I'd say just go RAII in bits and pieces.


Agreed. DIP44 supports an idiom of handling multiple unprotected 
resources within the same object, which should be infrequent and 
generally unrecommended.


Andrei

Re: DIP44: scope(class) and scope(struct)

[H. S. Teoh]

On Sat, Aug 24, 2013 at 06:50:11PM -0700, Walter Bright wrote:
> On 8/24/2013 1:09 PM, H. S. Teoh wrote:
> >On Sat, Aug 24, 2013 at 12:27:37PM -0700, Walter Bright wrote:
> >[...]
> >>Not a bad idea, but it has some issues:
> >>
> >>1. scope(failure) takes care of most of it already
> >>
> >>2. I'm not sure this is a problem that needs solving, as the DIP
> >>points out, these issues are already easily dealt with. We should be
> >>conservative about adding more syntax.
> >>
> >>3. What if the destructor needs to do more than just unwind the
> >>transactions? Where does that code fit in?
> >
> >I think it's unhelpful to conflate scope(this) with dtors. They are
> >related, but -- and I guess I was a bit too strong about saying dtors
> >are redundant -- if we allow both, then scope(this) can be reserved
> >for transactions, and you can still put code in ~this() to do
> >non-trivial cleanups.
> 
> If you take out automatic dtor generation, I see no difference
> between scope(this) and scope(failure).
> 
> 
> >>4. The worst issue is the DIP assumes there is only one constructor,
> >>from which the destructor is inferred. What if there is more than
> >>one constructor?
> >
> >This is not a problem. If there is more than one constructor, then
> >only those scope(this) statements in the ctor that were actually
> >encountered will trigger when the object reaches the end of its
> >lifetime.
> 
> Do you mean multiple dtors will be generated, one for each
> constructor?

No. Given this code:

class C {
this(int) {
scope(this) writeln("A1");
scope(this) writeln("A2");
}

this(float) {
scope(this) writeln("B1");
scope(this) writeln("B2");
}
}

The lowered code looks something like this:

class C {
this(int) {
scope(failure) __cleanup();

// scope(this) writeln("A1");
// Translated into:
__cleanups ~= { writeln("A1"); };

// scope(this) writeln("A2");
// Translated into:
__cleanups ~= { writeln("A2"); };
}

this(float) {
scope(failure) __cleanup();

// scope(this) writeln("B1");
// Translated into:
__cleanups ~= { writeln("B1"); };

// scope(this) writeln("B2");
// Translated into:
__cleanups ~= { writeln("B2"); };
}

void delegate()[] __cleanups;

void __cleanup() {
foreach_reverse (f; __cleanups)
f();
}

~this() {
__cleanup();
}
}

So, there is only one dtor. But it automatically takes handles
triggering the scope(this) statements of only the ctor that was actually
used for creating the object. And if the ctor didn't successfully
complete, it only triggers the scope(this) statements that have been
encountered up to that point.

Of course, the above lowered code is just to illustrate how it works.
The actual implementation can be optimized by the compiler. E.g., if
there is only one ctor and the sequence of scope(this) can be statically
determined, then the cleanup statements can be put into the dtor
directly without incurring the overhead of allocating the __cleanups
array. If the cleanups don't need closure over ctor local variables,
then they can just be function ptrs, not delegates. Only when you're
doing something complicated do you actually need an array of delegates,
which should be relatively rare.


T

-- 
Political correctness: socially-sanctioned hypocrisy.

Re: DIP44: scope(class) and scope(struct)

[Walter Bright]

On 8/24/2013 10:35 PM, H. S. Teoh wrote:

On Sat, Aug 24, 2013 at 06:50:11PM -0700, Walter Bright wrote:

On 8/24/2013 1:09 PM, H. S. Teoh wrote:

On Sat, Aug 24, 2013 at 12:27:37PM -0700, Walter Bright wrote:
[...]

Not a bad idea, but it has some issues:

1. scope(failure) takes care of most of it already

2. I'm not sure this is a problem that needs solving, as the DIP
points out, these issues are already easily dealt with. We should be
conservative about adding more syntax.

3. What if the destructor needs to do more than just unwind the
transactions? Where does that code fit in?


I think it's unhelpful to conflate scope(this) with dtors. They are
related, but -- and I guess I was a bit too strong about saying dtors
are redundant -- if we allow both, then scope(this) can be reserved
for transactions, and you can still put code in ~this() to do
non-trivial cleanups.


If you take out automatic dtor generation, I see no difference
between scope(this) and scope(failure).



4. The worst issue is the DIP assumes there is only one constructor,

>from which the destructor is inferred. What if there is more than

one constructor?


This is not a problem. If there is more than one constructor, then
only those scope(this) statements in the ctor that were actually
encountered will trigger when the object reaches the end of its
lifetime.


Do you mean multiple dtors will be generated, one for each
constructor?


No. Given this code:

class C {
this(int) {
scope(this) writeln("A1");
scope(this) writeln("A2");
}

this(float) {
scope(this) writeln("B1");
scope(this) writeln("B2");
}
}

The lowered code looks something like this:

class C {
this(int) {
scope(failure) __cleanup();

// scope(this) writeln("A1");
// Translated into:
__cleanups ~= { writeln("A1"); };

// scope(this) writeln("A2");
// Translated into:
__cleanups ~= { writeln("A2"); };
}

this(float) {
scope(failure) __cleanup();

// scope(this) writeln("B1");
// Translated into:
__cleanups ~= { writeln("B1"); };

// scope(this) writeln("B2");
// Translated into:
__cleanups ~= { writeln("B2"); };
}

void delegate()[] __cleanups;

void __cleanup() {
foreach_reverse (f; __cleanups)
f();
}

~this() {
__cleanup();
}
}

So, there is only one dtor. But it automatically takes handles
triggering the scope(this) statements of only the ctor that was actually
used for creating the object. And if the ctor didn't successfully
complete, it only triggers the scope(this) statements that have been
encountered up to that point.

Of course, the above lowered code is just to illustrate how it works.
The actual implementation can be optimized by the compiler. E.g., if
there is only one ctor and the sequence of scope(this) can be statically
determined, then the cleanup statements can be put into the dtor
directly without incurring the overhead of allocating the __cleanups
array. If the cleanups don't need closure over ctor local variables,
then they can just be function ptrs, not delegates. Only when you're
doing something complicated do you actually need an array of delegates,
which should be relatively rare.


Your example, again, is of an auto-generated dtor. But you said earlier that 
wasn't the point.


Without the auto-generated dtor, it is just scope(failure), which is already a D 
feature.


I don't get it.

Re: windows .lib files (dmc has them, dmd doesn't)

[Nick Sabalausky]

On Thu, 22 Aug 2013 17:10:06 +0200
Andrej Mitrovic  wrote:

> On 8/22/13, Adam D. Ruppe  wrote:
> > So, what's the plan here?
> 
> Well, I want us to have an open distribution process (i.e. put all the
> .zip making scripts up on Github), so we as a community can take care
> of this. This would also finally allow us to try and distribute
> per-platform zip files.

I'm almost done with a script (written in D) that does exactly that
(including per-platform archives, all-platform archives, zip and 7z). I
just need to get the generation of "d.chm" working[1], do some final
testing, and write a little more documentation.

There is one issue blocking it from working on the current GitHub
master though: http://d.puremagic.com/issues/show_bug.cgi?id=10856

One...uhh "interesting" thing I noticed while working on it: A lot of
the sources included in the 2.063.2 zip don't match GitHub. Some of
them (mainly in the backend) even appear to be specific revisions that,
AFAICT, don't even exist on GitHub.

[1] Related: