Re: So, User-Defined Attributes

[Walter Bright]

On 1/6/2013 11:31 PM, Timon Gehr wrote:

I am sure that very good progress is being made. However, the forward reference
error problem will need formal treatment at some point. I think one reason they
pop up is that symbol lookup for the intended language is inherently impossible
to compute.


A huge source of fwd ref problems was not at all about symbol lookup. It was 
about partial types referencing properties of themselves. For example,


struct S {
int a;
int b = S.sizeof;
int c;
}

for a simple example. There've been all kinds of variations on this theme, some 
of them wickedly complicated, but always boiling down to the same general issue.


Some forward ref regressions have cropped up because the compiler now does a 
better job of checking if there is enough of the type computed to get the 
desired property. Formerly, it would just return an incorrect size (for 
example). (I do not know if this is the case for your example, yet.)

Re: So, User-Defined Attributes

[Era Scarecrow]

On Monday, 7 January 2013 at 07:58:29 UTC, Walter Bright wrote:
A huge source of fwd ref problems was not at all about symbol 
lookup. It was about partial types referencing properties of 
themselves. For example,


struct S {
int a;
int b = S.sizeof;
int c;
}

for a simple example. There've been all kinds of variations on 
this theme, some of them wickedly complicated, but always 
boiling down to the same general issue.


Some forward ref regressions have cropped up because the 
compiler now does a better job of checking if there is enough 
of the type computed to get the desired property. Formerly, it 
would just return an incorrect size (for example). (I do not 
know if this is the case for your example, yet.)


 I've had certain headaches from that as well trying to make my 
polymorphic struct, it's easy to see how it can get lost.


  struct S {
static struct Data {
  int i;
}
union {
  Data data;
  S2 s2;  //problem line
}
  }

  struct S2 {
S base;   //problem line
  }

  Here the whole size is defined by Data, however because S2 
references S1 before it has a concrete size it can get stuck (may 
still get stuck, not sure).


  Hmmm in cases like this, a @size attribute could be useful 
(forces it to believe given size rather than looking it up). So 
that could become:


union {
  Data data;
  @size(Data.sizeof) S2 s2;  //size hint, forward ref problem 
gone

}

Re: Accessing UDA of private field

[Jacob Carlborg]

On 2013-01-06 23:33, Philippe Sigaud wrote:


Good thinking. It's not pretty but it works. Thanks.


Maybe it can be hidden inside a template?


Yeah, I'll see what I can do.

--
/Jacob Carlborg

D 2.061 release

[Russel Winder]

I just thought I should report that 2.061 has fixed all the threading
problems I was moaning about after the 2.059 → 2.060 update.  So thanks
to all concerned with fixing the bug reports that were generated.

LDC is though still generally creating faster executables than DMD. This
is just a gut feeling right now, in a couple of weeks time I'll see if I
can get some actual numbers.
 
-- 
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

Re: Accessing UDA of private field

[Tove]

On Monday, 7 January 2013 at 10:19:45 UTC, Jacob Carlborg wrote:

On 2013-01-06 23:33, Philippe Sigaud wrote:


   Good thinking. It's not pretty but it works. Thanks.


Maybe it can be hidden inside a template?


Yeah, I'll see what I can do.


in which context does private fail? I'm using something like this:

struct my_struct
{
private:
  @(1) int t1;
  @(2) int t2;
  @(3) int t3;
}

foreach(m; __traits(allMembers, my_struct))
  with(my_struct.init)
pragma(msg, __traits(getAttributes, mixin(m)));

Thrift 0.9.0 D tutorial broken by dmd 2.061

[Ivan Ribeiro]

Hi,

  Since I have upgraded my dmd from version 2.060 to 2.061 the 
cliend.d and server.d is not compiling anymore 
(thrift-0.9.0/tutorial/d).


  Someone with same problem?

  Best regards,

Ivan

