Tips for debugging EXC_BAD_ACCESS

[Jacob Carlborg]

I didn't have any luck with this in the learn newsgroup so I'm trying here.

I'm trying to debug the Mac OS X port of DWT. Almost as soon as a DWT 
application starts to process events I receive a segmentation fault. The 
error happens in the "objc_msgSend" C function when calling an 
Objective-C method. GDB backtrace:


http://pastebin.com/0fmUmPQ1

The source code of DWT is located here:

https://github.com/d-widget-toolkit/dwt-mac

The error happens at this call:

https://github.com/d-widget-toolkit/dwt-mac/blob/master/dwt/widgets/Shell.d#L1874

Which calls:

https://github.com/d-widget-toolkit/dwt-mac/blob/master/dwt/widgets/Widget.d#L1824

Then:

https://github.com/d-widget-toolkit/dwt-mac/blob/master/dwt/widgets/Widget.d#L230

Some other points of interest:

https://github.com/d-widget-toolkit/dwt-mac/blob/master/dwt/widgets/Display.d#L4871

https://github.com/d-widget-toolkit/dwt-mac/blob/master/dwt/widgets/Shell.d#L1818

https://github.com/d-widget-toolkit/dwt-mac/blob/master/dwt/widgets/Display.d#L4501

https://github.com/d-widget-toolkit/dwt-mac/blob/master/dwt/widgets/Display.d#L4367

--
/Jacob Carlborg

Re: #pragma comment (lib, ...)

[Arjan]

On Wed, 10 Oct 2012 16:32:05 +0200, Paulo Pinto   
wrote:



On Wednesday, 10 October 2012 at 14:44:20 UTC, Walter Bright wrote:

On 10/10/2012 4:49 AM, Paulo Pinto wrote:

On Wednesday, 10 October 2012 at 11:50:29 UTC, Manu wrote:
Really? Is it an MS thing? I'm amazed the other compilers haven't  
adopted

that in the last 10 years or whatever.


Yes, it is a Microsoft extension. I never saw it in any other C or C++  
compiler.


Digital Mars C and C++ !!


I only became aware of Digital Mars thanks to D, I must confess.

When I moved away from Turbo Pascal, I started using Turbo C and Turbo  
C++, followed by Borland C++ and eventually Visual C++.


Then at the university I started to use vendor's C and C++ compilers of  
the multiple UNIX systems we had access to.


I used to see adverts for Watcom C/C++, High C/C++ and Zortech C/C++ in  
computer magazines, but never knew anyone that had access to them.




You really missed something. For years Zortech/Sysmantec/DigitalMars C++  
has been my preferred compiler. Generated fast code very fast! With being  
STLport'ed it also had decent support for STL. It often times barked about  
issues with Type checking other compilers did not even mention. Which  
saved me from quite a few bugs.
When porting big C++ libraries like wxWidgets (then wxWindows) it became  
apparent to me DMC++ did need the least special treatment to make it  
compile the code. Also ported various Boost libs to it.

It wasn't util VS2005 came along before I started shifting away...

About Watcom? Well a complete opposite experience...

Arjan

Re: #pragma comment (lib, ...)

[Jacob Carlborg]

On 2012-10-11 04:54, Jesse Phillips wrote:


I don't see why, I'm the programmer I'd have to tell the package manager
what version I'm using... and again I don't know what it is. I'd think
pragma(lib) + package manager would get along nicely.


You don't know what version of a library you're using? That sounds 
pretty bad. Sure you might not need to know which version of a system 
library you're using but you should really know the version of all third 
party libraries you're using. Otherwise there's a huge risk of things 
starting to break.


What about any other compile or link flags, do you keep them in a 
separate file? Why would you keep half of the flags in one file and the 
other half in another file?



"Hi there, I need this library." says the source file.

"Hmm, ok, let me get this version as I've been instructed to do so."
replies the PM.

"Hey, what about me... lib..." says a close friend.

"Yeah, yeah, let me see... how does the latest version sound/what is
installed? I don't know what you need but we can give this a try." sadly
replies the PM.


So it just picks a random version, that doesn't sound like very good 
behavior.



"Mister programmer man, you have unspecified library versions for...
What do would you like to do with them? Did the currently selected
version work out for you?" The PM tells the programmer.


So this is just a guessing game, trail and error?

I think it would be much better to work with packages and not individual 
libraries. You would just tell the build tool, compiler or whatever to 
use package "foo". Then the package manager figures out what libraries 
and dependencies it needs to link to and also the path to the import files.


--
/Jacob Carlborg

Re: #pragma comment (lib, ...)

[Jacob Carlborg]

On 2012-10-11 01:18, Walter Bright wrote:


Not that easy. You'd have to do it also with the objects pulled in from
library files. Essentially, you have to implement most of the linker to
do that.

Not worth it.


Maybe it's time to update the old tool chain that we inherited form the 
70s, but this is a totally different discussion.


--
/Jacob Carlborg

Re: #pragma comment (lib, ...)

[Jacob Carlborg]

On 2012-10-11 04:54, Jesse Phillips wrote:

On Wednesday, 10 October 2012 at 19:21:58 UTC, Jacob Carlborg wrote:

On 2012-10-10 17:00, Jesse Phillips wrote:

As for versions. I don't know what version of ole32.dll I'm using or how
to find out, I don't really care either. But I guess it would be good to
have the option though.


A package manager would be the solution for that.


I don't see why, I'm the programmer I'd have to tell the package manager
what version I'm using... and again I don't know what it is. I'd think
pragma(lib) + package manager would get along nicely.

"Hi there, I need this library." says the source file.

"Hmm, ok, let me get this version as I've been instructed to do so."
replies the PM.

"Hey, what about me... lib..." says a close friend.

"Yeah, yeah, let me see... how does the latest version sound/what is
installed? I don't know what you need but we can give this a try." sadly
replies the PM.

"Mister programmer man, you have unspecified library versions for...
What do would you like to do with them? Did the currently selected
version work out for you?" The PM tells the programmer.


Also see my other post:

http://forum.dlang.org/thread/mailman.695.1349857389.5162.digitalmar...@puremagic.com?page=3#post-k54hng:241rra:241:40digitalmars.com

--
/Jacob Carlborg

List of reserved words

[Jacob Carlborg]

On dlang.org there's a page containing all the keywords, which are reserved:

http://dlang.org/lex.html

But it would also be nice to have a list of words/symbols that are not 
keywords but could otherwise be thought of being reserved. These are 
words that will make it problematic if used in user code in the wrong 
context. I thinking mostly of naming a module "object" or a class 
"Object", the compiler will not be happy seeing that.


What other "reserved" words like these does D have?

--
/Jacob Carlborg

Re: Any interest in libgit bindings?

[Jacob Carlborg]

On 2012-10-10 23:04, Andrej Mitrovic wrote:


Mine compiles but I'll have to reference some inlined functions since
they're not exported in the DLL. Yours looks very similar (you almost
can't go wrong with generating C bindings, it's very easy compared to
C++).


Yeah, I haven't done anything about inline functions yet. Another think 
I haven't been able to figure out yet is to how to properly translate 
include directives. It's not easy to translate to the module system used 
by D.



Btw, you should try to rename a module from 'object' to '_object' or
similar, otherwise it might conflict with the implicitly imported
object module in druntime. Walter flagged this as wontfix
(http://d.puremagic.com/issues/show_bug.cgi?id=7651).


Right, I missed that. It's easy to forget this kind of symbols, they're 
not really keywords but they are kind of reserved words. Any other 
symbols behaving like this I could have missed?


--
/Jacob Carlborg

Emacs D Mode

[Russel Winder]

Quick question, the answers to which will help determine strategy and
policy.

Those people using Emacs and D Mode, are you using a downloaded copy of
a release tarball/zip or are you working with a clone of the mainline
Git repository https://github.com/Emacs-D-Mode-Maintainers/Emacs-D-Mode

If the former then the maintainers need to set up an efficient release
and distribution mechanism, if the latter then we can assume a
continuous deployment and not worry about releases.

Please feel free to email me directly offlist.

Thanks.
-- 
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: DIP20: Volatile read/write intrinsics

[Alex Rønne Petersen]

On 11-10-2012 07:14, Chad J wrote:

On 10/10/2012 02:31 PM, Alex Rønne Petersen wrote:

http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP20

This supersedes DIP17.

The primary reason to use intrinsics instead of something built into the
language is that the latter is too complex for current (and likely also
future) compiler implementations.

Destroy!



Since this can affect semantics but might not always be available, is
there any chance you could add a feature detection intrinsic for this?
Maybe a compile-time "haveVolatileOps" identifier would work.

Volatility might be absent if:
- The backend target can't forward the volatility guarantees, ex: a D
compiler that emits JavaScript code.
- The compiler has not implemented volatile operations yet.


I suppose a simple D_Volatile version identifier will do, like we have 
D_SIMD for core.simd.__simd.


--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Re: DIP20: Volatile read/write intrinsics

[Chad J]

On 10/10/2012 02:31 PM, Alex Rønne Petersen wrote:

http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP20

This supersedes DIP17.

The primary reason to use intrinsics instead of something built into the
language is that the latter is too complex for current (and likely also
future) compiler implementations.

Destroy!



Since this can affect semantics but might not always be available, is 
there any chance you could add a feature detection intrinsic for this? 
Maybe a compile-time "haveVolatileOps" identifier would work.


Volatility might be absent if:
- The backend target can't forward the volatility guarantees, ex: a D 
compiler that emits JavaScript code.

- The compiler has not implemented volatile operations yet.

Re: Nested functions should be exempt from sequential visibility rules

[stas]

The most flexible method is to declare a local, nested struct.

... it's an awesome solution.


It is a solution, but IMO it looks unpleasant.
Reminds me C++, where I had to do this trick all the time.


It's a morass of special cases.


If D had a notion of pure pure functions - pure functions without 
any "concessions to practicality" then we could consider this 
simple rule:

"local pure pure functions can be forward referenced".

Re: #pragma comment (lib, ...)

[Jesse Phillips]

On Wednesday, 10 October 2012 at 19:21:58 UTC, Jacob Carlborg 
wrote:

On 2012-10-10 17:00, Jesse Phillips wrote:
As for versions. I don't know what version of ole32.dll I'm 
using or how
to find out, I don't really care either. But I guess it would 
be good to

have the option though.


A package manager would be the solution for that.


I don't see why, I'm the programmer I'd have to tell the package 
manager what version I'm using... and again I don't know what it 
is. I'd think pragma(lib) + package manager would get along 
nicely.


"Hi there, I need this library." says the source file.

"Hmm, ok, let me get this version as I've been instructed to do 
so." replies the PM.


"Hey, what about me... lib..." says a close friend.

"Yeah, yeah, let me see... how does the latest version sound/what 
is installed? I don't know what you need but we can give this a 
try." sadly replies the PM.


"Mister programmer man, you have unspecified library versions 
for... What do would you like to do with them? Did the currently 
selected version work out for you?" The PM tells the programmer.

Re: Any interest in libgit bindings?

[alexhairyman]

On Tuesday, 9 October 2012 at 23:10:39 UTC, Andrej Mitrovic wrote:

http://libgit2.github.com/

libgit has things like clone/commit/tag, reading/writing git 
loose
object files. You can easily deflate object files using 
std.zlib, but
unfortunately there's no git pack file unpacker in libgit (you 
can

externally use git's unpack-objects command for that).

I don't know whether dstep[1] can autogenerate the bindings 
(haven't

tried it myself), any luck there from anyone?

My dgen generator (unreleased) can generate bindings but it's a
C++-based generator so the generated files aren't pure 1to1 
bindings
since forwarding functions were automatically generated (this 
is an
implementation detail of the generator that can and will be 
fixed).


win32-based bindings are here, along with somewhat ported 
samples (a

little hardcoded but things generally work):
https://github.com/AndrejMitrovic/dgen_libgit

But if there's any interest I could clean it up and make it a 
nice

simple C wrapper just like the other deimos projects
(https://github.com/D-Programming-Deimos). If Dstep can do it
automatically even better, but I didn't get to use it yet.

[1] https://github.com/jacob-carlborg/dstep/


I think this would be cool :D

Re: Any interest in libgit bindings?

[Andrej Mitrovic]

On 10/11/12, Craig Dillabaugh  wrote:
> Likely you have already tried this but just in case not ...
>
> For Linux is /usr/local/lib in your  /etc/ld.so.conf file?
> If not, add it and run ldconfig.

Thanks! That did the trick, it's linking now.

I'll do a few verification tests and then post the bindings to d.announce later.

Re: Any interest in libgit bindings?

[Craig Dillabaugh]

On Thursday, 11 October 2012 at 01:39:46 UTC, Andrej Mitrovic
wrote:

On 10/10/12, Jacob Carlborg  wrote:

I would absolutely have interest in this.


https://github.com/AndrejMitrovic/dgen_libgit

Well it's mostly done (can't tell if anything is missing, 
except the
docs). I had to reimplement inline functions in D since they're 
not
exported on the C side (maybe -fkeep-inline-functions could 
work on
Posix but it doesn't on Windows). I don't know of a 
non-intrusive way
to work around this so I copy-pasted the functions to D and 
made them

compilable.

I'll put an extern(C) at the top later to replace all the 
extern(C)
declarations, but that's just a styling issue that's easily 
fixed.


But I can't get it to link with libgit on Linux though. After
compiling and installing libgit (which copied the shared lib to
/usr/local/lib), I've tried:

$ cd samples/diff
$ rdmd --force -L-L/usr/local/lib -L-lgit2 -I../../src diff.d

/tmp/.rdmd-1000/rdmd-diff.d-572543621CF312EC72273F3DB4C6B8BE/diff:
error while loading shared libraries: libgit2.so.0: cannot open 
shared

object file: No such file or directory

I never have luck with Posix. :)

This is from branch 'development', commit
acd1700630ea1159a55dc5e8cee12e4a725afe18 from
https://github.com/libgit2/libgit2/

Instructions on building libgit2 are here: 
http://libgit2.github.com/#install


Likely you have already tried this but just in case not ...

For Linux is /usr/local/lib in your  /etc/ld.so.conf file?
If not, add it and run ldconfig.

Craig

Re: What is the case against a struct post-blit default constructor?

[Malte Skarupke]

Hi, thanks for the detailed answers.

So I am very much for keeping init. I just want that if the user 
specifies a default constructor, it is being called after the 
value has been initialized to init.



On Wednesday, October 10, 2012 21:11:29 foobar wrote:

Arrays - without changing existing syntax we can use these
semantics:

auto a = new int[](5); // compiler calls T() for each instance
int[12] b; // ditto


And what on earth does that buy you over init? That's what init 
_does_. And
since the value needs to be known at compile time (otherwise 
arrays won't work
for directly initializing _anything_ that needs to be 
initialized at compile
time), a constructor really doesn't buy you anything here at 
all. init
provides a nice, consistent way of initializing or assigning a 
value to a
variable as well as providing a consistent default state for a 
type when you
need to be able to set a variable of that type to a consistent, 
safe state
(e.g. with std.algorithm.move). And as built-in types don't 
_have_
constructors, there's no other way for generic code to 
generically initialize

anything.


"What does this buy you over init?" This would help with structs 
that can't be initialized to a valid value at compile time.

So what I expect to happen in a line like
S[12] s;
Is that they all get blitted to init, followed by a loop that 
calls the default constructor on each of these. If there is no 
default constructor, they stay at init and the loop doesn't 
happen.

This would work with user defined types and with built-in types.
If a constructor throws an exception, then the array is correctly 
initialized up to the element before the throwing one. The 
remaining elements are at init.


For member variables I expect this to happen:
If one of your member variables has a default constructor but you 
do not, then the compiler will generate an empty default 
constructor for you. This gives your object the same behavior in 
arrays as described above, which means that the member variable 
will always be correctly initialized using both init and the 
deafult constructor.
If one of your member variables has a default constructor, and so 
do you, then the member variable's default constructor is called 
before your default constructor.
If an exception is thrown, the containing object remains at the 
state it is in (most likely init)
If you do not want the default constructor of your member 
variable to be called, you can declare it as S s = S.init;


For emplace I expect that the default constructor gets called.

For std.algorithm.move you'd have to define which state the 
source object is in after moving. Since it's a destructive move, 
I'd expect the object to be at init, as if a destructor had been 
called. You could implement that with a tiny change to the 
current implementation. (memcpy from init instead of a statically 
allocated instance)


This should cover all the cases that you mentioned. It is highly 
performant (in fact this is very close to the behavior in C++, 
but faster because it uses init) and it won't affect structs that 
can be initialized at compile time. It will only be used for 
cases where you need to do things at runtime, and the users have 
the full ability to shoot themselves in the foot if they want to.

Re: Any interest in libgit bindings?

[Andrej Mitrovic]

On 10/10/12, Jacob Carlborg  wrote:
> I would absolutely have interest in this.

https://github.com/AndrejMitrovic/dgen_libgit

Well it's mostly done (can't tell if anything is missing, except the
docs). I had to reimplement inline functions in D since they're not
exported on the C side (maybe -fkeep-inline-functions could work on
Posix but it doesn't on Windows). I don't know of a non-intrusive way
to work around this so I copy-pasted the functions to D and made them
compilable.

I'll put an extern(C) at the top later to replace all the extern(C)
declarations, but that's just a styling issue that's easily fixed.

But I can't get it to link with libgit on Linux though. After
compiling and installing libgit (which copied the shared lib to
/usr/local/lib), I've tried:

$ cd samples/diff
$ rdmd --force -L-L/usr/local/lib -L-lgit2 -I../../src diff.d

/tmp/.rdmd-1000/rdmd-diff.d-572543621CF312EC72273F3DB4C6B8BE/diff:
error while loading shared libraries: libgit2.so.0: cannot open shared
object file: No such file or directory

I never have luck with Posix. :)