[irocha@irrlab d]$ pwd
/data/D/thrift-0.9.0/tutorial/d
[irocha@irrlab d]$ make
dmd -I../../lib/d/src -L-L../../lib/d -L-lthriftd server.d 
../gen-d/share/SharedService.d ../gen-d/share/shared_types.d 
../gen-d/tutorial/tutorial_types.d ../gen-d/tutorial/Calculator.d
../../lib/d/src/thrift/codegen/processor.d(155): Error: module 
thrift.codegen.processor 
thrift.internal.codegen.FilterMethodNames(T, MemberNames...) is 
private
../../lib/d/src/thrift/codegen/processor.d(317): Error: CTFE 
failed because of previous errors in __lambda1161
../../lib/d/src/thrift/codegen/processor.d(317): Error: argument 
to mixin must be a string, not ((*delegate @system string()

...
...
server.d(101): Error: template instance 
thrift.codegen.processor.TServiceProcessor!(Calculator) error 
instantiating
server.d(101): Error: TServiceProcessor!(Calculator) is used as a 
type
server.d(105): Error: constructor 
thrift.server.simple.TSimpleServer.this (TProcessor processor, 
TServerTransport serverTransport, TTransportFactory 
transportFactory, TProtocolFactory protocolFactory) is not 
callable using argument types 
(_error_,TServerSocket,TWrapperTransportFactory,TBinaryProtocolFactory)

server.d(105): Error: expected 6 function arguments, not 4

Re: Thrift 0.9.0 D tutorial broken by dmd 2.061

[David Nadlinger]

On Monday, 7 January 2013 at 12:14:17 UTC, Ivan Ribeiro wrote:
  Since I have upgraded my dmd from version 2.060 to 2.061 the 
cliend.d and server.d is not compiling anymore 
(thrift-0.9.0/tutorial/d).


  Someone with same problem?


I must admit that I didn't test the tutorial, but the test suite 
is passing again on trunk/Git master, which contains a fix for 
the issue you are hitting (really just a wrong »private« 
qualifier, which was not checked by DMD before).


David

Re: Accessing UDA of private field

[Jacob Carlborg]

On 2013-01-07 12:59, Tove wrote:


in which context does private fail? I'm using something like this:

struct my_struct
{
private:
   @(1) int t1;
   @(2) int t2;
   @(3) int t3;
}

foreach(m; __traits(allMembers, my_struct))
   with(my_struct.init)
 pragma(msg, __traits(getAttributes, mixin(m)));


Using a mixin works.

--
/Jacob Carlborg

Re: manual memory management

[David Nadlinger]

On Monday, 7 January 2013 at 15:01:27 UTC, Gor Gyolchanyan wrote:
How can I have an associative array, which uses a custom 
allocator?


I'm afraid the only viable solution right now is to implement 
your own AA type as a struct with overloaded operators (which is 
in fact what the built-in AAs are lowered to as well).


There are two downside to this, though - besides, of course, the 
fact that you need a custom implementation:
 - You cannot pass your type to library functions expecting a 
built-in associative array.
 - You lose the convenient literal syntax. This could be fixed in 
the language, though, by providing a rewrite to a variadic 
constructor of user types for array/AA literals, thus eliminating 
the need for GC allocations (gah, another thing I just need to 
find the time to write up a DIP for…).


David

Re: Accessing UDA of private field

[Tove]

On Monday, 7 January 2013 at 13:36:47 UTC, Jacob Carlborg wrote:

On 2013-01-07 12:59, Tove wrote:

in which context does private fail? I'm using something like 
this:


struct my_struct
{
private:
  @(1) int t1;
  @(2) int t2;
  @(3) int t3;
}

foreach(m; __traits(allMembers, my_struct))
  with(my_struct.init)
pragma(msg, __traits(getAttributes, mixin(m)));


Using a mixin works.


but this seems to work too?

import std.traits;

struct my_struct
{
private:
  @(1) int t1;
  @(2) int t2;
  @(3) int t3;
}
void main()
{
  foreach(m; __traits(allMembers, my_struct))
pragma(msg, __traits(getAttributes, __traits(getMember, 
my_struct, m)));

}

Re: Accessing UDA of private field

[David Nadlinger]

On Monday, 7 January 2013 at 15:37:48 UTC, Tove wrote:

but this seems to work too?

import std.traits;

struct my_struct
{
private:
  @(1) int t1;
  @(2) int t2;
  @(3) int t3;
}
void main()
{
  foreach(m; __traits(allMembers, my_struct))
pragma(msg, __traits(getAttributes, __traits(getMember, 
my_struct, m)));

}


»private« means »accessible from this module« – are you running 
your tests with my_struct defined in a different module?


David

Re: manual memory management

[Gor Gyolchanyan]

On Mon, Jan 7, 2013 at 7:25 PM, David Nadlinger  wrote:

> On Monday, 7 January 2013 at 15:01:27 UTC, Gor Gyolchanyan wrote:
>
>> How can I have an associative array, which uses a custom allocator?
>>
>
> I'm afraid the only viable solution right now is to implement your own AA
> type as a struct with overloaded operators (which is in fact what the
> built-in AAs are lowered to as well).
>
> There are two downside to this, though - besides, of course, the fact that
> you need a custom implementation:
>  - You cannot pass your type to library functions expecting a built-in
> associative array.
>  - You lose the convenient literal syntax. This could be fixed in the
> language, though, by providing a rewrite to a variadic constructor of user
> types for array/AA literals, thus eliminating the need for GC allocations
> (gah, another thing I just need to find the time to write up a DIP for…).
>
> David
>

This means, that dlang.org is lying. D doesn't provide both a garbage
collector and manual memory management. It provides a garbage collector and
a lousy excuse for manual memory management. As much as I love D for it's
metaprogramming and generative programming, it's not even remotely fit for
system-level programming the way it claims it is.

I don't mean to be trolling, but it's not the first time I got grossly
disappointed in D.

-- 
Bye,
Gor Gyolchanyan.

Re: manual memory management

[mist]

How is D manual memory management any worse than plain C one?
Plenty of language features depend on GC but stuff that is left 
can hardly be named "a lousy excuse". It lacks some convenience 
and guidelines based on practical experience but it is already as 
capable as some of wide-spread solutions for systems programming 
(C). In fact I'd be much more afraid of runtime issues when doing 
system stuff than GC ones.


On Monday, 7 January 2013 at 15:49:50 UTC, Gor Gyolchanyan wrote:
On Mon, Jan 7, 2013 at 7:25 PM, David Nadlinger 
 wrote:


On Monday, 7 January 2013 at 15:01:27 UTC, Gor Gyolchanyan 
wrote:


How can I have an associative array, which uses a custom 
allocator?




I'm afraid the only viable solution right now is to implement 
your own AA
type as a struct with overloaded operators (which is in fact 
what the

built-in AAs are lowered to as well).

There are two downside to this, though - besides, of course, 
the fact that

you need a custom implementation:
 - You cannot pass your type to library functions expecting a 
built-in

associative array.
 - You lose the convenient literal syntax. This could be fixed 
in the
language, though, by providing a rewrite to a variadic 
constructor of user
types for array/AA literals, thus eliminating the need for GC 
allocations
(gah, another thing I just need to find the time to write up a 
DIP for…).


David



This means, that dlang.org is lying. D doesn't provide both a 
garbage
collector and manual memory management. It provides a garbage 
collector and
a lousy excuse for manual memory management. As much as I love 
D for it's
metaprogramming and generative programming, it's not even 
remotely fit for

system-level programming the way it claims it is.

I don't mean to be trolling, but it's not the first time I got 
grossly

disappointed in D.

Re: manual memory management

[Rob T]

On Monday, 7 January 2013 at 16:12:22 UTC, mist wrote:

How is D manual memory management any worse than plain C one?
Plenty of language features depend on GC but stuff that is left 
can hardly be named "a lousy excuse". It lacks some convenience 
and guidelines based on practical experience but it is already 
as capable as some of wide-spread solutions for systems 
programming (C). In fact I'd be much more afraid of runtime 
issues when doing system stuff than GC ones.


I think the point being made was that built in language features 
should not be dependent on the need for a GC because it means 
that you cannot fully use the language without a GC present and 
active. We can perhaps excuse the std library, but certainly not 
the language itself, because the claim is made that D's GC is 
fully optional.


--rt

Re: D 2.061 release

[Jonathan M Davis]

On Monday, January 07, 2013 11:13:55 Russel Winder wrote:
> LDC is though still generally creating faster executables than DMD. This
> is just a gut feeling right now, in a couple of weeks time I'll see if I
> can get some actual numbers.

I wouldn't expect that to change anytime soon. Work would have to be put in on 
specifically make dmd generate faster code, and AFAIK, pretty much all of the 
compiler work is being put into bug fixing and implementing a few new features 
(like Win64 support). I wouldn't expect improved optimizations to enter into 
the picture much until the bug count is much lower unless someone takes a 
liking to spending time improving dmd's code generation.

- Jonathan M Davis

Re: manual memory management

[Jonathan M Davis]

On Monday, January 07, 2013 17:55:35 Rob T wrote:
> On Monday, 7 January 2013 at 16:12:22 UTC, mist wrote:
> > How is D manual memory management any worse than plain C one?
> > Plenty of language features depend on GC but stuff that is left
> > can hardly be named "a lousy excuse". It lacks some convenience
> > and guidelines based on practical experience but it is already
> > as capable as some of wide-spread solutions for systems
> > programming (C). In fact I'd be much more afraid of runtime
> > issues when doing system stuff than GC ones.
> 
> I think the point being made was that built in language features
> should not be dependent on the need for a GC because it means
> that you cannot fully use the language without a GC present and
> active. We can perhaps excuse the std library, but certainly not
> the language itself, because the claim is made that D's GC is
> fully optional.

I don't think that any of the documentation or D's developers have ever 
claimed that you could use the full language without the GC. Quite the 
opposite in fact. There are a number of language features that require the GC 
- including AAs, array concatenation, and closures. You _can_ program in D 
without the GC, but you lose features, and there's no way around that. It may 
be the case that some features currently require the GC when they shouldn't, 
but there are definitely features that _must_ have the GC and _cannot_ be 
implemented otherwise (e.g. array concatenation and closures). So, if you want 
to ditch the GC completely, it comes at a cost, and AFAIK no one around here 
is saying otherwise. You _can_ do it though if you really want to.

In general however, the best approach if you want to minimize GC involvement 
is to generally use manual memory management and minimize your usage of 
features that require the GC rather than try and get rid of it entirely, 
because going the extra mile to remove its use completely generally just isn't 
worth it. Kith-Sa posted some good advice on this just the other day, and he's 
written a game engine in D:

http://forum.dlang.org/post/vbsajlgotanuhmmpn...@forum.dlang.org

- Jonathan M Davis

Re: dlangspec.pdf?

[H. S. Teoh]

On Mon, Jan 07, 2013 at 02:35:09AM -0500, Andrei Alexandrescu wrote:
> On 1/7/13 2:17 AM, Walter Bright wrote:
> >On 1/6/2013 9:31 AM, Philippe Sigaud wrote:
> >>Exactly.
> >
> >At one point I looked into doing Latex macros for Ddoc, but
> >unfortunately it didn't look like it was doable without some
> >extensive modifications to Ddoc.

I think the simplest way would be to allow the definition of some kind
of post-processing filter that escapes LaTeX metacharacters with their
appropriate substitutions. It can be as easy as a ddoc macro (or list of
macros) that translates a given character into its LaTeX equivalent,
with the default of no-op. So to adapt ddoc output to a particular
format, you just have to override that particular set of metacharacters,
and leave everything else as pass-through.


> ??? I already have something in progress.
[...]

Curious ears want to hear what that something is. :-)


T

-- 
Arise, you prisoners of Windows / Arise, you slaves of Redmond, Wash, /
The day and hour soon are coming / When all the IT folks say "Gosh!" /
It isn't from a clever lawsuit / That Windowsland will finally fall, /
But thousands writing open source code / Like mice who nibble through a
wall. -- The Linux-nationale by Greg Baker

Re: manual memory management

[Gor Gyolchanyan]

On Mon, Jan 7, 2013 at 8:55 PM, Rob T  wrote:

> On Monday, 7 January 2013 at 16:12:22 UTC, mist wrote:
>
>> How is D manual memory management any worse than plain C one?
>> Plenty of language features depend on GC but stuff that is left can
>> hardly be named "a lousy excuse". It lacks some convenience and guidelines
>> based on practical experience but it is already as capable as some of
>> wide-spread solutions for systems programming (C). In fact I'd be much more
>> afraid of runtime issues when doing system stuff than GC ones.
>>
>
> I think the point being made was that built in language features should
> not be dependent on the need for a GC because it means that you cannot
> fully use the language without a GC present and active. We can perhaps
> excuse the std library, but certainly not the language itself, because the
> claim is made that D's GC is fully optional.
>
> --rt
>


You're absolutely right. D would be far better if there was a way to
specify  custom allocators for built-in data structures. Perhaps another
magical property:

int[int] a;
a.allocator = new MyCustomAllocator;
a[5] = 5;

That's the least code-breaking way I can think of.

-- 
Bye,
Gor Gyolchanyan.

Re: dlangspec.pdf?

[Adam D. Ruppe]

On Monday, 7 January 2013 at 17:32:33 UTC, H. S. Teoh wrote:
I think the simplest way would be to allow the definition of 
some kind of post-processing filter that escapes LaTeX

metacharacters with their appropriate substitutions.


Believe it or not, but dmd already has the beginnings of this 
code! There's a ddoc escapes table.


from doc.c:

ESCAPES = //>/\n
  /&/&/\n


And there's code to parse it, but it isn't actually used. I did a 
dmd pull request a while ago to bring in this functionality but 
it didn't pass reviews. (A consequence of proper escaping would 
be that inline HTML, outside of macros, would no longer be 
permitted, because  etc would be properly escaped instead of 
printed out verbatim. This is far, far, far superior to the 
status quo, but it does break a lot of phobos documentation.)

Re: manual memory management

[Benjamin Thaut]

Am 07.01.2013 16:49, schrieb Gor Gyolchanyan:

On Mon, Jan 7, 2013 at 7:25 PM, David Nadlinger mailto:s...@klickverbot.at>> wrote:

On Monday, 7 January 2013 at 15:01:27 UTC, Gor Gyolchanyan wrote:

How can I have an associative array, which uses a custom allocator?


I'm afraid the only viable solution right now is to implement your
own AA type as a struct with overloaded operators (which is in fact
what the built-in AAs are lowered to as well).

There are two downside to this, though - besides, of course, the
fact that you need a custom implementation:
  - You cannot pass your type to library functions expecting a
built-in associative array.
  - You lose the convenient literal syntax. This could be fixed in
the language, though, by providing a rewrite to a variadic
constructor of user types for array/AA literals, thus eliminating
the need for GC allocations (gah, another thing I just need to find
the time to write up a DIP for…).

David


This means, that dlang.org  is lying. D doesn't
provide both a garbage collector and manual memory management. It
provides a garbage collector and a lousy excuse for manual memory
management. As much as I love D for it's metaprogramming and generative
programming, it's not even remotely fit for system-level programming the
way it claims it is.

I don't mean to be trolling, but it's not the first time I got grossly
disappointed in D.

--
Bye,
Gor Gyolchanyan.


You can use my GC free hashmap if you want:
https://github.com/Ingrater/druntime/blob/master/src/core/hashmap.d

Kind Regards
Benjamin Thaut

Re: dlangspec.pdf?

[H. S. Teoh]

On Mon, Jan 07, 2013 at 06:40:36PM +0100, Adam D. Ruppe wrote:
> On Monday, 7 January 2013 at 17:32:33 UTC, H. S. Teoh wrote:
> >I think the simplest way would be to allow the definition of some
> >kind of post-processing filter that escapes LaTeX
> >metacharacters with their appropriate substitutions.
> 
> Believe it or not, but dmd already has the beginnings of this code!
> There's a ddoc escapes table.
> 
> from doc.c:
> 
> ESCAPES = /   />/>/\n
>   /&/&/\n

This is exactly what's needed to produce proper LaTeX output.


> And there's code to parse it, but it isn't actually used. I did a
> dmd pull request a while ago to bring in this functionality but it
> didn't pass reviews. (A consequence of proper escaping would be that
> inline HTML, outside of macros, would no longer be permitted,
> because  etc would be properly escaped instead of printed out
> verbatim. This is far, far, far superior to the status quo, but it
> does break a lot of phobos documentation.)

Inline HTML should not be allowed in ddoc, because it completely defeats
the purpose of the ddoc macro system allowing the same documentation to
be rendered for multiple target formats.

We need to go through all instances of such errors in Phobos and fix 'em
all.


T

-- 
Don't get stuck in a closet---wear yourself out.

Re: dlangspec.pdf?

[Era Scarecrow]

On Monday, 7 January 2013 at 18:07:51 UTC, H. S. Teoh wrote:
Inline HTML should not be allowed in ddoc, because it 
completely defeats the purpose of the ddoc macro system 
allowing the same documentation to be rendered for multiple 
target formats.


We need to go through all instances of such errors in Phobos 
and fix 'em all.


 Depends on what HTML was used (and can extend to BBCode as 
well). If I were to add anything, it most likely would be 
bold/italic/underline & bullets. Those should be acceptable and 
overall easy to convert (or I would think so anyways).

Re: dlangspec.pdf?

[Andrei Alexandrescu]

On 1/7/13 9:30 AM, H. S. Teoh wrote:

On Mon, Jan 07, 2013 at 02:35:09AM -0500, Andrei Alexandrescu wrote:

??? I already have something in progress.

[...]

Curious ears want to hear what that something is. :-)


A set of ddoc macros that convert to LaTeX starting from Philippe's 
macros. The one systemic issue I encountered so far is tables, which in 
LaTeX must set the number of columns in advance.


Andrei

Re: D 2.061 release

[Era Scarecrow]

On Monday, 7 January 2013 at 17:05:19 UTC, Jonathan M Davis wrote:

On Monday, January 07, 2013 11:13:55 Russel Winder wrote:
LDC is though still generally creating faster executables than 
DMD. This is just a gut feeling right now, in a couple of 
weeks time I'll see if I can get some actual numbers.


I wouldn't expect that to change anytime soon. Work would have 
to be put in on specifically make dmd generate faster code, and 
AFAIK, pretty much all of the compiler work is being put into 
bug fixing and implementing a few new features (like Win64 
support). I wouldn't expect improved optimizations to enter 
into the picture much until the bug count is much lower unless 
someone takes a liking to spending time improving dmd's code 
generation.


 If I recall right, one of the larger slowdowns was during large 
struct initialization, as dmd wrote individual instructions to 
fill in the struct. I wouldn't think it would be that hard to fix 
that, then compare speeds, they might be closer to equal than we 
think.

Re: numericValue for (unicode) characters

[monarch_dodra]

On Friday, 4 January 2013 at 22:00:02 UTC, Dmitry Olshansky wrote:

[SNIP]


Thank you for all your feed back.

*everything* makes sense now.

However, the conclusion I'm comming to is that there needs some 
ground work before doing numeric value, which I am currently 
doing.

Re: numericValue for (unicode) characters

[monarch_dodra]

On Saturday, 5 January 2013 at 00:47:14 UTC, H. S. Teoh wrote:

[...]

I, for one, would love to know why isNumeric != hasNumericValue.


T


I guess it's just bad wording from the standard.

The standard defined 3 groups that make up Number:
[Nd]Number, Decimal Digit
[Nl]Number, Letter
[No]Number, Other

However, there are a couple of characters that *are* numbers, but 
aren't in those goups.


The "Good" news is that the standard, *does* define number_types 
to classify the kind of number a char is:

* Null: Not a number
* Digit: Obvious
* Decimal: Any decimal number that is NOT a digit
* Numeric: Everything else.

So they used "Numeric" as wild, and "Number" as their general 
category.


This leaves us with ambiguity when choosing our word:
Technically '5' does not clasify as "numeric", although you could 
consider it "has a numeric value".


I hope that makes sense.

Re: manual memory management

[nazriel]

On Monday, 7 January 2013 at 17:57:49 UTC, Benjamin Thaut wrote:

Am 07.01.2013 16:49, schrieb Gor Gyolchanyan:
On Mon, Jan 7, 2013 at 7:25 PM, David Nadlinger 

> wrote:

   On Monday, 7 January 2013 at 15:01:27 UTC, Gor Gyolchanyan 
wrote:


   How can I have an associative array, which uses a 
custom allocator?



   I'm afraid the only viable solution right now is to 
implement your
   own AA type as a struct with overloaded operators (which is 
in fact

   what the built-in AAs are lowered to as well).

   There are two downside to this, though - besides, of 
course, the

   fact that you need a custom implementation:
 - You cannot pass your type to library functions 
expecting a

   built-in associative array.
 - You lose the convenient literal syntax. This could be 
fixed in

   the language, though, by providing a rewrite to a variadic
   constructor of user types for array/AA literals, thus 
eliminating
   the need for GC allocations (gah, another thing I just need 
to find

   the time to write up a DIP for…).

   David


This means, that dlang.org  is lying. D 
doesn't
provide both a garbage collector and manual memory management. 
It
provides a garbage collector and a lousy excuse for manual 
memory
management. As much as I love D for it's metaprogramming and 
generative
programming, it's not even remotely fit for system-level 
programming the

way it claims it is.

I don't mean to be trolling, but it's not the first time I got 
grossly

disappointed in D.

--
Bye,
Gor Gyolchanyan.


You can use my GC free hashmap if you want:
https://github.com/Ingrater/druntime/blob/master/src/core/hashmap.d

Kind Regards
Benjamin Thaut


Benjamin, maybe you could in your spare time draw a DIP for 
Allocators?
This is really very important thing we need for yesterday and 
putting all the work on Andrei won't help with it.


Your solution seems to work very well in practice, maybe it would 
be possible to adapt it for Druntime/Phobos needs? Or maybe its 
already fully designed and only needs polishing and pull request?


Thanks!

Re: dlangspec.pdf?

[Andrei Alexandrescu]

On 1/7/13 10:23 AM, Andrei Alexandrescu wrote:

On 1/7/13 9:30 AM, H. S. Teoh wrote:

On Mon, Jan 07, 2013 at 02:35:09AM -0500, Andrei Alexandrescu wrote:

??? I already have something in progress.

[...]

Curious ears want to hear what that something is. :-)


A set of ddoc macros that convert to LaTeX starting from Philippe's
macros. The one systemic issue I encountered so far is tables, which in
LaTeX must set the number of columns in advance.

Andrei


Heh, here's the first thing that I actually got to compile error-free 
from spec.dd and lex.dd: http://erdani.com/d/dlangspec.pdf. Had to fudge 
a few macros and some stuff doesn't expand to what it should, but from 
here the path is relatively easy.


Andrei

__traits(getAttributes) with string mixin

[Jacob Carlborg]

I have some code looking like this. I don't understand why I can use a 
string mixin together with __traits(getAttributes) when it doesn't work 
if I use the template "getAttributes".


template Tuple (T...)
{
alias T Tuple;
}

struct Foo
{
@(3) int a;
}

template getAttributes (alias s)
{
alias Tuple!(__traits(getAttributes, s)) getAttributes;
}

void main ()
{
Foo foo;
writeln(__traits(getAttributes, mixin("foo.a")));

// Error: variable foo cannot be read at compile time   
// writeln(getAttributes!(mixin("foo.a")));

writeln(getAttributes!(foo.a));
mixin(`writeln(getAttributes!(foo.a));`);
}

--
/Jacob Carlborg

Re: D 2.061 release

[Walter Bright]

On 1/7/2013 3:13 AM, Russel Winder wrote:

I just thought I should report that 2.061 has fixed all the threading
problems I was moaning about after the 2.059 → 2.060 update.  So thanks
to all concerned with fixing the bug reports that were generated.


That is great news!



LDC is though still generally creating faster executables than DMD. This
is just a gut feeling right now, in a couple of weeks time I'll see if I
can get some actual numbers.


It's also helpful to drill down to see why. For example, a while back a D user 
posted a benchmark where he concluded that dmd generated poor code for integer 
math. Drilling down into the generated code, it was pretty much the same as what 
other compilers generated. What was different, however, was the implementation 
of the "long divide" library function. druntime had a slow one. The long divide 
dominated the performance profile. Fixing that brought it up to par with zero 
changes to the compiler.


I've also seen benchmarks where the compiler was blamed, where malloc, or 
printf, or strcpy, or whatever was the actual dominant cycle sucker. Or even 
that the wrong compiler switches were used. Yes, I've seen magazines publish 
benchmarks where the 'slow' compiler was used with debug switches on, and the 
'fast' compiler had the optimization switches on.