This is from branch 'development', commit
acd1700630ea1159a55dc5e8cee12e4a725afe18 from
https://github.com/libgit2/libgit2/

Instructions on building libgit2 are here: http://libgit2.github.com/#install

Re: #pragma comment (lib, ...)

[Walter Bright]

On 10/10/2012 11:56 AM, Dmitry Olshansky wrote:

BTW making the smart linker driver should be relatively easy: just get the
special section contents out of passed object files and turn that into a full
blown set of flags for a dumb linker.


Not that easy. You'd have to do it also with the objects pulled in from library 
files. Essentially, you have to implement most of the linker to do that.


Not worth it.

Re: GC statistics

[deadalnix]

Le 10/10/2012 21:11, Andrei Alexandrescu a écrit :

This is mostly for GC experts out there - what statistics are needed and
useful, yet not too expensive to collect?

https://github.com/D-Programming-Language/druntime/pull/236


Andrei


Number of collections (full and young if it is appropriate), maximum 
time of pause induced, average time of pause.


Size of different heap parts if it is appropriate.

All are not expansive to compute.

Re: Any interest in libgit bindings?

[Andrej Mitrovic]

On 10/10/12, Jacob Carlborg  wrote:
> This is the output of dstep on all files in libgit2/include:
> https://dl.dropbox.com/u/18386187/libgit2.zip
>
> I have no idea if it compiles.

Yeah, after incorporating some C shortcuts mine is now similar to
yours: https://github.com/AndrejMitrovic/dgen_libgit/tree/master/out/d/git2

Mine compiles but I'll have to reference some inlined functions since
they're not exported in the DLL. Yours looks very similar (you almost
can't go wrong with generating C bindings, it's very easy compared to
C++).

Btw, you should try to rename a module from 'object' to '_object' or
similar, otherwise it might conflict with the implicitly imported
object module in druntime. Walter flagged this as wontfix
(http://d.puremagic.com/issues/show_bug.cgi?id=7651).

Re: What is the case against a struct post-blit default constructor?

[Jonathan M Davis]

On Wednesday, October 10, 2012 22:40:50 Jonathan M Davis wrote:
> D's use of init is far superior to either C++ or Java's approach IMHO. But
> regardless of its various pros or cons, it's here to stay.

Something to remember here is that there are multiple ways to solve some of 
these problems. Each has their pros and cons. D has gone with init and IMHO 
greatly from it. You can undoubtedly find alternate ways to deal with pretty 
much every use case for init. After all, other languages went with other 
solutions (each with their own pros and cons). But init is what D chose to go 
with, so regardless of whether it's the best choice or not, it's what we have, 
and it's far too late to change it now.

So, while you may prefer another solution, because you prefer a different set 
of pros and cons, that doesn't mean that D's choice was a bad one. It just 
means that what it prioritizes isn't necessarily the same as what you 
prioritize.

- Jonathan M Davis

Re: What is the case against a struct post-blit default constructor?

[Jonathan M Davis]

On Wednesday, October 10, 2012 21:11:29 foobar wrote:
> Arrays - without changing existing syntax we can use these
> semantics:
> 
> auto a = new int[](5); // compiler calls T() for each instance
> int[12] b; // ditto

And what on earth does that buy you over init? That's what init _does_. And 
since the value needs to be known at compile time (otherwise arrays won't work 
for directly initializing _anything_ that needs to be initialized at compile 
time), a constructor really doesn't buy you anything here at all. init 
provides a nice, consistent way of initializing or assigning a value to a 
variable as well as providing a consistent default state for a type when you 
need to be able to set a variable of that type to a consistent, safe state 
(e.g. with std.algorithm.move). And as built-in types don't _have_ 
constructors, there's no other way for generic code to generically initialize 
anything.

> I don't get this example. If foo throws than the calling code
> will get control. How would you ever get to read that garbage in
> aa[5]? The surrounding try catch block should take care of this
> explicitly anyway.
> 
> E.g.
> try {
> aa[5] = foo(); // foo throws
> // ## do something with aa[5], this won't happen
> } catch {
> // Please handle aa[5] here explicitly.
> //
> }
> // @@ do something with aa[5], works due to the explicit fix in
> the catch.

It's a compiler (druntime?) bug. T.init is inserted at aa[5] regardless of 
whether foo() returns or not. It's just the assigned to the correct result of 
foo succeeds. So, if an exception is thrown, you end up with a value at aa[5] 
when you're not supposed to:

http://d.puremagic.com/issues/show_bug.cgi?id=3825

The fact that we have init saves us from it being set to garbage. In general, 
having init saves us from garbage where someone screws up, making behavior 
deterministic and therefore more easily caught, debugged, and fixed. It also 
saves us from the compiler complaining about stuff not being initialized when 
it really was like Java does.

> Isn't @disable breaks those algorithms in phobos anyway?

Which is why @disable is kind of a sucky idea. But as long as init exists for 
a type, functions such as std.algorithm.move can use it. Without it, they're 
pretty much screwed. So, using @disable will restrict what you can do with a 
type, but it least sane types can take advantage of such functions. Without 
init, _none_ could, or if they did, it would be unsafe.

> To answer the above question, I'd say there's nothing wrong with
> init to void. This is what happens anyway since the .init isn't
> used and the optimizer will optimize it away.

Using void is dangerous and should be avoided unless absolutely necessary, 
otherwise you run a high risk of ending up with garbage values, giving you 
non-determinstic behavior, which tends to lead to very nasty, hard-to-find 
bugs.

> Again, thanks for the explanation. I have to say that on a
> general level I have to agree with Don's post and I don't see how
> the .init idiom generally "works" or is useful. I can't see
> anything in the above examples that shows that .init is
> absolutely required and we can't live without it. The only thing
> that worries me here is the reliance of the runtime/phobos on
> .init.

init avoids all kind of initialization problems and is an absolute godsend for 
generic code - so much so that letting it be used for compile time reflection 
and type inferrence even when disabled (though it still couldn't be used in 
actual code) is under discussion. It would actually be pretty bad not to have 
init (which is why @disable sucks). I, for one, am _very_ glad that we have 
init. I'm guessing that you haven't written much generic code in D if you 
think that init should go away. You pretty much _need_ something like init for 
a lot of the stuff that you have to do in template constraints and whatnot.

D's use of init is far superior to either C++ or Java's approach IMHO. But 
regardless of its various pros or cons, it's here to stay.

- Jonathan M Davis

Re: GC statistics

[Paulo Pinto]

On Wednesday, 10 October 2012 at 19:35:33 UTC, Andrei 
Alexandrescu wrote:
This is mostly for GC experts out there - what statistics are 
needed and useful, yet not too expensive to collect?


https://github.com/D-Programming-Language/druntime/pull/236


Andrei


Although I am not a GC expert, have you look at these examples 
already?


http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstat.html

http://golang.org/pkg/runtime/#MemStats

http://www.haskell.org/ghc/dist/current/docs/html/libraries/base-4.6.0.0/GHC-Stats.html




--
Paulo

Re: Any interest in libgit bindings?

[Jacob Carlborg]

On 2012-10-10 00:46, Andrej Mitrovic wrote:

http://libgit2.github.com/

libgit has things like clone/commit/tag, reading/writing git loose
object files. You can easily deflate object files using std.zlib, but
unfortunately there's no git pack file unpacker in libgit (you can
externally use git's unpack-objects command for that).

I don't know whether dstep[1] can autogenerate the bindings (haven't
tried it myself), any luck there from anyone?


This is the output of dstep on all files in libgit2/include:

https://dl.dropbox.com/u/18386187/libgit2.zip

I have no idea if it compiles.

--
/Jacob Carlborg

Re: What is the case against a struct post-blit default constructor?

[foobar]

Thank you for explaining.
See comments inline.

On Wednesday, 10 October 2012 at 18:12:13 UTC, Jonathan M Davis 
wrote:

On Wednesday, October 10, 2012 13:40:06 foobar wrote:

Can you please elaborate on where the .init property is being
relied on? This is an aspect of D I don't really understand.
What's the difference between a no-arg ctor and one with args 
in

relation to this requirement?