Re: D 2.061 release

[Era Scarecrow]

On Monday, 7 January 2013 at 20:23:37 UTC, Walter Bright wrote:
I've also seen benchmarks where the compiler was blamed, where 
malloc, or printf, or strcpy, or whatever was the actual 
dominant cycle sucker. Or even that the wrong compiler switches 
were used. Yes, I've seen magazines publish benchmarks where 
the 'slow' compiler was used with debug switches on, and the 
'fast' compiler had the optimization switches on.


 Sounds rigged. I know I've heard of benchmarks from years ago 
where a windows server system (2000?) was against a linux server; 
The windows machine had like a gig of memory and a bunch of other 
snazzy hardware, while the linux machine was giving the bare 
minimum to run the server (32-128Mb). Also I think Microsoft was 
the one doing the benchmarks... :)

Re: dlangspec.pdf?

[Jordi Sayol]

Al 07/01/13 20:19, En/na Andrei Alexandrescu ha escrit:
> On 1/7/13 10:23 AM, Andrei Alexandrescu wrote:
>> On 1/7/13 9:30 AM, H. S. Teoh wrote:
>>> On Mon, Jan 07, 2013 at 02:35:09AM -0500, Andrei Alexandrescu wrote:
 ??? I already have something in progress.
>>> [...]
>>>
>>> Curious ears want to hear what that something is. :-)
>>
>> A set of ddoc macros that convert to LaTeX starting from Philippe's
>> macros. The one systemic issue I encountered so far is tables, which in
>> LaTeX must set the number of columns in advance.
>>
>> Andrei
> 
> Heh, here's the first thing that I actually got to compile error-free from 
> spec.dd and lex.dd: http://erdani.com/d/dlangspec.pdf. Had to fudge a few 
> macros and some stuff doesn't expand to what it should, but from here the 
> path is relatively easy.
> 
> Andrei
> 

"htmldoc" converts html files into pdf, generating a toc.

In this sample I've removed original toc and "htmldoc" generated a toc with 2 
levels.
http://d-packages.googlecode.com/files/dlangspec.pdf

Unfortunately "htmldoc" do not support css.
-- 
Jordi Sayol

Re: manual memory management

[Benjamin Thaut]

Am 07.01.2013 20:10, schrieb nazriel:

Benjamin, maybe you could in your spare time draw a DIP for Allocators?
This is really very important thing we need for yesterday and putting
all the work on Andrei won't help with it.

Your solution seems to work very well in practice, maybe it would be
possible to adapt it for Druntime/Phobos needs? Or maybe its already
fully designed and only needs polishing and pull request?

Thanks!


I'm very busy with university atm. But if I have some free time again I 
could think about doing this. But I actually would want someone who can 
do a decision on this to actually look at my fork and confirm that this 
is actually wanted. I'm not going to do all the work for pull request 
without actually having some kind of confirmation.


Kind Regards
Benjamin Thaut

Re: D 2.061 release

[Walter Bright]

On 1/7/2013 1:08 PM, Era Scarecrow wrote:

  Sounds rigged. I know I've heard of benchmarks from years ago where a windows
server system (2000?) was against a linux server; The windows machine had like a
gig of memory and a bunch of other snazzy hardware, while the linux machine was
giving the bare minimum to run the server (32-128Mb). Also I think Microsoft was
the one doing the benchmarks... :)


Most of the time it was just incompetence.

On one, the benchmark table results showed Zortech was the fastest, but the 
article text asserted that Major Brand X was the fastest.

Re: manual memory management

[Rob T]

On Monday, 7 January 2013 at 17:19:25 UTC, Jonathan M Davis wrote:
I don't think that any of the documentation or D's developers 
have ever
claimed that you could use the full language without the GC. 
Quite the
opposite in fact. There are a number of language features that 
require the GC

- including AAs, array concatenation, and closures.


True, there is some documentation describing that certain 
features require the use of the GC. Although I would say that the 
documentation needs to be made a lot more clear on this point. 
For example in the AA section there's no mention that the GC is 
required.


What you are saying is that while the GC is considered optional, 
it is not really optional given the language as a whole, only a 
(I assume large) subset of the language will work without the GC. 
In other words, the GC is partly optional.


I think we can do a lot better to make it more clear that the GC 
is not 100% optional, and also indicate clearly what features 
will not work without one.



You _can_

program in D
without the GC, but you lose features, and there's no way 
around that. It may
be the case that some features currently require the GC when 
they shouldn't,
but there are definitely features that _must_ have the GC and 
_cannot_ be

implemented otherwise (e.g. array concatenation and closures).


Is this a hard fact, or can there be a way to make it work? For 
example what about the custom allocator idea?


From a marketing POV, if the language can be made 100% free of 
the GC it would at least not be a deterrent to those who cannot 
accept having to use one. From a technical POV, there are 
definitely many situations where not using a GC is desirable.


--rt

Re: dlangspec.pdf?

[Philippe Sigaud]

On Mon, Jan 7, 2013 at 7:23 PM, Andrei Alexandrescu <
seewebsiteforem...@erdani.org> wrote:

> On 1/7/13 9:30 AM, H. S. Teoh wrote:
>
>> On Mon, Jan 07, 2013 at 02:35:09AM -0500, Andrei Alexandrescu wrote:
>>
>>> ??? I already have something in progress.
>>>
>> [...]
>>
>>
>> Curious ears want to hear what that something is. :-)
>>
>
> A set of ddoc macros that convert to LaTeX starting from Philippe's
> macros. The one systemic issue I encountered so far is tables, which in
> LaTeX must set the number of columns in advance.


Same here. The two systems do not see tables in the same way.

Did you find a way to get syntax-highlighted code?

Re: dlangspec.pdf?

[Philippe Sigaud]

> Heh, here's the first thing that I actually got to compile error-free from
> spec.dd and lex.dd: 
> http://erdani.com/d/dlangspec.**pdf.
> Had to fudge a few macros and some stuff doesn't expand to what it should,
> but from here the path is relatively easy.


I tried to find all the macros that created those ugly 

Re: D 2.061 release

[bearophile]

Walter Bright:


It's also helpful to drill down to see why.


I agree. Performance of the resulting code doesn't come out of 
magic, it comes from one or more (usually many) small stupid 
steps done by some optimization module, etc etc. If you locate 
the problem exactly, it's often possible to improve the 
"compiler". See below.



For example, a while back a D user posted a benchmark where he 
concluded that dmd generated poor code for integer math.


That person concluded that DMD was doing a worse job in compiling 
that code.


From similar discussions it seems that the problem is that what 
you call "compiler" isn't what most people think of "compiler". 
For me the "long divide" is part of what the compiler does.


Bye,
bearophile

Re: manual memory management

[bearophile]

Rob T:

What you are saying is that while the GC is considered 
optional, it is not really optional given the language as a 
whole, only a (I assume large) subset of the language will work 
without the GC. In other words, the GC is partly optional.


Technical users get angry when they uncover some marketing lies 
in technical documentation. It's much better to tell them the 
truth since the beginning.


Bye,
bearophile

Re: manual memory management

[H. S. Teoh]