init is used anywhere and everywhere that an instance of a type 
needs to be
default-initialized. _One_ of those places is a local variable. 
Not all places
where an instance of an object needs to be created can be 
initialized by the
programmer. The prime example of this would be arrays. If you 
declare


auto i = new int[](5);

or

int[12] s;

all of the elements in the array need to be initialized or 
they'll be garbage,
and there's no way for the programmer to indicate what values 
they should be.
The whole point of init is to avoid having variables ever be 
garbage without
the programmer explicitly asking for it. And having a default 
constructor
wouldn't help one whit with arrays, because the values of their 
elements must
be known at compile time (otherwise you couldn't directly 
initialize member
variables or static variables or anything else which requires a 
value at
compile time with an array). With init, the compiler can take 
advantage of the
fact that it knows the init value at compile time to 
efficiently initialize the

array.



I understand the idea of default initialization. I was more 
interested in the machinery and implementation details :) So 
let's dive in into those details:
Arrays - without changing existing syntax we can use these 
semantics:


auto a = new int[](5); // compiler calls T() for each instance
int[12] b; // ditto

This would be same as in C++. We could also expand the syntax and 
allow:

auto b = new int[](5, 9); // init all instances to 9
auto b = new int[](5, int (int index) { return index; });
initializes each member via a function call.
This can be generalized for multi dimensions.

But even constructing objects sanely relies on init. All 
user-defined objects
are fully initialized to what their member variables are 
directly initialized
to before their constructors are even called. In the case of a 
struct, that's
the struct's init value. It's not for a class, because you 
can't have a class
separate from its reference (so it's the reference which gets 
the init value),
but the class still has a state equivalent to a struct's init 
value, and
that's the state that it has before any of its constructors are 
called.


So for classes .init is null which complicates non-nullable 
classes. It seems the "solution" (more like a hack IMO) of 
@disable _breaks_ the .init guaranty in the language.




If it weren't for that, you'd get the insanity that C++ or Java 
have with
regards to the state of objects prior to construction. C++ is 
particularly bad
in that each derived class is created in turn, meaning that 
when a constructor
is called, the object _is_ that class rather than the derived 
class that
you're ultimately constructing (which means that things can go 
horribly wrong
if you're stupid enough to call a virtual function from a 
constructor in C++).
I believe that Java handles that somewhat better, but it gets 
bizarre ordering
issues with regards to initializing member variables that cause 
problems if
you try and alter member variables from base classes inside of 
a derived
constructor. With D, the object is guaranteed to be in a sane 
state prior to

construction.



C++ is insanely bad here mainly due to [virtual?] MI which 
doesn't affect D
and Java _allows_ virtual methods in constructors, which I think 
is also "fixed" in the latest c++ standard. I don't know about 
the ordering problems you mention but AFAIK the complication 
arises with MI, not default initialization. It's just a matter of 
properly defining the inheritance semantics.




And without init, even if every place that an object is 
instantiated could be
directly initialized by the programmer (which it can't), then 
you would either
end up with garbage every time that a variable isn't directly 
initialized, or
you'd have to directly initialize them all. In order for D's 
construction
model to work, this would include directly initializing _all_ 
member variables
even if the constructor then set them to something else (which 
would actually
cause problems with const and immutable). And that would get 
_very_ annoying,
even if it would be preferable for the local variable to 
require explicit

initialization.


You talk about:
class C {
immutable T val; // what to do here?
this() { ... }
}

This can be solved be either requiring a ctor call at # or if 
none specified call T(), or we can require the init to happen in 
the ctor a-la C++ semantics.







Another case where init is required is out parameters. All out 
parameters are
set to their init value when the function is called in order to 
avoid b

GC statistics

[Andrei Alexandrescu]

This is mostly for GC experts out there - what statistics are needed and 
useful, yet not too expensive to collect?


https://github.com/D-Programming-Language/druntime/pull/236


Andrei

Re: DIP20: Volatile read/write intrinsics

[David Nadlinger]

On Wednesday, 10 October 2012 at 19:21:24 UTC, Adam D. Ruppe 
wrote:

This does bring me to a question though. What if you had:

void foo() {
   volatile_read();
}

foo();
bar();
foo();

Is the call to foo allowed to be reordered? I imagine it has to 
mark the whole call chain upwards as internally volatile too.


Function calls are never allowed to be reordered. In D, there 
might be some exceptions regarding strong purity, but the 
volatile instructions just couldn't/wouldn't be pure.


David

Re: DIP20: Volatile read/write intrinsics

[Alex Rønne Petersen]

On 10-10-2012 20:57, Adam D. Ruppe wrote:

On Wednesday, 10 October 2012 at 19:09:34 UTC, deadalnix wrote:

We discussed it quite a lot already, but I still think volatile must
be a qualifier of the memory, and not of the statement.


I barely know anything about this, but couldn't that be done as a
library type? Something like a smart pointer.

This does bring me to a question though. What if you had:

void foo() {
volatile_read();
}

foo();
bar();
foo();

Is the call to foo allowed to be reordered? I imagine it has to mark the
whole call chain upwards as internally volatile too.


Good observation!

So here's the thing: The compiler is only allowed to reorder calls to 
functions where it knows the source of the function and can thus figure 
out what it does.


So, for functions that it does not have the source code for, it must 
*never* reorder, *ever*. This is one reason volatileLoad and 
volatileWrite should not be pure: They directly affect code that 
surrounds calls to them.


For functions where the compiler does have the source code, it can 
trivially figure out if reordering is OK, based on whether there are any 
calls to volatileLoad and volatileStore somewhere down the call graph. 
It gets even easier to do these checks when inlining is involved (since 
then the volatileLoad/volatileStore calls are readily visible in context).


--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Re: #pragma comment (lib, ...)

[Jacob Carlborg]

On 2012-10-10 17:56, Walter Bright wrote:


Exactly. Embedding it in a comment section accomplishes exactly nothing
if the linker ignores it.


DMD calls the linker (or rather GCC). Just read the section and append a 
link flag. But that might turn DMD into a linker.


Again, I think all this should be handled by a build tool and a package 
manager.


--
/Jacob Carlborg

Re: #pragma comment (lib, ...)

[Adam D. Ruppe]

On Wednesday, 10 October 2012 at 19:19:12 UTC, Jacob Carlborg 
wrote:
If I recall correctly, using pragma(lib) with dmd, you need to 
specify the extension for the library, ending up with code like 
this:


Nope, the extension is optional. I never use it.


pragma(lib, "pq");

Re: #pragma comment (lib, ...)

[H. S. Teoh]

On Wed, Oct 10, 2012 at 10:56:30PM +0400, Dmitry Olshansky wrote:
> On 10-Oct-12 22:54, H. S. Teoh wrote:
> >On Wed, Oct 10, 2012 at 08:56:49AM -0700, Walter Bright wrote:
> >>On 10/10/2012 8:19 AM, Simen Kjaeraas wrote:
> >>>On 2012-10-10, 16:19, Walter Bright wrote:
> Some object module formats do not have the ability to embed a
> library reference in them. Elf (cough cough), Mach-O (wheeze)
> >>>
> >>>ELF has .comment and .note sections. While they're not exactly
> >>>intended for the purpose, they seem to fit the bill?
> >>>
> >>>It'd of course require a linker to know what to do with the data,
> >>>but it seems to me this would not interfere with other uses.
> >>
> >>Exactly. Embedding it in a comment section accomplishes exactly
> >>nothing if the linker ignores it.
> >[...]
> >
> >I thought the point was that linkers that *did* understand it will do
> >the right thing, and linkers that don't will fall back to the
> >traditional way (require specifying libraries on the command-line).
> >
> 
> BTW making the smart linker driver should be relatively easy: just
> get the special section contents out of passed object files and turn
> that into a full blown set of flags for a dumb linker.
[...]

Excellent idea!


T

-- 
Guns don't kill people. Bullets do.

Re: #pragma comment (lib, ...)

[Jacob Carlborg]

On 2012-10-10 14:59, Manu wrote:


None of those things actually embody the information about the
relationship, nor can they. The source code does, and nothing else.
Features that imply the dependency may (and often are) be disabled at
compile time.
I rather like that the compiler is able to put a note in the object file
that it depends on a particular lib, because it does.
I'm not sure how a package manager helps... What is a package manager? ;)
I'd like to hear some reasons why that is a bad or undesirable thing, or
is this just an opinion?


A package manager is a tool that downloads and installs libraries, 
application and tools, also known as packages. It also tracks and 
installs all the dependencies of a package automatically. RubyGems, 
CPAN, PEAR, npm are a couple of examples of package managers 
specifically made for a programming language.


This is my vision (simplified) of how build tool, package manager and 
the compiler work together.


# build script
package foo
package bar

files myapp/main.d

$ build myapp

The build tool "build" will read the build script and see that it has 
two dependencies: "foo" and "bar". The build tool will get information 
from the package manager about these packages. Information like the path 
to the import files/source/headers and the path to the library to link with.


The build tool will then simply invoke the compiler with the correct 
flags to be able to build and link with these libraries. The build tool 
will, of course, know the platform it runs on so it can call the 
compiler with different flags depending on the platform. On Posix it 
would probably link to "libfoo.a" where on Windows it would link to 
"foo.lib".


If I recall correctly, using pragma(lib) with dmd, you need to specify 
the extension for the library, ending up with code like this:


version (Posix)
pragma(lib, "foo.lib");

else version (Windows)
pragma(lib, "libfoo.a");

Which is just ridiculous. Sure you could change DMD to support for this. 
But what happens with dynamic libraries? .dll on Windows, .so on 
Linux/BSD and .dylib on Mac OS X. Then on Mac OS X there are various 
other types of dynamic libraries, like frameworks and bundles, with 
their own extension.


Another point is that I don't want to separate the build script. Compile 
and link flags in one file and then the libraries to link with in a 
different file? That's just stupid.


With the approach with the build tool and the package manager working 
together the build tool can also automatically specify the path to the 
import files. How would you do that in a source file? Either the 
compiler would always need to read a special file first. Or it would 
need to scan all files for a particular pragma to get the import paths. 
Then it would rescan the files again during the actual compilation.


This is a specification/description of a package manager I'm working on:

https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D

--
/Jacob Carlborg

Re: #pragma comment (lib, ...)

[Jacob Carlborg]

On 2012-10-10 16:26, Paulo Pinto wrote:


Turbo Pascal was already doing this back in 1987.

The Pascal family of languages always made me look down to C and C++
toolchains as stone age technology that I have to endure when using
those languages.

This is actually one feature that I really like in JVM/.NET worlds, even
in the native compiler versions that are available for them.


I think the Clang/LLVM tool chain is planing to do this, or already has.

--
/Jacob Carlborg

Re: DIP20: Volatile read/write intrinsics

[Alex Rønne Petersen]

On 10-10-2012 20:45, deadalnix wrote:

Le 10/10/2012 20:31, Alex Rønne Petersen a écrit :

http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP20

This supersedes DIP17.

The primary reason to use intrinsics instead of something built into the
language is that the latter is too complex for current (and likely also
future) compiler implementations.

Destroy!



We discussed it quite a lot already, but I still think volatile must be
a qualifier of the memory, and not of the statement.

In other terms, volatile should alter the way memory is read and
written, on every access to that memory. Not on a specific statement.


I have no problem with counter-proposals so long as we get the ball 
rolling. Can you write up a counter-DIP with your idea so we can get the 
various approaches clarified and figure out which one is better?


--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Re: #pragma comment (lib, ...)

[Jacob Carlborg]

On 2012-10-10 17:00, Jesse Phillips wrote:


Well, to comply with the standard it must at least ignore it.

http://dlang.org/pragma.html

I don't see this needing to be outside the source files. Actually I'd be
happy if all that was supported was exporting that information, probably
to the json. What bothers me with not having this information in the
library is that each project I create will now need to copy and paste my
lib dependencies, or the general need to remember what library is used
by a given library.

Marco,

As for versions. I don't know what version of ole32.dll I'm using or how
to find out, I don't really care either. But I guess it would be good to
have the option though.


A package manager would be the solution for that.

--
/Jacob Carlborg

Re: #pragma comment (lib, ...)

[Dmitry Olshansky]

On 10-Oct-12 22:54, H. S. Teoh wrote:

On Wed, Oct 10, 2012 at 08:56:49AM -0700, Walter Bright wrote:

On 10/10/2012 8:19 AM, Simen Kjaeraas wrote:

On 2012-10-10, 16:19, Walter Bright wrote:

Some object module formats do not have the ability to embed a library
reference in them. Elf (cough cough), Mach-O (wheeze)


ELF has .comment and .note sections. While they're not exactly intended
for the purpose, they seem to fit the bill?

It'd of course require a linker to know what to do with the data, but
it seems to me this would not interfere with other uses.


Exactly. Embedding it in a comment section accomplishes exactly
nothing if the linker ignores it.

[...]

I thought the point was that linkers that *did* understand it will do
the right thing, and linkers that don't will fall back to the
traditional way (require specifying libraries on the command-line).



BTW making the smart linker driver should be relatively easy: just get 
the special section contents out of passed object files and turn that 
into a full blown set of flags for a dumb linker.


--
Dmitry Olshansky

Re: DIP20: Volatile read/write intrinsics

[Adam D. Ruppe]

On Wednesday, 10 October 2012 at 19:09:34 UTC, deadalnix wrote:
We discussed it quite a lot already, but I still think volatile 
must be a qualifier of the memory, and not of the statement.


I barely know anything about this, but couldn't that be done as a 
library type? Something like a smart pointer.


This does bring me to a question though. What if you had:

void foo() {
   volatile_read();
}

foo();
bar();
foo();

Is the call to foo allowed to be reordered? I imagine it has to 
mark the whole call chain upwards as internally volatile too.

Re: #pragma comment (lib, ...)

[H. S. Teoh]

On Wed, Oct 10, 2012 at 08:56:49AM -0700, Walter Bright wrote:
> On 10/10/2012 8:19 AM, Simen Kjaeraas wrote:
> >On 2012-10-10, 16:19, Walter Bright wrote:
> >>Some object module formats do not have the ability to embed a library
> >>reference in them. Elf (cough cough), Mach-O (wheeze)
> >
> >ELF has .comment and .note sections. While they're not exactly intended
> >for the purpose, they seem to fit the bill?
> >
> >It'd of course require a linker to know what to do with the data, but
> >it seems to me this would not interfere with other uses.
> 
> Exactly. Embedding it in a comment section accomplishes exactly
> nothing if the linker ignores it.
[...]

I thought the point was that linkers that *did* understand it will do
the right thing, and linkers that don't will fall back to the
traditional way (require specifying libraries on the command-line).


T

-- 
The most powerful one-line C program: #include "/dev/tty" -- IOCCC

Re: DIP20: Volatile read/write intrinsics

[deadalnix]

Le 10/10/2012 20:31, Alex Rønne Petersen a écrit :

http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP20

This supersedes DIP17.

The primary reason to use intrinsics instead of something built into the
language is that the latter is too complex for current (and likely also
future) compiler implementations.

Destroy!



We discussed it quite a lot already, but I still think volatile must be 
a qualifier of the memory, and not of the statement.


In other terms, volatile should alter the way memory is read and 
written, on every access to that memory. Not on a specific statement.

DIP20: Volatile read/write intrinsics

[Alex Rønne Petersen]

http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP20

This supersedes DIP17.

The primary reason to use intrinsics instead of something built into the 
language is that the latter is too complex for current (and likely also 
future) compiler implementations.


Destroy!

--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Re: #pragma comment (lib, ...)

[Paulo Pinto]

On Wednesday, 10 October 2012 at 15:43:36 UTC, Simen Kjaeraas 
wrote:

On 2012-10-10, 16:19, Walter Bright wrote:


On 10/10/2012 4:26 AM, Manu wrote:
I think D's modules make this relationship even stronger, and 
it's a shame it's

not a standard part of D.


Some object module formats do not have the ability to embed a 
library reference in them. Elf (cough cough), Mach-O (wheeze)


ELF has .comment and .note sections. While they're not exactly 
intended

for the purpose, they seem to fit the bill?

It'd of course require a linker to know what to do with the 
data, but

it seems to me this would not interfere with other uses.

Note: The above comes from a 2-minute cursory read of the ELF 
standard,

and may thus contain errors. :p


This is how Go packages are compiled.

The compiler reads the libraries (.a, .o) for the symbol 
information of what a package exports.


--
Paulo

Re: Windows DLLs and TLS

[jerro]

i.e. I copied the GDC distribution onto the latest TDM MinGW64 
release (using the bundle installer), and it still complains 
about missing libgmp-3.dll and libppl_c-4.dll. The former DLL 
is quite easy to find in MinGW's download repository, but I 
can't find the latter DLL anywhere.


The latest TDM MinGW64 uses gcc 4.7.1 and recent MinGW GDC 
releases use GCC 4.6.1. Maybe that is causing the problem? Try 
using a TDM MinGW64 build that uses GCC 4.6.1.

Re: #pragma comment (lib, ...)

[Paulo Pinto]

On Wednesday, 10 October 2012 at 16:18:10 UTC, Manu wrote:
On 10 October 2012 16:45, Paulo Pinto  
wrote:




This only works if it is part of the language definition.

In C and C++ case I am usually against it, because I favour 
portability
over dependencies to a specific compiler vendor. Many years of 
writing

multi-platform code do leave some scars.



Errr, what? This enhanced portability, that's the point.
I've spent my career writing more cross-platform code than most 
coders
would touch in their lives, and I give thanks for the platforms 
where it is

available.
It always leads to a vastly simplified path in the build 
scripts for those
platforms that support it, and typically produces more reliable 
and
less fickle results; ie, I never experience link problems with 
those

platforms.


I never state you did not. Actually since I know you do games 
development I suspect exactly that, that you are also aware of 
such issues.




Multi-platform code always has #ifdef guards around #pragma
comment(lib,)-ing the appropriate libs for the platform which 
the code is
being built for, and that is the whole point. The code its self 
selects the

libs it depends on by simply being compiled.


I tend to push for platform specific code to have their own set 
of files, thus

minimizing preprocessor usage.

I rather have a interface.h file with corresponding 
interface_osname.cpp files.


As I mentioned in other threads, when you work with cheap 
developers the code tends to be scary, so minimizing preprocessor 
usage is a GOOD thing.





As for D, if this can be made part of the language then I see 
no big reason

against it.



Well, DMD says it is ;) .. Question is, is it technically 
possible for