On Mon, Jan 07, 2013 at 11:26:02PM +0100, Rob T wrote:
> On Monday, 7 January 2013 at 17:19:25 UTC, Jonathan M Davis wrote:
[...]
> >You _can_ program in D without the GC, but you lose features, and
> >there's no way around that. It may be the case that some features
> >currently require the GC when they shouldn't, but there are
> >definitely features that _must_ have the GC and _cannot_ be
> >implemented otherwise (e.g. array concatenation and closures).
> 
> Is this a hard fact, or can there be a way to make it work? For
> example what about the custom allocator idea?

Some features of D were *designed* with a GC in mind. As Jonathan has
already said, array slicing, concatenation, etc., pretty much *require*
a GC. I don't see how else you could implement code like this:

int[] f(int[] arr) {
assert(arr.length >= 4);
return arr[2..4];
}

int[] g(int[] arr) {
assert(arr.length >= 2);
return arr[0..2];
}

int[] h(int[] arr) {
assert(arr.length >= 3);
if (arr[0] > 5)
return arr[1..3];
else
return arr[2..3] ~ 6;
}

void main() {
int[] arr = [1,2,3,4,5,6,7,8];
auto a1 = f(arr[1..5]);
auto a2 = g(arr[3..$]);
auto a3 = h(arr[0..6]);
a2 ~= 123;

// Exercise for the reader: write manual deallocation
// for this code.
}

Yes, this code *can* be rewritten to use manual allocation, but it will
be a major pain in the neck (not to mention likely to be inefficient,
due to the required overhead of tracking where each array slice went and
whether a reallocation was needed and what must be freed at the end).

Not to mention that h() makes it impossible to do static analysis in the
compiler to keep track of what's going on (it will reallocate the array
or not depending on runtime data, for example). So you're pretty much
screwed if you don't have a GC.

To make it possible to do without the GC at the language level, you'd
have to basically cripple most of the main selling points of D arrays,
so that they become nothing more than C arrays with fancy syntax. Along
with all the nasty caveats that made C arrays (esp. strings) so painful
to work with. In particular, h() would require manual re-implementation
and major API change (it needs to somehow return a flag of some sort to
indicate whether or not the input array was reallocated), along with all
code that calls it (check for the flag, then decide based on where a
whole bunch of other pointers are pointing whether the input array needs
to be deallocated, etc., all the usual daily routine of a C programmer's
painful life). This cannot be feasibly automated, which means it can't
be done by the compiler, which means using D doesn't really give you any
advantage here, and therefore you might as well just write it in
straight C to begin with.


> From a marketing POV, if the language can be made 100% free of the GC
> it would at least not be a deterrent to those who cannot accept having
> to use one. From a technical POV, there are definitely many situations
> where not using a GC is desirable.
[...]

I think much of the aversion to GCs is misplaced.  I used to be very
aversive of GCs as well, so I totally understand where you're coming
from. I used to believe that GCs are for lazy programmers who can't be
bothered to think through their code and how to manage memory properly,
and that therefore GCs encourage sloppy coding. But then, after having
used D extensively for my personal projects, I discovered to my surprise
that having a GC actually *improved* the quality of my code -- it's much
more readable because I don't have to keep fiddling with pointers and
ownership (or worse, reference counts), and I can actually focus on how
to make the algorithms better. Not to mention the countless frustrating
hours spent chasing pointer bugs and memory leaks are all gone -- 'cos I
don't have to use pointers directly anymore.

As for performance, I have not noticed any significant performance
problems with using a GC in my D code. Now I know that there are cases
when the intermittent pause of the GC's mark-n-sweep cycle may not be
acceptable, but I suspect that 90% of applications don't even need to
care about this. Most applications won't even have any noticeable
pauses.

The most prominent case where this *does* matter is in game engines,
that must squeeze out every last drop of performance from the hardware,
no matter what. But then, when you're coding a game engine, you aren't
writing general application code per se; you're engineering a
highly-polished and meticulously-tuned codebase where all data
structures are already carefully controlled and mapped out -- IOW, you
wouldn't be using GC-dependent features of D in this code anyway. So it
shouldn't even be

Re: dlangspec.pdf?

[Andrei Alexandrescu]

On 1/7/13 2:36 PM, Philippe Sigaud wrote:

Did you find a way to get syntax-highlighted code?


Listings package.

Andrei

Re: shared gitconfig

[Andrei Alexandrescu]

On 1/6/13 3:41 PM, Jonathan M Davis wrote:

I'm arguing that people should actually learn how to use git properly rather
than creating crutches for themselves.


False choice.


The more you try and do with git
without learning it properly, the more problems you're likely to run into
(e.g. by running commands that you don't entirely understand and ending up
with nasty side effects). So, I think that it's just plain bad practice to
create such macros.


I know how the shell works quite well but that doesn't stop me from 
writing scripts and aliases.


This boils down to advocating one needs to type by hand sequences of 
commands instead of defining higher-level scripts that have a cohesive 
meaning.



Andrei

Re: manual memory management

[Rob T]

Yes I can see in your example why removing the GC fully will be 
difficult to deal with.


I am not actually against the use of the GC, I was only wondering 
if it could be fully removed. I too did not at first agree with 
the GC concept, thinking the same things you mention. I still 
have to consider performance issues caused by the GC, but the 
advantage is that I can do things that before I would not even 
bother attempting because the cost was too high. The way I 
program has changed for the better, there's no doubt about it.


So if the GC cannot be removed fully, then there's no point 
trying to fully remove it, and performance issues have to be 
solved through improving the GC implementation, and also with 
better selective manual control methods.


As for the claims made that D's GC is "optional", that message is 
coming from various sources one encounters when reading about D 
for the first time.


For example:
http://www.drdobbs.com/tools/new-native-languages/232901643
"D has grown to embrace a wide range of features — optional 
memory management (garbage collection), ..."


Sure you can "optionally" disable the GC, but it means certain 
fundamental parts of the language will no longer be usable, 
leading to misconceptions that the GC is fully optional and 
everything can be made to work as before.


I know D's documentation is *not* claiming that the GC is 
optional, you get that impression from reading external sources 
instead, however it may be a good idea to counter the possible 
misconception in the FAQ.


Improved documentation will also help those who want to do 
selective manual memory management. As it is, I cannot say for 
certain what parts of the language require the use of the GC 
because the specification either leaves this information out, or 
is not specified clearly enough.


--rt

Re: manual memory management

[Brad Roberts]

On Tue, 8 Jan 2013, Rob T wrote:

> I am not actually against the use of the GC, I was only wondering if it could
> be fully removed. I too did not at first agree with the GC concept, thinking
> the same things you mention. I still have to consider performance issues
> caused by the GC, but the advantage is that I can do things that before I
> would not even bother attempting because the cost was too high. The way I
> program has changed for the better, there's no doubt about it.

There's some issues that can rightfully be termed "caused by the GC", but 
most of the performance issues are probably better labled "agregious use 
of short lived allocations", which cost performance regardless of how 
memory is managed.  The key difference being that in manual management the 
impact is spread out and in periodic garbage collection it's batched up.

My primary point being, blaming the GC when it's the application style 
that generates enough garbage to result in wanting to blame the GC for the 
performance cost is misplaced blame.

My 2 cents,
Brad