other compilers to support it?


You right here, I failed to look up the language definition.

--
Paulo

Re: What is the case against a struct post-blit default constructor?

[Jonathan M Davis]

On Wednesday, October 10, 2012 13:40:06 foobar wrote:
> Can you please elaborate on where the .init property is being
> relied on? This is an aspect of D I don't really understand.
> What's the difference between a no-arg ctor and one with args in
> relation to this requirement?

init is used anywhere and everywhere that an instance of a type needs to be 
default-initialized. _One_ of those places is a local variable. Not all places 
where an instance of an object needs to be created can be initialized by the 
programmer. The prime example of this would be arrays. If you declare

auto i = new int[](5);

or

int[12] s;

all of the elements in the array need to be initialized or they'll be garbage, 
and there's no way for the programmer to indicate what values they should be. 
The whole point of init is to avoid having variables ever be garbage without 
the programmer explicitly asking for it. And having a default constructor 
wouldn't help one whit with arrays, because the values of their elements must 
be known at compile time (otherwise you couldn't directly initialize member 
variables or static variables or anything else which requires a value at 
compile time with an array). With init, the compiler can take advantage of the 
fact that it knows the init value at compile time to efficiently initialize the 
array.

But even constructing objects sanely relies on init. All user-defined objects 
are fully initialized to what their member variables are directly initialized 
to before their constructors are even called. In the case of a struct, that's 
the struct's init value. It's not for a class, because you can't have a class 
separate from its reference (so it's the reference which gets the init value), 
but the class still has a state equivalent to a struct's init value, and 
that's the state that it has before any of its constructors are called.

If it weren't for that, you'd get the insanity that C++ or Java have with 
regards to the state of objects prior to construction. C++ is particularly bad 
in that each derived class is created in turn, meaning that when a constructor 
is called, the object _is_ that class rather than the derived class that 
you're ultimately constructing (which means that things can go horribly wrong 
if you're stupid enough to call a virtual function from a constructor in C++). 
I believe that Java handles that somewhat better, but it gets bizarre ordering 
issues with regards to initializing member variables that cause problems if 
you try and alter member variables from base classes inside of a derived 
constructor. With D, the object is guaranteed to be in a sane state prior to 
construction.

And without init, even if every place that an object is instantiated could be 
directly initialized by the programmer (which it can't), then you would either 
end up with garbage every time that a variable isn't directly initialized, or 
you'd have to directly initialize them all. In order for D's construction 
model to work, this would include directly initializing _all_ member variables 
even if the constructor then set them to something else (which would actually 
cause problems with const and immutable). And that would get _very_ annoying, 
even if it would be preferable for the local variable to require explicit 
initialization.

Another case where init is required is out parameters. All out parameters are 
set to their init value when the function is called in order to avoid bugs 
caused by reading the value of an out parameter before it's set within the 
function. That wouldn't work at all without init.

One of the more annoying AA bugs makes it so that if the foo function in this 
code

aa[5] = foo();

throws, then aa[5] gets set with a init value of the element type. While this 
clearly shouldn't happen, imagine how much worse it would be if we didn't have 
init, and that element got set to garbage?

There are probably other cases that I can't think of right now where init gets 
used - probably in the runtime if nowhere else. Every place that could 
possibly result in a variable being garbage _doesn't_ result in garbage, 
because we have init.

And regardless of what the language does, there are definitely places where the 
standard library takes advantage of init. It uses it a lot for type 
inferrence, but it also uses it directly in places such as std.algorithm.move. 
Without init, it would end up dealing with garbage values. It's also a 
lifesaver in generic code, because without it, generic code _can't_ initialize 
variables in many cases. Take something like

T t;

if(cond)
{
 ...
 t = getValue();
 ...
}
else
{
 ...
 t = getOtherValue();
 ...
}

How on earth could a generic function initialize t without T.init? void? 
That's just begging for bugs when one the paths doesn't actually set t like 
it's supposed to. It doesn't know anything about the type and therefore 
doesn't know what a reasonable default value would be, so it can't possibly 
initialize t properly.

I can u

Re: Windows DLLs and TLS

[Rainer Schuetze]

On 10/10/2012 6:57 PM, Denis Shelomovskij wrote:

10.10.2012 14:50, Jakob Ovrum пишет:

On Tuesday, 9 October 2012 at 17:45:07 UTC, Denis Shelomovskij wrote:

In your `bugdist.rar` bug.dll is fully in this {c|t}rap:
http://d.puremagic.com/issues/show_bug.cgi?id=8130

And I have already mentioned it, but you answered "I am using a .def
file".


Sorry, I was under the impression that VisualD automatically generated
and included a .def file, but indeed it doesn't. Adding the barebones
.def file fixed the problem. Thanks!



It is clearly mentioned in Issue 8130 description that such fixing on
IDE level is one of the solutions of the issue. Probably you'd better to
read better things you was advised to read.



I'll add a .def file to the default DLL project in Visual D...

Re: Windows DLLs and TLS

[Denis Shelomovskij]

10.10.2012 14:50, Jakob Ovrum пишет:

On Tuesday, 9 October 2012 at 17:45:07 UTC, Denis Shelomovskij wrote:

In your `bugdist.rar` bug.dll is fully in this {c|t}rap:
http://d.puremagic.com/issues/show_bug.cgi?id=8130

And I have already mentioned it, but you answered "I am using a .def
file".


Sorry, I was under the impression that VisualD automatically generated
and included a .def file, but indeed it doesn't. Adding the barebones
.def file fixed the problem. Thanks!



It is clearly mentioned in Issue 8130 description that such fixing on 
IDE level is one of the solutions of the issue. Probably you'd better to 
read better things you was advised to read.


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

Re: Any interest in libgit bindings?

[Andrej Mitrovic]

On 10/10/12, Justin Whear  wrote:
> I'd be interested.  I hand-wrote bindings to most of libgit2 (though not
> the latest version), but I skipped most of the write-oriented stuff, so a
> complete binding would be welcome.

Well the master branch was last updated 8 months ago and the libgit
devs said I should only use the development branch because master
doesn't compile, so yeah the bindings will be based on the latest
version.

It's pure irony that libgit devs don't have a stable main branch. I
mean, what exactly is Git for again? :D

GC is reclaiming live objects

[deadalnix]

And I don't use C stuff in the application. I don't explicitly free 
anything and use the last version of D.


Obviously, the problem isn't easy to reproduce in a small program, But I 
get consistent crash in some test cases.


So, What am I supposed to do now to investigate the issue ?

Re: GC is reclaiming live object

[deadalnix]

Le 10/10/2012 18:22, deadalnix a écrit :

And I don't use C stuff in the application. I don't explicitly free
anything and use the last version of D.

Obviously, the problem isn't easy to reproduce in a small program, But I
get consistent crash in some test cases.

So, What am I supposed to do now to investigate the issue ?


Sorry for that message, it seems that I posted it as an answer when it 
wasn't intended to be one.

Re: std.digest: can we get rid of start() functions?

[H. S. Teoh]

On Wed, Oct 10, 2012 at 06:21:10PM +0200, Piotr Szturmaj wrote:
> H. S. Teoh wrote:
> >Then you could just write:
> >
> > SHA1 sha1;
> > // calculate hash
> > sha1 = SHA1.init;
> > // calculate hash
> > ...
> >
> 
> In my proposal reset() does exactly the same.

My point was that there's no need to remember that there's a method
called "start" or "reset", etc., when we can just use .init which is
common to all types in D. It reduces cognitive load.


T

-- 
EMACS = Extremely Massive And Cumbersome System

Re: Error messages for newbies survey

[ixid]

On Wednesday, 10 October 2012 at 12:33:23 UTC, bearophile wrote:

 From Reddit, a nice survey:
http://www.reddit.com/r/coding/comments/118ssp/honours_student_at_my_university_is_doing_a/


For my Computer Science Honours research project, I am 
currently investigating ways of improving the terse, technical 
error messages given by traditional compilers to make them more 
useful to novice programmers. As part of this research, I have 
designed this survey to help determine which types of common 
novice errors are inadequately reported by a traditional 
compiler and to gather ideas on how they should be reported to 
a novice.<




Maybe I'm not quite as novice as most of those errors but by far 
the most frustrating thing is unhandled exceptions as a scrub. 
You just get thrown out of the program with no idea what caused 
it to sulk and little idea how to diagnose and fix it, making 
things like stack overflows and so on really irritating as a 
beginner.

Re: next_permutation and cartesian product for ranges?

[H. S. Teoh]

On Wed, Oct 10, 2012 at 10:59:32AM -0400, Andrei Alexandrescu wrote:
> On 10/10/12 10:27 AM, H. S. Teoh wrote:
> >On Wed, Oct 10, 2012 at 09:41:34AM -0400, Andrei Alexandrescu wrote:
[...]
> >>On another subject, I think this can be done with only input ranges
> >>- no need for bidirectional.
[...]
> >Using the Cantor method we can allow one range to be a forward range,
> >and the second a range whose take(n) is a reversible range (I was
> >wrong before: the second range doesn't need to be bidirectional, it
> >works as long as take(n) returns a reversible range). This gives us
> >constant space complexity. I'd say this is a pretty good solution.
> 
> I'm still thinking of Cantor's method, just a different schedule of
> spanning the triangle. Multiple save points are necessary. Consider
> you span the triangle in squares of increasing side. For each side
> size you first walk along one dimension, then walk along the other.
[...]
On Wed, Oct 10, 2012 at 11:00:43AM -0400, Andrei Alexandrescu wrote:
> On 10/10/12 10:59 AM, Andrei Alexandrescu wrote:
> >I'm still thinking of Cantor's method, just a different schedule of
> >spanning the triangle. Multiple save points are necessary.
> 
> I meant "Multiple save points are NOT necessary."
[...]

In the interest of not stalling the inclusion of a Cartesian product in
Phobos any longer (since the original discussion was apparently some
*years* ago), I propose that we check in the current implementation of
the Cantor method first, and then think about how we can improve it.
Since the improved version will *relax* the requirement on the argument
ranges, any code based on the current method shouldn't break with the
improved version once we figure out how to do it.


T

-- 
He who sacrifices functionality for ease of use, loses both and deserves
neither. -- Slashdotter

Re: std.digest: can we get rid of start() functions?

[Piotr Szturmaj]

H. S. Teoh wrote:

Then you could just write:

SHA1 sha1;
// calculate hash
sha1 = SHA1.init;
// calculate hash
...



In my proposal reset() does exactly the same.

GC is reclaiming live object

[deadalnix]

And I don't use C stuff in the application. I don't explicitly free 
anything and use the last version of D.


Obviously, the problem isn't easy to reproduce in a small program, But I 
get consistent crash in some test cases.


So, What am I supposed to do now to investigate the issue ?

Re: #pragma comment (lib, ...)

[Walter Bright]

On 10/10/2012 8:19 AM, Simen Kjaeraas wrote:

On 2012-10-10, 16:19, Walter Bright wrote:

Some object module formats do not have the ability to embed a library
reference in them. Elf (cough cough), Mach-O (wheeze)


ELF has .comment and .note sections. While they're not exactly intended
for the purpose, they seem to fit the bill?

It'd of course require a linker to know what to do with the data, but
it seems to me this would not interfere with other uses.


Exactly. Embedding it in a comment section accomplishes exactly nothing if the 
linker ignores it.

Re: #pragma comment (lib, ...)

[Manu]

On 10 October 2012 16:45, Paulo Pinto  wrote:

>
> This only works if it is part of the language definition.
>
> In C and C++ case I am usually against it, because I favour portability
> over dependencies to a specific compiler vendor. Many years of writing
> multi-platform code do leave some scars.
>

Errr, what? This enhanced portability, that's the point.
I've spent my career writing more cross-platform code than most coders
would touch in their lives, and I give thanks for the platforms where it is
available.
It always leads to a vastly simplified path in the build scripts for those
platforms that support it, and typically produces more reliable and
less fickle results; ie, I never experience link problems with those
platforms.

Multi-platform code always has #ifdef guards around #pragma
comment(lib,)-ing the appropriate libs for the platform which the code is
being built for, and that is the whole point. The code its self selects the
libs it depends on by simply being compiled.


As for D, if this can be made part of the language then I see no big reason
> against it.
>

Well, DMD says it is ;) .. Question is, is it technically possible for
other compilers to support it?

Re: std.digest: can we get rid of start() functions?

[H. S. Teoh]

On Wed, Oct 10, 2012 at 05:16:38PM +0200, Marco Leise wrote:
> Am Wed, 10 Oct 2012 16:28:36 +0200
> schrieb Johannes Pfau :
> 
> > There's makeDigest which calls start for you, so you can write code
> > like this:
> > 
> > auto sha1 = makeDigest!SHA1();
> > //calculate hash
> > sha1.start(); //start again
> > //calculate hash...
> 
> Just this point, I think it adds mental bloat. It is
> still easier to remember and shorter to use:
> 
> SHA1 sha1;
> sha1.start();
> //calculate hash
> sha1.start();
> //calculate hash...
[...]

What makes it so difficult that we cannot do this:

struct MyHash {
bool is_init = false;
...

void init() {
...
is_init = true;
}
void computeHash(...) {
if (!is_init)
init();

// Continue as usual
...
}
}

Then you could just write:

SHA1 sha1;
// calculate hash
sha1 = SHA1.init;
// calculate hash
...

Fits in better with the language, and no need to remember to call
start(), which adds mental load 'cos you have to remember it's called
"start" and not something else, and it's also is error-prone 'cos people
will forget to do it.


T

-- 
Famous last words: I wonder what will happen if I do *this*...

Re: Any interest in libgit bindings?

[Justin Whear]

On Wed, 10 Oct 2012 00:46:28 +0200, Andrej Mitrovic wrote:

> http://libgit2.github.com/
> 
> libgit has things like clone/commit/tag, reading/writing git loose
> object files. You can easily deflate object files using std.zlib, but
> unfortunately there's no git pack file unpacker in libgit (you can
> externally use git's unpack-objects command for that).
> 
> I don't know whether dstep[1] can autogenerate the bindings (haven't
> tried it myself), any luck there from anyone?
> 
> My dgen generator (unreleased) can generate bindings but it's a
> C++-based generator so the generated files aren't pure 1to1 bindings
> since forwarding functions were automatically generated (this is an
> implementation detail of the generator that can and will be fixed).
> 
> win32-based bindings are here, along with somewhat ported samples (a
> little hardcoded but things generally work):
> https://github.com/AndrejMitrovic/dgen_libgit
> 
> But if there's any interest I could clean it up and make it a nice
> simple C wrapper just like the other deimos projects
> (https://github.com/D-Programming-Deimos). If Dstep can do it
> automatically even better, but I didn't get to use it yet.
> 
> [1] https://github.com/jacob-carlborg/dstep/

I'd be interested.  I hand-wrote bindings to most of libgit2 (though not 
the latest version), but I skipped most of the write-oriented stuff, so a 
complete binding would be welcome.

Re: core.simd woes

[Manu]

On 10 October 2012 17:53, F i L  wrote:

> Manu wrote:
>
>> actually, no I won't, I'm doing a 48 hour game jam (which I'll probably
>> write in D too), but I'll do it soon! ;)
>>
>
> Nice :) For a competition or casual? I would love to see what you come up
> with. My brother and I released our second game (this time written with our
> own game-engine) awhile back: 
> http://www.youtube.com/watch?**v=7pvCcgQiXNkRight
>  now we're working on building 3D animation and Physics into the
> engine for our next project. It's written in C#, but I have plans for
> awhile that once it's to a certain point I'll be porting it to D.
>

It's a work event. Weekend office party effectively, with lots of beer and
sauna (essential ingredients in any Finnish happenings!)
I expect it'll be open source, should be on github, whatever it is. I'll
build it on my toy engine (also open source):
https://github.com/TurkeyMan/fuji/wiki, which has D bindings.

Re: std.digest: can we get rid of start() functions?

[Marco Leise]

Am Wed, 10 Oct 2012 16:28:36 +0200
schrieb Johannes Pfau :

> There's makeDigest which calls start for you, so you can write code
> like this:
> 
> auto sha1 = makeDigest!SHA1();
> //calculate hash
> sha1.start(); //start again
> //calculate hash...

Just this point, I think it adds mental bloat. It is
still easier to remember and shorter to use:

SHA1 sha1;
sha1.start();
//calculate hash
sha1.start();
//calculate hash...

-- 
Marco

Re: #pragma comment (lib, ...)

[Simen Kjaeraas]

On 2012-10-10, 16:19, Walter Bright wrote:


On 10/10/2012 4:26 AM, Manu wrote:
I think D's modules make this relationship even stronger, and it's a  
shame it's

not a standard part of D.


Some object module formats do not have the ability to embed a library  
reference in them. Elf (cough cough), Mach-O (wheeze)


ELF has .comment and .note sections. While they're not exactly intended
for the purpose, they seem to fit the bill?

It'd of course require a linker to know what to do with the data, but
it seems to me this would not interfere with other uses.

Note: The above comes from a 2-minute cursory read of the ELF standard,
and may thus contain errors. :p

--
Simen

Gathering info for D/Embedded presentation

[mist]

After some gentle preachings I have been asked in my company to 
prepare presentation regarding D usage in scope of embedded, 
kernel-level development and mobile devices. I am quite starving 
to find good project examples for D2 though ( most stuff I am 
aware of is D1 ) and do not have enough time to write some from 
scratch. Any suggestions here?


Regarding mobile development - I remember a thread some time ago 
regarding Android + D2 that I can't find anymore. What is current 
state of affairs?


Any general advices about D2 features and drawbacks to bring 
attention to are also welcome.

Re: #pragma comment (lib, ...)

[Marco Leise]

Am Wed, 10 Oct 2012 17:03:06 +0200
schrieb Marco Leise :

> Am Wed, 10 Oct 2012 14:22:38 +0100
> schrieb Iain Buclaw :
> 
> > To embody the information about the relationship in the object file,
> > one must be able to embody the information about the relationship in
> > the assembler file.  And last time I checked there is no assembly
> > syntax for '#pragma lib'.
> > 
> > 
> > Regards
> 
> Wit, both ELF .o and COFF .obj files can contain
> additional free form sections and comments, right?

Specifically the GNU toolchain adds ".note.GNU-stack" to
ELF object files on Linux. What prevents us from doing the
same with ".note.D-dynlink"?

-- 
Marco

Re: #pragma comment (lib, ...)

[Marco Leise]

Am Wed, 10 Oct 2012 14:22:38 +0100
schrieb Iain Buclaw :

> To embody the information about the relationship in the object file,
> one must be able to embody the information about the relationship in
> the assembler file.  And last time I checked there is no assembly
> syntax for '#pragma lib'.
> 
> 
> Regards

Wit, both ELF .o and COFF .obj files can contain
additional free form sections and comments, right?

-- 
Marco

Re: next_permutation and cartesian product for ranges?

[Andrei Alexandrescu]

On 10/10/12 10:59 AM, Andrei Alexandrescu wrote:

I'm still thinking of Cantor's method, just a different schedule of
spanning the triangle. Multiple save points are necessary.


I meant "Multiple save points are NOT necessary."

Andrei

Re: #pragma comment (lib, ...)

[Jesse Phillips]

On Wednesday, 10 October 2012 at 11:39:29 UTC, Iain Buclaw wrote:

NB: GCC has no such equivalent, and IMO libraries should be 
specified
during the linking step. Such information simply doesn't belong 
inside

a source file as a source file can be compiled or assembled even
without a linking stage.

Regards,


Well, to comply with the standard it must at least ignore it.

http://dlang.org/pragma.html

I don't see this needing to be outside the source files. Actually 
I'd be happy if all that was supported was exporting that 
information, probably to the json. What bothers me with not 
having this information in the library is that each project I 
create will now need to copy and paste my lib dependencies, or 
the general need to remember what library is used by a given 
library.


Marco,

As for versions. I don't know what version of ole32.dll I'm using 
or how to find out, I don't really care either. But I guess it 
would be good to have the option though.

Re: next_permutation and cartesian product for ranges?

[Andrei Alexandrescu]

On 10/10/12 10:27 AM, H. S. Teoh wrote:

On Wed, Oct 10, 2012 at 09:41:34AM -0400, Andrei Alexandrescu wrote:

On 10/9/12 7:25 PM, H. S. Teoh wrote:

I was an idiot. I knew about std.algorithm.joiner but for some reason
didn't think of it at the time. In any case, crossProduct doesn't
make any sense to me... I don't see what it's got to do with
flattening nested ranges.


I meant the resulting range spans the cross product (all combinations)
of the passed-in ranges.


Hmm. We must be using a different set of terms, because in my
understanding, a cross product is a binary operation on 3D vectors that
produces a perpendicular vector. The product that produces all
combinations of a set is known as a Cartesian product to me.


Same thing for sets. I agree using Cartesian is more precise.

http://www.transtutors.com/math-homework-help/set-theory/cartesian-product.aspx


On another subject, I think this can be done with only input ranges -
no need for bidirectional.

[...]

In the case of finite ranges, one of the ranges can be an input range,
but the other must at least be a forward range, since otherwise you
could only traverse it once, so it would be impossible to combine each
element with every element from the other range.


Yah.


When one of the ranges is infinite, it's obviously not enough for the
other range to be an input range, since you'd have to produce an
infinite number of combinations per element (of the second range) before
moving on to the next element, so you'd never get to it.


Something like that.


It should be possible to do it with both ranges being forward ranges,
but it may not be very efficient -- think about it, for every element in
one range, you need to combine it with every element in the other range,
so when you're at, say, the 100th element of the first range, you still
need to go back to the 1st, 2nd, 3rd, etc., elements in the second
range. But since you can only combine it with a finite number of
elements from the second range (otherwise you'll never get to the 101th
element), when you get to the 101th element, you still haven't produced
some of the combinations of the 100th element yet. So you'll end up
needing an increasing number of save points in order to get to every
possible combination -- possible but not efficient.

Using the Cantor method we can allow one range to be a forward range,
and the second a range whose take(n) is a reversible range (I was wrong
before: the second range doesn't need to be bidirectional, it works as
long as take(n) returns a reversible range). This gives us constant
space complexity. I'd say this is a pretty good solution.


I'm still thinking of Cantor's method, just a different schedule of 
spanning the triangle. Multiple save points are necessary. Consider you 
span the triangle in squares of increasing side. For each side size you 
first walk along one dimension, then walk along the other.



Andrei

Re: Will the D GC be awesome?

[Marco Leise]

Am Wed, 10 Oct 2012 15:24:58 +0200
schrieb "Simen Kjaeraas" :

> The NaN was intended as a joke, and to highlight the fact that
> you can have opCmp return a float today, and get some of the
> behavior that floats have.

Do you know this effect on bad news in the morning, that makes
you take satire serious for the rest of the day? :p

-- 
Marco

Re: core.simd woes

[F i L]

Manu wrote:
actually, no I won't, I'm doing a 48 hour game jam (which I'll 
probably

write in D too), but I'll do it soon! ;)


Nice :) For a competition or casual? I would love to see what you 
come up with. My brother and I released our second game (this 
time written with our own game-engine) awhile back: 
http://www.youtube.com/watch?v=7pvCcgQiXNk Right now we're 
working on building 3D animation and Physics into the engine for 
our next project. It's written in C#, but I have plans for awhile 
that once it's to a certain point I'll be porting it to D.

Re: Will the D GC be awesome?

[Alex Rønne Petersen]

On 10-10-2012 14:05, Marco Leise wrote:

Am Thu, 04 Oct 2012 15:27:58 +0200
schrieb Alex Rønne Petersen :


On 04-10-2012 15:21, Piotr Szturmaj wrote:

Jacob Carlborg wrote:
[…]
* For other struct sizes, the return value is stored through a hidden
pointer passed as an argument to the function.


I strongly advise ignoring the D calling convention. Only DMD implements
it and nowhere else than on Windows for 32-bit x86.

Instead, refer to the Windows and System V x86 ABIs.


The hidden pointer is exactly what I see MSVC++ produce for
struct returns (but even for 4 byte ones). e.g. "MyStruct
foo()" is equivalent to "foo(MyStruct&)"
I understand that the GCC people don't want to add YACC (yet
another calling-convention), but frankly Pascal got away with
a c-c of its own, too and I never heard anyone complain.
I mean aside from compiler implementations, what's the problem
with an own calling convention for D code calling D code if it
is more efficient?



The problem is ABI specification. Right now, you can't reliably write 
inline assembly in D because all the compilers use different calling 
conventions for extern (D).


Also, the Pascal calling convention is only supported by very few 
compilers today.


--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Re: #pragma comment (lib, ...)

[Paulo Pinto]

On Wednesday, 10 October 2012 at 14:44:20 UTC, Walter Bright 
wrote:

On 10/10/2012 4:49 AM, Paulo Pinto wrote:

On Wednesday, 10 October 2012 at 11:50:29 UTC, Manu wrote:
Really? Is it an MS thing? I'm amazed the other compilers 
haven't adopted

that in the last 10 years or whatever.


Yes, it is a Microsoft extension. I never saw it in any other 
C or C++ compiler.


Digital Mars C and C++ !!


I only became aware of Digital Mars thanks to D, I must confess.

When I moved away from Turbo Pascal, I started using Turbo C and 
Turbo C++, followed by Borland C++ and eventually Visual C++.


Then at the university I started to use vendor's C and C++ 
compilers of the multiple UNIX systems we had access to.


I used to see adverts for Watcom C/C++, High C/C++ and Zortech 
C/C++ in computer magazines, but never knew anyone that had 
access to them.


--
Paulo

Re: #pragma comment (lib, ...)

[Paulo Pinto]

On Wednesday, 10 October 2012 at 14:41:56 UTC, Walter Bright 
wrote:

On 10/10/2012 6:48 AM, Marco Leise wrote:

Linking is just time you wait until you can run your program.
In a modern language I'd like to understand compilation and
linking as one process.


Actually, I think you're right. There's no technical reason why 
the compiler can't go directly to an executable in one step.


I've often thought of doing this.


Turbo Pascal was already doing this back in 1987.

The Pascal family of languages always made me look down to C and 
C++ toolchains as stone age technology that I have to endure when 
using those languages.


This is actually one feature that I really like in JVM/.NET 
worlds, even in the native compiler versions that are available 
for them.


--
Paulo

Re: Error messages for newbies survey

[Don Clugston]

On 10/10/12 14:09, bearophile wrote:

  From Reddit, a nice survey:
http://www.reddit.com/r/coding/comments/118ssp/honours_student_at_my_university_is_doing_a/




For my Computer Science Honours research project, I am currently
investigating ways of improving the terse, technical error messages
given by traditional compilers to make them more useful to novice
programmers. As part of this research, I have designed this survey to
help determine which types of common novice errors are inadequately
reported by a traditional compiler and to gather ideas on how they
should be reported to a novice.<


http://www.esurveyspro.com/Survey.aspx?id=23752434-e25f-4a48-86bf-bb2634e1b5ce


So this survey is not to improve error messages in general, it's
specific for newbies. So the error situations shown in the survey
are not typical for C programmers.

Below some of the examples converted to D, with their relative
error messages.


Many of the things you report are examples of bug 8684. Please file bug 
reports for any others you think are important.

Re: std.digest: can we get rid of start() functions?

[Johannes Pfau]

Am Wed, 10 Oct 2012 15:02:40 +0200
schrieb Marco Leise :

> Am Wed, 10 Oct 2012 12:55:59 +0200
> schrieb Piotr Szturmaj :
> 
> > And replace them with global reset function:
> > 
> > void reset(T)(ref T digest)
> >  if (isDigest!T)
> > {
> >  digest = T.init;
> > }
> > 
> > Current usage:
> > 
> > SHA1 sha1;
> > sha1.start();
> > ... calculate hash
> > sha1.start(); // start again
> > ... calculate hash
> > 

There's makeDigest which calls start for you, so you can write code
like this:

auto sha1 = makeDigest!SHA1();
//calculate hash
sha1.start(); //start again
//calculate hash...

But the digests still have to implement a start method, even if it's
only a "this = typeof(this).init;". Maybe we could avoid the start
method by introducing a fallback UFCS start method...

> Unlike classes, structs don't mandate a ctor call, so in
> general you need to disguise the constructor as 'start()'
> 'Create()' or similar, where T.init is not sufficient. If on
> the other hand, you use a ".isInitialized = false" field
> instead of start(), then you'd have to unnecessarily check
> that every time data is added to the digest, instead of doing
> it once. (That might be personal taste though :) )
> 
> I think the constraints are:
> * no start() method ever takes arguments
> * no digest needs to allocate to start
> * no digest depends on global/static variables
> 

Yes, that's the main reason why we have 'start', but it also must work
as a reset function. The difficult question is whether there actually
is a hash algorithm (or whether there will be one in the future) which
needs such a complex start method.

No-allocation often means no C wrapper (although a C API could allow to
use stack objects, but often they just provide opaque structs), so this
is a little controversial. But if we allowed allocation we'd have to
worry about deallocation as well and then things get tricky. Reference
counting is probably still the easiest solution for those cases.

Re: next_permutation and cartesian product for ranges?

[H. S. Teoh]

On Wed, Oct 10, 2012 at 09:41:34AM -0400, Andrei Alexandrescu wrote:
> On 10/9/12 7:25 PM, H. S. Teoh wrote:
> >I was an idiot. I knew about std.algorithm.joiner but for some reason
> >didn't think of it at the time. In any case, crossProduct doesn't
> >make any sense to me... I don't see what it's got to do with
> >flattening nested ranges.
> 
> I meant the resulting range spans the cross product (all combinations)
> of the passed-in ranges.

Hmm. We must be using a different set of terms, because in my
understanding, a cross product is a binary operation on 3D vectors that
produces a perpendicular vector. The product that produces all
combinations of a set is known as a Cartesian product to me.


> On another subject, I think this can be done with only input ranges -
> no need for bidirectional.
[...]

In the case of finite ranges, one of the ranges can be an input range,
but the other must at least be a forward range, since otherwise you
could only traverse it once, so it would be impossible to combine each
element with every element from the other range.

When one of the ranges is infinite, it's obviously not enough for the
other range to be an input range, since you'd have to produce an
infinite number of combinations per element (of the second range) before
moving on to the next element, so you'd never get to it.

It should be possible to do it with both ranges being forward ranges,
but it may not be very efficient -- think about it, for every element in
one range, you need to combine it with every element in the other range,
so when you're at, say, the 100th element of the first range, you still
need to go back to the 1st, 2nd, 3rd, etc., elements in the second
range. But since you can only combine it with a finite number of
elements from the second range (otherwise you'll never get to the 101th
element), when you get to the 101th element, you still haven't produced
some of the combinations of the 100th element yet. So you'll end up
needing an increasing number of save points in order to get to every
possible combination -- possible but not efficient.

Using the Cantor method we can allow one range to be a forward range,
and the second a range whose take(n) is a reversible range (I was wrong
before: the second range doesn't need to be bidirectional, it works as
long as take(n) returns a reversible range). This gives us constant
space complexity. I'd say this is a pretty good solution.


T

-- 
Век живи - век учись. А дураком помрёшь.

Re: #pragma comment (lib, ...)

[Walter Bright]

On 10/10/2012 4:49 AM, Paulo Pinto wrote:

On Wednesday, 10 October 2012 at 11:50:29 UTC, Manu wrote:

Really? Is it an MS thing? I'm amazed the other compilers haven't adopted
that in the last 10 years or whatever.


Yes, it is a Microsoft extension. I never saw it in any other C or C++ compiler.


Digital Mars C and C++ !!

Re: #pragma comment (lib, ...)

[Walter Bright]

On 10/10/2012 4:26 AM, Manu wrote:

I think D's modules make this relationship even stronger, and it's a shame it's
not a standard part of D.


Some object module formats do not have the ability to embed a library reference 
in them. Elf (cough cough), Mach-O (wheeze)

Re: #pragma comment (lib, ...)

[Walter Bright]

On 10/10/2012 6:48 AM, Marco Leise wrote:

Linking is just time you wait until you can run your program.
In a modern language I'd like to understand compilation and
linking as one process.


Actually, I think you're right. There's no technical reason why the compiler 
can't go directly to an executable in one step.


I've often thought of doing this.

Re: #pragma comment (lib, ...)

[Walter Bright]

On 10/10/2012 6:45 AM, Paulo Pinto wrote:

In C and C++ case I am usually against it, because I favour portability over
dependencies to a specific compiler vendor. Many years of writing multi-platform
code do leave some scars.


Certainly, any particular use of this feature will be platform specific.

But you can use the version statement to adjust it for various platforms as 
required.

Re: std.digest: can we get rid of start() functions?

[Piotr Szturmaj]

Marco Leise wrote:

Unlike classes, structs don't mandate a ctor call, so in
general you need to disguise the constructor as 'start()'
'Create()' or similar, where T.init is not sufficient.


I know, but in case of digests their init data is always known at 
compile time, hence no special "constructor" is needed.



I think the constraints are:
* no start() method ever takes arguments
* no digest needs to allocate to start
* no digest depends on global/static variables


Yes, these constraints do not prevent digest structs to be correctly 
initialized after declaration.

Re: Will the D GC be awesome?