Re: shared gitconfig

[Andrej Mitrovic]

On 1/6/13, Andrei Alexandrescu  wrote:
> What I'd want to do next is define the alias such that other
> participants to the dlang project may use it. With time we'd collect a
> good set of macros that help our process.

This is what I use locally in my .bashrc:

# win32 helpers
alias cd..='cd ..'
alias dir="ls -F"
alias cls='clear'
alias c:='cd /c/'
alias d:='cd /d/'
alias e:='cd /e/'
alias f:='cd /f/'
alias g:='cd /g/'

# git stuff
alias com='git checkout master'
alias fpush='git push -f' # needed after a local rebase
alias hreset='git reset --hard head' # reset to the last commit,
discarding all changes
alias hdiff='git diff head~1' # check what I've added with the latest commit
alias amend='git commit --amend' # edit the last commit message
alias rb='git pull --rebase upstream master' # rebase local branch and
verify there's no merge conflicts
alias co='git checkout'
alias diff='git diff' # what did I change so far without staging/commiting?
alias cdiff='git diff --cached' # what am I about to commit?
alias add='git add'
alias gcm='git commit -m' # quick commit with message
alias gcn='git checkout -b' #quick create a new branch

I only add stuff there when I realize I'm constantly retyping some long command.
I should probably add 'git rebase -i head~' too.

Re: manual memory management

[deadalnix]

On Tuesday, 8 January 2013 at 02:06:02 UTC, Brad Roberts wrote:

On Tue, 8 Jan 2013, Rob T wrote:

I am not actually against the use of the GC, I was only 
wondering if it could
be fully removed. I too did not at first agree with the GC 
concept, thinking
the same things you mention. I still have to consider 
performance issues
caused by the GC, but the advantage is that I can do things 
that before I
would not even bother attempting because the cost was too 
high. The way I

program has changed for the better, there's no doubt about it.


There's some issues that can rightfully be termed "caused by 
the GC", but
most of the performance issues are probably better labled 
"agregious use
of short lived allocations", which cost performance regardless 
of how
memory is managed.  The key difference being that in manual 
management the
impact is spread out and in periodic garbage collection it's 
batched up.


My primary point being, blaming the GC when it's the 
application style
that generates enough garbage to result in wanting to blame the 
GC for the

performance cost is misplaced blame.

My 2 cents,
Brad


You'll also find out that D's GC is kind of slow, but this is an 
implementation issue more than a conceptual problem with he GC.

Re: dlangspec.pdf?

[Jordi Sayol]

Al 07/01/13 20:19, En/na Andrei Alexandrescu ha escrit:
> On 1/7/13 10:23 AM, Andrei Alexandrescu wrote:
>> On 1/7/13 9:30 AM, H. S. Teoh wrote:
>>> On Mon, Jan 07, 2013 at 02:35:09AM -0500, Andrei Alexandrescu wrote:
 ??? I already have something in progress.
>>> [...]
>>>
>>> Curious ears want to hear what that something is. :-)
>>
>> A set of ddoc macros that convert to LaTeX starting from Philippe's
>> macros. The one systemic issue I encountered so far is tables, which in
>> LaTeX must set the number of columns in advance.
>>
>> Andrei
> 
> Heh, here's the first thing that I actually got to compile error-free from 
> spec.dd and lex.dd: http://erdani.com/d/dlangspec.pdf. Had to fudge a few 
> macros and some stuff doesn't expand to what it should, but from here the 
> path is relatively easy.
> 
> Andrei
> 

wkhtmltopdf v0.11.0 (static)
https://code.google.com/p/wkhtmltopdf/

Converts html files into pdf, generating a toc index, and accepts css!

An example built in Linux 64-bit:
http://d-packages.googlecode.com/files/dlangspec-2.pdf

-- 
Jordi Sayol

Re: dlangspec.pdf?

[Era Scarecrow]

On Tuesday, 8 January 2013 at 03:45:36 UTC, Jordi Sayol wrote:

wkhtmltopdf v0.11.0 (static)
https://code.google.com/p/wkhtmltopdf/

Converts html files into pdf, generating a toc index, and 
accepts css!


An example built in Linux 64-bit:
http://d-packages.googlecode.com/files/dlangspec-2.pdf


 Glanced it over and it looks nice. :)

Re: Mac OS installer

[Joshua Niehus]

On Tuesday, 8 January 2013 at 04:00:25 UTC, Elias Zamaria wrote:

Can anyone help me with this?


Do you have Xcode installed?
If so, do you have "Command Line Tools" installed?
Otherwise, you'll need to install Xcode (free from app store), 
then:
Open Xcode -> Preferences -> Downloads -> Components -> Command 
Line Tools


related thread:
http://forum.dlang.org/thread/nxawipcegdmbkqkal...@forum.dlang.org

Re: manual memory management

[H. S. Teoh]

On Tue, Jan 08, 2013 at 02:57:31AM +0100, Rob T wrote:
[...]
> So if the GC cannot be removed fully, then there's no point trying
> to fully remove it, and performance issues have to be solved through
> improving the GC implementation, and also with better selective
> manual control methods.

I know people *have* tried to use D without GC-dependent features; it
would be great if this information can be collected in one place and put
into the official docs. That way, people who are writing game engines or
real-time code know what to do, and the other 90% of coders can just
continue using D as before.


> As for the claims made that D's GC is "optional", that message is
> coming from various sources one encounters when reading about D for
> the first time.
> 
> For example:
> http://www.drdobbs.com/tools/new-native-languages/232901643
> "D has grown to embrace a wide range of features — optional memory
> management (garbage collection), ..."
> 
> Sure you can "optionally" disable the GC, but it means certain
> fundamental parts of the language will no longer be usable, leading
> to misconceptions that the GC is fully optional and everything can
> be made to work as before.

Does Dr. Dobbs allow revisions to previously published articles? If not,
the best we can do is to update our own docs to address this issue.


> I know D's documentation is *not* claiming that the GC is optional,
> you get that impression from reading external sources instead, however
> it may be a good idea to counter the possible misconception in the
> FAQ.

Yeah that's a good idea.


> Improved documentation will also help those who want to do selective
> manual memory management. As it is, I cannot say for certain what
> parts of the language require the use of the GC because the
> specification either leaves this information out, or is not specified
> clearly enough.
[...]

I don't know if I know them all, but certainly the following are
GC-dependent:

- Slicing/appending arrays (which includes a number of string
  operations), .dup, .idup;
- Delegates & anything requiring access to local variables after the
  containing scope has exited;