[Paulo Pinto]

On Wednesday, 10 October 2012 at 12:29:19 UTC, Marco Leise wrote:

Am Thu, 04 Oct 2012 15:27:58 +0200
schrieb Alex Rønne Petersen :


On 04-10-2012 15:21, Piotr Szturmaj wrote:
> Jacob Carlborg wrote:
> […]
> * For other struct sizes, the return value is stored through 
> a hidden

> pointer passed as an argument to the function.

I strongly advise ignoring the D calling convention. Only DMD 
implements it and nowhere else than on Windows for 32-bit x86.


Instead, refer to the Windows and System V x86 ABIs.


The hidden pointer is exactly what I see MSVC++ produce for
struct returns (but even for 4 byte ones). e.g. "MyStruct
foo()" is equivalent to "foo(MyStruct&)"
I understand that the GCC people don't want to add YACC (yet
another calling-convention), but frankly Pascal got away with
a c-c of its own, too and I never heard anyone complain.


Because many moons ago people did use Pascal dialects for systems 
programming, and thanks to it, the Pascal calling convention 
earned its place in the land of operating systems calling 
conventions.



--
Paulo

Re: #pragma comment (lib, ...)

[Marco Leise]

Am Wed, 10 Oct 2012 15:59:42 +0300
schrieb Manu :

> None of those things actually embody the information about the
> relationship, nor can they. The source code does, and nothing else.
> Features that imply the dependency may (and often are) be disabled at
> compile time.
> I rather like that the compiler is able to put a note in the object file
> that it depends on a particular lib, because it does.
> […]

I share your opinion whole-heartedly! I've been on #rust,
yesterday and someone had problems with the bindings generator
not writing out the library name:

#[link_args = "-l"]

As you can see, you see nothing. But the question here really
is: "Don't you force the language into using 'ld' as a linker
if you use it's command-line?"

Linking is just time you wait until you can run your program.
In a modern language I'd like to understand compilation and
linking as one process. LTO and pragma(lib, ...) are steps
in that direction. (And single file compilation should work
without seems compared to one-step compilation.)

Part or all of the linker should be in the compiler, to allow
external(...)-declarations to work without additional platform
and compiler dependent command-line additions. Problematic
cases are for example the 'escape' switches used by different
compilers to pass arguments on to the linker in one-step mode,
or 'missing' .so-names on some distributions that make it
difficult to name a specific version, e.g. lua-4.2.

We should learn from package managers and improve on
pragma(lib, ...) to support dependencies like this:

// lua.dll or liblua.so.4 (or highest liblua.so.4.*)
pragma(lib, "lua-4.*");
// can match mysqlclient.dll or libmysqlclient.so.16
pragma(lib, ">=mysqlclient-12");

This would go through the system specific library paths and
lookup version information from .dlls or so-names. In my
opinion, just linking to a library without version constraints
is not enough.

-- 
Marco

Re: #pragma comment (lib, ...)

[Paulo Pinto]

On Wednesday, 10 October 2012 at 13:23:57 UTC, Manu wrote:

On 10 October 2012 15:42, Jacob Carlborg  wrote:


On 2012-10-10 13:15, Iain Buclaw wrote:

 NB: GCC has no such equivalent, and IMO libraries should be 
specified
during the linking step. Such information simply doesn't 
belong inside
a source file as a source file can be compiled or assembled 
even

without a linking stage.



I agree, I think a package manager together with a build tool 
should be

used instead.



None of those things actually embody the information about the
relationship, nor can they. The source code does, and nothing 
else.
Features that imply the dependency may (and often are) be 
disabled at

compile time.
I rather like that the compiler is able to put a note in the 
object file

that it depends on a particular lib, because it does.
I'm not sure how a package manager helps... What is a package 
manager? ;)
I'd like to hear some reasons why that is a bad or undesirable 
thing, or is

this just an opinion?



This only works if it is part of the language definition.

In C and C++ case I am usually against it, because I favour 
portability over dependencies to a specific compiler vendor. Many 
years of writing multi-platform code do leave some scars.


As for D, if this can be made part of the language then I see no 
big reason against it.


--
Paulo

Re: next_permutation and cartesian product for ranges?

[Andrei Alexandrescu]

On 10/9/12 7:25 PM, H. S. Teoh wrote:

I was an idiot. I knew about std.algorithm.joiner but for some reason
didn't think of it at the time. In any case, crossProduct doesn't make
any sense to me... I don't see what it's got to do with flattening
nested ranges.


I meant the resulting range spans the cross product (all combinations) 
of the passed-in ranges.


On another subject, I think this can be done with only input ranges - no 
need for bidirectional.



Andrei

Re: Will the D GC be awesome?

[Simen Kjaeraas]

On 2012-10-10, 14:24, Marco Leise wrote:


enum Comparison {
 Before = -1,
 Same = 0,
 After = 1,
 Unordered = NaN,
}



a) There is no integer NaN and floating point is a no-go.


The NaN was intended as a joke, and to highlight the fact that
you can have opCmp return a float today, and get some of the
behavior that floats have.



b) If you mix sortable and unsortable most algorithms fail.

Otherwise an enum solution is good, but a bit longer in
code:

auto rel = a.OpCmp(b);
if (rel < 0) ...;
else if (rel > 0) ...;
else ...;

vs.

if (rel == Comparison.Before) ...;
else if (rel == Comparison.After) ...;
else ...;

And in many cases right now you can just "return a - b";


Yeah, this last part is what I really like about the
current solution. Of course, if we could have ranged enums:

enum Comparison {
Before < 0,
Same = 0,
After > 0
}

But that's not going to happen (unless someone provides it
in a library, of course).

--
Simen

Re: #pragma comment (lib, ...)

[Iain Buclaw]

On 10 October 2012 13:59, Manu  wrote:
> On 10 October 2012 15:42, Jacob Carlborg  wrote:
>>
>> On 2012-10-10 13:15, Iain Buclaw wrote:
>>
>>> NB: GCC has no such equivalent, and IMO libraries should be specified
>>> during the linking step. Such information simply doesn't belong inside
>>> a source file as a source file can be compiled or assembled even
>>> without a linking stage.
>>
>>
>> I agree, I think a package manager together with a build tool should be
>> used instead.
>
>
> None of those things actually embody the information about the relationship,
> nor can they. The source code does, and nothing else. Features that imply
> the dependency may (and often are) be disabled at compile time.
> I rather like that the compiler is able to put a note in the object file
> that it depends on a particular lib, because it does.
> I'm not sure how a package manager helps... What is a package manager? ;)
> I'd like to hear some reasons why that is a bad or undesirable thing, or is
> this just an opinion?

IIRC the toolchain used by Visual Studio *always* performs linking, so
that is why this is not a problem for MSVC.

To embody the information about the relationship in the object file,
one must be able to embody the information about the relationship in
the assembler file.  And last time I checked there is no assembly
syntax for '#pragma lib'.


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: std.digest: can we get rid of start() functions?

[Marco Leise]

Am Wed, 10 Oct 2012 12:55:59 +0200
schrieb Piotr Szturmaj :

> And replace them with global reset function:
> 
> void reset(T)(ref T digest)
>  if (isDigest!T)
> {
>  digest = T.init;
> }
> 
> Current usage:
> 
> SHA1 sha1;
> sha1.start();
> ... calculate hash
> sha1.start(); // start again
> ... calculate hash
> 
> New usage:
> 
> SHA1 sha1;
> ... calculate hash
> sha1.reset(); // start egain
> ... calculate hash

Unlike classes, structs don't mandate a ctor call, so in
general you need to disguise the constructor as 'start()'
'Create()' or similar, where T.init is not sufficient. If on
the other hand, you use a ".isInitialized = false" field
instead of start(), then you'd have to unnecessarily check
that every time data is added to the digest, instead of doing
it once. (That might be personal taste though :) )

I think the constraints are:
* no start() method ever takes arguments
* no digest needs to allocate to start
* no digest depends on global/static variables

-- 
Marco

Re: #pragma comment (lib, ...)

[Manu]

On 10 October 2012 15:42, Jacob Carlborg  wrote:

> On 2012-10-10 13:15, Iain Buclaw wrote:
>
>  NB: GCC has no such equivalent, and IMO libraries should be specified
>> during the linking step. Such information simply doesn't belong inside
>> a source file as a source file can be compiled or assembled even
>> without a linking stage.
>>
>
> I agree, I think a package manager together with a build tool should be
> used instead.


None of those things actually embody the information about the
relationship, nor can they. The source code does, and nothing else.
Features that imply the dependency may (and often are) be disabled at
compile time.
I rather like that the compiler is able to put a note in the object file
that it depends on a particular lib, because it does.
I'm not sure how a package manager helps... What is a package manager? ;)
I'd like to hear some reasons why that is a bad or undesirable thing, or is
this just an opinion?

Re: "instanceOf" trait for conditional implementations

[Marco Leise]

Am Thu, 04 Oct 2012 14:43:00 +0200
schrieb "so" :

> OT - Is there any reason for disabling UFCS for this?
> 
> template isAssignable(Lhs, Rhs)
> {
>  enum bool isAssignable =
>  {
>  Lhs l = void;
>  void f(Rhs r) { l = r; }
>  return l;
>  }.typeof.is;
> }

Yoda says: "This proposal a special type of is!"

-- 
Marco

Re: #pragma comment (lib, ...)

[Jacob Carlborg]

On 2012-10-10 13:15, Iain Buclaw wrote:


NB: GCC has no such equivalent, and IMO libraries should be specified
during the linking step. Such information simply doesn't belong inside
a source file as a source file can be compiled or assembled even
without a linking stage.


I agree, I think a package manager together with a build tool should be 
used instead.


--
/Jacob Carlborg

Re: Any interest in libgit bindings?

[Jacob Carlborg]

On 2012-10-10 00:46, Andrej Mitrovic wrote:

http://libgit2.github.com/

libgit has things like clone/commit/tag, reading/writing git loose
object files. You can easily deflate object files using std.zlib, but
unfortunately there's no git pack file unpacker in libgit (you can
externally use git's unpack-objects command for that).

I don't know whether dstep[1] can autogenerate the bindings (haven't
tried it myself), any luck there from anyone?


If there aren't too many macros or bitfields it shouldn't be any 
problem. But the more people use it the better it can be.



My dgen generator (unreleased) can generate bindings but it's a
C++-based generator so the generated files aren't pure 1to1 bindings
since forwarding functions were automatically generated (this is an
implementation detail of the generator that can and will be fixed).

win32-based bindings are here, along with somewhat ported samples (a
little hardcoded but things generally work):
https://github.com/AndrejMitrovic/dgen_libgit

But if there's any interest I could clean it up and make it a nice
simple C wrapper just like the other deimos projects
(https://github.com/D-Programming-Deimos). If Dstep can do it
automatically even better, but I didn't get to use it yet.


I would absolutely have interest in this.

--
/Jacob Carlborg

Re: Will the D GC be awesome?

[Marco Leise]

Am Thu, 04 Oct 2012 16:12:43 +0200
schrieb "Simen Kjaeraas" :

> On 2012-27-04 07:10, Walter Bright  wrote:
> 
> >> * OpCmp returning an int is fugly I r sad
> >
> > How else would you return a 3 state value?
> 
> enum Comparison {
>  Before = -1,
>  Same = 0,
>  After = 1,
>  Unordered = NaN,
> }
> 
> I'm not saying it should be done, but it would be more readable
> (and more cmoplex to write).

a) There is no integer NaN and floating point is a no-go.
b) If you mix sortable and unsortable most algorithms fail.

Otherwise an enum solution is good, but a bit longer in
code:

auto rel = a.OpCmp(b);
if (rel < 0) ...;
else if (rel > 0) ...;
else ...;

vs.

if (rel == Comparison.Before) ...;
else if (rel == Comparison.After) ...;
else ...;

And in many cases right now you can just "return a - b";

-- 
Marco

Re: core.simd woes

[Manu]

On 10 October 2012 14:50, Iain Buclaw  wrote:

> On 10 October 2012 12:25, David Nadlinger  wrote:
> > On Wednesday, 10 October 2012 at 08:33:39 UTC, Manu wrote:
> >>
> >> I do indeed care about debug builds, but one interesting possibility
> that
> >> I
> >> discussed with Walter last week was a #pragma inline statement, which
> may
> >> force-enable inlining even in debug. I'm not sure how that would
> translate
> >> to GDC/LDC, […]
> >
> >
> > pragma(always_inline) or something like that would be trivially easy to
> > implement in LDC.
> >
> > David
>
> Currently pragma(attribute, alway_inline) in GDC, but I am considering
> scrapping pragma(attribute) - the current implementation kept only for
> attributes used by gcc builtin functions - and introduce each
> supported attribute as an individual pragma.
>

Right, well that's encouraging then. Maybe all the pieces fit, and we can
perform liberal wrapping of the compiler-specific intrinsics in that case.

Re: Will the D GC be awesome?

[Marco Leise]

Am Fri, 05 Oct 2012 08:43:53 +0200
schrieb Jacob Carlborg :

> We already have the .tupleof property:
> 
> struct Foo
> {
>  int x;
>  int y;
> }
> 
> void foo (int a, int b)
> {
>  writeln(a, " ", b);
> }
> 
> void main ()
> {
>  auto f = Foo(1, 2);
>  foo(f.tupleof);
> }
> 
> This works today and I'm pretty sure it has for a long time.

Thanks for this practical usage example. I always
ignored .tupleof. Next time I contemplate if I should make a
function take a "Rect" struct or four coordinates, I'll
remember that!

-- 
Marco

Re: Will the D GC be awesome?

[Marco Leise]

Am Thu, 04 Oct 2012 15:27:58 +0200
schrieb Alex Rønne Petersen :

> On 04-10-2012 15:21, Piotr Szturmaj wrote:
> > Jacob Carlborg wrote:
> > […]
> > * For other struct sizes, the return value is stored through a hidden
> > pointer passed as an argument to the function.
> 
> I strongly advise ignoring the D calling convention. Only DMD implements 
> it and nowhere else than on Windows for 32-bit x86.
> 
> Instead, refer to the Windows and System V x86 ABIs.

The hidden pointer is exactly what I see MSVC++ produce for
struct returns (but even for 4 byte ones). e.g. "MyStruct
foo()" is equivalent to "foo(MyStruct&)"
I understand that the GCC people don't want to add YACC (yet
another calling-convention), but frankly Pascal got away with
a c-c of its own, too and I never heard anyone complain.
I mean aside from compiler implementations, what's the problem
with an own calling convention for D code calling D code if it
is more efficient?

-- 
Marco

Error messages for newbies survey

[bearophile]

 From Reddit, a nice survey:
http://www.reddit.com/r/coding/comments/118ssp/honours_student_at_my_university_is_doing_a/


For my Computer Science Honours research project, I am currently 
investigating ways of improving the terse, technical error 
messages given by traditional compilers to make them more useful 
to novice programmers. As part of this research, I have designed 
this survey to help determine which types of common novice 
errors are inadequately reported by a traditional compiler and 
to gather ideas on how they should be reported to a novice.<


http://www.esurveyspro.com/Survey.aspx?id=23752434-e25f-4a48-86bf-bb2634e1b5ce

So this survey is not to improve error messages in general, it's
specific for newbies. So the error situations shown in the survey
are not typical for C programmers.

Below some of the examples converted to D, with their relative
error messages.

-

void main() {
 int height = 25;
 int width = 50;
 int area = height.width;
}


temp.d(4): Error: undefined identifier 'width'

-

void main() {
 int x = 3;
 int y = 2(x + 1);
}


temp.d(3): Error: function expected before (), not 2 of type int

-

int main() {
 for (int i = 0, i < 10, i++) {
 // do something
 }
 return 0;
}


temp.d(2): Error: semicolon expected, not '<'
temp.d(2): Error: expression expected, not '<'
temp.d(2): Error: found '10' when expecting ';' following for
condition
temp.d(2): Error: expression expected, not ','
temp.d(2): Error: found 'i' when expecting ')'
temp.d(2): Error: expression expected, not ')'
temp.d(2): Error: found '{' when expecting ';' following statement
temp.d(5): Error: Declaration expected, not 'return'
temp.d(6): Error: unrecognized declaration

-

void main() {
   int value = 0;

   while (value < 10) do {
 // do something
 value++;
   }
}


temp.d(8): Error: found '}' when expecting 'while'
temp.d(8): Error: found 'EOF' when expecting '('
temp.d(8): Error: expression expected, not 'EOF'
temp.d(8): Error: found 'EOF' when expecting ')'
temp.d(8): Deprecation: do-while statement without terminating ;
is deprecated
temp.d(8): Error: found 'EOF' when expecting '}' following
compound statement

-

void main() {
 double value = 1;

 switch (value) {
   case 1:
 // do something
 break;
 }
}


temp.d(4): Error: 'value' is not of integral type, it is a double
temp.d(5): Error: case must be a string or an integral constant,
not 1
temp.d(4): Deprecation: non-final switch statement without a
default is deprecated

-

void main() {
 int i = 0;

 if (i => 0) {
   // do something
 }
}


temp.d(4): Error: expression __lambda2 of type void does not have
a boolean value

-

void toDouble(int integer) {
 return cast(double)integer;
}
int main() {
 double x = toDouble(1);
 return 0;
}


temp.d(2): Error: cast has no effect in expression
(cast(double)integer)
temp.d(2): Error: cannot return non-void from void function
temp.d(5): Error: expression toDouble(1) is void and has no value

-

int f(int x) {
 return x * x - x + 1;
}
int main() {
 int x = 5;
 x = f;
 return 0;
}


temp.d(6): Error: not a property f

-

import std.math;
int main() {
 double x, y;
 x = 0.5;
 sin(x) = y;
 return 0;
}


temp.d(5): Error: sin(cast(real)x) is not an lvalue

-

void main() {
 int arr[10];

 for (int i = 0; i < 10; i++) {
 arr(i) = 0;
 }
}

temp.d(5): Error: function expected before (), not arr of type
int[10u]

-

import std.stdio;
int main() {
 int i = 1;
 printf("%f\n", i);
 return 0;
}


0.00

(DMD gives no warning here)

=

Let me add few basic mistakes specific for D, and the error
messages they generate:


void main() {
 foreach (i, 0 .. 10) {}
}


temp.d(2): Error: basic type expected, not 0
temp.d(2): Error: no identifier for declarator int
temp.d(2): Error: found '0' when expecting ';'
temp.d(2): Error: expression expected, not '..'
temp.d(2): Error: found '10' when expecting ')'
temp.d(2): Error: found ')' instead of statement
temp.d(3): Error: unrecognized declaration

-

void main() {
 int[10] data;
 foreach (i, x, data) {}
}



temp.d(3): Error: no identifier for declarator data
temp.d(3): Error: found ')' when expecting ';'
temp.d(4): Error: found '}' when expecting ')'
temp.d(4): Error: found 'EOF' instead of statement
temp.d(4): Error: found 'EOF' when expecting '}' following
compound statement

-

void main() {
 int[10] data;
 foreach (i; x; data) {}
}


temp.d(3): Err

Re: What is the case against a struct post-blit default constructor?

[Don Clugston]

On 10/10/12 13:27, Timon Gehr wrote:

On 10/10/2012 12:45 PM, Don Clugston wrote:

On 10/10/12 11:21, Jonathan M Davis wrote:

On Monday, October 08, 2012 18:47:43 Malte Skarupke wrote:

So I really can't think of a reason for why you wouldn't want
this. Yet this discussion has happened several times already.
There is clear demand for it and very good reasons, such as those
mentioned in all the linked discussions.

So why is this being rejected?


It buys you pretty much nothing. There are plenty of places in the
language
where init is required (e.g. member variables that can't be directly
initialized and the elements in an array). So, init _will_ be used
regardless
of what you do with the default constructor. If you want to prevent
that, then
you need to disable init, which we can already do. But you're not
going to get
those things initialized with the default constructor, which kind of
defeats
the purpose of the default constructor. If you can't guarantee that
every
instance which isn't explicitly constructed is default constructed, then
what's the point?


Of course there would be no point.
You have not answered the question. The issue is, WHY can we not
guarantee that that the struct default constructor is called?



Because the current language does not. :o)

Because that would imply disabling .init.
  - Which defeats the .init idiom in generic code. I am not convinced
that we need that though.


I don't like the .init idiom, I'm not sure it actually works. The 
semantics of .init aren't well defined. There is no guarantee that it is 
a valid value of the type.



 (T x)=>... does the job just fine, and

.init has issues, as eg. int.init has special implicit conversion
rules that not all members of the type int share.
  - Need a new (unsafe) language feature in order to be able to
implement eg. 'emplace'.


Exactly.



I have a vague memory that Walter mentioned a technical difficulty once
but I don't remember anything about what it was.

I can't imagine what it would be.


+1.


Even in the worst case, it would be
possible to run CTFE on the default constructor in order to create
.init. This would limit the default constructor to things which are
CTFEable, but even that would still be useful for templated structs.



You could run CTFE on the default constructor iff .init is requested,
but I don't really see the point. What would be the benefit?


You could have more complicated relationships between members.

struct W
{
  int x;
  int y;
}

W bar(T)() { return W(T.sizeof, T.alignof); }

struct Foo(T)
{
   int m;
   int n;
   int k;

   this() {
 W w = bar!(T)();
 m = w.x;
 n = w.y;
 k = abs(64 - m - n);
   }
}

of course it gains in value as bar!()() gets more complicated.



Really, there does not seem to me to be any point in having an invariant
for a struct, without a default constructor.



One can use a dented invariant.

struct S{
 bool valid = false;
 // ...
 invariant(){ if(valid) assert(...); }
 void establishInvariant()out{assert(valid);}body{...}
}


Yes, you have to do something like that. It's absolute garbage. When you 
have a hack like that, I don't see the point of having invariants in the 
language.




BTW .init doesn't really work for nested structs anyway. There are
several open bugs related to that.



That is true, what are the plans for that?


Don't know.

Re: core.simd woes

[Iain Buclaw]

On 10 October 2012 12:25, David Nadlinger  wrote:
> On Wednesday, 10 October 2012 at 08:33:39 UTC, Manu wrote:
>>
>> I do indeed care about debug builds, but one interesting possibility that
>> I
>> discussed with Walter last week was a #pragma inline statement, which may
>> force-enable inlining even in debug. I'm not sure how that would translate
>> to GDC/LDC, […]
>
>
> pragma(always_inline) or something like that would be trivially easy to
> implement in LDC.
>
> David

Currently pragma(attribute, alway_inline) in GDC, but I am considering
scrapping pragma(attribute) - the current implementation kept only for
attributes used by gcc builtin functions - and introduce each
supported attribute as an individual pragma.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: #pragma comment (lib, ...)

[Paulo Pinto]

On Wednesday, 10 October 2012 at 11:50:29 UTC, Manu wrote:
On 10 October 2012 14:15, Iain Buclaw  
wrote:



On 10 October 2012 09:31, Manu  wrote:
> Percect, thanks!
>
>
> On 10 October 2012 11:27, Walter Bright 
> 

wrote:
>>
>> On 10/10/2012 1:22 AM, Manu wrote:
>>>
>>> Does D support some sort of #pragma lib?
>>
>>
>> Yes:
>>
>> pragma(lib, "mylib.lib");
>
>

NB: GCC has no such equivalent, and IMO libraries should be 
specified
during the linking step. Such information simply doesn't 
belong inside
a source file as a source file can be compiled or assembled 
even

without a linking stage.



Really? Is it an MS thing? I'm amazed the other compilers 
haven't adopted

that in the last 10 years or whatever.


Yes, it is a Microsoft extension. I never saw it in any other C 
or C++ compiler.


Maybe Intel and CodeGear compilers have it, since they value MSVC 
compatibility.


--
Paulo

Re: What is the case against a struct post-blit default constructor?

[foobar]

On Wednesday, 10 October 2012 at 11:23:11 UTC, Jonathan M Davis 
wrote:

On Wednesday, October 10, 2012 12:45:20 Don Clugston wrote:

Of course there would be no point.
You have not answered the question. The issue is, WHY can we 
not

guarantee that that the struct default constructor is called?

I have a vague memory that Walter mentioned a technical 
difficulty once

but I don't remember anything about what it was.

I can't imagine what it would be.


I know that one of the issues was exceptions, though that could 
be solved by
forcing them to be nothrow. There were others, but I don't 
remember the
details. Certainly, from what I recall, the situation is such 
that you'd have
to restrict a default construtor so thoroughly that it would be 
pretty much

pointless to have one at all.


Even in the worst case, it would be
possible to run CTFE on the default constructor in order to 
create
.init. This would limit the default constructor to things 
which are
CTFEable, but even that would still be useful for templated 
structs.


Of what real value is a default construct that must be 
CTFEable? If you can
construct everything at compile time, then you can directly 
initialize each of
the member variables. It's being able to run a default 
constructor at runtime
that's useful, and since init must be known at compile time, 
you get into the
whole issue of needing init when you can't use a default 
constructor. For
default constructors to be of any real value, it would have to 
be possible to
replace all instances of init with a call to the default 
constructor _at
runtime_. As long as you're restricted to CTFE, you might as 
well just
directly initialize the member variables to set the values 
appropriately in

the init property.

- Jonathan M Davis


Can you please elaborate on where the .init property is being 
relied on? This is an aspect of D I don't really understand. 
What's the difference between a no-arg ctor and one with args in 
relation to this requirement?


Is this used somewhere in template code? I vaguely remember the 
clear() function is supposed to be related to this.


Personally, I don't agree with Walter's stance on default 
initialization. An explicit init by the user is IMO better design 
since it is _explicit_ and therefore documents the programmer's 
intention in the code itself.

i.e.:
int x = 0; // this is explicit and states my intention
int x; // is it intentionally == 0? Did I forget to set a 
meaningful value?