- Built-in AA's;
- Classes (though I believe it's possible to manually manage memory for
  classes via Phobos' emplace), including exceptions (IIRC);
- std.container (IIRC Andrei was supposed to work on an allocator model
  for it so that it's usable without a GC)

AFAIK, the range-related code in Phobos has been under scrutiny to
contain no hidden allocations (hence the use of structs instead of
classes for various range constructs). So unless there are bugs,
std.range and std.algorithm should be safe to use without involving the
GC.

Static arrays are GC-free, and so are array literals (I *think*) as long
as you don't do any memory-related operation on them like appending or
.dup'ing. So strings should be still somewhat usable, though quite
limited. I don't know if std.format (including writefln & friends)
invoke the GC -- I think they do, under the hood. So writefln may not be
usable, or maybe it's just certain format strings that can't be used,
and if you're careful you may be able to pull it off without touching
the GC.

AA literals are NOT safe, though -- anything to do with built-in AA's
will involve the GC. (I have an idea that may make AA literals usable
without runtime allocation -- but CTFE is still somewhat limited right
now so my implementation doesn't quite work yet.)

But yeah, it would be nice if the official docs can indicate which
features are GC-dependent.


T

-- 
Latin's a dead language, as dead as can be; it killed off all the
Romans, and now it's killing me! -- Schoolboy

Re: manual memory management

[Rob T]

On Tuesday, 8 January 2013 at 02:06:02 UTC, Brad Roberts wrote:
There's some issues that can rightfully be termed "caused by 
the GC", but
most of the performance issues are probably better labled 
"agregious use
of short lived allocations", which cost performance regardless 
of how
memory is managed.  The key difference being that in manual 
management the
impact is spread out and in periodic garbage collection it's 
batched up.


My primary point being, blaming the GC when it's the 
application style
that generates enough garbage to result in wanting to blame the 
GC for the

performance cost is misplaced blame.

My 2 cents,
Brad


There's more to it than just jerkiness caused by batching. The GC 
will do collection runs at inappropriate times, and that can 
cause slow downs well in excess of an otherwise identical 
application with manual memory management. For example, I've seen 
3x performance penalty caused by the GC doing collection runs at 
the wrong times. The fix required manually disabling the GC 
during certain points and re-enabling afterwards.


The 2 or 3 lines of extra code I inserted to fix the 3x 
performance penalty was a lot easier than performing full manual 
management, but it means that you cannot sit back and expect the 
GC to always do the right thing.


--rt

Re: dlangspec.pdf?

[Philippe Sigaud]

On Tue, Jan 8, 2013 at 5:02 AM, Era Scarecrow  wrote:

> On Tuesday, 8 January 2013 at 03:45:36 UTC, Jordi Sayol wrote:
>
>> wkhtmltopdf v0.11.0 (static)
>> https://code.google.com/p/**wkhtmltopdf/
>>
>> Converts html files into pdf, generating a toc index, and accepts css!
>>
>> An example built in Linux 64-bit:
>> http://d-packages.googlecode.**com/files/dlangspec-2.pdf
>>
>
>  Glanced it over and it looks nice. :)
>

It indeed looks very nice. If the entire content is here, it should be made
downloadable, as the .mobi version.

Re: shared gitconfig

[Vladimir Panteleev]

On Tuesday, 8 January 2013 at 01:54:43 UTC, Andrei Alexandrescu 
wrote:

On 1/6/13 3:41 PM, Jonathan M Davis wrote:
I'm arguing that people should actually learn how to use git 
properly rather

than creating crutches for themselves.


False choice.


Yet one should come before the other.


The more you try and do with git
without learning it properly, the more problems you're likely 
to run into
(e.g. by running commands that you don't entirely understand 
and ending up
with nasty side effects). So, I think that it's just plain bad 
practice to

create such macros.


I know how the shell works quite well but that doesn't stop me 
from writing scripts and aliases.


This boils down to advocating one needs to type by hand 
sequences of commands instead of defining higher-level scripts 
that have a cohesive meaning.


Such as?

Points:
1. If everyone needed to type the same sequences of commands all 
the time, git by itself would be a rather poor tool.
2. Automating commands that destroy (or move in a hard-to-reach 
place) user data has obvious consequences.
3. Your workflow may be different from the typical user's. I 
agree that untypical usage (e.g. a project maintainer's) might 
benefit from some automation.
4. Your workflow might be suboptimal (due to incomplete knowledge 
of git).


Enumerate some actions that you have to resort to typing series 
of commands to perform, and let's examine solutions. I'll reply 
to your original problem with a better solution, as well.

Re: shared gitconfig

[Vladimir Panteleev]

On Sunday, 6 January 2013 at 19:50:47 UTC, Andrei Alexandrescu 
wrote:
For example, I tried today to get the latest and greatest 
phobos into my repo, and got a bunch of conflicts. I searched a 
while on the net to figure what the command for "just get the 
latest remote into my local copy", which is entirely possible 
but not obvious and not easy to find.


#!/bin/bash

# Add untracked files to the index, so they're stashed and 
deleted.
# This gives us a cleaner directory, and avoids possible 
collisions with files that are currently untracked, but are 
tracked in master.

git add --all .

# Saves any changes in the working tree or index, if any, as a 
stash.

git stash save "Automatic save before switching to latest master"

# Now that the working tree is clean, switch to whatever the 
"master" branch is currently.

git checkout master

# Reset the master branch to point to the remote's tracking 
branch.
# This allows the merge implied by "git pull" to be a 
fast-forward.

git reset --hard origin/master

# Download new objects, update tracking branch, fast-forward 
current branch to tracking branch.

git pull

# End

This script assumes that the branch you want is "master", and 
that the remote is called "origin".


Do not invoke the script directly. Rather, create an alias in 
your .gitconfig which launches the script. This will allow it to 
work correctly even from a subdirectory in the project.


Instructions to recover data from accidental usage of this script:

To find what branch (or commit, with detached HEAD) you were on 
before the switch to master, check the output of `git reflog 
HEAD`. It should look something like this:


eb5121f HEAD@{0}: pull: Fast-forward
8e7ed2b HEAD@{1}: reset: moving to origin/master
d49acd5 HEAD@{2}: checkout: moving from foo to master
ecdc09c HEAD@{3}: ...
...

The commit you were on should be below the line the description 
of which starts with "checkout:".


Uncommitted data in your index or working tree will be in the git 
stash. Use `git stash apply` to apply the patch to the current 
working tree.


The script could be improved to be a little more efficient (e.g. 
avoid checking out the old master), or less noisy or reliant on 
the environment (e.g. detecting the name of the remote).

Re: shared gitconfig

[Andrei Alexandrescu]

On 1/7/13 10:56 PM, Vladimir Panteleev wrote:

On Sunday, 6 January 2013 at 19:50:47 UTC, Andrei Alexandrescu wrote:

For example, I tried today to get the latest and greatest phobos into
my repo, and got a bunch of conflicts. I searched a while on the net
to figure what the command for "just get the latest remote into my
local copy", which is entirely possible but not obvious and not easy
to find.


#!/bin/bash

[snip]

This script is bad because it does not do any meaningful error handling 
and offers no good explanation on how to proceed if either step fails. 
If you thought I had this kind of style in mind, I agree that using such 
scripts is a terrible idea.


Andrei

Re: Mac OS installer

[Jacob Carlborg]

On 2013-01-08 05:57, Joshua Niehus wrote:

On Tuesday, 8 January 2013 at 04:00:25 UTC, Elias Zamaria wrote:

Can anyone help me with this?


Do you have Xcode installed?
If so, do you have "Command Line Tools" installed?
Otherwise, you'll need to install Xcode (free from app store), then:
Open Xcode -> Preferences -> Downloads -> Components -> Command Line Tools


He's running Mac OS X 10.6 with a pretty old version of Xcode, i.e. 
before App Store. This version of Xcode installs the command line tools 
when Xcode itself is installed.


--
/Jacob Carlborg